OpenAI Codex负责人亲口说：做产品这件事顺序已颠倒了

有没有想过，做产品这件事的先后顺序可能已经彻底反过来了？过去大家普遍认为，产品开发中最昂贵的环节是把东西真正做出来。正因如此，才会有那么多文档要写、评审要过、原型要测，目的就是在真正动手前把风险降到最低。但如今，局面完全变了。OpenAI Codex 的产品和工程负责人 Andrew Ambrosino 最近在 Lenny's Podcast 上的一番访谈，令人重新审视这个问题。他有一句话印象特别深：现在做产品的顺序是反过来的——实现已经不再是昂贵的那部分了，真正贵的，是 taste（审美判断力，也可以理解为品味和判断力）。

这话听着简单，但越是琢磨，越觉得它触及了一个特别根本的变化。Andrew 提到，现在 OpenAI 内部几乎每个人都很 agentic，都有自己的好点子，于是每个人都在动手做东西。当你给所有人无限的 token，结果就是：任何一个被认为重要的功能，可能同时有 90 个互相并不知道对方存在的团队，各自在尝试实现。这跟我们过去几十年习惯的产品流程完全不一样。以前是先研究、先写文档、先画原型，把假设都验证完了才开始真正写代码——因为写代码太贵了。现在写代码几乎不要钱，但从这 90 个尝试里挑出哪个是对的、怎么把它们捏合起来、怎么框定这个功能该长什么样子，这件事变得无比重要。

taste 到底是什么 不只是审美

一直以来，taste 这个词被用得太泛了，听起来谁都能说自己有 taste，但具体是什么，很多人说不清楚。Andrew 在访谈里举了一个例子：有人引用 Paul Graham 当反例，说他明显是个有 taste 的人，但他天天穿工装短裤。这个例子让人突然意识到，taste 根本不只是审美这么简单。

Andrew 把它拆成几层。一层是纯粹的美学判断，比如一个交互动效是不是太轻快了，跟它想传达的情绪不匹配。另一层是系统性思维，这个功能放在整个产品里合不合适，跟其他模块是否协调。还有一层是方向感——我们到底要往哪走，这个东西属于哪个大主题。再往上一层，是怎么呈现一件事，用什么媒介去表达一个想法。这几层叠在一起，才是真正的 taste。这个拆解特别有用，因为它把一个原本很玄的词，变成了几个可以练习、可以讨论的具体能力。审美只是 taste 的一个小角落，更大的部分其实是判断力——知道在一堆可能性里该往哪个方向投入精力。

为什么 AI 在设计上还是不太行

这是听完整段访谈后最有共鸣的一部分。Andrew 直接说，当前最顶尖的大模型在设计这件事上表现并不好，输出的东西很少有让人拍案叫绝的，大多时候一看就知道这是 AI 做的设计，缺了点什么。他给了几个原因，都觉得挺扎实的。

第一个原因是设计这件事比代码难评判。代码写得对不对，能不能编译，是不是符合预期，这些都可以用客观标准去检验。但设计好不好，里面掺杂了人的审美判断，这种反馈信号本身就很难形成一个干净的训练循环。第二个原因更现实：几个大实验室在选择往哪些能力上重点投入资源时，会优先选那些能加速 AI 研究本身的能力。比如写代码这件事进步了，直接就能让研究效率提高，但设计能力的提升很难直接反哺到这个飞轮里，所以投入的优先级自然就低一些。

还有两个更深层的原因特别有启发。一个是文化和新颖性的问题。Andrew 提到去年很多新网站长得都像 Linear 的官网，因为大家都觉得 Linear 的设计审美特别好。但如果一个模型每次都给你输出一个 Linear 风格的网站，那其实不算什么进步——设计这件事比写代码更需要一点随机性和新鲜感，而写代码的时候反而希望模型尽量贴近已知的、成熟的模式。另一个原因是抽象层的问题：他举了一个换品牌的例子，如果公司明天要重新设计视觉系统，浅层的做法是把两百多个组件一个一个手动改掉，但深层的做法是理解这些组件之间共享的语义关系，知道哪些列表组件传达的是同一种交互模式。这种跨越视觉和代码、理解背后抽象结构的能力，现在的模型还做不到。这个判断特别诚实——他没有说 AI 永远做不好设计，只是说现在这道坎还没迈过去。

同一个功能 换个时间发布 结果完全不一样

访谈里有一段反复琢磨了好几次。Andrew 说他非常确信，如果 Codex 这款应用在二月份发布时的样子，放到去年十一月发布，一定会彻底失败——中间唯一的差别只是模型本身在这几个月里变强了。这个判断让人意识到一件事：我们经常以为产品失败是因为形态不对、定位不对、时机不对，但很多时候真正的瓶颈是底层模型够不够聪明，产品的形态本身可能根本没问题。

他还提到了一条很有意思的线：从 ChatGPT 里的 Operator，到 Atlas 浏览器里的 agent，再到 Codex，这几个东西本质上是同一个功能反复被重新包装、重新发布。Operator 当时没成功，但这不代表那个想法是错的，只是说明那时候模型还没准备好。他说自己现在会提醒团队，不要因为一个东西现在跑不通，就武断地说这是个糟糕的功能——可能只是还没到时候，先把它当成一个可以留着、等模型变强之后再拿出来试一次的素材。这种心态特别值得学习：很多团队遇到失败的实验就直接判了死刑，但如果失败的原因是底层能力不够，那耐心等技术追上来，可能比急着换方向更划算。

设计流程死了吗 我觉得一半对一半错

Andrew 提到一个叫 Jenny 的设计负责人，她的观点是设计流程已经死了——东西变化太快，根本没时间走完整套设计流程，直接边做边设计。Andrew 说他基本认同这个判断，但补充了一个细节让人觉得特别清醒。

他说传统设计流程里有一种很学院派的东西，叫案例工厂——设计师被教育说只要走完用户研究、发散、收敛这一整套流程，结果就一定是好的，哪怕最后没人用这个东西，流程本身也被当成了正确性的证明。Andrew 说他一直不喜欢这种把流程本身当成目的的做法，这一点在 AI 出现之前他就这么想了。但他同时强调，如果把设计流程理解成那些具体的工具和步骤，那确实是死了；但如果把它理解成一种节奏感——知道自己现在处于探索阶段还是验证阶段——这个东西反而比以前更重要了。

这里有个细节特别值得说。以前因为实现成本高，所以原型这种半成品才显得珍贵——大家知道看到的是个原型，心理预期是匹配的。但现在实现几乎不要钱，一个原型可以做得非常精致，精致到看起来已经是成品了，结果公司里一堆人看了就说这看起来已经能上线了吧，赶紧发布吧。可实际上这东西可能还停留在探索阶段，根本没经过验证。Andrew 提到不少公司现在会做一个简化版的产品克隆，比如 baby codex，用一个极度简化的代码库去快速试验各种交互想法——侧边栏长这样会不会更好，弹出一个群聊框会怎样——这种轻量化的试验场，本身就是新时代设计流程的一部分。所以设计流程没有真的消失，只是换了一身衣服，换的是工具和节奏，不是它存在的必要性。

角色正在融化 但不能把角色这个概念整个扔掉

这是整段访谈里最需要警惕、也最容易被误读的一部分。Andrew 说他们团队里角色边界确实在模糊——设计师会写代码，产品经理会读懂技术语言，每个人做的事情比以前重叠得多。他用了一个说法特别喜欢：现在一个人的角色，是看他平均把时间花在哪上面。如果你把一个人一周做的事情画在图上，平均下来落在哪个区域，那就是他现在的角色，这个角色是会变的，不是一个固定的身份标签。

但紧接着他话锋一转，说他很担心一种趋势——有些公司特别极端，直接宣布要取消产品经理这个角色，让所有人都变成所谓的 builder。Andrew 说这是个很糟糕的想法。因为一旦你把角色这个概念整个否定掉，你很容易顺带否定掉这个角色背后那一整套经过验证的专业知识和最佳实践，变成谁写过几行代码就觉得自己什么都懂了。他说得很直接：每个专业背后都有真正的技能门槛，就像你会用 Excel 不代表你能进财务团队工作。这个区分特别重要：边界模糊不等于专业知识可以被随便丢弃，角色之间的墙可以拆，但墙后面几十年积累下来的经验不能跟着一起被倒掉。

他还提到一个挺有意思的现象：OpenAI 内部有些团队会用 member of technical staff（技术岗位成员）这个统一称呼，不分 PM 还是工程师还是设计师。这个说法据说最早是施乐用的，后来在做研究的公司里变成了一种传统。这个细节挺能说明问题的——不是角色不重要了，而是角色的边界变得更流动：你今天主要做产品思考，那你这阵子就是 PM；明天主要在写代码，那你这阵子就是工程师。重要的是你能不能快速切换到该有的思维模式里去，而不是被一个工具或者一个职位名称死死框住。

zone defense 当所有人都能造任何东西的时候 怎么分工

Andrew 用了一个体育里的概念来形容产品经理现在的协作方式，叫 zone defense（区域防守）。他说如果两个产品经理工作得离得太近，往往不是一个好信号。因为现在到处都是各种点子在到处冒出来，自上而下做一年期规划这种老办法已经不管用了，真正需要的是一群有判断力的人去引导从一个想法的萌芽到最终该长成什么样。

具体怎么做呢？就是大家先看一圈谁擅长什么，故意把彼此的关注区域拉开一些距离，确保整个公司的不同方向都有人在盯着，剩下的空隙再去补。他还提到一个用人标准：他们想招的是有产品意识的工程师，而不是写一堆代码然后全靠产品团队去做事后审查、检查产品逻辑对不对。换句话说，他们希望每个人身上都具备多种技能的底子，但每个人真正深耕的方向应该有差异化，不是大家一拥而上做同一件事。这个思路挺值得借鉴的——团队规模不一定要靠堆人头来扩张覆盖面，靠的是每个人主动找空白、主动补位的那种自觉性。

规划这件事 越往后看 就该越模糊

对 Andrew 聊规划那段也很有感触。他说他们团队对规划其实没什么特别聪明的招，基本逻辑就是越近期的事情需要的细节越多，越远期的事情就应该保持模糊——因为现在给一个九个月之后的计划加太多精确的细节，本质上是一种虚假的精确，到头来只是浪费时间。

他还讲了他上一家公司的经历：当时他们开始用模型驱动功能开发，结果发现传统产品流程根本撑不住了。唯一可行的办法变成把未来一两年想做的事情全部列出来，做成原型，看哪些现在就能用，剩下的先放着，等模型能力有了新的跃升，再把放着的那些拿出来重新试一次。因为这些功能能不能成立，归根结底取决于模型够不够聪明，跟功能本身的形态关系不大。这跟前面 Codex 在十一月和二月的对比是同一个道理。可以理解的是，在模型能力快速变化的阶段，规划这件事的重点不是预测未来会发生什么，而是提前准备好一堆半成品，随时等技术追上来就可以立刻拿出来用。

Andrew 自己怎么用 Codex 这才是最有意思的部分

访谈里最喜欢的一段，是 Andrew 讲自己怎么用 Codex 处理日常工作。他说他早上起来会先看一份每日简报，这份简报是从他加入的三千多个 Slack 频道里自动筛出来的，只挑他真正需要关心的内容。他可以直接回复说给我五个问题我来回答，然后就这么处理掉一部分工作。他说这套自动化是慢慢调出来的——第一次跑的时候肯定不准，他就直接跟它说下次别管这个事了，多关注那个事，它就会调整自己通知他的方式。

还有一个细节印象特别深：他们公司内部有个视频剪辑师叫 Brent，纯粹出于好奇想试试 Codex 能不能帮他剪视频。Codex 本身根本不是视频编辑器，但它发现 Brent 用的是 Premiere Pro，就先尝试直接改背后的工程文件来实现一些剪辑操作，发现这样还不够，于是它自己写了一个可以装进 Premiere Pro 的插件，通过这个插件去跟 Premiere Pro 对话，告诉它把某个标记点移到哪里。Andrew 说他们第一次看到这个发生的时候都惊了。这个故事特别能说明一种新的思路——不是说一定要为每个场景单独造一个专用工具，而是让一个通用的智能体自己想办法连接到你已经在用的那些专业工具上，缺什么接口就自己搭一个。

一点思考

听完整段访谈，最大的感受是：AI agent 这件事正在把过去几十年里我们对分工、流程、规划这些管理常识的假设全部推翻重来。这些假设之所以存在，本质上都是因为以前实现一件事很贵，所以才需要层层把关、提前论证、谨慎规划。现在实现变便宜了，贵的东西换成了判断力，换成了知道往哪个方向投入精力、知道什么时候该等技术追上来、知道角色的边界该在哪里松开又该在哪里守住。

最容易被误解的一点，是很多人听到角色融化、流程已死这些说法，就以为分工这件事彻底不重要了，谁都可以做任何事。但 Andrew 的态度其实很克制——他反复强调专业知识本身没有消失，消失的是工具门槛和身份标签那层硬壳。这跟自己这几年观察到的趋势挺一致的：越来越多工具把动手成本降到接近于零，真正能把人和人区分开的，从来不是会不会用某个软件，而是有没有判断力——知道该做什么、不该做什么、什么时候该坚持、什么时候该等一等。这可能才是 AI agent 时代真正稀缺的东西。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：OpenAI Codex负责人亲口说：做产品这件事顺序已颠倒了要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题