GitHub Copilot 发布“Harness”工作流：用单一工具完成原型、规划、实现与代码审查

如果你现在被 AI 搞得不知所措，你并不孤单。

每天似乎都有新工具、新 MCP、新模型、新技能、新工作流、新功能、新社交帖子，内容无非是某种形式的“嘿，看！我用这个奇怪的提示词彻底搞懂了 AI。”

我……不信你。

我每天都和 AI 打交道，而我发现的是，少即是多。真正带来改变的，并不是我安装了什么、配置了什么，或者诱骗智能体去做了什么。那些东西挺有意思，但说到底感觉都是噱头。

我发现，我的生产力提升最大的部分，来自我如何使用 harness，以及我对它的理解有多深。

所以在这篇文章里，我要分享一个简单的工作流，你只需使用 GitHub Copilot 的现有功能，就能大幅提升你使用 AI 的效率。不需要奇怪的提示词。不需要别人似乎都知道的技能。只需要 harness。你需要的全部就是 harness——基本上是这样。

1. 选一个工具，随便哪个都行

这很明显，对吧？选一个工具！太简单了！

但即便是在 GitHub Copilot 家族内部，也有非常多的选择。仅举几例，就包括 CLI、全新的 GitHub Copilot 应用、VS Code、Visual Studio 以及 JetBrains。

好消息是，这些体验正越来越多地集中到同一套 harness 之上。具体细节可能因工具而异，但核心工作流是一致的。学一次 harness，处处都能用。

话虽如此，我确实认为学习 harness 是关键，而学习它的最佳方式就是尽可能贴近它。所以如果你刚刚起步，我会建议从 GitHub Copilot CLI 开始。它是一个终端界面，也就是说它只有文本。没有太多 UI 需要学习。你输入一个提示词。智能体去执行操作。但这种交互更直接、更即时，而且坦白说，非常令人满足。

在这次演示中，我将使用全新的 GitHub Copilot 应用。但该应用所使用的 harness，与你在使用 GitHub Copilot CLI、Visual Studio Code 以及许多其他可以找到 GitHub Copilot 的地方时所使用的完全是同一套。

2. 开启 YOLO 模式

YOLO 模式也被称为“全部允许”。这会让智能体无需请求许可即可执行任何命令。具体方式可能因你使用的工具而异，但对大多数工具来说，它只是聊天中的一个 /allow-all 命令。否则，智能体每次需要做某些工作时都会停下来等待你的批准。

智能体需要自主性，你才能看到生产力的提升。如果你必须批准智能体所做的每一件事，那你还不如自己动手。况且，那也是一种糟糕的用户体验。没人愿意被降格为整天坐在桌前按“批准”按钮。而一遍又一遍地按“批准”，只会训练你不再阅读被要求批准的内容，这恰恰违背了初衷。

不过，你还是希望安全地使用智能体。好人也会遭遇坏事。使用 YOLO 模式时，你不会想在本地机器上运行智能体。当你在工作中使用它们时尤其如此——组织系统上的数据是私密的，而错误可能代价高昂。

幸运的是，在沙箱中运行智能体有很多选择。一个容易上手的是 GitHub Codespaces 或 开发容器。

3. 从原型开始

AI 最神奇的一点是，你可以轻松地在前期对任何事物进行原型开发。历史上并非如此。原型开发曾是项目的一个完整阶段，而且往往是一种奢侈。现在，你只需一个提示词就能做出原型。

我们来看几个例子。

假设我们想构建一个日期选择器 Web 组件。这看起来很简单，但实际上相当复杂。想想你可能想用它做的所有不同的事情。

• 你如何在组件内进行导航？
• 选中的日期是什么样子的？
• 选中的范围是什么样子的？
• 用户如何在日、月和年之间导航？

从一个简单的原型开始，做出几个变体。我通常会从这样的东西开始：

Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare.

在这个例子中，AI 生成了一堆不同的布局，但其中一个是先从年份视图开始的模拟稿。这很有意思。我希望我的日期选择器能让用户先缩小到年份，然后进入月份，最后到具体的某一天。这类事情，你不看到就不会想到。

作为人类，我们处理图像、形状和实体布局等感官丰富的模型，要比处理密集的文字快得多。在早期创建低成本的的原型有助于让复杂的概念变得直观易懂。

这也适用于非视觉任务。

例如，如果我想新增一个 API 端点，我仍然会先创建一个可视化原型，以理解需求和约束，然后再深入实现。

Create a visual mockup of the API for this project. Add five options for how we could handle a new API endpoint that allows the user to download their analytics data.

由于 GitHub Copilot 应用支持 Mermaid 图表，智能体会将其渲染为 Markdown，列出我们可以实现该 API 端点的五种不同方式。

在与智能体协作时，人们很容易忘记一切都是充满细微差别的。原型设计有助于提前发现这些细微之处，从而避免把宝贵的时间和 token 浪费在返工上。

对于大多数工作，我建议使用中等规模的模型，例如 GPT 5.6 Terra 或 Claude Sonnet，并采用中等推理级别。我还建议在这个特定功能、缺陷或增强的整个过程中，坚持使用你在这里选定的模型。提示词缓存会为你节省 token。只要你不切换到其他模型或推理级别，你之前的对话就会保留在该模型的缓存中，从而让你在后续请求中获得折扣。

4. 有条理地规划

既然你已经知道自己真正想要什么，而不是最初以为自己想要什么，那么是时候规划实现了。

在 GitHub Copilot 中切换到规划模式，而无需开启新会话。

/plan Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

这是一个相当模糊的提示词，你很可能比我这里有更多关于模型的上下文，但这只是一个演示。如果你没有更多上下文，也没关系。这正是这一步的用途所在。

理论上，只要你能用完美的上下文、以完美的顺序组合出完美的提示词，就能让模型一次性搞定任何事。理论上而已。

但我们谁都做不到这一点。不过，规划能帮你更接近那个理想状态，因为它会提出所有那些如果你要手工把这个东西搭建出来、一路上必须自己回答的问题：

• 开始日期和结束日期可以是同一天吗？
• 部分选择是否有效？
• 用户应该能够清除日期吗？
• “今天”是否应该始终是一个可见的选项？
• 是否允许手动输入？
• 日期以什么格式存储？
• 是否应该允许粘贴日期？

这样的问题还能列出一大堆。你不可能把所有边界情况都想全，但模型可以帮你识别出其中许多。

你可以安装 Matt Pocock 的 “grill-me” 技能，让规划模式在提问数量和边界情况覆盖上变得更加激进。

/plan /grill-me Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

这一规划步骤至关重要。重点不是让你全盘接受 AI 的每一条建议。如果你那样做，就等于否定了这个规划过程的价值。重点在于你要深入参与问题、引导模型。这正是你的专业能力发挥作用的地方。

你也可以反过来向模型提问。在下面的截图中，它向我询问了“非连续日期”的问题。我很确定模型在这里指的是什么，但我还是打算要求它澄清一下，以便我们达成共识。

即使你打断它去问澄清性问题等等，规划过程仍会继续进行。

5. 用 Autopilot 实施

一旦规划完成，GitHub Copilot 很可能会提示你切换到 Autopilot 并开始实施该规划。

Autopilot 是一个内置循环。它通过确保模型确实完成了它声称要做的事——在此情况下就是完成规划中的每一项——来迫使模型持续工作。

GitHub Copilot 会在此阶段自动充当编排器。如果它需要读取代码库中的文件，它会使用搭载小模型的“Explore”子智能体。如果它认为某个操作相对复杂，它很可能会选择搭载更大模型的“General Purpose”子智能体。虽然你可以通过 自定义智能体和指令在 GitHub Copilot 中对编排进行精细控制，但你无需做任何特殊操作即可享受子智能体和多模型工作流带来的优势。这一切开箱即用，即便你此前根本不知道这些东西的存在。

6. 人工审查与迭代

这就是你获得多巴胺快感的地方。你能看到 AI 创造出了什么。

但很可能你得到的并不完全是你想要的。这很正常，也在意料之中。模型无法读心，而且容易出错。与模型反复迭代，直到得到你真正想要的东西。无论只是代码还是改进后的 UI，这部分正是你的品味决定最终产品质量的环节。

例如，这是 GitHub Copilot 给我的日期选择器。

我已经能看出它存在一些问题：

• 动画不一致
• 由于颜色对比度问题，悬停在已选日期上时文字无法阅读
• 它不需要在顶部写着“12 YEARS”。
• 当我点击“Today”时，如果我处于月视图或年视图，它并不会带我跳到当天。

另外，我不太喜欢这个设计。它看起来太像是 AI 生成的了——因为它确实是！

所以现在我们只是处于后续跟进模式。我将使用一个我自己创建的 CSS 框架，叫做 Postrboard。我把它作为一个技能添加进去，这个技能只是指向该 CSS 并告诉智能体如何使用它。如果你愿意使用它，可以随意自行安装，或者你也可以选择任何其他你喜欢的 CSS 框架。给模型一些设计指导非常有帮助，通常一个 CSS 框架就足够了。

ok - we don't need a landing page here - just the component, output and settings panel in a minimal setting. Use the /postboard skill for the design and colors.

For the date picker, when I click on the day, it tries to zoom in, but can't because there is nothing to zoom to. There should be no zoom there.

It doesn't need to say "Zoom Out" at the top

When I mouse over a month or year that contains the selected day, I cannot read the hover text.

When I click "Today" it should take me to that day view, even if I'm on the month or the year.

The months don't need numbers under them and they don't need to be in boxes

Same goes for years. And it doesn't need to say "12 years" at the top."

注意这有多像对话。不要想太多。当你在修复这样一堆小问题时，直接交给模型就好。如果你有上下文，你就有了提示词。

最重要的事情是不要满足于“足够好”的 AI 输出。坚持质量。对此要毫不留情。这部分仍然是你的责任，而能够分辨什么是高质量结果、什么不是，正是你所带来的价值。没有任何 AI 能够取代你的人性化触感和创造力。

以下是我最终的日期选择器的样子。滚动到本文末尾可以看到它的实际效果。

7. 对结果进行小黄鸭调试

在你反复迭代并对所创建的内容感到满意之后，就该做最终审查了。

向 GitHub Copilot 请求一次 Rubber Duck 审查。你只需提出请求即可：

Perform a rubber duck review on this date picker component implementation

在 Rubber Duck 审查中，GitHub Copilot 会向另一个 AI 家族的模型请求审查。例如，由于我当时使用的是 GPT 5.6 Terra，它便向 Sonnet 请求了审查。不同的模型基于不同的数据训练，因此它们有着不同的盲区。Rubber Duck 审查有助于发现单个模型可能会遗漏的潜在问题。

请注意，你可以在这一工作流的任何阶段使用它。你可以对原型做 rubber duck，也可以对方案做 rubber duck。这完全取决于你是否想就某件事获得第二份 AI 审查。

如果你想更进一步，还可以把 rubber duck 与 Autopilot 结合起来，让模型在循环中协同工作，以改进最终结果。

/autopilot rubber duck this date picker implementation. When you have the result, review it carefully and make any necessary adjustments. Repeat the rubber duck review until both you and the reviewing model agree that the only items that remain have diminishing returns.

完成这一步后，你将得到比之前更加精炼的结果，并且很可能已经识别出许多额外的边缘情况。这一步确实会消耗更多 token，但你是在真正地让代码经受实战考验。把它看作是对未来自己的一笔投资——因为你现在就抓住了这些问题，未来的你就不必再为此头疼。

8. 收益

此时，你已经可以暂存并提交，或者继续着手处理你想随这个拉取请求一起添加的下一个功能。

我建议，接下来你要做的任何与这个日期选择器无关的事情，都新开一个聊天会话。你可以把聊天会话理解为按主题划分的；如果你开始偏离主题太多，那大概就该开一个新会话了。

这是我在本文中构建日期选择器工作流的最终成果。

视频 · 前往原文观看

我意识到这个例子有点刻意，但我们能不能都先停一下，惊叹一下如今用 AI 能做到的事情？构建日期选择器曾经是你能尝试做的最难的事情之一。随便问问那些构建过它的英雄们就知道了。

事情不必搞得那么复杂

这个简单的工作流对大多数人来说就足够了。简单也有助于你同时处理多项任务。当你把事情保持简单时，就更容易推断哪个智能体处于什么状态，以及你上一次在做什么。你的上下文窗口也是有限的。

如今 AI 领域发生的事情太多了。你可以构建和实验的东西没有上限。你可以添加 MCP 服务器、技能、指令和自定义智能体。你可以设置工作流和循环，创建能提示其他智能体的智能体，还能组建起整个虚拟开发团队。

但请记住，现在没有人真正知道自己在做什么。我们都在边做边摸索。今天很多被奉为 AI 的神奇咒语，明天就会变成反面模式。

只需专注于用最简单的方式获得可重复、高质量的结果。学会这套测试框架，你就没问题了。