AI 原生产品团队怎么工作:来自 Claude Code 产品经理的经验

Cat Wu 是 Anthropic Claude Code 和 Cowork 的产品负责人。她在 Lenny 的 podcast 上讲了 Claude Code 团队内部的工作方式——发布节奏、PM 和工程师的角色融合、跨职能协作怎么跑。这些细节大部分是第一次对外讲清楚。

这篇文章整理了我认为最值得 AI 产品公司关注的几块：发布周期从月变成天之后，PRD、roadmap、跨职能协作和 PM 技能结构都发生了什么变化。播客见原文链接。

发布周期从月到周到天

Cat 说得很直接：AI 之前，技术变化慢，规划可以按 6 到 12 个月来做，因为写代码贵，所以强调和各个 partner team 对齐长期 roadmap。现在，很多产品功能的时间线从六个月压缩到一个月，有时候压缩到一周，甚至一天。

她给了一个具体的流程例子——Research Preview。Claude Code 几乎所有的新功能都作为 Research Preview 发布。在 UI 上明确打标签告诉用户：这是早期产品，只是一个想法，我们在收集反馈，这个功能未来可能不会一直存在。

这个做法的意义不是”让产品看起来没那么正式”，而是降低团队的承诺成本。用 Cat 的原话说：”这降低了我们发布东西的承诺。我们可以在一两周内就把一个东西发出去。”

一个产品一旦被当作正式功能发布，团队就需要承诺长期支持、处理 edge case、做完整的文档和回归测试。Research Preview 这个标签把这些承诺拆掉了，于是任何工程师有一个想法，周内就可以推给用户。

Lenny 问她，你们发布这么快，是不是因为内部用上了 Mythos（Anthropic 内部那个能力极强但还没发布的模型）。她的回答：

“Mythos 是一个极其强大的模型。我们内部确实在用这些模型。这稍微提升了一点我们的发布速率，但不能解释大部分增量。我觉得大部分来自流程和团队的期望。”

团队低流程是最重要的。他们希望每个人都觉得自己可以把一个想法在一周内、有时一天内推向世界。这个文化本身比工具更重要。

PRD 少了，原则多了

传统的 PM 工作模式里，PRD 和多季度 roadmap 是核心载体。Cat 说，他们几乎不写 PRD 了——除了两类场景：

一类是”模糊度特别高的功能”。这种情况下写一个 one-pager 有用：目标是什么、什么是 delightful 的使用场景、现在的 failure mode 是什么、需要修复什么。

另一类是”需要重基础设施投入的项目”。这种项目天然需要几个月时间，所以仍然写完整 PRD。

那么替代长 PRD 和 roadmap 的是什么？Cat 讲了两件事：

第一件是每周 metrics readout。 团队每周做一次完整的指标回顾，目的是让每个人都深度理解业务的各个方面——核心目标是什么、趋势如何、背后的驱动因素是什么。

第二件是团队原则（team principles）。 这份列表包括：谁是我们的核心用户、为什么是他们、我们愿意做什么取舍。Cat 说：

“我们明确写出所有这些，是为了让团队每个人都觉得自己理解业务如何运转、什么对我们重要、我们愿意牺牲什么。这样每个人都能自己做决定，不需要等 PM 或其他 stakeholder。”

这是一个很重要的转向。传统 PM 把大量时间花在”对齐”上——对齐 roadmap、对齐优先级、对齐每个跨职能团队。当发布周期是一天到一周时，每个决策都走对齐流程是不可能的。取代它的是：让每个人理解得足够深，使他们能独立做出与团队方向一致的决策。

对齐一次，而不是对齐每次。

跨职能协作的新形态

Cat 描述了 Claude Code 团队的一个具体机制，叫 evergreen launch room。

流程是这样的：工程师觉得一个功能 ready 了，团队内部 dogfood 过了，就在 evergreen launch room 这个频道里发一个帖子。然后 docs 负责人 Sarah、PMM 负责人 Alex、DevRel 的 Tarek 和 Lydia，会在第二天跳进来，把营销公告搞定。

这里有几个值得看的点：

第一，是”评审”而不是”同步”。 这个协作是异步的，工程师不需要拉会、不需要提前几周预约所有 stakeholder 的时间，只需要把功能 post 出来。

第二，是”次日完成”而不是”纳入季度计划”。 传统的跨职能协作里，marketing 和 docs 有自己的排期，一个 feature 要发布通常需要提前几周通知。这里的模式是：工程师决定何时发，其他职能响应。

第三，这个机制本身是 PM 设计的。 Cat 的原话：

“PM 应该是设置这个流程的角色。”

她把 PM 的核心职责重新定义了。不再是”写需求、推进项目、协调资源”，而是”建立一个让工程师可以独立出货的框架”。框架建好了，PM 不需要在每个功能里充当协调人。

这对 PM 来说是个角色转变——从每个功能的 owner，变成团队机制的 owner。

PM、工程师、设计师的边界在融合

Cat 在访谈里反复提到一件事：角色在融合。PM 在做一些工程工作，工程师在做 PM 工作，设计师既在做 PM 也在写代码。她说：

“我们团队上有很多工程师完全可以端到端地操作——在 Twitter 上看到用户反馈，到周末就把产品发了出去，几乎不需要 PM 介入。我觉得这实际上是最高效的发布方式。”

Claude Code 团队招人的倾向是”有出色 product taste 的工程师”，而不是”更多 PM 来引导工程师”。Cat 说这样做的理由是”减少发布任何产品的 overhead”。

值得注意的是，Cat 自己是工程师出身，Claude Code 团队的 PM 几乎都要么当过工程师、要么在 Claude Code 里直接写代码，设计师也大多有前端工程背景。这不是偶然：

“这是帮助团队建立信任的事情之一，也让我们可以跑得更快。”

PM 在团队里是否有执行能力，直接决定了他们是成为加速器还是瓶颈。

这个融合是有代价的。Cat 坦率地讲了牺牲了什么：产品一致性。

传统上，代码写起来贵的时候，你会仔细规划整个产品矩阵、产品之间的关系、每个产品对应的用例——通常每个用例对应一个产品。现在，因为 AI 跑得太快、要测试的想法太多，有时候会出现功能之间重叠。很多时候是因为内部喜欢两种 form factor，想让外部用户告诉他们哪个更好。

代价是：新用户不知道”完成 X 的最佳路径是什么”。Claude Code 里加了一个叫 /power-up 的引导功能，就是为这个问题：

“过去我们不想做 power-up 这样的东西，因为我们觉得产品应该足够直观，不需要任何 tutorial。后来意识到功能太多、需求太大，于是我们偏离了’不做 onboarding’的原初原则，加了这个功能——因为太多用户想知道：这里有 100 个功能，我必须用的那 10 个是哪些。”

这是一个真实的 trade-off。用快速迭代换产品一致性，然后在一致性被损害到一定程度时，再用 onboarding 来补。不是完美，但是一个清醒的选择。

Product taste 是什么，怎么培养

如果角色在融合，那么区分 senior 和 junior 的核心能力是什么？Cat 的答案是 product taste。

“代码变得便宜之后，变贵的是决定写什么。什么是这个功能的正确 UX？什么是用户体验这个功能最 delightful 的方式？我们有数以万计的 GitHub issues 要每一件事，需要很多判断力来决定哪个值得做、应该怎么做。”

Product taste 不是一个抽象的品味问题，Cat 给了很具体的几个培养路径。

第一，和模型大量交互，让模型反思自己的行为。

这个建议我没在别处听过。Cat 的做法是：当模型做了一件意料之外的事，她会让模型自己分析为什么做了那个决定。举例：模型做前端修改时只跑了测试，没有实际用 UI 验证。如果你问模型为什么，它可能会说：system prompt 里有让我困惑的地方、或者我没意识到前端验证是这个任务的一部分、或者我把验证委托给子 agent 但没检查它的工作。

“很多时候，只要对模型为什么做了那个决定保持好奇，你就会看到是什么误导了它，然后可以去修复 harness 来关闭这个 gap。”

PM 在做 AI 产品，模型不是黑盒。让模型自己解释自己的行为，是读取”当前这代模型有哪些局限、harness 里哪里需要加料”的最直接方式。

第二，找到少数几个反馈质量高的人，建立快速反馈回路。

“有一小撮人比其他人更擅长讲清楚什么让一个特定的模型或 harness 组合是好的。找到你最信任的五个人，对快速反馈非常重要。”

反馈不是越多越好，而是越精越好。

第三，建 eval。

Cat 说 eval 是 PM 里被低估的一个技能。你不需要建几百个 eval，有 10 个好的 eval 就非常有用——它帮团队量化目标、量化进展、量化差距。

Claude Code 团队里有一个小组专门和研究团队密切协作，更精确地理解 Claude Code 的行为，测量最大的改进空间在哪里。Cat 自己会在”需要更多产品定义的功能”上跳进去写 eval，输出通常是：这是五个 eval、这是运行方式、这些通过了这些没通过、这是我用来提高成功率的 prompt。

当代码便宜、判断变贵的时候，PM 的核心工作从”写出清楚的需求让工程师执行”变成”定义什么是好的，并用可量化的方式验证”。Eval 是这个新工作的载体。

一条隐藏的逻辑

Cat 讲的这些变化，背后有一条共同的逻辑：当单次交付成本大幅下降时，组织的瓶颈从”执行”变成了”决策”。

代码贵的时候，执行是瓶颈，所以需要 PM 仔细规划、roadmap 长远对齐、跨团队几个月协调——避免执行成本浪费在错方向上。代码便宜了之后，执行不再是瓶颈，决策才是——决定做什么、决定什么是好的、决定何时应该发。

几乎所有变化都可以用这个逻辑推出来：

• PRD 减少，因为写 PRD 是为了让执行者照着做，执行不贵了就不需要这份合约了
• 团队 principles 增加，因为每个人要能独立做决策，就需要理解判断标准
• Research Preview 流行，因为它降低了”发布”这个决策的心理成本
• PM 做 eval，因为 eval 是新的”判断载体”
• 招有 taste 的工程师，因为他们能同时做决策和执行

这条逻辑也解释了为什么 Anthropic 能跑得比别人快——不是因为有 Mythos，是因为他们较早地做了这个组织上的适配。

对任何一个做 AI 产品的团队，值得问的问题是：你的团队结构、流程、合约形式，是按”执行贵”的假设建的，还是按”决策贵”的假设建的？如果还是前者，它不会错，但它会慢。