为什么拿"智能发起"当例子

它是这个检查工具接的第一个特性，也是迄今最完整的一个。工具里那些"通用能力"——多候选选择、接口断言——没有一个是我提前设计的，全是被智能发起的真实检查需求一步步逼出来的。所以拿它还原，最能看清"摸透特性"和"固化检查"这两部分到底各自发生了什么。

先一句话说清这个特性：智能发起是产品里那个对话式 AI 助手的核心能力之一——用户用大白话说一句诉求（"我要出差""帮我报销"），助手识别意图、推荐表单、对话着帮你把字段填上、最后发起流程。我要做的，是验证它到底听不听得懂、填不填得对、该拦的拦不拦得住。

第一部分：摸透智能发起

1. 让 AI 先读懂框架规矩

第一句话不是"帮我检查智能发起"，而是先让 AI 把工具的规矩吃透。

请先阅读这个检查工程的全部规则文档，不要写任何代码。读完后用你自己的话讲清楚：
通用执行器负责什么、现有动作词汇表有哪些、一个 feature 的目录怎么放、有哪些必须守的纪律。
讲清楚再停下来等我确认。

它复述对了，我才往下走。这一步当时帮我省了很多事——后面它写任何东西，都知道"业务名词不能进执行器""目录要按 features/「特性」/ 放"。

2. 喂智能发起 3.0 的 PRD，让 AI 出场景总览

我把"智能发起 3.0"的 PRD 丢给它，让它先理解这个功能干什么，再基于设计意图给一份场景总览。

它和我对齐后，总览收敛成四条线：

这一步我做的判断： AI 一开始只列了"出差、报销"两条主流程线。是我按真实用户视角补的——考勤那张表"一单三用"是个隐藏坑，必须单独验；而"下一步动作识别"（用户中途冒一句无关的话，助手会不会跑偏）这条线，AI 完全没想到，恰恰后来在这条线上抓出了最多的真问题。

3. 让 AI 写临时探测脚本，自己去摸真实页面

总览是纸上的。接下来最关键——让 AI 写一次性的探测脚本，自己登录、自己点、把页面真实的样子摸回来。这一步它分了好几轮探（对应 stage1～stage6 六个临时脚本），每一轮摸一层：

人机分工在这一步现形得最清楚： 基本全是 AI 自己探、自己写脚本、自己跑。但它卡在过两个地方——一个是死活找不到登录框（因为埋在 iframe 里），一个是发完消息抓不到回复内容（因为是 SSE 流）。这两次我都是打开页面、把"它在 iframe 里""这是流式响应得 hook fetch"这一眼指给它，它接着就把活干完了。我出的是它看不见的那一眼，不是替它写代码。

这一轮探完，几个决定整个工具形态的事实就钉死了：登录走浏览器、操作打到助手 iframe、回复优先读渲染文本（DOM），接口数据用 hook fetch 兜底。

4. 现有动作不够用，让 AI 加新动作

探到报销那条线时，撞上了第一个"现有动作表达不了"的情况。

发"我要报销这两天的打车和住宿费用"，助手返回了 4 个候选表单，而我要验的"费用报销单"排在第 3 个。现有的 click 只能点第一个匹配元素——点下去会选错表单，整条检查就跑歪了。

这时候才让 AI 给执行器加一个新动作：

探测发现报销诉求会返回多个候选，目标不在第一个。现有 click 只能点第一个，表达不了。
请加一个新动作"点击第 N 个匹配元素"。要求：必须通用（描述的是一类浏览器操作）、
不准出现任何报销/表单的业务名词、命名和参数风格跟现有动作一致、加完更新动作词汇表文档。

于是有了 click_nth（带一个 index 参数）。注意它的命名——叫"点击第 N 个"，不叫"选费用报销单"。这条纪律很重要：新动作是给所有特性用的通用能力，绝不为某一个业务写死。 后来别的特性遇到多候选，直接复用它。

这就是这个工具"双向生长"的真相：场景复用执行器的能力，而执行器又从一个个真实场景里，把反复出现的操作沉淀成新的通用动作。click_nth 不是设计出来的，是报销这条线逼出来的。

5. 需要更细的数据时，再做一次单点探测

报销和出差这两条线，光知道入口还不够——明细表到底有哪些字段、字段真实叫什么，不摸清根本没法写断言。所以针对它们又做了一轮更聚焦的探测，把表单字段抓回来。

比如报销明细表，探测把每个字段的真实 key 都抓出来了：费用日期、票据性质、票据数量、列支部门、报销金额……这些后来直接成了写断言的依据。

也是在这一步，发现了一个关键的坑：明细表的金额在页面上是折叠的，DOM 里只能看到摘要、看不到每行的真实数值。 这个发现直接决定了后面一条设计原则——这种藏起来的真实值，只能靠接口捕获的数据来还原。不是每个场景都要这步：对话式的简单命中，Step 3 探一次就够了；要验字段回填的复杂表单，才需要这层补充探测。

6. 把探测结论沉淀成智能发起的 skill/index

第一部分的交付物在这——不只是写文档，而是给这个特性建起完整的目录结构，再写一份"检查说明书"。

把前面所有探测结论沉淀下来：
1. 创建 features/smart-initiate/ 下的 docs/、scenarios/、records/ 目录
2. 在 docs/index.md 写清楚这个特性的检查说明书——功能干什么、入口在哪、
   检查要用哪些动作（含新加的 click_nth）、探测发现的坑、和我对齐过的场景总览
3. 遵循框架的目录约定和文档规范

最后落出来的 index.md 里有几样东西，是这个特性以后所有检查的地基：覆盖边界（只管"通过助手发起固定表单"，自由协同、辅助审批明确划走、要另建特性）、新增场景的标准流程、什么时候该先探测、什么时候该扩执行器、怎么判断失败归因。

跑通的标志： 执行器认识智能发起了（click_nth 这些动作都有了），而且有一份说明书，让 AI 以后能照着它给这个特性写任何新场景。第一部分到此结束。

第二部分：固化检查

有了说明书，剩下就是套路活。下面以"费用报销"这条线为主线还原。

7. 让 AI 写场景文档（人话版）

让 AI 拿着 index.md，把报销这条线展开成人话场景文档：检查明细表的增删改查。链路定下来是——

找单 → 选中第 3 个候选（费用报销单）→ 一次性报两笔（打车 80、酒店 620）→ 追加第三笔（45）→ 改金额（620 改成 600）→ 删一笔（45 那笔）→ 问缺口 → 补收款账户 → 传票据（边界）→ 发起。

我审的就是这条链路像不像真人报销：一次报多笔、中途追加、改错了金额、又删掉一笔——这才是真实报销会发生的事，而不是规规矩矩一笔填到底。

8. 让 AI 把场景文档转成可执行 JSON

转 JSON 时，我重点审两件事，正好各踩一个真实的点：

候选选择有没有用对。 因为探测时已经知道"费用报销单"排第 3 个，这一步就必须是 click_nth 配 index: 2，而不是默认 click 点第一个。审 JSON 时我专门盯了这里——用错了，整条检查从第二步就歪了。

断言关键词稳不稳。 报销金额这种就卡数字关键词（"80""620""45""600"），不卡整句话。AI 的回复每次措辞都不同，但金额数字是稳定的。

9. 执行，看报告

一行命令跑完，形式断言 11/11 全过。报告看着一切正常。

但这恰恰是最危险的时候——形式全绿，不代表真没问题。

10. 人工复核归因，沉淀结论

这一步才是检查真正的价值所在。我对着接口捕获的数据逐条复核，揪出了几个形式断言盖不住的真问题：

报销金额没落表（最典型的一个 bug）。 一次性报的两笔金额（打车 80、酒店 620），对话文本里都出现了，所以形式断言"包含 80、包含 620"全过。但接口数据揭穿了真相：这两笔金额根本没写进明细表字段，那一栏还停在 0.00；反而是后面单独追加的第三笔（45）正常落进去了。只看页面渲染，这个 bug 就被一份全绿报告盖过去了。 这也直接印证了那条原则——接口数据这张底牌必须留。

缺口提示不精准。 问"现在明细还差什么"，助手只提示要去详情页传附件，完全没提那笔金额还是 0.00。

路由那条线（下一步动作识别）抓出的真问题更多，30 个用例过了 25 个，5 个失败全是真问题：

• "还差什么"——被跑偏成了反问"你要查待办/已办/已发/待发？"，去查协同了
• "帮我查一下今天的待办"——直接跳出发起链路真去查待办了，没留在当前表单
• "算了不发了"——明确放弃，却被误判成"已跳转详情、本轮对话已终止"

也是这条线逼出了接口断言：因为路由判断时，页面文本会混进历史对话导致误判，光看 DOM 判不准，所以给执行器加了 api_must_contain 这套接口断言，专门拿接口数据来判路由。又一个"被真实检查逼出来的通用能力"。

最后，把多份报告汇总：

读取 features/smart-initiate/records/ 下本轮所有执行记录，按应用检查报告模板汇总：
基本信息（用例总数：通过 X / 不通过 Y）、检查清单明细表、问题明细表。
脚本判定的失败要逐条复核，把 AI 给了合理回复的误判剔除后再认定真问题数，备注里写清楚剔除了几例。

AI 出的汇总初稿里，一共 57 个用例。但脚本报的失败里，有一例其实是助手对"好的，谢谢"给了合理的礼貌总结——这是误判，我把它剔除了，最后认定 53 通过 / 4 个真问题。汇总出来后我又手动调了措辞和归类，一份能直接拿去报 bug 的检查报告就成了。

机器判分是起点，这一步的人工复核才是终点。

回头看：智能发起到底"还原"出了什么

把这一遍走下来，最该被看见的是：这个工具不是设计出来的，是被智能发起这一个特性一步步逼出来的。

• 多候选 → 逼出了 click_nth
• 明细金额 DOM 折叠看不到 → 逼出了"接口当底牌"
• 路由判断 DOM 会混历史对话 → 逼出了接口断言

而我在整个过程里没写一行代码。我做的是：定场景总览、卡住时帮 AI 指一眼它看不见的元素、审说明书和 JSON、判断断言稳不稳、逐条复核每个失败到底是不是真问题。AI 把活干了，我把着方向和判断。 这就是"驾驭 AI"四个字在一个真实项目里的样子。