Kat Wu × Lenny 播客访谈：AI 时代的 PM 与产品构建

我认为，在超强 AI 模型时代做产品真的非常困难。对于超强模型来说，构建产品很容易。困难的是弄清楚——对于当前的模型，如何发挥其最大能力？

我从未见过像 Anthropic 团队这样飞速迭代的速度。你们专注于快速发布产品。我们希望能消除发布产品的每一个障碍。很多产品功能的时间线已经从 6 个月缩短到 1 个月，有时候甚至缩短到 1 天。

今天我们请到了

，她是 Anthropic Cloud Code 产品的负责人。Kat 处于 AI 和产品领域一切变化的核心。她和她的团队正在构建的产品，正在深刻改变我们所有人构建产品的方式。她充满了洞见、智慧和经验教训，这是一期你绝对不能错过的节目。

Kat Wu 创建了 Cloud Code，她领导工程团队，每天为数百万用户发布大量 PR。人们没有给予你们在 Cloud Code 成功方面足够的认可。能帮我们了解一下你在团队中的角色吗？你和 Boris 是怎么合作的？责任是怎么划分的？

我很幸运能和 Boris 合作，他是一个非常棒的思维伙伴。他是我们的技术负责人，也是非常出色的产品愿景规划者。他很擅长设定这样的方向：“这就是产品 3 个月、6 个月后应该成为的样子。“这就是产品愿景驱动的版本。

我的角色更多是弄清楚——从我们今天所在的位置，到 3 到 6 个月后的愿景，这中间的路径是什么。我花更多时间在跨职能协作上：确保营销团队、销售团队、财务、算力团队等都认同这个计划，我们所有人朝着同一个方向努力。一旦功能准备好了，确保没有任何发布障碍。

我们大概有 80% 的事情是心有灵犀的，然后有 20% 的事情可能我更在意，我会主导那些；反过来也有 20% 是他更在意的，他就主导那些。

你一直在面试大量的 PM。Anthropic 是人们最想去工作的地方。你说你看到人们在面试时做错了——他们接近 PM 角色的方式是错的，他们认为要成为成功的 AI PM 需要什么。跟我们聊聊你看到了什么？

在 AI 技术转变之前，很多事情的节奏都比较慢。所以你可以规划 6 到 12 个月的时间范围。因为发布功能的速度比较慢，写代码是非常昂贵的。

现在有了 AI，它大大加速了工程速度，模型能力也在快速提升。我们很多产品功能的时间线已经从 6 个月缩短到 1 个月，有时候甚至到 1 周或 1 天。

这就意味着作为 PM，要少花精力在确保多季度路线图与合作伙伴团队对齐，而是更多关注：

让工程师或 PM 有想法，到周末就能把它交到用户手中。

在 AI 原生产品上做得最好的 PM，是那些能弄清楚如何缩短”有这个想法”到”把产品交到用户手中”时间的人，以及能帮助定义”哪些最重要的任务需要开箱即用”的人。

人们还没有意识到他们需要移动多快。什么能帮助你做到这一点？你的 PM 团队做了什么来帮助他们快速前进？

第一，设定清晰的目标。

因为如果目标太笼统，实际上会造成很多歧义——你在为谁构建？在解决什么问题？主要用例是什么？一个优秀的 PM 能够说清楚：我们的关键用户是专业开发者，我们想解决的问题是权限提示太频繁，用例是让企业开发者安全实现零权限提示。这排除了很多潜在方案，设定了清晰方向。

第二，想出可重复的发布流程。

我们几乎所有功能都是通过”研究预览”（Research Preview）模式发布的。清楚地标注”这是一个早期产品，可能不会永久支持”。这样做的好处是降低了发布承诺，我们可以在 1 到 2 周内推出东西。

第三，帮助团队创建跨职能协作框架。

当工程师觉得某个功能准备好了，而且已经内部 dogfood 过了，他们就会发到常设的发布室。然后文档、PMM 团队立即加入，在第二天就能完成营销公告。PM 就是应该负责搭建这个的人。

PRD 现在就是几个要点吗？PM 世界是怎么演变的？

我们做两件事。第一，我们有非常严格的指标，每周和整个团队一起做指标复盘——关键目标是什么，趋势如何，什么驱动了这些指标。目的让每个人都深入理解业务。

第二，我们有团队原则清单——谁是关键用户？为什么他们是关键用户？阐明这些让每个人都能自己做决定，而不觉得被 PM 或任何其他利益相关者卡住。

对于特别模糊的功能，我们仍然会写一页纸的 PRD——目标、用例、失败模式。有一些需要重型基础设施的项目，确实需要几个月的时间，我们仍然会写完整的 PRD。

我从未见过像 Anthropic 团队这样飞速迭代的速度。有人做了一个你们整个发布会的日历，基本上每天都有一个重大功能。你们刚刚推出了 Mythic 模型，是不是一直在用这个作为能移动这么快的原因之一？

我们已经快速移动好几个季度了，不完全是 Mythos 的功劳。Mythos 是一个强大的模型，我们确实在内部使用，这稍微提高了发布速度，但不是大部分增长的原因。

很大一部分是流程和对团队的期望。

我们想消除发布东西的每一个障碍。我们要确保团队中每一个人都感到被授权——能够把想法从一个想法到推向世界，有时候不到一周，有时候甚至一天。

大约一周前，Cloud Code 的整个源代码泄露了。有什么可以评论的吗？发生了什么？

当我们看到时立即展开了调查。这是人为错误的结果——有一个人和 Cloud Code 合作写了一个 PR，这只是一个关于如何发布包的更新，它经过了两层人工审查。我们已经加强了流程，确保不会再次发生。这个人还在这里工作，他没事的。这是一次流程失败，最重要的是从中学习，添加更多保障措施。

最近有一些举措阻止人们把 Cloud 订阅用于 OpenAI 的产品。人们对此感到非常困惑和不满。人们怎么理解这个决定？

我们看到了对 Cloud 的巨大需求。我们一直在非常努力地扩展基础设施。Cloud 不是为第三方产品设计的，第三方产品的使用模式可能不同。我们花了大量时间想办法提供最无缝的过渡。每个人在订阅的同时都获得了一些积分。但我们确实必须做出艰难的决定——需要优先考虑我们的第一产品和 API。

我们现在大概有 30 或 40 个 PM，有若干个团队：

•

（Diane 领导）：理解来自模型客户的反馈，推动模型发布

•

：维护 Cloud Code 的 API，发布 Managed Agents 等

•

：同时负责 Cloud Code 和 Claude Code 产品

•

：帮助大企业采用，包括成本控制、安全控制

•

：负责全产品套件的增长

Miles 的观点是，因为工程师移动得这么快，PM 和设计师被压缩了，需要更多的 PM 因为很难跟上。你的观点是什么？

所有的角色都在演变。PM 做一些工程工作，工程师做 PM 的工作，设计师做 PM 也写代码。你要么雇用更多有很好产品感的工程师，要么继续按照传统方式经营，雇用更多 PM。

但我觉得随着工程速度越来越快，你实际上需要更多产品策略。你需要有人真正思考什么是正确的长期方向，什么是最重要的用例。

你经常自己使用 Cloud Code——不只是工作，还用于个人项目。这怎么帮助你的？

我每天都在用 Cloud Code 和 Claude Code。当你亲自使用产品时，你能感受到很多细微的东西——什么感觉自然，什么感觉别扭，什么会让人卡住。这些细节数据无法完全捕捉。我的个人项目帮助我理解普通用户可能遇到的问题，这些问题在我专注工作流程时可能不会出现。

“HCI” 是人机交互（Human-Computer Interaction）的缩写。当我们说”HCI-pilled”时，意思是产品应该非常注重用户体验——不仅仅是功能是否工作，而是人们使用它的感觉是否自然、是否愉快。

Cloud Code 面对的是非常复杂的任务，所以我们需要让界面尽可能直观。我们花很多时间思考人们如何与 AI 协作、反馈循环是什么样的、人们如何知道 agent 在做什么、错误时如何纠正。这些都是 HCI 问题，而不仅仅是工程问题。

我们主要用三种方法。一是内部 dogfooding——团队每天都在使用新模型。二是看数据——我们有一套非常详细的指标，每个功能都有，看新旧模型上的表现差异。三是 A/B 测试——把新模型放出去给一小部分用户，看反馈和指标。

我们在 Twitter 上非常活跃，有一个专门的团队监控所有社交渠道。我们有一个”用户爱（User Love）“频道——每当有人分享成功故事就发到那里。还有一个反馈频道，每当有人分享产品问题就放在那里。

我们最看重的是

。如果我们能重现一个问题，就能成为下一代模型和改进方向。所以我一直呼吁大家在 Twitter 上不要害羞，分享遇到的问题。

有两个人我认为非常出色。一个是 Amanda——她负责塑造 Cloud 的性格，这是一个非常难的角色。塑造性格需要对这个角色应该成为什么样有非常强烈的信念。她不仅能塑造性格，还能清楚地阐述目标和成功的标准。

另一群我非常信任的人是 Cloud Code 团队。我们经常在团队午餐时测试新模型，挨个问每个人”这个模型给你的感觉怎么样？“通常我们会得到这样的反馈：“这个模型没有完全解释它的思考，太突然了”或”这个模型很喜欢写 memories，但我们不确定质量是否高”。

co-founder 说过，Claude 的性格和宪法是它如此重要的原因之一。个性是让 Claude 如此多才多艺的核心。为什么性格如此关键？

当人们想到 Claude 和 Cloud Code 时，这是提到最多的事情之一——他们真的很喜欢 Claude 轻松有趣，但它也极其胜任你的任务。

人们真的很喜欢 Claude 的

。如果你告诉它”你做错了这件事”，它会真心道歉：“哎呀，感谢你告诉我，让我来修复，我们一起工作吧。”

它也非常积极。如果你说”这是一件大任务，我不知道从哪里开始”，Claude 会说：“好的没关系。这些是我觉得我们应该采取的步骤，你想让我帮你开始吗？”

一个伟大同事的特质——积极性、偏向行动的能力、给你真诚反馈而不是只是同意你说的每一件事——我们尝试把这些都灌输到 Claude 中，因为我们认为这让它更令人愉快。

当新模型出来时，你们经常需要回过头来看构建的东西。聊聊你们多久需要重新做一次产品？

我们用新模型做的很多变化是

。很多时候我们添加功能是因为模型做不到，是权宜之计。

最经典的例子是待办事项列表。当我们第一次发布 Code 时，模型会要求做大型重构，说要改 20 个调用点，然后改了 5 个就停了。Seth 想出一个办法——人类做这件事会做一个清单，列出需要改变的所有地方，逐一替换。所以我们给了它这个工具，发现有了待办事项后，Claude Code 能修复所有 20 个调用点。

但随着 Opus 4 和更新的模型，我们意识到不需要强迫它使用待办事项了——它会自然地使用。现在待办事项对用户来说仍然是好的（更清楚地看到 Claude 在做什么），但已经不是产品的核心部分了。

最令人兴奋的是

。我们用之前的模型测试过很多功能但准确率不够。比如代码审查——我们过去推出过 slash code review 命令，但只有用最新模型，我们才觉得代码审查真的很好。现在我们的工程团队依赖这个来通过 PR 合并。只有用 Opus 4.5 和 Sonnet 4.6，我们才能同时运行多个代码审查 agent，遍历整个新代码库。

很重要的一点是构建那些目前还不能工作的产品

，这样你就知道是什么阻碍了这个产品。当最新的模型出来时，就可以把它插入到原型中，看看新模型是否填补了空白。

Cloud Code 和 Claude Code 的发展方向是什么？长期愿景是什么？

我们用”积木”来思考。核心积木是

——你给了一个清晰的提示描述，它能始终如一地产出你能接受的输出。然后我们看到了

——一个任务工作了，现在你可以一次做 6 个任务。

我们推测下一步可能是你一次运行 50 个或数百个调用。到那时候，你可能不再在本地运行所有东西了。我们在思考：如何让你更容易管理这些远程运行的东西？如何构建界面，让你知道哪些任务需要关注？如何确保 agent 完全被验证？如何让你的反馈长期锁定到未来每次运行中？

很多 PM、创始人、跨职能人员对他们的角色和职业的未来有担忧。你有什么建议——不只是生存，而是真正茁壮成长？

AI 给每个人的杠杆比他们以前拥有的多得多。每当你意识到自己在多次做某个手动任务时，想想怎么用 Cloud Code、Claude Code 来自动化那个。

大多数人的工作有他们绝对喜欢的创意部分，然后有他们真的讨厌做的繁琐部分。AI 的美在于它能做那些繁琐的部分。它可以从你每次做那个手动任务中学习，然后归纳，自动运行——这样你就可以专注于创意部分。

所以我的推动是：找出你可以传递给 Claude 的重复性工作，在自动化上投入时间直到成功率非常高。然后专注于”我还能为我的团队、我的产品、我的公司做什么？”

把自动化从”这是一个很酷的概念”带到”这实际上 100% 时间都能工作”。

有时候我看到用户尝试自动化某事，达到 90% 或 95% 的准确率就放弃了。如果一个自动化不是 100% 时间都能工作，它就不是真正的自动化。

投入那额外的努力来教 Claude 你的偏好，给它反馈，让它能达到那个 100%。然后你就能真正依赖它了。

搭建你每天都在使用的 app。

如果你搭建了一个原型 app，它没有帮助你完成更多事情，那 AI 就没有真正为你的每一天增加价值。只有通过那样的使用，你才能真正获得价值。

我也觉得有很多人花太多时间定制工具——skill、MCP，这些”黑魔法”。有时候这可能分散你对核心目标的注意力。定制确实有趣，但简单的 setup 实际上效果更好。

大转变是：

人们真正的大”aha”时刻是——Claude 可以代表你做事。agent 可以自己就去做——这是一种奇妙的感觉。

《Asia’s Rise in the Global Economy》——关于什么样的政策和政府能带来持久成功的经济。

《Technology’s Flight》——关于过去几次技术革命如何影响了工人，我们可以从历史中学到很多。

《Paper Menagerie》——一本短篇小说集，关于成长和 AI 以及自我发现。

Drive to Survive——看到人们对某个工程目标如此痴迷、追求的纯粹性，非常令人满足。

《Free Solo》——关于 Alex Honnold 无保护攀登 El Capitan。我实际上是一个攀岩者，第一次看是在开始攀岩之前。这是我少数几部越了解越被震撼的电影。

Waymo。我是一个狂热的用户，每天用它两次上下班。它没有催我的压力，而且在车里我可以打电话参加工作会议，不担心有人偷听。这让我每天找回了 30 分钟。

“Just do things”（尽管去做）。

第一性原理思维很有价值。如果你知道你在优化什么，有强力的第一性原理，你通常能推断出正确的行动方案。职位是假的。如果你理解约束，你可以弄清楚你能做什么——然后试着去做，快速从错误中学习。你可以”尽管去做”——不管是谁说需要许可。

“Manifesting”（显化）。

这也是我最喜欢的贴纸，明显是冠军。

AGI 要在社会中广泛普及还需要很长时间。immediate 的事情是帮助这个世界跟上步伐。不严肃的答案——之后我可能会做很多攀岩，搬到 boulder 附近。也有很多想读的书，目标是每周读一到两本。即使知道 AGI 已经知道了所有这些，有很多有趣的话题我很兴奋去学习。

Twitter:

或

。随便 tag 我，随便 DM 我，我会全部读。

最有帮助的事情是告诉我们

。我们茁壮成长的是边缘案例和错误——具体可重现的任务。因为如果你能与我们分享，我们能够重现——这是积极改进下一代模型和 harness 的东西。