AI 审查适合发现什么
这些结果应作为审查线索，而不是缺陷定论。评审人员需要回到代码、调用链和测试证据确认。
- 新增分支是否遗漏空值、超时、重试和异常处理。
- 接口字段、类型和错误码是否与约定一致。
- 是否出现重复代码、未使用变量或明显复杂度增长。
- 单元测试是否缺少反例、边界值和失败路径。
- 注释、接口说明与实际实现是否不一致。
- 变更是否触碰约定的敏感目录、依赖或配置。
按变更风险决定审查强度
- 低风险：文案、注释、样板代码和非核心字段映射。AI 可初筛一致性，仍需责任人确认并运行基础检查。
- 中风险：普通业务逻辑、接口适配、数据处理和依赖升级。需要模块责任人评审，并完成单元与集成测试。
- 高风险：鉴权、权限、支付、密钥、隐私、并发、生产配置、安全或设备关键路径。AI 只提供线索，必须专项人工审查、目标环境验证和明确批准。
- 风险不能按代码行数判断。少量权限逻辑可能比大量页面样式更关键，第三方依赖、数据范围和故障后果也要进入分级。
一套可执行的 AI 辅助代码审查流程
- 控制变更规模：一次评审只解决一个明确问题，把无关格式化、依赖升级和功能修改拆开。
- 提供最小充分上下文：包括目标、差异、接口约束、禁止事项、环境、已有测试和风险级别，不无边界上传整个代码库。
- 先执行确定性检查：格式化、编译、类型检查、静态分析、依赖扫描和自动化测试优先运行。
- 要求证据：每条 AI 意见应包含位置、触发条件、可能影响和验证方法；泛泛建议不进入缺陷清单。
- 由责任人确认或驳回：高风险意见要记录处理依据，AI 输出本身不能形成合并批准。
- 保留记录：关联变更编号、工具版本、审查范围、检查结果和最终批准人，以便复查。
如何避免意见变多、审查反而更慢
- 只报告与本次变更有关的问题，不重构未改动模块。
- 优先处理安全、数据损坏、权限越界和可用性问题。
- 把风格偏好交给格式化和静态规则，不进入人工争论。
- 无法给出触发条件的问题标记为待验证，不直接阻塞。
- 统计采纳、驳回和重复意见，持续调整检查清单；若有效发现率和评审周期无改善，应缩小范围或停用低价值规则。
如何验收 AI 代码审查流程
可比较从提交到首次有效反馈的时间、人工评审等待、AI 意见的确认与驳回比例、评审后仍被测试或线上发现的缺陷，以及高风险变更是否完成指定审批。
不能把 AI 生成的评论数量当成质量指标。评论越多不代表问题越重要，也不能替代代码、测试、接口文档和变更记录的一致性检查。
AI 代码审查可以替代人工评审吗？
不可以。AI 可作为初筛和第二视角，但不能承担业务责任、安全批准和最终合并决定。高风险变更应由具备相应上下文和职责的人员审查。
是否应该把整个企业代码库交给 AI 审查？
不应默认这样做。应先确认部署方式、数据保留、训练使用、访问权限、第三方处理和审计能力，再按最小必要范围提供上下文。
AI 评论和静态分析有什么区别？
静态分析适合稳定、确定的规则；AI 更适合结合自然语言约束、变更目的和多个文件关系提出线索。二者应分工使用，不能用生成式判断替代可重复的确定性检查。
哪些代码需要更严格的人工复核？
鉴权、权限、支付、密钥、隐私数据、加密、并发、生产配置、设备控制和其他故障后果较大的代码，都应提高人工审查和验证等级。
参考依据与适用边界
- NIST Secure Software Development Framework（SSDF）：https://csrc.nist.gov/pubs/sp/800/218/final
- NIST AI Risk Management Framework：https://www.nist.gov/itl/ai-risk-management-framework
- 本文给出通用工程控制方法，不替代企业安全、隐私、知识产权和供应商准入审查。