HarnessCoding核心思想最近OPCOne 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的上下文都是聚焦的不会因为代码量增长而失控不过光是角色拆分还不够我们还要知道这些数字员工之间是怎么协作的接下来这张图展示了一条典型的数字员工协作流水线每个角色接收上游输入、执行本角色任务、产出给下游产出物沿着流水线从左往右流转最终变成可运行的软件是不是觉得有点复杂一个人要管这么多数字员工光是指挥他们就已经很累了所以仅靠拆分和流水线还不足以让这套体系稳定运转我们还需要一套统一的工作方法告诉这些数字员工什么时候该干什么产出什么验收什么失败了怎么办这就是接下来要讲的 ISIERISIER让数字员工流水线运转起来的方法论光把数字员工拆出来还不够还得让他们能协同起来这就需要一套统一的工作流我把它叫做ISIER取自五层首字母I— Intent 意图层识别用户意图生成标准Spec和PlanS— 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验收失败时触发RollbackRefl反思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的工具选择