Cat Wu 谈 Anthropic 为什么比所有人都快

一句话总结：Anthropic 把产品发布周期从六个月压到一天，靠的不是更强的模型，而是「极低过程 + Research Preview 兜底 + 工程师即产品经理 + 模型品味」这一整套刻意设计的组织系统。

开场

Lenny Rachitsky 在节目里反复感叹：「我从没见过任何一家公司像 Anthropic 这样发版——有人做了一张日历，几乎每天都有重磅功能上线。」

这就是 Cat Wu 要面对的问题。她是 Anthropic Claude Code 与 Cowork 产品线负责人，搭档技术负责人 Boris Cherny。当主持人追问「你们是不是偷偷用了 Mythos（暗指内部下一代模型）才做到这个速度」时，Cat 的回答干脆利落——不是模型，是组织。

她对所有想抄作业的产品经理只给了一句话：「这不是工具问题，是你愿不愿意把过程砍到最低、把决策权下放、把品味当成稀缺资源这件事情。」

下面把这一小时半访谈里 Cat 真正说清楚的东西重组成四块。

金字塔总览

mindmap
  root((Anthropic 速度<br/>= 组织设计))
    一·把过程砍到最低
      不写多季度路线图
      Research Preview 降低承诺
      引擎师有完整发布通道
    二·目标清晰 + 团队原则
      明确谁是核心用户
      每周指标 readout
      取舍透明 自主决策
    三·工程师 + 产品品味
      角色融合 PM/Eng/Design
      招带 taste 的工程师
      端到端 一周内发布
    四·AGI-pilled 钢丝
      不能太信现在
      也不能只造未来
      品味 = 知道模型边界

一、把过程砍到最低，把承诺降到最浅

Cat 上来就纠正一个最大的误解：速度不是「写更快的代码」，而是「拿掉一切阻挡发布的东西」。

她说的「东西」很具体：

• 不再做多季度路线图对齐。AI 之前的世界里，PM 大部分时间在和合作团队对齐六到十二个月的计划，因为代码太贵、写慢，必须事先把依赖排好。今天模型能力以月为单位跳变，「把产品功能的交付周期从六个月压到一个月，有时甚至一天」。多季度对齐反而成为最大障碍——对齐到的那个未来已经不在了。
• 几乎所有功能都先以 Research Preview 形式发布。这是 Anthropic 自创的一个产品标签，明确告诉用户「这是早期产品、想法、用来收集反馈、可能不会永远支持」。Cat 的原话是：「它降低了我们的承诺（it reduces our commitment）——我们就可以一两周内把东西丢出去。」这不是营销话术，是一个组织级的兜底机制——承诺越低，决策门槛越低，发布越快。
• PM 的职责是为团队铺路，不是把守闸门。她举了一个具体流程：工程师觉得功能内部 dogfood 通过了，就贴到一个常驻的 evergreen launch room；负责文档的 Sarah、PMM 的 Alex、DevRel 的 Tarek 和 Lydia 第二天就能把发布稿写出来。「PM 的角色是把这个流程搭出来，不是当审批节点。」

金句：我们想把一切阻挡发布的障碍都拿掉——团队里每个人都应该有权把自己的想法在一周内、有时一天内推向世界。

二、目标足够清晰，团队才能自己跑

如果只把过程砍掉而不给方向，团队会原地打转。Cat 说 Anthropic 的解法是「少做过程，多做对齐」——而对齐靠两件事。

第一件，每周指标 readout。 全团队一起看核心指标怎么动、什么在驱动它、和目标差多远。她说目的不是审视谁该背锅，而是「让每个人都深度理解业务的每一个面向」。当一个工程师知道某个指标是为什么涨的，他下次提想法就会自带优先级判断。

第二件，明文写下来的团队原则（team principles）。 这份清单包括：核心用户是谁、为什么是这些人、哪些事情我们愿意牺牲。Cat 强调它的真正作用：「让大家可以自己做决策，不被 PM 或别的角色卡住。」

LLM 这种通用工具放大了模糊性——谁都能用、什么都能做、看上去什么问题都可以解。她举了一个 Claude Code 的例子：核心用户是企业专业开发者；要解决的是「权限提示太多导致疲劳」；目标是「安全地把权限提示数量降到零」。「这个目标其实排除掉了一大堆潜在方案」——这就是清晰目标的力量。

至于 PRD？Cat 的回答很务实：「我们偶尔也写。」只有在需求特别模糊、或者要做长达数月的基础设施时，才会写一页纸，列清楚目标、令人愉悦的用例（delightful use cases）、当前失败模式。其它情况靠 readout + 原则就够了。

金句：我们花时间把这些都写出来，是为了让团队里每个人都觉得自己理解这门生意——知道什么对我们重要，我们愿意牺牲什么。

三、与其招 PM，不如招带 product taste 的工程师

Lenny 提到上一期嘉宾 Amjad（Replit CEO）的观点：因为工程师在 AI 加持下跑太快，PM 和设计反而成了瓶颈，所以要招更多 PM。Cat 给的答案截然相反——

「我觉得所有角色都在融合。PM 在写代码，工程师在做 PM 的事，设计师既 PM 也提交代码。」

Anthropic Claude Code 团队的具体选择是：保持工程团队规模，重点招带产品品味（product taste）的工程师。她说团队里很多工程师能完整地从「在 Twitter 看到用户反馈」一路走到「周五把功能上线」，整个过程几乎不需要 PM 介入——「这其实是最高效的发布方式」。

她自己就是工程师出身，团队里几乎所有 PM 也都做过工程师或还在写代码；设计师之前都是前端工程师。这种背景重叠带来两个直接好处：

1. 建立信任。工程师不会把 PM 当成「不懂技术的外行」。
2. 判断难度。「如果你有工程背景，就更清楚一件事该做多久。如果一小时就能做完，就别开会讨论，直接做；如果很难，就提前知道它要花团队多少钱。」

那 product taste 到底是什么？她解释得很直接——「代码越来越便宜，决定写什么变得更值钱」。Claude Code 一个项目就收到几万个 GitHub issue，要从里面挑出哪些值得做、用什么方式做，靠的不是流程，是品味。

金句：当代码变得越来越便宜，更值钱的事情就是决定该写什么。

四、走钢丝：在「今天的模型」和「明天的 AGI」之间

Cat 全场最戳人的一句话是开头那句：「要做到刚刚好程度的 AGI-pilled 其实非常难。」

「AGI-pilled」是 Anthropic 内部黑话，大意是「相信 AGI 真的会到来、并据此做决定」。Cat 把这件事拆成两端的陷阱：

• 太相信现在——为今天的模型做精细产品，明天模型一变能力，整套产品逻辑作废。
• 只造未来——「为超强 AGI 模型做产品其实非常容易：一个文本框，扔过去自己解决就行。」但这种产品在今天毫无用处，因为今天的模型还不够强。

真正难的是中间那条钢丝：「为今天的模型做产品，但要找到一种能引出模型最大能力（elicit the maximum capability）的方式。」

这就是为什么品味这么稀缺。Cat 说她自己每天花大量时间和模型对话、用它做事、观察它在什么地方出错。她举了一个具体例子：模型经常会改完前端代码、跑测试通过就交差，但根本没真正去 UI 上点一下看效果。「这种时候我会让模型反思自己为什么这么做」——这种近乎临床观察的耐心，就是 Cat 说的「知道每个模型的能力边界」。

Boris 负责拉远——「这个产品三到六个月后应该是什么样、AGI-pilled 版本是什么样」。Cat 负责拉近——「从今天到那个愿景之间的具体路径」。她说两人「大概 80% 是 mind meld（心电感应）」，剩下 20% 各自驱动自己更在意的事。

她还补了一句对未来 PM 的判断：「现在的环境奖励那些能戴很多顶帽子、愿意切换、对自己做什么工作 ego 很低的人。」——只要能帮团队跑得更快，干什么都行。

金句：「为超强 AGI 模型做产品很容易；难的是搞清楚针对当下的模型，怎么把它的最大能力引出来。」

一页速览

一句话收束

速度从来不是冲刺出来的——是把过程砍到最短、把决策推到最近、把品味提到最高之后的副产品。