Brittany Ellich & Jason Etcovitch
一个简单易记的首字母缩写——WRAP，将帮助你编写高质量的 Issue、优化指令表达，并充分发挥 GitHub Copilot 编码智能体的能力。

GitHub 的工程师们已经使用 GitHub Copilot 编码智能体超过一年时间，并在实践中不断总结它在哪些场景下能够真正为开发者节省时间与精力。基于这些经验，我们提炼出了一个实用、易记的首字母缩写：WRAP，它分别代表：

• W – Write effective issues（编写高质量的 Issue）
• R – Refine your instructions（优化你的指令）
• A – Atomic tasks（原子化任务）
• P – Pair with the coding agent（与编码智能体协作）

WRAP 能帮助你最大化发挥编码智能体的价值。举例来说，你的 Backlog 中可能堆积着大量难以优先排序的 Issue。也许为了尽快交付新功能，你不得不一再推迟技术债的改进；又或者，你的开发时间被分散在修复客户问题和推进一些更长期、更有热情的项目之间。通过 WRAP，你可以更快进入状态，借助 Copilot 编码智能体去处理那些过去因为时间有限而迟迟未能完成的任务。

编写高质量的 Issue

WRAP 的第一步，是确保你编写的 Issue 足够清晰、有效，能够直接分配给 GitHub Copilot 编码智能体。在本质上，这一步的目标是为编码智能体的成功创造条件——就像你在给一位新加入团队的成员布置任务时，会尽可能补充必要的背景信息一样。

以下是一些值得参考的编写准则：

• 把 Issue 当作是写给一位刚接触代码库的新成员。思考新人需要哪些背景信息，通常就能帮助你提供足够的上下文，让编码智能体更有效地完成任务。
• 编写具有描述性的标题，明确工作内容和发生位置。编码智能体的一大优势是你可以同时给它分配多个任务，但这也意味着你可能需要同时跟进多个 Pull Request 的评审。确保 Issue 标题清楚说明工作的性质以及涉及的模块或位置，有助于你在智能体面板中保持良好的可读性与可管理性。
• 提供期望结果的示例。如果你已经明确希望编码智能体采用某种实现方式（例如特定的错误处理模式），请在 Issue 中直接给出示例。这些额外的上下文信息，将显著提升最终产出符合预期的概率。

以下是一些示例，帮助你快速上手：

不要这样写：

更新整个仓库以使用 async/await

可以这样写：

将认证中间件更新为使用较新的 async/await 模式，参考如下示例实现。同时补充单元测试以验证本次修改，并确保覆盖相关的边界场景。

> 

async function exampleFunction() {

  let result = await promise;

  console.log(result); //”done!”

}

优化你的指令

WRAP 的下一步，是通过优化 GitHub Copilot 的自定义指令，来提升编码智能体所创建 Pull Request 的质量与一致性。你可以根据不同的使用场景，创建多种类型的自定义指令，从而获得更理想的结果。

• 仓库自定义指令 这是存放适用于整个代码仓库的信息的理想位置。例如，如果你在开发一个 Go 应用，并且对 Go 代码的编写方式有明确偏好，就应当将这些规范写入仓库自定义指令中。随着时间不断补充和完善这些指令，GitHub Copilot 在该仓库中的所有交互结果都会持续改进。你可以参考这一指南开始配置仓库自定义指令。
  • 提示：这也是 GitHub Copilot 编码智能体的一个绝佳入门使用场景！你可以直接让它为你的仓库生成一份自定义指令初稿。
• 组织自定义指令 与仓库级自定义指令类似，你也可以为整个组织配置一套 GitHub Copilot 自定义指令。这非常适合用于那些对组织内所有仓库都通用的规则。例如，你可能要求所有应用都必须创建并通过一定范围的测试。这类统一要求就非常适合放在组织自定义指令中。你同样可以参考这一指南来开始配置组织自定义指令。
• 编码智能体的自定义 Agent 类似于仓库和组织级自定义指令，自定义编码智能体可以通过自然语言文本文件来创建，并可应用在企业、组织或仓库级别。这类自定义 Agent 非常适合处理频繁出现、但并非每次变更都适用的重复性开发任务。例如，你可以创建一个 “Integration Agent”，专门用于将新产品集成到某个特定仓库中。你可以参考这一指南开始创建自定义 Agent。

原子化任务

编码智能体在处理小而清晰、定义明确的原子化任务时表现尤为出色。当然，它同样可以用于解决较大的问题——关键在于将大问题拆分为多个彼此独立的小任务。

例如，你通常不希望给 GitHub Copilot 分配这样一个 Issue：

将 300 万行 Java 代码全部重写为 Golang

这类任务的范围过大，不仅不适合一次性完成，对后续的代码评审来说也会非常痛苦。

相反，你可以将这个大问题拆解为多个 Copilot 可以分别处理的小 Issue，例如：

• 将认证模块迁移到 Golang，并确保所有现有单元测试通过
• 将数据校验工具包转换为 Golang，同时保持现有 API 接口不变
• 将用户管理控制器重写为 Golang，保留现有的 REST 接口与返回结果

通过将大问题拆分为原子化任务，你可以更轻松地对每一部分进行测试与验证，也能更高效地评审每一个 Pull Request。

与编码智能体协作

在与编码智能体协作时，理解它的优势以及你作为人类的优势至关重要。这种清晰的分工认知，可以有效减少未来因结果不符合预期而产生的挫败感。

人类更擅长的方面包括：

• 理解“为什么” 人类非常擅长理解任务产生的背景与动机，也能够判断某次修改是否真正解决了创建 Issue 的根本原因。
• 应对模糊性 相比 AI，人类更擅长处理模糊不清的需求。例如，作为人类，你可能可以省略某些细节，而编码智能体则往往需要非常明确的说明，比如你期望的测试类型或遥测数据。
• 跨系统思考 人类更善于理解一个系统中的改动对其他系统可能带来的影响。当编码智能体完成某个仓库中的任务时，它通常无法感知这些变化会如何影响其他仓库。跨系统影响的评估，更适合由人类来完成。

而编码智能体非常擅长的则包括：

• 不知疲倦的执行能力 你可以一次性给编码智能体分配十个不同的任务，并让它同时推进所有工作。
• 重复性任务 人类在处理大量重复性工作（例如在多个文件中统一命名规范）时，容易疲劳或遗漏细节，而 GitHub Copilot 在这类任务上表现得非常出色。
• 探索多种可能性 当你在考虑用不同方案解决同一个问题时，可以把每种方案分别交给编码智能体去尝试。这样，你就能快速了解各种策略可能带来的结果，而无需消耗大量开发资源。

带走这些要点

当你配备了 GitHub Copilot 与 WRAP 方法论，那些长期积压的 Backlog Issue 将不再有立足之地。

有需要更新的依赖项？某些地方亟需补充测试覆盖率？想在整个代码库中统一引入新的错误处理模式？又或者，你希望尽快完善仓库指令，并直接使用 GitHub Copilot 编码智能体来完成这些工作？

赶快用 WRAP，把 Backlog 一次性收尾！

开始使用 GitHub Copilot >