来源：抖音 @产品总监看AI
AI代码审查的效率悖论
随着AI编程工具（如Copilot、Cursor等）的普及，开发者产出原始代码的速度提升了数倍，但真实生产力并未同步大幅增长。数据表明，生产力的提升仅约12%，而代码变更（Code Churn）、缺陷率及事故比例反而显著上升。瓶颈已从”写不出”转变为”信不过”。
在这种高频生成的背景下，传统的代码审查（Code Review）模式面临严峻挑战。若因代码是新人或AI生成就预设偏见，或因担心AI出错而全部重审，都不仅效率低下且不可持续。
风险分层审查策略
更高效的审查机制应基于风险分层，而非作者身份。审查策略需考量以下三个核心变量：
- 影响范围：代码变动会破坏哪些模块？
- 维护成本：后续由多少人、多久维护一次？
- 技术复杂度：是否涉及配置改动、UI微调或核心业务逻辑？
1. 低风险代码
对于涉及配置、非核心UI微调或非关键路径的代码，且已跑过Lint工具和基础测试的，审查标准可相对放宽。
2. 中高风险代码
对于普通业务逻辑、涉及支付权限、认证安全路径或任何UI变动的代码，即使只修改十行，也需要进行严格的类型检查、测试覆盖及交叉审查。系统Owner需承担最终责任。
Agent代码的审查难点
Agent生成的代码往往缺乏推理过程（Reasoning Process）。人类开发者在写代码时会思考”为什么这么写”、“排除了哪些方案”，这些信息通常包含在PR的描述中。而Agent生成的代码常丢失这一”决策日志”。
因此，要求Agent在提交PR时附带以下信息是审查的前提条件：
- 决策日志（Decision Log）：说明目的、方案、排除的选项、证据及重点检查位置。
- 技术证据：必须包含测试用例输出、CI结果及关键路径说明。
若缺乏上述信息，该PR不应直接进入人工审查环节。此外，审查者需警惕Agent可能通过修改断言（Assertion）来“匹配”错误的行为，导致测试通过但逻辑仍错误。
引入AI Reviewer的正确姿势
目前市面上有许多AI Review工具（如CodeRabbit、Sentry、Seer等），试图自动审查PR。然而，研究显示，这些工具之间重合度极低，极少有标记能同时被两个以上工具捕获。这意味着AI Reviewer更像是一个传感器，提供多维度的信号（正确性、架构、事故、安全），而非最终的法官。
Human on the Loop
审查机制不应走向两个极端：
- 全量人工审查：在AI生成海量代码下不具备可行性。
- 全自动化审查：AI自己写、自己审、自己合并，会导致相互认可但无法发现真实风险。
最合理的模式是Human on the Loop（人在回路）。团队引入AI Coding后，不必争论是否信任AI，而应建立一套按风险分层的流程。明确谁是按下Merge键的责任人，并由产品总监或具备业务判断力的人工角色对关键上线决策负责。AI提供信号与辅助，人类负责最终的风险判断与合并且承担相应责任。