摘要
1) 一句话总结
OpenAI 仅用 4 名工程师在 28 天内完成了 Sora 安卓客户端的开发，其中约 85% 的代码由 AI（Codex）生成，且发布首日无崩溃率高达 99.9%，这主要得益于“架构先行、先规划后编码”的 AI 深度协作模式。
2) 关键要点
- 项目成果：4 人团队耗时 28 天完成开发，85% 代码由 AI 编写；App 发布首日 24 小时内生成超 100 万条视频，无崩溃率达 99.9%。
- 架构先行：人类工程师首先定义 App 的整体架构（模块化、依赖注入、导航、网络层等），并手写代表性功能作为范本，随后让 AI 进行“填空”。
- 建立 AI 规范：团队编写了大量
AGENTS.md文件作为 AI 的“新人手册”，明确团队的代码规范（如提交前需通过detektFix检查），告诉 AI 在团队中“什么才算正确”。 - 先规划再编码：开发复杂功能时，流程设定为：AI 理解系统 → 人类纠正 → AI 输出实现计划（设计文档） → 人类确认计划 → AI 开始编写代码，以此减少返工。
- 并行任务管理：同时运行多个 Codex 任务（如播放器优化、搜索、补测试等），工程师的角色从“编写代码”转变为“做决策和给反馈”。
- AI 跨平台翻译：将已有的 iOS 代码库接入 Codex 环境，让 AI 参考 iOS 的 Swift 实现和 Android 的架构，直接“翻译”生成对应的 Kotlin 代码。
- 核心能力演进：AI 辅助开发实际上提高了工程标准，未来软件工程师的核心能力在于对系统的深度理解以及与 AI 的长期协作能力。
3) 风险与不足（原文明确提及）
- 直接生成的架构偏离风险：如果跳过规划阶段，直接让 AI 根据需求和文件去实现复杂功能，生成的代码虽然能运行，但会严重偏离架构预期。
- 人类审查成为瓶颈：当多个 AI Agent 并行工作时，开发的瓶颈不再是敲代码的速度，而是人类大脑审查和验证代码的速度。
- Agent 数量的扩展限制：不能无限增加 AI Agent 的数量，因为最终仍需要人类去分配任务、验证结果并维持系统平衡。
- 传统增加人力的负面效应：在软件工程中，单纯向延期的项目增加人力会因沟通、任务碎片化和整合成本，导致效率降低、延期更严重（《人月神话》定律）。
正文
刚看了 OpenAI 发的那篇《How we used Codex to build Sora for Android in 28 days》https://openai.com/index/shipping-sora-for-android-with-codex/ 的“凡尔赛”文章
整个 Sora 的安卓客户端 App 大约 85% 的代码是 AI 写的。发布首日，用户 24 小时内生成了超过 100 万条视频，并且质量很稳定，无崩溃率 99.9%。
对于这样的结果肯定有人质疑有人觉得程序员要完。说说我看完的感觉，如果打个比方，就是几个特种兵配上了最先进的武器，自然所向披靡。所以先不用神化这个结果，然后就算我们不是特种兵，一样可以从这个结果中去学习借鉴到有价值的结果。
《人月神话》作者 Fred Brooks 说过一句软件工程中被反复验证的名言：“向一个延期的软件项目增加人力，只会让它延期得更厉害”。
因为增加更多的工程师往往会因为增加了沟通成本、任务碎片化和整合成本，反而降低效率。
那往团队中加 AI 呢？
取决于团队成员驾驭 AI 的能力。我们有句古话叫：“韩信带兵多多益善”，如果团队成员是韩信，那么 AI Agents 越多越好。OpenAI 安卓团队显然是精锐，只有 4 个人，就像一队特种兵，每个人配备了各种机器人辅助。
那么他们怎么做的呢？
1. 架构先行：人先搭好架子，再让 AI 来填空
这个架子怎么搭？
团队先自己定义了 App 的整体架构：模块化方案、依赖注入、导航结构、认证流程、基础网络层。然后手写了几个有代表性的功能，作为范本。
关键一步： 他们写了大量的 AGENTS.md 文件，相当于给 AI 写的新人手册。比如里面会写：每次提交前必须跑 detektFix 检查格式，CI 会卡这个。
这样一来，每次启动新的 Codex session，它都能快速读到这些规范。就像给新员工发一本内部 wiki，减少重复解释的成本。
团队总结了一句话：我们不需要告诉 Codex 怎么写代码，我们需要告诉它在我们团队什么才算正确。 这是微妙但重要的区别。
2. 先规划再写代码
一开始他们也试过偷懒，直接扔一句“这是功能需求，这是相关文件，你去实现”。结果代码能跑，但歪得厉害，完全不符合架构预期。
后来他们改了流程。任何复杂功能，第一步不是让 AI 写代码，而是让 AI 先理解系统。比如让它读一组相关文件，总结数据是怎么从 API 流到 Repository 再到 ViewModel 最后到 UI 的。然后人来纠正它的理解。
理解对了，再让 AI 出一份 实现计划，像个迷你设计文档。哪些文件要改，要引入什么新状态，逻辑怎么流转。人确认计划没问题，AI 才开始动手。
这个规划环节看起来慢了，其实省了大量返工。更重要的是，当你知道 AI 的计划是什么，review 它的代码就容易多了。你是在检查执行是否符合计划，而不是对着一堆 diff 发呆。
- 一个小技巧： 对于特别长的任务，让 AI 把计划保存到文件里。这样换一个 session 也能继续。
当多个 Codex 任务同时跑起来，整个开发体验发生了质变。感觉不像在用工具，更像在管理一个团队。
一个任务在做播放器优化，另一个在写搜索功能，第三个在处理错误逻辑，第四个在补测试。它们各自推进，隔一段时间就来汇报：我这个模块规划好了，你看看行不行？或者直接甩过来一个大 diff。
工程师的工作从写代码变成了做决策和给反馈。 瓶颈不再是敲代码多快，而是大脑审查验证代码的速度多快。
再次应验了《人月神话》的话，你不仅不能无限增加人力，也不能无限增加 Agent。
3. 最好的跨平台框架是 AI Agent
还有一个有趣的实践：跨平台开发的新范式。
Sora 已经有 iOS 版本了。团队做 Android 时，直接把 iOS 代码库也挂进 Codex 的环境里。然后告诉 Codex：参考 iOS 的代码实现，再看看我们 Android 的架构，你来生成相应的 Kotlin 代码。
这就是为什么文章中开玩笑说：忘掉 React Native 和 Flutter 吧，未来的跨平台框架就是 Codex。
这句话半认真半玩笑。因为应用逻辑是可移植的。数据模型、网络请求、校验规则，用 Swift 写和用 Kotlin 写，本质是同一套东西。AI 擅长的恰恰是这种翻译工作，给它足够的上下文，它就能在语言之间无损转换。
所以回过头来看，为什么说不能过度神化呢？
因为他们虽然只 4 个人，但每个人都是“韩信”那样善于带团队的角色，用起 Agent 来得心应手。但即使如此，也做不到“多多益善”，毕竟还是需要人去分配任务验证结果，人是平静。另外他们已经有了 iOS 代码，所以很多逻辑可以共用，只需要 AI 去“翻译”。
但还是有很多可以学习的地方：
-
先设计架构再去让 AI 填空： 这样代码更容易维护，也更好的保证质量。
-
先规划再写代码： 让 AI 充分理解上下文再动手。很多人吐槽 Codex 太慢，但我有时候就怕 Agent 太快乱来，宁可多等会，让它多了解上下文，这样一次成功，否则返工起来时间成本更高。
-
给 AI 好的参考： 让它能照葫芦画瓢。开始的时候先花点时间把最佳实践沉淀下来，后续让 AI 去参考这些最佳实践，生成结果就会好很多。如果有其他语言的实现，让它去“翻译”也会事半功倍。
能做好这些才能用好 AI 辅助开发。 AI 辅助开发不是让开发的标准降低了，反而是提高了标准。
Coding Agent 擅长完成一个小的具体任务，但软件工程不是一个小的任务，它是由无数动态变化的小任务组成的。需要人去分解去验证。
所以未来软件工程师的核心能力，不是写代码快，而是两件事：对系统的深度理解，以及和 AI 长期协作的能力。
代码在变得廉价，但品味在变得昂贵。 那些能定义什么是正确、什么是优雅、什么是面向未来的人，会越来越稀缺。
AI 把搬砖的活儿接走了，但画图纸的活儿还是你的。
相关文档
- 我们如何使用 Codex 在 28 天内构建 Android 版 Sora；关联理由：引用；说明：本文中的核心数据与方法流程直接来自该文并进行了二次解读。
- AI 真的会写 90% 的代码了；关联理由：观点一致；说明：两文都强调 AI 提升编码产出，但人类仍需负责架构、任务拆解与代码审查。