两个月没更新，我去研究了一个 AI 工程的新范式

两个月没写东西了。上一篇还在聊 Claude Cowork 的体验，这篇直接跳到了一个更大的问题：AI 写代码已经这么猛了，工程师到底该干什么？

这不是我的原创问题。2026 年 2 月，OpenAI 发了一篇博文：3 个工程师，5 个月，从空仓库到 100 万行代码，零手写。他们给这套方法论起了个名字叫 Harness Engineering——驭缰工程。核心主张是：工程师不再写代码，而是设计环境、约束和反馈回路，让 AI 智能体在这个”缰绳”里可靠地干活。

这个概念击中了我。不是因为它多新——lint、CI、代码规范我们一直在做。而是因为它把这些零散的实践提升到了范式的高度：你的产出不再是代码，而是让 AI 产出好代码的系统。

然后我发现了一个有趣的现象：OpenAI 发完之后的两个月里，又出现了十几篇文章讨论这件事——Fowler 站、Anthropic、LangChain、Stanford、GitHub，甚至有个人开发者写了万字复盘。每一篇都在 OpenAI 的乐观叙事上补了一块拼图。但没有人把这些拼图拼在一起看。

所以我花了两个月干了这件事。

这个项目长什么样

一个 GitHub 仓库：harness-engineering。

数字上看：

  • 15 篇核心文章的深度阅读和结构化摘要
  • 11 篇翻译（含 2 篇学术论文，总计超过 5 万字）
  • 5 篇独立思考（不是读后感，是跨文章的交叉分析）
  • 1 篇综合分析——15 篇文章拼在一起之后才能看到的那个故事

但数字不是重点。重点是这个项目本身就是一次 Harness Engineering 的实践。

仓库的组织方式用了 OpenAI 提出的”渐进式披露”——每个目录有自己的 AGENTS.md 导航文件。翻译工作用了术语对照表（40+ 条）作为”自定义 linter”，五轮流水线作为反馈飞轮，长论文拆块并行翻译作为多智能体协调。约束 + 反馈 + 分治 + 持久化——我用 Harness Engineering 的方法研究了 Harness Engineering。

两个月下来，我的三个核心判断

读了 15 篇文章、翻了 11 篇、写了 5 篇思考之后，我对 Harness Engineering 的态度从”这是新东西”变成了”这是一场未完成的革命”。三个判断：

1. 它不是一个统一的方法论，而是四个学派在争论

OpenAI 说多加约束（约束派），Böckeler 说设计控制论闭环（控制论派），Anthropic 说让 Harness 本身可替换（架构派），一个叫 YDD 的博主用数据证明你加速的可能根本不是瓶颈（怀疑派）。

四个学派都有数据支撑，但作用在完全不同的层次上。约束派告诉你今天该做什么，控制论派告诉你怎么系统地做，架构派告诉你怎么让做的东西活过下一次模型升级，怀疑派告诉你什么时候该停下来想想方向对不对。

同时持有四个视角，比选哪个重要得多。

2. 评估是整个体系的阿喀琉斯之踵

所有文章都在讨论怎么引导和约束 AI——更好的 AGENTS.md、更严的 linter、更巧的架构。但它们集体回避了一个问题：你怎么知道 AI 做的事情是对的？

不是”代码能编译”，不是”测试通过了”，而是——它真的解决了用户的问题吗？

一个叫 lalitm 的开发者给了最痛的数据点：500 个测试全部通过，但设计是完全错误的，最终全部推倒重来。测试验证的是”AI 认为的正确”，不是”用户需要的正确”。

Böckeler 在 Fowler 站上最诚实地命名了这个问题：行为验证是房间里的大象。但命名不等于解决。15 篇文章读完，没有一篇给出令人信服的答案。

3. 人类不会消失，但角色在重新定义

从 OpenAI 到 Anthropic 的最新文章，人类的角色在渐次消解：从”设计整个环境”到”写几行提示词”到”文章里压根不提人类”。

但 lalitm 的经验给了一个有力的反例。他经历了两种模式：vibe-coding 月（把设计和实现都委派给 AI，结果全部推倒重来）和 Harness 月（自己做设计、AI 做实现、持续审查，项目成功发布）。

他的顿悟值得所有用 AI 编码的人记住：AI 是力量倍增器，但倍增的是你的判断力——如果你没有判断力，它倍增的是你的错误。

综合分析：15 篇文章不会告诉你的那个故事

以上只是我思考的切面。完整的分析在这里：

驭缰工程的隐秘叙事：15 篇文章不会告诉你的那个故事

这篇万字长文不是摘要集。它讲的是 15 篇文章拼在一起之后才能看到的叙事——从”约束模型”到”与模型共演化”的范式转移，以及这场转移中暴露出的结构性裂缝。

如果你在用 AI 写代码（大概率你已经在了），这些裂缝决定了你在什么条件下可以信任这个范式，在什么条件下必须保持警觉。

给不同读者的入口

如果你是个人开发者，最值得看的是我的思考：个人开发者的 Harness Engineering——OpenAI 的六大概念哪些对你有用，哪些是噪音。

如果你关心评估问题：评估是房间里的大象——所有人都在讨论怎么约束 AI，没人讨论怎么验证 AI。

如果你是 Java/Spring 开发者：可驾驭性与 Java 的结构性优势——为什么强类型语言在 AI 时代可能比动态语言更有优势。

如果你什么都不想看，只记住一句话：先记录 AI 犯的错，再写规则阻止它。反馈飞轮比完美计划更有价值。

仓库在这里：github.com/deusyu/harness-engineering

欢迎 Star，欢迎讨论。