OpenAI 在 Harness Engineering 里讲到一个很关键的转变：当 agent 开始承担越来越多软件工程工作时，工程师的核心职责会从“亲手写代码”，逐渐转向“设计环境、表达意图、构建反馈回路”。

这句话背后有两层含义。

第一层是 Harness Engineering。

让 agent 能看见真实环境，能运行系统，能复现问题，能验证结果。

第二层，是我认为接下来更重要的 Standard Engineering。

让 agent 不只会工作，还能按照团队认可的工程标准工作。

可以粗暴概括成一句话：

Harness Engineering 解决的是“让 agent 能工作”。

Standard Engineering 解决的是“让 agent 按团队认可的标准工作”。

过去一段时间，我在几个不同类型的项目里，都逐渐做出了类似实践。

它们表面看起来差别很大。

有的是 AI 产品研发。

有的是真实设备回归。

有的是业务系统发布路径。

有的是部署诊断和运维约束。

抽象到最后，背后是同一种结构：

先让 agent 看到真实世界。

再把“什么才算正确”的判断沉淀成标准。

Harness 的本质不是测试

很多人听到 harness，第一反应是测试脚本、CI、浏览器自动化、回归用例。

这些当然都算。

只是还没有碰到本质。

Harness 的本质，是给 agent 一个可行动的环境。

它让 agent 能启动系统，能观察页面、日志、网络请求、运行状态，能复现一个问题，能在修复后重新验证，并留下证据。

原来靠人手工确认的流程，被它变成了系统可以反复执行的反馈回路。

在 AI 产品项目里，这会表现为浏览器验证、接口路径、运行产物、质量报告和交付记录。

在真实设备项目里，这会表现为固定设备、状态脚本、服务日志、发版路径、回归恢复。

在业务系统里，这会表现为 CI、runtime harness、环境推广路径、线上配置验证。

在部署诊断项目里，这会表现为诊断入口、部署约束、运行模式和真实机器证据。

这些都是 harness。

它们共同解决的是同一个问题：

别让 agent 在猜。

但 harness 真正跑起来之后，会出现一个新的瓶颈。

agent 已经能跑，能测，也能交付。

可它到底按照什么标准判断自己做对了？

Harness 之后的新瓶颈是判断标准

AI Coding 的早期瓶颈是生成能力。

模型能不能写出代码？

能不能理解需求？

能不能补测试？

进入 harness 化之后，瓶颈会移动。

agent 可以更快地写代码，也可以更快地跑验证。这个时候，真正稀缺的东西变成了团队判断。

什么样的代码是可维护的？

什么样的边界不能突破？

什么样的运行证据才算可信？

什么样的发版路径才算完成？

什么样的设备状态才是真相源？

什么样的绕路虽然能过测试，却会制造长期债务？

这些判断，过去靠资深工程师 review，靠项目经验，靠事故之后的口头约定。

但 agent 的吞吐量远高于人工 review。

每一次都靠人重新解释，标准就规模化不了。

更麻烦的是，agent 很擅长复制既有模式。

仓库里有好模式，它会复制。

仓库里有坏模式，它也会复制。

速度越快，坏模式扩散越快。

所以 harness 化之后，下一件事不是继续堆提示词。

我们要把团队反复做出的工程判断，沉淀为 agent 可以识别、执行、失败、修复和复用的标准系统。

这就是 Standard Engineering。

什么是 Standard Engineering

Standard Engineering 不是某个具体工具。

也不是一份更长的规范文档。

它是一种工程系统：

把工程团队长期有效的判断，转化为仓库内可命名、可版本化、可验证、可追溯、可修订的标准系统。

它不替代 harness。

它站在 harness 之上，为每一次检查、失败、修复和交付证据提供判断语义。

可以把 AI Coding 的工程体系分成三层。

  • Prompt 层：告诉 agent 要做什么。
  • Harness 层：让 agent 能运行、观察、测试、复现、提交证据。
  • Standard Engineering 层：告诉 agent 什么才算做对，失败属于哪个标准，应该沿什么方向修。

更短一点说：

Harness 是 agent 的感知和行动回路。

Standard Engineering 是 agent 的工程判断回路。

没有 harness，agent 容易在静态代码里猜。

没有 Standard Engineering，agent 容易为了通过检查，绕过真正的问题。

我们其实已经在做了

回头看不同项目里的实践，会发现 Standard Engineering 并不是凭空提出的新概念。

它已经自然长出来了。

只是之前没有统一命名。

在 AI 产品研发里，它表现为结构标准、质量门槛、交付证据和运行产物。

比如文件复杂度、层级边界、数据访问边界、文档同步、功能验证、领域产物质量。

这些都可以被标准化，并让检查报告携带标准编号、证据字段和修复方向。

在真实设备项目里，它表现为设备状态标准和发版标准。

比如固定设备状态脚本是第一真相源，发版必须走远端构建和上传，回归必须记录恢复路径，artifact 路径必须可复现。

这些不是普通脚本。

它们是围绕真实设备形成的工程判断。

在业务系统里，它表现为环境推广和运行证据标准。

比如修复进入某个环境之前，要验证当前分支、远端引用、CI 信号、部署状态、worker 日志或 live config。

这里的核心不是“跑了命令”。

核心是：用什么证据证明它真的到了目标环境。

在部署诊断项目里，它表现为部署约束和诊断标准。

比如诊断页应该复用已有协议，产品界面不暴露任意 shell，生产部署要显式声明目标平台，启动入口必须以真实运行路径为准。

这些都是从运维风险里提炼出来的标准。

过去，它们散落在脚本、runbook、agent 记录、CI gate、发版纪律和口头经验里。

Standard Engineering 做的事情，就是把它们提升成统一的工程概念。

它不是更长的 AGENTS.md

Standard Engineering 最容易走错的一条路，是写一份越来越长的“AI 开发规范”。

这通常没用。

一个巨大的规则文档会快速腐烂。它会占据上下文，让重要信息和不重要信息混在一起。

最后它变成心理安慰：

人觉得自己写了规范。

系统并没有真正执行规范。

Standard Engineering 应该反过来做。

入口要短。

标准要分散。

判断要命名。

检查要机器可读。

报告要能被 agent 消费。

每个标准都应该有清晰边界。别把所有“最佳实践”塞进同一份文档。

一个最小标准对象，至少应该包含这些字段。

  • id：稳定编号，用于报告、日志、review 和交付记录。
  • intent：这个标准保护什么工程判断。
  • scope：适用于哪些代码、流程或产物。
  • enforcement：由什么检查、测试、harness 或 review 机制执行。
  • evidence：什么证据能证明它被满足。
  • repair path：失败后应该怎么修，不能只写怎么禁止。
  • revision trigger：什么情况下需要更新标准本身。

这几个字段的价值在于，它们把“资深工程师脑子里的判断”，变成 agent 可以读取、引用、执行的对象。

它也不是普通 CI

CI 通常只回答一个问题：

过了没？

Standard Engineering 要回答更多问题。

违反了哪个标准？

证据是什么？

这个标准为什么存在？

应该往哪个方向修？

这次失败是实现问题，还是标准本身该修订？

同类问题以后能不能自动发现？

比如一个普通 CI 可能只说：某个文件超过行数限制。

Standard Engineering 不应该停在这里。

它应该进一步说明：这个失败违反的是“复杂度边界”标准；这个标准保护的是模块可读性和 agent 可导航性；证据是当前行数、阈值和豁免状态；建议修复方向是按服务、组件、hook、fixture 或领域边界拆分。

这就不只是检查。

这是把工程判断注入反馈回路。

对人来说，这是更好的错误信息。

对 agent 来说，这是更明确的修复上下文。

把 taste 工程化

OpenAI 的 Harness Engineering 文章里有一个重要观点：架构和 taste 需要被执行，不能只靠描述。

在人类团队里，taste 很多时候靠长期协作传递。

什么样的抽象太早。

什么样的依赖方向危险。

什么样的日志才足够定位问题。

什么样的证据才算可信。

这些东西往往不完整写在规范里。

但 agent 不会自然继承团队 taste。

它只会继承可见上下文和已有模式。

所以 Standard Engineering 的核心价值之一，就是把 taste 拆成可执行标准。

这些标准不必一开始很宏大，可以从高频问题开始。

结构边界是否清楚。

文件是否超过可读复杂度。

接口层是否过厚。

数据访问是否绕开统一边界。

旧的复杂模块是否继续扩张。

文档和 agent 入口是否同步。

功能交付是否留下验证证据。

运行环境是否有真实部署信号。

真实设备回归是否有可恢复路径。

关键业务产物是否满足质量门槛。

这些都不是简单格式问题。

它们是团队对长期可维护性、可交付性和可复现性的判断。

过去它们靠 review 反复提醒。

Standard Engineering 要把它们变成系统能力。

对抗 agent 规模化后的熵增

AI Coding 最大的风险之一，不是 agent 写不出代码。

是 agent 写得太快。

速度本身没问题。

问题在于，如果系统没有足够强的边界，速度会放大熵增。

一个不好的模式，人工团队里可能几周才扩散开。agent 高吞吐下，可能一天内就复制到很多地方。

一个临时 workaround，如果没有被标记和清理，很快就会变成“仓库惯例”。

Harness 能发现一部分问题，但 harness 更偏运行反馈。

Standard Engineering 要负责把重复出现的问题转化为标准，再由检查、报告和修复路径持续执行。

这类似一种工程垃圾回收机制。

人工 review 里反复出现的问题，不该永远停留在 comment。

线上事故里暴露的系统性缺陷，不该只停留在复盘文档。

真实设备回归踩过的坑，不该只留在某次聊天记录里。

某次发版路径的经验，也不该只靠下次人类记得提醒。

它们应该被提升为标准。

一旦成为标准，后续 agent 遇到同类问题时，不只是被拦住。

它还能知道自己为什么被拦住，应该怎么修，修完需要留下什么证据。

Standard Engineering 如何运转

一个可落地的 Standard Engineering，不需要一开始很复杂。

先做四个动作就够了。

第一，检查输出携带标准 ID。

不要只输出“失败”，要输出“违反了哪个标准”。标准 ID 是后续追踪、统计和修复的共同语言。

第二，运行证据携带标准引用。

浏览器验证、设备回归、质量报告、部署检查、诊断结果，不只是保存结果，还要说明这些结果覆盖了哪些标准。

第三，交付记录绑定验证结果。

每次有意义的 agent 变更，都应该留下 prompt、目标、改动、验证、风险和提交关系。

不然未来的 agent 或 reviewer 很难理解当时为什么这样做。

第四，review 和事故反向更新标准。

如果一个问题反复出现，不要只修当前代码。要问几个更麻烦、也更有价值的问题：

是否缺了一个标准？

是否已有标准没有自动执行？

是否错误信息没有给出修复方向？

是否证据不足以复现判断？

这四个动作连起来，Standard Engineering 就形成闭环：

标准定义判断。

Harness 提供证据。

检查发现偏差。

交付记录保存上下文。

Review 和事故推动标准进化。

工程负责人真正要管理的东西变了

在 AI Coding 之前，工程负责人主要管理人的协作效率、代码质量和交付节奏。

在 AI Coding 之后，这些仍然重要。

但控制点会变化。

你不能只靠增加 review 来管理 agent 吞吐量。

也不能只靠更好的 prompt 获得长期一致性。

你要管理的是环境、反馈和标准。

环境决定 agent 能不能工作。

反馈决定 agent 能不能修正。

标准决定 agent 会朝什么方向修正。

Harness Engineering 已经把“环境”和“反馈”往前推进了一大步。

Standard Engineering 要补上的，是“标准”。

它不是为了限制 agent。

它是为了释放 agent。

因为只有当边界、证据和修复方向足够清楚时，agent 才能在更大范围内自治，不需要人类反复盯着每个细节。

真正成熟的 AI Coding 团队，不会只问“模型能力够不够”。

它会问：

我们的工程判断是否已经进入仓库？

我们的标准是否能被 agent 发现？

我们的失败是否有可执行修复方向？

我们的验证证据是否能被复用？

我们的 review 经验是否正在沉淀，而不是流失？

我们的设备、环境、部署、质量门槛是否都有明确真相源？

结语

Harness 让 AI Coding 可运行。

Standard Engineering 让 AI Coding 可治理、可继承、可持续扩张。

前者解决 agent 的手和眼睛。

后者解决 agent 的工程判断。

当 AI Coding 只是辅助个人写代码时，prompt 技巧可能已经够用。

当 AI Coding 进入团队级、仓库级、真实环境级、长期演进级的软件工程时，harness 是基础设施，Standard Engineering 是治理系统。

更重要的是，Standard Engineering 往往不是先设计出来的。

它从真实项目里长出来。

最初可能只是一个发版脚本、一个设备状态检查、一个 CI 修复经验、一个 agent 交付记录、一个 review 规则、一个部署 runbook。

当这些东西被命名、归类、版本化、自动检查、绑定证据之后，它们就不再只是经验。

它们会变成团队可复用的工程判断系统。

未来优秀工程团队的差异，可能不只是用了哪个模型、接了多少工具、跑了多少测试。

更大的差异在于：有没有能力把自己的工程判断沉淀成可执行的标准系统。

这才是 AI Coding 从“能写代码”走向“能长期维护复杂系统”的关键一步。