AI 编程

提交量涨了 400%，人没快 400%：AI 编程卡在评审

一周 12 亿次提交，你没快 400%——增长卡在评审那 441%。四个阶段，四张清单，说清哪些活交给 agent、哪些判断必须留给人。

今年 10 月，GitHub 一周收到超过 12 亿次提交，比一年前多 400% 以上——比 GitHub 2025 年全年的提交量还多。

然后问自己一句：你觉得自己比去年高效了 400% 吗？

写软件从来不只是"写"。AI 把实现这一步加速之后，压力挪到了别的地方。Faros AI 的一项研究发现，团队从低 AI 采用率升到高采用率后，拉取请求在评审环节停留的时间延长了 441%。

GitHub 的两位作者 Nick Liffen 和 Philip Holleran 把开发者的工作拆成四段——规划（Plan）、实现（Build）、验证（Verify）、观察（Observe）——然后逐段说明 agent 能接哪些活、哪些判断仍然必须由人来做。

规划：让人和每个 agent 看同一份材料

看看这个场景熟不熟。你要改一个 API。设计在一个工具里，一条兼容性要求埋在 Slack 里，还有一个旧 PR 解释了现在这段实现为什么必须这样做。你要写出一份有用的计划，得先把这些细节串起来、比较几种方案、再和所有人确认现有客户端怎么继续工作。看起来是件直白的规划工作，实际变成了几个小时的搜索、交叉核对和追问。实现还没开始，你已经累了。

你可以用 Copilot 把这些散落各处的上下文收拢到一处，把权衡推演清楚，再把这些决定变成一份实施计划。

在团队本来就工作的地方一起规划。 在 Slack 或 Teams 里用 Copilot，把产品经理、设计师、分析师和业务相关方都拉进来。接入已连接工具的上下文，让团队当场核对假设、补充想法、一起把需求改细。
把谈定的需求变成可执行的工作。 让 Copilot 创建 GitHub Issue，带上实现所需的上下文和验收标准，并把可以分开处理的任务拆出来。
别让例行分诊吃掉规划时间。 用 GitHub Agentic Workflows 给 issue 打标签、估任务复杂度。低复杂度任务直接派给 Copilot，你的时间留给更难的判断。
复杂的工作给它应有的规划。 在常用的 Copilot 界面里用 Plan Mode 比较方案、打磨实施计划。计划经你评审批准之后，再交给 Copilot 开始实现。

过去要花几天搜索和收集上下文的事，现在产出的是一份可评审的计划、明确的验收标准和范围圈定的 issue；你的时间花在决定上，而不是翻找上。方案定了之后，你和你的 agent 也已经站在实现这份计划的起点上了。

实现：同时推进不止一件事

计划可以变成代码了，但现实总有别的安排。agent 一个任务干到一半，你的下一个会议五分钟后开始，狗已经盯着门看了二十分钟。然后会上有人指出，实现还得处理一个边界情况。所有人同时都在向你要东西。你想继续推进，但你没法同时出现在三个地方。

你可以让工作继续走，而不用被拴在启动它的那台机器上。

换台设备接着聊。 会话连续性（session continuity）让你在不同客户端里接上同一个 Copilot 会话，在哪儿方便就在哪儿干。
合上笔记本，活还在跑。 Copilot 在云端沙箱里跑任务，执行不占你的机器，也允许你离开之后再回来。
不同任务不要互相污染。 Copilot 应用给每个会话独立的仓库副本，一个实现任务和一次文档更新不会共用一份没做完的工作树。
把项目知识带进每个任务。 仓库指令（repository instructions）记下约定和验证命令；共享记忆（shared memory）保存 Copilot 可以在整个仓库里复用的事实。Copilot Dreaming 会审视符合条件的历史会话和 PR 反馈，让记忆保持新鲜，并提议更新指令或技能。也就是说，你不用反复解释团队是怎么干活的，Copilot 在不同任务上给出的帮助也更一致。
按任务配模型。 用 Copilot Fusion 为任务选择模型和推理深度，需要时再拉额外模型来复审方案。你设定努力档位，在质量、成本和响应时间之间取平衡。
在哪儿干活都守公司规则。 企业托管设置（enterprise managed settings）把你的公司策略和已配置的工具带到各个 Copilot 界面，减少你在客户端之间切换时的设置差异。

写代码不是朝 LLM 甩一句提示、看回来什么就算完。手上堆的活比以往都多，坚持编码标准、按时交付也变得更难。Copilot 靠共享的项目知识让各个任务各自推进，同时允许你跨设备接着上次的会话继续干。这给你留出更多空间去处理实现决策、接住临时冒出来的变化。等工作结束，等你的是一批聚焦的、可以直接评审的改动。

验证：把注意力花在值得的地方

你花了一个小时把 agent 掰到正确方向，觉得终于落地了。于是你开了一个标着"小重构"的 PR。它改了 47 个文件。你想让人看的只是共享校验逻辑，但它埋在对每个调用它的端点的更新、格式化改动和几百行生成的测试里。你开始琢磨这份 PR 要多久才能拿到批准，毕竟团队的评审板上还有一长串拉取请求。

那串评审队列，就是 441% 的现实形态。你可以从两端缩短等待：让改动对人更好评审，同时让 Copilot 在人打开 diff 之前清掉例行检查和修复。

叠小 PR，而不是造一个巨大改动。 你和 agent 可以用叠放式拉取请求（stacked pull requests）把有依赖的工作拆成更小的片。每份 PR 可以单独评审，依赖关系保持可见，团队也能在你的工作合并之前就在它上面继续构建。
在例行质量问题吃掉评审时间之前拦住它。 GitHub Code Quality 按编码实践和组织的标准检查改动，在问题到达人类评审者之前抓住它，给作者和评审者都省时间。
让评审帮助与改动匹配。 Copilot 代码评审给出自动反馈：简单改动用更轻的分析，复杂改动用更深的分析。你可以自己设定深度，也可以让 Copilot 逐份 PR 决定。
安全扫描覆盖更多代码库。 AI Scan 能找到 CodeQL 覆盖范围之外的语种和文件里的漏洞。AI 密钥检测帮忙识别非结构化的密钥，比如密码——这类东西靠模式匹配容易漏。
新依赖守住政策。 许可证合规检查在合并前把依赖许可证对一遍公司规则。GitHub 的包防火墙（目前对 npm 公测）可以拦下违反已配置安全策略的下载。
处理发现项和后续工作，不必盯守每份 PR。 Agentic Autofix 为安全问题提出修复，Agent Merge 自动处理失败的检查、评审意见和合并冲突——让 PR 继续往前走到可合并状态。如果你配置了，验证步骤通过之后 Copilot 甚至会直接合并。

更小的改动，加上例行工作已经被处理掉，意味着更少的来回。评审者可以把注意力放在两件真正要紧的事上：代码是不是做了你想要的，以及哪里可能出错。

观察：从上线的结果里学

改动批准了，部署检查通过了，你终于可以把它从清单上划掉。第二天早上，值班看板显示间歇性超时，支持反馈有几个大客户受影响。现在你一边对日志、发布历史和客户反馈，一边有人在问要不要回滚。昨天那句"所有检查都通过"，今天听上去没那么让人安心了。

把运维证据和工程上下文摆在一起，你才有依据决定下一步。

用真实行为核对假设。 通过 Fabric 之类的连接器接入你的可观测性工具和业务数据，Copilot 可以帮忙排查是哪些请求、哪些客户群受影响。
把发现记录到有人能行动的地方。 让 Copilot 起草一份 issue，附上支撑证据和验收标准，其中包括针对这次暴露的故障的回归测试。
把有用的教训带进后面的工作。 看看 Dreaming 建议的改进——它利用会话与仓库活动来打磨记忆、技能和代码评审指引。

弄清一次发布之后发生了什么，本来会让你在仪表盘、对话和提交历史之间来回跳。Copilot 帮忙把这些信息连通之后，你可以记录发现、创建后续 issue，并改进未来任务可用的指引。你花更多时间决定要改什么，更少时间重走一遍调查。而你下一份计划，会从"人真正在用的软件"里学到的东西开始。

从哪开始

挑一件已经压在你手上的活，然后越过编码任务本身看：它需要什么上下文？你打算怎么评审和测试它？上线之后，你凭什么知道它成了？

你不必一次性改掉整个流程。从这周最让你烦的那件事开始，把 agent 放上去。然后随着时间扩到流程里的其它部分。等 agent 在全流程上都在帮忙，你也许终于会觉得，自己的产出对得起提交数了。

这个话题我们在 GitHub Universe 2026 的"Agentic Engineering: Past the Pilot"上现场讲过。

我们的整理：四段各自的产物与失败点

GitHub 这篇原文是产品指南，读起来每段都对，但不容易落地。把它压成一张表，四段的差别立刻清楚：

阶段	谁在做	应该留下的产物	最常见的失败
规划	人主导，agent 收集与提问	一份可评审的计划、验收标准、范围圈定的 issue	计划只存在对话里，没人再打开
实现	agent 为主，人定方向	隔离的工作副本、可单独评审的小 PR	会话丢在某一台机器上；几个任务共用一份没做完的工作树
验证	机器先过，人后审	更小的 diff、例行检查已清、评审意见聚焦在意图	评审队列膨胀——441% 就是这么来的
观察	人主导，agent 关联证据	带证据与回归测试的 issue	把"所有检查通过"当成结论