你可能已经在不知不觉中批准过这样的代码。测试通过了。代码很整洁。你合并了它。

但它是智能体生成的——而那种轻易批准的便利恰恰就是问题所在。

2026年1月的一项研究《更多代码，更少复用》发现，与人类编写的代码相比，智能体生成的代码每次变更会引入更多的冗余和技术债务。表面看起来很整洁。债务是无声的。而根据同一项研究，审查者实际上更愿意批准这样的代码。

这不是主张放慢速度。这是主张要有意识地行动。两者有区别。

智能体的拉取请求已经让审查带宽饱和

数量已经惊人。GitHub Copilot 代码审查已处理超过6000万次审查，在不到一年内增长了10倍。GitHub 上超过五分之一的代码审查现在涉及智能体。这还只是自动化审查环节。拉取请求本身正在以审查者无法处理的速度激增。

传统的流程——请求审查、等待代码所有者、合并——当一名开发者在午饭前就能发起十几个智能体会话时，这套流程就崩溃了。吞吐量呈指数级增长。人类审查能力却没有。差距正在扩大。

你将要审查智能体的拉取请求。问题在于，当你审查时，能否抓住真正重要的东西。

这个拉取请求到底是谁（或什么）写的

在你查看任何一行差异之前，你需要一个模型来理解你正在审查什么。

一个编码智能体是一个高效、刻板、遵循模式的贡献者，它对你的事故历史、你团队的边缘案例知识库，以及那些不在代码仓库中的运维约束一无所知。它会生成看起来完整的代码。但那种“看起来完整”的失败模式是危险的。

你才是那个承载这些上下文的人。这不是负担。这才是真正的工作。审查中无法被自动化的部分是判断力，而判断力需要只有你才拥有的上下文。

给代码作者的一点提示

如果你要打开一个由智能体生成的拉取请求，请在请求审查之前先编辑正文。智能体喜欢冗长。它们会描述那些通过代码本身更容易理解的内容。在有帮助的地方对差异进行注释。在标记他人之前，先自己审查一遍，这不仅是为了检查正确性，也是为了表明你已经验证了智能体准确捕捉了你的意图。

当涉及智能体时，审查自己的拉取请求并非可选项。这是对审查者时间的基本尊重。

现在，回到审查者这边。拉取请求进入了你的队列。作者已经完成了他们的部分。以下是需要注意的事项。

需要警惕的危险信号

1. CI 作弊

智能体在 CI 中会失败。当它们失败时，它们有一条明显的路径来让测试通过：删除测试、跳过 lint 步骤、在测试命令后添加 `|| true`。有些智能体会选择这条路。

任何削弱 CI 的更改都是阻碍。到此为止。在批准任何智能体拉取请求之前，请检查：

1. 覆盖率阈值是否发生了变化？
2. 是否有任何测试被删除、重命名或标记为跳过？
3. 工作流是否停止在 fork 或拉取请求上运行？
4. 是否有任何 CI 步骤现在被置于以前没有的条件之后？

对上述任何一项回答“是”，意味着你需要一个明确的理由才能继续。

2. 代码复用盲区

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

智能体的局部上下文并不包含你仓库中存在的全部情况。而你了解。

对于智能体拉取请求中的每个新辅助函数或实用工具，快速搜索一下。如果你找到了等效的，不要只留下评论。要求在合并前进行整合。留下重复逻辑的代价是，智能体会将其作为现有实现找到并进一步复制。

💡专业提示：要求智能体拉取请求中新增工具函数时，若超出规模阈值必须提供理由说明。这能及早发现重复性问题。

3. 幻觉式正确性

明显的幻觉（调用不存在的 API、引用作用域外的变量）会在 CI 中被捕获。真正危险的是更隐蔽的情况：代码能编译通过、能通过所有测试，但却是错误的。

分页中的差一错误。测试中从未触及的分支上缺少权限检查。在智能体从未考虑过的边界条件下短路失效的验证逻辑。仅在规模化运行时才会暴露的竞态条件下出现错误行为。

追踪代码，而非仅扫描代码。在差异代码中选取最关键路径。从输入开始，经过每次转换直至输出，全程追踪。检查边界条件（零值、最大值、空值）、外部值缺失的验证、每个分支的权限检查，以及出人意料的条件逻辑。

要求新增一个能在变更前行为下失败的测试。如果智能体无法编写出能捕获其声称修复的 bug 的测试，说明修复不完整或理解有误。

4. 智能体式失联

你提交了详尽的审查意见。你解释了问题所在，提供了上下文，指明了方向。然后拉取请求就沉默了。或者智能体回复了，但完全没抓住重点，在原地打转。你又投入一轮审查，仍然毫无收获。

没有结构化计划的大型拉取请求，与智能体放弃或偏离目标高度相关。拉取请求越大、范围越模糊，你投入审查时间却最终毫无进展的可能性就越高。

在对大型智能体拉取请求投入深度审查之前，先检查该拉取请求的历史记录。它在之前的轮次中是否及时响应？它是否有清晰的实现计划，还是智能体直接就开始写代码了？

如果没有计划，在写下任何一条评论之前，先要求对方分解任务。可复制粘贴的模板如下：

“这个拉取请求太大了，没有更清晰的实现计划我无法审查。能否将其拆分为范围更小的单元，或者添加一个摘要说明每个部分的功能及其结构设计理由？之后我很乐意进行审查。”

语气坚定、简短、不针对个人。这能为你省下一小时。

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

CI 智能体中的提示词注入是真实存在且被低估的问题。其模式如下：智能体工作流从拉取请求正文、议题或提交消息中读取内容。该内容被插入到提示词中。提示词被发送给模型。模型输出被传递到 shell 命令中。整个过程以 `GITHUB_TOKEN` 的权限运行。

当你审查任何调用大语言模型的工作流时，以下都是阻塞性问题：

• 不可信的用户输入、拉取请求正文、议题正文、提交消息，是否未经清理就被插入到提示词中？
• 当 `GITHUB_TOKEN` 只需要读取权限时，它是否被赋予了写入权限？
• 模型输出是否未经验证就被作为 shell 命令执行？
• 密钥是否对智能体步骤可访问，或被打印到日志中？

合并前的要求：工作流 YAML 中使用最小权限（`permissions: read-all` 是合理的默认值），在不可信内容进入提示词之前对其进行清理和转义，将“分析”步骤与“执行”步骤分开，并对任何影响生产环境的操作设置人工审批关卡，永远不要对模型输出执行 `eval`。

时间	步骤	操作内容
1–2 分钟	扫描与分类	查看文件列表和差异大小。将任务分类为范围狭窄（文档、CI、小改动）或复杂（多文件、逻辑、性能、测试）？该分类决定了后续所有审查的深度。
2–3 分钟	先检查 CI 变更	在阅读任何一行应用代码之前，先查看所有涉及 `.github/workflows`、测试配置、覆盖率设置或构建脚本的内容。标记任何削弱 CI 的内容。这是停止检查。
3–5 分钟	扫描新增工具函数	搜索新增的函数、辅助工具或模块。对每一个，在仓库中快速搜索以检查是否有重复。标记任何重复实现已有功能的内容。
5–8 分钟	追踪一条关键路径	选择最重要的逻辑变更。从头到尾追踪它：输入 → 转换 → 输出。检查边界条件、权限、意外的分支。这是你不能跳过的步骤。
8–9 分钟	安全边界	如果此拉取请求涉及任何调用大语言模型或处理不可信输入的工作流，请执行上述安全检查清单。
9–10 分钟	要求提供证据	对于任何非琐碎的逻辑变更，都需要编写一个在变更前行为下会失败的测试。对于有风险的变更没有回滚计划？要求提供一个。

何时应要求提交更小的拉取请求：

1. 代码差异涉及超过五个不相关的文件
2. 你无法用一句话描述该拉取请求的目的
3. 智能体没有实施方案，或者拉取请求正文为空
4. 持续集成（CI）正在失败，且代码差异中唯一的变更就是测试文件

让 Copilot 先审查

利用自动化审查做它擅长的事：在人工介入之前，先抓住那些机械性的问题。Copilot 代码审查会标记出风格不一致、明显的逻辑错误、缺失的错误处理以及类型不匹配。它负责处理低层次的扫描。这让你能腾出精力去做判断性的工作，那才是你时间真正有价值的地方。

将其视为一个先决条件，而非替代品。让 Copilot 先运行。如果它发现了明显的问题，让作者先处理，你再投入审查时间。

你可以通过针对你团队的自定义指令来调整这一点：标记任何修改 CI 阈值的操作，将新的工具函数提出来进行去重审查，检查每个外部输入是否都经过验证。你的指令越具体，自动化审查的用处就越大。

💡 专业提示：我最近尝试使用 Copilot SDK 将我自己的审查清单代码化。我不再需要在每个拉取请求上都记得去执行相同的安全检查，而是构建了一个工作流，它会拿我个人的检查清单——包括管理端点的身份验证、测试是否实际运行、安全的环境变量处理——自动对照代码差异进行检查。如果发现关键问题，它会阻止合并。

判断力是瓶颈，这没问题

代码的覆盖面在增长。拉取请求的数量在增长。你花在扫描模板代码上的时间应该减少。

不会减少的是你掌握的上下文信息。那些你了解你的系统、但并未记录在任何地方的认知。这才是让你的审查有价值的部分，也是无法被自动化的部分。

三个要点：

1. 任何削弱 CI 的行为都是硬性停止点。
2. 让智能体先扫描。你来追踪关键路径。
3. 将危险信号检查清单作为你在处理复杂智能体拉取请求时的默认操作。