技术革命级碰撞，Harness Engineering 之下，SDD 的不可替代性

最近一段时间AI工程圈里最热门的概念莫过于Harness Engineering。HashiCorp联合创始人、Terraform缔造者Mitchell Hashimoto还有OpenAI工程团队相继发文详细阐述了一套让AI Agent可靠工作的工程方法论。与此同时我自己也在实践一套规范驱动的AI Coding工作流核心就是搭建一套完整的Spec体系把系统的意图、契约、行为规范都结构化地写入代码仓库让AI Agent有章可循、有据可查。这里需要特别说明一下本文中提到的“规范驱动AI Coding”方法我简称它为SDD也就是Spec-Driven Development特指通过结构化规范驱动Agent编程的方法论。这个SDD是一个特定的概念和实践框架和传统软件工程中的其他方法论有着明显区别大家不要混淆。这就引出了一个很多人都在困惑的问题在AI技术飞速迭代、Harness Engineering概念刚刚兴起的今天我们花费大量精力去构建这套Spec体系到底还有没有意义随着Harness的工具和环境体系不断完善Spec会不会在不久的将来变得多余甚至彻底过时在仔细研读了OpenAI和Mitchell Hashimoto的一手文章后结合我自己长期的SDD实践经验我对基于SDD的AI Coding工作流有了更深入的思考也梳理出了一些自己的见解今天就和大家好好聊聊这个话题帮大家解开心中的疑惑。先给大家一个核心结论省得大家花时间找重点Harness Engineering和SDD不是竞争关系而是同一件事的两个层面。OpenAI的文章其实说得很清楚工程纪律并没有消失只是从“写好代码”转移到了“构建好让Agent工作的scaffolding”支撑结构。而Spec也就是那些写进仓库的意图、契约和规范正是这个支撑结构的核心内容之一。Harness的能力越强执行效率越高Spec的质量对最终结果的影响就越大。简单来说Harness是放大器Spec是被放大的内容。所以SDD不仅有意义而且非常重要这不是因为Harness不够好恰恰是因为Harness把Spec的重要性无限放大了。一、先搞懂Harness到底是什么要回答“SDD还有没有意义”这个问题我们首先得把Harness这个概念搞清楚因为很多人在讨论的时候对这个词的理解都很模糊甚至存在偏差。其实Mitchell Hashimoto和OpenAI从不同视角给我们讲清楚了Harness的核心内涵两者结合起来就能完整理解它的本质。Mitchell Hashimoto在2026年2月的博客里把自己的AI采纳之旅分成了六个阶段其中第五阶段就是“Engineer the Harness”。他对Harness的定义非常简洁只有一句话每当你发现Agent犯了一个错误你就花时间去工程化一个解决方案让它再也不会犯同样的错。他还提到了两类具体的做法很有参考价值。第一类是在AGENTS.md文件里记录Agent的坏行为模式防止这类错误再次出现。他以Ghostty项目的AGENTS.md为例说那个文件里的每一行内容都来自一次真实的坏行为而写进去之后这些问题几乎全部得到了解决。第二类是编写专用的工具脚本比如截图工具、过滤测试工具等让Agent有办法自己验证自己的工作是否做对了不用每次都依赖人类去检查。从Mitchell的视角来看Harness更偏向于工程师的个人实践核心逻辑就是Agent出错后不反复纠正而是从根源上工程化地消除这个错误的可能性让Agent下次遇到同样的情况时能自动避开错误。而OpenAI工程团队在2026年2月的官方博客《Harness Engineering》中从团队系统的层面给我们展示了一次更大规模的实践。他们用5个月时间从空仓库开始生成了约100万行代码完成了1500个PR这些全部都是由Agent生成的。这里的“全部由Agent生成”指的是代码层面的工作而人类工程师的工作已经转移到了定义产品规格、设计约束、搭建反馈系统等“支撑结构”上。那么OpenAI的Harness到底是什么样的它是一套完整的环境体系里面包含了结构化的docs/目录、product-specs/产品规格、exec-plans/执行计划、design-docs/设计文档还有架构约束比如自定义linter和结构测试以及反馈回路比如可观测性工具直接接入Agent运行时另外还有定期运行的“垃圾回收”Agent专门用来扫描架构漂移及时发现并修正问题。虽然Mitchell和OpenAI的视角不同一个偏向个人实践一个偏向团队系统但两者指向的核心是一致的Harness是让Agent可靠工作的系统而不只是AI模型本身。它不是单一的工具而是一整套包含规范、约束、反馈、验证的完整体系目的就是让Agent的输出更可靠、更符合人类的预期。二、OpenAI的核心观点工程纪律没有消失只是转移了OpenAI在官方《Harness Engineering》博客文章中有一段话非常关键我给大家意译一下显而易见的是构建软件仍然需要纪律但纪律更多地体现在支撑结构上而不是代码上。保持代码库一致性的工具、抽象和反馈回路变得越发重要。我们当前最棘手的挑战集中在设计环境、反馈回路和控制系统方面帮助智能体实现我们的目标也就是大规模构建和维护复杂、可靠的软件。这句话重新定义了“工程纪律”的所在也彻底打破了很多人的误解。在没有AI Agent的时代我们的工程纪律体现在哪里体现在好好写代码、认真做code review、严格遵守编码规范每一行代码都要反复检查确保没有错误。但现在随着Agent的广泛应用工程纪律的重心转移了转移到了构建好让Agent工作的环境上包括结构化的文档、明确的约束规则、完善的反馈回路等。简单来说以前我们关注的是“如何写好代码”现在我们关注的是“如何构建支撑Agent工作的系统体系”这个转移我们可以总结为从代码驱动转移到了环境设计。而这个环境设计的核心就是支撑结构的质量而支撑结构的质量又由写进去的内容决定。大家可以仔细想想OpenAI自己的Harness里维护着product-specs/、design-docs/、exec-plans/这些文件夹里面都是结构化写进仓库的“意图和规范”。他们在实践中总结出一个核心发现大意是从智能体的角度来看它在运行时无法在情境中访问的任何内容都是不存在的。那些存储在Google Docs、聊天记录里或者只存在于人们头脑中的知识都无法被系统访问。只有代码仓库本地的、已版本化的工件才是Agent所能看到的全部。这句话不是隐喻而是实实在在的事实。Agent不像人类它没有记忆也无法主动去联想那些没有被明确提供的信息它只能依赖于代码仓库里能直接读取到的内容进行推理和工作。所以Harness里的支撑结构本质上就是所有被写进仓库、Agent可以读到、可以推理的内容包括规范、意图、约束、决策记录等。说到这里大家应该就能明白“把意图和规范写进仓库”本身就是Harness Engineering的核心工作之一。而这恰恰就是SDD所倡导和实践的核心内容。所以从这个角度来说SDD不仅没有过时反而和Harness Engineering高度契合是Harness体系中不可或缺的一部分。三、Spec在Harness里的三个核心角色缺一不可明白了“支撑结构由写进去的内容决定”我们就能清晰地看到Spec在Harness里的核心角色。它不是Harness的附件也不是可有可无的补充而是Harness能正常运转的前提之一。具体来说Spec在Harness里扮演着三个至关重要的角色每一个都不可或缺。一角色一Agent推理的“地图”而非“说明书”OpenAI有一条非常重要的实践原则要给Codex的是一张地图而不是一本1000页的说明书。这句话的核心的是实现“渐进式披露”让智能体从一个小而稳定的切入点开始然后被指导下一步该去哪里查看而不是一开始就被海量的信息淹没无从下手。而这正是Spec应该具备的特质它是一张地图而不是一本百科全书。地图的特点是什么有目录、有指针能让人快速找到自己需要的内容。Agent可以从高层概览出发按需深入到具体的节点不用一次性读完所有内容。具体来说系统级Spec会告诉Agent这个系统有哪些服务每个服务各自负责什么服务之间的边界在哪里。服务级Spec会告诉Agent这个服务内部有哪些能力接口语义是什么行为规则是什么。有了这张“地图”Agent就能明确自己的工作边界和方向知道该去哪里找自己需要的信息。如果没有这张“地图”Agent的工作起点就只能是代码。但代码只能告诉它“系统现在是什么样”无法告诉它“为什么是这样”“哪些是不应该改的”“这个字段在跨服务之间有什么约定”。没有这些信息Agent就只能靠猜测来工作而猜测就必然会出现错误尤其是在复杂系统中一个小小的猜测错误都可能导致整个系统出现问题。二角色二约束生效的语义基础填补linter的空白OpenAI在实践中会用linter和结构测试来机械地强制执行架构规则比如层间依赖方向、文件大小限制、命名规范等。这些都是“格式”层面的约束是可以完全自动化的只要设置好规则linter就能自动检查发现不符合规范的地方。但问题是linter只能检查格式检查不了语义。它不知道某个错误码在跨服务场景下应该怎么处理不知道某个接口字段在特定来源场景下的业务含义也不知道某个状态的流转规则是什么。这些语义层面的约定是linter无法覆盖的但却是Agent必须知道的否则就无法正确推理和工作。而Spec的契约层和行为规格层承载的正是这类“linter管不到、但Agent必须知道”的语义约定。这些语义约定被显式地写下来Agent才能正确理解才能避免因为语义误解而出现错误。我在自己的SDD AI Coding实践中就遇到过这样的问题。服务A定义了某个错误码的含义但服务B的Agent在实现时完全不知道这个跨服务的语义于是就沉默地猜测了一个处理方式。AI的猜测有一个特点它不会告诉你“这里我猜了”它只会生成一段看起来合理的代码然后上线后才会发现行为不符合预期造成不必要的损失。这个bug的出现不是因为Agent的能力不够而是因为跨服务的错误码契约没有被写进Spec在Harness的支撑结构里这一块是空白的。后来我们在系统级Spec里补充了完整的错误码契约同一个Agent生成的实现就通过了验证。这说明不是我们换了更强的模型而是补上了缺失的语义定义让Agent有了明确的依据自然就能做对。三角色三反馈回路的正确性判据让错误可被发现Harness Engineering的核心飞轮是这样的Agent犯错诊断原因工程化修复Agent不再重犯。这个飞轮能持续运转的前提是第一步“Agent犯错”能够被及时发现。而要发现Agent犯错就需要一个“正确性的判据”也就是对照什么来判断Agent的输出是对是错。如果只有代码这个判据很难建立。因为代码只描述了“系统实际是什么样”不描述“系统应该是什么样”。我们只能靠人肉review靠把系统跑起来看结果甚至靠上线后被用户发现问题这样不仅效率低而且容易遗漏很多错误尤其是边界条件下的错误。而Spec的验收标准层也就是描述“在什么条件下系统应该有什么行为”的结构化场景提供的正是这个判据。Agent的实现可以被自动对照Spec里定义的场景来验证比如覆盖了哪些场景哪些没有覆盖哪些行为和Spec描述不一致。有了这个判据反馈回路才能闭合“发现错误”这一步才能变得高效、准确而不是靠运气。举个例子我们在Spec里定义了“当用户输入为空时系统应该返回特定错误码并提示用户输入”这个场景Agent生成代码后我们就可以自动对照这个场景进行测试看看Agent的实现是否符合预期。如果不符合就可以及时诊断原因补充或修改Spec让Agent下次不再犯同样的错误。这就是Spec在反馈回路中扮演的核心角色。四、规范驱动SDDAI Coding把Harness里的Spec做对、做好理解了Spec在Harness里的三个核心角色我们再回到最初的问题规范驱动AI Coding还有意义吗答案是肯定的而且意义重大。因为规范驱动AI Coding也就是我们说的SDD不是独立于Harness的另一套东西而是在回答一个核心问题Harness里的Spec应该长什么样、包含什么、如何组织才能真正让Agent可以推理、可以执行、可以验证。一Spec的质量决定了Agent能做对什么Agent的输出质量有一个简单的上限那就是它的输入质量。Spec写得越完整、越精确Agent猜测的空间就越小产出正确结果的概率就越高。我前面提到的错误码契约的案例就充分说明了这一点。不是我们换了更强的模型而是补全了Spec同一个Agent就能一次做对。而且Spec的价值是在三个层次上逐步递进的。第一个层次是在一个capability能力内做对通过WHEN/THEN场景约束行为边界让Agent在单一能力范围内不出现错误。第二个层次是多服务联动做对通过系统级契约让各个服务的Agent看到同一份语义避免跨服务的语义误解确保多服务协同工作时的一致性。第三个层次是改了还对通过验证规范提供持续的回归基线即使系统发生变更也能确保Agent的输出始终符合预期不会出现回归错误。OpenAI在实践中也走了这条路他们的Agent在处理“这四个关键用户旅程中的任何跨度都不得超过两秒”这样的约束时就需要靠写进仓库的可观测性配置和规范文档Agent才能正确推理和验证确保满足这个约束条件。如果没有这些规范Agent根本无法理解这个非功能约束自然也就无法实现预期的效果。二SDD消灭的是返工不只是提速很多人对SDD有一个常见的误解认为规范驱动AI Coding是“先写文档再写代码”前期投入太多时间和精力会拖慢开发进度。但实际上规范驱动方法优化的不是“写出第一版代码的速度”而是“正确交付的总成本”。我们可以对比一下没有Spec和有Spec的情况。没有Spec时跨服务的歧义要等到联调的时候才会暴露边界条件要等到上线后才会被发现每次新的AI会话都要从零重建上下文反复和Agent沟通确认需求和规范。这些隐性成本加起来远远超过了写Spec的前期投入。我自己的实践经历也充分印证了这一点。在SDD实践初期我们也遇到过进度稍慢的情况但随着Spec体系的逐步完善后续修复变更的时间几乎全部来自初版Spec精度不足。比如错误码语义、非功能约束、边界条件没有在Spec中定义Agent只能猜测上线后才发现问题不得不返工修改。而一旦Spec写得完整、精确Agent就能一次生成符合预期的代码返工率大幅降低整体交付效率反而提升了。OpenAI的工程师们也有同样的发现。他们花了大量时间把越来越多的“原本在人脑里的东西”显式地写进仓库。他们在博客中提到那次让团队在架构模式上达成一致的Slack讨论如果智能体无法发现它那么它就会像迟了三个月入职的新员工一样对其一无所知。这些隐藏在聊天记录、人脑里的知识一旦没有被写进SpecAgent就无法获取只能靠猜测进而导致错误和返工。所以前移写进Spec的成本本质上是在消灭后移的返工和猜测成本从长期来看是更高效、更经济的做法。三知识资产化Spec是可继承的工程记忆AI Coding的普及也加速了一个已有的问题那就是知识随人和会话流失。在Vibe Coding模式下也就是不做规划、随意向AI提需求的开发方式大量的设计决策、跨服务约定、“为什么不选另一个方案”的讨论全部停留在一次性的AI对话里。下一个人接手或者下一次AI会话完全无从获取这些关键信息只能重新沟通、重新确认浪费大量时间。而Spec的价值就在于把这些知识从“人脑对话历史”转化为“仓库里版本化的结构化资产”。系统级Spec记录跨服务约定服务级Spec记录各服务的语义决策记录层记录“为什么选了这个方案、排除了什么”。人可以换AI session可以换但Spec会一直留在仓库里成为可继承、可复用的工程记忆。这也是Harness里支撑结构能长期有效的前提。如果支撑结构里的知识无法继承每次换人和换AI会话都要重新搭建那么Harness的价值就会大打折扣。而Spec作为可继承的工程记忆能确保Harness的支撑结构持续发挥作用让Agent无论在什么情况下都能获取到一致、准确的知识。四人才能力迁移从写代码到设计环境OpenAI的文章里有一段话描述了他们实验中的角色转变非常有启发意义。他们说当事情进行不顺利时解决方案基本上再也不会是“再努力一点”。因为取得进展的唯一方式是让Codex来完成工作而人类工程师则总是介入这项任务并追问“究竟还需要什么样的能力我们又该如何让这个能力对智能体来说既清晰可读又可强制执行”这个“追问”其实就是SDD在做的事情。写Spec的过程本质上就是在回答这个追问系统需要什么能力这个能力的边界在哪里行为规则是什么失败的场景怎么处理这些信息怎么组织才能让Agent既能读懂又能执行随着AI Agent的普及人类工程师的核心能力也在发生迁移。以前我们的核心能力是“写好代码”而现在“把模糊意图转化为精确、结构化、可被Agent消费的定义”这个能力正变得越来越重要。而SDD的Spec编写和审查流程本身就是对这个能力的训练和提升。未来优秀的工程师不再是“写代码最快的人”而是“能设计出最优环境、能写出最精准Spec的人”。因为他们能让Agent发挥最大的价值高效、准确地完成代码编写工作而自己则专注于更核心的设计和决策工作。五一套典型的规范驱动方案到底长什么样很多人可能会问既然SDD这么重要那一套典型的规范驱动方案到底长什么样其实OpenAI自己的实践已经给我们提供了一个非常具体的参照。在OpenAI的实践中他们的仓库里维护着三类结构化文档product-specs/产品规格、design-docs/设计文档、exec-plans/执行计划。这三类文档各自承担着不同粒度的角色相互配合形成了完整的Spec体系。产品规格定义系统要做什么明确产品的核心需求和目标设计文档描述技术方案说明如何实现产品规格中的需求执行计划拆解具体任务指导Agent一步步完成开发工作。Agent在工作时会从高层的产品规格出发按需深入到设计文档和执行计划不需要一次性读完所有内容。这正是OpenAI所说的“渐进式披露”的工程化落地让Agent从稳定的高层视图切入被指引着找到它需要的那部分信息而不是一开始就被海量文档淹没无从下手。而规范驱动开发SDD的核心就是如何把意图、契约、行为规范按这个逻辑组织起来让Agent既能找到“地图”又能在需要时深入到细节。在整套体系里人类其实只做两件事提供原始意图比如口述需求、架构决策以及审查AI生成的Spec和代码。这里有一个关键点Spec的生成不是由人类直接编写的而是由AI主导基于引导式对话从人类的非结构化输入中提取、精化、结构化。人类不直接编写Spec文件但会审查Spec。这是因为审查Spec比审查代码简单得多我们审查的是自己意图的结构化表达而不是AI对我们意图的解读。这样既能节省人类的时间和精力又能确保Spec的准确性让Agent有可靠的依据。五、Harness Engineering的实践启示完善SDD落地细节前面我们已经说清楚了SDD为什么有意义以及SDD的核心内容。这一节我想和大家分享一些Harness Engineering带来的具体启示。读完OpenAI和Mitchell Hashimoto的文章我发现有些东西不仅印证了SDD的方向更让一些原本模糊的事情变得清晰也看到了一些典型SDD方案里还需要补充的地方。这些启示能帮助我们更好地落地SDD让Spec在Harness体系中发挥更大的作用。启示一人类注意力是最稀缺的资源审查重心应在Spec而非代码OpenAI的整篇文章有一条隐线贯穿始终人类的时间和注意力是固定的限制因素所有的工程投入都是在想办法让这有限的注意力产生最大的杠杆效应。他们在文章中提到我们优先处理工作将用户反馈转化为验收标准并对结果进行验证。这句话的核心就是人类要做的是“定义正确性”而不是“检查每一行代码”。在一套SDD方案里人类只做两件事提供原始意图以及审查AI生成的Spec和代码。Harness的视角让这两件事的优先级顺序变得更加清晰Spec ReviewSpec审查是上游控制Code Review代码审查是反馈入口。为什么说Spec Review是上游控制因为一个场景被遗漏、一个字段语义被写模糊Agent会在整个实现过程中持续放大这个偏差。实现、测试、文档都会基于这个有缺陷的定义生成出来。如果在Spec层就发现问题修改成本非常低只需要修改Spec即可。但如果等到代码生成之后再发现问题涉及的改动范围就会大得多不仅要修改代码还要修改测试、文档甚至可能影响其他相关服务返工成本极高。而Code Review的主要价值更多在于“发现Spec没有定义清楚的地方并把它补回Spec”而不仅仅是“检查Agent写得好不好”。每一个在代码Review里发现的语义问题本质上都是一个Spec缺口。修改代码只是治标补充Spec才是治本也是让Harness飞轮继续转下去的方式。所以在落地SDD时我们需要有意识地建立一个认知先把Spec Review做好Code Review的压力会自然减轻。把有限的注意力放在Spec审查上能带来更大的价值也能大幅降低后续的返工成本。启示二“大型AGENTS.md”是陷阱执行约束和语义约束要分开管OpenAI在实践中明确踩过一个坑他们尝试过一个大型的AGENTS.md文件用来记录所有Agent应该遵守的规则。但后来发现这个文件存在四个系统性问题挤掉有效上下文、内容过多导致失效、规则会立即腐烂、难以核实。最终他们得出的结论是AGENTS.md应该是目录而不是百科全书大约100行左右主要用来导航指向其他地方更深层的真实来源。背后的原因其实很简单执行约束和语义约束是两类性质完全不同的东西不能混在一起管理。执行约束是什么比如“不要使用这个API”“文件大小不超过X行”“不要运行这个命令”这些都是具体的、可直接执行的规则偏向于操作层面。而语义约束是什么比如“这个字段的含义是什么”“这个服务的边界在哪里”“这个错误码在跨服务场景下如何处理”这些偏向于语义层面是Agent理解工作的基础。如果把这两类约束混在同一份文件里随着文件体积的膨胀两者都会失效。执行约束会被海量的语义约束淹没Agent无法快速找到需要遵守的操作规则语义约束会被执行约束打乱无法形成清晰的体系Agent也无法准确理解。我们前面提到的Spec体系天然处理了语义约束它按层、按粒度组织Agent可以按需导航快速找到需要的语义信息。但执行约束这一类在典型的SDD方案里还需要明确划定位置。这是我们在落地时需要补充的一块AGENTS.md或等价物应当作为specs/体系的入口文件保持轻量和精简它的职责是“Agent进入代码库后应该怎么行动、去哪里找什么”而不是把Spec里的语义规则再复制一遍。把执行约束和语义约束分开管理各自才能保持清晰和可维护才能真正发挥作用。执行约束放在AGENTS.md里作为Agent的操作指南语义约束放在Spec体系里作为Agent的推理基础两者相互配合才能让Harness体系更高效。启示三Spec漂移是必然的仅靠人工维护不够需要主动检测机制OpenAI在实践中发现了一个问题随着代码吞吐量的增加Agent会不断复现代码仓库里已有的模式包括那些不均衡或不理想的模式。他们一开始尝试用人工每周花20%的时间清理“AI残渣”但后来发现这种方式不具备可扩展性随着代码量的增加人工清理的成本会越来越高也容易出现遗漏。他们的解法是把“品味”编码进规则然后用一个定期运行的“doc-gardening”Agent自动扫描架构漂移发起修复PR。他们还形象地说技术债务就像一笔高息贷款不断地以小额贷款的方式偿还总比让债务不断累积要好。这个问题对Spec来说更加严峻。代码漂移通常能在运行时感知到比如测试挂了、类型报错了、行为不符合预期我们能及时发现并修复。但Spec漂移是沉默的处于Active状态的Spec可能已经在描述一个已经演进了的系统它不会报错也不会提醒你只会沉默地让下一个Agent基于一份过时的定义去生成代码进而导致错误。典型的SDD方案通常已经有了Spec生命周期管理比如Draft草稿→ Active活跃→ Deprecated废弃还有变更治理流程但触发Spec更新的动作目前大多依赖人工需要开发者在做需求时记得同步更新Spec。这种方式很容易出现遗漏导致Spec漂移。所以设计一个主动的Spec-Code一致性检测机制是后续值得重点建设的方向。我们可以对照接口定义、数据库Schema、配置文件定期检测Spec描述是否与代码现状一致对漂移的条目自动发起更新提案。在这个机制建立之前我们可以先用工程规范来弥补Spec修改和代码修改必须在同一个PR里提交而且Spec要先于代码合入确保Spec和代码始终保持一致减少Spec漂移的可能性。启示四遇到问题时追问“AI还缺什么”而非“人类再努力一点”OpenAI在文章里有一句话值得我们反复回想当事情进行不顺利时解决方案基本上再也不会是“再努力一点”。因为取得进展的唯一方式是让Codex来完成工作而人类工程师则总是介入这项任务并追问“究竟还需要什么样的能力我们又该如何让这个能力对智能体来说既清晰可读又可强制执行”这句话给我们的启示是在SDD落地过程中遇到Bug或阻塞时我们首要的追问不是“怎么让人把这件事做对”而是“AI在完成这件事时还缺什么”。AI缺的可能是Spec里的一个场景可能是一个让AI能自我验证的工具也可能是系统里缺少一层AI可以直接读取的可观测性数据。OpenAI在实践中花了大量精力让应用程序对Agent“直接可读”。他们把日志、指标、追踪接入Agent运行时让Agent能启动应用实例来复现Bug、验证修复而不是每次都靠人工QA。这些投入是让执行层能够自主运转的基础设施。SDD体系解决了“Spec这一层的可读性”让Agent有地图、有契约、有行为规范可以推理。但随着落地的推进让AI也能读到运行时的反馈信号比如日志、错误、验证结果是下一个值得投入的方向。这样可以让Harness飞轮的“发现错误”这一步更多由AI自己完成而不是等人来发现进一步提升Harness体系的效率和可靠性。这部分内容和SDD的直接关联相对松散但它是Harness整体能力成熟之后自然要走到的地方。六、结语Harness越强Spec越重要最后我们再回到最初的问题Harness来了SDD真的过时了吗我的答案依然是没有过时而且更有意义。原因很简单Harness是一个放大器。它放大了Agent的执行能力也放大了输入给Agent的内容的影响。如果Spec写得好Harness就能把它放大为可靠的、一致的、可验证的输出让Agent高效、准确地完成工作大幅提升开发效率。如果Spec写得差或者根本没有SpecHarness就会把Agent的猜测放大让Agent高效率地产出错误不仅无法提升开发效率还会带来大量的返工和损失。这就像我们开车引擎越强导航就越重要。高速公路的护栏比自行车道更必要不是因为车更危险而是因为速度更快一旦出错后果更严重。Agent的执行能力越强就越需要清晰、准确的Spec来引导否则就会像没有导航的车在高速公路上乱开很容易出现事故。OpenAI自己也说得很清楚他们当前最难的挑战不是“模型够不够强”而是“如何设计环境、反馈回路和控制系统”。这正是Harness Engineering的实质也是SDD在解决的问题。构建SDD体系不是在做一件和Harness Engineering平行的事而是在回答Harness Engineering最核心的那个追问究竟需要什么样的支撑结构才能让Agent把我们想要的东西既清晰可读又可强制执行地做出来而Spec就是这个支撑结构中举足轻重的一环。SDD就是把这个答案做工程化的方法。在Harness Engineering飞速发展的今天SDD不仅没有过时反而迎来了更大的发展空间。只有把Spec做好、做精才能让Harness的价值得到最大发挥才能真正实现AI Agent的可靠、高效工作推动软件工程进入一个新的时代。