3人5个月0行代码：Harness Engineering揭示的工程真相

今年2月，OpenAI发了一篇技术博客，标题平平无奇：《Harness Engineering: Leveraging Codex in an Agent-First World》。内容讲了一件听起来有点疯狂的事：一个由3名工程师组成的团队（后来扩展到7人），在5个月内，用AI生成了超过100万行生产级代码，合并了约1500个Pull Request。

零行手写。

全网在转发，在惊叹，在焦虑。我的问题是另一个方向的：**他们到底在做什么？**

不是AI取代了工程师，是工程师换了工作

有一种叙事是这样的：AI越来越强，人类工程师要被取代了。

这个叙事最近又多了一个证据：看，100万行代码，零手写。

但这个叙事忽略了一件关键的事：这3到7个工程师，5个月里到底在干什么？

他们在驾驭。

不是写代码——代码是AI生成的。他们做的是：设计环境，让AI知道该做什么；制定约束，让AI知道什么不该做；构建验证机制，让AI知道什么是对的；建立反馈循环，让AI知道什么时候该停。

这个"环境+约束+验证+反馈"，英文叫 Harness。中文有人译成"驾驭系统"。

真正的工程产品，不是那100万行代码。那100万行代码只是输出。真正的产品，是那套让AI能可靠工作的控制系统。

三次出现的概念，不是巧合

OpenAI那篇文章里引用了一个有意思的观点：Harness Engineering这个范式，在历史上已经出现过三次。

第一次：1780年代，瓦特的离心调速器。

蒸汽机很强大。但蒸汽机自己不会控制速度——快了会爆炸。瓦特发明了一个机械装置：转速快了，调速器就把阀门关小一点；慢了，就开大一点。这个装置不需要任何人工干预，自己形成了一个反馈回路。

第二次：2010年代，Kubernetes。

服务器集群很强大。但虚拟机自己不知道该调度到哪里、什么时候扩缩容、怎么分配资源。Kubernetes做了一件类似的事：把底层的计算资源抽象成一个可编程的平面，让人类可以用声明式的方式描述想要什么，而不是手动一条条执行指令。

第三次：现在，Harness Engineering。

AI Agent很强大。但Agent自己不知道该先做什么、做到什么程度算对、什么时候该停下来问人。Harness Engineering要解决的，是怎么设计一套系统，让AI Agent能可靠地完成复杂的多步骤任务。

三个案例的本质是一样的：**当你的工具能力超出人工直接控制的范围时，你需要设计一个中间层，让机器能够规模化地做决定，同时保留人类的意图。**

这件事为什么让工程师难受

我见过不少工程师聊这件事。反应通常分两类：

第一类：兴奋。 “太好了，以后不用写无聊的代码了。”

第二类：焦虑。 “那我们以后干什么？”

第二类反应是对的。但焦虑的方向错了。

让我把话说清楚一点：Harness Engineering 不是软件工程的终结。它是软件工程的一次升维。

过去几十年，软件工程的成长路径是清晰的：写代码 → 代码评审 → 架构设计 → 技术管理。这条路径的核心能力是"把人类的想法翻译成机器能执行的指令"。

Harness Engineering 需要的能力完全不同：

• 你要能把模糊的业务意图，拆解成 AI 能理解的任务描述
• 你要能设计验证机制，判断 AI 的输出是否真的符合预期
• 你要能建立反馈循环，让 AI 在偏离目标时能自动纠正
• 你要能在"让 AI 继续做"和"让 AI 停下来问人"之间做正确的取舍

这些事情，本质上是系统设计和约束工程，不是传统意义上的编程。

用一个不精确的类比：以前的工程师是步兵团，靠人海战术正面推进。现在的工程师是总参谋部，负责画战场、画指令、画撤退路线。你不能说参谋部的工作比步兵团低级——但你也不能让一个优秀的步兵团士兵直接去当参谋。

最让人不安的结论

写到这里，我想提一个不太让人舒服的推论。

如果 Harness Engineering 真的是 AI 落地的瓶颈——那意味着什么？

意味着AI 可能早就足够强了。瓶颈不在模型，在我们在模型外围建的那套系统。

我们一直在等一个更强的 AI。等来等去，模型已经迭代了好几轮，Harness 这件事好像还是没解决。

不是模型不够强。是我们的 Harness 还没建好。

这不是在说 AI 没用。这是在说：**如果你觉得 AI 还差点意思，很可能不是 AI 的问题，是你没想清楚怎么给 AI 设计一个它能可靠工作的环境。**

一个可操作的开始

说远了。回到一个具体的问题：如果你想开始练习 Harness Engineering，从哪里开始？

我的建议是一个反直觉的方法：**拿出一周时间，不写任何代码。**

这一周里，只做三件事：

第一件：定义"done"。 你想用 AI 做什么？做完的标志是什么？怎么判断 AI 做到位了？大多数人在这一步是模糊的——“让它写个功能”。这不是任务描述，这是愿望清单。

第二件：设计反馈机制。 AI 做的每一步，你怎么知道是对的？自动化测试？人工 review？案例验证？很多 AI 生成的代码"看起来对"但跑起来错——因为你没设计好验证环节。

第三件：建环境，而不是给指令。 与其一个 prompt 接着一个 prompt 地调，不如退一步想想：有没有办法让 AI 一开始就在一个更好的上下文里工作？上下文工程，本质上是 Harness 的一部分。

这些事情，技术含量不比写代码低。只是我们的大脑还没建立做这些事情的肌肉记忆。

结语

蒸汽机刚发明的时候，工厂主的第一反应是"太好了，用机器替代人工"。但真正变革性的采纳，不是"机器替代人"，而是"工厂重新设计工作流程，机器和人各司其职"。

这个过程花了三十年。

AI 这件事，可能也在走同样的路。我们现在大概在第三年左右的位置。Harness Engineering 不是"有了 AI 之后顺便学的东西"。Harness 才是 AI 时代的操作系统层——它决定了 AI 能发挥多大能力。

先把 Harness 建好。

剩下的，AI 自己会来。

---

作者Daniel，专注工程实践与 AI 落地的长期观察。