十个要点,零份文档:OpenAI Codex 团队如何在混沌中极速造船

Photo by Clint Patterson on Unsplash

一个产品从八个人膨胀到近百人，几个月内用户量暴涨 20 到 30 倍。在同一时间窗口里，这支团队写过的”产品需求文档”几乎为零。设计师每天提交的代码量，超过了半年前一个工程师的产出。产品经理不认为自己是领导者——他把自己定义为”填补缝隙的人”。

这是 OpenAI Codex 团队在 2026 年春天的真实切面。

一、1200 token/秒：当思考速度追上打字速度

Romain 打开了一个他正在搭建的 iOS 应用。他没有翻阅任何设计稿或任务看板，只是对着麦克风说了一句：”给这个应用加一个新页面，关于 NASA 的 Artemis 重返月球计划。”GPT 5.4 开始运转，几十秒后，一个全新的页面出现在模拟器里。

但这不是他想展示的重点。

他把屏幕一分为二——左边是 GPT 5.4，右边是 Codex Spark。同一个任务发出去，左边还在思考的时候，右边已经写完了。平均速度：1200 token/秒。

“这个速度意味着什么？”他没有停下来解释。他直接打开了一个刚用 Codex 搭的 2D 小游戏——就在录制开始前几分钟做的。游戏里有一条可以走动的道路，但什么装饰都没有。主持人 Peter Yang 随口说了句：”加点装饰吧，树啊，房子啊，热闹一点。”

Romain 对着 Codex Spark 说了一句”加一些装饰，比如树”，发送。几秒钟后，画面上冒出了树。不是占位符，是渲染好的、可以交互的游戏元素。他继续玩这个游戏，好像什么都没发生过。

两种模型，两种节奏。GPT 5.4 可以处理百万行代码的迁移任务，耗时数小时甚至数天。Codex Spark 则是另一回事——它的设计目标是让你在灵感涌现的瞬间不被工具拖慢。Romain 把 Codex 的对话窗口弹出来，悬浮在屏幕顶部，随时呼唤，随时消失。写代码的体验开始像呼吸一样自然：你想到什么，它就出现。

我自己搭 Alpha OS 的体验印证了这一点，但也暴露了一个 Romain 没提到的瓶颈：执行速度追上来之后，瓶颈不是写代码，是判断。Agent 可以在几秒内给你十个方案，但你得知道哪个方案的二阶效应会在三周后咬你一口。我 48 小时内从零搭了整个 Alpha OS，迭代了 20 个版本——速度不是问题。问题是我现在回看那 48 小时，真正耗时间的不是让 Agent 写代码，是我自己在脑子里”感觉哪里不对”的那些时刻。感觉比思考先到，但把感觉翻译成明确的判断，Agent 帮不了你。

二、十个要点代替一切文档

Peter Yang 问了一个每个产品经理都关心的问题：你们还写 spec 吗？

Alex 的回答简洁到令人不安：”我们在 Codex 团队几乎不写 spec。”

不是”精简了文档”，不是”用模板代替长文档”，而是——几乎不写。只有在一个问题复杂到一个人的大脑装不下、或者需要跨几个人协调、又或者面临真正棘手的技术决策时，他们才会写点东西。而就算写了，也就是十个要点左右的长度。

这种工作方式有一个前提条件：当一个人能做的事情变多了，需要协调的界面就变少了。过去一个功能可能需要工程师写代码、设计师出视觉稿、PM 写需求文档、然后三方对齐。现在 Codex 团队的设计师直接写代码——不是写伪代码，不是画草图让工程师实现，是真的提交 PR、进入生产环境的代码。Alex 开玩笑说，团队里的设计师”现在写的代码比半年前一个工程师还多”。

而 PM 自己呢？Alex 坦承团队曾因为他提交的 PR 数量太少而”嘲笑”他。他没有给出具体数字，只是说”确实应该更多”，尤其考虑到其中很多还是很小的改动。但他紧接着说了一件更有意思的事：写代码已经不是瓶颈了。agent 可以写代码。真正重要的是，你决定做什么。

他把自己使用 Codex 的方式分成了几层。最简单的改动，直接给 Codex 一条指令就发出去了。中等复杂度的，可能先让 Codex 出一个方案，自己看一眼再决定。但真正有意思的是第三层——他有时候脑子里甚至没有一个明确的功能需求，只是有一个模糊的问题。他会打开 Codex，让它自己去探索代码库、问他几个问题、提出一些可能的方向。

“我经常不会真正使用这个输出，”他说。”因为这可能是一个很复杂的改动，我不想成为那个长期维护它的人。但走完这个过程之后，我对问题的理解会深很多。然后我把这种理解——不是 plan 本身，而是思考的过程——分享给工程师。”

一个 PM 用编程工具做的最有价值的事，不是写代码，而是用它理解系统。

这里面藏着一个更深的认知转变。过去 PM 的核心价值之一是”翻译”——把用户需求翻译成工程师能理解的语言，把技术约束翻译成商业决策者能接受的框架。但现在翻译成本降为零了。PM 可以直接进入代码的语境里思考，不再需要事先把问题抽象成文档格式。文档存在的意义是让信息在人脑之间传递，但如果你可以让 agent 帮你直接触摸到问题的本体，那文档就退化为一种低带宽的沟通方式。

十个要点不是简陋。是他们发现，在 agent 辅助下，一个人的认知带宽足以覆盖过去需要一份文档才能装下的内容。

三、让产品隐形：Codex App 的设计哲学

Alex 分享了一个 Codex 团队内部频繁使用的思考框架：产品的核心原语（core primitives）是什么？

这个问题听起来抽象，但他举了一个非常具体的例子。Codex 的开源组件（harness）是用 Rust 写的，CLI、IDE 扩展和 Codex App 都共享同一套底层代码。这意味着无论你在哪个入口使用 Codex，底层跑的是同一套引擎。这个架构决策不是随机做出的——它是团队深思熟虑后确定的”核心原语”之一。

围绕这些原语，他们有一套明确的分层策略：

第一层：让产品隐形。Codex App 的理想状态是”不碍事”。不要在模型和用户之间塞太多 UI 概念。模型变强了，产品就自动变强。这不是 vibe coding 出来的——恰恰相反，核心原语的设计是团队最严肃、最认真写下来的部分。

第二层：给 power user 最大的配置自由。因为 harness 是开源的，最前沿的用户会自己改代码、fork 代码库、甚至抢先体验还没上线的功能。Alex 说了一件让人意外的事：他们经常在 Twitter 上收到用户投诉，说某个功能”有 bug”——但那个功能根本还没发布到正式版。用户是自己翻源码发现的，然后改了代码抢先用上了。

“这在我看来是产品最棒的一面，”Alex 说。”你最前沿的用户在和你一起生活在未来。”

第三层：把 power user 的发现简化给所有人。这是 Codex App 诞生的核心逻辑。2025 年底，GPT 5.2 之后，模型能力跨过了一个临界点——你可以把一个很长的任务委托给模型，它能独立完成。用户开始自发地用 tmux 开十几个终端窗口并行运行 Codex。有人拍了一张 Peter Steinberger 的工作台照片：三块显示器上排满了 18 个终端窗口，全在跑 Codex。

这是 1% 工程师的工作方式。但 99% 的开发者不会去学 tmux。

于是 Codex App 诞生了。启动时看起来就是一个聊天窗口。用着用着你发现有个侧边栏；再用一阵发现可以同时运行多个任务、在任务之间一键切换。Alex 把这种体验比作”玩游戏”——你在不断发现新功能，而不是被迫阅读一份操作手册。

这套分层逻辑我在 Alpha OS 里走过一遍完全相同的路径——底层是 Gene Protocol（知识基因组），中间是可配置的 workflow 和 skill，最上层是 /done、/remix 这些一条命令搞定的界面。但说实话，我做反了：我先搭了底层，然后花了大量时间让自己成为 power user，最后才想起来简化入口。Codex 团队的聪明之处在于他们同时维护三层，而且让用户自然地从外层往里探索。我的教训是：如果连你自己都要翻文档才能想起某个 workflow 怎么用，那这个”简单界面”就是假的。

这背后有一个产品团队很少公开讨论的张力：如果你只为 power user 设计，产品会变得无法理解（”你得整天刷 Twitter 才知道怎么用”）；但如果你只为入门用户设计，你最有价值的用户群会离开你。Codex 团队的回答是在架构层面解决这个矛盾——底层是高度可配置的开源组件，上层是极简的应用界面，两者共享同一套引擎。

四、不做中期规划：OpenAI 的时间哲学

Peter Yang 问了一个看起来很普通的问题：你们有年度路线图吗？Codex App 是怎么决定要做的？

Alex 的回答颠覆了大多数产品团队的思维方式：”两者都不是。”

他分享了一条来自 OpenAI 内部研究员 Andre 的建议，这条建议后来成了 Codex 团队的操作系统之一：在 OpenAI，你要么做近期规划，要么做远期规划，但绝对不做中期规划。

近期，指的是八周以内——这是上限。一个足够具体的目标，能让一支团队集中精力冲刺完成。八周之外的事？不要试图精确预测。

远期，则是一种”直觉”。不是路线图，不是 OKR，更像是一种对未来气氛的嗅觉。比如：一年后模型会更聪明；我们不会想把自己的电脑借给模型用，因为那意味着同一时间只能做一件事；我们会想要无限多的模型同时独立工作、自己检验结果、甚至自己部署和监控代码。

中间那段？就是传统意义上的”产品路线图”。Alex 的态度是：我们基本不做这个。

这不是懒惰，而是一种在极端不确定性下的生存策略。当底层模型的能力每几个月就跃升一个台阶，任何超过两个月的具体计划都会面临一个尴尬：你还没做完，前提假设就变了。

Codex App 的诞生过程完美地诠释了这种哲学。团队有一个长期方向性的判断：我们需要把 Codex 从特定的工作空间中解放出来。这是什么意思？如果你用 VS Code，你一次只能打开一个文件夹、一个 git work tree。CLI 也是一样——你在一个终端里只能做一件事。但他们的愿景是让用户同时委托给多个 agent，这些 agent 在云端独立运行、互不干扰。

所以他们需要一个”不和特定文件夹绑定”的本地体验。

没有 spec。团队里几个工程师在一次 hack week 上各自独立搭了不同版本的”Codex App”原型。Alex 甚至不记得 Romain 有没有也做了一个。唯一被正式写下来的东西，是”为什么我们认为应该做一个 App”——一份理由声明，而不是功能清单。

这个决定在内部是有争议的。IDE 扩展已经很受欢迎了，要不要继续优化那个？CLI 也有一批死忠用户。做一个全新的 App 真的有必要吗？

最终让这个决定落地的，不是某次 product review 上领导一锤定音。是用户自己用行为投了票——当 GPT 5.2 之后 Codex 的委托能力大幅提升，有人开始用十几个终端并行工作。这些人用行动告诉团队：你们的工具需要一个新的界面。

Codex 历史上的两次”气氛转变”清晰地标记了这条路径：

第一次是 2025 年 8 月。GPT 5 发布，交互式编程模型真正可用。Codex 团队做了一个关键决策——暂时搁置云端方案，先解决模型当前能解决的问题。他们发布了 Codex CLI 和 IDE 扩展。几个月内，用户量增长了 20 到 30 倍。

第二次是 2025 年 12 月到 2026 年 1 月。模型能力越过了另一个拐点：你可以把一个真正复杂的任务委托出去，模型能独立工作数小时。”回到委托愿景”的时机到了，Codex App 应运而生。

不做中期规划的另一面，是对”时机”的极度敏感。你不知道拐点什么时候来，但你要能在拐点到来的那一刻识别它，然后在八周内把它变成产品。

五、Peter Steinberger 和个人 Agent 的预兆

在这场对话里，一个名字被反复提到：Peter Steinberger。

Peter 是 OpenClaw 的创造者——一个开源的个人 agent 框架。Peter Yang 自己就是它的早期用户，而且已经上瘾了。他把银行信息、YouTube 数据、日历、邮箱全部接入了 OpenClaw。他老婆晚上看他对着手机说话，问”你在跟谁聊？”，他说”我在跟我的 OpenClaw bot 聊”。有一天这个 bot 给了他一段”极其粗暴但极其深刻的鼓励”，他说那是他从 AI 那里听过的最有洞见的话。

Alex 分享了一个细节。2025 年 10 月，他和 Peter 在旧金山 Fort Mason 散步。他没有直接说”我们在考虑做一个 App”，但他试探性地聊了聊”某种让委托工作变得自然的新界面”。

Peter 的回答是：他永远不会用这种东西。

几个月后，Peter 在 Twitter 上发推：”好吧，地狱冻结了。App 确实不错。”

Peter Yang 指出这是一项了不起的成就——说服一个同时打开 20 个终端窗口的人改用图形界面，这可不容易。

但 Peter Steinberger 在这个故事里的角色远不止”测试用户”。Romain 把他的贡献放在了一个更大的叙事里：如果你回看 Peter 整个 2025 年，他写了超过 40 个开源项目。日历的命令行接口、Twitter 的命令行接口、Gmail 的命令行接口……每一个看似零散的项目背后都指向同一个愿景——把你数字生活中的每一个触点都变成 agent 可以调用的工具。

他本质上是在给一个尚不存在的个人操作系统铺设基础设施。而当 Codex 的 skills 和自动化生态成型之后，这些工具找到了它们的自然栖息地。

“这不会只是一个编程 agent，”Romain 说。”这会变成任何一种个人 agent。”

Peter Steinberger 后来加入了 OpenAI。他的角色被低调描述为”帮助改进 Codex，同时推进下一代个人 agent 在 ChatGPT 中的落地”。Alex 说他不能分享太多细节。但话已经够清楚了：Codex 团队看到了一条路径——从编程工具到个人操作系统，从帮你写代码到帮你管理生活，而 Peter 的 40 个开源项目就是这条路径的早期地图。

六、PM 已死？No, 标签已死

对话进入最后三分之一时，Peter Yang 抛出了一个半挑衅性的问题：你之前是不是说”大多数团队不再需要那么多 PM 了”？

Alex 没有退缩。他说：”让我把这话说得更辣一点——如果一个初创公司在不到 20 个工程师的时候就有 PM，那是一个 red flag。”

但他真正想说的比这更微妙。

以前的世界有清晰的分工：设计师管视觉，工程师管代码，PM 管需求和优先级。你可能有一个”黄金比例”——多少工程师配一个设计师再配一个 PM。但现在这些边界在溶解。设计师用 Codex 写代码了。工程师用 Codex 分析用户反馈、自动把问题提交到 Linear 了。PM 用 Codex prototype 原型了——不是画原型图，是直接搭出一个可以运行的东西给团队看。

“所有职业阶梯之间的界线都在模糊，我们都是 builder。”

但这不意味着所有人都变成了同一种人。Alex 做了一个关键区分：与其问”我们还需要 PM 吗”，不如问”你到底对什么最感兴趣？”

如果你一直想当工程师，只是因为”团队需要有人做 PM 的活”才做了 PM——那现在你应该把自己删掉，回去做工程师。AI 和你周围的团队会填补你不想做的那些事。

如果你做 PM 是因为你骨子里对用户着迷，愿意花大量时间泡在用户群里，即使这会让你远离”造东西”的快感——那也许”PM”这个标签仍然有意义，只是它的内涵已经完全不同了。

“PM 只是一个标签，指的是一个能设计也能写代码、但对用户最感兴趣的人，”Alex 说。”你同样可以找到一个对用户非常感兴趣的工程师。所以这些标签正在失去意义。”

Romain 补充了一个具体案例：Stripe 在 250 名员工的时候，PM 数量是零——甚至没有 AI 的帮助。为什么？因为他们是工程师在给工程师建工具。他们自己就是最懂用户的人。但如果你的产品服务的是一个你不直觉理解的领域，那种”对用户的痴迷”就需要有人专职来做。

Alex 最后总结了两个观点，它们之间存在微妙的张力：

第一：”每一个问题领域都需要一个人来为它负责——但那个人不一定要是 PM。”

第二：”我不认为 PM 是一个领导岗位。我认为它是一个填补缝隙的岗位。偶尔这可能需要领导力——但即便如此，那种领导力也只是帮助人们对齐方向，而不是某个天才想出了正确的战略。”

“填补缝隙”听起来不性感。但这可能是对这个角色最诚实、也最适应 AI 时代的定义。当 agent 能写代码、分析数据、整理反馈，PM 剩下的价值不是”管理”，是在混沌中发现哪些缝隙正在裂开——然后在任何人注意到之前把它们补上。

“Fill in the gaps”这个定义精准到让我有点不舒服——因为我每天干的就是这个。我一个人 + AI 搭了整条 Agent 联邦，理论上什么角色都是我。但实际操作下来，我发现有一个能力是 Agent 完全替代不了的：知道什么时候该停下来问”我们到底在解决什么问题“。Agent 特别擅长往前冲，你给方向它就执行，执行得又快又好。但方向本身可能是错的——我做了二十多个 workflow，回头一看，真正高频使用的不超过五个。剩下的都是”感觉应该有”而不是”真的需要”。Alex 说的”fill in the gaps”，本质上是一种对缝隙的嗅觉——你得先闻到哪里裂了，才能补。这不是策略能力，更接近直觉。而直觉这东西，目前为止还是只有人有。

七、给我看你造了什么

对话接近尾声，Peter Yang 问了最后一个问题：你们招人看什么？

Alex 的回答可以归结为一个词：agency。

不是”有领导力”，不是”沟通能力强”。是那种”自己会动手做事”的人。他把 Codex 团队的入职体验描述为：”Welcome.” 没有了。没有 12 个递进难度的任务清单，没有 onboarding 文档，就是一个”欢迎”。

“我们需要那种自发启动、有精力、有想法的人。不介意和现有方案唱反调的人——因为那些方案大概率是我们偶然间做出的决定。”

当有人给他发消息表达兴趣时，他的阅读顺序是：

1. 有没有链接？如果有，他几乎总是会点进去看。
2. 有没有想法？如果有观点和提案，他会认真读。
3. 个人简介、职业经历、学校背景？他坦言自己”很少读这部分”。他最近才意识到，他完全不知道团队成员是哪个大学毕业的。

Peter Yang 的反应是：”太好了，我们终于生活在一个那些愚蠢的 credential 不重要的世界了。谁在乎呢？给我看你造了什么。”

Romain 从他自己负责的 Developer Experience 团队的视角补充了另一个维度。他在找的人不仅技术强、是 Codex 的重度用户，还要有一种分享的热情——喜欢教别人怎么用这些工具。他举了一个例子：Thomas，一个在开源社区造了 Codex monitor 工具的人，刚刚加入了他的团队。这个人的特质是”自己造得好，也喜欢教别人怎么造”。

Alex 在这一段最后开了个玩笑，但这个玩笑精准地概括了他们的招聘审美：

“DevX 的岗位描述是什么？一个很厉害的工程师，同时 Twitter 玩得很好。”

Romain 纠正说 Twitter 不够全面——在欧洲有人用 LinkedIn，其他地方有其它平台。但核心逻辑不变：在 AI agent 时代，最有价值的人才不是”会用工具”的人。是那些用工具造出东西、然后自发地把自己的发现分享给世界的人。

Codex 团队自己就是这种文化的产物。团队里很多正在使用的功能，最初都是工程师完全自下而上提出来的——因为他们自己想用，所以他们就造了。

参考资料：

• 标题：How OpenAI’s Codex Team Builds with Codex (43 Min) | Alex & Romain
• 主持：Peter Yang
• 嘉宾：Alex（Codex 产品负责人）、Romain（Developer Experience）
• 链接：https://www.youtube.com/watch?v=9qXc-THAvc0

小结

在 AI agent 时代，产品文档、职业边界和招聘标准正在同步瓦解——保留下来的只有两样东西：你选择做什么，以及你实际造出了什么。

Alex 是 OpenAI Codex 团队的产品负责人。这支团队在不到一年的时间里从 8 人扩展到近百人，用户量增长超过 20 倍。他管理着一个几乎不写产品文档的团队——设计师直接提交代码 PR，PM 用编程 agent 探索系统来替代写 spec。Romain 负责 Developer Experience，此前在 Stripe 从零做到 250 人的公司里经历过”零 PM”的模式。

“我们在 Codex 团队几乎不写 spec。如果写，也就是十个要点的长度。”Alex 如此描述他们的工作方式。在模型能力足够强的前提下，一个人的认知带宽可以覆盖过去一份文档才能装下的信息量。

核心洞察：Codex 团队不做中期规划——只做八周内的冲刺和远期的方向性直觉。这不是因为懒，而是因为底层模型每几个月就会改变所有前提假设。他们的关键能力是识别”拐点”——当模型能力突然跃升时，在八周内把它变成产品。2025 年 8 月和 12 月的两次转变完美诠释了这种策略。

关于 PM 角色的未来，Alex 给出了一个反直觉但极其诚实的定义：”我不认为 PM 是一个领导岗位。我认为它是一个填补缝隙的岗位。”当 agent 能写代码、分析反馈、整理需求，PM 剩下的价值是在混沌中找到正在裂开的缝隙——然后比任何人都先补上。