一文讲透：Harness Engineering即控制论
一句话概括
本文将 OpenAI 提出的 Harness Engineering（人类掌舵、智能体执行的 AI 编程范式）追溯到维纳控制论的理论根源，论证 AI 编程本质上是控制论在编码世界的工程实现：通过信息获取与反馈对系统进行调节控制以实现特定目标。文章以 OpenAI 3人团队5个月1500个PR的实践数据为起点，系统讲解了 Harness Engineering 的七条实践原则（渐进式披露、规则沉淀仓库、架构约束、AI可观测系统、等待成本高于纠错成本、自动清理垃圾代码、人类建议沉淀仓库），并从控制论的信息、控制、反馈三个核心概念出发，分析了目标设定、框架规范降低可能性空间、流程规划实现控制力累积、共轭控制等关键机制。
实践内容
Harness Engineering 七条实践原则（OpenAI Codex 团队）
- 给目录而不是整本说明书 — AGENTS.md 控制在约 100 行，仅作为索引目录，AI 需要时再根据目录找到深层知识（渐进式披露）
- 规则要沉淀到仓库 — 设计决策、架构约定、团队共识必须以版本化的 Markdown、代码或可执行计划的形式提交到仓库
- 务必要有架构约束 — 通过脚本、流水线等校验生成的代码是否满足架构约束，防止架构漂移；明确哪些地方需要限制、哪些允许 AI 自由发挥
- 构建 AI 可观测的系统 — 将日志、监控等信息通过文件、MCP 等方式暴露给 AI，让 AI 可以自己闭环开发-测试-修复
- 等待成本高于纠错成本 — PR 生命周期应尽量短，不要因为偶发性失败而阻塞
- 让 AI 自动清理垃圾代码 — 将”黄金原则”编码到仓库中，运行后台 Codex 任务定期扫描偏差、发起重构 PR
- 人类的建议要沉淀到仓库中 — 代码审查中的评论、重构 PR 和用户反馈必须提取为规则写到文档或编码进工具
控制论核心逻辑循环
[ 设定目标 ] → [ 感知偏差 ] → [ 施加干预 ] → [ 消除偏差 ]
对应 AI 编程：写 Prompt 给 AI 设定目标 → AI 执行 → 人类验收（出现偏差）→ 修改 Prompt/SKILL/RULE 文件施加干预 → AI 消除偏差
用例规约模板（业务相关传感器示例）
前置条件：存在已经完成签约的学生账户
后置条件：扣款凭证已经关联一笔扣款成功的支付订单
涉众利益：
家长--担心由于忘记充值，账户内余额不足而导致孩子无法吃饭
餐厅老板--担心卖出饭但是没有收到对应的款项
系统提供商老板--担心出现大量垫资未还的欠款，产生坏账造成资金损失
基本路径：
1. 服务商收银系统提交消费信息
2. 系统提示学生刷脸
3. 系统验证刷脸学生账号签约状态
4. 系统请求XX支付扣款
5. 系统保存扣款结果
6. 系统返回扣款单信息
扩展路径：
3a. 学生账号未签约：3a1. 系统通知家长签约
4a. 扣款账户余额不足：
4a1. 系统校验垫资条件
4a1a. 不满足垫资条件 → 转到5
4a2. 系统请求XX支付扣款
4a3. 系统通知家长还款
字段列表：
1. 消费信息=消费金额+商户订单号
2. 扣款单信息=扣款金额+是否垫资+支付订单号
业务规则：
1. 单学生账户最多同时存在3笔欠款
2. 垫资只针对消费金额小于30元的订单
3. 每个学校有垫资上限，垫资上限=学生数*3*30*10%
质量需求：扣款从收到请求到结束在5秒内完成
设计约束：收款系统使用XX支付
古法编程 vs Harness Engineering 对照
| 古法编程 | Harness Engineering |
|---|---|
| 编写代码 | 设计环境 |
| 调试 bug | 明确意图 |
| 代码审查 | 构建反馈回路 |
| 编写测试 | 将工程判断编码成机器可读的规则 |
| 重构代码 | 校准传感器与执行器 |
摘录
代码库过去实际上一直是有反馈回路的，但只限于低层级（例如编译器校验语法……），而更上层，即架构层面的决策、质量判断等问题只有靠人判断、修正，而AI则可以让这个反馈回路闭合，识别问题并修复问题。然而真正的难题是把人类独有的知识变成AI可读的东西，大多数情况的失败并非 AI 能力不够，而是知识一直锁在人的大脑里。过去人们总是跳过编写规则直接写代码，因为他们要为此付出代价可能要在很久以后，但到了 AI 时代付出的代价会被成倍放大，因为AI代码生产效率实在是太高了。所以人不需要在实现上（写代码）战胜机器，而要在评估上胜过它：定义什么是正确、看出哪里偏了、判断方向对不对。
软件方法、领域建模、架构……这些”最佳实践”我们喊了数十年但实践的并不好，因为即使代码写的很粗放，债务依然积累的很慢，直到很久很久之后的一个时间点爆发，也许这个时间点到我们离职都不一定爆发，惰性让我找各种借口拖延。然而AI时代债务的累积速度是远超想象，AI可以全天候的参考已有代码复制同样的错误，一次坏的实现会被无数次的重复，因为”你没写下来的规矩，AI永远不知道”。因此我们一定要将业务规则写下来，AI的输出是不确定，但是代码可以被确定性的验证，我们不需要比机器写得更快，但是我们一定要高效评估它的产出。
在控制论中，针对矫枉过正有一个专门的术语——滞后。一根铁丝我们施加一定力会变弯，松手后并不会完全变直，而是要适当的往相反的方向施加一个力，也就是要”矫枉过正”。研发模式的升级我认为将会是一个飞跃的过程，之所以现在我们仍然需要参与编码，一个非常大的原因就是缺乏传感器和基建，仍然需要人来串流程。未来的某一天当我们的传感器建设的完善到一个临界值，AI编程再也不需要人来串流程了，我相信所有人会立刻抛弃原有个开发模式，就像我们迅速抛弃传统 IDE 去拥抱Cursor一样。
AI时代程序员的本职工作就是设计让 AI 正确写代码的环境，而不再是正确的写代码。蒸汽时代到来后船夫再也不需要去划桨了，不是因为他们不会，而是因为这件事已经没有任何意义了。程序员的核心价值不再是”实现”，而是”评估”。
涉及实体
- Harness —— 本文核心概念，探讨其与控制论的理论关联
涉及主题
- Harness-Engineering —— Harness 工程化方法论
- Cybernetics —— 控制论，Harness 的理论根基
我的评注
- 作者从控制论视角重新审视 Harness Engineering，将其定义为”人类掌舵、智能体执行”的管理与执行关系，而非简单的协作关系——程序员的核心价值从”实现”转向”评估”
- OpenAI 的实践数据（3人5个月1500个PR、100%AI编写、100万行代码）证明了大规模 AI 编程的可行性
- 将领域建模、用例规约等传统软件工程方法重新定位为 AI 编程的基础设施，而非过时实践——“领域建模并不会消失，相反会扮演更重要的角色”
- 自繁殖系统概念的引入（坏代码被 AI 无限复制）是对代码质量重要性的有力论证