---
title: "AI Code Review 与人工代码审查：区别、边界与协作流程"
source: https://www.iowill.com/blog/2026/10/ai-code-review-vs-human-code-review/
date: 2026-10-27
updated: 2026-10-27
tags: [AI Code Review, AI 编程, Code Review, Git]
categories: [编程开发]
---

# AI Code Review 与人工代码审查：区别、边界与协作流程

提交一个改动后，AI很快写出了几条审查意见：这里可能空值异常，那里建议重构，还补了一段修改代码。看起来已经有人替我们检查过了，但接下来仍有几个问题：这些问题真的存在吗？修改会不会改变需求？没有评论的地方，是否就没有风险？

**Code Review是对代码变更进行检查与讨论的活动；AI Code Review是其中一种辅助方式，人工代码审查则由开发者结合需求与工程背景进行判断。** 它们可以处于同一条工作流中。AI产生候选发现，开发者核对事实和影响，再用适当的检查验证修改，并按项目规则决定是否合并。

这篇文章不做工具排行榜，也不声称“AI一定更准”或“人工一定不会漏”。文中分别标明通用工程原则、具体产品行为和原创示例；示例只在本地离线运行，不冒充商业AI工具的实测报告。公开资料核对日期为2026年10月27日。

## Code Review检查什么：从代码能运行到变更值得合并

代码能通过编译，只能回答一部分问题。审查还要看需求是否得到正确实现、边界是否处理、模块职责是否清楚，以及改动会给后续维护带来什么影响。

[Google的审查标准](https://google.github.io/eng-practices/review/reviewer/standard.html)把长期代码健康作为核心目标，并没有要求每次改动都达到抽象的“完美”。[其审查清单](https://google.github.io/eng-practices/review/reviewer/looking-for.html)覆盖设计、功能、复杂度、测试、命名和文档等内容。一个符合格式规范却破坏业务规则的补丁，仍然可能不该合并。

[Google的现代代码审查案例研究](https://research.google/pubs/modern-code-review-a-case-study-at-google/)也从组织实践、动机与挑战研究这项活动。这里引用其研究背景，不用某一家公司的历史实践代表所有团队。

审查时需要区分三类信息：

-   **需求和约束**：这次要解决什么，哪些已有行为不能改变？
-   **变更和依赖**：改了哪些代码，哪些调用方、数据结构或配置会受影响？
-   **验证证据**：做过哪些检查，覆盖什么条件，还有什么没有确认？

审查意见只有落到这些信息上，才有机会从“听起来合理”变成可处理的问题。

## AI与人工如何分工：能力重叠，责任需要明确

AI可以协助解释diff、查找可疑分支、提示缺失测试和整理审查意见。人工也会做这些事情，但更需要负责核对业务意图、跨模块影响及取舍依据。这里的分工是工作流建议，不是对所有模型和开发者能力的固定排名。

| 维度 | AI辅助审查可承担的工作 | 人工应重点核对的内容 |
| --- | --- | --- |
| 局部逻辑 | 提出空值、条件分支、资源处理等疑点 | 触发条件是否成立，调用链是否已有保护 |
| 需求与设计 | 依据提供的文档检查一致性 | 文档是否准确，取舍是否符合当前业务 |
| 测试 | 建议输入组合、边界场景和检查方法 | 测试是否表达真实需求，是否遗漏关键路径 |
| 反馈处理 | 汇总问题、起草修补建议 | 是否采纳、如何修改及影响范围 |
| 合并决定 | 提供评估或平台允许的审查动作 | 明确授权规则、验证标准与维护责任 |

不要把“AI看过代码”写成“代码已经安全”。[GitHub的责任使用说明](https://docs.github.com/en/copilot/responsible-use/agents)明确列出漏报、误报与不正确修改建议等限制，并建议认真复核和测试。它支持“输出需要核对”这个判断，不提供所有AI工具的统一准确率。

研究也应按范围理解。2024年的[AutoCommenter论文](https://research.google/pubs/ai-assisted-assessment-of-coding-practices-in-industrial-code-review/)研究了工业环境中的语言最佳实践检查，涉及C++、Java、Python和Go。本文核对了作者机构的摘要与出版入口，没有复现其系统；这一研究不能证明任意模型能替代完整的业务设计审查。

![AI辅助审查、人工复核与自动化检查的分工](https://img.iowill.com/file/编程开发/AICodeReview/body1.png)

工作流建议示意：职责可以重叠，任何一层都不能单独证明代码没有缺陷；不表示工具能力排名。

## 上下文决定审查质量：只有diff往往不够

看到一行删除代码，AI或人工都可能缺少判断所需的信息。删除的是重复校验，还是调用链中最后一道校验？一个看似冗余的兼容分支，是历史包袱，还是仍在支持旧客户端？

提供上下文时，可以优先补齐变更目的、验收条件、相关调用方、配置约定和已做的测试。无需不加选择地上传整库，尤其不能将凭据、生产数据或不被允许外发的私有材料放进提示词。

[GitLab Duo非Agent式代码审查文档](https://docs.gitlab.com/user/gitlab_duo/code_review/)列出了该功能使用的合并请求描述、diff、文件内容及自定义指令，并说明大请求重试时可能减少上下文。这个产品实例说明：工具“审查了MR”，不代表它始终拿到了同样完整的信息；不能将它外推为所有Agent式工具的统一工作方式。

把改动拆成目的明确的小单元，也有助于理解。[Google关于小变更的指导](https://google.github.io/eng-practices/review/developer/small-cls.html)强调自洽、便于理解的改动。实际操作中，应尽量将机械格式化与行为修改分开，避免一个PR同时改接口、迁移数据、重构目录，又调整业务规则。

一段可复用的审查请求可以这样写：

```text
目标：检查本次变更是否违反列出的需求，不直接修改代码。
上下文：变更目的、允许输入、兼容要求、相关调用方和已做检查。
输出：文件位置、触发条件、预期/实际差异、影响、验证办法。
约束：区分确认问题与待核实疑点；证据不足时说明缺什么。
对同一根因合并报告，不把个人风格偏好当作阻塞问题。
```

这份模板是本文的工程建议，不保证模型遵循，也不代替审查结果的验证。

## 一个小例子：把审查意见变成可验证的发现

假设某个配置允许：`None`表示使用默认超时30秒，`0`表示不等待，正数表示具体等待秒数。输入类型和合法范围由上游校验；这里仅检查默认值语义。

```python
def effective_timeout(value):
    return value or 30
```

候选审查意见是：“当value为0时，函数返回30，改变了不等待的语义。”这条意见之所以值得处理，不是因为它由AI还是人工提出，而是因为可以给出完整证据：

| 项目 | 内容 |
| --- | --- |
| 前提 | 本例明确允许0，并约定0表示不等待 |
| 触发输入 | `effective_timeout(0)` |
| 预期结果 | 0 |
| 实际结果 | 30 |
| 修改方向 | 只在输入为None时使用默认值 |

针对该约定，可以改为：

```python
def effective_timeout(value):
    return 30 if value is None else value
```

本地检查了`None`、`0`、`1`、`30`四个输入：修改前，0这一项违背约定；修改后，四项结果符合本例约定。代码与离线验证脚本随素材保存。这只是人为设计的最小例子，不是某个真实项目故障，也不是AI产品的检出率测试。

如果业务规定0是非法值，而且上游已经拒绝0，那么同一条审查意见就需要重新判断。可见，**代码位置、需求前提、触发输入和实际影响缺一不可。** 仅仅说“这里应该改成is None”，还不能自动升级为阻塞合并的问题。

## 如何处理误报和漏报：不按评论数量判断质量

误报会消耗核对时间，漏报则意味着风险没有被指出。没有评论只能说明本轮没有产出发现，不能证明不存在缺陷；评论很多也可能只是重复、风格偏好或对上下文的误解。

可以把每条发现先分类：

| 分类 | 处理方式 |
| --- | --- |
| 可复现且违反约定 | 确认影响，修复并补充适当验证 |
| 触发条件尚不明确 | 补查调用方、输入约束或运行证据 |
| 已有保护或判断有误 | 说明依据后关闭，不为迎合评论而改代码 |
| 可选改进或风格建议 | 按项目规范处理，避免与正确性混为一谈 |

修补代码也应重新审查。一个能消除报错的修改，可能吞掉异常、破坏兼容性或扩大行为范围。尤其当同一个AI既生成代码又审查代码时，不应把角色切换当作获得了独立证据；仍要重新检查需求、相关实现和运行结果。

如果要评估工具是否值得长期使用，可以记录确认发现、误报、重复意见、人工核对时间，以及事后发现的遗漏。统计时写清项目、样本、版本与判断方法。只有“已确认问题”这类分母时，通常还不足以算出完整召回率；不要凭一次顺利体验给出通用百分比。

## 协作流程：AI初审、人工复核、验证后决定合并

我更推荐把AI安排在容易复核、反馈能形成闭环的位置：

1.  **作者自查**：说明变更目的、需求约束和影响范围，运行适当的格式、静态检查与测试。
2.  **AI初审**：提供相关上下文，要求输出带位置、条件和证据的候选发现。
3.  **人工复核**：核对真实问题，补查设计和业务边界，将误报与可选改进分开处理。
4.  **修改与验证**：修复确认的问题；对行为变化补充必要的验证，检查补丁是否引入新问题。
5.  **最终审查与合并**：针对最终提交核对未解决发现、CI结果、兼容及回滚条件，再按项目权限规则合并。

这里“验证后”并不意味着所有改动一律跑完整测试。修改文档、局部逻辑、数据库迁移与并发控制，所需证据不同。检查要与变更风险匹配，测试通过也不等于需求、设计和所有运行条件都已证明正确。

还要区分平台动作与工程判断。核对当日的[Copilot使用文档](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/use-code-review)说明，概览中的批准评估本身不计入合并要求；若启用处于公开预览的审批功能，Copilot可以提交按配置计入要求的批准。因此不能笼统写成“AI永远不能Approve”，也不能将平台允许合并等同于变更已被全面验证。团队仍须明确哪些变更需要人工复核和谁承担维护责任。

![作者自查、AI初审、人工复核、修改验证与最终合并的闭环](https://img.iowill.com/file/编程开发/AICodeReview/body2.png)

协作流程示意：审查意见需要核实，修改后应针对最终提交验证；不是所有平台强制采用的审批流程。

## 常见问题：AI审完了，还需要人工看吗

### 小改动是否可以完全自动合并

这应由项目针对变更类型、检查质量和回滚能力制定规则。受控的低风险更新与涉及鉴权、数据迁移、并发状态的改动，需要的审查证据不同。本文不提供一个适用于所有仓库的自动合并开关。

### 人工复核是不是把AI的评论再读一遍

复核需要追到需求与代码证据，必要时独立检查AI没有评论的关键路径。把建议全部照单修改，或看到“未发现问题”就直接合并，都没有完成这一步。

AI的价值可以体现在更早提出值得检查的问题、减少机械整理，让人有更多精力判断上下文。最终应衡量的是发现是否成立、修改是否正确，以及这次变更是否达到项目约定的合并条件。

## 参考资料

以下8项为2026年10月27日核对的公开一手资料。同一机构的工程文档与研究不视为多次独立效果验证；产品说明不作为通用性能排名依据。

1.  [Google：The Standard of Code Review](https://google.github.io/eng-practices/review/reviewer/standard.html)，长期代码健康与审查标准。
2.  [Google：What to look for in a code review](https://google.github.io/eng-practices/review/reviewer/looking-for.html)，设计、功能、测试及相关检查维度。
3.  [Google：Small CLs](https://google.github.io/eng-practices/review/developer/small-cls.html)，自洽的小变更与审查工作流。
4.  [GitHub：Copilot Agents责任使用说明](https://docs.github.com/en/copilot/responsible-use/agents)，代码审查的漏报、误报及不准确建议等限制。
5.  [GitLab：Duo Code Review（非Agent式）](https://docs.gitlab.com/user/gitlab_duo/code_review/)，输入上下文与大请求处理边界；不混同其他审查产品。
6.  [GitHub：Using Copilot code review](https://docs.github.com/en/copilot/how-tos/use-copilot-agents/use-code-review)，审查与批准配置；预览功能可能继续变化。
7.  [Google Research：AI-assisted Assessment of Coding Practices in Industrial Code Review（2024）](https://research.google/pubs/ai-assisted-assessment-of-coding-practices-in-industrial-code-review/)，本文使用机构页面的摘要与出版入口，没有复现论文实验。
8.  [Google Research：Modern Code Review: A Case Study at Google](https://research.google/pubs/modern-code-review-a-case-study-at-google/)，传统现代代码审查的研究背景，本文仅核对机构页面摘要，不将历史案例外推为当前所有团队效果。