当实现不再稀缺，AI PM 靠什么活下去？

guozi

当实现成本越来越低，AI PM 的价值不再是“把需求推进到上线”，而是能不能在大量可运行方案里判断：什么值得做，什么时候做，做到什么程度，以及如何把它放进一个稳定的产品系统里。



这两天重新看了一遍 Lenny’s Podcast 对 Andrew Ambrosino 的访谈。

表面上看，它像是一场关于 Codex 的产品访谈，但我越看越觉得，它真正讲的是另一个问题：AI 时代，产品工作到底变成了什么样子？

视频开头有个数字很刺眼：OpenAI 内部大量员工都在使用 Codex，而且不是只有工程师。Andrew 后面还讲到，市场、法务、财务、视频制作等团队都开始把 Codex 拿去做自己的工作，哪怕这个产品表面上还带着很强的开发者工具气质。

这对 AI PM 来说，信号非常明确：AI 产品的真实边界，经常不是产品经理在需求文档里画出来的，而是用户在使用过程中硬生生“用出来”的。

所以这篇不是普通播客笔记，也不是逐字稿压缩。我会从 AI PM 的角度，把这期最有信息量的部分整理成 12 条深度观察。它们分别指向产品流程、设计协作、角色边界、路线图、模型时机、agent 工作流，以及未来知识工作入口的形态。

如果你是下面几类人，我建议把这期访谈和这篇整理都看一遍：

• 正在做 AI 产品的 PM，尤其是每天都在处理模型能力、用户预期和落地边界的人；
• 负责 AI 产品团队协作的人，正在重新思考 PM、设计、工程之间应该怎么配合；
• 想用 AI 改造自己工作流的创业者、独立开发者和产品负责人。


当“做出来”越来越便宜，真正贵的是判断什么值得做、什么时候做、做到什么程度，以及如何把它放进一个稳定的系统里。
1. 实现成本塌陷后，PM的主战场从“推动资源”变成“治理丰饶”
Andrew 在访谈一开始就把旧产品流程翻了个面。他说，过去大家默认实现很贵，所以产品工作往往是先研究、再写文档、再设计、再原型、最后才争取工程资源。这个流程背后的隐含假设是：代码和实现是稀缺资源，所以你要在实现之前把风险尽量排干净。

但在 OpenAI 这样的环境里，这个前提被打穿了。Andrew 说，现在几乎任何人都可以从零开始做出一个功能探索。给大家足够多 token、足够强的模型、足够低的试错成本，结果就是同一个想法可能同时出现几十个版本。不是一个团队慢慢排期做，而是很多人直接动手做。

这对 AI PM 的冲击非常大。过去 PM 的核心动作之一，是帮团队争取工程资源、安排优先级、把需求推进到实现。现在实现不再是最贵的部分，产品工作反而要处理另一种麻烦：版本太多、方向太多、半成品太多、看起来都能跑的东西太多。

也就是说，AI PM 的价值不再只是“让东西被做出来”，而是从大量可运行探索里判断：哪个方向真的值得收敛？哪些只是局部聪明？哪些应该合并？哪些看起来漂亮但会增加长期复杂度？哪些要进入主产品，哪些只适合留在实验区？

这可能是整期最值得反复看的地方。AI 把产品团队从“资源饥荒”推向“产物过剩”。在产物过剩的环境里，PM 更像编辑、导演和系统架构师：不是鼓励大家多产出，而是帮团队建立判断标准，决定什么东西有资格留下来。
2.PRD没死，但它必须重新证明自己为什么存在
主持人问了一个现在很流行的问题：既然大家都能快速做原型，PRD 是不是死了？Andrew 的回答很清醒。他并不同意“PRD 已死，原型上位”这种口号。他的判断是，文档和原型都没有天然优越性，关键要看你到底想解决什么问题。

如果团队面对的是一个模糊领域，需要建立共同语言、厘清问题边界、说明为什么值得做，那么文档可能仍然是更好的媒介。因为文档适合展开逻辑、暴露假设、组织争论。可如果团队已经有一个交互假设，想要把东西放到用户手里试试看，原型就比文档更有力量。

这件事对 AI PM 特别重要。AI 工具让每个人都能更快生成文档、原型、代码、图表，但工具变快之后，媒介选择反而变成更高级的能力。你不能因为会做原型，就把所有问题都原型化；也不能因为会生成长文档，就把所有不确定性都藏进 PRD。

更准确地说，AI PM 需要先判断当前讨论缺的是什么。如果缺共识，就写文档。如果缺体验反馈，就做原型。如果缺真实行为数据，就上实验。如果缺系统边界，就画架构。如果缺高层对齐，就写一页 narrative。媒介不是流程规定，而是服务于判断。

以前很多团队把 PRD 当成产品工作的起点，现在它应该变成一种可选表达方式。一个成熟的 AI PM，不是永远少写文档，也不是永远多做原型，而是能解释：为什么这个问题现在需要这种形式的 artifact。


3. 越像成品的原型，越需要被贴上“它还不是成品”的标签
Andrew 提到一个很微妙的变化：过去，一个东西如果看起来像生产环境里的功能，通常意味着它已经经过一轮比较完整的判断。它之所以像成品，是因为研究、设计、工程、业务目标、资源投入都已经走到后面了。

但现在完全不是这样。AI 可以很快生成一个非常像成品的原型。它可以有漂亮界面，可以交互顺滑，可以看起来像马上就能上线。问题是，外观完成度和判断完成度已经被拆开了。

这会制造一个很危险的团队错觉：大家看到一个 polished prototype，就容易以为事情已经成熟。Andrew 讲得很直接，一个本来只是早期探索的东西，因为看起来太像产品，可能会被别人问：“那我们能不能直接发？”

AI PM 在这里要做的不是阻止原型变漂亮，而是给 artifact 做阶段标注。这个东西现在是在探索问题，还是验证交互，还是压测技术方案，还是已经准备进入生产？如果团队不共享这个状态，就会被“视觉完成度”误导。

这也是为什么我觉得 AI PM 需要引入一种新的交付物管理习惯：每个原型、demo、实验分支、AI 生成方案，都要带上它正在回答的问题。一个原型不是“一个功能的雏形”，而是“一次问题回答”。回答完问题，它可以被丢掉，不一定要被推进。

你敢信？未来很多产品灾难，可能不是因为团队做得太慢，而是因为团队太快把“早期答案”误认为“最终答案”。
4. Taste 不是审美词，它是 AIPM在无限方案里做取舍的操作系统
这期里 Andrew 多次提到 taste。这个词现在很容易被用滥，好像一说 taste，就变成“这个人审美好”。但 Andrew 的解释更宽。他说 taste 当然包括审美，但不止审美，还包括系统思考、方向判断、表达方式、交互语义，以及知道一个东西应该成为什么。

他举了一个很有意思的方向：当你什么都能做的时候，真正的问题不是“能不能做”，而是“目标是什么”。如果你可以快速生成 10 个界面、20 个工作流、90 个功能探索，那谁来判断哪个更符合系统，哪个更符合用户心智，哪个会让产品长得更健康？

这就是 AI PM 的 taste。它不是“我喜欢这个按钮颜色”，而是能同时看三件事：

• 第一，这个方向是否值得投入；
• 第二，这个方案放进现有系统后会不会制造复杂度；
• 第三，这个体验传达的意思是否和产品想表达的语义一致。


Andrew 还提到一个交互动画的例子：某个动画可能太快、太硬，不符合它应该传达的含义。这个例子很小，但背后的标准很大。产品不是一组功能，也不是一组页面，而是一套用户在心里形成的因果关系。好的 taste，就是能看出这些因果关系是否顺。

对 AI PM 来说，taste 不是天赋玄学，而是一套可以训练的判断系统。你要多看好产品，多拆失败案例，多理解工程抽象，多跟用户真实使用场景对齐。AI 能给你很多答案，但它不能替你建立“什么叫好”的内部标尺。
5. AI 现在还不擅长设计，不是因为它不会画界面，而是因为设计反馈太难自动化
主持人问了一个很多人都关心的问题：为什么顶级模型写代码越来越强，但做设计总让人觉得差一口气？Andrew 的回答不是“模型不够聪明”这么简单。他认为，代码比设计更容易形成训练闭环。代码能不能编译、测试能不能过、行为是否符合预期，这些反馈相对清楚。

设计就麻烦多了。一个界面好不好，不只是看它有没有对齐、有没有层级、有没有组件。它还涉及文化、语境、新意、品牌感、用户预期和人类 taste。也就是说，设计的反馈里有大量主观但又真实存在的判断。

Andrew 还提到，过去 AI 实验室更优先让模型擅长能加速 AI 研究的能力，比如写正确代码。设计当然重要，但它没有那么直接进入研究飞轮。这是一个非常现实的产品视角：模型能力不是平均发展的，它会被产业目标和反馈机制塑形。

这对 AI PM 的含义是，不要把“AI 能生成 UI”误读成“AI 已经会做设计”。它能生成界面，不代表它理解你的产品气质；它能模仿 Linear 风格，不代表它知道你的用户为什么需要这样的体验；它能做 20 个方案，不代表它知道哪个方案最少伤害系统。

AI PM 在设计协作里的新职责，可能不是替代设计师，也不是让设计师只做润色，而是把设计判断显性化：我们要传达什么语义？用户在这个状态下应该感到确定、紧张、轻松还是被提醒？这个组件和系统里已有模式是什么关系？如果未来品牌升级，这套结构能不能承受变化？

说到底，AI 会越来越会“画”，但设计真正难的是“判断为什么这样画”。


6. 设计流程死了，但阶段意识不能死
Andrew 对“设计流程已死”这个说法的态度很有意思。他并不怀念那种教条式流程：研究、发散、收敛、设计、原型、交付，每一步都像考试一样走完。甚至他说自己在 AI 之前也不喜欢这种过于学术化的设计流程。

但他反对把流程意识一起扔掉。因为实现变快以后，团队更需要知道自己现在处在哪个阶段。一个东西可以很快被做出来，但它到底是在探索问题，还是在验证方案，还是在准备上线？这个阶段判断比以前更重要。

这句话对 AI PM 非常关键：流程的形式可以死，流程的元认知不能死。

过去流程慢，有时候是因为工具慢、协作慢、排期慢。现在这些阻力变小了，大家就容易觉得“不需要流程了，直接做就行”。但一旦团队完全失去阶段意识，所有 artifact 都会混在一起。早期探索会被当成上线候选，局部 demo 会被当成战略方向，模型刚好跑通的一次结果会被当成稳定能力。

Andrew 还提到一种“baby version”的产品代码库：它不是完整生产代码，而是高度简化、能近似关键交互的探索环境。团队可以在里面快速试 sidebar、pane、group chat 等想法。这其实就是新设计流程的一部分，只是它不再像传统流程那样围绕 Figma 或文档，而是围绕可运行的简化产品。

AI PM 可以从这里借一个很实用的方法：给不同阶段准备不同沙盒。问题探索用 narrative，交互探索用 baby app，技术验证用 spike，真实采用用小流量实验。不要让所有探索都挤进主产品，也不要让所有讨论都停留在文档里。
7. 角色会重叠，但取消专业角色是一个坏主意
这期里最容易被误读的一点，是“role collapse”。Codex 团队确实出现了角色重叠：设计师懂工程，PM 会写代码，工程师也要有产品判断。Andrew 说，在他们团队里，大家越来越不是由清晰边界定义，而更像由自己时间投入的平均值定义。

这个说法很妙。一个人如果大部分时间在做产品判断，他就更像 PM；如果大部分时间在写代码和处理系统问题，他就更像工程师；如果大部分时间在处理体验、语义、交互和视觉，他就更像设计师。title 还在，但真实角色更像一个动态坐标。

可是 Andrew 也非常明确地说，他害怕一些公司走向极端：一听说 AI 时代人人都是 builder，就开始取消产品角色，觉得大家都写代码就够了。他认为这是一个糟糕想法。因为产品、设计、工程、财务、法务这些职能背后都有长期沉淀的专业知识、最佳实践和失败经验。

这对 AI PM 是一个很重要的定心丸，也是一记提醒。PM 这个专业不会因为 AI 能写代码就消失，但只会转述需求、同步进度、排会议的 PM 会越来越没有空间。真正保留下来的，是产品专业里更硬的部分：问题定义、用户理解、系统取舍、商业判断、组织对齐、灰度实验、信息编辑。

未来的 AI PM 不该把自己缩在“这不是我的边界”里，也不该幻想自己会一点代码就能替代所有专业。更合理的状态是：边界更开放，专业更扎实。你可以跨过去协作，但你必须尊重对方领域里那些不显眼但很重要的 know-how。

坦率地讲，这比“人人都是 builder”成熟得多。
8.PM更像打区域防守：哪里混乱，哪里就需要产品判断
Andrew 用了一个很有画面感的词来形容产品工作：zone defense，区域防守。他说，如果两个产品人长期挤在同一个地方工作，往往不是好信号。更理想的状态是，产品人分散到不同区域，覆盖那些混乱、空白、缺判断的地方。

这个比喻非常适合 AI 时代。因为当每个人都能做探索，组织内部会自然出现大量自下而上的想法。你很难再用一个自上而下的年度计划，把所有事情安排得整整齐齐。现实更像一片动态信息场：有人在做原型，有人在改工作流，有人在试新模型能力，有人在从用户那里听到新需求。

AI PM 的工作就从“管一条需求流水线”变成“维护一个判断网络”。你要知道哪里有重复探索，哪里有未被看见的机会，哪里某个 demo 看起来很强但缺少产品定位，哪里某个模型能力已经成熟到可以重新验证旧想法。

区域防守不是躺平等球来，而是主动找空当。Andrew 提到，他们希望工程师本身也有产品感，不希望一堆人写完代码后再等产品团队统一审核产品一致性。这意味着 PM 不再垄断产品判断，而是要把判断标准扩散到团队里。

所以 AI PM 的新能力，不只是自己会判断，还包括让别人也更容易判断。比如建立探索分级、定义什么叫 ready、沉淀决策原则、把成功和失败案例写成团队语言。这样一来，产品判断不再是 PM 的个人品味，而会变成组织能力。


9. 路线图要近实远虚，因为模型时机会重写产品命运
谈到 roadmap 时，Andrew 的态度很务实。他说短期越近，计划越需要具体；越往远处走，计划越要保持模糊。不是不做长期规划，而是不能给 9 个月后的事情加太多虚假的精度。

这在 AI 产品里尤其真实。因为 AI 产品有一个传统软件很少遇到的变量：模型能力会突然改变一个功能的可行性。Andrew 举了 Codex app 的例子。他认为，如果 2 月发布的那个版本在前一年 11 月就推出，可能会失败。产品形态可以一样，但模型能力不一样，市场结果就会完全不同。

这句话非常反直觉。过去我们评估一个产品失败，往往会从定位、需求、体验、定价、分发里找原因。但在 AI 产品里，还要多看一层：是不是模型还没到能力点？是不是用户心智还没准备好？是不是同一个形态过三个月再发，结果会完全不同？

Andrew 还说，他们会把一些暂时跑不通的想法作为 artifact 留下来，等模型升级后再测。这个做法很值得 AI PM 学。你的 backlog 不应该只有“待开发需求”，还应该有一类“等待能力成熟的产品假设”。这些假设要写清楚：价值是什么，当前卡点是什么，需要哪类模型能力或基础设施变化。

更进一步，AI PM 的路线图应该从功能列表变成假设组合。短期写具体交付，中期写能力依赖，长期写方向和判断条件。这样团队才不会因为一个功能现在跑不通就过早放弃，也不会因为一个愿景很美就过早上线。

想想这个逻辑，AI 产品经理不是在一条稳定赛道上排功能，而是在一个不断变化的技术地形里选择窗口期。
10. 太 AGI-pilled 会伤产品，终局愿景不能替代当下形态
Andrew 在复盘 Codex 早期形态时，讲了一个很重要的教训：有些产品想法不是错，而是对当下模型能力来说太早。早期 Codex web 更像“你把任务交给模型，它去云端做完再回来”。这个终局听起来很合理，但当时模型还没有强到能稳定完成这种委托。

后来另一些更本地、更互动、更愿意提问、更不假装全自动的形态，反而更适合当时的模型能力。Andrew 用了一个挺直白的表达：他们当时有点 too AGI-pilled，也就是太按终局能力来想产品了。

这对 AI PM 是非常宝贵的提醒。很多 AI 产品都容易犯这个错：一上来就设计“全自动 agent”“替你完成一切”“一句话搞定工作”。愿景当然迷人，但用户真正需要的可能是一个可监督、可纠偏、能中途问问题、能解释自己状态的协作者。

产品形态必须贴着模型真实能力走。模型只能做到 70 分时，你硬包装成 100 分自动化，用户会失望；但你把它设计成一个 70 分但透明、可控、能逐步学习的助手，用户反而愿意把它纳入工作流。

AI PM 在这里要做的，是把终局愿景拆成当下可用形态。比如全自动不是第一步，半自动可能是第一步；一次性完成不是第一步，边做边确认可能是第一步；替代专业工具不是第一步，先连接和调用专业工具可能是第一步。

有时候，产品不是不够大胆，而是大胆的方式错了。真正成熟的大胆，是知道现在该把未来折叠到多大。


11. Codex 的真正方向不是“写代码工具”，而是工作 home base
Andrew 讲 Codex 未来愿景时，有一个很关键的转向：他们一开始当然把它看成开发者工具，但内部 dogfood 后发现，很多非工程团队也在用它。更有意思的是，这些人明明面对的是一个对非工程用户并不友好的界面，仍然愿意留下来使用。

这说明什么？说明 Codex 吸引人的可能不是“它能写代码”这个单点，而是它提供了一种新的工作入口：你可以在这里发起任务、组织上下文、连接工具、让 agent 去执行、再回来看结果。

Andrew 后面提到，他们不一定要把所有东西都塞进一个矩形窗口。比如做金融建模的人可能仍然需要 Excel，视频编辑仍然需要 Premiere Pro，浏览网页仍然可能需要浏览器。关键不是替代所有专业软件，而是让 Codex 或 ChatGPT 成为工作开始和结束的地方，中间可以调用、打开、连接、控制各种工具。

这对 AI PM 的启发很大。未来很多 AI 产品竞争的不是单一功能，而是“工作编排位置”。谁能成为用户组织上下文、分配任务、追踪状态、连接工具的 home base，谁就有机会变成更高频、更中心的入口。

但这里也有一个产品陷阱：不要轻易喊“超级 App”。Andrew 在访谈里也开玩笑说，有人这么叫后他就天天听到这个词。更准确的说法不是把一切功能都做进来，而是决定哪些能力应该内建，哪些应该通过连接器，哪些应该交给浏览器，哪些应该控制本地 App，哪些只是临时打开。

AI PM 做这类产品时，真正难的不是“要不要做浏览器”“要不要做插件”，而是设计决策边界：什么时候 agent 该用 connector，什么时候该用 in-app browser，什么时候该控制 Chrome，什么时候该直接操作桌面。入口越大，边界判断越重要。
12. 最好的新功能，常常藏在用户的奇怪用法里
访谈后半段有个很有意思的案例：OpenAI 内部视频团队用 Codex 辅助 Premiere Pro 剪辑。Codex 并不是视频编辑器，但它能理解用户在用 Premiere Pro，能操作背后的文件，甚至在某些场景下为自己搭一个 Premiere 扩展，从而控制专业软件里的操作。

这个例子特别能说明 AI 产品的演化方式。很多新工作流一开始并不是产品经理设计好的，而是用户带着好奇心，把一个看似不属于自己的工具拿来试。试着试着，产品团队发现：原来这里有真实需求，原来这类跨工具操作可以变成一等能力。

Andrew 和制作人在结尾也聊到类似判断，很多工作都从“这个产品不是为我设计的，但我看看能不能用”开始。只要试错成本足够低，用户就会探索很多你没写进 roadmap 的路径。

这对 AI PM 来说，是非常重要的用户研究方法变化。过去我们更多观察用户是否按设计路径完成任务；现在还要观察用户如何把产品扭成新的形状。那些看起来边缘、奇怪、临时、非标准的用法，可能就是下一代核心功能的种子。

所以 AI PM 不应该只看埋点里的主路径，也要看用户如何 prompt、如何连接工具、如何绕过限制、如何把输出复制到别处、如何让模型帮自己搭一个小工具。尤其在 AI 产品里，用户经常不是“使用功能”，而是在“发明工作流”。

这也是为什么 Andrew 反复强调 curiosity 和 agency。真正的早期用户不是只等产品设计好，而是愿意带着意图试一下：这个东西能不能帮我完成一个原本不属于它的任务？AI PM 要做的，就是从这些尝试里识别哪些应该被产品化，哪些应该留给高级用户自由发挥。


结尾：AIPM的工作，正在从“管需求”变成“管理判断”
这期访谈表面上讲 Codex，实际上讲的是 AI 时代产品工作的底层迁移。实现不再是唯一瓶颈，原型不再天然代表成熟，文档不再天然代表严谨，角色不再由边界定义，路线图也不再能假装技术能力稳定不变。

对 AI PM 来说，接下来真正要补的能力，不是某一个工具，而是一组更底层的工作方法：

• 判断媒介：什么时候写文档，什么时候做原型，什么时候直接上实验。
• 判断阶段：一个 artifact 是探索、验证、候选，还是准备上线。
• 判断 taste：在无限方案里识别什么真的好，什么只是看起来像好。
• 判断时机：一个功能是坏想法，还是只是模型能力还没到。
• 判断边界：哪些能力应该内建，哪些应该连接外部工具。
• 判断组织：哪里需要 PM 集中推进，哪里应该区域防守。
• 判断信噪比：哪些用户奇怪用法是噪声，哪些是新工作流的早期信号。


所以，不要把 AI PM 的未来理解成“PM 也要会写代码”这么窄。

更准确地说，AI PM 要变成一个能在高产出、高噪声、高不确定性环境里持续做高质量判断的人。你不一定要亲手完成每一件事，但你要知道什么值得被完成；你不一定要替代每个专业角色，但你要能理解它们的核心判断；你不一定要预测模型未来，但你要为未来能力留好验证入口。

最后留一个问题，也算是这期访谈给所有 AI PM 的拷问：

当“把东西做出来”已经不再稀缺，你准备靠什么证明自己做的是对的东西？

本文由 @YF拾光机 原创发布于人人都是产品经理。未经作者许可，禁止转载

题图来自作者提供

--------------------------------------------------
本文转载自：https://www.woshipm.com/pmd/6425789.html