提交量涨400%评审却慢441%：AI编程瓶颈不在写代码

今年10月，GitHub 单周提交量超过12亿次——比一年前高出400%以上。这比 GitHub 在2025年全年收到的提交还多。很可能，你比一年前生成了更多代码。但问问自己：你觉得自己比去年生产力高了400%吗？

构建软件所需的远不止一个好提示词。随着 AI 加速实现，软件开发者在其他环节感受到更大压力：Faros AI 的一项研究发现，当团队从低 AI 采用度转向高 AI 采用度时，拉取请求在评审中花费的时间延长了441%。

作为软件开发者，你收集需求并引导实现，评审变更并评估测试结果，然后调查生产环境中发生了什么。智能体可以帮助你在所有这些阶段更高效地工作：计划（Plan）、构建（Build）、验证（Verify）和观测（Observe）。我们将逐一介绍，在 GitHub 上，一个有效的智能体工程工作流是什么样子。

计划：让每个人和每个智能体都同步

看看这是否似曾相识。你正在规划一次 API 变更。设计在一个工具里，一项兼容性要求埋在 Slack 里，而一个旧的拉取请求解释了当前实现为何这样工作。在你写出有用的计划之前，你需要把这些细节连接起来，比较各种方案，并就现有客户端将如何继续工作达成一致。原本看似简单的规划任务，变成了数小时的搜索、交叉核对和追着答案跑。在实现尚未开始前，你就已经筋疲力尽了。

你可以用 Copilot 把那些分散的上下文汇集到一处，推演权衡取舍，并把决定转化为实施计划。

在团队已经工作的地方一起做计划。在 Slack 或 Teams 中使用 Copilot，与所有相关方协作——从产品经理、设计师到分析师和业务干系人。把来自已连接工具的上下文带进来，让团队能够一起核对假设、贡献想法并细化需求。

把达成一致的需求变成可执行的工作。让 Copilot 创建包含实施所需上下文和验收标准的 GitHub Issues，并拆分出可以单独处理的任务。

别让例行分类消耗计划时间。使用 GitHub Agentic Workflows 给 Issue 打标签并估算任务复杂度。把低复杂度任务直接分配给 Copilot，然后把你自己的时间花在更难的决策上。

给复杂工作应有的规划。在你偏好的 Copilot 界面中使用 Plan Mode，比较各种方案并细化实施计划。在把计划交给 Copilot 开始实施之前，先评审并批准它。

过去要花几天搜索和收集上下文的工作，现在能产出可评审的计划、明确的验收标准和范围清晰的 Issue，你的时间花在决策上，而不是检索上。然后，一旦你确定了方案，你其实已经让自己和你的智能体为实施这个计划做好了准备。

构建：一次推进不止一项任务

你已准备好把那个计划变成代码。但生活另有安排。你的智能体任务做到一半，下一场会议五分钟后开始，而你的狗已经盯着门看了二十分钟。然后会上有人指出，实现还需要处理一个边界情况。所有人都在同一时间有求于你。你想继续推进，但你没法同时出现在三个地方。

你可以让工作继续推进，而不必被绑在开始工作时的那台电脑上。

从另一台设备继续对话。会话连续性让你可以跨客户端接续同一个 Copilot 会话，因此你能在最方便的地方工作。

合上笔记本电脑后也让工作继续。Copilot 在云沙箱中运行任务，让执行不发生在你的机器上，并允许你离开稍后再回到会话。

处理不同任务时不让它们的编辑混在一起。Copilot 应用为每个会话提供独立的仓库副本，因此一个实现任务和一个文档更新不会共享同一个未完成的工作树。

把项目知识带到每个任务中。仓库指令记录约定和验证命令，而共享记忆存储 Copilot 可以在整个仓库中复用的有用事实。Copilot Dreaming 会审查符合条件的会话和拉取请求反馈，让记忆保持最新，并提出指令或技能更新建议。这意味着重新解释团队如何工作的时间更少，Copilot 在各个任务中提供的帮助更一致。

让模型匹配工作。选择 Copilot Fusion 来为任务挑选模型和推理深度，在需要时引入额外模型来评审解决方案。你设置投入程度，以平衡质量、成本和响应时间。

无论在哪里工作，都遵守公司规则。企业托管设置会把公司策略和已配置工具带到各个 Copilot 界面，减少你在不同客户端之间切换时的设置差异。

写代码不只是向 LLM 发射一个提示词，然后看看返回什么。而且，手头的工作比以往更多时，维持编码标准并按时交付项目可能很难。Copilot 借助共享的项目知识帮助任务独立推进，同时让你跨设备从上次中断的地方接续会话。这给你更多空间去处理实现决策，并在变化出现时应对它们。当工作完成时，你已经有聚焦的变更可供评审。

验证：把注意力花在真正重要的地方

花了一个小时折腾你的智能体，让它们朝正确方向前进，你以为大家都到了不错的位置。于是你打开一个标注为“小重构”的拉取请求。它改动了47个文件。你想要的是关于共享校验逻辑的反馈，但它被埋在对每个调用它的端点的更新、格式调整以及几百行生成的测试里。想到团队评审看板上无穷无尽的拉取请求列表，你怀疑这个要多久才能获得批准。

那个评审队列，就是441%在实践中的样子。你可以从两端缩短等待时间：让你的变更更容易被人评审，并让 Copilot 在任何人打开 diff 之前清理掉例行检查和修复。

把更小、更聚焦的拉取请求堆叠起来，而不是创建单个巨型变更。你和你的智能体可以用堆叠式拉取请求把有依赖关系的工作拆成更小的片段。这样每个 PR 都能被单独评审，依赖关系保持可见，并让团队在你的工作合并之前就基于它继续构建，从而不再被阻塞。

在例行质量问题消耗评审时间之前抓住它们。GitHub Code Quality 会对照编码实践和你的组织标准检查变更，在问题到达人工评审者之前将其捕获，为作者和评审者节省时间。

获取与变更匹配的评审帮助。Copilot 代码评审给出自动反馈：对简单变更做较轻量分析，对复杂变更做更深分析。你可以自己设置这种深度，也可以让 Copilot 为每个拉取请求选择。

在更大范围的代码库中检查安全。AI Scan 能在 CodeQL 覆盖范围之外的语言和文件中发现漏洞。AI secret detection 有助于识别模式匹配可能漏掉的非结构化密钥，例如密码。

让新依赖保持在策略范围内。许可证合规检查会在合并前对照公司规则检查依赖许可证。GitHub package firewall 目前针对 npm 处于公开预览阶段，可以阻止违反已配置安全策略的下载。

解决发现问题和后续工作，而不必照看每个拉取请求。Agentic Autofix 会为安全问题提出修复建议，而 Agent Merge 会自动处理失败的检查、评审意见和合并冲突——帮助你的拉取请求继续推进，并为合并做好准备。而且，如果你配置了它，一旦你的验证步骤通过，Copilot 甚至会合并你的拉取请求。

更小的变更，加上已经处理好的例行工作，意味着更少的来回沟通。你的评审者可以把注意力花在代码是否做了你意图中的事，以及哪里可能出错上。

观测：从发布之后发生的事情中学习

你的变更获得批准，部署检查通过，你终于可以把它从清单上划掉。第二天早上，你的值班仪表盘显示间歇性超时，支持团队报告有几个大客户受影响。现在你一边比对日志、发布历史和客户报告，一边有人问你是否应该回滚。“所有检查都通过”这句话，感觉不像昨天那么让人安心了。

把运维证据和工程上下文放在一起，这样你就能决定该做什么。

用真实行为核对假设。通过 Fabric 等连接器访问可观测性工具和业务数据后，Copilot 可以帮助调查哪些请求或客户群体受到影响。

把发现记录到有人能据此行动的地方。让 Copilot 起草一个带支撑证据和验收标准的 Issue，其中包括针对你发现的故障的回归测试。

把有用的经验带到未来工作中。审阅 Dreaming 提出的改进建议；Dreaming 会利用会话和仓库活动来帮助细化记忆、技能和代码评审指引。

弄清一次发布之后发生了什么，可能让你在仪表盘、对话和提交历史之间来回切换。有了 Copilot 帮助连接这些信息，你可以记录发现、创建后续 Issue，并改进未来任务可用的指引。你花更多时间决定需要改变什么，花更少时间重走排查过程。而你的下一个计划，将从你从人们实际使用的软件中学到的东西开始。

从哪里开始

挑一件已经在你手头的工作，并越过编码任务去看它。它需要什么上下文？你将如何评审和测试它？它发布之后，你如何知道它起作用了？

你不必一次性改变整个流程。从本周最让你沮丧的一件事开始，把一个智能体放上去。然后随着时间推移，扩展到流程的其他部分。一旦智能体在你整个工作流中提供帮助，你也许终于会觉得自己像提交量所说的那样高效。

我们在 GitHub Universe 2026 的“Agentic Engineering: Past the Pilot”现场讨论了这个话题。