AI 写代码时，你睡得着吗？
凌晨三点，你的 AI Agent 还在跑。早上醒来，Git 里多了 5 个 PR，2000 行代码。
你敢合并吗？
这不是科幻。现在已经有团队每周合并 40-50 个 AI 生成的 PR，是以前的 4 倍。问题是：谁在看这些代码？
代码审查已经崩了
传统方案是"多招人审代码"。但你招不过来。而且让资深工程师整天读 AI 生成的代码，这是对人才的浪费。
有人说"让 AI 写测试"。听起来不错，但这是个陷阱：AI 写的测试只能证明代码做了 AI 以为你想要的事，而不是你真正想要的事。
这就像让学生自己批改自己的作业。测试会通过，但可能从一开始就理解错了需求。
TDD 的复仇
还记得 TDD（测试驱动开发）吗？先写测试，再写代码。
大部分团队不这么做，因为"太慢了"。但现在 AI 能秒写代码，速度不再是瓶颈。瓶颈变成了：你怎么知道代码是对的？
TDD 的核心不是测试，是在写代码之前，先想清楚"对"是什么样子。
现在你可以用更简单的方式：用人话写下功能应该怎么表现，让机器去验证。
比如登录功能：
- 用户输入正确的邮箱和密码，跳转到 /dashboard
- 密码错误时，显示"邮箱或密码错误"
- 5 次失败后，锁定 60 秒这些你在打开编辑器之前就能写出来。然后让 AI 写代码，另一个系统去检查这些标准是否满足。
实际怎么做？
有人做了个工具叫 verify，配合 Claude Code 用。流程是这样的：
- 写验收标准（Acceptance Criteria）- 用人话描述功能应该怎么表现
- AI 写代码 - 按照标准实现功能
- 自动验证 - 用 Playwright 跑浏览器测试，每个标准都截图验证
- 只看失败的 - 通过的不用管，只审查失败的部分
前端用浏览器自动化，后端用 API 测试。每个验收标准要么通过，要么失败，一目了然。
关键是：你审查的是失败项，而不是 2000 行 diff。
这不是银弹
说实话，这套方法有个明显的坑：如果你的需求本身就错了，验证也会通过。
它能抓到的是：集成问题、渲染 bug、浏览器兼容性问题。这些是代码审查经常漏掉的。
但它抓不到的是：你一开始就理解错了需求。这个还是得靠人。
为什么大家不这么做？
因为写验收标准比写 prompt 累。
它逼着你在写代码之前，把边界情况都想清楚。工程师抗拒它，就像当年抗拒 TDD 一样——感觉"慢"。
但如果你不写，你就只能盯着 AI 输出的代码，祈祷它是对的。
凌晨三点，AI 还在跑。你睡得着吗？
相关链接：