写在代码之外：为什么我越来越相信 Harness 是下一代工作方式

最近这段时间，我一直在学习两件事：

• SDD（规格驱动开发）

• Harness Engineering（把 AI 真正接入流程）

边学边做，我自己写了一个小项目： OpenHarness，欢迎star~

✅️项目地址：

https://github.com/hahaxiang27/openHarness

使用方式概括：

1. 下载源码，按照要求安装

2. 在项目中执行oph init

3. 可以执行以下命令

4. 可以打开面板查看流程

它的目标很直接： 让先写规格，再跑闭环，还能看见过程状态这条线连接起来。

我为什么会做 OpenHarness？

过去我们用 AI 写代码，很多时候像即时问答：

想到一个需求 → 问模型

给一段代码 → 让它改

出错了 → 再补一轮提示词

这样能做出东西，但很难稳定复现。 尤其是项目变复杂以后，最痛的不是“写不出来”，而是：

• 过程不可见

• 状态不可控

• 结果不可复用

最近的技术变化的太快了，大家普遍都在fomo的阶段

有一句老话：AI时代你要是学的太慢，那你就可以不用学了...

包括像Harness这个概念，其实周期真的很短，但是其实这个架构在早年前已经被很多的人验证并且跑通了，只不过名词来的晚一些

确实Harness也困扰了我很久，这次是参考了一些项目，和朋友交流学习，慢慢才理解了这个架构的实践方案。

加上最近的Claude源码泄露，所以才想着做这样子一个工具，虽然还在完善阶段，但是边做边学就不会错hh

OpenHarness 在做什么？

我把它理解成一个轻量的实践框架： 用 SDD(OpenSpec) 定义目标，用 Harness 跑通闭环。 

目前它已经支持：

• 在项目里类似 OpenSpec 一样使用

• 先写规格 ，再执行开发流程

• 跑流程时可以看到过程状态

• 支持切换 OpenCode / Claude Code / Codex CLI

• 本地监控页可以看整体执行（页面还在持续优化，现在确实比较朴素😂）

做这个项目，我最大的感受

一句话：

未来好用的 AI 编程工具，拼的不只是“会不会写代码”， 而是能不能真正进入开发流程。

也就是说，决定工具上限的，不只是模型能力， 而是它能不能被放进真实工作流里，成为稳定的一环。

为什么我觉得 Harness 不只是开发概念？

这是我最近越来越笃定的一点。 Harness 的核心不是“写代码”，而是“把能力接入流程并可控运行”。 所以它天然可以跨行业：

• 在内容行业，它是“选题-生产-审核-分发-复盘”的闭环

• 在销售团队，它是“线索-触达-跟进-成交-复盘”的闭环

• 在客服场景，它是“识别-检索-处理-升级-质检”的闭环

• 在管理场景，它是“目标-执行-监控-复盘”的闭环

你会发现，不同岗位都在面对同一个问题： 如何把零散能力，变成稳定产能。 这正是 Harness 的价值。

OpenHarness 现在还在快速迭代阶段， 包括监控页、可视化体验、细节交互都还有很多可改进空间。 如果你也在研究：

• SDD

• Harness Engineering

• AI 如何真正进入研发流程（或业务流程）

欢迎来交流，给建议，甚至一起共建。 我这边也有自己的产品在做，后续会开放更多内测体验。 

✅️项目地址：

OpenHarness

关于作者

Helans-黄老斯

专注Agent落地真实场景

BossClaw产品内测中...

以结果为导向，解决agent在各行业的快速落地

感兴趣的欢迎交流~