为什么 OpenAI 只用 4 个人做 Sora Android？
最近，OpenAI 发布了一篇技术博客《我们如何使用 Codex 在 28 天内构建 Android 版 Sora》。4 名工程师，28 天，从原型到全球上线，应用上线当天登顶 Play Store 榜首，99.9% 无崩溃率。
这不只是一个产品发布故事，我从中看到了软件开发方式正在发生的深刻变化。以下是我结合这篇博客和自己使用 AI 的经验，总结的一些思考。
一、为什么不堆人？
iOS 版 Sora 一经发布，使用量爆炸式增长，用户疯狂生成视频。而此时 Android 端只有一个小型内部原型，Google Play 上的预注册用户却在不断攀升。压力显而易见：必须尽快交付 Android 版本。
面对这种紧迫需求，传统做法是什么？堆人。拉一个 20 人的团队，加班加点赶工期。
但 OpenAI 没有这样做。他们只组建了 4 名工程师的小团队，配备 Codex 作为 AI 协作工具。18 天后发布内部版本，再过 10 天正式全球上线。整个过程消耗了约 50 亿 token。
这背后有深刻的道理。布鲁克斯在《人月神话》中早已揭示：向进度落后的项目增加人手，只会让项目更慢。因为沟通成本会随人数增加急剧攀升——人越多，花在对齐信息上的时间越多，真正写代码的时间反而越少。
而 AI 没有这个问题。它不需要开会，不需要同步上下文，不需要休息。精简团队 + AI 杠杆，让小团队也能爆发大能量，绕过了繁琐的协同内耗。
二、人机协作的正确姿势
这是整篇博客最核心的部分。OpenAI 工程师们摸索出了一套行之有效的人机协作模式，我把它拆解为四个层面。
2.1 心智模型：把 AI 当新入职的高级工程师
理解 AI 的正确方式，是把它想象成一位刚加入团队的资深工程师。
这位"新同事"能力很强：精通多种编程语言，能快速阅读和理解大型代码库，写代码速度飞快，还特别热衷于写单元测试。
但他对你的项目一无所知。他不知道你们的代码规范、架构约定、命名习惯，也不知道那些从不写进文档的"潜规则"——比如"这个模块我们一般不动"，"这个接口虽然看起来能用但其实有坑"。
如果你只是甩给他一句话需求，比如"帮我写一个用户管理模块"，他会自己做架构决策。这些决策可能在技术上是合理的，但大概率和你现有系统格格不入。他不会拒绝你的请求，但他会盲猜。
因此，高效使用 AI 的前提是：写好"入职指南"。
这份指南应该包括：
项目的技术栈和核心架构决策
代码风格和命名约定
模块间的依赖关系和边界
那些"我们这里一般这样做"的隐性知识
已有的代表性功能，作为参照物
OpenAI 团队的做法是：在代码库中维护大量 AGENT.md 文件，让 AI 在每次会话开始时就能快速理解项目背景。这些文件就像是给 AI 的"入职手册"，确保它在不同会话中都能遵循相同的规范和最佳实践。
2.2 亲手奠基，AI 盖楼
OpenAI 成功的关键在于：没有一开始就让 AI "全自动"开发。
他们强调，即使有 AI 辅助，核心系统设计必须由人类工程师亲手完成。具体来说：
第一步：亲自奠基（Laying the Foundation）
架构选择、模块划分、依赖注入、导航设计、身份验证、基础网络流程——这些决定了系统的骨架，必须由人类深思熟虑后落地。AI 的本能是"让功能跑起来"，而不是"考虑长期可维护性"。如果不加引导，它可能会在你希望扩展现有模型的地方引入新的视图模型，或者把本该放在存储库层的逻辑推向 UI 层。
第二步：树立范本（Representative Features）
工程师先手动编写几个代表性的端到端功能，遵循整个代码库都应该遵守的规则。这些功能定义了"什么是正确的代码"，成为 AI 的参照物。
第三步：AI 做填充
在既定的架构和范本约束下，AI 进行大规模的代码生成。有了精心规划的基础，就能避免代价高昂的回溯和重构。
OpenAI 团队提到，在部分模块中，他们估计 Codex 编写了约 85% 的代码。但这 85% 是建立在人类打好的 15% 地基之上的。
他们也尝试过直接让 AI "基于 iOS 代码构建 Android 应用"，但很快放弃了这个方案。虽然 Codex 生成的代码在技术上可以运行，但产品体验并不理想。缺乏对业务流程和用户体验的清晰理解，AI 的一次性代码并不可靠。
我们的目标不是尽快开发"能运行的程序"，而是打造"符合预期运作方式的程序"。
2.3 先规划后编码
这是新范式中最具颠覆性的一环：将开发重心从"编写代码"转向"编写计划"。
传统开发中，我们拿到需求就开始写代码，遇到问题再改。但在 AI 辅助开发中，OpenAI 工程师采用了不同的流程：
第一步：让 AI 先输出计划
对于任何实质性变更，不直接下达"写代码"的指令。而是先让 AI 阅读一组相关文件，总结现有功能的运作原理——比如数据如何从 API 流向存储库层、视图模型，并进入用户界面。然后工程师纠正或完善 AI 的理解。
接下来，与 AI 共同制定一份实施计划。这份计划像一个微型设计文档，指明哪些文件需要更改，哪些新状态应引入，以及逻辑流程应如何调整。
第二步：在计划层面解决问题
如果发现数据库设计不合理、API 契约有误、模块边界不清，直接修改计划。调试计划的成本几乎为零，而调试已生成的成千上万行代码则代价巨大。
第三步：计划确认后再执行
一旦计划经过审核，AI 按计划生成代码的准确率会大幅提升。而且代码审核也变得更容易——可以根据计划检查实施情况，而不是在缺乏背景的情况下研究代码差异。
一个实用技巧：对于较长的任务，当背景窗口达到限制时，可以让 AI 把计划存入一个文件，以便在不同会话中延续相同的方向。
这个转变的本质是：把人类的注意力从"怎么写"转移到"写什么"。
事实上，这种"先规划后编码"的理念已经被系统化成了一套开发范式：SDD（Spec-Driven Development，规范驱动开发）。
传统的 AI 编程交互往往是这样的：
用户：帮我实现一个用户认证系统
AI：好的，我来帮你实现...（生成 500 行代码）
用户：不对，我想要 JWT 认证，不是 Session
AI：好的，让我重新实现...（又生成 500 行代码）
用户：等等，我还需要双因素认证...这种"边做边改"的模式被称为 Vibe Coding（氛围编程）——需求散落在对话历史中，AI 自由发挥，每次修正都需要重新生成代码。
SDD 的核心理念是：先写规范，后写代码。在让 AI 动手之前，先用一份清晰的规范文档定义系统应该做什么。规范文档成为"唯一真理来源"，AI 是按规范执行的实现者，而非自由创作者。
标准的 SDD 流程分为四个阶段：
Specify（规范定义）：用自然语言描述需求、用户故事、约束条件
Plan（计划制定）：与 AI 协作，将需求转化为技术设计和任务清单
Implement（执行实现）：AI 按照规范和任务清单逐个执行
Archive（归档更新）：实现完成后，将变更合并到主规范文档
这和 OpenAI 工程师的做法如出一辙——他们让 AI 先输出计划、在计划层面解决问题、计划确认后再执行，本质上就是 SDD 的实践。
目前已经有一些工具支持 SDD 工作流：
OpenSpec：轻量级 SDD 框架，专注于变更管理，适合改造现有项目
spec-kit：GitHub 推出的 SDD 工具包，提供完整模板和阶段验证
Kiro.dev：AWS 推出的专用 SDD IDE，内置完整的规范驱动流程
如果你正在寻找一种更可控、更可审查的 AI 编程方式，SDD 值得一试。
2.4 并行指挥：从独奏者到指挥家
由于 AI 不存在沟通损耗，一名工程师可以同时开启多个会话，并行推进不同模块。
在项目高峰期，OpenAI 团队经常同时运行多个 Codex 会话：一个负责回放功能，一个负责搜索，一个负责错误处理，还有一个负责测试或重构。每个会话都会定期返回进度报告。
这不像是在使用工具，更像是在管理一个团队。每个"AI 下属"都需要关注、反馈和审核——就像技术主管管理多名新任工程师，所有人都在同时推进，每个人都需要指导。
工程师的角色从"写代码的人"变成了"指挥 AI 的人"。
事实上，这种"指挥多个 AI 代理"的需求已经催生了专门的工具。比如 Vibe Kanban 这个开源项目，它的定位就是帮助工程师管理多个 AI 编码代理。
请至钉钉文档查看附件《一款AI编程智能体任务看板工具：Vibe Kanban，帮你把AI编程效率再放大10倍它把不同Age.mp4》
它提供了一个看板界面，让你可以：
在 Claude Code、Codex、Gemini CLI 等不同代理之间切换
并行或顺序编排多个代理的执行
追踪每个代理正在处理的任务状态
快速审查代理的产出并启动开发服务器
这类工具的出现印证了一个趋势：当 AI 成为生产力工具，管理 AI 本身也变成了一项需要工具支持的工作。我们正在从"一个人写代码"进化到"一个人指挥一群 AI 写代码"。
但这也带来了新的瓶颈：开发中的卡点从编写代码转变为制定决策、提供反馈和整合变更。AI 不会因为上下文切换而受阻，但人类会。审核队列中总是有待处理的项目。
三、跨平台的新思路
以前解决跨平台问题，我们要么学习 React Native、Flutter 这样的跨平台框架，要么老老实实写两套原生代码。
OpenAI 展示了一个新思路：让 AI 做语义级翻译。
他们让 Codex 阅读已有的 iOS（Swift）代码，理解其业务逻辑和数据流，然后将其翻译为 Android（Kotlin）代码。这不是简单的语法转换，而是在理解业务逻辑的基础上，用目标平台的惯用方式重新实现。
这种方式的优势在于：
保持原生性能：没有中间抽象层，两端都是纯原生代码
降低学习成本：团队不需要额外掌握跨平台框架
逻辑一致性：核心业务逻辑从源平台"翻译"而来，天然保持一致
当然，这种方式对 AI 的代码理解能力要求很高，目前可能还不适用于所有场景。但它指向了一个有趣的方向：跨平台的终极解法也许不是抽象层，而是翻译层。
四、延伸思考：从 MVP 到高保真模拟
传统敏捷开发推崇 MVP（最小可行性产品）：想造汽车？先给用户一个滑板，收集反馈，再做自行车，然后摩托车，最后才是汽车。
MVP 是有道理的，但很多时候它是妥协的结果：用户需求不明确，需要先投石问路；产品经理自己也没完全想清楚；工期紧张，编码成本高，一次性做完风险太大。既然没法一步到位，那就先给你个能跑的东西再说。
但 AI 正在改变这个等式。
当编码成本被大幅压缩，工程师可以使用 AI 迅速产出可运行的高保真 Demo，而非简陋的原型图。产品经理在真正动工前就能"试驾"产品细节，把需求冲突和体验问题暴露在最早期。换句话说，我们可以更早地"想清楚"，而不用边做边猜。
这让我想起李安拍《少年派的奇幻漂流》的做法。为了在茫茫大海中捕捉那只并不存在的孟加拉虎，他没有直接开机，而是先耗资制作了一部完整的动画预览。每一组分镜、光影、水的流动都在动画中被精确模拟。当电影正式开拍时，所有的不确定性已在模拟中被消解，剩下的只是精准的执行。
AI 时代的软件开发正在走向同样的方向：先用 AI 进行高保真模拟，把"想清楚"前置，然后再精确实现。这避免了在正式代码库中留下大量由于需求反复而产生的技术债。
结语
AI 辅助开发并没有降低对工程师的要求，反而增加了对系统深度理解能力的要求。
我们的工作不再是"写代码"，而是：
经营上下文：维护好 AI 需要的"入职指南"
做出架构决策：把握系统的骨架和方向
审核计划与输出：确保 AI 的产出符合预期
如果说传统开发是在黑夜里摸索着修路，修一段看一段，修错了再拆；那么新范式就像是先用全息投影绘制出整座城市，在投影中讨论交通流、测试承重，等一切完美后再按下执行键。
你依然是那个造城的人，但你手里握着的，不再是铁锹，而是蓝图与指挥棒。