AI代理测试通过后的核查清单

来自 AI Agent 的绿色 CI 并不是合并信号。它是一种声明："我运行了某些东西，它以零退出。"你的工作是检查这个声明是否覆盖了你关心的 bug、意图和故障模式。

我把"测试通过"视为一个简短验证序列的开始——而不是审查的终点。

1. 检查 diff，而不是摘要

先打开文件列表。在你能回答之前，先忽略 AI Agent 的叙述：

• 哪些文件实际改变了？
• 它们是否符合人类意图的一句话描述？
• 有没有你没有要求的 lockfile、重命名、配置或测试 fixture？

AI Agent 经常在修改不相关的辅助文件时填充测试套件。如果 diff 范围超过了 ticket，信任绿色检查之前先暂停。在错误的表面上通过的测试套件仍然是错误的合并。

2. 审查断言（逆向地）

打开新编写或修改的测试，然后问：如果原始 bug 再次出现，这个测试会失败吗？

以下情况需要警惕：

• 只检查"返回了某些东西"或状态码 200 的断言
• 吸收任何行为变化的快照测试
• 只有正常路径的覆盖，缺少边界或负面情况
• 只在函数被删除时才会失败的测试

如果恢复回归后断言仍然通过，那测试套件就是做秀。在批准之前要求更严格的断言。宁可要一个尖锐的负面案例，也不要五个软弱的正面案例。

3. 练习故障路径

绿色测试经常跳过在生产环境中会造成问题的路径：

• 无效输入、缺少认证、权限被拒绝
• 空集合、超时、部分写入
• 特性开关关闭、第二次调用、幂等性

选择最接近 ticket 的故障模式，然后检查测试是否强制覆盖了这个场景。如果没有，要么添加该测试用例，要么在合并前手动测试。AI Agent 优化的是"看起来覆盖了"。你优化的是"坏了就会 break"。

4. 本地复现命令

不要只信任 AI Agent 粘贴的输出。在你的机器上（或在同一个 CI job 中）用 PR 分支检出后运行相同的命令：

# example — use whatever your repo actually runs
npm test -- path/to/relevant.spec.ts

问自己：

• 与 AI Agent 声称运行的命令相同吗？
• 工作目录/环境假设相同吗？
• 是否有你不接受的 flaky 测试、跳过、或"带警告通过"？

如果无法在本地复现绿色状态，你就不是真正的通过——而是一个故事。在合并前修复这个故事。

顺序很重要：diff → 断言 → 故障路径 → 本地复现。跳过步骤只是在盲目自信。当文件列表或断言薄弱时提前停止——不要在永远无法捕获 bug 的测试套件上花费二十分钟。

这是我用在其他 AI Agent PR 上的同一标准：保持速度，保持你的判断力。绿色是必要的，但不足够。

如果你想要我用的打包检查清单、Cursor 导向规则和 AI Agent PR 审查提示，AI Agent Code Review Kit 在这里：https://chopragunji.gumroad.com/l/nxoboi

在 AI Agent 声称测试通过后，你首先检查什么——文件列表、断言还是本地重新运行？在评论中分享你的顺序。