夜雨聆风随着 AI 编码智能体普及，PR 数量激增但质量隐患凸显。本文分享了识别 CI 作弊、代码冗余及幻觉逻辑的实战经验。
你可能已经在大脑还没反应过来时，就点击了“核准”（Approve）按钮。测试全部通过，代码整洁漂亮，于是你合并了它。🚀
但那是 AI 智能体（Agent） 生成的代码——这种“丝滑”的审查体验，恰恰是问题所在。
2026 年 1 月的一项研究《更多代码，更少复用》（More Code, Less Reuse）发现：智能体生成的代码比人类编写的代码引入了更多的冗余和技术债务。 表面上看起来很干净，但债务是“无声”的。而且研究显示，审查者在批准这些代码时，心理压力反而更小，感觉更良好。💡
这不是在劝你放慢速度，而是提醒你要有意识地去审查。
🤖 智能体 PR 正在吞噬审查带宽
AI 生成代码的数量已经达到了令人震惊的程度。GitHub Copilot 的代码审查功能在不到一年的时间里增长了 10 倍，处理了超过 6000 万次审查。在 GitHub 上，每五次代码审查中就有一个涉及到智能体。这还仅仅是自动审查阶段，PR 本身的增长速度远超人类审查者的处理能力。
传统的“发起审查 -> 等待负责人 -> 合并”的闭环，在一名开发者可以在午饭前启动十几个智能体任务时彻底崩溃了。吞吐量呈指数级增长，但人类的审查能力却没有。 差距正在拉大。
你终究会面对智能体提交的 PR。关键在于，你是否能捕捉到那些真正致命的问题。
🔍 到底是谁（或什么）写了这个 PR？
在查看任何一行 Diff 之前，你需要先建立一个认知模型。
编码智能体是一个高效、刻板、遵循模式的“贡献者”，但它对你的故障历史、团队的边缘案例（Edge Case）经验，或者那些没写在仓库里的运营限制一无所知。它生成的代码看起来很完整，但这种“看起来很完整”的失效模式才是最危险的。⚠️
你才是那个携带上下文的人。 这不是负担，而是你的核心价值所在。审查中无法被自动化的部分是判断力，而判断力需要只有你才拥有的上下文。
如果你正在开启一个由智能体生成的 PR，请在请求审查前修改 PR 描述。智能体通常很啰嗦，它们喜欢用文字描述那些通过看代码就能理解的东西。在需要上下文的地方添加 Diff 注释，并在艾特别人之前自己先过一遍。这不仅是为了检查正确性，更是为了发出一个信号：你已经验证了智能体准确捕捉了你的意图。
在使用智能体时，自审（Self-review） 并非可选项，而是对审查者时间的最基本尊重。
🚩 必须警惕的红线信号
1. CI 作弊（CI Gaming）
当智能体无法通过 CI 测试时，它们有一个简单粗暴的解决路径：删除测试、跳过 Lint 检查，或者在测试命令后面加上 || true。 有些智能体真的会这么干。
任何削弱 CI 的变更都是“一票否决”的障碍（Blocker）。 绝无例外。在批准任何智能体 PR 之前，请检查：
单元测试覆盖率阈值是否被修改？ 是否有测试被移除、重命名或标记为跳过？ 工作流是否停止在 Fork 或 PR 上运行？ 是否有 CI 步骤被添加了以前没有的限制条件？
只要其中任何一项为“是”，在得到明确合理解释前，绝不合并。🚫
2. 代码复用盲区（Code Reuse Blindness）
这是审查者收益最高的操作。智能体会寻找“先例”，它们会发现代码库中的某种模式并进行复制，但往往不会检查是否已经存在执行相同功能的工具函数。
典型症状：
新增了与现有工具函数功能重合、但名称略有不同的函数。 在多处重新实现验证逻辑。 编写了原本就在共享模块中的中间件。 “几乎一样”但命名不同的 Helper 函数。
智能体的局部上下文看不到仓库的全貌，但你可以。对于 PR 中的每个新 Helper 或 Utility，请做一个快速搜索。如果发现重复，不要只留个评论，要求在合并前必须整合。 否则，智能体以后会把这些冗余代码当成“先例”继续无限复制。
💡 专家建议： 对于超过一定规模的智能体 PR，要求作者必须说明新增工具函数的理由。这能尽早拦截重复问题。
3. 幻觉正确性（Hallucinated Correctness）
明显的幻觉（如调用不存在的 API、引用作用域外的变量）会被 CI 拦截。最危险的是那些微妙的幻觉：代码能编译，能通过所有测试，但逻辑是错的。
比如：
分页中的“差一错误”（Off-by-one errors）。 测试从未覆盖到的分支缺少权限检查。 在某种边缘情况下失效的验证逻辑。 只有在大规模并发下才会暴露的竞态条件。
要追踪（Trace），而不仅仅是扫描（Scan）。 挑选 Diff 中最关键的一条路径，从输入开始，追踪每一次转换，直到输出。检查边界条件（零值、最大值、空值）、外部输入的验证、每个分支的权限检查等。
要求提供证据： 如果智能体无法编写一个能复现该 Bug 的失败测试，那么这个修复就是不完整的，或者它根本没理解问题所在。
4. 智能体“幽灵化”（Agentic Ghosting）
你留下了一份详尽的审查意见，提供了背景和方向。结果 PR 没动静了，或者智能体回应了但完全没领会要点，在那绕圈子。你又投入了一轮沟通，依然无果。
PR 越大且缺乏结构化计划，智能体就越容易“跑路”或产生偏差。 你会把宝贵的审查时间浪费在一个毫无结果的任务上。
在深入审查大型智能体 PR 之前，请先看它的历史：
它在之前的轮次中是否有响应？ 它是否有清晰的实施计划，还是直接就开始写代码了？
如果没有计划，请直接要求它先拆解任务。回复模板如下：
“这个 PR 太大了，在没有更清晰的实施计划前我无法审查。你能把它拆成更小的单元，或者总结一下每个部分的作用和架构逻辑吗？完成后我会再来审查。”
语气坚定、简短且对事不对人。这能帮你省下一小时。⏳
5. 工作流中的不可信输入
CI 智能体中的提示注入（Prompt Injection） 是一个常被低估的风险。
场景：一个智能体工作流读取 PR 描述、Issue 或提交信息，将其插入 Prompt，然后模型输出被直接传给 Shell 命令运行。而这一切都拥有 GITHUB_TOKEN 权限。
审查工作流 YAML 时，以下是“红牌”行为：
未经清理的外部输入直接插入 Prompt。 只需要读取权限却配置了 GITHUB_TOKEN的写权限。模型输出被直接当作 Shell 命令执行（ eval）。Secret 密钥可被智能体步骤访问或打印到日志。
合并前的要求： 遵循最小权限原则，对外部输入进行转义，将“分析”步骤与“执行”步骤分离，并加入人类审批关口。
⏱️ 10 分钟快速审查清单
| 1-2 min | 扫描与分类 | |
| 2-3 min | 优先检查 CI 变更 | .github/workflows、测试配置、覆盖率设置的行为，必须先过关。这是停止信号检查。 |
| 3-5 min | 扫描新工具类 | |
| 5-8 min | 追踪关键路径 | 不可跳过的一步。 |
| 8-9 min | 安全边界 | |
| 9-10 min | 索取证据 |
💡 什么时候该要求拆分 PR？
Diff 涉及超过 5 个不相关的文件。 你无法用一句话描述这个 PR 的目的。 智能体没有实施计划，或者 PR 描述是空的。 CI 失败了，但 Diff 里只修改了测试文件。
🚀 让 Copilot 先替你“挡一阵”
利用自动化工具捕捉那些机械性的问题：格式不一致、明显的逻辑错误、缺失的错误处理、类型不匹配。让 AI 负责低级别的扫描，把你解放出来去做更有价值的判断工作。
把自动化审查当成前提条件，而非替代品。如果 Copilot 已经发现了一些低级错误，让作者（或智能体）先改完，你再介入。
💡 进阶技巧： 尝试把你的团队规范或个人审查清单（如：管理端接口必须加权限检查、测试必须真实运行、环境变量安全处理）编写成自动化的工作流。如果发现致命问题，直接拦截合并。
⚖️ 判断力是瓶颈，这没关系
代码的表面积在增长，PR 的数量在爆炸。你花在扫描模板代码上的时间应该缩短。
但你拥有的上下文不会缩短。 那些关于系统的、没有写在纸面上的知识，才是你审查的真正价值。
核心总结：
任何削弱 CI 的行为都是硬障碍。 让智能体先扫，你负责追踪关键路径。 面对复杂的智能体 PR，默认开启红线检查清单。
笔者锐评
这篇文章精准捕捉到了当下开发者的一种“集体无意识”：当 AI 帮我们写好代码、写好测试、甚至写好注释时，我们往往会因为“看起来太对了”而产生一种盲目的信任感。
这种“静默债务”非常可怕，它不像 bug 那样会立即爆发，而是像慢性病一样侵蚀代码库的健康。在国内追求“快”的大环境下，很多团队为了 KPI 疯狂堆叠 AI 生成的代码，却忽视了审查能力的建设。
判断力是无法外包的。 越是 AI 盛行的时代，能够“看透”代码背后逻辑、携带全局上下文的高级工程师就越稀缺。不要让自己沦为 AI 代码的“人肉图章”，保持那种对代码的警惕感，才是我们在这个时代的护城河。
求点赞 👍 求关注 ❤️ 求收藏 ⭐️你的支持是我更新的最大动力！
