OpenAI 用 AI 写了 100 万行代码，人类一行都没写——他们是怎么做到的？

来源：市场资讯

（来源：图灵人工智能）

您想知道的人工智能干货，第一时间送达

TL;DR（极简版）：

OpenAI 已经做到：AI 自己写、测、改代码，人类一行不写

核心不是 AI 变强，而是方法变了：人负责定规则，AI 负责执行

关键只有一句话：不会写规则的人，会被会写规则的人淘汰

本质转变：

• 以前：你写代码

• 现在：你定义“什么是好代码”

OpenAI 有一个团队的顶级程序员基本不写代码。

这是 OpenAI 工程师 Ryan Lopopolo 在今年二月发的一篇工程博客里记录的真实经历。三名工程师，从空仓库开始，五个月时间，一百万行代码，1500 个 PR，产品已经有真实用户在日常使用。整个过程，人类没有手动写过一行代码。

这套方法论有个名字，叫 Harness Engineering——驾驭式工程。

1784年的一个工人，和2026年的一个工程师

1784年，英国某座工厂里，有个工人每天的工作就是站在蒸汽机旁边，盯着转速，手动调节阀门。转快了拧小，转慢了拧大。一整天，就干这一件事。

后来詹姆斯·瓦特发明了离心调速器——一个会随转速自动张开或收拢的飞球装置，直接接在阀门上。转速高了，飞球张开，阀门自动收小；转速低了，飞球收拢，阀门自动开大。机器自己管自己，不再需要人盯着。

那个工人没有消失，但他的工作彻底变了。他不再转阀门。他开始设计调速器。

两百多年后，2026年的 OpenAI，一个三人工程团队用五个月时间，让 AI 写了一百万行代码，发布了一个有真实用户的产品。整个过程，人类没有手动写过一行代码。

这两件事，本质上是同一件事。

Norbert Wiener 在1948年给它起了个名字：控制论（Cybernetics），来自古希腊语 κυβερνήτης，意思是"舵手"。你不再转阀门，你来掌舵。Kubernetes 这个名字，也来自同一个词根。

OpenAI 把这套做法叫做 Harness Engineering——驾驭式工程。

先说清楚，这不是"AI 辅助编程"的升级版

很多人听到"AI 写代码"会条件反射地联想到 Copilot，联想到 Tab 键自动补全，联想到"省点打字力气"。

这是两件性质完全不同的事。

AI 辅助编程，人类还是主角。你决定写什么、怎么写，AI 帮你快一点。

推荐阅读：斯坦福CS146S：AI辅助、多智能体、AI原生，一次说清楚三者关系仅仅离上篇多agent和ai原生概念的文章发布过去 12 天，技术路线就已经发展出新的脉络。有一句话怎么说：”躺平的速度约等于ai进化的速度，过段时间再学“不无道理。harness 概念是 7 天前发的，我在脑子里面基本上每天都有30-60min在想这个概念，或者在看别的博主都解释、内部培训文档，卷疯了。

驾驭式工程，AI 智能体是主角。人类退到幕后，扮演架构师、规则制定者和裁判员。AI 自己决定怎么实现、自己跑测试、自己提 PR、自己回应审查意见、自己合并代码。

更关键的区别在于：AI 能力不是瓶颈，环境设计才是。

绝大多数人抱怨"AI 老是做错事，不理解我们的代码库"——这个诊断几乎都是错的。不是 AI 没有能力，而是你没有把它需要的知识外化出来。它不会通过"感受团队气氛"来学习规范，你不写下来，它就永远不知道。

这是驾驭式工程最反直觉的地方：问题不在 AI，在你自己有没有把判断力变成机器可读的东西。

真正的工作，发生在这五个地方

1、关闭高层的反馈回路

代码库其实一直有反馈回路，只是层次太低。

编译器负责语法，测试套件负责行为，Linter 负责风格——这些都是真实的控制系统，但它们只能检查"可以机械验证的属性"：能不能编译？测试过不过？格式对不对？

更高层的问题——这个改动符不符合系统的整体架构？这个抽象三个月后会不会变成麻烦？——从来没有传感器，也没有执行器。只有人类能在这个层面做判断，也只有人类能动手修。

LLM 同时改变了这两端。它可以在人类曾经独占的层面上感知问题，也可以在同一层面上执行修复——重构一个模块，重新设计一个不一致的接口，围绕真正重要的契约重写测试套件。反馈回路第一次可以在真正重要的决策层面闭合。

这是整个驾驭式工程的理论基础。其余的一切，都是在回答同一个问题：怎么把这个回路调好。

2、把判断力变成机器可读的东西

这是最难的部分，也是大多数人卡住的地方。

工程师最宝贵的东西——什么是好代码、哪些模式这个架构鼓励、哪些模式要避免——通常只存在于脑子里，或者散落在 Slack 记录和会议纪要里。对人类来说，这些东西通过"感受"传递，新同事会慢慢被"熏陶"出来。

AI 没有这个能力。它在第一百次运行里犯的错和第一次完全一样，除非你把规则写下来。

OpenAI 的解法是三层结构：架构文档描述真实的分层关系和依赖方向；自定义 Linter 把规则变成自动检查，报错信息直接写给 AI 看，告诉它"你应该这样改"；"黄金原则"把团队的品味编码成可执行的规范。

他们花了每周五一整天清理"AI 残渣"——直到把自己的标准编码进工具里，这个工作才消失。这不是 AI 变聪明了，是他们把聪明变成了规则。

3、给 AI 一张地图，不是一本百科全书

上下文窗口是稀缺资源。往 AI 的上下文里塞越多，真正有用的信息就越少。

OpenAI 踩过这个坑——他们试过一个巨大的 AGENTS.md，把所有规则和注意事项全装进去。结果 AI 要么漏掉关键约束，要么对着已经过时的规则反复优化，越跑越歪。更麻烦的是，没有人愿意维护这个文件，它慢慢变成了陈旧规则的坟场。

他们后来的做法极其克制：AGENTS.md 只保留大约 100 行，作用是一张索引地图，告诉 AI"遇到什么问题去看哪个文件"。真正的知识按领域分散存放，有专门的 CI 作业检查文档是否过期、是否有交叉链接。

你要给 AI 的是导航系统，不是城市全图。 关键是渐进式披露：从一个小而稳定的入口开始，指向更深层的信息，而不是一开始就把所有东西倾泻进去。

4、让应用对 AI 直接可见

有一个细节，比什么理论都直观：OpenAI 把 Chrome DevTools 协议接进了 AI 的运行时。

Codex 能打开浏览器、截屏、点击、看 DOM、观察运行时事件。发现 bug，自己复现，自己修，跑一遍验证，录个视频证明修好了，提 PR。整条链路，AI 自己完成。他们还给 AI 配了完整的可观测性栈——用 LogQL 查日志，用 PromQL 查指标，每个任务有独立的 Git Worktree 实例，跑完自动销毁。

这让"确保服务启动在 800ms 以内"这种指令变得可行。否则对 AI 来说，这个要求毫无意义——它根本看不到数据。

这背后是一个简单的等式：你投入多少精力让系统对 AI 可读，AI 就能换回多少自主工作的能力。 不是线性关系，是杠杆关系。

5、把技术债变成每天自动还的利息

AI 会复制它在代码库里看到的模式，包括坏的那些。时间一长，坏模式会像病毒一样扩散，架构漂移开始发生，风格混乱，补丁摞补丁。

OpenAI 最初靠人工清理，每周五一整天。很快发现不可持续——AI 产出的速度永远快过人工清理的速度。

他们的解法是用 AI 清理 AI 造成的问题。定义"黄金原则"，然后定期跑后台 Codex 任务，专门扫偏差、发起重构 PR。大多数这类 PR 一分钟内审完自动合并。

这里有一个更深的洞察：如果环境没有校准好，你连"用 AI 清理 AI 造成的烂摊子"这件事都做不到，因为 AI 不知道什么是干净的。 没有标准，清理工具和制造问题的工具是同一个东西。

五个层面的对比

核心工作

本质是什么

门槛

最容易忽视的时机

忽视的代价

关闭高层反馈回路

让 AI 能感知并修复架构级问题

项目立项时

AI 只能处理表层问题

判断力机器可读化

把品味变成规则，写给 AI 看

第一次发现"AI 总做错"

每次运行都重复同样的错误

上下文地图化

精准指路而非信息轰炸

文档开始膨胀时

AI 越跑越偏，规则失效

应用对 AI 可见

日志、UI、指标全部暴露给 AI

AI 开始频繁出错时

AI 无法自主验证，依赖人工

自动化熵控制

每天还利息而不是集中爆发

坏模式开始重复出现时

技术债以 AI 速度复利增长

那个工人后来去哪了

那个在蒸汽机旁边转阀门的工人，在调速器发明之后，并没有回家。他去设计了更好的调速器。

他没有消失，但他的位置变了——从执行循环的内部，移到了循环的外部。他不再是被调速器控制的那根阀门，他是设计调速器的人。

驾驭式工程走到这里，留下的不是一套新工具，而是一个古老问题的新版本：当机器能做你做的事，你去做什么？

答案是：去做机器做不到的事——判断什么是对的，设计让机器知道什么是对的，然后让机器以你完全无法企及的速度去执行。

那些一直被工程书籍推荐、一直被大多数团队跳过的实践——完善的文档、自动化测试、明确的架构决策、快速的反馈回路——一直都是正确答案。只是以前跳过的代价是慢性的，悄悄累积的。现在，代价变成了即时的，而且以机器的速度复利。

你现在能做的最有价值的一件事，不是学一个新工具，而是把你脑子里那些"不言而喻的规则"写下来——写进文档，写进 Linter，写进任何能让机器读到的地方。

那是舵手真正掌舵的地方。

名词解释

控制论（Cybernetics）研究系统如何通过反馈信号来实现自我调节和控制的学科，由数学家 Norbert Wiener 于1948年创立。核心思想是：系统感知自身状态，与目标对比，然后自动纠偏。蒸汽机调速器、恒温器、自动驾驶，背后都是这个逻辑。

Kubernetes谷歌开源的容器编排系统，负责自动管理服务器上运行的应用程序。你告诉它"我要三个副本在线"，它就持续确保这件事成真——某个副本挂了，它自动重启；负载高了，它自动扩容。名字来自希腊语"舵手"，和控制论同一词根。

Copilot微软推出的 AI 编程助手，集成在代码编辑器（如 VS Code）里。它会根据你正在写的代码，预测并补全接下来的内容，按 Tab 键接受建议。本质上是"更聪明的自动补全"，人类仍然主导每一个决策。

AI 智能体（AI Agent）能够自主感知环境、制定计划并连续执行多步骤行动的 AI 程序。区别于只回答单个问题的普通 AI——智能体会主动"做事"，比如自己查资料、写代码、运行测试、根据结果调整策略，直到完成目标。

PR（Pull Request）代码合并请求。开发者把写好的代码推送到一个独立分支，然后发起 PR，请求把这些改动合并进主代码库。团队成员可以在 PR 里查看代码差异、留下评审意见，作者修改后再合并。是现代软件团队协作的标准流程。

代码库（Codebase）一个软件项目的全部源代码集合，通常存放在 Git 这类版本控制系统里统一管理。包含应用逻辑、测试、配置文件、文档等所有构成这个软件的文件。

编译器（Compiler）把人类用高级编程语言（如 Python、Java）写的代码，翻译成计算机能直接执行的机器语言的程序。编译过程中会检查语法错误——写错了就报错，不让你运行。

测试套件（Test Suite）一组自动化测试脚本的集合，用来验证代码的功能是否符合预期。每次改动代码后，跑一遍测试套件，就能知道有没有把原来能用的东西搞坏。

Linter静态代码分析工具。不运行代码，直接扫描源文件，检查格式规范、潜在错误和不良编码习惯。就像语文老师批改作文时标出的"用词不当"和"格式错误"——只是速度快得多，而且不会疲劳。

LLM（大语言模型）Large Language Model，通过对海量文本进行训练得到的 AI 模型，能理解和生成人类语言，也能读懂和编写代码。ChatGPT、Claude、Gemini 都属于这一类。"大"指的是模型参数量极大，通常达到数十亿乃至数千亿个。

https://cloud.tencent.com/developer/article/2446221

架构文档（Architecture Doc）描述软件系统整体结构的文档，说明各个模块是什么、彼此怎么协作、依赖关系如何。相当于建筑的设计图纸——施工前先搞清楚这栋楼长什么样，各层之间怎么连接。

AGENTS.md放在代码仓库根目录的一种 Markdown 文件，专门写给 AI 智能体看的操作说明。告诉 AI 这个项目的规则、惯例、目录结构和工作方式。类似于给新员工的入职指引，只不过读者是机器。

上下文窗口（Context Window）LLM 每次处理任务时能"看到"的最大信息量。超出这个范围的内容，模型完全不知道。就像人的工作记忆有容量上限，塞进来的东西越多，每条信息能分到的"注意力"就越少。

CI 作业（CI，持续集成）Continuous Integration，每次有代码提交时自动触发的一系列检查任务，包括运行测试、检查代码格式、验证文档结构等。检查不通过，代码就不能合并。相当于流水线上的质检环节，每个零件进来都要过一遍。

渐进式披露（Progressive Disclosure）一种信息组织策略：先呈现最核心的内容，再按需引导到更深的细节，而不是一次性把所有信息全部展示出来。目的是降低认知负担，让接收方能按需获取信息。

Chrome DevTools 协议（CDP）Chrome DevTools Protocol，谷歌浏览器提供的一套程序接口，允许外部程序远程控制浏览器、读取页面结构、监听网络请求和运行时事件。通常用于自动化测试和调试，OpenAI 把它接入 AI 运行时，让 AI 能像人一样"操作浏览器"。

CodexOpenAI 开发的代码智能体，能够理解自然语言描述的任务，并自主完成编写、测试、提交代码等一系列工程工作。本文中 OpenAI 团队用它完成了整个产品的开发。

DOM（文档对象模型）Document Object Model，浏览器把网页解析成的树状数据结构。页面上的每个按钮、文字、图片，在 DOM 里都是一个节点。程序可以通过读取和修改 DOM 来控制页面的显示内容和行为。

可观测性栈（Observability Stack）一套用于监控和理解系统运行状态的工具组合，通常包含三类数据：日志（记录发生了什么事）、指标（系统健康状况的数值，如响应时间、错误率）、追踪（一个请求在系统内部各环节的完整旅程）。

LogQL / PromQL两种专门用于查询监控数据的查询语言。LogQL 用于查询 Loki 日志数据库，从海量日志里筛选出特定记录；PromQL 用于查询 Prometheus 指标数据库，计算和分析各类系统指标。语法类似 SQL，但专为时序数据和日志场景设计。

Git WorktreeGit 版本控制系统的一个功能，允许同一个代码仓库在不同的目录下同时检出不同的版本，互不干扰。OpenAI 用它让每个 AI 任务都有独立的运行环境，多个任务可以并行处理而不会相互影响。

架构漂移（Architecture Drift）代码库随着时间推移逐渐偏离原始设计意图的现象。通常是因为大量局部修改慢慢积累，每次改动看起来都无伤大雅，但叠加起来就破坏了整体的一致性和设计原则。

重构（Refactoring）在不改变程序外部行为的前提下，改善代码内部结构的过程。功能不变，但代码变得更清晰、更易维护、更符合设计规范。就像整理房间——东西还是那些东西，但放得更有条理了。

https://pub.towardsai.net/ai-solves-p-versus-np-problem-8bcf347c0848?gi=876f503c1f63

P vs NP计算机科学中最著名的未解难题之一。核心直觉是：验证一个答案是否正确，通常比从零开始找到这个答案容易得多。这个不对称性在驾驭式工程里有直接意义：你不需要比 AI 更会写代码，你只需要比 AI 更会判断代码写得对不对。

编者按

我第一次读到这篇文章，脑子里冒出来的不是兴奋，而是一种很久没有过的感觉——似曾相识。

不是因为内容眼熟，而是因为这件事发生过。不止一次。

回顾：这条线，我们其实走了很久

如果你把镜头拉远，会发现软件工程这几十年走过了三条平行的演进线索，而这篇文章，恰好是三条线同时交汇的节点。

第一条线，是"验证"持续替代"执行"的历史。

从手写汇编到高级语言，从人工测试到自动化测试，从人工代码审查到静态分析工具——每一次进化，都是把"执行层"交给机器，把人类的注意力推向更高的"判断层"。驾驭式工程不是这条线的终点，它是目前为止最激进的一步：把编码本身也交出去了。这不是突变，是量变积累到了质变的临界点。

第二条线，是"隐性知识"持续显性化的历史。

软件工程几十年来最难解决的问题，从来不是技术，而是知识传递。老工程师脑子里那套"为什么这样设计""为什么不能那样改"，很难教给新人。Linter、架构文档、设计评审、ADR 记录——这些工具的本质，都是在把隐性知识变成显性规则。AI 智能体只是把这件事的优先级，从"最好有"变成了"必须有"。不写下来，代价从"慢慢腐化"变成了"立刻崩塌"。

第三条线，是"谁是工程师"这个问题的持续漂移。

1980年代，程序员是少数人。后来有了更高级的语言和框架，门槛下移，更多人能写代码了。再后来有了低代码工具，非技术背景的人也能搭应用了。现在，AI 能直接把自然语言变成代码——这条线一直在往同一个方向走：让"表达意图"变得比"实现意图"更重要。驾驭式工程只是这条线走到今天的样子。

展望：我愿意说三件可能发生的事

我不想散布焦虑，但我也不想假装这些变化无关紧要。以下三个判断，是我认为值得认真对待的方向。

第一，"软件工程师"这个职位不会消失，但它的入职门槛会被彻底重新定义。

以前面试考算法题，是因为写代码需要扎实的基础。未来，面试可能会更像产品评审——你能不能把一个模糊的需求拆解成清晰的验收标准？你能不能判断 AI 给出的方案哪里合理、哪里有坑？《钢铁侠》里托尼·斯塔克设计盔甲的方式，比他亲手锻造盔甲零件更值钱——这个比喻以前是夸张，现在开始变成字面意思了。

第二，文档会从"最容易被跳过的事"变成"最核心的工程资产"。

这听起来像老生常谈，但这次驱动力完全不同。以前写文档靠职业道德，现在写文档靠生存压力——AI 看不到的东西不存在，你不写下来，智能体就会按它自己的理解行事，而且会以机器的速度把错误复制到整个代码库。一家公司的工程文档质量，会开始直接反映在它的 AI 开发效率上，变成可量化的竞争优势。

第三，"人机协作"的瓶颈，会从技术侧转移到组织侧。

现在大家谈 AI 落地，还在聊模型够不够好、工具够不够稳。但这篇文章揭示了另一个维度：OpenAI 的团队花了最多时间的地方，不是调模型，而是建规范、写文档、设计反馈回路。未来真正拉开差距的，不是哪家公司用的模型更强，而是哪家公司更擅长把自己的判断力外化成机器可以执行的规则。这是一个组织能力问题，不是一个技术问题。

这篇文章讲的，表面上是"三个工程师怎么用 AI 写了一百万行代码"，但往深了看，它在讨论一个更古老的问题：当工具足够强大，人的价值在哪里？

瓦特的调速器发明之后，那个转阀门的工人没有消失。他去设计了更好的调速器。

这不是一个关于被替代的故事，而是一个关于位置迁移的故事。人类一直在把自己从执行循环里解放出来，移到更高的位置上。这次只是又往上走了一层。

至于站在那个新位置上，风景是什么样的，我还没有完整的答案。

我愿意和读者一起期待。