跳到正文
GitHub Blog · AI & ML· Nick Liffen·· 3 小时前AI 评分47

GitHub Copilot 智能体工程实战指南:超越代码生成

Beyond code generation: A developer’s guide to agentic engineering

AI 导读

GitHub 发布开发者智能体工程指南,介绍如何用 Copilot 覆盖 Plan、Build、Verify、Observe 四个阶段的完整工作流。文中指出 10 月 GitHub 一周收到超 12 亿次 commit,同比增长超 400%;Faros AI 研究发现团队 AI 采用率从低到高时 PR 审核时间延长 441%。

正文 · AI 翻译

编写代码变得更快了,但围绕它的工作并没有。了解如何借助 GitHub Copilot 进行规划、编写代码、审查变更和排查生产问题,以及哪些工作仍然需要你的判断。

2026年11月6日

|

8 分钟

  • 分享:

今年 10 月,GitHub 在一周内收到了超过 12 亿次提交——比一年前增加了 400% 以上。这比 GitHub 在整个 2025 年收到的提交还要多。很可能,你现在生成的代码比一年前更多了。但问问自己:你觉得自己比去年效率高了 400% 吗?

构建软件远不止写一个好提示词。当 AI 加速了实现过程,软件开发者在其他地方感受到更大的压力:Faros AI 的一项研究发现,当团队从低 AI 采用率转向高 AI 采用率时,拉取请求在审查中停留的时间延长了 441%。

作为软件开发者,你需要收集需求并引导实现方向,审查变更并评估测试结果,然后排查生产环境中发生的问题。智能体可以在所有这些阶段帮助你更高效地工作:规划(Plan)、构建(Build)、验证(Verify)和观察(Observe)。我们将带你看一个有效的智能体化工程工作流在 GitHub 上是什么样子。

规划:让每个人和每个智能体达成共识

看看这是否听起来很熟悉。你正在规划一次 API 变更。设计方案在一个工具里,一个兼容性要求埋在 Slack 中,而一个旧的拉取请求解释了当前实现为何如此设计。在你能写出一份有用的计划之前,你需要把这些细节串联起来、比较各种方案,并就现有客户端如何继续正常工作达成一致。看似简单的规划任务变成了数小时的搜索、交叉核对和追问答案。实现还没开始,你已经精疲力竭了。

你可以使用 Copilot 将这些分散的上下文汇集到一处,权衡各种取舍,并将决策转化为实施计划。

  • 在团队已经使用的地方协同规划。使用 Copilot in Slack 或 Teams 与所有相关人员协作——从产品经理、设计师到分析师和业务利益相关者。引入来自已连接工具的上下文,让团队能够检验假设、贡献想法,并共同完善需求。
  • 将商定的需求转化为可执行的工作。让 Copilot 创建 GitHub Issues,附上实施所需的上下文和验收标准,并拆分出可以单独处理的任务。
  • 别让例行分类消耗规划时间。使用 GitHub Agentic Workflows 为你的 issue 添加标签并评估任务复杂度。将低复杂度任务直接分配给 Copilot,然后把时间花在更困难的决策上。
  • 为复杂工作提供所需的规划。在你偏好的 Copilot 界面中使用 Plan Mode 来比较各种方案并完善实施计划。在将计划交给 Copilot 开始实施之前,先审查并批准该计划。

过去需要数天搜索和收集上下文的工作,现在产出的是一份可供审查的计划、明确的验收标准和范围清晰的 issue,而你的时间则花在决策上而不是检索上。然后,一旦你确定了方案,你和你手下的智能体就已经为实施计划做好了准备。

构建:同时推进不止一项任务

你已经准备好把计划变成代码。但生活总有别的安排。你的智能体正执行到任务一半,下一个会议五分钟后就要开始,而你的狗已经盯着门二十分钟了。这时会议中有人指出实现需要处理一个边界情况。所有人同时都需要你。你希望继续推进工作,但你无法同时出现在三个地方。

你可以让工作继续推进,而不必被拴在你最初开始工作的那台电脑前。

  • 从另一台设备继续你的对话。会话延续让你在不同客户端之间接续同一个 Copilot 会话,因此你可以在最方便的地方工作。
  • 合上笔记本电脑后让工作继续。Copilot 在云端沙箱中运行任务,把执行过程移出你的机器,让你可以稍后离开再回到会话。
  • 处理多个任务而不混淆彼此的修改。Copilot 应用为每个会话提供仓库的隔离副本,因此一个实现任务和一个文档更新不会共享同一个未完成的工作树。
  • 把项目知识带入每个任务。仓库指令记录约定和验证命令,而共享记忆存储 Copilot 可在整个仓库范围内复用的有用信息。Copilot Dreaming 会审查符合条件的会话和 pull request 反馈,保持记忆最新,并提议更新指令或技能。这意味着你无需反复解释团队的工作方式,Copilot 在各个任务中的帮助也更加一致。
  • 让模型与工作相匹配。选择Copilot Fusion 为任务挑选模型和推理深度,并在需要时引入额外的模型来审查解决方案。你可以设定投入程度,以平衡质量、成本和响应时间。
  • 无论在哪里工作都遵守公司规则。企业托管设置将你公司的策略和已配置的工具贯穿所有 Copilot 界面,减少你在不同客户端之间切换时的配置差异。

写代码不只是向你的 LLM 发送一个提示然后看看返回了什么。而且当你的工作比以往任何时候都多时,维护你的编码标准并按时交付项目可能会变得困难。Copilot 借助共享的项目知识让任务独立推进,同时让你可以在不同设备上从中断处接续会话。这给了你更多空间去推敲实现决策,并处理随时出现的变化。而当工作完成时,你就有了集中且便于审查的改动。

验证:把注意力花在刀刃上

在花了一个小时引导你的智能体朝正确方向前进后,你觉得自己和它们都落在了不错的地方。于是你打开一个标记为“小型重构”的 pull request。它修改了 47 个文件。你希望获得关于共享验证逻辑的反馈,但它被淹没在对每个调用它的端点的更新、格式更改以及数百行生成的测试之中。考虑到团队审查板上那望不到头的 pull request 列表,你不知道要等多久才能获得批准。

这个审查队列正是现实中那 441% 的体现。你可以从两端缩短等待时间:让你的改动更容易被人审查,并让 Copilot 在有人打开 diff 之前完成例行的检查和修复。

  • 用更小、更聚焦的拉取请求堆叠起来,而不是创建一个庞大的单一变更。你和你的智能体可以使用堆叠式拉取请求把有依赖关系的工作拆分成更小的部分。这让每个 PR 都可以单独评审,让依赖关系保持可见,并且在你的工作合并之前就允许团队基于它进行开发,从而解除阻塞。
  • 在常规质量问题消耗评审时间之前就把它们拦下。GitHub Code Quality 会依据编码规范和贵组织的标准检查变更,在问题到达人类评审者之前将其捕获,为作者和评审者都节省时间。
  • 获得与变更相匹配的评审帮助。Copilot code review 提供自动化反馈,对简单的变更进行轻量分析,对复杂的变更进行深入分析。你可以自己设定分析深度,也可以让 Copilot 为每个拉取请求自动选择。
  • 在代码库的更大范围内检查安全性。AI Scan 能在 CodeQL 覆盖范围之外的语言和文件中发现漏洞。AI secret detection(AI 密钥检测)帮助识别模式匹配可能遗漏的非结构化密钥,例如密码。
  • 让新依赖符合公司策略。License compliance 会在合并之前根据贵公司的规则检查依赖的许可证。GitHub package firewall 目前已针对 npm 开放公开预览,可以阻止违反已配置安全策略的下载。
  • 解决发现的问题和后续工作,而无需时刻盯守每个拉取请求。Agentic Autofix 会为安全问题提出修复建议,而 Agent Merge 会自动处理失败的检查、评审意见和合并冲突——帮助你保持拉取请求持续推进并为合并做好准备。而且,如果你进行了配置,一旦你的验证步骤全部通过,Copilot 甚至会帮你合并拉取请求。

更小的变更加上已经处理好的常规工作,意味着更少的来回沟通。评审者可以把注意力放在代码是否实现了你的意图、以及可能出现什么问题上。

观察:从上线后的实际情况中学习

你的变更获批了,部署检查也通过了,你终于可以把它从待办清单上划掉。第二天早上,你的值班仪表盘显示出现间歇性超时,支持团队报告几家大客户受到影响。此刻你正在比对日志、发布历史和客户报告,同时有人在问是否应该回滚。“所有检查都通过了”这句话,听起来已不像昨天那么让人安心。

把运维证据和工程上下文整合在一起,以便你决定该怎么做。

  • 用真实行为检验假设。通过 Fabric 等连接器访问你的可观测性工具和业务数据,Copilot 可以帮助调查哪些请求或客户群体受到了影响。
  • 把发现记录在别人可以着手处理的地方。让 Copilot 起草一个附带支持证据和验收标准的 issue,包括针对你发现的故障编写回归测试。
  • 把有用的经验带入未来的工作。查看 Dreaming 建议的改进,它会利用会话和仓库活动来帮助优化记忆、技能和代码评审指南。

发布之后弄清楚究竟发生了什么,可能会让你在仪表盘、对话记录和提交历史之间来回奔波。有了 Copilot 帮助串联这些信息,你可以记录自己的发现、创建后续 issue,并改进可供未来任务使用的指导。你把更多时间花在决定需要改变什么上,而花更少的时间重走调查之路。而你的下一个计划,将始于你从人们实际使用的软件中学到的东西。

从哪里开始

拿一件你手头已有的工作,把眼光放到编码任务之外。它需要什么背景信息?你会如何审查和测试它?发布之后你又如何知道它奏效了?

你不必一次性改变整个流程。从本周最让你沮丧的一件事开始,把一个智能体放到它上面。然后随着时间推移,扩展到流程的其他部分。一旦智能体在你的整个工作流程中发挥作用,你也许终于能感受到与提交数量所显示的相称的生产力。

我们在 GitHub Universe 2026 上以现场形式讨论过这个话题,议题为“智能体工程:超越试点”。

相关文章

我们也做新闻通讯

在我们专为开发者打造的双周通讯中发现技巧、技术指南和最佳实践。

来源: GitHub Blog · AI & ML · github.blog