打造全球最「AI化」的工程团队

摘要

Fiona Fung 是 Anthropic 旗下 Claude Code 和 Cowork 团队的工程负责人，拥有超过 25 年的软件工程经验。在本期 Lenny's Podcast 中，她分享了 Anthropic 工程师平均每季度代码产出较 2025 年增长 8 倍的惊人数据，以及这一变化背后的深层逻辑：编程不再是瓶颈，真正的天花板已被打破，一切在理论上都变得可能，关键只在于你的野心有多大。Fiona 深入探讨了 AI 时代工程团队的角色模糊化趋势——设计师、产品经理、工程师都在提交代码，人人都成了「构建者」（Builder）；她分享了如何用 Claude 来管理 Claude 团队、建立「坏体验 vs 坏心情」的质量框架、从六个月规划转向即时（JIT）月度规划，以及如何在高代理感（Agency）与高问责（Accountability）之间找到平衡。此外，她还就 AI 时代工程师技能退化、工作中的孤独感、小企业 AI 普惠以及下一代工程师的培养等深层问题给出了独到见解。这篇文章是对本次深度对话的完整呈现。

正文

一、8 倍代码产出：一个新时代的序幕

节目开场，主持人 Lenny Rachitsky 就抛出了一组令人震撼的数据：Anthropic 工程师平均每季度的代码产出，与 2021 至 2025 年相比增长了 8 倍。图表显示，此前多年的代码产出曲线一直平稳，而后陡然飙升，直冲天际。这个数据背后是软件工程领域的范式转变。

Fiona Fung 指出，这一转变的核心逻辑在于：「编程不再是瓶颈。」当编码速度被 AI 工具极大提升后，限制工程师的不再是「能不能做出来」，而是「你敢于设想多大的目标」。她用一句话概括了当前 Anthropic 团队的心态：「我们总是问自己，有什么比我自己做更好？答案是让 Claude 来做。」（It's always something we ask ourselves, what's better than me doing it? Having Claude do it.）

Fiona 在 Anthropic 管理着 Claude Code 和 Cowork 两个团队，直接领导 Boris Cherny 和 Kat Wu——这两位都曾做客本播客，他们的节目均跻身历史收听量前十。在加入 Anthropic 之前，Fiona 的履历横跨了软件行业的数个关键节点：在 IBM 参与 DB2 操作系统服务团队的工作；在 Microsoft 领导 TypeScript 和 Visual Studio 团队长达十一年；在 Facebook（Meta）从零孵化出如今年交易额超 1000 亿美元的 Facebook Marketplace；随后又负责 Meta 首款智能眼镜产品及 AR 眼镜 Orion 的开发；最后在 Instagram 领导基础设施、增长、诚信与安全团队，管理着超过 500 人的组织。她亲身经历了工程工具从 VIM 终端调试到 IDE 集成开发环境，从 CD 光盘发行软件到在线推送更新，再到如今 AI 代理编写代码的完整演变过程。

二、工程师之路：从 IBM 到 Anthropic 的工具进化史

Fiona 的职业生涯始于 IBM 的实习。当时她在 DB2 操作系统服务团队，使用 VIM 进行终端调试——那是她所处的「硬核」时代，认为越靠近操作系统底层就越能学到东西。然而，从 IBM 转到 Microsoft 的经历让她第一次接触到 IDE（集成开发环境，Integrated Development Environment）。她回忆道，当时甚至不知道 Visual Studio 是什么，还天真地问经理：「这是不是一个更好的画图程序？」（因为名字里有 "Visual" 一词）。当看到 IDE 里可以设置断点、进行多线程调试时，那种震撼至今难忘。

更特别的是，Fiona 所在的团队正是 Visual Studio 编辑器团队——她使用 VS 编辑器来构建 VS 编辑器本身。这段经历奠定了她日后对「吃自己的狗粮」（Dogfooding，即团队使用自己开发的产品）的执着。她回忆说，在那个 Twitter 还未诞生（约 2006 年才出现）、社交媒体尚未普及的年代，大多数工程师很难获得快速用户反馈；但因为她的团队本身就是 VS 的重度用户，内部反馈循环变得异常紧密，这让她深刻体会到「亲身体验自己产品」的不可替代性。

另一个被 Fiona 反复提及的重大转变，是从 CD 光盘发行软件到在线分发的跃迁。当时软件发行有硬性截止日（Hard Deadline），必须赶在母盘交付、压制 CD、上架零售之前完成开发。这迫使团队进行大量前期规划，力求在有限时间做出最优决策。对比之下，如今的 Claude Code 和 Cowork 世界正好相反：编程能力不再稀缺，稀缺的是如何验证如此海量代码的正确性，以及如何确保这些代码真正解决了问题。

三、角色模糊化：人人都是构建者

Fiona 观察到 AI 时代最显著的变化之一，是角色的全面模糊化。在 Claude Code 团队，不仅工程师在提交代码，设计师、产品经理——跨所有职能的人都在提交代码。「每个人都在成为构建者（Builder），」她说。跨学科的参与者大幅增加，每个人都在更高的抽象层面上进行工作，但这也带来了一个新的核心问题：当越来越多人、且来自不同背景的人都在提交代码时，验证（Verification） 应该如何跟上？

验证问题之所以关键，是因为代码产出的数量级已经发生了根本性变化。Fiona 提到了团队新近推出的「Routines」（例行程序）功能：过去她每天早上会一边喝咖啡一边浏览反馈频道，手动筛选需要关注的问题；现在她只需设置一个 Routine，让它自动监控反馈渠道、提取主题、甚至在早上她醒来时已经生成好可供审阅的 PR（拉取请求，Pull Request）。这不仅是效率的提升，更是工作范式的转变——从「我看了信息、然后决定做什么」，变成「AI 看了信息、列出了发现，并已经准备好了修复方案」。

四、用 AI 管理 AI 团队：Claude 成为管理者的脚手架

Fiona 分享了一个极具启发性的管理实践：她在一个专用远程会话中运行 Claude Code，并将其注册到团队所有代码仓库中。这个 Claude 实例不仅拥有代码库的完全访问权限，还能查看所有 Slack 频道和各项指标仪表板。每个月，她会与团队成员分享屏幕，一起在 Claude Code 中回顾过去一个月的工作：聚焦领域是什么？发布了哪些产品？表现如何？反馈渠道显示了什么？

这种方法的价值远不止于自动化 PR 和 Bug 修复，而在于促发有价值的对话（Enable Conversations）。在代码产出 8 倍增长的背景下，管理者已无法通过传统的「列出本月交付物」方式来跟踪每个人的工作。而 Claude 作为「管理脚手架」，不仅帮助追踪交付了什么，更能帮助分析交付产生了什么影响、出现了哪些问题、以及这些问题的模式是否暗示了需要系统性投入的方向。

Fiona 提到她有一个重要原则：「犯新错误」（Make New Mistakes）。错误可以犯，但要确保是「新」的错误——这意味着团队始终在学习和进步。如果目标是零错误，大概率说明你不够快，或者过于谨慎。Claude 能够帮助她审视一段时间内的事件，识别主题和热点，从而决定下一个质量投入方向。一年前，她根本无法如此高效地获取这些洞察。

五、Agency 与 Accountability：高自主，也意味着高问责

在 Fiona 的团队中，「代理感」（Agency）是一个被高度重视的品质。团队成员看到问题后，有完全的自由去构思解决方案并付诸行动。但 Fiona 强调了一个关键的平衡：「高代理感意味着高问责。」（With high agency comes high accountability.）

给予自由去「烹饪」的同时，也必须问清楚：你想解决什么问题？你的假设是什么？你如何验证它？这种平衡机制确保了自主权不会沦为散漫，而是始终锚定在可衡量的目标和产出上。

这与 Lenny 在节目中多次触及的主题遥相呼应：Tyler Cowen 等人提出的「主动性」（Initiative）和「代理感」（Agency）正在成为 AI 时代最关键的区分因素——在 AI 工具面前，所有人拥有大致平等的生产力杠杆，差距在于谁更主动地发现问题、提出解决方案并推动落地。

六、AI 时代的人才画像：创意构建者与系统专家

Fiona 在演讲中分享了她目前招聘时寻找的两种人才类型：

第一类是创意构建者（Creative Builder），具备产品感知力（Product Sense）。 这类人对产品充满激情，有一个想法就会立刻去实现，然后持续关注反馈、迭代打磨，将产品体验做到极致。他们通常是「梦想家」型人才，能够端到端地负责产品体验。

第二类是深度系统专家（Deep Systems Expert），负责攻克硬核难题。 当 Fiona 刚加入 Claude Code 时，团队拥有出色的产品通才，却缺少具备系统背景的人才。她很快意识到需要补充分布式系统和底层系统方面的专家。因为在 AI 辅助编程的世界里，核心理念是「信任但要验证」（Trust but Verify）——模型非常强大，但在许多关键领域仍需专业人员的深度验证。因此，凡是需要深度领域知识（Domain Expertise）的地方，依然值得持续投入人力。

Lenny 补充说，他最近与一位「10 倍工程师」交流时，对方提到过去听到一个复杂的功能需求时会本能地退缩，觉得太难太复杂；而现在第一反应是「这完全可能，我只需要让 Claude Code 来做」。Fiona 完全认可这一观察：AI 已经抬高了每个人能力的「天花板」，一名非移动端工程师现在也能借助 Claude 完成 Android 应用的开发。

七、成长心态与恐惧管理：在变化中保持前行

对于那些在 AI 浪潮中感到沮丧、抗拒甚至恐惧的工程师，Fiona 给出了两个核心建议：成长心态（Growth Mindset） 和聚焦可控之事。

她从自身经历分享了成长心态的重要性。从 Microsoft 转到 Meta 的第一年，她才真正理解了成长心态的含义：永远保持学习状态，同时意识到让你走到今天的做事方式可能不再适用于明天。这对很多人来说极其困难——「我一直按照某种方式做事才取得成功，你现在却让我改变它？」但正是这种「抛弃旧我」的勇气，在急剧变化的时代显得尤为重要。

至于恐惧，Fiona 的建议是直面它、然后问自己：「我能对此做什么？什么是我可以控制的？」她分享了高中时的亲身经历：因为家庭经济条件不确定能否负担工程学院的学费，她主动应聘了加拿大国家银行的银行柜员实习生职位，利用周末打工攒学费，最终恰恰是这份工作帮她度过了 2000 年互联网泡沫破裂后的招聘寒冬。她的信条是：「如果你不害怕的话，你会做什么？偶尔做一件让你害怕的事，因为那通常是你成长的契机。」（What would you do if you're not afraid? Do something scary once in a while, because that's usually how we grow.）

八、自动化代码审查与「好是什么样」的框架

随着代码产出量级的飙升，人工代码审查（Code Review）成为了严重的瓶颈。Fiona 坦言，就在一年前 Claude 还不具备代码审查能力。如今，团队的做法是：对于需要深度领域知识的关键领域，仍然保留人工审查；但对于可以将「好」的标准固化为框架的部分，则尽可能自动化。

核心思路是：只要你能定义出「好是什么样」（What Good Looks Like），就把它以规范（Spec）的形式检入代码仓库，并保持规范与代码同步更新。Claude 在有了明确的规范框架后，验证代码是否符合规范变得效率极高。Fiona 举了最近的内容设计更新为例——他们将内容设计标准写成一个 Skill，检入仓库后 Claude 便可以自动检查所有变更是否符合设计规范。

这本质上是测试驱动开发（TDD，Test-Driven Development） 的进化版。Fiona 回忆说，TDD 曾是一个重要理念——先写测试、确保测试失败、再写代码让测试通过——但自己当年总觉得这是一个「先吃西兰花」的苦差事。而现在，她只需要对 Claude 说一句「帮我做 TDD」，模型就会自动生成测试、验证测试失败、编写修复代码、再让测试通过。曾经需要付出意志力的流程，如今被彻底自动化了，这让她得以重新拥抱那些已经存在多年但过去执行成本过高的工程原则。

九、速度与质量的平衡：Bad vs Sad 框架

面对惊人的交付速度，如何确保质量不滑坡？Fiona 引入了一套简洁而有力的框架：Bad（糟糕的）vs Sad（令人沮丧的） 体验。

• Bad 是指不可恢复的致命错误——例如 CLI（命令行界面，Command Line Interface）的崩溃导致工作丢失。
• Sad 是指可恢复但令人不适的痛点——例如界面闪烁、加载缓慢等。Fiona 警告说，当 Sad 体验堆积起来时，整体上就可能演变成 Bad。

重要的是，Fiona 赋予每个子团队高度自主权（Agency）来定义各自领域内什么是 Bad、什么是 Sad，以及设定改进目标。因为不同产品表面（Surface Areas）或服务的衡量标准各异——单纯依靠原始性能或可靠性数据难以判断一个数字是「好」还是「坏」；但有了 Bad/Sad 这个高层框架，团队就能跳出各自仪表板的细节，从整体上把握用户体验的主题。

Lenny 由此提炼出一个关键启示：维持质量最有效的工具是监控和测试，而非花更多时间在代码审查上。 在代码产出爆炸的时代，人力审查已经追不上机器输出的速度；更好的策略是投入资源建立完善的验证和监控体系，让代理（Agent）自己知道成功的标准是什么，从而实现自我纠错。

十、工程生产力的衡量困境

工程生产力（Eng Productivity）的衡量一直是业界难题。Fiona 分享了她的亲身经历：最初用代码行数（Lines of Code）衡量，但很快发现有人只是引入了一个库然后大量提交，行数暴增却无实质贡献。于是改为「有效代码行数」，但问题随之而来：当框架升级后，生成的代码变少了，输出却完全一样。接着有人说，那就看 PR 落地时间吧……然而每换一个指标，都有人能找到针对性优化指标而非优化结果的方法。

Fiona 的核心建议是：始终将产出（Output）与成果（Outcome） 区分开来——不要混淆「运动」和「进步」。她引用了一句格言：「不要为了运动而放弃进步。」（Don't forsake motion for progress.）与其执着于衡量工具使用量或输入/输出动作，更应该退后一步，问清楚真正要解决的问题是什么，以及什么才是衡量那个结果的合理方式。

对于正在推动团队大规模采用 AI 工具的领导者，Fiona 还给出了一个实用建议：做一次「聆听之旅」（Listening Tour），尤其是与资深工程师深入交流——了解什么有效、什么无效、如何改进。资深工程师的反馈不仅本身极具价值，他们还可能成为在整个工程组织中放大和推广最佳实践的关键节点。

另一个经典案例来自 Facebook Marketplace 早期：当时团队以「卖家数量」作为是否扩展到新区域的核心指标。在某个地区，卖家数量很少，但买家却找到了他们想要的商品。Fiona 意识到，该地区的「超级卖家」（Power Sellers）现象被指标完全忽略了。团队迅速调整了衡量方式。这个教训至今有效：始终保持警惕，不要让曾经合理但已过时的指标蒙蔽双眼。 环境变化如此之快，指标本身也需要不断被审视和调整。

十一、失去的东西：心流、孤独感与未来的工程师

当代码不再由自己亲手一行行敲出，工程师失去了什么？Fiona 和 Lenny 进行了坦诚的反思。

心流（Flow）的消失。 过去，工程师会戴上耳机、沉浸到「状态区」中，享受攻克棘手问题后的快感——「终于解出来了！」那种成就感是工程工作中最令人上瘾的部分。如今，工程师更多是在等待代理完成工作，那种亲自「破解」的喜悦被产品层面的满足感所取代。

孤独感的出现。 当每个人都在和自己的 AI 代理工作时，团队间的互动反而减少了。Fiona 的团队最近启动了一项「结对编程午餐」（Pairwise Programming Lunch）——不是传统的两人一起写代码，而更像是幼儿的「平行游戏」（Parallel Play）：大家坐在同一个空间里各自工作，但通过观察彼此如何使用 Claude Code 和 Cowork 来互相学习。因为团队中每个人使用工具的流程都不相同，仅通过观看他人的工作方式，就能学到大量新技巧。此外，黑客马拉松（Hackathon）也被用作保持团队凝聚力的手段。

对于下一代工程师的培养，Fiona 坦率地表示这是她尚未找到答案的重大问题。她担心当编码不再需要亲力亲为时，年轻工程师是否还有动力去深入理解基础设施、内存分配等底层知识？也许未来的模型会优秀到这些不再重要，但她依然认为，「双击」（Double Click）——去深入理解你所依赖的下一层——是发现系统改进机会的关键。她猜测，未来的软件工程教育可能更像学徒制（Apprenticeship）或研修（Fellowship） 模式，而非当前三个月的实习加小型项目的路径。

十二、小企业与 AI 普惠：不让任何人掉队

Fiona 对小企业的热情源自家人的经历。她的祖母从香港搬到加拿大，不谙英语，感到极度孤立。直到一个夏天，她们偶然发现了一家由粤语店主经营的毛线店——那里成了祖母的编织社交圈，也让 Fiona 深深体会到小企业在社区中的凝聚力量。

当 Fiona 使用 Cowork 处理自己最厌恶的差旅报销时，她突然意识到：如果 Cowork 能让报销变得如此轻松，那对经营利润微薄、还不得不在酒吧柜台边处理一沓沓纸质账单的小企业主来说，该是多大的帮助。于是她找上了自己那些经营小企业的朋友，帮助他们上手 Cowork。

令她意想不到的是，朋友们使用 Cowork 的方式完全超出了她的预期。一位经营两家餐厅的朋友用 Cowork 在混乱的文档文件夹中找到了菜单、然后让 Claude 对比当地同类菜系的价格，确保自己的定价对本地人和游客都能保持合理——本质上进行了一次市场分析。这次体验让她坚定了信念：必须让 AI 工具变得普惠，否则技能鸿沟（Digital Divide）只会越拉越大。

Anthropic 随后推出了「Claude for Small Business」，将小企业常用的各类插件和功能打包在一起，在 Cowork 中只需一键切换即可使用。Fiona 呼吁所有「AI 化」程度较高的听众主动伸出手，帮助身边的人——不管是社区成员、家庭成员、还是你喜爱的小企业——迈出了解和使用 AI 的第一步。

十三、潜在需求与产品嗅觉：保持对意外行为的敏感

Lenny 特别点出了 Anthropic 的一项核心能力：总能领先于其他实验室发现巨大机遇。最早是编码，这是有史以来最大的新兴商业机会之一；然后是 Cowork，瞄准了全知识工作领域的自动化；再到对模型「性格」（Personality）的重视——这些都早于同行被识别出来。

Fiona 将这种能力归因于团队对潜在需求（Latent Demand） 的持续关注。编码之所以被率先抓住，很大程度上是因为 Anthropic 自身就是编码工具的第一批重度用户——「我们是自己的客户」，拥有极其紧密的反馈循环。而 Cowork 的诞生则源于团队注意到大量非编码人员在尝试使用 Claude Code，这激发了一个问题：「能否让这种体验变得更好？」

Fiona 强调，她的经验远不止于 Anthropic——在她参与过的所有产品中，最好用的方法都是：密切关注产品被以非预期方式使用的行为。 客户总会以你未曾设想的方式使用产品，不管那是好事还是坏事。关键就在于持续迭代、学习，并始终贴近反馈。当看到用户为了完成某件事而「跳圈」（Jump Through Hoops）时，就要问自己：能否将此打磨成更顺畅、更优雅的体验？

十四、异步化与 Routine：下一代工作范式

Fiona 认为，工程团队的下一个重大转变方向是异步化（Async）。Routine 便是这种转变的关键载体。

过去的工作流是同步的：Fiona 写一个 Prompt、等待结果、然后根据结果决定下一步。现在她可以设置一个 Routine，让它每天在固定时间自动运行——检查反馈频道、识别主题和 Bug、然后自动启动代理去生成修复 PR。她第二天醒来时，桌上已经摆好了可供审阅的代码变更。

这意味着抽象层级在持续上移：过去是「我写 Prompt」，现在是「Routine 替我生成 Prompt 并启动代理」。Fiona 预测，未来工程团队将越来越习惯于这种「设置好意图、然后异步等待结果」的工作方式，代理的数量将增长，类似「代理舰队」（Fleets of Agents）的场景将日益普遍。

但异步化也带来了新的挑战：上下文切换（Context Switching）的负担急剧增加。 Fiona 发现，过去她会专门安排「专注时间」（Focus Time）来写代码，因为编码工作需要持续沉浸；现在因为可以同时触发多个异步代理，她反而需要重新回归「专注时间」——不是用来写代码，而是用来追上所有异步代理返回的结果。如何减少这种切换成本，是团队仍在探索的开放问题。

十五、规划方式的根本转变：即时规划（JIT Planning）

Fiona 分享了一个令 Lenny 极感兴趣的细节：Claude Code 团队的规划方式已经从六个月路线图转变为「即时规划」（JIT Planning，Just-In-Time Planning）。

她刚加入团队时，曾提议做一个轻量级的六个月路线图文档。虽然到了第三个月他们就意识到几乎不再参考最初的规划——因为变化太快，但这个练习本身仍有价值，因为它启动了团队间的对齐对话。如今他们改为月度规划：用一张简单的电子表格对齐当月优先级，然后每周快速确认「这些是否仍是本月的优先级」。

Fiona 坦言，即使这样的流程她也仍在思考如何进一步自动化，因为「我不希望更新电子表格变成一种负担。」她给所有工程领导者的建议是：明确赋予团队「杀死不再服务你的流程」的权限。 找一个你惧怕的、高噪的、或极其昂贵的流程，首先问它是否还有存在的意义——因为在这个变化速度下，任何流程都可能迅速过时。

十六、团队文化：最让她彻夜难眠的事

被问及「什么让你彻夜难眠」时，Fiona 的回答不是产品挑战、不是工程难题，而是团队文化（Team Culture）。

Claude Code 和 Cowork 团队正在快速扩张，而文化是一个「活着的、会呼吸的东西」——不是贴在墙上的海报，它体现在团队成员如何对待彼此、如何在困难时互相支持。Fiona 特别警惕管理者对她隐瞒问题，她引用了一个网络梗来描述自己的噩梦：「一只狗端着一杯咖啡坐在燃烧的房间里说『一切都好』。」她要求所有管理者——尤其是新上任的——保持开放对话，敢于说出「不好的事」，因为只有摊开来谈，才能一起解决。

她珍视「一个团队」（One Team）的心态：鼓励公开、诚实、健康的辩论，欢迎多元视角；当接近终点线时，回头看看有没有需要帮助的队友——因为团队是一起冲线的。Lenny 补充了他在 Airbnb 时的经验：创始人自上而下对文化的持续强调是维持文化的关键；而 Sheryl Sandberg 曾说过，文化被稀释其实是「你希望拥有的问题」，因为这意味着公司在增长——真正可怕的是不增长、不招聘时文化的停滞与衰退。

十七、闪电轮：书籍、电影与人生格言

在节目的闪电轮环节中，Fiona 分享了她的推荐：

书籍方面，她推荐两位小说家——加拿大作家 Margaret Atwood（以推想小说见长，让人不禁怀疑「这一切会不会真的发生」）和日本作家村上春树（Magical Realism，魔幻现实主义）。但她每年必重读至少一次的书是《小王子》（The Little Prince），用它来提醒自己什么才是真正重要的事。

电影方面，她手机里始终存着三部影片：法国电影《天使爱美丽》（Amélie），因为它完美捕捉了 16 岁高中旅行时巴黎带给她的魔力；以及两部吉卜力动画——《千与千寻》（Spirited Away）和《风之谷》（Nausicaä of the Valley of the Wind）。她特别提到，《风之谷》的女主角娜乌西卡（Nausicaä）在她八九岁时就深深刻印在心中，女主角的领导方式至今仍是她许多领导原则的灵感来源。

产品推荐方面，她介绍了一家来自惠德比岛（Whidbey Island）的本地小企业 Sweet Sisters Body Care，其全系列有机护发护肤产品解决了她困扰多年的面部皮疹问题——仅仅因为换了不含化学添加剂的洗发水就痊愈了。

人生格言上，工作中她常说「保持简单」（Keep It Simple），专注于真正想做好的一件事，不要过度思考；生活中她信奉：「在一个你可以成为任何人的世界里，选择善良。」（In a world where you can be anything, be kind.）

Fiona 给自己的衣服编织，她的编织声在重要会议中常常成为背景音——这既是她与祖母的情感纽带，也像是她在「编译执行文件」：编织与编程的共通之处（两个基本针法如同 0 和 1，堆和队列的概念在编织中同样存在）让她乐在其中。她开玩笑说，她的梦想是退休后开一家以祖母名字命名的毛线店，用好 Cowork 来自动化开票等烦琐工序。

十八、结语：保持学习，保持善良

Fiona 的职业生涯跨越了软件工程从打孔卡到 AI 代理的整个演进历程。她的故事核心可以浓缩为几个关键词：成长心态、亲身体验产品、高自主与高问责的平衡、对用户行为保持好奇、永不停歇的验证。

对于正在经历这场变革的工程领导者、工程师、产品经理和设计师们，她的最终建议是：拥抱变化，直面恐惧，找准自己能控制的一件事情去行动；使用自己团队打造的产品——没有任何指标能替代那种来自亲身使用的直觉；找到那些不再服务你的流程并果断终结它们；最重要的是，花点时间去握住一个人的手，帮他们迈出使用 AI 的第一步。

因为在这个一切皆有可能的时代，真正重要的不是 AI 能做什么，而是你选择用它去创造什么。