企业官网建设流程全解析

GitHub Copilot Harness工作流技术解析：用单一工具完成原型、规划、实现与代码审查

一、引言

亲爱的朋友们，创作不容易，若对您有帮助的话，请点赞收藏加关注哦，您的关注是我持续创作的动力，谢谢大家！有问题请私信或联系邮箱：jasonai.fn@gmail.com

2026 年 7 月 27 日，GitHub Blog 发布 Burke Holland 的文章《The harness is all you need (mostly)》，给出一套从原型、规划、实现到代码审查的 GitHub Copilot 工作流。它切中的不是“哪个模型跑分更高”，而是一个更现实的问题：当 MCP、Skill、自定义 Agent 和工作流越来越多，开发者是否必须先组装一套复杂 AI 工具链，才能真正提高开发效率？

作者的答案是：大多数时候并不需要。先把 GitHub Copilot 这个 Agent Harness 用透，一个工具就能承接需求探索、方案澄清、自动实现、人类迭代和跨模型复核。复杂扩展不是无用，而是应该在基础流程已经稳定、团队确实需要自动化时再加入。

不过，“GitHub Copilot 发布 Harness”需要准确理解：Harness 不是此次发布的独立产品名，也不是一个新按钮。原文明确说明，作者将 “harness” 与 GitHub Copilot 交替使用，指的是把模型、上下文、工具、权限、执行循环、子 Agent 和审查机制组织起来的运行框架。GitHub 发布的是一套实践方法，而不是又推出一个需要购买或安装的新工具。

本文将沿着这条工作流拆解 Harness 的技术职责、安全边界与工程价值，并回答：为什么同一个模型放进好的 Harness 后，会比“裸 API + 一条神奇提示词”更接近真正的软件开发者。

二、Harness 到底是什么

2.1 模型只是大脑，Harness 才负责把工作做完

单独调用 LLM API，模型只能接收输入并生成输出。一个编码 Agent 还需要找到相关文件、编辑代码、运行命令、观察测试结果、维护任务状态，并在失败后继续修正。Harness 就是承载这些能力的执行层。

从这个角度看，开发效果并不只由模型智力决定。模型能力相近时，谁能更准确地准备上下文、选择工具、控制权限、验证结果并管理失败，谁就更可能稳定完成任务。

2.2 一套 Harness，多种使用入口

GitHub Copilot 已覆盖 CLI、Copilot app、VS Code、Visual Studio 和 JetBrains 等入口。原文指出，这些体验正在逐渐集中到同一 Harness 上；界面细节虽然不同，核心工作流保持一致。作者建议新用户从 Copilot CLI 开始，因为终端界面更直接，能清楚看到 prompt、工具调用和 Agent 行为；文章演示则使用新的 GitHub Copilot app。

这带来一个重要变化：开发者学习的对象不再只是某个 IDE 面板，而是一套可迁移的方法。入口可以变化，工作流仍然是原型、计划、执行、复核和提交。

三、八步工作流：从想法到可提交代码

3.1 工作流全景

原文用日期选择器 Web Component 作为案例，将整个过程分成八步：

┌──────────────┐ │ 1. 选择入口 │ CLI / Copilot app / IDE └──────┬───────┘ ▼ ┌──────────────┐ ┌───────────────────────────────┐ │ 2. 授予自治 │ ───▶ │ 隔离环境：Codespaces / Dev Container │ └──────┬───────┘ └───────────────────────────────┘ ▼ ┌──────────────┐ │ 3. 快速原型 │ 一次生成多个方案，先看见可能性 └──────┬───────┘ ▼ ┌──────────────┐ │ 4. 系统规划 │ 澄清需求、边界条件与验收标准 └──────┬───────┘ ▼ ┌──────────────┐ │ 5. Autopilot │ 按计划实现、调用工具、运行验证 └──────┬───────┘ ▼ ┌──────────────┐ │ 6. 人类迭代 │ 体验、品味、业务判断与质量把关 └──────┬───────┘ ▼ ┌──────────────┐ │ 7. 跨模复核 │ Rubber Duck review └──────┬───────┘ ▼ ┌──────────────┐ │ 8. 提交成果 │ Stage、Commit 或继续当前 PR └──────────────┘

3.2 为什么先做原型，而不是直接写代码

日期选择器看起来简单，实际涉及日、月、年导航，单日与范围选择，键盘访问、视觉状态和边界日期。若直接让 Agent 实现，需求中的空白会被模型自行填补，返工成本很高。

原文先要求 Copilot 在一个 HTML 文件中生成 20 个日期选择器 mock：

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

这里的目标不是得到可上线代码，而是用低成本样品暴露隐含选择。例如，其中一个原型从年份视图开始，促使作者确定“年 → 月 → 日”的缩放式导航。对非视觉任务也可以使用相同方法：为一个数据导出 API 先画 Mermaid 图，对比同步下载、异步任务、Webhook 等多种设计，再决定实现路线。

3.3 Plan mode 把模糊需求变成约束

原型确定方向后，不开启新会话，直接切换到 Plan mode：

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

计划阶段会追问：开始与结束日期能否相同、部分选择是否有效、能否清空、是否允许手工输入与粘贴、日期如何存储等。它的价值不是替开发者做决定，而是系统地暴露开发者尚未决定的事情。

原文特别强调，不能无条件接受模型的每一项建议。计划是人机共同收敛需求的过程，领域经验仍由人提供。用户也可以反问模型某个术语的含义，规划过程会在澄清后继续。

四、Autopilot：计划如何变成持续执行

4.1 内置循环避免“说做了，实际没做完”

计划完成后，Copilot 会建议切换到 Autopilot。原文将其描述为一个内置循环：模型需要继续工作，并检查自己是否完成计划中的每个项目，而不是生成一段代码后立即宣布任务结束。

读取下一计划项 │ ▼ 定位上下文 → 修改文件 → 运行命令/测试 → 读取结果 ▲ │ └────── 失败：分析原因并修正 ───────┘ │ 成功：更新任务状态 │ 仍有计划项？继续执行

这正是 Harness 相比裸模型调用的价值：模型不是只预测“应该怎么改”，而是在真实环境中观察动作结果，再决定下一步。

4.2 默认就存在的多 Agent 与多模型编排

在 Autopilot 阶段，GitHub Copilot 会充当编排器。根据原文：需要阅读和探索代码库时，它会使用搭配较小模型的Explore 子 Agent；判断任务相对复杂时，则可能选择搭配更大模型的General Purpose 子 Agent。

开发者可以进一步配置自定义 Agent 和 Instructions，但基础的子 Agent、多模型编排开箱即用。这也是文章“先学 Harness”的核心理由：不少被包装成高级技巧的能力，平台已经放进默认执行链路，不需要用户先拼一套虚拟开发团队。

五、审查机制：AI 不能替代人的品味与责任

5.1 Human review 不是流程装饰

Autopilot 完成计划不代表结果已经合格。原文中的初版日期选择器仍有动画不一致、选中状态文字对比度不足、“Today”按钮导航错误和多余文案等问题。作者通过自然语言连续反馈，让 Agent 逐项调整设计和行为。

这一步揭示了一个常见误区：Agent 的“任务完成”通常指计划项被执行，并不等于产品体验、可维护性和业务语义都达标。开发者的价值从逐行输入代码，转向定义质量、发现不协调之处并拒绝“差不多能用”的结果。

5.2 Rubber Duck 用不同模型寻找不同盲点

人工迭代完成后，可以请求一次 Rubber Duck review：

Perform a rubber duck review on this date picker component implementation

GitHub Copilot 会向另一个 AI 家族的模型请求审查。原文案例的主模型是 GPT 5.6 Terra，复核由 Sonnet 完成。不同模型的训练数据和行为偏好不同，交叉审查有机会发现单一模型反复忽略的问题。

Rubber Duck 不只适用于最终代码，也可以审查原型或计划。还可以与 Autopilot 组合，形成“审查 → 修正 → 再审查”的循环，直到剩余问题的收益明显递减。

但跨模型一致不等于客观正确。两个模型可能共享错误假设，也可能提出互相冲突的意见。最终合并前仍需运行测试、静态分析、安全扫描并由人审查 diff；涉及架构、安全和数据迁移时，不能用“两票 AI 同意”代替责任人批准。

六、Allow All：效率最高，也是风险最大的步骤

6.1 为什么需要自治

原文第二步建议开启 YOLO mode，即Allow All。在多数入口中可以使用：

/allow-all

它允许 Agent 执行命令时不再逐次等待批准。持续执行对 Autopilot 很重要；如果每个文件读取、安装命令和测试都需要点击确认，循环会不断中断，人也容易形成机械批准的习惯，最终失去审批本来的安全意义。

6.2 自治必须和隔离绑定

原文同时给出明确警告：开启Allow All时，不应让 Agent 直接运行在本地机器上，尤其不能在包含企业私有数据和生产凭据的工作电脑环境中运行。推荐使用 GitHub Codespaces 或 Development Container 等沙箱。

所以，更准确的工程公式不是“Allow All = 更高生产力”，而是：

有效自治 = 足够的工具权限 + 可抛弃的隔离环境 + 有限故障半径 + 最终人工门禁

七、横向对比：简单 Harness 与复杂 Agent 栈

7.1 四种工作方式的差异

GitHub 的观点并不是反对 MCP、Skill 或自定义 Agent。原文明确承认，当团队要定义复杂工作流和自动化时，这些扩展会很重要；作者在示例里也使用了grill-me与设计 Skill。真正的优先级是：先用最少组件获得可重复的高质量结果，再为已经被证明的需求增加扩展。

7.2 与主流编码 Agent 的生态位

它们的竞争已经不只是“接入哪个模型”，而是 Harness 如何管理上下文、权限、工具、任务状态和质量反馈。对团队来说，模型可以替换，工作流、审计和安全策略才是长期资产。

八、可直接复用的工程模板

8.1 一个功能对应一个主题会话

原文建议把聊天会话视为“主题容器”。一个功能、Bug 或增强尽量在同一会话内完成，以保留原型、决策和实现上下文；任务主题发生明显变化时开启新会话，避免上下文被无关历史稀释。

# 1. 原型：先比较可能性 Generate several minimal prototypes for <feature> in one file so I can compare. # 2. 规划：明确边界和验收标准 /plan Implement <feature>. Ask me about ambiguous behavior and edge cases first. # 3. 实现：在隔离环境中按计划执行 /autopilot Implement the approved plan and run the relevant tests. # 4. 人类迭代：指出具体问题，不需要追求“完美提示词” The behavior is wrong when <case>. Remove <unneeded part> and preserve <constraint>. # 5. 跨模型复核 Perform a rubber duck review of the implementation, tests, and edge cases.

8.2 团队落地检查表

这套流程不要求每次都生成 20 个原型，也不要求所有小改动都启用跨模型循环。关键是让每个阶段产生可检查的中间成果，避免把模糊需求直接交给 Agent 后，只在最后看到一大包难以审查的代码。

九、总结

纵向看，GitHub Copilot 已从代码补全逐步发展为能读取仓库、执行命令、规划任务和编排子 Agent 的开发 Harness；横向看，Claude Code、Codex 和 Cursor 也在沿同一方向演进。模型仍然重要，但开发者每天真正使用的，是模型外面的那套执行系统。

这篇 GitHub Blog 最值得保留的观点，不是“Harness 可以包办软件开发”，而是更克制的结论：先用一套简单、连续、可复核的工作流稳定地产出高质量结果，再决定是否需要更复杂的 Agent 工程。原型减少方向性返工，计划暴露隐含约束，Autopilot承担机械执行，人类把守品味与责任，跨模型审查寻找盲点。单一工具真正节省的，不只是点击次数，而是阶段之间反复丢失和重建上下文的成本。

参考资料：

1. The harness is all you need (mostly) — Burke Holland, GitHub Blog, 2026-07-27
2. GitHub Copilot CLI — GitHub Docs
3. Allowing GitHub Copilot CLI to use tools — GitHub Docs
4. GitHub Copilot CLI Autopilot — GitHub Docs
5. Rubber Duck review — GitHub Docs
6. Creating custom agents for GitHub Copilot CLI — GitHub Docs
7. About GitHub Codespaces — GitHub Docs
8. Development Containers specification