目录
- Codex、应用数学与早期职业经历 [00:00:00 - 00:10:00]
- 从 DeepMind 到 OpenAI，再到 Codex [00:10:00 - 00:20:00]
- Rust、开源与模型选择权 [00:20:00 - 00:30:00]
- 模型选择权、本地执行与 Harness 演进 [00:30:00 - 00:40:00]
- 维护自动化、工程师角色与 ChatGPT 合并 [00:40:00 - 00:50:00]
- ChatGPT Work、个人使用方式与工程师建议 [00:50:00 - 00:59:01]
Codex、应用数学与早期职业经历
Gergely Orosz：Codex 是如今最受欢迎的 AI 编程 harness 之一。但这一切到底是怎么开始的？很多听众认识今天的嘉宾 Tibo，是因为他经常给大家重置 Codex 的使用额度，而且给得相当大方。Codex 作为一款产品刚起步时，他就在团队里，并且一直带领着整个 Codex 团队。今天我们会聊聊 Codex 是怎么诞生的，为什么它用 Rust 编写并开源，以及 Codex 团队和 OpenAI 内部的代码审查正在发生怎样的变化。当维护和重构架构的成本变得极其便宜时，这意味着什么？Codex 合并进 ChatGPT 的过程是怎样的？如果你想了解 OpenAI 内部团队如何规划、审查和发布软件，这一集非常适合你。Tibo，欢迎来到播客，很高兴你能来。 [00:00:00]
Tibo Sottiaux：谢谢你邀请我。再次见到你真好，能做这次对谈很棒。上次我们是当面聊的，这次是在网上视频聊天。
Gergely Orosz：首先我想问问，你当初是怎么进入科技行业的？你最早是什么时候知道自己想和计算机打交道？
Tibo Sottiaux：这是个好问题，那是很久很久以前的事了。我父母当时决定搬出布鲁塞尔，也就是我出生的地方。他们觉得买一幢小房子、重新翻修一下挺好的，但那是在一个小村庄里，平时没什么事发生。我记得那里大概只有两百人，没多少我可以说话或交朋友的人，所以我算是被困住了。那时我还很小，大概八岁，就陷进了电脑里。那会儿算是互联网的早期，对我来说，电脑是了解各种事物的途径。后面的事情就顺理成章地发生了。某种程度上，我得感谢父母把我搬到了那么偏僻的地方。
Gergely Orosz：我别无选择，只能对电脑产生兴趣。高中毕业之后，你就接着去读大学，对吧？算是正儿八经地去学这个了。
Tibo Sottiaux：是的，我在大学学的是数学，具体来说是应用数学，而且我上大学挺早，所以毕业也比较早。有很长一段时间，我都觉得自己其实念不下去，可能会退学。读书时我搞过几家小公司，做过小型咨询业务，也给银行打过工。我对供应链和应用数学问题特别感兴趣，应该说就是把这些东西拿去卖，同时在这个过程中学到了很多。后来我进入了比利时的创业圈，干了一阵子，然后搬去伦敦工作，一开始是在谷歌，后来去了 DeepMind。
Gergely Orosz：再到现在搬到了这里，在 OpenAI 工作。这里就是加州了，我很喜欢加州的天气，我们之后可以聊聊这个。大学一毕业，你就创立了一家初创公司，对吧？你骨子里就有创业的冲动？
Tibo Sottiaux：或者说，是那种企业家的冲动。那家初创公司主要做医药供应链，关注临床试验中的供应链：优化并决定要不要生产更多药品、应该送到哪里、应该分发到哪里，以及怎样避免浪费，从而让临床试验更有效率。当时用的是传统的、非机器学习的方法，更偏向组合优化和蒙特卡洛模拟。说白了，这其实是随机多阶段优化问题。我们还把它应用到了钢铁行业和欧洲电网。只要长得像优化问题的东西，我们差不多都会感兴趣。这家公司直到今天都还在。
Gergely Orosz：我觉得他们依然在做一些很有意思的工作。随着现代 AI 的发展，肯定发生了很大变化。但挺有意思的是，你刚才好像随口说，那会儿不是机器学习，而是传统方法；接着你就聊到了蒙特卡洛模拟、优化和这些算法。我的感觉是，你当时算是钻得很深：这里有一个问题领域，我怎么能用数学，以及我学过或没学过的东西，一直往里面钻。我理解得对吗？
Tibo Sottiaux：对，这就是为什么我当时对应用数学那么着迷。理论数学、理论科学或物理学的研究，是因为有些东西有待发现，其中有一种美感，都是关于规律和推进领域前沿的，但你未必总是知道该怎么应用它。然后就有了现实世界：到处都是很有意思的问题。我当时特别想看看，怎样才能让这个世界变得更好，怎样用复杂的数学去优化我周围的世界。
Gergely Orosz：那家初创公司背后的逻辑，很大程度上就是这个。创业之后，你去了谷歌，一开始是在伦敦谷歌，那是在 2015 年。我记得那时谷歌的竞争非常激烈，从行业地位或声望来说，可能跟今天的 OpenAI 一样难进。你最初做的是什么？后来又为什么离开那个明显很喜欢、也很有意思的领域，比如优化物流？
Tibo Sottiaux：其实我一开始做的不是谷歌地图，而是一个旨在提高网络速度、让网站变得更快的项目，尤其是在移动端。当时谷歌看到了从桌面端到移动端的转变，越来越多流量流向手机，所以想走在前面，就资助了一些举措和项目。我负责其中一个。这非常好玩，因为是个小团队，实际上在广告业务部门内部，初衷是弥补流量转向移动端所造成的广告收入损失。我做了差不多两年，后来这个项目被取消了。虽然那是我解决硬核技术挑战时玩得最开心的一次，但我也学到了很多教训：没有找到产品与市场的契合点，没有找对用户，也没有建立好的反馈闭环。还有，当产品经理说项目进展顺利时，别轻信，因为实际上根本就不一定顺利。有一天，一位副总裁从加州飞过来，说：“对，我们要取消这个项目。很遗憾，你们只有几百个用户，这显然达不到谷歌的规模。”这简直难以置信，大家当时都很惊讶。 我从中吸取、并一直带在身边的教训是：永远要去质疑，永远要深入思考你正在产生的影响，以及你参与的整个项目本身的重要性。后来我转去了谷歌地图。谷歌地图超级有意思，我做的是评价系统。大约一年后，我实在没办法忽视 DeepMind。那真是一个特别的地方，总部在伦敦，当时那里正在发生很多很棒的事情。那是非常早期的时候，私下里已经在传 AlphaGo 之类的事情了。他们看起来在做非凡的事情，真正去攻克你能碰到的最难的问题。凭我的背景，我显然被吸引过去了，于是去了那里。我当时负责很多研究基础设施和研究工具的开发，这是我坚持了将近十年的一个主题，也非常符合我做事情的方式：怎样打造出帮助别人提高效率、给他们带来巨大实用价值的工具和产品。起初我是为科研做这些，后来随着时间推移，我思考问题的方式越来越通用、越来越宏观。
Gergely Orosz：最后就走到了你现在的位置。你最近在 X 上也分享过一个有趣的故事，讲的是你曾参与过一个团队，做出了谷歌内部的一个机器人，可以说和 ChatGPT 很像，但比 ChatGPT 早了一年。你能讲讲那个吗？
Tibo Sottiaux：这是个新故事，我之前没听过。那是 DeepMind 内部做的事情。当时其实有好几个方向在做，Google Brain 也是独立的团队。他们在大语言模型上也有自己的尝试，但这绝对是大家都在探索的方向，并不是 DeepMind 的主要发力点。DeepMind 当时更忙于思考重大挑战、游戏以及强化学习，不是语言层面的那种强化学习。当时有一个小组在全力推进大语言模型，思考着：如果海量文本、语料库就是一切呢？如果把语言推到极致，一味把语言模型的规模做大，是否足以实现通用人工智能？这在当时是一个热门争论。于是有个小组决定全力推进这个方向，事情就很自然地发生了。当时我正和其他人一起为研究做工具，大家显然会想：我们能用这个模型做什么？怎么把它呈现给研究员，让他们调试输入和输出？最终做出来的差不多就是一个对话系统，所以我们在内部把它做了出来。 我们玩得很开心。一开始那些模型有点荒唐，不太连贯，也没多大用处，但拿来鼓捣真的很有意思。它像野火一样传开了，DeepMind 内部几乎每个人都在分享零碎的对话记录，感觉它已经不仅仅是一个研究项目，或者一个给研究员使用的项目了。后来随着时间推移，大家产生了把它作为外部产品发布的想法。但 DeepMind 根本不是为此设计的。在谷歌发布产品有一套既定的合规流程和运转机制，告诉你该怎么做；这是一整套官方认可的生产上线流程，多年来显然经过了高度优化，能把事情做好。但作为一种环境，要真正去创新也非常困难。
Gergely Orosz：那我本来想问，是什么让你开始往外看，甚至可能考虑去 OpenAI？换作是我站在你的角度，如果是在 2023 年或 2024 年，你在谷歌内部发着很棒的论文，做着非常出色、超级好玩的研究，不断突破前人的极限，而且是在一家你已经转过岗、待得很舒服的公司里，是什么让你还在往外探索？
Tibo Sottiaux：我想看看还有什么别的可能。当时我确实待得很舒服，那是个好地方，但我真的很想去结识优秀的人，也想加入一个我真正认同的使命。我觉得那里的人对这个使命很真诚，非常在乎以一种积极而直接的方式去影响世界。
从 DeepMind 到 OpenAI，再到 Codex
Tibo Sottiaux：我想加入的是一个把所有因素放在一起考虑的团队：研究和产品真正协同设计。OpenAI 当时势头正猛，ChatGPT 正在起飞。我见到了几个 OpenAI 的人，然后整个人都愣住了：等等，什么？你们做 ChatGPT 的只有 20 个人？这也太少了吧。在里面工作一定有极大的自主权。你们怎么能只靠 20 个工程师维持这样一个规模的产品，同时保持这种自主权？随着我不断深入了解，我发现这真是一群了不起的人，使命很棒，极有才华，也极有干劲，我完全被吸引住了。于是我加入了，立刻投入到早期推理模型的研发里。很典型的 OpenAI 风格，我刚加入就看到他们在做这个：要发布推理模型了，这算是一种新范式。然后大家立刻全速冲刺，差不多一个月后，公司就发布了 o1 Preview。能参与其中真的很让人兴奋。 我想加入的是一个跑得快、在乎影响力、能跟世界同频，而且真正懂得倾听的地方。对我来说，做 Codex 产品时，我也一直带着这种想法：要建立一个社区，倾听社区的声音，专注于高频反馈循环，然后做一个自己真正想投入、也在乎它能给世界带来多大价值的东西。
Gergely Orosz：你很快就开始做 Codex 了。你是 2024 年加入的，能带我们回顾一下吗？你加入时，内部对于 AI、语言模型和代码的结合是怎么看的？我知道当时有 ASWE 项目，我们在 The Pragmatic Engineer 做的深度报道里也聊过，也就是 Autonomous Software Engineer。内部当时是这么称呼的。这个项目后来已经没有了，现在就是 Codex。 [00:11:27]
Tibo Sottiaux：我加入时是开始为研究做基础设施。之前我做的大多是大规模数据存储、分析，以及用来理解模型训练过程的工具。这些年我做过很多不同的事，但核心始终是为别人做东西，帮他们提速，认真把这件事从根本上做好，再通过工具和基础设施，让新的可能性成为现实。所以我加入 OpenAI 时也带着同样的想法。到了 o1 Preview 和后来的一些模型，大家就看得很清楚了：我们必须用模型本身来帮我们提速。我当时特别着迷于这个想法，局限究竟在哪里？我们要怎么把这些模型用到研究本身上？于是我和做研究的其他同事聚到一起，开始训练模型，也开始做一些小型的 agent，那些其实就是 Codex 的前身。 当时我们在训练内部模型，让它精通 OpenAI 的 Python 代码库，在架构和代码风格上都有很好的品位。当时只支持 Python。我们的想法是用它来快速搭建基础设施，同时帮助研究人员更快地写代码，这样我们就能跑得更快。随着时间推移，当你不断推进这个想法、把它简化到核心，就会发现自己能非常快地取得很大进展，也能学得非常快。Greg 和 Sam 两个人给了极大的支持，而且 Greg 非常坚持：我们不能只专注于自己，也要专注于造福世界。他鼓励我们不要只把它当成给 OpenAI 内部使用的工具，还要考虑真正把它做成一个产品。就在这个时候，我们把这项研究工作和 ASWE 项目合并了，开始合力做一个东西，紧接着就发起了一次冲刺。， 那就是我们最先发布的云端 Codex。它其实并没有真正找到产品与市场的契合点，因为使用摩擦稍微有点太高了。我们还发布了 Codex CLI，之后继续推进，但核心想法始终是：到底怎么让模型在这里真正帮上忙？
Gergely Orosz：你提到，最开始是训练模型学习 Python 代码，来帮助自己更好地搭建基础设施。但后来你们做了一个很有意思的决定：Codex 用 Rust 编写，而当时模型并没有针对 Rust 的分布进行训练，对吧？它在 Rust 上的表现不如在 Python 或 TypeScript 上那么好。你们为什么会做这样的决定？是觉得模型迟早会赶上来，还是觉得性能更重要？这非常反直觉，大部分其他编程 harness 都不是用 Rust 写的，而是选择分布内的 TypeScript、Python 或其他语言。你们是怎么权衡的？
Rust、开源与模型选择权
Tibo Sottiaux：对，从第一性原理出发，我们很早就把产品界面和 agent 当作两码事来考虑。所以，把 agent 的核心做得足够健壮、足够安全，并且为了效率和规模化去做工程设计，是非常重要的。这些年经历过不少项目，从一开始觉得挺好玩，到后来必须把它扩展到最大数据中心的规模。只要不过度牺牲研发速度，早期的决定到头来往往相当关键，这就是一种权衡。不过我们当时有产出极高、非常优秀的 Rust 开发者，我们内部的模型写 Rust 并不差；而且在编译期还能拿到很多校验，比如静态验证之类的。所有这些特性对 agent 来说也非常棒。事实证明，只要我们愿意投入精力，Rust 作为一门语言很快就能变得非常适合 agent。主要关注点是正确性，同时也关注效率。 [00:14:36]
Gergely Orosz：也就是说，在你们看来，提前去想这东西未来要走到哪一步是值得的，语言选择就是一个例子。显然，有了 agent 之后重写代码比过去容易得多，但如果能搭好合适的脚手架，为系统打好基础，还是能省去返工，对吧？
Tibo Sottiaux：我觉得就算用 TypeScript，或者哪怕用 Python 来写，我们也能做成，完全没问题，无非是后面某个节点再重写。但把 agent 本身和产品清晰地隔离开，让它脱离产品也能独立存在，是一个非常重要的原则。如果把所有东西都写在同一个代码库、用同一种语言，难免会写得粗糙一点，把东西缠得过深，后面就会阻碍进一步的创新。
Gergely Orosz：所以这一点非常关键。某种意义上，Rust 设下的这道边界在这方面很有帮助。你们做的另一个很有意思的决定，也是各大顶尖实验室里少见的，就是把它做成开源。CLI 是开源的，SDK 和应用服务器也全都是开源的。你们是什么时候、为什么做出这个决定的？这并不是理所当然的，尤其过去大家还会开玩笑说 OpenAI 很多东西都闭源，但这次正好相反；一些竞争对手发布的是闭源 harness。你们为什么想开源？
Tibo Sottiaux：把代码开源这件事本身就感觉非常酷。从根本上说，你做的是一个写代码的 agent。我们当时就在想，既然有了这东西，显然会拿它来写它自己，也许还能借此聚拢一个贡献者社区，大家用它来改进它，我们也能从中获益良多。另外我们当时很明确地感觉到，如果真能做成功，开源本身会改变代码的作用，所以身处这个社区之中显得很重要，而不是跟它脱节。如果你不亲身体验那些问题，就很难真正去解决它们。 还有一点，虽然现在看也还算早期，但当时是非常早期，我们感觉已经有了一些把事情做好的想法。我们把这些想法和训练、研究一起协同设计，核心就是以最灵活、最好的方式释放模型能力。但我们并没有掌握所有答案，也不敢很坦诚地告诉大家一个好的 harness 应该长什么样。这就是我们的思路：外面的世界广阔得很，有很多聪明绝顶的人，我们也会从其他开源项目中获得启发。
Gergely Orosz：那就给大家一个公平竞争的环境，在这个阶段多多鼓励动手折腾和探索。现在过去了一年，或者一年半，在当下的 AI 时间线上已经是一段很长的时间了。回头看或总结一下经验，你看到了哪些好处？开源给工程团队带来了哪些收益？坦白讲，开源又有哪些比较难受的地方？肯定会有代价，我想听听你对这两方面的实在看法。
Tibo Sottiaux：确实有坏处，这是要付出代价的。好处在于，公开构建的感觉太棒了，代码库比较小也挺好。比如我们每招一个人加入 Codex 团队，他们之前都看过这个仓库、翻过 PR，入职培训差不多就直接完成了。入职的时候，直接用 Codex 帮你一起看代码库、问点问题就行，能马上上手干活。我们也收到了很多不错的贡献，虽然也有一大堆乱七八糟的东西涌进来。 对我来说，能成为社区的一部分并直接做贡献，能带来很多活力。不仅仅是嘴上说在乎社区，而是真正在做，你能看得出我们花精力做的事情，本来可以不这么做的。坏处是它跟我们其余的代码是分开的，所以有时我们得人为划清界限，跨多个仓库干活。当我们在做某个特别让人兴奋的东西，而且公开构建时，有时会发现别人在我们来得及发布之前就抄走了它，这多少有点让人难过，但这也是其中的一部分，是规则的一部分。既然你在公开构建，就相当于签下了契约，别人可以抄；我们的开源许可也非常宽松。 第三点就是，和大家一样，我们也被各种乱七八糟的贡献淹没了，必须去应付这种额外负担。
模型选择权、本地执行与 Harness 演进
Gergely Orosz：但这也促使我们去想办法解决。我觉得这挺好的。除了开源之外，Codex 还有一点让我挺惊讶：它并没有和 OpenAI 的模型绑定，你可以在 Codex 里用其他模型。换作从厂商的角度来看，这可能并不显而易见，因为我看到的其他厂商在做 CLI 时，基本都是让你用他们自家的模型。是什么让你决定放得这么开，允许在你们的 harness 上使用其他模型？ [00:20:05]
Tibo Sottiaux：如果你是这个社区的一员，而且在做一个优秀的编程 harness，把它和自家的模型绑死，感觉挺违和的。为什么要这么做？那样会让人失望，感觉不太对。大体上，我尽量做的决定都是自己能解释得通、觉得正确的决定，这和一开始选择开源是同一个道理。任何人都可以很轻松地 fork 一份，然后加上对其他模型的支持；但那样就等于鼓励大家去使用那个 fork。你之所以 fork，仅仅是因为想改几行代码来支持另一个模型提供商，这感觉太蠢了，为什么不从一开始就支持呢？ 另一点是，能够提供这种选择权，对我们自己也大有好处。比如今天你很喜欢用 OpenAI 的模型，用起来效率极高，但明天出了个新模型，你想试一试，为什么要逼着你为了试一个新模型，就彻底换掉整套配置？我们也能从后续得到的反馈中受益：你可能喜欢那个模型的某一点，或者发现它其实表现不好。善待我们的用户和社区，在当下就是正确的做法，而且我们自己也会去尝试其他模型。我们用同一个 harness 去试，这完全挺好的。这种选择权对和我们合作的公司来说也非常重要，所以这也是我们全力投入的方向。
Gergely Orosz：任何一家认真的公司都会希望有选择权，希望用能给你这种选择权的工具。但我挺欣赏这一点，因为在我看来这很坦诚。它逼着整家公司在各个层面争第一：在模型层、harness 层，和开源竞争，也和可选模型竞争。它不会让你舒舒服服地觉得，我们搞定了，现在可以先歇一会儿了。
Tibo Sottiaux：对，我希望我们靠最好的模型、最高效的模型和最好的产品去赢得用户。如果我们把这些都做好了，大家都会很开心。如果我们是因为某一个单独的捆绑点去逼着你用这个产品，我也不觉得这能吸引到最优秀的人来做这个产品。我们在这里是在尽全力做出最好的成果，非常在乎使用体验；无论背后驱动它的是什么模型，用起来都应该让人觉得愉悦。
Gergely Orosz：我喜欢靠真本事去赢，而不是靠绑定去赢。作为工程师、作为工具的使用者，我每次看到竞争都觉得非常棒。比如我记得当年微软和 JetBrains 之间的 IDE 大战，还有各大云厂商在各种功能上互相厮杀。现在有了各种 harness 和模型，作为用户这很棒，因为我们有了更多选择，它们的发展速度也更快。我想我们的声音能被更好地听到。说到 harness，你能跟我讲讲它现在是怎么运作的吗？比如当我启动一个 Codex 任务时，它总是在我的电脑上跑吗？它会选择云端吗？它会用沙盒吗？作为工程师，我该怎么控制或了解这些，或者我到底需要了解多少？
Tibo Sottiaux：默认情况下，它是在沙盒里运行的。凡是有命令需要在沙盒外、以额外权限运行，它都会向你这个用户请求许可。但所有操作、每个工具的执行，默认都在沙盒内进行，而且完全在你的本地电脑上运行。这种情况已经持续了一年多，但现在也在不断演进和转变。比如你可以选择在云端运行，它就会跑在一个托管虚拟机里，也就是你通过 ChatGPT Work 获得的那种虚拟机。你可以去检查它，不过它运行在一个安全的容器里。如果所有东西都在那个虚拟机里运行，就不在你的电脑上跑了；你的电脑上唯一发生的，只有你的输入和输出传回去。这样显然对 CPU 和电脑友好得多，而且你能扩展的规模也大得多。未来使用云端机器会顺畅得多。
Gergely Orosz：但本地运行有一个好处，也是我喜欢在本地跑的原因。当然这也很痛苦，因为如果我在干活，比如开了好几个 agent，它就会猛吃 CPU；如果我想合上笔记本，又不能就那么半开着放在那里。之前我在一家 AI 公司的办公室里，笔记本就那么半开着，他们问：“你在跑 agent 吗？”我说：“对，我正跑着一个。”我之所以在本地跑，是因为我有本地工具、本地的 Postgres 数据库和相应配置。你们怎么考虑或尝试解决这些配置？云端固然很棒，但它没有这套配置，或者说配置起来实在太麻烦了。我有点想起我们在 AI 爆发前聊过的话题：2022、2023 年那时候的云端开发环境很火，后来我们聊 AI 更多了。但我觉得，在大型科技公司之外，云端开发环境一直没有普及开。
Tibo Sottiaux：因为前期成本非常高，后面还要付维护成本。作为独立开发者或小团队，你根本享受不到它的好处。以我们现在 agent 的能力水平，配置几乎可以说是零成本了。搭建成本和维护成本摆在那里，但如果你的 agent 有能力做，它直接帮你做就好了。比如你说：“我有本地的 SQLite，或者有一个本地服务，以及 MCP 之类的。”在云端 DevBox 上配置出一模一样的环境，并保持同步，到底能有多难？要是模型直接替你搞定，可能就没那么难了。所以我觉得我们会看到完全由云端编排的机器重新兴起，把你从笔记本电脑前解放出来。我们在 ChatGPT Work 上看到非常成功的一点，就是它在手机上随时都能用。 我开启一天的方式，就是在咖啡馆旁边对着它口述一堆任务，它就直接去办了。它能访问我的日历、邮件和 Slack，我可以一边走动一边把事情办好，不用走到哪儿都背着笔记本。这种感觉太棒了。我觉得 Codex Remote 也是一样的道理：虽然执行依然在你的笔记本上跑，但如果你不用一直开着笔记本，那就太好了。
Gergely Orosz：过去你们是怎么改进 Codex 的？我记得我最早用 Codex 时，那是早期版本之一。你可以跟它对话，它会做一些事情；但比如我说“改一下这个”，它改是改了，可我明明有单元测试，它却不去跑。过了几个月，它就开始自动跑测试了。这些改动，是你们改进了运行脚本和给它的指令吗？我不确定具体该怎么称呼那个引导脚本，还是说你们在改进模型。作为开发者，我该怎么理解你们如何在 harness 和模型之间，让每个版本变得更好？
Tibo Sottiaux：这是个好问题。某种程度上说，harness 总是比模型稍微领先一点。模型本身具备某些能力，但你会给它架上几根拐杖，好让它真正把事情做成，达到一定的可靠度，而且效率更高，表现也符合用户预期。这就是 harness 的作用，比如提供护栏保障安全，让它更高效、更听指挥、更可控。 另外，harness 通常还负责所谓的 developer message，它会在每一轮对话开始时注入上下文，目的是影响 agent 在这一轮里的行为。你看到的很多效果，其实是 harness 和模型共同作用的结果。一开始你可能会觉得它不跑测试，所以得提醒它去跑；后来我们训练出了更好的模型，它能更好地领会你提出某个要求时真正想要什么，于是你就不用再提醒它了。随着时间推移，我们看到的是系统里的 developer message 在变小，harness 也在变薄。
Gergely Orosz：在 Codex 团队内部，你们有具体的目标吗？你们会说，Codex 作为一个结合了 harness 和模型的整体，在这方面不太行，或者老是犯低级错误，然后推进下一个版本吗？作为开发者，我有点想不明白：模型对我来说像魔法一样的东西，它自己会变强，我相信你们肯定有反馈渠道，但你们手里还有 harness，也就是你们在做的那些工具。这大概是团队主要负责的部分。你们到底是怎么定目标的？传统软件里，你会说要建一个功能，然后把它做出来，因为你知道该怎么做；但这种开发流程在我看来模糊得多。
Tibo Sottiaux：所以我们大多数东西都是协同设计的，这是研究团队和工程团队合作的过程。工程团队主要在做核心的 agent harness，这总是一个权衡问题：我们现在看到自己在这一块很擅长，但在那一块还不太行；我们很想做另一件事，因为那会是个很酷的产品功能。我们总会琢磨，这应该是 harness 层的改动，还是模型层的改动？如果是模型层的改动，我们多快能拿到，一个月、三个月还是六个月？ 我们就是这么一步步梳理的，接着看能多快直接在模型里解决，具体在哪个训练阶段解决。我们可能决定根本不用在 harness 里做任何事情，直接等模型来搞定。全流程都是 agent：我们用 agent 来分析大量反馈，梳理出主题，帮助我们展开讨论并敲定优先级。我们在整个编程领域做分析，也在财务、公关、市场等其他领域做分析，也就是如今用户使用这些 agent 的所有场景；这些领域下面还有子分类。我们大致能知道自己的表现如何，然后不断推进前沿。有意思的是，随着预训练模型变好、整体模型变好，整个表现都会水涨船高。
Gergely Orosz：但有时我们也会对某些方面多倾注一点精力。你刚才提到全流程用 agent 做分析，我们能不能聊聊 Codex 的软件开发生命周期？每当新工程师加入任何团队时，都会面临“这里平时是怎么做事的”。在 AI 出现之前，如果你加入 Uber 或谷歌这样的公司，他们会告诉你：先有一个想法，或者产品经理有个想法，接着做计划、碰头开会、做估算、拆解任务、写代码、做测试、做代码审查、发布、切 feature flag，然后轮流值班。以前都是这么过来的。 当有人加入 Codex 团队时，他们显然一直在给开源部分做贡献。但如果他们是个彻头彻尾的新人，你会对他们说什么？这里平时是怎么做事的？
Tibo Sottiaux：听得最多的一句话就是：“你问过 Codex 吗？”在 OpenAI，Codex 默认直接接入了所有东西：它能访问 Slack、所有文档和所有代码。刚入职的新人往往还是会感到惊讶，你基本什么都能问它，而且它经常能给出相当不错的回答。想了解一个项目的进展、谁在负责什么，或者当初为什么做某个决定，最简单的方式就是去问，因为 Codex 对内部的一切都一清二楚，所以直接用起来就行。 正因为这样，我们很多工作都是在公开频道里进行的，公开文档的范围也给得很宽，好让大家看到这些信息，也方便 agent 去翻阅、推理和分析。另外我们还有几样对团队生产力和协作特别有帮助的东西，目前还没发布，但一部分会在 DevDay，也就是开发者日上亮相。所有这些能让你心里很有底，跟团队步调一致，快速了解现状，并且自己动手做出东西来。普遍的建议就是，多为用户着想，注重产品一致性，关注模型本身以及模型的发展方向。要是为了绕过模型缺陷，硬写出一万行代码来当拐杖，那方向大概就走偏了。我们确实有一套原则。
Gergely Orosz：但到了现在，其实更像是团队的文化和风气。新人加入时，就是靠团队其他人手把手带，一代代传下去。如果我有个想法，觉得挺不错，我先跟 Codex 聊聊，也可能跟几个同事聊聊。比如我打算做个很酷的新功能，作为对 Codex 的第一笔或第一项大贡献，接下来该怎么做？显然我会用 Codex 把代码写出来，也肯定会做测试，确保它能跑通。从那之后流程是什么样的？你们还有代码审查或 AI 代码审查的概念吗？还有校验、上线验证、分阶段灰度发布的流程吗？因为 Codex 本身就面向几百万人，刚刚超过 2000 万活跃用户；而 ChatGPT 面向的人群规模还要大得多。
Tibo Sottiaux：但不管是发布到 Codex 还是 ChatGPT，流程出奇地相似。哪怕 ChatGPT 面向的是 10 亿活跃用户，而且还在增长，你提一个 PR、改好代码，第二天甚至当天就能上线，直接发给 10 亿用户，而且不会出问题。我们非常注重培养主人翁意识和责任心，大家得到的授权非常充分，可以做改动，哪怕是大改动。大家普遍需要拿出证据，表明它会受欢迎、值得加入，而且长期维护是划算的。 不过现在维护成本确实大幅降下来了，所以我们的想法和两三年前相比稍微有些不一样。另外，我们尽可能做到了自动化，很多像代码审查、部署、拦截回归这类流程基本全都自动化了。这样一来，你就能把精力放在想法本身，看它怎么帮到用户，关心整体一致性，提升 agent 的整体能力，把东西做好。我们有一份长长的清单，上面全是想做但还没顾上做的事情。 另外还有个北极星方向：一个让人愉悦、用起来简单的个人 通用人工智能。它知道所有该知道的关于你的事情，能访问合适的资源，有时能代表你做一些带风险的决定，但你会收到通知，可以去确认。作为用户，你对它一清二楚，它也清楚你的日程和目标，能主动帮你做事，而且用起来应该极其自然。它应该是你用自然语言、用声音就能控制的；如果它有摄像头画面，也许还能读懂你的情绪。它应该变成世界上最自然不过的东西，不应该是一个带着十个不同按钮和配置项的东西。通用人工智能 用起来就该简单。你刚才简单提到了 review。
Gergely Orosz：也就是 code review，我想回过头再聊聊这个。你以前在谷歌做过谷歌地图，那可是有几亿人使用的产品，而谷歌向来以极其严格的代码审查文化闻名。我想他们应该有两层代码审查，其中一层是语言层面的正确性审查；长期以来，他们在全行业都做到了极致，也一直坚信这套方法管用。你觉得这一块正在发生怎样的变化，特别是人工 review 的部分？在很长一段时间里，直到一两年前，我都会说代码审查有很多好处：分享知识，多一双眼睛把关，消除“巴士系数”，因为现在有别人能看懂，那个人不在时也能顶上；大家在 review 时会探讨架构，而不只是代码。 但现在代码量大得多了，代码审查的价值在哪里？在什么情况下，在你们团队里，哪些地方依然需要人类或开发者参与，哪些地方无所谓、可以直接交给 agent 去做？你觉得行不行？代码审查扮演的角色确实在变。
Tibo Sottiaux：我早期在 Codex 做的一个项目，就是和研究团队合作开发一个代码审查模型，让它能发现逻辑和推理错误，达到人类可能需要花上好几个小时才能抓出同等水平错误的程度。因为这需要顺着依赖关系深挖三四层，搞清楚是不是文档本身写错了，或者第三方依赖的实现其实和你的预期不一样，导致某个假设根本不成立；除非你是那个领域的专家，否则根本不会知道，于是就有了 bug。 所以我们开发了这些代码审查模型，后来也发布了。现在通过深度验证发现这些错误的能力，已经直接融入主线模型里了。我们做跑分评测时，它们在代码审查上的表现简直超乎常人，这不仅体现在正确性上，安全方面也是如此。比如它们能对极其复杂的情况做推理分析，然后指出这里有一个严重的安全漏洞。现在 OpenAI 所有的 PR 都必须过这一关，只要标记出安全问题，我们就会直接拦截，不让合并；这全都是自动化的。， 现在代码审查的核心一直都是确保正确性，确保东西能跑通，但它也有点像一个小小的仪式，用来交换信息、拉起大家的认知、鼓励讨论。这种讨论理想情况下本来应该在之前就发生，但有时候大家只有看到具体代码才会去聊，因为一旦合进去，它就真跑在生产环境里、真正干活了，然后你就得去维护它。所以它也有这种偏社交的一面。我觉得这一切都在变：正确性和安全性会被自动化，而围绕 PR 的讨论其实是在探讨背后的意图，就是你到底想做什么、尝试做这件事是否正确。我觉得这种讨论完全可以在 PR 之外进行。
Gergely Orosz：没必要非得围着代码聊，所以也许这能帮大家想清楚，到底哪些讨论该放在哪里，而不是像以前那样，可能只是因为我们手头没有现在这样的工具。这会改变很多事情。
Tibo Sottiaux：以前它像是一个强制机制，因为在你合进去、变成生产代码之前，你必须，或者最好，有这么一次讨论。但我认为还有其他方式来进行这些讨论，一起做设计，确保意图是对的。
Gergely Orosz：到那个时候，代码本身就没那么重要了。这挺有意思，因为回想我经历过的所有 code review，有些记忆很美好，大家聊得很透，或者我学到了特别有意思的东西；但说实话，很多时候它真的烦透了。比如我正忙着做自己的东西，收到一条消息：“嘿，能帮我 review 一下代码吗？”我说：“不行，我现在正忙。”对方说：“不行啊，我真得靠这个解卡。”然后你就得切换上下文。所以这事一直都有好有坏，只不过现在这些利弊在发生转移。我猜好的一面是，作为工程师，你可能不用再把精力放在那些本来就不需要你操心的基础事情上了。
维护自动化、工程师角色与 ChatGPT 合并
Gergely Orosz：它能省时间，而且慢慢我们会看到，大家只要对这个黑盒子以及它应该做什么的整体契约达成一致，然后里面的东西只要在资源占用、数据访问和安全性等方面有严格保障，盒子里面怎么弄、写成什么样都行。 [00:39:59]
Tibo Sottiaux：你其实没必要太关心里面的实现。大家真正需要达成共识的，不就是这个盒子到底要干什么、必须满足哪些约束吗？我觉得这时候就很值得好好聊一聊，可能还可以在你最喜欢的 agent 辅助下聊。一旦定好了这些，有了这个理解，在盒子里改动任何东西就都不需要这种讨论了。
Gergely Orosz：这真的能帮你省下精力。维护成本降下来后，在谷歌、Uber 甚至初创公司里，只要我们做东西，维护永远都是一个大热点。开发是有趣的部分，维护才是痛苦的部分；以前我们会因此意识到，好吧，这东西根本不值得做，诸如此类的。随着 Codex 和 OpenAI 内部的维护变得更便宜，你觉得它在改变什么？比如你想做什么、目标是什么，或者自研工具这些方面。维护其实就像为了让东西一直运行，而长期支付的一种税；它一直都有必要。
Tibo Sottiaux：以后也一直有必要，但我觉得发生变化的地方在于，其中很大一部分将被自动化。比如你用了某个第三方依赖，需要升级版本号；如果更新日志写得好、代码文档齐全、模型能把逻辑理清楚，你就可以把它全自动化。它能在两小时内刷刷把你的代码库全改完。以前你可能会往后拖，因为这不是什么好玩的差事，但对业务和项目来说又特别重要，尤其涉及安全漏洞时，你想保持更新，把这些补丁都打上。我觉得这以后会全自动化，所以维护的很大一部分差不多就成了免费附赠的。 想想以前也很有意思。以前当你想彻底重做架构，可能是因为你想为新的权衡取舍腾出空间，对业务负载有了新的理解，或者想塞进一个新功能，突然意识到现在的系统限制太大了，必须彻底重新做架构。那是一项成本非常高的工程，有时得花上好几年。我认为现在这也大大加快了，所以犯错的成本是在下降的。但与此同时，软件工程那些经典的老规矩，比如做好抽象，真的非常有帮助。回到刚才说的带有约束的盒子，如果把边界画对，就能在盒子里更快地改东西。
Gergely Orosz：而且不影响其余的服务或基础设施。我认为这很重要，设计时就要考虑快速迭代和变更。我记得和 Peter Steinberger 聊过，那还是在他加入 OpenAI 之前，我们聊到 OpenClaw 以及他是怎么想的。他跟我说，其实不读代码，但一直在思考；我能看出来，架构全在他脑子里。他讲过怎么频繁重构架构，怎么把它做成模块化，怎么让 100 个贡献者各做各的而互不冲突。 所以我听懂你的意思了：这种用心、规划和结构设计，可能变得重要得多。过去往往是架构师、staff 工程师或资深员工在做这些事，周围其他工程师只是在做较小的零碎部分。但听起来，现在所有工程师在写软件时都得有这个意识，而且得提前规划好。
Tibo Sottiaux：对，而且 GPT 模型在这方面也越来越强了。思考长期维护和优秀架构，是很自然的下一步。这不光是代码质量问题，比如文件里的代码干不干净，而是架构到底对不对，能不能随时间推移减少维护负担，为未来的产品或功能扩展、变更留下空间，本质上是长期工程维度的考量。模型现在也开始有能力把这些想得很周全。 我觉得很有意思的一点是，我们现在做的软件走完整个生命周期的速度快太多了。以前你做个扩展，一开始可能就你自己加上两三个工程师的小团队，然后慢慢招人；过了一年，如果非常成功，可能会有 50 个或 100 个工程师铺在上面。你有时间预见这一步，有时间看到新人入职，去想文档怎么写，这些都能从容准备。但现在就像突然爆发一样。
Gergely Orosz：一下子就有 100 个 agent 在给这套东西做贡献，这种事一个周末就能发生，所以推进速度比以前快太多了。你和 OpenAI 的同事是怎么面对这个的？心里不会受到冲击吗？你在这一行已经干了很久，我们过去习惯了一种节奏，现在明显快得多。你该怎么接受这一点？一年前还在做的事，现在可能不用做了，因为模型已经很擅长了。软件里有些事情你本来非常擅长，但现在可以直接交给 agent；如果是重构或架构设计，模型也变得特别擅长，那不会有点刺痛吗？我们聊过功能被开源替代会让人难受，但这像是自己本来很擅长的东西也被替代了。 然后你会觉得：“好吧，该死，我挺高兴的，但也觉得要是这事由我来做该多好。”我觉得这里面有一种手艺人的情结。
Tibo Sottiaux：我偶尔还是会打开编辑器写代码，那种感觉很好。我也有很多美好的回忆，比如深夜坐在那里用 Vim 不停地敲，疯狂输出，喝着零度可乐，除了眼前的难题什么都不用想。但我真觉得，关键还是在于进入心流和解决问题。我发现这里的同事，以及我聊过的所有人，适应得都非常快。如果你换个心态，把代码看作解决问题的工具，就能解决多得多的问题。 以前你想做个基准测试，又不太确定最终结果会怎样；现在可以随时去做，花不到 30 秒在后台跑起来，拿到靠谱的数据，做出更好的权衡。只要你真正看中结果和系统的良好运转，这会让你，也应该让你成为更好的工程师。它能让我们在 OpenAI 把推理运行得更高效，让我们拿到更多有效算力，部署给全世界。大家都在专注做这件事，以前所未有的速度解决重要问题。
Gergely Orosz：我到现在还没碰到有人说“这样不好、这样没意思”。我这么理解对不对：如果你面对的是极其远大的问题，要解决的问题远远超过今天、明天或下周能搞定的量，那这就根本不是问题。因为你在某个地方变高效了，就能继续往前推。很多初创公司都是这样，初创公司的野心总是远超自己的能力范围，我们肯定不缺问题。
Tibo Sottiaux：而且我觉得很长一段时间内都不会缺。我们前面还有很长很长的路：数学突破、科学突破、让世界变得更好，真正为人类构建，解决每个人面临的最重要的问题，而且用一种深刻人性化的方式去做，这就是我们在这里的目的。 回到写代码和熬夜的事上，我觉得那可能多少带点美化色彩。我也经历过很多熬夜重构的日子，扎进去弄了三个小时，才发现这是条死胡同，必须从头再来，当时非常让人崩溃。所以既有非常开心的时候，也有怎么都编译不过的时候，你会想：“为什么还没编译过？”
Gergely Orosz：你肯定也遇到过，拖到了后半夜，必须睡觉了，躺下又睡不着，心里挂着做了一半的任务，弄得人心烦意乱。我记得有时候做梦都在写代码。我现在给自己的业务写软件，有一点挺好：基本不会留下做了一半的事，因为我可以直接告诉它做这个，然后留在一个基本完成的状态，要么跑通了，要么证明行不通。不过这很有意思，因为所有事情都变快了。
Tibo Sottiaux：对，很多人会这么做，我自己也是。有时我心里有些更大的疑问，来自白天的谈话，或者当时没时间深究，我就会让 Codex 连夜去研究。
Gergely Orosz：第二天醒来看结果时会特别兴奋，所以每天早上都挺让人期待的。我觉得做长时间运行的任务确实是一门学问。当然你也可以用 Fuego，它会一直往下跑，这也是最近几个月刚加的功能，对吧？给 Codex 的 Fuego 指令？
Tibo Sottiaux：回到刚才说的，harness 可能就是个拐杖。Fuego 之前是必须的，为了让模型在很长一段时间里不跑偏、盯住单一目标，它能让模型在面对特别难的问题时真的连续跑上几天，甚至几周。但换到新一代模型，我们看到的是，你已经不再需要 Fuego 了，不需要在外面套一个 harness。
Gergely Orosz：你只要跟模型说“去忙上一周吧”，它就真能做下来。说到难题，以及你们面前还有很多难题，从外界看你们上线的动作里，有一件挺有意思的事。作为工程师，我觉得很有意思的就是所谓的 merge，也就是 Codex 搬进了 ChatGPT。我之所以觉得有意思，是因为我们本来就在用 Codex，它就在那儿；现在你能在 ChatGPT 的 app 里打开它了。我当时直接点过去用 Codex，因为我平时不太用 ChatGPT 的 app 本身。 但我和 OpenAI 的人、以及你团队里的人聊过，他们说中间做了大量准备，遇到了很多工程挑战。你能讲讲这个项目有多大、具体需要做什么、为什么很难，以及 Codex 和其他工具怎么帮你们以之前很难想象的方式完成它吗？自从上线 merge，你一直在分享 Codex 使用人数增长速度比以前快多了，所以我猜你们解决了一个很大的规模化问题。Merge 有很多挑战，首先技术栈完全不一样：ChatGPT 是完全托管的。
ChatGPT Work、个人使用方式与工程师建议
Tibo Sottiaux：ChatGPT 基于云端，所有东西都在我们的系统上运行；我们按传统方式存储、构建系统，专为规模和效率打造。而 Codex 完全是本地的，所以 merge 的核心就是，怎么把这个本地编程 agent 的优势和能力拿过来，围绕它做成一个产品，让更广泛的人群用上它。这也是我们所有人加入 OpenAI 的初衷：让全世界如此广泛的人群受益。 这是一个特别令人兴奋的过程：琢磨怎么做成一个云端版本，本质上具备几乎完全一样的能力，同时又能支撑几千万、几亿用户，效率还能维持住，从而把它一路做进 Plus 计划。ChatGPT Work 本质上就像在云端运行完整的 Codex harness，再加上一台云端电脑，实际上是一台非常强大的机器。大家也注意到了，我们展示过它能做什么：只要 prompt 写得有创意，你就能让 ChatGPT 在里面训练另一个模型。， 确实有些用法挺惊人的。你能让它装个 Blender 做 3D 建模，权限放得很开，它能联网，机器性能很强，Codex 又在上面运行。这就是我们通过 ChatGPT Work 推出的东西，所以有很多系统层面的挑战。团队推进得非常快，当然 Codex 也帮着提高了效率，帮忙审查并搭建了大量基础设施，还帮忙拉平 Codex 和 ChatGPT 之间出现的大量细微差异，比如合并插件架构、合并代码库，真正朝着一个统一的系统推进。 这也是我们的终极目标：你不应该觉得有什么事在 Codex 里能做，在 ChatGPT 里就不能做，反之亦然。我们想做的是一个统一的产品，让你接触到同样的智能，但用的是你想要的方式。整件事也挺好玩的，因为 Codex 在整个过程中还充当了记者的角色，记录团队的所有步骤、争论和讨论。关于应该怎么做、东西该叫什么、什么时候以什么方式推出，以及把什么合并进什么里面，当时讨论得非常热烈，也考虑了许多种组合方案。， 这里面有一层很有趣的即时色彩：我们有一份由 Codex 完整记录下来的过程回溯。它在 OpenAI 内部也渐渐被称为“开关篇章”。我们推出了 Work 开关，围绕这个开关也有过很多争论和讨论：这样做到底对不对？后来我们慢慢变得特别喜欢它，但随着时间推移，我们会进一步做整合，确实在朝着完全统一的方向走。我们把这看作一个过渡状态，目前在 Work 模式下能力更好、更强，但慢慢我们会把这些能力推给每一个使用 ChatGPT 的人。
Gergely Orosz：那你个人是怎么用 Codex 的？在 agent 搭配、任务划分，还有用它来管理事情上，你的工作环境具体是什么样的？顺着这个，我问过 Peter Steinberger 应该聊聊你的什么。他说你得问问，参与了这么多项目，你是怎么应对的；你的日程表排得像俄罗斯方块似的，但你出现的时候通常都挺精神的。我的日程表还行，主要是现在因为有了像 Codex 这样的技术。 [00:52:41]
Tibo Sottiaux：我能做的事情多太多了，而且其实把很多工作都移到了手机上。我用 ChatGPT Work，每当有想记下来的东西，就直接发过去；经常用语音输入。每当有问题时，与其把它记下来，回头看或者转给别人，我直接在 ChatGPT Work 里发出去，就能拿到一份报告。它有一整套自定义 skill 和自定义指令，现在已经非常定制化了，能按照我高效吸收的风格，生成这类报告、PPT 以及代码探索。 所以每次在会议间隙或别的什么时候，你都会看到我一直对着手机说话。就像我之前说的，我们很多工作都是在公开频道里做的，Slack 上有很多内容，Notion 和 Google Docs 里也同样有很多。所以基本上没什么问题是我觉得不能问的，Codex 至少都能做一轮初步梳理，不管是某个功能的大众口碑，还是看线上日志、了解某样东西的用量，或者列出一批没什么人用、我们该弃用的东西，还是了解某个团队在忙什么。， 不管我有什么问题，差不多 30 分钟内都能拿到答案。我就是这么用它的，什么事都用它；它在方方面面都像是我的个人 agent。周末我也经常做代码探索，或者搭一些原型，在脑海里设想产品未来的走向，觉得挺有意思的。我也会和团队里的其他人一起做，不总是同一个团队。只要一天时间，我就能把脑子里憋着想做的东西搭出来。 就像某天醒来，我心想，我们应该去探索一下做这个会是什么样；然后一天之内，就能把这些全都表达出来，拿出一个东西摆在大家面前，让他们推敲、批评，说不定还能受到启发。这绝不是说我们一定要把它发布出去，更多的是我把这个念头做出来了，然后就接着去干别的事。所以我不知道，这是不是一个特别神奇的时代，但感觉自己能做的事情太多了。
Gergely Orosz：最后作为收尾，对于软件工程师或 AI 工程师，也就是做软件的人，如果想掌握技能和经验，获得去 Codex 团队、OpenAI 或 AI 初创公司工作的机会，你有什么建议？也就是，怎么用这些工具成为一个特别厉害的构建者？经常有人问：我应该从理论开始吗？基础有多重要？是不是只要把工具用得特别熟练就行了？
Tibo Sottiaux：我觉得有两件事很重要。第一，对事物的运作方式抱有极深的好奇心；第二，训练自己非常快速地理解事物。事情确实会不断变化，但在 OpenAI 做得极其出色的人，都是那些能迅速把一个系统吃透，也能扎进一个新代码库、把它理清楚的人。显然，现在所有这些都有 agent 的辅助。 关键是有那么多信息需要吸收、理解和推理。我觉得很大程度上，是去提出好问题，真正探究事物是怎么运作的，追问五个为什么。你可以一直挖、一直挖、一直挖，通过这个过程学得非常快。另一件事是，要和你正在为之解决问题的社区或人群保持同步。并不是所有事情都像是直接解决一个问题；有时候你解决的问题，是在为人类解决问题的过程中帮助到另一群人。， 但你要对品位、需求或具体规格保持敏锐，并且能够想得清清楚楚，不断锻炼这种清晰的思维。在我看来，这非常重要。如果你说不清楚自己想要达成什么，说不清楚自己的意图，如果你跟社区没有连接，如果没有那份品位，想做出出色的工作就会难得多。
Gergely Orosz：太棒了。Tibo，非常感谢这次交流。 聊得太棒了，谢谢你的邀请。我一直想跟 Tibo 聊一聊，很高兴我们终于把这事办成了。我很欣赏 Tibo 不仅谈了开源的好处，还谈了坏处，最典型的就是竞品可以直接抄你眼下正在公开做的功能，敢在你发布之前抢先上线，这确实挺让人难受的。另外你还会收到很多低质量的贡献代码，却还得想办法去处理。 另一个有意思的地方是，Tibo 说 harness 总是比模型快一步。从内部来看，Codex 团队觉得自己的工作就是用 harness 工具和配置指令给模型搭拐杖，而下一个版本的模型经过训练后，对这些拐杖的需求就会减少。说实话，作为一名开发者，这听起来有点让人泄气：我搭的东西到了下一个版本的模型那里，它直接就会了，我们就可以把它丢掉了。更不用说，这不仅仅是搭拐杖，还要造出给模型用的工具。， 下一个版本的模型总不可能把 MCP 协议、skill 或插件都重新发明一遍，至少我希望不会。我也很喜欢听内部视角聊那次合并，也就是把 ChatGPT 和 Codex 合并起来：把一个原本完全本地的代码 agent，也就是 Codex，合并进一套托管的云端技术栈，并且做得足够高效，让它能塞进 OpenAI 每月 20 美元的套餐里。要知道按算力采购来说，20 美元真不算多。 听他说 Codex 本身怎么充当整个项目的记录员也挺有意思，因为它存在于所有 Slack 对话和所有文档里，所以能捕捉到所有重要的辩论和决策。老实说，这部分让人觉得有点“老大哥”的味道，像是一直在盯着你看。但在未来的初创公司里，这很可能会成为新常态，我对这事到底怎么看，目前还没想好。最后我很认同 Tibo 给工程师提出的建议：保持好奇心，迅速搞懂问题表象。， 并且和你的服务对象同频。从 Tibo 那里听到基本功依然如此重要，也让人很踏实。请务必查看下方的节目附注，里面有关于 Codex、Claude Code 和 Cursor 是怎么搭出来的深度解析，以及其他相关话题。如果你喜欢听到的内容，请在正在使用的播客播放器上给个好评，这对我和这个节目都意义重大。谢谢大家，我们下一期见。