当写代码成本趋近于零：AI重写软件开发核心逻辑

当代码编写的成本不断趋近于零，整个软件开发的底层逻辑正在被全面重构。OpenAI Codex的核心负责人Tibo Sottiaux在一场深度访谈中，分享了这款工具从内部测试工具成长为成熟产品的完整历程，以及团队如何借助AI重构软件开发全流程的实践细节。

Tibo的职业路径颇具代表性。他在比利时成长，大学攻读应用数学专业，尚未毕业就开始为银行与供应链企业提供咨询服务，之后创办了一家专注于制药供应链优化的公司，核心技术是蒙特卡洛模拟与随机多阶段优化这类数学工具，并未涉及机器学习领域。此后他先后加入谷歌负责谷歌地图项目、在DeepMind搭建研究基础设施，2024年加入OpenAI参与了初代推理模型o1的发布工作，随后全身心投入Codex的开发。这份深耕工具效率提升的职业底色，也完整融入了Codex的设计理念中。

选择Rust与开源：背后的长远考量

很多人都知道Codex的命令行工具是基于Rust开发的，但很少有人深究这个选择背后的逻辑。Tibo解释，当时OpenAI内部的大模型在Rust场景下的表现并不比Python或TypeScript更突出，所以选择Rust并非因为模型已经适配得很好，而是基于第一性原理的判断：智能体需要的是健壮性、安全性与运行效率，而Rust的编译期静态验证特性，恰好能为智能体提供天然的优势。他直白地表示，即便用TypeScript也能实现，但后续大概率需要完全重写代码。

这个选择背后还有更深层的设计思路：团队很早就将智能体本身与产品界面视作两个完全独立的模块。Rust在这里不仅是编程语言的选择，更是一道强制的边界隔离线，迫使团队将智能体的核心逻辑与产品层代码清晰拆分。Tibo提到，如果所有代码都混杂在同一个代码库中，必然会出现功能纠缠的问题，进而阻碍后续的创新迭代。清晰的代码边界并非为了美观，而是为了未来能够快速灵活地调整与迭代。

开源同样是一个值得深思的决定。Codex CLI与SDK均采用开源协议，这在主流AI编程工具中属于少数情况。Tibo表示，既然做的是编码智能体，自然要让工具能够自我指向、自我改进，同时吸引社区贡献者。他提到的核心观点是：如果想要获得成功，开源本身会推动代码角色发生改变，成为社区的一部分远比游离在外更有价值。当然他也坦诚开源的代价：竞争对手会提前复制你的功能，参差不齐的社区PR会带来大量的维护压力，需要投入额外的人力处理。他坦言这种情况“有点刺痛”，但也明确这是选择开源必须承担的部分。

还有一个细节同样值得关注：Codex并不会绑定OpenAI自家的模型，用户可以使用其他厂商的模型运行Codex。Tibo的态度很明确：如果要打造优秀的编程框架，为什么要将其绑定在自家模型上？他希望依靠顶尖的模型与成熟的产品赢得用户，而非通过绑定来维持竞争力，这份底气也体现了团队对自身产品能力的自信。

编程框架始终领先模型一步：设计逻辑的核心

Tibo分享了一个此前较少被提及的设计思路：编程框架在设计上始终要比当前模型的能力领先一步。他用“拐杖”来比喻harness的作用：帮助模型在当前的能力水平下，达到用户期待的可靠性与行为表现。比如早期的模型不会主动执行测试，harness就会在系统提示中提醒模型完成测试；当模型经过训练掌握了主动测试的能力后，这段提示配置就可以被移除。

这个过程有一个清晰的规律：随着模型能力不断增强，系统指令会越来越简短，harness本身也会不断精简，因为越来越多原本需要手动提醒的能力，模型已经可以自主完成。很多人会觉得这种设计是让工程师的工作变得多余，但实际上这是非常健康的方向：工程师编写harness的目标并非为了维持自身的工作，而是为了让整个系统变得更好，即便这部分代码最终会被模型的能力替代。

团队也会面临一个实际的问题：如何判断一个问题应该在harness层解决，还是等待模型本身的能力升级？Tibo给出的判断标准很简单：先评估模型的改进需要多久才能落地，是一个月还是六个月？如果模型升级很快，就不需要在harness中做临时方案，直接等待模型迭代即可；如果模型升级周期较长，才考虑先在harness中搭建临时解决方案。他还提到一句清醒的判断：“如果你正在编写上万行代码来绕过模型的缺陷，那大概率你的方向出现了问题。”这句话的核心逻辑是，不要死磕模型的局限性，而是要学会判断何时应该等待技术本身跟上节奏。

代码审查并未消失，但核心价值已经改变

这部分是整个访谈中最具思考深度的内容之一。Tibo提到，团队内部开发了专门的代码审查模型，可以实现跨多层依赖的深度验证，能够发现人类工程师需要花费数小时才能追踪到的逻辑错误，比如第三方依赖文档描述与实际实现不一致导致的漏洞，或是复杂的安全隐患。他表示，在代码正确性与安全性这两个维度上，当前的AI模型已经达到了超越人类的水平，OpenAI内部所有的拉取请求如果被标记出安全问题，会被直接自动拦截。

但Tibo同时强调，代码审查作为团队协作的仪式，其核心价值从来都不只是检查代码的对错。他指出，代码审查一直是团队内部交换信息的场合，是让成员理解“为什么要做这件事”的机制，也是讨论架构设计意图的场景，这部分价值是AI模型无法替代的。他提出了一个清晰的框架：代码审查真正应该讨论的是开发意图——你到底想要达成什么目标，这件事是否值得做，是否是正确的方向。这类讨论不一定需要在代码层面进行，完全可以提前到编写代码之前，先把意图梳理清楚。只要代码满足约定好的不变量与接口契约，具体的实现细节就不需要过多的人工审查。

很多团队的代码审查已经沦为形式，评审人员因为上线压力，往往只是快速扫过格式与命名就通过审核。真正有价值的讨论，其实是在更高的层级上，比如这个功能该不该做、应该是什么形态、和其他模块的边界在哪里。现在有了更好的工具与更快的迭代速度，这类讨论反而应该更早、更认真地开展，而不是等到代码写完之后才在拉取请求中争论不休。

维护成本下降，但优秀架构的重要性反而提升

Tibo提出了一个有趣的判断：软件维护本质上是为了“保持系统正常运转”而持续支付的“税”，这个税负并不会消失，但会越来越多地被自动化替代。他举了一个具体的例子：升级第三方依赖的版本号，曾经是没人愿意做的苦差事，既耗时又有风险，还不会带来明显的业绩收益，但对系统安全至关重要。现在如果代码库的文档清晰、结构合理，AI模型可以在数小时内扫描整个代码库，完成所有依赖的升级。过去很多团队会拖延这项工作，因为不值得投入优先级，但现在这个理由已经不再成立。

他还提到了代码重构的成本变化：过去如果系统架构存在问题需要整体重构，往往是需要耗费数年的大型工程，但现在这个成本正在急剧下降，因为AI模型可以在短时间内完成大规模的代码重组。但他同时强调，良好的抽象与清晰的代码边界，反而比以往更加重要。因为当你可以极快地重写一个模块的内部实现时，真正稳定的东西是模块之间的接口契约与不变量。他用“带有不变量的盒子”来比喻这种设计：你只需要约定好这个盒子对外承诺的功能，只要这个承诺不改变，盒子内部的实现可以随时替换，不需要和其他团队讨论。

这里有一个反直觉的结论：当维护成本越来越低，并不代表架构思维变得不重要，恰恰相反。当代码修改的成本趋近于零，真正决定开发速度的，反而是你在一开始是否清晰划分了系统的边界。边界划分清晰，任何改动都不会牵一发而动全身；边界模糊，每次改动都需要花费大量时间梳理影响范围。这和软件工程的底层原则一脉相承，只是在当前的技术语境下，这个原则变得更加突出。

将Codex并入ChatGPT：远超预期的工程难度

外部用户看到的“合并”，只是在ChatGPT界面中增加了一个Codex的入口，看起来只是添加了一个标签页。但Tibo透露，这个项目在工程层面是两套完全不同体系的融合：ChatGPT是全托管的云端系统，数据按照传统方式存储，针对大规模服务做了高度优化；而Codex则是完全本地运行的编码智能体。将本地运行的智能体能力迁移到云端，同时保持完整的功能，还要保证足够高的效率，能够纳入ChatGPT Plus的月度订阅计划中，背后涉及相当复杂的系统工程工作。

他还分享了一个有趣的细节：在整个合并过程中，Codex本身充当了“项目记者”的角色。因为Codex接入了所有的Slack频道与项目文档，它记录了整个项目过程中团队的所有讨论、争论与决策，包括那些关于“这个功能应该叫什么名字”、“这个开关应该如何设计”的激烈讨论。Tibo提到，这段记录在内部被称为“toggle arc”。听到这里或许会让人感到些许不适——AI系统在不知不觉中记录了所有团队讨论，但仔细想想，这可能会成为未来团队协作的新常态，尤其是在大量使用AI工具的团队中，知识沉淀的方式会从“人工撰写文档”转变为“智能体自动归档”。这或许会改变团队内部的信息流动与知识管理模式，虽然目前还很难完全评估其影响，但足以让人意识到AI在团队中的角色，早已不只是帮助编写代码。

Tibo本人如何使用Codex：真实的工作流场景

Tibo描述的日常工作方式，比任何产品介绍都更能说明Codex的实际价值。他表示自己大量使用手机端的ChatGPT Work模式，在开会间隙直接通过语音发送任务或问题，系统会自动检索Slack、邮件、日历等平台的信息，给出整合后的回答。他说现在自己能够处理的事务量比以前多得多，因为很多原本需要“专门抽出时间处理”的问题，现在可以随手提问，不需要打开电脑，也不需要等待整块的时间。

他还分享了自己的工作习惯：设置了大量的自定义技能与自定义指令，让智能体生成的报告、幻灯片与代码分析都符合自己的风格与需求。这也让人意识到，当前很多人使用AI工具还停留在“通用提问”的阶段，但Tibo的工作流已经进入了“高度个性化的智能助手”阶段——它不再是通用助手，而是完全熟悉你的工作方式与需求的个人智能体。两者之间的效率差距，远比大多数人想象的要大。

他还提到，有时会在周末使用Codex进行代码探索或产品原型开发，将脑海中的想法在一天之内变成可以分享、讨论和批判的成果。他说“我只是需要把它从我的系统里排出去”，这句话非常真实。有了这样的工具后，从“脑海中有一个想法”到“变成可以被他人反馈的成果”的过程，被压缩到了之前根本不可能达到的速度，这对产品迭代、创意探索与技术决策的影响是系统性的。

软件工程师的核心价值正在向何处转移

听完整个访谈，最大的感受是Tibo描述的这些变化，并非只是在讨论某一款工具是否好用，而是在描述软件开发底层逻辑的全面转变：当代码实现成本趋近于零，当维护工作可以被自动化，当代码审查的正确性检查被AI接管，那么工程师真正稀缺的能力是什么？

Tibo给出的答案是：深度的好奇心，能够快速理解新系统并找到方向的能力，以及与你服务的群体保持真实连接的能力。他还补充了一个非常核心的词：判断力。他表示：“如果你说不清楚自己想要达成什么目标，如果你没有和某个社区建立连接，如果你没有判断力，那么做出优秀的产品会困难得多。”

这里的“判断力”并非审美层面的品味，而是指一种对目标与价值的认知能力：知道什么事情值得去做，知道一个产品或功能应该是什么形态，知道何时应该坚持、何时应该等待技术跟进、何时应该放弃某个方向。这种判断力无法被自动化替代，因为它本质上是人类对目标与价值的思考，而非执行某个具体步骤的能力。

还有一个细节值得单独提及：Tibo聊到年轻时在Vim中熬夜编写代码、喝着零度可乐、不需要考虑其他事情的时光，偶尔还是会打开编辑器亲手写一段代码。能感受到他对编程手艺本身的眷恋，但他也清醒地表示：如果你将代码本身当作最终目的，现在或许会开始感到失落；但如果你将代码视作解决问题的工具，那么现在你能够解决的问题比以往多得多，这应该是一件令人兴奋的事，而非焦虑的来源。

这种心态上的转变，或许是这个时代的软件工程师最需要完成的调整。工具在不断变化，开发速度在不断加快，很多具体的技能会被替代，但“能否想清楚要做什么、能否感知到用户的真实需求、能否在众多可能性中做出正确的判断”——这些能力反而变得比任何时候都更加珍贵。