Codex 是怎么做出来的？OpenAI 内部人说了实话

你有没有想过，软件工程师这个职业的核心价值，在过去两年里已经悄悄换了一个位置？写代码、做 code review（代码审查）、维护系统、处理依赖升级——这些事情正在被自动化掉，而且速度比大多数人预想的要快得多。OpenAI Codex 的核心负责人 Tibo Sottiaux 最近在 The Pragmatic Engineer Podcast 里做了一次深度访谈，聊了 Codex 从最初的内部工具到现在的产品全过程，也聊了 OpenAI 内部是怎么用这套东西来开发软件的。我听完整个访谈，有几个点让我反复在脑子里转，觉得值得认真拆开来说一说。

Tibo 的背景很有意思。他在比利时长大，大学读的是应用数学，还没毕业就在给银行和供应链公司做咨询，后来创办了一家专注于制药供应链优化的公司，用的是蒙特卡洛模拟（Monte Carlo simulation）和随机多阶段优化这些数学工具，不是机器学习。之后加入 Google 做 Google Maps，再到 DeepMind 做研究基础设施，2024 年加入 OpenAI，参与了最早的推理模型 o1 的发布，然后一头扎进 Codex 的建设里。我觉得他这条路挺有代表性的——不是那种一上来就做大模型的人，而是长期在"怎么让工具帮助别人提高效率"这个方向上深挖的人，这个基因后来也完整地带进了 Codex 的设计里。

Rust 和开源，这两个决定比看起来更有深意

很多人知道 Codex CLI（命令行工具）是用 Rust 写的，但很少有人认真想过这个决定背后的逻辑。Tibo 说，当时 OpenAI 内部的模型在 Rust 上的能力并不比 Python 或 TypeScript 更强，换句话说，选 Rust 不是因为模型已经很擅长 Rust 了，而是从第一原则出发做的判断：agent（智能体）需要的是健壮性、安全性和效率，而 Rust 在编译期就能做静态验证，这对 agent 来说天然是个优势。他说得很直白，"就算用 TypeScript 也能做成，但我们很可能之后就要重写一遍。"

我觉得这个判断背后有一层更重要的东西：他们很早就把 agent 本身和产品界面当成两个完全独立的东西来设计。Rust 的边界在这里不只是一个语言选择，而是一道强制隔离线，逼着团队把 agent 的核心逻辑和产品层的代码分清楚。他说，如果所有东西都写在同一个 codebase 里，"你不可避免地会把东西缠在一起，然后这就会阻止你之后的创新。"这句话我觉得是真正懂系统设计的人才会说的话。干净的边界，不是为了美观，是为了未来能够快速迭代。

开源这个决定同样有意思。Codex CLI 和 SDK 都是开源的，这在几个主要 AI 编程工具里面是少数派。Tibo 解释说，做的是一个 coding agent，那你当然要让它能指向自己、改进自己，还能吸引社区里的贡献者。他说了一句我觉得很关键的话："如果我们要成功，开源本身会改变，代码的角色也会改变，所以成为这个社区的一部分，比游离在外面更重要。"但他也没有回避开源的代价：竞争对手会在你发布之前就把你正在做的功能复制出去，各种质量参差不齐的 PR 会像浪潮一样打过来，需要额外的人力去处理。他说"有点刺痛"，但同时也说这是你签的合同的一部分。我自己觉得，这种心态其实很难得——知道代价，还是选择做，是因为觉得长期来看这是对的事情。

还有一个细节让我挺意外的：Codex 不锁定 OpenAI 的模型，你可以用其他模型提供商的模型跑 Codex。Tibo 说得很简单，"如果你要做一个优秀的 coding harness（编程框架），为什么要把它绑死在自己的模型上？这很令人失望。"他说他想靠最好的模型、最好的产品赢用户，而不是靠锁定。我觉得这个态度本身就是一种信号，说明他们对自己模型能力的判断是有底气的，而不是靠捆绑销售来维持竞争力。

Harness 永远比模型领先一步，这个关系值得认真理解

Tibo 分享了一个我之前没有想清楚过的东西：harness 在设计上是永远比当前模型的能力领先一步的。他说得很形象，harness 的作用是给模型提供"拐杖"（crutches），让它能在当前的能力水平上达到用户期待的可靠性和行为表现。比如早期模型不会主动跑测试，harness 就在 system prompt 里提醒它跑；后来模型训练好了，就不需要这个提醒了，harness 对应的那段配置就可以删掉。

他描述的这个过程有一个规律：随着模型变强，developer message（系统指令）会越来越短，harness 本身也会越来越精简，因为越来越多之前需要"手动提醒"的能力，模型自己学会了。我第一次听到这个的时候觉得有点奇怪，因为工程师花时间写的 harness 逻辑，最终目标是让自己变得不再必要。但仔细想想，这其实是一种很健康的设计方向——你不是在为了维持 harness 的存在而写代码，你是在为了让系统变得更好而写代码，即使"更好"意味着你写的这部分会被模型能力替代掉。

这里有一个对团队来说很实际的问题：怎么决定一个问题该在 harness 层解决，还是等模型来解决？Tibo 说他们会问，这个模型的改进多快能到位？一个月还是六个月？如果很快，那就不在 harness 里动，等模型。如果比较慢，才考虑先在 harness 里做一个临时方案。他还说了一句我觉得特别清醒的话："如果你正在写一个一万行的代码，专门用来绕过模型的缺陷，你可能做错了事情。"这句话背后的逻辑是，不要跟模型的局限性死磕，要学会判断什么时候该等技术本身跟上来。

Code review 没有消亡，但它真正重要的部分变了

这一段是我整个访谈里觉得最有思考深度的地方。Tibo 说他们内部开发了专门的 code review（代码审查）模型，能够做到跨多层依赖的深度验证，发现那种人类工程师可能需要好几个小时才能追踪到的逻辑错误，包括第三方依赖的文档描述和实际实现不一致导致的 bug，或者复杂的安全漏洞。他说，在代码正确性和安全性这两个维度上，模型现在已经是超人类水平了，所有 OpenAI 内部的 pull request 如果被标记了安全问题，会直接被 block 掉，全自动。

但 Tibo 同时说，code review 作为一种仪式，它真正的价值从来不只是检查代码对不对。他说 code review 也一直是信息交换的场合，是让团队成员理解"为什么做这件事"的机制，是讨论架构意图的地方。这个部分，是模型替代不了的。他提出了一个我觉得很清晰的框架：code review 真正该讨论的，是 intent（意图）——你到底想做什么，这件事值不值得做，是不是一个正确的方向。这个讨论不一定要发生在代码层面，也可以更早发生，在写代码之前就把意图谈清楚，然后代码里面发生的事情，只要满足了约定好的 invariants（不变量）和接口契约，里面具体怎么实现，就不需要那么多人工审查了。

我自己对这个判断有很深的共鸣。我见过太多 code review 变成一个形式，reviewer 因为要上线的压力，最后就是扫一眼格式和命名就过了。真正值钱的讨论，其实是在更高的层次，是关于这个东西该不该做、应该长什么形状、跟其他模块的边界在哪里。这些问题，现在有了更好的工具和更快的迭代速度，反而应该更早、更认真地去谈，而不是等到代码都写完了才在 PR 里争论。

维护成本在下降，但好的架构变得更重要了

Tibo 说了一个挺有意思的判断：maintenance（维护）本质上是你为了"保持系统正常运转"而持续支付的税。这个税本身不会消失，但它会越来越多地被自动化掉。他举了一个很具体的例子：升级第三方依赖的版本号，以前是个没人愿意干的苦差事，因为要花时间、有风险、不出彩，但实际上对系统安全很重要。现在，如果 codebase 文档写得清楚、代码结构合理，模型可以在几个小时内扫完整个库，把依赖全部升级好。以前很多团队会把这件事一拖再拖，因为不值得优先级，现在这个理由就不成立了。

他还提到了 rearchitecture（重新架构）这件事的成本变化。以前如果系统架构不对了、需要整体重构，那是一个可能耗费好几年的工程。现在这个成本正在急剧下降，因为模型可以帮你在很短的时间内完成大规模的代码重组。但他同时强调，好的抽象和清晰的边界变得比以前更重要了，不是更不重要。因为当你能以极快的速度重写一个模块的内部实现时，真正稳定的东西是模块之间的接口契约和不变量。他说的那个"box with invariants"（有不变量的盒子）的比喻我觉得很贴切：你需要约定好这个盒子对外承诺什么，只要这个承诺不变，盒子里面的实现可以随时换掉，不需要跟其他人讨论。

我从这里读到的是一个有点反直觉的结论：维护越来越便宜，不代表架构思维变得不重要，恰恰相反。当修改成本趋近于零的时候，真正决定速度的反而是你一开始有没有把系统的边界划清楚。划得清楚，任何改动都不会牵一发动全身；划得模糊，每次改动都要花大量时间搞清楚影响范围。这跟软件工程的底层原则是一脉相承的，只是现在的语境让这个原则更加突出了。

把 Codex 并入 ChatGPT，工程挑战比看起来大得多

外部用户看到的"merge（合并）"，就是 ChatGPT 界面里出现了一个 Codex 的入口，感觉只是加了一个 tab。但 Tibo 说，这个项目在工程上是两套完全不同的体系在做融合：ChatGPT 是全托管的云端系统，数据按照传统方式存储，为大规模服务做了高度优化；Codex 则是完全本地运行的 coding agent。把本地运行的 agent 能力搬到云端，同时保持一样的功能，还要做到效率足够高，高到可以包含在 ChatGPT Plus 的月度计划里——这背后是相当复杂的系统工程工作。

他还分享了一个很有趣的细节：整个 merge 过程中，Codex 本身充当了"项目记者"的角色。因为 Codex 接入了所有的 Slack 频道和文档，它把整个项目过程中团队的讨论、争论、决策都记录了下来，包括那些关于"这个功能应该叫什么名字"、"这个 toggle 应该怎么设计"的激烈讨论。Tibo 说这段记录现在在内部被叫做"toggle arc"。我听到这里有一瞬间有点不适——一个 AI 系统在你不知不觉中把所有讨论都记下来，这感觉有点像被一直监视着。但仔细想想，这可能确实会成为未来团队协作的新常态，尤其是在那些用 AI 做大量工作的团队里，知识的沉淀方式会从"人写文档"变成"agent 自动归档"。我自己还没有完全想清楚这件事的影响，但它让我意识到，AI 在团队里的角色不只是帮你写代码，也在悄悄改变信息流动和知识管理的方式。

Tibo 自己怎么用 Codex，这才是我最感兴趣的部分

Tibo 描述了他日常工作的方式，我觉得这段比任何产品介绍都更能说明问题。他说他大量使用手机端的 ChatGPT Work 模式，开会间隙就直接对着手机用语音把任务或问题发出去，然后系统会自动去查 Slack、邮件、日历，给他一个整合好的回答。他说现在他能处理的事情量比以前多得多，因为很多以前需要"找个时间专门看"的问题，现在随手就能问出去，不需要打开电脑，不需要等到有整块时间。

他还分享了一个他的工作习惯：他有很多 custom skills（自定义技能）和 custom instructions（自定义指令），让 agent 生成的报告、slide deck 和代码分析都是按照他自己的风格和需求来的。这一点让我想到，现在很多人用 AI 工具还停留在"通用提问"的阶段，但 Tibo 描述的这个阶段已经是"高度个性化的 AI 工作流"——它不是一个通用助手，而是一个非常了解你的工作方式和需求的个人 agent。这两者之间的效率差距，比大多数人想象的要大。

他还提到，他有时候在周末会用 Codex 跑一些代码探索或者产品原型，把脑子里的想法在一天之内变成一个可以给别人看、可以讨论、可以批判的东西。他说，"我只是需要把它从我的系统里排出去"——这句话让我觉得很真实。有了这套工具之后，从"脑子里有个想法"到"变成别人能反应的东西"这个过程，压缩到了以前根本不可能的速度。这对产品迭代、创意探索、技术决策的影响，是系统性的。

软件工程师的核心价值，正在往哪个方向移动

我自己听完这个访谈，最大的感受是，Tibo 描述的这些变化不是在说某个具体工具好不好用，而是在描述一种底层逻辑的转变：当实现成本趋近于零，当维护可以被自动化，当 code review 的正确性检查被模型接管，工程师真正稀缺的能力是什么？

Tibo 给出了他的答案：深度好奇心，能够快速理解一个新系统并在里面找到方向的能力，以及和你要服务的那群人保持真实连接的能力。他还加了一个我觉得非常核心的词：taste（品味，也就是判断力）。他说，"如果你说不清楚你在试图达成什么，如果你没有和某个社区的连结，如果你没有 taste，做出好东西会难得多。"

我自己的理解是，taste 在这里不是指审美，而是指一种判断力：知道什么是值得做的，知道一个东西做成什么形状是对的，知道什么时候该坚持、什么时候该等技术追上来、什么时候该放弃一个方向。这种判断力，不会被自动化掉，因为它本质上是人对目标和价值的认知，而不是执行某个步骤的能力。

还有一个细节我想专门说一下。Tibo 聊到了他年轻时候在 Vim 里熬夜写代码、喝 Coke Zero、不需要想其他事情的那段时光，说偶尔还是会自己打开编辑器写一段。我能感受到他说这段话时的那种情感，那是一种对 craft（手艺）本身的眷恋。但他也很清醒地说，如果你把代码本身当目的，你现在可能会开始感到失落；但如果你把代码当成解决问题的工具，那你现在能解决的问题比以前多太多了，这应该是让人兴奋的事情，而不是让人焦虑的事情。

我觉得这个心态上的转变，才是这个时代工程师最需要做的调整。工具在变，速度在加快，很多具体的技能会被替代掉。但"能不能想清楚要做什么，能不能感知到用户真正需要什么，能不能在一堆可能性里做出正确的判断"——这些东西，反而变得比任何时候都更值钱。