摘要
- 小团队 + AI 代理 = 超常产出：4 名工程师借助 Codex，在 28 天内将 Sora Android 版从原型推向全球发布，上线首日登顶 Google Play。
- 布鲁克斯法则的现代诠释：面对紧迫的交付压力，团队选择"少而精"而非"堆人头"，用 AI 放大每位工程师的产出，而非增加沟通成本。
- Codex 贯穿全流程：从架构搭建、功能开发、测试编写到缺陷修复，Codex 在每个阶段都深度参与，功能开发速度约为传统方式的 3 倍。
- 人工审查不可或缺：AI 生成的代码同样需要严格的人工审查，Codex 是"放大器"而非"替代者"。
- 高质量可以与高速度并存：最终应用崩溃率仅 0.1%，上线 24 小时内用户生成超过 100 万条视频。
文章信息
- 来源： OpenAI Blog
- 发布日期： 2026-02-01
- 原文： English Original
去年 11 月，我们面向全球发布了 Sora Android 应用，让每一位 Android 用户都能通过一段简短的提示词生成生动的视频。发布当天，应用即登上 Google Play 下载榜第一名。Android 用户在头 24 小时内生成了超过 100 万条视频。
这次发布背后有一个故事：Sora 生产级 Android 应用的初始版本在 28 天内构建完成，所依赖的正是任何团队或开发者都可以使用的同一个代理 -- Codex。
从 2025 年 10 月 8 日到 11 月 5 日，一支精干的工程团队与 Codex 协同工作，消耗了约 50 亿 token，将 Sora Android 版从原型推进到全球发布。尽管规模不小，应用的无崩溃率达到了 99.9%，架构质量也令我们引以为傲。如果你好奇我们是否使用了某个秘密模型 -- 我们使用的是 GPT-5.1-Codex 的早期版本，与任何开发者或企业今天通过 CLI、IDE 插件或 Web 应用所能使用的版本完全相同。
Sora 在 iOS 上线后，使用量迅速爆发。用户不断涌入并生成大量视频。而在 Android 端，我们仅有一个小型内部原型，以及 Google Play 上不断增长的预注册用户。
面对高风险、时间紧迫的发布，常见的做法是堆积资源、增加流程。这种规模和质量的生产级应用，通常需要许多工程师花费数月时间，并且受到大量协调工作的拖累。
美国计算机架构师 Fred Brooks 有一句名言："向一个已经延期的软件项目增加人手，只会让它更晚完成。"换言之，在试图快速交付复杂项目时，增加工程师数量往往会因沟通开销、任务碎片化和集成成本的增加而降低效率。我们选择顺应这一洞见而非忽视它 -- 我们组建了一支 4 人精锐工程团队，每位成员都配备了 Codex，从而大幅提升单个工程师的产出。
以这种方式工作，我们在 18 天内将 Sora Android 的内部构建版本交付给员工使用，并在 10 天后正式对外发布。我们坚持了 Android 工程的高标准实践，投入了可维护性建设，并以与传统项目同等的可靠性标准来要求这款应用。（我们今天仍在广泛使用 Codex 来持续演进应用并带来新功能。）
Codex 是开发各个阶段的核心组成部分。以下是我们的具体用法：
我们首先使用 Codex 搭建应用的整体架构。Codex 生成了初始项目结构，配置了依赖注入，并串联了导航图 -- 这些工作在传统流程中通常需要数天的模板化劳动。
对于每个主要功能，我们用自然语言描述需求，然后让 Codex 生成初始实现。工程师负责审查、优化并集成代码。这使我们在功能开发上的速度大约是传统开发方式的 3 倍。
Codex 编写了我们绝大多数的单元测试，并帮助识别了我们未曾考虑到的边界情况。我们还使用它为视频生成流水线编写了集成测试。
当问题出现时，Codex 往往是我们拿起的第一个工具。我们描述缺陷，将相关代码指给它，它就会提出修复方案 -- 找到根因的速度通常比手动调试更快。
数据本身就是最好的说明：
小团队 + AI 放大可以超越大团队。 Codex 并没有取代工程师 -- 而是放大了他们。每位工程师都能承担起远超常规团队规模的工作量。
AI 在清晰的规格说明下表现最佳。 我们对需求描述得越精确，Codex 的表现就越好。模糊的提示只会产出模糊的代码。
人工审查依然不可或缺。 Codex 极大地加速了开发，但每一行代码都经过了人工审查。AI 生成的代码需要与人工编写的代码接受同等程度的审视。
从架构入手。 在早期就把基础打好 -- 借助 Codex 的帮助 -- 意味着后续的功能开发能够顺畅推进。
我们相信，这就是未来软件构建方式的预演：小而专注的团队与 AI 代理并肩工作，以前所未有的速度交付雄心勃勃的产品。