OpenAI如何用Codex在28天内极速打造安卓版Sora

28 天，4 个工程师，一个登顶 Play Store 的 App。

刚刚，OpenAI 发布了一篇工程博客，揭秘了他们如何用 Codex 在不到一个月的时间内，从零开始打造出 Sora 的安卓版应用。

这个应用上线首日就冲上了 Google Play 下载榜第一， 24 小时内用户生成了超过 100 万个视频 。

而最让人惊讶的是：整个开发过程消耗了约 50 亿 tokens ，应用的崩溃率却低至 0.1% 。

Alexander Embiricos(@embirico) 分享了这篇博客:

这篇文章来自 OpenAI 的两位技术人员 Patrick Hum 和 RJ Marsan，他们详细记录了整个开发过程中的经验和教训。

背景：一个月的「紧急任务」

当 Sora 在 iOS 上发布时，用户量瞬间爆炸。

而此时的安卓端，只有一个小小的内部原型，以及 Google Play 上一长串等待的预注册用户。

面对这种高压、时间紧迫的发布任务，常规做法是 堆人、加流程 。一个这样规模和质量的生产级应用，通常需要很多工程师花费数月时间，还要被各种协调工作拖慢进度。

但 OpenAI 团队选择了相反的路径。

计算机架构师 Fred Brooks 有句名言： 「给一个已经延期的软件项目加人，只会让它更晚交付。」

原因很简单： 人越多，沟通成本越高，任务越碎片化，集成代价越大。

于是他们组建了一个精干的 4 人工程团队 ，每个人都配备了 Codex 来大幅提升个人产出。

结果怎么样呢？

团队最终用时 18 天 完成了内部版本，并在 10 天后 正式全球上线。

把 Codex 当新来的资深工程师

要理解他们是怎么用 Codex 的，首先要搞清楚 Codex 擅长什么、不擅长什么。

团队发现， 把 Codex 当作一个新入职的资深工程师来对待，效果最好 。

Codex 需要指导的地方

推断它不知道的东西 ：比如你偏好的架构模式、产品策略、真实用户行为、内部规范或快捷方式。

无法「看到」应用运行 ：它不能在设备上打开 Sora，感知滚动是否流畅，或者判断某个流程是否让人困惑。这些体验层面的任务只能由人来完成。

每个实例都需要「入职培训」 ：清晰地分享目标、约束条件和「我们团队的做事方式」，对 Codex 的执行效果至关重要。

缺乏深度架构判断 ：如果放任不管，它可能会在本该扩展现有 view model 的地方引入一个新的，或者把本该放在 repository 层的逻辑塞进 UI 层。它的本能是让东西跑起来，而不是优先考虑长期的代码整洁。

团队让 Codex 在整个代码库中创建并维护了大量的 AGENT.md 文件，这样就能在不同会话间保持一致的指导和最佳实践。比如，为了确保 Codex 按照团队的风格规范写代码，他们在顶层的 AGENTS.md 中加入了这样的内容：

## Formatting and static checks- **Always run** `./gradlew detektFix` (or for the affected modules) **before committing**. CI will fail if formatting or detekt issues are present.

Codex 擅长的地方

快速阅读和理解大型代码库 ：Codex 基本上懂所有主流编程语言，这使得跨平台复用概念变得更容易，不需要复杂的抽象层。

测试覆盖 ：Codex（独特地）对写单元测试充满热情，能覆盖各种各样的场景。虽然不是每个测试都很深入，但广泛的覆盖率有助于防止回归。

响应反馈 ：当 CI 失败时，可以把日志输出粘贴到提示词里，让 Codex 提出修复方案。

大规模并行、可丢弃的执行 ：大多数人不会触及同时运行会话数量的上限。完全可以并行测试多个想法，把代码视为「用完即弃」的。

提供新视角 ：在设计讨论中，团队把 Codex 当作一个生成工具，用来探索潜在的失败点和发现新的解决方案。比如在设计视频播放器内存优化时，Codex 翻阅了多个 SDK，提出了团队自己没时间去研究的方案。这些洞察在最终应用中对最小化内存占用起到了关键作用。

让人做更高杠杆的工作 ：实际上，团队花更多时间在 review 和指导代码上，而不是自己写代码。而且 Codex 本身也很擅长代码审查，经常在代码合并前就发现 bug。

先打好地基

就像最优秀的新员工一开始也没有足够的视野来做长期权衡一样，要让 Codex 的工作稳健且可维护，关键是团队自己要把控好应用的系统设计和关键决策。

这包括： 确定应用的架构 、 模块化 、 依赖注入和导航 ； 实现认证和基础网络流程 。

在这个基础上，团队 端到端地手写了几个代表性功能 ，使用了他们希望整个代码库遵循的规则，并在过程中记录下项目级别的模式。

通过指向这些代表性功能，Codex 就能在团队的标准内更独立地工作。

对于一个估计 85% 由 Codex 编写 的项目来说，精心规划的地基避免了代价高昂的返工和重构。

这是他们做出的最重要的决定之一。

核心理念不是尽快做出「 能跑的东西 」，而是做出「 符合我们期望方式的东西 」。

团队也试过直接提示：「 基于 iOS 代码构建 Sora 安卓应用。Go。 」

但很快就放弃了这条路。

虽然 Codex 创建的东西技术上能跑，但产品体验很差。

而且没有对端点、数据和用户流程的清晰理解，Codex 一次性生成的代码是不可靠的。

结论是：Codex 在有良好编写示例的「沙箱」里才能发挥最佳水平。

让 Codex「构建这个设置页面」而几乎不给上下文，结果不可靠。但让 Codex「使用你刚看到的那个页面相同的架构和模式来构建这个设置页面」，效果就好得多。

人类做结构性决策并设定不变量；Codex 在这个结构内填充大量代码。

让 Codex 长时间「无人值守」工作

团队接下来要解决的问题是： 如何让 Codex 在长时间（最近甚至超过 24 小时）内无人值守地工作。

早期使用 Codex 时，团队直接跳到这样的提示：「这是功能，这是一些文件，请构建它。」这有时候能行，但大多数时候产出的代码虽然能编译，却偏离了架构和目标。

于是他们 改变了工作流程 。

对于任何非平凡的改动，他们首先让 Codex 帮助理解系统和代码是如何工作的。

比如，让它阅读一组相关文件，总结某个功能的工作方式： 数据如何从 API 流经 repository 层、view model，再到 UI 。

然后团队会纠正或完善它的理解。

类似于与一个新入职的高能力队友互动的方式，他们与 Codex 一起创建 可靠的实施计划 。

这个计划通常像一个小型设计文档，指明哪些文件需要改动、应该引入什么新状态、逻辑应该如何流动。只有这时，才让 Codex 开始按计划一步步执行。

一个有用的技巧是： 对于非常长的任务，当上下文窗口达到上限时，让 Codex 把计划保存到文件里，这样就能在不同实例间应用同样的指导。

这个额外的计划循环被证明是值得的。

它让团队可以放心让 Codex 长时间「无人值守」运行，因为他们知道它的计划。它让代码审查更容易，因为可以对照计划检查实现，而不是没有上下文地阅读 diff。

当出问题时，可以先调试计划，再调试代码。

像管理团队一样管理 Codex

在项目高峰期，团队经常同时运行多个 Codex 会话。一个在做播放功能，一个在做搜索，一个在处理错误处理，有时还有一个在写测试或重构。

感觉不像在用工具，更像在管理一个团队。

每个会话会定期向团队汇报进展。一个可能说「 我已经规划好这个模块了，这是我的提案 」，另一个会给出一个新功能的大型 diff。

每个都需要关注、反馈和审查。

这和作为技术负责人管理几个新工程师的感觉出奇地相似——所有人都在推进，所有人都需要指导。

结果是一种协作流程：Codex 的原始编码能力把团队从大量手动敲代码中解放出来，有更多时间思考架构、仔细阅读 PR、测试应用。

但同时，那种额外的速度意味着审查队列里总有东西在等着。Codex 不会因为上下文切换而被阻塞，但人会。

开发的瓶颈从写代码转移到了做决策、给反馈和集成改动上。

这也是 Brooks 洞察的新体现： 你不能简单地增加 Codex 会话就期望线性加速，就像不能不断加人就期望时间线性缩短一样 。

每多一双「手」，即使是虚拟的，都会增加协调开销。

团队从独奏者变成了乐队指挥。

跨平台的新方式：翻译而非抽象

团队的项目有一个巨大的起点：Sora 已经在 iOS 上发布了。他们经常让 Codex 查看 iOS 和后端代码库，帮助它理解关键需求和约束。

在整个项目过程中，团队开玩笑说他们「 重新发明了跨平台框架的概念 」。

忘掉 React Native 或 Flutter 吧；跨平台的未来就是 Codex。

这个玩笑背后有两个原则：

逻辑是可移植的。 无论代码是用 Swift 还是 Kotlin 写的，底层的应用逻辑——数据模型、网络调用、验证规则、业务逻辑——都是一样的。Codex 非常擅长阅读 Swift 实现并生成语义等价的 Kotlin 代码。

具体的例子提供强大的上下文。 一个新的 Codex 会话如果能看到「这是 iOS 上这个功能的工作方式」和「这是安卓架构」，比只有自然语言描述有效得多。

他们把 iOS、后端和安卓的代码库都放在同一个环境中可用，给出这样的提示：

「阅读 iOS 代码中的这些模型和端点，然后提出一个计划，使用我们现有的 API 客户端和模型类在安卓上实现等价行为。」

一个小而有用的技巧是在 ~/.codex/AGENTS.md 中详细说明本地代码库的位置和内容，这样 Codex 更容易发现和导航相关代码。

他们实际上是在通过翻译而非共享抽象来做跨平台开发。

因为 Codex 处理了大部分翻译工作，他们避免了翻倍的实现成本。

更广泛的教训是： 对 Codex 来说，上下文就是一切。

当它理解功能在 iOS 上如何工作，同时又理解安卓应用的结构时，Codex 的工作效果最好。当它缺乏这些上下文时，它不是「拒绝合作」，而是在猜测。团队越是像对待新队友一样投入精力给它正确的输入，它的表现就越好。

未来的软件工程