本文根据 Matthew Berman 与 The Pragmatic Engineer 对 OpenAI 的 Tibo Sottiaux 的两场视频访谈编译整理，非逐字翻译；文中观点均属于访谈嘉宾。
主要视频：How to Understand the Next Wave of AI Before Everyone Else | Tibo Interview
补充访谈：Building Codex with Tibo Sottiaux
全文字符数：4672
最近我看了 Matthew Berman 对 Tibo 的这场访谈。混 AI 圈的人应该都知道 Tibo 的 X 账号，他因为动不动就重置大家的用量，被网友封了个外号——“古希腊掌管重置的神”。这次访谈内容很扎实，我很推荐，下面就把它完整讲给你听。
先说说 Tibo 是谁
Tibo 全名 Thibault Sottiaux，出生在布鲁塞尔。大概八岁那年，他跟着爸妈搬到一个只有两百来人的小村庄，电脑和早期的互联网，就成了他认识世界的窗口。后来他念的是应用数学，还在上学的时候，就已经在给银行做咨询了。他一直在意的一件事，就是怎么把数学和技术放进真实的系统里，去解决具体的问题。
大学毕业之后，他在比利时跟人一起创办了一家公司，用蒙特卡洛模拟和随机多阶段优化，去改善临床试验里的药品供应链，后来也处理钢铁和电网的问题。这段经历，其实也解释了他后来为什么一直做基础设施和工具——先找到复杂系统的瓶颈，再让其他人干活更有效率。
2015 年，他去了 Google 伦敦，参与一个给移动网页加速的项目。做了两年，项目被取消了，原因很直白：只有几百名用户，达不到 Google 想要的规模。他由此意识到，技术再漂亮，也得先确认真实影响。之后他转去 Google Maps 做评论相关的工作，一年后又加入了 DeepMind。
在 DeepMind，他主要负责研究基础设施和工具，还参与做了一个内部聊天系统，比 ChatGPT 早了大概一年。这个系统一开始回答得离谱，后来慢慢变得连贯、实用，也在公司内部流行了起来，但始终没能变成大众产品。Google 的成熟体系保证了稳定，可也意味着，颠覆现有业务的创新很难真正落地。这让 Tibo 特别在意一件事：研究成果到底能不能交到用户手上。
为什么离开 Google，又为什么加入 OpenAI
Tibo 在 Google 其实过得并不差，但他想去一个使命感更直接、研究和产品能一起拍板的地方。他发现 ChatGPT 这种量级的产品，当时核心团队居然只有二十来名工程师。团队人少、权限大、速度快，还会认真听用户反馈，这种做事的方式把他吸引进了 OpenAI。
他在 2024 年加入 OpenAI，正好赶上推理模型发布前的冲刺，入职大概一个月后，o1-preview 就上线了。在这里，不是研究团队先把东西做好再交给产品，而是模型、基础设施和产品一起设计，再尽快让真实用户来验证。Tibo 觉得，公司规模变大之后，还是得敢打破自己已有的产品，因为 AI 不会等一门生意做成熟了才继续变。
不过，“发布得快”也不等于随便堆功能。他同样强调简单、一致、性能和完成度。模型不能只看基准测试，团队往往要自己上手用了，才知道它能撑起什么样的产品。比如语音变得自然、还能调用工具之后，他就开始直接对着手机交代任务，产品设计也不再只能围着键盘和文本框转。
Codex 为什么会出现
刚进 OpenAI 的时候，Tibo 也是从大规模数据存储、训练分析这些研究基础设施做起的。但 o1 这类模型出来之后，他开始琢磨：为什么不用模型本身来加速研究和开发呢？他跟研究人员一起，训练出一个熟悉 OpenAI Python 代码库、架构和代码风格的内部模型，还做了一批小型智能体去干真实的活，这些就是 Codex 的前身。
内部另有一个项目叫 Autonomous Software Engineer，读作 AS3。它跟研究工具合到一起之后，慢慢长成了 Codex。最初的云端版本门槛太高，一直没找到很好的产品市场匹配，团队随后才推出 Codex CLI。Codex 从一开始就不只是更聪明的代码补全，它要验证的是，模型能不能碰真实的代码、终端和工具，把一整件事完整推进下去。
至于 Tibo 自己为什么用 Codex，说到底是因为代码只是解决问题的工具。过去一个想法，可能因为要搭环境、写测试、等结果，就被放弃了；现在几十秒就能跑起一个实验。这样人就能把注意力留给更重要的问题：这件事值不值得做、系统要满足哪些约束、结果能不能真正帮到用户。
为什么用 Rust、开源，还允许其他模型
Codex 的核心是用 Rust 写的，而当时模型写 Rust，还不如写 Python 或 TypeScript 熟练。团队更看重的，是把智能体核心和产品界面分开，同时保证正确、安全、高效、可扩展；Rust 的编译期检查，也刚好能让智能体尽早发现错误。别的语言其实也可能做成，但 Rust 划出了一条清晰的边界，避免智能体逻辑和产品代码缠在一起。
把 CLI、SDK 和应用服务器开源，一来能让 Codex 读取并改进自己的代码，二来也让团队把他们理解 harness 的方式公开出来，向社区学习。代价当然也有：开发中的功能可能被提前复制，维护者要处理质量参差不齐的贡献，还得在内部能力和公开仓库之间划好边界。
Codex 不强制绑定 OpenAI 模型，也是同一个思路。既然别人改几行代码就能做出一个分叉版本，那不如干脆把选择权交给用户和企业。Tibo 更希望靠模型质量、效率和产品体验把人留下，而不是靠限制。
Tibo 平时到底怎么用 Codex
在 OpenAI 内部，Codex 能访问代码、文档和 Slack。新人想了解项目现状，或者想知道某个决定是怎么来的，最常听到的一句话就是：“你问过 Codex 了吗？”它会先把散落各处的信息串起来，让人很快搞清楚谁在做什么、项目走到了哪一步。
Tibo 自己大量在手机上用它。开会间隙想到个问题，他会直接口述给 ChatGPT/Codex，让它先出一版报告。他配了自己的 Skills 和指令，让它按自己习惯的方式输出报告、幻灯片或者代码探索。任务可能是分析功能反馈、查看生产日志、找出该废弃的功能，也可能是了解某个团队的进展。几乎任何问题，都可以先让 Codex 想一遍，通常半小时内就有结果。
周末他也会拿 Codex 做代码探索和产品原型，一天之内就能把模糊的想法变成一个可以拿来讨论的版本；那些来不及研究的大问题，就丢给它跑一整夜。原型不一定会真的上线，价值在于让想法尽快被批评、被修改。对 Tibo 来说，Codex 早就不只是编码工具，而是覆盖整个工作的个人智能体。
今天的 Codex 还只是过渡形态
Tibo 说过，现在这版 Codex，等两三个月后再回头看，会显得很原始。今天熟练的用户得自己维护 Skills、担心记忆丢失、手动组织子代理和并行任务，很多所谓的高级技巧，其实只是在替模型补能力。下一代智能体应该能直接理解用户的目标、习惯和团队环境，既能听人指挥，也能在对的时候主动帮上一把。
笔记本电脑本来就是按人的工作量设计的，而模型能同时探索、写测试、编译、验证假设。模型越快，CPU、网络和工具调用就越容易变成新的瓶颈，所以更多任务会挪到云端去。产品真正要保护的，是人的注意力：有人喜欢频繁切换，有人只想专注在两三个任务上，智能体得去适应不同的人。
在 Tibo 看来，未来会分成两条路线：一条是个人智能体，理解具体的人，帮着处理编程、研究和建议，让人始终有掌控感；另一条是完整的自动化系统，读生产日志、优化性能、修回归和安全漏洞，只把高风险动作留给人来批准。前者像伙伴，后者像一条可靠的自动化流水线。
ChatGPT 和 Codex 为什么要合并
不少用户一开始不理解，为什么要把 ChatGPT 和 Codex 合到一起。Tibo 的解释是，这两者底层正在变成同一个东西——一个多模态、以自然交互为方向的个人智能体。软件工程师、设计师、产品经理，这些只是人为贴上的标签，真实用户往往是在角色之间来回切换的。所以同一个系统，应该根据任务、工具和习惯去调整界面，而不是先逼人选择一个身份。
落到工程上，ChatGPT 原本是个托管的云服务，Codex 更偏本地智能体。团队得在受管理的云端计算机里运行完整的 harness，同时还要控制住服务海量用户的成本，把插件、基础库和两边已经分叉的架构统一起来。Codex 自己也参与了这件事，帮忙搭基础设施、处理差异、记录决策。现在这种模式切换只是中间状态，方向仍然是进一步统一。
“重置之神”为什么总在按按钮
用量重置一开始并不是营销活动。团队快速迭代的时候，偶尔会把服务弄坏、把参数配错，Tibo 觉得用户既然靠 Codex 干活，出了这种问题，就该给点补偿。后来，重置也被拿来庆祝新功能、招呼大家来试，慢慢地就成了社区里的一个梗，甚至真做了一枚实体按钮。
按不按这个按钮，没有什么营销或者财务审批流程，他觉得合适，就可以按下去。听起来挺随性，但背后还是那条原则：别光嘴上说关心用户，要对真实的体验负责。后来被问到 OpenAI 和 Anthropic 的竞争，他同样把话题拉回到社区和透明度上，拉回到把能力广泛地开放出去，以及怎么做出自己真正擅长的东西。
算力、递归式自我改进和安全刹车
敢频繁送用量，前提是算力跟得上。OpenAI 很早就开始规划计算资源，而最强的模型又会反过来优化推理栈、CUDA 内核和服务架构。Matthew 提到，Soul 帮 Luna 做完优化之后，后者的价格降了 80%；Tibo 还说，普通推理速度比三个月前大约快了 60%。团队希望把这些效率收益继续变成更低的价格、更高的吞吐，还有更多的额度。
这也算是一种“递归式自我改进”：它不一定先表现为模型训练模型，也可以是强模型去改造推理基础设施；系统变快、变便宜之后，人和智能体都能做更多实验，再推动下一轮改进。
但能力加速，不等于取消刹车。聊到暂停最前沿的强化学习训练时，Tibo 说，团队需要时间理解风险、加固系统，并形成一套恢复的原则，具体标准由安全团队来定。这只是原则层面的说明，访谈并没有披露完整的技术细节，所以别把它当成一套完整的安全方案。
Ultra Fast 到底改变了什么
Ultra Fast 最直接用在那些高风险、高时效的任务上。OpenAI 出故障的时候，事故响应团队会拿到这项能力；临近发布、急着判断一个原型值不值得继续做的团队，也会去申请。Tibo 还开玩笑说，宠物功能虽然讨喜，但还没关键到非用它不可的地步。
比如网页或游戏原型这种要大量生成代码的任务，速度能快到接近十倍；可如果任务里有很多工具调用，瓶颈就会转移到网络和执行链路上，体感也许只有三四倍，而不是十四倍。Tibo 自己有 ADHD，平时喜欢切换上下文，但专注做一件事的时候，他也希望模型能立刻跟上，别让等待打断思路。
OpenAI 内部也不是人人无限量用 Ultra Fast，大部分容量还是留给外部用户。Tibo 更期待的，是一种非文本的交互：人跟 AI 共享一块画布，实时生成设计，再用语音继续修改。他觉得一两年后，今天这种高速体验可能就会接近默认水平，但上面大概永远还有一个档位，用更多硬件去换速度。
对工程师和普通用户的建议
AI 正在让代码审查、维护和重构都发生变化。正确性、安全扫描和常规检查会越来越自动化，而人的讨论要提前到“为什么做”、模块契约是什么、哪些不变量必须成立这些问题上。边界一旦清楚，内部实现就可以更快地替换，那些过去要花几个月甚至几年的升级或重构，也可能重新变得值得做。
他建议工程师保持好奇心，练出快速理解一个陌生系统的能力，并且不停地追问“为什么”。智能体能帮你消化信息，但目标、意图和用户需求这些，还是得由人来说清楚，也要跟自己服务的社区保持联系。如果表达不清，又判断不出好坏，再强的工具也很难做出好东西。
对那些还在担心 AI 的人，Tibo 的建议是：不用先去接受什么宏大叙事，先看它能不能解决你眼前的问题。他自己会先用写作、语音、健康和财务这些能力拿到第一轮信息，再带着更充分的问题去找专业人士。模型还会继续变便宜，与其只听别人争论，不如看看身边的人怎么用，然后自己上手试一次。