本文整理自 OpenAI Forum 发布的分享视频：Vibe Engineering with OpenAI’s Codex。
什么是“Vibe Engineering”？看看 OpenAI 内部是如何重新定义软件开发的
我们大概都经历过那种死线逼近的时刻，心里幻想着：“要是有个不知疲倦、不用睡觉的同事能帮我把这些代码写了该多好。”
在 OpenAI，Codex 就扮演着这个角色的。
最近在 OpenAI Forum 上，Global Affairs 团队的 Chris Nicholson 邀请了两位真正的“内行”——OpenAI 开发者体验负责人 Romain Huet 和技术专家 Aaron Friel，深入聊了聊一个最近很火的概念：Vibe Engineering（氛围工程）。
这不仅仅是一个流行词，它代表了软件开发的一种新范式：利用 AI 构建真正的生产级软件，同时让人类工程师对交付的每一行代码保持完全的掌控。
这不只是让 AI 吐出一堆代码然后祈祷它能跑通，而是把 AI 深度融入到设计、架构、调试甚至长周期的多步骤项目中。
今天，我们就来扒一扒 OpenAI 内部的工程师们究竟是怎么“生活”在未来的，以及作为普通开发者，我们可以怎么把这种工作流偷师过来。
从“Vibe Coding”到“Vibe Engineering”
你可能听说过“Vibe Coding”，通常指那种随意的、凭感觉的编程体验。但 Simon Willison 提出的“Vibe Engineering”是它的严肃版——它是 AI 驱动开发的进阶形态。
在这个形态下，大模型不再只是一个代码补全工具，它们变成了你的队友。
Romain Huet 分享了一个很有意思的观察：一年前，你会为了模型能写出一个贪吃蛇游戏或者 iPhone App demo 而兴奋。但现在，模型的能力已经进化到了可以处理长达数小时甚至数天的复杂任务。它们可以制定计划、做架构决策、编写测试，甚至自己检查自己的作业。
当 AI 学会了自我检查（Self-correction），它的表现就有了质的飞跃。这就是从“写代码”到“搞工程”的转变。
现场实战：把一个 Kotlin 项目重写为 Rust
光说不练假把式。Aaron Friel 在现场展示了一个非常硬核的 Demo，任务听起来就很让人头大：
任务：将一个名为 Bazel Diff (原版由 The Match Group 用 Kotlin 编写) 的项目，完全用 Rust 重写一遍，并命名为 BazelDifferis。
要求：必须保持 100% 的功能兼容性，并通过所有测试。
Friel 打开了一个空文件夹，里面只有一个提示词（Prompt）。但他并没有像我们平常那样简单地问一句，而是给 AI 设置了一套**“高管计划”（Exec Plan）**。
AI 是如何工作的？
- 启动看门狗（Watchdog）：Friel 启动了一个 Codex 会话，它首先创建了一个“看门狗”子代理（Sub-agent）。这个子代理的唯一任务就是时刻提醒主代理：“我们的最终目标是什么？用户的需求有哪些？”它确保了 AI 在长时间运行中不会跑偏。
- 多代理协作：紧接着，混合模型开始工作（GPT-5.1、Codex Mini 等）。有的负责去调研上游项目，有的负责研究 Bazel 8 和 9 的区别。
- 自主调研：最酷的一点是，AI 发现自己不懂某些知识时（比如 OpenAI 的训练数据里关于 Bazel 的内容不多），它会自动去 Clone 仓库，阅读文档，甚至通过运行代码来理解“真相”是什么。
Friel 提到，他在前一天晚上运行了这个任务，大概跑了 12 个小时。第二天早上，AI 不仅写完了代码，还生成了完整的测试套件、架构文档，并成功通过了 CI 检查。
这就是“长视界”（Long-horizon）任务的能力。你睡觉，它干活。
OpenAI 内部是怎么用的？（数据大揭秘）
这不仅仅是 Demo，这是 OpenAI 工程师的日常。
Romain 透露了一些内部数据：
- 92% 以上的 OpenAI 技术员工都在深度使用 Codex。
- Codex Review Codex：OpenAI 内部所有的 Pull Request (PR) 都会先经过 Codex 的审查。它真的抓出过很多人类资深工程师都忽略了的复杂 Bug，阻止了生产事故。
- 效率暴增：使用 Codex 的工程师，平均产出的 PR 数量增加了 70%。注意，这些不是为了凑数的垃圾代码，而是真正合并到线上产品的有效功能。
- 自我迭代：OpenAI 实际上是在用 Codex 来构建 Codex，这就是为什么他们的发版速度能做到几天一更。
“反向 Onboarding”：不再是你学 API，是 AI 帮你学
以前，如果你想用 Stripe 的 API，你得先啃几天文档，搞清楚每一个参数。
现在逻辑变了。由 AI 来阅读文档、理解能力（Capabilities），而你只需要作为一个协作者（Collaborator）提出需求。
Romain 把这称为**“反向 Onboarding”**。开发者从想法到原型的速度被极度压缩了。你不需要成为 API 专家就能构建能赚钱的产品。
甚至，这种赋能延伸到了非技术人员。在 OpenAI，产品经理、销售甚至设计师都在变得“技术化”。设计师可以通过 Codex 把 Figma 组件直接变成代码；销售可以问 Codex 关于底层代码逻辑的技术问题，而且 Codex 解释得往往比忙碌的工程师还有耐心且准确。
这解决了一个古老的职场矛盾：非技术团队总有十万个为什么，而工程师只想戴上耳机写代码。现在，AI 成了中间那个不知疲倦的翻译官。
这种模式下，工程师还在做什么？
如果 AI 把活都干了，我们干嘛？
Friel 讲了一个很有画面感的故事。有一次他在家陪老婆看电视，顺手让笔记本上的 Codex 跑一个复杂的重构任务。第二天早上醒来，发现它还在跑。最后，虽然只输出了 500 行代码的 Diff，但这背后经过了 200 多轮的测试、失败、修复、再测试。
这 500 行代码不仅是代码，是经过深思熟虑的高质量工程产出。
所以，现在的关键不再是“AI 帮你写了多少行代码”，而是**“产出的质量如何”**。
工程师角色的转变：
- 从写手变导演：我们开始管理全自动化流程，指挥多个 AI 代理（Agent）分头行动。
- 并行探索（Best of N）：以前我们做一个功能只能选一条路走到黑。现在，你可以让 Codex 同时尝试 4 种不同的架构方案，然后你像选秀一样，看哪一种“味道（Vibe）”最对。这让我们可以基于实证结果来做架构决策。
- 品味（Taste）和判断力：这成为了核心竞争力。AI 可以生成无数种方案，但只有深耕这一领域的人，才知道什么是“卓越”，什么是“仅仅能用”。
- 死磕文档：这听起来很反直觉，但在 AI 时代，写好清晰的文档、计划书（Plan files）比以往任何时候都重要。这不仅是给人看的，更是给 AI 队友看的“剧本”。文档写得越好，AI 跑得越稳。
如何不失去“手感”？
有人担心，过度依赖 AI 会不会让编程技能退化？
恰恰相反。在这个代码变得廉价的时代，阅读代码（Reading Code） 的能力变得前所未有的重要。你需要有能力审视 AI 的产出，判断它是否符合你的标准。
Friel 建议，保持敏锐的最好方法就是多去读 AI 写的东西，如果不理解它为什么要这么写，或者使用了什么冷门技巧，直接问它。大模型是一个永远不会嫌你问题蠢的导师。
结语：未来的样子
大家对未来都很乐观。Romain 觉得我们正在进入一个**“创意不再被技能卡脖子”**的时代。很多人的激情项目（Passion Projects）以前因为没时间、没技术而胎死腹中，现在它们都有机会变为现实。
Friel 则更接地气，他希望软件能便宜到免费，这样他就能用 Codex 帮他写个程序来管理家里的杂物，或者帮他设计下一场《龙与地下城》（Dungeons & Dragons）的战役模组。
无论你是想重写一个底层架构，还是仅仅想整理衣柜，Vibe Engineering 传达的核心理念都很清晰：
别把自己当成只会敲键盘的码农，去当那个指挥 AI 军团的将军吧。