先说一个最近的感受AI 写代码的速度已经远远超过人类 review 的速度了。以前一天合并 5 个 PR团队两个人轮流看勉强撑得住。现在引入 AI 编程工具之后一个人一天能产出十几个 PR有些甚至逻辑完整、代码规范、注释齐全看起来完全像是老手写的。可问题是——你根本看不完也不敢不看。这不是某一个人遇到的麻烦而是整个开发团队在向 AI 辅助开发切换时必然撞上的一堵墙。代码量爆炸式增长而代码审查Code Review依然依赖人肉带宽。继续用“每个 PR 都人肉过一遍”的老办法流程会直接卡死但如果放弃审查、无脑信任 AI线上出问题的时候锅根本分不清楚是谁的。这篇文章我想拆解一下当 AI 负责写代码人类已经无法逐行审查全部内容时团队该用什么方法重建质量防线。会涉及 AI 生成代码的风险特点、分层审查策略、自动化辅助工具包括 Open Code Review、Claude Code 等的使用思路以及一批能直接落地的工程建议。我还会把常见的“review 积压”“API Key 报错”“AI 代码不听话”等问题单独列一节方便你对照排查。这个主题适合正在使用或准备引入 AI 编程工具的后端、前端和测试同学也适合需要制定团队研发规范的 Tech Lead 和技术管理者。1. AI 时代代码审查为什么突然变成了瓶颈1.1 代码审查是干什么的代码审查Code Review指的是在代码合并到主干分支之前由其他开发者对代码进行系统检查的过程。它至少覆盖四个目标发现缺陷包括逻辑错误、边界条件遗漏、并发问题等。保证规范让代码符合团队约定的命名、分层、异常处理方式。传递知识审查人通过了解新代码保持对系统的全局认知。控制风险避免未经确认的改动进入生产环境。在没有 AI 辅助的时候这套流程虽然慢但它能工作。因为人类的“代码生产速度”本身就是有限的审查端和产出端之间基本能维持一种动态平衡。1.2 AI 编程工具把这种平衡打破了以 Claude Code、Cursor、GitHub Copilot 为代表的 AI 编程工具正在大幅压缩从想法到代码的时间。过去要写一天的接口现在把需求描述清楚AI 几分钟就能生成骨架。这就带来一个非常现实的变化代码提交量变多了。单个 PR 体积变大了。PR 之间的质量差异也变大了。而审查人的时间和精力并没有增加。于是你会看到团队里出现这种状态代码仓库里到处是waiting for review状态的 PR审查人的待办列表越来越长开发者抱怨“代码写完三天还没人看”质量负责人则焦虑“这堆 AI 代码到底有没有问题”。1.3 核心矛盾数量膨胀与带宽瓶颈如果把这个矛盾说得更直白一点就是AI 的代码产出速度接近无限。人的审查带宽是固定且有限的。两者之间的缺口正在指数级扩大。这意味着我们必须承认一个前提“所有代码都人肉审查”已经不再可能了。不管是大型团队还是小团队只要 AI 参与开发的比重足够高就一定有一部分代码在“低人工介入”的情况下合入。我们需要做的不是假装这一情况不存在而是想办法让“低人工介入”的部分足够安全。2. AI 生成代码的典型风险为什么不能闭眼合入很多人觉得 AI 生成的代码“看起来挺完整”所以直接合入也没什么问题。但如果你真的把 AI 代码当作“资深工程师写的代码”那就高估它了。AI 生成代码的问题集中在下面几类。2.1 幻觉 API 与不存在的依赖这是最典型的问题。AI 在生成代码时经常“创造”出一些并不存在的函数名、配置项或者第三方包。如果你不仔细核对官方文档这些代码甚至能通过编译器的部分检查直到运行到那一步才报错。例如from some_unknown_library import helper result helper.process_data()这段代码在编辑器里看起来很正常但如果some_unknown_library并不存在或者process_data根本不是那个库的函数运行时就全会挂掉。人工审查的一个核心任务就是核对这类“凭空产生”的依赖。2.2 边界条件与异常处理缺失AI 非常擅长写“正常路径”的代码但面对空值、极端输入、并发竞争、网络超时这些边界场景时经常偷工减料。public String getUserName(Long userId) { return userRepository.findById(userId).get().getName(); }这段代码在用户存在时没问题。但一旦findById返回空.get()就会抛出NoSuchElementException。AI 生成的业务代码里这种“主流程通畅、边界裸奔”的情况很常见。2.3 安全隐患AI 模型学习过海量公开代码而公开代码里有大量不安全写法。比如 SQL 拼接、弱加密算法、硬编码密钥、缺少权限校验等。相比人类开发者AI 更倾向于生成“看起来能跑”的代码而不是“经过安全设计”的代码。query SELECT * FROM users WHERE name name cursor.execute(query)这种代码如果合入并且暴露在公网接口中基本等于白送一个注入漏洞。2.4 业务语义不符合预期这是最隐蔽的问题。AI 并不能真正理解你的业务上下文。你以为它“知道”订单金额必须保留两位小数它可能在某个分支直接做了浮点运算你以为它“知道”这个接口需要做幂等它很可能直接忽略了。所以代码审查不是因为“AI 不行”才需要而是因为审查本身是质量闭环中不可缺失的一环。问题只在于我们怎么把这环做得更聪明。3. 围绕 AI 代码重建审查链路工具与环境准备既然人肉审查跟不上那么第一反应应该是用工具把一部分审查工作自动化。现在的生态里已经有不少能用的方案我把最常用的环境准备流程列出来。3.1 AI 编程工具Claude CodeClaude Code 是 Anthropic 推出的命令行 AI 编程工具可以在终端里通过对话直接操作项目文件生成代码、修改代码、运行命令等。它的典型安装方式如下npm install -g anthropic-ai/claude-code安装完成后在项目目录执行claude就会进入交互式命令行你可以直接输入自然语言描述需求。需要特别说明的是这类工具迭代非常快具体的安装命令、环境变量、认证方式以官方文档最新版本为准。但我更想强调的是使用习惯不要把 AI 当成一个“答案机器”而是当成一个“结对编程的对象”。在让它写代码之前先定义清楚输入输出、边界条件和可接受的失败行为能显著降低后续审查压力。3.2 代码审查工具Open Code ReviewOpen Code Review 是一个偏“自动化代码审查”的辅助工具它能在开发者提交代码时自动拉取 diff并对代码风格、常见错误模式、潜在缺陷给出检查结果再把结果反馈到 IDE 或命令行中。如果你用的是 VS Code在扩展市场中搜索“Open Code Review”即可安装也可以在项目根目录用命令行触发审查。基本使用思路是把它作为“第一道审查层”在人工介入之前先完成机械性检查。不过要注意一个问题现在很多 AI 审查类工具都需要配置 API Key。如果你在本地运行 Open Code Review 或类似工具时遇到了这样的报错unexpected status 401 unauthorized: {code:api_key_required,message:api_key_required}这通常意味着工具没有读取到合法的 API Key。你需要检查环境变量是否正确设置比如OPENAI_API_KEY或对应的服务密钥。Key 是否过期或余额不足。工具的配置文件是否指向了正确的模型服务地址。这种报错和处理思路会在后面“常见问题”一节里再细讲。3.3 版本提醒根据我的经验AI 相关工具链的版本兼容问题是最大的隐形坑。操作系统、Node.js 版本、模型 API 版本、IDE 插件版本任何一个对上不都可能导致行为异常。所以本文的示例只给出通用思路不写死具体版本号。你在落地时请使用自己项目实际环境对应的版本并优先查看官方更新日志。4. 策略一建立 AI 代码的分层审查模型既然不可能对所有 AI 代码都做深度人工审查那就必须区分“哪些必须人肉细看”和“哪些可以放权给自动化”。我建议团队按下面的分层模型来设计流程。4.1 风险等级划分风险等级适用场景审查方式示例L1 低风险纯新增、无业务逻辑、不涉及资金与数据自动化检查 提交人自测新增测试用例、补充注释、重命名变量L2 中风险普通业务功能、有明确输入输出自动化检查 一位 reviewer新增查询接口、普通 CRUDL3 高风险涉及订单、支付、权限、用户数据、敏感信息、核心链路自动化检查 两位 reviewer 安全/架构确认支付回调、鉴权逻辑、数据迁移脚本这个分层不是拍脑袋而是基于一个朴素原则风险越高的改动越需要人类介入风险越低的改动越可以通过自动化放行。4.2 提交时的信息补充为了让分层的判断更准确可以要求开发者在 AI 生成代码之后、提交 PR 之前额外填写一段“AI 参与说明”。这个说明不是形式主义而是给审查人提供上下文。我建议的 PR 描述模板## 变更内容 一句话描述 ## AI 参与情况 - [ ] 全人工编写 - [ ] AI 辅助生成请填写生成工具和提示词 - [ ] AI 自动生成后人工修改 ## 风险自评 - [ ] 低风险无业务逻辑改动 - [ ] 中风险普通功能新增/修改 - [ ] 高风险涉及资金、权限、敏感数据 ## 自测情况 - [ ] 本地测试通过 - [ ] 已补充/更新单元测试 - [ ] 相关边界用例已覆盖有了这个信息reviewer 就可以快速判断投入多少精力。4.3 提交拆分建议AI 的生成能力强所以开发者很容易一次性提交一个大而全的 PR。但“大 PR 难看懂、难审查”是人尽皆知的道理。我建议在 AI 生成代码之后强制要求按功能拆分一个 PR 只解决一个问题。一个 PR 的 diff 行数尽量控制在 400 行以内视团队情况调整。如果超过阈值必须额外说明为什么无法拆分。很多团队反馈“waiting for review 堆积”其实不是 review 人数不够而是 PR 过于臃肿导致 reviewers 不愿意点开。小步提交能显著提高审查意愿和审查效率。5. 策略二用自动化工具构建“第一道审查层”人工审查永远不够用那第一步就是把重复性、机械性的审查交给工具。这部分我会讲几个能直接落地的办法。5.1 静态检查与规范检查这是最基础的一层也是完全不依赖 AI 的一层。比如Python 项目用ruff或flake8做代码风格和常见错误检查。Java 项目用Checkstyle和SpotBugs。JavaScript/TypeScript 项目用ESLint。这类工具的优点是确定性强、速度快、不依赖模型 API适合放在 CI 里作为强制门禁。AI 生成代码再快如果在这一层没过就不允许合入。5.2 AI 辅助审查让模型先读一遍 diff除了规则型工具我们还可以让大模型扮演“初级 reviewer”先读一遍 diff输出存在怀疑的点再由人类确认。这就是 Open Code Review 这类工具的用武之地。假设你已经配置好了 Open Code Review在项目里运行open-code-review --diff HEAD~1 --focus high-risk这条命令的逻辑是把最近一次提交的 diff 交给模型让模型优先关注高风险问题安全漏洞、边界条件、异常处理。模型可能输出类似下面的结果[LOW] 第 23 行变量名 user_name 与上下文命名风格不一致。 [MED] 第 41 行请求超时未设置极端网络环境下可能长时间阻塞。 [HIGH] 第 57 行在支付成功回调中直接信任了外部传入的用户 ID存在越权风险。需要注意的是AI 审查结果只能作为参考不能作为最终结论。因为模型本身也会误报、漏报。它最大的价值是把审查人的注意力导向“值得细看的位置”而不是替代人做决策。5.3 在 VS Code 中集成审查流程把 Open Code Review 装进 VS Code 之后开发者在写完代码的第一时间就能看到审查反馈而不是等到 CI 阶段才被拦住。这种“左移”的思路能大幅减少无效提交。在.vscode/settings.json中可以做类似配置{ openCodeReview.enableOnSave: true, openCodeReview.model: gpt-4o, openCodeReview.maxDiffLines: 500, openCodeReview.ignoredPaths: [dist, node_modules, build], openCodeReview.riskThreshold: medium }注意这只是示例配置真实字段名可能随工具版本变化。我建议你装上插件之后先打开官方文档确认当前版本的配置项。5.4 自动化门禁的优先级在 CI 流水线里自动化门禁应该按顺序执行避免浪费时间语法编译检查代码能不能跑起来。静态规则检查风格、复杂度、明显 bug 模式。单元测试核心函数是否有测试覆盖。AI 辅助审查生成审查报告但不阻塞合入。人工审查只处理自动化结果无法覆盖的部分。这样设计的好处是大部分低质量问题在 1-3 步被拦截AI 辅助审查帮助人缩小范围真正走到人面前的代码已经经过了层层过滤。6. 策略三从源头降低 AI 代码的审查成本审查做不完除了“看不过来”之外还有一个重要原因AI 生成的代码质量本身不够高。如果能让 AI 在生成阶段就产出更规范、更自解释、自带测试的代码审查压力会大幅下降。这一节我们从提示词工程和代码生成规范两个角度来聊。6.1 给 AI 写“带约束的提示词”很多人让 AI 写代码就一句话“帮我写个用户接口。” 这种开放式提示词等于把质量控制的全部责任都甩给了审查者。更好的做法是在提示词里明确约束。我提供一份可复制的提示词模板你可以根据自己的项目修改请实现以下功能并严格遵守约束 【需求】 实现一个用户注册接口接收用户名、密码、邮箱返回注册状态。 【约束】 1. 使用 Python FastAPI 风格。 2. 密码必须使用 bcrypt 哈希存储禁止明文。 3. 用户名长度 3-20 个字符邮箱格式必须校验。 4. 所有异常必须捕获并返回统一的 JSON 错误格式。 5. 必须包含异常处理不允许出现未捕获的运行时异常。 6. 请为关键逻辑编写单元测试。 7. 请在代码注释中标注可能存在的边界条件。 【输出格式】 先列出接口设计再给出代码最后补充测试用例与潜在风险点。同样一个需求提示词越具体AI 产出的代码质量就越高后续审查需要付出的劳动就越少。6.2 要求 AI 自带测试这是我觉得最有效的一招。让 AI 生成代码的同时必须生成对应的单元测试。这样reviewer 在看代码的时候可以同时看到“作者声明的行为”再对照代码判断是否一致。示例提示词写完 register_user 函数之后请补充 pytest 测试覆盖 1. 正常注册成功 2. 用户名过短 3. 邮箱格式错误 4. 重复用户名注册 5. 数据库异常时的错误返回有了测试合入门禁就能自动判断“代码是否符合声明的行为”人类只需要检查“声明的行为是否正确”。6.3 在代码审查时使用 AI 辅助核对清单除了让 AI 写代码我们还可以让 AI 在审查阶段帮忙做“清单核对”。比如把团队的质量规范输出给模型让模型逐条比对 diff你是一名资深代码审查员。请根据下面的审查清单检查这段代码并逐条输出“通过/不通过/需要确认”。 【审查清单】 1. 没有 SQL 拼接。 2. 所有外部输入都经过参数校验。 3. 所有资源都正确关闭。 4. 错误信息不泄露内部堆栈。 5. 关键业务代码有测试覆盖。 6. 没有硬编码的密钥和 URL。这种方法能让 AI 审查的结果更结构化也更容易被人工确认。6.4 反思为什么不能完全依赖 AI 审查 AI这里必须说一句泼冷水的话AI 审查 AI 是辅助手段不是终极解药。原因很现实生成代码的模型和审查代码的模型可能拥有相同的盲区。如果训练数据里本身就有漏洞模式两者可能都识别不出来。模型对业务语义的理解是概率性的不是确定性的。安全性问题讲究“未知的未知”模型天然不擅长。所以AI 审查代码的真正定位是把人工审查从“逐行阅读”变成“抽查关键点”从“大海捞针”变成“坐标定位”。最终的质量责任人仍然是人。7. 常见问题与排查思路下面把我在实践中遇到的高频问题整理成一个表格方便你对照处理。问题现象常见原因解决思路waiting for review的 PR 持续积压提交粒度过大单个 PR 改动量太多强制拆分 PR限制单次 diff 行数设置 review SLA审查者不知从何看起AI 代码没有上下文说明要求 PR 描述填写“AI 参与说明”和“风险自评”使用 AI 审查工具时报401 unauthorized未配置或配置错误的 API Key检查环境变量、配置文件、密钥是否有效AI 生成的测试用例全通过但代码仍有 bug测试只覆盖“AI 自己写的逻辑”与真实需求不一致人工补充关键业务场景测试不盲目信任 AI 生成的测试同一个 AI 生成的代码风格混乱没有在提示词中限定规范在项目根目录加入.ai-coding-rules或直接在提示词中引用团队规范开发者抱怨审查太慢缺少自动化辅助人工逐行看完全部 diff引入规则检查 AI 辅助审查让 AI 先过滤一遍个别开发者直接跳过审查合入流程约束不够在 Git 服务端开启分支保护强制 PR 审查以下挑两个典型场景展开说明。7.1 场景一waiting for review积压严重如果你们的 PR 列表里长期挂着大量waiting for review首先要做的不是增加审查人而是分析积压的原因。我建议按这个顺序排查单个 PR 是否有巨大的 diff如果是先做提交拆分。审查人是否明确如果 PR 没有指定 reviewer大家会默认“别人会看”结果没人看。有没有自动化门禁如果 lint 和测试能拦截大部分低级错误reviewer 看见的 PR 会清爽很多愿意看的概率也更高。有没有 SLA建议给不同风险等级设置不同的响应时限比如 L1 24 小时内、L2 12 小时内、L3 4 小时内。7.2 场景二AI 审查工具报401 unauthorized这个报错在配置过 AI 审查工具的同学那里非常常见。完整报错一般是unexpected status 401 unauthorized: {code:api_key_required,message:api_key_required}从字面意思来看就是服务端认为你请求时没有携带合法身份信息。排查顺序建议是找到工具读取 API Key 的配置位置一般是通过环境变量读取。检查环境变量是否设置并且echo确认没有包含特殊字符。检查 API Key 是否过期可以在官方接口做一次手动请求验证。如果是本地开发环境重启终端让环境变量生效。配置好之后再运行一次审查命令如果还是 401大概率就是 Key 的问题而不是代码的问题。8. 最佳实践与工程建议走到这里你应该已经理解了问题本身和几种应对方案。最后我把更细的工程建议整理成一套可以直接落地的检查清单方便你带回团队讨论。8.1 为团队定义“AI 代码可合入标准”光说“谨慎审查”没用必须有明确的合入标准。我建议团队至少固定以下几条所有 AI 生成的代码必须通过 lint、测试和编译三件套。凡是高风险操作支付、权限、数据删除、密钥处理必须有至少一位人类 reviewer 明确确认。AI 审查工具的结论只能作为参考必须有人类确认的“最终 review 结论”。AI 生成的测试用例必须至少有人类补充一个关键业务场景用例。任何“AI 说不清为什么这样写”的代码必须人工介入。8.2 把质量规范沉淀成 AI 可读的文件AI 的质量表现取决于你给它的上下文。如果你的团队有编码规范别把它锁在 Confluence 里而是做成 AI 能读取的文件例如.ai-coding-rules或CODING_GUIDE.md然后在提示词中引用请先阅读项目根目录下的 CODING_GUIDE.md然后严格按照其中的规范实现以下需求。这样做的好处是AI 生成的代码会更贴近团队风格审查的人就不会一边看逻辑一边吐槽格式。8.3 量化审查数据持续改进我强烈建议团队定期看一组数据每日新增 PR 数量。平均每个 PR 的 diff 行数。平均 review 响应时间。自动化门禁拦截率。AI 代码占比。线上问题中属于“AI 生成且未经仔细人工审查”的比例。这些数据能帮你判断你的审查策略是不是真的有效还是只是在“看起来忙”。8.4 注意安全与合规边界最后说一个容易被忽略的点AI 生成代码进入生产环境不只是技术问题还涉及安全和合规。涉及用户个人信息、支付信息、敏感业务数据的代码必须经过更严格的审查。不要把内部代码直接交给第三方 AI 服务审查除非你确认数据合规性。在本地运行 AI 编程工具时注意是否会上传代码片段。如果团队有保密要求必须选择合规的部署方案。生产环境的任何变更都要有回滚预案和备份机制AI 写的代码也不例外。9. 总结写到这里再用一句话概括这次想聊的核心AI 写代码这件事已经不可逆了但工程质量不能崩。我们不能用“逐行人肉审查”去对抗“AI 无限生成”而是要用分层策略、自动化工具和更好的提示词工程把人类审查重新放回关键位置。我自己在实际项目里最受益的一条经验是把 AI 当成一个“产出量很大的初级工程师”而不是“不会犯错的高级工程师”。你会给它设边界、会检查它的关键产出、会把高风险任务交给更有经验的同事复核。AI 代码审查也一样——它不是一个新问题而是把老问题放大之后逼我们想出新解法。如果你所在的团队正在经历 AI 代码增长速度快、审查跟不上的阶段我建议先不要追求“完美方案”而是从一个小改进开始强制拆分 PR、给 AI 代码打标签、设置自动化门禁。这三件事做完了再谈要不要引入更复杂的 AI 审查工具。希望这篇分享能给你带来一些可落地的思路。如果你有更好的方案也欢迎在评论区交流。 AI时代代码审查突围：从人肉逐行到分层自动化
先说一个最近的感受AI 写代码的速度已经远远超过人类 review 的速度了。以前一天合并 5 个 PR团队两个人轮流看勉强撑得住。现在引入 AI 编程工具之后一个人一天能产出十几个 PR有些甚至逻辑完整、代码规范、注释齐全看起来完全像是老手写的。可问题是——你根本看不完也不敢不看。这不是某一个人遇到的麻烦而是整个开发团队在向 AI 辅助开发切换时必然撞上的一堵墙。代码量爆炸式增长而代码审查Code Review依然依赖人肉带宽。继续用“每个 PR 都人肉过一遍”的老办法流程会直接卡死但如果放弃审查、无脑信任 AI线上出问题的时候锅根本分不清楚是谁的。这篇文章我想拆解一下当 AI 负责写代码人类已经无法逐行审查全部内容时团队该用什么方法重建质量防线。会涉及 AI 生成代码的风险特点、分层审查策略、自动化辅助工具包括 Open Code Review、Claude Code 等的使用思路以及一批能直接落地的工程建议。我还会把常见的“review 积压”“API Key 报错”“AI 代码不听话”等问题单独列一节方便你对照排查。这个主题适合正在使用或准备引入 AI 编程工具的后端、前端和测试同学也适合需要制定团队研发规范的 Tech Lead 和技术管理者。1. AI 时代代码审查为什么突然变成了瓶颈1.1 代码审查是干什么的代码审查Code Review指的是在代码合并到主干分支之前由其他开发者对代码进行系统检查的过程。它至少覆盖四个目标发现缺陷包括逻辑错误、边界条件遗漏、并发问题等。保证规范让代码符合团队约定的命名、分层、异常处理方式。传递知识审查人通过了解新代码保持对系统的全局认知。控制风险避免未经确认的改动进入生产环境。在没有 AI 辅助的时候这套流程虽然慢但它能工作。因为人类的“代码生产速度”本身就是有限的审查端和产出端之间基本能维持一种动态平衡。1.2 AI 编程工具把这种平衡打破了以 Claude Code、Cursor、GitHub Copilot 为代表的 AI 编程工具正在大幅压缩从想法到代码的时间。过去要写一天的接口现在把需求描述清楚AI 几分钟就能生成骨架。这就带来一个非常现实的变化代码提交量变多了。单个 PR 体积变大了。PR 之间的质量差异也变大了。而审查人的时间和精力并没有增加。于是你会看到团队里出现这种状态代码仓库里到处是waiting for review状态的 PR审查人的待办列表越来越长开发者抱怨“代码写完三天还没人看”质量负责人则焦虑“这堆 AI 代码到底有没有问题”。1.3 核心矛盾数量膨胀与带宽瓶颈如果把这个矛盾说得更直白一点就是AI 的代码产出速度接近无限。人的审查带宽是固定且有限的。两者之间的缺口正在指数级扩大。这意味着我们必须承认一个前提“所有代码都人肉审查”已经不再可能了。不管是大型团队还是小团队只要 AI 参与开发的比重足够高就一定有一部分代码在“低人工介入”的情况下合入。我们需要做的不是假装这一情况不存在而是想办法让“低人工介入”的部分足够安全。2. AI 生成代码的典型风险为什么不能闭眼合入很多人觉得 AI 生成的代码“看起来挺完整”所以直接合入也没什么问题。但如果你真的把 AI 代码当作“资深工程师写的代码”那就高估它了。AI 生成代码的问题集中在下面几类。2.1 幻觉 API 与不存在的依赖这是最典型的问题。AI 在生成代码时经常“创造”出一些并不存在的函数名、配置项或者第三方包。如果你不仔细核对官方文档这些代码甚至能通过编译器的部分检查直到运行到那一步才报错。例如from some_unknown_library import helper result helper.process_data()这段代码在编辑器里看起来很正常但如果some_unknown_library并不存在或者process_data根本不是那个库的函数运行时就全会挂掉。人工审查的一个核心任务就是核对这类“凭空产生”的依赖。2.2 边界条件与异常处理缺失AI 非常擅长写“正常路径”的代码但面对空值、极端输入、并发竞争、网络超时这些边界场景时经常偷工减料。public String getUserName(Long userId) { return userRepository.findById(userId).get().getName(); }这段代码在用户存在时没问题。但一旦findById返回空.get()就会抛出NoSuchElementException。AI 生成的业务代码里这种“主流程通畅、边界裸奔”的情况很常见。2.3 安全隐患AI 模型学习过海量公开代码而公开代码里有大量不安全写法。比如 SQL 拼接、弱加密算法、硬编码密钥、缺少权限校验等。相比人类开发者AI 更倾向于生成“看起来能跑”的代码而不是“经过安全设计”的代码。query SELECT * FROM users WHERE name name cursor.execute(query)这种代码如果合入并且暴露在公网接口中基本等于白送一个注入漏洞。2.4 业务语义不符合预期这是最隐蔽的问题。AI 并不能真正理解你的业务上下文。你以为它“知道”订单金额必须保留两位小数它可能在某个分支直接做了浮点运算你以为它“知道”这个接口需要做幂等它很可能直接忽略了。所以代码审查不是因为“AI 不行”才需要而是因为审查本身是质量闭环中不可缺失的一环。问题只在于我们怎么把这环做得更聪明。3. 围绕 AI 代码重建审查链路工具与环境准备既然人肉审查跟不上那么第一反应应该是用工具把一部分审查工作自动化。现在的生态里已经有不少能用的方案我把最常用的环境准备流程列出来。3.1 AI 编程工具Claude CodeClaude Code 是 Anthropic 推出的命令行 AI 编程工具可以在终端里通过对话直接操作项目文件生成代码、修改代码、运行命令等。它的典型安装方式如下npm install -g anthropic-ai/claude-code安装完成后在项目目录执行claude就会进入交互式命令行你可以直接输入自然语言描述需求。需要特别说明的是这类工具迭代非常快具体的安装命令、环境变量、认证方式以官方文档最新版本为准。但我更想强调的是使用习惯不要把 AI 当成一个“答案机器”而是当成一个“结对编程的对象”。在让它写代码之前先定义清楚输入输出、边界条件和可接受的失败行为能显著降低后续审查压力。3.2 代码审查工具Open Code ReviewOpen Code Review 是一个偏“自动化代码审查”的辅助工具它能在开发者提交代码时自动拉取 diff并对代码风格、常见错误模式、潜在缺陷给出检查结果再把结果反馈到 IDE 或命令行中。如果你用的是 VS Code在扩展市场中搜索“Open Code Review”即可安装也可以在项目根目录用命令行触发审查。基本使用思路是把它作为“第一道审查层”在人工介入之前先完成机械性检查。不过要注意一个问题现在很多 AI 审查类工具都需要配置 API Key。如果你在本地运行 Open Code Review 或类似工具时遇到了这样的报错unexpected status 401 unauthorized: {code:api_key_required,message:api_key_required}这通常意味着工具没有读取到合法的 API Key。你需要检查环境变量是否正确设置比如OPENAI_API_KEY或对应的服务密钥。Key 是否过期或余额不足。工具的配置文件是否指向了正确的模型服务地址。这种报错和处理思路会在后面“常见问题”一节里再细讲。3.3 版本提醒根据我的经验AI 相关工具链的版本兼容问题是最大的隐形坑。操作系统、Node.js 版本、模型 API 版本、IDE 插件版本任何一个对上不都可能导致行为异常。所以本文的示例只给出通用思路不写死具体版本号。你在落地时请使用自己项目实际环境对应的版本并优先查看官方更新日志。4. 策略一建立 AI 代码的分层审查模型既然不可能对所有 AI 代码都做深度人工审查那就必须区分“哪些必须人肉细看”和“哪些可以放权给自动化”。我建议团队按下面的分层模型来设计流程。4.1 风险等级划分风险等级适用场景审查方式示例L1 低风险纯新增、无业务逻辑、不涉及资金与数据自动化检查 提交人自测新增测试用例、补充注释、重命名变量L2 中风险普通业务功能、有明确输入输出自动化检查 一位 reviewer新增查询接口、普通 CRUDL3 高风险涉及订单、支付、权限、用户数据、敏感信息、核心链路自动化检查 两位 reviewer 安全/架构确认支付回调、鉴权逻辑、数据迁移脚本这个分层不是拍脑袋而是基于一个朴素原则风险越高的改动越需要人类介入风险越低的改动越可以通过自动化放行。4.2 提交时的信息补充为了让分层的判断更准确可以要求开发者在 AI 生成代码之后、提交 PR 之前额外填写一段“AI 参与说明”。这个说明不是形式主义而是给审查人提供上下文。我建议的 PR 描述模板## 变更内容 一句话描述 ## AI 参与情况 - [ ] 全人工编写 - [ ] AI 辅助生成请填写生成工具和提示词 - [ ] AI 自动生成后人工修改 ## 风险自评 - [ ] 低风险无业务逻辑改动 - [ ] 中风险普通功能新增/修改 - [ ] 高风险涉及资金、权限、敏感数据 ## 自测情况 - [ ] 本地测试通过 - [ ] 已补充/更新单元测试 - [ ] 相关边界用例已覆盖有了这个信息reviewer 就可以快速判断投入多少精力。4.3 提交拆分建议AI 的生成能力强所以开发者很容易一次性提交一个大而全的 PR。但“大 PR 难看懂、难审查”是人尽皆知的道理。我建议在 AI 生成代码之后强制要求按功能拆分一个 PR 只解决一个问题。一个 PR 的 diff 行数尽量控制在 400 行以内视团队情况调整。如果超过阈值必须额外说明为什么无法拆分。很多团队反馈“waiting for review 堆积”其实不是 review 人数不够而是 PR 过于臃肿导致 reviewers 不愿意点开。小步提交能显著提高审查意愿和审查效率。5. 策略二用自动化工具构建“第一道审查层”人工审查永远不够用那第一步就是把重复性、机械性的审查交给工具。这部分我会讲几个能直接落地的办法。5.1 静态检查与规范检查这是最基础的一层也是完全不依赖 AI 的一层。比如Python 项目用ruff或flake8做代码风格和常见错误检查。Java 项目用Checkstyle和SpotBugs。JavaScript/TypeScript 项目用ESLint。这类工具的优点是确定性强、速度快、不依赖模型 API适合放在 CI 里作为强制门禁。AI 生成代码再快如果在这一层没过就不允许合入。5.2 AI 辅助审查让模型先读一遍 diff除了规则型工具我们还可以让大模型扮演“初级 reviewer”先读一遍 diff输出存在怀疑的点再由人类确认。这就是 Open Code Review 这类工具的用武之地。假设你已经配置好了 Open Code Review在项目里运行open-code-review --diff HEAD~1 --focus high-risk这条命令的逻辑是把最近一次提交的 diff 交给模型让模型优先关注高风险问题安全漏洞、边界条件、异常处理。模型可能输出类似下面的结果[LOW] 第 23 行变量名 user_name 与上下文命名风格不一致。 [MED] 第 41 行请求超时未设置极端网络环境下可能长时间阻塞。 [HIGH] 第 57 行在支付成功回调中直接信任了外部传入的用户 ID存在越权风险。需要注意的是AI 审查结果只能作为参考不能作为最终结论。因为模型本身也会误报、漏报。它最大的价值是把审查人的注意力导向“值得细看的位置”而不是替代人做决策。5.3 在 VS Code 中集成审查流程把 Open Code Review 装进 VS Code 之后开发者在写完代码的第一时间就能看到审查反馈而不是等到 CI 阶段才被拦住。这种“左移”的思路能大幅减少无效提交。在.vscode/settings.json中可以做类似配置{ openCodeReview.enableOnSave: true, openCodeReview.model: gpt-4o, openCodeReview.maxDiffLines: 500, openCodeReview.ignoredPaths: [dist, node_modules, build], openCodeReview.riskThreshold: medium }注意这只是示例配置真实字段名可能随工具版本变化。我建议你装上插件之后先打开官方文档确认当前版本的配置项。5.4 自动化门禁的优先级在 CI 流水线里自动化门禁应该按顺序执行避免浪费时间语法编译检查代码能不能跑起来。静态规则检查风格、复杂度、明显 bug 模式。单元测试核心函数是否有测试覆盖。AI 辅助审查生成审查报告但不阻塞合入。人工审查只处理自动化结果无法覆盖的部分。这样设计的好处是大部分低质量问题在 1-3 步被拦截AI 辅助审查帮助人缩小范围真正走到人面前的代码已经经过了层层过滤。6. 策略三从源头降低 AI 代码的审查成本审查做不完除了“看不过来”之外还有一个重要原因AI 生成的代码质量本身不够高。如果能让 AI 在生成阶段就产出更规范、更自解释、自带测试的代码审查压力会大幅下降。这一节我们从提示词工程和代码生成规范两个角度来聊。6.1 给 AI 写“带约束的提示词”很多人让 AI 写代码就一句话“帮我写个用户接口。” 这种开放式提示词等于把质量控制的全部责任都甩给了审查者。更好的做法是在提示词里明确约束。我提供一份可复制的提示词模板你可以根据自己的项目修改请实现以下功能并严格遵守约束 【需求】 实现一个用户注册接口接收用户名、密码、邮箱返回注册状态。 【约束】 1. 使用 Python FastAPI 风格。 2. 密码必须使用 bcrypt 哈希存储禁止明文。 3. 用户名长度 3-20 个字符邮箱格式必须校验。 4. 所有异常必须捕获并返回统一的 JSON 错误格式。 5. 必须包含异常处理不允许出现未捕获的运行时异常。 6. 请为关键逻辑编写单元测试。 7. 请在代码注释中标注可能存在的边界条件。 【输出格式】 先列出接口设计再给出代码最后补充测试用例与潜在风险点。同样一个需求提示词越具体AI 产出的代码质量就越高后续审查需要付出的劳动就越少。6.2 要求 AI 自带测试这是我觉得最有效的一招。让 AI 生成代码的同时必须生成对应的单元测试。这样reviewer 在看代码的时候可以同时看到“作者声明的行为”再对照代码判断是否一致。示例提示词写完 register_user 函数之后请补充 pytest 测试覆盖 1. 正常注册成功 2. 用户名过短 3. 邮箱格式错误 4. 重复用户名注册 5. 数据库异常时的错误返回有了测试合入门禁就能自动判断“代码是否符合声明的行为”人类只需要检查“声明的行为是否正确”。6.3 在代码审查时使用 AI 辅助核对清单除了让 AI 写代码我们还可以让 AI 在审查阶段帮忙做“清单核对”。比如把团队的质量规范输出给模型让模型逐条比对 diff你是一名资深代码审查员。请根据下面的审查清单检查这段代码并逐条输出“通过/不通过/需要确认”。 【审查清单】 1. 没有 SQL 拼接。 2. 所有外部输入都经过参数校验。 3. 所有资源都正确关闭。 4. 错误信息不泄露内部堆栈。 5. 关键业务代码有测试覆盖。 6. 没有硬编码的密钥和 URL。这种方法能让 AI 审查的结果更结构化也更容易被人工确认。6.4 反思为什么不能完全依赖 AI 审查 AI这里必须说一句泼冷水的话AI 审查 AI 是辅助手段不是终极解药。原因很现实生成代码的模型和审查代码的模型可能拥有相同的盲区。如果训练数据里本身就有漏洞模式两者可能都识别不出来。模型对业务语义的理解是概率性的不是确定性的。安全性问题讲究“未知的未知”模型天然不擅长。所以AI 审查代码的真正定位是把人工审查从“逐行阅读”变成“抽查关键点”从“大海捞针”变成“坐标定位”。最终的质量责任人仍然是人。7. 常见问题与排查思路下面把我在实践中遇到的高频问题整理成一个表格方便你对照处理。问题现象常见原因解决思路waiting for review的 PR 持续积压提交粒度过大单个 PR 改动量太多强制拆分 PR限制单次 diff 行数设置 review SLA审查者不知从何看起AI 代码没有上下文说明要求 PR 描述填写“AI 参与说明”和“风险自评”使用 AI 审查工具时报401 unauthorized未配置或配置错误的 API Key检查环境变量、配置文件、密钥是否有效AI 生成的测试用例全通过但代码仍有 bug测试只覆盖“AI 自己写的逻辑”与真实需求不一致人工补充关键业务场景测试不盲目信任 AI 生成的测试同一个 AI 生成的代码风格混乱没有在提示词中限定规范在项目根目录加入.ai-coding-rules或直接在提示词中引用团队规范开发者抱怨审查太慢缺少自动化辅助人工逐行看完全部 diff引入规则检查 AI 辅助审查让 AI 先过滤一遍个别开发者直接跳过审查合入流程约束不够在 Git 服务端开启分支保护强制 PR 审查以下挑两个典型场景展开说明。7.1 场景一waiting for review积压严重如果你们的 PR 列表里长期挂着大量waiting for review首先要做的不是增加审查人而是分析积压的原因。我建议按这个顺序排查单个 PR 是否有巨大的 diff如果是先做提交拆分。审查人是否明确如果 PR 没有指定 reviewer大家会默认“别人会看”结果没人看。有没有自动化门禁如果 lint 和测试能拦截大部分低级错误reviewer 看见的 PR 会清爽很多愿意看的概率也更高。有没有 SLA建议给不同风险等级设置不同的响应时限比如 L1 24 小时内、L2 12 小时内、L3 4 小时内。7.2 场景二AI 审查工具报401 unauthorized这个报错在配置过 AI 审查工具的同学那里非常常见。完整报错一般是unexpected status 401 unauthorized: {code:api_key_required,message:api_key_required}从字面意思来看就是服务端认为你请求时没有携带合法身份信息。排查顺序建议是找到工具读取 API Key 的配置位置一般是通过环境变量读取。检查环境变量是否设置并且echo确认没有包含特殊字符。检查 API Key 是否过期可以在官方接口做一次手动请求验证。如果是本地开发环境重启终端让环境变量生效。配置好之后再运行一次审查命令如果还是 401大概率就是 Key 的问题而不是代码的问题。8. 最佳实践与工程建议走到这里你应该已经理解了问题本身和几种应对方案。最后我把更细的工程建议整理成一套可以直接落地的检查清单方便你带回团队讨论。8.1 为团队定义“AI 代码可合入标准”光说“谨慎审查”没用必须有明确的合入标准。我建议团队至少固定以下几条所有 AI 生成的代码必须通过 lint、测试和编译三件套。凡是高风险操作支付、权限、数据删除、密钥处理必须有至少一位人类 reviewer 明确确认。AI 审查工具的结论只能作为参考必须有人类确认的“最终 review 结论”。AI 生成的测试用例必须至少有人类补充一个关键业务场景用例。任何“AI 说不清为什么这样写”的代码必须人工介入。8.2 把质量规范沉淀成 AI 可读的文件AI 的质量表现取决于你给它的上下文。如果你的团队有编码规范别把它锁在 Confluence 里而是做成 AI 能读取的文件例如.ai-coding-rules或CODING_GUIDE.md然后在提示词中引用请先阅读项目根目录下的 CODING_GUIDE.md然后严格按照其中的规范实现以下需求。这样做的好处是AI 生成的代码会更贴近团队风格审查的人就不会一边看逻辑一边吐槽格式。8.3 量化审查数据持续改进我强烈建议团队定期看一组数据每日新增 PR 数量。平均每个 PR 的 diff 行数。平均 review 响应时间。自动化门禁拦截率。AI 代码占比。线上问题中属于“AI 生成且未经仔细人工审查”的比例。这些数据能帮你判断你的审查策略是不是真的有效还是只是在“看起来忙”。8.4 注意安全与合规边界最后说一个容易被忽略的点AI 生成代码进入生产环境不只是技术问题还涉及安全和合规。涉及用户个人信息、支付信息、敏感业务数据的代码必须经过更严格的审查。不要把内部代码直接交给第三方 AI 服务审查除非你确认数据合规性。在本地运行 AI 编程工具时注意是否会上传代码片段。如果团队有保密要求必须选择合规的部署方案。生产环境的任何变更都要有回滚预案和备份机制AI 写的代码也不例外。9. 总结写到这里再用一句话概括这次想聊的核心AI 写代码这件事已经不可逆了但工程质量不能崩。我们不能用“逐行人肉审查”去对抗“AI 无限生成”而是要用分层策略、自动化工具和更好的提示词工程把人类审查重新放回关键位置。我自己在实际项目里最受益的一条经验是把 AI 当成一个“产出量很大的初级工程师”而不是“不会犯错的高级工程师”。你会给它设边界、会检查它的关键产出、会把高风险任务交给更有经验的同事复核。AI 代码审查也一样——它不是一个新问题而是把老问题放大之后逼我们想出新解法。如果你所在的团队正在经历 AI 代码增长速度快、审查跟不上的阶段我建议先不要追求“完美方案”而是从一个小改进开始强制拆分 PR、给 AI 代码打标签、设置自动化门禁。这三件事做完了再谈要不要引入更复杂的 AI 审查工具。希望这篇分享能给你带来一些可落地的思路。如果你有更好的方案也欢迎在评论区交流。