Anthropic 的工程师平均每个季度提交的代码量，与 2025 年相比翻了八倍。〔音乐〕
编程不再是瓶颈。它把每个人能力的上限都抬高了。理论上，一切都有可能了。现在的问题是，你能有多远大的抱负？〔音乐〕
我们总在问自己，有什么比我亲自做更好的办法？还没想到，David。那些做得最好的人，往往最主动、最积极、最有能动性。我们说，高能动性也伴随着高责任感。所以，关键是要确保大家有自由去写代码。但接着也要问：那责任是什么？你试图解决的问题的假设是什么？我很好奇，在这个软件工程的新世界里，什么正在流失。这可能会开始变成一种孤独的经历，因为我们都太频繁地只和自己的 agent 一起工作了。所以在 Claude Code 团队，最近我们发起了结对编程午餐会。你会思考这样一个正在形成的鸿沟〔音乐〕：一边是积极拥抱 AI、做得风生水起的人，另一边是不肯接受、极度沮丧、挣扎抗拒的人。说到沮丧，我觉得有时我也能看到一丝恐惧。对于任何让人感到恐惧的事，我的建议是迎上去问：〔音乐〕“我能做些什么？什么是可控的？”
Lenny：今天，我的嘉宾是 Fiona Fung。Fiona 负责领导 Anthropic 旗下 Claude Code 和 co-work 的团队。她管理着 Boris Cherney 和 Kat Wu，这两位都曾做客本播客，他们的单集也位列有史以来播放量最高的前十期。加入 Anthropic 之前，Fiona 在 Microsoft 带领团队打造了 TypeScript 和 Visual Studio。之后她去了 Facebook，创立了 Facebook Marketplace 团队，并将其〔音乐〕从想法推进到上线。如今，Facebook Marketplace 每年创造超过 1000 亿美元的 GMV。此外，在 Meta 期间，她监督了 Meta 首款智能眼镜产品的开发，随后参与打造了 Orion——Meta 首款 AR 眼镜产品。接着她去了 Instagram，负责领导基础设施、增长、诚信与安全团队。在 Instagram 和 Meta 期间，她〔音乐〕管理着一个超过 500 人的组织。Fiona 已经做了 25 年以上的工程师，作为一名资深的工程领导者，尤其是现在〔音乐〕在 Anthropic，她对事物的发展方向、什么值得关注，以及团队应该思考什么，都有着独到的视角，因为〔音乐〕AI 正在改变构建世界的方式。非常感谢 Kat Lo、Boris Cherney 和 Mohammad〔音乐〕Hegazi 为本次对话提供主题和问题建议。在开始之前，别忘了访问 Lenny's product pass.com。
〔音乐〕免费领取全球最热门、最精良的 AI 产品一年使用权，仅限 Lenny 的通讯订阅用户。话不多说，有请 Fiona Fung。
〔音乐〕
Lenny：Fiona，非常感谢你来做客，欢迎加入播客。
Fiona：非常感谢邀请，Lenny。
Lenny：大概一个月前，我参加了那个“Code with Claude”活动，听了你的演讲，我当时就想：天哪，一定得请 Fiona 来播客。她对 AI 发展方向和现状的思考远超其他人。你当工程师已经有 25 年了。我浏览了你的 LinkedIn，你最早竟然是在 IBM 工作。那跟现在相比真是〔笑声〕截然不同。过去短短两年间，工程师这份工作发生了翻天覆地的变化，简直像换了一个职业。大家可能忘了，就在不久前，100% 的代码都是由人类编写的；而现在，正走向 100% 由 AI 编写代码。正如 Boris 那句名言所说，coding 就是 salt。说到这个，你们昨天发的一条推文展示了——就是这条推文——Anthropic 的工程师平均每个季度提交的代码量，与 2021 到 2025 年相比翻了八倍。我们待会儿会在屏幕上展示这张图表，简直就是稳、稳、稳、稳，然后砰地一飞冲天。所以这个角色的变化之大实在令人难以置信。我很好奇，作为一名工程师，你一路走来的经历是怎样的？做了这么久工程师，一路上有哪些重要时刻改变了你的思维和运作方式，最终让你形成了现在的工作方法和理念？
Fiona：哇，我太喜欢这种回顾了。没错，IBM，当时在做 DB2，操作系统服务团队。那时候我在想，怎样才能接触到技术栈里最难的部分？我真的觉得越往底层走、越接近 OS，就越硬核，学到的东西也越多。所以我很幸运能拿到 IBM 的实习机会。不过从 IBM 到 Microsoft，其实也有一次巨大的转变。在 IBM 的时候，我们用的大概是 Vim。我们根本没有 IDE，也许有 Eclipse 的授权，但出于某种原因大多数人都不用。所以我记得当时主要靠 Vim，还有终端调试。后来我加入了 Microsoft，说来惭愧，我当时太天真了，连 IDE 是什么都不知道。而且那时候你其实没法选团队，那是 2000 年代初。首先我得说，我非常感激自己拿到了那个实习和全职机会，因为把时间拨回去，2000 年互联网泡沫破裂了，我那届毕业生很多公司都不招人，或者冻结招聘。所以 Microsoft 给我发 offer 的时候，我觉得自己太幸运了。然后他们说：你去 Visual Studio 团队。我当时根本不知道 Visual Studio 是什么，因为我来自一个 Unix 背景的学校。我记得我还问：这是什么东西？因为我在想，Visual Studio 这个名字，听起来是不是一个更好的画图软件？我能从经理脸上的表情看出他在想：这人怎么回事？
〔笑声〕
Fiona：但结果它却成了我职业生涯前 11 年的挚爱。那也是我第一次使用 IDE。加入 Visual Studio 团队后，看到原来还有带调试器的 IDE，可以设断点、做多线程调试，这对我来说也是一次飞跃式的震撼。所以从 IBM 到 Visual Studio 的故事大概就是这样。而我真正喜欢 Visual Studio 的地方在于，我当时在 Visual Studio 编辑器团队。我用 VS 编辑器来开发 VS 编辑器，这让我养成了 dogfooding 的习惯。我记得我当时首先想为自己、也为队友创造愉悦的体验。因为回到那个时代，你还记得 Twitter 是什么时候出现的吗？大概是 2006 年？
Lenny：它简直贯穿了我整个人生。
〔笑声〕
Fiona：但在那个年代，社交媒体出现之前，大多数工程师很难快速听到客户反馈。当然，会有用户研究环节，或者客户来访，但你得不到像现在这样的快速反馈。不过那时候我很幸运，因为我在 VS 团队，我们自己之间就互相提供了大量快速反馈，毕竟团队里每个人都是 VS 的重度用户。本期节目由我们本季的呈现赞助商 WorkOS 为您带来。OpenAI、Anthropic、Cursor、Vercel、Replit、Sierra、Clay 以及数百家其他成功公司有什么共同点？它们都由 WorkOS 提供支持。如果你在为企业开发产品，你一定体会过集成单点登录、SCIM、RBA、审计日志以及大型企业所要求的其他功能有多么痛苦。WorkOS 将这些成交阻碍转化为即插即用的 API，其现代开发者平台专为 B2B SaaS 打造。毫不夸张地说，我投资的每一家开始向高端市场扩张的初创公司，最终都会与 WorkOS 合作。因为他们就是最好的。无论你是试图签下首位企业客户的种子期初创公司，还是正在全球扩张的独角兽企业，WorkOS 都是让你的产品具备企业级能力、解除增长瓶颈的最快路径。它本质上就是企业级功能的 Stripe。访问 workos.com 即可开始使用，或者直接在他们的 Slack 里找人，那里有真正的工程师等着回答你的问题。WorkOS 凭借出色的 API、全面的文档和流畅的开发者体验，让你更快地构建产品。前往 workos.com，今天就让你的应用具备企业级能力。人们在思考工程师成长道路上的这些里程碑时，却忘了多年来也发生了许多变革。虽然不像我们现在正在经历的这场变革，但就像 IDE、Visual Studio 那样。所以我很喜欢你提醒我们软件工程史上的这些时刻，它们极大地改变了这项工作。是的，当年我在 Visual Studio 团队时，我们还通过 CD 来发布软件。我的意思是 ，那时候……所以当时有非常严格的截止日期，因为你必须确保软件已经准备好，可以交给制造部门去刻录到 CD 上，然后放到货架上销售。后来，当我们真正开始能够通过网络发布软件时，又是一次转变。我觉得这很有意思，而且我在演讲中也提到过这一点。以前，工程时间是非常宝贵的资源，但你又有非常严格的截止日期，比如把软件刻录到 CD 上。因此那时候你会做更多规划，因为你只想确保在有限的时间内做到最好。而现在，随着 Clockwork 和 Co-work 的出现，我们正在看到一种转变：编码不再是瓶颈。现在，就像你展示的那条推文和图表一样，关键在于这种转变发生在哪里。现在不仅工程师，我们还有设计师、产品经理，Clockwork 团队的每个人都会提交代码。当不仅更多人提交代码，而且涉及不同学科，同时吞吐量又如此之高时，我们该如何看待验证？这是我看到的另一种转变。也许可以先定个调，这是我想在本次对话中探讨的主题。很多人都在好奇，软件工程、管理软件工程师、管理软件和产品团队在未来会是什么样子，而你正在亲身经历这一切。你刚才提到了一点，即要更加关注验证，确保代码质量在产出达到 8X 的情况下依然很高，确保代码能够正常运行。那么，让我先问一个宏观的问题，看看这次对话会走向何方：到 2026 年，一个全面拥抱 AI 的软件团队会是什么样子？因为角色正在发生巨大变化，我觉得它正更多地转向“构建者”的方向，每个人都开始成为构建者。我最近做的另一个改变是，我在我们所有的代码仓库中都部署了一个 cloud code 远程会话。这样，我就能完全了解每个人在做什么。这个实例还能访问我们所有的 Slack 频道，我也能查看我们追踪的各项指标。所以每个月，我都会说：“嘿，你知道吗？好玩的是，咱们来回顾一下。”我们会一起做这个。我会共享我的屏幕，你知道，打开 cloud code，我们一起进行一次 cloud code 会话。内容就是：“嘿，当时的重点是什么？上线了哪些产品？它们表现如何？哦，反馈渠道有哪些？”虽然以前我只会用这些会话来生成 PR 和修复 bug，但现在我利用这些会话来支持我与团队成员进行对话。再多说说这个。那么，这可以说是一种管理技巧，帮助人们不只是交付，而是更好地交付，理解他们交付的东西是否产生了影响。是这个意思吗？就是利用 cloud code 来掌握大家在交付的所有事情，然后以此为基础与他们展开对话。完全正确。所以，是的，除了交付这个动作本身，还要看它在市场上的表现如何？或者，我们有没有引入一些 bug？我有句话叫“犯新的错误”。犯错没关系，只要犯的是新错误，这样我们就能持续学习，因为如果你目标是零错误，那可能意味着你行动得不够快，或者过于谨慎了。所以，借助 Claude，它还能帮我查看，比如，实际上，我刚才就在看，鉴于我们遇到的一些事故，让我们全面看看这些。我们能否提炼出一个主题？特别是在质量方面，有哪些值得投入的好领域？我们是不是看到了哪些可能出现缺口的热点区域？我觉得这在以前是一个更加手动的过程。如果回望一年前，我不认为我能通过 Claude 获得这些洞察。是的，一部分原因是有了这些工具，还有就是以前人们交付的东西没那么多，所以你可以简单地列个清单：这是我上个季度交付的东西，这个功能、那个功能、这个功能、那个功能。所以我觉得你刚才说的是，这似乎是唯一能够跟上你们团队所有交付内容的方式。这是一个很酷的思路，就是你找到了方法来应对代码量 8 倍增长所带来的管理需求。还有什么方法帮助你和你的团队跟上节奏，并维护好你们交付的所有内容的质量？因为这显然是个挑战，而且是个更大的挑战。是的，所以反馈渠道对我们来说确实非常重要，而且我们也收到了大量反馈。比如，就连我自己，以前的晨间习惯是，先喝杯咖啡，然后查看反馈渠道，再试着找出，如果今天有一些 maker time，我能帮上什么忙，或者发现哪些缺口。这以前是我每天早上都会做的事。大概一两个月前，我们推出了 routines。这也彻底改变了我的工作方式。现在我只需运行一个 routine，就能为我自动化处理所有这些事。而且这几乎就像以前我只能自己生成一些 prompt，但现在有了 routines，就好像有一个 agent 在帮我生成 prompt 和 PR。举个例子，其中一个 routine 是：“嘿，留意这个反馈渠道，看看有哪些主题？”然后当我醒来时，我就有一份非常好的总结。甚至还有一些我可以查看和审核的 PR。那这个反馈渠道的反馈是从哪里来的？是指邮件、Twitter，还是所有这些的结合？我们的反馈渠道确实有很多来自内部，但也有邮件、各种频道。实际上，每个人收到反馈时——哪怕是朋友发消息过来，或者在 LinkedIn 和社交媒体上——我们都会把这些全部发到 Slack 里。当然，我们还有合作伙伴。所以我们针对不同来源有不同的渠道。但我的意思是，我需要 Claude 帮我跟上进度，因为涌入的反馈实在太多了。明白了。这很酷。所以你建立了一种工作方式，用来跟上所有正在发布的东西。这几乎是一种日常仪式或固定流程：你作为管理者，查看人们对 Claude Code 和 Co-work 当前状态的评价。以前只是“来个人去修这个、去修那个”，现在是“这是能修复这个问题的 PR，你看看。如果你同意，我们随时可以发布。”
没错。好，显然对大家来说一大挑战就是代码审查。我猜 Claude 也在做很多自身的代码审查。你们最近有没有什么新发现，能让团队更快发布他们确信很棒的东西？是啊，说实话，想到去年我们还没有 Claude Code Reviews，就觉得挺不可思议的。说到瓶颈，人工审查曾经真的是一个非常大的瓶颈。所以，对于那些需要深厚领域专业知识的重要领域，我们当然还是希望有合适的人工审查。不过我觉得对我们有帮助的是，我们越是能将“什么是好的”这一框架自动化地提交进去，效果就越好。当你给 Claude 一个框架，让它对照验证时，它非常擅长。所以我提到过，最近我们更新了内容设计，加入了一个评分标准。我觉得，如果你有规格说明之类的东西，就把它们提交到 repo 里，然后确保规格说明也能经常与代码保持同步。我发现这招很管用：任何时候只要你对“好”有一个定义，就把它放进仓库，然后 Claude code review 就能确保它仍然符合你最初设定的标准。基本上，这就像是测试驱动开发的进化版。对，说到 TDD，我记得那大概是 2000 年代很火的概念：先写测试，确保它失败，然后再写代码。原则上这很好，但我记得自己当时有点挣扎，因为感觉就像是你得先吃掉西兰花。这就是为什么我一想到要先写测试就头疼，而我从发布产品和做产品中获得太多快感了。有趣的是，实际上我在 Claude Code 上修的第一个 bug，我记得当时问 Claude：“嘿，我想做测试驱动开发。帮我先写测试，确保它失败，然后我们再修 bug，再让测试通过。” 而以前，测试生成简直就是一种我记得不得不支付的“税”。现在这完全自动化了，你还可以重新审视这些存在已久的原则，而且它们现在可能变得更高效了，毕竟有模型能帮你做更多工作。是啊，这太不公平了。它直接帮你把测试先写好了。说到构建者这一点，你演讲里有一张我最喜欢的幻灯片，我想就此请教你：你在招聘什么人，你看重哪些特质。我来读一下你在那里说的，然后想在这里听到更多。你现在招聘时寻找的两类人是：有产品嗅觉的创造性构建者，以及负责攻克难点的深度系统专家。对，深厚的领域专业知识。比如，我刚加入 Cloud Code 时，我们有很多非常优秀的产品通才。然后我意识到，啊，我们缺有系统背景的人。所以这绝对是我们需要更多拥有系统和分布式系统专业知识的领域。我想说的是，本质上还是要“信任但要验证”。模型确实很厉害，但肯定还有很多领域需要验证。所以， wherever 你需要深厚的领域专业知识，我认为那绝对是仍然值得投资的领域。另一类则是有产品嗅觉的人，他们几乎就像梦想家。这些人通常会想：“天哪，我对这个产品特别有热情。” 他们有个想法，就去做出来，然后不断看反馈、迭代、打磨，确保产品体验令人愉悦。从头到尾对这款产品负责。这也是在 Cloud Code 上对我们非常有帮助的另一类技能。这特别共鸣。有个词叫“野心”，我不知道你有没有用过，但我听你讲的时候就想到了这个词。最近在我做的播客和其他工作中，这个词经常出现。前几天我和一位 10X 工程师聊天，他说：“以前我听到一个功能想法，有人说咱们该做这个，我就会想，不，那太难了、太复杂了。但现在我会想，不不不，完全可行啊。我让 Claude Code 去做，它就做出来了。” 这整个就是思维模式的转变。他现在意识到，问题在于你能有多大胆？理论上一切都变得可能了。现在关键是你能想得多大、多敢想，而不是“好吧，又是一堆我得去疏通的琐碎小功能”。你有同感吗？你会思考这个问题吗？对，其实我昨天刚和一位工程师聊过。他本身不是做移动端的，但我们确实需要更新这个功能，让它也覆盖移动端。结果太惊人了。他说：“你知道吗？” 这很常见，因为你可能会想，“等等，我又不是 Android 专家。” 但现在，多亏了 Claude，我其实有了一个搭档，也能在移动端做这件事了。所以这绝对有共鸣。就像是它抬高了任何人能力的天花板。让我顺着这个思路问。随着这个角色发生了如此巨大的转变，有些人如鱼得水，有些人则非常沮丧、不开心、抗拒、抵触。在那些做得很好、已经适应并蓬勃发展的工程师，与那些沮丧、过得不好的工程师——甚至非工程岗位的人——之间，你看到了什么共性？我觉得成长型思维真的、真的很有帮助。实际上，早在 AI 工具出现之前，我就发现这非常宝贵。我学到很多。其实是从微软转到 Meta 的时候，那是我第一次真正……第一年我就想：“哦，这就是拥有成长型思维真正的含义。” 本质上就是永远保持学习。能让你走到今天的东西，可能不再能帮到你继续走下去。但这很难，因为当然，我们每个人，你知道，我们都是通过某种特定的行为或工作方式才达到现在的状态的。所以有时候想想会有点可怕：“等等，但我到目前为止一直很成功，你现在要我改变那些让我成功的东西。”所以我想说，成长型心态真的对我帮助很大，而且我觉得对我观察到的其他人也是如此。就是永远带着好奇心去投入，永远保持学习的能力。说到挫折感，我觉得有时候背后也有一点点恐惧。所以我的建议是，至少在生活中我是这样做的——因为我们都会有恐惧，恐惧当然是一种进化而来的反应，我没学过人类学，但我觉得这说得通，对吧？它帮助我们确保能够生存下来，不被更大的捕食者吃掉。但对于任何让你感到恐惧的事情，我的建议是去直面它，然后问自己：“好吧，我能做些什么？什么是由我控制的？”因为有时候挫折感来自恐惧，来自觉得一切都超出自己掌控、事情正在发生在自己身上的感觉。所以如果你想想：“好吧，什么是我能控制的？”与其说它发生在你身上，能不能说它为你而发生？然后有什么是你能够去做和改变的？我觉得这很有帮助，因为如果不这样做，那种恐惧加上一切都超出掌控的感觉真的会让人非常沮丧。其实我记得，当我在高中的时候——这挺有意思的，我们刚才还聊到 IBM。我上高中时其实没选计算机科学或工程，我真的很想成为一名视觉艺术家。那是很久很久以前的事了。那时候电脑非常贵，我根本没有电脑可用。我第一次接触电脑是在高中九年级。我都不知道现在高中还有没有这种课了。我的高中有一门打字课，就是学习如何在键盘上打字，打得非常熟练，那是我第一次接触电脑，然后接下来的课可能是一些 HTML 编程。总之，我爱上它的原因是，我喜欢艺术的地方在于创造，在于如果你有想法，你就可以去创造、去讲故事。然后我意识到：“哦，电脑和编程也能让我做到这些。”
所以，我拼命补修所有理科课程为了能考上大学，但我一直有个恐惧：“哦，但我怎么负担得起工程学院的学费呢？”这是一个巨大的未知数。我在安大略省长大，我很感激我知道有一个安大略省学生援助计划，叫 OSAP 吧，我很感激有这个，但我不知道它能覆盖多少学费或生活费，这完全是个未知数，而且那是一年后的事。我记得当时想：“好吧，我能做些什么呢？”然后碰巧的是，加拿大国家银行刚好在我们高中贴了一张海报，写着：“嘿，我们在招高中生实习生当银行柜员。”我记得当时想：“哦，这个……”当然那会是最低工资，但我觉得那可能是一条生命线。但好笑的是，我高中最讨厌的课就是会计，所以我都不知道自己能不能干好，但我还是报名当了银行柜员，结果这成了一个非常明智的决定。我整个夏天都在工作，攒了钱，而且实际上周末也能去做银行柜员。所以是的，我周一到周五上学，周六去当银行柜员，这最终成了一条生命线，让我能够支付所有的学费。嗯，我们聊到过 2000 年互联网泡沫破裂，那时候大家不怎么招实习生了，实际上我又继续做了两年银行柜员。但那就是我觉得我能采取的、在我控制范围内的一个行动，试图对抗我的恐惧——如果我真的要走这条路，我都不知道自己能不能负担得起上学。所以这可能是我的另一个建议：关于成长型心态，以及挫折或焦虑的根源，看看有没有一个在你控制范围内的行动是你能采取的。因为我觉得有句话是，如果你不怕的话你会做什么？那曾是我最喜欢的两句话之一：如果你不怕的话你会做什么，以及偶尔去做些可怕的事，因为那通常也是我们成长的方式。我发现，当你在所做的事情上非常优秀、非常专业时，你基本处于巅峰状态，就是最高效率，但你要如何继续成长呢？那就是去做一些你可能从未做过的、可怕的事情。是的，你会有低谷，因为你需要学习，但这大概就是你不断鞭策自己学习的方式。我在这个播客里用过最多次的一句话可能是：你所恐惧的洞穴里，藏着你寻求的宝藏。哦，我喜欢这句话。是啊，这太对了。我忘了是谁说的，但最可怕的事情就像一个指南针，指向你应该去做的事。嗯。我要偷走你这句话。好啊，请便。你知道，也不是说所有可怕的事都要做，比如别从悬崖上跳下去，但在职业选择上，这可能是很好的选择。顺着这个话题，我知道有件事对你很重要，也是你和我都在思考的，就是那些全力投入 AI、大获成功的人，和那些没有这样做的人之间，正在形成一种差距。对于可能在这个新兴世界中被落下的人来说，这是一个可怕的时代。我知道你花了很多时间和小企业在一起，帮助人们学习如何在工作中使用 AI 是你的热情所在。聊聊你是怎么看待这件事的，以及我们或许应该思考些什么来帮助人们不被落下。哦，我太喜欢这个话题了。是的，这是我最热衷的话题之一，因为我提到过，我在加拿大长大。我小时候搬到那里的。我出生在香港，所以不会说英语，我父母一直要工作。所以我奶奶，她是任何人能拥有的最好的奶奶。我知道每个人都觉得自己的奶奶最好，但我真的太幸运了，我有最好的奶奶。她搬来和我们一起住，就是为了在我父母工作时照顾我。但我们俩都不会说英语，我能够通过上学和同学交流学会说英语。而当我想到我奶奶时，对她来说在那个新国家是非常疏离的，而且那时候那里不太适合步行。但有一个夏天，我记得我们碰巧找到一家小小的毛线店，老板娘也说粤语。所以那个夏天我们每周都去那家毛线店，我奶奶找到了她的编织圈子，然后我想我学会了做 macrame。顺便说一句，我觉得 macrame 正在回归流行，看到这些东西总是很有趣……
Macrame 要回归了？我觉得 macrame 是的。你在 Lenny 的播客里第一个听到这个消息。我觉得 macrame 要回归流行了。好吧。但我的爱大概就是从那里开始的。我当时就想，哇，这家小小的企业竟然营造出了这么棒的社区氛围。而且我很幸运，能和我喜欢的所有小企业主成为朋友。所以我的热情大概就来源于此。然后，事情的经过是这样的：我当时在用 Co-work 处理我自己公司的差旅报销。不知道为什么，我真的很不喜欢做报销。而当我用 Co-work 时，感觉就像魔法一样。我心想，所有我不喜欢做的这些事，Co-work 都帮我做了。然后我转念一想，等等，我的朋友们，说实话，小企业主们真的非常拼命。他们工作得极其努力，而且你要知道，有时候利润率可能真的很低。所以我想，如果 Cloud Co-work 这么擅长帮我处理这点差旅报销，那对小企业来说意义重大，因为我有时看到我的朋友坐在酒吧里，面前堆着一摞账单，做的全是开票和报销。而且我觉得没人真正喜欢做这些事。所以大概就是从这里开始的。然后，我记得我帮其中几家走了一遍 onboarding 流程。看着她们使用我们的 onboarding 流程，也让我很受触动。实际上，还发现了一些很不错的 bug。所以这真的是双赢，但对我来说也很开心，因为她们使用 Coda 的方式是我完全没想到的，因为我当时一心只想着看它在处理 PDF 和发票方面有多厉害。然后，我有个朋友经营两家餐厅，她说："天哪，我这个文件夹就像个杂物抽屉，基本上我们的文档文件夹，或者说下载文件夹，就变成了这样一个杂物抽屉。"她说："我知道里面有几份菜单，但我找不到。"我说："那我们来问问 Coda 吧。"于是我们给了 Coda 目录访问权限，找到了菜单。然后她以非常独特的方式使用它。她说："我想确保我给本地人和游客的价格都合理。"于是她说："嘿 Claude，查查我这个菜系在这个区域的可比价格。"结果返回了非常酷的内容，几乎像是市场分析。她说："嘿，其实我刚去过西雅图那家餐厅，还挺不错的。"所以我每次都能学到新东西。而且她们也给了我很好的反馈。那么问题就是，我们该如何把这件事推广给所有人？因为你也看到了，很多人就是说"我没时间弄这个"，或者"我讨厌 AI"，就想无视它。是靠谈论这些、分享案例吗？你怎么看？要怎么做？有什么办法能在这个问题上取得突破？对我们所有人来说，尤其是你的听众可能已经非常接受 AI 了。如果在你的社区或家人中有这样的人，我会先从那些你真心觉得、确实感受到 AI 工具给你带来了有意义的生活改变的事情说起。然后看看这能不能成为一个对话的开端，因为对我来说 AI 是一种工具。再说一遍，它就像是黑暗中的光。我也完全理解令人沮丧的部分。但对我来说，知识就是力量。必须学会使用这些工具，因为它实际上可以成为那个明暗等式中"光"的部分。所以我想这是我希望大家都能帮忙的事——不管是社区成员，还是你很喜欢的一家店，你可以想"嘿，你有没有……"一开始会有点尴尬。我记得我第一次联系朋友时，因为我不太跟他们聊我的工作，但我就说"嘿，我算是从事 AI 工作的，能不能……"让我说"嘿，能不能给你展示一下 Codoxer 能做到什么"这种话，对我来说都很不自然。但最后我们玩得很开心。所以是的，如果能有一个这样的对话开场白就太好了。因为我想确保我们持续分享知识，让这些工具更加公平可及，否则我担心鸿沟会越来越大。我也是。正如你所说，我发现分享使用案例的力量非常大。前几天我刚用 Codoxer 填了我儿子的夏令营表格。就在 Twitter 上分享了这件事，很多人都表示"哇，我都没想到还能这样"。是的，就是这些小事情，你根本想不到 Codoxer 和 Claude 也能做。顺着这个思路，说到 Codoxer，你想想，Anthropic 在发现这些巨大机会方面一直遥遥领先。比如编程，远远走在前面。意识到这是一个巨大的市场。不管是有意为之还是无意之举，当时就是"哇，这可能是历史上最大的新商业机会"。然后 Codoxer 也是个很好的例子，直接投入到知识工作中。干脆解决所有知识工作的问题，为什么不呢？远远领先于其他所有人。另一个要素是对模型个性的重视，你们很早就意识到这有多重要。不仅对体验重要，对模型的智能和成功也很重要。你认为 Anthropic 和团队做了什么不同的事，让你们能发现这些机会，并在其他实验室之前大胆投入？嗯，我没在其他实验室工作过，所以不清楚其他实验室是怎么运作的，但我可以分享的是，是的，实际上在 Claude Code 团队和 co-work 这边，我们也会关注潜在需求。在编程这个用例上我们很幸运，因为很多 ants 就是我们自己的首批用户，我们能够获得非常快速的反馈。所以我认为……但潜在需求一直是一个……比如 co-work，我们注意到，嘿，很多不一定是程序员的人也在用 Claude Code。我们能不能让那个体验更好？我觉得这一点其实不光是在 Anthropic，在我做过的所有不同产品中都对我很有帮助。然后其实有趣的是，你提到了 Claude for……就是我对小企业的热情，在我拜访了几家之后，我们现在推出了 Claude for small business。这真的很酷，而且完全不是我推动的，所以我不会邀功，但我也注意到了。比如我和她们合作时，她们会问我，哦，它有没有这个插件，那个插件？我说应该有吧，然后我们就得去搜。所以现在 Claude for small business 把所有这些都打包好了，在 co-work 里面你只需切换一个小开关。有一个很棒的团队一直在和小企业做 co-work sessions，她们可能发现，嘿，我们在这里可以提升效率，或者说改善体验。所以我想说，永远要……不光是你负责的产品，要确保你始终在倾听反馈，持续迭代，努力打造令人愉悦、可靠、高质量的体验，同时还要留意，哦，出现了哪些其他用例，我们能不能也让那些体验更好？有趣的是，在软件行业我学到一点，客户使用你产品的方式可能出乎你的意料，不管结果是好是坏。所以最佳方式其实就在于不断迭代、学习，并紧密贴近反馈。等等，in demand。这个词在这档播客里出现过好几次。确实在。也许有点意思。所以本质上就是密切观察那些你可能没预料到的、或者正在逐渐浮现的行为。然后基本上就是在这方面大力投入，探索它，构建一些东西。对。而且要对这种现象提出假设——因为实际上，当你看到人们费尽心机让某个东西运转起来时，你能不能把它变成一个更顺畅、更好的体验？是的。回到你们团队的运作方式上，你们一直处在技术可能性的最前沿。工程本身的角色已经发生了巨大变化。我很好奇，你认为工程领域下一个前沿会是什么？是代理集群之类的吗？还是别的什么？就是说，工程师工作方式的下一个重大转变是什么——是你们已经在做或正在实施的，还是刚刚起步的？我觉得我们正更多地转向 async，也就是异步。所以正如你所说，代理集群之所以有趣，是因为以前我基本上是同步地写 prompt，然后可能会异步地触发不同的 prompt。但现在我可以设置一个 routine，让它为我生成这些 prompt。所以抽象层级似乎在不断提升。我真希望能有个水晶球，看看这会变成什么样。一年后咱们再来回顾，应该会很有趣。不，我想多听听这个。所以帮我们理解一下，routine 是什么？你说的异步又是什么意思？你写了一个 prompt，然后它就自己跑出去了，是立刻就开始写了吗？说说这到底是什么样的。嗯，对，routine 就是你可以……如果你还记得，我以前每天早上端着咖啡醒来，然后让 Claude 帮我浏览 Slack 频道。但现在我设置了一个 routine，让它每天早上固定时间自动运行。嗯，没错。然后它就能代表你去触发代理。因为你知道，以前你可能会用 cron job 来做自动化，但现在的情况是：看看这些反馈，如果你发现一些 bug，有哪些打磨修复可以顺手解决，然后它就会自动去处理。我醒来时就有 PR 可以审阅了，而不是以前那样，虽然也有不同的代理在跑，但我还得自己想：好，拿到这些信息后我该做什么？所以现在抽象层级更高了：我要怎么写一个 routine，让它基本上能帮我生成 prompt，去派生不同的代理？所以我觉得我们会更多地转向这种异步的工作方式。太有意思了。所以某种意义上，作为管理者，你每天都有一些例行事务。你说的就是，你可以设置这些 prompt，每天自动检查那些你本来会做的事：项目进展如何？什么落后了？我该疏通什么障碍？谁遇到了困难？怎么改进一些细节打磨？所以你描述的想法是，把管理者每天几乎都会做的事写成 prompt，让 Claude 本质上帮你做了，然后向你汇报：我在做这些，这些是你要审阅的内容。而且甚至在某种程度上给它更多自主权。你知道吗，就是放手让它干。比如，如果验证机制很可靠，那就去干吧。明白了。所以你给它一点自由，让它做更多这样的事。对。这太有意思了。这让我想起——说到“放手去干”这个想法，我本来没打算聊这个，但我刚看了 Tyler Cowen 一个很棒的演讲，讲的是正在发生的事。不知道你认不认识 Tyler Cowen，他是个非常聪明的经济学家，也做播客。他提到，现在人们常说，世界上做得最好的人，他用的词是 initiative（主动性）。他们有主动性。另一个人们常用的词是 agency（能动性）。人们经常听到这个说法：似乎做得最好的人总是最有主动性、最积极、最有能动性的。这有没有让你想到什么？就是人们可能需要思考或改进些什么？其实你说的这个词就是 agency。这在 cloud code 和 code work 团队里是我们非常看重的。但有意思的是，我会把它和 high 连在一起说，因为对我们来说，面对一个问题，团队里每个人都会有解决思路。所以这就是 high agency（高能动性），而伴随高能动性的还有 high accountability（高问责制）。关键在于确保大家有自由去发挥、去折腾，但同时也要明确相应的责任。这又回到你要解决问题的假设是什么。所以我觉得，agency 和 accountability 之间的平衡，或者说几乎是一体两面，对我们团队帮助很大。这太重要了。有能动性。好的，大家都在忙着做事，但等等，你到底搞砸了什么？你做出了什么？顺着这个思路，感觉最近有一种氛围转变：从 token maxing（疯狂消耗 token）——就是拼命花钱，看看极限在哪里——变成了：等等，我们到底得到了什么？这花了多少钱？ROI 是多少？有意思的是，Boris 之前在 Meta 担任负责工程生产力的产品负责人，他的工作就是衡量工程生产力。还有最近关于代码行数之类代码产出的讨论——大家都在热议如何衡量生产力的提升，以及如何衡量 AI 工具投入的 ROI。你们有无限优势，因为在 Anthropic 工作有免费的 token。鉴于此，关于如何衡量当今工程师的 ROI，你有什么心得？工程生产力是个非常迷人的话题。嗯，对，我记得就像刚才提到的，我们最初会从代码行数开始。然后那是吞吐量。我还记得有一次争论：某个工程师代码行数高得离谱，但他只是拿了个库做移植，然后提交上去了。于是我就想，那也许要看 significant lines of code（有效代码行）。但接着又说，万一我们在更新框架，生成的代码变少了，但产出其实一样呢？于是我又想，那也许该看 PR 的合并时间。但很有意思的是，无论用哪个指标，如果你真正关注的是产出……我的建议是，首先，产出是否真正导向了结果？因为 token maxing 有点像我们以前看代码行数那套，但我更关心的是，我们到底想达成什么？抛开这些不谈，我特别喜欢一句话：不要错把忙碌当进步。因为如果你度量的是工具使用量，那你实际上只是在度量动作本身，但这真的对你的最终目标有重要意义吗？所以我会尝试抽离出来，专注于我们要解决什么问题？有什么好方法能度量它？然后这才是我们主要关注的方向，而不是那种生产力度量。不过我想说，除了 metrics 之外，特别是在团队中，当越来越多人开始使用 AI 工具时，各位听播客的领导，我绝对建议你们去走一趟倾听之旅。我尤其喜欢关注高级工程师，听听他们觉得什么有效、什么无效，我们怎样才能真正做得更好，因为他们也会帮你在整个工程团队中放大和推广这些经验。而且有时候在对话中，你可能会被激发出新的想法，这也是非常好的共同学习，相比之下，metric dashboard 就显得很单薄了。这挺有意思的。我也从 metrics 中学到了一些很好的教训。我完全认同，当你有一个可以持续优化的 metric 时，这非常棒，但始终要记住——这也是我成长型思维的核心——它是否还在为你服务？要始终牢记，那个 metric 是否还在服务于你原本追求的目标。举个例子，在 Facebook Marketplace 早期，我们是按区域上线的，而且我们非常希望在扩张前确保打造出一款令人愉悦的产品。我记得早期我们会关注的一个指标是卖家数量。我记得在第一个区域上线后，我发现这个区域的卖家数量虽然不多，但实际上人们确实能找到他们想要的东西——而这正是我们的目标，帮助人们找到他们需要的物品。然后我意识到，那个区域虽然没有大量卖家，但存在 power seller。但我们之前设定的扩张门槛，原本会严重依赖卖家数量。我记得那次简短的对话——嘿，这就回到了那个道理：人们会以你意想不到的方式使用产品，所以要快速上线、快速学习。于是我们更新了 metric，意识到不应该只看卖家数量，因为这个指标没有考虑到 power seller 的因素。所以这就是我的建议：无论是生产力 metric 还是产品 metric，都要时刻留意，确保不要一叶障目，盲目追随一个曾经合理但现在未必适用的 metric，因为有时候环境变化太快了，metric 本身也可能需要调整。这就回到了你之前分享的那个流程：让 Claude 去查看每位工程师提交的 PR，然后不专注于 metrics，而是专注于由此引发的对话——这带来了什么影响？出现了哪些 bug？这是一种非常强有力的方式，去理解这位工程师的工作状况。太棒了。让我回到速度和质量问题，以及影响力这个话题。关于如何平衡这些因素，你还有什么其他的心得吗？现在代码生成速度快得惊人，要如何保证质量和影响力？对于其他那些每天都在努力应对大量 PR 的团队，你还有什么建议吗？我想说，这其实也是我们一直在努力做得更多、做得更好的事情。就是主动式质量保障。特别是在质量方面，要确保明确哪些体验是关键的，并且确保你真正有对应的 metric。这些能帮助你观察长期趋势，是非常好的事情。所以在质量方面，我们发现越是主动，就越能尽早发现质量问题。这也是我们一直非常关注的一点。所以我提出了一个概念：区分 bad 和 sad。bad 是指非常严重的、不可恢复的错误。sad 是指那种痛点，但可以恢复。不过有趣的是，当 sad 不断堆积时，通常也会演变成 bad。但即便如此，先建立这样一个高层框架是很有帮助的。因为有时候在 dashboard 上，你会看到加载时间或其他各种指标，但当你面对很多不同的产品界面时，很难判断“等等，这个数字到底好还是不好？”所以有一点对我们很有帮助：相比于只看原始的性能或可靠性数字，我们还建立了一个框架，来定义什么样的体验属于 bad，确保我们专注于解决这些问题，同时也留意 sad 的趋势。这对我们帮助很大。我喜欢这个 bad 和 sad 的框架。所以这有点像阈值：这属于 bad，好的，这很严重。那你们具体是在衡量性能、故障，还是其他什么？比如，我们赋予每个团队很高的自主权。大家都知道 bad 是非常严重的不可恢复错误。我们让每个团队针对自己负责的产品界面或服务来定义：什么是 bad？比如在 CLI 上，崩溃率可能就算 bad，因为崩溃了会丢失工作。而 sad 可能是“嘿，界面在闪烁？”虽然可能可以恢复。我们让每个团队自己定义……这也是为什么这很有意思，因为不同产品界面都不一样，以前我们虽然有很多 dashboard，但很难抽离出来看“等等，整体体验的主题是什么？”所以正如你所说，我们给予每个团队很高的自主权，让他们自己定义什么是 bad、什么是 sad，以及他们想要达成的目标。我听到的主要收获之一是，保证质量的最佳工具其实是监控和测试，而不是花更多时间去做 review，这很合理，因为速度太快了，根本跟不上。而且这几乎呼应了让 agent 自己闭环的想法——它们知道成功是什么样子，然后自己修复。所以一个很有意思的收获就是：多在测试上投入。Evals 应该也是其中一部分，然后就是监控故障、速度等等。没错。有件事我想是公开的。我知道你们有个 dashboard，专门追踪用户说脏话（F-words）的频率——
因为他们太愤怒、太沮丧了。我觉得这个还有个有趣的叫法，但我忘了叫什么。是的。其实我记得，那是去年九月，因为我们都看到了一些用户的 frustrations，然后团队里有个工程师说“嘿，也许我们应该追踪脏话。”我当时就想，哇这主意太棒了。我记得很清楚，因为我刚加入，我们正在进行那场非常有趣的对话。嗯，是的，所以这又很有意思，值得去思考。这也是为什么 Evals 很难做，因为它归根结底关乎用户体验，以及我们如何确保这是一种愉悦的体验，而不是令人沮丧的。不过，"脏话仪表盘"确实是个有趣的东西。本集节目由 Mercury 赞助播出。Mercury 是一家与众不同的银行，深受超过 30 万创业者的喜爱，现在更推出了 Command。我作为 Mercury 的客户已有六年多，从未想过要离开。Mercury 本质上是由产品人而非银行家打造的银行。 他们让开发票、转账、为团队成员设置虚拟卡变得极其简单，甚至可以说有趣。你的银行有 API、原生终端 CLI，或者支持 AI 的 MCP 服务器吗？我想没有。就在最近，他们推出了 Command，这是一个直接内置于 Mercury 的对话式界面，充当你的财务运营助手。我一直用 Command 来转账、查看自己在哪些类别上花钱最多、分析现金流，而且 就在今天，我还用它查了过去一年从某个特定赞助商那里赚了多少钱。我只问了一句， "过去一年我从 X 那里赚了多少钱？"十秒后我就得到了答案。 这太酷了。访问 mercury.com 了解更多信息，几分钟内即可在线申请。Mercury 是一家金融科技公司，并非 FDIC 参保银行。银行服务由 Choice Financial Group 和 Column N.A. 提供，二者均为 FDIC 成员。回到你的运作方式，以及你在这个疯狂的新世界中找到的工作方法上。我听说你推行了几个相当独特的做法，我认为这在团队运作中非常特别，而且对你来说效果很好。其中之一是让每位管理者都从 IC 做起，并且每位管理者都必须继续兼职做 IC，有点像"球员兼教练"的模式。谈谈这个做法，以及为什么它在当今如此重要。是的，我很喜欢这个做法。有趣的是，我刚加入时——我有非常棒的招聘合作伙伴——我注意到我们当时围绕"成长型思维"有一个整体主题。这仅仅是因为行业格局变化太快了。以前行之有效的方法现在可能不再适用，甚至今天有意义的东西明天可能也需要改变。这就是我一直在提醒自己的。所以，我刚加入时，招聘人员说："好的，我们有几位 manager 在招。"我说："你知道吗，这实际上源于我对团队所有成员做的一次倾听之旅。我听到很多人说，'嘿，我很欣赏这种自主权，但我如何确保优先级呢？'通过那次交流，我意识到了这一点，而且还有一些很好的反馈，比如要确保不要设置太多层评审。大家给出了很好的反馈。有些人可能从其他公司带来了一些想法，然后我就想，'嗯。'实际上，我认为作为领导者，如果你先以 IC 的身份起步，暂时不用担心带人——因为那是很重的责任——但在承担这份全职责任之前，给自己留出创造者时间，深入地去写代码、学习代码库，或者了解产品，随便什么。说实话，我做的那些 PR 其实……但对我来说更重要的是，这能让我保持手感，因为我们在协作和代码方面做了太多改动。所以即使我做 PR，重点也不在于我在修复什么，而在于我每天都在使用这个产品，保持那种接触。因为尽管指标和各种仪表盘都很棒，我也确实会看，但如果你作为领导者不是每天都在切身使用和感受自己的产品，你有时会失去对产品触感的把握。不过话说回来，在管理者方面，我认为应该给新加入的管理者留出时间，让他们在带人之前先深入做这些事情。这样他们实际上最终能和团队建立起非常好的关系。因为如果不这样，我觉得有时候作为管理者，你加入新团队后会立刻想：'我得管理了。让我翻开管理工具箱，做一些管理该做的事。'但如果你给自己一点时间，先不用操心这些，而是先学习作为一名工程师和团队成员是什么感觉，这对建立关系也有很大帮助。至于使用产品，我觉得这很有意思。我加入的每个团队——实际上是所有不同产品，可能是 VR，可能是智能眼镜，也可能是 Instagram——通常我刚加入时，都会有人跟我说：'嘿，你知道吗？我真的很喜欢你真正在用我们做的东西。看到你给出用户反馈，真让人耳目一新。'所以我认为，作为领导者，这也是我们亲身感受团队所做工作的一种方式。有件事大家可能没意识到，你在加入 Anthropic 之前，在 Meta 管理着一个大约 500 人的组织，对吧？而离开那里后，你在 Anthropic 基本上是从 IC 工程师做起的。我一开始确实如此，不过只做了很短一段时间。但这也算是我从 Microsoft 到 Meta 的一段经历。所以在 Meta，我面试的是 manager 岗位，但我认为至少在前一个季度，我也同时是 IC，因为我真的很想了解作为一名 Meta 工程师是什么感觉。在此之前我在 Microsoft，基本上是在那里磨练工程技能的。所以我对所有的代码库、工具、语言都很熟悉。但能有最初那几个月真正学习作为一名 Meta 工程师去交付代码，这非常宝贵。而且这也很有趣。我觉得有时候我们忘记了……顺便说一下，这正是我喜欢 Claude Code 的原因。因为我上一次交付生产环境软件可能还是在 2017 年。每年我都会做很多 dogfooding，也……我用 dogfooding 来帮助自己评估产品质量。但已经过去很久了，我没有再交付过生产环境软件。部分原因是我不想搞砸。我总是很害怕：万一我做错了什么，引入了一个 bug，或者我没有正确验证，又或者我在浪费别人的时间怎么办？因为工具流程也会变化。但我记得在 Claude 的第一周，我一开始几乎又想按惯例行事——让我去见见所有工程师，请他们喝咖啡——然后我想，等等，让我问问 Claude。Claude 成了我非常好的入职伙伴，因为我对代码库很好奇，向它提问，而且它也真的帮我……做自动化测试，但我也想做一些手动测试。我问 Claude："嘿，帮我想想有什么方法可以手动测试这个，确保我覆盖所有情况。"所有这些让我有了信心：好吧，我又能 ship PR 了。然后我又慢慢变得更自如了。所以实际上有很多当了很久管理者的朋友联系我，说："嘿，多亏 Claude，我又开始写代码了。"
总的来说，作为领导者，确保你在使用团队打造的产品，这对我来说很重要。很有意思的是，你作为工程负责人，带领着一支最能改变工程师角色的团队。这是一个非常 meta 的角色。工程师的工作正因为你们打造的软件而发生转变。沿着这个思路，我想问：你会担心工程师的编码技能因为不再亲自写代码而退化吗？这重要吗？你会思考这个问题吗？这是件大事吗？有意思的是，我们团队内部确实讨论过这个问题。比如，我们是不是会遗漏什么？或者说到你提的这一点，我一直在想新人入职和成长的过程。像 Boris，他早期亲手写代码，当然现在不写了，但他之前之所以具备那些知识，是因为他深入过代码库。所以，尤其是对新加入的工程师，我也一直强调要确保你花时间在你做的所有工作中，仍然去理解架构或变更，因为这又回到了“信任但验证”的原则。也许有一天这不再重要了，但按照我们目前的节奏，我仍然认为要去理解——要始终对你所依赖的那一层做 double click。对我来说，这或许是一种 meta 能力，因为始终要花时间去了解你的 dependencies，这样当 dependencies 发生变化时，你会更敏锐，或者也能利用 dependencies 的更新。所以我认为始终要去深入那一层。另外，Claude Code 团队还发现一个有趣的现象：过了一段时间后，我们开始感到这可能是一种孤独的体验，因为大家都开始只和自己的 agent 工作了。所以最近我们开始搞一种 pairwise programming 午餐。因为我们在 Claude Code 上也发现，每个人使用 Claude Code 和 co-work、每个人使用 flow 的方式都大相径庭。于是我们意识到，哇，当我们做 pairwise programming 时，实际上能从彼此身上学到很多。另外还有一点，我们也确保大家有共处的时间。比如，hackathons 就是我们很喜欢做的另一件事，以确保我们作为一个团队保持互动。这说得太好了。就像那种孤独感的产生，是因为过去常常是团队一起写代码。有人做后端，有人做前端，有人做 iOS 应用。后端可能还有一群人。然后现在呢，如果有 10 个 Claude 在并行运行，做所有这些事。所以想办法让工程师们保持连接，真是个好主意。所以这个点子有点像结对编程，但又不是。它更像小孩子成长时的平行游戏。你们坐在一起工作，但各自做各自的东西。不过，光是观察别人怎么搭建，你们就发现这非常有价值。是的，而且我们自己的工具链变化也非常快。不过，确实很有意思，我们团队每个人使用 Claude Code 和 co-work 的方式都各不相同。所以每次我看别人工作，自己也能学到东西。你怎么看待大家对优化自己工作流过度着迷这件事？有没有什么时候你会说：“好了，没问题，继续往下做就好”？你知道，我们团队里倒没太多这样的人。我觉得大家只是对架构升级——比如我们认为能提升可靠性的架构更新，或者某些产品体验——感到非常兴奋。所以大多数人经常聊的都是这些。对，我们不会过度优化，这是午餐时有趣的话题，但我觉得我们不会过度优化，因为实际上并不存在完美的答案。要做的事太多了。还有什么……这些洞察真的很有意思。就像随着角色转变，有得有失。所以我很好奇，在这个软件工程的新世界里，还有什么东西正在流失。我以前也是工程师，不知道你知不知道。我做了 10 年工程师。那时候光是坐下来进入 flow 写代码就很有趣。你懂这种感觉。就像：“哇，跑通了。看，它编译成功了。太棒了，我在进步。”而现在你不再这样了。你只是坐在那里，等着 agent 把东西搭出来。还有什么？对工程师来说，这个新世界还有什么东西正在流失？是啊，特别有意思。我刚和团队里一位工程师聊到过 flow。就像，记得以前吗，你碰到一个特别棘手的问题，戴上耳机放起音乐，然后就进入状态了。所以，确实有一点……而且最后总会有那种顿悟的 aha moment。我记得。就像……对，你记得那种终于破解难题的感觉，那种“耶”的兴奋。所以我们确实会怀念，但我觉得现在我们从产品中获得了很多乐趣。不过我也听到其他工程师说起，我以前最享受的部分恰恰是那些最难的部分。对，我也听另一位工程师这么说过。所以我想我们都在逐渐转变。但我确实注意到——这也是为什么我之前提到 pairwise programming 和 hackathon——最近越来越多人开始觉得，这正在变成一种孤独的体验。太有意思了。在 Anthropic 内部，我觉得工程是目前变化最大的角色。那第二变化最大的角色是什么呢？你觉得在 Anthropic 内部，与一两年前相比，哪个角色的变化最大？所有与编码相邻的角色都在转变。比如 PM，我知道你和 Kai 聊过。我觉得 PM 的变化也相当大，因为 PM 不再受限于工程人力——如果他们有个想法，不用再等着排工程资源了。所以这是我看到接下来在转变的角色。实际上，我们的 PM 也会挽起袖子帮我们推动一些功能，当我们想做某件事而工程师抽不出身的时候。所以我想所有与编码相邻的角色都开始转变。但这也是验证变得重要的原因——当有更多不同学科的人参与检查时，我们如何确保大家都有很高的信心。我也觉得我们需要在自动化工作流的其他环节上做更多。当然，我们目前很关注编码，但接下来，当你想到设计或数据科学，这些正成为下一个领域，我觉得有机会去看看我们如何能在那些方面也开始提升体验。是啊，说到数据科学，我有个做数据科学的朋友，他就在说现在数据科学变得太不一样了。现在他们大部分工作就是别人用 AI 做一些不怎么样的数据科学工作，然后拿给数据科学家看：“喏，这是我做的分析，你能帮我看看对不对？”结果有一半时间都是错的。所以这份工作现在完全变了个样，不再是他们当初想做的那种工作，而是：“好吧，我整天就在审阅这些 AI 做的数据科学工作。搞什么鬼？”
顺着这个话题，回到团队运作方式以及变化上，让我想想怎么组织这个问题。现在的工程经理应该对团队抱有什么样的期望，与几年前相比？正常运作的基线期望应该是什么？除了我们交付得更快之外，还有其他什么吗？哦，有意思。嗯，我觉得现在大多数 commit 都是 cloud assisted 完成的，这是一个转变。嗯，就像我之前提到的，我们有 Slack 频道收集所有反馈，还有我们的 dashboard 也接入了云端。我认为让工程师持续培养更强的产品感，这也是……我觉得这也是另一个方面，而且总体上这有助于培养出真正有强烈产品思维的工程师。我想说，很多传统上不属于工程领域的角色，现在你会看到工程师也在涉足；而有时候你本来会被卡住，比如在等跨职能合作伙伴。我觉得现在这种阻碍变少了，因为模型能够增强你作为工程师可能不具备的额外能力。所以这很有意思，这是双向的。工程师变得更有产品思维，对产品的质量和成功负责，而与此同时，每个人也越来越像工程师了。是的，没错。界限越来越模糊了。是啊。我忘了是谁说的，但有这么一种说法，现在岗位到底是什么？那人说，就看你平时做的平均事项是什么？你做的所有事情里占比最高的是什么？那大概就是你现在的角色了，不管它最终会是什么。嗯。哦，对了，我想回到你之前说的那个点，就是你对产品那种痴迷——全身心投入、与之共呼吸，也就是 dogfooding。我跟很多和你一起工作的人聊过你，提到最多的就是你对沉浸于产品、时刻使用自己正在做的产品的那种痴迷，不管做的是什么。聊聊为什么这如此重要，为什么你会把它灌输给你的团队和下属。哦，我很喜欢这个话题。嗯，是的，我觉得这真的……而且这对我很管用，它让我能够随时把握脉搏，因为任何时候你做产品，背后都有一个愿景。你真的希望实现某种体验，或者让某种体验变得更好。所以，我认为……这样能帮助我紧跟产品的脉搏。我觉得，呃，也许……肯定是在 Visual Studio 的时候，我培养起了这种热爱。但有趣的是，即使在 Marketplace 上，我记得偶尔还会这么做，其实离开那个团队之后也是。有一次我有一台 MacBook Air，想卖掉旧的，你知道，我从没在 Marketplace 上卖过东西，那我就试试吧。结果简直难以置信，我刚挂上去，就有个卖家或买家试图骗我，那是一种我此前没察觉到的、很有意思的新型诈骗手段。但这再次说明，人们使用产品的方式可能出乎你的意料。所以，尤其是作为领导者，或者团队里的任何人，我们每个人的生活……其实挺有意思的，当时我支持 VR 和 AR 团队的时候，不知怎么回事，我在使用 VR、进行设置时，总能发现一些非常奇怪的地板高度问题。最后这就成了……我就想说，我来帮大家，因为不知怎的我刚好能复现这个环境。所以，我认为这是第一要务，就是这样你才能把握住自己做的产品的脉搏，而不是只迷失在指标、dashboard 或演示文稿里。我觉得你说的这一点非常重要，我想确保大家都能听到，就是一直以来都有这种讨论，轶事证据、个例与数据之间的对比。而你在这里想说的是，作为产品负责人、工程负责人，你正是在这些轶事、这些你作为用户亲身体验到的具体小事件中获得了很大的成功，而不是只痴迷于数据。是的。而且实际上，有时候这也是我能够最有效帮助团队的方式。比如，我带的上一支团队，我在带一个 VR 团队，当时因为……那时候我……我其实没往那个代码库里提交过任何代码，因为我真的很担心把操作系统搞坏。但缺了什么呢？我们在做很多打磨修复，我就想，"嘿，你知道吗？我就用 dogfooding 的时间来真正审视一下体验看起来怎么样。" 所以，这可能也是我觉得仍能做出实质性贡献、帮团队守住质量门槛的一种方式。而且就像我说的，团队每个成员通常都非常感激，因为我觉得……作为 lead、作为 leader，你在支持团队里的大家，除了指标之外，每个人都非常想确保自己的工作是有价值的。所以，确保领导层也在用你的产品，我觉得大家会感受到领导层仍然非常投入，而不会太……我……
这和你说的工程师需要变得更有产品思维那个点非常契合。工程师需要变得更像 PM，PM 也需要变得更……但作为一个工程师，这就是一种方法。持续使用产品。这会帮助你从用户的角度理解产品缺了什么，因为你就在用它。没错。而且我想说，如果你带的团队很难让你亲自去用产品，那就去见客户。不管是什么其他途径，我觉得这对你也一直很重要。每次我去拜访客户，总能学到新东西。比如，我记得当时我们在尝试把 Facebook Marketplace 推向拉丁美洲。我们在智利做测试。我记得它的表现就是不如我们之前做的其他区域好。其他办法我们都试过了。然后我记得……我们组织了一次很小的调研之旅，我去了智利。我记得给我们弄了一堆 Android 手机。团队很小，就我们三个人。一下飞机，我一打开这些 Android 手机，就发现，啊，你知道，LTE 连接比我们在美国习惯的速度慢多了。然后我就意识到，哦，Marketplace 的信息流在这种 LTE 环境下根本加载不好。这简直是多大的增长阻碍啊，你连加载都加载不出来。但这也是为什么说，始终倾听客户反馈、建立快速的反馈循环，是如此重要。我记得是 Jeff Bezos 说过，如果你既有数据，又有一个轶事，那就相信轶事而不是数据。挺出人意料的。你这个例子很棒。好，呃，再问几个问题。一个是，你在演讲最后有一张很有意思的幻灯片，讲的是你现在正在重新思考哪些问题，因为变化太快了，你还没想明白怎么解决。我来念一下这三个问题。我好奇现在还是这三个吗，还是有什么其他我们在运作方式上尚未解决的当下问题。你当时分享的是：我们是否仍然需要独立的 iOS 和 Android 组织架构？全自动化的审查能推进到什么程度？以及，在角色模糊化的情况下，如何确保每个人的产出同样高效？这些问题还在吗？你还有什么觉得是“我们得攻克这个，目前还没有想明白”的问题吗？你知道的，iOS 和 Android 这块。我觉得我们其实还在摸索。说起来挺有意思的，因为我谈到的是深厚的专业知识。我们确实觉得非常重要，非常有必要继续引进具备这些专业知识的人才，但因为现在大家都能身兼多职，我们可能不需要以前那么大规模的团队。所以还是要确保我们有 Android 和 iOS 方面的专家，但不需要像以前那样庞大的移动端组织架构。不过这仍然是我们试图把握的平衡：我们有没有恰到好处且足够多的 expertise？嗯，第二个问题是……抱歉，第二个是什么来着？哦对，是“自动化审核要做到什么程度”。啊，对。这其实是个有趣的话题，你知道的，关于内容设计检查。我觉得我们在所有环节中都在寻找：到底什么才是“好”的标准？实际上，验证这块仍然是我们……我觉得这算是第二和第三个问题，我们认为那里还有很多机会。但关于要做到什么程度，我认为得看哪些方面专家仍然不可或缺，同时也要不断问自己：有没有办法利用我们的专业知识去实现自动化？我觉得从整个端到端的体验来看，要确保我们没有遗漏什么。我们是从工程角度出发的，但要确保在体验层面也能覆盖到其他领域。我觉得我们在这方面肯定还有很多可以做的。本质上就是，如何建立一种验证机制，来确认体验确实达到了你想要的效果？没错。而且我觉得这仍然是个很难攻克的难题，因为你之前也提到了 eval 用例。一部分确实是准确性，但也关乎体验。嗯，这是我们还在思考的问题。太棒了。还有没有其他最近发生变化、需要我们重新思考工作方式的问题？还是说主要就是这些？我觉得，因为日常工作流程和所有事情都越来越异步，上下文切换的负担开始变重了。因为我甚至记得我自己也是，比如我发起了一个……发起了一个……所以我觉得这可能是另一个需要思考的问题：无论是对团队成员还是用户，我们如何优化体验来减轻这种负担？因为我确实看到上下文切换的负担在增加。我能想象，如果你在跑 20 个 agent，那就得不停地检查和 review，还得记着自己当时在做什么。这就像是一个非常有趣的世界，就像我们之前聊的“心流”——工程师和大多数人以前能连续专注好几个小时，现在这种情况变少了。但现在 agent 可以提醒你：你进行到哪一步了。切换后的重启几乎变得更容易了，因为你不需要重新学习所有东西，不需要重新理解代码库和架构。你可以直接说：行，这是我们正在做的事。这似乎是变好了，也变糟了。嗯，有意思的是，我以前会专门留出专注时间，比如编程的专注时间，因为需要那种不受打扰的状态，然后再处理上下文切换。有趣的是，现在因为我可以借助更多异步的 agent 进行更多上下文切换，我反而发现需要重新划出一段专注时间，来跟进我发起的各种异步工作。是啊，对此你有什么解决办法的思路吗？因为这很难。人们就是想越做越多，但怎么才能在不停上下文切换的情况下做到呢？这真的又难又烦。是的，我同意。我确实也还没想出办法。太有意思了。对了，我们聊着聊着我想到一个问题，我特别想听听你的看法。我本来没打算问这个，但现在太重要了，就是关于 AI 和招聘。有意思的是，你可能会以为 AI 会让工程师变得不那么必要。但另一方面，感觉你们在疯狂招聘工程师，OpenAI 也在疯狂招聘工程师。就是对工程师的需求好像特别大。你觉得这会往什么方向发展？你怎么看工程师这个角色未来的前景？这是个很大的问题，但随便聊聊你的想法。我在这里说点掏心窝子的话。首先，说到这种重大的开放性问题，我确实在思考我们如何培养下一代工程师，因为你我走上工程道路的方式已经完全不同了。现在从学校毕业，几乎就像是要怎么给它加速。但对我来说重要的是，他们仍然要能理解，你知道的，我之前说的那种“双击”深入到底层的能力。嗯，这是我的一大疑问，我希望自己有答案。我在想，对于软件工程来说，未来是不是会更像 fellowship 或学徒制项目？我知道这很难，因为严格来说我们现在有实习，但那些都是三个月左右的小项目。我确实在想，而且我希望自己有个水晶球能预知未来，但 yeah，就像是，你怎么才能把……也许这不会那么重要，但怎么说呢，我们积累的那些人生经验，你怎么才能把它们传授给下一代 builder？对，如果你永远不需要看代码，那对于新入行的软件工程师来说，真正去理解基础设施如何运作、内存分配这些东西的动力在哪里？而这些都是基础性的知识。而且这很有意思。也许模型会变得足够好，好到这些都不再重要，但我确实觉得……
嗯。你知道，但我确实觉得那种深入探究的能力很关键，因为我觉得那里可能有优化产品或系统的机会。但问题是，如何学会这种能力，却不一定非要通过……你知道的……多年的……
敲代码。对。是啊，总得有人在某种程度上理解代码。就像有一天可能得把某个退休的 COBOL 工程师请回来，问他：“你还记得怎么写 Python 吗？”
你知道吗，特别有意思。我以前的一位经理，他做软件工程师那会儿还是打孔卡的时代。这太了不起了。他一直在给我发消息，讲他用 cloud code 做的各种东西。我当时就想：“哇，这职业生涯太传奇了，从打孔卡一路走过来。”他真的见证了整个行业的变迁。所以我觉得，对我们来说，想想他的职业生涯，他当年从打孔卡起步，和现在也完全不同。所以，也许……我觉得我们会看到什么依然重要，什么的重要性发生了变化。然后就是，你怎么去掌握……我有一种理论，也许关键的是，什么重要这件事本身会随着时间改变。然后你怎么围绕它建立专业能力。哦对，去学那些真正重要的东西就行了。我经常听到的一种说法是，这就像是一种新的抽象层级，就像 assembly 和 binary 一样，层级不断向上攀升。到现在，我们甚至不需要去看代码了。这就像是 prompts、Claude 的 thinking，还有 messages 构成的一个新的抽象层。是的，而且这也引出了一个问题：什么才是有趣的问题？构建体验时的优先级该如何排序？这很有意思。也许我们有点……对了，当你构建东西的时候，怎么知道它真的引起了共鸣？它是否真的按照你的意图在运作？而且这是不是真的好。就是说，我们是在做一堆 slop，还是说这确实是能运转起来的架构 ？不过我认为年轻人的优势在于，他们更容易全身心投入并以这种新方式工作，而不是被困在旧有的模式里。像您这样的资深工程师能够适应并拥抱这些变化，这很罕见，也让我很惊讶。要改变一切真的很难。好吧，那就做吧，全部改 。是啊，因为变化的速度也太快了。其实，这正是我想起的一件事，我记得第一次用的时候，应该是 Sonnet 3.5 或 3.6，当时我正在做一些副业项目，它还会犯一些错误。我当时就想：“你在干什么？”然后我注意到，有些抗拒 AI 工具的工程师会说：“啊，但是你看，它还是会出这些错。”但我觉得他们很难理解这种指数级的改进速度。所以，也许这也是我自己一直在学习的另一件有趣的事。可能之前我尝试让 Claude 自动化的某件事，当时它还做得不够好，但到了下一个模型，哦，现在它够好了。所以我们也应该时常去想那些之前没做成的事。也许值得花时间回头再试试，因为现在它可能已经具备了新的能力。是的，这个播客里也经常提到。就去构建那种几乎能跑起来、处于前沿的东西，因为一旦模型能力达到了，你就会遥遥领先于其他人。好了，最后一个问题。可能您刚才已经回答过了，但还有什么事会让您睡不着觉？让我睡不着觉的事，可能是我们……您知道，我们谈到了 Claude code 和 co-work 团队文化。团队文化对我来说非常重要。就是那种“一个团队”的心态，我也会跟大家反复强调。顺便说一句，文化是一个活的东西，不是往墙上一贴就完事的海报。它会随时间变化，体现在我们如何对待彼此、如何在彼此需要的时候互相支持上。所以团队文化对我很重要，因为我们在成长，而文化会发生变化，要确保那些重要的东西得以保持。对我来说，拥有多元化的视角仍然非常重要，这样我们才能公开地进行健康、坦诚的辩论，我们也欢迎这种辩论。我所说的“一个团队”心态，就是当你接近终点线时，要回头看看有没有队友需要帮忙，因为我们要作为一个团队一起冲线。这可能就是让我睡不着觉的事。当然还有很多其他难题，但其他很多可能是产品或工程上的挑战，我们有仪表盘、有理论、有假设。而文化是一个关乎人的层面……我觉得这是我最想确保的：随着我们成长，我们仍然要保持那种文化，因为它是团队的根基。当它开始漂移时，我总是担心，如果它偏离了，我们能不能及时发现，并作为一个团队一起沟通，确保我们都希望文化朝着正确的方向发展。是的，我想每个人都在为此挣扎，考虑到变化的速度和招聘的速度，尤其是像 Anthropic 这样的公司，正经历着历史上最前所未有的增长轨迹。我能理解在这么多变化下这确实是个挑战。所以这也说得通，就算是我当时在 Airbnb，那也算是一个相当快的增长轨迹了，但跟你们现在经历的根本没法比。当时我们也在不断讨论：该如何保持文化？其实我很好奇，您在 Airbnb 时在保持文化方面有什么经验？有两点。一是创始团队对此非常痴迷，每次 all hands，每次大型会议，都会不断提醒大家文化的重要性、文化的价值以及我们的价值观是什么。创始人自上而下地痴迷于这件事，这是非常重要的部分。几乎不可能开一次会而不提到这个话题。另一点是我一直记得的一个回忆：我们曾经请 Sheryl Sandberg，当时她在 Meta，来做一个 fireside chat。有人问她：在快速扩张时如何保持文化？因为我们发展太快了，要应对这么多变化、文化冲击和这么多新人，实在太难了。她的建议是：这其实就是你希望遇到的问题，因为这意味着你在成长、做得好，这是正常的。相反，如果你做得不好，什么都不会改变——那才是最糟糕的情况。当你不再增长，不再疯狂招聘时，情况会糟得多，会带来更多甚至更深的痛苦。所以她说，这是一个好问题。这个建议一直让我印象深刻。哦，这太棒了。说到这儿，我觉得在 Claude code 和 co-work 团队里有一点很重要：无论是 IC 还是管理者，但我们团队里的管理者尤其需要做到——我们当然要聊进展顺利的事情，但也要坦诚地说哪些方面进展不顺。因为如果我们能真正去讨论什么做得不好，我们才能着手解决它。说到让我睡不着觉的事，我的噩梦是：如果某个管理者跟我说“嘿，最近怎么样？”他说“一切都好”。我就会想，天哪，我可没觉得 一切都好。我知道事情其实是……就像那个梗图，房间里着火了，猫医生却淡定地端着咖啡杯。这就是我的噩梦。所以这是我和团队里很多人，尤其是刚加入的管理者，都会进行的对话：嘿，让我们始终保持这种开放的沟通，这样我们才能一起解决问题。我想很多人都在为此挣扎：看到周围所有人都做得特别好，至少表面上看起来做得很好。一切都好极了。我在经营一家很棒的公司，或者诸如此类的。在这种情况下，你很难诚实地说“其实不太好，我在这里很挣扎，我掉队了”，因为你周围的每个人表面上看起来都干得风生水起。嗯。是的。在我们进入非常精彩的快问快答环节之前，您还有什么想留给听众的，或者我们没聊到的，又或者您觉得很重要想分享的？有件事只是个建议，因为你知道我们聊过 Cloud 如何实现自动化。另外一点在 Cloud Code 和 Core 团队文化中非常重要，那就是明确允许砍掉那些不再有价值的流程。所以我想给任何在我们团队工作、或者带领团队的人提个建议：想想有没有哪个流程是你特别抵触的、特别冗杂的、或者成本很高的——要耗费大量精力——又或者非常手动的。挑一个出来，首先问自己：它现在还起作用吗？比如我们之前的规划流程。实际上，这是我刚加入 Cloud Code 时学到的重要一课。我当时想，也许我们应该做一个六个月路线图文档，但要做得非常轻量，因为我不想在规划上浪费太多时间，而且我觉得我们的流程已经很轻量了。但这给了我很好的教训，因为这个练习确实有助于开启对话、确保大家方向一致，但三个月过去后，我就想：等等，我们还有在参考它吗？因为形势变化太快了。这也是我自己引入的、以为会有帮助的东西，后来却改变了。所以要始终保持开放学习的心态，不断问自己：现有的流程还在发挥作用吗？因为这个领域变化实在太快了。我很喜欢这个建议。我得快速跟进一下。那现在呢？你们怎么看待规划？还会做规划吗？只是一个月长度的路线图吗？能不能简单说说你们现在的做法？对，我现在称之为 JIT planning，也就是准时制规划。因为六个月确实太长了。现在虽然有些项目肯定要花一个月以上，但我们尽量只做一个月的规划，而且非常轻量。实际上，甚至没有文档，就是我们在一个小型电子表格上对齐一下哪些事情重要。但即便这样，我也在想：也许每周我们都应该保持一下——我们现在的尝试是，先定好这个月的优先级，然后去执行。但我有种感觉，每周可能都得快速确认一下：嘿，检查一下。对，这个月的优先级还是这些，很好。总之，我们现在把它压缩成了 JIT 月度规划。所以月度规划的意思是，为下个月准备一个小小的表格或 Excel 电子表格，列出我们计划做的事。然后每周检查一次：这仍然是我们下个月计划要做的事吗？对，就是非常……但即便这个，我也还在想：我们怎么还能进一步自动化？因为我不想让更新电子表格这种事变成一种负担。实际上就在昨天我们还在聊：嘿，我们怎么才能把这个自动化？总之，就是要不断问自己：这件事能不能自动化得更好？我这个产品经理的脑子就觉得，这不是理所当然该做的事吗？好的，这是我们下个月的想法。每周检查一次。确保方向一致，很难想象连这都不做。另外，我听说你们的电子表格上条目也不多。对，但我们真的尽量聚焦。所以我们会分享我们认为的最高优先级是什么。同样，为了赋予团队这种能动性，在明确优先级之后，每个人都会提出自己认为能对应这些优先级的具体事项。那有没有什么未来六个月的大赌注、大方向之类的东西？还是说真的只想一个月之后的事？我们当然会有一些关于工作方向的主题。实际上，整个团队每六个月会聚一次。在那种场合，我们通常启动一些大主题，但关键是要把握脉搏、紧跟变化，因为形势变化实在太快了，主题也会随之改变。好吧，把电子表格打开让我们看看。天哪。这整期播客本来可以就聊你们这套规划方法。好吧，我得找别人再聊聊这个，因为你们这种规划方式太有意思了。嗯，好吧。Fiona，说到这里，我们进入了非常激动人心的快问快答环节。我有五个问题要问你，准备好了吗？准备好了。好，第一个问题。有哪两三本书是你最常推荐给别人的？嗯，虚构类的话，有两位作家我会推荐给所有人：Margaret Atwood 和 Haruki Murakami。我在加拿大长大，小时候读了很多 Atwood 的书。她的书非常迷人，几乎像推想小说，你可以眯起眼睛想：这会不会真的发生在某个社会里？所以我很喜欢她对推想小说的诠释。Murakami 的话，我喜欢他的魔幻现实主义风格。不过，要说具体的一本书，我总是推荐大家每年至少读一次——《小王子》（The Little Prince）。我相信我们每个人一生中某个时刻都读过它，但我每年至少读一次，只是为了提醒自己思考什么才是真正重要的。哇，这个不常被提到。好，我喜欢。那你最近特别喜欢的一部电影或电视剧是什么？我没看过电视剧。这在我播客里采访的 Anthropic 员工中很常见，是个共性。但我可以分享几部一直存在手机里的电影，这样坐飞机时如果我有时间就可以看。有三部电影我一直在手机里，因为我觉得它们实在太有意思了。一部是《天使爱美丽》（Amelie），这是一部法国电影，天哪，顺便说一下这些电影都很老了，算是经典老片。但我超爱《天使爱美丽》，非常奇幻。所以强烈推荐给还没看过的人。你还记得我说过我曾经想成为一名视觉艺术家吧。16 岁时，我高中组织了一次去巴黎的旅行，我有很多关于那次旅行的回忆，而《天使爱美丽》真的捕捉到了我在巴黎感受到的那种魔力。另外两部是吉卜力电影。我很喜欢《千与千寻》（Spirited Away），我就是太爱那个故事了，我爱关于它的一切。这大概是我最喜欢的吉卜力电影之一。第三部是另一部吉卜力电影，《风之谷》（Nausicaä of the Valley of the Wind）。这部电影我想得很多，因为如果有人问我：你是怎么形成这些领导特质的？我觉得我大概八九岁时看了这部电影。女主角娜乌西卡，看着她如何领导，在我心里留下了深深的印记，可以说娜乌西卡启发了我很多不同的领导原则。哇，那部书叫什么名字来着？电影叫《风之谷》（Nausicaä of the Valley of the Wind），但实际上它是改编自一部漫画。
《风之谷》。所以，就像安迪·格鲁夫的《高产出管理》，《风之谷》的娜乌西卡。
（笑声）
没错。两本顶级管理书籍。太酷了。好。呃，你最近有没有发现什么特别喜欢的单品？可以是 App，可以是衣服，可以是小 gadget，可以是厨房用具。呃——
我来分享一个最近让我意识到它对我生活有多大影响的产品。呃，因为我最近一直在出差，而且我喜欢轻装出行。所以，我会用酒店提供的任何洗发水、护发素之类的。然后我忘了带……呃，那个产品……其实我手头有他们的一款……我保证这不是电视购物。但 Sweet Sisters Bodycare，你知道的，是惠德比岛上的一家本地企业。嗯，但为什么他们的产品对我生活影响这么大呢，是因为他们有一整套有机头发、身体、皮肤护理系列。但几年前，我开始在鼻子这里长皮疹，非常疼，真的会流血。我怎么也想不到办法止住。比如我试过不用任何乳液，把脸上所有东西都停掉了，可还是很疼。然后有人问我：“你用的是什么洗发水？”我说：“就是我从小用到大的那款啊。”他们说：“也许你的身体现在……而且那是很普通的、到处都能买到的棕色洗发水。”他们说：“也许你的身体开始对里面的化学物质过敏了，因为你一直用它。”
哇。我说：“什么？”总之，我找到了这款有机洗发水。结果你猜怎么着，我用了他们的洗发水，而且因为你一般不会想到，洗头的时候水流其实会流到你身体的其他部位。但从那以后，我把所有洗护用品都换成了 Sweet Sisters。嗯，但最近我又意识到这有多重要，因为用了一周的……对，酒店洗发水之后，我又开始出现一些皮肤反应。我就想：“啊，也许我应该买些旅行装的小瓶子带在身上。”
这个推荐太棒了。我喜欢推荐本地小企业的，特别加分。呃，顺便说一下，你这次出差——可能有些人不知道——现在世界各地都在举办 Code with Claude 活动。我去了旧金山那场，伦敦也办了一场，你还要去东京。这是最后一站吗，还是之后还有？呃，东京是……对，就在下周，这是这次行程的最后一站。然后未来可能……可能还会有更多。呃——
（笑声）
太酷了。很高兴这活动在进行中。好，还有两个问题。你有没有最喜欢的人生信条，在工作或生活中经常会回到它？哦。嗯，在工作中，我真的很喜欢提醒大家：保持简单。就是，你真正想要做好的那件事到底是什么，然后专注于它？你知道吗，就是保持简单，因为我觉得我们有时会想太多。嗯，所以，这样想总是一个很好的信条。然后在生活中呢，嗯，你知道的，大概是“在一个你可以成为任何样子的世界里，选择善良”。是的。我喜欢这句。我们之前去一所 Montessori 学校参观，老师就把它挂在墙上。啊。就是说，你知道的，我们自己已经有很多事情在忙了，你永远不知道别人正在经历什么，而一个小小的善举可能带来最大的改变。就像，嗯——
是啊。其实对我来说，就是……你还记得新冠吗？那时候我们都在家办公，就是新冠期间。嗯，这件事一直让我印象深刻，因为我当时连轴转地开会，而且一对一会议对我来说一直很重要，因为那段时间其实通常对对方也很重要。那是他们一直期待的事，他们可能有事情要讨论。所以我总是……我总是很重视一对一会议。呃，但那时候我奶奶身体不太好，她在加拿大的一家养老院，因为新冠我不能去看望，其实连我姑姑……你知道的，姑姑和妈妈也去不了。而且很难得的是，如果护工有空帮忙，我们才能 FaceTime。但你永远不知道那会是什么时候，因为你知道，要照顾的人太多了。突然我姑姑发来消息说：“奶奶今天下午 12 点左右可以 FaceTime。”我当时想：“糟了，我正有个一对一会议，而且是我一直想开的。”我就给……你知道的，我的下属发消息说：“真的非常抱歉，这么临时，请问可以……”我知道现在说起来好像不是什么大事，但对我来说信守承诺一直很重要。结果他说：“没事，完全没问题。”对我来说，那就是一个小小的善举。他完全没有小题大做，但这对我来说意义重大，因为我得以……你知道的，在 FaceTime 上和奶奶打招呼。我喜欢这个故事。
（笑声）
好。呃，最后一个问题。Boris Cherny，当我跟他提起你时，他有个有趣的观察，他说：“在非常重要的会议上，你经常能听到 Fiona……能听到 Fiona 在背景里织毛衣的咔嗒咔嗒声。”
（笑声）
呃，也许可以聊聊这是怎么回事，还有……（笑声）你最近织了些什么？哦天哪。嗯，我最近织了这件上衣。你自己做衣服。太不可思议了。这（笑声）对 Cloud Code 自己构建自己来说，真是太有 meta 意味了。你知道的，我们总是在构建自己的衣服。
（笑声）
是啊，其实我觉得织毛衣和编程之间有个特别好玩的地方，因为它就像两种针法，正针和反针，也就是零和一。而且，stacks 和 queues 之类的概念你其实可以……就像我有点像一台编译器。你知道的，我织毛衣的时候有点像在生成一个可执行文件。嗯，这个我就不好说了（笑声）。是啊，其实是我奶奶在我八岁的时候教我织毛衣的。我刚才提到过她，还有我……嗯……去那家毛线店，所以每次我织毛衣的时候都会想起她。嗯，而且你也看到了，我总喜欢同时做几件事。就像，对，我会启动多个 agent，所以任何时候我坐着，而且因为我练得够多，已经很熟练了，我不需要盯着手看。所以这几乎就像……你知道的，有时候人们会玩指尖陀螺之类的东西。呃，织毛衣就是这样，所以每当我静静坐着的时候，我就想，哦，这是该……你知道的，多织点毛衣的时候了。这很可爱。嗯，因为我买了太多毛线，如果不这么做的话……对，我的毛线……我可能有轻微的毛线成瘾问题。我喜欢这个。当我问 Boris，当 AGI 到来、我们不用工作时他会做什么，他说他会去亲手做点东西，所以我猜你的答案就是织毛衣、做漂亮的衣服吧。（笑声）
哦天哪，我的梦想其实是开一家以奶奶名字命名的毛线店，然后建立那样一个社区。然后 Cloud Code 可以帮你把一切自动化。没错。尤其是开票。
（笑声）
哦天哪。Fiona，你太棒了。你和你的团队所做的工作太不可思议了，正以如此深刻的方式改变世界，难怪发展得这么快。做得好。你们那边干得好。谢谢你抽出时间来做这个访谈。
Fiona：说实话，我真的非常幸运，也心怀谦卑，能够和如此出色的团队共事。我深知自己有多幸运，也非常感激。同时也非常感谢你邀请我来参加这档播客，这次对话非常愉快。
Lenny：接着问一个问题，如果听众想跟进某些内容，他们在哪里可以找到你？另外，听众可以怎样帮到你？
Fiona：嗯，我在 LinkedIn 上很活跃，我相信大家已经分享过相关信息了，但我很想知道哪些功能运行良好，哪些还不够好。另外，也欢迎大家分享你们正在使用的、可能是有趣用例的潜在需求。比如最近有个朋友发消息告诉我，他在用 Claude 帮他生成一个棚屋的建筑平面图，还实际给我看了他的棚屋，挺酷的。所以我很想听到这类故事。还有就是，也许正如我们刚才聊到的，向身边的人伸出援手——无论是你喜欢的小商家，还是你觉得还没有接触过 AI 的人，毕竟有些听众已经对 AI 非常了解了。也许可以花点时间，手把手地向他们展示 AI 能够如何帮助他们。
Lenny：这个建议太棒了。这是对这个问题非常精彩的回答，尤其是出自你之口，Fiona。这次访谈太棒了，非常感谢你的到来。
Fiona：非常感谢你邀请我，Lenny。
Lenny：各位再见。非常感谢大家的收听。如果你觉得这期内容有价值，可以在 Apple Podcasts、Spotify 或你喜欢的播客应用上订阅本节目。另外，也请考虑给我们打分或留下评论， 这确实能帮助其他听众发现这档播客。你可以在 lennyspodcast.com 找到所有往期节目或了解更多信息。 我们下期再见。