AI编码工具的爆发式应用正在颠覆传统开发流程，但随之而来的代码混乱与维护困境让无数产品经理陷入崩溃。本文深度解析OpenAI提出的Harness Engineering方法论，揭秘如何通过文档化、自动化检测和闭环反馈机制，让AI从无头苍蝇变为高效协作伙伴，实现3人5个月零手写代码打造百万行项目的惊人案例。

都说PM要自己Vibe Coding写产品demo，然后你用 Cursor 写了一个小工具，跑起来了，很兴奋。

第二天你让 AI 加个功能，加上了，但把昨天的逻辑改崩了。修好，再加，又崩。一周后发现整个项目已经没法维护了。AI 每次都很努力，但它根本不记得你之前说过什么，也不知道你的代码架构长什么样。每次都要重新交代一遍背景，真的很崩溃。

我自己也经历过这个阶段。

去年我开始用 AI 写代码做产品的时候，工作模式就是边聊边改。想到一个功能就跟 AI 说一句，它写完我看看，不对再改。听起来很高效对吧？结果几轮下来，代码越来越乱，模块之间互相缠绕，改一处崩三处。最后只能推倒重构。

反复几次之后我悟了一件事：不能直接跟 AI 聊代码，得先写文档。

我开始在每个项目里写一份给 AI 看的 PRD。不是传统产品经理写给开发看的那种，而是写清楚每个功能的技术实现细节、交互逻辑、模块边界，但不限制 AI 用什么工具和技术栈。每次改需求，先改文档，再让 AI 按文档改代码。

效果立竿见影。AI 不再像无头苍蝇一样乱改，我也清晰地知道当前有哪些功能、每个模块负责什么。

但后来我发现，我这套做法只是解决了一小部分问题。

2026年2月，OpenAI 发了一篇博客，讲他们的 Codex 团队只用 3 个工程师，5 个月时间，不写一行手工代码，让 AI 生成了 100 万行代码的完整产品。他们把这套方法叫做Harness Engineering（驾驭工程）。

我看完之后的感受是：我先写文档再写代码的土方法，只是 Harness 的冰山一角。

Harness Engineering 是什么？先讲个故事。

Codex 团队从一个空的代码仓库开始，用 5 个月时间交付了一个完整的内部产品。这个产品有真实用户在每天使用，经历了上线、部署、故障、修复的完整生命周期。

重点是整个项目大约 100 万行代码，没有一行是人手写的。全部由 AI Agent 生成。最初推动这件事的只有 3 名工程师。

3 个人，100 万行代码，0 行手写。

你可能会问：这 3 个人每天在干嘛？

答案是：他们在带新人。

把 AI Agent 想象成一个能力极强的新员工。代码能力比你强，执行速度比你快十倍，一天能产出十几个 PR。但他有一个致命问题：对你们公司的一切一无所知。

你不告诉他公司的架构规范，他就按自己的理解随便写。你不告诉他模块之间的边界，他就把 A 模块的逻辑写到 B 模块里。你不给他检查标准，他写完就提交，错了也不知道。你不让他看运行日志，他改完代码连对没对都不确定。更可怕的是，他的学习方式是看代码库里已有的代码来模仿。如果代码库里有一段写得不好的代码，他不会判断”这个不该学”，而是会照着这个坏模式继续写，还能写出十个变体来。

听起来是不是很熟悉？带过新人的产品经理应该都有类似体感：新人不是不聪明，是缺乏上下文和规矩。

OpenAI 的工程师把这套”带 AI 新人”的方法论总结成了一个词：Harness Engineering（驾驭工程）。

Harness 是马具的意思，就是骑马时套在马身上的缰绳、马鞍、嚼子那一整套装备。听起来这个词有点花里胡哨，但其实这个比喻很精准：

• 马是大模型，力气大、跑得快，但不知道往哪跑
• 马具（Harness）是你给它搭建的规则、文档、检测工具、反馈机制
• 骑手是工程师，负责定方向、做判断

马的能力越强，马具就越重要。没有缰绳的千里马，只会把你摔下来。

为什么 Prompt 不够了？从单向指令到闭环系统

你可能觉得，问题出在 AI 不够聪明。

不是。现在的大模型写代码、做设计、写文档的能力已经很强了。OpenAI 那个 100 万行代码的项目就是证明，模型能力完全够用。

那是不是 prompt 写得不够好？

也不全是。你把 prompt 写成 3000 字的小作文，把所有要求塞进去，AI 当时确实能按要求做。但明天你再开一个对话，它又什么都不记得了。你又得重新交代一遍。

这就是问题的根源：不是 AI 的能力问题，是你跟 AI 协作的方式问题。

我自己的经历刚好走过了三个阶段，每个阶段的协作方式完全不同。

第一阶段：Prompt

最早用 AI 的时候，就是对话框里打字。想到什么说什么，AI 做完了我看看，不对再改。就像你在微信里给实习生发消息：帮我做个XX。他做完了交给你，你发现不对，再发一条。一来一回，效率极低，而且每条消息之间没有连续性。上一条你说的要求，下一条他可能就忘了。

这个阶段的核心问题是：指令是一次性的，没有积累。 第二阶段：Skills（文档化上下文）

反复被”AI 失忆”折腾之后，我开始做一件事：把规范、架构、参考资料写成持久化的文档。我用 Claude 的 Skills 体系，给每个工作场景写一份SKILL.md文件，相当于一本入职手册。AI 每次执行任务都能读到这份手册，不用我每次重新交代。

效果确实好了很多。AI 的产出质量稳定了，风格一致了，不再像无头苍蝇。

但新问题来了：AI 不遵守规范的时候，我只能靠自己一条条人肉检查。手册写得再好，它不按手册来你也没辙，只能你自己去发现、去纠正。当产出量上来之后，这就成了瓶颈。

就像你给新人准备了一份详细的入职手册，但新人看没看、照没照着做，全靠他自觉。你得自己一个个去检查。带一个人还行，带十个你就疯了。

第三阶段：Harness（闭环系统）

Harness Engineering 在 Skills 的基础上，加了一个关键的东西：自动检测 + 自动修复的反馈闭环。

不光有文档告诉 AI 该怎么做，还有自动化工具检测 AI 有没有做对，做得不对的时候系统直接告诉 AI 哪里错了、该怎么改。AI 自己修完再提交，再检测，直到通过。全程不需要人盯着。

回到带新人的类比：这就像你不光给了新人入职手册，还给他配了一套代码检查工具，写完代码自动跑检测，哪里不符合规范直接标红告诉他怎么改。他改完再跑一遍，通过了才能提交。你只在工具也搞不定的时候才需要出手。

所以这三个阶段是一条清晰的进化链：

Prompt（单向指令）→ Skills（持续上下文）→ Harness（闭环系统）

大部分人现在还停留在第一阶段和第二阶段之间。而 OpenAI 已经在第三阶段跑出了成果。

怎么给 AI 套上马具？四个核心机制

你现在知道了 Harness 是什么，但具体怎么给 AI 套上这套马具？

OpenAI 在实践中总结了六大核心机制。我挑四个跟产品经理最相关的展开讲。

4.1 给 AI 一张地图，而不是一本百科全书

你有没有发现，AI 换个对话窗口就像失忆了一样？

这不是 AI 的 bug，这是所有大模型的底层机制：它只能看到你当前喂给它的信息。你脑子里的架构想法、你们团队 Slack 里的讨论、你上周跟同事达成的那个约定，AI 统统不知道。

对 AI 来说，它看不到的信息就等于不存在。

所以第一件事就是把这些隐性知识显性化，写进 AI 能读到的地方。

但这里有个坑。OpenAI 一开始也踩了：他们把所有规则、架构说明、编码规范全塞进一个大文件里。结果适得其反。为什么？打个比方。你给新人的第一天发了一份 200 页的公司手册，告诉他”这里面什么都有，你自己看”。你猜他会怎么做？大概率翻两页就放下了，遇到问题还是直接来问你。

AI 也一样。你给它塞一个超长的指令文件，会出现一个问题：上下文稀释。重点太多就是没有重点。AI 没法区分哪些规则是当前任务最重要的，哪些只是通用背景，最后它要么忽略关键约束，要么对着一条无关的规则死磕。

OpenAI 的解决方案很精巧：把大百科全书拆成一张目录地图。

他们写了一份大约 100 行的AGENTS.md文件，放在项目根目录。这个文件不讲具体规则，只做一件事：告诉 AI 去哪里找更详细的信息。具体的设计文档、编码规范、产品说明分门别类放在 docs/ 子目录里，AI 根据当前任务按需去读对应的文件。

这个方法叫渐进式披露，在Skill里也有一样的逻辑，不是一上来把所有信息全给你，而是先给你一个入口，让你根据需要逐层深入。

用带新人的类比来说：你不应该在新人第一天就扔给他一本 200 页的手册。而是给他一张”你遇到 X 类问题去找谁、遇到 Y 类问题查哪个文档”的速查卡片。他带着这张卡片就能自己导航，不需要你每次都手把手指路。

还有一个容易忽略的细节：文档本身也需要维护。OpenAI 专门安排了一个”图书管理员”Agent，定期巡查所有文档，发现跟实际代码不一致的就自动修复。他们把文档当成代码一样管理，有版本控制、有自动检测、有持续更新。

因为过时的文档比没有文档更危险。AI 按照一份过期的规范去执行，产出的东西跟你的预期南辕北辙，而你可能很久才发现问题出在哪。

4.2 AI 写错了，靠什么发现？靠你自己一行行看？

你带过新人就知道，交代完任务不等于任务做对了。新人交上来的东西你总得检查一遍。一个两个还好，如果你同时带十个新人，每天每人交三份作业，你根本看不过来。

AI Agent 面临的就是这个问题的放大版。OpenAI 那个项目，平均每个工程师每天要处理 3.5 个 PR。3 个工程师就是每天十几个 PR。靠人眼一行行看？不可能。

所以他们设计了一个特别聪明的机制：让机器替你检查，而且检查出问题之后直接告诉 AI 怎么改。

流程是这样的：AI 写完代码提交，自动化检查工具立刻跑一遍。如果发现违规，构建直接失败，同时在错误信息里写清楚”你哪里错了、该怎么改”。注意，这个错误信息不是写给人看的，是写给 AI 看的。AI 读到错误信息之后自己修改，改完再提交，再检查，直到通过。

全程不需要人参与。

这就是 Harness 最核心的引擎：反馈闭环。

你可能会问：机器能检查出什么问题？AI 犯的错不都是那种”说不清楚但就是不对”的问题吗？

不全是。OpenAI 把检查分成了三个层级：

第一层：死规矩，机器直接判。比如”A模块不能调用B模块的代码””日志必须用统一格式””单个文件不能超过500行”。这些规则非黑即白，写成检查工具一跑就知道对不对。就像公司的考勤制度，迟到就是迟到，没有灰色地带。第二层：跑一遍才知道的问题。比如”服务启动时间不能超过800毫秒””模块之间有没有循环依赖”。这些你光看代码看不出来，得实际运行一遍、跑一遍测试才能发现。就像新人写的方案，逻辑看着没问题，但放到实际场景里一跑就暴露了。

第三层：说不清楚的软标准，让另一个 AI 来判。比如”这个模块的职责是不是越界了””这段代码的设计风格跟整体一不一致”。这类问题没法用死规矩定义，但另一个 AI Agent 可以基于上下文做出判断。就像你搞不定新人的问题，找一个资深同事帮忙看看。

三层检查叠在一起，从硬规则到软判断全覆盖。大部分问题在 AI 提交的那一刻就被拦住了，根本到不了你面前。

4.3 AI 写的代码为什么越来越乱？

如果你用 AI 做过稍微大一点的项目，一定有过这种感觉：刚开始写的时候挺好的，代码清晰、结构分明。但写了几天之后，整个项目开始变味了。风格不统一，重复代码到处都是，明明之前定好的规范不知道什么时候就被打破了。

这不是你的错觉。这是 Agent 开发的一个底层特性：AI 会无脑复制和扩展代码库里已有的模式。

好模式如此，坏模式也如此。

打个比方。你团队里有个新人，他特别擅长”照葫芦画瓢”。你让他参考现有代码写新功能，他写得又快又像。问题是，如果他参考的那段代码本身就有问题，他不会判断”这个不该学”，而是会照着这个坏样本继续写，还能写出十种变体来。

人类开发者也会引入坏模式，但传播速度是线性的。一个人一天也就写那么多代码，Code Review 还能兜住。但 Agent 的产出量是人类的十倍以上，一个坏模式可以在一天之内扩散到整个代码库。人类制造的技术债是线性增长，Agent 制造的技术债是指数增长。

OpenAI 一开始也被这个问题折腾得够呛。他们每周五留出 20% 的时间手动清理 AI 产出中的各种垃圾。但很快就发现这种方式不可持续。代码量每天在涨，人手就那么几个，根本清不过来。

他们的解决方案很妙：既然 AI 制造了混乱，就让 AI 自己清理。

他们制定了一组”黄金原则”，就是对代码质量的硬性标准，比如”优先使用共享工具包而不是手写工具函数””数据结构必须有类型验证，不允许靠猜”。然后安排一组后台 Agent，定期自动扫描整个代码库，找出不符合黄金原则的地方，自动发起修复。

这个机制跟 Java 里的垃圾回收（GC）是同一个思路：不是等垃圾堆满了再一次性清理，而是在后台持续回收。技术债就像一笔高息贷款，每天还一点利息很轻松，等到累积成山再还就要你命了。

这里面有一个特别深刻的洞察：人类的品味一旦被编码成规则，就可以持续自动应用于每一行代码。你不需要每天盯着代码库看，你只需要把”什么是好的”定义清楚，让机器帮你持续守住标准。

4.4 AI 写完了，谁来验证它写对了？

前面讲的三个机制，解决的都是”AI 怎么写”的问题。但还有一个问题没解决：AI 写完了，怎么知道它写的东西能跑、跑得对？

你带新人的时候应该有这个体感：新人写完方案交给你，你问他”你验证过了吗？”他说”我觉得没问题”。你心里一万个问号。”你觉得”不算数，你得自己去验一遍。

AI Agent 也是这样。它写完代码告诉你”完成了”，但它自己其实没有能力判断代码跑起来到底对不对。因为它看不到运行结果，看不到日志，看不到界面长什么样。它就是一个只会写但看不见的人。

OpenAI 的做法是：给 AI 装上眼睛。

他们给 Agent 开放了三个感知通道：

第一，能看界面。通过浏览器自动化工具，Agent 可以自己打开应用、点击按钮、截图、查看页面元素。它不需要你帮忙打开浏览器截个图发给它，它自己就能看。

第二，能查日志。Agent 可以直接查询应用的运行日志，看有没有报错、请求链路是不是通的。就像一个开发者自己打开日志面板排查问题。第三，能看指标。延迟多少毫秒、错误率多高、吞吐量够不够，Agent 都能自己查。你可以直接跟它说”确保服务启动在 800 毫秒内完成”，它会自己启动服务、查指标、定位瓶颈、改代码、再验证。全程你不需要参与。

有了这三个通道，Agent 从一个”只会写”的人变成了一个”能写、能看、能测”的完整开发者。

而且每个 Agent 任务都跑在一个完全独立的环境里，自带独立的代码分支、独立的应用实例、独立的数据库。做完了整个环境直接销毁。就像你给每个新人分了一间独立的实验室，他在里面怎么折腾都不会影响别人。

这意味着你可以同时让多个 Agent 并行工作，互不干扰。OpenAI 经常看到单个 Agent 在一个任务上连续工作超过六个小时，通常是在工程师睡觉的时候。

从 human in the loop 到 human on the loop

所以，Harness Engineering 到底改变了什么？

如果只用一句话总结，就是这个转变：

从 human in the loop，到 human on the loop。

in the loop，是你在循环里面。AI 每做一步你都要参与：看代码、提修改、验结果、再看代码。你是流水线上的一个工位，少了你就停工。

on the loop，是你在循环上方。AI 自己跑完整个流程，你在上面看大盘。哪里亮红灯了你再下去处理，没亮就不用管。

这不是偷懒，是把人类最稀缺的资源用对了地方。

Harness-in the loop vs on the loop.excalidraw

OpenAI 原文里有一个很直白的说法：人类的时间和注意力是唯一真正稀缺的资源。3 个工程师面对每天十几个 PR，如果每个都人工 review，那 Agent 写得再快也没用，瓶颈在你身上。

所以工程师的角色发生了根本性的转变。不再是”写代码的人”，而是”设计 Agent 工作环境的人”。你的核心产出不再是代码，而是约束、反馈和环境。

这对产品经理意味着什么？

你可能觉得这是工程师的事，跟 PM 没关系。但仔细想想，这个范式转移的本质不是技术问题，是协作方式的根本改变。

产品经理未来跟 AI 协作的方式，也会经历一样的进化。你现在可能还在用 prompt 跟 AI 一问一答地做需求、做分析、做文档。但随着 AI Agent 越来越强，你迟早要面对同样的问题：怎么让 AI 自主完成更长链条的任务，而不是每一步都需要你盯着？

答案就是 Harness 的思路：不要试图在每次对话里给 AI 更好的指令，而是投入时间去搭建一套让 AI 能自主运转的系统。把你的标准、你的规范、你的判断力编码进这个系统里，让它持续为你工作。

回到我自己的经历。从”边聊边改”到”先写文档再写代码”，再到现在搭建完整的 Skills 体系，本质上就是在这条进化链上一步步走过来的。而 Harness Engineering 告诉我，这条路还远没到头。我那套 Skills 体系只是做到了”给 AI 持续的上下文”，但”自动检测””自动修复””Agent 审查 Agent”这些闭环机制，还有很大的空间可以搭建。

最后

我们从一个很多人都有的痛苦讲起：用 AI 做项目，越用越乱。不是 AI 不行，是我们跟 AI 协作的方式还停留在早期阶段。

OpenAI 的 Codex 团队用一个极端实验证明了另一种可能：3 个人，5 个月，100 万行代码，0 行手写。他们把这套方法叫Harness Engineering（驾驭工程）。核心思路是什么？不要试图给 AI 更好的指令，而是给 AI 搭建一个更好的工作环境。

这个环境包含四个关键机制：

• 地图而非手册：给 AI 一张导航目录，让它按需查找，而不是把所有信息一股脑塞给它
• 反馈闭环：AI 做错了不靠你人肉检查，而是机器自动检测、自动告诉 AI 怎么改
• 持续清理：AI 会无脑复制坏模式，所以需要后台 Agent 持续自动清理垃圾
• 给 AI 装上眼睛：让 AI 能看界面、查日志、看指标，自己验证自己的产出

而你跟 AI 协作的方式，也有一条清晰的进化路径：

Prompt（单向指令）→ Skills（持续上下文）→ Harness（闭环系统）

大部分人还停留在前两个阶段。Harness Engineering 告诉我们第三阶段长什么样。

最终指向的是一个根本性的转变：

从 human in the loop，到 human on the loop。

你不需要参与每一步。你需要做的，是把你的标准、你的规范、你的判断力编码进系统里，让 AI 在你设计的轨道上自主运转。

你设计的不是功能，而是约束、反馈和环境。