我对代码审查 Agent 的态度有点矛盾。一方面，它确实适合做很多人不愿意认真做的事：检查边界条件、扫一遍 diff、找明显的空指针、提醒测试没覆盖。另一方面，如果团队把它当成“自动 reviewer”，很快就会遇到一个更麻烦的问题：它可以发现问题，但不应该替你决定取舍。
Anthropic 在 Claude Code 相关更新里提到过专门的 review session 和 /ultrareview 这类能力。我的关注点不是它名字有多强，而是这说明 AI 编程工具正在从“帮我写代码”进入“帮我审代码”。这一步对小团队很有价值，也更容易被滥用。
代码审查最缺的不是眼睛，而是判断边界
很多小团队的 code review 其实很脆弱。忙的时候只看能不能跑，熟人的 PR 默认通过，不熟的 PR 才仔细看。AI reviewer 的价值在这里很直接：它不会累，也不会因为你昨天已经改了三轮就不好意思继续挑问题。
但代码审查不只是找 bug。它还包括：
- 这个抽象是不是过早；
- 这个兼容逻辑值不值得背；
- 这个性能风险能不能接受；
- 这次是否应该顺手重构；
- 上线窗口是否允许改这么多文件。
这些问题里有很多不是模型能单独决定的。它需要上下文，需要业务优先级，需要团队对风险的偏好。AI 可以给意见，但最好不要拥有最终决定权。
我会让 Agent 先审“机械问题”
如果我是一个三五人的小团队，我不会一开始就让 AI 审架构。我会让它先审机械问题，因为这类问题成本低、收益稳定、争议少。
请只检查以下问题，不要提出风格重构建议： 1. 空值、越界、并发、重试相关风险； 2. 是否遗漏错误处理； 3. 测试是否覆盖新增分支； 4. 是否修改了公共 API 行为； 5. 是否引入明显的安全风险。 输出格式： - 问题位置 - 为什么是风险 - 最小修复建议 - 是否必须阻塞合并
这段提示词的关键不是“请认真审查”，而是限制它不要乱提大而泛的建议。很多 AI review 让人烦，不是因为它没用，而是它把“可以改得更优雅”说得像“必须修”。
AI reviewer 最应该接入测试和 diff，而不是只读 PR 描述
只把 PR 描述丢给模型，价值有限。真正有用的是让它看到 diff、相关测试、失败日志和影响范围。一个更稳的本地流程可以是这样：
git fetch origin main git diff --stat origin/main...HEAD git diff origin/main...HEAD > /tmp/pr.diff pnpm test -- --runInBand 2>&1 | tee /tmp/test.log pnpm typecheck 2>&1 | tee /tmp/typecheck.log
然后让 Agent 基于 /tmp/pr.diff、/tmp/test.log、/tmp/typecheck.log 做审查。这样它至少不是凭 PR 标题猜。
如果是 GitHub Actions，可以把 AI review 放在非阻塞 job 里，先生成评论或报告，而不是直接挡住合并。原因很简单：早期误报一定会多。你需要先观察两三周，看看它最常报什么，哪些对团队真的有用。
不要让它替你做产品和架构取舍
我最不建议交给 AI reviewer 的，是产品语义和架构方向。比如：
- 这个字段到底该不该暴露给外部 API；
- 为了兼容老客户是否值得保留分支；
- 是否应该引入新的消息队列；
- 这个模块边界是不是团队未来半年要坚持的方向。
这些问题可以让 AI 帮你列利弊，但最后必须由人决定。一个比较稳的写法是：
请列出这个改动可能影响的架构边界， 但不要给出最终合并建议。 最终判断由维护者根据路线图决定。
这听起来保守，但小团队真正怕的不是漏掉一个格式问题，而是被一堆“看似合理”的建议拖着重构，最后主线需求没交付。
审查记录要沉淀，否则只是一次性聊天
AI review 如果只停留在聊天窗口，很快会消失。更好的做法是把结果沉淀成项目规则。比如 AI 连续三次提醒“新增 API 没有鉴权测试”，那就不应该每次都靠它提醒，而应该补测试模板或 CI 检查。
docs/review-rules.md - 新增 API 必须包含鉴权测试 - 涉及金额字段必须包含精度测试 - migration 必须有 rollback 或明确不可回滚说明 - 后台任务必须记录 task_id 和失败原因
我的建议是，每两周看一次 AI reviewer 的报告，把高频且真实的问题变成自动化检查。AI 适合发现模式，但长期治理不能只靠 AI。
我的判断
代码审查 Agent 对个人开发者和小团队都值得试，但不要把它当成“更便宜的资深工程师”。它更像一个耐心的初筛器，适合抓机械问题、提醒遗漏、整理风险清单。
我会这样落地：先让它非阻塞审查两周，只看 bug、安全、测试、公共 API 变化；不让它提大规模重构建议；每周把有效提醒整理进 CI、测试模板或 review checklist。等误报率降下来，再考虑让它参与更复杂的设计审查。
资料依据：Anthropic Claude Code / Claude Opus 4.7 公开更新中关于专门 review session 和 /ultrareview 的说明。这里没有引用真实团队 PR 数据，后续最好补一个匿名 diff 审查案例，否则只能作为工作流建议。