AI 产品团队的速度，来自一套更短的判断回路

Cat Wu 在 Lenny’s Podcast 的访谈里讲了一个很小的场景。

她要为 Code with Claude 大会准备一场演讲，主题是 Claude Code 如何从助手走向完整的智能体。过去，这类工作通常意味着：翻 Slack、找发布记录、看内部案例、整理产品叙事、做幻灯片、对齐设计系统，再反复改稿。

她把 Google Drive、Slack、Gmail、Calendar 等上下文交给 Co-work，给出产品营销同事的建议、自己的草稿和想讲的故事线。Co-work 跑了一个小时，整理 Twitter、发布室、Claude Code 公告频道和内部案例，生成了一份 20 页的演示文稿。她第二天醒来看到稿子，觉得已经相当不错，只需要继续压缩文字、挑选更有说服力的演示。

这个场景最值得注意的地方，不是 AI 会做 PPT。

真正的变化是：AI 把“整理可能性”的成本压低了，而产品经理的价值被挤到更前面的一层：决定什么应该进入最终叙事，什么应该被删掉，哪个演示最能说明产品进化，哪条故事线值得被团队押注。

Cat Wu 对 AI 产品管理的判断可以压缩成一句话：当写代码、做稿子、整合信息都变快以后，团队真正稀缺的是高频判断。

以前，产品团队把大量精力花在降低执行浪费上。路线图、PRD、跨团队协调、季度计划，都有其合理性。代码很贵，发布很慢，一个功能如果和另一个团队撞车，代价很高。于是产品经理要提前把路铺平，尽量减少返工。

现在，Anthropic 这样的 AI 原生团队遇到的是另一种约束。功能规划从六个月变成一个月、一周，甚至一天。工程师可以从 Twitter 上看到用户反馈，周末就把功能推给用户。Claude Code、Co-work 和内部模型让原型、文档、客户材料、定制工具的生产速度都提升了。

执行变便宜以后，旧流程不会自然失效，但它的主战场变了。团队更需要一套短回路，让判断快速产生、快速落地、快速被现实修正。

速度来自明确目标，而不是更多混乱

很多人看 Anthropic 的发布节奏，会把原因归结为“他们有最强模型”。访谈里 Cat Wu 明确说，模型确实提升了一些速度，但主要原因不是模型本身，而是流程和团队预期。

她举了 Claude Code 的例子。一个好的目标不是“减少权限提示”，而是更具体地定义：

核心用户是专业开发者；问题是权限提示太多造成疲劳；目标用例是让企业里的专业开发者能够安全地实现零权限提示。

这种目标有一个重要作用：它排除了大量看似相关的方案。团队不再围绕“我们能不能让提示少一点”争论，而是围绕“什么方案能让这个用户在这个场景里安全地走到目标状态”行动。

这也是 AI 产品团队和传统产品团队的一个关键差别。AI 模型很通用，通用性会制造模糊性。你可以把同一个模型包装成聊天工具、代码工具、办公助手、客户支持、数据分析、浏览器代理。方向一多，团队就容易用速度掩盖混乱。

所以 AI 产品经理的第一项工作，反而是收窄。

收窄用户，收窄任务，收窄成功标准，收窄不做什么。Anthropic 会保留团队准则清单，让团队理解核心用户是谁、业务怎样运作、哪些取舍是被允许的。它还会每周做指标复盘，让每个人理解业务趋势和驱动因素。

这类机制听起来不如“每天发布功能”刺激，但它们决定了每天发布出来的东西是不是朝同一个方向走。

PRD 变薄以后，评估变厚了

访谈里有一个细节很重要：Anthropic 仍然会写 PRD。特别模糊的功能、重大基础设施项目，仍然需要文档来阐明目标、愉悦用例和当前故障模式。

变化不在于 PRD 消失了，而在于 PRD 不再是唯一的对齐载体。

Cat Wu 提到，构建 AI 产品时，评估被严重低估。她不认为每个功能都需要数百个评估。很多时候，10 个出色的评估就能帮助团队量化目标、进展和缺口。对于某些需要更多产品定义的功能，她会介入产出类似这样的东西：5 个评估、运行方法、哪些成功、哪些失败、用来提高成功率的提示词。

这说明 AI 产品的“成功定义”正在从静态描述走向可运行样本。

传统 PRD 擅长回答：我们要做什么？给谁用？有哪些功能？上线后看什么指标？

AI 产品还必须回答：模型在什么样的输入下会失败？怎样算完成任务？哪些边界案例必须被捕捉？提示词、工具、记忆、权限、UI 引导分别在帮助模型补哪一块能力？

当产品的核心行为来自模型，团队不能只写“用户可以完成代码审查”。它还要定义：什么样的代码审查算可信？哪些漏洞应该被发现？怎样避免生成泛泛建议？什么时候需要多个代码审查代理并行遍历代码库？工程师在合并前应该看到怎样的问题列表？

这就是为什么评估开始接近产品管理的核心。评估不是测试团队的附属品，而是产品经理把“好”变成可运行现实的方式。

快速发布需要一种可撤回的承诺

Anthropic 几乎把 Claude Code 的大量功能都以“研究预览版”发布。这个做法降低了发布心理负担：团队明确告诉用户，这是早期想法，是为了获取反馈和迭代，未来可能不会长期支持。于是功能可以在一两周内推出。

这不是草率发布，而是一种承诺设计。

传统产品发布默认带有长期支持承诺。一个功能一旦进入正式产品，用户会期待稳定、完整、文档齐全、和其他功能一致。AI 产品团队面对的是模型能力快速变化、用户行为快速变化、功能形态还在探索的环境。如果每次发布都背上正式承诺，团队很快会被自己的历史拖慢。

研究预览版把承诺拆成两层：

第一层，团队承诺认真听反馈、快速迭代、修复不阻碍核心用例的问题。

第二层，团队暂时保留重新设计、合并、下线或弱化功能的权利。

这对 AI 产品尤其重要，因为很多功能本质上是模型当前能力的“辅助结构”。当模型变强，这些结构就要被重新评估。

Claude Code 的待办事项列表就是例子。早期模型做大型重构时，可能说要改 20 个调用点，改了 5 个就停住。团队把人类的工作方式借给模型：列出所有调用点，逐一检查，确保做完。待办列表帮助旧模型完成任务。

后来的模型自然能追踪这些事项后，团队就不再需要强制模型使用待办列表。它仍然对用户有价值，因为用户可以看到 Claude 在处理什么，但它从“模型必须依赖的拐杖”变成了“用户理解进度的界面”。

这类功能如果一开始就被设计成不可动摇的正式承诺，产品会越来越重。AI 产品团队需要有能力把帮助模型的结构，在模型成长后转化为帮助用户理解、控制和信任的结构。

AI 团队的产品品味，是判断该保留什么

“产品品味”在访谈里出现了多次。这个词容易被误解成审美、直觉或个人偏好。放到 AI 产品里，它更接近一种动态判断能力：在模型能力、用户需求、工程难度和组织目标都快速变化时，判断什么值得做，什么值得删，什么值得先试，什么需要等模型追上来。

Cat Wu 说，未来几个月最有价值的技能组合都会快速更新。工程背景现在有用，因为它能帮助判断一个东西到底难不难。如果一件事一小时就能做出来，与其争论，不如做出来。如果一件事成本高，就需要更慎重地优先级排序。

这背后是一个很实用的原则：当执行成本下降，讨论成本也要下降。

过去，团队会用会议和文档过滤掉很多想法，因为试错太贵。现在，一些低成本想法可以直接做成研究预览、内部工具或小范围实验。产品经理不需要在每个想法出现时都充当审批者，而要设计默认路径：哪些想法可以直接试，哪些想法需要评估，哪些想法需要安全和企业团队提前介入，哪些想法必须升格为长期基础设施项目。

下面这张表可以作为 AI 产品团队处理需求的默认路由。

这张表的重点不是流程本身，而是默认动作。AI 产品团队不能把所有需求都塞进同一个 PRD 管道，也不能把所有想法都交给工程师自由发挥。它需要把判断变成路由系统。

自动化的价值，卡在最后 5%

访谈后半段，Cat Wu 给普通知识工作者的建议也很具体：找出那些重复、繁琐、自己不喜欢做的工作，用 Claude Code、Co-work 或其他 AI 工具自动化。但她马上补了一句更重要的话：很多人把自动化做到 90%-95% 就停了，而一个需要持续人工清理的自动化，往往不能真正释放时间。

这句话对 AI 产品团队同样成立。

演示文稿生成、客户会议简报、定制销售材料、代码审查、Gmail 收件箱整理，看起来都很适合自动化。但 95% 的成功率在不同任务里的价值完全不同。一个演示文稿 95% 可用，人工改一改就能交付；一个邮件分类器 95% 准确，偶尔把重要邮件扔进垃圾文件夹，用户就会失去信任；一个代码审查工具如果漏掉关键漏洞，团队就不能把它当作合并前的可靠环节。

因此，AI 产品经理要区分两类任务。

一类任务可以接受“高质量草稿”。AI 负责综合、起稿、提出可能性，人类负责最后判断。Co-work 生成 20 页大会演示稿就是这种任务。它不需要一次完成，因为产品经理的判断本来就应该留在最后。

另一类任务必须接近“可靠委托”。比如权限控制、邮件过滤、代码审查、客户承诺信息查询。用户把它交出去以后，希望它在后台稳定运行。对于这类任务，最后 5% 的错误就是产品价值本身。

这也是为什么未来的产品品味不只是会想功能，还要会判断可靠性要求。不同任务对“完成”的定义不同，不同自动化需要不同的信任门槛。

速度会制造一致性债务

快速发布不是没有代价。Cat Wu 在访谈里直说，角色融合和高频试验牺牲了产品一致性。

过去代码昂贵，团队会仔细规划产品套件，确保每个产品对应一个用例，彼此不重叠。现在想法太多，需要快速测试，功能之间有时会重叠，甚至同一个问题会出现两种不同形态。对内部团队来说，这是探索；对新用户来说，这是困惑。

用户不知道完成任务的最佳路径，也跟不上每天的发布节奏。于是 Anthropic 需要更多用户教育，比如 slash power up，把用户真正需要掌握的核心能力打包出来。过去团队不想做教程，因为他们相信产品应该直观到不需要上手流程。后来功能太多，用户想知道“100 个功能里我绝对需要用哪 10 个”，产品原则就要跟着现实调整。

这提醒了 AI 产品团队一个容易忽视的问题：速度会把学习成本转嫁给用户。

如果团队只优化发布速度，不优化用户理解速度，产品会变成一台越来越快的跑步机。最懂产品的人每天都兴奋，普通用户每天都落后。

因此，AI 产品的用户教育不是边角料，而是高频发布之后的必要补偿。它决定用户能不能把新能力吸收到自己的工作流里。

组织使命是最高层的路由规则

Anthropic 的另一个速度来源，是统一使命和专注。Cat Wu 提到，当两个优先级冲突时，团队会讨论哪一个更服务于 Anthropic 的使命。她甚至说，如果 Claude Code 失败但 Anthropic 成功，她会很高兴。

这句话放在商业语境里很重。它说明团队的产品线目标，可以在公司使命面前让位。

很多公司也有使命，但使命常常只是对外表达。真正有用的使命，是内部取舍工具。它让团队知道什么时候该牺牲自己的 KR，什么时候该推迟某个产品功能，什么时候该优先支持第一方产品和 API，什么时候该拒绝看起来有增长但偏离方向的机会。

AI 公司尤其需要这种高层路由规则。因为模型通用，机会很多，任何方向都能讲出故事。没有强使命，速度会把组织带向发散；有强使命，速度才会变成复利。

新的 PM 工作：把团队带进更短的现实反馈

这次访谈最有价值的地方，是它没有把产品经理神秘化。

AI 时代并没有让 PM 消失。它让 PM 更接近一套团队操作系统的设计者。

PM 要定义清楚的目标，让模型和团队的通用能力被收束到具体用户和具体任务上。

PM 要设计可重复发布流程，让工程、文档、市场、开发者关系在功能准备好时能快速接上。

PM 要知道什么时候写 PRD，什么时候写一页目标文档，什么时候直接做研究预览，什么时候先做评估。

PM 要理解模型能力边界，能从用户反馈、失败案例、少数高信号用户和小评估集中看出模式。

PM 要在模型升级时重新检查产品，把旧的提示干预和模型拐杖清掉，让产品保持轻。

PM 还要识别速度带来的债务：一致性、教育、信任、可靠性、用户注意力。

这不是从路线图经理变成“全能打杂”。更准确地说，PM 的核心工作从管理长期计划，迁移到了管理高频判断回路。

当 AI 让执行变快，团队最容易犯的错是把速度当成目的。真正好的 AI 产品团队会把速度变成学习能力：更快地暴露错误，更快地判断价值，更快地修正方向，更快地删掉不再需要的东西。

最终留下来的判断框架很简单：

能低成本试的，尽快试。
需要信任的，做到可靠。
模型已经会的，删掉辅助。
用户跟不上的，补上引导。
方向冲突的，回到使命。

AI 产品团队的速度，不是每天多发几个功能。它是一套更短、更诚实、更可验证的判断回路。执行越便宜，判断越值钱。

资料来源

本文基于 Lenny’s Podcast 2026-04-23 期访谈《How Anthropic’s product team moves faster than anyone else | Cat Wu (Head of Product, Claude Code)》的播客摘要和转写材料。