观点观点 · 产品访谈

Anthropic 的产品团队为什么比谁都快（Cat Wu 访谈）

视频 · Lenny’s Podcast · 嘉宾 Cat Wu（Anthropic，Claude Code 产品负责人） 1:25:34

功能上线周期从 6 个月压到 1 周甚至 1 天，靠的不是模型，是流程和「零障碍发布」

导读

Lenny Rachitsky 对话 Cat Wu，Anthropic 旗下 Claude Code 的产品负责人。一句话概括最反直觉的点：Anthropic 出活快得离谱，但她说这主要不是因为有最强模型，而是流程和团队预期，他们想「移除发布路上每一个障碍」。

这是一期 85 分钟的长访谈，下面按主题做精译导读，点上方「看原片」看完整对话。

一、她和 Boris：80% 脑子接通

Boris（Claude Code 创造者、技术负责人）是产品愿景的人，擅长定「这个产品 3 到 6 个月后该是什么样、AGI 版本是什么样」。Cat 的工作很大一部分是找出从今天到那个愿景的路径，并花大量时间做跨职能协调：让市场、销售、财务、容量等团队都认同计划、朝一个方向划船，确保功能就绪时没有任何东西卡住发布。

两人配合得好是因为「脑子接通」：大约 80% 想法一致，剩下 20% 各有更在意的事，谁更在意谁来推。

“We’re like 80% mind meld, and then there’s like this 20% of things that maybe I care a lot more about than Boris.”

二、多数 PM 搞错的事：没意识到要多快

AI 之前技术变化慢，可以按 6 到 12 个月规划，因为代码贵、要花很多精力和兄弟团队对齐多季度路线图。现在 AI 把工程大大加速、模型能力快速提升，很多功能的周期从 6 个月降到 1 个月、有时 1 周甚至 1 天。

所以 PM 该少花精力在多季度路线图对齐上，多想「怎么用最快的方式把东西送出门」。做得最好的 AI 产品 PM，是那些能缩短「从有想法到交到用户手里」时间的人。

“The timelines for a lot of our product features have gone down from 6 months to 1 month and sometimes to 1 day.”

三、怎么做到一周上线一个功能

第一，定清晰目标。LLM 太通用，反而带来「给谁做、解决什么、核心场景是什么」的模糊。好 PM 能把目标收窄到，比如「核心用户是专业开发者，要让企业里的他们安全地做到零权限弹窗」，这一下就排除了大量方向。

第二，可复制的发布流程。Claude Code 几乎所有功能都以「research preview」形式发布并明确标注，让用户知道这是早期尝试、可能不会永久支持，这降低了发布的承诺成本，一两周就能放出去。第三，PM 搭好框架：工程师觉得功能就绪、内部 dogfood 过后，发到固定的发布频道，文档、PMM、DevRel 第二天就能跟上做发布公告。流程越顺，任何工程师发布东西的摩擦就越低。

“We want to remove every single barrier to shipping things.”

四、角色在融合，但 product taste 不会过时

PM 在做工程、工程师在做 PM、设计师既 PM 也写代码。他们团队的选择是招「有很强产品品味的工程师」，很多人能从看到 Twitter 上的用户反馈，一路到周末把产品发出去，几乎不需要 PM 介入，这是最高效的方式。

为什么 product taste 是关键？因为当写代码越来越便宜，「决定写什么」就越来越值钱：几万个 GitHub issue 里哪个值得做、怎么做才对、什么是最舒服的 UX。工程背景在「近几个月」尤其有用，因为你更清楚一件事该有多难，这帮助排优先级。但她强调技能价值每隔几个月就会变，重点是有第一性原理思考、能看出团队缺口然后补上。

“As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.”

五、在龙卷风里保持冷静

团队招的是「拥抱混乱」的人：面对难题会笑着说「这会很难，但我兴奋」。她说有些周日晚上来个 P0，到周一变 P00、周一下午 P000，回头看会觉得当初那个 P0 根本不算事。

应对方式是承认你能做的有限、睡好觉才能做好决策、残酷地排优先级、并接受放手一些东西。会发布一些不如理想中打磨的产品，但只要不挡住核心场景就行，听到反馈下个版本修。「发布有 bug 的功能」曾让她睡不着，现在能接受了，因为反馈快、下个版本能修。

“You need to sleep well so that you can make good decisions next day, and just brutally prioritize where you spend your time.”

六、Anthropic 凭什么后来居上：使命 + 专注

两件最重要的事。一是统一的使命：招的是最在意「把安全的 AGI 带给全人类」的人，这个使命被放在任何单一产品线之上，所以能做出跨整个组织的快速决策并统一执行。当两个优先级冲突时，就看哪个更服务 Anthropic 的使命，大家都会站在选出的那个背后。

二是专注：团队愿意为 Anthropic 的整体目标牺牲自己团队的 KR。一个极端的说法是，如果 Claude Code 失败但 Anthropic 成功，她会非常开心。这种取舍解释了为什么 Anthropic 不去做社交网络、信息流这类不契合使命的事，从而保持了专注。

“If Claude Code failed, but Anthropic succeeded, I would be extremely happy.”

七、四个产品，什么时候用哪个

Claude Code（终端 CLI）：跑一次性编码任务、想要最新功能时用，新功能往往最先落在 CLI，最强大。Claude Code on desktop：做前端时很棒，可以开预览面板边聊边看 web app 实时变化；对不熟终端的人更友好，还能一眼看到 CLI、桌面、web、移动端所有会话，是一个统一控制台。

web / 移动端：适合在路上随手发起任务，不用带着笔记本到处跑。Co-work：适合产出「不是代码」的工作，比如清空 Slack/收件箱、做客户演示的幻灯片、写功能目标或发布计划文档。她的分法很简单：产出是代码就用 Claude Code，不是代码就用 Co-work。

“If I’m building something where the output is code, I’ll use Claude Code. And if the output is anything that’s not code, I’ll use Co-work.”

八、新一代 PM 的技能：恰到好处地「AGI 上头」

最难的技能是定义「一个月后产品该长什么样」。她说最微妙的是要「恰到好处地 AGI 上头」：为那个无所不能的超强模型设计产品很容易，无非一个文本框；难的是针对当下的模型，怎么把它的最大能力激发出来、把用户引到「黄金路径」上、用产品补上模型的弱点。

怎么练？花大量时间和模型对话，尤其是让模型「自省」为什么做了某个意外动作，往往能看出是什么误导了它，从而修 harness。再就是找到少数几个你最信任、最会表达「什么样的模型好」的人拿快速反馈。还有写 eval：不用几百个，10 个好 eval 就能帮团队量化目标和差距，这是被低估、更多 PM 和工程师该做的事。

“The hard thing is figuring out for the current model, how do you elicit the maximum capability?”

九、模型会吃掉你的 harness，以及给所有人的建议

每出一个更聪明的模型，他们就删掉一批「拐杖」功能。经典例子是 to-do list：早期 Claude Code 做大重构会改 5 个就停，于是加了 to-do 工具逼它做完 20 个；到了 Opus 4 之后的模型，它自然就会用、不用提醒了。每次发新模型，他们会通读整个 system prompt，把不再需要的提醒删掉。更兴奋的是新模型解锁全新功能，比如代码审查，只有最新模型好到能让工程团队「合并前依赖它过审」。所以要敢于做「现在还不太行」的产品，等新模型一换就能补上那道缺口。

给所有人的建议：把你重复做的手工活交给 AI 自动化，把自动化打磨到 100% 可靠（95% 的自动化不算自动化），并且去构建你每天真在用的应用，只有真用起来才拿得到杠杆。她也提醒别走另一个极端：有人沉迷于堆 skill、MCP、各种定制，反而忘了原本要做的核心事，「简单的配置往往更好用」。她最爱的人生信条很对味：Just do things。