导读

这篇文章分享了团队将 AI 驱动的开发模式从 “Vibe Coding”升级为 “Harness 模式”的实践。按理说，主要是与 E2E 测试的全流程。通过定义清晰的 Agent Handoff 协议，实现了任务状态在不同 Agent 间的安全、自动化流转。实践表明，该模式成功将原本需要 1 天完成的功能开发缩短至约 2 小时效率提高约 4 倍。显著降低了前后端联调的沟通成本。

为了更快地发布大模型评测网站，我们借鉴 OpenAI 的思路搭建了一套 Harness 模式。之前需要 30 天开发完的功能，现在基本上 8 个小时左右就可以完成。

背景

在我让 OpenClaw 🦞 管理大模型评测任务中，我们场景…，所以，我们的评测网站属于一个功能不断丰富、 的状态。网站增加功能来自我们对网站功能点的规划。

Side‑by‑Side 效果

使用者反馈

在实现上。网站由 React 的前端服务 versus-fe 和 Go 的后端服务 versus-server 构成，而且对于前后端这两个服务，我们分别安排了一个同学来负责。整体看，这个程序也属于：麻雀虽小、五脏俱全。

Vibe Coding

痛点一：沟通成本高——前后端同学需要频繁沟通 API 接口细节导致上线周期拉长。不过，

痛点二：人工迭代慢——每次 UI 微调都要手动改代码。浪费数分钟时间，却常因上下文误解导致“越改越糟”。

痛点三：上下文焦虑——长提示词导致 AI 过早结束任务，引发重复沟通。

痛点四：缺少自动化闭环——测试不完整，缺乏即时修复机制。

• "Vibe Coding 是“AI 代写代码，人来统筹状态”；而 Harness 是“代码库即唯一事实Agent 自治流转状态”。"
• "最开始的时候。我们用 DUCC，最终再利用 TOOS 网站发布新功能。老实说，”
• "可以看到。 在 Vibe Coding 模式下开发过程中的唯一变化就是代码实现由人变成了 AI。而新功能拆解、模块联调、代码迭代调整还都是人来驱动。"
• "我们最开始并不太懂 React，但是整个网站在 AI 的帮助下也就这么建立起来了。"
• "虽然 Vide Coding 确实提高了我们的开发效率。但是有时候我们总是会为了调整页面某个元素而浪费几十分钟，而人去改动这些代码可能只需要几分钟。"
• "更让人接受不了的是整个改动过程会出现越改越糟的问题，这实在是令人抓狂。"
• "当提示词比较长时我们希望增加一个展开全部功能。却与 DUCC 沟通两小时才完成，这段经历说明人机交互仍需调整。"
• "麻了我再也不想和 AI 废话了我不想写代码，也不想和 AI 来来回回聊天。"
.
• 痛点五：技术门槛高——非技术成员难以直接参与编码或配置。.
.

对 Harness 的思考

• 问：项目架构并不复杂，有必要搞 Harness 吗？
• 问：Harness 已跑出一套可复制成功路线吗？如果没有探索是否必要，答：从 OpenAI 与 Anthropic 的案例来看，即使是在轻量级架构下也能证明其价值。若 Harness 无法胜任轻量级程序，那么更复杂程序亦无望。.

---AGENT-HANDOFF--- requirement-id: REQ-status: completed | awaiting_review | has_bugs | all_passed 再看output。产出的文件方法 next-step: 接下来动作描述 next-step-prompt: 启动下一个 Agent 时使用的 prompt after-approval-next-step: 审核通过后的动作 after-approval-prompt: 审核通过后的 prompt bugs这方面，Bug 列表 review-message: 审核提示 ---END-HANDOFF---;

Harness 闭环设计

从例子来看。需求 – 后端 – 前端 – 集成测试 – E2E 测试 – Bug 修复 – 重跑测试 → all_passed。整个闭环除了 PRD 阶段需人工确认之外其余均可完全自动化；在前后端开发过程中避免 RD 间沟通成本，提高效率。
`......`;
`---AGENT-HANDOFF--- requirement-id: 说到status，output: next-step: next-step-prompt-integration: next-step-prompt-e2e: ---END-HANDOFF---`;