Claude Code做首轮PR审查：每天省30分钟

代码审查是移动端团队每周悄悄损失每个工程师一天时间的地方。不是写审查，是等审查。我把 Claude Code agent 放进了真正的审查流程中，作为每个 PR 的第一道关卡，在我自己的测量中，这为每个工程师每天节省了大约 30 分钟。审查周期时间下降了，审查质量保持住了。人类审查者回到了真正重要的事情上争论：设计。

这是完整的工作流程，包括那些没有奏效的部分。

人类优先审查的问题

每个 PR 审查都混合了两件完全不同的工作：

机械验证。能否构建，边界情况是否处理，命名是否一致，是否有人忘记了本地化字符串。

判断。这是不是正确的抽象，它是否符合模块的发展方向，半年后它会不会咬我们一口。

人类在第一件事上很慢，在第二件事上不可替代。传统审查迫使高级工程师同时做两件事，所以机械部分挤掉了判断部分。审查者浏览、 LGTM，架构漂移在一个个被浏览的 PR 中累积。

我把 Claude Code 作为第一个审查者，运行在每个 PR 上在任何人类看它之前。

1. PR 打开时的 Agent 审查

多 agent 审查在 diff 上展开，每个维度一个 agent：

正确性：边界情况、nil 处理、并发。那些当人类浏览 400 行变更时容易溜过去的老问题。

一致性：代码是否与周围模式、命名、错误处理惯用法、模块约定匹配。

测试：测试是否真正覆盖了行为变更，还是只是在镜像实现。

i18n 和无障碍（移动端特有）：硬编码字符串、缺少 Dynamic Type 支持、触摸目标小于 44pt。

每个发现都必须引用文件和行号，并描述具体的失败场景。没有失败场景的发现会被丢弃。这条规则是保持输出不会变成"考虑提高可读性"这种噪音的原因。

2. 作者在人类审查前修复

作者在几分钟内收到发现，而不是几小时。机械问题在高级工程师切换到 PR 上下文前就被消灭了。当人类打开 PR 时，diff 已经足够干净，审查是关于设计的。

3. 人类审查，重新定义

人类审查者现在只有一件事：判断。模块边界、API 形态、这个功能是否应该在这里。我在前文 iOS Architecture Decisions AI Can't Make 中写的东西仍然是 100% 人类的，而现在它终于得到了需要的注意力，而不是在审查者最后一小时被一个缺失的 nil 检查占用。

那些没有奏效的部分

绿色 agent 审查时自动合并。这是我最后悔先发布的功能。一个有着 prompt 但没有编码意图的 agent 会优化最近的代理指标——"测试通过"，而不是真正的目标——"这个变更正确且值得合并"。它愉快地点亮绿灯满足了测试的字面意思却错过了要点。我撤掉了自动合并，让人类回到合并按钮上。agent 提供建议，人类做决定。

一个 mega-agent 而不是分维度。一个单独的"审查一切"的通过产生浅显的发现。分维度窄聚焦的展开才能暴露真正的 bug。正确性 agent 不会被命名分散注意力，所以它真正在推理并发。

在有了记录的指标之前部署 agent。我是在事后测量 30 分钟的，不得不重建基线。我应该在第一个 agent 运行前就商定我关心的数字，以及如何测量它。如果我重新做，那会是第零步。我在一个更小的规模上再次犯了同样的错误，在这个网站上发布 llms.txt，我在那里的不同做法是相同的修复：在发布前决定你如何知道它有效。

我实际测量的

我只引用我测量的内容，因为这样的文章生死取决于此。在那个跨国 iOS 团队上，经过数月的日常使用：每个工程师每天节省了大约 30 分钟，审查周期时间下降，审查质量保持住（当机械通过移到 agent 时，人类的标准没有下降）。我没有足够干净地检测逃逸缺陷率或回收的高级工程师小时数来引用，所以我不引用。

不要在一周内自动化你的整个审查文化。从一个维度开始（一致性是最安全的），一个仓库，发现作为建议而不是关卡。让人类留在合并按钮上。只有当团队开始自己信任这个信号时才扩展。审查循环是更广泛模式的一个实例；我在 AI agent 工作流 for engineering teams 中写了如何选择和界定其余部分。

如果你想要帮助为你的团队设置 AI 辅助的工程工作流，包括架构、工具和围绕它的变更管理，这正是我在策略会议上做的事情。

我仍在解决的一个问题：对你来说，agent 提供建议和实际上让它合并之间的界限在哪里？我还没有找到一个团队愿意把这条线前移，我想知道你的答案。

Originally published at veheria.tech/blog/claude-code-code-review-workflow.