Block 如何成为全球最 AI 原生的企业 | Dhanji R. Prasanna
How Block is becoming the most AI-native enterprise in the world | Dhanji R. Prasanna
嘉宾：Dhanji R. Prasanna
全文文稿 · 按对话顺序保留完整内容，深入理解上下文。
本篇目录1 章节
§01原文文稿 · 00:00–1:26:15§01原文文稿 · 00:00–1:26:15
关于通过 AI 提升生产力，人们有很多讨论。有一派人认为这完全是炒作，什么都没奏效，实际上没有人在大规模采用。
我们看到的成效相当可观。我们发现，非常积极采用 AI 的工程团队报告说每周大约节省 8 到 10 个小时。每当我听到这样的统计数字，我都会想，一个重要因素是：这已经是它最差的表现了。这就是现在的基线。事实是，价值每天都在变化，所以你需要跟着这股浪潮一起前进。
我听说你在另一档播客里分享过一个故事：有一位工程师让 Goose 观察着。
你可能正在 Slack 或电子邮件里与同事交流，对方正在讨论某个他们认为值得实现的功能。几个小时后，他会发现 Goose 已经尝试构建这个功能，并在 Git 上为它发起了一个 PR。
哪种级别的工程师从这些工具中获益最多？
令人意外且非常惊喜的是，非技术人员正在使用 AI 智能体和编程工具构建东西。那些能够拥抱它、针对自己的工作日和任务集合进行优化的人，确实从这些工具中获得了最大的影响。
你认为几年后工程师的工作方式会变成什么样，与今天相比会有什么不同？
所有这些 LLM 在夜间和周末都处于闲置状态，因为那时人不在。没有必要这样。它们应该一直工作，应该提前尝试构建我们想要的东西。
关于构建产品或团队，你学到的最反直觉的经验可能是什么？
很多工程师认为代码质量对构建成功的产品很重要。但这两者毫无关系。
今天的嘉宾是 Dhanji Prasanna。Dhanji 是 Block 的首席技术官，负责一支超过 3500 人的团队。在他的领导下，Block 已成为全球最 AI 原生的大型公司之一，基本实现了许多工程和产品负责人希望在自己公司实现的目标。（00:01:55）：我们在对话中聊到了 Block 内部的开源智能体 Goose。按他们的衡量，它平均每周为员工节省 8 到 10 个小时的工作时间，而且这个数字还在上升；我们还讨论了 AI 如何具体提升团队生产力，以及哪些团队受益最大。有趣的是，受益最大的不是工程团队；我们也谈到，要让文化变得高度面向 AI，需要做什么，以及他们内部做出的那项非常无聊的改变，它对生产力的提升甚至超过了任何 AI 工具。（00:02:24）：此外，我们还聊到他构建 Google Wave、Google Plus、Cash App 等产品的经验教训。这期节目适合所有想了解高度拥抱 AI、由技术驱动的大型公司是什么样、又能如何行动的人。如果你喜欢这档播客，别忘了在你常用的播客应用或 YouTube 上订阅和关注，这会带来巨大帮助。（00:02:45）：如果你成为我的 newsletter 年度订阅者，还能免费获得 16 款优秀产品一整年的使用权，包括 Devin、Replit、Lovable、Bolt、n8n、Linear、Superhuman、Descript、Wispr Flow、Gamma、Perplexity、Warp、Granola、Magic Patterns、Raycast、ChatPRD 和 Mobbin。前往 Lennysnewsletter.com，点击 Product Pass。下面请听 Dhanji Prasanna，广告之后见。（00:03:12）：本期由客户通信云 Sinch 赞助。关于数字客户通信，有一件事是这样的：无论你发送的是营销活动、验证码还是账户提醒，都需要可靠地送达用户，这正是 Sinch 的作用。全球最大的 10 家科技公司中有 8 家，以及超过 15 万家企业，都在使用 Sinch 的 API，将消息、电子邮件和通话功能构建到自己的产品中。（00:03:38）：消息领域正在发生一件产品团队需要了解的大事：富通信服务，也就是 RCS。可以把 RCS 想象成 SMS 2.0。你的用户不必下载任何新东西，看到的不再是来自随机号码的短信，而是经过验证的公司名称和标志。这种体验更安全、更具品牌特色，还能提供互动轮播和建议回复等功能。这里的关键是，美国运营商开始采用 RCS。（00:04:06）：Sinch 已经在帮助主要品牌向全球发送 RCS 消息，并帮助 Lenny 播客听众在美国市场竞争开始前完成注册。前往 sinch.com/lenny 了解详情并开始使用。网址是 S-I-N-C-H 点 com/lenny。本期还由 Figma 赞助，Figma Make 的开发者。在 Airbnb 做产品经理时，我仍记得 Figma 出现后如何改善我们的协作方式。（00:04:35）：突然之间，我可以让整个团队参与设计过程，很快地对设计概念提出反馈，整个产品开发过程也变得更有趣。但 Figma 从来没有让我觉得它是为我准备的。它很适合给设计和原型提供反馈，但作为一个构建者，我想做出东西。所以 Figma 构建了 Figma Make。只需几个提示，你就能把任何想法或设计变成完全可运行的原型或应用，让任何人都能继续迭代并与客户验证。（00:05:02）：Figma Make 是一种不同的氛围编程工具，因为它完全位于 Figma 中。你可以使用团队现有的设计构件，让产出看起来更好、感觉更真实，也与团队的构建方式相连接。别再花那么多时间向别人讲解产品愿景，直接展示给他们。用 Figma Make 快速把代码变成原型和应用。前往 figma.com/lenny 查看。Dhanji，感谢你来到这里，欢迎来到播客。
谢谢你，Lenny。很高兴来到这里。
我想从一封信开始。我听说你曾写信给 Jack Dorsey，说服他和 Block 必须更加认真地对待 AI。我想你把它叫作 AI 宣言，而且它似乎真的起了作用。我们会谈到那封信带来的许多变化。先问问你：你在信里写了什么？寄出信后马上发生了什么？
大约两年半前，Jack 确实觉得事情需要改变。我想他意识到这个行业正在走向不同的方向。所以他每周把公司的大约 40 位高管召集到一个房间里，大家一起讨论正在发生的一切，他也把我加入了这个小组。（00:06:26）：后来我发现，我们在讨论许多深刻且相关的事情，但没有人真正关注 AI，于是我写了那封信。说实话，我认为它后来被赋予了自己的生命，但那封信本身没有太多内容，无非是：我认为我们应该做这件事。我认为应该集中推进，而我们必须走在行业前面，成为一家 AI 原生公司，因为行业正朝这个方向发展。
我想说明一点：那时你还不是 CTO，只是类似高级工程师的角色，对吗？
不，是的，实际上当时我是兼职，因为我刚有了孩子，正在回到公司，帮助其中一个工程团队。后来 Jack 来到悉尼，和我一起花了两天时间散步。我们走遍悉尼，反复讨论这件事，然后他向我提供了这份工作。我觉得这是千载难逢的机会，所以接受了。
这有点像“当心自己擅长的事情会带来什么”的情况。好。那么在 Jack 和 Block 的高管都认可你的观点、认为“完全正确，我们需要更深入、更大规模地思考 AI 如何改变我们的构建方式以及我们应该如何构建”之后，你们做了哪些更大的改变？从其他想思考自己应该做什么的公司角度看，又有哪些更大的改变？
一开始，我的主要目标是让 Block 像一家科技公司一样思考。很长一段时间，我们有一点，姑且称之为身份漂移吧。我们把自己说成是一家金融服务公司，有人称我们为金融科技公司，诸如此类。但我开始在当时还叫 Square 的公司工作时，我们一直把自己看作科技公司，就像 Google 或 Facebook 等其他公司一样。（00:08:25）：所以我想让我们回到那种状态。我的第一步是尝试建立一系列聚焦于此的项目：从召集公司的顶尖个人贡献者相互交流，到启动一大批特别项目。每个项目安排大约 2 到 5 名工程师，总共有大约 8 或 9 个项目，我们还恢复了全公司黑客周。（00:08:55）：所有这些共同制造了一点火花：“嘿，我们又在构建技术了，又在推动前沿了。”事情就是这样开始的。之后还有很多步骤：我们从 GM 结构转向职能型组织结构，我认为这是让我们转型为更 AI 原生公司的关键。
好，详细说说。那是什么意思？具体是什么样？为什么这么重要？
当然。在我们进入成熟阶段、Square 运转良好时，它已经是一个很大的业务；后来我们创建了 Cash App，它也走上了同样的路。我们把它们拆分出来，形成了所谓的 GM 结构。实际上，它们像一组独立公司的组合，各自有自己的 CEO，向 Jack 汇报，同时仍共用一个高管团队，但工程实践和设计团队彼此独立。（00:10:00）：除了法律、部分平台等基础资源外，它们几乎在所有方面都是分开的。我认为这对于当时所处的公司阶段很有用，但当你真正想在技术上深入、真正想连接那些改变行业的事件时，你需要单一焦点，于是我们改变了组织。现在所有工程师都向同一个团队汇报，所有设计师也都向同一个团队汇报，分别由一位工程负责人、一位设计负责人等统一负责。（00:10:32）：这就是我们做出的重大转型，它意味着我们可以真正推动 AI、平台以及整体技术深度。
对于正在为此挣扎或试图弄清楚该怎么做的公司，我听到两个重点：第一，开始把自己看作一家科技公司。这不一定适用于每家公司，但似乎很重要的一点是：我们在构建技术，而不是一家金融公司、房地产公司，我们是一家科技公司。第二，组织团队，让工程师向工程负责人汇报，而不是向可能不太理解工程、也没有足够重视工程的 GM 汇报。
是的，我们基本就是这么做的。虽然我不想过度依赖这个例子，但乔布斯回到苹果后也是这么做的。他把苹果改造成职能型组织。我们并不是照着某套剧本走，而是在研究如何让这些团队更注重技术、让我们的 DNA 回到根源时发现了这一点。对我来说，这意味着把工程和设计放在第一位。所以我会对公司说，找到你们的 DNA，并以非常简单、清晰的方式，真正围绕它进行优化。
好，你们做了很多改变，有了这份宣言，所有人都认同了，你们做了很多改变：职能化、技术优先。把现在的工程团队与两三年前相比，最大的不同是什么？
并不是所有人都认同，我可以告诉你。这是一次相当痛苦的转型。我在这个过程中最大的收获之一是，康威定律可能非常、非常有力量。它基本上说，你会交付自己的组织结构。也就是说，团队如何组织、协作群体如何组合以及运营模式是什么，对你构建的东西有很大影响。（00:12:45）：所以最大的变化其实是：过去 Cash App、Afterpay、Square，甚至 TIDAL 或音乐流媒体服务等各个孤岛都有很强的势头，但彼此之间没有真正交流，也没有围绕我们作为一个整体团队五年后想成为什么在技术战略上达成一致。现在这些都不同了。我不是说一切完美，前面仍有很长的路，但至少我们说着同一种语言。（00:13:24）：我们都能使用同样的工具，共享同样的政策。因此，某个级别的高级工程师在整个公司意味着同样的事情。人们可以从一个团队转到另一个有需要的领域。所有这些都非常不同。概括来说，我们现在更重视技术，也把推进技术卓越作为目标，而两三年前这并不完全如此。当时我们在优化其他事情。
我们可以再深入一层，看看人们每天究竟如何工作。假设有一支普通的工程团队，也有一支最优秀、最理想的工程团队，它们现在的工作方式与几年前相比有什么不同？
从细节上说，一些非常 AI 原生、或者处处以 AI 为先的团队，工作方式已经大不相同，因为它们在使用氛围编程工具，本质上是在不手写代码行的情况下进行构建。三年前这还不是事实，我不认为当时世界上任何地方都这样。所以，对于仍在使用非常沉重的遗留代码库的团队来说，变化没有那么明显，但它们也开始遇到后台 AI 流程。我们有一些工具全天候运行，或者在 CI 流程中运行，分析漏洞，甚至查看工单里提交的 bug，并在工程师睡觉时尝试构建补丁。于是工程师第二天来到公司时，就可以查看这些结果。所以我会说，团队的工作方式有很多不同，但不同团队根据自己与这些工具的接近程度，以不同方式进行了适应。
好，我们深入聊聊 AI，我认为这是你们领先许多其他公司的地方。你们打造了自己的智能体，我想你们称它为 Goose。关于 AI 带来的生产力提升，人们有很多讨论。一派人说：“你们不明白 AI 还有多少生产力可以释放。这就是未来，一切都会这样运作。”我们会全部提速 10 倍。另一派人则说：“炒作太过头了，什么都没奏效。大家一直在谈论它，但所有试点都失败了，实际上没有人在大规模采用。”我感觉你可能属于第一派。你们在团队中实际看到了 AI 工具带来的哪些提升？
我们的首要任务是通过 automate Block，也就是让 AI 和各种 AI 形式的自动化遍布整个公司。我们认为，这些大语言模型的实用性才刚刚开始，未来还会继续提升。即使现在，我们也发现，那些非常积极拥抱 AI、每天使用 Goose 的工程团队，报告说每周大约节省 8 到 10 个小时，这个数字是员工自报的。我们还有许多辅助指标来尝试验证这一点：看 PR 数量、功能吞吐量以及一系列其他数据，再由数据科学家用一个复杂公式把这些指标提炼成有意义的结果。我们估计，在整个公司范围内，节省的人工工时可能正朝着 20% 到 25% 的方向发展。我认为这只是开始。更 AI 原生的公司确实更擅长认识到这一点。主要由 AI 初创公司开始的企业，大多更能体现这一点，但“AI 不是万能药，而且它的能力也在增长”这句话同样有道理。所以你要跟着这股浪潮一起前进。很多公司没有意识到这一点，会问：“价值在哪里？”事实是，价值每天都在变化。你需要适应变化，观察今天的价值是什么，并规划明天的价值，然后逐步扩展到最有效的领域。举个例子，我们发现一个特别有效的领域，是让非技术团队能够为自己构建小型软件工具。这是 Block 内部使用 Goose 最令人惊讶、也最令人振奋的方式之一：企业风险管理团队可以构建整套企业风险自助服务系统，把通常需要数周的工作压缩到几个小时。以前他们可能要等内部应用团队来构建这些东西，内部团队会把它放进第二季度的路线图，所有人都只能等着它最终落地；现在，他们可以直接自己完成。我们在这类用例中看到了巨大的生产力提升。另一个让我非常兴奋的领域是另一个叫 Gosling 的工具，可以理解为移动端的 Goose。它通过无障碍 API 在原生层面操作 Android 系统，我们用它来自动化 UI 测试。以前你可能需要雇一大群承包商或 QA，让他们逐个点击每个页面；现在可以把这些步骤编入自动化测试，最后直接生成报告。所以我们在这些领域看到了很多优势。但当大量深厚经验和真正优秀的人聚集在一起时，AI 仍然不如人类，我认为这会随着时间改善，但人类也应该利用这一点。当资深工程师思考架构、设计、竞态条件、编排等问题时，AI 还没有完全达到那个水平。因此，那些没有感受到 AI 成效的公司，往往只是把这些工具丢进庞大的代码库，希望事情自然变好，但现实不是这样。最终我认为 AI 会做到这一点，只是我们目前仍处在实用性的早期阶段。
天哪，你刚才分享的内容里信息太多了。我想追问大约五件事。先说一个你提到的指标：你们如何衡量 AI 对团队的影响？你说的是节省人工工时吗？
没错。
所以目前 AI 工具大约节省了一名工程师四分之一的时间。
这个指标覆盖所有团队。也就是说，包括客服团队、法务团队、风险团队，所有团队都算在内。
哇。
工程方面的情况差异很大，因为正如我之前所说，代码库的规模和复杂程度很重要。如果你是在构建一个全新的代码库，或者为一个新平台开发应用，我们看到的提升就很明显；但对于已经存在的复杂代码库，提升还没有那么大。
太惊人了。每当我听到这样的统计数字，我都会觉得大家需要考虑一个重要因素：这已经是它最差的表现了，是现在的最低水平，是当前的基线。也许听起来还没有那么疯狂，但它会变得疯狂。好，你还谈到 Goose，但还没有解释 Goose 是什么。这是一件非常重要的事情。请解释 Goose 是什么，以及它对你们变得有多重要。
Goose 是一个通用型 AI 智能体。你可以把它理解为一个桌面工具或程序，下载安装到电脑后，它会提供一个界面。你可以像和聊天机器人一样与它对话，比如说：“嘿，Goose，按类别整理我的照片。”它能够查看照片，如果发现里面有很多树，就会把它们归类为自然照片；如果有很多人，就会归类为肖像照片。除了这些，它还可以为你编写软件。（00:22:30）：它可以完成各种任务，我们之所以能够做到这一点，是因为使用了一种叫作模型上下文协议，也就是 MCP 的东西，很多听众可能听说过。这是 Anthropic 提出的协议，我们很早就参与了贡献。模型上下文协议很简单，就是围绕现有工具或能力建立的一套标准化封装。如果企业里有 Salesforce、Snowflake 或 SQL 等工具，都可以用 MCP 封装起来，然后暴露给大语言模型，让模型能够操作它们。（00:23:16）：在那之前，大语言模型除了聊天基本做不了多少事情；而 Goose 给这些“大脑”装上了手脚，让它们能够在数字世界中行动。我们发现，它最大的影响就来自这里，而且它建立在任何人都能实现的开放协议之上。顺便说，Goose 完全开源，所以任何人都可以下载、扩展它、编写自己的 MCP。这就是 Goose 成功的核心。
所以它本质上有点像带界面的 Claude Code，是构建在 Claude、OpenAI ChatGPT 以及一批开源模型之上的桌面应用，对吗？
它可以使用任何模型。我们有可插拔的提供商系统，你可以自行提供 API 密钥，使用 Claude 系列模型或 OpenAI 系列模型；也可以使用开源模型，下载到本地直接运行，或者通过 Ollama 使用，还有一些其他工具能帮助你做到这一点。本质上，它把这些模型生成文本、理解文本的能力应用到了现实场景中。我很喜欢的一个例子是，你可以让 Goose 去制作一份营销报告。它通过 MCP 连接 Snowflake、Tableau 和 Looker，从那里写 SQL 提取数据，对数据进行分析并生成 CSV，还可以在你的桌面上编写 Python 代码完成这些工作。它会用自己了解的 JavaScript 图表库生成图表。（00:25:11）：最后，它会把这一切整理成 PDF、Google 文档或其他格式，甚至可以替你发邮件或上传到某个地方。而且这些事情都是它自己完成的，不需要有人坐在旁边逐步告诉它。你只要说：“我想要这份报告，把它发到这个地址，再给我这些漂亮的图表。”它就会在所有这些系统之间进行编排。
所以在 Block，你们不是直接使用 Claude、ChatGPT，甚至 Cursor 这类应用，而是使用 Goose？
我们允许工程师和全体员工使用他们想用的任何工具。Goose 只是与我们所有系统集成得最好，因为它建立在 MCP 之上，而为现有系统创建一个 MCP 非常容易。比如你使用某个问题跟踪工具，想为它添加 AI 自动化。在 Goose 出现以前，团队要么等供应商构建 AI 能力，要么等待 OpenAI、Anthropic 或 Google 提供一种通用能力，让我们可以接入。但有了 Goose，就不再需要等待。MCP 只需几行代码，就能让所有这些系统在 AI 协助下实现编排，基本上一夜之间就可以完成。而且 Goose 还能编写自己的 MCP，所以它也很容易自我扩展。
这个项目是开源的，而你们花了这么多时间打造它，现在其他公司都可以采用它，建立在你们完成的全部工作之上？
是的，而且有很多公司正在非常积极地使用 Goose。我不想说太多名字，但从竞争对手到紧密合作伙伴，很多公司都在团队中经常使用 Goose。我知道 Databricks 经常谈到它，但你能想到的处于中型科技企业层级的公司，基本都以某种形式使用 Goose。
这太疯狂了。它本来完全可以成为一家独立的大公司，有些全球增长最快的公司实际上把类似的东西当成自己的产品，而你们却把它打造出来并免费提供。
我们相信开源的力量，而我们的核心使命之一就是提高开放程度，这意味着参与开放协议，也参与开源项目。作为一家科技公司，我们建立在大量开源软件之上。我认为几乎每一家科技公司都是如此，无论是 Linux、Java、MySQL，还是任何这类基础组件。因此，我们有强烈的责任感去回馈社区。我们希望构建的不仅对自己和客户有益，而且能够超越 Block 本身、比 Block 发展得更大的东西。这一直是我们的核心价值，从一开始就是这样，早在这轮 AI 浪潮之前就如此。所以 Goose 延续了这一传统，我们非常高兴它取得了现在的成功。
顺便问一下，Goose 这个名字有什么来历？我忍不住想问。
Goose 是对《壮志凌云》的引用。提出这个名字的工程师本人也长得非常像 Goose。如果把他们放在一起对比，简直不可思议。他听到我这样分享一定会很尴尬，但这就是它被叫作 Goose 的原因。之后我们又顺势延伸出了整套鸟类主题。
太有意思了。我听说你在另一档播客里讲过一个故事，有位工程师把这件事推向了极致，让 Goose 观察自己。请讲讲并分享这个故事。
对，当然。他非常专注于 AI，正努力从 Goose 中挖掘所有这些疯狂的想法。Goose 可以通过与工具的特定交互完成我刚才描述的所有事情，也可以直接观察你的屏幕，因此它能理解如何处理图像，以及如何通过屏幕截图处理它所看到的内容。他构建了这样一个系统，本质上是让它一直观察自己所做的一切。他可能正在 Slack 或电子邮件里与同事交流，对方正在讨论某个他们认为值得实现的功能。（00:29:30）：几个小时后，他会发现 Goose 已经尝试构建这个功能，并在 Git 上为它发起了 PR，还做出各种其他古怪的事情。它会尝试把他从原有工作流中引导出来。如果他某个会议超时、赶不上下一件事，Goose 会想出一些他没有编程、也没有写提示词要求的创意做法，但它认为这些做法能够提高他的生产力或改善他的工作日。所以，这确实很疯狂。你得有足够的心理准备，才能让它如此深度地连接你的工作工具，但这也展示了这类工具能够实现什么。
显然，事情就是朝这个方向发展。等它变得足够好之后，我很喜欢这个人正在尝试这件事。它基本上是在观察他工作，预测他接下来应该做什么，并先替他完成一份初稿，这样他就会发现：“这件事的 PR 已经写好了，我们刚才还在会议上讨论它。”太不可思议了。
完全正确。
它到底有多好？现在发展到什么程度？如果从 0 到 100 来看，什么时候才能达到“你只需要思考和说话，它就会替你完成工作”的程度？
对，语音是其中另一个重要部分。它具备语音处理能力，也一直在听他说什么，并尝试理解其中的含义。我认为这目前主要还是一个实验，因为他是我们 Goose 核心团队的成员，也参与 Goose 的开发，所以他有自己的日常工作。这是他在工作之外开发的东西。（00:31:04）：一旦它发展成 Goose 本身或我们在企业中使用的其他工具的原生功能，我认为它会有很大的发展空间，但它现在已经相当不错了。它可能已经减少了大量必须完成的琐事。比如，他会说：“我有时间冲突，那个时间无法参加会议”，或者“我得去接孩子”。（00:31:32）：Goose 就会自动重新安排那场会议，不需要他坐在日历前点击十次。我们过去可能一直在等日历供应商把这些功能加进日历，但现在不需要再等了，因为 AI 已经能够替我们完成编排。
这不是那个在四家不同初创公司同时拥有四份工作、还能把所有工作并行处理并雇人替自己做的人吧？
不是。他是我共事了很长时间的人，也已经在 Block 工作了很久。他就是喜欢做实验，体现了这种实验文化，就像 Goose 的创造者一样，后者也做过同样的事情。
我想沿着这个话题继续聊。你正在看到未来发展的一个缩影，而 Block 在很多方面都走在前面。你认为几年后工程师和产品团队的工作方式会怎样变化，与今天有什么不同？
很大程度上取决于大语言模型性能的提升，但我可以告诉你，我正在尝试改变自己的工作方式，也在尝试改变我们当前团队的工作方式。氛围编程很有趣、很令人兴奋，本质上是你和聊天机器人交谈，然后它替你构建软件，但我认为这种方式的局限性很大。（00:32:59）：它更像乒乓球：你做一件事，等待三四分钟，它返回一些半成品，你还得不断提示、引导和调整，才能让它达到需要的状态。我认为未来会有更多自主性。我们正在用 Goose 的下一版本做一些实验，真正推动它不只是运行两三分钟或五分钟。我们的会话中位数是五分钟，平均时长是七分钟，但我们正在努力把它推进到几个小时。（00:33:36）：我们会说：“这些大语言模型在夜间和周末都处于闲置状态，因为那时人不在，没有必要这样。”它们应该一直工作，应该提前尝试构建我们想要的东西，这也回到了对话前面提到的部分。但我还认为，它们应该能够用以前不可能的方式构建东西。（00:34:04）：过去，作为人类，我们资源有限、带宽有限，还承担着大量协调成本。所以我们必须选择最值得尝试的实验路径。我认为现在不再需要这样。相反，我们可以非常详细地描述多个不同实验，然后去睡觉，第二天早上所有实验都已经构建出来了，我们可以直接丢掉其中五六个。（00:34:34）：我经常做的一件事是，我每天都写代码，但也经常丢掉大量、大量代码。这对我来说有点困难，因为以前从未这样做过。当然，工程师都喜欢删除代码，但这次不一样。你构建一个全新的系统或功能，然后想：“啊，它感觉不太对。我直接删掉，重新开始。”（00:35:00）：所以我认为，未来会更多采用这种工作方式。比如，我们不再把应用重构成另一种界面或演进到新版本，而是直接从头重写这个应用。我现在一直推动团队思考：如果每次发布时都执行 RM -RF，删除整个应用并从头构建，世界会是什么样？今天我们还做不到，但这能说明这些工具正在把我们带向什么方向，以及未来可能实现什么。
有意思的是，软件工程和产品领域有一条普遍规则：永远不要重写。不要试图重写现有东西。你会忘记多年来人们做出的所有微小改进、调整和 bug 修复，以为这会很简单、很直接，最后却可能花一年甚至更久，才能把它恢复到原来的状态。所以现在 AI 让这件事成为可能，而你的意思是，这也许反而是未来应该采用的工作方式。
我认为是这样。关键在于让 AI 尊重所有这些渐进式改进，并把它们作为规格的一部分融入进去。
你刚才提到，让智能体接收一堆想法，夜间构建出来，然后你就能看到结果。我想这可能还会进一步向上延伸：它自己提出想法，开始构建，然后你会说：“好，这个想法很棒。”接着你就能在同一工作流中立刻看到它。
是的，确实如此。上周我实际上就在尝试你说的事情。我有一个正在开发的 Goose 新版本，让它提出改进自己的想法，并在夜间实现这些改进。有时候——
滑坡问题。
……有时它会完全偏离原定脚本，你必须把它稍微拉回来。所以我认为，我们还没有进入完全自我改进、完全自主的时代，但确实处在一个过渡阶段。我们可以给它一个推动，说：“这是我希望你能做的 10 件事，请找出最好的实现方式。”如果功能描述得足够好，我认为它能成功完成其中 60%；剩下的 40% 会遇到困难，需要你介入并调整。
天哪，我在想象一个功能：你给它的目标是推动收入和增长，然后它说：“好，所有人都被解雇了。这是你们的工资支票，接下来交给我。”
我不认为我们会走到那一步。我确实认为，我们需要用大量人类品味来锚定这些 AI，诚实地说，防止它们偏离脚本。这正是我们的设计负责人和设计团队推动我们思考的方向，也是我认为能让我们超越如今大家所说的 AI 垃圾内容时代的差异化因素。关键是把它锚定在对人有意义、具有品味、真正有用且有价值的东西上。
为了让它更具体，有没有什么例子：AI 或某个团队试图推动某件事，而你必须判断这是人类需要介入、让事情保持正轨的地方？
我认为更多发生在流程自动化这类事情上。有时我会收到这样的请求：某个团队说“我们需要从这个供应商购买一个新工具，因为现有工具正在遇到 X、Y 和 Z 问题”。另一个团队会说：“不，不，不，我们可以用 Goose 构建一个应用，在一半时间甚至更短时间内完成同样的事情。”然后作为人类，你会坐在那里想：“这些真的有必要吗？如果我们改变流程，是否根本不需要构建工具？”这正是 AI 不擅长的地方：它无法从全局判断哪些事情重要、哪些事情值得做。（00:39:40）：所以很多时候，我会告诉团队，先质疑基本假设，尤其是我们的信息安全团队。他们有时会为了保护某个东西而把自己绕进死胡同，你会想：“让构建它的团队换一种方式做，或者如果它根本不重要，就别构建了。这样你就不必扩大需要保护的攻击面。”我认为这些领域更适合由人使用判断力，而 AI 目前还做得不好。
你提到，与其购买东西，不如构建自己的软件和工具。这是 AI 领域的一个大问题：它会不会取代所有 SaaS 应用，让 Salesforce 之类的产品走向终结？你们是否大概节省了多少成本？或者说，你们是否因此重新认识到现有 SaaS 软件的价值？毕竟大家都在使用，也支付了很多钱。
我认为，脱离公司的核心使命是一个陷阱。我们的核心使命是赋能经济，让客户、商户和艺术家能够完成销售、支付房租，或者把最新作品上传到 TIDAL。我认为，任何服务于这一使命的事情，我们都应该鼓励和投入；但如果我们只是单纯比较支出金额，那就会偏离使命。（00:41:12）：用内部构建的东西替代供应商工具，可能确实能节省一些钱，但考虑到这会消耗的心理带宽，以及团队技术注意力会被带走，这种节省可能并不值得。所以，我会说，继续回到对公司真正重要的事情上，其他事情自然会从那里展开。
对，我觉得人们常常忘记，维护自己构建的东西需要多少工作。开始时会说：“太好了，我们一个周末就做出来了”，然后迎来的却是多年的持续维护、需求和支持。而且正如你所说，这似乎又回到了一个长期原则：专注于自己的核心能力，其他东西都购买。
对，这是经典的二八问题。我们为客户构建的应用已经足以让我们遇到这个问题。我们会做出一些真正引起共鸣的优秀实验，然后不得不花大量时间处理长尾问题。比如 Cash Card，我认为我们几乎是在一个周末，或者说一周的集成和开发中，构建出了完整功能。（00:42:26）：之后却花了很长时间处理各种边界情况，比如有人给的小费是账单金额的两倍，后端就会彻底出错；或者人们在加油站使用它，而加油站对卡片的扣款方式不同。所以确实如此。正如你所说，我总会回到一个问题：我们为什么要做这件事？它为什么对我们和客户重要？如果它不能明确满足这个问题，我就会把它推迟，认为它没有意义。
本期由 Persona 赞助。Persona 是一个经过验证的身份平台，帮助组织为用户办理入驻、打击欺诈并建立信任。我们在这档播客中经常谈论 AI 的惊人进步，但它也可能是一把双刃剑。每一个令人惊叹的时刻背后，都有欺诈者利用同样的技术制造混乱、洗钱、接管员工身份并冒充企业。（00:43:27）：Persona 通过自动化的用户、企业和员工验证来帮助应对这些威胁。无论你是想发现候选人欺诈、满足年龄限制，还是保护平台安全，Persona 都能根据你的具体需求帮助你验证用户。最重要的是，Persona 让你可以在不增加正常用户阻力的情况下清楚地知道自己面对的是谁。因此，Etsy、LinkedIn、Square 和 Lyft 等领先平台都信任 Persona 来保护自己的平台。Persona 还为听众提供每月 500 次免费服务，持续整整一年。前往 withpersona.com/lenny 开始使用。网址是 withpersona.com/lenny。（00:44:06）：再次感谢 Persona 赞助本期节目。AI 讨论中一个重要主题是招聘和工作岗位。所以我有一个分成两部分的问题：这些 AI 工具的兴起和生产力提升，如何影响你们规划人员数量和招聘？现在 AI 已经成为你们工作方式的重要组成部分，你在招聘时会寻找哪些不同的特质？
我认为事情还没有发展到足以从根本上改变这样一个问题的程度：比如要构建 Cash App 这种规模的应用，到底需要多少人。对我们来说，发生的变化其实完全不同，而且与 AI 无关。正如我们前面谈到的，是从 GM 结构转向职能型结构。在 GM 结构下，我们总是倾向于把工程师人数看成一种可以增加的商品。（00:45:09）：所以，如果想构建更多功能，我们就增加工程师，这就是所谓“神奇的人月”之类的经典陷阱。我认为，转向职能型结构完全改变了这种思维：我们可以利用共享平台和共享模块，也可以请公司各处的专家来指导我们如何更好地完成工作。（00:45:38）：这些变化让招聘方式大不相同。我们不再把工程师看作可以随意增加 100 人来构建 Cash App 下一项产品的商品。但在 AI 方面，我们非常重视那些拥抱这些工具、愿意尝试并从中学习的人。我们并不要求他们一开始就是出色的 AI 实践者。（00:46:14）：如果那些人愿意和我们一起工作，我们当然也会对真正厉害的 AI 人才感兴趣。但我更愿意寻找一个对学习这些工具充满热情、愿意接受它们的应届毕业生，或者一个已经拥抱这些工具、摸索出使用方法的资深人士。我们优化的是这种倾向，而不是某一套特定技能。
所以最大的变化就是寻找拥抱 AI 的人，而不是寻找那些说“我不需要这些东西，我是很厉害的工程师，不需要使用 Cursor、Goose 或这些工具”的人。
我会把它称为学习心态。我们的 CEO Jack 经常谈到这一点：他希望我们成为一家学习优先的公司。我们做的每件事、发布的每个实验，都要问自己能从中学到什么，以及是否觉得自己已经尽了最大努力。我认为，这对他来说甚至比每次都给出正确的业务答案更重要。
那面试时呢？你们是否鼓励工程师在做题时使用 AI 工具？过去一两年里，这件事发生了怎样的变化？
是的，我们现在开始这样做。传统上，我们会使用 CoderPad 之类的工具来擦写代码、解决问题，甚至用伪代码或接近伪代码的方式编程。但现在我们会观察：你能否使用氛围编程构建一些东西？你对这些工具有多熟悉？你如何思考自己与这些工具共同发展？（00:48:04）：不过我认为现在还处于早期阶段。我还不确定，一个人是否会使用 Goose、Cursor 或其他工具，以及使用得多好，对判断他是不是优秀工程师有多大影响。我仍然认为，过去面试时考察的批判性思维，以及深入理解问题技术本质的能力，比一个人是不是完全 AI 原生的程序员重要得多。
我一直在想，很多人都好奇：哪种级别的工程师从这些工具中获益最多？可以说是初级工程师，因为他们现在能完成所有这些工作；也可以说是高级工程师，因为他们更了解系统运作方式，现在可以协调成千上万个智能体替自己工作。你观察到哪个级别受益最大？
这个问题有两个答案。第一，你的判断肯定有道理：越资深或越初级的人，通常越容易、也越愿意采用这些 AI 工具。原因有很多，包括你提到的那些。资深人员非常深入地理解系统如何工作，所以他们几乎会因为出现了一个能替他们完成那些已经做过一百万次、却懒得再做的事情的工具而感到如释重负。（00:49:18）：而初级人员就像我侄子侄女用黑莓之类的设备时那样，操作速度飞快。不是早期的黑莓，而是现在的 iPhone；他们飞快地发送短信，而我还在键盘上用两根手指慢慢敲，足以说明我有多老。（00:49:50）：但我认为，真正令人意外、也非常惊喜的是，非技术人员正在使用 AI 智能体和编程工具构建东西。这说明未来这些角色会如何演变。法律、风险、工程，甚至设计之间的界限都会变得模糊。所以，真正从这些工具中获得最大影响的人，是那些能够拥抱它们、针对自己的工作日和任务集合进行优化的人。
很有意思。很少有人谈到工程生产力的这一面：公司其他部门向工程师提出请求、让他们构建各种临时小工具的需求减少了。这对工程师来说感觉会是巨大的生产力提升。
确实巨大。不过，我认为这有点像修建更宽的高速公路，路上就会出现更多汽车。大家都在构建软件，意味着需要构建的软件更多了，需要进行的协调更多了，大家也更愿意更快地发布、取得更好的结果。所以我们看到的是整体速度提升，以及对更多功能的需求增加。
当然。而且这也连接到你说的没有放慢招聘。我的理解是，你们对人员数量和招聘的需求，想要更多工程师、更多产品人员，完全没有放慢，仿佛 AI 根本不存在。
我们对此考虑得更周全了。正如我说的，在 GM 时代，我们把工程师看作一种商品；现在采用职能型结构后，招聘多少工程师不再简单取决于 Square 或 Cash App 有多少功能。我们更关注需要优化的领域、可以建立深度的地方，以及如何通过模块化、复用和深入平台来加速优先事项。
我很喜欢这个反直觉观点：如果你想提高生产力，忘掉 AI，直接改组为职能型组织。
从某些角度看，这并没有错。还有一个很有意思的例子：我们正在尝试缩短构建时间，也使用 Goose 和很多其他工具来帮助我们，而且它们已经做出了非常出色的事情。我们有一个很酷的工具，会分析测试套件，并根据代码变更选择正确的测试。（00:52:50）：这样我们基本减少了 50% 的测试运行次数，这很不错，也减少了运行这些不必要测试所浪费的 CPU 周期，因此不必像以前那样加剧全球变暖。但把测试转移到云端，或者直接删除不再有意义的测试，节省的时间可能是前者的两到三倍。（00:53:14）：所以，换个说法，我们仍然需要采用组合管理的方法。就像我之前说的，应该购买供应商工具还是内部构建？还要问：“我们真的需要做这个流程吗？”从某些角度看，组织结构比工具本身的效能更重要。
这些话很有智慧，让我想到 Elon 有一整套优化流程，其中一步就是：在开始优化和自动化之前，我们是否真的需要这件事？在我退一步询问你整个职业生涯学到的经验之前，还有没有其他对那些想更深入拥抱 AI、或者只是想帮助团队更前瞻地思考的人很有价值的建议？
我会说，真正尝试亲自使用这些工具。我们之所以能推动大多数采用，我认为是因为 Jack 使用 Goose，我使用 Goose，我们的高管团队都用过 Goose，也经常使用其他 AI 编程工具和助手，而且我们每天都在使用。（00:54:31）：这样我们就能了解自己的工作流如何改变。这比在 LinkedIn、Harvard Business Review 或其他地方读一堆评论文章，然后试图让团队照着做，能告诉你更多关于组织工作流应该如何改变的信息。我认为一切事情都应该这样做：亲身感受，自己使用产品，了解它的优缺点和使用体验，然后再想办法应用到团队中。
我也发现这样做很有帮助，完全同意。别再读别人怎么写，也别再听我们谈论它，直接构建一些东西。我发现真正有效的方法是为自己找一个具体任务或问题，因为这会给你动力，让事情变得真实。比如前几天，我想从 Google 文档里提取图片。Google 文档就像《加州旅馆》：图片放进去之后，除非做一些疯狂的操作，否则根本没有办法取出来。所以我去了 Lovable，说：“构建一个应用，我给你一个 Google 文档 URL，你帮我轻松下载图片。”然后它立刻做到了。
这是个很好的例子。几个月前我也做过类似的事。我儿子要接受很多治疗，有额外的照护需求，所以我想收集这些治疗的收据，分享给我妻子，由她向保险公司申请理赔。但这件事很困难，因为收据格式各不相同。（00:56:05）：有些是截图，有些是 PDF，或者其他格式。所以我让 Goose 来做。所有收据都在我的笔记本电脑上，Goose 想到可以把它们放进 Apple Notes 的同一条笔记里。它把内容转换成 HTML，这样就能无缝同步到我的手机，然后我可以从那里给妻子发邮件或分享。（00:56:30）：这是我自己从未想到的办法。它通过 AppleScript 完成了这些工作，在后台替我控制电脑。这些工具帮助我们的方式非常出人意料；正如你说的，越多用它们解决真实问题，就越能理解它们的优势，以及可以把它们用在哪里。
我喜欢这个例子。顺便问一下，你只是去 Goose 那里说：“这是我的问题，你会怎么解决？”
差不多。我说：“Google Drive 里有这些收据，我们在那里遇到了类似的来源问题。我需要把它们放进同一种格式，汇总总额，还要做这些事情。”它先尝试了几种方法：下载收据，用 PDF 阅读器读取，等等。Goose 有一点我认为很多其他 AI 智能体也从我们这里学到了：如果它尝试几种方法都失败了，就会退回去换一条路，并不断尝试，直到取得一些进展。（00:57:33）：它最后选择 AppleScript 来完成，因为它有控制我电脑的 MCP 扩展。这和我们前几天谈到的那位工程师用来观察屏幕的机制相同，但这次它处理的是一个非常具体的问题。所以，这些工具能做什么确实令人惊讶，而允许它们灵活尝试，是学习如何使用它们的重要部分。
真酷。顺便问一下，普通人能运行 Goose 吗？能直接下载 Goose，用它替代 Claude 吗？
当然可以。你可以从我们的网站下载，我们可以把链接放在节目说明里。你可以安装它，我相信它支持 Mac、Windows 和 Linux。它是 Electron 应用，所以这些系统都能运行。它还有命令行界面，更习惯使用命令行的人也可以用这个界面。
哇，你们确实在和那些构建基础模型的巨头竞争。用最简单的方式说，Goose 与其他产品相比是什么？它像 Claude Code 吗？
我认为它和 Claude Code 有些不同，因为 Goose 的核心是一个实现 MCP 的平台。MCP 让它能够动态扩展，因此它可以替你完成各种事情：既能自动化我们刚才说的 Google 文档和笔记等任务，也能通过其他 MCP 直接完成编程任务。（00:59:11）：它可以索引代码并据此工作。所以它更像一个可扩展的平台，位于经典 AI 助手和更专门的 Cursor、Claude Code 之间。经典助手可以回答天气、计算两个日期相差几个月之类的问题，而 Cursor 和 Claude Code 更聚焦于特定工作。
基本上，它把所有能力结合起来，而且完全免费。你只需要支付大语言模型的 token 费用。
对，当然也可以使用开源模型，不过——
天哪，太疯狂了。在 Block 这样构建 Goose 的团队里工作一定很有趣。好，我把视角拉远一点。你担任 CTO 差不多两年了。如果能回到几年前，在你接任这个职位前给自己轻声说几条建议或经验，你希望当时知道什么？
我想到两件不同的事。第一，是我们前面谈过的康威定律：如果不改变组织中人与人之间的关系结构，就很难改变结果。我在某种程度上一直知道这一点，但真正从切身经历中理解它的力量，是很重要的。另一件我可能是吃了苦头才学会的事是：你通常只有在事情出问题时才会听到反馈。（01:00:49）：事情进展顺利时，周围反而会有一种诡异的寂静，你会想：“我做的是正确的事吗？我关注的是正确的问题吗？”所以你需要形成判断力，也要定期留出时间退一步，从整体角度审视事情。这些时间必须主动安排，我希望自己接任时就知道这一点。
回顾你在 Block 的经历，我总差点说 Square，因为我已经习惯了。但我知道 Block 是更大的公司，Square 只是其中一个业务。为了让大家理解，Square 是 Block 旗下的一个业务部门、一个产品。
没错。我们有 Square、Afterpay、Cash App 和 TIDAL 四个主要品牌，还有 Bitkey 和 Proto，它们专注于比特币，我们在这两个品牌中做硬件芯片。
很好。有些人可能会困惑我们到底在谈什么。回顾你在 Block 的经历，关于构建产品或团队，你学到的最反直觉经验是什么？它违背了哪些常见的创业智慧？
代码质量是一个例子。作为工程师，我很早就学到这一点，而且它一次又一次得到验证。很多工程师认为代码质量对构建成功产品很重要，但两者毫无关系。我最喜欢的例子是 YouTube。我在 Google 工作时正好是 YouTube 被收购的时期，记得大家都非常焦虑，说 YouTube 的代码库很糟、架构很差，甚至把视频以 blob 存在 MySQL 里。（01:02:41）：你可以说，YouTube 是 Google 远远最成功的产品，甚至可能比其他很多产品加起来还成功。所以产品有多成功，与架构设计得多好关系很小。Google Video 就是反例，很多人可能记得它，它比 YouTube 支持更多格式、更高分辨率，也能上传一小时的视频，而当时 YouTube 什么都没有，只能上传一两分钟的短视频，但 YouTube 远远击败了它。（01:03:11）：所以要始终记住，我们为什么构建这些工具、应用或产品？它们是为人服务、解决具体问题的。对我们来说，是帮助 Square 商户完成销售，比如把咖啡或自己制作的东西卖给你。（01:03:49）：只要 Android 平台的表现能服务这个需求，它架构得多好并不重要。我职业生涯中一直很难真正接受这一点，也不断遇到认为必须重构、必须用更好的方式做事的工程师。我会说：“这些代码明天全删掉也没关系。专注于我们要构建什么，以及为谁构建。”
这是非常深刻的洞察和经验。YouTube 这个故事很有趣。你的意思是，他们把视频内容作为 blob 数据存进 MySQL 的行列中？
这是当时的普遍说法，我没有实际看过代码，所以无法验证。另一个说法是，他们使用了完全基于 Python 的技术栈，相比 Google 当时高度优化的 C++ 和 Java 服务器，速度慢得多。
太好笑了。这也让我想到，在公司内部工作时，你可能会觉得：“这里完全是混乱，没有人知道发生了什么，一切马上就要崩溃。”但每家成功的高速增长公司基本都是这样。
这确实有一定道理。
所以，企业成功还有很多更重要的因素。正如你说的，关键是你是否在解决真实问题，能否把产品交到用户手里，并持续为他们解决真实问题。重点不在代码质量，也不在内部运营得多好。
完全正确。Cash App 早期也有同样的情况。我从团队约 10 名工程师时负责工程，后来增长到 200 多名，并达到大约 1000 万到 2000 万用户。外部看起来一团混乱：人们会构建随机实验、发布它们，看起来也不像在严格遵守软件生命周期之类的政策，这在某种程度上确实如此。（01:06:13）：我的想法一直是，我们有这么多优秀工程师，如果把他们限制在非常严格、狭窄的范围里，我造成的伤害可能大于帮助。如果他们想暂时花时间构建某个完全浪费时间的东西，我可以接受；但如果另一方面他们能交付惊人的成果，我也愿意容忍。（01:06:44）：这需要平衡，因为工程师可能会钻进兔子洞。但混乱也会孕育创造力，你需要知道如何构建受控的混乱：先建立不会破裂的基础，避免重大责任风险或资金损失；在这些基础稳固后，让工程师自由试验、迭代和做让他们兴奋的事，这才是理想状态。
说到受控的混乱，你在 Block、或者说当时在 Square 工作时，曾经有四年半的头衔是“疯狂科学家”。
是的。那时我主要兼职，因为孩子还很小，而且需要额外照护。我是多个项目的顾问，努力帮助一些古怪的事情启动。我很感谢 Block 给了我在职业生涯中拥有这个角色的自由。
在进入 Fail Corner 之前，我再问一个问题。我已经听到你分享了几条职业经验。还有没有其他核心领导力经验，对你能够做好这些工作很重要？
我认为任何事情都应该从小处开始。有人说过“想煮一杯茶，却要先把海洋烧开”，我不知道是谁说的，但这句话非常实用，我一直会想起它。你永远做不到。如果只是要泡一杯茶，就泡这一杯，不需要把所有海水都烧开。
听起来茶一定不好喝，毕竟是海水。
还有一句话，我想是 Carl Sagan 说的：“如果你想从零开始做苹果派，就必须先发明宇宙。”所以要把范围缩小到眼前、可实现的事情。这非常重要，也是我们的核心原则之一。早期还是 Square 时，我们就一直坚持从小处开始。
有没有一个做得很好，或者没有做好的例子？
Goose 就是从小处开始的。它只是一个工程师利用自己的时间，尝试构建一个有用的东西，验证自己的判断。Goose 的创造者 Brad 很早就相信，智能体会是从大语言模型中释放价值的方式，早在这个词流行前就是如此。他做了一个概念验证，分享给很多人，也分享给 Databricks 和 Anthropic，获得了他们的兴趣，并从中学到很多。（01:09:59）：于是它逐渐形成了势头。公司内部也类似。Cash App 本身最初也是一个黑客周创意，后来一步步变大。很多项目都从小实验开始，再在其上继续构建。我们还是第一家推出比特币产品的上市公司，那同样源于一个黑客周创意，由 Jack、我和另一位工程师共同完成。
那是黑客马拉松团队吗？你、Jack Dorsey 和一位工程师？
对，就我们三个人。
难以置信。
对，非常棒。我们去买了一杯 Blue Bottle 咖啡，用 Cash Card 通过比特币支付。回头看，那可能是最昂贵的一杯咖啡。
当时比特币价格是多少？2 万美元？
我想当时是 6000 或 7000 美元，不确定。
现在是 12 万美元左右。太棒了。
这说明，只要先聚焦一个小事情，就能把产品做成真正可用、能交到用户手里的东西。
再强调一下这个反面例子：有了一个大想法，就立刻投入大量资源、马上做大。
当然。我也经历过这样的团队。我在 Google 工作时参与过 Google Wave，它试图满足所有人的所有需求。在 Google 之外还没有真正用户时，我们就已经有 70 或 80 名工程师在构建它。这说明，如果一开始就做大、第一天就想做大，可能没有真正面对现实，也没有根据现实调整。
我记得 Google Wave，当然记得。它很漂亮，也有很多炒作，但我不记得它具体是做什么的，只记得看起来很棒。
那件事让我学到了很多。
还有什么？其他重要经验呢？
这两点最重要，但我还要说，要质疑一切基础假设。有时我们作为专业人士，过度专注于当天、当周、当月正在构建的东西，却停不下来问：我们真的应该构建它吗？构建它的目的是什么？我们能不能构建完全不同、但更符合核心使命的东西？（01:12:46）：这听起来有些老生常谈，但你必须反复提醒自己应用它。
我以前邀请过你的同事 IO 上节目，他曾和你一起做 Cash App。
对。
他是我的朋友，非常厉害。他曾说过类似的话，我记不清原话了，大意是：要触及正在做的事情的“底层金属”，亲手接触你正在构建的东西，深入根基，真正理解发生了什么。我猜这对构建 Cash App 和 Cash Card 非常重要。
IO 是我合作过的最优秀的产品人员之一，也是我最亲密的朋友之一。所以这件事我完全同意，你说得对。
好，现在进入播客的固定环节 Fail Corner。我已经听到你分享过一个失败产品的例子，想再问一个：你参与过、但没有成功的产品是什么？听众经常看到成功人士来节目分享成功故事，却听不到事情不顺利时的经历。所以，这个问题很简单：你做过哪个产品没有成功？它教会了你什么？
这是个很有价值的问题。我的职业生涯基本上是一连串失败产品接着失败产品。Google Wave 就是一个例子。我还在 Google+ 上工作过很短时间，那也是一次史诗级失败。
这个例子不错。
我曾在社交网络初创公司 Secret 工作，它短暂辉煌后就崩溃了。后来我们又做过一家电子邮件初创公司，同样很有希望，却最终失败。Canva 的联合创始人也参与了那个项目。我的职业生涯充满失败，但每次我都会学到东西，并提醒自己绝不能再次犯同类错误。Cash App 是我的重大成功：我很早就参与，后来它成长为人们喜爱的大型业务和产品。我的职业就是从失败中提取经验，也获得谦逊，愿意听取他人的批评，而不是以为自己拥有所有答案。
我敢说这些失败产品的代码一定很漂亮，也做过很多很好的架构决策。当然有些产品在各方面都很糟，所以失败的原因很多。Dhanji，在闪电问答前，还有什么想强调的吗？
我们正处于变化很多的时代，人们害怕、不愿改变，或不确定未来。我建议关注对自己重要的事。对我们来说是开源、开放协议和改善所有人的使用机会。我很幸运，职业生涯中做过的产品都免费或接近免费，或者有免费层，任何人都能使用。任何人都可以成为 Square 商户。（01:16:42）：早期人们甚至用 Square 做点对点转账，这后来促成了 Cash App。所以要找出对你重要的事，并围绕它优化。技术趋势往哪个方向发展并不重要，因为技术应当服务我们。如果你有重要的使命，就能让技术服务于使命，这比精通技术或追逐每一个趋势重要得多。
这是很好的建议。面对这么多信息，很多人会焦虑，觉得自己不了解所有事情，不如社交媒体上的人，尤其觉得自己落后于 AI。你的意思是，关注真正重要的事，去做它，而不必成为所有最新 AI 新闻的专家。
对。如果一件事没有意义，也没有乐趣，那你可能就不该做它。
现在进入闪电问答。我有五个问题，你准备好了吗？
好，问吧。
我看到你身后有很多书，很期待你的答案。你最常推荐哪两三本书？
我认为不应该读关于日常工作或职业的书。我读小说、经典、诗歌、哲学和历史，这些书能拓展思维、带来创意，也让你思考人的处境，比自助书或“如何成为优秀工程经理”的书有价值。（01:18:39）：我很喜欢米哈伊尔·布尔加科夫的《大师与玛格丽特》，它是俄罗斯文学杰作。我一直喜欢丁尼生的诗，在最不确定或悲伤的时候，它总能让我找到内心的中心。
以前没听过这些推荐，我很期待读它们。作为大型科技公司的 CTO，这些选择很酷。最近最喜欢的电影或电视剧是什么？
我觉得《异形：地球》很棒，由《冰血暴》电视剧的创作者 Noah Hawley 制作。他把高艺术电影技巧用于通俗科幻，画面和质感都很惊艳，也抓住了《异形》系列那种有趣的通俗科幻气质。我还在看《流人》，它是电视上最好的剧之一。
我也喜欢《流人》，新一季已经播出，录制当天刚更新第五集。《异形：地球》我也刚看过，很诡异，满是黏糊糊的小生物到处爬。
我喜欢它的美学。它抓住了原版《异形》的核心，而且每一幕都像在看画，或有人在为你读小说，展开得很有思考。
我一部异形作品都没看过，却很喜欢《异形：地球》。结尾节奏似乎慢了一点，但总体很有趣。下一个问题：最近发现、很喜欢的产品是什么？可以是应用、设备或厨房用品。
我是玩家，喜欢玩游戏，所以是 Steam Deck，尤其是最新的 Steam Deck OLED。它是一件漂亮的硬件，让你玩最好的游戏，同时高度可扩展、可定制。在大科技公司不断说必须封闭一切、锁定用户体验时，Valve 证明这完全没有必要。（01:21:28）：你可以安装竞争对手的应用商店，也可以安装 Windows，把它当电脑使用，甚至编写能在上面运行的程序。我很喜欢它，它漂亮又好用。
你在工作或生活中经常回想的生活格言是什么？
如果你每天早晨醒来，对当天要做的职业工作没有活力，那就改变一些事情；必要时就辞职，或者换一种做法。不要接受别人分配给你的生活。我一直这样尝试，有时有效，有时无效，但值得经常问自己。
很多人很难做到这一点，害怕辞职后不知道去哪里。有什么帮助你克服这种恐惧？
告诉自己，一年后回头看，眼前这个看似巨大的、改变人生的问题，可能会变得微不足道。我们常常过度思考、害怕改变，但事后它们并没有那么严重。时间和经历会让你看到世界更大，做有用的事、提升自己永远不晚。记住，事情通常没有当下看起来那么巨大、灰暗或决定性。
你在 Square 做过多年疯狂科学家。现实或流行文化中，你最喜欢的另一位疯狂科学家是谁？
我总会想到《回到未来》里的 Doc Brown。他是我这一代人心中的典型疯狂科学家：因为强烈愿望而决定建造时间机器，然后整部电影都在修复它制造的问题。他一直是我很喜欢的角色。
我想到《Pink y 与大脑》里的 Pinky。
对，这也是很好的例子。
Dhanji，这次太棒了。谢谢你来到这里。最后两个问题：如果大家想了解 Goose 或 Block 的其他项目，可以在哪里找到你？听众怎样对你有帮助？
可以查看我们的 GitHub 页面，那里有 Goose 和 Block 的其他开源项目，也有很多 Android 开源工作。你也可以在 LinkedIn 找到我，欢迎联系。（01:25:06）：听众可以要求公司、雇主和团队做得更好。Block 总会问：“我们能否默认把它开源？能否为不只是自己或客户的人构建？能否让所有人受益？”（01:25:37）：AI 时代尤其重要，因为大家都在建造围墙花园，试图占据新平台的一部分。请对人们提出更高要求。互联网曾承诺开放共享信息、让所有人受益，我希望 AI 也能实现这一点。
这是非常美好的收尾。Dhanji，谢谢你来到这里。
谢谢你，Lenny。我很享受这次对话。谢谢。
我也很感谢你。
干杯。
大家再见。感谢收听。如果你觉得这期节目有价值，可以在 Apple Podcasts、Spotify 或常用播客应用订阅。也请评分或留下评论，这会帮助更多听众找到节目。所有往期节目和更多信息请访问 lennys podcast.com。下期再见。