编码问题解决之后会发生什么？| Fiona Fung（Claude Code 与 Cowork 团队负责人）
What happens after coding is solved? | Fiona Fung (Manager of the Claude Code and Cowork Teams)
嘉宾：Fiona Fung
全文文稿 · 按对话顺序保留完整内容，深入理解上下文。
§01文稿 · 0:00
Anthropic 的工程师平均每季度产出的代码量，是 2025 年同期的 8 倍。编码已经不再是瓶颈。
它已经把每个人能做到的事情推到了能力上限。
理论上一切现在都可能做到。接下来要看的是：你的野心能有多大？
我一直很好奇，在这个新的软件工程世界里，什么东西会被丢失？
这可能会变成一种孤独的体验，因为我们都开始在 ClockCo 团队里大量和自己的智能体一起工作。最近，我们开始组织结对编程午餐。
你会想到，越来越大的鸿沟正在两类人之间形成：一类人拥抱 AI、表现出色，另一类人则非常沮丧，在抗争、抵制。
说到沮丧，我有时也会看到一些恐惧。对于任何让你感到恐惧的事情，我的建议都是拥抱它，然后问自己：我能做些什么？哪些事情在我的控制范围内？
今天我的嘉宾是 Fiona Fung。Fiona 负责 Anthropic 旗下 Claude Code 和 Cowork 背后的团队。她同时管理 Boris Cherny 和 Kat Wu，他们都曾来过这档播客，他们的节目也都位列历史收听量最高的前十名。加入 Anthropic 之前，Fiona 在微软负责打造 TypeScript 和 Visual Studio 的团队。之后她去了 Facebook，在那里创办了 Facebook Marketplace 团队，并将它从一个想法做到了上线。如今，Facebook Marketplace 每年的商品总额超过 1000 亿美元。她在 Meta 任职期间还负责过 Meta 第一款智能眼镜产品的相关工作，之后又帮助打造了 Orion，也就是他们第一款 AR 眼镜产品。
之后她去了 Instagram，负责基础设施、增长、诚信与安全团队。在 Instagram 和 Meta 任职期间，她管理过一个规模超过 500 人的组织。Fiona 做了 25 多年的工程师，而作为一名长期担任工程领导者的人，尤其是现在在 Anthropic，她对事情的发展方向、值得关注的内容以及团队应该思考的问题，都有非常独特的视角。下面请听 Fiona Fung。
Fiona，非常感谢你来到这里，欢迎来到这档播客。非常感谢你邀请我，Lenny。
邀请我，Lenny。
大约一个月前，我参加了 Code with Claude 活动，也听了你的演讲。我当时就想：天哪，我一定要邀请 Fiona 上这档播客。她思考事情的方向远远领先于其他人，也远远领先于大家当前对 AI 的理解。你做了 25 年工程师。我浏览过你的 LinkedIn，你最初居然是在 IBM 工作的。如今那里已经是完全不同的地方了。过去短短两年里，工程师的工作变化大得惊人，简直像换了一份工作：人们可能会忘记，就在不久前，100% 的代码还是由人类编写的，而现在正逐渐变成 100% 的代码由 AI 编写。正如 Boris 那句著名的话：编码已经解决了。
说到这里，你们昨天发了一条推文，内容是：Anthropic 的工程师平均每季度产出的代码量，是 2021 到 2025 年同期的 8 倍。我们会把这张图放在屏幕上。数据一直稳定、稳定、稳定，然后突然猛冲，直上月球。这个角色发生的变化实在太惊人了。我想了解一下你作为工程师一路走来的经历：长期做工程师、亲历这些变化之后，沿途有哪些重要时刻改变了你的思考和工作方式，并最终让你走到今天、以现在的方式工作？
我很喜欢这样回顾过去。那时我在 IBM 做 DB2，属于操作系统服务团队。当时我在想，怎样才能进入技术栈中最难的领域？我确实认为，越往底层、越接近操作系统，就越硬核，也能学到更多东西。所以我非常幸运，得到了 IBM 的实习机会。但有趣的是，从 IBM 到微软，我觉得还发生了一次很大的转变。在 IBM，我记得我们用的似乎是 Vim。我没有使用过 IDE，可能有一个 Eclipse 许可证，但不知为什么，我们大多数人都不用。所以我记得当时主要使用 Vim 和终端调试。
后来我加入微软。你可以想象我当时有多天真：我甚至不知道 IDE 之类的东西。当时也不能真正选择团队，那是 2000 年代初。其实首先应该说，我非常感激自己能拿到那份实习和工作。把时间拉回更早的时候，互联网泡沫在 2000 年破裂了。所以对我们这一届毕业生来说，很多公司都不招聘，或者冻结招聘。微软向我发出邀请，我真的非常幸运。他们说：你会去做 Visual Studio。我当时甚至不知道 Visual Studio 是什么，因为我来自 Unix 学校。
所以我记得自己当时问：Visual Studio 这个名字听起来，它是不是一个更好的画图软件？我能看出经理脸上的表情，仿佛在说：这到底是怎么回事？但后来，它成了我职业生涯头 11 年里最爱的东西。那也是我第一次使用 IDE。加入 Visual Studio 团队后，我看到：哇，这里有一个带调试器的 IDE，可以设置断点，还能进行多线程调试。这让我一直感到不可思议。回头看这种一步一步的变化，是的，从 IBM 到 Visual Studio，大概就是这样的经历。然后我真正喜欢上的地方是……
其实，我当时在 Visual Studio 编辑器团队，所以我用 VS 编辑器来构建 VS 编辑器。这就是我对 dogfooding（内部试用自己产品）产生全部热爱的来源。我记得自己首先想做的，是创造一种令人愉悦的体验，不只是为我自己，也为我的队友。因为如果我们再回到那个年代，你还记得 Twitter 是什么时候出现的吗？2006 年？感觉它好像伴随了我的一生。但在社交媒体出现之前，大多数工程师也更难快速听到客户反馈。当然，那时也会有用户研究环节，或者客户来拜访我们。
但你得不到如今这样快速的反馈。不过那时我很幸运，因为我在 VS 团队。我们自己就能获得大量快速反馈，因为团队里的每个人都是 VS 的重度用户。
本期节目由本季冠名赞助商 WorkOS 赞助。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家成功公司有什么共同点？它们都由 WorkOS 提供支持。如果你正在为企业构建产品，就一定感受过集成单点登录、SCIM、RBAC、审计日志以及大公司要求的其他功能时的痛苦。WorkOS 把这些阻碍交易的功能变成开箱即用的 API，并提供一个专为 B2B SaaS 打造的现代开发者平台。构建……下次见。
WorkOS 让你能够借助令人愉悦的 API、完善的文档和顺畅的开发者体验，更快地构建产品。访问 workos.com，让你的应用今天就具备面向企业的能力。
人们会想到工程师职业道路上的这些里程碑，但我们忘了，多年来还发生过许多变化。它们不完全等同于我们正在经历的变化，但 IDE 和 Visual Studio 确实带来了类似的转型。所以我很喜欢你提醒我们软件工程历史上那些以很大方式改变工作的时刻。
我当时在 Visual Studio 工作时，我们还通过 CD 发布软件。也正因为如此，当时有非常严格的截止日期：你必须确保软件准备好交给制造部门，然后他们把它刻录到 CD 上，最后我们才能把 CD 放到货架上。后来我们又经历了一次转变，开始能够在线发布软件。我觉得这件事很有意思。我在演讲中也提到过：以前工程师的时间是一种非常宝贵的资源，但与此同时，我们还面临着非常严格的截止日期，比如印制软件 CD。
所以那时你会做更多规划，因为你希望在有限的时间里把事情做到最好。而这就是我们在 Claude Code 和 Cowork 中看到的变化：编码不再是瓶颈。你刚才展示了那条推文和图表。现在关键变成了：这种转变发生之后，我们该如何应对？如今不只是工程师，设计师、产品经理，以及 ClockCo 团队里的每个人都会提交代码。提交代码的人更多了，参与的专业领域也更多了，而且产出速度还非常高。我们该如何思考验证问题？
这就是我正在看到的另一个变化。
§02文稿 · 9:27
我想先为这场对话定下一个主题。很多人都在问：未来的软件工程、软件工程师管理，以及软件和产品团队管理会是什么样？而你现在正亲历这一切。你提到了更加重视验证，确保代码量达到 8 倍时，质量仍然很高，而且确实能够正常工作。所以我想先问一个宽泛的问题，再看看谈话会走向哪里：一个在 2026 年‘AI 上头’的软件团队是什么样的？
随着角色被打破，工作越来越转向构建者。可以说，每个人都开始成为构建者。我最近做的另一个转变，是在我们所有的代码仓库里都加入一个 Claude Code 远程会话。这样我就能完整了解每个人正在做的工作。这个实例还能够访问我们所有的 Slack 频道，也能让我看到我们追踪的各种指标。每个月我都会说：‘嘿，做点有趣的事吧，我们回顾一下。’然后我们会一起进行。我会分享我的 Claude Code，也会分享屏幕，我们一起进行一次 Claude Code 会话。内容就是：当时有哪些重点领域？
比如，哪些产品发布了？效果怎么样？反馈渠道有哪些？所以，尽管以前我可能只会用这些会话来生成 PR 和修复 bug，但现在我会利用这些会话，和我支持的同事展开对话。
再多说一点。所以这可以说是一种管理方法，帮助人们不只是发布产品，而是更好地发布产品，并理解他们发布的东西是否产生了影响？大概就是利用 Claude 来掌握大家发布的所有东西，然后把它变成一次对话，对吗？
完全正确。也就是说，除了发布这个动作本身，还要看它在市场上的表现，或者我们是否引入了 bug。我有一句话：‘犯新的错误。’犯错没关系，只要犯的是新的错误，这样我们就能不断学习。因为如果你的目标是零错误，那可能意味着你行动得还不够快，或者过于谨慎。所以，有了 Claude 之后，他们也可以查看一些内容。比如，实际上我刚才就在看：考虑到我们发生过的一些事故，让我们把这些都放在一起，看看能不能总结出一个主题。
接下来我们应该重点投资哪个领域？尤其是考虑质量时，我们有没有看到哪些热点，或者哪些地方可能存在缺口？我觉得过去这曾经是一个更加手动的过程。回顾一年前，我认为自己不可能借助 Claude 得到其中一些洞察。
是的，部分原因在于，除了这些，人们当时发布的东西也没有这么多。你可以简单列个清单：上个季度我发布了这些东西，这个功能、那个功能、还有这个功能。所以我理解你的意思是，这是掌握队友发布的一切的少数方法之一。这条思路很有意思：面对代码产出增加 8 倍的情况，你还找到了哪些方法，帮助自己和团队掌握并维持所有这些发布内容的质量？因为这显然是个挑战，而且是更大的挑战。
是的，所以反馈渠道对我们非常重要。但我们也会收到大量反馈。比如，我自己过去通常会这样开始早晨：泡一杯咖啡，然后查看反馈渠道，挑出一些内容，想想如果我有一段亲自构建的时间，哪些事情也许能帮上忙，或者我能发现哪些缺口。这是我过去每天早上都会做的事。大概一两个月前，我们推出了 routines，这也彻底改变了情况。现在我只需要设置一个 routine，它就会自动帮我完成这些事情，然后……
以前我可能只能生成一些提示词，但现在有了 routines，感觉就像让一个智能体帮我生成提示词和 PR。比如，其中一个任务是：‘持续关注这个反馈频道，看看有哪些主题。’这样我醒来时，就能看到一份很好的总结，甚至还有一些我可以查看和审阅的 PR。反馈来自哪个反馈渠道？
这些反馈来自电子邮件、Twitter，还是各种来源的组合？
我们的反馈渠道确实很多：有大量来自内部广告的反馈，也有电子邮件和各种频道。实际上，只要有人给我们反馈，比如朋友联系了我们，或者有人在 LinkedIn 或社交媒体上反馈，我们都会把所有这些内容发到 Slack 里。我们当然还有合作伙伴渠道，所以不同来源都有不同的渠道。但这就是为什么我需要 Claude 帮我掌握全局，因为涌入的反馈实在太多了。
明白了。好，这很有意思。这是你建立起来的一种工作方式，用来掌握所有正在发布的东西：一种介于每日仪式和 routine 之间的做法。作为管理者，你会查看大家对当前 Claude Code 和 Cowork 状态的看法。以前可能只是说：‘有人去修这个，有人去修那个。’现在则是：‘这是能修复这个问题的 PR，来看看。如果你愿意，我们就准备好发布了。’很棒。当然，我想对很多人来说，代码审查也是一个重大挑战。我猜 Claude 也在做大量代码审查。最近你有没有找到什么方法，让团队能够更快地发布他们确信质量很高的东西？
是的。老实说，想到我们去年甚至还没有 Claude Code 代码审查，就觉得很疯狂。说到瓶颈，人工审查者确实曾经是一个非常、非常大的瓶颈。对于那些重要、需要深厚领域专业知识的部分，我们当然仍然要确保由合适的人来审查。但对我们有帮助的是，越能自动化地检查‘什么才算好’的框架，就越有帮助。Claude 在你给它一个用于验证的框架时表现得非常好。我之前提到过，我们最近刚刚给 content design 加入了一个 skill。
这也是为什么我认为，如果你有规格说明，就应该把它们签入代码仓库，然后确保规格说明也经常随着代码更新。我发现，只要你有一份说明‘什么才算好’的标准，就应该把它放进代码仓库。这样，代码审查就能确保实际结果仍然符合你最初设定的目标。
基本上，这就是测试驱动开发的演进。
是的。说到 TDD，我记得那曾经是一件大事。天哪，也许是在 2000 年代：先写测试，然后确保测试失败，接着再写代码。原则上这真的很好，但我记得自己有点挣扎，因为那感觉几乎像是必须先吃西兰花。我当时想：‘啊，你得先写这个测试。’而我从发布产品和构建产品中获得了很多兴奋感。所以很有趣，我在 Claude Code 上修复的第一个 bug，就是我记得自己问 Claude：‘我想做测试驱动开发，帮我先写测试，确保它失败，然后我们再进行修复。’
然后我们真的做了修复，接着测试通过了。过去生成测试只是我记得自己不得不付出的一项额外成本，但现在它已经自动化了。你甚至可以重新审视那些已经存在了一段时间的原则，而它们现在可能反而更加高效，只因为你有了能够替你完成更多工作的模型。
是的，这太不公平了。它就是先替你写测试。
说到构建者，我很喜欢你演讲中的一张幻灯片，也想问问你招聘什么样的人，以及你看重什么。所以我来读一下你当时写的内容，也想听你进一步展开。你现在招聘时寻找的两类人是：具有产品判断力的创意型构建者，以及负责困难部分的深层系统专家。
§03文稿 · 17:18
深厚的领域专业知识。比如，我刚加入 Claude Code 时，团队里有很多非常优秀的产品通才。后来我意识到，我们缺少具有系统背景的人。所以，我们确实需要更多拥有系统和分布式系统专业知识的人。我会说，很多事情归根结底都是‘信任，但要验证’。模型确实非常优秀，但仍然有很多领域需要验证。因此，凡是需要深厚领域专业知识的地方，我认为都仍然值得投入。
另一类人有点像产品梦想家。他们通常会让你觉得：‘天哪，你真的对一个产品充满热情。’他们有一个想法，就把它构建出来；然后不断查看反馈、迭代和打磨，确保产品带来令人愉悦的体验。端到端地负责一个产品，这是另一种在 Claude Code 上表现得非常好的技能。
这非常有共鸣。有一个词我不知道你有没有用过，但我想到的是‘野心’。最近无论是这档播客还是我正在做的其他工作，这个词都反复出现。前几天我和一位 10 倍工程师聊天，他说：‘以前听到一个功能想法时，比如有人说我们应该构建这个，我会说不行，那太困难、太复杂了。但现在我会说，不不不，这完全可行，我只要让 Claude Code 去做，它就会完成。’这是一次完整的思维转变。他现在意识到，问题变成了：你的野心能有多大？理论上一切现在都可能做到。
现在关键变成了：你的野心能有多大，你能把事情想得多大，而不只是面对一堆愚蠢的小功能和需要你逐个解除阻塞的问题。这能引起你的共鸣吗？你会思考这件事吗？
是的。其实我昨天刚和一位工程师交流。他本职并不是移动端工程师，但我们确实需要更新一个功能，让它也能覆盖移动端。他做得非常出色。他说：‘你知道吗，因为有了 Claude，我现在有了一个合作伙伴。’你可能会想：‘等等，我不是 Android 专家。’但多亏了 Claude，他确实可以把这个功能做到移动端界面上。所以这非常有共鸣：它已经把每个人能做到的事情推到了能力上限。
沿着这个思路继续谈。随着这个角色以如此疯狂的方式发生变化，有些人如鱼得水，有些人却非常沮丧、不开心，在抗争、抵制。那些表现得非常好、适应变化并从中受益的工程师，与那些在工程领域甚至工程领域之外感到沮丧、日子很难过的人相比，你看到了哪些共同点？
我会说，成长型思维真的非常有帮助。其实在 AI 工具出现之前，我就发现它极其有价值。我真正理解成长型思维的含义，是在从微软转到 Meta 的第一年。那就是不断学习的概念：曾经帮助你走到今天的东西，今后可能不再继续帮助你。但这确实很难，因为我们每个人都是通过某种特定的方式行动或工作，才走到现在这个阶段的。所以有时你会害怕：‘等等，我一直都很成功，你现在却要求我改变那些让我成功的东西。’
所以我会说，成长型思维真的、真的对我很有帮助，我也观察到它对其他人同样有帮助：始终带着好奇心主动投入，并且始终能够学习。至于沮丧，我有时也会看到一些恐惧。我的建议是，至少在生活中我就是这么做的，因为我们每个人都有恐惧。恐惧当然是一种进化机制。我没有研究人类学，但我觉得这很合理，对吧？它帮助我们生存下来，不被更大的捕食者吃掉。
但对于任何让你感到恐惧的事情，我的建议都是主动靠近，然后问自己：‘我能做些什么？哪些事情在我的控制范围内？’因为有时沮丧来自恐惧，以及一种‘可是这一切都不在我的控制范围内，它正在发生在我身上’的感觉。所以你可以想一想：哪些事情在你的控制范围内？与其觉得事情发生在你身上，不如想想它是否正在为你发生。然后，你能做些什么、改变些什么？我觉得这很有帮助，因为恐惧本身已经很难受，再觉得一切都失去控制，就会特别沮丧。我记得我当时在，实际上我在高中时……
有趣的是，回到 IBM 那段经历，我在高中时其实没有进入计算机科学或工程领域。我真的很想成为一名视觉艺术家。那已经是很久以前的事了。当时电脑非常昂贵，所以我甚至没有电脑可用。第一次能够使用电脑，是我上高中九年级的时候。我甚至不知道现在高中是否还会这样：我的高中有打字课，你去上课只是为了学习如何在键盘上打字，并且变得非常熟练。那是我第一次接触电脑。接下来的课程可能是一些 HTML 编程。总之，
我之所以爱上它，是因为我喜欢艺术中的创造过程：如果你有一个想法，就可以去创作并讲述一个故事。后来我意识到，电脑和编程也能让我做到这一点。于是我努力快速补上所有科学课程，以便进入大学。但我当时有一个恐惧：我该怎样负担工程学院的学费？这是一件完全未知的事。我在安大略省长大，所以很感激自己知道安大略省有一个学校援助项目，好像叫 OSAP，我对此非常感激。但我不知道它会承担我的学费或其他开支中的多少。
那笔援助究竟能覆盖多少学费和开支，我并不知道；而且距离入学还有大约一年。我记得自己想：‘好，我能做些什么？’恰好这时，加拿大国家银行在我们高中张贴了一张传单，说他们要招聘高中生实习生担任银行柜员。我记得当时想，这个机会虽然当然只会支付最低工资，但或许能成为我的救命稻草。不过很有趣，我在高中最讨厌的课程就是会计，所以我也不知道自己是否能胜任。但我还是报名去做银行柜员。
结果这是一个非常好的决定。我整个夏天都在工作并存钱，后来还能够在周末继续做银行柜员。也就是说，我周一到周五上学，然后疲惫地去做银行柜员。这最终成了我的救命稻草，让我能够支付所有的学校开支。我们刚才还谈到 2000 年互联网泡沫崩溃，当时公司招聘的实习生变少了；实际上，我继续做了两年的银行柜员。所以，那是我觉得自己能够采取、并且在控制范围内的一个行动，用来对抗……
我对这条道路的恐惧：如果我真的要走上这条路，我甚至不知道自己是否负担得起上学的费用。所以我的另一个建议是，面对成长型思维，以及由不确定性带来的沮丧或焦虑，看看是否有一个在你控制范围内的行动，你可以采取它。因为我觉得有句话说得很好：‘如果你不害怕，你会做什么？’这一直是我最喜欢的两件事：如果你不害怕，你会做什么？以及偶尔做一些吓人的事，因为我们通常就是这样成长的。
我发现，当你在自己的工作中已经非常优秀、非常专业时，你往往处于最高效的状态。但你要怎样继续成长？就是去做一些以前可能不会做的、让你害怕的事情。你会经历一个低谷，因为你需要学习，但这正是你继续推动自己学习的方式。
我在这档播客中引用最多的一句名言，可能就是所有名言里最多的：你害怕的洞穴里，藏着你所寻找的宝藏。
我喜欢这句话。
§04文稿 · 25:32
而且确实如此。我忘了是谁说的，但最可怕的事情往往就像一个指南针，指向你应该去做的方向。我要借用你的名言。请便。你知道，当然不是所有可怕的事情都要去做，比如别从悬崖上跳下去。但在职业选择上，这通常可能是一个不错的选择。沿着这个思路继续，我知道有一件事对你很重要，也是你会思考、我同样会思考的事情：两类人之间正在形成一道鸿沟。一类人拥抱 AI、表现出色、做得非常好，另一类人则没有这样做，而这……
对于那些可能在这个正在形成的新世界里掉队的人来说，这是一个可怕的时期。我知道你花了很多时间和小企业相处，帮助人们学习如何在工作中使用 AI 是你的重要热情所在。谈谈你是如何看待这件事的，以及我们或许应该思考些什么，才能帮助人们不至于掉队。是的，我很喜欢这个问题。
这是我非常热衷的话题之一。正如我提到的，我在加拿大长大，但我是小时候才搬去加拿大的。我出生在香港，当时不会说英语，而我的父母必须一直工作。所以，我的外婆，也就是任何人都能拥有的最好的外婆——我知道每个人都会觉得自己的外婆最好，但我真的非常幸运，拥有一位最好的外婆——她和我们一起搬家，只是为了在我父母工作时照顾我。但我们两个人都不会说英语。我通过上学、和同学交流，学会了说英语。当我想到我的外婆时，我觉得这对她来说一定非常……
孤立无援。她身处一个陌生的新国家，而且当时那里还没有现在这样适合步行。但我记得有一年夏天，我们碰巧找到了一家小小的毛线店，店主也会说粤语。于是那年夏天，我们每周都会去这家毛线店，我的外婆在那里找到了自己的编织圈。我想我也就是在那里学会了类似 macramé 的东西。顺便说一句，我觉得 macramé 正在重新流行起来。看到 macramé 重新流行总是很有趣。Macramé，我觉得是的，这个消息你可以先在 Lenny 的播客听到。但那大概就是我产生这种热爱的地方：我当时想，哇，这家小企业创造了一种美好的社区感。
我也非常幸运，和所有我喜欢的小企业都成了朋友。所以我的热情大概就是这么来的。后来事情是这样的：我用 Cowork 处理自己公司的差旅报销。我不知道为什么，我真的非常不喜欢做企业报销。但当我使用 Cowork 时，感觉就像魔法一样。我想，这些我不喜欢做的事情，Cowork 都在替我完成。然后我想到：等等，我的朋友们，尤其是小企业主，真的都非常辛苦。他们工作极其努力，而且通常有时只能在非常低的利润率下经营。所以我想，
如果 Claude Cowork 能这么好地帮助我处理一点小小的企业差旅报销，那对它来说会是巨大的机会。因为我有时看到朋友坐在吧台边，面前堆着一叠账单，而他们做的全部事情就是开票和报销。我觉得其实没有人真正喜欢做这些。所以事情就是这样开始的。后来我记得自己帮助其中几个人完成了入门流程。看着他们走过我们的入门流程，也让我非常谦逊，因为他们确实发现了一些很好的 bug。那真的是双赢。不过这对我来说也很有趣，因为他们使用 Cowork 的方式超出了我的想象。我之前一直只关注于它处理 PDF 和发票有多么出色，而……
我的一个朋友经营两家餐厅，她说：‘天哪，我有一个文件夹，简直像一个杂物抽屉。它基本上就是我们的文档文件夹，变成了各种文件的杂物抽屉；下载文件夹也是一样，就像厨房里的杂物抽屉。我知道里面有几张菜单，但找不到它们。’我说，那就问问 Cowork。于是我们让 Cowork 访问那个目录，它找到了菜单。然后她又以一种非常独特的方式使用它：‘我想确保自己的价格对本地人和游客来说都合理，所以 Claude，请看看这一地区同类菜系的价格。’
它返回了非常酷的结果，几乎就像一份市场分析。她又说：‘我最近刚去过西雅图的那家餐厅，那里挺不错的。’所以我每次都能学到东西，而他们也一直给我很好的反馈。
所以问题就是：我们怎样把这些推广给所有人？因为正如你所看到的，很多人会说‘我没时间做这个’，或者‘我讨厌它，我只想忽略它’。我们应该通过对话来做吗？只是谈论这件事、分享案例吗？你觉得怎样才能为我们所有人，尤其是你的听众，在这个问题上真正带来一些改变？
你的听众可能已经非常 AI 上头了。如果他们的社区或家人中有人还没有这样做，我会从一个问题开始：有没有什么事情真正让你觉得 AI 工具对你的生活产生了有意义的改变？然后看看这能不能成为一次对话的起点。因为对我来说，AI 是一种工具。它又回到了光明与黑暗的比喻，我完全理解令人沮丧的部分，但我也觉得知识就是力量。你必须学会使用这些工具，因为它们实际上可能成为光明与黑暗这个等式中的光。所以，我希望大家都能帮助做的一件事就是……
不管是社区成员，还是一家你很喜欢的企业，都可以问：‘嘿，你有没有……’开口其实有点尴尬。我第一次联系朋友时就记得这一点，因为我平时不太和他们谈自己的工作。我会说：‘嘿，我最近在做一些 AI 相关的工作。我能不能……’即使对我来说，这样做也很不自然，因为我会想：‘嘿，我能不能给你看看 Cowork 能做什么？’但最后我们玩得非常开心。所以我很希望这能成为一个很好的对话起点，因为我只是想确保我们持续分享知识，并且……
让工具变得公平可及。否则我担心，鸿沟会越来越大。
我也这么认为。我发现，正如你所说，分享使用案例非常有力量。前几天我还用 Cowork 填写我儿子的夏令营表格，然后把这件事分享到了 Twitter 上。很多人都说：‘哇，我没想到还可以这样。’
就是这些你不会想到 Cowork 和 Clockwork 能做到的小事情。
沿着这个思路，说到 Cowork，如果你想想看，Anthropic 一直非常早地发现了这些巨大的机会，而且领先于其他所有人。比如编码。你们很早就意识到这是一个巨大的市场，领先得太多了。不管这是有意为之还是无意为之，当时都让人觉得：哇，这或许是历史上最大的全新商业机会。然后 Cowork 也是一个很好的例子：只要拥抱知识工作，我们把所有知识工作都解决掉，为什么不呢？你们再次远远领先于其他人。另一个方面是，你们似乎很早就重视模型的个性。
你们很早就意识到，模型的个性不仅对体验很重要，对模型的智能和成功也很重要。你觉得 Anthropik 以及这些团队做了哪些不同的事情，才让你们能够发现这些机会，并在其他实验室之前放手大干？
我没有在其他实验室工作过，所以不确定其他实验室是如何运作的。但我可以分享的是，在 Claude Code 团队和 Cowork 团队，我们也一直关注潜在需求。对于编码这个使用场景，我们非常幸运，因为很多智能体都是我们自己的第一批客户，我们能够获得非常快速的反馈。我想，潜在需求一直是很重要的一点。比如 Cowork，我们知道很多并非编码员的人正在使用 Claude Code，于是我们会问：能不能让这段体验变得更好？我想，这一点不仅在 Anthropic 有效，在我做过的所有不同产品中也一直对我很有帮助。
§05文稿 · 33:20
有趣的是，你提到了 Claude。因为小企业是我的热情所在，我拜访了几家小企业之后，我们最终推出了 Claude for Small Business，这很酷。不过这完全不是我的功劳，所以我不想邀功。我只是注意到，当我和他们一起工作时，他们会问我：‘它有这个插件吗？或者那个插件吗？’我会想：‘我觉得有。’然后我们还得去搜索。现在，Claude for Small Business 把这些东西都打包在了一起。在 Cowork 里面，你只需要打开这个小开关。还有一支很棒的团队，他们一直在和小企业进行 Cowork 会话，可能就是他们发现了：‘嘿，这里可以提高效率，或者让体验更好。’
所以我会说，不仅要持续倾听你所负责产品的反馈，不断迭代，努力创造令人愉悦、可靠且高质量的体验，也要留意正在出现的其他使用场景，看看能不能让那些体验也变得更好。软件领域有件事让我很感兴趣：客户会以你没有预想的方式使用产品，无论这种使用是好是坏。
所以最好的方法确实就是不断迭代、学习，并且和反馈保持紧密联系。
‘Weight and demand’。这个说法在这档播客里已经出现过很多次了。这里面确实有点东西，也许真的有点东西。所以本质上，就是密切观察那些你没有预期过的行为，或者正在自然出现的行为，然后在这些方向上大力投入，探索它、构建一些很棒的东西。是这样吗？
还要形成一个假设。比如，当你看到人们为了让某件事运转而绕了很多弯路时，你能不能把它变成一种更加顺畅、更好的体验？
回到你们团队的工作方式。你们站在可能性的前沿，而工程师这个角色本身也发生了如此巨大的变化。我想知道，你认为工程领域接下来的前沿会是什么？是智能体组成的集群，还是别的东西？工程师工作方式的下一次重大转变是什么？你们已经在研究或实施它，还是它才刚刚开始发生？
我认为我们正在更多地转向异步工作。就像你说的智能体集群，这也是 routines 如此有趣的原因。以前我会同步地输入一个提示词，然后可能异步地启动不同的提示词；但现在我可以设置一个 routine，让它为我生成这些提示词。所以抽象层级似乎一直在往上提升。我真希望自己有一颗水晶球，能看看这最终会变成什么样。不过，一年后我们再来回顾这件事，应该会很有趣。
不，我想多听一点。这非常有帮助。请帮助我们理解，routines 是什么？你说的同步又是什么意思？你输入一个提示词，它就立即运行吗？具体谈谈它的工作方式。
好的。routines 就是这样使用的：你还记得我之前说过，我过去每天早上都会泡一杯咖啡，然后让它帮我查看这个 Slack 频道吗？现在，我设置了一个 routine，让它每天早上特定的时间运行，并告诉它：‘对，就是这样。’然后它实际上就能代表你启动智能体。这和以前不同，以前你可以设置 cron job 来自动化这些事情，但现在你可以说：‘看看这些反馈，如果你发现其中一些 bug，有哪些润色修复是你可以完成的？’
然后它就会启动任务。等我醒来时，我会发现有一些 PR 可以审阅。过去，即使我可以启动不同的智能体，我仍然需要思考：‘现在我该拿这些信息做什么？’现在则是更高层的抽象：我可以编写一个 routine，让它基本上替我输入提示词，去启动不同的智能体。所以我认为，我们会越来越多地转向这种……
异步工作方式。很有意思。也就是说，作为管理者，你每天有一些固定要做的事情。你的意思是，你可以设置一些提示词，让它们每天检查那些原本需要你亲自做的事情：项目进展如何？什么事情落后了？我应该解除什么阻塞？谁遇到了困难？我该怎样修复或改善某些细节？你描述的想法就是，把这些几乎每天都要做的管理工作写下来，让 Claude 基本上替你完成，然后告诉你：‘我正在做这些事，这些是需要你审阅的内容。’
然后，在某个阶段，它甚至会获得更多自主权。你会说：‘你知道吗？放手去做吧。’比如验证工作做得非常好，那就放手去做吧。
我明白了。所以你给它一点自由，让它完成更多这类工作。这太有意思了。说到‘放手去做’，这让我想到一件事。我本来没打算谈这个，但我刚看了 Tyler Cowen 的一场精彩演讲，内容就是正在发生的这些变化。不知道你是否了解 Tyler Cowen，他非常聪明，是一位经济学家，也主持一档播客。他提到，在这个世界里表现最好的人都有一个特点，他用的词是 initiative，也就是主动性。他们有主动性。人们还会用另一个词：agency，能动性。这是否会让你想到什么？人们经常听到这种说法：那些看起来表现最好的人，往往采取最多的主动行动，最积极主动，也拥有最大的能动性。
这会让你想到什么吗？你觉得人们可能需要思考或改进些什么？
这就是能动性。我很喜欢 agency 这个词，它正是我们在 Claude Code 和 Cowork 团队真正重视的东西。不过有趣的是，我说它和高标准放在一起，因为对我们来说，事情是这样的：这里有一个问题，团队里的每个人都有解决这个问题的想法。所以我们强调高能动性；但我们也会说，高能动性同时意味着高问责。关键是要确保大家有自由去构建、去发挥，但同时也要明确：对此承担什么责任？这又回到了一个问题：你正在尝试解决什么问题？你的假设是什么？
所以我认为，这种平衡对我们团队真的很有帮助。它们几乎就像同一枚硬币的两面：能动性和问责。
能动性中一个非常重要的元素。好，大家都在各自做事，但你们实际上完成了什么？打破了什么？沿着这个思路，最近似乎出现了一个氛围变化：以前是 token maxing，不管怎样先疯狂使用，尽可能多花 token，看看能做到什么；现在则开始问，等等，我们究竟从中得到了什么？成本是多少？投资回报率是多少？有趣的是，Boris 之前在 Meta 负责生产力提升，他的工作就是衡量生产力提升。还有关于代码行数、代码变更的那条推文。现在有一场很有意思的讨论：我们到底该如何衡量生产力提升，以及 AI 工具投入的投资回报率？
你们在 Anthropic 工作，可以免费使用 token，显然拥有不公平的优势。基于这一点，你们对于如何衡量当今世界里工程师的投资回报率，学到了什么？
工程生产力是一个非常有趣的话题。因为我记得，Boris 也提到过，我们一开始会从代码行数入手。然后这代表产出量。后来我记得出现过一次争论：代码行数这个指标并不可靠，因为有一位工程师产生了惊人的代码行数，但他只是拿了一个库，然后把它移植过来并提交了。于是我想，也许应该看重要的代码行数。但问题又来了：如果我们更新了框架，生成的代码变少了，但产出仍然相同呢？于是我又想，好吧，也许应该看 PR 的落地时间。但它……
§06文稿 · 40:59
很有意思，因为无论你选择什么指标，我的建议始终是：首先看产出；这个产出是否真的朝着结果前进？token maxing 有点像我们过去使用的代码行数，但我更关注的是：我们到底想完成什么？我很喜欢另一句话：不要把忙碌误认为进展。如果你衡量的是工具使用量，那你衡量的是行动，但它真的让你想要的最终结果变得更好吗？所以我会尽量拉远视角，关注我们试图解决的问题是什么，以及怎样才是衡量它的好方法。相比某种抽象的生产力指标，我们主要关注这些。
不过除了指标之外，尤其当团队里越来越多的人采用 AI 工具时，我会建议领导者进行一次倾听之旅。比如听这类播客，当然也要重点和高级工程师交流。听听他们觉得什么有效、什么无效，以及我们怎样才能把它做得更好。因为他们也会帮助你把这些经验复制并推广到整个工程团队。
有时正是在这些对话中，你会获得一个突然冒出的想法，也能形成非常好的共享学习，而不只是查看指标仪表盘。关于指标，我学到了一些很好的经验：如果有一个指标，你确实可以围绕它持续优化，那非常棒。但要始终记住成长型思维的核心问题：它是否仍然在帮助你？这个指标是否还在推动你原本想要的结果？我有一个有趣的例子。在 Facebook Marketplace 早期，我们按地区逐步上线产品，并且非常希望在扩大范围之前，先确保产品带来令人愉悦的体验。我记得早期我们会关注卖家的数量，并且……
上线第一个地区后，我想：为什么这个地区的卖家数量这么少？但实际上，人们正在找到自己要找的商品，而这才是我们的目标，也就是帮助人们找到需要的商品。后来我意识到，这个地区的卖家数量虽然不多，但有一些超级卖家。可我们在扩大范围前设定的第一个门槛，本来会非常重视卖家数量。我记得我们很快讨论了一下：‘等等，这……’
这又回到了一个道理：人们会以你没有预料到的方式使用产品，所以要不断调整、迭代和学习。于是我们更新了指标：不能只看卖家数量，因为这个指标没有把超级卖家考虑进去。所以我的建议是，无论是生产力指标还是产品指标，都要持续关注并确保自己没有戴上眼罩，盲目追随一个过去有意义的指标。有时环境变化得非常快，甚至指标本身也需要调整。
这又回到了你分享的流程：让 Claude 观察每位工程师发布的所有 PR，然后不要只关注指标，而是围绕这些 PR 产生对话：它们带来了什么影响？发生过哪些 bug？这是一种非常有力的方式，可以理解这位工程师正在做什么。太棒了。回到速度、质量和影响这个问题：对于如何平衡这些因素，你还学到了什么？代码生成的速度如此疯狂，怎样才能掌握质量和影响？对于那些试图管理每天发布的所有 PR 的其他团队，还有什么可能有帮助的经验吗？
每天发布这么多 PR。
我会说，这正是我们想继续做得更多、也做得更好的事情：主动保障质量。尤其是在质量方面，要明确哪些体验是关键的，并确保自己能够观察它们随时间发展的趋势。说到指标，这些正是很适合进行长期趋势观察的内容。在质量方面，我们发现，越主动地做这些事，就越有可能更早发现质量问题。这一直是我们非常关注的一点。
我开始提出这样一个概念：什么是 bad，什么是 sad。bad 是非常严重、无法恢复的错误；sad 则是某种痛点，但还可以恢复。有趣的是，当许多 sad 叠加起来时，通常可能会变成 bad。即使只是从这样一个高层框架开始，也很有帮助。否则，当你面对仪表盘上的加载时间或其他指标时，如果同时处理许多不同的产品服务，就很难判断：这个数字到底好不好？所以对我们有帮助的是，不只看……
原始的性能或可靠性数字，还要有一套框架来定义我们认为的糟糕体验，并确保我们专注于解决这些体验，同时关注哪些地方出现了 sad。
这对我们有一点帮助。是的，我喜欢 bad 和 sad 这两个说法。所以它们有点像阈值：这是 bad，意味着情况很严重。你们衡量的是性能、故障，还是其他类型的事情？
比如，我们允许每个团队自行负责。说到能动性，既然 bad 是非常严重、无法恢复的错误，我们就让每个团队针对自己负责的各个界面或服务，定义什么属于 bad。比如在 CLI 中，可能是崩溃率。崩溃就很糟糕，因为你会丢失工作。
嗯。
而 sad 可能是：‘它是不是在闪烁？’这种问题也许可以恢复。但我们让每个团队自己定义，这一点很有意思，因为以前每个界面都不同，我们会有各种仪表盘，却很难拉远视角，理解整个体验的主题是什么。所以，正如你所说，我们赋予每个团队很高的能动性，让他们定义什么属于 bad、什么属于 sad，以及每个团队想要达成的目标。
我听到的主要结论是，掌握质量的最佳工具之一就是监控和测试，而不是花更多时间做审查。这很合理，因为发布速度实在太快，根本不可能完全靠人工跟上。这也几乎对应了一个想法：让智能体形成闭环，使它们能够自行发现问题。它们知道成功是什么样子，然后说：‘很好，我们自己修复。’所以一个很有意思的结论是：更多投入测试和评估。我想这也是其中的一部分，然后持续监控故障、速度以及类似的问题。
没错。
有一件事我想它应该是公开的。我听说你们有一个仪表盘，追踪大家说 F 开头脏话的次数，也就是他们有多生气、多沮丧。这个说法好像很有趣，我忘了它具体叫什么。
是的。实际上我记得，那是去年九月的事。那时我们都感受到了一些沮丧，团队里有位工程师说：‘我们也许应该追踪脏话。’我想，哦，这主意不错。我记得自己当时刚加入团队，正好参与了那次很有趣的讨论。所以，这件事确实很有意思，也正因为如此，评估很难：它又回到了用户体验，以及我们怎样确保体验令人愉悦、减少沮丧。但没错，脏话仪表盘是一个很有趣的东西。
本期节目由 Mercury 赞助。Mercury 提供与众不同的银行服务，深受超过 30 万名创业者喜爱，如今又推出了 Command。我成为 Mercury 的客户已经六年多了，从未想过离开。Mercury 基本上就是由产品人而非银行家打造的银行：他们让开具发票、转账以及为团队成员设置虚拟卡变得非常简单，甚至可以说很有趣。你的银行有 API、终端原生 CLI，或者支持 AI 的 MCP 服务器吗？我想没有。而就在最近，他们推出了 Command，这是直接构建在 Mercury 中的对话式界面，就像你的财务运营员。我一直在用 Command……
§07文稿 · 49:04
来转账、了解我在哪些类别上花钱最多、分析现金流。就在今天，我还用它查出了过去一年从某个特定赞助商那里赚了多少钱。我只需要问：‘过去一年我从 X 那里赚了多少钱？’十秒钟后就得到了答案。真的太酷了。访问 mercury.com 了解更多信息，并在线申请，几分钟内即可完成。Mercury 是一家金融科技公司，不是受 FDIC 保险的银行；银行服务由 Choice Financial Group 和 Column N.A. 提供，成员受 FDIC 保障。
FDIC。
回到你的工作方式，以及你在这个疯狂的新世界里找到的工作方法。我听说你实施了几件很独特的事情，它们可能是团队运作方式中比较特别的做法，而且似乎对你很有效。一件事是让每位管理者都先从 IC 做起，然后每位管理者还必须继续兼职做 IC，也就是一种‘亲自上阵的教练’方式。谈谈这种做法，以及它为什么在今天的世界里如此重要。
我很喜欢这种做法。有趣的是，我刚加入时，因为我有很棒的招聘合作伙伴，我注意到，我们一直在谈成长型思维，原因就在于环境变化得太快了：过去有效的东西，今天可能已经不再合理；而今天合理的东西，明天也可能需要改变，对吧？我必须不断提醒自己这一点。刚加入时，招聘人员会说：‘好，我们有几个管理者职位。’我会想……实际上，这来自我和团队所有成员进行的一次倾听之旅。我听到很多人说：‘我非常珍惜这种能动性，但怎样才能确保优先级得到明确？’所以我通过这些反馈意识到……
同时，还有一些很好的反馈：要确保审查层级不要太多。有些人可能来自其他公司，他们提供了很好的意见。然后我想，作为一名领导者，如果你先从 IC 做起，不必一开始就承担支持他人的压力，会怎么样？支持他人是一项非常沉重的责任，虽然我认为管理者应该承担它，但在你承担全部责任之前，应该给自己留出亲自构建的时间，深入接触代码、学习代码库，或者学习产品，不管具体对象是什么。这并不……
老实说，我做的 PR 通常是……但对我来说，更重要的是它让我保持在工作流中。因为我们对 Cowork 和 Claude Code 做了如此多的改动，即使是我自己做 PR，也不太重要我具体修复了什么，更重要的是我每天都在使用产品，保持这种接触。虽然各种指标和数据都很有用，我也确实会查看那些仪表盘，但作为领导者，如果你不是每天都在亲身体验自己的产品，有时就会失去对产品触感的联系。不过说回管理者这件事，我认为应该给新加入的管理者留出时间，让他们深入了解工作，在支持他人之前先做到这一点，然后他们……
最终确实会和团队建立非常好的关系。否则，作为管理者，你有时可能刚加入一个新团队，就立刻想：‘我得开始管理了。让我拿出管理者工具箱，做一些管理者该做的事。’但如果你给自己一些时间，先不用担心那些事情，真正去了解作为团队中的工程师和队友是什么感觉，这也会非常有助于建立关系。至于使用产品，我认为这同样很重要。有趣的是，我加入过的每个团队，不管是 VR、智能眼镜，还是 Instagram，通常当我刚加入时，
总有人会对我说：‘嘿，你真的在使用我们构建的东西，我很喜欢这一点。’看到你给出用户反馈，会让人耳目一新。所以我认为，对领导者来说，这也是一种亲身体验团队工作成果的方式。
人们可能没有意识到，在加入 Anthropic 之前，你在 Meta 管理着一个大约 500 人的组织，对吧？然后你去了 Anthropic，基本上从那个职位转成了 IC 工程师。
一开始确实是这样，虽然持续的时间很短。这其实发生在我从微软转到 Meta 的过程中。我在 Meta 面试的是管理者职位，但至少在第一个季度，我也做了一名 IC，因为我真的想了解成为 Meta 工程师是什么感觉。在那之前我在微软工作，在微软磨炼了工程能力，所以我熟悉所有代码库、工具和语言。但最初那几个月非常有价值，让我真正了解作为 Meta 工程师发布产品是什么样的。而且这也很有趣。我们有时会忘记这一点。不过，顺便说，这也是我喜欢 Claude Code 的原因。
我上一次发布生产软件大概是在 Meta 的 2017 年。之后每年我都会大量 dogfooding，也会用它来帮助自己检验产品质量。但我已经很久没有发布生产软件了，部分原因是我不想把事情搞砸。我总是害怕：如果我做了什么，然后引入了 bug 呢？我有没有正确验证一切？我会不会浪费别人的时间？毕竟工具流程也会发生变化。但我记得在 Claude 的第一周，我一开始几乎又要按惯例去做：‘让我去见见所有工程师，请他们喝咖啡。’然后我想：‘等等，等等，等等，让我先问问 Claude。’于是 Claude 成了我非常好的入门伙伴。我对代码库感到好奇，就向它提问；它也确实帮助我做自动化测试。但我仍然想做一些手动测试，于是我问 Claude：‘帮我想想，我应该怎样手动测试这个功能，才能确保覆盖所有情况？’
这些事情让我有了信心：好，我可以再次在这里发布产品。后来我逐渐重新适应了这种工作方式。实际上，很多朋友都联系过我，他们已经做管理工作一段时间了，他们说：‘多亏了 Claude，我又开始写代码了。’所以总的来说，对我这个领导者而言，重要的是确保自己确实在使用团队构建的产品。
很多朋友都联系过我，他们已经做管理工作一段时间了，说：‘多亏了 Claude，我又开始发布代码了。’所以总的来说，对我这个领导者而言，重要的是确保自己确实在使用团队构建的产品。
很有意思，你作为工程领导者管理着一支最能改变工程师角色的团队。这是一个非常‘元’的角色：工程师的工作正在因为你们构建的软件而发生转变。
沿着这个思路，我想问：你是否担心工程师因为不再真正写代码，编码技能会逐渐萎缩？这件事重要吗？你会思考它吗？这是一个大问题吗？
这件事很有意思，因为我们团队确实讨论过：有没有什么东西被我们错过了？正如你说的，我一直会思考新人入职和熟悉工作的过程。比如 Boris，他早期是亲手编写代码的，当然现在已经不再这样做，但他从那段经历中获得了知识，因为他经历过亲自写代码的时代。所以对所有加入的工程师，我都会说：确保你花时间去理解自己完成的工作、架构和改动。这又回到了‘信任，但要验证’。也许有一天这不再重要，但按照我们现在前进的速度，我仍然认为，理解很重要。
你要不断深入了解自己依赖的那一层。对我来说，这意味着始终花时间了解自己的依赖关系。这样，当依赖发生变化时，你会更有意识，也不会错过利用依赖变化的机会。所以我认为关键始终是不断深入查看。但我们在 Claude Code 团队还发现了另一件有趣的事：过了一段时间后，这可能开始变成一种孤独的体验，因为我们都开始大量只和自己的智能体一起工作。
所以最近我们开始组织结对编程午餐。我们还发现，Claude Code 团队里的每个人都会使用 Claude Code 和 Cowork，但每个人使用这套工作流的方式都非常不同。于是我们发现，哇，进行结对编程时，我们真的能从彼此身上学到很多东西。另一件事是，我们也会确保一起安排亲自构建的时间。比如黑客马拉松就是我们非常喜欢做的另一件事，它能确保我们作为团队保持互动。
§08文稿 · 57:15
这是一个很好的观点：因为过去是各个工程团队一起构建代码，有人负责后端，有人负责前端，有人负责 iOS 应用，后端可能还有很多人一起工作。但现在有 10 个 Claude 并行运行，分别完成这些事情。想办法让工程师保持联系，确实是个很好的主意。这几乎像结对编程，但又不是；更像孩子成长时的平行游戏：你们坐在彼此旁边，各自构建自己的东西。但仅仅观察其他人如何构建，你就发现这非常有价值。
你发现观察其他人如何构建确实很有价值。
我们的工具链也在快速变化。但这对我来说很有意思：团队里的每个人都以不同方式使用 Claude Code 和 Cowork。所以每次我观察别人工作时，自己也会学到一些东西。
你怎样管理那些过度痴迷于优化自己工作流的人？你会不会对他们说：‘没关系，继续做就好？’
你知道，我没有在团队里看到太多人这样。我觉得大家都非常兴奋，要么是因为我们认为某个架构更新能够提高可靠性，要么是因为某种产品体验。所以我们经常谈论这些。我们不会过度……午餐时这样聊天很有趣，但我不认为我们会过度优化，因为没有……没有完美答案，而要做的事情太多了。
随着这个角色发生变化，有些东西出现了，有些东西消失了。我很好奇，在这个新的软件工程世界里，还有什么被丢失了？我以前是一名工程师，不知道你是否了解这一点，我做了 10 年工程师。那时坐在那里沉浸在编码状态中非常有趣：‘哇，它能运行。看，它编译成功了。太棒了，我正在取得进展。’但现在你不再这样做了，只是坐在那里，等智能体把东西构建出来。对于工程师来说，这个新世界还有什么东西消失了？
很有趣，我刚和团队里的一位工程师谈到沉浸状态。你还记得过去遇到一个非常棘手的问题时，会放上音乐，然后完全进入状态吗？所以确实少了一些东西。以前最后总会有一个巨大的顿悟时刻。我记得那种感觉：你终于破解了问题，心里会说‘耶！’。这就是我们过去获得的快乐。但现在我觉得，我们从产品中获得了很多快乐。不过我确实听其他工程师说过，其中一些最困难的部分，恰恰是他们过去最享受的部分。我还从另一位工程师那里听到过同样的说法。
所以我想，我们都在不断调整。
但我确实看到了最明显的一点，这也是我刚才提到结对编程和最近出现的黑客马拉松的原因：越来越多的人开始觉得，这正在变成一种孤独的体验。所以在……
在 Anthropic 内部，我很好奇：既然工程是目前变化最大的角色，那么到目前为止，第二个变化最大的角色是什么？在 Anthropic 内部，哪个角色和几年前相比发生了最大的不同？
所有与编码相邻的角色都在变化。产品经理就是一个例子。我知道你和 Kat 聊过，我认为 PM 的工作也发生了很大变化，因为产品经理不再受工程带宽限制，不必在有了想法之后等待工程团队有空。所以这大概是我看到的下一个发生变化的角色。事实上，当我们想做某些事情、但当时没有工程师能够完成时，我们的 PM 也会帮助我们卷起袖子，参与并推动一些功能。所以我认为，所有与编码相邻的角色都开始发生变化。但我想，这又说明了为什么……
验证很重要：当更多不同专业领域的人提交代码时，我们怎样确保每个人都有更高的信心？我也认为，我们需要继续自动化工作流中的其他部分。我们当然在编码上投入了很多精力，但接下来，设计和数据科学可能就是值得探索的领域，看看我们怎样也能改善那里的体验。
说到数据科学，我有一位做数据科学的朋友。他说，数据科学现在已经完全不同了：如今，他们的大部分工作是别人用 AI 做一些并不出色的数据分析，然后把结果拿给数据科学家，说：‘这是我做的分析，你能确认它是否正确吗？’而且一半时间它都不正确。所以这份工作已经完全变了，不再是他们以为自己想做的工作，而是一直审查这些 AI 做的数据科学分析。
这到底是怎么回事？
沿着这个思路，回到你们团队的工作方式和正在发生的变化。我想问一个由此想到的问题：现在，工程经理应该对团队有什么期待？和几年前相比，正常的、我不知道该怎么说的基线期待是什么？除了‘我们发布得更快了’，还有什么不同吗？
有意思。我认为，大多数提交都得到了 Claude 的辅助。这就是一个变化。
我之前提到过，我们有 Slack 频道收集所有反馈，也有各种仪表盘，我们会把这些交给 Claude。我认为，让工程师不断培养更强的产品判断力，是另一件重要的事。总体而言，这有助于培养非常强的产品型工程师。过去属于非工程领域的更多能力，现在也会由工程师承担。有时你过去会被卡住，只能等待跨职能合作伙伴，但现在这类阻塞少了一些，因为模型能够……
补充你作为工程师可能没有的其他能力。
所以这很有意思，它是双向的：工程师变得更加以产品为导向，并对产品的质量和成功负责；同时，每个人也越来越像工程师。是的，没错，一切都在变得模糊。我忘了是谁说过，有人问：‘如今还有什么角色？’这个人说，角色就是你所做事情的平均值，也就是你投入时间最多的事情，不管它是什么，那就是你现在的角色。天哪，我想回到你刚才说的对产品痴迷、亲身体验产品、不断使用产品和 dogfooding 的话题。我和很多与你共事的人聊过你，大家最常提到的就是你对亲身体验产品、持续使用产品的痴迷，不管你正在构建的是什么。关于 dogfooding，谈谈它为什么如此重要，以及为什么你会在团队和直接下属中灌输这种做法。
我和很多与你共事的人聊过你，大家最常提到的就是你对亲身体验产品、不断使用产品的痴迷，不管你正在构建的是什么。关于 dogfooding，谈谈它为什么如此重要，以及为什么你会在团队和直接下属中灌输这种做法。
我喜欢这样做。我认为这确实是一种非常好的方式，帮助我掌握产品的脉搏。每次构建产品时，你都有一个愿景：你真正希望创造一种体验，或者改善一种体验。所以能够做到这一点，能让我始终贴近产品的脉搏。我觉得，Visual Studio 确实是我培养这种热爱的地方。不过有趣的是，即使是 Marketplace，我也记得自己偶尔会这样做。离开团队之后，有一次我有一台 MacBook Air……
我想把它卖掉。我当时想：‘我还从来没有在 Marketplace 上卖过东西。’结果我完全没想到，刚把它放上去，就有一个买家试图骗我。这是一种我此前没有发现的新型诈骗方式。但这再次说明，人们会以你没有预料到的方式使用你的产品。尤其对领导者，甚至对团队中的任何人来说，我们每个人的生活经历都不同。有趣的是，我支持 VR 和 AR 团队时，我使用 VR 的方式总能发现一些非常奇怪的地面高度问题。于是这成了一个机会：我可以利用自己恰好拥有的良好复现环境，来帮助我们……
所以我认为，第一，这就是你如何掌握自己正在构建的产品的脉搏，而不是只沉迷于指标、仪表盘或演示文稿。
§09文稿 · 65:40
我觉得你刚才说的非常重要，希望大家听清楚：人们总会把轶事证据、具体案例与数据进行比较。而你这里说的是，作为产品领导者和工程领导者，你从轶事、从自己作为用户经历的那些具体小事中获得了很多成功，而不是只沉迷于数据。
是的。有时，这也是我能够最有效地帮助团队的方式。比如我上一次负责的是 VR 团队。当时我没有向那个代码库提交任何代码，因为我非常担心弄坏操作系统。但当时的缺口是什么？我们做了大量润色修复，我想：‘嘿，我可以利用自己的 dogfooding 时间，实际检验一下体验看起来怎么样。’所以，这也是我觉得自己仍然能够有意义地做出贡献、帮助团队守住质量标准的一种方式。
而且我发现，团队成员通常都会非常感激这一点。作为领导者，你在支持团队成员时，除了指标和其他一切，他们也都希望确保自己的工作有意义。领导者使用自己的产品，就能让大家感受到领导者仍然真正投入其中，而不是与团队相距太远。
这和你刚才说的工程师需要变得更加以产品为导向、工程师需要更多地承担产品经理职责、产品经理也需要变得更加……联系得很紧密。对工程师来说，持续使用产品就是一种实现方式。你作为用户不断使用它，就会理解产品缺少什么。
没错。如果你领导的团队很难让你直接使用产品，那就去和客户见面。无论采取什么其他途径，我认为这都很重要。每次拜访客户，我总能学到新东西。比如在 Facebook Marketplace，我们当时正试图把产品推向拉丁美洲，在智利进行测试。但它的表现一直不如我们做过的其他地区，也不如我们尝试过的其他方法。后来我想：‘好，我们去智利做一次很小的调研旅行。’我记得我们拿了一大堆 Android……
手机。我们一共只有三个人，是一个非常小的团队。落地之后，我打开这些 Android 手机，发现 LTE 连接确实比美国慢得多。我想：‘哦，在这种低速 LTE 的情况下，Marketplace 信息流甚至加载得不好。’这会成为一个多么大的增长阻碍：你甚至无法加载页面。但这再次说明，为什么持续倾听客户反馈、建立快速反馈闭环如此重要。
我想这是 Jeff Bezos 说的：如果你同时拥有数据和一个轶事，令人惊讶的是，要相信轶事而不是数据。这就是一个很好的例子。好，再问几个问题。你在演讲结束时有一张很有意思的幻灯片，列出了你正在思考、但在变化如此之快的情况下还没有解决的问题。我想读一下这三个问题，也想知道它们现在是否仍然是这三个问题，或者还有没有其他关于我们如何工作、尚未解决的当前问题。你在演讲中分享的是：我们是否仍然需要分别设立 iOS 和 Android 组织？
完全自动化的审查应该推进到多远？随着角色变得模糊，如何确保每个人的生产力都一样高？这些问题现在仍然存在吗？你还在思考其他什么问题？比如：‘好，我们需要解决这个，但还没有想明白。’
关于 iOS 和 Android，我认为我们仍然在摸索。有趣的是，说到深厚的专业知识，我们确实认为它非常重要，仍然需要引入拥有这些专业知识的人。但因为大家都在灵活承担更多事情，我们可能不需要这么大的团队规模。所以，我们仍然需要 Android 和 iOS 专家，但不一定需要规模同样大的移动端组织，或者每个平台各有一整套人员。我们还在努力寻找平衡：自己是否拥有正确数量、足够深度的专业知识？第二个问题是什么来着？
对，第二个问题是：完全自动化的审查应该推进到多远？
是的。这个问题很有意思。比如 content design 检查，我们一直在寻找一种方法，真正定义‘什么才算好’。所以验证仍然是我们需要继续思考的事情，我认为第二和第三个问题都有更多机会。但至于自动化应该推进到多远，我觉得要先看哪些地方仍然需要专家，然后不断问自己：有没有办法利用专家知识，同时也实现自动化？我们需要审视整个端到端体验，确保没有遗漏。
我认为我们目前主要从工程角度处理问题，但也要确保在体验层面，思考其他领域该如何被验证。我觉得那里确实还有很多可以做的事情。
基本上，你要怎样建立一套验证机制，确保实际体验就是你想要的体验？
没错。我认为这仍然是一个很难解决的问题。正如你提到的评估，其中一部分当然是准确性，但同时也是体验。因此，这仍然是我们正在思考的问题。
还有其他最近发生变化、需要我们重新思考工作方式的事情吗？还是说这些就是主要的问题？
我认为，随着 routines 的出现，以及一切变得更加异步，我们的上下文切换负担开始变得很重。我记得自己甚至会想：‘哦，我刚刚启动了……’所以我们可能还要思考另一件事：无论是对团队成员还是用户，我们怎样才能改善体验，降低这种负担？我确实看到上下文切换有些增加。
如果你有 20 个智能体在运行，就会有无休止的查看和审阅，而且你必须记得自己在每个任务中做到了哪里。这是一个非常有趣的世界。我们之前谈过思维流：对工程师和大多数人来说，长时间保持沉浸状态的情况变少了，但现在智能体可以提醒你：‘你目前在这里。’所以重新切换回来似乎更容易了，因为你不必重新学习一切，也不必重新理解代码库和架构，你只需要知道：‘好，我们正试图完成这个。’所以这件事似乎既变好了，也变糟了。
过去我会专门安排编码的专注时间，因为你需要一段完整的时间保持专注。但现在，由于我可以和更多异步智能体进行上下文切换，我发现自己确实需要重新安排专注时间，用来追上自己启动的各种异步工作。
你对这里的解决方案有什么想法吗？因为这很难。人们只想做越来越多的事情，但怎样才能避免不断进行上下文切换？这真的很难，也很烦人。
是的，我同意。确实如此。我还没有解决这个问题。
有意思。谈话过程中我想到一个问题，非常期待听到你的回答。我原本甚至没打算问，但现在这个问题非常重要：工程师岗位和招聘。你可能会以为 AI 会让工程师变得不那么必要，但另一方面，你们似乎又在疯狂招聘工程师，OpenAI 也在疯狂招聘工程师。市场对工程师的需求非常大。你觉得这会走向哪里？你怎么看待工程师这个岗位的未来？这是一个很大的问题，但请谈谈你的想法。
§10文稿 · 73:19
我想在这里分享一点脆弱。说到那些重大的开放问题，我确实认为，我们如何培养下一代是一个大问题，因为你我走上工程道路的方式完全不同。现在，当你从学校毕业时，怎样才能加速成长，同时仍然真正理解我所说的那种深入了解依赖层的过程？这是我非常大的一个问题，我希望自己有答案。但我想，对软件工程来说，也许未来会更多采用 fellowship 或学徒制项目。
这听起来有点奇怪，因为严格来说，我们已经有实习，但实习通常只有三个月，而且只是一些小项目。不过我确实想知道，我希望自己有一颗水晶球：我们怎样才能把一些东西压缩进去？也许它们将来不再重要，但我们怎样才能把我们都经历过的一些生活经验，传授给下一代构建者？
对。如果你永远不需要看代码，那新软件工程师为什么要真正理解基础设施如何运作、内存如何分配，以及所有这些基础性的东西？这是个有趣的问题。
也许模型会变得足够好，以至于这些都不再重要，你不必再担心它们。但我确实认为，深入了解那一层很重要，因为这可能是改善产品或系统的机会。问题是，怎样才能学会这些东西，而不一定要靠多年的代码输入？
是的。总得有人在某种程度上理解代码。也许有一天，我们要把某个 COBOL 工程师从退休生活中请回来：‘你还记得怎么写 Python 吗？’
你知道什么很有趣吗？我以前的一位经理，他在打孔卡时代就开始做软件工程师了。他非常出色。最近他一直给我发消息，展示自己用 Claude Code 构建的所有东西。我会想：哇，这真是一段怎样的职业生涯啊。他确实亲眼见证了整个变化。从打孔卡时代开始，到现在完全不同的世界。我想，我们需要思考的是：当我回顾他的职业生涯时，他从打孔卡开始的方式和现在完全不同。所以，我们需要观察哪些东西仍然重要，哪些东西在重要性上发生了变化，以及我们怎样才能……
获得这些能力。我有一个理论：也许‘什么重要’这件事会随着时间变化。然后我们要怎样建立熟练度，学习真正重要的东西？
关于这一点，我经常听到的论点是：这只是一个新的抽象层。就像汇编语言和二进制一样，抽象层不断上升。现在我们不必真正查看代码了，因为出现了一个新的抽象层：提示词，以及 Claude 的思考和消息。
是的。也许问题变成了：什么是有趣的问题？该优先构建什么体验？这很有意思，也许我们正在……然后，当你构建东西时，你怎么知道它真的引起了共鸣，真的在做你想让它做的事情，而且效果很好？
我们是在构建一堆垃圾，还是在构建真正能够运行的架构？不过我认为，年轻人的优势在于，他们更容易直接拥抱这种新的工作方式，而不是被过去的方式困住。像你这样的长期工程师，能够适应并拥抱这一切，实在令人惊叹。要彻底改变一切非常困难，但你却能说：好，那就这么做。
因为变化速度也非常快。实际上，这就是其中一件事。我记得最开始大概是 Sonnet 3.5 或 3.6，那时我在做其他事情时，它仍然会犯一些错误。我会想：‘你在做什么？’后来我注意到，一些抵制 AI 工具的工程师会说：‘看吧，它就是这样。’但我觉得，人们很难理解改进速度是指数级的。所以我一直在学习，也许这是另一件有趣的事：我可能曾经尝试自动化某件事，
当时 Claude 还不够好，但下一个模型出来后，突然就足够好了。所以你也要不断思考：过去没有奏效的事情，也许值得重新尝试，因为现在可能出现了新的能力。
这档播客里经常有人这么说：先构建一个几乎能用、处在能力边缘的东西。因为一旦模型达到那个水平，你就会远远领先于其他人。好，最后一个问题。你也许已经通过刚才的话回答过了，但什么事情会让你夜不能寐？
让我夜不能寐的事情，可能是我们如何……我们谈过 Claude Code 和 Cowork 团队的文化，这对我非常重要：我们要有一体化的团队意识。我也会和大家分享，文化是一种有生命、会呼吸的东西，不只是贴在墙上的海报，它会随时间变化，也会体现在我们如何彼此对待、如何互相支持。所以团队文化对我很重要，因为我们正在成长，而文化也在变化。我们要确保仍然保留那些重要的东西。
对我来说，拥有多样化的视角也非常重要，这样我们才能进行健康、开放、诚实的讨论，并且把这些讨论公开进行，我们欢迎这种讨论。我所说的一体化团队意识，就是当你快到终点时，要回头看看：团队里还有人需要帮助吗？因为我们是作为一个团队一起完成的。这可能就是让我夜不能寐的事情。当然，还有很多其他困难的问题，但我想其中大多数是产品或工程挑战。我们有仪表盘、理论和假设，但文化属于人的层面，它是……
我认为这就是我始终想确保的事情：随着团队成长，我们仍然维持这种文化。它是团队的纤维。当文化开始偏离时，我总会担心：我们能发现这种偏离吗？能不能作为团队一起进行讨论，确保我们都希望文化朝着正确的方向成长？
我总会担心：当文化开始偏离时，我们能不能发现它，并作为团队一起进行讨论，确保我们都希望文化朝着正确的方向成长？
考虑到变化的速度和招聘的速度，我想很多人都在为此苦恼。尤其是 Anthropic 这样的公司，正处在历史上最疯狂、最前所未有的增长轨迹中。我能想象，这么多变化会带来挑战。所以这很合理。比如我在 Airbnb 时，公司也经历过一段很快的增长轨迹，但和你们正在经历的完全不是一个量级。那时我们也一直在讨论：怎样维持文化？
我很好奇，你在 Airbnb 维持文化、推动公司成长时有什么经验？
有几件事。第一，创始人对文化的痴迷非常有效。每次全员会议、每次重要会议，都会不断提醒大家文化、文化的价值以及我们的价值观。创始人自上而下地重视文化，是其中很重要的一部分。你几乎无法参加一次会议而不谈到这件事。另一件我经常想起的事，是 Sheryl Sandberg 来做炉边谈话时，有人问她：‘公司规模扩大时，你如何维持文化？我们成长得这么快，很难处理所有这些变化、文化和新员工。’她的建议是……
‘这其实是你希望遇到的问题，因为这意味着你正在成长，事情进展顺利。这很正常。相比之下，如果你做得不好，什么都不会改变；当你不再成长，也不再疯狂招聘时，情况会糟糕得多，那会带来更多痛苦和折磨。你现在面对的是一个好问题。’她的这条建议一直留在我的脑海里。
§11文稿 · 81:32
这很好。有趣的是，听你这样说，我觉得 Claude Code 和 Cowork 团队非常重视的一件事是：无论是 IC 还是管理者，尤其是团队里的管理者，我们不仅要谈论正在发生什么，也必须坦诚谈论哪些事情进展不顺利。因为只有真正讨论哪里不顺利，我们才能去解决它。说到让我夜不能寐的事情，我最害怕的情况是：尤其当某个人身处管理者职位时，我问他‘最近怎么样？’他回答：‘一切都很好。’
但我会想：‘天哪，我明明一点都不好。我知道这里有问题。’这就像那个表情包：一只狗坐在着火的房间里喝咖啡。这就是我的噩梦。所以我会和团队里的很多人讨论这一点，尤其是管理者，特别是他们刚加入的时候。我会说：‘我们要始终保持开放的对话，这样才能一起解决问题。’
我想很多人都会为此苦恼：看到周围那么多人表现得非常好，至少看起来表现得很好，一切都很顺利，大家都在建设很棒的公司。你很难真正诚实地说：‘事情进展得不好，我在这里遇到了困难，我落后了。’因为周围的人表面上看起来都表现得非常出色。
在进入非常令人期待的闪电问答之前，还有什么想留给听众的吗？有没有其他我们没有讨论、但你想分享的重要事情？
也许有一个建议。我们谈过 Claude 如何自动化工作，而 Claude Code 和 Cowork 团队文化中还有一件非常重要的事：明确允许淘汰那些不再服务于我们的流程。所以我想给任何在团队中工作或领导团队的人一个建议：挑出一个你害怕做、噪音特别多、成本很高、非常手动，或者只是让你觉得负担很重的流程，先选一个。
然后首先问：它现在仍然有意义、仍然在发挥原本的作用吗？比如我们的规划。我刚加入 Clockhood 时的第一个重要教训就是：我想，‘也许我们应该做一份六个月的路线图文档。但要做得非常轻量，因为我不想浪费大量时间规划。’于是我们做了一个非常轻量的流程。这对我来说是很好的学习，因为这个练习有助于启动对话并确保大家对齐。但三个月后，我想：‘等等，我们还在参考那份……吗？’因为变化太多了。这也是我自己引入的一件事，当时我觉得它可能会有帮助。所以要始终保持学习的开放态度，并且不断问自己：无论你采用什么流程，它是否仍然在发挥作用？因为这个领域变化得太快了。
所以要始终保持学习的开放态度，并且不断问自己：无论你采用什么流程，它是否仍然在发挥作用？因为这个领域变化得太快了。
我喜欢这个建议。让我马上追问一下：你现在怎样看待规划？你还做规划吗？是做一个月的路线图吗？简单来说，你们现在是怎样做的？
我现在把它叫作 JIT planning，也就是 just-in-time planning，及时规划。因为我觉得六个月太长了。现在有些项目确实会花费超过一个月，但我们会尽量做一个月的规划，而且非常轻量。实际上，连文档都没有，只是把我们认为重要的事情列在一个小电子表格里。不过即使是这样，我也还在思考：我们可能每周都需要保留一个快速检查。现在我们尝试的方式是：这是本月的优先事项，我们先试试看。但我感觉，我们可能每周都会想快速确认一下：‘嘿……’
没错。
确认这仍然是本月的优先事项。很好。不过现在我们已经把规划周期缩短到每月了。
所以按月规划，意思是：这是下个月的小表格或 Excel 电子表格，列出我们计划下个月要做的事；然后每周检查一次，确认它仍然是我们下个月要做的事。
是的，这非常奇怪。不过即使是这样，我仍然在思考，怎样才能进一步自动化？我从来不希望有人必须更新电子表格，而让它感觉像一种额外负担。实际上，就在昨天我们还在讨论：‘我们怎样才能把这件事自动化？’所以，回到刚才那个问题，要始终问自己：我们能不能把这件事做得更自动化？我的产品经理思维会想……
这确实是个问题：你怎么可能不把它做成这样？好，这是我们下个月的计划，每周检查一次，确认它仍然有效。我也听出，你们的电子表格里不会有很多条目。
是的，我们确实努力保持专注。我们会分享：这是我们认为最高优先级的事情。然后，基于这些优先事项，大家会分别提出自己认为能够解决这些优先事项的项目。
有没有更长期的内容，比如未来六个月要做的重大押注？还是你们只考虑提前一个月？
通常我们确实会先确定工作的主题，所以每六个月会把整个团队召集起来，确定一些主题。但之后关键是持续掌握进展，因为这些主题也会随着环境变化而快速改变。
好，那我们把电子表格拿出来看看。
天哪，这整档播客都可以只聊你们的规划方式。好，我得找别人来聊这个，因为它太有意思了。好，Fiona，说到这里，我们进入非常令人期待的闪电问答。我有五个问题要问你。准备好了吗？准备好了。第一个问题：你最常向别人推荐哪两三本书？
说到小说，我会向所有人推荐两位作者：Margaret Atwood 和 Haruki Murakami。我是在加拿大长大的，所以从小读了很多 Atwood 的作品。她的书很迷人，因为你几乎可以眯起眼睛问：好，这件事真的可能发生在一个社会里吗？我很喜欢她对推想小说的处理方式。我也喜欢 Murakami 的魔幻现实主义风格。但在这两位作者之外，有一本书我总是建议大家至少每年读一次，那就是《小王子》。我想我们可能都在人生的某个阶段读过它，但我……
我至少每年读一次，只是为了提醒自己思考：什么才是真正重要的。哇，这个答案还没有出现过很多次。
我喜欢。你最近特别喜欢的电影或电视剧是什么？
我不怎么看电视剧。这在 Anthropic 的人里很常见。我在……
这是这档播客里的常见主题。
不过我可以告诉你，我总会在手机里下载什么，这样坐飞机时就能看。有三部电影我总会放在手机里，因为如果有时间，我觉得它们真的非常有趣。其中一部是《天使爱美丽》，这是一部法国电影。天哪，顺便说一句，这些电影都非常老了，算是复古电影。但我很喜欢《天使爱美丽》，它非常奇幻，我强烈推荐给还没看过的人。你还记得我告诉过你，我曾经以为自己会成为一名视觉艺术家吗？我 16 岁时，高中组织了一次巴黎之旅，这段经历给我留下了很多回忆，而《天使爱美丽》真的捕捉到了我在巴黎感受到的魔力。我还有……
很多关于那里的回忆。另外两部是吉卜力电影。我喜欢《千与千寻》，它真的是一部非常出色的电影。我喜欢这个故事，也喜欢《千与千寻》的一切。它可能是我最喜欢的吉卜力电影之一。第三部是另一部吉卜力电影《风之谷》。我经常想起这部电影，因为如果有人问我：‘你是怎样形成这些领导原则的？’我想，我大概在八九岁时看了那部电影。《风之谷》的主人公娜乌西卡，以及观察她如何领导，深深地留在了我的心里。
所以你可以说，娜乌西卡可能在很多方面都深深启发了我的领导原则。
哇，那本书叫什么来着？
§12文稿 · 90:11
电影叫《风之谷》，但它实际上改编自一部漫画。
《风之谷》。所以就是 Andy Grove 的《高产出管理》，再加上《风之谷》和娜乌西卡。
没错。
两本顶级管理书。太棒了。你最近有没有发现一件非常喜欢的产品？可以是应用、服装，或者厨房用品。
我来分享一个产品。最近我重新意识到它对我的生活有多大影响，因为我最近旅行了一些，而我喜欢轻装旅行，所以通常会使用酒店提供的洗发水和护发素。我手头正好有他们的一件产品。我保证这不是信息广告：Sweet Sisters Body Care 是惠德比岛的一家本地企业。他们提供完整的有机头发、身体和皮肤护理产品。几年前，我的鼻子就在这里开始长疹子，非常疼。
甚至会出血，我怎么都想不出办法让它停下来。我试过完全不用乳液，也把脸上所有东西都停了，但还是很痛。后来有人问我：‘你用的是什么洗发水？’我说：‘就是我从十几岁起一直用的那种。’他们说：‘也许你的身体开始对它产生过敏反应了，因为里面有化学成分。’那天晚上我想：‘什么？’那是一种随处可买到的普通品牌洗发水。总之，我后来找到了一种有机洗发水。我用了她家的洗发水。
你不会想到，洗头时使用的东西其实会流到身体的其他部位。但从那以后，我把所有使用的产品都换成了 Sweet Sisters 的。最近我再次意识到它有多重要：在酒店使用了一周酒店提供的洗发水后，我的皮肤又开始出现一些反应。我想：‘啊，也许我应该买一些旅行装瓶子带着。’
这是个很棒的选择。我喜欢本地企业的推荐，推荐本地企业还能额外加分。顺便说一下，你这次旅行可能有些听众不知道：世界各地正在举办 Code with Claude 活动。我去了旧金山那场，伦敦有一场，你要去东京。东京之后这趟行程就结束了吗，还是后面还有？
东京是下一站，就在下周，也是这趟旅行的最后一站。
之后可能还会有更多。太棒了，我喜欢这件事正在发生。还有两个问题：你有没有一个经常在工作或生活中想起的人生格言？
工作上，我很喜欢提醒大家：保持简单。你真正想做好的一件事是什么？专注于那件事。保持简单，因为我觉得我们有时会想得太复杂，所以这是一个值得经常提醒自己的格言。生活上，大概就是：在你可以成为任何人的世界里，做一个善良的人。
我喜欢这句话。我们去参观一所蒙台梭利学校时，老师就把这句话挂在墙上。
我们要处理的事情太多了，你永远不知道别人正在经历什么。一件小小的善举，可能带来巨大的不同。对我来说，实际发生过这样一件事。你还记得新冠疫情吗？那时我们都在家工作。
怎么可能忘记？那件事一直让我印象深刻。当时我每天参加一个接一个的会议，而且我一直非常重视一对一会谈，因为那段时间通常对另一方也很重要，他们一直在等待这个机会，可能有一些事情想要讨论。但在那段时间，我的外婆身体不好，她住在加拿大的一家护理机构里。因为新冠疫情，我无法去看她，我的姨妈和妈妈也无法去。只有当护理人员能够帮忙时，我们才偶尔可以通过 FaceTime 联系，但你永远不知道具体会是什么时候，因为有很多人需要照顾。突然有一天，我收到姨妈的消息：‘外婆今天中午 12 点可以 FaceTime。’我想：‘糟糕，我一直想和这位同事进行一次一对一会谈。’于是我给我的下属发消息说：‘真的非常抱歉，临时才说，是否可以……’
我知道这听起来不是什么大事，但对我来说，保持这次会谈一直很重要。他说：‘当然可以，完全没问题。’对我来说，那就是一个小小的善举。他完全没有把它当成什么大事，但这对我意义重大，因为我终于可以通过 FaceTime 向外婆问好。
好的。最后一个问题：我问 Boris Cherny 对你的看法时，他分享了一个很有意思的观察。他说，在非常重要的会议上，你经常能在背景中听到 Fiona 织毛衣的哒哒声。谈谈这是怎么回事？你最近织了什么？
天哪。我最近织了这件上衣。
你自己选了衣服。这对 Claude Code 自己构建自己来说很有‘元’的意味。我们总是……
针织和编程之间确实有一种很有趣的联系。针织里有两种针法，正针和反针，可以类比成 0 和 1。而且，栈和队列之类的概念其实也很多。我织毛衣时有点像编译器，像是在生成一个可执行文件。是的，我八岁时是外婆教我织毛衣的，我刚才提到过她，也提到过那家毛线店。所以每次织毛衣时，我都会想到她。不过我总喜欢一心多用，就像你可以启动多个智能体一样。每当我坐下来，因为练习得足够多、已经很熟练了，不需要一直看自己在做什么，所以……
它有点像人们有时玩的指尖陀螺。只要我坐着不动，我就会想：‘哦，这是生成更多针织可执行文件的时间。’因为我有太多毛线了，如果不这样做，我可能有一点毛线成瘾的问题。
我喜欢这个。当我问 Boris AGI 到来、我们不再需要工作时他会做什么，他说他要让你缝纫。我猜你会回答：织毛衣，做漂亮的衣服。
天哪。我的梦想是用外婆的名字开一家毛线店，创造那样的社区。
太棒了。然后 Cowork 会帮你把所有事情自动化。
尤其是开票。
天哪。Fiona，你太棒了。你和团队所做的工作太不可思议了，以如此深刻的方式改变着世界。很明显，Anthropic 正在快速成长，所以你们做得很好，真的做得很好。
我真的非常幸运，也很谦逊，能够和这样出色的团队一起工作。我知道自己有多幸运，也非常感激。也谢谢你邀请我来参加这档播客，今天非常开心。
最后两个问题：如果听众想在线上找到你、跟进今天谈到的事情，你在哪里？他们怎样才能对你有所帮助？
我在 LinkedIn 上。相信大多数人已经分享过这些内容了，但我很希望听到大家的反馈：哪些事情进展顺利，哪些事情不顺利？还有哪些你们正在使用的潜在需求或有趣的使用场景？最近有位朋友给我发消息说：‘我在用 Claude 帮我为棚屋生成建筑方案。’他还把完整的棚屋展示给我看，真的很酷。所以我很想听到这类故事。我们还谈过向身边的人伸出手。如果你身边有一家喜欢的小企业，或者有人还没有……当然，我假设听众们都非常 AI 上头。
也许你可以花一点时间，牵着某个人的手，向他展示 AI 可能怎样帮助他们。
这是一个很好的回答，尤其是由你来回答这个问题。Fiona，今天非常棒，谢谢你来到这里。
谢谢你邀请我，Lenny。大家再见。
非常感谢你的收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用中订阅节目。也请考虑给节目评分或留下评论，这会帮助其他听众找到它。你可以在 lennyspodcast.com 找到往期节目或了解更多信息。我们下期再见。