AI 写码提速后，工程瓶颈转向审查与验证

GitHub 在 10 月某一周接收了超过 12 亿次提交，比一年前增长 400%，甚至超过 2025 年全年的总和。但提交更多，不代表软件交付更快。原文引用的 Faros AI 研究发现，团队从低 AI 采用率转向高采用率后，PR 停留在评审阶段的时间增加了 441%。

这篇解读的核心是：AI 加速实现之后，瓶颈会转移到需求澄清、代码评审和上线反馈。GitHub 用 Plan、Build、Verify、Observe 四个阶段组织 agentic engineering，值得借鉴的是这套工作划分，以及每个阶段应该留下什么证据。

开始写代码前，先让人和 Agent 拿到同一份上下文

改一个 API，设计稿、Slack 里的兼容要求、旧 PR 中的历史决策，可能分散在不同地方。即使 Agent 很会写代码，漏掉其中一项，也可能沿着错误方向完成任务。

Plan 阶段要解决的就是这种信息缺口：收集材料、比较方案，再把决定变成可执行的任务。大白话讲，先把「为什么这样改、哪些行为不能变、怎样才算完成」写清楚。

原文建议在团队已有的 Slack 或 Teams 中使用 Copilot，结合已连接工具的上下文，让产品、设计、分析和相关负责人及时核对假设。达成一致后，再由 Copilot 创建 GitHub issues，带上背景和验收标准，并拆出可以独立处理的工作。

例行分流可以交给 GitHub Agentic Workflows，例如标记 issue、估算复杂度，把简单任务交给 Copilot。复杂任务则进入 Plan Mode，比较选项、细化方案，由人审阅批准后再实现。

这里需要保留一道判断：Agent 可以整理决策材料，但需求之间发生冲突时，谁承担兼容成本、哪个目标优先，仍然需要人决定。

并行执行能省等待，但要管住工作区和项目记忆

Build 阶段关心的是，开发者离开当前设备后，任务能否继续，以及多个任务会不会相互干扰。

原文列出的 session continuity 支持在不同客户端接续同一个 Copilot 会话；cloud sandboxes 让任务在云端执行，不占用本机。Copilot app 则为每个会话准备独立的仓库副本，避免功能开发和文档更新共用一个改到一半的工作区。

这些能力解决的是执行连续性。另一个问题是项目知识如何延续：Repository instructions 记录约定和验证命令，shared memory 保存可复用的仓库事实。Copilot Dreaming 会检查符合条件的历史会话和 PR 反馈，更新记忆，并提出 instructions 或 skills 的修改建议。

这类记忆值得审阅。某次任务的临时处理，未必适合升级成整个仓库的长期规则。

模型也可以按任务分配。Copilot Fusion 允许选择模型和推理深度，并引入其他模型复核方案，在质量、成本、延迟之间取舍；Enterprise managed settings 则让企业策略和配置工具跨 Copilot 使用界面生效。

但原文没有提供并行任务吞吐量、模型费用或返工率的对照数据。这些是能力描述，还不足以证明多开几个 Agent 就能提高交付效率。

评审队列变长，应该先缩小需要人判断的范围

原文用了一个很贴近日常的场景：标着「小重构」的 PR 改了 47 个文件，真正需要人判断的共享校验逻辑，却埋在调用方更新、格式变化和大量生成测试里。

评审慢，未必是 reviewer 看得不够快，也可能是提交者没有把决策范围整理好。

AI 生成代码越快，越需要控制单次变更的范围。

原文给出两条路径。第一条是使用 stacked pull requests，把存在依赖关系的大改动拆成多个小 PR，明确展示依赖，让每一部分都可以单独评审。

第二条是让自动化先处理常规问题。GitHub Code Quality 在人工评审前检查编码规范和组织标准；Copilot code review 根据变更复杂度采用较轻或较深的分析，深度可以手动设置，也可以由 Copilot 判断。

安全检查也分层进行。AI Scan 补充 CodeQL 未覆盖的语言和文件，AI secret detection 尝试识别密码等非结构化秘密。License compliance 按公司规则检查依赖许可证；GitHub package firewall 可以阻止违反所配置安全策略的下载，原文明确它针对 npm 处于 public beta。

发现问题后，Agentic Autofix 提议安全修复，Agent Merge 处理失败检查、评审意见和合并冲突。经过配置，Copilot 还可以在验证通过后合并。

不过，Verify 通过并不等于生产行为符合预期。Observe 阶段要把运行证据和工程上下文放在一起：通过 Fabric 等方式连接可观测性工具及业务数据，帮助定位受影响的请求和客户群体，再形成带证据、验收条件和回归测试要求的 issue。Dreaming 的后续建议则用于把教训带回项目记忆、skills 和评审指导。

四个阶段由此连起来：计划留下决定，实现留下变更，验证留下依据，上线观察留下可追踪的问题。

我的判断

我赞同原文的优先级：先让每个阶段留下别人能打开、能核对的材料，再考虑更换模型。没有验收条件的计划、没人理解的变更、只有「检查通过」的上线记录，都很难支持下一步判断。

其中最扎实的建议是缩小变更。这不依赖 Copilot，也适用于普通分支、人工评审和现有 CI。stacked pull requests 则是进一步管理依赖的做法，团队需要能处理后续变更的同步和调整，拆分本身也有维护成本。

数据部分要留一个问号。12 亿次提交、400% 增长和评审时间增加 441%，都来自原文引用的外部来源，作者没有独立复现。输入材料也没有交代 Faros AI 研究的样本、采用率划分和混杂因素，不能直接推导出 AI 使用越多，评审一定越慢。

同样，GitHub 的这套介绍带有产品指南色彩。文章引用的 GitHub Blog 发布于 2026-11-06，各项能力受套餐、预览状态和配置开关影响，不能把整套流程视为随时可启用的现成功能。

原文还提到一张对照表，但提供的正文没有包含表格内容，无法据此补出具体比较结果。它关于其他三个阶段「悄悄失败」的判断，更适合作为排查提醒，而非经过对照实验验证的结论。

能拿来做什么

• 给下一次 API 修改写一份简短任务说明，列清现有客户端的兼容要求、历史决策和验收条件，再让 Agent 开始实现。
• 当 AI 生成的重构同时包含逻辑修改、格式调整和调用方迁移时，按可独立判断的目的拆分 PR；有先后依赖时，把依赖关系写清楚。
• 把项目约定和实际可运行的验证命令放进仓库 instructions，并审阅 Agent 提议的记忆更新，避免临时方案变成长期约束。
• 为上线异常建立带日志证据、影响范围和回归要求的 issue，让下一轮任务接住生产反馈，而不只接住一句「部署成功」。