AI代码审查规范：AI可以写代码，但不能批准合并

一套AI代码审查规范，首先要为团队划出一条不可妥协的底线：AI可以写代码、查代码，但合并责任必须落到一位具名负责人身上。凡是AI参与的改动，都应说明AI如何介入，通过结果可复现的检查，并按潜在损害程度接受相应级别的人工审查。

现在尤其需要明确这条边界。2026年8月17日，Wiz披露了GitHub Actions中的一个严重注入漏洞，漏洞位于Snowflake的一个公开仓库。最终的squash commit将Copilot Autofix列为共同作者，GitHub的AI辅助安全审查也判定该变更没有问题。Wiz特别说明，目前无法确定这次代码改动本身是否由AI辅助完成。漏洞上线5天后，一个自主安全智能体在授权测试中发现并利用了它。

成本账解释了团队为何仍然需要自动化。假设每周处理50个拉取请求，人工初审每个用时30分钟，团队就要投入25个工程师小时。若按每小时$120的示例综合成本计算，在深入审查之前，每周已经要花$3,000。GitHub目前估算，使用Lite强度完成一次Copilot审查会消耗$0.05到$1的AI credits，Balanced强度则为$0.25到$5，此外还需计入GitHub Actions运行分钟数。第一轮筛查正在变得便宜，但批准权限绝不能因此廉价下放。

AI代码审查规范究竟管什么？

好的规范是代码流转的交通规则，而不是AI禁令。它告诉作者必须披露什么，告诉自动化流程应拦住什么，也明确何时必须再增加一双人工眼睛。

可以把拉取请求想成进入港口的货物。测试和扫描器负责检查集装箱，AI审查者读取货单并标出可疑物品，最后仍由人工关员决定货物能否过关。如果把关员的印章交给检查工具，这道控制也就失效了。

下面这段可以直接作为规范的核心：

使用AI编程工具创建或进行实质性修改的代码，只能通过拉取请求进入代码库。作者仍有责任理解整个变更，并且必须注明所用工具、AI辅助范围、已运行的测试和人工负责人。批准前，所有必需的测试与安全检查都必须通过。AI审查仅供参考，绝不能计作必需的人工批准。敏感文件必须由代码负责人审查；关键变更必须有另一名独立审批者和回滚计划。新增commit会使此前的批准失效，并触发重新审查。

这套规范依据的是后果，而不是作者身份检测。开发者不必证明自动补全具体写了哪几行；他们应披露实质性的AI参与，并对整个diff负责。这比争论AI生成比例更有用，因为任何工具都无法把这种比例直接变成批准决定。

设置三档审查通道

关键通道就是应该成本高昂，但其中只应容纳很少一部分变更。稀缺的资深工程师注意力，要花在那些只需一个“看起来没问题”的错误，就可能泄露凭据、破坏数据或改变访问权限的地方。

去掉术语，这套流程如何运作？

整个流程有6道关卡，每一道都会留下证据，供下一位审查者核验。

1. 披露AI辅助。 在拉取请求模板中加入AI-assisted、tool、scope、human owner和tests run字段。不论AI只写了一个函数，还是完成了整个初稿，作者都要对每一行负责。
2. 划分风险。 用一个小型策略文件，将路径和变更类型映射到常规、敏感或关键通道。对.github/workflows/的修改，绝不能与文档中的拼写修正走同一条通道。
3. 先运行确定性检查。 “确定性”是指相同输入会得到相同的通过或失败结果。先完成编译、类型检查、lint、测试、密钥扫描、依赖项检查和静态安全分析，再去征求另一个模型的意见。GitHub自己的审查指南同样把自动化测试和静态分析放在前面。
4. 让AI扮演挑错者。 要求它查找遗漏场景、架构不匹配、被删除的测试、虚构的API、可疑软件包和权限变化。安全敏感或跨服务的工作应采用更高强度的审查。编写代码的智能体不能靠自审满足关卡要求。
5. 由人作出结论。 审查者要确认意图、测试高风险行为、质疑新增依赖项，并判断这个diff是否应该进入系统。在人工或确定性工具验证之前，AI评论只是线索，不是结论。
6. 每次推送后重置。 新commit进入后，应撤销过期批准、重新运行必需检查，并再次请求审查。GitHub指出，Copilot自动审查通常只运行一次，除非启用“每次推送均审查”（review-on-every-push）。

规范里还应加入两项不那么显眼的控制。第一，依赖文件需要单独的扫描器，因为GitHub Copilot代码审查会排除package.json和Gemfile.lock等文件。第二，对AI指令文件的修改必须进入关键审查。Copilot会读取拉取请求源分支（head branch）中的仓库指令、智能体指令和技能文件（skills），这意味着待审变更可能改写用来审查它自身的指令。

这套规范最先在哪7类场景见效？

1. 在大量仓库中运行编程智能体的平台团队

平台工程团队的收益最大，因为一份规范可以约束未来数以千计的变更。把风险映射放入共享模板，统一要求相同的披露字段，并提供一项所有受保护分支都能识别的状态检查。这样既能集中控制，又不必让每个产品团队各自设计一套流程。正在比较适合企业的最佳AI编程智能体的团队，即使更换工具，也无需重建审批模式。

2. 保护身份认证、计费和客户数据的SaaS团队

SaaS工程负责人可以把身份认证、权限检查、支付代码和数据导出路径标为关键。智能体可以起草修复方案，AI审查者也可以提出质疑，但身份或支付负责人以及另一名人工审批者必须共同批准。收益在于聚焦：资深审查者不再平均对待每个文件，而是集中处理真正具有影响范围的变更。

3. 维护CI/CD工作流的DevOps团队

应把工作流文件当作可执行的生产基础设施。每次变更都要交给DevOps代码负责人，扫描是否把不受信任的issue或拉取请求内容直接插入命令，检查token权限，并要求提供回滚方案。Wiz案例把价值讲得很具体：一个公开issue的标题进入了shell命令，泄露的token可以读取内部Jira项目。规范能够在大家争论原作者究竟是人还是AI之前，就拦住这一类错误。

4. 推广Copilot、Codex或Claude Code的工程负责人

推广负责人可以把工具使用权限与合并权限分开。开发者可以快速生成代码并完成第一轮审查，但分支规则集仍要求人工批准、工作流通过和代码负责人审查。这样既能推进采用，也保留可审计的控制平面。对Codex本地与GitHub审查模式的评估可以帮助选择工具，但即使更换供应商，同一道人工作为最终关卡的原则也应保留。

5. 面对大量低上下文拉取请求的开源维护者

在CONTRIBUTING.md中加入AI辅助复选框和证据清单，再让自动化流程拒绝缺少复现步骤、测试或责任维护者的提交。AI可以汇总并预筛队列，人工则把时间用在判断意图、兼容性，以及这项贡献是否适合项目。这样可以减少审查积压，又不会在不知不觉中降低陌生贡献者的准入门槛。

6. 交付客户自有软件的服务机构

服务机构可以为每次发布附上一份审查凭证，列明所用工具、受影响组件、测试结果、尚未解决的问题和具名审批者。客户的敏感路径要在发布前交由客户代码负责人审查。这样既能明确责任，也能留下即使交付团队离场后仍然有效的交接材料。

7. 借助AI编程智能体发布产品的独立创始人

独立创始人默认没有独立队友，因此流程必须主动制造职责分离。让一个模型起草，运行确定性检查，再用不同的审查流程复核，最后由本人在合并前实际验证高风险路径。涉及支付、身份认证或生产基础设施时，应请外部专家参与。这样能获得低成本的第一层过滤，又不会把第二个模型假装成第二位能承担责任的人。

围绕AI代码审查可以做什么产品？

市场已经在为自动化审查付费。在Google上，“ai powered code review platform”在美国每月约有1,600次搜索，“ai code review”为1,300次，“ai code review tools”为590次。CodeRabbit目前的Pro年付方案为每位开发者每月$24，Pro Plus为$48。Qodo起价为每月$30。真正的空档不是再做一个在所有拉取请求下留言的机器人，而是建立一个能决定哪种审查才算数的控制层。

1. 策略即代码的拉取请求关卡：最强机会

面向工程和安全负责人构建一款GitHub App，把简短的策略文件转化为必需检查。它读取变更路径、核验AI使用声明、分配风险通道、请求对应的代码负责人、确认必需的扫描器已经运行、使过期批准失效，并生成审计凭证。

需求数据支撑了这个品类：“ai powered code review platform”在美国每月约有1,600次搜索，“ai code review”则有1,300次，CPC为$63.85。最小可售版本需要一款GitHub App、一份仓库策略文件、一项状态检查、一套审查者路由服务和一张审计表。难点在于配置疲劳：只有默认设置能覆盖常见技术栈，且例外情况容易解释，产品才可能胜出。

2. 关键文件审查路由器

为平台和AppSec团队构建一个范围更窄的工具。它监控工作流、基础设施、迁移、身份认证和策略文件等路径，随后提升审查强度、召集对应负责人，并要求每次推送后重新审查。常规代码可以走低成本筛查，把昂贵的推理资源和人工时间留给关键diff。

“AI code review tools”在美国每月约有590次搜索，带有商业意图，关键词数据中的年度趋势为50%。“Secure code review”每月还带来170次搜索，CPC为$50.19。MVP包括路径规则、CODEOWNERS集成、检查运行界面和能够感知预算的审查路由。难点是品类边界膨胀：它必须补充SAST、密钥扫描和依赖项分析，而不能把自己宣传成这些工具的替代品。

3. AI变更来源凭证

为服务机构和受监管团队构建一个轻量级CLI与拉取请求机器人。它记录申报的工具、会话标识符、变更文件、已运行测试、审查决定和最终人工负责人，再生成签名发布凭证。它应证明流程，而不是根据代码风格猜测作者身份。

在美国，每月约有210次搜索在寻找“ai generated code detector”，CPC为$16.70。这种需求反映了真实焦虑，但“检测”是错误的产品承诺。可售版本应转而向买家提供审查与责任归属的证据。难点是参与度：如果团队可以绕过声明，凭证就会沦为形式主义。分支保护和身份集成是产品本体，而不是可选项。

引用来源上的空档同样存在。ChatGPT引用检查没有发现“ai code review tools”存在反复被引用的来源。若产品发布严谨、版本化的策略Schema和透明控制机制，就有机会成为参考层，同时销售背后的执行产品。

局限与坦率判断

AI审查是有效的过滤器，却不能构成安全论证。GitHub表示，Copilot审查可能漏掉问题，必须辅以人工审查；它还会排除部分文件，在运行器不可用时可能回退到能力较弱的模式，并在AI credits预算耗尽后停止运行。任何一种情况都不应悄悄降低合并门槛。

智能体自动修复也有相同边界。GitHub处于公开预览阶段的系统可以浏览代码库、提出修复、重新运行CodeQL，并创建草稿拉取请求，通常只需2到4分钟。GitHub同时说明，该系统只能尽力而为，无法确认部分自定义或安全扩展查询的修复，也不保证针对第三方告警的修复质量。绿色的重新运行结果只能证明某个检测器不再报警，并不能证明业务行为、权限模型或周边工作流已经安全。

这套规范无法解决作者身份检测、测试薄弱、架构知识缺失，或团队走过场批准拉取请求的文化问题。如果每个拼写错误都进入关键通道，它也会显得过重。让常规通道保持低成本，让关键通道保持小范围，并且绝不能让生成变更的工具成为唯一有权批准它的主体。

周一就能落地的一步

周一，工程经理可以先在拉取请求模板中增加5个字段：AI-assisted、tool、scope、human owner和tests run。然后把.github/workflows/、身份认证、支付、生产基础设施、密钥和破坏性迁移标为关键。对这些路径，要求CI通过、代码负责人审查、撤销过期批准，并由第二名人工审批者确认。做到这些，就足以把关于AI代码的观点变成一版可执行的规范。

AI生成的代码需要人工审查吗？

需要。先运行测试和确定性扫描器，再把AI审查作为额外的挑错环节，最后由一位具名人员对合并负责。AI审查绝不能满足必需的人工批准规则。

ChatGPT能做代码审查吗？

它可以评议diff、追问缺失的测试，并指出可疑逻辑，但无法执行分支保护、证明CI已经运行，也不能承担生产环境中的后果。应把它放进规范之内，而不是用它取代规范。

哪款AI最适合做代码审查？

最合适的选择，应能理解足够多的仓库上下文、接入现有检查、遵守数据控制要求，并留下清晰的审计轨迹。模型质量固然重要，但与合并关卡的集成和明确的人工责任更重要。

有没有免费的AI代码审查工具？

免费或已包含在现有服务中的组件确实存在。对于符合条件的仓库，GitHub经典版Copilot Autofix既不需要Copilot订阅，也不消耗AI credits；现有CI工具也可以执行许多确定性检查。但要形成一套完整规范，仍然需要配置和人工审查。

如果希望把这道审查关卡接入工程工作流，可以查看AI生产系统。