超越代码生成：面向开发者的智能体工程指南

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

构建软件不只是写好提示词。随着 AI 加速实现，软件开发者在其他环节感受到更大压力：Faros AI 的一项研究发现，当团队的 AI 采用率从低升到高时，拉取请求在审查中停留的时间延长了 441%。

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

Plan：让每个人和每个智能体达成共识

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

你可以使用 Copilot 将这些分散的上下文汇集到一个地方，权衡各种取舍，并把决策转化为实现计划。

• 在团队已经工作的地方一起规划。在 Slack 或 Teams 中使用 Copilot，与所有相关人员协作——从产品经理、设计师到分析师和业务利益相关者。从已连接的工具中引入上下文，让团队可以一起检查假设、贡献想法并完善需求。

• 将已达成一致的需求转化为可执行的工作。让 Copilot 创建带有实现所需上下文和验收标准的 GitHub Issues，并拆分出可以单独处理的任务。

• 避免例行分诊占用规划时间。使用 GitHub Agentic Workflows 为问题添加标签并估算任务复杂度。将低复杂度任务直接分配给 Copilot，然后把你的时间花在更难的决策上。

• 为复杂工作提供其所需的规划。在你偏好的 Copilot 界面中使用 Plan Mode，比较不同方案并完善实现计划。在将计划交给 Copilot 开始实现之前，审查并批准该计划。

过去需要数天搜索和收集上下文的工作，现在会产出一份可审查的计划、明确的验收标准以及划定范围的问题，而你的时间花在决策上，而不是检索上。然后，一旦你确定了一种方案，你就已经为自己和智能体做好了实现计划的准备。

Build：一次推进多个任务

你准备好把计划变成代码。但生活另有安排。你的智能体任务才做到一半，下一个会议五分钟后开始，你的狗已经盯着门看了二十分钟。然后会议上有人指出实现需要处理

• 合上笔记本电脑后，工作仍可继续。Copilot 在云沙箱中运行任务，把执行放在你的机器之外，并让你可以离开、稍后返回某个会话。

• 处理不同任务，而不混在一起编辑。Copilot 应用为每个会话提供仓库的隔离副本，因此一项实现任务和一次文档更新不会共享一个未完成的工作树。

• 把项目知识带入每个任务。仓库指令记录约定和验证命令，而共享记忆存储 Copilot 可在整个仓库中复用的有用事实。Copilot Dreaming 会审查符合条件的会话和 pull request 反馈，以保持记忆常新，并提出指令或技能更新。这意味着你花更少时间重复解释团队的工作方式，Copilot 在各项任务中提供的帮助也更一致。

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

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

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

验证：把注意力花在关键处

花了一个小时引导你的智能体，让它们朝正确方向推进后，你以为大家都已落到一个好位置。于是你打开一个标着“小型重构”的 pull request。它改动了 47 个文件。你本想获得关于共享验证逻辑的反馈，但它被埋没在对每个调用它的端点的更新、格式变更以及数百行生成的测试之中。想到团队评审板上无穷无尽的 pull request 列表，你不禁纳闷，这个要等多久才能获批。

那条评审队列就是现实中的 441%。你可以从两头缩短等待：让你的变更更容易由人评审，并让 Copilot 在任何人打开 diff 之前清理例行检查和修复。

• 堆叠更小、更聚焦的 pull request，而不是创建单个庞大变更。你和你的智能体可以使用堆叠 pull request 将相互依赖的工作拆成更小的部分。这样每个 PR 都能单独评审，依赖关系保持可见，并让团队在你的工作合并前就能在其之上继续开发，从而解除阻塞。

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

• 获得与变更相匹配的评审帮助。Copilot code review 提供自动化反馈，对简单变更做较轻量分析，对复杂变更做更深入分析。你可以自行设置该深度，或让 Copilot 为每个 pull request 选择。

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

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

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

常规工作已处理妥当的小改动意味着更少的反复沟通。你的审查者可以将注意力集中在代码是否实现了你的意图，以及可能出现的问题上。

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

你的改动获得批准，部署检查通过，你终于可以把它从清单上划掉了。第二天早上，你的值班仪表板显示间歇性超时，支持团队报告说有几个大客户受到影响。现在你在对比日志、发布历史和客户报告，同时有人问你是否应该回滚。“所有检查均已通过”听起来不像昨天那么令人安心了。

将运维证据和工程上下文结合起来，以便决定该做什么。

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

• 将发现记录在有人可以采取行动的地方。让 Copilot 起草一个包含支持证据和验收标准的问题，包括为你发现的故障编写回归测试。

• 将有用的经验带入未来的工作。查看 Dreaming 提供的改进建议，它利用会话和仓库活动来帮助完善记忆、技能和代码审查指导。

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

从哪里开始

从你手头已有的工作中挑一项，看看编码任务之外的部分。它需要什么上下文？你将如何审查和测试它？发布后你如何知道它是否有效？

你不必一下子改变整个流程。从这周最让你感到沮丧的事情开始，让一个智能体来处理它。然后随着时间的推移扩展到流程的其他部分。一旦智能体在你整个工作流中提供帮助，你也许终于会感到自己的生产力与提交数量所显示的一样高。

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

开始使用 Copilot >

标签：

• GitHub Copilot

• GitHub Universe

作者