Full text · 原文
3,449 字
自今年 1 月以来，Codex 成了最明星的 AI coding 产品之一，用量增长 6 倍，目前超过 500 万周活用户。在 OpenAI 内部，近 90% 员工每周使用 Codex——不是 100% 的工程师，是 100% 的整个公司，包括法务、财务、市场、传播，都在用。<br>
负责 Codex 的 Andrew Ambrosino，是设计师出身，转工程师，再做 PM，多次创业。最近他作客播客节目，分享了 Codex 及其背后的一系列产品理念和哲学，以及更重要的问题：当 AI 让实现变得几乎免费，「该做什么」这件事，到底谁说了算？<br>
一个老问题：为什么 AI 至今做不好设计<br>
不久前，Codex 的竞品 Claude Code 的设计负责人 Jenny Wen 提出过一个观点：设计流程已经死了，东西动得太快，没时间按传统流程走。<br>
Jenny Wen<br>
这个观点引发不少讨论，Andrew 也看到了，他同意设计流程死了，但理由不一样。他回忆起早年在创业公司做设计招聘时，行业里流行一篇文章叫「案例工厂」，是一篇 2019 年发表在 UX Collective 上的著名文章，核心观点是设计师被教成了一套流程至上的人，从用户研究、发散、收敛、原型验证，只要走过这套流程，结果就一定好。<br>
「我在 AI 出现之前就不喜欢那个流程。」Andrew 说，并非流程本身有什么问题，但执着于流程，会把它本身凌驾在了结果之上。<br>
AI 出现之后，任何人都能快速做出一个看起来非常精致的原型。过去，你看到一个东西长得像产品，你默认它已经走到流程晚期，「假设已经被消除、设计已经看过、业务目标已经对齐」。如今，这种「精致」和「真正准备上线」之间的关联已经断了，Andrew 的描述是：<br>
「现在你可以把完整的实现拉进设计流程的最早期。一个打磨得无比精致的原型看起来就像能上线，但它实际上还在设计流程的探索阶段——只是没有人告诉你这一点。九十个人都会有同一个想法，每个人都做出来了，看起来很精致，但这不是产品——这就是现在的设计流程。」<br>
Codex 团队内部的解法是一个叫「baby Codex」的极简代码库，专门用来快速探索交互方案，不做生产级代码。<br>
「我们有个叫 baby Codex 的内部版本——一个极度简化的代码库，用来快速探索交互方案。『侧边栏能不能这样？面板能不能加个群聊？』这本身就是设计流程。」<br>
那么设计流程到底死了吗？Andrew 给了一个两面回答：<br>
「说设计流程死了，既对也不对。如果你跟流程的具体工具绑死了，那你完了。但把『我们现在在流程的哪个阶段』这个框架扔掉，那才是最大的错误。」<br>
至于为什么 AI 在设计这个具体任务上表现尤其差，Andrew 的答案很直接：设计比代码更难打分。<br>
「设计比代码更难『打分』。创造一个训练循环来区分好设计和坏设计，比判断代码能不能编译，要啰嗦得多、困难得多。因为品味中的人的部分，是这个反馈机制必需的东西。」<br>
他还补充了两个更深的问题。第一是文化维度——AI 可以完美复制 Linear 的网站，但每次都出 Linear，而设计需要的恰恰是新东西多于已知模式。第二是抽象层——如果一个公司明天改品牌色，浅层做法是手动改 263 个组件，深层做法是让所有视觉元素之间共享同一套语义关系，而这个抽象能力，目前的模型还够不着。<br>
「给人类大脑鼓个掌吧，」他说。<br>
同一个产品，模型换了，就改命了<br>
Codex 的前身可以拉出一条线：Operator → Atlas → Codex Web → Codex 桌面端。Andrew 认为这本质上就是同一个功能，在不同的时间点、搭配不同的模型能力，反复重新发布。<br>
「这些其实都是同一个功能，一次又一次地重新发布。只不过每次搭配的智能水平不同。」<br>
他给了一个非常有说服力的例子：<br>
「我非常确定，Codex 桌面端如果去年 11 月发布，在市场上绝对会失败。而唯一的变量就是 11 月到 2 月之间的模型进步。同一个产品形态，结果完全取决于几个月的模型时间差。」<br>
这里他还提到一个教训，他们曾经「在 AGI 这条路上走得太快了」。<br>
「最初的 Codex Web 太 AGI-pilled 了——你给模型一个任务，它跑去做完回来告诉你，问题是它做得不够好。Claude Code 反过来——完全本地、不接云端、不强求全自动，它会问你问题、等著你。那个形态才适合当时的模型水平。我们在 AGI 这条路上走得太快了。」<br>
这个说法听着有些为自己挽尊的意思，但不重要，及时调转船头就行。 Andrew 现在的逻辑是：不要因为一个功能现在不行就判它死刑。列出未来一两年所有想做的事，全部做成原型，哪些现在够成熟就上，剩下的交给时间。每次模型有一次飞跃，把那件事再拿出来试一遍。功能好不好，很多时候不在于功能本身的形态，而在于它背后那个模型够不够聪明。<br>
他怎么用 Codex 工作<br>
Andrew 每天早上打开 Codex，首先看到的是一份每日简报。<br>
「我每天早上醒来，看到 Codex 给我的每日简报——从我加入的 3000 个 Slack 频道里提取出来的。哪些需要我注意。我可以回复，『给我五个问题，我来回答』。」<br>
这个简报是怎么养出来的？不是靠写多么精确的指令。<br>
「每次 Codex 自动任务跑了，如果不对，我不需要去改指令。我直接对它说：『下次跑的时候注意这个』，『这个东西没出现在简报里，能不能确保类似的东西以后出现』。它自己会更新通知方式。」<br>
他最近一次产品发布的协调方式也很有意思：<br>
「我有一个 Notion 文档列了所有要做的事。Codex 自动从 Pull Request、Slack 频道收集进度更新，更新我的状态追踪表——这是我们第一次『用 vibe 协调』的发布。」<br>
整体来看，他的工作流并不局限在 Codex 当中，而是通过 MCP 等方式协同各个外部资源。可以参考，但不一定要借鉴，毕竟，他可是不用操心 token 计费的人呐……<br>
Codex 不是超级应用，是一个 home base<br>
外界一直有人把 Codex 和 ChatGPT 的关系往「超级应用」上靠——所有工具塞进一个窗口。Andrew 明确不喜欢这个叫法，他用的词是 home base。<br>
「Codex 不该是把你所有事都锁在一个矩形里的超级应用。它应该是一个 home base——你在上面开始工作、结束工作、自动工作。它用各种连接器、浏览器、扩展跟你已经用的工具对话。你做重度财务建模时，它直接跟 Excel 桌面端交互，算完你就关掉 Excel。」<br>
最能说明这个理念的，是一个 Premiere Pro 的故事。OpenAI 内部的视频编辑试着用 Codex 剪片子。<br>
Codex 不是视频编辑器，但它理解 Premiere Pro 的工作方式——能直接编辑 Premiere 背后的项目文件，做不了的操作，它做了一件更惊人的事：<br>
「Codex 自己给自己写了个 Premiere Pro 的扩展插件，然后通过扩展告诉 Premiere：请把这里的时间标记移到那里。」<br>
产品开发流程，已经被重塑<br>
整个对话中，Andrew 反复回到一个核心观察：AI 把产品开发流程完全倒转了。<br>
「任何人都能做出任何东西。你给人们无限 token，每个人都在做东西。回头看看我们过去跑的产品流程——研究、构思、原型，所有这些都是建立在一个假设上：实现是昂贵的。所以你要用文档、研究、原型把所有实现风险提前消除。这个假设已经消失了。」<br>
旧流程的逻辑是「实现贵 → 先写 PRD、做研究、画原型来降风险 → 再动手」。新流程里实现便宜到几乎免费，于是同一个功能可能有 90 个团队在同时做原型。难事不再是「要不要做这个」，而是「做了这么多，哪个最好、哪些该合并、怎么收束」。<br>
但是，这意味着 PRD 已经死了吗？<br>
「因为实现变得极其便宜，非工程师特别容易直接跳进原型。但对工程师来说，现在反而很容易写一堆没人想读的文档。关键不是扔了文档或扔了原型，而是选对媒介。」<br>
Andrew 收束整场对话的那句话，大概也是给所有在 AI 时代重新定位自己的人的一句建议：<br>
「别跟你的具体流程结婚。跟你唯一能交付的结果结婚，然后该改流程就改流程。如果你最擅长的还是『Figma 自动布局』，那就该干嘛还是干嘛。」<br>
既然工具会变、模型会变、流程会过时，唯一不变的，应该是你交付独特结果的能力。