> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # 提交量涨了 400%，人没快 400%：AI 编程卡在评审 - URL: https://www.hubwiz.com/blog/agentic-engineering-four-stages-review-bottleneck/ - Published: 2026-11-07T08:39:34.000Z - Updated: 2026-11-07T08:43:00.000Z - Description: 一周 12 亿次提交，你没快 400%——增长卡在评审那 441%。四个阶段，四张清单，说清哪些活交给 agent、哪些判断必须留给人。 - Author: admin - Tags: AI 编程, GitHub Copilot, 代码评审, 软件工程 **今年 10 月，GitHub 一周收到超过 12 亿次提交，比一年前多 400% 以上——比 GitHub 2025 年全年的提交量还多。** 然后问自己一句：你觉得自己比去年高效了 400% 吗？ 写软件从来不只是"写"。AI 把实现这一步加速之后，压力挪到了别的地方。Faros AI 的一项研究发现，团队从低 AI 采用率升到高采用率后，**拉取请求在评审环节停留的时间延长了 441%**。 GitHub 的两位作者 Nick Liffen 和 Philip Holleran 把开发者的工作拆成四段——规划（Plan）、实现（Build）、验证（Verify）、观察（Observe）——然后逐段说明 agent 能接哪些活、哪些判断仍然必须由人来做。 ![GitHub Copilot](https://www.hubwiz.com/blog/content/images/2026/11/img_1d0013e366ae007d7722fe44bfc6d22e-800-2.jpg) ## 规划：让人和每个 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 | 把"所有检查通过"当成结论 | 这张表里真正值得盯的是最后一列。四个阶段里，只有验证阶段的失败是**会被别人看见的**（队列变长、PR 变肥），其余三个阶段的失败都很安静：计划没写下来、会话丢了、上线后只有一句"检查都过了"。所以真要改，先从"每段都必须留下一个别人能打开的东西"开始，而不是先从换模型开始。 还有一处需要泼冷水：这些能力按 GitHub 的套餐与预览状态提供——包防火墙对 npm 是公测，Agent Merge、Copilot Fusion 这类功能也各有开关。原文写的是能力边界，不是你明天就能全开。真正能立刻做、不依赖任何套餐的只有一件事：把改动切小。 原文：[Beyond code generation: A developer's guide to agentic engineering](https://github.blog/ai-and-ml/github-copilot/beyond-code-generation-a-developers-guide-to-agentic-engineering/?ref=hubwiz.com)（GitHub Blog，Nick Liffen & Philip Holleran，2026-11-06） 本文由汇智网 · Software 2.0 完整编译，转载请注明出处。 > **这是「AI 编程 / Vibe Coding」专题的一部分。** 完整地图见：[AI 编程 / Vibe Coding 完全指南](https://www.hubwiz.com/blog/vibe-coding-stack/) **相关阅读**：[Agent 老是散架？该修的是 harness，不是提示词](https://www.hubwiz.com/blog/harness-engineering-agent-guide-lunar/) · [AI 编程评测复盘：推理档位开满，36 题 196 个检查点](https://www.hubwiz.com/blog/ai-coding-eval-effort-cost-regression/)