写在前面
我没有给这个项目写过一行代码。
但它有自己的架构、有声明式的协议、有可回归的证据链，还真的从一个对话式 AI 产品里揪出了几个具体的 bug。从头到尾，我做的是另一件事：理解问题、定义预期、诊断 AI 为什么没做对、在它卡死时给出方案，然后把它跑出来的零散能力一次次重构成可复用的资产。
所以这篇文章其实在讲两件并行的事。一件是怎么把一个没人会做的新问题工程化，另一件是怎么驾驭 AI 替我把它落地。前者是结果，后者是手段。
一、问题：传统软件厂商，不知道怎么验证智能体
先交代背景。
我们在做的产品里有一个对话式 AI 助手（下文叫它"助手"）。它是一个"用对话来执行业务的壳"——你用大白话跟它说一句诉求，它去理解意图、调起对应的 agent 能力帮你把事办了。
问题来了：作为一家传统软件厂商，我们其实不知道怎么验证这样一个智能体。
过去验证一个功能，逻辑是确定的——点这个按钮，出那个结果，对就是对、错就是错。但智能体不是这样。它的回复是流式生成的、有波动的，同一句话今天这么答、明天那么答；有幻觉问题，有工作流问题。拿验传统功能那套办法去套它，会撞上三个很现实的坑：
- 问法太局限。 大家习惯了"标准操作路径"，但智能体的入口是自然语言，用户怎么说都行。只验那几句"标准问法"，等于没验。
- 记录太混乱。 谁在什么环境、问了什么、得到什么、判定对错的依据是什么——全散在各人的脑子和截图里，没法复现，也没法回归。
- 归因太难。 出了问题说不清是哪一环错的，于是同一个问题被不同的人重复报好几次 bug。
还有一层我得诚实说出来：智能体本来是有一套成熟评估办法的——测试集、评测指标、评估标准。但那是做模型的人的通用能力，作为传统软件厂商的我，一开始完全不懂这些。
我大概考虑分两部分完成，先提效再标准：
- 第一部分，先把"场景化检查"这件事工程化——解决问法、记录、归因这三个最痛的坑，让检查变成可重复、可留证、可回归的事。
- 第二部分，再引入标准的测试集和评测指标，去优化检查场景和分析过程。
这篇文章讲的是已经做完的第一部分。而这所有的内容，我都打算靠驾驭 AI 来落地——因为我不写代码。
二、这个工具到底是什么
一句话：它是一个给对话式 AI 助手做"场景化质量检查"的工具。 它用程序驱动浏览器，像真人一样登录系统、打开助手、把一句句诉求发进去，等它回复稳定后抓下结果、自动判分、截图留证，最后出一份报告。
它的骨架是三件套：
1. 一个不懂任何业务的通用执行器。 它只负责"怎么操作浏览器"，并且把这些操作抽象成了一套固定的"动作词汇表"——打开助手、发消息、点击某个元素、新开一轮对话、跳转页面。它不知道"出差""报销"是什么，它只认这几个动作。
2. 一堆声明式的"场景"。 一个场景就是一串用上面那套动作拼出来的步骤，外加每一步的断言（期望回复里有什么、不能有什么）。我想检查什么业务，就用动作把它拼出来。下面是一个真实的出差检查场景，脱敏后长这样：
{
"name": "business-trip",
"description": "出差申请单 · 智能发起主流程与边界检查",
"env": "<环境名>",
"steps": [
{ "id": "setup", "title": "打开助手面板", "action": "open_comi" },
{
"id": "BT-F01", "title": "用大白话找出差申请",
"action": "send", "msg": "帮我发起出差申请",
"expect": { "must_contain": ["出差"] }
},
{
"id": "BT-F01-confirm", "title": "选中候选表单",
"action": "click", "selector": ".selectable-card-wrapper",
"expect": { "must_contain": ["出差"] }
},
{
"id": "BT-W01", "title": "一次性补齐核心信息",
"action": "send",
"msg": "下周一到周三，从北京去上海见客户，项目差旅，不自驾",
"expect": { "must_contain": ["北京", "上海"] }
},
{
"id": "BT-W03", "title": "问还差什么",
"action": "send", "msg": "还差什么没填？",
"expect": { "must_contain": ["填"] }
},
{ "id": "BT-S01", "title": "发起并触发校验",
"action": "send", "msg": "发起" }
]
}你不用懂代码也能读懂它：找单子 → 选单子 → 填字段 → 问缺口 → 发起。 这正是一个真人会走的检查流程，只不过被固化成了一份能反复跑、能回归的声明文件。后面几步省略了，真实场景还接着验了"模糊意图该不该直接发起""传附件这种不支持的诉求它怎么兜底"这类边界。
3. 一套证据化的产物。 每跑一次，都落进一个带日期的独立目录：一份机读的结果文件、一份人读的报告（每一步嵌着截图，同时并排展示"它界面上显示了什么"和"它接口里实际返回了什么"）、以及每一步的截图。而且立了条规矩：历史记录不许回头改来粉饰结果，要修正就改场景文档、重新跑一份新的。它是当证据链来经营的，不是一次性脚本。下面是报告的一个小用例：
三、我怎么驾驭 AI，把它重构成资产
那个干净的三件套，不是一开始就长这样的。AI 给我的第一版永远是"能跑就行"的紧耦合：要检查的内容糊在代码里、环境写死、发起的动作也写死。我每次介入都做同一件事——解耦、抽象、划边界。但更值得讲的不是"我改了什么"，而是我怎么让 AI 改对。
我有一套逐级升级介入力度的节奏，能用轻手段就不上重的：
- 先看懂，再提预期。 我从不让 AI 直接给最终产物，而是先要它讲清"这东西是什么、负责什么"，我理解透了才提预期。预期提得准，它一次就能做对——这是最省力的一级。
- 没做成，先诊断它的思路。 不急着自己上，而是追问：你怎么想的？考虑了哪些维度？为什么没做到？很多时候问到这一层，它自己就改对了。
- 实在不行，才给方案——但仍让它判断。 把方案丢给它，让它看哪里有问题、有没有达到预期，而不是命令它照抄。给方案是兜底，不是首选。
- 做成了，追问"以后能怎么用"。 让单次成果沉淀成可复用的能力，而不是用完即弃。
内核就一句：我把 AI 当成一个要被我理解、诊断、引导的执行者，不是一个许愿机。
这套节奏在项目里重复了四次，每一次都把"一次性脚本"往"可复用资产"推了一步：
- 把场景从代码里拽出来。 最早 AI 把要检查的内容直接糊进代码。我提了硬要求：检查内容必须场景化、由我改写，拆成"人话场景文档"和"机器执行 JSON"两层。这一步定了全项目的调子——业务归我，转译归 AI。
- 把环境从写死变成多对多。 我意识到真实情况是"一个检查要跑多个环境、一个环境要跑多个检查"，就提出把环境抽出来单独配置，场景只引用它的名字。
- 把执行器拆成动作词汇表（最关键的一次）。 执行器最早把"发起某个具体内容"整段写死。我没直接说"改掉"，而是先要它讲清职责——讲清之后我自己就看出来了：登录是所有检查通用的，而打开助手、发消息、点击、跳转这些是可以拆成独立动作、自由组合的。那套"动作词汇表"，就是我用"先看懂再预判"这一级逼出来的。
- 业务变多时，我直接给目录方案。 从检查一个业务扩展到多个时，AI 彻底乱了，引导多轮都拉不回来。我最后直接告诉它目录该怎么拆，它才沉淀好——这是典型的"兜底给方案"。
四、几条设计原则
做这件事的过程里，沉淀下来几条设计原则：
- 以"用户真正看到的"为准，接口数据只当底牌。 断言以页面渲染文本为准——因为我们测的是用户体验，不是接口契约。接口返回的原始数据只用来还原真相、或在渲染文本不可靠时加固判断。这条是被"自动判分会误判、得靠截图人眼复核"反复逼出来的。
- 先探测，再固化，绝不臆造断言。 面对一个流式、有候选歧义、字段藏在折叠卡里的 AI，断言不能凭想象写。所以新接一个表单，我会让 AI 先发一句话探一次、把真实返回拿回来，我看过之后再定策略——点第几个候选、断言卡哪个关键词，然后才让它写成完整场景。探测和转写都是 AI 干的，但"必须先探、探完我审了才固化"这条规矩是我定的。拍脑袋直接写，只会得到一份骗自己的"全绿报告"。
- 机器判分是起点，人复核归因才是终点。 脚本报的失败要逐一人工复核——有的"失败"其实是 AI 给了合理回复。同时历史记录不许回头改来粉饰结果，要修正就改场景、重跑一份。证据得诚实。
五、它现在真带来了什么
我不打算把它说得比实际更厉害。
真实状态：目前只有我在用，离"通用给别人用"还有一段距离。 但对我个人来说，它是实打实地省事了——过去靠人一遍遍点、一遍遍看的检查，现在能可重复地跑、留下证据、回归验证。我靠它定位到了一些真实问题，也据此报过 bug。全程我没有写过一行代码。
举一个最能说明问题的例子。检查报销单的明细表时，形式上的断言全部通过——看报告像是一切正常。但接口捕获到的数据揭穿了真相：第一次一次性报的两笔金额，根本没落进对应的字段，那个字段还停在 0.00；反而是后面追加的那一笔正常落进去了。这是个非常具体、非常真实的 bug，而它恰好印证了前面那个判断——如果只看表面渲染、不留接口这张底牌，这个 bug 就被一份全绿报告盖过去了。
类似的还有路由判断上的真问题：用户说"还差什么"被跑偏成了去查协同、说"算了不发了"被误判成已经跳转详情。这些都不是我臆想的，是检查跑出来、再经我复核归因确认的。
六、下一步：从"场景化检查"走向"标准评测"
回到开头那两步走。第一步（场景化检查的工程化）已经站住了，第二步才刚起头：
- 往场景前面，加一层总览。 这层我已经做了初步的版本，但它还不是标准意义上的"测试集"——这正是我要补的方向：把零散的场景，整理成有覆盖意识、成体系的测试集。
- 把检查产出的数据，喂给大模型做分析。 现在每次跑都留下了结构化的结果，这些本身就是很好的数据源。下一步是引入标准的评测指标，让模型基于这些数据做评估分析，而不只是停在"这条断言过没过"。
- 报告里接口数据的获取还有没处理干净的地方，这块要补完，让接口这张底牌更可靠。
我把这些如实列出来，是因为这件事对我来说是个有路线的事，不是做完就停的一次性脚本。
结尾
这个项目证明的，其实不是"我会用某个浏览器自动化工具"——那个谁都能学。
它想说明的是两件可迁移的事：一是我能把一个没人会做、连我自己一开始都不懂的新问题，一步步工程化成可复用的东西；二是我能驾驭 AI 替我把它落地——靠的是理解、定预期、诊断、引导、必要时兜底这一整套节奏，而不是把活一股脑丢给它。
一个不写代码的人做出了这个工具，靠的不是写代码的能力，是想清楚问题、并且让 AI 把它做出来的能力。我觉得，这才是这个作品真正想展示的东西。