最近我遇到一个特别典型的场景下午刚开完会打开代码托管平台待审核的变更列表排了十几条。点开一条diff 里有一大段明显是 AI 生成的代码结构很完整注释也周全但你再往下翻发现它悄悄改了一个共享函数的默认参数影响到旁边两个模块。看完这条下一条又在等着你。一天下来几乎没时间写自己的代码全是帮 AI “擦屁股”。这不是个别人的困扰。AI 编码助手把“写代码”的速度压缩到了分钟级但“审代码”这件事几乎没有被加速。于是团队出现了一个新的瓶颈代码产出过剩人工审查跟不上。我的核心判断是我们需要的不是“更认真地逐行审完所有代码”而是把代码审查重新设计成一套分层、自动化、按风险分配精力的系统。用机器处理机器擅长的事用 AI 辅助人做判断让人只盯住真正会出问题的边界。1. 瓶颈已经从“写代码”转移到“看代码”1.1 AI 编码助手到底改变了什么过去几年编码辅助工具走了一条非常清晰的路从补全一个函数到生成一个文件再到根据需求直接改多个文件。像 Claude Code、Cursor 这一类工具已经不只是“帮你少敲几个字”而是能自主读取项目结构、修改代码、运行命令、提交变更。换句话说AI 开始承担“实现者”的角色。这个变化带来的直接后果是 PR 的体积和数量同时上升。以前一个需求可能要写大半天现在 AI 可以在几分钟内生成初版剩下的时间大部分花在调试和修改上。于是提交到 review 环节的代码量迅速膨胀。但人的阅读速度并没有因此变快。一个人一小时能认真阅读并理解的代码量大概也就几百行。如果团队每天合并的代码里有一半以上是 AI 生成的那 review 的压力会直接成为新的瓶颈。这不是说 AI 工具不好而是说团队过去围绕“人写代码”建立的工作流现在需要围绕“人审代码”重新调整。原来代码写得慢review 可以慢慢来现在 AI 写得快如果 review 还停留在“逐行阅读”的阶段整个流程一定会堵住。1.2 为什么“全部逐行审查”在数学上不可行我们先算一笔账。假设一个中等规模的团队每天合并 10 个 PR每个 PR 平均 300 行其中 60% 是 AI 生成的代码。那就意味着每天有 1800 行 AI 生成代码需要被审查。如果读一行代码需要 10 秒那 1800 行就是 5 个小时。这还只是“读一遍”的时间没有算上理解上下文、查看关联调用、模拟异常路径、和作者讨论的时间。而且人不是机器连续读两小时代码之后注意力会明显下降很多问题根本看不出来。所以“每一行 AI 代码都必须人工逐行审查”这个假设在规模化场景下已经不成立了。它听起来很安全但实际上会导致两种结果要么 review 队列越积越长要么审查流于形式——人还在看代码但已经看不进去了。这时候要接受一个反直觉的判断不是所有代码都需要同等程度的人工关注。逐行阅读只是审查手段之一而且不是最高级的手段。更高效的方式是先用工具做一遍结构化筛选再让 AI 做一遍一致性检查最后让人把注意力放在真正高风险、高影响的代码上。2. 用三层漏斗替代“人肉审查所有代码”如果只能记住一个框架我建议记住这个代码审查不是一道门而是一个漏斗。越靠前越应该用机器和自动化完成越靠后越应该集中人的判断力。2.1 第一层机器先过滤把低级问题挡在 PR 之前很多团队的问题在于PR 一到人工手里还在处理本应由 CI 和静态检查发现的问题。比如变量没声明、格式不符合规范、测试跑挂、明显的类型错误、死代码、未处理的异常。这些内容让人来看非常浪费精力。理想的流程是在 PR 被创建之前或推送之后自动化工具先跑一轮代码格式化与 lint 检查类型检查单元测试和集成测试静态代码分析比如 SonarQube、ESLint、Bandit 这类工具按语言和框架选安全扫描依赖漏洞、密钥扫描、危险函数调用这些检查不是“可选项”而是人工审查的前置门槛。如果一个 PR 连 lint 和测试都没过就不应该进入 human review 队列。下面是一个很简化的 CI 流水线示例用来表达“机器先过滤”这件事在工程上长什么样# .github/workflows/review-gate.yml 示例结构 name: review-gate on: pull_request jobs: static-analysis: runs-on: ubuntu-latest steps: - uses: actions/checkoutv4 - name: Run linter run: npm run lint - name: Run tests run: npm test - name: Run security scan run: npm run audit --audit-levelhigh这个示例不是标准答案但它体现了一个原则让机器先回答“代码有没有低级问题”。只有当这些都通过之后才轮到人回答“这个改动是不是真的正确”。2.2 第二层AI 辅助审查处理重复性和规范性问题等机器检查通过之后代码进入第二层。这一层可以交给 AI 辅助审查工具或者编码工具本身提供的 review 能力。AI 辅助审查可以做的事情包括总结这个 PR 改了哪些文件、哪些函数方便人快速建立全局认识检查代码是否符合项目的目录结构、命名规范、错误处理规范找出重复代码、死代码、可疑的边界条件检查是否有调试用的临时日志、硬编码的密钥、被注释掉的旧逻辑给出“可疑点列表”而不是直接下结论说代码有没有问题这里的关键是AI 审查的产物应该是“线索”而不是“结论”。人可以在 AI 生成的 review 摘要上快速判断哪些点值得深入哪些是误报。不过要注意AI 辅助审查也有边界。它很容易发现风格不一致、明显的逻辑遗漏但它很难判断“这个需求的产品语义是不是正确”也很难理解业务上不可妥协的约束。比如一个字段是不是必须加密、一个接口是不是允许匿名访问这类问题必须由人来定。我建议的用法是把 AI review 结果当作第二双眼睛先把可疑区域标出来再让人去确认。不要直接让 AI 做 final review也不要完全忽略它的输出。2.3 第三层人工聚焦高影响区域经过前两层过滤能到人工面前的代码应该已经少了很多。此时人的任务是做“高价值判断”而不是做“文本校对”。人工审查时需要带着几个问题去看这个改动如果上线出问题影响面有多大它是否涉及安全、权限、资金、数据隐私等不可妥协的领域如果出问题能不能快速回滚是否有足够的测试覆盖这个改动的核心路径如果这些问题的答案都是“低风险”那么人工可以快速看完甚至只需要看 diff 摘要。如果有一个答案是“高风险”那就要停下来认真读相关代码必要时把作者拉过来当面讨论。下面是一个分层审查责任表可以作为团队讨论的基础层级负责主体处理内容耗时预期第一层CI/Lint/静态分析格式、类型、测试、依赖漏洞、安全问题分钟级自动完成第二层AI 辅助 reviewdiff 总结、规范检查、重复/死代码、边界提醒分钟级生成线索第三层工程师人工审查高影响模块、业务语义、架构设计、不可妥协边界控制在每次 20 分钟内这个漏斗看起来不高深但真正落地需要一个前提团队必须接受“不是所有代码都要人看一遍”这个想法。否则工具做的再多人还是会把自己累死在低价值 diff 上。建议先不要急着把 review 自动化率拉满。从“机器先过滤”开始跑两周再把 AI 辅助层加进来最后才决定人工到底该看哪些文件。3. 人工到底应该审什么一份风险红线清单3.1 先按“改动影响面”给代码分风险等级很多人 review 慢是因为他对所有代码一视同仁。实际上不同代码出问题时造成的后果完全不同。一个登录函数的边界情况和一个展示型页面的文案修改不该占用同样的注意力。我们可以先把代码分成三类风险风险等级典型场景人工审查要求高风险权限、认证、支付、数据导出、生产配置、底层依赖升级必须人工逐行或逐逻辑审查最好有第二个人复核中风险核心业务逻辑、异常处理、并发、跨服务调用、状态机必须人工审查但可以借助 AI 摘要加速定位低风险文档、注释、纯前端展示、隔离的辅助函数、测试数据可以走抽审或事后审不需要逐行这个分级需要每个团队自己定义。比如一个做电商的公司订单金额计算一定是高风险一个做内容社区的公司用户作品版权相关代码可能是高风险。没有统一的跨行业清单但要有一套共同认知。建议团队花一次评审会的时间把最核心的业务模块和最容易出安全事故的代码路径列出来。这张清单不需要很详细只要足够让团队知道哪些区域的 PR 必须被认真看哪些区域可以依赖自动化。3.2 必须人工确认的六类场景虽然每个团队的高风险清单不同但有一些场景是通用的。只要 AI 生成的代码涉及下面任何一类都应该触发人工重点审查安全与权限控制登录、鉴权、角色判断、加密、密钥管理、越权漏洞。AI 容易生成“看起来能跑”的权限判断但可能漏掉一个反向条件。资金与合规相关金额计算、折扣、退款、税率、审计日志、敏感数据存储。这里的错误不是代码 bug而是业务事故和法律风险。外部接口契约和存储结构修改 API 请求/响应字段、修改数据库表结构、调整消息队列消息格式。一旦上线老版本客户端或者其他服务可能直接崩。复杂并发和状态机分布式锁、重试、幂等、超时、异步回调、多步骤状态流转。AI 很难通过局部代码看出全局并发问题必须靠人脑推演时序。删除、重命名、迁移类改动删函数、改函数签名、迁移数据、替换依赖库。表面上看起来改动不大实际上会引发连锁反应。依赖升级和锁定版本变化package.json、requirement.txt、go.mod 这类文件的变化AI 可能只因为“新版本更好”就升级一个库但这会引入不确定性必须人工确认。如果你发现一个 AI 生成的 PR 同时落在多个高风险场景里那这个 PR 应该被标记为“重点审查”甚至可以要求 AI 先补充设计说明和测试计划再进人工阶段。3.3 低风险代码也可以“事后审”或“抽审”强调一点低风险不代表不审而是可以改变审查时机和强度。比如一个隔离开的工具函数有单测覆盖CI 全绿那它完全可以在合并后的一周内由团队随机抽审而不是阻塞在发布前。“事后审”有一个前提自动化覆盖足够强回滚足够快。如果你的团队没有回滚能力或者测试覆盖很弱那低风险代码也应该保守一些至少做一次抽审。另外“抽审”不是随机抽而是按照变更模块抽样。比如本周合入了 20 个低风险 PR那就至少抽 4 到 5 个按功能模块分散开。抽审的目的是发现系统性风险比如 AI 是否总在某个模式下产生同一种问题。这比挨个看所有代码更有价值。4. 让 AI 生成的代码天然更容易被审查4.1 把审查要求写进 AI 编码规范现在很多 AI 编码工具支持项目级别的规则文件比如 AGENTS.md、CLAUDE.md 这类的约定。你可以在规则里明确要求 AI 在生成代码时遵守哪些约束从而让后续 review 更轻松。我见过一个比较有效的项目规则文件内容大概是这样# AI coding rules示例 - 所有生成代码必须遵守现有目录结构和命名规范。 - 新增第三方依赖时必须在代码块内说明用途、版本和替代方案。 - 修改文件读写、网络请求、环境变量相关代码时必须先输出风险提示。 - 禁止提交调试日志、临时注释、硬编码密钥。 - 涉及数据迁移和接口契约变化时必须额外提供影响范围说明。 - 提交前先运行相关测试不得跳过失败项。这里的重点不是让 AI 变成完美的代码生成器而是让 AI 在生成代码的同时额外输出一份“为什么这么写”的上下文。这样人 review 时不需要再去猜作者的意图能节省大量时间。要注意规则文件不要写得过长不要写成口号大全。AI 能记住的上下文有限规则越短越可执行。团队应该在每次 review 之后把 AI 反复犯的错误补充进规则让它成为一个持续更新的“审查经验库”。4.2 小步提交与自解释变更AI 生成代码有一个很明显的特点喜欢一次性生成一大片。一个 PR 里可能同时改了工具函数、页面组件、后端接口、数据库迁移文件。看起来效率很高但 review 起来非常痛苦因为几千行 diff 混在一起很难判断每个改动的因果关系。解决办法是限制每一步变更的范围。如果你在用 AI 编码工具可以在提示词里明确要求先完成类型定义和接口定义再实现业务逻辑最后补测试。每个 PR 只解决一个需求点不要混入无关重构。每个文件尽量控制在 200 行以内超过就拆分。在提交说明里写清楚“为什么这样做”而不是只有“fix bug”。这样做的本质是把一个大问题拆成多个小问题让每个变更都更容易被验证。AI 代码本身好不好是另一回事但如果 AI 做不到小步提交后续的 review 成本会非常惊人。4.3 不要执行不理解的代码这一点必须单独说。AI 不仅能生成普通代码还会给出 shell 命令、Python 脚本、JSON 配置甚至建议你在浏览器控制台里粘贴一段代码。对这类建议要建立一条安全底线不理解、不信任、不执行。例如 AI 为了安装某个依赖可能给出一段命令其中包含权限提升或者对全局环境的修改。还有的网络钓鱼页面会用“复制这段代码到控制台就能解决”的话术诱导用户执行恶意脚本。这类场景和 AI 编程工具没有直接关系但在 AI 生成代码的场景里更容易被无意中触碰。建议的规范是AI 给出的命令先拆开看每一段是做什么的。绝对不要把生产环境的密钥、Token、数据库连接串粘贴给 AI 工具。在隔离环境比如容器、虚拟机里运行 AI 生成的脚本确认没有异常再放到本地执行。如果 AI 让你在浏览器控制台或系统终端里执行一段看不到完整逻辑的代码直接拒绝。安全底线生成代码可以快但执行前必须慢。尤其当代码涉及删除、覆盖、权限变更、网络请求、环境变量时先看清楚再动手。5. Review 卡住了怎么办一条可复用的排查链路5.1 先看数量再谈质量如果你的 review 队列一直在涨先别急着增加人手也别急着要求大家“更仔细地看代码”。先量化再归因。我建议团队至少记录以下数据指标含义说明每日合并 PR 数产能看流程能承受多少变更PR 中位数 diff 行数变更粒度值越大越难 reviewAI 生成代码占比自动化水平不是越低越好而是要知道有多少代码不是人写的自动化检查覆盖率防线厚度lint、测试、静态检查覆盖了多少变更人工平均 review 耗时人力成本判断瓶颈在效率还是数量合并后一周内 bug 数质量反馈衡量整体控制效果如果每天合并 PR 数很多但每个 PR 很小那 review 压力不一定大。如果 PR 数量不多但每个都上千行那问题在于变更粒度太大。如果 AI 占比很高但自动化覆盖率很低那人工不可能扛得住。这些情况要分开处理。5.2 逐层排查输入、环境、参数、工具边界在实际使用 AI 编码工具和 AI 辅助 review 工具时经常遇到“工具没发挥作用”的情况。这时不要急着反复运行而是按顺序排查先看输入你给 AI 的上下文是否完整需求是否清晰规则文件是否被加载如果 AI 没有足够上下文生成的代码质量差review 自然难。再看环境依赖版本是否匹配API Key 是否有权限网络是否通畅比如遇到401 unauthorized报错时先检查环境变量是否生效再确认服务地址和模型名称是否匹配而不是重复执行浪费时间。再看参数是否一次性让 AI 处理了太多文件并发数和扫描范围是否太大超时时间是否设置得过短很多时候AI 工具“看起来卡住”其实是任务量超出了它的处理边界。最后看工具边界当前这套工具是否适配你的语言和框架它是否适合做深度语义理解如果工具本身只能做格式检查那你不应该指望它发现复杂的并发问题。下面是一个很常见的环境变量检查示例仅供参考# 检查 API Key 是否已经设置 echo $AI_CODING_API_KEY # 如果为空或不对再设置 export AI_CODING_API_KEYyour-key-here # 出现 401 时可以先看返回信息确认是地址、模型名还是密钥问题不要拿到报错就反复重试。好的排查方式是先看错误信息里的关键词再回到配置里一项项确认。5.3 建立团队 review 健康度指标当流程跑起来之后需要用数据判断它是否健康。我建议用红绿灯这种简单方式绿灯review 队列中位等待时间小于 1 个工作日合并后一周内没有出现严重线上问题。黄灯review 队列积压超过 3 天或者 AI 代码占比超过 80% 但自动化覆盖率还在 50% 以下。红灯开始出现“跳过 review 直接合并”的情况或者线上问题中有多起源于未被 review 的 AI 代码。红灯出现时不是要去“责怪谁审得不够认真”而是说明系统设计有问题。要做的是停止增加新代码先把过滤层加固再恢复流动。这套指标不需要做得特别精细只要能稳定暴露问题就行。团队每两周复盘一次对比数据变化比开一个“大家以后 review 认真点”的会有效得多。6. 长期价值从“审代码”到“建系统”6.1 AI 不会让工程师失业但会重新定义工程师的职责回到标题的问题AI 写代码人审不过来怎么办如果说这三五年有什么值得长期关注的趋势那就是工程师的职责正在从“实现功能”转向“判断什么是对的、什么可以信任、什么必须保护”。过去写代码是核心能力现在AI 已经能完成相当一部分编码工作真正稀缺的能力变成了定义清晰的规范和边界设计可验证、可回滚的架构建立自动化防线让机器先处理重复问题在高风险区域做出果断判断通过 review 和复盘持续改进 AI 生成代码的质量换句话说AI 不会让工程师失业但会让“只会写代码”的人感到吃力。未来最能拉开差距的不是谁敲键盘快而是谁能把一套复杂的生成、审查、发布系统运转起来。6.2 最小可落地的改进顺序如果你想改变团队现状不要一上来就上全套平台和工具。我建议按下面的顺序推进先量化一周数据记录 PR 数量、diff 行数、review 耗时、线上问题来源。没有数据就没有讨论基础。把 CI/Lint/测试门槛补上这是成本最低、收益最明显的一步。至少保证低质量 PR 不会占用人的注意力。引入 AI 辅助摘要让工具先总结 diff并标注可疑点人的工作从“读全文”变成“看摘要重点”。定义高风险清单先明确哪些模块必须人工重点审查哪些可以抽审。不要追求一步到位先从最核心的模块开始。每月复盘 AI 代码缺陷每次线上问题出现后区分是“AI 写错了”还是“人没有审出来”还是“流程没有覆盖到”。这会指导下一轮优化。这个顺序的核心逻辑是先减少人工需要看的内容再提高人工看重点的效率最后通过复盘反哺规则和工具。6.3 适用边界与不适用场景最后说清楚适用边界。这套“分层审查 AI 辅助 人工聚焦风险”的方法适合大多数互联网业务开发、企业内部系统、工具类软件和测试代码。它能有效缓解 AI 代码激增带来的 review 压力。但不是所有场景都适用。如果你的系统属于金融核心交易、医疗设备、自动驾驶、生产控制系统这类对审计追踪有严格合规要求的领域那就不能简单用“抽审”替代“全量强制审查”。这类系统通常需要满足行业监管要求保留完整审查记录并且由具备资质的工程师进行签字确认。AI 可以辅助发现线索但不能成为最终放行的唯一依据。另外如果团队自动化测试覆盖非常薄弱也没有快速回滚能力那“低风险事后审”的策略要谨慎使用。自动化的防线越弱人工审查的兜底责任就越重。这二者是互相补充的关系不是一个省心一个费心。长期看真正有效的不是“把 AI 生成的每一行代码都看完”而是建立一个体系让它用机器挡住低级错误用 AI 帮忙发现可疑点让人只盯最值得盯的地方。我见过很多团队在 AI 编码工具上投入很多却忽略了 review 流程的重新设计最后被淹没在 PR 队列里。其实优化方向不在“写得更多更快”而在“生成之后如何减少人类的认知负担”。下次打开 PR 列表时你可能会发现自己不再焦虑于所有代码看不完。你会先问一句哪些地方出了问题我承担不起然后把有限的注意力放在那里。这不是妥协而是新的工程能力。