AI Engineering | 别写代码了！OpenAI用3个人5个月撸出100万行代码，秘诀全在这套“缰绳工程”

当AI能写代码，人类该干什么？答案可能让你意外

---

大家好呀！今天想跟你们聊一个超级炸裂的话题 🔥

前两天刷到OpenAI的一篇博客，看完我整个人都不好了——

3名工程师，5个月，100万行代码，0行手写。

没错，你没看错。一行代码都没写。所有代码都是AI（Codex）写的。

更离谱的是，这个产品不仅有内部日活用户，还有外部测试者在用，还经历了交付、部署、故障、修复的全过程。

那这三个人在干嘛？摸鱼吗？😂

恰恰相反。他们做的事情，可能比写代码难多了——他们给AI套上了一副“缰绳”。

今天就来聊聊这个新词：Harness Engineering。放心，我保证用最人话的方式讲清楚～

---

01 先说说这个奇怪的名字：为什么叫“缰绳工程”？ 🐎

看到“缰绳工程”四个字，你可能一脸懵：啥玩意儿？程序员改行驯马了？🤣

别急，这个翻译确实有故事。

“Harness”这个词，英文原意是马具——缰绳、马鞍、马嚼子那一整套。在技术圈，这个词的翻译目前五花八门：有人叫“驾驭工程”（听起来像开车，但车不会乱跑啊），有人叫“治具工程”（太硬核，像工厂里的术语），有人干脆不翻译，直接说“Harness”。

那我为什么偏要选“缰绳”呢？因为缰绳这东西，你一拉，马才知道往哪走——这不就是咱们对AI干的事吗？给它套上缰绳，引导方向，防止它跑偏、撞墙、或者自顾自地撒欢。

更重要的是，“缰绳”暗示了一种双向互动：你拉一下，马动一下。人类和AI Agent的协作，不正是这样吗？我们给出指令，AI执行，我们反馈，AI调整。这不是开车（车不会回嘴），这是驯马。

所以这篇文章里，我就用“缰绳工程”来称呼它。你要是觉得“驾驭工程”更顺口，也完全没问题——反正说的是同一件事：设计一套让AI能可靠、持续、自主工作的系统。

好了，名字解释完了，咱们正式开讲！👇

---

02 什么是“缰绳工程”？一个比喻就懂了 🐴

想象一下：你有一匹力气大得吓人但方向感堪忧的马（这就是现在的AI大模型）。你想让它帮你干活。

你是应该：

• A. 自己下场跟它比谁力气大？ 💪
• B. 给它套上一副好用的马具，把它的力气引导到你想要的方向？ 🐎

答案显然是B。

Harness Engineering的核心就是：不是跟AI比写代码，而是设计一套让AI能可靠、持续、自主工作的系统。

说白了，工程师的角色正在从“写代码的人”变成“给AI套缰绳的人”。

是不是感觉突然没那么焦虑了？😉

---

03 为什么我们需要这套“缰绳”？数据惊掉下巴 📊

先看一组让人倒吸一口凉气的数据：

一个叫Can.ac的实验，仅仅改变了AI调用工具的方式，就让Grok Code Fast 1这个模型的编码基准分数从6.7%直接飙到了68.3%！

看清楚——没有换模型，没有改参数，只是优化了它干活的方式。😱

LangChain也有类似的发现：同一模型，仅通过Harness改进，从第30名跃升至第5名，涨了13.7分。

这意味着什么？意味着你现在纠结“GPT-5和Claude 4.6哪个更强”，可能不如花时间把AI干活的环境整得舒服一点。

瓶颈不在模型智能，在基础设施。 🎯

那AI现在干活容易翻车吗？太容易了！Anthropic（Claude的母公司）总结了几种经典翻车姿势：

🚫 试图一步到位：一口气把所有事情做完，结果上下文窗口爆了。下次会话启动时，看到的是半成品、没文档的代码，一脸懵。

🚫 过早宣布胜利：做了一部分功能就觉得自己完成了，剩下的一大堆没做的功能视而不见。

🚫 写完就算完成：写完代码就标记完成，根本没做端到端测试。单元测试过了？那肯定没问题了！（结果用户一用就崩）

🚫 每次重启都要重新认路：每次新会话启动，都得花大量token搞清楚“这项目怎么跑起来”，而不是把时间花在正事上。

看到这里是不是觉得AI像个不太靠谱的新员工？👶

那Harness Engineering要做的，就是把这些坑全填上。

---

04 OpenAI的疯狂实验：5个月，100万行代码，0行手写 🤯

来，我们拆解一下OpenAI是怎么做到的。

原则1：工程师不写代码，只设计环境 🏗️

团队的核心原则是：从不手动编写代码。

听起来像偷懒？其实更难了。

早期进展特别慢。不是因为AI不会写代码，而是环境太乱。AI缺乏实现高级目标所需的工具、抽象层和内部结构，根本没法推进。

工程师们的工作变成了：当AI卡住时，不是“再努力一点”，而是追问“它到底缺什么能力？我怎么让这个能力对AI来说既清晰可见又能强制执行？”

然后让AI自己去构建这个能力。

这感觉像什么？像一个项目经理，而不是码农。💼

原则2：让AI能“看懂”你的应用 👀

这是一个很聪明的点。

为了让AI自主工作，他们把应用设计成了“对AI可读”的版本。

比如，他们让应用能根据git worktree启动，这样AI每次改动都能启动一个独立实例。他们还把Chrome DevTools接入了AI，让AI能直接看DOM快照、截图、操作界面。

这意味着AI可以自己复现bug、验证修复。是不是已经开始觉得它比某些实习生靠谱了？🤣

更绝的是，他们把可观测性工具也开放给AI了。日志、指标、追踪记录——AI可以直接用LogQL查日志，用PromQL查指标。

提示词可以是“确保服务启动在800ms内完成”，AI就能自己去验证。

这就是传说中的“把QA也外包给AI” 😂

原则3：给AI地图，不是百科全书 🗺️

最开始他们犯了一个错误：写了一个巨大无比的AGENTS.md文件，想把所有规则都塞进去。

结果可想而知：AI要么漏掉关键约束，要么被淹没在信息里，要么照着过时的规则干活。

后来他们学聪明了：把AGENTS.md从百科全书改成了目录（约100行），指向结构化的docs/文件夹。

设计文档、执行计划、技术债务追踪——全部分门别类，版本控制，定期由AI自己维护。

他们还做了一个特别骚的操作：写了一个后台AI，定期扫描过时的文档，自动发起清理PR。

这就变成了——AI给AI维护文档。😎

原则4：强制架构约束，用代码说话 📐

他们设计了一个严格的分层架构：

Types → Config → Repo → Service → Runtime → UI

每一层的依赖方向都是固定的。

这些约束不是写在文档里让人“注意”的，而是用自定义Linter和结构测试机械化强制执行的。

最妙的是，当AI违反规则时，错误消息不仅告诉你错了，还告诉你怎么修。

工具在AI干活的同时，也在教它。这就是所谓的“边工作边教学”。👩‍🏫

原则5：垃圾回收机制 ♻️

AI生成的代码有个问题：它会复制已有的模式，哪怕那个模式不太好。时间长了，代码库里全是“AI残渣”。

刚开始，团队每周五花20%的时间手动清理。后来他们把这个活也自动化了：

写了个后台AI，定期扫描技术债务、更新质量评分、发起重构PR。

从每周手动清理，变成让AI自己给自己打扫卫生。

这不就是传说中的“用魔法打败魔法”吗？🪄

---

05 Anthropic：16个AI同时干活，搞定了一个C编译器 🖥️

如果说OpenAI的实验是“深度”，那Anthropic的C编译器项目就是“广度”。

Nicholas Carlini（Anthropic的研究员）搞了个疯狂的项目：用16个并行的Claude实例，构建一个C编译器。

结果呢？

• ⏱️ 约2周时间
• 🤖 16个AI并行
• 📝 10万行Rust代码
• 🎯 GCC torture test通过率99%
• 📦 能编译PostgreSQL、Redis、FFmpeg、CPython，甚至Linux 6.9内核
• 💰 总API成本：约2万美元

他踩到的坑很有意思：

AI的时间盲区：Claude“无法感知时间，如果放任不管，会乐于花几个小时运行测试而不是推进工作”。解决方案是确定性测试子采样——每个AI只跑1-10%的测试，但不同AI跑不同的随机子集，合起来就能覆盖全套。

AI会重复造轮子：LLM生成的代码经常重新实现已有的功能。所以他们专门分配了一个“去重AI”来解决这个问题。

CI就是Harness：项目后期，AI在实现新功能时频繁破坏现有功能。解决方案不是换模型，而是加强CI流水线——用Harness层面的解决方案应对模型层面的问题。

Carlini的总结很到位：

“我必须不断提醒自己，我是在为Claude写这个测试框架，不是为自己写。”

这句话值得细品。👏

---

06 Stripe：Minions系统——AI自主干到PR 🚀

Stripe的实践可能是最接近“未来已来”的。

他们搞了个叫Minions的系统。开发者在Slack里发个任务，AI从写代码到跑通CI再到提PR，全程包办，人类只在最后审查环节介入。

关键要素：

• 🛠️ Toolshed MCP服务器：给AI提供了近500个工具，覆盖内部系统和SaaS平台
• 🧪 隔离的预热Devbox：AI和人类工程师使用相同的开发环境，但与生产和互联网隔离
• ⚡ 重要原则：AI需要的上下文和工具，和人类工程师一模一样——不是事后补上的集成，而是一开始就得是一等公民

有工程师开玩笑说：“我现在的工作就是在Slack里发消息，然后等AI把活干完。” 💬

当然，能这么玩的前提是Harness已经足够成熟。

---

07 工程师的新技能树：给AI套缰绳 🌳

看完这些案例，你可能在想：那我以后干什么？

答案在Charlie Guo的分析里：

“团队在这个光谱上的位置取决于两个因素——Harness的成熟度，和对AI在代码库中的信任程度。”

简单说，工程师的工作正在分成两块：

第一块：构建环境 🏗️

当AI卡住时，把它当作环境设计问题——诊断AI缺什么，然后让AI自己去建。

第二块：管理工作 📋

Greg Brockman建议每个团队指定一名“Agent队长”，负责思考AI如何融入团队工作流。

Boris Tane（Cloudflare）把核心原则总结为一句话：

“永远不要让AI在你审查和批准书面计划之前写代码。”

这句话背后是一个深刻洞察：审查500行代码可能需要半小时，但审查一个500字计划只需要3分钟。

计划错了，3分钟纠正；代码错了，半小时返工。 ⏱️

Anthropic把这个做到了极致：初始化Agent从高级prompt生成综合feature列表——单个Web应用超过200个独立功能，每个都有明确的测试步骤，全部初始标记为“failing”。

---

08 那些还没人解决的问题（空白区）🤔

说完了热闹的，来点扎心的。目前Harness Engineering还有三个没人能回答的问题：

空白1：老项目怎么办？ 🏚️

所有成功案例——OpenAI、Anthropic、Stripe——都是新项目。

对于十年历史的遗留代码库怎么引入这套方法？零成功案例，零方法论。

Martin Fowler把这个问题比喻得很形象：

“就像在一个从未用过静态分析工具的代码库上运行静态分析——你会被警报淹没。”

空白2：怎么验证AI做对了事？ ✅

目前大家擅长的是“约束AI不做错事”——架构约束、Linter、类型检查。

但“验证AI做对了事”这个问题，远没有解决。

即使给了AI浏览器自动化工具，它还是看不到浏览器原生alert弹窗。

功能正确性验证，是当前最大的技术缺口。

空白3：AI代码的长期可维护性 📚

Greg Brockman提出的问题：怎么防止“功能没问题但维护性很差”的代码渗透进代码库？

AI写的代码和人写的代码，积累技术债的方式不一样。LLM生成的代码经常重新实现已有功能（所以Carlini才需要“去重Agent”）。

“垃圾回收”Agent是一种新兴做法，但长期效果还缺数据。

---

最后的话：AI时代的工程师，正在进化 🦋

读到这里，你可能已经发现了：Harness Engineering不是一个“要不要用”的问题，而是“怎么用”的问题。

就像Addy Osmani说的：

“AI编码的兴起并没有取代软件工程的工艺——它抬高了工艺的门槛。”

在未来，你可能会看到两种工程师：

一种是还在跟AI比写代码速度，每天焦虑“我会不会被取代”的；😰

另一种是已经完成了进化，不再亲自写代码，而是设计让AI能高效工作的系统，用更少的人力和时间交付更可靠的产品。😎

OpenAI那个三人团队的经验告诉我们：

真正的稀缺资源不是代码能力，而是人类的时间和注意力。

而Harness Engineering，就是把人类的时间和注意力，用在真正需要判断力的地方——而不是跟AI卷代码行数。

最后，用Mitchell Hashimoto（Terraform创始人）的一句话收尾：

“每当发现AI犯错，就花时间设计一个解决方案，确保AI永远不会再犯同样的错误。”

这，大概就是AI时代工程师的新使命吧。💪

---

你觉得这套“缰绳工程”靠谱吗？欢迎评论区聊聊～ 💬