用 AI 做 code review：全新视角，而不是自我打分

AI review 在全新上下文中效果最好：不应该由写代码的那个 agent 来给自己的代码打分——而且任务本身也需要明确的边界。

核心原则：全新的上下文

Anthropic 的 best practices 在这一点上很明确：全新的上下文能让 review 效果更好，因为 Claude 不会对自己刚写出来的代码抱有偏见。作者往往会倾向于认为自己的实现思路是对的——一个只看得到 diff 和评判标准的 reviewer，能独立地评估结果。因此，Claude Code 里的 /code-review 命令会在一个拥有全新上下文的独立 subagent 里运行。

用到的工具

在本地，/code-review 会在你 push 之前检查当前的 diff 有没有 bug。在 GitHub 上，一个自动 review 可以分析每一个 pull request，并把发现的问题以带严重程度标签的 inline 评论发出来。

AI review 擅长什么，不擅长什么

它在正确性方面很强：逻辑错误、被忽略的边界情况、违反已写明的项目规则。它在需要代码之外背景知识的判断上比较弱：架构决策、各种权衡取舍、某个抽象长期来看是否真的对团队有利。还有一点：一个被要求去找问题的 reviewer，几乎总能找到一些——哪怕代码本身写得很扎实。

收窄任务范围

所以要限定 review 的 prompt：说清楚要检查什么、依据什么标准、什么才算是一个有效发现。文档是这样表述的：“Report gaps, not style preferences”——只报告缺陷，不要报告风格偏好。

示例

带明确边界的 review prompt： “用一个 subagent，对照 PLAN.md 检查 rate limiter 的 diff。检查：每一项需求都实现了吗？边界情况都测试到了吗？有没有改动任务范围之外的内容？只报告缺陷，不要报告风格偏好。”

🛠️ 练习——自己动手试试

让一个全新上下文来 review 一段 diff，然后自己评估这些发现。

在一个项目里做一个小改动（或者用一个已有的 open branch），在 Claude Code 里运行 /code-review。
把发现的问题分成两组：“涉及正确性”和“风格/偏好”。
只修复涉及正确性的发现，记下你有意舍弃的那些发现——并各写一句理由。

✅ 自查清单

☐ 你能把每一个发现都归到这两组里的一组吗？
☐ 你有没有至少有理有据地舍弃过一个发现，而不是每个都去追？
☐ 你能说清楚为什么这次 review 是在一个 subagent 里运行，而不是在你自己的 session 里吗？

小测验

按照 Anthropic 的说法，为什么 code review 应该在全新的上下文里运行——而不是在写代码的那个 session 里？