AI 代码通过测试后，审查该看哪里

AI 用 10 分钟改完 40 个文件，PR 描述清楚、测试全绿，还附上一句「一切符合预期」。Reviewer 真正要回答的问题却没变：哪些地方必须仔细读？这些证据够不够支持上线？

作者给出的答案是，把审查精力分配给风险、证据和上下文。能合并，只能说明变更跨过了当前的合入门槛；能否上生产，还要看故障后果、恢复能力，以及它是否解决了真正的需求。这套思路值得读，因为 AI 加快交付后，人工判断正在成为更稀缺的资源。

一行共享代码，为什么比 300 行页面更值得审

按改动行数分配 Review 时间，很容易看错重点。

作者举了两个 PR：一个新增 300 行设置页，包含新组件；另一个只改共享 API client 的一行，让请求失败时返回空列表，不再抛出异常。前者的影响可能局限于设置页，后者却改变了所有调用方的错误语义。用户看到的「没有数据」，可能其实是服务出了问题。

审查深度应该跟着失败后果走。

作者先看影响范围，也就是故障会波及多大面积，并分成三档：

• 低影响范围包括独立 UI 组件、没有共享状态的展示组件、小样式调整。检查明显错误后，可以更多依靠自动检查、测试和视觉验证。
• 中等影响范围包括功能专属 hooks、表单校验与提交、单个功能的 API 集成、页面级状态。重点是数据流、边界情况和功能内的回归。
• 高影响范围包括全局状态、认证与授权、共享 API client、通用 hooks、路由、权限和应用级配置。需要进一步检查依赖、副作用、兼容性、安全性和生产影响，必要时增加一位人工或 AI reviewer。

不过，波及范围只是风险的一部分。共享格式化工具影响面很广，但出错代价可能较小；支付授权只涉及一条流程，失败后果却可能很重。因此，还要叠加判断严重程度。

审批之前，作者还会问三个问题：哪些既有行为必须保持不变？最坏且合理的失败结果是什么？恢复需要多久，能否安全完成？

这会把 Review 从「新功能看起来能跑」推进到「出了问题怎么办」。API 返回异常数据、请求执行到一半失败、兼容性被破坏，都应该进入讨论。对于难以撤回的变更，可以考虑功能开关、渐进发布、向后兼容，以及范围集中的小 PR。

作者用一个夸张场景提醒读者：2,000 行 PR，要么认真审一周，要么四分钟得到一句「LGTM」。这不是统计结果，但指出了一个现实约束：混在一起的改动越多，理解和回退的成本通常越高。小 PR 并不天然安全，只是更容易看清风险。

测试全绿之后，还缺哪一种证据

作者区分了两件事：实现是否自洽，以及实现是否完成需求。

AI 很容易把前一件事包装得很完整。代码结构清楚，测试也覆盖了它写出的行为，最后给出肯定结论。但如果需求理解错了，这些检查可能一起跑偏。

原文的筛选功能例子很典型：agent 报告「筛选已实现，所有测试通过」，测试却只覆盖了筛选操作，没有验证需求中的「刷新页面后保留筛选条件」。一段包含刷新操作的录屏，或者一个执行页面重新加载的测试，就能暴露缺口。

证明实现正确的测试，未必证明需求已经完成。

因此，证据要按变更类型选择。前端更新可以提供截图、录屏或受影响流程的演示；业务逻辑需要有意义的测试及结果；API 集成还应验证请求失败、异常响应和边界情况。

这些材料都要回到原始验收条件上核对。截图能证明某个页面状态，却无法单独证明刷新后的持久化行为。测试名称写着「成功」，也不代表关键用户路径已经覆盖。

面对 AI 的完成报告，Reviewer 应该追问的是：实际运行了什么，哪些检查通过了，还有哪些没有验证。作者没有要求每个 PR 都附上所有材料，而是要求证据能够支撑当前变更的结论。

哪些交给工具，哪些仍然需要人判断

TypeScript、ESLint、格式化工具和静态分析，适合提前处理能够稳定识别的问题。AI 也可以承担重复清理和直接的重构工作，让人工注意力更多留给正确性、架构、安全、业务规则与回归风险。

但可读性不能全部归入个人偏好。

尾随逗号之争可以交给 formatter；误导性的命名、绕来绕去的控制流、不必要的抽象，会增加后来者理解和修改代码的成本，仍然值得在 Review 中指出。判断标准是：这条意见能否说明具体的维护代价。

反馈也需要提供证据。「这里可以更好」没有告诉提交者要修什么。有效评论应说明问题，并标明它是否阻塞合并，还是一条可选建议。

工具负责机械检查后，人仍要解释为什么这里存在风险。多一个 AI reviewer 可以增加检查视角，却不能自动替代这种判断。

为什么审 diff 之前，要先读需求和历史

有些代码看起来多余，是因为它在规避过去发生过的故障。只看当前 diff，很容易把保护逻辑当成冗余，甚至在重构时重新引入旧问题。

作者建议，在深入实现前，先看任务、验收要求、PR 描述、关联 issue 和相关提交历史。它们能解释代码为什么长成这样，也能帮助判断复杂度究竟来自业务约束，还是来自不必要的设计。

这也是保持 PR 聚焦、提交记录清晰的价值。描述和历史除了帮助当前审批，还会影响以后排查故障的效率。

AI 可以搜索文件、追踪依赖、总结陌生代码，但它同样需要这些上下文。开发者也必须掌握足够的信息，才能判断 AI 的解释是否站得住。原文没有提供某种上下文长度、提示词模板或自动化审查系统，因此不能从这里推导出一套开箱即用的方案。

我的判断

我认同作者把 Review 从「平均读代码」转向「按风险寻找证据」。它尤其适合 AI 生成的大量整洁代码：排版和解释越完整，越容易让人把完成感当成可靠性。

但这篇文章提供的是实践原则，没有给出团队样本、缺陷率、审查耗时或上线事故的对照数据。300 行设置页与一行 API 修改、筛选条件刷新丢失，都是用来说明问题的场景，不能当作实测结论。

风险分级本身也有门槛。一个看似独立的组件，可能调用共享状态或影响全局行为；只有了解依赖，才能判断它是否真的隔离。恢复能力同样不能只看有没有回退按钮：如果变更已经破坏数据，撤回代码未必能恢复原状。原文提出了恢复问题，却没有展开数据修复方案。

与每行投入同等精力相比，这种方法更能解释审查时间该花在哪里；与单纯增加 reviewer 相比，它也更关注检查内容。不过，它仍需要可靠的基础检查、明确的验收条件和熟悉系统的人参与。作者没有证明三档风险划分优于其他分级办法，团队可以借用判断维度，不必照搬分类。

能拿来做什么

• 给 AI 生成的 PR 补上具体的验证记录，写清执行了哪些测试、走过哪些用户流程、哪些场景仍未验证，避免只留下「全部通过」。
• 审查共享 API client、认证、权限和全局状态时，先列出行为变化及受影响调用方。例如请求失败返回空列表，就要检查页面能否区分服务异常与真实空数据。
• 把前端验收条件转换成可观察的操作。需求包含刷新保留筛选状态，验证就应包含设置筛选、刷新和检查恢复结果，单张截图覆盖不了这条路径。
• 对混有功能开发、重构和清理的 PR，尽量拆成范围集中的变更；高风险部分同时说明失败后果与恢复方式，让 Reviewer 能判断上线条件是否充分。