Sora 产品已于 2026 年 4 月 26 日正式关停。

我们在 11 月面向全球推出 Sora Android 应用，支持任何拥有 Android 设备的用户将简短的提示转化为生动的视频。应用上线当天，便登上 Play Store 榜首。Android 用户已在前 24 小时内生成超过 100 万个视频。

发布背后的故事：Sora 的 Android 应用初始版本在 28 天内构建完成，这要归功于任何团队或开发人员均可使用的智能体：Codex。

2025 年 10 月 8 日至 11 月 5 日，一支精干的工程团队与 Codex 携手合作，消耗约 50 亿 token，将 Android 版 Sora 从原型阶段推向全球发布。尽管规模庞大，但该应用的无崩溃率高达 99.9%，其架构也让我们深感自豪。如果你想知道我们是否使用了某个秘密模型，其实我们用的是 GPT‑5.1‑Codex 模型的早期版本 — 任何开发人员或企业均可通过 CLI、IDE 扩展或 Web 应用使用的相同版本。

iOS 版 Sora 一经发布，使用量就呈爆炸式增长。人们立即开始生成大量视频。相较之下，Android 系统中只有一个小型内部原型，而 Google Play 中预注册的用户数量正不断增加。

面对高风险、时间紧的发布工作，常见的响应策略是积累资源并增加流程。具有如此规模和质量的生产应用通常需要众多工程师花费数月时间来开发，且因协调工作而进展缓慢。

美国计算机架构师 Fred Brooks 曾有一句广为流传的警言：“向已延期的软件项目增加人手，只会让它更晚完成。”换句话说，当试图快速交付一个复杂项目时，引入更多工程师往往会导致沟通成本增加、任务分散和集成成本攀升而降低效率。我们并未忽视这一洞察，而是选择积极加以利用；我们组建了一个由四名工程师组成的强大团队 — 每位工程师均配置 Codex，以大幅提高其产出能力。

通过这种方式，我们在 18 天内向员工发布了 Android 版 Sora 内部版本，并在 10 天后公开上线。我们在 Android 工程实践中坚持高标准，在可维护性方面进行投资，并对应用可靠性提出与传统项目相同的要求。（如今，我们仍在广泛使用 Codex，以优化该应用并为其添加新功能）。

要了解我们如何与 Codex 开展合作，就必须明确它在哪些方面发挥作用，在哪些方面需要指导。将其视作一名新任高级工程师，就是一个好方法。Codex 的能力意味着我们可以投入更多时间指导和审核代码，而无需自行编写代码。

Codex 需要指导的环节

我们发现，让 Codex 在整个代码库中创建和维护大量 AGENT.md 文件非常实用。这样，我们就能实现在各个会话间轻松应用相同的指导和最佳实践。例如，为了确保 Codex 按照我们的风格指南编写代码，我们已在顶层 AGENTS.md 中添加以下内容：

Codex 的优势

一旦认识到这些特性，我们的工作模型就会变得更加简单明了。我们依靠 Codex 在已知模式和明确范围内完成大量繁重的工作，而我们的团队则专注于架构、用户体验、系统性变更和最终质量。

即便新任资深员工能力再强，也无法立刻掌握长期权衡的精准视角。为了充分利用 Codex 并确保其运作的稳健性和可维护性，我们必须亲自监督应用的系统设计和关键权衡事宜。这些任务包括设计应用的架构、模块化、依赖项注入和导航；我们还实施了身份验证和基础网络流程。

在此基础上，我们编写了部分具有代表性的端到端功能。我们采用整个代码库都应遵循的规则，并在此过程中记录了项目级模式。通过将 Codex 指向具有代表性的功能，它能够在我们的标准范围内更加独立地运作。对于某个我们估计由 Codex 编写了 85% 代码的项目，精心规划的基础可避免代价高昂的回溯和重构。这是我们做出的关键决策之一。

我们的目标并非尽快开发“能运作的程序”，而是打造出“符合预期运作方式的程序。”编写代码的“正确”方法多种多样。我们无需提示 Codex 应执行哪些操作，而是需要向其展示我们团队定义的“正确”操作。一旦我们确定了切入点和构建方式，Codex 就能开始执行操作。

为了解实际运行情况，我们确实会尝试以下提示：“基于 iOS 代码构建 Sora Android 应用。开始吧”，但我们很快就放弃了这个方案。虽然 Codex 创建的技术具备可行性，但产品体验并不理想。由于对端点、数据和用户流缺乏清晰的理解，Codex 的一次性代码并不可靠（即使未采用智能体，合并数千行代码也是有风险的）。

我们推测，在精心编写的示例所构成的沙盒中，Codex 能发挥最佳性能；而事实印证了这一点。在几乎没有任何上下文的情况下，要求 Codex“构建这个设置界面”并不可靠。要求 Codex“使用与你刚才看到的另一个界面相同的架构和模式来构建此设置界面”，则更为有效。人类负责结构性决策和设定核心约束，随后 Codex 在此结构内填充大量代码。

为了进一步挖掘 Codex 的潜力，我们的下一个目标是攻克其自动化运维难题 — 即如何让 Codex 在无人值守的情况下，实现超长时间（近期已突破 24 小时⁠）的持续稳定运行。

在刚开始使用 Codex 时，我们经常直接用这样的提示：“这是要实现的功能，这是相关文件，把它做出来。”这种方法颇为有效，但大多数情况下生成的代码在技术上可以编译，但却偏离了我们的架构和目标。

因此，我们更改了工作流程。对于任何实质性变更，我们首先要求 Codex 帮助我们理解系统和代码的运作原理。例如，我们会要求它读取一组相关文件并总结该功能的运作原理；例如，数据如何从 API 流向存储库层、视图模型，并进入用户界面。然后，我们会纠正或完善其理解。（例如，我们会指出某个抽象实际上属于不同的层级，或者某个类只适用于离线模式，而不应扩展）。

就像你可能会与一位新入职且能力出众的队友合作一样，我们也与 Codex 共同制定了完善的实施计划。该计划看似一个微型设计文档，用于指示哪些文件需要更改，哪些新状态应引入，以及逻辑流程应如何调整。然后，我们才会要求 Codex 开始逐步实施计划。一个实用提示：对于冗长的任务，当我们达到上下文窗口的限制时，我们会要求 Codex 将其计划存入一个文件，以便在不同实例中应用相同的方向。

事实证明，这一额外的规划环节值得投入时间。由于我们掌握了 Codex 的计划，因此我们可以确保其在“无人监督”的情况下长时间运行；并轻松完成代码审核，因为我们可以根据计划检查实施情况，而无需在缺乏上下文的情况下研究差异。当出现问题时，我们可以先调试计划，然后再调试代码。

这种动态策略就像一份完善的设计文档，让技术负责人对项目充满信心。我们不仅仅是在生成代码，而是在生成可支持共享路线图的代码。

在项目高峰期，我们经常会同时运行多个 Codex 会话。一个会话负责回放，一个负责搜索，一个负责错误处理，还有一个则负责测试或重构。这不像是在使用工具，而更像是在管理一个团队。

每个会话都会定期向我们返回进度报告。有的会话可能会表示：“我已完成该模块的计划；以下是我的建议。”而另一个会话则可能会针对某项新功能做出大量更改。每个会话都需要关注、反馈和审核。这与技术主管管理多名新任工程师的场景非常相似，所有人都在不断进步，每个人都需要指导。

其结果是形成协作流程。Codex 的原始编码能力帮助我们摆脱了大量手动输入工作。我们可以投入更多时间来思考架构，仔细研究 Pull Request（合并请求），并测试应用。

同时，效率的提升意味着我们的审核队列中总是存在待处理的项目。Codex 不会因上下文切换而受阻，但我们却会受其影响。我们在开发中的瓶颈从编写代码转变为制定决策、提供反馈和整合变更。

这也为布鲁克斯的洞察提供了全新的立足点。你不能仅仅通过增加 Codex 会话就期望获得线性的速度提升，正如你无法通过不断增派工程师就指望项目工期线性缩短一样。每增加一双“手”，即使是虚拟的，也会增加协调工作的开销。我们已经从速度更快的独奏者转变为乐团的指挥。

我们基于关键里程碑启动项目：Sora 已面向 iOS 系统正式发布。我们经常将 Codex 指向 iOS 和后端代码库，助其理解关键要求和限制条件。在整个项目中，我们常开玩笑说：我们重新定义了跨平台框架的概念。忘掉 React Native 或 Flutter 吧；跨平台的未来正是 Codex。

这句俏皮话背后有两个原则：

根据这些原则，我们在同一环境中运行 iOS、后端和 Android 代码仓库。我们会给 Codex 提供提示，例如：

“读取 iOS 代码中的模型和端口，然后制定一个计划，利用我们现有的 API 客户端和模型类在 Android 中实现等效行为。”

一个小而实用的技巧是在 ~/.codex/AGENTS.md 中详细记录本地代码仓库的位置及其内容。这有助于 Codex 轻松探索和浏览相关代码。

实际上，我们通过转换而非共享抽象来进行跨平台开发。由于大部分转换工作由 Codex 负责，我们可以借此避免实施成本加倍增长。

更广泛的教训是，对于 Codex，上下文就是一切。当 Codex 理解功能在 iOS 系统中的运行方式，并结合我们对 Android 应用结构的认知时，它就能发挥最佳水平。当 Codex 缺乏上下文时，它并不会“拒绝合作”，而是在盲目猜测。我们越是把它视作新队友，并提供正确的输入，它的表现就会越好。

在为期四周的冲刺阶段结束后，使用 Codex 已不再像一次实验，而是成为了我们默认的开发循环。我们用其来理解现有代码、变更计划，并实现功能。我们以审核队友交付成果的方式，对其输出进行审核。这就是我们发布软件的方式。

显然，AI 辅助开发并未减少对严谨性的需求，反而会增加这种需求。尽管 Codex 功能强大，但其目标是立即从 A 到达 B。正因如此，AI 辅助代码编写无法在缺乏人工干预的情况下正常运作。软件工程师能够理解和应用系统的现实限制条件、最理想的软件架构方法，并在考虑未来开发和产品计划的情况下进行构建。未来软件工程师的超能力，将是对系统的深刻理解，以及与 AI 长期协作的能力。

软件工程最有趣的环节是构建引人注目的产品、设计可扩展的系统、编写复杂的算法，以及在数据、模式和代码中进行实验。然而，无论过去还是现在，软件工程的日常往往更为平凡：调整按钮位置、对接端口以及编写样板。如今，Codex 帮助我们专注处理软件工程中最具价值的任务，并保留了我们热爱这门技艺的初心。

一旦将 Codex 放入上下文丰富的环境中，助其了解你的目标和偏好的构建方式，任何团队都能加倍提升其能力。我们的发布回顾并非“放之四海而皆准”，也并未声称已解决 AI 辅助开发的问题。但我们希望：我们的经验能助你轻松确定赋能 Codex 的最佳方式，从而赋能团队。

七个月前，当 Codex 推出研究预览版时，软件工程的面貌与现在大不相同。借助 Sora，我们得以探索工程的新篇章。随着我们的模型和工具不断优化，AI 将成为构建过程中不可或缺的组成部分。

你会用自己的 Codex 团队创造什么呢？