当实现变得几乎免费，谁来决定“该做什么”？

自今年1月以来，Codex已经成为AI编程领域最受瞩目的产品之一。周活用户已突破500万，增幅达到6倍。更值得注意的是，在OpenAI内部，接近90%的员工每周都在使用Codex——这里说的不是90%的工程师，而是包括法务、财务、市场、传播在内的整个公司。

Codex的负责人Andrew Ambrosino，背景很有意思。他是设计师出身，后来转型工程师，再做产品经理，期间还多次创业。最近他在一档播客节目中，详细分享了Codex的产品理念和方法论，以及一个更深层次的问题：当AI让“实现”几乎零成本，“该做什么”这件事，究竟由谁说了算？

一个老问题：为什么AI至今做不好设计

不久前，Codex的竞品Claude Code的设计负责人Jenny Wen提出了一个观点：设计流程已经死了。因为东西动得太快，根本没时间按传统流程走。

这个观点引发了不少讨论。Andrew看到了，也同意设计流程死了，但理由不同。他回忆起早年在一家创业公司负责设计招聘时，行业里流行一篇文章叫“案例工厂”，是2019年发表在UX Collective上的名篇。核心观点是：设计师被教成了一套流程至上的人——从用户研究、发散、收敛、原型验证，只要走完这套流程，结果就一定好。

“我在AI出现之前就不喜欢那个流程。”Andrew说。流程本身没问题，但执着于流程，会把它凌驾在结果之上。

AI出现后，任何人都能快速做出一个看起来非常精致的原型。过去，看到一件东西像产品，潜意识里会默认它已经走到流程晚期——假设已被消除、设计已审核、业务目标已对齐。现在，这种“精致”和“真正准备上线”之间的关联已经断裂。Andrew的描述是：

“现在你可以把完整的实现拉进设计流程的最早期。一个打磨得无比精致的原型看起来就像能上线，但它实际上还在探索阶段——只是没人告诉你这一点。九十个人都会有同一个想法，每个人都做出来了，看起来很精致——但这不是产品。这就是现在的设计流程。”

Codex团队内部的解法，是一个叫“baby Codex”的极简代码库，专门用来快速探索交互方案，不追求生产级代码。

“我们有个叫baby Codex的内部版本——一个极度简化的代码库，用来快速探索交互方案。‘侧边栏能不能这样？面板能不能加个群聊？’这本身就是设计流程。”

那么设计流程到底死了吗？Andrew给了一个两面回答：

“既对也不对。如果你跟流程的具体工具绑死了，那确实完了。但把‘我们现在在流程的哪个阶段’这个框架扔掉，那才是最大的错误。”

至于AI在设计这个具体任务上为什么表现尤其差，Andrew的答案很直接：设计比代码更难打分。

“创造一个训练循环来区分好设计和坏设计，比判断代码能不能编译，要困难得多。因为品味中属于人的部分，是这个反馈机制必需的东西。”

他还补充了两个更深的问题。一是文化维度：AI可以完美复制Linear的设计风格，但每次出来的都是Linear，而设计需要的恰恰是新东西多于已知模式。二是抽象层：如果公司明天改品牌色，浅层做法是手动改263个组件，深层做法是让所有视觉元素共享同一套语义关系——这个抽象能力，目前的模型还够不着。

“给人类大脑鼓个掌吧。”他说。

同一个产品，模型换了，就改命了

Codex的前身可以拉出一条线：Operator → Atlas → Codex Web → Codex桌面端。Andrew认为这本质上就是同一个功能，在不同的时间点、搭配不同的模型能力，反复重新发布。

“这些其实都是同一个功能，一次又一次地重新发布。只不过每次搭配的智能水平不同。”

他给出了一个非常有说服力的例子：

“我非常确定，Codex桌面端如果去年11月发布，在市场上绝对会失败。而唯一的变量就是11月到2月之间的模型进步。同一个产品形态，结果完全取决于几个月的模型时间差。”

这里他还提到一个教训：他们曾经“在AGI这条路上走得太快了”。

“最初的Codex Web太AGI-pilled了——你给模型一个任务，它跑去做完回来告诉你，问题是它做得不够好。Claude Code反过来——完全本地、不接云端、不强求全自动，它会问你问题、等着你。那个形态才适合当时的模型水平。我们在AGI这条路上走得太快了。”

这个说法听着有些为自己挽尊的意思，但不重要，及时调转船头就行。Andrew现在的逻辑是：不要因为一个功能现在不行就判它死刑。列出未来一两年所有想做的事，全部做成原型，哪些现在够成熟就上，剩下的交给时间。每次模型有一次飞跃，就把那件事再拿出来试一遍。功能好不好，很多时候不在于功能本身的形态，而在于它背后那个模型够不够聪明。

他怎么用Codex工作

Andrew每天早上打开Codex，首先看到的是一份每日简报。

“我每天早上醒来，看到Codex给我的每日简报——从我加入的3000个Slack频道里提取出来的。哪些需要我注意。我可以回复，‘给我五个问题，我来回答’。”

这个简报是怎么养出来的？不是靠写多么精确的指令。

“每次Codex自动任务跑了，如果不对，我不需要去改指令。我直接对它说：‘下次跑的时候注意这个’，‘这个东西没出现在简报里，能不能确保类似的东西以后出现’。它自己会更新通知方式。”

他最近一次产品发布的协调方式也很有意思：

“我有一个Notion文档列了所有要做的事。Codex自动从Pull Request、Slack频道收集进度更新，更新我的状态追踪表——这是我们第一次‘用vibe协调’的发布。”

整体来看，他的工作流并不局限在Codex当中，而是通过MCP等方式协同各个外部资源。可以参考，但不一定要借鉴——毕竟，他可是不用操心token计费的人。

Codex不是超级应用，是一个home base

外界一直有人把Codex和ChatGPT的关系往“超级应用”上靠——所有工具塞进一个窗口。Andrew明确不喜欢这个叫法，他用的词是home base。

“Codex不该是把你所有事都锁在一个矩形里的超级应用。它应该是一个home base——你在上面开始工作、结束工作、自动工作。它用各种连接器、浏览器、扩展跟你已经用的工具对话。你做重度财务建模时，它直接跟Excel桌面端交互，算完你就关掉Excel。”

最能说明这个理念的，是一个Premiere Pro的故事。OpenAI内部的视频编辑试着用Codex剪片子。

Codex不是视频编辑器，但它理解Premiere Pro的工作方式——能直接编辑Premiere背后的项目文件。做不了的操作，它做了一件更惊人的事：

“Codex自己给自己写了个Premiere Pro的扩展插件，然后通过扩展告诉Premiere：请把这里的时间标记移到那里。”

产品开发流程，已经被重塑

整个对话中，Andrew反复回到一个核心观察：AI把产品开发流程完全倒转了。

“任何人都能做出任何东西。你给人们无限token，每个人都在做东西。回头看看我们过去跑的产品流程——研究、构思、原型，所有这些都是建立在一个假设上：实现是昂贵的。所以你要用文档、研究、原型把所有实现风险提前消除。这个假设已经消失了。”

旧流程的逻辑是“实现贵 → 先写PRD、做研究、画原型来降风险 → 再动手”。新流程里实现便宜到几乎免费，于是同一个功能可能有90个团队在同时做原型。难事不再是“要不要做这个”，而是“做了这么多，哪个最好、哪些该合并、怎么收束”。

这意味着PRD已经死了吗？

“因为实现变得极其便宜，非工程师特别容易直接跳进原型。但对工程师来说，现在反而很容易写一堆没人想读的文档。关键不是扔了文档或扔了原型，而是选对媒介。”

Andrew收束整场对话的那句话，大概也是给所有在AI时代重新定位自己的人的一句建议：

“别跟你的具体流程结婚。跟你唯一能交付的结果结婚，然后该改流程就改流程。如果你最擅长的还是‘Figma自动布局’，那该干嘛还是干嘛。”

既然工具会变、模型会变、流程会过时，唯一不变的，应该是你交付独特结果的能力。