AI重构通过测试，仍可能破坏接口契约

一个 Agent 做了一次大规模重构：重命名了 10 个文件，合并了两层结构，所有检查都通过了。我差点就凭这份信心合并了代码。

但我没有。仔细读了一遍 diff，我就明白为什么不能合并。

测试套件跟着代码一起变了

原来的测试明确约束了返回值的结构。新代码返回的结构略有不同。Agent 没有识别出这其实破坏了既有契约，而是修改了测试，让测试接受新的结构。所有测试都通过了，但测试套件已经不再守护它最初要守护的行为。

这就是陷阱。当代码和测试都由同一个作者编写时，CI 全绿只是在检查自洽性。它证明代码的行为符合测试的预期，而测试的预期又符合代码的行为。

错误假设会成对传播

这种失败并不是随机发生的，而是源于双方共享的错误。如果模型对业务领域有一个错误的认知，它就会把这个假设同时写进实现，以及覆盖该实现的测试。两边完全一致，CI 全绿，生产环境却依然会出问题，因为它们只是彼此自洽，并没有与真实系统保持一致。

过去，人工审查原有测试时往往能发现这类问题，因为审查者记得当初为什么要写这个测试。Agent 没有这段记忆，会毫不犹豫地删掉这道防线。

每次 AI 编写的重构完成后，我都会像审查代码 diff 一样，仔细审查测试 diff。如果某个测试被改成了匹配新输出，我会问：原来的行为确实有错，还是我们只是停止对它做断言了？这两种答案有着本质区别。

对于 API 类型的代码，很容易把这类校验独立出来。测试不应该只存在于编写代码的同一个会话里：对照真实 endpoint 检查的契约，或者预先记录的标准响应，都不会因为 Agent 决定整理代码而跟着改变。我们把这类检查保留在本地，而不是完全信任生成的测试套件。

全绿只是底线，不是上限。AI 重构之后，要问的不是“测试通过了吗？”，而是“测试在重构后保留下来了吗，还是也跟着代码一起被改写了？”

你上一次发现某个测试被悄悄改成了匹配代码，是什么时候？

如果需要采取进一步行动，你可以考虑屏蔽此人，或举报滥用行为。