AI 产品团队为什么跑得快：Anthropic 方法论播客整理
AI 时代，真正的速度不是“更快写代码”，而是“更快知道什么值得做”。
基于 Lenny's Podcast 对 Cat Wu 的访谈整理
AI PM 与传统 PM 的工作差异
AI 工具降低了从想法到原型的成本，也放大了产品判断的价值。代码便宜之后，判断更贵。
| 维度 | 传统 PM | AI PM |
|---|---|---|
| 核心产出 | 长文档（PRD、需求池） | 短定义（任务、成功标准、eval） |
| 推进方式 | 催排期、对齐、评审 | 做原型、跑评测、灰度验证 |
| 与研发的关系 | 需求搬运者，把用户反馈转述给研发 | 判断者，识别模型能力边界和产品适配点 |
| 复盘对象 | 用户行为数据 | 模型推理路径、prompt 误导、工具调用缺口 |
| 核心技能 | 需求拆解、优先级排序 | 能力曲线感知、eval 设计、灰度策略 |
| 时间视角 | 按当前需求规划 | 按模型能力曲线规划，提前下注 |
| 做减法 | 很少，功能只加不减 | 主动删壳子：模型变强后清理补丁和拐杖 |
AI 时代，PM 不是需求搬运者，而是"能力曲线 × 用户任务 × 组织速度"的判断者。
AI 产品如何快速上线
Anthropic 的快不是单点效率，而是一套围绕**"最短反馈回路"**的工作系统：目标收窄 → 可体验原型 → 分层发布 → 模型协同复盘 → 升级即清理。
方法一：目标先收窄，速度才会出来
LLM 产品最容易陷入"什么都能做"的陷阱，但高速度来自清晰边界。速度不是来自多做，而是来自少纠结。
- 核心原则：目标越具体，团队越少内耗。越清楚服务谁，越少内部争论。
- 案例：Claude Code 面向专业开发者，判断标准不是"功能酷不酷"，而是能不能让开发者更安全、更高效地完成任务。
- 落地要点：AI 产品尤其需要先定义"谁在什么场景下，把什么任务交给我们完成"。
点评：和敏捷交付并没有本质区别，但 AI 产品的边界更模糊，更应该面向 eval 开发功能。
方法二：Research Preview - 让产品先进入真实世界
不是粗糙上线，而是降低承诺成本，换取真实反馈速度。
它解决什么问题：
- AI 产品不确定性太高，闭门打磨很容易错方向
- 模型能力、用户行为、场景边界都需要真实反馈校准
- 早期版本需要允许变化、删除和重构
它不是怎么做：
- 不是把半成品不负责任地推给所有用户
- 不是把安全风险暴露给主链路用户
- 不是用"实验"逃避质量标准
点评：依然是灰度发布，但更强调“承诺”分层。或者说“实验用户”，会承担安全风险，更深一层说，实验用户需要更有效的筛选、管理和补偿。 在 to B 的场景下，意味着我们跟大客户需要更深度的共创和彼此信任。
方法三：Evergreen Launch Room - 把协同摩擦压到最低
一个常设发布作战室，让功能从"差不多能发"到"真的发出去"更短。很多团队慢，不是慢在写代码，而是慢在：谁负责、谁拍板、谁出文案、谁过审、谁背锅。
- 运作方式：工程师或产品发现一个功能接近可发布，就进入 Launch Room。文档、PMM、DevRel、产品、工程快速补位，不靠多轮会议等待。
- 目标：不是"所有人充分表达"，而是"必要角色及时把东西送到用户手里"。
点评：和 AI Native 的组织建设是一回事，缩短决策链路、降低摩擦、提升协同速度。
方法四：提前做"模型还没完全撑住"的产品
AI 产品不只看用户需求曲线，还要看模型能力曲线。
| 问题 | 传统产品判断 | AI 产品判断 |
|---|---|---|
| 今天做不稳怎么办？ | 先不做，等能力成熟 | 先做原型和评测，等模型追上 |
| 为什么要提前做？ | 提前做可能浪费 | 能力跃迁时可以第一时间吃到红利 |
| 核心资产是什么？ | 功能本身 | 任务定义、场景样本、评测集、工具链 |
点评：确实是 AI 时代的信特性，AI 产品不能只按当前能力设计，要按下一代能力曲线设计。
方法五：模型升级后，先问"哪些壳子可以删？"
每一次模型变强，产品都应该重新审视前台交互、prompt 和辅助机制。
- 现象：早期模型不够强时，产品会长出很多"拐杖"——按钮、卡片、确认、规则、提示、兜底。
- 问题：模型变强后，如果还保留所有旧壳子，前台就会越来越重，用户感觉不是更智能，而是更复杂。
- 行动：新模型发布后，不只是加能力，也要删掉过时的补丁。
AI Native 不是越做越复杂，而是随着模型变强，前台越来越低熵。
“快”带来的问题
| 风险 | 表现 | 为什么要警惕 |
|---|---|---|
| 功能重叠 | 用户不知道该用哪个 | 入口分层，实验入口与主入口分开 |
| 学习成本增加 | AI 工具更新太快，用户会 FOMO | 产品内教育和渐进式引导 |
| 不一致体验 | 不同实验并行可能割裂 | 评测标准和体验规范先行 |
| 质量波动 | AI 输出不稳定天然存在 | 安全链路不实验，非安全体验可灰度 |
明天就能做的几件事
建立失败案例的评测集（Eval 回归）
难度最低，无需组织变更，今天就能开始。
AI 功能出了问题，当前大概率是"看一眼、修一下、过了就过了"。改成"每个失败 case 沉淀成评测样本"，本质上是在建团队的记忆。没有这个记忆，模型迭代永远在原地打转。
做法：建一个共享文档或轻量表格，每次 AI 输出不符合预期，记下输入、期望输出、实际输出、根因。每周 review 一次，逐步积累 eval set。目标每周沉淀 20 个失败 case，变成下周回归样本。
用一页纸定义 AI 功能目标（目标压窄）
难度低，只需改变文档习惯。
大多数团队做 AI 功能时的真实状态是"领导说要加 AI，我们想了几个场景，都觉得能做但都不深"。一页纸写清楚"谁、做什么任务、怎样算成功"，比写十页 PRD 有用。如果写不出来，说明这个功能本身就不该现在做。
做法：每个 AI 功能启动前，强制写一句话——用户是谁？要托付什么任务？怎样算成功？写不出来就不进入开发。
形成模型升级后的"补丁审计"习惯（删壳子）
难度最高，需要对抗"只加不减"的组织惯性。
模型变强后删补丁，这个动作几乎没有人做。因为"加功能"总是比"减功能"更容易获得认同——加功能有体感，减功能看起来像退步。但 AI 产品的长期竞争力恰恰在前台的简洁度。模型能力上来了，那些为了让旧模型"能用"而加的确认弹窗、死规则、兜底文案，如果不去清理，产品只会越来越笨重。
做法：每次模型升级后，强制做一次"补丁审计"——把所有因为模型能力不足而加的交互补丁过一遍，问"这个补丁还需要吗"。