来源：市场资讯

（来源：图灵人工智能）

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

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

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

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

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

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

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

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

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

驾驭式工程，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 的运行时。

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

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

架构漂移（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 写了一百万行代码"，但往深了看，它在讨论一个更古老的问题：当工具足够强大，人的价值在哪里？

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

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

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

我愿意和读者一起期待。