在关于 AI 编程的讨论里，外界最常关注的是模型能写多少代码、工程师效率提升了多少、AI 是否会替代程序员。但在 Anthropic Claude Code 与 Cowork 团队负责人 Fiona Fung 看来，真正的变化已经越过了“代码生成”本身。
Lenny’s Podcast 这期对话提供了一个少见的内部视角：当一个工程团队的代码交付量在一年内被 AI 拉升到原来的 8 倍之后，软件工程的瓶颈并没有消失，而是转移到了别的地方。写代码不再是最稀缺的能力，验证质量、判断优先级、衡量真实产出、管理异步 agent、保持团队文化，开始成为新的难题。
Fiona 领导 Claude Code 和 Cowork 背后的团队，并监管 Boris Cherny 以及整个工程和 PM 团队。基本上在这条业务线 / 产品线里，Fiona 是 Boris 的上级或至少是组织管理上的负责人。
在加入 Anthropic 之前，Fiona 曾在 Microsoft 参与 Visual Studio 和 TypeScript 相关工作，后来加入 Meta，创立 Facebook Marketplace 团队，并参与 Meta 智能眼镜、AR 眼镜以及 Instagram 基础设施、增长、安全等团队建设。超过 25 年的工程经历，让她既经历过从 Vim 到 IDE、从 CD 发版到在线发布的软件工程变迁，也正在亲身经历 AI 对工程组织的重塑。
这场谈话中，Fiona 具体讲到了 Anthropic 内部如何使用 Claude 管理团队输出，如何让 routines 在每天早上自动读取反馈、启动 agent、生成 PR；如何用 bad vs. sad 框架定义产品质量，甚至通过用户脏话频率观察挫败感；如何从 token maxing 转向 ROI 衡量，避免把工具使用量误认为真实进展；以及为什么管理者必须亲自 dogfooding，甚至先从 IC 做起，才能不被 dashboard 和会议汇报隔离在真实产品之外。
她也谈到了 AI 编程的另一面：工程师可能失去过去写代码时的心流，团队协作可能变得孤独，新人工程师可能跳过亲手理解架构和底层系统的阶段。与此同时，PM、设计师、数据科学家等角色正在被卷入编码工作流，工程师也被要求拥有更强的产品感。岗位边界不再清晰，团队运作方式也不得不随之改变。
以下为完整版对话，经 InfoQ 编译：
1 2026 年，一个被 AI “浸透”了的软件团队什么样？
Lenny：Fiona，谢谢你来参加节目。我之前在 Code with Claude 活动上听了你的演讲，当时就觉得必须把你请到节目里。你对 AI 和软件工程未来的思考已经非常超前。你做工程师已经 25 年了。我看了你的 LinkedIn，你最早是在 IBM，这和今天的软件世界已经完全不一样了。尤其是过去两年，工程师这个职业变化太剧烈了。大家可能都忘了，不久前 100% 的代码还是人写的，而现在已经越来越接近大量代码由 AI 生成。Boris 曾经说过，coding is solved。
Anthropic 最近还发了一张图，说 Anthropic 工程师平均每季度交付的代码量，相比 2025 年已经增长到 8 倍。你作为一个经历了很长工程周期的人，能不能回顾一下：在你的职业路径中，哪些关键时刻改变了你对工程工作的理解，也塑造了你今天的工作方式？
Fiona：我很喜欢这种回顾。最早我在 IBM 做 DB2，在操作系统服务团队。当时我的想法很简单：越靠近底层、越靠近操作系统，就越“硬核”，也能学到更多东西。所以我很幸运能进入 IBM 实习。
从 IBM 到 Microsoft，对我来说已经是一次很大的变化。在 IBM 时，我主要用 Vim，没有真正使用 IDE。可能当时有 Eclipse 授权，但我们大多数人并不用，更多是在终端里调试。
后来我加入 Microsoft。那是 2000 年互联网泡沫破裂之后，很多公司冻结招聘，所以我能拿到 Microsoft offer 非常幸运。当时他们告诉我会去 Visual Studio 团队，但我其实并不知道 Visual Studio 是什么。我来自一个偏 Unix 的学校，听到 Visual Studio 这个名字，我甚至以为它是不是一个更好的画图软件。我能看出经理当时脸上的表情是：“这是什么情况？”
但后来，Visual Studio 成了我职业生涯前 11 年里最重要的部分。那是我第一次真正使用 IDE，第一次看到调试器、断点、多线程调试等能力。那种体验对我来说非常震撼。
我在 Visual Studio 编辑器团队工作，用 Visual Studio editor 来构建 Visual Studio editor，也正是从那里开始，我真正喜欢上了 dogfooding，也就是自己深度使用自己团队做的产品。我们希望先为自己和队友创造非常好的开发体验。那个年代还没有今天这样的社交媒体反馈机制，工程师很难快速听到客户反馈。虽然会有用户研究、客户拜访，但没有今天这种即时反馈。幸运的是，在 Visual Studio 团队里，我们自己就是重度用户，因此团队内部就能形成非常快的反馈循环。
Lenny：大家现在讨论工程师角色变化时，常常只关注最近两年 AI 带来的冲击，但其实软件工程历史上也经历过很多重要变化。比如 Visual Studio 这类 IDE 的出现，本身就大幅改变了工程师的工作方式。你提醒了我们这些历史节点。
Fiona：是的。我在 Visual Studio 工作时，我们还会把软件刻在 CD 上发布。那时有非常硬的 deadline，因为软件必须准备好交给制造环节，再刻录到 CD，最后放到货架上销售。
后来，软件可以在线发布，这又是一次变化。过去工程时间是非常稀缺的资源，同时又有印刷 CD 这样的硬截止日期，所以大家会做大量规划，确保在有限时间里尽量把事情做好。
现在在 Claude Code 和 Cowork 上，我们看到的是另一种变化：Coding 不再是瓶颈。你刚才提到的那张图也说明了这一点。问题变成了：瓶颈转移到了哪里？现在不只是工程师在提交代码，Claude Code 团队里的设计师、PM，几乎所有人都在 check in code。提交代码的人更多，角色更混合，吞吐量也变得非常高。因此新的问题是：我们如何做 verification？如何确认这些高速生成和提交的东西是正确的、高质量的？
Lenny：这正是我想展开的主线。很多人都在想，未来的软件工程、工程管理、产品团队管理到底会是什么样子。你现在其实正在亲身经历这一切。你刚才提到一个更强的 Verification 需求，也就是说，当代码量增长 8 倍时，团队必须更关注质量和正确性。那我先问一个很大的问题：到 2026 年，一个真正 AI-pilled 的软件团队会是什么样？
Fiona：角色边界正在变得模糊，越来越多人会成为 builder。我最近做的一个变化是，我有一个 Claude Code remote session，会把它接入我们所有 repo。这样我可以全面看到团队正在做什么。这个实例也能访问我们的 Slack 频道，以及我们追踪的各种指标。
每个月，我会和团队一起回顾。我们会打开 Claude Code，一起看过去一个月的重点工作、哪些产品发布了、效果如何、反馈频道里出现了什么。以前我可能只是用这些 session 来生成 PR 或修 bug，但现在我也用它来帮助我和团队成员展开对话。
Lenny：也就是说，这已经变成了一种管理方法。它不是只帮助大家 ship，而是帮助你了解大家 ship 出来的东西有没有影响、质量怎么样。你会用 Claude 跟踪团队交付的内容，然后把这些信息变成和团队成员的讨论，对吗？
Fiona：对。重点不只是“有没有发出去”，而是它上线后的表现如何。有没有引入 bug？如果出了问题也没关系，我常说：make new mistakes。犯错可以，但要犯新的错误，这样团队才是在学习。
如果你的目标是完全不犯错，那可能说明你移动得不够快，或者太谨慎了。
通过 Claude，我们可以回看一些 incident，分析它们之间是否有共同主题。比如在质量方面，是否能看出某些热点区域，是否说明下一个投资方向应该放在这里。过去这会是一个非常手工的过程。回到一年前，我不认为自己能用 Claude 获得这些洞察。
Lenny：一部分原因也是以前大家没有 ship 这么多东西。过去可能简单列一下：“这个季度我做了这些 feature。”但现在交付量太大了，你需要新的方式来掌握团队成员到底在做什么。这条线索很有意思。你们的代码交付量增长了 8 倍，而你找到了一些方法来跟上这种变化。除此之外，还有什么方法能帮助你和团队保持质量、跟上所有正在发布的东西？
Fiona：反馈渠道对我们非常重要。以前我的早晨习惯是：拿一杯咖啡，然后看各种反馈频道，从里面找一些我能帮忙处理的点。如果我有 maker time，就会看看有哪些问题我可以直接帮忙，或者哪里存在明显 gap。
大概一两个月前，我们推出了 routines，这彻底改变了我的工作方式。现在我会设置一个 routine，把这些事情自动化。以前我可能自己写 prompt，现在有了 routines，就像有一个 agent 帮我生成 prompt，甚至生成 PR。
比如我会让它持续关注某个反馈频道，总结里面出现的主题。等我早上醒来，就能看到很好的摘要，甚至还有一些 PR 可以让我 review。
Lenny：这些反馈频道具体来自哪里？是邮件、Twitter，还是各种渠道的组合？
Fiona：来源很多。包括内部 Anthropic 员工的反馈，也包括邮件渠道。我们每个人如果从朋友、LinkedIn 或社交平台上收到反馈，也都会发到 Slack 里。我们还有来自合作伙伴等不同渠道的反馈。因此信息量非常大，我需要 Claude 帮我跟上这些反馈。
Lenny：明白了。所以这是你建立的一种新工作方式。作为管理者，你每天会看大家对 Claude Code 和 Cowork 当前状态的反馈。过去可能是看到问题后让某个人去修，现在变成 Claude 已经生成了一个 PR，告诉你它可以解决这个问题，你 review 后就可以决定是否合并。我们继续这个问题聊，显然，代码审查也是一个大问题。我想 Claude 现在也在做大量代码审查。你们最近有没有发现什么方法，可以让团队更快地交付，同时仍然相信交付出来的东西质量很好？
Fiona：这件事变化非常大。想想看，去年我们甚至还没有 Claude Code reviews。之前人类 reviewer 是一个很大的瓶颈。
当然，对于需要深度专业知识的重要区域，我们仍然需要合适的人类来 review。但能帮上忙的是，我们可以尽量把“什么是好的”自动化、框架化。Claude 在你给它明确框架后，非常擅长按照这些框架做验证。
举个例子，我们最近把 content design 做成一个 skill。我的建议是，如果你有 spec 或某种“什么是好的”的定义，就把它放进 repo，并且确保 spec 能跟代码一起保持更新。只要你有一个关于 good looks like 的清晰描述，就应该把它纳入 repo。这样 Claude Code review 就能检查代码是否仍然符合这些标准。
Lenny：这基本上像是测试驱动开发的一种演进。对吗？
Fiona：是的。TDD 在 2000 年代曾经非常流行：先写测试，让测试失败，再写代码让它通过。原则上很好。但我自己当时也会觉得有点挣扎，因为这就像必须先吃西兰花：你得先写测试，但我真正兴奋的是 shipping 和构建产品。
我在 Claude Code 上修的第一个 bug，就让 Claude 帮我做 TDD。我对它说：帮我先写测试，确保测试失败，然后我们再修复，最后让测试通过。过去测试生成像是一种必须支付的成本，现在它可以被自动化。很多老原则现在可以重新发挥价值，因为模型能帮你完成更多执行工作。
Lenny：这太不公平了，它甚至可以先替你写测试。
2 Anthropic 招人时看重什么？
Lenny：说到 builder，你演讲里有一页我特别喜欢，是关于你现在招聘时看重什么人。你提到两类画像：一类是有产品感的 creative builders，另一类是能解决 hard parts 的 deep systems experts。你能展开讲讲吗？
Fiona：是的，深度专业知识仍然非常重要。比如我刚加入 Claude Code 时，团队里有很强的 product generalist，但我意识到我们缺少系统背景的人。因此，系统和分布式系统专家就是我们需要补强的方向。
这仍然是 trust but verify。模型已经很强，但很多地方仍然需要验证。所以，只要某个领域需要深度专业能力，这类人才仍然值得投入。
另一类人是有产品感的人，或者说 dreamers。他们通常会非常热爱一个产品，有自己的想法，能把它做出来，然后持续看反馈、迭代、打磨，确保产品体验是令人愉悦的。他们会端到端拥有一个产品体验。这种能力在 Claude Code 团队里非常有用。
Lenny：你刚才讲的让我想到一个词：ambition。最近这个词在节目里和我其他工作中反复出现。我前几天和一个很强的工程师聊天。他说，过去如果有人提出一个功能，他第一反应可能是“不行，这太难了，太复杂了”。但现在他的反应变了：这完全可能，我可以让 Claude Code 去做。于是整个心态发生了变化。现在关键不再是“这件事是不是太难”，而是“你能想得多大、多有野心”。理论上很多事情都能做了，限制变成了你的想象力和野心。这和你的观察一致吗？
Fiona：非常一致。我昨天刚和一位工程师聊过。他本来不是移动端工程师，但我们需要把一个功能扩展到移动端。以前他可能会觉得：我不是 Android 专家，做不了这个。但现在有了 Claude，他可以有一个 partner，帮助他在移动端 surface 上推进这件事。所以这确实抬高了每个人能做事情的上限。
Lenny：有些人在 AI 时代适应得很好，有些人则非常沮丧、不开心，甚至抵触、抗拒。你看到那些适应得很好、正在感到害怕的工程师，和那些很痛苦的人之间，有什么共同差异？不只是工程师，其他角色也一样。
Fiona：我觉得 growth mindset 非常重要。其实在 AI 工具出现之前，我就已经觉得这种心态很有价值。真正让我理解 growth mindset 的，是我从 Microsoft 转到 Meta 的第一年。
所谓 growth mindset，就是你要一直学习，也要意识到：过去帮助你走到今天的方式，未必还能继续帮助你走到下一阶段。这个过程很难，因为每个人都是靠某种工作方式获得过去的成功。当别人告诉你“你需要改变”时，你会自然地想：可是我过去就是靠这套方式成功的，为什么现在要改？但我觉得，growth mindset 对我帮助非常大。我也看到，适应 AI 比较好的人，通常都更愿意带着好奇心进入新变化，愿意持续学习。
至于挫败感，我有时也会看到背后其实有恐惧。恐惧本身是很自然的，人类进化过程中需要恐惧来保护自己。但如果你对某件事感到害怕，我的建议是：lean in，靠近它，然后问自己，我能做什么？什么是在我控制范围内的？很多沮丧来自一种感觉：所有变化都发生在我身上，而我无能为力。如果你能换一个角度想，不是“这件事发生在我身上”，而是“这件事是否也可能是为我而发生”，然后找出一件你可以采取的行动，情况会好很多。
我小时候原本并不是想学计算机或工程，而是想做视觉艺术家。我第一次接触电脑是在高中九年级，那时候电脑很贵，学校甚至有专门的打字课，教学生怎么熟练使用键盘。后来我接触 HTML 编程，发现计算机和编程也能像艺术一样，把一个想法创造出来、表达出来、讲成一个故事，于是开始喜欢上编程。
但我当时也有很大的恐惧：如果真的走工程这条路，自己能不能负担大学学费？我在加拿大安大略长大，知道有学生资助项目，但不知道能覆盖多少费用。后来我看到加拿大国家银行在高中贴招聘传单，招高中生暑期实习做银行柜员。虽然我最讨厌的高中课程就是会计，也不知道自己能不能做好，但还是报名了。
这份工作后来成了我的“生命线”。我暑假工作攒钱，后来周末也继续做银行柜员，靠这份收入支付学校开销。尤其在 2000 年互联网泡沫破裂后，很多公司不招实习生，我还继续做了两年银行柜员。这就是我当时能采取的一个、在自己控制范围内的行动，用来对抗“我可能负担不起上学”的恐惧。
所以我给出的建议是：面对焦虑和恐惧时，先问有没有一个你能控制的行动。我过去很喜欢两句话：如果你不害怕，你会做什么？以及偶尔做一些让你害怕的事。因为当你已经非常擅长某件事时，往往已经处在熟练度高点。继续成长的方法，就是去做一些以前没做过、让你有点害怕的事情。这个过程一定会有能力下滑期，因为你需要重新学习，但这也是成长的方式。
Lenny：我在节目里引用最多的一句话可能是：你害怕进入的洞穴里，藏着你寻找的宝藏。
Fiona：我很喜欢这句话。
Lenny：这句话确实很真实。很多时候，最让你害怕的事情，反而像一个职业指南针，指向你最应该去做的方向。当然，不是所有可怕的事情都要做，比如不要去跳悬崖。但在职业选择上，这通常是一个不错的信号。
3 帮助中小企业落地 AI 应用
Lenny：沿着这个话题，我知道你很关注一个问题：现在正在形成一种差距。一部分人积极拥抱 AI，表现非常好；另一部分人没有跟上。这对很多人来说是一个很可怕的时代，他们可能会被新的世界甩在后面。我知道你花了很多时间帮助小企业使用 AI 工具，这也是你很在意的事。你怎么看这个问题？我们应该怎么帮助更多人不要掉队？
Fiona：这是我非常有热情的话题。我小时候从香港出生，后来搬到加拿大。那时我不会说英语，父母又一直需要工作，所以我的奶奶和我们一起搬过去照顾我。她是我能想到的最好的奶奶。我们刚到加拿大时，我和奶奶都不会说英语。我后来可以通过上学、和同学交流学会英语，但对奶奶来说，在一个新的国家生活是很孤立的。
后来有一年夏天，我们偶然发现一家小毛线店，店主也会说粤语。于是那个夏天，我和奶奶每周都会去那家毛线店。奶奶在那里找到了自己的 knitting circle，也就是编织圈子。我自己也学了一些手工，比如 macramé。那家小店让我看到，一个小企业也可以创造非常好的社区感。这也是我后来喜欢小企业的原因。
后来，我自己用 Cowork 处理商务差旅报销。我一直不喜欢做报销，但 Cowork 可以帮我做这些我不喜欢的事。于是我想到：如果 Cowork 能帮我处理这些小的商务报销，那对小企业主应该会非常有用。因为我的很多小企业朋友真的非常辛苦，他们工作很拼，利润率有时也很低。我见过朋友坐在吧台前，面前堆满账单，只是在做发票和报销。我想，没有人真的喜欢做这些事。
于是我开始帮几个朋友上手 Cowork。这个过程也让我很受触动。一方面，我看到他们在 onboarding 流程里遇到了一些很好的 bug，帮助我们发现产品问题；另一方面，我也看到他们用 Cowork 的方式超出了我原本的想象。
比如我原本关注的是 Cowork 处理 PDF、发票这些能力。但我有一位开两家餐厅的朋友，她说自己的文件夹就像厨房里的杂物抽屉，里面堆满了各种文件和下载内容，她知道里面有几份菜单，但找不到。于是我们让 Cowork 访问目录，它帮她找到了菜单。
然后她又提出一个很特别的问题：她想让本地居民和游客都觉得价格合理，于是让 Claude 看看当地同类型菜系的价格，她的菜单价格是否可比。Claude 给出了类似市场分析的结果，还提到了一些当地餐厅。她看到后说：“我前阵子刚去过西雅图那家餐厅，确实不错。”所以每次我都会从这些使用场景里学到东西，也获得很多反馈。
Lenny：那问题就变成了：我们怎么把这些能力传播给更多人？很多人会说“我没时间学这个”“我讨厌 AI”“我想忽略它”。解决这个问题的方法是什么？是多分享案例吗？尤其是我的听众里很多人已经非常 AI-pilled，很深度拥抱 AI。
Fiona：我觉得可以从你自己真实感受到的变化开始。先想想 AI 工具有没有在哪件事上真正改变了你的生活或工作，然后把它作为和身边人对话的入口。
对我来说，AI 是一种工具。我也完全理解它有令人沮丧的一面，但我一直觉得知识就是力量。你必须学会使用这些工具，因为它可能是“光明与黑暗”里面的光明部分。
所以我很希望大家帮忙做一件事：如果你的社区里、家庭里，或者你喜欢的小企业里，有人可能还没接触 AI，你可以试着问问他们：“你有没有想过 AI 也许能帮你做这件事？”一开始可能会有点尴尬。我第一次联系朋友时也有点不自然，因为我平时不太和他们聊我的工作。我会说：“我在做 AI，能不能给你演示一下 Cowork 能做什么？”但后来我们都玩得很开心。
我希望这种对话能更多发生。我们需要继续分享知识，让这些工具更公平地被更多人使用。否则我担心，人与人之间的差距会越来越大。
Lenny：我也有同感。分享具体 use case 非常有力量。比如我前几天用 Cowork 帮我填写儿子的夏令营表格，然后我在 Twitter 上分享，很多人反应是：“哦，我从来没想过可以这么用。”很多时候就是这些很小的场景，人们没意识到 Cowork 和 Claude 可以帮上忙。
说到 Cowork，如果回头看，Anthropic 似乎很早就能发现一些巨大机会。比如 Coding，你们很早就意识到这是一个巨大的市场。不管最初是不是有意为之，这可能都是历史上最大的新增商业机会之一。Cowork 也是类似，你们很早就开始进入知识工作领域，像是在说：为什么不把整个知识工作都解决掉？另外，我感觉 Anthropic 也很早就重视模型的 personality。它不只是体验问题，也影响模型的智能和成功。
你觉得 Anthropic 和你们团队做了什么不一样的事，使你们能比其他实验室更早发现这些机会，并且敢于大规模投入？
Fiona：我没有在其他实验室工作过，所以不太确定其他实验室怎么运作。但我可以说，在 Claude Code 和 Cowork 团队，我们确实会关注 latent demand，也就是潜在需求。
编码这个 use case 上，我们很幸运，因为很多 Anthropic 员工自己就是第一批用户，所以我们可以非常快地获得反馈。但 latent demand 这个概念很重要。比如 Cowork 的例子中，很多并不是程序员的人也在使用 Claude Code。那我们就会问：能不能让这种体验变得更好？这种观察方式不只在 Anthropic 对我有用，在我过去做过的其他产品里也很有帮助。你刚才提到小企业，我之前拜访了一些小企业，后来我们推出了 Claude for Small Business。这个点不是我推动出来的，所以我不是在抢功，但我也注意到了同样的现象。
我和小企业主一起使用产品时，他们会问：“它有没有这个插件？有没有那个插件？”我会说：“我觉得有吧。”然后我们还要去找。后来 Claude Business 相关能力把这些都打包起来，在 Cowork 里面有一个小 toggle。另一个很棒的团队一直在和小企业做 Cowork sessions，可能他们也发现这里有提升效率和改善体验的机会。
所以我觉得关键是：不只是你负责的产品本身要持续听反馈、迭代，努力做出令人愉悦、可靠、高质量的体验；同时也要观察，有没有新的使用场景正在冒出来，我们能不能让这些场景变得更好。
在软件行业，我学到的一件事是：用户会用你没预料到的方式使用你的产品，不管这种方式是好的还是坏的。所以最好的方法就是持续迭代、持续学习，并且和反馈保持很近的距离。
Lenny：latent demand 这个词在节目里已经出现很多次了，可能里面真有东西。你说的意思是，要非常仔细地观察那些你没有预料到、但正在出现的用户行为。然后一旦看到这种行为，就投入进去，探索它，做出很棒的东西，并提出假设：当你看到用户为了让某件事可行而“绕很多弯子”时，你能不能把它变成一个更顺滑、更好的体验。
4 下一个前沿：AI 驱动的异步协作
Lenny：回到你们团队的工作方式。你们处在能力边界的最前沿，而工程师这个角色也已经发生了很大变化。你觉得工程工作方式的下一个前沿是什么？是 fleets of agents，也就是大量 agent 并行吗？还是其他东西？有哪些变化是你们已经在做、正在实施，或者刚开始发生的？
Fiona：我会说，我们正在更多转向 async，也就是异步工作。你提到 fleets of agents，这也是 routines 有意思的原因。过去我可能同步写一个 prompt，等待结果；后来我可能异步启动几个 prompt。但现在，我可以设置一个 routine，让它替我生成这些 prompts。抽象层级又往上抬了一层。
我没有水晶球，不知道一年后会变成什么样，但我觉得一年后我们可以再回头看这个问题，会很有意思。
Lenny：我想听更多。帮我们理解一下，routines 到底是什么？你说从同步工作变成异步工作，具体是什么意思？是写一个 prompt，然后它不会立刻完成，而是之后运行吗？
Fiona：比如我以前每天早上会喝咖啡，然后让 Claude 帮我看某个 Slack 频道。现在我可以设置一个 routine，每天早上固定时间运行。它不只是帮我看信息，还可以代表我启动 agents。
过去如果要自动化，你可能会做一个 cron job。但现在是：它会看这些反馈，如果发现某些 bug，或者发现一些可以做的 polish fixes，它就可以启动 agent 去处理。等我醒来时，可能已经有一些 PR 可以 review。
以前即使我有不同的 agents，我还要自己想：拿到这些信息后，我下一步该做什么？现在是更高一层抽象：我可以写一个 routine，让它替我生成 prompts，并派生出不同 agents。所以我认为我们会越来越走向这种异步工作方式。
Lenny：这很有意思。某种意义上，作为管理者，你每天会做很多固定动作：检查项目进展、看哪里落后、看谁被卡住、看哪些地方需要修补和改进。你现在说的是，可以把这些日常管理动作写成 prompts，让 Claude 替你执行，然后告诉你：这是我正在做的，这是你需要 review 的。
甚至到某个阶段，你会给它更多自主权，比如如果验证机制足够可靠，就可以直接让它“go for it”。
Fiona：是的，可以给它一点自由，让它做更多事情。
Lenny：这让我想到“go for it”背后的概念。我本来没打算聊这个，但我最近看了 Tyler Cowen 的一个演讲。他是经济学家，也有自己的播客。他提到，在现在这个世界里，表现最好的人往往有 initiative。另一个常用词是 agency。
很多人都在说，表现最好的人是最主动、最 proactive、最有 agency 的人。这个话题会让你想到什么？人们需要思考或提升什么？
Fiona：我很喜欢 agency 这个词。Claude Code 和 Cowork 团队也非常重视这一点。但有意思的是，我们通常会把它和另一个东西放在一起讲。对我们来说，重要的是：这里有一个问题，团队里的每个人都可以有自己的想法，去思考怎么解决它。这就是 high agency。
但我们也会说，high agency 必须对应 high accountability。也就是说，我们要确保大家有自由去发挥、去尝试，但同时也要问：这件事怎么负责？你要解决的问题是什么？你的假设是什么？所以 agency 和 accountability 是同一枚硬币的两面。这个平衡对我们团队很有帮助。
5 Agent 风向变了：从堆 Token 到算 ROI
Lenny：这确实是 agency 非常重要的一部分。大家都可以各自去做事，但最后还是要问：你到底做出了什么？最近感觉行业氛围正在变化。之前大家更像是在 token maxing：疯狂使用 token，尽可能多花，先看看能做出什么。但现在大家开始问：我们到底得到了什么？花了多少钱？ROI 是什么？有意思的是，Boris 以前在 Meta 负责 productivity，他的工作就是衡量工程效率。最近关于代码行数、代码交付量，也有很多讨论。你们在 Anthropic 有一个“不公平优势”，因为内部使用 token 的条件不一样。在这种情况下，你们学到了什么？今天要怎么衡量工程师使用 AI 工具后的 ROI 和生产力？
Fiona：工程生产力是一个非常有意思的话题。最开始，大家可能会看 lines of code，也就是代码行数，把它当作 throughput。但很快就会出现争论：某个工程师代码行数很多，但也许只是把一个库迁移或移植过来。那是不是应该看 significant lines of code？可是如果我们更新了框架，生成的代码变少了，但输出结果还是一样，那又怎么办？于是可能又会想，是否应该看 PR 落地时间。
但无论用什么指标，最重要的是：output 是否真的导向 outcome。也就是说，你产出的东西是否真的服务于最终结果。
token maxing 有点像过去看代码行数。它看起来是一个动作很多的指标，但我更关心的是：我们到底要解决什么问题？我很喜欢一句话：不要把 motion 当成 progress。 如果你只衡量工具使用率，那你衡量的是 action。但它是否真的让你想要的最终结果变得更好？这才是关键。
所以我会尽量 zoom out，先问：我们要解决的问题是什么？衡量这个问题有没有被解决的好方法是什么？然后围绕这个去做，而不是只盯着生产力指标本身。
除了指标之外，我还建议团队领导者，尤其是在更多人开始采用 AI 工具时，要做 listening tour。特别要去听资深工程师的反馈：哪些有效，哪些无效，怎样能变得更好。因为他们也能帮助这些经验在整个工程团队里放大和扩散。有时这些对话比 dashboard 更能激发新想法，也能带来很好的共同学习。
我也从指标中学到过很多。一个好的指标应该是你可以持续 hill climb 的，也就是可以围绕它不断优化。但你始终要问：这个指标还在服务你的目标吗？它是否仍然服务于你最初想要达成的 outcome？我在 Facebook Marketplace 早期有一个例子。当时我们按地区上线 Marketplace，希望先确保产品体验足够好，再扩展到更多地区。早期我们会看一个指标：卖家数量。上线第一个地区后，我发现某个地区卖家数量不高，但用户其实能找到自己想要的物品。而这才是我们真正的目标：帮助人们找到他们需要的东西。
后来我意识到，那个地区虽然卖家数量不多，但有一些 power sellers，也就是高活跃、高供给能力的卖家。
Lenny：除了“团队 ship 得更快”之外，现在工程经理对团队还有什么新的 baseline expectation？还有别的变化吗？
Fiona：这是个有意思的问题。首先，我觉得现在大多数 commit 都是 Claude 辅助完成的，这是一个很大的变化。
其次，刚才也提到过，我们有 Slack 反馈频道，也有各种 dashboard，这些都会交给 Claude 帮我们处理。我认为，工程师需要继续强化自己的产品感，也就是 product sense。这样他们会成为更有主见、更强的 product engineers。
另外，过去一些传统上不属于工程师的事情，现在工程师也能做一些。以前你可能会被卡住，因为要等某个跨职能伙伴，比如产品、设计或其他角色。但现在这种 blocker 会少一些，因为模型可以增强工程师原本不具备的一些能力。
所以变化是双向的：工程师变得更有产品意识，也更直接对产品质量和产品成功负责；与此同时，其他角色也越来越像工程师。
Lenny：对，两个方向都在发生。工程师变得更产品化，而所有人也都越来越工程化。
Fiona：是的，边界正在模糊。
Lenny：我忘了是谁说过一句话：现在“角色”到底是什么？也许就是你日常工作里占比最高的那部分。你做什么最多，那就是什么角色。
6 亲身试用自家产品的重要性
Lenny：我想回到你刚才提到的 dogfooding，也就是深度使用自己团队做的产品。我和一些与你共事过的人聊过，他们最常提到的一点就是：你非常执着于 living and breathing the product，持续使用自己正在构建的产品。你为什么这么重视 dogfooding？为什么也会把这件事灌输给团队和下属？
Fiona：我很喜欢这个问题。对我来说，dogfooding 是保持产品脉搏的一种方式。每当你做一个产品时，你背后都有一个 dream：你希望启用某种体验，或者让某种体验变得更好。亲自使用产品，能让我始终贴近这个脉搏。
我对 dogfooding 的热爱很大程度上来自 Visual Studio。但这个习惯在后来的产品里也一直有用。比如 Facebook Marketplace，即使我离开团队之后，有一次我想卖一台 MacBook Air，就想：我已经很久没在 Marketplace 上卖东西了，试试看吧。
结果我刚一挂上去，马上就有买家或卖家试图诈骗我，而且是一种我之前没发现的新诈骗方式。这再次证明，用户会以你没想到的方式使用你的产品，不管是好的还是坏的。
所以，无论是 leader，还是团队里的任何人，我们每个人都有不同的生活场景，能发现不同问题。比如我支持 VR 和 AR 团队时，不知道为什么，我用 VR 时总能复现一些奇怪的地面高度问题。后来这反而成为我的贡献方式，因为我能稳定复现某些体验问题。
所以第一点是，dogfooding 能让你保持对产品的真实触感，不至于只迷失在指标、dashboard 或演示文稿里。
Lenny：我觉得这是一个很重要的点，想强调给大家听。大家经常讨论 anecdotal evidence 和 data 的关系，也就是个案和数据的关系。你这里说的是，作为产品负责人或工程负责人，你从具体个案、亲自作为用户遇到的小问题里，获得了很多有价值的信息，而不是只盯着数据。
Fiona：是的。有时这也是我最有效帮助团队的方式。比如我之前领导 VR 团队时，我没有往那个代码库提交代码，因为我担心自己会搞坏操作系统。但当时团队在做很多 polish fixes，也就是体验打磨。我就想，我可以把自己的 dogfooding 时间用来检查体验，看它到底是什么样子。这样我仍然可以有意义地帮助团队把住质量标准。
团队成员通常也会很感谢这一点。因为作为 leader，你支持团队成员，而团队成员也希望知道，他们做的工作是重要的。如果 leader 真正在使用产品，大家会感觉 leader 是投入的，不是离团队很远。
Lenny：这也和你前面说的工程师要更有产品感有关。工程师需要变得更像 PM，PM 也需要变得更像工程师。对工程师来说，培养产品感的一种方式就是持续使用产品。你作为用户使用它，就能知道产品缺什么。
Fiona：对。如果你领导的团队做的产品很难被你自己使用，那就去见客户。不管是哪一种方式，你都需要建立接近用户的渠道。
每次我做客户拜访，都会学到新东西。比如 Facebook Marketplace 当时想进入拉美市场，我们在智利测试，但效果不如其他地区。我们尝试了很多方法，后来决定去智利做一个很小的研究行程，团队只有三个人。我们还带了一堆 Android 手机。
刚落地，我一打开这些 Android 手机，就发现当地 LTE 连接比美国慢很多。Marketplace feed 在低速 LTE 下加载得很差。这是一个非常大的增长阻碍，因为用户连 feed 都加载不出来。
这就是为什么听客户反馈、建立快速反馈循环这么重要。
Lenny：我记得好像是 Jeff Bezos 说过：如果数据和一个具体个案发生冲突，要更相信个案。这是一个很好的例子。你之前演讲结尾有一页很有意思，列了一些你现在还没想明白的问题。现在变化太快，我想知道这些问题是否依然存在，或者有没有新的问题。
你当时提到三个问题：第一，我们是否仍然需要分开的 iOS 和 Android 组织？第二，完全自动化 review 到底能推进到什么程度？第三，在角色边界越来越模糊的情况下，如何确保每个人都同样高效？这些还是你们正在思考的问题吗？还有没有其他你觉得必须解决、但还没解决的问题？
Fiona：关于 iOS 和 Android 组织这个问题，我们还在思考。前面也提到过，深度专业知识仍然非常重要，所以我们仍然需要有 Android 和 iOS 专家。但因为大家现在可以跨领域 flex，我们可能不再需要过去那么大的、独立的移动端组织。关键是找到平衡：我们是否有正确且足够的专业能力？这个问题仍在探索中。
Lenny：第二个问题是：完全自动化 review 到底能推到多远？
Fiona：这个很有意思。比如我们做了 content design check。更大的问题是：你怎样定义 good looks like？verification 仍然是很大的机会点。我们要判断专家经验在哪里仍然重要，同时也要不断问：能不能利用这些专家经验，把一部分事情自动化？我们需要看完整的 end-to-end experience，而不是只从工程角度看。也要思考体验、内容设计等其他领域，不能漏掉这些部分。
Lenny：也就是说，核心问题是：怎么建立一种 verification 机制，确认最后的体验确实是你想要的体验？
Fiona：正是这样。而且这仍然很难。你前面提到 eval，评估里当然有准确性问题，但还有体验问题。体验是否令人满意、是否符合预期，这仍然是我们在思考的难题。
Lenny：还有其他最近出现的新问题吗？有没有什么变化让你觉得，我们必须重新思考团队运作方式？
Fiona：有。随着 routines 和更多异步工作出现，我觉得 context switching 的负担正在上升。
我自己也有这种感受：我启动了很多异步任务，然后就需要不断检查、review，还要记得自己当时在做什么。所以无论是对团队成员，还是对用户，我们都需要思考如何改善这个体验，降低上下文切换负担。
如果你同时有 20 个 agents 在运行，就会有无穷无尽的检查和 review，而且你必须记住每个任务的上下文。
Lenny：这很有意思。前面我们聊过 flow，过去工程师可以有几个小时连续沉浸。但现在虽然这样的 flow 少了，agent 也能提醒你：你现在进行到哪里了。它让上下文切换变容易，因为你不需要重新理解整个代码库或架构，它可以告诉你：“我们正在做这个。”所以这件事既变好了，也变糟了。
Fiona：是的。过去我会专门 block focus time，用来写代码，因为 coding 需要专注，避免上下文切换。现在有趣的是，因为我同时启动了更多 agents，反而又需要重新 block focus time，用来追上我自己启动的各种异步工作。
Lenny：你有什么解决方案吗？这确实很难。大家都想做更多，但怎么避免被持续的上下文切换拖垮？
Fiona：我同意，这很难。我还没有解决这个问题。
7 工程就业与教育，未来何去何从？
Lenny：我刚想到一个问题，虽然原本没打算问，但现在非常重要：就业和招聘。按理说，AI 似乎会让工程师变得没那么必要。但另一方面，你们正在大量招聘工程师，OpenAI 也在疯狂招聘工程师，工程师需求仍然非常高。你觉得这件事会怎么发展？工程师角色的未来会是什么样？
Fiona：我可以坦诚地说，这是我心里的一个大问题。我真的在思考：我们该如何培养下一代工程师。你和我走上工程道路的方式，和现在的新人会非常不同。现在一个人从学校毕业后，可能需要被“快进”到一个更高的工作方式。但对我来说，重要的是，他仍然要理解我前面提到的 double click，也就是能深入理解自己依赖的那一层。
我不知道答案，但我在想，软件工程教育会不会更像 fellowship 或 apprenticeship，也就是某种研究员式、学徒式项目。虽然现在也有 internship，但很多实习只是三个月的小项目。未来我们也许需要一种方式，把我们过去通过多年写代码、踩坑积累到的经验，压缩并传递给下一代 builder。
如果一个年轻软件工程师根本不需要亲自看代码，那他为什么还会有动力真正理解基础设施、内存分配这些基础知识？也许模型有一天会强到这些都不再重要，但我仍然认为，double click 的能力很重要。因为真正改进产品或系统的机会，往往来自你理解了更底层的东西。问题是：如何不靠多年手写代码，也能学到这些东西？Lenny：总得有人在某个层面理解代码。否则未来可能会像 COBOL 工程师一样，还得把退休的人找回来问：“你还记得怎么写 Python 吗？”
Fiona：很有意思的是，我以前有一位 manager，他开始做软件工程时用的是 punch cards。现在他一直给我发消息，展示他用 Claude Code 做了什么。我觉得这很神奇。他的职业生涯从打孔卡开始，一直看到现在这种变化。
所以也许我们需要思考的是：哪些东西会继续重要，哪些东西的重要性会下降。也许随着时间变化，重要能力会转移。关键是，我们要学会构建那些真正重要的能力。
Lenny：我经常听到的说法是：这只是新的抽象层。过去从二进制到汇编，再到更高级语言，抽象层一直在往上走。现在也许我们不需要直接看代码，而是进入 prompt、Claude thinking message 这类新的抽象层。
Fiona：也许未来更重要的问题会变成：你要解决什么有意思的问题？你要优先构建什么体验？当你构建完之后，怎么知道它真的产生共鸣？它是否真的做到了你想要的事情？它是否足够好？Lenny：对，也就是说，我们到底是在构建一堆 slop，还是在构建真正能工作的架构？年轻人的优势可能在于，他们更容易直接进入这种新工作方式，而不是被旧方式束缚。像你这样有多年经验的工程师还能适应并拥抱这种变化，其实很不容易。
Fiona：变化速度确实非常快。我记得第一次用 Sonnet 3.5 或 3.6 做一些 side project 时，它还会犯一些错。我当时会想：你在干什么？但我注意到，一些抵触 AI 工具的工程师会说：“你看，它就是不行。”他们很难理解模型能力提升的指数速度。
这也是我自己正在学习的一点：有些我曾经尝试自动化的事情，Claude 当时还不够好；但到了下一个模型，突然就足够好了。所以要经常回头看那些以前没跑通的事情，因为现在可能已经变成新的能力了。
Lenny：这个观点在节目里也经常出现：构建那些“几乎能工作”、处在能力边缘的东西。等模型能力补上来，你就会比别人领先很多。
8 技术领导的焦虑之源：团队文化如何随规模扩张
Lenny：最后一个问题。你可能已经用刚才的回答回答了一部分，但我还是想问：什么事情会让你夜里睡不着？
Fiona：最让我睡不着的，大概是我们如何保持 Claude Code 和 Cowork 团队的文化。团队文化对我非常重要。我很重视 one team mentality，也就是一个团队的心态。文化不是贴在墙上的海报，它是一个活的东西，会随着时间变化。它体现在我们如何对待彼此，如何支持彼此。
我们正在增长，而文化也会在增长中变化。所以我很在意：我们能否保留那些重要的东西？比如多元视角、健康开放的争论、公开诚实的讨论，以及当你接近终点线时，是否会回头看看其他队友需不需要帮助。因为我们是一起完成事情的。
这可能是最让我担心的事情。其他很多问题是产品或工程挑战，我们可以用 dashboard、理论或假设来处理。但文化是人的问题，它是团队的纤维。我总是担心，如果文化开始漂移，我们能不能及时发现，并且作为一个团队一起讨论，确保它朝正确方向生长。
Lenny：我能想象大家都在面临这个问题。考虑到变化速度和招聘速度，尤其是 Anthropic 这样处在几乎前所未有增长轨迹上的公司，保持文化一定很难。我之前在 Airbnb 时也经历过高速增长，虽然和你们现在的增长不能比，但如何维持文化也是一个持续讨论的话题。
Fiona：我很好奇，你在 Airbnb 时是怎么维持文化的？Lenny：有几件事很有用。第一是创始人非常重视文化。在每次全员会、每次大型会议上，他们都会不断提醒大家文化的重要性，以及公司价值观是什么。创始人自上而下地对文化保持执着，这是很重要的一部分。
还有一个记忆我一直记得。当时 Sheryl Sandberg 来 Airbnb 做 fireside chat，有人问她：公司快速扩张时，怎么维持文化？她的建议是，这其实是你想要拥有的问题。因为这说明公司在增长、在做得不错。相反，如果公司做得很差，增长停滞，没有疯狂招聘，也许什么都不会变，但那是更糟糕的情况。所以高速增长带来的文化挑战，是一个“好问题”。这个建议我一直记得。
Fiona：这很好。听你这么说，我想到 Claude Code 和 Cowork 团队里很重要的一点：无论是 IC 还是 manager，尤其是 manager，我们都必须公开讨论什么进展顺利，也要公开讨论什么进展不顺利。
只有当我们能谈论不顺利的地方时，才有机会解决问题。说到让我睡不着的事情，我的噩梦是：某个 manager 在我问“情况怎么样”时说，“一切都很好。”但我心里想：“天啊，不可能一切都很好，我知道这里有问题。”
这就像那个 meme：房间着火了，狗还坐着喝咖啡说“this is fine”。这就是我的噩梦。所以我会和很多团队成员，尤其是刚加入的 manager，反复讨论这件事：我们要一直保持开放对话，这样才能一起解决问题。
Lenny：我想很多人都会有这种挣扎。周围的人看起来都做得很好，表面上每个人都在赢、都在成长、都在一家很棒的公司里顺风顺水。在这种环境下，要诚实地说“我这里不太顺，我有点跟不上”，其实很难。在进入 lightning round 之前，还有什么你想留给听众的吗？有没有我们没聊到、但你觉得很重要的事情？
Fiona：我想提一个建议。我们前面聊到 Claude 可以自动化很多事情。Claude Code 和 Cowork 团队文化里还有一件很重要的事：我们明确允许自己杀掉那些已经不再服务我们的流程。
所以如果你在一个团队里工作，或者你在带团队，可以挑一个流程：它可能是你很讨厌做的，可能噪音很大，可能成本很高，可能非常手动。先问一句：它还在实现原本的目的吗？比如规划这件事。我刚加入 Claude 团队时，曾经想：也许我们应该做一个六个月 roadmap 文档，而且要做得很轻量，因为我不想浪费太多时间在规划上。我当时觉得已经很轻量了。
这个过程确实有价值，它帮助我们开启对话、确保对齐。但三个月后，我突然意识到：我们还在参考这个东西吗？因为变化太快了。于是我也调整了这个原本由我带进来的流程。
所以一定要保持开放学习，不断问自己：任何流程是否仍然服务它的目的？因为这个领域变化太快了。
Lenny：我很喜欢这个建议。那我想追问一下：你们现在怎么做规划？还做规划吗？是按月做 roadmap？能不能简单解释一下你们现在的方式？
Fiona：我现在叫它 JIT planning，也就是 just-in-time planning。
六个月对我们来说太长了。当然，有些项目会超过一个月，但我们现在尽量做轻量的月度规划。其实甚至没有文档，只是用一个小 spreadsheet，对齐我们认为重要的事情。
即便是这个 spreadsheet，我也还在思考是否可以进一步自动化。现在我们的方式是：列出这个月的优先级，然后每周快速检查一下，这些是否仍然是本月优先级。
所以我们已经把它缩短成 JIT monthly planning。也就是说，下个月我们准备做什么，用一个小表格列出来；每周 check-in，确认这是否仍然是下个月要做的事情。
Lenny：这很有意思。听起来你们表格里的事项也不多。
Fiona：是的，我们会尽量聚焦。我们会分享最高优先级是什么。然后基于这些优先级，每个人都会提出自己认为可以如何推进这些优先级的事项。这也和 agency 有关。
Lenny：那你们会不会也有未来六个月的大方向或大赌注？还是只看一个月？
Fiona：通常我们会有一些主题。大概每六个月，我们会把整个团队聚在一起，启动一些主题。但重点仍然是保持对现实变化的感知。因为环境变化太快，即使主题也可能很快变化。
Lenny：这太有意思了。这个节目其实可以全程只聊你们怎么规划。
9 快问快答
Lenny：我还有几个小问题想让你快问快答下。第一个问题。你最常向别人推荐的两三本书是什么？
Fiona：如果说小说，我会推荐两位作家：玛格丽特·阿特伍德和村上春树。我在加拿大长大，所以小时候读过很多阿特伍德的作品。她的书很有意思，有点像“推想小说”或者“思辨小说”：你读的时候会觉得，只要眯起眼睛想一想，这些事情好像真的有可能发生在某个社会里。我很喜欢她处理这类题材的方式。
至于村上春树，我喜欢他的魔幻现实主义风格。
如果只推荐一本书，我总是会推荐大家每年至少读一次《小王子》。我想我们大多数人可能都读过这本书，但我自己至少每年都会重读一遍，因为它会提醒我去思考，什么才是真正重要的东西。
Lenny：你最近喜欢的电影或电视剧是什么？
Fiona：我最近没怎么看电视剧。但我会分享三部我总是下载在手机里的电影，这样坐飞机时如果有时间就能看。
第一部是法国电影《天使爱美丽》（Amélie）。这些电影可能都很老，算 vintage 了。但我很喜欢《天使爱美丽》，它非常 whimsical。我 16 岁时原本想成为视觉艺术家，高中时去过巴黎，那段经历留下了很多记忆。《天使爱美丽》很好地捕捉了我当时感受到的巴黎魔力。
另外两部是吉卜力电影。一部是《千与千寻》（Spirited Away），我非常喜欢它的故事，几乎喜欢其中的一切，它可能是我最喜欢的吉卜力电影之一。
第三部是《风之谷》（Nausicaä of the Valley of the Wind）。如果有人问我，我的很多领导力特质来自哪里，我会想到这部电影。我大概八九岁时看过它，女主角 Nausicaä 的领导方式在我心里留下了很深的印记，也影响了我很多领导原则。
Lenny：这像是两本顶级管理书：《High Output Management》和《风之谷》。下一个问题。你最近发现并喜欢的产品是什么？可以是 app、衣服、工具、厨房用品，任何东西。
Fiona：我想分享一个最近又提醒我它对生活影响很大的产品。因为最近一直在旅行，我又喜欢轻装出行，所以通常会用酒店提供的洗发水和护发素。但这让我想起一个产品：Sweet Sisters Body Care。它是 Whidbey Island 上一家本地小企业。
它是一整套有机头发、身体和皮肤护理产品。几年前，我鼻子附近开始长一种很痛的皮疹，甚至会出血。我一直找不到原因。我停用了各种护肤品，还是没有好转。后来有人问我：“你用的是什么洗发水？”我说就是从十几岁开始一直用的普通洗发水。对方说，也许你的身体开始对里面的化学成分过敏了。
后来我找到了这款有机洗发水。用了一段时间后，情况真的好转了。你平时不会想到，洗头发时洗发水会流到身体其他部位。后来我几乎把日常使用的东西都换成了 Sweet Sisters。
最近因为旅行用了一周酒店洗发水，皮肤反应又开始出现，我才意识到，也许我应该带旅行装。
Lenny：我很喜欢本地小企业产品。顺便说一下，你最近在旅行，是因为 Code with Claude 活动在全球各地举办。我去了旧金山那场，伦敦也有一场，你接下来去东京。东京是最后一站吗？
Fiona：是的，东京是下周，也是这次行程的最后一站。
Lenny：下一个问题。你有没有在工作或生活中经常想起的一句座右铭？
Fiona：工作上，我常提醒大家：keep it simple。你真正想做好的一件事是什么？聚焦在那件事上。因为我们有时会想太多，所以 keep it simple 是一个很好的提醒。
生活上，我喜欢一句话：in a world where you can be anything, be kind。我们参观一所修道院学校时，看到老师把这句话贴在墙上。我很喜欢。每个人生活里都有很多事情，你永远不知道别人正在经历什么。一个很小的善意行为，可能会产生非常大的影响。
我有一个亲身经历。疫情期间，我们都在家工作。我有很多 back-to-back meetings，而我一直非常重视 one-on-one，因为这段时间对对方也很重要，他们可能一直等着和你讨论一些事情。
那时我奶奶身体不好，在加拿大的一家养老院里。因为疫情，我不能去看她，我妈妈和阿姨也不能去。偶尔如果有护理人员帮忙，我们才能 FaceTime，但时间完全不确定。
有一天，我阿姨突然发消息说，奶奶中午 12 点可以 FaceTime。我当时正好有一个很重要、一直想进行的 one-on-one。我就给对方发消息，说非常抱歉，临时有事，能不能改一下时间。现在说起来好像不是什么大事，但对我来说，守住 one-on-one 一直很重要。对方很爽快地说，当然，完全没问题。
这对他来说只是一个很小的善意，没有把这件事变得很严重。但对我来说意义很大，因为我因此能和奶奶 FaceTime，能和她打招呼。
Lenny：最后一个问题。之前我问 Boris，如果 AGI 到来、我们不需要工作了，他会做什么。听起来你的答案可能是继续编织，做漂亮衣服。
Fiona：我的梦想其实是开一家以我奶奶名字命名的毛线店，创造一个社区。然后 Cowork 可以帮忙，把一切都自动化。我真的觉得自己很幸运，也很谦卑，能和这么棒的团队一起工作。我知道自己非常幸运，也非常感激。也谢谢你邀请我来节目，这次聊天很有意思。
原视频链接：https://www.youtube.com/watch?app=desktop&v=Ybrl4FYM57c
本文系【发现AI】原创内容，部分内容综合自网络，如有侵权，请联系编辑删除。
转载请注明来源：http://faxai.cn 发现AI
微信扫一扫 
