1. 为什么要给 AI“配一间专属办公室”各个团队对“AI 编程”的探索基本都会经历一个相似的过程第一周觉得它无所不能第二周发现它经常自作聪明第三周开始怀疑是不是自己的打开方式不对。我见过不少项目组AI 工具装了一大堆prompt 写了几百条结果代码库里到处都是风格迥异的片段、互相矛盾的实现、以及“上次还能跑这次不知道为什么就不行”的玄学问题。问题出在哪里大多数人把 AI 当成一个随叫随到的“火花塞”——需要的时候点一下出结果就用不行就重新生成。但软件开发从来不是单点输出而是一条完整的价值链从模糊的想法到可执行的规格到具体代码实现到质量验证再到交付发布。如果 AI 只在这一条链路的某个节点上“闪一下”它产生的价值就会被上下游的混乱消耗掉。所以我才开始认真思考一件事与其让 AI 在每个人的编辑器里各自为战不如给它配一间“办公室”——把流程、岗位、接口、质量标准都定义清楚让 AI 在固定的工位上按照固定的规矩完成固定的交付物。这套做法就是 Harness Engineering。Harness 这个词在工程领域有“系绳、束缚”的意思用在 AI 协作上非常贴切不是限制 AI 的能力而是给它的能力配上明确的边界和轨道。边界越清晰输出越稳定轨道越明确协作越顺畅。这套思路落下来就是六个模块——需求澄清、规格生成、代码实现、代码评审、持续集成验证、交付发布——以及支撑这六个模块运转的一套基础设施。这篇文章会把我在实施 Harness Engineering 过程中踩过的坑、验证过的方法、以及最终沉淀下来的框架完整讲清楚。适合正在做 AI 辅助开发、想从“点状使用 AI”升级到“体系化使用 AI”的团队参考。内容会涉及具体模块设计、Agent 协作机制、以及真实项目中遇到的典型问题我尽量不用抽象的概念糊弄人全部拿实际场景说话。2. 六大模块拆解一条从想法到交付的完整链路2.1 需求澄清把“想做点什么”翻译成“到底要做什么”大多数项目死在第一步不是因为没有想法而是想法太模糊。“我想做一个更好用的后台管理系统”——这种需求交给任何工程师都做不好交给 AI 只会更糟。因为 AI 不具备人类的“心领神会”能力它需要的是明确、完整、无歧义的输入。需求澄清模块要解决的就是这个“从模糊到明确”的鸿沟。我在实践中给它定义了三个核心产物用户意图描述用自然语言记录用户想解决的问题但必须包含场景背景、已有约束、期望效果。功能性需求清单把意图拆解成具体的功能点每个功能点都对应一个可验证的行为。边界与限制声明明确系统不做什么避免 AI 在实现时自作主张地“扩展”。这里最关键的一点是需求澄清模块必须做到“每个输入都对应一个经过验证的输出”。也就是说不能用户说什么就记什么而是要经过一轮结构化追问——比如“这个功能在什么场景下使用”“数据量级大概是多少”“如果操作失败用户应该看到什么反馈”——把隐藏信息挖出来。我在实际项目中把这个环节做成了“需求对话模板”AI 根据模板反问用户而不是被动等待用户把需求一次性说全。一个很有意思的收获是需求澄清模块跑通之后团队内部的沟通质量也跟着提升了。以前产品经理和开发对需求的理解经常有偏差现在因为需求经过了一层结构化处理偏差在早期就被暴露出来后续返工大幅减少。这就是 Harness Engineering 的“溢出效应”——你本来是想约束 AI结果把人的协作也一起理顺了。2.2 规格生成把需求变成可验收的工程契约需求澄清的输出还是半自然语言的形态离“可执行”还有一段距离。规格生成模块要做的事情是把澄清后的需求进一步翻译成工程规格——也就是“到底要做什么、验收标准是什么、场景限制在哪里”这三件套的完整表达。规格不是文档而是契约。契约意味着双方都要遵守。我见过太多团队跳过这一步直接从需求跳到写代码结果就是 AI 生成的代码跟需求文档貌合神离。规格生成模块的产出物是这样的功能规格说明书每个功能模块的输入、处理逻辑、输出格式全部用结构化条目描述。接口契约模块与模块之间的交互协议包括参数类型、返回值结构、错误处理方式。验收标准表每个需求点对应的验证条件写清楚“满足什么条件算完成”。规格生成模块承担着一个重要的翻译职能把人类容易理解的“自然语言需求”转换成 AI 更容易理解的“结构化规格描述”。这个翻译质量直接决定了后续代码实现模块的表现。我在实施过程中发现给 AI 喂规格而不是喂原始需求生成的代码在架构一致性上会有一个质变——因为它不再需要自己“脑补”业务逻辑只需要按照规格执行。规格生成模块还有一个容易被忽略的细节模型选择很重要。需求澄清阶段可以选理解能力强的对话模型但规格生成阶段最好选逻辑推理能力强的模型对输出格式的稳定性要求也更高。同一个模型在这两个阶段的表现差异可能很大后面我会专门讲模块与模型的匹配逻辑。2.3 代码实现让 AI 在特定上下文里当“建模工程师”有了规格作为契约代码实现模块就能在一个相对稳定的上下文里工作了。这个模块里的 AI 不是一个通用的代码生成器而是一个被限定在特定任务边界内的“建模工程师”——它的职责就是把规格翻译成符合架构约定、符合代码规范、符合接口契约的实现。代码实现模块在 Harness Engineering 框架里承担的是“AI 建模工程师 A”的角色。它与普通 AI 编程的最大区别在于它拿到的输入不是一句“帮我写个登录功能”而是一份完整的任务单——包含功能规格、接口契约、依赖关系、编码规约、以及复用组件的清单。AI 在这个任务单约束下工作输出的是可审查、可测试、可集成的代码而不是一堆需要人再去整理拼装的“半成品”。在这个模块里我沉淀了三个关键经验上下文打包比提示词长度更重要。AI 真正需要的不是一条写得天花乱坠的指令而是一份让它能“进入工作状态”的完整上下文——包括规格条目、相关接口定义、代码风格样例、以及不要去动的部分。输出约定必须强制。代码实现模块的 AI 必须按约定输出结构化结果改了哪些文件、为什么改、影响范围是什么、有没有新增依赖。没有这些约定后续的代码评审和集成验证根本无法自动化。任务的粒度决定了质量的稳定度。任务切得越细AI 的完成度越高。我在实践中把大模块拆成小任务每个任务控制在 30 分钟到 2 小时的工作量代码实现的可靠性会明显提高。不少人觉得代码实现模块应该是整套系统里最聪明的部分但实际做下来会发现它更像是“执行能力最强”的部分。“聪明”已经被规格生成模块消耗掉了代码实现模块更重要的是按规矩执行。这也是 Harness Engineering 与“让 AI 自由发挥”的根本区别。2.4 代码评审用独立的“验证视角”审视实现结果代码评审模块在整个链条里承担着独特的职能——它不是让 AI 检查自己的代码而是让另一个具有“验证视角”的 AI 来审查“建模工程师 A”的产出。在流程角色设计上这就是“AI 建模工程师 B验证操作”的核心职责。为什么要用独立的 AI 来做评审而不是让实现代码的 AI 自评道理很简单人自己检查自己的错误会受惯性思维影响AI 也一样。实现者天然会倾向于为自己的设计辩护而评审者需要做的是从“这个代码是否满足了规格”“这个实现是否引入了额外风险”“这个改动是否影响了已有功能”这三个维度挑刺。评审模块的运行机制包含两层静态规则检查层基于代码规范、架构约束、命名约定做机械性检查这一层完全可自动化。逻辑质量评审层对照规格和验收标准检查实现的完整性和一致性这一层需要 AI 具备推理能力。代码评审模块的输出是结构化的评审报告——不是一句“代码写得不错”或者“有些地方可以优化”这种没有信息量的话而是逐条列出问题、对应到具体代码位置、标注问题等级、给出修改建议。评审报告会回流给代码实现模块实现者根据报告修改后再次提交形成一个小闭环。这个小闭环出现之后我对“AI 编程质量”的理解发生了很大变化质量不是靠一个“更强大的生成模型”冲出来的而是靠“实现 验证”的循环迭代出来的。这也是为什么把评审从实现中独立出来、而不是合成一个 Agent是 Harness Engineering 框架里一个关键设计决策。2.5 持续集成验证把“看起来对了”变成“确实是对的”代码评审通过不代表代码真的没问题。人的认知局限和 AI 的幻觉都可能让“看起来合理”的东西在真实环境里跑不通。持续集成验证模块就是专门负责把静态审查升维到动态验证——拉代码、建环境、跑构建、执行测试、验证接口。这一模块并不需要发明新东西CI/CD 领域已经有非常成熟的工具链。Harness Engineering 给它加的价值是“验证任务的自动化生成”——流水线里跑哪些测试、验证哪些接口行为、覆盖哪些场景不再是人工手写的维护负担而是由前面的规格和评审结论自动推导出来。也就是说验证任务本身就是“被工程化设计”的对象。这个模块的实施难点不在技术而在“测试任务的规格化”。你需要告诉验证 Agent 这样几件事本次变更涉及的模块和数据流哪些必须纳入验证范围。相关测试的运行环境、依赖版本、Mock 规则。验证结束后的输出格式——测试报告、覆盖率报告、遗留风险清单。我见过不少团队把集成验证做成了“跑一遍流水线发一条消息看有没有变红”这不是 Harness Engineering。真正的持续集成验证模块输出的是一份“已验证的交付结论”而不是一个“构建通过”的状态徽章。验证结论会明确说明哪些规格条目已经确认满足哪些还存在风险哪些需要人工介入决策。2.6 交付发布让验收标准在最后一环真正沉淀交付发布模块是整个链路中承前启后的最后一站。前面所有模块的产出——规格、实现、评审结论、验证报告——都会在这里汇总形成一份完整的交付档案。验收标准在这里真正落到实处只有通过全部验证条目的交付物才能进入发布决策环节。这套机制把“发布”这个动作从“拍脑袋决定”或者“看一眼好像没问题”变成了一种流程化决策。每一次发布的依据都清晰可见哪个需求、对应什么规格条目、代码实现做了什么改动、评审发现了哪些问题、验证覆盖了哪些场景、已知风险是什么。交付发布模块的运行让整个团队对“什么情况可以发布”达成了共识。在具体实施中交付发布模块的输出包括发布清单本次发布包含的所有变更项每项对应到具体的规格编号和验证证据。回滚方案如果线上发现问题如何快捷回退到上一稳定版本影响范围是什么。遗留事项本次发布未解决的问题、以及它们对系统的影响等级和处理预案。交付发布模块跑顺之后带来的最大变化是发布从“心惊胆战的操作”变成了“例行公事的流程”。因为该验证的都已经验证过了未知风险被控制在一个可以接受的范围内。剩下的小概率事件由回滚方案兜底。这套逻辑让交付节奏稳定下来团队的心态也跟着稳定下来。3. 三角协作机制两个 AI 与一个人类如何配合3.1 为什么是“一个人类 两个 AI”而不是全自动把六大模块摆开之后一个自然的问题是既然 AI 能完成从需求澄清到交付发布的全部环节为什么还要留一个人类在流程里我的答案是AI 擅长在给定边界内稳定输出但边界的设定、方向的选择、以及异常情况下的决策在现阶段仍然需要人类来兜底。我设计的协作模型是“一人类运维 双 AI 工程师”。两个 AI 分别承担不同角色AI 建模工程师 A 负责代码实现AI 建模工程师 B 负责验证操作——这个“验证操作”角色并不只是做代码评审它还承担了验收标准在链路中不断细化的执行任务。人类运维在三角关系中的职责不是写代码也不是检查每一行输出而是三件事定义边界确认需求澄清的方向、把握规格的合理性、审批接口契约的变更。处理异常当 AI 之间的协作出现分歧比如评审报告不通过、验证结论不确认人类做最终判断。沉淀经验把项目运行中暴露出来的问题反馈到模块设计里让下一轮流程更完善。这套三角机制成立的前提是接口清晰。AI 与 AI 之间的接口是规格文档和评审报告——这两个结构化产物一旦定义好两个 AI 就能稳定地协作下去。AI 与人类之间的接口是决策点和异常事件——人类不需要全程在场只需要在关键节点介入。3.2 AI 与 AI 之间怎么“对话”一开始我尝试过让两个 AI Agent 直接用自然语言对话——“你帮我看看这个实现有什么问题”“我觉得这部分逻辑不太对”——结果效率很低对话经常跑偏还会出现两个 AI 互相客气的场面“你说得对我改一下”简直是人类无效会议的 AI 复刻。后来我改成了“产物驱动协作”两个 AI 之间不直接对话而是通过结构化产物交换信息。实现者输出实现报告验证者输出评审报告实现者根据评审报告修改并输出修改说明验证者复核并更新评审状态。每一步都对应一个可追踪的产物每一轮互动都有明确的输入和输出整个协作链路可以被完整审计。这个设计带来的直接收益是“责任可追溯”。谁提交了什么版本、评审提出了什么问题、是否已被解决、解决方式是什么——全部有记录。团队在做复盘或者处理线上故障时能快速定位问题出在哪个环节而不是在一堆聊天记录里翻找“当时是谁改的这个逻辑”。3.3 人类介入的“决策点”设计在三角协作机制里人类运维不需要时刻盯着流程但必须在关键决策节点到位。我把这些节点梳理成了三类边界确认节点需求澄清完成后、规格定稿前人类需要确认“这是我们想要做的事情”以及“我们明确不做的事情”。分歧仲裁节点当实现 Agent 和验证 Agent 对某一个问题无法达成一致——比如验证方认为存在风险实现方认为可以忽略——人类需要做最终裁决。发布审批节点交付发布前人类根据交付档案判断是否放行或者是否启动回滚方案。这三个节点数量不多但都在流程的“质变点”上。它们确保了整套系统既不会因为 AI 的自动化而失控也不会因为人类的过度介入而丧失效率。合理的节奏是AI 跑 90% 的流程人类在 10% 的决策点上创造价值。4. 模块与模型的匹配逻辑什么岗位用什么“员工”4.1 不同模块对模型能力的差异化要求在构建 Harness Engineering 的过程中我逐渐认识到一个容易被忽视的事实不是越强的模型放之四海而皆准而是不同的任务类型需要不同能力侧重的模型。你可以把这理解为招人——你不会让一个擅长写代码的人去干全部工作也不会让一个擅长沟通协调的人去做深度算法推导。AI 模型也一样不同模块对能力的需求有着明显的差异。需求澄清模块需要的是理解与提问能力。这个环节的输入是模糊的自然语言模型需要从碎片化描述中提取意图识别信息缺口并通过反问让用户把话说明白。什么样的模型适合那些对话感强、上下文理解能力突出、知道在什么时候该追问的模型。规格生成模块需要的是结构化与逻辑能力。输出物必须严谨、一致、可验证容不得“大概”“可能”“我觉得”这类模糊表达。模型的格式遵循能力、逻辑一致性、以及对契约式描述的把控水平在这个环节成了核心指标。代码实现模块需要的是执行能力与代码素养。它要在既定规格框架内生成符合架构约定的代码不能天马行空地重构全局也不能引入多余的抽象。具备良好的代码风格理解力、熟悉主流框架的模型是合适的选择。代码评审与持续集成验证模块需要的是批判性思维与细节辨别力。模型必须像一位严格的审计师能从实现中发现潜在缺陷、边界遗漏、性能隐患而不是顺着实现者的思路说“挺好”。到了交付发布模块重点又转向了信息汇总与决策支持能力需要模型把分散的信息拼装成完整、可审计、可追溯的交付档案。4.2 模型选型不当的典型翻车现场模型与模块错配的代价在早期实验里就给了我几个印象深刻的教训。最初我把一个擅长代码生成的模型用在需求澄清模块上结果它对用户说“请提供更明确的需求”却不知道围绕场景追问细节。被模糊需求喂大的代码自然不可能稳定实现这就是链路源头出了问题。反过来的案例同样精彩。某个推理能力极强但对话风格拘谨的模型被用在需求澄清的对话场景里用户体验非常僵硬——它能把用户已有的每句话都分析出一堆边界条件和假设唯独不会用一句顺滑的话引导对方把缺失的信息说出来活脱脱一个“学识渊博但不会聊天”的工程师。代码评审模块用错模型的场景也很常见。如果选了一个“迎合型”模型它输出的评审报告基本就是“实现整体质量良好部分地方可以优化”这种废话。真实的评审报告应该是克制甚至尖锐的这里并发处理有风险那里缓存策略违背了既定架构这个接口契约与规格描述不符。这些翻车经历让我养成了一个习惯在正式启用每个模块之前先用一组固定的测试样本去“面试”候选模型考察它在对应岗位上的具体表现。人选错了再好的制度和流程都发挥不出作用AI 系统也是一样。4.3 提示词、模型和输出约定的“铁三角”在 Harness Engineering 框架里每个模块的构建都遵循一个“铁三角”定制的提示词、特定的模型选择、明确的输出约定。三者缺一不可。提示词解决的是“让模型进入正确的角色和状态”的问题。代码实现模块的提示词包含角色设定“你是一名严格遵循架构约定的后端工程师”、上下文信息“以下是本次任务涉及的规格条目和接口定义”、以及约束条件“不得修改非任务范围内的文件”“必须处理规格中定义的异常分支”。模型选择解决的是“能力是否匹配任务”的问题。每个模块独立配置模型互不干扰。模型迭代时也只影响单个模块不会牵一发动全身。这种解耦带来的好处是当某个环节质量出现波动时优化是局部的不会引发整个系统的重构。输出约定解决的是“结果如何被下游消费”的问题。代码实现模块必须输出结构化变更说明评审模块必须输出按问题等级分类的评审报告验证模块必须输出测试覆盖结论。每个输出都有固定 schema可以被下一个模块直接消费不需要中间人做“翻译”。这三个要素的配合是整个框架里我最想强调的部分。很多人把“AI 编程”理解成“想一个好提示词然后让模型输出代码”但在工程化体系里提示词只是三分之一的变量。当三个变量都被控制住系统才能持续产出稳定结果。5. 任务工程化为什么这是多 AI 协作的前提5.1 “生成、修改、再生成”的死循环怎么破“AI 编程热潮减退的原因是什么”这个问题其实已经给出了答案的一半。热潮减退不是因为 AI 不行而是因为大多数人把 AI 用在了错误的工作模式上——无结构的“生成、修改、再生成”循环。在这种模式下AI 看起来一直在工作代码量不断膨胀但方向可能早就偏了或者同一个逻辑被改来改去最后变成一锅粥。Harness Engineering 的应对思路是任务工程化在让 AI 动手之前先把任务本身设计清楚。任务不是“把登录功能写出来”这种结果导向的描述而是“在规格条目编号 S-102 的约束下实现符合契约接口定义的后端登录逻辑完成输入校验、会话管理、异常处理三个子任务输出变更说明文档”这种过程可控的工程定义。任务工程化的核心要素包括角色分工、约束条件、契约接口与质量标准、工作流编排、以及任务和依赖管理工具。角色分工决定了谁做什么约束条件划定了“能做”与“不能做”的边界契约接口确保模块之间的衔接顺畅质量标准定义了“完成”的可接受底线工作流编排则把以上要素连接成有序的执行序列。一个让人意外的发现是任务工程化做得越细工具的操作界面就越简单。当智能体管理和依赖管理成为常态时系统的人机交互入口就会被极大简化。因为大量复杂性已经被前置到任务定义和流程编排中消化掉了人类不需要在界面上做一堆微调只需要面对几个清晰的决策点。这也让我意识到“界面复杂”和“系统强大”之间并没有必然关系真正的复杂度应该藏在工程化设计中而不是暴露给操作者。5.2 显式协作机制工具链不碎片化的关键在落地过程中另外一个高频出现的痛点是“反应式 AI 使工具链碎片化”。每个开发者都按自己的习惯使用各种 AI 插件和工具一些项目里甚至同时存在三四种风格迥异的 AI 辅助方案各自带一套上下文管理逻辑和输出范式。它们之间没有显式的协作机制最终表现在代码库里的就是混乱和不可维护。解决这个问题必须靠“显式协作”。所谓显式是指 AI 与 AI 之间、AI 与人之间的接口和交互方式被明确写出来而不是靠隐式的默契或者临时的口头沟通。规格文档就是显式的接口评审报告就是显式的反馈交付档案就是显式的审计记录。没有这些显式约定多 AI 协作就退化成“多个单点 AI 的简单叠加”不仅没有产生协同效应反而增加了协调成本。具体到工具层面我们做到了“每个模块的输出都是下一个模块的输入”。需求澄清模块产出结构化需求清单规格生成模块消费它并产出规格文档代码实现模块消费规格并产出代码与变更说明评审模块消费代码与规格并产出评审报告持续集成验证模块消费代码与测试任务并产出验证报告交付发布模块消费全部上游产物并产出交付档案。数据和信息在这个链条中一次流转、持续沉淀不会出现“换一个工具就要重新解释一遍上下文”的局面。5.3 配置化的工作流编排要让以上机制在真实项目中跑起来必须落到配置化的工作流编排上。我在实施中用 Yaml 定义过一条典型的工作流骨架以下为简化示意workflow: name: ai_delivery_pipeline stages: - stage: 需求澄清 agent: ai_requirement_analyst input: user_request output: requirement_doc - stage: 规格生成 agent: ai_spec_engineer input: requirement_doc output: spec_doc - stage: 代码实现 agent: ai_implement_engineer input: spec_doc output: code_delta - stage: 代码评审 agent: ai_review_engineer input: code_delta spec_doc output: review_report - stage: 持续集成验证 agent: ai_verification_engineer input: code_delta spec_doc review_report output: verification_report - stage: 交付发布 agent: ai_release_engineer input: verification_report review_report spec_doc output: release_archive这份配置看起来简单但它把一个复杂的协作问题做成了“可修改、可复用、可审计”的工程资产。换一个项目只需要调整具体的规格库、编码规约和验证用例集工作流骨架可以直接复用。当团队里来新人看一遍配置就能理解整套协作机制不需要靠口口相传。我有一个同事用了一句特别形象的话总结这套系统“这就像是给 AI 社团立了一套章程每个 AI 都清楚自己的职位和职责有事按章程办没事不越权。人也不用天天开会了。”这基本就是我感受到的真实效果。6. 落地过程中最值得说的经验与教训6.1 需求标准化带来的连锁收益在整个 Harness Engineering 的实施中需求澄清模块对我的冲击最大因为它直接改变了团队对“需求”这个概念的理解。过去需求被当作“用自然语言描述的希望”它天然模糊、天然依赖听者的猜测而在 Harness Engineering 的语境里需求被标准化为一种“工程输入”。标准化手段通常是设计一套需求模板配合自动接收需求的工具链。这套工具不只是一个“文档管道”更像是一个“软硬件需求自动化和工程化实现的工具”它接收各个来源的原始需求产品沟通记录、用户反馈、内部讨论片段自动补全缺失信息按模板生成结构化需求条目并把模糊的“想做点什么”转成“到底要做什么、验收标准是什么、场景限制在哪里”。这套体系运转一段时间后我发现一个意外的收益因为需求在源头就被标准化后续所有模块的效率都提高了。规格生成不再需要反复猜需求意图实现模块不再需要在“理解需求”上消耗上下文窗口评审模块能用需求条目逐条核对实现完整性。这不是某个模块的优化而是整条链路的复利效应。6.2 依赖管理和“上下文地板”问题多 AI 协作中有一个不明显但极其致命的坑“上下文地板”。当多个模块串联运行时每个模块的 AI 都只拿到上一模块的输出而不是整个链路的历史。如果上游模块遗忘了某个关键约束下游所有模块都会在“不知道这件事”的状态下工作——这就是一处低级错误经过链路放大后变成重大事故的典型路径。依赖管理在 Harness Engineering 里不只是代码层面的依赖还包括信息依赖。每个模块的输入必须显式声明它依赖了哪些上游产物并且由编排框架保证这些依赖在模块启动时被完整加载。实现模块需要的规格条目、评审模块需要的实现上下文、验证模块需要的测试基线都必须在对应模块启动前齐备。为了实战验证我做过这样一个实验故意在一个规格文档里隐藏了一条约束“本模块不支持超过 100 并发”然后在没有配置依赖管理的链路中运行。结果实现模块没有遵守约束评审模块也没有发现遗漏测试基线也没有覆盖边界场景。直到交付前人工检查才暴露。而配置了依赖管理之后这条约束会被自动传递给实现、评审、验证三个阶段的上下文问题在实现阶段就会被发现。6.3 我建议的小规模起步路径Harness Engineering 的全量落地确实需要不少前期投入。对于想尝试的团队我的建议是从小处入手而不是一次性上全套。比较务实的路径是第一步先做规格生成模块。这是整套系统中杠杆率最高的一个环节。只要把规格生成和代码实现分离让 AI 不再直接吞需求写代码输出的稳定性就会有可见提升。第二步增加代码评审模块。给实现配一个独立的验证视角形成“实现→评审→修改”的小闭环。这个闭环是质量提升的核心引擎。第三步接入持续集成验证。把验证任务从人工编写逐步改为自动化生成让每一次代码变更都有对应的验证证据。最后完善需求澄清和交付发布。当中间链路跑顺再回头补源头和末端把整条流水线串起来。这条路径的每一步都能独立产生收益不需要等全套就绪才见效。很多团队是在走了两三步之后才真正理解为什么要给 AI “配一间办公室”——不是办公室里的每个房间都同时需要而是这组房间本身构成了一个完整的空间多一个不多缺一个就让人感觉少了点什么。回到最初的问题AI 编程的热潮为什么会减退因为热闹过后能不能持续交付才是试金石。给 AI 配一间办公室不是为了把简单的事做复杂而是为了让“稳定交付”这件事常态化。当 AI 不再是一簇火花而是流水线上各司其职的成员团队对它的信任才会从“偶尔好用”变成“可以依赖”。这就是我理解中 Harness Engineering 最大的价值也是这套框架值得继续投入的理由。
Harness Engineering：给AI配一间专属办公室的体系化AI编程
1. 为什么要给 AI“配一间专属办公室”各个团队对“AI 编程”的探索基本都会经历一个相似的过程第一周觉得它无所不能第二周发现它经常自作聪明第三周开始怀疑是不是自己的打开方式不对。我见过不少项目组AI 工具装了一大堆prompt 写了几百条结果代码库里到处都是风格迥异的片段、互相矛盾的实现、以及“上次还能跑这次不知道为什么就不行”的玄学问题。问题出在哪里大多数人把 AI 当成一个随叫随到的“火花塞”——需要的时候点一下出结果就用不行就重新生成。但软件开发从来不是单点输出而是一条完整的价值链从模糊的想法到可执行的规格到具体代码实现到质量验证再到交付发布。如果 AI 只在这一条链路的某个节点上“闪一下”它产生的价值就会被上下游的混乱消耗掉。所以我才开始认真思考一件事与其让 AI 在每个人的编辑器里各自为战不如给它配一间“办公室”——把流程、岗位、接口、质量标准都定义清楚让 AI 在固定的工位上按照固定的规矩完成固定的交付物。这套做法就是 Harness Engineering。Harness 这个词在工程领域有“系绳、束缚”的意思用在 AI 协作上非常贴切不是限制 AI 的能力而是给它的能力配上明确的边界和轨道。边界越清晰输出越稳定轨道越明确协作越顺畅。这套思路落下来就是六个模块——需求澄清、规格生成、代码实现、代码评审、持续集成验证、交付发布——以及支撑这六个模块运转的一套基础设施。这篇文章会把我在实施 Harness Engineering 过程中踩过的坑、验证过的方法、以及最终沉淀下来的框架完整讲清楚。适合正在做 AI 辅助开发、想从“点状使用 AI”升级到“体系化使用 AI”的团队参考。内容会涉及具体模块设计、Agent 协作机制、以及真实项目中遇到的典型问题我尽量不用抽象的概念糊弄人全部拿实际场景说话。2. 六大模块拆解一条从想法到交付的完整链路2.1 需求澄清把“想做点什么”翻译成“到底要做什么”大多数项目死在第一步不是因为没有想法而是想法太模糊。“我想做一个更好用的后台管理系统”——这种需求交给任何工程师都做不好交给 AI 只会更糟。因为 AI 不具备人类的“心领神会”能力它需要的是明确、完整、无歧义的输入。需求澄清模块要解决的就是这个“从模糊到明确”的鸿沟。我在实践中给它定义了三个核心产物用户意图描述用自然语言记录用户想解决的问题但必须包含场景背景、已有约束、期望效果。功能性需求清单把意图拆解成具体的功能点每个功能点都对应一个可验证的行为。边界与限制声明明确系统不做什么避免 AI 在实现时自作主张地“扩展”。这里最关键的一点是需求澄清模块必须做到“每个输入都对应一个经过验证的输出”。也就是说不能用户说什么就记什么而是要经过一轮结构化追问——比如“这个功能在什么场景下使用”“数据量级大概是多少”“如果操作失败用户应该看到什么反馈”——把隐藏信息挖出来。我在实际项目中把这个环节做成了“需求对话模板”AI 根据模板反问用户而不是被动等待用户把需求一次性说全。一个很有意思的收获是需求澄清模块跑通之后团队内部的沟通质量也跟着提升了。以前产品经理和开发对需求的理解经常有偏差现在因为需求经过了一层结构化处理偏差在早期就被暴露出来后续返工大幅减少。这就是 Harness Engineering 的“溢出效应”——你本来是想约束 AI结果把人的协作也一起理顺了。2.2 规格生成把需求变成可验收的工程契约需求澄清的输出还是半自然语言的形态离“可执行”还有一段距离。规格生成模块要做的事情是把澄清后的需求进一步翻译成工程规格——也就是“到底要做什么、验收标准是什么、场景限制在哪里”这三件套的完整表达。规格不是文档而是契约。契约意味着双方都要遵守。我见过太多团队跳过这一步直接从需求跳到写代码结果就是 AI 生成的代码跟需求文档貌合神离。规格生成模块的产出物是这样的功能规格说明书每个功能模块的输入、处理逻辑、输出格式全部用结构化条目描述。接口契约模块与模块之间的交互协议包括参数类型、返回值结构、错误处理方式。验收标准表每个需求点对应的验证条件写清楚“满足什么条件算完成”。规格生成模块承担着一个重要的翻译职能把人类容易理解的“自然语言需求”转换成 AI 更容易理解的“结构化规格描述”。这个翻译质量直接决定了后续代码实现模块的表现。我在实施过程中发现给 AI 喂规格而不是喂原始需求生成的代码在架构一致性上会有一个质变——因为它不再需要自己“脑补”业务逻辑只需要按照规格执行。规格生成模块还有一个容易被忽略的细节模型选择很重要。需求澄清阶段可以选理解能力强的对话模型但规格生成阶段最好选逻辑推理能力强的模型对输出格式的稳定性要求也更高。同一个模型在这两个阶段的表现差异可能很大后面我会专门讲模块与模型的匹配逻辑。2.3 代码实现让 AI 在特定上下文里当“建模工程师”有了规格作为契约代码实现模块就能在一个相对稳定的上下文里工作了。这个模块里的 AI 不是一个通用的代码生成器而是一个被限定在特定任务边界内的“建模工程师”——它的职责就是把规格翻译成符合架构约定、符合代码规范、符合接口契约的实现。代码实现模块在 Harness Engineering 框架里承担的是“AI 建模工程师 A”的角色。它与普通 AI 编程的最大区别在于它拿到的输入不是一句“帮我写个登录功能”而是一份完整的任务单——包含功能规格、接口契约、依赖关系、编码规约、以及复用组件的清单。AI 在这个任务单约束下工作输出的是可审查、可测试、可集成的代码而不是一堆需要人再去整理拼装的“半成品”。在这个模块里我沉淀了三个关键经验上下文打包比提示词长度更重要。AI 真正需要的不是一条写得天花乱坠的指令而是一份让它能“进入工作状态”的完整上下文——包括规格条目、相关接口定义、代码风格样例、以及不要去动的部分。输出约定必须强制。代码实现模块的 AI 必须按约定输出结构化结果改了哪些文件、为什么改、影响范围是什么、有没有新增依赖。没有这些约定后续的代码评审和集成验证根本无法自动化。任务的粒度决定了质量的稳定度。任务切得越细AI 的完成度越高。我在实践中把大模块拆成小任务每个任务控制在 30 分钟到 2 小时的工作量代码实现的可靠性会明显提高。不少人觉得代码实现模块应该是整套系统里最聪明的部分但实际做下来会发现它更像是“执行能力最强”的部分。“聪明”已经被规格生成模块消耗掉了代码实现模块更重要的是按规矩执行。这也是 Harness Engineering 与“让 AI 自由发挥”的根本区别。2.4 代码评审用独立的“验证视角”审视实现结果代码评审模块在整个链条里承担着独特的职能——它不是让 AI 检查自己的代码而是让另一个具有“验证视角”的 AI 来审查“建模工程师 A”的产出。在流程角色设计上这就是“AI 建模工程师 B验证操作”的核心职责。为什么要用独立的 AI 来做评审而不是让实现代码的 AI 自评道理很简单人自己检查自己的错误会受惯性思维影响AI 也一样。实现者天然会倾向于为自己的设计辩护而评审者需要做的是从“这个代码是否满足了规格”“这个实现是否引入了额外风险”“这个改动是否影响了已有功能”这三个维度挑刺。评审模块的运行机制包含两层静态规则检查层基于代码规范、架构约束、命名约定做机械性检查这一层完全可自动化。逻辑质量评审层对照规格和验收标准检查实现的完整性和一致性这一层需要 AI 具备推理能力。代码评审模块的输出是结构化的评审报告——不是一句“代码写得不错”或者“有些地方可以优化”这种没有信息量的话而是逐条列出问题、对应到具体代码位置、标注问题等级、给出修改建议。评审报告会回流给代码实现模块实现者根据报告修改后再次提交形成一个小闭环。这个小闭环出现之后我对“AI 编程质量”的理解发生了很大变化质量不是靠一个“更强大的生成模型”冲出来的而是靠“实现 验证”的循环迭代出来的。这也是为什么把评审从实现中独立出来、而不是合成一个 Agent是 Harness Engineering 框架里一个关键设计决策。2.5 持续集成验证把“看起来对了”变成“确实是对的”代码评审通过不代表代码真的没问题。人的认知局限和 AI 的幻觉都可能让“看起来合理”的东西在真实环境里跑不通。持续集成验证模块就是专门负责把静态审查升维到动态验证——拉代码、建环境、跑构建、执行测试、验证接口。这一模块并不需要发明新东西CI/CD 领域已经有非常成熟的工具链。Harness Engineering 给它加的价值是“验证任务的自动化生成”——流水线里跑哪些测试、验证哪些接口行为、覆盖哪些场景不再是人工手写的维护负担而是由前面的规格和评审结论自动推导出来。也就是说验证任务本身就是“被工程化设计”的对象。这个模块的实施难点不在技术而在“测试任务的规格化”。你需要告诉验证 Agent 这样几件事本次变更涉及的模块和数据流哪些必须纳入验证范围。相关测试的运行环境、依赖版本、Mock 规则。验证结束后的输出格式——测试报告、覆盖率报告、遗留风险清单。我见过不少团队把集成验证做成了“跑一遍流水线发一条消息看有没有变红”这不是 Harness Engineering。真正的持续集成验证模块输出的是一份“已验证的交付结论”而不是一个“构建通过”的状态徽章。验证结论会明确说明哪些规格条目已经确认满足哪些还存在风险哪些需要人工介入决策。2.6 交付发布让验收标准在最后一环真正沉淀交付发布模块是整个链路中承前启后的最后一站。前面所有模块的产出——规格、实现、评审结论、验证报告——都会在这里汇总形成一份完整的交付档案。验收标准在这里真正落到实处只有通过全部验证条目的交付物才能进入发布决策环节。这套机制把“发布”这个动作从“拍脑袋决定”或者“看一眼好像没问题”变成了一种流程化决策。每一次发布的依据都清晰可见哪个需求、对应什么规格条目、代码实现做了什么改动、评审发现了哪些问题、验证覆盖了哪些场景、已知风险是什么。交付发布模块的运行让整个团队对“什么情况可以发布”达成了共识。在具体实施中交付发布模块的输出包括发布清单本次发布包含的所有变更项每项对应到具体的规格编号和验证证据。回滚方案如果线上发现问题如何快捷回退到上一稳定版本影响范围是什么。遗留事项本次发布未解决的问题、以及它们对系统的影响等级和处理预案。交付发布模块跑顺之后带来的最大变化是发布从“心惊胆战的操作”变成了“例行公事的流程”。因为该验证的都已经验证过了未知风险被控制在一个可以接受的范围内。剩下的小概率事件由回滚方案兜底。这套逻辑让交付节奏稳定下来团队的心态也跟着稳定下来。3. 三角协作机制两个 AI 与一个人类如何配合3.1 为什么是“一个人类 两个 AI”而不是全自动把六大模块摆开之后一个自然的问题是既然 AI 能完成从需求澄清到交付发布的全部环节为什么还要留一个人类在流程里我的答案是AI 擅长在给定边界内稳定输出但边界的设定、方向的选择、以及异常情况下的决策在现阶段仍然需要人类来兜底。我设计的协作模型是“一人类运维 双 AI 工程师”。两个 AI 分别承担不同角色AI 建模工程师 A 负责代码实现AI 建模工程师 B 负责验证操作——这个“验证操作”角色并不只是做代码评审它还承担了验收标准在链路中不断细化的执行任务。人类运维在三角关系中的职责不是写代码也不是检查每一行输出而是三件事定义边界确认需求澄清的方向、把握规格的合理性、审批接口契约的变更。处理异常当 AI 之间的协作出现分歧比如评审报告不通过、验证结论不确认人类做最终判断。沉淀经验把项目运行中暴露出来的问题反馈到模块设计里让下一轮流程更完善。这套三角机制成立的前提是接口清晰。AI 与 AI 之间的接口是规格文档和评审报告——这两个结构化产物一旦定义好两个 AI 就能稳定地协作下去。AI 与人类之间的接口是决策点和异常事件——人类不需要全程在场只需要在关键节点介入。3.2 AI 与 AI 之间怎么“对话”一开始我尝试过让两个 AI Agent 直接用自然语言对话——“你帮我看看这个实现有什么问题”“我觉得这部分逻辑不太对”——结果效率很低对话经常跑偏还会出现两个 AI 互相客气的场面“你说得对我改一下”简直是人类无效会议的 AI 复刻。后来我改成了“产物驱动协作”两个 AI 之间不直接对话而是通过结构化产物交换信息。实现者输出实现报告验证者输出评审报告实现者根据评审报告修改并输出修改说明验证者复核并更新评审状态。每一步都对应一个可追踪的产物每一轮互动都有明确的输入和输出整个协作链路可以被完整审计。这个设计带来的直接收益是“责任可追溯”。谁提交了什么版本、评审提出了什么问题、是否已被解决、解决方式是什么——全部有记录。团队在做复盘或者处理线上故障时能快速定位问题出在哪个环节而不是在一堆聊天记录里翻找“当时是谁改的这个逻辑”。3.3 人类介入的“决策点”设计在三角协作机制里人类运维不需要时刻盯着流程但必须在关键决策节点到位。我把这些节点梳理成了三类边界确认节点需求澄清完成后、规格定稿前人类需要确认“这是我们想要做的事情”以及“我们明确不做的事情”。分歧仲裁节点当实现 Agent 和验证 Agent 对某一个问题无法达成一致——比如验证方认为存在风险实现方认为可以忽略——人类需要做最终裁决。发布审批节点交付发布前人类根据交付档案判断是否放行或者是否启动回滚方案。这三个节点数量不多但都在流程的“质变点”上。它们确保了整套系统既不会因为 AI 的自动化而失控也不会因为人类的过度介入而丧失效率。合理的节奏是AI 跑 90% 的流程人类在 10% 的决策点上创造价值。4. 模块与模型的匹配逻辑什么岗位用什么“员工”4.1 不同模块对模型能力的差异化要求在构建 Harness Engineering 的过程中我逐渐认识到一个容易被忽视的事实不是越强的模型放之四海而皆准而是不同的任务类型需要不同能力侧重的模型。你可以把这理解为招人——你不会让一个擅长写代码的人去干全部工作也不会让一个擅长沟通协调的人去做深度算法推导。AI 模型也一样不同模块对能力的需求有着明显的差异。需求澄清模块需要的是理解与提问能力。这个环节的输入是模糊的自然语言模型需要从碎片化描述中提取意图识别信息缺口并通过反问让用户把话说明白。什么样的模型适合那些对话感强、上下文理解能力突出、知道在什么时候该追问的模型。规格生成模块需要的是结构化与逻辑能力。输出物必须严谨、一致、可验证容不得“大概”“可能”“我觉得”这类模糊表达。模型的格式遵循能力、逻辑一致性、以及对契约式描述的把控水平在这个环节成了核心指标。代码实现模块需要的是执行能力与代码素养。它要在既定规格框架内生成符合架构约定的代码不能天马行空地重构全局也不能引入多余的抽象。具备良好的代码风格理解力、熟悉主流框架的模型是合适的选择。代码评审与持续集成验证模块需要的是批判性思维与细节辨别力。模型必须像一位严格的审计师能从实现中发现潜在缺陷、边界遗漏、性能隐患而不是顺着实现者的思路说“挺好”。到了交付发布模块重点又转向了信息汇总与决策支持能力需要模型把分散的信息拼装成完整、可审计、可追溯的交付档案。4.2 模型选型不当的典型翻车现场模型与模块错配的代价在早期实验里就给了我几个印象深刻的教训。最初我把一个擅长代码生成的模型用在需求澄清模块上结果它对用户说“请提供更明确的需求”却不知道围绕场景追问细节。被模糊需求喂大的代码自然不可能稳定实现这就是链路源头出了问题。反过来的案例同样精彩。某个推理能力极强但对话风格拘谨的模型被用在需求澄清的对话场景里用户体验非常僵硬——它能把用户已有的每句话都分析出一堆边界条件和假设唯独不会用一句顺滑的话引导对方把缺失的信息说出来活脱脱一个“学识渊博但不会聊天”的工程师。代码评审模块用错模型的场景也很常见。如果选了一个“迎合型”模型它输出的评审报告基本就是“实现整体质量良好部分地方可以优化”这种废话。真实的评审报告应该是克制甚至尖锐的这里并发处理有风险那里缓存策略违背了既定架构这个接口契约与规格描述不符。这些翻车经历让我养成了一个习惯在正式启用每个模块之前先用一组固定的测试样本去“面试”候选模型考察它在对应岗位上的具体表现。人选错了再好的制度和流程都发挥不出作用AI 系统也是一样。4.3 提示词、模型和输出约定的“铁三角”在 Harness Engineering 框架里每个模块的构建都遵循一个“铁三角”定制的提示词、特定的模型选择、明确的输出约定。三者缺一不可。提示词解决的是“让模型进入正确的角色和状态”的问题。代码实现模块的提示词包含角色设定“你是一名严格遵循架构约定的后端工程师”、上下文信息“以下是本次任务涉及的规格条目和接口定义”、以及约束条件“不得修改非任务范围内的文件”“必须处理规格中定义的异常分支”。模型选择解决的是“能力是否匹配任务”的问题。每个模块独立配置模型互不干扰。模型迭代时也只影响单个模块不会牵一发动全身。这种解耦带来的好处是当某个环节质量出现波动时优化是局部的不会引发整个系统的重构。输出约定解决的是“结果如何被下游消费”的问题。代码实现模块必须输出结构化变更说明评审模块必须输出按问题等级分类的评审报告验证模块必须输出测试覆盖结论。每个输出都有固定 schema可以被下一个模块直接消费不需要中间人做“翻译”。这三个要素的配合是整个框架里我最想强调的部分。很多人把“AI 编程”理解成“想一个好提示词然后让模型输出代码”但在工程化体系里提示词只是三分之一的变量。当三个变量都被控制住系统才能持续产出稳定结果。5. 任务工程化为什么这是多 AI 协作的前提5.1 “生成、修改、再生成”的死循环怎么破“AI 编程热潮减退的原因是什么”这个问题其实已经给出了答案的一半。热潮减退不是因为 AI 不行而是因为大多数人把 AI 用在了错误的工作模式上——无结构的“生成、修改、再生成”循环。在这种模式下AI 看起来一直在工作代码量不断膨胀但方向可能早就偏了或者同一个逻辑被改来改去最后变成一锅粥。Harness Engineering 的应对思路是任务工程化在让 AI 动手之前先把任务本身设计清楚。任务不是“把登录功能写出来”这种结果导向的描述而是“在规格条目编号 S-102 的约束下实现符合契约接口定义的后端登录逻辑完成输入校验、会话管理、异常处理三个子任务输出变更说明文档”这种过程可控的工程定义。任务工程化的核心要素包括角色分工、约束条件、契约接口与质量标准、工作流编排、以及任务和依赖管理工具。角色分工决定了谁做什么约束条件划定了“能做”与“不能做”的边界契约接口确保模块之间的衔接顺畅质量标准定义了“完成”的可接受底线工作流编排则把以上要素连接成有序的执行序列。一个让人意外的发现是任务工程化做得越细工具的操作界面就越简单。当智能体管理和依赖管理成为常态时系统的人机交互入口就会被极大简化。因为大量复杂性已经被前置到任务定义和流程编排中消化掉了人类不需要在界面上做一堆微调只需要面对几个清晰的决策点。这也让我意识到“界面复杂”和“系统强大”之间并没有必然关系真正的复杂度应该藏在工程化设计中而不是暴露给操作者。5.2 显式协作机制工具链不碎片化的关键在落地过程中另外一个高频出现的痛点是“反应式 AI 使工具链碎片化”。每个开发者都按自己的习惯使用各种 AI 插件和工具一些项目里甚至同时存在三四种风格迥异的 AI 辅助方案各自带一套上下文管理逻辑和输出范式。它们之间没有显式的协作机制最终表现在代码库里的就是混乱和不可维护。解决这个问题必须靠“显式协作”。所谓显式是指 AI 与 AI 之间、AI 与人之间的接口和交互方式被明确写出来而不是靠隐式的默契或者临时的口头沟通。规格文档就是显式的接口评审报告就是显式的反馈交付档案就是显式的审计记录。没有这些显式约定多 AI 协作就退化成“多个单点 AI 的简单叠加”不仅没有产生协同效应反而增加了协调成本。具体到工具层面我们做到了“每个模块的输出都是下一个模块的输入”。需求澄清模块产出结构化需求清单规格生成模块消费它并产出规格文档代码实现模块消费规格并产出代码与变更说明评审模块消费代码与规格并产出评审报告持续集成验证模块消费代码与测试任务并产出验证报告交付发布模块消费全部上游产物并产出交付档案。数据和信息在这个链条中一次流转、持续沉淀不会出现“换一个工具就要重新解释一遍上下文”的局面。5.3 配置化的工作流编排要让以上机制在真实项目中跑起来必须落到配置化的工作流编排上。我在实施中用 Yaml 定义过一条典型的工作流骨架以下为简化示意workflow: name: ai_delivery_pipeline stages: - stage: 需求澄清 agent: ai_requirement_analyst input: user_request output: requirement_doc - stage: 规格生成 agent: ai_spec_engineer input: requirement_doc output: spec_doc - stage: 代码实现 agent: ai_implement_engineer input: spec_doc output: code_delta - stage: 代码评审 agent: ai_review_engineer input: code_delta spec_doc output: review_report - stage: 持续集成验证 agent: ai_verification_engineer input: code_delta spec_doc review_report output: verification_report - stage: 交付发布 agent: ai_release_engineer input: verification_report review_report spec_doc output: release_archive这份配置看起来简单但它把一个复杂的协作问题做成了“可修改、可复用、可审计”的工程资产。换一个项目只需要调整具体的规格库、编码规约和验证用例集工作流骨架可以直接复用。当团队里来新人看一遍配置就能理解整套协作机制不需要靠口口相传。我有一个同事用了一句特别形象的话总结这套系统“这就像是给 AI 社团立了一套章程每个 AI 都清楚自己的职位和职责有事按章程办没事不越权。人也不用天天开会了。”这基本就是我感受到的真实效果。6. 落地过程中最值得说的经验与教训6.1 需求标准化带来的连锁收益在整个 Harness Engineering 的实施中需求澄清模块对我的冲击最大因为它直接改变了团队对“需求”这个概念的理解。过去需求被当作“用自然语言描述的希望”它天然模糊、天然依赖听者的猜测而在 Harness Engineering 的语境里需求被标准化为一种“工程输入”。标准化手段通常是设计一套需求模板配合自动接收需求的工具链。这套工具不只是一个“文档管道”更像是一个“软硬件需求自动化和工程化实现的工具”它接收各个来源的原始需求产品沟通记录、用户反馈、内部讨论片段自动补全缺失信息按模板生成结构化需求条目并把模糊的“想做点什么”转成“到底要做什么、验收标准是什么、场景限制在哪里”。这套体系运转一段时间后我发现一个意外的收益因为需求在源头就被标准化后续所有模块的效率都提高了。规格生成不再需要反复猜需求意图实现模块不再需要在“理解需求”上消耗上下文窗口评审模块能用需求条目逐条核对实现完整性。这不是某个模块的优化而是整条链路的复利效应。6.2 依赖管理和“上下文地板”问题多 AI 协作中有一个不明显但极其致命的坑“上下文地板”。当多个模块串联运行时每个模块的 AI 都只拿到上一模块的输出而不是整个链路的历史。如果上游模块遗忘了某个关键约束下游所有模块都会在“不知道这件事”的状态下工作——这就是一处低级错误经过链路放大后变成重大事故的典型路径。依赖管理在 Harness Engineering 里不只是代码层面的依赖还包括信息依赖。每个模块的输入必须显式声明它依赖了哪些上游产物并且由编排框架保证这些依赖在模块启动时被完整加载。实现模块需要的规格条目、评审模块需要的实现上下文、验证模块需要的测试基线都必须在对应模块启动前齐备。为了实战验证我做过这样一个实验故意在一个规格文档里隐藏了一条约束“本模块不支持超过 100 并发”然后在没有配置依赖管理的链路中运行。结果实现模块没有遵守约束评审模块也没有发现遗漏测试基线也没有覆盖边界场景。直到交付前人工检查才暴露。而配置了依赖管理之后这条约束会被自动传递给实现、评审、验证三个阶段的上下文问题在实现阶段就会被发现。6.3 我建议的小规模起步路径Harness Engineering 的全量落地确实需要不少前期投入。对于想尝试的团队我的建议是从小处入手而不是一次性上全套。比较务实的路径是第一步先做规格生成模块。这是整套系统中杠杆率最高的一个环节。只要把规格生成和代码实现分离让 AI 不再直接吞需求写代码输出的稳定性就会有可见提升。第二步增加代码评审模块。给实现配一个独立的验证视角形成“实现→评审→修改”的小闭环。这个闭环是质量提升的核心引擎。第三步接入持续集成验证。把验证任务从人工编写逐步改为自动化生成让每一次代码变更都有对应的验证证据。最后完善需求澄清和交付发布。当中间链路跑顺再回头补源头和末端把整条流水线串起来。这条路径的每一步都能独立产生收益不需要等全套就绪才见效。很多团队是在走了两三步之后才真正理解为什么要给 AI “配一间办公室”——不是办公室里的每个房间都同时需要而是这组房间本身构成了一个完整的空间多一个不多缺一个就让人感觉少了点什么。回到最初的问题AI 编程的热潮为什么会减退因为热闹过后能不能持续交付才是试金石。给 AI 配一间办公室不是为了把简单的事做复杂而是为了让“稳定交付”这件事常态化。当 AI 不再是一簇火花而是流水线上各司其职的成员团队对它的信任才会从“偶尔好用”变成“可以依赖”。这就是我理解中 Harness Engineering 最大的价值也是这套框架值得继续投入的理由。
