代码评审过去盯着一件事：这几行代码写得对不对。AI 开始大规模生成代码，光盯实现已经看不过来了。工程师还得回答一个更难的问题：交付结果有没有兑现原始意图。
IBM Technology 的这段 14 分钟视频，用代码评审的历史解释了这次变化。原视频：How AI Is Changing Code Reviews & Software Development。
评审对象一直在扩大
视频把软件系统的基本材料归为代码、文档和架构。早期的 Fagan inspection 会把团队召集到一个房间，逐行检查代码与文档。流程很正式，也很耗时间。当时开发节奏较慢，团队还付得起这笔成本。
敏捷开发把评审搬进了 pair programming。两个人边写边看，问题当场讨论，等待时间短了。审查重点仍然落在实现上：语法是否正确，代码有没有 bug，文档有没有写清楚。
代码库继续变大，协作转向 pull request。版本、diff、merge approval 加进流程，评审由少数人的实时检查变成团队共识。审查者判断某次变更能不能进入主分支，也要处理多人同时修改同一系统带来的冲突。
CI/CD 随后接管了一部分机械检查。流水线能查代码质量、安全漏洞和合规规则，也能把内部规范、外部标准或政府监管要求写成自动门禁。人看 diff，系统看规则，代码评审由共识检查进一步扩成系统检查。
把这段历史放在一起看，大致有四站：
| 阶段 | 主要评审对象 | 典型方式 |
|---|---|---|
| 逐行检查 | 语法与实现 | Fagan inspection、团队检查 |
| 协作检查 | 实时实现质量 | Pair programming |
| 共识检查 | 版本与差异 | Pull request、merge approval |
| 系统检查 | 质量、安全与合规 | CI/CD、自动门禁 |
每次变化都没有彻底替代上一层。它只是把适合机器处理的部分固化下来，让人去处理更难判断的内容。
AI 把评审面推向意图和结果
LLM 进入开发流程后，AI 已经能写代码和文档，也能搭出架构草案。它还能分析版本差异、合并关系、代码质量和合规问题。审查材料一下子多了，继续逐行阅读很快会堵住整个交付流程。
IBM 给出的分工很清楚。AI 负责广域分析，把散落在代码库里的组件、检查项和依赖关系串起来。人负责设定上下文，判断业务目标，比较不同方案的取舍，再通过多轮提示让结果靠近需求。
评审问题也跟着换了。团队开始追问下面几件事：
- 需求表达的意图有没有落到产品里；
- 结果是否通过测试和自动检查；
- 运行时证据是否支持这个结果；
- 业务影响是否符合预期。
视频把这种方式称为 outcome review，也就是结果评审。它依赖既有的自动化基础。测试、质量检查和运行时观测没有消失，反而成了判断结果可信度的证据。
这里有一个容易忽略的区别。AI 能生成一份看起来完整的实现，也能给出解释，但“看起来完整”无法证明系统真的工作。结果评审要求把需求、实现和证据放在同一个审查面里。没有证据，结果仍然只是一次有说服力的猜测。
只看结果也会留下盲区
这段视频的方向是对的，但还缺一层约束。AI 让生成速度变快，审阅能力未必同步增长。生成量超过审阅量以后，差额会沉淀为未检查的代码，边界条件和异常路径往往最先出问题。
一个真实故障能说明问题。某个 SSE 服务已经把消息创建事件发给客户端，上游也生成了完整答案，客户端却一直收不到完成或失败事件。逐层看代码，每一处都很常见：函数遇错提前返回，外层关闭 channel，HTTP 层把 channel 关闭当作正常结束。组合起来，异常被安静地翻译成正常 EOF。
这类问题很难靠逐行审查发现，也不能只看“页面最终有没有答案”。需要一条跨层不变式：每条消息创建后，必须且只能进入完成、失败或取消中的一个终态。然后用服务日志、数据库状态、事件流和客户端记录交叉验证。
这个案例补上了结果评审的工程底座。结果需要拆成可以验证的契约，关键路径要有确定性门禁，运行时要留下证据。AI 可以帮忙检查范围，人仍要定义什么算成功、哪些异常不能静默退出。
代码评审还承担团队对齐
结果正确只是评审的一部分。Pull request 也在传递知识：为什么选这个架构，哪些约束来自历史系统，新同事应该怎样理解模块边界。团队成员读代码和讨论方案的过程，本身就是对齐。
如果 AI 写代码、AI 审代码，人只负责点一次批准，技术检查可能变快，团队却会逐渐失去共同上下文。几个月后，系统仍然能运行，但没人说得清某个取舍来自业务要求、历史包袱还是一次临时提示。
所以，未来的评审面至少要保留两类内容：
| 评审层 | 要回答的问题 | 主要证据 |
|---|---|---|
| 结果验证 | 产品有没有按意图工作 | 验收标准、测试、运行时数据、合规检查 |
| 团队对齐 | 团队是否理解为什么这样做 | 决策记录、架构取舍、提示会话、评审讨论 |
视频重点讲了第一层。第二层来自工程团队的长期协作经验。两层放在一起，代码评审才不会退化成 AI 产物的自动盖章机。
评审流程可以怎样调整
真要落地，可以先改 PR 入口。提交 diff 时，一并附上原始意图、验收标准和验证结果。审查者先看目标和证据，再按风险决定要不要深挖实现细节。
低风险、可确定判断的内容尽量交给工具：格式、类型、依赖、安全规则、迁移校验和常见异常路径。业务取舍、架构边界和失败影响仍由人判断。这样做能扩大审阅带宽，也能避免工程师把时间花在机器早已能稳定检查的项目上。
还要保存 AI 协作过程里真正有价值的上下文。提示词里经常包含需求澄清、边界条件和被放弃的方案。如果合并代码时把这些内容全部丢掉，最完整的意图记录也随之消失。保留决策摘要与测试依据，比保留整段聊天记录更实用。
我的补充
IBM 的结论可以浓缩成一句话：AI 时代的代码评审，会从检查实现逐步转向验证意图、结果和业务影响。
工程上还要再加一句：结果必须有证据，对齐必须有记录。缺少这两项，团队只是把“人工逐行看代码”换成“人工相信 AI 已经看过”。
如果团队准备调整评审流程，可以从一条小规则开始：每个 AI 参与生成的 PR，都附一份可执行的验收清单和运行结果。先让结果可验证，再讨论要不要减少逐行阅读。
