不要让实现者自证正确：Spec 编程最容易忽略的测试陷阱

Spec 驱动开发解决了“做什么”的问题，却不自动解决“做得对不对”。

在 Agent 编程中，一个常见流程是：同一个 Agent 阅读 Spec、修改代码、补测试，然后宣布任务完成。看起来闭环完整，实际上存在一个结构性风险：实现、测试和验收都来自同一份理解。

如果它误解了需求，很可能会写出与错误理解完全一致的测试。测试全部通过，只能证明代码和测试彼此自洽，不能证明产品满足真实目标。

这就是我越来越强调独立 QA Agent 的原因。

独立不只是换一个模型名称，而是要切断三类污染：

1. 结论污染。 QA 不应先读实现者的“已经完成”和自我解释，而应先根据原始需求形成自己的验收清单。
2. 上下文污染。 QA 应从用户目标、界面行为、接口契约和运行结果出发，而不是沿着实现者的修改路径检查。
3. 证据污染。 实现者提供的单元测试可以作为证据，但不能是唯一证据。QA 还应检查真实运行、边界条件、失败路径、回归影响和未覆盖范围。

一个更可靠的工作流是：需求 Agent 生成 Spec；实现 Agent 按 Spec 修改；QA Agent 独立生成验收矩阵；测试工具提供运行证据；人类只处理风险、歧义和最终决策。

QA Agent 至少应该输出五样东西：逐条需求的证据、正向与反向用例、跨模块回归范围、未验证项、最终判断及置信度。

这里还有一个很重要的原则：未验证不等于通过。

在真实项目中，很多错误来自一句模糊的“看起来没问题”。无法访问真实环境、没有跑浏览器、没有调用真实接口、没有覆盖异常分支，都应该明确标成未验证，而不是被一条绿色总结吞掉。

AI 可以生成更多测试，但数量不是质量。真正的质量来自验收视角的独立、证据链的完整，以及失败时能否快速定位是哪一条假设出了问题。

不要让实现者自证正确，并不是不信任 Agent。恰恰相反，这是让 Agent 能进入真实生产流程的前提。