把"每天点十几下导出一份报表"这类重复劳动，变成一句"跑一下导出日报"就能完成的事，是录制式自动化能带来的直接收益。思路很简单：你在浏览器里正常操作一遍，插件记录下点击、输入、跳转的轨迹，再把这条轨迹保存成一个 Skill；下次只改几个参数（日期、关键词、文件名）就能重放。本文讲清从录第一遍到参数化、批量下载的完整流程，也讲清它会在什么地方失效。
这篇能做出什么
先看三个具体成果，判断是否值得投入时间：
- 自动导出：进入后台 → 选日期范围 → 点查询 → 点导出 → 等文件落到下载目录。录一次，之后每次只改日期。
- 自动填表：把一列数据（比如客户名单）逐个填进表单并提交，每个字段都来自参数数组。
- 批量下载：在列表页逐条点开详情，把附件按
日期_单号.pdf的规则存下来，避免重名覆盖。
需要提前说清楚的边界：录制式自动化不是"写完就一劳永逸"的脚本。目标网站改版、按钮改名、登录态过期、出现验证码，都会让 Skill 中途失败。把它当成"把 30 分钟手工压到 3 分钟、偶尔需要修一下"的工具，预期会更稳。
前置条件清单
动手前先确认这几项，缺一项后面都会卡住：
- 桌面版 Chromium 内核浏览器（Chrome、Edge 等，具体兼容范围以扩展商店页面的当前说明为准）。
- 已从官方渠道安装 Kimi 浏览器插件，并完成账号登录。
- 目标网站的账号已登录，且你有权对该账号做自动化操作。
- 明确知道哪些字段是"每次会变"的：日期、关键词、文件名、页码等。
- 一个可以随便试错的测试环境或测试数据，别一上来就拿生产账号跑循环。
- 记录一下插件版本号。版本更新后行为可能变化，出问题时这是第一条排查线索。
另外提醒一句：插件里"录制""自动化""Skill"这些入口的命名和位置会随版本调整，本文描述的是通用流程，具体按钮名称以官方文档或扩展页面的当前说明为准。
第 1 步：先用文字把流程写一遍
别急着点录制。先在记事本里用人话写出来，这份清单既是操作指南，也是之后的验收标准。
```text
1. 打开 https://example.com/login
2. 输入用户名、密码，点登录
3. 进入「订单」页面
4. 日期范围设为 {{start_date}} 到 {{end_date}}
5. 点「查询」
6. 等待列表加载完成
7. 点「导出」
8. 等文件下载完成
```
写的时候做一个判断：这一步每次是不是都一样？一样就写死，不一样就写成 {{变量}}。经验是，绝大多数流程只有 3 到 6 个真需要参数化的地方，剩下的都是固定动作。
第 2 步：安装、授权与固定版本
1. 从官方渠道安装插件后，打开目标网站，点插件图标。
2. 授予"读取和更改网站数据"的权限。注意权限是按站点给的，从 a.example.com 换到 b.example.com 可能要重新授权。
3. 如果插件面板里有"录制""自动化"之类的开关，先打开它。
4. 顺手检查浏览器设置里的下载项：关闭"下载前询问每个文件的保存位置"，否则批量下载时会被弹窗打断。
第 3 步：录第一遍，慢一点
开始录制后，按第 1 步的清单操作，有几个细节直接影响后面能不能跑通：
- 慢一点。每一步等页面稳定再点下一个元素，录制工具记录的是"当时那个元素"，页面还在刷新时点下去，记录的定位会偏。
- 输入框先点一下再输入，不要用 Tab 键跳。很多组件只有获得焦点后才挂载真实输入框。
- 下拉框直接点选项，不要用键盘盲打文字去匹配。
- 遇到弹窗、新手引导、Cookie 提示，先关掉再继续。或者故意把它录进去，然后在步骤列表里把它挪到最前面。
- 录完立刻回头看步骤列表，删掉多余的点击（比如误触的空白区域）。
第 4 步：把写死的值改成参数
录制会产生一条步骤序列，大致长这样（下面是示意，真实格式以插件导出结果为准）：
```yaml
name: 导出日报
params:
- start_date
- end_date
steps:
- action: goto
url: "https://example.com/orders"
- action: type
target: 日期开始输入框
value: "{{start_date}}"
- action: type
target: 日期结束输入框
value: "{{end_date}}"
- action: click
target: 查询按钮
- action: wait_for
target: 结果列表
- action: click
target: 导出按钮
```
参数化遵循三条原则：
1. 每次会变的值才参数化。日期、关键词、金额区间、文件名规则。
2. 能算出来的不要手填。比如"昨天"用内置的时间表达式，避免每次手工改。
3. 敏感信息不要明文写进 Skill。用户名密码尽量走已登录的会话，或者引用凭据管理功能，别把密码贴在步骤里。
第 5 步：先跑两次，再换数据跑一次
- 用同一组数据连续跑两次，结果应该完全一致。第二次失败通常意味着上一步留下了状态（比如页面还停在结果页）。
- 换一组数据再跑，比如把日期换成上周，验证参数真的生效，而不是被缓存了。
- 失败时看日志停在哪一步。录制式工具排错的关键就是"定位到具体步骤"，而不是笼统地说"跑失败了"。
第 6 步：进阶——循环抓取与批量下载
批量任务的写法是"先取数组，再对每一项执行子流程"：
```text
1. 打开列表页，抓取当前页所有行的单号，存成 list
2. 对 list 中的每个 id：
a. 打开详情页 https://example.com/order/{{id}}
b. 下载附件，保存为 {{deadline}}_{{id}}.pdf
c. 返回列表页
```
两个要点：
- 文件名必须带唯一变量。全叫
report.pdf的话，后面的文件会把前面的覆盖掉。 - 循环里要有等待和重试。每一步之间留出固定或随机的间隔，别一路狂奔，既容易失败，也容易触发网站的访问频率限制。
第 7 步：决定用什么方式触发
- 对话触发：直接说"跑一下导出日报，日期是昨天"，适合临时用。
- 定时触发：如果客户端或插件支持定时任务，注意电脑要开机、网络要通、登录态要有效。
- 手动触发：作为兜底，出错时能随时重来一遍。
常见坑与排错
| 现象 | 原因 | 处理方式 |
|---|---|---|
| 找不到元素 / 点错位置 | 定位方式太脆（坐标、深层 CSS） | 改用文本、label、按钮名等语义定位 |
| 页面没加载完就点 | 没有等待 | 在动作前加"等某元素出现"的显式等待 |
| 被弹窗挡住 | 遮罩层未关闭 | 在流程开头加关闭弹窗步骤 |
| 昨天能跑，今天报错 | 网站改版 | 重新录一遍该步骤，并把定位写得更稳 |
| 登录态过期 | 会话超时 | 把登录做成第一步，或先判断是否已登录 |
| 卡在验证码 | 自动化难以绕过 | 人工过验证后接管，或改用官方 API |
| 跨 iframe 操作失败 | 上下文未切换 | 显式切换到对应 iframe 再操作 |
| 打开新标签页后断掉 | 未处理新窗口 | 显式切换窗口句柄，或改成当前页跳转 |
| 文件被覆盖 | 文件名重复 | 文件名拼上时间戳或单号 |
| 被限速或拦截 | 频率过高 | 降低频率、加随机间隔、遵守网站条款 |
哪些网站容易中途失效
以下类型要有心理准备，稳定性会明显低一些：
- 登录重、验证码多的站点：每次跑都要人工介入。
- 频繁改版的前端单页应用：按钮的 DOM 结构一变，定位就失效。
- 有反自动化检测的站点：可能返回空数据或直接阻断。
- 大量 iframe、弹窗、新窗口的站点：上下文切换容易出错。
- 依赖短信、扫码二次确认的站点：基本无法无人值守。
一个务实的判断标准：如果这个网站提供了官方 API 或"导出为 CSV"的入口，优先走那条路；录制 Skill 更适合"没有 API、但操作路径很固定"的场景。
下一步建议
1. 从高频小任务开始。选一个"每周至少跑 3 次、每次 5 分钟"的操作，投入产出比最直观。
2. 拆成小 Skill。把"登录""切到订单页""导出"拆开，组合起来更灵活，改一处不影响全部。
3. 加失败通知。哪怕是让脚本在失败时停在当前页面截图留证，也能省下大量排查时间。
4. 每月做一次回归。固定跑一遍核心 Skill，网站改版能早点发现。
5. 留好退路。关键业务流程不要只依赖录制脚本，人工流程、官方导出、API 三条路至少保留两条。
最后重复一句提醒：只对自己有权限的账号和数据进行自动化操作，注意遵守目标网站的服务条款与隐私规定，涉及个人信息时尤其谨慎。