利用 WRAP 法则高效清理积压工作：GitHub Copilot 的最佳应用技巧

GitHub 的工程师们提出了一个叫做 WRAP 的框架，旨在帮助开发者像带新同事一样带领 Copilot，轻松搞定技术债务和待办事项。WRAP 代表编写有效的 Issue、精炼指令、原子化任务、与智能体合作。

其实，GitHub 的工程师们已经使用 GitHub Copilot 编码智能体（coding agent） 超过一年了。通过这些实践，我们发现它在哪些方面能够真正帮助开发者节省时间和精力。于是，我们总结出了一个简单易记的缩写：WRAP。它的意思是：

• W – 编写有效的 Issue
• R – 精炼你的指令
• A – 原子化任务
• P – 与编码智能体合作

WRAP 能帮助你充分利用编码智能体的功能。比如说，你的待办事项里可能有很多难以处理的 Issue，也许为了推新功能，你不得不暂时放下技术债务，或者开发时间被客户 Bug 修复和大项目分割了。WRAP 可以让你快速上手，利用编码智能体处理那些过去可能没有时间应对的任务。

✍️ W – 编写有效的 Issue (Write effective issues)

WRAP 的第一步是为 GitHub Copilot 编码智能体编写有效的 Issue。实际上，你是在为智能体的成功提供必要的上下文，就像你会为新进团队成员提供的那样。

下面是一系列你应该考虑的准则：

• 把它当成刚接触代码库的新人来写 Issue。如果你能设想新人需要什么背景信息，基本上就能保证包含足够的信息，让编码智能体顺利完成任务。
• 给出描述性的标题。标题要能清晰表述工作的内容和位置。你可以给智能体布置多少任务，但任务多也意味着你需要处理大量的 Pull Request (PR) 审查！确保你的 Issue 标题能准确描述工作的性质和位置，这样智能体面板才好操作。
• 添加你想要的代码示例。如果你已经知道希望编码智能体如何实现（比如特定的错误处理方式），不妨在 Issue 中附上一个示例！这样的额外信息将大大提高你得到理想结果的机会。

以下是一些 Issue 的入门示例：

❌ 别这样写：

Update the entire repository to use async/await （把整个仓库更新为使用 async/await）

✅ 试着这样写：

Update the authentication middleware to use the newer async/await pattern, as shown in the example below. Add unit tests for verification of this work, ensuring edge cases are considered. （更新认证中间件以使用较新的 async/await 模式，如下面的示例所示。添加单元测试以验证此工作，确保考虑到边缘情况。）

async function exampleFunction() {     
  let result = await promise;
  console.log(result); //”done!”       
}

️ R – 精炼你的指令 (Refine your instructions)

接下来的步骤是确保你对 GitHub Copilot 自定义指令（Custom Instructions）进行了精炼，以提高编码智能体生成的 PR 的质量。你可以为不同的场景创建多种自定义指令。

• 仓库级自定义指令（Repository custom instructions）：这是一个很好的地方，用于存放适用于整个仓库的信息。例如，如果你有一个 Go 应用程序，并且喜欢特定的代码风格，这些规则就应该放在这里。随着时间的推移，这些指令的积累会改善你在该仓库与 GitHub Copilot 的互动效果。
• 提示：这是 GitHub Copilot 编码智能体的一个绝佳入门用例！不妨让它为你的仓库生成自定义指令。
• 组织级自定义指令（Organization custom instructions）：就像你可以为整个仓库创建自定义指令一样，也可以为整个组织创建一套。这对于适用于组织内所有仓库的要求非常合适。例如，可能你希望所有应用程序都必须编写测试。
• 定制化智能体（Coding agent custom agents）：与仓库和组织级自定义指令类似，你能够通过自然语言文本文件创建“定制化智能体”，应用在企业、组织或仓库层面。这些特别适合那些频繁发生，但不适用于每一次变更的重复性开发任务。例如，你可以创建一个专注于将新产品与特定仓库集成的“集成智能体（Integration Agent）”。

⚛️ A – 原子化任务 (Atomic tasks)

编码智能体非常擅长处理小型、原子化且定义明确的任务。不过，它也能应对大型问题！如果你想让它处理一个更复杂的问题，诀窍就在于将这个大问题拆解成多个小任务。

比如说，你肯定不想给 GitHub Copilot布置一个“把 300 万行 Java 代码重写为 Golang”的 Issue。这对于单个任务来说实在是太庞大了，审查这些变更也会变得极其困难。

相反，你可以把这个大问题拆分成 Copilot 可以轻松处理的小 Issue：

• 迁移认证模块到 Golang，确保所有现有的单元测试通过。
• 将数据验证工具包转换为 Golang，同时保持相同的 API 接口。

让我们一起聊聊如何管理 AI 助手

• 将用户管理控制器重写为 Golang，同时保持现有的 REST 端点和响应格式。

把一个庞大的问题拆解成小任务后，测试和验证每个部分就会变得简单多了，审查每个 Pull Request 也会轻松许多。

P – 与编码助手搭档 (Pair with the coding agent)

使用编码助手的时候，记得要清楚它作为智能体的优势和你作为人类的强项。明白这一点后，即使智能体的表现没达到你的期望，你也不会太沮丧。

人类在以下方面特别出色：

• 理解“为什么”：人类擅长理解任务背后的理由，还能判断任务的修改是否真正解决了造成该问题的根本原因。
• 处理模糊性：人类在应对复杂和不确定的情况时，明显比 AI 更有优势。比如说，如果你在问题描述中省略了一些细节（像是你希望进行怎样的测试），那么交给 GitHub Copilot 完成时，它可能会因为缺乏信息而无法执行。
• 跨系统思考：人类更善于考虑一项变更在不同系统中可能产生的影响。当编码智能体在一个仓库内完成某个任务时，它可能并不清楚这个任务会如何影响其他仓库，而这正是人类的强项。

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

• 不知疲倦的执行：你可以现在就给编码助手十个不同的任务，并期待它能同时处理每一个。
• 重复性任务：当人类面对重复性工作（比如在多个文件中更新命名规则）时，往往会感到厌烦或忽略细节，但 GitHub Copilot 在这方面非常有效！
• 探索可能性：如果你在考虑用多种不同方式解决一个问题，可以把每种方法交给编码助手，这样你能迅速了解到每种解决方案的效果，而不必消耗过多的开发资源。

总结

当你拥有 GitHub Copilot 和 WRAP 法则的时候，那些让人头疼的积压问题就不再是难题了。

需要更新依赖项吗？某些地方需要增加测试覆盖率？想在整个代码库里引入新的错误处理模式？或者你想迅速开始添加仓库指令，利用 GitHub Copilot 来帮忙？

使用 WRAP 来“收尾（wrap up）”你的积压工作吧！

---

️ 笔者锐评

GitHub 所提出的 WRAP 框架，实际上是一份 **”AI 时代的员工管理指南”**。

我们常说 AI 是我们的副驾驶，但在 WRAP 框架下，AI 更像是一个执行力强但缺乏全局观的初级工程师。

• Write（编写） 和 Refine（精炼） 其实是在教我们提高 “定义问题” 的能力。过去我们习惯自己写代码，现在需要学会如何清晰地向 AI 描述需求。这就像从“大头兵”晋升为“技术主管”，需要学会撰写技术规格和任务单。
• Atomic（原子化） 是拆解架构能力的体现。能否将一个庞大的重构目标分解为 AI 能轻松处理的小任务，是评估一个资深工程师在 AI 时代价值的重要标准。
• Pair（结对） 指出了人机协作的最高境界：人负责“为什么”和“什么”，AI 负责“怎么做”。

国内许多开发者仍在纠结于“AI 写的代码能不能直接用”，而 GitHub 已经提供了成熟的方法：通过标准化的流程（WRAP）来引导 AI，从而将不可控的 LLM 转变为可控的生产力。

不要把 Copilot 仅仅视为一个更聪明的“代码补全”工具，不妨把它当成你的助手，运用 WRAP 法则去管理它，你会发现自己的生产力将得到巨大的提升。