OpenAI Codex负责人：当代码变得廉价，产品流程、设计和角色分工都发生了倒转

这篇文章来自于OpenAI Codex 应用的产品与工程负责人 Andrew Ambrosino的一次采访对话。

原视频地址：https://www.youtube.com/watch?v=P3KDebPTUrw

当（代码）实现变得廉价之后，产品流程、设计和角色分工都发生了变化，甚至说都被“倒转”了，那么具体都有哪些呢？这篇采访提供了12个视角的改变。

采访中 Andrew Ambrosino讲得非常务实与中肯，没有像网络上那样过于“吹捧”AI的强大，但也真正看到了AI对团队结构、产品研发流程的底层改变。其中提到的“品味”、“审美”、“筛选”更是值得思考。

这篇文章的来源是采访视频，这里将内容精简整理成Andrew Ambrosino第一视角的陈述，提炼了其中最精华的部分，以飨各位读者：

90%的OpenAI的员工在使用Codex

90%的OpenAI的员工在使用Codex

如果要用一句话概括我对当下产品开发变化的判断，那就是：过去的流程建立在“实现很昂贵”这个前提上，而现在，这个前提正在迅速失效。 一旦实现不再昂贵，整个产品组织的重心、设计流程的逻辑，以及团队分工的方式，都会随之反转。

一、过去最贵的是实现，现在最贵的是筛选

传统产品流程的底层逻辑一直是：实现成本高，所以在真正动手之前，必须尽量降低风险。

于是我们会先做研究、写文档、做方案、跑原型、评审设计。哪怕后来不再是严格的瀑布式开发，这种逻辑也没有真正消失——因为大家默认，代码是昂贵的，工程资源是稀缺的，所以要尽可能在写代码之前把问题想清楚。

但现在情况变了。任何人几乎都能借助模型把任何想法快速搭出来。 真正难的已经不再是“能不能做”，而是“这么多能做的东西里，到底哪一个值得做”。

在这种环境下，一个团队甚至一家公司内部，会同时冒出大量并行尝试：同一个需求，可能已经有几十个不同的人、不同小组，在各自用不同方式实现。于是，最昂贵的环节不再是生产，而变成了判断、取舍、整合与呈现。

也就是：哪些尝试是好的，哪些应该合并，哪些应该被放弃，哪些适合作为独立功能，哪些更应该作为别的功能的一部分出现。

所以今天真正稀缺的，不是“实现能力”，而是品味，以及基于品味做筛选的能力。

二、“PRD 已死”只说对了一半

很多人现在喜欢说“PRD 已死”、“文档没用了”、“直接做原型就行”。我并不认同这种说法，至少它只说对了一半。

真正死掉的，不是文档本身，而是那种把固定步骤和固定格式当成方法论本体的思路。不是说以后都不需要写文档了，而是你必须更清楚：你现在到底想表达什么，以及什么媒介最适合表达这个观点。

如果你要解决的是一个定义模糊、边界不清、需要澄清目标和问题空间的产品问题，那么文档往往仍然是更好的工具。因为文档能帮助团队在还没被具体实现绑架之前，把问题讲清楚，把思路铺开。

但如果你要验证的是一个交互模式是否成立，想让别人快速上手体验、压力测试某种流程，那么原型显然更合适。

所以今天最重要的，不是“只用文档”或“只做原型”，而是为不同类型的思考选择正确的媒介。实现越便宜，媒介选择反而越重要。因为当每种媒介都变得很容易产出时，错误媒介带来的误导也会更大。

三、“像成品”已经不再意味着“接近发布”

以前，一个东西如果看起来像生产环境里的产品，那通常意味着它已经走到了流程的后期：风险已经被消解，业务目标已经明确，设计已经经过验证，团队已经决定投入资源把它做出来。

但现在，这个信号已经失效了。

今天非常容易出现这样的情况：一个看上去已经可以上线的高保真原型，实际上仍然处于非常早期的探索阶段。它视觉上很成熟，交互也似乎完整，甚至代码都写完了，但它可能仍然只是一个用于探索方向的实验品，甚至只是一个给未来模型做测试的 artifact（产物）。

这意味着，团队必须重新建立一种能力：清楚地区分“它看起来像什么”，和“它实际上处于流程的哪个阶段”。

否则，组织会很容易被“成品感”误导，过早锚定在某个本来还应该继续探索的方向上。

这是今天产品工作里一个特别反直觉、但又越来越关键的变化：

代码写完了，不代表该发布；原型能跑了，不代表方向正确；看起来像成品，也不代表它已经成熟。

四、设计流程没有消失，但固定套路失效了

我同意“传统设计流程正在失效”这个判断，但不同意把它简单理解为“设计流程已死”。

过去那套正规设计流程——用户研究、发散、收敛、交互原型、设计评审、进入开发——之所以成立，是因为它有一个前提：实现很贵，所以必须尽可能在动手前把问题空间和解法空间都走完整。

后来 Figma、Origami 之类的工具让交互原型更早进入流程，设计师可以提前模拟很多接近真实产品的体验。这已经是在把“实现”往前拉了。

而现在，AI 进一步把整个实现都提前拉进了流程。于是问题来了：当你甚至可以在正式开发前就做出一个几乎完整、可交互、视觉打磨到位的版本时，组织该如何理解它的状态？

这正是今天设计流程的核心难题。不是设计不重要了，而是以前那些“阶段信号”失灵了。

所以现在比以往更重要的，不是机械地执行流程步骤，而是保留一种更高层的框架意识：

• 我们现在处于探索、验证，还是收敛阶段？
• 这个产物是为了澄清观点，还是为了让人试用？
• 这是一个研究工具，还是一个准备发布的版本？

换句话说，死掉的是僵化步骤，不是过程意识。

真正变重要的，是对“我们现在在哪个阶段”的共同理解。

五、品味不是审美偏好，而是方向判断能力

很多人一听“品味”，会以为只是视觉审美、动画细节、界面风格。但我所说的品味要宽得多。

当然，审美是品味的一部分。比如一个过于“利落”的交互动效，可能在语义上就不对，因为它传递了错误的感觉。这种细节很重要。

但更深层的品味，其实包括：

• 这件事值不值得做；
• 它应该以什么形态出现；
• 它如何嵌入整个系统；
• 它属于哪个方向；
• 它该如何被呈现，才能让人理解它真正的价值。

当任何人都能快速实现任何东西时，最关键的问题不再是“怎么做出来”，而是：

目标到底是什么？我们到底应该往哪里去？

这才是今天最稀缺的品味。

六、AI 为什么还不擅长设计？

我认为，AI 在设计上落后于代码，不只是模型能力问题，也有训练机制和反馈结构的问题。

代码的好坏相对更容易判断：能不能编译、能不能运行、是否实现目标，反馈链条比较明确。

而设计的评估则复杂得多，因为其中有很强的人类判断、文化语境和新颖性要求。你很难像评价代码那样，把设计简单地归类为“对”或“错”。

此外，设计有一个软件工程里没那么强的维度：新颖性。

软件工程很多时候希望复用稳定模式，最好别发明新东西；而设计却常常需要在熟悉与新鲜之间找到平衡。一个每次都生成“看起来像某个成熟产品官网”的模型，也许说明它学到了风格，但不代表它真的解决了设计问题。

更难的是，真正的软件设计不仅仅是视觉层面，它还涉及抽象层。比如两个界面元素看起来不同，但在产品语义和代码结构中，本质上可能属于同一类东西。模型不仅要“画得像”，还要理解这些抽象关系如何映射到系统里。

这不是简单的美术生成问题，而是更深层的产品与工程抽象问题。

所以我相信模型会越来越擅长设计，但设计追赶代码，确实会更慢，也更难。

七、一个功能能不能成功，往往取决于“发布时模型够不够聪明”

今天做 AI 产品，最反直觉的一件事是：同一个功能形态，可能要发布六次才会成功。

这并不一定是因为前五次做错了，而可能只是因为模型当时还不够聪明。

从这个角度看，Operator、Atlas、Codex，甚至某些 ChatGPT 里的能力，本质上都可以看作是同一个方向上的不同版本：想法没那么不同，差别主要在于发布时所依赖的模型能力处于什么水平。模型稍微聪明一点，整个体验就可能从“不成立”变成“终于 work 了”。

这意味着一个非常重要的产品判断：

不要轻易把“现在不 work”理解成“这个功能本身是坏功能”。

它可能只是还没到时间。

因此，写完代码并不意味着就该上线。很多时候，那只是一个可以拿来反复测试未来模型的实验壳。

产品团队需要摆脱一种旧有肌肉记忆：既然已经做了，就该发。现在不是这样了。现在更合理的理解是：做出来，只意味着你获得了一个可持续验证的载体。

八、长期规划仍然需要，但高精度长期规划往往是虚假精度

在 AI 产品环境里，规划变得异常困难。不是因为不需要规划，而是因为很多关键变量——尤其是模型能力的跃迁——变化太快。

我的基本看法是：

• 越短期的事情，越应该具体；
• 越长期的事情，越应该保持模糊。

不是说不看九个月后、十二个月后，而是说：你现在给九个月后的计划加上很多精细颗粒度，往往只是虚假精度。 看起来更严谨，实际上只是更容易错。

更现实的做法，是把未来一两年感兴趣的方向尽可能列出来，尽量先做成原型或实验壳，判断哪些在当前模型条件下已经成熟，哪些还不成熟。然后随着模型能力进步，不断把那些“还差一点”的功能拿回来重新测试。

因为很多时候，一个功能最终是否成立，核心变量并不在产品团队本身，而在于：到发布时，模型是否已经聪明到足以支撑它。

九、角色边界在模糊，但专业性没有消失

现在大家很喜欢谈“角色坍塌”，好像工程、设计、产品这些传统职能都要消失了。我认为，这个趋势确实存在，但不能被过度简化。

现实情况更像是：每个人不再由职能边界定义，而是由自己工作内容的平均值定义。

一个设计师今天可能也在写代码，一个 PM 可能会直接做交互原型，一个工程师可能对产品结构和用户体验做大量判断。大家都在彼此重叠。

但这并不意味着专业能力不重要，也不意味着谁都可以随意替代谁。

边界变柔软了，不代表专业消失了。

我很警惕一种极端倾向：有些公司一听说“大家都是 builder”，就想取消产品岗、弱化设计、忽略专业训练，好像只要人人都会用 AI 写点代码，就可以不需要这些学科积累了。我认为这很危险。

因为每个领域都有自己的方法论、最佳实践、失败经验和深层技能。

你会用 Excel，不等于你能进财务团队。

同样地，你能调几句 prompt，也不等于你掌握了设计或产品。

真正的变化在于：工具门槛正在下降，守门方式正在瓦解。

过去很多岗位会把“擅长使用某个具体工具”误认为“擅长这个职业”。这种绑定正在松动。以后更重要的不是你会不会某个工具，而是你能否进入那个问题域的思维方式，理解什么有效、什么无效，并持续做出正确判断。

十、现在“有多少代码是 AI 写的”已经是个过时问题

如果还用去年的标准衡量，那么今天很多先进团队的产品代码几乎已经可以说是100%由 AI 生成的。所以，“有多少代码是 AI 写的”这个问题本身已经开始失去意义。

真正有意义的问题变成了：

这些代码是“有监督地写出来的”，还是“无监督地写出来的”？

也就是说，人到底是在逐步引导、约束、修正它，还是已经可以把某个目标交给它，让它自己长期连续地推进？

而在走向更高水平自治的路上，一个非常现实的拦路石是：模型普遍擅长加代码，不擅长删代码。

它们会让系统越来越复杂，会不断叠加东西，却不够擅长做清理、重构、抽象收敛和复杂度控制。

这件事非常关键。因为真正成熟的工程能力，不只是能加功能，更是能知道哪些该删、哪些该合并、哪些抽象需要提升、哪些结构应该简化。 如果模型只会加法，不会减法，它就很难真正成为长期可靠的自治开发者。

十一、真正有价值的人，是能把想法从 idea 带到 done 的人

在这样的环境下，我越来越重视一种人：既有强烈能动性，又有稳定品味，能把一个想法一路带到完成的人。

这类人不一定严格属于某个传统职能，但他们通常具备几个共同特征：

• 能发现空白，而不是等任务分配；
• 能在混乱中做判断，而不是只执行清晰指令；
• 能把探索推进到交付，而不是停留在灵感层面；
• 能持续校正方向，而不是一味堆砌产出。

这也是为什么我认为，今天无论是 IC（Individual Contributor，个人贡献者） 还是管理者，本质上都越来越像是在“管理某种系统”。

IC 不再只是逐字写代码，而是在管理 agent、管理工作流、管理正在发生的自动化过程；

管理者做的也是类似的事，只不过粒度更高。

所以今天最重要的能力之一，不是单点执行，而是在无限生成能力面前，持续判断什么是信号、什么是噪声。

十二、未来的产品，不一定是一个更大的 app，而是一个工作“基地”

对 Codex 这类产品，我越来越相信的一点是：它的未来不只是一个开发者工具，也不只是一个聊天界面，而是一个工作入口与工作基地。

它未必取代所有专业工具，也未必要把所有功能都塞进一个矩形界面里。

更现实的方向是：你在这里开始工作、结束工作、管理工作、自动化工作，它再去调用你真正需要的那些工具——浏览器、Excel、Premiere、Notion、Slack，甚至桌面上的其他应用。

也就是说，它不一定什么都亲自做，但它应该能够理解你的工作流、跨工具协调任务、把不同系统串起来，并在适当的时候代替你去操作它们。

从这个角度看，未来真正重要的不是“一个 AI app 能不能替代所有软件”，而是：

它能不能成为你所有工作的 home base。

十三、给今天的从业者一个最实用的建议

如果今天只能给一个建议，我会说：

不要执着于你当前那套具体流程，而要执着于你能独特交付的结果。然后主动去改变流程，尝试新的做法。

很多人还把自我价值绑定在某个工具或某套旧流程上，比如“我是最懂某个设计工具高级功能的人”。但这种价值会越来越快地被模型吞没。

真正更稳定的价值，不是你是否精通某个具体操作界面，而是：

• 你是否知道什么值得做；
• 你是否能分辨好坏；
• 你是否能推动事情成形；
• 你是否能在工具变化时，持续找到新的有效工作方式。

说到底，不要守着流程，去守着结果。