HarnessCoding核心思想

最近OPC（One Person Company即一人公司）的概念炒的比较火

当然我理解的OPC相对来说要狭义一点

即软件行业OPC

为什么提这个概念呢

因为它恰好对应了我的Harness Coding核心思想：

像管理一个公司一样去管理你的Agents和Harness Coding项目

为什么要这么做呢？

其实就是一个分而治之的思想

如果只是一个小demo

一个纯前端的网页（现在很多Harness Coding都在做的）

那么我想我们是不需要工程化的东西的

直接告诉AI我们想要什么

然后让它修修改改最后就完工了

但是商业化的大型项目这个明显是不现实的

因为牵一发而动全身

很有可能因为AI的一次小改动

导致关联业务收到影响

或者导致全局的问题产生

并且随着代码量的增多

AI要去处理新的需求会占用越来越多的上下文

最终导致工程变得不可维护

（下图：作者Harness Coding的商业化SaaS项目结构）

所以就像最开始的单体应用发展到一定阶段后

就会有微服务

就会有应用编排

就会有大数据一样

AI Harness Coding到了一定阶段

也需要去做“拆分”

每个业务领域可以建立专属的知识库、Skills、Memories

我们可以像管理一个大型项目的员工一样去管理这些Agents

让他们互相协同但是互不干扰

最终成为一条流水线上的螺丝钉（大厂人应该都有这种感受吧）

所以只有充分了解在一个软件开发从0到1的过程中

有哪些人员角色参与

我们才能将我们的“数字员工”进行合理的拆分

为什么要基于人员角色来拆分呢？

因为AI替代的就是人（sad）

从一个软件的诞生史来学 Harness Coding

一般来讲

一个软件的诞生一定是基于市场的需求

“我要”二字

成为了软件诞生的源动力

于是需求分析师BA开始介入

为我们的软件编写需求文档

但是通常一个人并不能完成整个传统软件工程的交付

所以需要将工程进行拆分

“分而治之”

AI时代亦复如是

常见的AI工程拆分思路

既然要基于人员角色来拆分

那我们就顺着软件诞生史往下走

看看一个软件从0到1

到底有哪些角色参与

每个角色又对应着什么样的"数字员工"

需求阶段：BA需求分析师

软件的起点是"我要"

但"我要"往往是模糊的

需要BA去澄清、去拆解

去把模糊的市场需求翻译成清晰的PRD

对应的数字员工就是

负责意图识别和Spec契约生成的Agent

它通过反复确认模糊部分

把用户的"我要"变成可执行的Spec文档

设计阶段：架构师

需求清晰之后

架构师开始介入

做技术选型、做系统设计

定义模块边界和数据流向

对应的数字员工是

负责架构设计和技术决策的Agent

它沉淀了项目的技术栈记忆

每一次架构演进都会被记录下来

开发阶段：前端工程师 + 后端工程师

这是最重头的部分

前端负责UI实现和交互

后端负责API和业务逻辑

对应的数字员工各自带着专属的Skills

前端的组件库规范、UI约定

后端的数据模型、业务规则

互不干扰又互相协同

质量阶段：测试工程师

代码写完了不代表能用

测试工程师要验收

对应的数字员工是

负责Eval验收的Agent

它带着缺陷模式记忆和测试基线

对照Spec文档逐项验证

不通过就反哺前面的流程

运维阶段：运维工程师

验收通过后要部署上线

运维工程师负责发布、监控、告警

对应的数字员工带着部署配置记忆

和历次故障案例

让每一次发布都更稳

持续进化：成本控制 + 自我进化

商业项目不能只顾着跑

还要算成本、还要持续进化

这两个角色对应的数字员工

一个盯着token消耗和模型选择

一个盯着Harness环境本身的完善

让整套体系越用越顺

可以看到

每个角色都有自己专属的Skills、Memories、产出物

就像公司里每个岗位都有明确的职责边界

这样拆分之后

每个Agent的上下文都是聚焦的

不会因为代码量增长而失控

不过光是角色拆分还不够

我们还要知道

这些数字员工之间是怎么协作的

接下来这张图展示了一条典型的数字员工协作流水线

每个角色接收上游输入、执行本角色任务、产出给下游

产出物沿着流水线从左往右流转

最终变成可运行的软件

是不是觉得有点复杂

一个人要管这么多数字员工

光是指挥他们就已经很累了

所以

仅靠"拆分"和"流水线"

还不足以让这套体系稳定运转

我们还需要一套统一的工作方法

告诉这些数字员工：

什么时候该干什么

产出什么

验收什么

失败了怎么办

这就是接下来要讲的 ISIER

ISIER：让数字员工流水线运转起来的方法论

光把数字员工拆出来还不够

还得让他们能协同起来

这就需要一套统一的工作流

我把它叫做ISIER

取自五层首字母

• I — Intent 意图层：识别用户意图，生成标准Spec和Plan
• S — Spec 契约层：基于SDD和TDD思想，生成标准化文档和验收清单
• I — Impl 执行层：注入上下文执行任务，基于ReAct不断修正
• E — Eval 验收层：自我测试，通知用户验收，不满意则loop前四步
• R — Refl 反思层：更新Agent上下文，归档文档，完善Harness环境

ISIER描述了一个任务从"用户意图"到"反思归档"的完整主线流程

每一层是前一层的下游

这套流程不是凭空设计的

而是在长期和Agent协作的过程中

被反复打磨出来的

每一个环节都对应着真实踩过的坑

比如Intent层为什么要反复确认

因为AI最容易在模糊意图上跑偏

你以为是A它理解成B

最后交付一个四不像

比如Spec层为什么要先写契约再执行

因为不写契约的执行

就像没有图纸就盖楼

盖到一半发现地基歪了

再比如Eval层为什么要loop

因为一次验收通过是理想情况

现实往往是验收-反馈-调整-再验收

直到真正符合预期

所以ISIER不是一个单行道

它是一个带反馈环的工作流

每一层都可能回到上一层

这种"螺旋式推进"才是工程化的常态

理解了这一点

就不会对AI的反复修改感到不耐烦

Rollback：贯穿始终的安全网

ISIER五层之外

还有一个贯穿始终的原则

就是Rollback（回滚）

它不是独立的一层

而是保障ISIER安全执行的横切机制

在每一层都有对应的职责

层级	Rollback 职责
Intent	识别风险任务，初步评估回滚必要性
Spec	定义验收标准时同步定义回滚标准
Impl	执行前必须确认Rollback方案存在
Eval	验收失败时触发Rollback
Refl	反思Rollback是否有效，沉淀回滚经验

为什么要强调Rollback

因为AI执行任务是有副作用的

它会改代码、会改配置、会删文件

如果没有回滚方案

一次失败的执行可能就让项目陷入泥潭

所以我给自己定了一条硬约束

任何任务执行之前必须要有Rollback方案

无方案就STOP

多方案就STOP

方案失效就STOP

宁可慢一点

也不能让Agent裸奔

这套机制看起来有点保守

但和商业项目的稳定性比起来

多花几分钟确认回滚方案

完全是值得的

实践出真知：5人团队0手写代码

说了这么多方法论

最终还是要落到实践上

这套Harness方法论

已经应用在我所在的5人开发团队

强制要求全员使用提示词工程

在Harness架构下开发

0手写代码

所有代码由Agent在Harness约束下生成

截至2026年8月23日

已完成2个项目的开发

另有3个商用项目立项

实践证明

在完善的Harness约束下

团队无需手写代码即可稳定交付商业级项目

开发者角色从"代码编写者"

转变为"Harness设计者与提示词工程师"

说实话一开始让团队全员放弃手写代码

大家是有点慌的

毕竟写代码是我们安身立命的本事

但跑通之后发现

当Harness搭好之后

人的精力从"怎么实现"转移到了"要做什么"和"怎么验收"

反而更聚焦在真正有价值的事情上

写在最后

Harness Coding的核心思想

其实就一句话

像管理一个公司一样去管理你的Agents

把AI当成数字员工

给它们明确的职责边界

给它们专属的知识沉淀

给它们统一的工作流程

给它们可靠的安全网

然后让它们各司其职

协同流水线作业

这听起来有点像把人变成螺丝钉

但换个角度想

当流水线搭好之后

作为"Harness设计者"的你

终于可以从重复的编码劳动中解放出来

去做更有创造性的工作

去思考产品、思考市场、思考方向

这或许就是Harness Coding

带给软件行业OPC的最大价值

下一章我们会具体讲讲

Harness Coding的工具选择