夜雨聆风上一篇从通用的层面聊了什么是 AI-Native 组织，接下来通过具体的 function 来看 AI 是如何改变组织，前沿的公司再怎么做。从 Claude Code PM 的访谈开始
但 PRD 消失只是表面那一层，更值得讨论的变化是：产品研发的瓶颈从"实现"转移到了"判断"。这种新的瓶颈需要新的工具、新的产出形式、新的衡量方式，而这些正是那场访谈里讲得最关键、却也最少被展开的部分。
PRD 的真正问题
PRD 这份文档过去同时承担着几件事。它把模糊需求锁成清晰的执行目标，让产品、研发、设计、市场对齐到同一个版本，留一份决策依据让后人能追溯，再充当上线前的质量基线。这几件事每一件在当时都是真问题，PRD 是当时能找到的最合适的载体。
在执行成本崩掉之后，这几件事有的不再是问题，有的换了载体。PRD 自己没变，但它服务的那个协作模式塌了。
锁定需求这件事不需要靠 PRD 了。一个工程师下午就能拉出原型，原型本身比文字描述精确得多，团队看着可点击的东西讨论，比对着 PRD 里某句话怎么理解争论要省事。跨部门对齐也不需要靠 PRD 了。当一个方向错了几小时就能改回来，先做一版给大家看就比开三场会更高效。这两件事在执行很贵的年代是 PRD 的核心价值，现在都失重了。
决策记录这件事没消失，但 Anthropic 团队找到的载体不是 PRD，是 metrics readout 和 team principles。前者是每周一次的核心指标全员回顾，所有人对业务发生了什么有同样的认知；后者是一份持续更新的清单——我们的核心用户是谁、为什么是他们、我们愿意做什么取舍。两样东西合在一起，比任何一份 feature 级别的 PRD 都更能让团队成员独立做出方向正确的决定。这件事 PRD 做不到，因为 PRD 是 feature 颗粒度的，而决策记录需要的是更高层的判断标准。
质量基线在 AI 产品里反而比过去更重要，但 PRD 那种自然语言的"验收标准"对 AI 产品基本没用。它的替代品是 eval，一种可以直接跑、能给出数字结果的测试集。
这套替代机制——principles、metrics readout、Research Preview、evergreen launch room——服务的是同一个目标：把对齐成本压到最低。每个人理解得够深之后，对齐就发生在每个人脑子里，不需要再走流程。
这是 PM 工作变化里最容易看到的一层。更深的一层是：当 PRD 不再是核心产出，PM 到底在产出什么？
判断成了新瓶颈
Cat Wu 在那场访谈里有一句被广泛转述的话：代码越来越便宜，品味越来越贵。这句话描述的是一个非常具体的变化——产品研发的瓶颈位置换了。
过去的产品研发链路里，瓶颈在执行那一段：想法相对廉价，写出来很贵。所以组织把大量资源放在"管住执行"——PM 的工作是把模糊想法转成清晰需求，让昂贵的执行不跑偏。判断当然也重要，但因为执行这道墙太厚，判断的瑕疵会被执行的延迟掩盖。
执行变便宜之后，判断这道墙就裸露出来了。一个想法上午冒出来，下午就能跑通原型，第二天就能给用户用，这中间几乎没有缓冲带。判断错了，没有"开发周期"作为补救机会，错误会直接落到用户面前。同时也意味着，判断对了的回报变得比过去高得多——一个对的方向，能用一天时间走完过去一个季度的距离。
判断的杠杆放大了，判断本身没有变容易。具体到 PM 的工作上，判断这件事至少分成三个独立的子问题：决定做什么、决定什么是好的、决定什么时候停。每一个都需要新的工作方式来支持。
决定做什么：先理解模型在哪里坏
Cat Wu 提到她有一个保留的内部测试项目——让 Claude Code 给 Excalidraw 加一个表格工具。这个测试在 16 个月里能力表现跳了 41 倍。模型能力以这种速度跃迁的时候，PM 工作的起点就不能再是"用户要什么"或"竞品做了什么"——这两个起点在传统软件里管用，因为技术能力是稳定的常量。AI 产品里它是变量。
更可操作的起点是另一个问题：模型今天在哪里会坏？
Marily Nika 在 Lenny's Newsletter 上写过一组针对这个问题的训练方法。她在 Google 和 Meta 做了十年 AI PM，建议每周花十五分钟做三件事：让模型做一件明显错的事、让模型做一件模糊的事、让模型做一件意外难的事。看它在这三种情况下怎么坏。坏的方式叫 failure signature——模型在被压到边界时反复掉进的那个坑。
这个动作的目的不是"测试模型"，而是看清楚产品要建在哪一块地基上。同一个想法，今天的模型在哪里能做对、在哪里会自信地编造一个看似合理的结果、在哪里会陷入循环——这些信息决定了产品的形态。一个 PM 如果不知道模型的 failure signature，他设计的产品就是基于幻觉。Marily 给的一个例子很直接：把一段杂乱的 Slack 聊天扔给模型，让它提炼"战略性产品决策"——模型会自信地编出一份路线图、分配错的负责人、把随口一句话变成承诺。这种 failure signature 一旦你见过，就再不会被一个看起来漂亮的 demo 骗到。
Meta 最近改了 PM 面试，新加了一轮叫 Product Sense with AI——让候选人在面试现场跟 AI 一起解决产品问题。考察的不是 prompt 写得多巧、对模型多熟，而是候选人能不能看出模型在哪里开始猜、什么时候该追问、面对不完整的信息怎么做决定。这是 Meta 五年来最大的一次 PM 面试改动。一个新岗位类别就是这样从空白长出来的。
理解了模型在哪里坏，"决定做什么"这件事就有了起点。
具体形态是这样的：你想做一个功能，今天的模型做不到，输出错误率三成。按传统 PM 的判断框架，这件事不能立项——技术不成熟，做出来不能用。但如果你已经摸清了这个三成错误的 failure signature，知道它在哪些场景下成立、在哪些场景下崩，对的判断可能是相反的——现在就开始建，把那些模型已经做得对的场景先做成产品，把它做不对的场景设计成 guardrail（后面会专门讲），等下一代模型出来直接接上。如果你等模型完美了再动手，那时市场上已经有十个人占住了这个位置。
Cat Wu 给了一个相关的判断准则——"永远做最简单的实现"。如果今天的模型不够好，不要急着搭一套巧妙的脚手架去绕过它。下一代模型出来，绕过的方案就成了负债，它是为已经不存在的限制设计的。这个原则听起来反工程师本能。工程师的天职是遇到问题就解决，绕过限制是基本动作。但在 AI 产品里，"等等看"有时候是最优解。这需要 PM 有一种新的判断能力——分辨出哪些限制是结构性的、哪些只是"这一代模型暂时不行"。结构性的限制值得投入设计去绕开，时间性的限制只需要做最笨的实现，等下一代模型自然解决。
我自己做技术管理多年，过去面试产品和工程师，看一个人能不能做事，主要看他能不能把不清晰的需求拆成清晰的执行计划。这个能力现在依然重要，但它变得不够了。新的要求是能看着今天还做不到的事情，判断它"下个月做到"和"两年后才做到"的概率分别多大，并据此决定现在投不投入。这是一种预判能力，跟规划能力是两件事，大多数人身上不会同时具备。
决定什么是好的：eval 和 MVQ
Cat Wu 在访谈里把 eval 列为 PM 最被低估的技能。她说团队里很多功能开发的流程是这样的——PM 写五个 eval、给出运行方式、列出哪几个通过哪几个没通过、再写一段提示词来提升通过率，这就是 PRD 的替代品。
这件事在传统产品语境里几乎不存在。传统 PM 衡量"好不好"靠的是用户反馈、A/B 测试、留存指标——这些都是在功能上线之后才能得到的信号。开发之前的"什么算好"，主要靠 PM 在 PRD 里写的验收标准，本质上是一段自然语言描述。
AI 产品里这套不工作。原因是 AI 产品的输出空间太大、变化太多。同一个 prompt，模型今天输出 A、明天输出 B 都可能是合理的；同一个功能，对用户 X 是惊艳的、对用户 Y 是噪音。一段自然语言的验收标准根本量化不出来"这一版比上一版好在哪"。
eval 就是这个问题的答案。它是一组可执行的、可重复的、能给出数字结果的测试用例，把"什么算好"从模糊的描述变成了量化的输出。一个功能从 60% 通过率提升到 75% 通过率，这个数字本身就是判断载体——它告诉团队哪些 prompt 调整有效、哪些没效，让"这一版好不好"这个问题从主观争论变成客观比较。
Aman Khan 在 Lenny's 上写过一篇 eval 完整指南，他是 Arize AI 的产品负责人、跟 Andrew Ng 一起开过 eval 的课。他把 eval 分成三类，每类的用法都不一样：
第一类是 human eval——产品里嵌入用户反馈机制（点赞点踩、评论框），或者请领域专家手工标注。优点是直接对应终端用户感受，缺点是稀疏、慢、贵。
第二类是 code-based eval——用代码检查模型输出。比如生成的代码能不能跑、API 调用是不是合法、关键字符串有没有出现。优点是便宜快，缺点是只能测客观的事，主观的好坏测不了。
第三类是 LLM-as-judge eval——用另一个 LLM 作为判官来给模型输出打分。优点是可以测主观的事（语气、相关性、是否回避），而且 PM 自己就能写判官的 prompt，不需要工程师介入。缺点是需要先用人工标注样本来校准判官 LLM，结果是概率性的不是确定性的。
这三种放在一起用，覆盖了 AI 产品大部分的"好不好"问题。一个 PM 真正掌握 eval，意味着他能看着一个 AI 产品场景，判断这件事应该用哪一类 eval、需要写多少个用例、怎么校准、阈值定在哪里。这些都是新的产品工艺。
Aman Khan 还总结了写好一个 LLM-as-judge eval 的四个组成部分：给判官 LLM 一个角色（你正在审阅一段文本）、提供上下文（被打分的内容是什么）、说清楚目标（要测的是什么、什么是好什么是坏）、定义术语（"toxic" 在你的场景下具体指什么）。这四件事任何一件没说清楚，eval 就会失准。
Eval 解决了"这一版比上一版好"的问题，但还有一个更上层的问题——整个产品到底好到什么程度才能上线？
Marily Nika 提出过一个对这个问题很有用的框架，叫 MVQ（Minimum Viable Quality），最低可接受质量。它把"好"拆成三道阈值：
- acceptable：达到这个标准，可以给真实用户用了
- delight：达到这个标准，用户会觉得这个产品有魔法
- do-not-ship：低于这个标准，绝对不能发布，因为会破坏信任
她举的例子是智能音箱的声纹识别。acceptable 是"在普通家庭环境里能正确识别说话人 x% 以上，识别不出来时优雅地降级（询问要不要用默认账号继续）"；delight 是"用户停止重复指令，没有'不，我是说...'这种修正"；do-not-ship 是"在关键流程上（支付、消息）误识别超过 y%"。
MVQ 跟 eval 是一对。eval 告诉你今天这个版本的指标是多少，MVQ 告诉你这个指标要到哪个数才能上线。两者合在一起，"什么是好的" 就从一个主观判断变成了一组可以讨论、可以辩论、可以推进的数字。
MVQ 还有一个被低估的作用——它把"成本"放进了"好"的定义里。Marily 提到她见过 AI PM 最常犯的错是爱上一个漂亮的 demo，但不去算这东西在 scale 下的运行成本。一个功能如果每个用户每月成本 $0.30 而且能带来留存，是个划算买卖；同样的功能如果做到 $5/用户/月而效果不明确，那它就是个商业问题。MVQ 把这个判断从"做完之后才意识到"提前到"立项之前就想清楚"。
回到 Cat Wu 说的那种工作模式——PM 写五个 eval、跑一遍、看哪些过哪些没过、再调 prompt 提升通过率——这个工作流的真正价值在于：PM 输出的不再是文档，是可运行的测试集。文档需要被人读、被人理解、被人执行；测试集自己会跑、自己会给出结果、自己会显示进步。前者的产出是说服力，后者的产出是确定性。AI 时代真正稀缺的是后者。
招聘市场上能看到这种供需错配。Lenny Rachitsky 用 TrueUp 的数据做过统计，全球开放 PM 岗位 6000 多个，其中 AI 相关的 PM 岗已经接近 700 个，曲线在 2025 年陡峭上行，全球三分之一集中在湾区。但能写 eval、能设 MVQ、能区分三类 failure mode 的 PM 在市场上极度稀缺。我接触过不少传统 SaaS 出身的 PM 转 AI 产品的，最常卡住的不是想不清楚要做什么，是不会做 eval——产品直觉没问题，但因为不能把直觉量化成测试用例，他们的判断停留在自己脑子里，没法传给团队，也没法跟模型一起进化。这是当下 AI PM 招聘市场最大的错配。
决定什么时候停：guardrail 优先于修复
第三个判断子问题，是最微妙的：什么时候应该停下来。
AI 产品有一个特殊性——它的失败不是"做错了"，而是"做了一件看起来对、其实错"。一个用户看上去满意的功能，背后可能是模型在某个 edge case 上输出了完全错误的结果；一个跑起来一切正常的 agent，可能在某个特定输入下会陷入死循环。这些问题在传统软件里也有，但 AI 产品里数量级更大、更隐蔽。
面对这种隐蔽的失败，PM 的本能是"想办法让它别错"。但 AI 产品里更经常对的做法不是修，是 设 guardrail——给模型划一个边界，告诉它什么时候不要回答、什么时候要降级到询问用户、什么时候要拒绝执行。
Marily Nika 给过一个很具体的例子。她跟一个 startup 做过一个 AI 功能，把长 Slack 讨论自动总结成 "decisions and action items"。测试时效果不错，上线之后开始出问题——它会给 action item 分配负责人，但很多时候那些人根本没同意接活。有时候它甚至挑错了人。
team 的第一反应是换更好的模型。但通过观察 failure pattern，他们发现问题不在模型，在产品边界没定清楚。fix 不是换模型，是在 system prompt 里加一句："只在有人明确自愿、或者被直接询问并确认后，才指派负责人。其他情况下提炼主题，问用户接下来怎么办。" 一行字，最大的信任问题立刻消失。
这就是 guardrail 的本质——它定义的不是"产品应该做什么"，是"产品在模型撞墙时应该退让到哪里"。
Cat Wu 在访谈里讲过一个让模型自己反思的技巧，跟 guardrail 是一对。当模型做了一件意料之外的事，让它自己分析为什么做了那个决定。她举的例子是：模型给一个前端做修改，只跑了测试，没有实际用 UI 验证。如果你直接问模型"为什么不验证 UI"，它通常会给出有用的信息——可能 system prompt 里有让它困惑的地方，可能它没意识到前端验证是这个任务的一部分，可能它把验证委托给了 subagent 但没检查 subagent 是否完成。这些回答指向的不是"模型笨"，是 harness 里哪里需要加料、guardrail 该划在哪里。
这两件事——让模型自己讲为什么这么做、然后据此设 guardrail——构成了 AI 产品里"什么时候停"的核心动作。停下来不是放弃，是把"修复"这个动作往上提了一层——不是修这个 case，是修产品边界。修单个 case 永远修不完，划清边界一次就够了。
一个 PM 学会这套动作，他面对 bug 时的第一反应会从"加需求让它不要再这样"变成"问模型为什么这样、然后看 guardrail 要不要重划"。这是 AI 时代 PM 跟传统 PM 在判断逻辑上最大的分叉之一。
判断力从哪里来
判断"做什么"、判断"什么是好的"、判断"什么时候停"，三件事都比过去难。这种判断力从哪里来？
我做技术管理这些年，面试和带过的产品、技术 leader 不算少。判断力的强弱有一部分是天生的，但是更多的是可以后台培养的。判断能力有几个来源相对清楚，每一个都可以刻意养成。下面这五件事不是并列关系，是互相补的——少了任何一个，判断力都会有结构性的盲区。
经验——亲手做过、亲手撞过墙留下的体感。Cat Wu 反复强调 Anthropic 招 PM 几乎都是工程师出身、或者直接在 Claude Code 里写代码，根本原因就在这里。一个没写过 eval 的 PM 没法判断 prompt 的输出是不是真的更好，他只能转述工程师的判断。读文章、听汇报、看 demo 能给词汇，给不了直觉。不能/不愿亲自动手的 PM 肯定不是好的 PM，这点在 AI 时代更加明显。
同理心——判断"什么是好的"，本质上是判断"对用户来说什么是好的"。纯靠数据会得到合理但平庸的产品，纯靠 PM 自己的偏好会得到有 taste 但用户不一定买账的产品。中间那个平衡靠的是同理心。AI 产品里同理心尤其重要，因为输出有高方差，"看起来挺酷的"和"用户真的需要"经常是两件事。一个 demo 能让团队兴奋，但用户在真实场景下根本用不起来——区分这两种状态只能靠同理心。
第一性原理——AI 产品决策里最容易踩的坑是被表面现象带跑。一个功能爆了就去复制，一个 case 失败了就堆 prompt 去 fix 那个 case，短期看起来都对，长期累计下来是一个臃肿的产品。第一性原理是把每个决策拆到"它要解决的根本问题是什么"。Cat Wu 那个"永远做最简单的实现"，背后就是第一性原理——巧妙方案不解决根本问题，只是补丁化地应对当前模型的缺陷，模型升级后就变成负债。
逻辑思考——从证据推出判断，而不是从情绪、立场或者老板的偏好推出判断。我见过太多 PM 明明数据已经在那里，但因为不喜欢方向，硬要找理由说"这个数据可能不准"；也见过相反的情况，样本量很小、结论站不住，但因为符合自己已有的判断，就拿去支撑决策。AI 产品里这件事更难做到，因为很多直觉判断在短期内确实正确（模型在快速变好，蒙对的概率高），让人误以为自己的直觉很强。
data driven——但这里要小心一种误解。data driven 不是"看数据做决策"，它是用数据来校准自己的直觉。纯看数据有两个常见失败模式：一是指标本身不对，看 DAU 不看任务完成率；二是数据滞后，等数据说话的时候，机会窗口已经关了。AI 产品的迭代速度要求 PM 在数据不全的时候也能做决策，但同时持续用部分数据校准自己有没有跑偏。
这五件事我面试人的时候会按这个顺序考察。少了任何一项，判断力都会出现稳定的盲区——光有手感的人容易做出技术漂亮但用户不买账的产品，光有同理心的人容易被每个用户反馈带着走，太理论的人证据看不进去，纯靠数据的人活在指标里。判断力强的人是这几件事都能用、并且能根据场景知道当下该重点用哪一项的人。这种人在 AI 时代变得比过去稀缺很多，因为执行已经不再过滤错误判断了。
一个判断
如果你现在管着一个产品团队，看完这些可能会想——我们应不应该按这个方向改？我的看法是，不要把这套东西当成模板照搬。Anthropic 是一家 AI infra 公司，他们的产品本身就是 AI 模型，所以 PM 写 eval、跟模型反思，是工作的天然组成部分。不是所有公司都是这样。
但有一件事是普适的——如果你的产品组织还在按"执行慢"的逻辑配置 PM，比如要求 PM 写详细 PRD、按季度做 roadmap、用项目经理的方式去做跨部门协调，那你在解决一个已经不存在的问题。执行不是瓶颈了，对齐和协调也不再是 PM 的核心价值。继续按老的方式配置 PM，等于花一份工资去维护一个不再产生价值的岗位。
这个问题不在"要不要变 AI Native"，它更像一个配置错误。配置错的岗位再尽力，也只是在解决一个不再存在的问题。值得每个产品组织问自己的是：你的 PM 现在花最多时间在做的事，是判断"做什么是对的"、"什么是好的"、"什么时候应该停"，还是在写文档、开对齐会、推进项目进度？如果是后者，那不只是组织慢——是你的 PM 团队正在变得不重要。
