Github 这篇文章对 harness 的理解很深刻也很务实
开篇的观点很扎心：生产力的关键不在于安装多少新工具、MCP、Skills 或"神奇提示词"，不要相信「"我用一个神奇 prompt 就彻底搞懂了 AI"」「一句 prompt 完美复刻某某某」「这个 Skill 如何如何」，这些 99% 只会产生 SLOP。。
回来看看 Github Copilot 这个 Harness 的八步工作流
1. 选一个工具，学透它 Copilot 各形态（CLI、App、VS Code、JetBrains）正在收敛到同一个 harness，学一次，处处可用。作者建议新手从 CLI 入手--纯文本、交互最直接、反馈最即时。
2. 开启 YOLO 模式（Allow All） 这是全文最大胆也最具争议的建议：让智能体自主执行，不做逐条审批。理由有二：逐条审批等于自己动手，毫无意义；反复点"Approve"只会训练你不再阅读审批内容，反而架空了安全机制。 但前提明确：必须在沙箱中运行（Codespaces、dev containers），尤其是工作场景--数据在组织的系统里，试错成本高昂。自主性与隔离环境必须成对出现。
3. 先做原型（Prototype） AI 把原型从"项目中的奢侈阶段"变成"一个 prompt 的事"。要点： · 原型不必是代码，视觉化优先--人脑处理图形远快于密集文本； · 同样适用于非视觉任务：为 API 设计生成 Mermaid 对比图，把 5 种实现路径摆在一起再选； · 原型的价值在于提前暴露你没考虑到的细节（如"从年视图逐级缩放"的交互），避免浪费 token 返工； · 实用技巧：用中等模型+中等推理档位，且同一任务期间不切换模型--prompt 缓存能持续省钱。
4. Plan Mode 理论上"完美 prompt 一次出活"存在，实际上没人做得到。Plan 模式的价值是让模型替你问出你没想到的边界问题（起止日期可否相同？能否清除？粘贴输入？……）。 作者强调一个关键态度：规划不是照单全收 AI 的建议，而是你深度介入、用专业判断引导模型的环节--这才是人的价值所在。也可以反问模型澄清（如"non-contiguous dates"具体指什么），确保双方对齐。
5. Autopilot 实现 内置的循环执行机制，强制模型真正完成计划中的每一项，而非说一套做一套。编排开箱即用：读代码用小模型 Explore 子智能体，复杂任务用大模型 General Purpose 子智能体--不需要任何自定义配置就能享受多模型、多智能体工作流。这一条直接支撑了全文论点：harness 自带的编排能力已经够强。
6. 人工评审与迭代 "模型读不了你的心，也会犯错"，初稿不达预期是常态。这一阶段的要点： · 对话式反馈即可，不要过度设计 prompt--"你有上下文，你就有 prompt"； · 拒绝"够用就行"，坚持质量标准要"毫不留情"。品味决定最终品质，这是 AI 无法替代的人的价值。
7. Rubber Duck 终审 一个精巧的机制：让另一个模型家族来评审。不同训练数据带来不同盲区，跨模型评审能捕捉单模型的系统性遗漏。 进阶玩法是把 Rubber Duck 套进 Autopilot 循环，让两个模型迭代互审直到"只剩边际收益递减的问题"。作者坦承这费 token，但定位为对未来自己的投资--现在捕获的问题，将来不用还债。
8. 收尾与会话管理 完成后提交；新话题开新会话--把会话视为主题性的，偏离主题就换，保持上下文干净。