Codex负责人谈AI时代唯一值钱的能力是什么

自今年 1 月以来，AI 编程赛道最亮眼的产品非 Codex 莫属。用量涨了 6 倍，如今周活用户已经突破 500 万。在 OpenAI 内部，近 90% 的员工每周都会用 Codex——注意，不是工程师的 90%，而是整个公司的 90%，连法务、财务、市场、传播等部门的人都在用。

Codex 的负责人 Andrew Ambrosino 背景挺有意思：设计师出身，后来转做工程师，再做到产品经理，中间还创过好几次业。最近他在一档播客里聊了不少关于 Codex 的产品理念和哲学，以及一个更关键的问题——当 AI 让“实现”这件事变得几乎免费，“该做什么”这个决定权，究竟在谁手里？

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

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

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 自动布局’，那就该干嘛还是干嘛。”

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

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Codex负责人谈AI时代唯一值钱的能力是什么要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题