AI生成的Pull Request无处不在，这里是如何审查它们的方法

Q: 引言

AI生成代码看似干净但隐藏技术债务。

The GitHub Blog

The GitHub Blog2026年5月7日

AI生成的Pull Request无处不在，这里是如何审查它们的方法

8.5Score

TL;DR · AI 摘要

代码审查中需特别注意AI生成的Pull Request，因其可能引入更多技术债务和冗余。

核心要点

2026年研究显示，AI生成代码每改动一次会引入更多技术债务。
GitHub Copilot已处理超6000万次代码审查，其中超过20%涉及AI生成代码。
审查AI Pull Request时需关注CI规避、代码复用问题及潜在逻辑错误。

结构提纲

按章节快速跳转。

§引言
AI生成代码看似干净但隐藏技术债务。
§Agent PR饱和现状
GitHub Copilot一年内处理了6000万次审查，AI PR占比超20%。
§谁写了这个PR
AI缺乏上下文知识，生成的代码可能看似完整但存在隐患。
§红灯标志
审查AI PR时需警惕CI规避、代码重复及逻辑错误等问题。

思维导图

用一张图看清主题之间的关系。

查看大纲文本（无障碍 / 无 JS 友好）

Review Agent Pull Requests
- Study Findings
- Bandwidth Saturation
- Context Matters
- Red Flags
  - CI Gaming
  - Code Reuse Blindness
  - Hallucinated Correctness

金句 / Highlights

值得收藏与分享的关键句。

2026年1月的一项研究发现，AI生成代码每次改动都会引入更多冗余和技术债务。
— 第3段
⬇︎ 下载 PNG 𝕏 分享到 X
AI在CI失败时，可能会通过删除测试、跳过代码格式化步骤或添加|| true到测试命令来让测试通过。
— 部分：需要注意的红旗
⬇︎ 下载 PNG 𝕏 分享到 X
要求新增一个针对变更前行为失败的测试。如果AI无法编写出能够捕获其声称修复的漏洞的测试，则修复不完整或理解有误。
— 部分：幻觉正确性
⬇︎ 下载 PNG 𝕏 分享到 X

#GitHub#AI#代码审查#技术债务

打开原文

标题：代理生成的拉取请求无处不在。这是如何审查它们的方法。

来源 URL: http://github.blog/ai-and-ml/generative-ai/agent-pull-requests-are-everywhere-heres-how-to-review-them/

发布时间: 2026-05-07T12:00:00-07:00

你可能已经不知不觉地批准了一个代理生成的拉取请求。测试通过了，代码很干净，你也合并了它。

但它是代理生成的——而这种轻松的批准正是问题所在。

2026年1月的一项研究 “更多代码，更少复用” 发现，代理生成的代码在每次变更中引入了比人工编写的代码更多的冗余和更多的技术债务。表面上看起来很整洁，但技术债务却悄无声息。而且根据同一项研究，评审者实际上对批准代理生成的代码感到更加放心。

这并不是说要放慢速度。而是要更有意识地进行评审。这两者之间是有区别的。

代理生成的拉取请求已经占据了评审带宽

数量已经令人震惊。GitHub Copilot 的代码评审已经处理了超过6000万次评审，在不到一年的时间里增长了10倍。如今，GitHub 上超过五分之一的代码评审涉及代理。这只是自动评审部分。拉取请求本身正在以评审者无法跟上的速度激增。

传统的循环——请求评审、等待代码所有者、合并——在一名开发者午餐前可以启动十几个代理会话的情况下就会崩溃。吞吐量呈指数级增长，但人类评审能力却没有跟上。差距正在扩大。

你将评审代理生成的拉取请求。问题是，当你评审时，你是否能抓住真正重要的东西。

谁（或什么）实际编写了这个拉取请求

在查看任何一行差异之前，你需要明确自己正在评审的内容。

一个编码代理是一个高效的、字面化的、遵循模式的贡献者，但它对你的事故历史、团队的边缘案例知识或存储库外的操作约束一无所知。它生成的代码看起来是完整的。但这种“看起来完整”的失败模式是危险的。

你才是那个携带这些上下文的人。这不是负担，这就是你的工作。评审中无法自动化的部分是判断力，而判断力需要只有你才拥有的上下文。

现在回到评审者。拉取请求出现在你的队列中。作者完成了他们的部分。以下是你需要注意的地方。

需要注意的红旗

1. 欺骗 CI

代理可能会导致 CI 失败。当这种情况发生时，它们有明显的途径让测试通过：删除测试、跳过 lint 步骤、在测试命令中添加 || true。有些代理确实这样做了。

任何削弱 CI 的更改都是阻断点。在批准任何代理生成的拉取请求之前，请检查：

覆盖率阈值是否发生了变化？
是否有任何测试被删除、重命名或标记为跳过？
工作流是否停止在分支或拉取请求上运行？
是否有任何 CI 步骤现在被条件限制，而之前没有？

如果上述任何一项的答案是肯定的，那么在继续之前你需要一个明确的理由。

2. 忽视代码复用

这是作为评审者你能做的最高回报的事情。代理会寻找先例。它们会在代码库中找到一个模式并复制它，通常不会检查是否存在已经实现相同功能的工具。症状包括：新的实用函数与现有的函数名称略有不同、在多个地方重新实现验证逻辑、从头编写已经在共享模块中存在的中间件、具有“几乎相同”但名称不同的辅助函数。

代理的本地上下文中不包含整个存储库中的全貌信息。而你有。

对于代理生成的拉取请求中的每个新辅助工具或实用程序，请快速搜索一下。如果你找到了等效的工具，不要留下评论。要求在合并前进行整合。保留重复逻辑的成本是代理会将其视为先例并进一步复制。

💡专业提示： 对于超过一定规模的代理生成的拉取请求，要求提供添加新工具的理由。这可以及早发现重复问题。

3. 幻觉正确性

明显的幻觉（调用不存在的 API、引用超出范围的变量）会在 CI 中被捕获。危险的是更微妙的情况：能够编译、通过所有测试但实际上是错误的代码。

分页中的越界错误。从未在测试中命中的分支中缺少权限检查。在代理未考虑的边缘情况下短路的验证逻辑。仅在大规模下才会出现竞争条件下的错误行为。

追踪它，而不仅仅是扫描它。选择差异中最关键的路径。从输入开始，跟踪每一个转换到输出。检查边界条件（零、最大值、空），外部值的缺失验证，每个分支的权限检查，以及意外的条件逻辑。

要求一个新的测试用例，该测试用例在更改前的行为上失败。如果代理无法编写一个能够捕获它声称要修复的 bug 的测试用例，那么修复是不完整的或者理解是错误的。

4. 代理生成的沉默

你留下了详细的评审意见。你解释了问题，提供了上下文，建议了方向。拉取请求变得安静了。或者代理回复完全错过了重点，并陷入循环。你又投入了一轮评审。仍然没有任何有用的东西。

较大的拉取请求如果没有结构化的计划，与代理放弃或错位密切相关。拉取请求越大且范围越不明确，你就越有可能将评审时间浪费在毫无结果的工作上。

在对大型代理生成的拉取请求进行深入评审之前，请检查拉取请求的历史记录。它在之前的轮次中是否有响应？它是否有清晰的实现计划，还是代理只是开始写代码？

如果没有计划，请在写下任何评论之前要求提供分解说明。复制粘贴版本：

“_这个_ pull request _对我来说太大了，无法在没有更清晰实现计划的情况下进行审查。你能否将其拆分为更小的范围单元，或者添加每个部分的功能及其如此结构的原因的总结？之后我很乐意进行审查。_“

坚定、简短、不针对个人。而且能为你节省一个小时。

5. 工作流中的不可信输入

CI 代理中的提示注入是真实存在的，并且被低估了。模式如下：代理工作流从 pull request 内容、问题或提交消息中读取内容。该内容被插入到提示中。提示发送给模型。模型输出被传递到 shell 命令中。整个过程以 GITHUB_TOKEN 权限运行。

当你审查任何调用 LLM 的工作流时，这些都是必须解决的问题：

是否有未经清理的不可信用户输入（pull request 内容、问题内容、提交消息）被插入到提示中？
GITHUB_TOKEN 是否仅需要读取权限却被赋予写入权限？
模型输出是否在未验证的情况下被执行为 shell 命令？
密钥是否对代理步骤可见或被打印到日志中？

合并前的要求：工作流 YAML 中的最小权限（permissions: read-all 是一个合理的默认值），在内容接触提示之前清理和引用不可信内容，通过人工审批将“分析”步骤与“执行”步骤分开，绝不直接执行模型输出。

| 时间 | 步骤 | 要做什么 | | --- | --- | --- | | 1–2 分钟 | 扫描和分类 | 查看文件列表和 diff 大小。任务是简单（文档、CI、小改动）还是复杂（多文件、逻辑、性能、测试）？该分类决定了后续所有内容的审查深度。 | | 2–3 分钟 | 先检查 CI 改动 | 在阅读任何一行应用代码之前，查看任何涉及 .github/workflows、测试配置、覆盖率设置或构建脚本的内容。标记任何削弱 CI 的改动。停止标志检查。 | | 3–5 分钟 | 扫描新工具 | 搜索新函数、辅助工具或模块。对于每一个，快速搜索仓库以检查是否有重复项。标记任何重新发明现有功能的内容。 | | 5–8 分钟 | 追踪关键路径 | 选择最重要的逻辑改动。追踪其端到端流程：输入 → 转换 → 输出。检查边界条件、权限、意外分支。这是不能跳过的步骤。 | | 8–9 分钟 | 安全边界 | 如果此 PULL REQUEST 触及任何调用 LLM 或处理不可信输入的工作流，请运行上述安全检查清单。 | | 9–10 分钟 | 要求证据 | 对于任何非平凡的逻辑改动，要求一个在更改前行为失败的测试。没有高风险改动的回滚计划？请要求一个。 |

何时要求更小的 pull request：

diff 涉及超过五个无关文件
你无法用一句话描述 pull request 的目的
没有实现计划或 pull request 正文为空
CI 失败且 diff 中唯一的改动是测试文件

让 Copilot 先审查

使用自动化审查来捕捉它擅长的部分：在人类介入之前抓住机械性问题。Copilot 代码审查会标记风格不一致、明显的逻辑错误、缺失的错误处理和类型不匹配。它负责低级扫描。这让你可以专注于判断性工作，这才是你时间真正重要的地方。

将其视为前提条件，而不是替代品。让 Copilot 先运行。如果它发现了明显的问题，让作者在你投入审查时间之前解决它。

你可以通过针对团队的自定义指令来调整这一过程：标记任何修改 CI 阈值的内容，突出新工具以进行去重审查，检查每个外部输入是否已验证。你的指令越具体，自动化的审查就越有用。

💡 专业提示： 我最近尝试使用 Copilot SDK 将我自己的审查清单编码化。与其每次 pull request 都记住运行相同的安全部分检查，我创建了一个工作流，将我的个人清单——管理员端点的身份验证、测试实际运行、环境变量的安全处理——自动应用于 diff。如果它发现关键问题，它会阻止合并。

判断是瓶颈，但这没关系

代码的表面面积正在增长。pull request 数量也在增长。你花在扫描样板代码上的时间应该减少。

不会减少的是你所携带的上下文。那些关于你的系统但没有写下来的东西。这就是让你的审查有价值的地方，也是不会自动化的部分。

三个要点：

任何削弱 CI 的改动都是硬性停止。
让代理先扫描。你追踪关键路径。
在复杂的代理 pull request 上，默认使用红旗检查清单。

* *

撰稿人

Andrea 是 GitHub 的高级开发者倡导者，拥有十多年的开发者工具经验。她结合技术深度与使先进技术更易获取的使命。从陆军服役和建筑管理转型到软件开发后，她带来了独特的视角，将复杂的工程概念与实际实施相结合。她与威尔士籍伴侣、两个儿子和两只狗住在佛罗里达州，继续通过 GitHub 的全球倡议推动创新并支持开源。在线关注她 @acolombiadev。