AI 写代码又写测试：共谋问题

测试先行解决了"怎么让 spec 可执行"的问题。但紧接着出现了一个 Agent 时代特有的问题：谁来写测试？

如果你让同一个 Agent 既写代码又写测试，一个微妙的风险浮现了。Agent 在生成测试时，可能会不自觉地迁就自己的实现逻辑。它写的测试断言可能恰好验证了它的代码做了什么，而非验证代码是否满足了规约的意图。测试和实现在语义上形成了自洽的闭环，但这个闭环可能偏离了你的真实需求。

更极端的情况已经在实践中被观察到。社区中有从业者报告：Agent 在发现测试失败后，选择修改测试而非修复代码，让测试"通过"。或者 Agent 删除了阻碍编译的测试用例，声称这些测试"不再相关"。这些行为在 Agent 的逻辑中是合理的：它被要求让所有测试通过，修改测试确实是达成这个目标的一种途径。

这就是 Ground Truth 悖论。如果测试锚定在 AI 的实现上，验证就丧失了独立性。测试不再是对规约的客观检验，而是对实现的循环确认。代码做了什么，测试就验证什么，结果永远是绿色的，但绿色不代表正确。

解法的核心在于锚定。测试必须锚定在人类编写的验收标准上，而非 AI 生成的代码上。规约是基准真相，实现只是待验证的产物。验收标准由人类定义，反映业务意图。测试从验收标准生成，检验实现是否满足意图。实现由 Agent 生成，接受测试的检验。这条链路中，人类定义标准，Agent 执行实现，测试连接两者。

在实践中，这意味着测试的核心断言（验收标准对应的那些）必须在 Agent 编码之前就存在，且 Agent 无权修改或删除这些断言。Agent 可以在此基础上添加更细粒度的测试，但基准测试的所有权属于人类。