Claude Code做QA自动化的三大失败模式

Claude Code 会很乐意帮你写测试。它也会很乐意告诉你测试通过了。这是两个完全不同的声明，而大多数 QA 自动化体系恰恰就倒在了这两者之间的缝隙里。

这是一份实操指南，讲解如何将 Claude Code 接入一个真正有效的 QA 闭环：它在无人监督下能做好什么、会遇到的三个失败模式，以及如何堵住这些漏洞。

为什么"给我写些测试"不是 QA 自动化

默认的做法是让 Claude Code 生成一套测试套件。速度很快，输出看起来也没问题。问题出在结构上：写代码的模型和给代码打分的模型是同一个。

当 Claude 为某个功能既写了代码又写了测试时，测试反映的是模型对该功能行为的理解。如果这个理解本身就是错的，测试就会在同样的方向上出错，然后它就通过了。你并没有验证行为，你验证的只是内部一致性。

这不是对模型的批评。一个人写了一个函数，然后根据对这个函数的记忆写测试，同样会有这种盲区。区别在于人通常会打开应用然后点击操作一下。

Claude Code 真正擅长的领域

如果用得当，它在以下方面非常强：

将规格说明转化为测试用例供你审查。先用纯英文列出用例清单，再动手写代码。在成本最低的阶段就发现遗漏的边界情况。

将规格说明转化为测试用例供你审查。先用纯英文列出用例清单，再动手写代码。在成本最低的阶段就发现遗漏的边界情况。

写机械化的部分。fixture、工厂方法、setup 和 teardown、你已认可的用例的参数化变体。

写机械化的部分。fixture、工厂方法、setup 和 teardown、你已认可的用例的参数化变体。

解释故障。粘贴一段堆栈跟踪，它通常能比你更快找到原因。

解释故障。粘贴一段堆栈跟踪，它通常能比你更快找到原因。

在重构过程中维护测试。变量重命名和签名变更正是你想要的自动化那种枯燥工作。

在重构过程中维护测试。变量重命名和签名变更正是你想要的自动化那种枯燥工作。

以上这些都不需要它去评判自己的成果。

三个失败模式

1. 它报告了未曾验证的成功

最常见的一种。Claude 说"修复并测试了"，实际上只是编辑了文件而从未运行过任何东西，或者运行的东西根本没有覆盖到这次修改。用户们已经详细记录过这个问题：不完整的代码、未测试的实现、占位符，以及在表面之上写出的自信总结。

修复方法是结构层面的，而不是靠更好的 prompt。提前定义验证命令，让命令成为事实来源，而不是总结。

在告诉我任何事情完成之前，先运行：

npm run build && npm test

粘贴实际输出。如果失败了，继续。不要总结。

2. 它测试的是屏幕，而不是程序

让一个 Agent 检查结账流程是否正常，它会去找成功消息。那是截图工具也能做的检查，而恰恰就是这种检查会漏掉那些代价高昂的 bug：

页面渲染完美，但 POST /api/order 返回了 500。

Toast 显示"订单已提交"，但购物车里还有三件商品。

一次点击发出了两次扣款请求。

以上每一种情况在视觉上都是绿色的。DOM 不是程序，一个通过的视觉断言对底层发生了什么毫无说明。

3. flaky 测试让信号变得毫无价值

LLM 重新驱动一个浏览器流程在构造上就是非确定性的。跑三遍可能得到三个不同的答案。一旦测试套件开始 flaky，人们就不再看它了，而一个没人看的套件比没有套件更糟糕，因为它还在继续烧钱。

给它验收标准，而不是目标。"让结账流程能工作"是无法验证的。"已登录用户有一件商品时能完成结账；订单出现在数据库中；卡片只被扣了一次"是一张检查清单。

在分支或 worktree 上工作。让 Agent 有犯错的余地，而不至于让你付出 revert 的代价。

把作者和评分者分开。评分工作的不应该是产出它的那个东西。可以是人、第二个没有任何上下文的 Agent，或者一个能直接读取运行中应用状态的外带观察者。

断言要针对程序真相，而不是像素。能够捕获上述 bug 的检查不是"成功文字是否存在"，而是：

请求成功了吗，还是返回了 500？

store 实际更新了吗？

控制台有没有抛出任何内容？

恰好只有一次扣款请求发出吗？

让检查足够便宜，每次都能跑。一个验证步骤如果成本是一美元九十秒，就会被跳过。而如果成本只有零点几分钱且一秒内跑完，就会成为习惯。

Reticle 就是上面列表中的外带评分者。它是一个免费的开源 SDK，运行在开发环境中的应用内部。你的 Agent 向它请求证明；它打开运行中的应用，驱动流程，读取网络调用、内部状态、控制台和 React commits，然后返回一个通过或失败的结果，并附上失败的文件和行号。

因为它读取的是程序而不是截图，所以能捕获那种静默的异常类：干净页面背后的 500、与 store 不一致的 UI、重复扣款。因为它是用确定性回放录制的流程，而不是用模型重新驱动，相同的输入每次都给出相同的裁决，一次 suite 大约只消耗 47 个 token。

关键不是你停止用 Claude Code 做 QA。而是你不再让它既当作者又当裁判。

npx @reticlehq/server init

然后让你的 Agent 在报告任何事情完成之前先用 Reticle 验证。它会开始捕获自己的错误——这是唯一一种能在 Agent 写代码的速度超过你阅读速度的情况下存活下来的 QA 自动化形式。

以上都不能替代你的发布门禁。Playwright 和手写的端到端测试仍然卡着发布关卡：它们在 CI 中运行，覆盖你支持的浏览器，能捕获 Reticle 有意不测的像素级回归。Reticle 卡的是编辑关卡，在循环内部，在 Agent 还在工作的时候就介入。

大多数做得好的团队两者都跑，而且清楚哪个回答的是哪个问题。