按影响半径审查智能体写的代码

为什么小 PR 规则不管用了

人手写代码时，diff 小就好审、好回滚，所以团队推小 PR。智能体按特性而不是按增量输出：迁移、模型、服务、测试、前端一次给齐。Rootly 试过让智能体拆成堆叠 PR，每个都挑不出错，合起来却更难审——审一个 PR 的意见，总要依赖另一个 PR 的改法。

缺陷的样子也变了：代码能跑、测试全绿，只是用错了场景。一次迁移删掉了后台任务还在调用的字段；一个服务往另一个团队正在读的表里写数据。按行数审，这类问题看不出来。

审查分四步

1. 先问坏了会影响谁。 把会改变业务行为的变更，和只影响性能或界面的变更分开定级。Rootly 的内部审查器只回答这一个问题，交给人的是一份带风险评估和严重程度的报告，不是原始 diff。
2. 「为什么改」由人写。 PR 里的动机和背景，由使用智能体的那个人填写，不让 AI 生成——这一段的价值就在于记下生成代码的那一方不知道的上下文。每个 PR 还要写明怎么回退，包括要不要修数据。
3. 用审查工具前先选方向。 Open Code Review 精确率高、token 用量约为通用智能体的九分之一，但召回上限约 20%：专家标出的问题它有八成找不到。它适合减少人要看的噪声，不能单独兜底。
4. 把安全边界挪到发布。 重要特性放在功能开关后面，合并时默认关闭，先在团队内部打开，再到一小批客户、10%、全量。真正的审查发生在放量过程中。

守住整体设计

产出不再是瓶颈，能被人看懂的设计才是。Simon Willison 借《人月神话》的「概念完整性」说：过去一周工期会替你否掉的功能，现在一小时就能写出来，所以「要不要这个功能」得有人明确把关。

审查时还要看测试和基线有没有跟着被改。Copilot 运行时改写成 Rust 的过程中，漏掉功能的回归几乎都来自端到端测试不够；DoorDash 的 45 个合并请求里有 14 个仍需要人修改。

与相邻能力的分工

任务怎么挑、验收标准怎么锁，见「给编码智能体划定任务与验收」；这一条接在它后面，处理已经交回来的代码。