返回全部播客
Lenny's Podcast 85 min · · 72,537 次播放

How Anthropic's product team moves faster than anyone else

主持:Lenny Rachitsky
嘉宾:Cat Wu (Head of Product, Claude Code & Cowork, Anthropic)
shipping velocityproduct tastemission alignmentResearch PreviewAGI calibrationmodel introspectionevalsClaude character
原始播客链接

⚡ 速览

Anthropic Claude Code 和 Cowork 产品负责人 Cat Wu 揭示了团队如何以前所未有的速度发布功能——时间线从六个月压缩到几天。

她解释了为什么在代码日益廉价化的今天,产品品味(product taste)成为最稀缺的能力,Anthropic 的使命认同如何消除组织内耗,以及基于当前模型能力而非假设性 AGI 来构建产品的务实哲学。

核心主题包括:用 Research Preview 加速发布、让模型反思自身错误、将 Claude 的性格视为核心产品特性,以及把自动化推到 100% 而非止步于 95%。

英文原文

Cat Wu, Head of Product for Claude Code and Cowork at Anthropic, reveals how the team ships features at an unprecedented pace — timelines collapsed from six months to days. She explains why product taste is now the most valuable skill as code becomes commoditized, how Anthropic's mission alignment eliminates organizational friction, and the practical philosophy of building for current model capabilities rather than hypothetical AGI. Key themes include using Research Preview to ship fast, asking models to introspect on their own mistakes, treating Claude's personality as a core product feature, and pushing automations to 100% rather than settling for 95%.

🗺 章节地图

💡 核心亮点

发布速度:从数月到数天

快不靠拼命,靠降低承诺:Research Preview 把发布变成可撤销的实验,而不是许诺。

Anthropic 的功能开发周期从 6 个月压缩到 1 个月,有时甚至只需 1 天。这套体系依赖三个要素:极简流程、Research Preview 品牌标签降低承诺压力,以及工程、市场和文档团队之间紧密的跨职能协作闭环。

EN original

Shipping velocity: from months to days

Anthropic's feature timelines collapsed from 6 months to 1 month, sometimes 1 day. The system relies on low process, Research Preview branding for reduced commitment, and tight cross-functional loops between engineering, marketing, and docs.

产品品味比工程技能更重要

代码越廉价,瓶颈越从做出来移向选什么做——决定写什么才是新的稀缺技能。

当代码的编写成本越来越低,真正稀缺且有价值的技能是「决定写什么」。Anthropic 优先招聘具有出色产品品味的工程师,这样 PM 就不会成为发布流程中的瓶颈。

EN original

Product taste over engineering skill

As code becomes cheaper to write, the scarce and valuable skill is deciding what to write. Anthropic prioritizes hiring engineers with great product taste so PMs aren't bottlenecks in the shipping process.

使命作为终极决策过滤器

把使命置于任何产品线之上,取舍的次序就提前排定——团队才敢快速拍板。

Anthropic 的统一使命——为全人类实现安全的 AGI——让团队能够快速做出跨部门决策,并甘愿牺牲个别产品目标。Cat 说:「如果 Claude Code 失败了,但 Anthropic 成功了,我会非常高兴。」

EN original

Mission as the ultimate decision filter

Anthropic's unifying mission — safe AGI for all humanity — lets teams make fast cross-org decisions and willingly sacrifice individual product goals. Cat: 'If Claude Code failed but Anthropic succeeded, I would be extremely happy.'

对 AGI 保持恰如其分的信念

为假想的超强模型做产品人人都会;从当前模型榨出最大能力,才是稀缺功夫。

PM 最难掌握的技能,是在未来 AGI 潜力与当前模型能力之间找到正确校准。为一个假设中的超级智能做产品很容易;真正的挑战是从今天的模型中榨取最大价值,引导用户走上最佳路径。

EN original

Be the right amount of AGI-pilled

The hardest PM skill is calibrating between future AGI potential and current model capability. It's easy to build for a hypothetical superintelligence; it's hard to extract maximum value from today's models and guide users onto the golden path.

模型会吃掉你的产品外壳

为模型短板打的补丁都有保质期——模型每升级一次,路线图就被划掉一行。

随着模型能力提升,Anthropic 会主动移除那些充当拐杖的产品功能。待办列表的加入是因为早期 Claude 会在重构中途停下来;而更新的模型能自然地完成所有任务,让这个功能变成了装饰而非必需品。

EN original

Models eat your harness for breakfast

As models improve, Anthropic actively removes product features that were crutches. The to-do list was added because Claude would stop mid-refactor; newer models naturally complete all tasks, making the feature decorative rather than essential.

100% 自动化阈值

95% 可靠的自动化不是自动化——价值全在最后 5-10%,不啃下来等于没做。

95% 的自动化不算自动化。Cat 敦促大家啃下最后 5-10% 的硬骨头,让工具真正做到可靠——哪怕一开始构建自动化的速度比手动操作还慢。

EN original

The 100% automation threshold

95% automation is not an automation. Cat urges people to push through the last 5-10% to make tools truly reliable, even though building the automation is often slower than doing the task manually at first.

直接动手做

职位是虚的,约束才是实的——看懂约束的人,做事不需要等谁批准。

Cat 的核心信条:如果你理解了约束条件和第一性原理,就放手去做。职位是虚的,角色是流动的,行动偏好永远胜过等待许可。这种哲学是 Anthropic 赋能个人文化的基础。

EN original

Just do things

Cat's core motto: if you understand the constraints and first principles, just act. Jobs are fake, roles are fluid, and bias towards action beats waiting for permission. This philosophy underpins Anthropic's culture of empowered individuals.

🎤 金句

我们很多产品功能的时间线,从六个月压缩到一个月,有时甚至只需要一天。
EN original
The timelines for a lot of our product features have gone down from six months to one month and sometimes to even one day.
Cat Wu
当代码的编写成本大幅降低,真正变得更有价值的是——决定写什么。
EN original
As code becomes much cheaper to write, the thing that becomes more valuable is deciding what to write.
Cat Wu
如果 Claude Code 失败了,但 Anthropic 成功了,我会非常高兴。
EN original
If Claude Code failed, but Anthropic succeeded, I would be extremely happy.
Cat Wu
为超级 AGI 强模型做产品很容易。真正的难题是,对于当前的模型,如何激发出它的最大能力?
EN original
It's very easy to build the product for the super AGI strong model. The hard thing is figuring out, for the current model, how do you elicit the maximum capability?
Cat Wu
很多时候我们给产品加功能,其实是在给模型打补丁,因为模型本身还没有自然地完成这些事。
EN original
A lot of times we add features to the product as a crutch for the model, because it's not naturally doing itself.
Cat Wu
如果一个自动化不能百分之百可靠地运行,那它就算不上真正的自动化。
EN original
If an automation doesn't work a hundred percent of the time, it's not really an automation.
Cat Wu
去构建你每天都在用的应用,因为只有通过日常使用,你才能真正获得价值。
EN original
Build apps that you're actually using every single day, because only through that usage are you actually getting the value.
Cat Wu
直接动手做。职位是假的。如果你理解了约束条件,就能想清楚能做什么,然后尽快去做。
EN original
Just do things. Jobs are fake. If you understand the constraints, you can figure out what you can do and then just try to do it quickly.
Cat Wu

🧭 行动建议

  1. 1
    以 Research Preview 的名义发布 08:58

    将早期功能标记为 Research Preview,降低承诺压力,在 1-2 周内获取真实用户反馈,而不是等几个月追求完美。

    EN original

    Brand early features as Research Preview to lower commitment and get real user feedback within 1-2 weeks instead of waiting months for perfection.

  2. 2
    将所有数据源连接到 Cowork 35:58

    Slack、日历、Gmail、Drive——Cowork 只有在掌握完整上下文的情况下才能产出高质量结果。结果的质量与接入数据的丰富程度成正比。

    EN original

    Slack, Calendar, Gmail, Drive — Cowork can only produce great output with full context. The quality of results scales with the richness of connected data.

  3. 3
    让模型自我反思 51:15

    当模型做出意料之外的行为时,问它为什么做出那个决定。这往往能揭示误导性的提示词或产品外壳中的漏洞,让你可以针对性地修复。

    EN original

    When the model does something unexpected, ask it why it made that decision. It often reveals misleading prompts or gaps in the harness that you can fix.

  4. 4
    构建 10 个优秀的 eval 55:00

    你不需要几百个。只需 10 个精心设计的 eval 就能帮你量化目标、衡量进展,并发现 AI 产品中缺少什么。

    EN original

    You don't need hundreds. Just 10 well-crafted evals help quantify goals, measure progress, and identify what's missing in your AI product.

  5. 5
    每次模型升级都清理产品外壳中的拐杖 60:44

    每次新模型发布时,通读整个系统提示词,移除模型不再需要的指令。更简洁的外壳才是更好的外壳。

    EN original

    With every new model, read through the entire system prompt and remove instructions the model no longer needs. Simpler harnesses are better harnesses.

  6. 6
    把自动化推到 100% 69:18

    不要止步于 95%。花时间教会 AI 你的偏好,持续迭代直到完全可靠。最后那 5-10% 很难,但正是它区分了玩具和工具。

    EN original

    Don't stop at 95%. Invest the time to teach AI your preferences and iterate until it's fully reliable. The last 5-10% is hard but makes the difference between a toy and a tool.

  7. 7
    构建日常使用的应用,而非一次性原型 71:58

    原型应用教不了你太多。构建你每天都在用的工具,才能真正理解 AI 的价值、局限性和它在哪儿会出问题。

    EN original

    Prototype apps teach you little. Build tools you actually use every day to understand AI's real value, limitations, and where it breaks.

📖 全文

约 55 分钟 · 27k 字

01 · 0:00 · Introduction to Cat Wu

0:00我认为要对 AGI 保持恰到好处的信念是非常困难的。为超级 AGI 强模型构建产品其实很简单。难的是搞清楚对于当前的模型,如何激发出最大的能力?我从来没见过像你们 Anthropic 这样的发货速度。我们想消除所有阻碍发货的障碍。我们很多产品功能的开发周期从六个月缩短到了一个月,有时候甚至一天。你在面试几百个 PM然后你一直觉得他们的方法完全不对。PM 的角色正在发生巨大变化。变化非常快。构建 AI 原生产品最关键的一点就是快速迭代,想办法真正做到每周都发布新功能。你觉得 PM 需要培养哪些新兴技能?归根结底还是产品品味。随着写代码变得越来越廉价,更有价值的是决定写什么代码。今天我的嘉宾是 Cat Wu,Anthropic Cloud Code 和 CoWork 的产品负责人。

1:01Cat 处于 AI、产品和构建领域所有变革的核心,她和她的团队正在打造的产品正在改变我们所有人构建产品的方式。她充满了洞察力和智慧与经验。这是一集你不能错过的节目。在我们开始之前,别忘了去 Lenny's Product Pass dot com 看看为 Lenny's newsletter 订阅者独家提供的超值优惠。接下来,有请 Cat Wu。

02 · 1:29 · Working with Boris Cherny

1:31Cat,欢迎来到播客。谢谢邀请我。我有好多问题想问。很高兴你能来参加这个播客。我想先让大家了解一下你和 Boris 的角色分工。大家都认识 Boris。他那期节目是这个播客上最受欢迎的节目。没有压力。他创造了 Cloud Code。他带领团队,发货,每天从手机上提交无数的 PR,我甚至都不知道数字是多少了。我觉得大家没有给你足够的认可,Cloud Code以及 CoWork 和你们正在构建的所有东西取得的成功。帮我们了解一下你在团队中的角色,你是怎么和 Boris 合作的,你们怎么分工的,Cloud Code团队的 PM 角色是什么样的?我觉得很幸运能和 Boris 一起工作。他一直是一个很好的思考伙伴。他是我们的技术负责人。他在很大程度上是产品远见者,他非常擅长设定产品在三个月、六个月后应该是什么样的。

2:33这就是产品在高度 AGI 化之后的样子。我的角色很大程度上是弄清楚,好吧,从我们现在所处的位置到三到六个月后的愿景,路径是什么?我把更多时间花在跨职能协调上。确保我们的市场团队、销售团队、财务产能等等,都认同这个计划,并且我们都在朝同一个方向努力。而且一旦功能准备好了,没有任何障碍可以阻止发货。我觉得在很多方面这种合作效果很好,因为我们基本上心意相通,但这条界限实际上非常模糊。我觉得我们大概 80% 是心有灵犀的。然后有大约 20% 的东西可能我比 Boris 更在意,所以我会去推动那些,还有 20% 是他比我更在意的,他就直接推动那些。本期节目由我们本季的首席赞助商 WorkOS 带来。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家其他成功公司有什么共同点?它们都由 WorkOS 驱动。

3:37如果你在为企业构建产品,你一定感受过那种痛苦——集成单点登录、SCIM、RBAC、审计日志以及其他大公司需要的功能。WorkOS 将这些阻碍交易的功能变成了即插即用的 API,这是一个专为 B2B SaaS 构建的现代开发者平台。我投资的几乎所有初创公司在开始向高端市场扩张时最终都会选择 WorkOS,因为他们是最好的。无论你是一家试图拿下第一个企业客户的种子期初创公司,还是一家在全球扩张的独角兽。WorkOS 是成为企业级就绪和释放增长的最快途径。它本质上就是企业功能版的 Stripe。访问 WorkOS.com 开始使用,或者直接联系他们的 Slack,那里有真正的工程师等着回答你的问题。WorkOS 让你能用令人愉悦的 API、全面的文档和流畅的开发者体验更快地构建产品。

03 · 4:29 · What Anthropic looks for when hiring PMs

4:29前往 WorkOS.com,今天就让你的应用为企业级做好准备。你在录制前分享的一件事是你一直在面试大量的 PM。如果每次有人找我要介绍去Anthropic 做 PM,我就能赚 300 亿美元的 ARR。那简直就是大家最想去工作的地方。所以我都能想象你在面试多少 PM。你告诉我你看到人们做得不对,他们研究成为成功 AI PM 的方式是错误的。说说你看到了什么,以及人们需要理解什么才能在当下取得成功。我认为在 AI 之前,技术变革的速度慢得多。所以你可以在六到十二个月的时间跨度上做规划。而且因为你发布功能的速度相对较慢,所以有更多精力花在与所有合作伙伴团队协调上,确保他们发布的功能能解锁你的功能,因为那个时候代码非常昂贵。我认为现在有了 AI,加上工程效率的大幅提升,以及模型能力提升的速度如此之快,我们很多产品功能的开发周期从六个月缩短到了一个月,有时候甚至缩短到一周甚至一天。这意味着我们实际上必须确保产品能非常快地发布。

5:55这意味着作为 PM,不应该那么强调确保你的多季度路线图与合作伙伴团队对齐,而应该更多强调,好吧,我们怎么找到最快的途径把东西推出去?我们怎么打造一个概念试验田,让工程师有一个想法或者 PM 有一个想法,

04 · 6:18 · How to help your teams move fast

6:18到周末就能交到用户手中。我认为在 AI 原生产品上做得最好的 PM是那些能想出如何缩短从有想法到实际把产品交到用户手中的时间的人,并且能定义哪些是最重要的、需要开箱即用的功能。我喜欢的是你说的,人们还没有意识到他们需要多快地行动,以及现在工作中有多大一部分就是推动行动,就是帮助团队快速前进。什么能帮助做到这一点?你做了什么?你的 PM 团队做了什么来帮助这么快地推进?除了能使用最先进的模型之外?我认为首先是设定清晰的目标,因为 LLM 太通用了,这实际上在我们为谁构建、解决什么问题、核心用例是什么方面造成了很大的模糊性。所以我认为一个优秀的 PM 能说,好吧,我们的核心用户是专业开发者。我们想为这个功能解决的主要问题可能是权限提示太多,人们感到疲劳,而用例是我们希望企业中的专业开发者安全地实现零权限提示。

7:36这实际上设定了一个相当清晰的目标,因为它排除了很多潜在的减少权限提示的方法,让人们可以通过一个提示完成更多事情。然后我认为第二件非常重要的事情是找到某种可重复的流程来发布这些功能。所以对于 Cloud Code,我们几乎以 Research Preview 的形式发布所有功能。我们在发布时会明确标注,这样用户就知道这是一个早期产品,这只是一个想法。这只是我们正在尝试获取反馈并不断迭代的东西,这个功能可能不会永远存在。这样做的好处是降低了我们发布东西的承诺。我们可以在一两周内就推出一些东西。PM 应该做的第三件事是帮助团队建立框架,让他们知道什么时候需要拉入跨职能伙伴。以及这些跨职能伙伴的期望是什么。比如说,我们在工程、市场和文档之间有一个非常紧密的流程。

8:37所以当工程师觉得某个功能已经准备好并且我们已经内部吃自己狗粮了,他们会把它发到我们永久的发布房间里。然后负责文档的 Sarah、负责 PMM 的 Alex 以及 DevRel 的 Tarek 和 Lydia就会跳进来,第二天就能把市场公告发出来。因为我们有这个非常紧密的流程,任何工程师发布东西的摩擦都降低了。

05 · 8:58 · How PRDs and roadmaps have evolved at Anthropic

8:59而 PM 就是应该搭建这个的角色。PRD 在这里面是怎么 fits 的?你说目标是非常重要的部分,就像对齐成功是什么样的,这是为谁的,不是为谁的?你们写 PRD 吗?还是就是几个要点?这个在 PM 的世界里是怎么演变的?所以我们做两件事。一是我们有非常严格的指标,我们每周都会和整个团队一起做指标回顾。这样做的目的是确保每个人都深入理解我们业务的所有方面,我们的核心目标是什么,它们的趋势如何,以及什么在驱动它们。第二件事是我们有一份团队原则清单,包括我们的核心用户是谁,为什么这些是我们的核心用户。我们阐述所有这些是为了让团队中的每个人都觉得自己理解我们的业务是如何运作的。他们理解什么对我们重要,以及我们愿意做什么取舍。这让人们可以自己做决定,而不会觉得被 PM 或任何其他利益相关者阻碍。

9:58我喜欢这里面大部分内容都是,好吧,我们未来仍然需要 PM。而网上有那么多讨论说,我们为什么还需要 PM?我们只需要发布和构建就行了。我们需要工程师。哦,我们实际上还是会写 PRD 的。所以我认为对于那些特别模糊的功能,确实有助于写一页纸来说明目标是什么,令人愉悦的用例是什么,目前需要修复的失败模式是什么。偶尔也会有一些项目,特别是需要大量基础设施的项目。确实需要好几个月。

06 · 10:28 · The Mythos model and Anthropic's shipping velocity

10:28对于这些情况,我们确实还是会写 PRD。我想进一步深入了解一下你们怎么能这么快。我从来没见过 Anthropic 这样的发货速度。有人做了一个 Anthropic 各项发布的日历。几乎每天都有重大的功能或产品发布。所以网上有人问的是你们刚刚——不是发布,而是构建了这个不可思议的模型 Mythos,它目前还在预览阶段,因为它太强大了。人们有点害怕它能做什么。你们有用过这个吗?这是你们能这么快的原因之一吗?我们已经连续好几个季度都在快速推进了。所以我认为这不完全是 Mythos 的功劳。Mythos 是一个非常强大的模型。我们确实在内部使用这些模型。我认为这在一定程度上提高了我们的发布速度,但我不认为这是速度提升的主要原因。我认为很大程度上是流程和团队的期望。

11:27所以我们的流程非常少。我们想消除每一个阻碍发布的东西。我们要确保团队里的每一个人都觉得有权力把自己的想法从只是一个想法变成一周内发布到世界上,有时候甚至是一天内。太酷了。天哪。拥有最好的模型同时又做产品,这是多大的优势啊。太酷了。我们很幸运能和前沿模型一起工作。我的天。多么棒的优势啊,就是构建一个东西然后使用它,

07 · 11:54 · What happened with the Claude Code source code leak

11:55然后加速得更快。太有趣了。有几个其他的我想在这段对话中走一些支线话题。Anthropic 发生了太多事情,我太好奇你的见解了。一个是大约一周前,Cloud Code 的整个源代码泄露了。有人把它弄出去了。我觉得是有人犯了个错误。你有什么可以说的吗?就是发生了什么?出了什么问题?大家应该知道什么?我们看到后立即进行了调查。我们发现这是人为错误导致的。有一个人在用 Cloud 写 PR。这只是对我们发布包方式的一个更新。而且它实际上经过了两个人工审核。所以这是人为错误的结果。我们已经加固了流程,确保以后不会再发生。这个人还在 Anthropic 吗?他还好吗?是的,是的。这是一个流程失误。最重要的是从中学习,并添加更多保障措施,确保不会再发生。

08 · 12:53 · Integrating with OpenClaw

12:53所以这是我们一直在关注的,而且大部分的措施已经实施了。好的,我另一个问题是关于 OpenClaw。最近有这个动向,阻止人们使用 Cloud 订阅来配合他们的 OpenClaw,人们很不满。他们搞不清楚为什么会这样。感觉像是你们在——你知道,对开源社区造成了伤害。大家需要理解这个决定背后的考量是什么?我们看到了对 Cloud 的大量需求,我们一直在非常努力地扩展基础设施,同时让我们的系统更加节省 token,这样你能获得更多的使用量。它不是为第三方产品设计的,第三方产品与我们第一方产品的使用模式不同。我们花了不少时间。试图找出我们能提供的最无缝的过渡方案。所以我非常高兴能宣布每个订阅用户都会获得一些 API 额度。但是是的,我们确实不得不做出艰难的决定,我们需要优先考虑我们的第一方产品和 API。

14:00所以这就是那个决定的结果。是的,对我来说,这太合理了。你们基本上是在以每月 200 美元的价格补贴这些使用量。基本上就是无限使用这个。我觉得大家不理解的是——他们是在赚钱的。我们在努力实现盈利。当计算资源如此紧缺的时候,我们不能就这么送出去。

09 · 14:19 · How the PM team is structured at Anthropic

14:19所以我理解。回到 PM 团队,PM 团队是什么样的?在 Anthropic,有多少 PM?他们是怎么组织的?是的,我们有几个 PM 团队。我想我们目前大概有 30 到 40 个 PM。我们有研究 PM 团队,由 Diane 带领。这个团队负责理解来自我们客户的所有关于模型的反馈,然后把反馈传递给最合适的研究团队去执行。他们还负责管理模型发布。还有 Cloud 开发者平台团队,负责维护那些 API,Cloud Code 就是建立在那些 API 之上的,他们还发布了类似 managedagents 这样的功能,让你可以构建自己的 agent,我们可以代为托管。然后是 Cloud Code 团队,同时负责 Cloud Code 和 CoWork 核心产品。

15:11还有企业级团队,帮助让 Cloud Code和 CoWork 更容易被所有企业客户采用。这包括从成本控制、RBAC、安全控制,一直到确保这些企业对使用我们的工具感到非常放心和舒适。然后我们还有增长团队,负责推动我们整个产品组合的增长。我们和他们密切合作,推动 Cloud Code 和 CoWork 的增长。我知道他们还和其他团队合作推动 CDP 的增长。

10 · 15:42 · How engineer and PM roles are merging

15:43也就是使用 Cloud API 的用户的增长。说到增长,Amol 刚刚上了播客。他有一个很有趣的洞察,大多数人还没分享过。总有一种感觉说我们未来需要更少的 PM。我们为什么需要 PM?工程师直接发布就行了。他的观点是因为工程师推进得如此之快,PM 和设计师被压缩了,没有那么多时间跟上所有正在发生的事情,每天都有新功能发布。所以他的观点是他需要更多的 PM,因为很难跟上节奏。你怎么看?你觉得 PM 的招聘会增加吗?你觉得 PM 这个职业长期来看会怎样?我觉得所有角色都在演变融合。PM 在做一些工程工作,工程师在做 PM 工作,设计师在做 PM 工作,同时也在提交代码。你可以选择雇佣更多具有出色产品品味的工程师,或者保持工程师招聘不变,然后雇佣更多 PM 来帮助指导他们的部分工作。

16:43在我们团队,我们很专注于招聘具有出色产品品味的工程师。这样可以减少发布任何产品的开销。我们团队中有很多工程师完全能够端到端地完成从在 Twitter 上看到用户反馈到周末发布产品,几乎不需要 PM 参与。我认为这实际上是最高效的发货方式。所以我觉得工程师和 PM 的角色在某种程度上是重叠的,增加任何一个都会带来很多好处。我认为产品品味仍然是一种非常稀缺的技能,我们基本上会雇佣任何我们认为强烈展现出这种能力的人。你的背景是工程对吧?是的,我做了很多年工程师。然后我很短暂地做过 VC,然后加入了 Anthropic。实际上,我们团队上几乎所有的 PM 要么曾经是工程师,要么在Cloud Code 上提交过代码,所以这是我认为有助于建立团队信任的一件事,也让我们能够快得多。

17:52然后实际上我们的设计师

11 · 17:54 · Why product taste is the most valuable skill

17:54之前也做过前端工程师。哇,因为这是个大问题。确实有这种融合在发生。维恩图在合并。我觉得很多人关心的大问题是,如果你来自工程或者产品或设计,哪些核心技能会是最有价值的?我在 Anthropic 和 Cloud Code 看到,工程背景非常宝贵。我好奇在其他公司,如果你有设计背景,做 PM 是不是更有价值,或者就是传统的 PM。我还是觉得归根结底是产品品味。随着写代码变得越来越廉价,更有价值的是决定写什么代码。比如,这个功能的正确 UX 是什么?用户体验它的最令人愉悦的方式是什么?我们收到几万条GitHub issue,什么要求都有。这需要大量的心思和品味来判断,好吧,哪些值得构建,正确的构建方式是什么?我认为这个技能集可以来自任何背景,但我觉得这是最重要的东西。我认为工程背景之所以特别有用,至少在未来几个月内,是因为如果你有工程背景,你对某件事应该有多难有更好的感觉。

19:08这通常是决定你选择构建什么的因素。所以如果某件事非常容易构建,那与其争论,不如花一个小时就做了。但如果某件事更难构建,而且你一开始就知道,那你就会知道,好吧,这会花费更多。让我们的团队把这个推出来。所以在优先级排序上有一些帮助。你说在未来几个月内。这是不是因为模型在未来几个月内可能会变得如此之好,你可能都不需要了解那么多工程知识了。我认为有价值的技能组合确实变化很频繁。所以很难预测超过几个月之后的事情。所以这不太是我认为会发生什么变化的评论,更多的是我认为大的变化会发生。所以你不是说那就是 Mythos 出来的时候,会改变一切。然后我们就不需要了解任何工程知识了。不,我只是在说每隔几个月,似乎都会有一次大的编码能力的

12 · 20:10 · Where human brains will continue to be useful

20:10提升,然后其他角色的价值就会随之改变。我认为最重要的是能够拥有这种第一性原理思维,这样你就能弄清楚技术格局是如何变化的,团队真正需要你做什么,然后跳进去填补那个缺口,因为我认为工作变得越来越模糊,这意味着一个优秀的 PM 能够理解所有的差距,找出哪些是最高优先级的,然后想办法,好吧,我怎么学习那个技能,或者我已有的什么技能可以应用到这个挑战上?所以我认为当前环境重视那些能戴很多帽子的人,能随时切换帽子,而且对自己做什么工作来帮助团队加速非常低姿态。我喜欢这个回答。有一个问题我一直在问像你这样处于前沿的人,那些在用最新工具构建的人,就是在达到超级智能之前,人类的大脑在哪里会继续有用和必要?我听到的是本质上就是选择要做什么,知道市场的走向,弄清楚优先做什么。

21:37然后就是知道你构建的东西是不是好的、对的,并以某种早期版本发布出去。这听起来对吗?还有什么人类大脑至少在未来几个月内会继续有用的地方吗?我认为人类仍然提供了一种模型所不具备的常识水平。而且任何产品发布都有上千个移动的部件。有些非常小,但总是有很多可能出错的地方。我认为模型不一定对所有利益相关者是谁、他们之间怎么关联、他们的偏好是什么、什么是与他们沟通、让他们保持配合的正确渠道有很好的理解。我认为很多这种更加隐性的、常识性的、偏情商类的知识仍然非常有价值。

13 · 22:23 · How to stay sane in constant chaos

22:24当然,我们希望模型在这些方面变得更好,我认为它们会的。但目前,我认为仍然存在差距。作为一个人,你怎么应对如此多的持续变化,就像在龙卷风的中心——也许里面是平静的,但就是你怎么跟上正在发生的一切,你怎么在这种疯狂中保持理智?我认为我们团队充满了拥抱混乱的人。所以我们试着笑着面对每一个挑战,因为总是有这么多事情在发生,总是有这么多风险和棘手的情况。如果你对任何事情太紧张的话,你会崩溃的。所以我们真的在寻找那些能看着一个挑战说,哦,这会很难,但我很兴奋能去应对,而且我会尽我所能做到最好。我知道我不会完美的,但我晚上能睡得着觉,因为我知道我尽了最大努力。这是一个有趣的关于未来需要什么技能的回答,因为——我忘了谁说的,可能是 Ben Mann,说这是世界有史以来最正常的时候了。

23:24是的,肯定会变得更难。就是,我感觉有很多个星期,也许周日晚上有什么P0 的事情,然后到了周一就变成了 P00,到了周一下午就变成了 P000。你就会想,哇,我真不敢相信我周日还在为那个 P0 担心。但我觉得你只需要承认你能做的只有那么多,你需要好好睡觉,这样第二天才能做出好的决定,然后就是无情地优先排序你的时间花在哪里,什么是最重要的事情要做对,并且接受放手一些东西。就是,有些产品我们发布的时候没有我希望的那么完善。但是。你知道,我们的首要目标是帮助赋能专业开发者。如果一个产品不成功,只要它不阻碍核心用例,

14 · 24:16 · What gets sacrificed when you ship so fast

24:17那就没关系,因为我们会听到反馈,然后在下一个版本中修复它。发布一个有 bug 的功能,这种事情以前会让我彻夜难眠。但这现在是我能够接受的事情,因为我知道,好吧,我们会得到快速的反馈,然后在下一个版本中修复它。我脑海中浮现出那个 gif 图。我觉得可能是《加勒比海盗》里的那个在一艘船的楼梯上走下来的人,整艘船都在他周围被摧毁,但他却非常淡定地走下楼梯,一切都在他周围崩塌。这很有趣,因为我遇到的每一个 Anthropic 的人都特别淡定而且特别乐观。是的。我觉得这是一个很有趣的洞察,就是拥有这种平静和乐观,而不是——我的天啊,一切都疯了。是的,我觉得如果你没有这种心态,你会很快崩溃的。我觉得我们招聘的也往往是那些在行业里待了很长时间、经历过很多起起落落的人,他们对什么给自己能量有很好的感觉,知道怎么长期维持自己的能量,我觉得这对我们帮助很大。

25:21太有趣了。有一个我想问的事情是,这些角色在模糊化,工程师变成了 PM,每个人又当爹又当妈,每个人都变成了所有人。我们会在这个世界中失去什么?我们会失去职业阶梯和清晰的职业路径吗?我们会失去设计一致性、代码质量吗?可能有一些缺点。你觉得哪些事情是好吧,那是我们为了更大的利益而牺牲的东西?我们在牺牲产品一致性。过去,当写代码很昂贵的时候,你会仔细规划好你的产品要用的所有东西、产品组合、每个产品之间如何关联、每个产品的用例是什么、它们怎么集成。你基本上每个用例只有一个产品。现在随着 AI 推进得如此之快,加上我们需要测试的想法如此之多,我们确实有时候会有功能互相重叠。很多时候是因为我们内部有两种形式都很喜欢,我们想让外部用户告诉我们哪个更好。

26:24这对新用户来说意味着,新用户可能不知道,好吧,完成某件事的最佳路径是什么?我们需要做更多的教育工作,帮助人们理解核心功能是什么,以及使用它们的最佳实践是什么。我认为这就是发布大量功能的代价。我觉得用户也觉得很难跟上最新动态。通常在传统 PM 中,你每月或每季度发布一个功能,所以用户很容易理解,好吧,我只需要每月来看一次,就能学到一些新东西。如果我忽略六个月,也没关系。不会觉得自己错过了什么。我觉得对于这些智能体工具,不仅仅是 Cloud Code 和 CoWork,而是整个生态系统,人们觉得需要每天刷 Twitter 来看绝对最新的东西是什么。我觉得我们还能做更多来帮助人们减少这种越来越快的跑步机上的感觉,我希望人们能感觉到他们可以直接打开这些工具,工具会教育他们,

15 · 27:47 · The /powerup command

27:47或者教他们想知道的东西,他们能感觉到被带着一起走。是的,我看到你们前几天发布了一个很有趣的功能。我觉得是 slashpower up,它基本上带你了解所有很酷的用法,基本上就是使用 Cloud Code 的所有最佳实践,是这个方向的东西吗?是的,没错。过去,我们其实不想做像 power up 这样的功能,因为我们觉得产品应该足够直观,你实际上不需要任何教程。随着时间的推移,我们意识到有太多功能了,而且对内置引导体验的需求如此之大,所以我们就偏离了之前说不做引导流程的理念。我这样做是因为有太多用户想知道,有 100 个功能,哪 10 个是我必须用的?

16 · 28:32 · Why Anthropic has been so successful

28:32所以我们就把这个整合出来了。是的,这是一个很奇异的世界。Anthropic 在 B2B 企业市场非常成功,而传统上你不会发布一堆东西,你基本上是每季度发布一次,也许吧,而这恰恰相反,每天我们都有新东西。所以顺着这个思路,Anthropic 的这波表现简直就是超凡脱俗的。Anthropic 曾经远远落后。刚开始的时候根本微不足道。就是那种最不受资金青睐的公司之一,没有分发渠道。它是第一个开放的吗?远远领先。就是觉得不可能。Anthropic 长期来看有任何机会进行有力竞争。现在它就是大杀特杀,击败了最大的公司和团队。增长简直了,一个月就 110 亿美元的 ARR。利润和增长。等到这期节目出来的时候,可能还会更高。我觉得从内部来看,哪些因素让Anthropic 能够如此成功,从落后追赶到做到这么好?

29:33最重要的两件事,一是这个统一的使命。很难说这有多重要。我们雇佣最关心为全人类带来安全 AGI 的人。而且这实际上是我们在决策中经常参考的东西,And because we put this mission above any individual product line, we're able to快速做出贯穿整个组织的决策,然后统一执行。所以我觉得这在同等规模的公司里是从未见过的。所以为了确保这一点清楚明白。基本上,把第一使命定为安全、对齐、确保 AI 对世界有益。你是说仅仅把它作为一个清晰的使命就能让决策变得容易得多。如果有两个互相竞争的优先事项,我们会讨论哪个对 Anthropic 的使命更重要。这样就更容易决定我们优先做哪个。然后所有人都会支持我们做出的决定。所以有时候这意味着,比如说,我们想在 Claude Code 上发布某个功能,但另一件事更重要。所以我们就降低这个功能的优先级,等到以后再说。真正有趣的是这解释了,我认为,相比于另一家可能跟 Bopen AI 押韵的公司,做了很多不同的事情。我觉得这是非常有趣的一点。而且我认为这是一个非常有趣的我在这里听到的基本上就是,好吧,我们不会去做社交网络。我们不会去做什么有趣的信息流,因为这不符合我们的

31:04使命。这让 Anthropic 保持了专注,而这似乎是成功的核心要素。说到使命,我觉得就是把 Anthropic 的目标放在任何单个团队或单个产品之上。所以对我来说,我觉得我们要谈的第二件事是使命。对我来说,使命的含义稍有不同。使命意味着各个团队愿意做出牺牲,哪怕损害自己的目标和 KR,也要服务于 Anthropic 的目标和 KR。而且大家非常乐意做这些权衡。比如说,一个极端的例子是,如果 Claude Code 失败了,但 Anthropic 成功了,我会非常开心。整个团队都非常愿意做出这样的决定,遵循这样的思路。我不知道你是否能深入谈谈这个但你觉得 Open Cloud 的决定是不是也是这个原因?就是觉得,这没有推进 Anthropic 的使命。我们需要停下来,因为它的效果没有达到我们的期望。我认为对 Anthropic 来说最重要的事情之一就是扩大我们能触达的用户数量。实现这一目标的方式之一就是通过我们第一方产品的 Claude 订阅。所以我们非常希望有时候以第三方产品为代价。所以我们一直在聊 Claude

17 · 32:28 · When to use Claude Code vs. Desktop vs. Cowork

32:30Cowork 这些东西,我想确保大家能理解。我也很好奇你是怎么用这些工具的。有 Claude Code,有 Claude 桌面版/网页版,还有 Cowork。最好的理解方式是什么?什么时候该用哪个?你分别什么时候用这三个?所以我通常会在终端里使用 Claude Code,当我只是启动一个一次性编码任务,而且想要所有最新功能的时候。CLI 是我们最初的产品界面,也是功能通常最先落地的地方。所以它是所有工具中最强大的。这就是我通常用的,当我只是想启动一两个或者几个任务的时候。我觉得桌面版在做前端工作的时候特别出色。我特别喜欢用的一个功能就是预览。如果我在做一个网页应用,我通常会使用桌面版的 Claude Code。我会把预览面板打开在右边,这样我就能实时看到我正在和 Claude 聊天的同时,正在构建的网页应用。它也非常适合那些想要更图形化界面的人。终端对非技术人员来说可能感觉很陌生。

33:40你的电脑上会出现一堆看起来很吓人的弹窗,而且你没法像在其他几乎所有产品里那样随意点击。所以有很多人就是在终端里感觉不舒服。如果你也是这样,我强烈建议试试桌面版的 Claude Code。桌面版也非常适合快速一览所有正在进行的任务。你可以在桌面版里看到你的 CLI 终端会话。你可以看到你的其他桌面会话。你可以看到你在网页版和移动端启动的会话。所以它是一个一站式的控制台,你可以看到所有任务。我觉得网页版和移动端的好处是它非常适合在外面随时启动任务。CLI 和桌面版都需要你在本地笔记本电脑上操作。这就有局限,因为有时候你在外面比如说出去走走、散个步什么的,没带着笔记本电脑。我数不清见过多少人,在外面的时候笔记本电脑开着,手机热点连着。这就说明我们缺少一个满足这个需求的产品。所以对我来说,移动端能让你在外面也能启动这些任务,这样你就不需要到处带着笔记本电脑还得确保随时随地都开着笔记本电脑。

34:56太有意思了。我见过有人在飞机上,这现在都成了一个梗了,就是"我需要等它完成,让这个 agent 跑完。我不能关掉它。"确实如此。然后我觉得 Cowork 填补的角色是每个人都有很多工作,产出不是代码。比如说把 Slack 消息处理完,或者把收件箱清空,或者做一叠为即将到来的客户会议准备演示文稿,或者写一个简短的文档来说明某个功能的目标是什么,或者某个功能的上线计划,所有这些任务的产出都不是代码,而 Cowork 最适合做这些。所以我对这些产品的划分方式是如果我构建的东西产出是代码,我就用 Claude Code 或桌面版,或者移动端的 Claude Code。如果产出不是代码,我就用 Cowork。大家真的低估了 Cowork 取得的成功。它的增长速度惊人。我觉得大家可能还是不太了解它是做什么的。所以你能不能给我们举几个

18 · 35:58 · Tips for getting started with Cowork

36:00你作为 PM 工作中的用例,有哪些非常有趣、可能出人意料的使用 Cowork 来节省时间、完成更多工作的方式?如果你刚开始使用 Cowork,第一件你真正需要做的事情就是连接所有与你角色相关的数据源。只有当它能获取到所有需要的上下文信息时,才能做好为你整理输出的工作。所以对我来说,就是把它连接到 Google 日历,连接到Slack、Gmail、Google Drive,这样它就知道了,它可以灵活地找到相关的上下文,提出问题,拉取讨论线程,这大大提升了输出结果的质量。我用它做的事情包括[重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容]

19 · 38:44 · Demo: Using Cowork to build slide decks overnight

38:44[重复内容][重复内容]- 太慢了。- 而且我很喜欢,人们会看到这叠演示文稿不管你什么时候展示,它都会公之于众。虽然显然不是一版定稿的,但你已经反复迭代过了。所以就是为了帮助大家自己尝试一下。所以第一步是连接他们的,你怎么说的,Slack?你还建议连接什么?- Slack、Google 日历、Gmail、Google Drive。你应该连接你的通讯工具还有你存储团队核心数据的地方,你们团队关注的,你关注的,以及你正在做的事情。- 好的,那你大概输入了什么提示词来生成这叠演示文稿?- 我就写了,给我做一叠演示文稿用于 Code with Claude 大会。这是我们的 PMM 建议应该涵盖的内容。这是目前我自己做的草稿,我不太满意。这是我自己手动做的一版,不太喜欢,但我附上了链接。

39:38你能先创建一个建议的大纲和详细内容吗?还要确保不要和主题演讲有太多重叠,因为那个更重要。然后 Claude 读了我发给它的一堆链接,创建了一个建议大纲。然后我仔细看了它的提案,还有它生成的所有关于我们可以涵盖什么内容的想法。然后我就决定了哪些内容我想要放进最终的演示文稿里。我觉得这就是一个很好的例子,说明了PM 如今的角色是什么。就是说,Claude 是一个很好的头脑风暴伙伴。它能非常快速地综合大量信息,把所有可能性呈现给你。但 PM 的角色依然是做出最终决定:好吧,最终产品里应该包含什么?所以对于这个,我最终决定让这场演讲涵盖从让本地任务成功,到让每个 PR 都变绿,再到帮助工程师提交更多 PR 的发展过程。对于每个阶段,哪个演示然后在决定了大纲之后,Cowork 就自己跑了几个小时。

40:48然后把整叠演示文稿都做好了。太棒了。不用再做这部分工作真是太好了。感觉就像你在跟一个演示文稿设计师说话,而且他还对你做过的项目有实际的了解,能把内容做成你想要的样子,不只是让它看起来好看而已。你是怎么处理设计系统那部分的?那是怎么运作的?它怎么知道 Anthropic 的设计系统的?所以我的做法是,我们其实已经有了一套标准化的演示文稿模板,在我们所有的外部活动中使用。所以我就把这个模板给了 Claude。然后它就能看到我们用什么颜色、什么字体,以及各种不同的——怎么说来着?可用的幻灯片格式。它有 20 张这样的示例幻灯片。举个例子吧。明白了。所以你上传了——这是我们的模板,从这个开始做。对。你也可以连接到你的 Figma MCP,如果你的演示文稿格式保存在那里的话,它可以拉取过来。

41:43你可以把那个导入进来。说到这个,我一直很好奇的是

20 · 41:48 · Cat's PM tech stack and internal tools

41:48你作为 Anthropic 的 PM,你的工具栈都有什么?当然有 Claude Code 和 Cowork 以及所有 Anthropic 的工具。还有什么?你还用什么?其他的——Slack,你提到了。还有别的吗?所以我的工具栈主要就是 Claude Code、Cowork 和 Slack。Anthropic 基本上是在 Slack 上运转的。我觉得它是我们公司的核心操作系统。日常来说,很多——我大概有 30% 的时间是在探索Cowork 和 Claude Code 的能力边界,这样我就非常清楚我们哪些地方做得不够好。而且我花很多时间和模型对话,来理解为什么它会犯这些错误。我们其实做了很多内部工具。我觉得 Claude Code 真正为我们整个公司解锁的一点是,它大大降低了制作任何你想要的自定义应用的门槛。

42:53所以我们看到个性化工作软件的激增,大家都在为特定的使用场景构建定制工具,而不是使用那些不能完美匹配需求的现成工具。我得听听更多。有什么例子?你自己或者其他人做了什么,特别受欢迎和有用的?Claude Code 的一个销售同事,他发现自己在反复制作这些相同的演示文稿。所以他做了一个网页应用,里面包含了 Claude Code 核心演示文稿的模板,我们知道效果很好的那些,比如 101、201 和精通 Claude Code 系列。然后他有一个方式可以输入特定的客户上下文信息,从 Salesforce 拉取,从 Gong 拉取,从其他来源拉取,这样我们就能为特定客户定制演示文稿。所以它会提取信息,比如,好的,这个客户在使用Bedrock 或者 Claude for Enterprise 或者控制台,这会影响他们能使用哪些功能。

43:53它会提取信息,比如,好的,这个客户关注 SDLC 中的代码审查阶段。所以我们就会在那里加一页关于代码审查功能的幻灯片。它会提取信息,比如,好的,这个客户需要符合 HIPAA 合规,或者需要 XYZ 安全控制。所以我们就会确保在他们的演示文稿里加一两页关于这个的内容。然后,例如如果——这是一个使用 Vertex 或 Bedrock 的客户,不想使用 Claude for Enterprise,那我们就会把一些只有 Claude for Enterprise才有功能的幻灯片拿掉。通常来说,这是需要手动做的可能要花 20、30 分钟的工作。所以人们要么花时间去做,要么就直接决定不做了,用通用版本的演示文稿。用了这个,只需要几秒钟,你就能得到一份定制的演示文稿。

44:41MARK MANDEL:有趣的是,像 Slack 这样的工具没有人——就是没有人想去做一个自己的替代品。Slack 持续在赢。你描述它的方式就是很多公司的操作系统。太有意思了。大家谈论 Salesforce 就像是 SaaS 的代表,但我们不再需要 SaaS 软件了。我们要自己做。但 Slack 是一个持久的工具,没有人想跟它竞争或者做一个更好的版本。LILY FIERRO:我觉得它是非常重要的通讯基础设施。而且我觉得它把核心任务做得非常好,帮每个人获取实时更新这一点做得极其出色。MARK MANDEL:对,大家虽然吐槽 Slack,但它在它要做的事情上确实做得很好。而且最前沿的团队都离不开它。真有意思。LILY FIERRO:是的,我也很喜欢他们把定制化做得这么简单。

45:25所以我们很喜欢做 Slack 机器人。而且这种可 hack 的特性意味着我们可以按照自己想要的方式跟 Slack 集成。真的非常感谢 Slack 在这方面的努力。MARK MANDEL:是时候买点 CRM 股票了。我非常激动地向大家介绍本季的赞助商,Vanta。Vanta 帮助超过——15,000 家公司,包括 Cursor、Ramp、Duolingo、Snowflake 和 Atlassian,赢得并向客户证明信任。团队们正在以史无前例的速度构建和发布产品,这要归功于 AI。但结果是,引入到你的产品和业务中的风险量比以往任何时候都高。我交谈过的每一位安全负责人都感受到了保护其组织、业务日益加重的压力,更不用说他们的客户数据了。因为事情发展得太快了,他们一直在被动应对,不得不猜测优先级,不得不用过时的解决方案将就。

46:21Vanta 通过超过 35 个安全和隐私框架自动化合规和风险管理,包括 SOC 2、ISO 27001 和 HIPAA。这帮助公司快速获得合规认证并保持合规。信任比以往任何时候都更有力量决定你企业的成败。了解更多请访问 vanta.com/lenny。作为本播客的听众,你可以享受 Vanta 1,000 美元的优惠。那就是 vanta.com/lenny。

21 · 46:47 · Which teams use the most tokens

46:48好的,你谈到了所有这些不同的团队以及他们如何使用 Claude Code 和 Cowork 来工作。除了工程团队之外,还有哪些团队?我想工程团队应该是最大的 token 消耗者。如果不是的话,那就很有意思了。目前 token 使用量第二的是哪个职能?哦,Applied AI 团队在探索Claude Code 和 Cowork 的能力边界方面做得非常棒。我们 Applied AI 团队很多人花时间跟客户在一起。帮助他们使用我们的 API。所以有时候我们的 Applied AI 团队会,例如,代表这些客户做原型,而 Claude Code 让这比以前快了很多。他们还有另一个目标,需要管理大量的客户沟通、大量的客户反馈,以及历史联系记录、通话记录。

47:37所以他们既大量使用 Cowork,也大量使用 Claude Code。代码。那 Applied AI 具体是做什么的?那是不是类似前线的部署工程那种角色?大多数人会怎么描述Applied AI 团队在做什么?是的。就是帮助我们的客户在公司内部采用最新的 API 和模型功能,既用于驱动他们公司的产品,也用于内部效率提升。明白了。所以有点像客户成功、市场推广,类似于前线部署工程那种角色。没错。就像一个非常技术型的市场人员。明白了。好的,太棒了。所以你是说他们可能是token 使用量第二的团队。对。而且我们也看到他们在不断推进Cowork 能做到的极限。比如,这些人很多都同时负责多个客户。忙的时候一天可能有 5 到 10 个客户会议。所以他们经常用 Cowork 做的是,前一天晚上,会让它总结一下,好的,我明天有哪些客户会议?

48:44后天呢?这个客户之前都跟我提过什么需求?他们最关心什么?之前会议的行动项是什么?然后 Cowork 就会把一份简报整理出来,一份关于他们在进入下次会议前应该了解的信息汇总。而且 Cowork 还能帮忙研究答案。如果客户问了,好的,功能 X 什么时候上线?Cowork 可以帮助这位 PyDI 成员在 Slack 里搜索获取最新的预计时间,添加到——添加到笔记里,这样在客户通话的时候,这位 PyDI 成员就有了绝对最新的信息。这些都是大家自己构建的工作流,然后分享给团队里的其他人。MARK MANDEL:太酷了。有一个——这个问题,这个趋势——我不知道,这个话题最近经常被提到,就是 token 花费超过了人们的工资,大家用 AI,结果费用比他们的工资还高。

49:40有没有什么数据关于这个话题,比如到底工程师花多少 token,比方说,一个月、一天,或者 PM,之类的?JENNY GUY:我们很清楚,随着模型变得更好,人们会把更多的任务交给它,他们在 Claude Code 和 Cowork 这类工具上花的时间也越来越多。所以我们确实看到每个工程师或每个知识工作者的 token 成本在每次模型升级或重大产品改进后都有所增加。JENNY GUY:我觉得——它仍然比工程师的平均工资低很多,但我们看到这个比例在随时间增长。MARK MANDEL:这真是太有趣了——我们聊到了你们如何能使用最前沿的模型,这是在 Anthropic 工作的另一个优势。在 Anthropic 工作的那种方式。我相信你们基本上有无限的 token 可以用。

50:30你们——想用多少就用多少,对吧?JENNY GUY:我们可以用很多 token。有些人确实会遇到限额,所以——MARK MANDEL:好吧,原来有限额。好吧。Boris,关掉它。好的,能使用最先进的模型有这么多优势,真是太有意思了。这就形成了一个非常有趣的飞轮效应。我们也非常相信要赋予我们的内部团队尽可能快的构建能力。而且我们相信每个人都理解运行这些模型到底需要多少成本。而且我们相信团队会负责任地使用 token。所以浪费 token 是很不受待见的,但我们确实信任每个人做出这个判断。我们相信团队可以做出这个判断。

22 · 51:15 · The emerging skills PMs need for AI companies

51:15MARK MANDEL:太棒了。回到 PM 角色的话题,我们之前聊过一些,但我觉得这对听众来说会非常有趣。我想了解的是,你认为PM 需要培养哪些新兴技能,或者说你最看重什么,AI 公司如今在招聘 PM 时最看重什么?JENNY GUY:我觉得最难的技能是能够定义产品一个月后应该是什么样子。我觉得在那个时间范围内模型能做到什么,以及用户行为会怎么变化,都有很多不确定性。但我认为最优秀的 PM 能看到一些模式,基于用户如何"滥用"现有产品边界的模式。最好的 PM 能感知到这一点,能设定方向,能稳步朝目标执行,如果模型能力比预期好得多或差得多,还能调整路径。比他们最初预期的还要糟。我觉得很难把握好"AGI 信仰"的程度。所以我觉得每个人都能看到那个模型极其聪明、几乎什么都能做的未来,在这种情况下你其实不需要那么复杂的产品。

52:31你其实只需要一个文本框,告诉模型你想要什么。它聪明到可以自动添加任何工具或任何它需要的集成来完成任务。它知道什么时候不确定。它可以问澄清问题。为超级 AGI 强模型构建产品其实很容易。我觉得难的是,针对当前的模型,你如何激发它的最大能力?你如何帮用户找到最佳路径?你如何引导用户与模型的优势互动,同时弥补它的弱点?这种技能非常稀缺。那你怎么培养这种技能?基本上就是理解每个模型的限制吗?你说的是品味吗?理解,对模型可能的能力有品味,知道它擅长什么、不擅长什么,哪里有变化?我觉得就是花大量时间跟模型对话和使用模型。我特别喜欢做的一件事就是让模型反思自己的行为。所以,有时候当我发现模型做了意想不到的事情,比如,有些情况下模型会做前端修改然后跑测试,但实际上并没有使用 UI,这时候让模型反思一下为什么这么做其实很有用。

54:01有时候它们会说,"嘿,系统提示里有一些令人困惑的内容,"或者,"我没意识到前端验证是这项任务的一部分,"或者,"嘿,我把验证委托给了子 agent,但子 agent 没有做测试,我也没有检查它的工作。"很多时候,对模型为什么做出那个决定保持好奇心,就能让你看到是什么误导了它,这样你就可以修复引导机制来弥补这个差距。另一件有帮助的事是找出你最信任的那些用户,让他们给你关于模型的准确反馈。通常有那么几个人比其他人更善于表达是什么让某个特定的模型或模型+工具组合好用。很多人会给你反馈,但不是每个人的反馈都同样有价值。所以,找到你信任的那五个人,对于获取快速反馈非常重要。

23 · 55:00 · Why building evals is underappreciated

55:04我觉得第三件有用但不是所有人都喜欢做的事是构建 eval。你不需要构建几百个 eval 才有用。只要构建 10 个好的 eval,就能帮助团队量化目标是什么,他们离目标有多远,以及还缺什么。所以我觉得 eval 是一种被低估的东西,更多的 PM 和工程师应该去做。我们之前聊过很多关于 eval 的话题。有一种趋势就是,"产品管理的未来就是写 eval,"因为本质上,它让我们看起来就像,"好的,很酷。让我具体定义一下,然后我们就知道了。"你觉得你花多少时间在写 eval 上?我觉得 eval 的重要性取决于你正在做的功能或者你试图解决的问题是什么。所以,我们团队有很多人确实花了很多时间在 eval 上。我们有一个小组跟研究团队紧密合作,更精确地了解我们 Claude Code 的行为,以及最大的改进空间在哪里,并且努力非常具体地衡量这些。

56:30我个人会在某个功能需要更多产品定义的时候跳进来做 eval。通常的产出是,"好的,这是我做的五个 eval。这是运行方法。不过差异很大。取决于具体的功能。不是每个功能都需要,但我觉得像记忆这样的功能从中获益很大。你说的关于人们非常擅长评估模型这一点太有趣了。几乎就像一个人肉 eval,就是"好的,他们知道哪里表现出色,哪里可能不足。"有没有什么特定的人你想提一下,特别擅长这个的?我觉得在这方面非常厉害的两个人,一个是 Amanda,她塑造了 Claude 的性格。这个角色真的很难,因为任务太模糊了。即使是编码都更容易,因为你可以验证成功与否,而塑造性格需要对 Claude 应该成为什么样的人有非常强的信念。我觉得她不仅有能力塑造性格,还能非常清晰地表达目标是什么,性格应该是什么样的,什么是成功的,什么是不成功的。

57:35我觉得她不仅有能力塑造性格,还能非常清晰地表达目标是什么,性格应该是什么样的,什么是成功的,什么是不成功的。我觉得她不仅有能力塑造性格,还能非常清晰地表达目标是什么,性格应该是什么样的,什么是成功的,什么是不成功的。我觉得她不仅有能力塑造性格,还能非常清晰地表达目标是什么,性格应该是什么样的,什么是成功的,什么是不成功的。我觉得她不仅有能力塑造性格,还能非常清晰地表达性格应该是什么样的,什么是成功的,什么是不成功的。另一群我非常信任的人就是 Claude Code 团队。所以我们经常有团队午餐,每当有新模型在测试时,我们获取反馈最快的方式之一就是在这些午餐上,走到每个人面前问,"嘿,你对这个模型感觉怎么样?"通常我们会得到这样的反馈,"好的,这个模型好像没有充分解释它的思考过程。

58:06太唐突了。"或者,"嘿,这个模型就是喜欢写一堆记忆,但我们不确定这些记忆质量高不高。"或者有人会注意到,好的,这个模型喜欢自己测试自己,这很好。或者这个模型自我测试不够。这告诉我们应该去看什么数据来验证,好的,这是不是一个更大的模式?我们有大量数据,但很难从中提取洞察。所以这个群体的反馈就是,"嘿,这个模型喜欢写一堆记忆,但我们不确定这些记忆质量高不高。"我们有大量数据,但很难从中提取洞察。所以这个群体的反馈就像,"嘿,这个模型喜欢写一堆记忆,但我们不确定这些记忆质量高不高。"我们有大量数据,但很难从中提取洞察。所以这个群体的反馈帮助我们明确,好的,我们要测试哪些假设?然后我们就能提取数据来验证。[重复内容][重复内容][重复内容][重复内容]

24 · 58:44 · Why Claude's character and personality matter so much

58:44[重复内容]你提到的关于 Claude 性格这一点,我之前请过联合创始人 Ben Mann 来做播客,他谈到过这个,就是 Claude 的性格和特质是 Claude 非常重要的一部分。[重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容][重复内容]大家真的很喜欢 Claude 的低调。

1:00:03所以如果你告诉它,嘿,你做错了这件事。它会真心道歉。就像,哎呀。就像,谢谢你告诉我,让我来修一下。我们一起解决。而且它也非常积极。所以如果你觉得,哦,这任务太难了。我不知道怎么开始。Claude 就会说,好的,没关系。我觉得我们应该按这些步骤来做。要不要我先开始帮你做?我觉得一个好同事的特质就是这种积极性,这种行动导向,这种能给你真诚反馈的能力,而不是你说什么就同意什么。所以我们努力把这种特质融入到 Claude 中,因为我们觉得

25 · 1:00:44 · How new models force product changes

1:00:44这样会让跟它合作变得更加愉快。有个话题我想回来聊聊。你谈到每当新模型出来的时候,你经常需要重新审视之前构建的东西。太有意思了。而且可能还有点沮丧,就像,天啊,我们已经发布了这个东西。现在又得重新思考。聊聊大概多久会发生一次。你需要回过头来处理新模型,然后说,好的,我们要重做几个月前发布的产品。很多时候,新模型带来的变化是移除不再需要的功能。很多时候我们给产品添加功能是为了弥补模型的不足,因为它本身做不到。典型的例子就是待办事项列表。我们刚推出 Claude Code 的时候,人们会要求它做大型重构,Claude Code 就会说,好的,没问题。我需要——然后它要修改 20 个调用点,结果只改了 5 个就停了。然后我们就在想,怎么才能让它记住要改完所有 20 个?

1:01:39所以我们团队的 Sid 就说,好吧,我们想想人类会怎么做?人类会先把所有需要修改的东西列一个清单。就像在 VS Code 里,你会查找所有调用点,左边会显示一个列表,然后你一个个去替换。我们怎么给 Claude 这种工具呢?所以他就添加了待办事项列表。我们发现有了这个之后,Claude 确实能够修改完所有 20 个调用点,但后来有了 Opus 4 和更新的模型,我们意识到不需要再强制它使用待办事项列表了。对早期的模型来说,它会自己用。我们需要不断提醒它。嘿,待办事项都做完了吗?你得把待办事项上所有的事都做完才行。而对于后来的模型,不需要提示,它就自然地会把待办事项上的所有事情都做完,现在待办事项对用户来说还是有用的,因为你可以更清楚地看到 Claude在做什么,但说实话,它现在已经是产品中非常弱化的一部分了,模型可能会用,也可能会不用。

1:02:40它已经不再是做出彻底修改所必需的了。我忘了是谁在播客上说的,模型会把你的脚手架当早餐吃掉。我在这里听到的基本上就是你——你随着时间推移移除了那些不得不加在模型之上的东西,因为它之前没有按你想要的方式运作。基本上随着模型变得更聪明,它就变得越来越简单,就能直接做你想让它做的事了。是的。每次模型变聪明的时候,我们可以移除很多提示干预。模型变得更聪明的时候。其实每次发布模型我们都会做这件事,我们会通读整个系统提示,然后反思,好的,对于每个部分,模型还需要这个提醒吗?如果不需要了,我们就把它移除。不过新模型最令人兴奋的是全新功能。有很多功能我们之前用旧模型测试过,但准确率不够高,我们不想发布。其中一个例子就是代码审查。我们尝试过几次构建代码审查产品,也发布过一些简单版本的代码审查,就是过去的斜杠代码审查命令。

1:03:50这个代码审查太好了,以至于我们的工程团队在合并 PR 之前都要依赖代码审查通过。我们发现,我们一直梦想着 Claude 能成为一个可靠的代码审查者,能够——我们有信心它能发现大部分的 bug。直到 Opus 4.5、4.6 和 Sonnet 4.6,我们才觉得,好的,我们现在可以同时运行多个代码审查 agent,遍历整个代码库,然后综合出工程师在合并前需要处理的一系列真实问题。所以这就是最新的模型解锁的一项新能力。这是本播客上非常常见的一个趋势:构建那些在未来六个月内可能实现的东西,稍微处于可行性的边缘,然后模型会追上来,产品就会变得非常好,而你已经领先所有人了。没错。构建那些暂时还不能用的产品很重要,这样你就知道,好的,这个产品要能用还缺什么。

1:05:09然后有了最新的模型,你可以直接把它

26 · 1:05:11 · The vision for Claude Code and Cowork

1:05:12换进你已经做好的原型里,看看,新模型是否填补了那个差距。你能在多大程度上谈谈 Claude 和 Cowork 的发展方向和愿景?我想你不想透露太多目标,但感觉你——有所有这些很棒的功能在上面叠加,调度、手机控制,还有移动应用,所有这些,怎么理解这些产品长期的整体愿景?我们用构建模块的方式来思考这件事。对于 Claude Code 和 Cowork,核心构建模块就是让单个任务成功。所以你想要它产生某个输出。你给它一个清晰的提示描述。它能持续产出你能接受的输出吗?你可以合并,或者分享给同事,或者给外部用户?所以任务是核心构建模块。随着模型变得更聪明,任务成功率大幅提高。然后我们看到人们开始同时做多个任务。所以多 Claude 并行是 2025 年底的一大趋势,而且此后只增不减。

1:06:17所以我们把这看作,好的,很好。单个任务搞定了,现在你可以同时跑六个任务。随着模型变得更聪明,我们的推演是,好的,接下来,也许你会同时运行 50 个 Claude,或者几百个 Claude。那么我们需要构建什么基础设施来支持这个?到那时,你可能不会在本地机器上运行所有东西了。就是没有足够的内存来做这件事。所以我们正在思考如何让你更轻松地管理所有这些?这些可能会远程运行。我们怎么构建界面,让你作为人类知道哪些任务需要查看,我们怎么确保 agent 完整地验证了它的成果,这样当你看到一个任务显示完成时,你能很快验证并且完全信任它达到了你的要求。我们怎么确保这个过程是自我改进的,这样当你确实看到一个不符合你要求的任务时,你可以给它反馈,

27 · 1:07:22 · Advice for thriving in an AI-driven world

1:07:23模型会在未来的每次运行中 incorporate 那个反馈。这样它就再也不会犯同样的错误了。这就是我们带用户一起前进的路径。有很多——听众里有很多产品经理、很多创始人、很多其他跨职能的人。很多人担心自己的角色、职业生涯的未来,你对这些人有什么建议,不只是在这个 AI 驱动的世界里生存下来,而是真正成功,在这个未来中蓬勃发展?有什么大家需要听到、需要去做的?我觉得 AI 给了每个人比以前多得多的杠杆。所以我建议你,每当你发现自己在反复做某个手动任务时,想想怎么用 Claude Code、Cowork 或其他 AI 工具来自动化它。大多数人都有工作中非常喜欢的创造性部分。然后还有一些非常讨厌的繁琐部分。我觉得 AI 的美妙之处就在于它可以帮你做那些繁琐的部分。

1:08:53它可以从你每次做的过程中学习。它可以做手动任务,总结规律,然后自动运行,这样你就可以专注于创造性部分。这意味着你能做到比以前多得多的事情。

28 · 1:09:18 · Why 95% automation isn't good enough

1:09:19所以我对大家的直接建议是,找出可以交给 Claude 的重复性工作,迭代这些自动化,直到成功率非常高,然后专注于,好的,你还能为你的团队、你的产品、你的公司做什么,那些人们一直没精力去做的事情?比如那个你一直觉得公司应该做的 pet project,但你从来没时间做?你可以自动化的,关注那些一直想去做但没时间的想法。基本上就是为自己解决一个问题,这是核心建议。没错。我也想鼓励听众,把你的自动化从,好的,这是一个好工具,这是一个很酷的概念,变成,嘿,这个真的百分之百能用了。有时候我看到用户尝试自动化某件事,做到 90%、95% 的准确率,然后就放弃了。如果一个自动化不能百分之百工作,它就不算是真正的自动化。而最后那 5% 到 10% 确实需要更多时间。

1:10:15而且构建自动化往往比你亲自动手慢很多。我鼓励大家投入那个时间。投入时间去定义你真正想要做到百分之百的自动化,下功夫教 Claude 你的偏好,给它反馈,让它提高技能,直到达到百分之百。然后你就真的能依赖它了。一个 95% 的自动化其实没多大价值。我太有这个毛病了。这个建议对我太有用了。我也有这个毛病。我一直在教它。我一直在教 Cowork——试着帮我达到 Gmail 收件箱归零,但效果一直——非常耗时,而且肯定还没做到,你可能也发现了。是的,有趣的是。我想到的也是这个。我有一个工作流,每封邮件进来后,它会找出那些垃圾性质的邮件,就是那些,"嘿,我能上你的播客吗?"或者"要不要做个广告?"之类的,我就是没时间处理这些,所以我让它把这些分到一个叫"垃圾邮件"的文件夹里。

1:11:22而且它——95% 做得很好。但有时候就会,哦,天哪。我错过了一封邮件,因为它被分到那里去了。所以这对我来说是一个很好的推动,我要把它做好。我要把它做到完美。是的。我们也在努力让定制这些命令的流程变得更加简单。因为现在我觉得你需要了解太多概念了。你需要知道怎么定义一个 skill。你需要知道怎么使用这个 skill,还要给它反馈。然后你还需要知道告诉 Cowork 基于你给的所有反馈来更新这个 skill。然后你还需要知道去哪里读这个 skill,确保反馈被按照你的要求

29 · 1:11:58 · Build apps you use every day, not prototypes

1:11:58纳入了。这也是我们的工作,让这个流程变得非常顺畅,不会让人觉得很痛苦。太棒了。还有什么想分享的吗,Cat?还有什么想留给听众的?有什么想进一步强调的,在我们进入非常精彩的闪电问答之前?我看到很多人在玩 AI,构建一些原型应用,摆弄各种工作流。我真的很建议大家去构建你真正在用的应用。每天在用的那种,因为我觉得只有通过这种使用,你才能真正获得价值。如果你构建了一个原型应用但并不能帮你完成更多工作,那 AI 并没有真正为你的日常生活增加价值。你只做了一次就觉得,好的,我就试了一次。哦,挺酷的。然后你再也不碰它了。你学不到多少东西,也得不到什么真正的杠杆。真正的杠杆。是的。这个观点太好了。我也觉得有很多人花了很多时间在定制他们的工作流上。所以就像,我觉得有两端。一端是从来不定制、从来不构建自动化的人,但还有另一端的人痴迷于定制他们的工具,比如加一堆 skill 和 MCP,还有这些工作流改进。

1:13:30我觉得有时候这甚至会分散你做核心目标的注意力,

30 · 1:13:41 · The divide between AI skeptics and believers

1:13:41比如发布某个产品或构建某个功能。定制化确实很有趣,而且我们当然希望我们的产品非常可 hack,这样你可以让它很好地为你工作,但它的实用性是有限度的。我觉得有一类人可能花太多时间在定制上了,以至于没在睡觉,也没在做他们最初想做的核心任务。我在 Twitter 上看到很多这样的。就是那种,"看看我的设置。""简直失控了。""优化到极致了。"然后你问,你到底在构建什么?"不是,但我的设置太棒了。""我能做超多事。"我觉得简单的设置实际上效果更好。就是稍微提升一下就好。是的。是的。Karpathy 昨天发了一条推文,他谈到了这种分化。很有意思,就是当年试过 ChatGPT/Claude 的人,觉得,好的。然后说,"不,这太差了。"两边的人都不理解对方,不理解对方为什么那样看待世界。

1:14:32所以你的建议在这里真的很好。就是真正去用它做实际的事情,看看它到底变得多好了。是的。我觉得最大的转变是,2024 年那一代产品是基于对话的,而 Claude Code 这一代产品是基于行动的。所以大家的大 aha 时刻就是当 Claude 可以替你做事的时候。那种感觉非常奇妙,知道 agent 能做到的远不止是告诉你该怎么做。agent 可以真的自己去做。当人们感受到这一点时,我觉得那就是豁然开朗的时刻。顺便提一下 Chrome 扩展,Claude 的 Chrome 扩展,你可以看着它在做事,比如你让它帮你填个表格。它就会说,好的,我开始了。没错。

31 · 1:15:19 · Lightning round

1:15:19好的。在我们进入非常精彩的闪电问答之前,还有什么吗?没有了,开始吧。开始吧。好的,Cat,我有五个问题要问你。欢迎来到闪电问答。有个动画——我得说一下。你准备好了吗?我准备好了。第一个问题。你经常推荐给别人的两三本书是什么?我很喜欢《How Asia Works》。它是关于经济发展的故事,以及什么样的政策、政府能创造长期的——那个——持久的、成功的经济体。我喜欢的另一本书是《The Technology Trap》。它其实是关于过去几次技术革命的,工业革命和计算机革命,以及这些如何影响了工人。我喜欢它的原因是我觉得我们可以从历史中学到很多,来确保这次的转型进展顺利。也许轻松一点的推荐,我很喜欢《Paper Menagerie》。它就是一本短篇故事集,关于成长、AI 和自我发现。最喜欢的近期电影或电视节目?我很喜欢《Drive to Survive》。没有什么深层含义。

1:16:39我就是觉得那些人对一个单一的工程目标如此痴迷,追求的纯粹性,让人非常满足。我还很喜欢《Free Solo》,关于 Alex Honnold 不带安全绳攀登 El Capitan 的故事。我觉得类似地,能够攀爬这条极其挑战性、危险的路线,还能保持那种精神专注力,知道犯一个错误就会死——这太纯粹了。太疯狂了。是的,那部电影真的太震撼了。有趣的是这些在某种程度上跟你做的工作也有关联。我其实是个攀岩爱好者。我在攀岩之前就看了《Free Solo》。所以当时觉得很厉害,但不知道到底有多厉害。这是那种罕见的电影,你越了解,就越被震撼到。像他在墙上做的那些动作,我觉得我这辈子在攀岩馆里、离地一英尺,都做不到。还系着绳子。系着绳子。你看了那个关于另一个更年轻的攀冰者的纪录片吗?

1:17:49我看了。那个很令人难过。但那个真的很疯狂。好的。你最近发现并非常喜欢的产品?除了 Claude 相关产品之外,对我的生活改变最大的产品可能就是 Waymo 了。我是一个铁杆 Waymo 用户。每天用两次,上下班通勤。是的。我喜欢它的两点,一是如果 Waymo 在等我,我不会觉得不好意思。所以我觉得不用那么有压力非得在它到达的那一刻就站在路边。第二是我觉得它让我更高效了。当我和另一个人在车里时,我通常不会打工作电话。我觉得如果在车上一直用笔记本电脑有点不礼貌。但 Waymo 的好处是我可以接工作电话。不用担心有人偷听。不用担心,嘿,这样会不会很没礼貌?我是不是说话太大声了?要不要让人家换个音乐?所以这真的——我觉得每天帮我省了 30 分钟。

1:18:47技术的这些二阶效应。太有意思了。是的。我一直以为 Waymo 需要定价比 Uber 和 Lyft 低才能成功,但实际上我非常乐意付两倍的溢价。我爱 Waymo。就是——你一旦体验过,你就会觉得,啊,这太——太疯狂了。然后你就习惯了。你坐进去的时候会觉得,太不可思议了。然后你就忘了这种感觉了。完全正确。而且我觉得它也改变了语言习惯。Anthropic 很多人喜欢 Waymo。过去你可能说,嘿,叫个某某打车软件。现在大家就直接说,好的,Waymo 到了吗?好的。还有两个问题。你有最喜欢的工作或生活中的座右铭吗?去做就好。我觉得第一性原理思考非常有价值。如果你知道你在优化什么,而且你有很强的第一性原理,那你通常能推导出正确的行动方案,并且能向所有利益相关者清楚地表达。

1:19:46然后你就应该去做。我觉得工作头衔是假的。如果你理解了约束条件,你就能弄清楚你能做什么,然后就去做,快速学习,如果做错了就道歉或修正。比如快速去做、从错误里学习,做错了就道歉或者修复做错了。你就可以去做事情。谁说的来着。我觉得这其实是一种解放。告诉大家这个,我觉得很多公司的角色定义非常严格,好的,PM 做这个,设计师做这个,工程师做这个。然后连团队范围都定义得很死板。所以,嘿,代码库的这个角落我们碰,那个角落我们不能碰。我觉得"去做就好"让大家觉得自己有权力做这些决定,有权力跨团队操作,就是为了把事情做好。这感觉是一项非常重要的技能。要擅长的,人们称之为"主动性"。就是去做需要做的事。行动导向。行动导向。所有这些描述方式都是在说,不要等许可。

1:20:50是的。我觉得这是在人生某个阶段去创业公司工作的最好理由,因为对我来说非常改变人生的一件事就是在 Scale 只有 20 个人的时候工作。那时候完全没有流程,但我们需要解决非常大的问题。我真的很感谢 Alex 和团队其他人给了我这么大的自主权。让我和团队其他人可以不受边界限制地去解决问题,不管销售应该做什么,运营应该做什么,工程师应该做什么。就像你拥有所有可用的工具,面对一些雄心勃勃的棘手问题,你可以做任何需要做的事来找到好的解决方案。你几乎需要那种经历来培养那种技能,让自己习惯这样做。因为很多人,你知道的,从学校或大学一路走来,都是"做我们让你做的事,然后你就会得到好成绩"。你需要忘掉这种思维,就像,好的,我就去做需要做的事。即使别人觉得这很蠢,但我觉得这是对的事情。是的,没错。

1:21:47好的。其实我还有两个快问快答。最后两个问题。一个是,Claude 会有那些——我不知道你们叫不叫动词,这些东西叫什么?思考词。思考词。有趣的是,这些词在源代码里泄露了。你有最喜欢的思考词吗?我非常喜欢"manifesting"。这也是我笔记本电脑上的贴纸。哦,太棒了。显然是赢家。好的。最后一个问题,AGI 有可能在我们有生之年到来,当你不用工作的时候,你会做什么?你会用你所有的时间做什么?我觉得 AGI 扩散到整个社会还需要很长时间。所以我觉得眼前的其实是帮助世界跟上步伐。我的不太认真的回答是,那之后我可能就是去攀岩。我可能就搬到Fontainebleau,住在那一万块巨石中间,爬一阵子。还有好多书想读,目标是每周能读一到两本书。现在大概只能读 0.5 本。积压的量很大。我觉得历史有太多我们可以学习的,太多我还不够了解但很想深入了解的。

1:23:11物理学,或者机器人学,或者硬件,或者航空航天——有太多有趣的话题了。所以我很期待去学习,即使知道 AGI已经都知道了。Kat,太棒了。你太厉害了。两个后续问题。大家在网上哪里可以找到你,如果想联系你或关注你的动态?听众怎么帮到你?最好的联系方式是我在 Twitter 上的账号:_KatWu。可以在推文里 tag 我,也可以给我发私信。我会读所有私信。虽然不一定会每条都回复,但我都会看。然后最有帮助的是告诉我们Claude Code 和 Cowork 在哪里对你不好用。我们非常感激大量的正面反馈。但我们最需要的是边界情况、错误,那些我们能复现的具体任务,Claude Code 或 Cowork 在哪里失败的。因为如果你能分享给我们,我们能复现,那这就是我们能主动改进的,为下一代模型和下一代工具。太酷了。Twitter 上的人分享这些反馈一点都不害羞。

1:24:28所以继续来吧。分享,分享。请,请把你们遇到的问题分享给我们。是的。而且很酷的是你们整个团队在 Twitter 上这么活跃,回复大家。所以——我听到的就是,这些确实是你们真正会看到并做出反应的东西。是的。我们感谢大家的积极参与。这给团队带来了很多能量。我们有一个"用户之爱"频道。所以每当你们分享成功故事,我们就会发到那里。每当你们分享产品的问题,我们就会放进反馈频道。这样我们更大的团队就能据此行动了。知道这个太酷了。谢谢分享。Kat,非常感谢你来。谢谢你的邀请。大家再见。非常感谢收听。如果你觉得有价值,可以在Apple Podcasts、Spotify 或你最喜欢的播客应用上订阅。也请考虑给我们评分或留下评论,因为这真的能帮助其他听众找到这个播客。你可以在Lenny's Podcast.com 找到所有往期节目或了解更多关于这个节目的信息。下期再见。

发布速度产品品味使命认同Research Preview(研究预览)AGI 校准模型自我反思评估(Evals)Claude 的性格自动化阈值角色融合