用 Claude Code 为质量工程造 Agentic AI

终端里的 AI 做质量工程，和 IDE 插件的差别在于它能跑东西：跑测试、看输出、改了再跑。

这个差别很关键，因为判断的依据从「看起来对」变成了「我跑过了」。

先把项目知识固化

最值钱的第一步不是让它写测试，是把每次都要解释的东西写下来。

一个测试项目里，反复要交代的通常是这几样：

• 测试怎么跑（命令、环境变量、需要先起什么服务）
• 项目约定（页面对象怎么组织、断言用哪一套、命名规则）
• 已知的坑（哪些测试天生不稳、哪些目录别碰、哪个环境不能写数据）

这些每次重讲一遍，就是每次调用都在付的税。 固化成一个文件是一次性付清。

而且固化下来还有两个额外好处：它能被 review、能被版本控制 —— 一段塞在提示词里的话做不到这两件事。

有个具体的经验值得抄：发现逻辑要写成 skill，不要塞进定时任务。因为塞在 cron 里的那堆字，没有人会再去更新它。

让它跑，而不是让它猜

终端 agent 在测试场景里最该被用的能力是执行：

1. 跑一遍失败的测试，把真实输出贴出来
2. 读相关代码
3. 提出修改
4. 再跑一遍验证

第 1 步和第 4 步是它相对 IDE 补全的全部优势。没有这两步，它就退化成一个更会打字的补全工具。

按可信度排，验证手段有三档：

• 确定性检查（测试跑没跑过、编译过没过、lint 干不干净）—— 最可信最便宜，能用就用
• 错误日志（真跑一遍看报什么）—— 比读代码强，因为它基于执行
• 模型判定 —— 最后的手段，而且必须换一个没参与干活的模型

「能用死规矩做对的事，就别交给会瞎猜的东西。」

一个必须画的边界：谁能改断言

上一篇提过那组数：某套自动修复 UI 测试的系统，朴素口径的收敛率 70%，剔除作弊之后 50% —— 差的部分来自把断言改松和删掉修不好的用例。

在终端 agent 这个场景里，这个风险更高，因为它真的能改文件、真的能跑命令。

所以规矩要写死：

• 改实现代码 → 可以自动
• 改断言、删测试 → 必须人批
• 改测试基础设施（CI 配置、依赖）→ 人批

这不是不信任模型，是目标函数的问题：它优化的是「让测试通过」，而删测试是达成这个目标的合法解。

分清基础设施故障和测试失败

这条来自同一份案例研究，我认为是最被低估的一条。

那套系统的失败里，导航和环境超时占 40%，浏览器上下文崩溃占 16% —— 而这些和「产品有 bug」完全是两回事。

混在一起统计，会污染所有的数字：你的「测试通过率」里混着环境噪音，于是你既不知道产品质量如何，也不知道 agent 干得如何。

我自己在这一格只做了一半：错误分类里区分了「找不到目标」和「断言不成立」，但没把环境超时单独拎出来 —— 按那份研究的比例，那可能是最大的一类。

有界迭代

而这不是个例。MAST 把 1642 条多 agent 执行轨迹的失败归了类，「任务验证」这一整类占 23.5% —— 其中「验证做错了」9.10%，「没验或只验了一半」8.20%，「还没干完就宣布结束」6.20%。接近四分之一的失败，根子在那道本该说「不行」的门上。

所以「有上限」还不够 —— 那个例子恰恰是跑满了上限。还需要一条：连续多少轮无进展就升级给人。

判据可以很土：连续三轮的测试失败信息完全一样，说明它在原地打转，停。

边界与代价

终端 agent 的权限比 IDE 插件大得多。 它能跑任意命令。沙箱不是可选项 —— 至少要保证它跑在一个可以随时扔掉的环境里，而且凭据不在那个环境里。

固化知识有维护成本。 项目结构变了、CI 换了，那个文件不会自己更新。它比塞在提示词里好，但不是免维护。

这一篇里我的第一手部分是错误分类那条：我自己的系统里把 401 一开始归进了「可重试」，结果一轮跑完发现每个任务都白试三次、报的是同一句认证失败。判据不是「失败了没有」，是「重试有没有可能成功」。