我现在日常开发几乎所有代码都是 Claude Code 或者 Codex 生成的。偶尔回头看看 git log，已经分不清哪些是自己写的哪些是 AI 写的了。
问题也跟着来了。代码量上去了，人的审查跟不上。以前一个 PR 三五百行，认真看半小时能看完。现在动不动几千行改动，而且 AI 生成的代码往往结构正确、命名规范、注释齐全，看起来挑不出毛病，但跑起来就是有各种问题。
那能不能让 AI 来做代码审查？AI 写的代码再让 AI 审一遍，听起来很合理。但 AI 审 AI 的代码，怎么保证不是互相糊弄呢？今天就来分享一下我自己摸索出来的一套方法。
质量门控是底线
不管有没有 AI，基本的质量门控都得有。Lint、类型检查、单元测试、集成测试、端到端测试，这些是所有代码合并的前提。AI 时代这些东西反而更重要了，因为 AI 写代码特别擅长绕过人的直觉，但很难绕过一个覆盖全面的测试套件。
所以，如果你的项目连这些基本的门控都没搭好的话，那就不要让 AI 上来就开始做功能开发，AI 编程的第一步应该是补上这个短板，打好质量门控这个基础。
有这些基础之后，再来看如何用 AI 审 AI 的代码。
把 PR 拉到本地，给 AI 完整上下文
我现在的做法是让 Agent 把 PR 代码拉取到一个独立的工作树里，避免影响我正在进行的其他工作。然后拿整个代码库作为上下文来做整体审查。
之所以这么做，是因为我之前踩过不少坑。最典型的是 GitHub Copilot 的审查功能，特别容易产生大量评论，一个 PR 能标出十几个“严重问题”。看起来每条都头头是道，分析得很有道理。但你要是真跟着它改了，就有可能把原来好好的代码改坏。
为什么？因为 AI 在“想办法说服你它是对的”这件事上，比大部分人都厉害。它能给你编出一套完美的推理链，解释为什么这行代码有问题，为什么应该按它说的改。但这个推理链可能建立在一个错误的假设上，而你纯靠看代码很难发现这个假设是错的。
所以光“看”是不够的。
验证比审查重要得多
纯靠看代码做审查，不管是人看还是 AI 看，都有一个根本性的局限：你只能发现你能想到的问题。
解决方案是给 Agent 一个真实的运行环境，让它把修改后的代码构建起来、实际跑起来，做一些真实场景的验证。不是在脑子里模拟“这段代码会不会出问题”，而是实际跑一遍看看结果。
这个思路和 Claude Code 团队的 Boris Cherny 最近说的完全一致。他提到现在 LLM 产生的问题跟以前不一样了，不太会犯人容易犯的低级问题，更多是系统设计、UI 可用性、缺少更广泛的上下文这类问题。这种问题纯靠看代码几乎不可能发现，但跑一遍就很容易发现。
他给了一个很简单的例子：只需要一行提示词，让 Agent 用动态工作流在模拟器里对每个边界情况做对抗式测试，或者直接用 Claude Code 内置的 /code-review。对抗式的审查比单纯“帮我看看有没有问题”要有效得多。
跑真实环境的两个副作用
不过，给 AI 真实环境做验证也带来了新问题。
第一个是安全。Claude Code 有内置的 /security-review，Codex 也有类似的安全扫描能力，直接用就行。安全问题往往藏在代码的交互边界上，比如输入校验、权限检查、敏感数据处理这些地方。人看代码的时候注意力容易放在业务逻辑上，反而是这种模式匹配的活儿 AI 更擅长。
第二个坑我踩了好多次：AI 在验证过程中会跟你本地的各种服务交互，然后它写审查评论或者 PR 描述的时候，特别喜欢“展示证据”，顺便把你本地的环境信息也带出去了。我经常碰到的就是 PR 里出现我本地 Kubernetes 集群的名字、命名空间、用户名之类的信息。比如 AI 会写“在 xxx-cluster 的 dev 命名空间跑了验证，发现 xxx 问题”。这种私有信息一定要避免推到公开仓库。
最好的办法是在审查流程的最后加一个单独的清理步骤，专门扫描 PR 内容里有没有内部环境信息、凭据、IP 地址这些不该出现的东西。
那还需要人干嘛？
AI 编程之后再让 AI 来审核，是不是就不需要人了？是不是就应该把所有程序员都开掉？
完全不是的。随着大模型变的越来越强大，部分编程问题的确是已经解决了，但编程并非全部。
需求梳理、系统设计、用户体验、安全策略、技术路径选择等等，还有很多方面需要人来把关。AI 能写出正确的代码，但不一定能写出合适的代码。“正确”和“合适”之间的差距，就是人的判断力存在的空间。
其实现在已经能看到大量 AI 生成的小项目和工具，看起来功能齐全、代码规范，但真正用起来根本解决不了实际问题。代码能跑不等于产品能用，很多只是在浪费算力。没有人去判断“该不该做”和“做成什么样”，AI 再能写代码也只是在批量生产垃圾。
不过说实话，“人应该把关哪些东西”这件事我自己也还没完全想清楚。发现需求和设计产品显然需要人，但 UI 可用性呢？特定场景的边界情况呢？这些东西现在靠人，未来是不是也能靠更好的约束来覆盖？我不确定。目前的做法就是先把能自动化的自动化掉，剩下的再说。
怎么开始？
Claude Code 的 /code-review 和 Codex 的审查命令是不错的起点。
我建议你在本地开发的时候尽量把它们用起来，每次改完代码提 PR 前先让它们审一遍。不需要什么复杂配置，直接用就行。Claude Code 还支持不同级别的审查深度，/code-review low、/code-review medium 之类的，可以根据改动的风险程度选择。
对于自动化的 AI 代码审查流程，我的建议是参考这些工具的实现，在它们的基础上加上前面提到的几个核心点：
- 完整的代码库上下文，别只看变更 diff
- 真实环境验证，代码要能构建跑起来
- 安全扫描
- 本地信息清理
- 对抗式审查测试，主动找茬而不是被动检查
不同项目的环境准备和验证步骤都不一样，不要试图造一个大而全的通用方案。为每个项目构建独立的审查配置，把项目特有的约束写进去，让 AI 生成的代码必须通过这些约束才能合入，通不过就打回去让它自己修。
这个做法跟我之前在《烧了 20 亿 token 总结的 Codex 使用指南》里说的一样，验证比生成重要，审查配置比审查本身重要。
欢迎长按下面的二维码关注 Feisky 公众号，了解更多云原生和 AI 知识。
