代码审查正在变成一个被反复争论的话题尤其是在 AI Engineer 这个岗位逐渐进入团队之后。过去代码审查被当成质量的最后一道闸门现在很多团队发现这道闸门已经变成了合并代码的主要瓶颈。开发者提交 PR 后在等待评审者在堆积如山的变更列表前疲惫不堪AI 生成的代码还在以更快的速度涌入。于是我们不得不面对一个更尖锐的问题代码审查到底该如何终结这里说的“终结”不是取消质量保障而是终结一种已经失效的协作方式。传统的人工逐行审查正在被一套更细、更自动化、更分层的新工作流替代。留下来的不是“人肉找茬”而是真正需要人类判断的设计评审和决策对话。1. 为什么代码审查从“质量保障”变成了“流程瓶颈”1.1 传统代码审查的三个价值从工程实践看代码审查之所以存在靠的是三个核心价值。第一是发现缺陷。在代码合并到主干之前让另一个人用眼睛扫一遍找出明显的逻辑错误、边界条件遗漏、安全隐患和异常处理缺失。这个价值在早期代码规模小、开发速度慢的年代是有效的。第二是评估设计。审查者不仅要看代码是否跑得通还要看它是否融入了现有架构是否引入不必要的复杂度是否破坏了接口兼容性是否存在更简单的实现路径。这是一类需要系统视角和经验的工作。第三是传递知识。通过审查评论新成员可以理解老代码为什么这样设计团队可以对齐编码习惯甚至能发现一些文档里没有写清楚的“隐藏规矩”。这三个价值都对。问题在于传统流程把这三件事捆绑成了一个动作创建 PR等人审然后在评论框里逐行讨论。这个动作看起来很合理但它对参与者的要求极高审查者需要在有限时间内同时扮演缺陷检测器、架构顾问和文档写作者。1.2 真正让它变成瓶颈的是异步等待现实工程中最常见的场景是开发者写完一个功能创建了 PR然后开始等待。评审者可能正在开会、在写另一个功能、或者在处理线上事故。于是 PR 挂在那里时间一长分支落后主干又产生冲突开发者也忘了当时的上下文。等评审者终于打开 PR又要花很长时间重新理解这段代码。这还不是最麻烦的。麻烦在于代码审查是串行依赖稀缺注意力的流程。团队里真正能提出高质量评审意见的人往往也是压力最大的核心开发者。他们被拉进大量 PR 评审自己的开发节奏被频繁打断。结果就是审查队列越来越长质量越来越低大家都疲惫。1.3 AI 代码生成放大了这个矛盾AI 辅助编程普及之后代码生产速度明显提升。一次提交中的变更量可能比过去大很多而且很多代码是模型生成的。这些代码通常语法规范、风格统一人眼看起来“很干净”。但它们是否真的符合业务逻辑是否覆盖了异常路径是否会在特殊数据下出错往往不是一眼能看出来的。如果团队仍然坚持逐行人工阅读审查工作会立刻过载。一个由 AI 生成但被人工确认过的 PR可能比一个由人自己写的 PR 更少有人愿意真正深入审查。因为大家都觉得“AI 写的代码自己也没把握但至少看起来没问题”。于是代码审查从一个质量保障机制变成了整个研发流程里最脆弱的环节。2. 要终结的不是审查而是“人眼逐行检查”这个旧假设2.1 旧模式的前提已经失效传统代码审查隐含一个假设一个聪明、有经验的人通过阅读代码差异就能在合并前识别出大多数高风险问题。这个假设在代码规模小、变化频率低、团队业务知识稳定的时候是成立的。但在今天代码库复杂度、依赖复杂度、业务上下文都在增长很多错误不是靠读代码能发现的。并发问题需要在特定调度下才出现数据一致性问题需要看多个服务的调用链安全问题需要分析输入输出路径性能问题需要看运行时指标。这些都无法靠一次人工 diff 阅读解决。所以旧模式不是不好而是它的条件变了。继续沿用只会让团队在低价值的地方消耗高成本。2.2 把审查拆成三个能力要重构流程先把代码审查拆成三类能力。审查活动最佳执行者原因语法错误、规范问题、重复代码、明显的安全反模式静态检查工具 AI 审查机器人速度快、覆盖广、不会疲劳异常处理、边界条件、并发风险、逻辑漏洞AI 预审 人工确认AI 能找到疑点人来做最终判断架构设计、接口契约、业务对齐、长期演化人的设计评审需要业务上下文、取舍经验和系统视角这个拆分的核心是不要把三个不同性质的任务塞进同一个“读 diff”动作里。机器擅长的事情让机器做人才擅长的事情留给人在更合适的时间做。2.3 用“变更风险 × 变更规模”矩阵做分级我们可以用一张简单的四象限来判断一个 PR 应该走什么审查路径。小规模变更大规模变更低风险自动检查通过后合并可抽审AI 预审 人工抽审高风险AI 预审 至少一名人工评审设计评审 分阶段合并 深度审查具体怎么判断风险可以考虑这几个维度涉及的资金、权限、数据路径是否修改核心公共模块是否有单元测试覆盖是否有兼容性要求是否引入新的依赖是否涉及安全敏感操作。这个矩阵不是定死的它可以按团队实际情况调整。但它提供了一种思路不是所有 PR 都应该被同等审查。让高成本的人工注意力流到真正高风险的地方。2.4 为什么设计评审这件事不能交给 AI有人会问AI 既然能理解代码能不能连设计评审也一起做了我的判断是不能至少现在不行。设计问题往往不是“对错”问题而是“取舍”问题。一个接口是设计成同步还是异步一个功能是放在服务端还是客户端一个逻辑是统一抽象还是保持清晰重复这些决策依赖业务目标、团队能力、系统现状和未来规划。AI 能看到代码但它看不到会议室里讨论过的那些约束和妥协。它可以辅助我们整理选项、列出隐患但最终“该不该这样改”的判断必须由一个对业务负责的人来确定。所以被终结的不是设计评审而是把设计评审和逐行检查绑在一起的陈旧流程。3. 用“AI 预审 人工抽审 自动门禁”重构代码审查工作流3.1 五步流程总览下面这套工作流是我在实际团队里比较推荐的做法适合已经有 CI 基础、希望通过渐进方式减少审查负担的团队。提交前在本地运行静态检查和单元测试。创建 PR 后让 AI 审查机器人先做一轮预审。自动按风险矩阵做分级决定是否需要人工评审。人工只审高风险变更评委提问作者解释。把评审结论沉淀成规则、测试和设计文档。下面展开每一步。3.2 提交前先用自动化把低层级问题拦截掉这一步的目的是让 PR 在进入任何人视野之前先把机器能查的问题清一遍。常见的做法是# 简化示例PR 检查顺序 npm run lint npm run typecheck npm run test ai-review --focusbug,security --diff-only # 如果风险分级为 high则进入人工评审环节 risk-assessment这是一个示例结构具体命令要结合你的技术栈和工具链替换。但原则很明确先跑静态检查和测试再让 AI 针对 diff 做一轮面向 bug 和安全的预审。需要提醒的是不要在第一次引入 AI 审查时就把所有规则打开。先在一个仓库、一条 PR 上试跑看它生成的评论价值有多大再逐步扩大范围。注意不要一上来就把“AI 审查机器人”的评论全当结论先在一条 PR 上跑通再逐步打开范围。3.3 创建 PR 后让 AI 先做预审而不是人等 AIPR 创建后理想状态是 AI 机器人在几分钟内给出初步评论而不是等人工评审者开始看。AI 预审能做的事情包括定位可能的空指针、未处理错误、资源泄漏、缺少权限校验、重复代码、高风险依赖变更等。这些评论可能有很多是噪音需要调优但它可以作为初筛。要给 AI 审查工具提供足够的上下文否则它只能就代码论代码。通常需要让 PR 描述包括为什么要改这个功能。影响范围是什么。是否涉及公共接口或数据模型变更。已经做过哪些测试。期望评审者重点看什么。没有这些上下文AI 只能猜人工审查也无法高效展开。3.4 按风险分级决定是否进入人工审查在 AI 预审的基础上可以用一个简单的规则做分级。风险维度判断标准变更模块是否涉及核心服务、基础库、权限、支付、数据迁移变更规模改动文件数、行数、依赖数测试覆盖是否有对应单测、集成测试本地与 CI 是否通过兼容性是否修改对外 API、数据库字段、消息协议可回滚性出问题后是否容易回滚是否需要迁移脚本根据这些维度给出低中高风险。比如低风险改动范围小有测试覆盖不影响公共接口可快速回滚。中风险改动涉及核心逻辑但测试齐全评审者可以抽审。高风险改动公共接口、数据模型或安全相关代码必须人工深度审查。这样做有一个好处人工评审不再被几百行 diff 淹没而是只在真正关键的位置出现。3.5 人工审查从“逐行挑错”变成“关键决策评审”如果团队已经走到这一步人工评审者的角色就变了。不用再重复检查格式、命名、未使用的变量这些事情机器已经做了。人要看的是这个设计是否符合当前业务目标。这个抽象是否过早或者是否已经把复杂度推给了调用方。这个改法是否破坏了系统的兼容性边界。如果上线后出问题回滚方案是否清晰。是否有比当前实现更简单、更稳定、更容易测试的路径。建议采用“评审者提问、作者解释”的方式而不是单向列出一堆评论。这样既减少了无意义的争论也让知识在对话中流动。对大型 PR尽量拆成多个小 PR。一次变更最好只做一件事。如果真的无法拆分至少要分阶段合并避免一个巨型 PR 把所有信息都压在一起。3.6 把评审输出沉淀成知识库这一步经常被忽略但它决定了这个流程能否长期有效。一次评审中发现的典型 bug应该转化成静态检查规则或测试用例。一个反复出现的架构问题应该被记录为设计决策文档。一次关于“为什么不用某个轮子”的讨论值得写进团队的 ADR让以后少重复一轮同样的讨论。当团队把这些知识沉淀下来之后AI 审查工具也可以基于这些规则做更好的初筛。慢慢地人会越来越不需要看低价值评论。4. 落地的四个真实坑以及一条排查链路4.1 坑一AI 审查结果误报和漏报AI 审查不是银弹。它可能会提出一堆“建议把变量重命名”的噪音评论却漏掉真正复杂的并发问题。也可能因为缺少业务上下文把兼容逻辑当成死代码建议删除。处理方式不是放弃 AI而是给它设定合理的边界。可以先在一个月内记录 AI 评论与人工发现的问题交集如果交集太小就调整规则或者换一种审查策略。要允许忽略低价值评论不要让 AI 审查变成新的噪音来源。4.2 坑二人工审查变成“走过场”自动化门禁多了以后会出现一种新的风险评审者看到机器已经检查过就只点一个“Approve”不再认真想问题。我的建议是人工审查只在高风险 PR 中出现并且给评审者设定一个明确的“必须回答的问题清单”。例如这个改动是否会影响现有的线上数据是否引入了新的依赖维护成本可接受吗是否存在比当前实现更简单的路径如果这个模块出了问题团队能不能快速定位和回滚这样的问题驱动比简单说“代码看起来没问题”要有效得多。这里最容易被忽视的是自动化门禁越多人越容易放松。要保留一道“必须由人来回答”的问题清单。4.3 坑三上下文缺失导致 AI 说废话AI 预审如果看不到业务背景就会给出泛泛的建议。比如一个函数是兼容旧接口的AI 却建议删掉一个变量名是团队约定的缩写AI 建议改掉。解决方案是从流程上逼作者提供上下文。PR 描述模板里可以明确要求写为什么改、影响范围、测试情况、需要评审的焦点。没有这些内容PR 不进入 AI 预审阶段。这个习惯一旦建立不仅 AI 审查更准确人工评审也更高效。因为这本质上是在强制开发者先想清楚自己的变更。4.4 坑四知识传递沉默当评审评论被便捷地“resolve”掉之后很多有价值的讨论就消失在界面里了。新人之后遇到类似问题只能重新发现一遍。建议把关键评审会议沉淀为短会纪要把典型问题转成测试用例或 lint 规则。尤其要记录那些“我们讨论了很久最后因为某个原因选择了这个方案”的时刻。这些记录的价值远大于一次性的评论留言。4.5 一条可复用的排查链路如果你已经引入了这套流程但感觉效果不好可以按下面的顺序排查先看现象是 AI 审查没有评论、评论噪音太多还是漏掉了严重问题再看输入PR 描述是否完整diff 是否携带了必要的上下文变更范围是否太大再看环境静态检查工具、AI 审查工具、CI 是否正常运行仓库语言和框架是否兼容再看配置AI 审查的严重级别、focus 领域、ignore 路径、阈值是否合理规则是否与团队风格一致最后看边界是否只试运行了一两天就下结论样本量够不够是否拿它去审查了一个本来就不适合自动化的老系统这个顺序适用于大多数“工具不生效”的问题。先不要急着换工具往往问题出在前面几层。5. 代码审查终结后的团队角色与适用边界5.1 未来形态AI 负责“有没有问题”人负责“该不该这么改”当传统代码审查被终结之后并不意味着不再需要人参与质量保障。机器和人会在不同层协作。AI 和自动化工具负责回答“有没有问题”有没有语法错误、有没有明显 bug、有没有安全漏洞、有没有违反规范、有没有测试失败。这些问题可以被枚举、被验证、被自动化。它们的答案是可重复的适合由机器处理。人负责回答“该不该这么改”这个设计是不是符合业务目标、这个取舍是否可接受、这个引入的新依赖是否值得、这个拆解方式是否会在未来带来更多复杂度。这些问题没有标准答案需要根据团队、业务和系统现状来做决策。5.2 开发者的能力模型迁移在这个变化中开发者的能力要求也在变化。过去一个能把代码写对、能应付审查提问的人就是一个合格的开发者。未来你还需要有另一种能力把业务意图讲清楚把变更拆成可验证的小块能判断哪些问题可以交给机器哪些必须让人来看。这就是 AI Engineer 时代的一种典型协作能力。AI 可以帮你生成代码但你需要为它的结果负责。你需要说清楚“我希望它做什么”并且在 AI 审查结果面前做出取舍。对经验丰富的评审者来说意义也在变。你不用再花时间在低质量评论上可以把精力放在更值得深入的问题上。这也是一种从“看代码”到“看设计”的角色升级。5.3 适合什么团队不适合什么团队这套流程适合有一定基础设施的团队。比如已经有 CI、有自动化测试、代码模块划分相对清晰的团队。在这样的环境中AI 预审和风险分级可以很快起作用。如果你的团队只有两三个人直接引入一整套流程会变成负担。这时候最简单的做法是本地钩子跑一遍检查再加上一次每周固定的代码走查就够了。如果你的仓库还是老旧的巨型单仓几乎没有测试覆盖改动经常跨几十个模块那第一步不是引进 AI 审查而是先把变更拆小、把关键路径补上测试。没有这些基础AI 预审也无法提供稳定价值。另外在极端安全合规要求下某些行业可能仍然需要完整的人工审查记录。这种场景不能直接“终结”代码审查但可以用 AI 预审来辅助人工提高漏检率。如果团队只有两三个人直接引入全套流程会变成负担先做“本地钩子 一次走查”就够了。5.4 回到一个更底层的经验我见过很多团队花了大量时间争论审查流程最后真正带来改变的不是工具选型而是把注意力从“读每一行代码”转向“让机器做机器的事让人做人的事”。代码审查的终结不是取消一个流程而是把人的注意力从重复劳动中释放出来放到只有人能做出的判断上。真正的质量保障会发生得更早也更分散在需求设计时、在写提交描述时、在测试覆盖时、在评审关键决策时。所以你不需要再问“代码审查该不该终结”而是该问我们团队目前把时间花在哪些低价值审查上哪些部分可以先交给机器哪些部分必须让人继续亲自负责这几个问题答完代码审查的新形态就基本出来了。它不再是一条需要排队等待的流水线而是一套有自动预审、有分级门禁、有人机协作的质量护栏。