Block 如何成为全球最 AI 原生的企业 | Dhanji R. Prasanna

Dhanji R. Prasanna 2025-10-26

Block 如何成为全球最 AI 原生的企业 | Dhanji R. Prasanna

Block 如何成为全球最 AI 原生的企业 | Dhanji R. Prasanna

AI 带来的生产力提升

**Lenny Rachitsky：**关于 AI 带来的生产力提升，大家讨论得很多。有一派人觉得都是过度炒作，什么都没真正起效，没有人在大规模地落地这些东西。

**Dhanji R. Prasanna：**我们看到了显著的收益。我们发现那些非常非常积极拥抱 AI 的工程团队，每周能节省大约八到十个小时的工作时间。每当我听到这样的数据，我觉得很重要的一点是——这已经是它最差的时候了，这就是现在的基准线。事实是，这个价值每天都在变化，所以你需要乘上那波浪潮一起前进。

**Lenny Rachitsky：**我听你在另一个播客上分享过一个故事，说有个工程师让 Goose 在旁监听。

**Dhanji R. Prasanna：**你会在 Slack 或电子邮件里跟同事讨论某个他们认为值得实现的功能。几个小时后，他会发现 Goose 已经尝试把那个功能做了出来，并且在 Git 上开了一个 PR。

**Lenny Rachitsky：**哪个级别的工程师从这些工具中受益最大？

**Dhanji R. Prasanna：**令人惊讶、也非常棒的是，那些非技术人员正在使用大语言模型（LLM）的代理（agent）和编程工具来构建东西。那些能够拥抱这些工具、为自己的工作日和特定任务集进行优化的人，才是真正从这些工具中展现出最大影响力的。

**Lenny Rachitsky：**你觉得几年后工程师的工作方式和今天相比会有什么不同？

**Dhanji R. Prasanna：**所有这些 LLM 在夜间和周末都在闲置，而人类不在。这没有必要。它们应该一直在工作。它们应该预判我们想要什么，并提前去构建。

**Lenny Rachitsky：**关于打造产品或建设团队，你学到的最反直觉的教训是什么？

**Dhanji R. Prasanna：**很多工程师认为代码质量对于打造成功的产品至关重要。这两者之间毫无关系。

嘉宾介绍

**Lenny Rachitsky：**今天的嘉宾是 Dhanji Prasanna。Dhanji 是 Block 的首席技术官，管理着一个超过 3500 人的团队。在他的领导下，Block 已经成为全球最 AI 原生的大型公司之一，基本上实现了许多工程和产品负责人在各自公司里想要达成的目标。

在我们的对话中，我们聊到了他们内部名为 Goose 的开源代理——按照他们的衡量，平均每周为员工节省八到十个小时的工作时间，而且这个数字还在上升。我们还聊到了 AI 具体如何让团队更高效，以及哪些团队受益最大——有趣的是，并不是工程团队。我们还聊到了将企业文化转变为高度 AI 导向需要付出什么，以及他们内部做的一个非常无聊的改变，却比任何 AI 工具都更能提升生产力。此外，还有从构建 Google Wave、Google Plus 和 Cash App 等产品中积累的经验教训。这期节目适合所有好奇一家高度 AI 前沿、技术驱动的大型公司是什么样子、能如何运作的人。如果你喜欢这档播客，别忘了在你最喜欢的播客应用或 YouTube 上订阅关注，这对我帮助非常大。

[广告部分已跳过]

**Lenny Rachitsky：**Dhanji，非常感谢你的到来，欢迎来到播客。

**Dhanji R. Prasanna：**谢谢你，Lenny。很高兴来到这里。

致 Jack Dorsey 的 AI 宣言

**Lenny Rachitsky：**我想从一封信说起——听说你给 Jack Dorsey 写了一封信，想说服他以及 Block 需要更加重视 AI。我记得你把它叫做你的 AI 宣言，看起来效果非常好。我们后面会聊到由此带来的一系列变化。那么请问，你在那封信里说了什么，信发出之后紧接着发生了什么？

**Dhanji R. Prasanna：**大约两年半以前，Jack 确实觉得需要做出改变。我认为他预感到行业正在朝一个不同的方向发展。于是他把公司大约四十位高管召集到一起，每周定期开会，把正在发生的所有事情都讨论一遍，他把我加入了这个小组。到了某个时候，我注意到我们在讨论很多深入的话题、很多相关的事情，但没有人真正关注 AI。于是我就写了那封信。说实话，这封信后来似乎有了自己的生命，但信本身并没有太多内容，无非就是——我认为我们应该做这件事，应该集中力量来做，走在前面、成为一家 AI 原生公司对我们来说很重要，因为这就是行业的发展方向。

**Lenny Rachitsky：**我想补充一点，值得一提的是你当时还不是 CTO。你当时只是一名高级工程师之类的？

**Dhanji R. Prasanna：**对，事实上我当时还是兼职状态，因为我刚有了一个孩子，正在陆续回归，帮一个工程团队做些事情。后来 Jack 专门飞到悉尼来找我，跟我待了两天。我们俩都喜欢长距离步行，所以就围着悉尼到处走，上上下下把事情聊了个透。然后他就把这个职位给了我，我觉得这是一个千载难逢的好机会，于是就接了。

**Lenny Rachitsky：**这有点像”小心你擅长什么”那种情况。好吧。那在 Jack 和 Block 的高管们都认可”这完全正确，我们需要更大力度地投入，更深入地思考 AI 如何改变我们的构建方式以及我们应该如何构建”之后，你做出的一些更大的改变有哪些？从其他正在收听、试图思考自己该怎么做的公司角度来看，可以借鉴些什么？

回归技术公司本源

**Dhanji R. Prasanna：**最开始，我的主要重点是让 Block 回归到以技术公司的思维方式来运作。很长一段时间以来，我们多少出现了一种——我想称之为身份漂移（identity drift）吧。我们把自己说成是一家金融服务公司，有人叫我们 FinTech，诸如此类。但当初我加入那时还叫 Square 的公司时，我们一直把自己看作一家技术公司，就像 Google、Facebook 或者其他任何一家一样。

所以我想要让我们回到那个状态。于是做的第一件事就是推行一系列聚焦于此的计划——从把公司最顶尖的个人贡献者（IC）召集到一起互相交流，到启动一大批特殊项目。每个项目大约两到五名工程师，总共大概八九个，另外我们还恢复了全公司范围的 Hack Week。

所有这些做法产生了一点火花——“嘿，我们又在造技术了，又在努力推进前沿了。“事情就这样开始了。之后还有一系列步骤，其中我们从 GM 结构转变为职能型组织结构（functional org structure），我认为这是让我们成功转型为一家更 AI 原生公司的关键。

从 GM 结构到职能型组织

**Lenny Rachitsky：**好，多聊聊这个。这是什么意思？具体长什么样？为什么这么重要？

**Dhanji R. Prasanna：**当然。在我们成熟的阶段，也就是 Square 运转得非常好的时候，它已经是一个非常大的业务了，然后我们又做了 Cash App，后者也发展得很顺利。我们当时几乎把它们拆分为我们所说的 GM 结构来运营——也就是说，它们实际上被当作一个独立公司的组合来管理，每个都有自己的 CEO，都直接向 Jack 汇报。虽然是同一个高管团队，但他们有各自独立的工程实践、各自独立的设计团队。

除了法律部门和一些平台等基础性共享资源之外，它们在几乎所有方面都是相互独立的。我认为那种结构在我们公司当时所处的发展阶段确实非常有用，但当你真正想在技术上深入下去，当你想要对接那些正在改变行业格局的事件时，你需要一个统一的聚焦点，所以我们重组了整个组织。

现在所有工程师都向同一个团队汇报，所有设计师也都向同一个团队汇报，有单一的工程负责人、单一的设计负责人等等。这就是我们做出的重大转型，这意味着我们可以真正地大力推进 AI，推进平台建设，以及整体上提升技术深度。

**Lenny Rachitsky：**对于那些在这个问题上挣扎或者正在摸索怎么做的公司，我从你这里听到的有两点：一是开始把自己看作一家技术公司——这不一定适用于每家公司，但看起来是一个重要元素，就是我们是在造技术，不是金融公司，不是房地产公司，我们是技术公司。二是组织团队的方式——比如让工程师向工程负责人汇报，而不是向一个可能不太懂工程或者对工程不够重视的 GM 汇报。

**Dhanji R. Prasanna：**对，我觉得基本上就是我们做的这些。不是要过度依赖这个类比，但乔布斯回到 Apple 时也是这么做的——他把 Apple 重组为职能型结构。我们并不是在照搬什么剧本。我们是在探索”到底需要什么才能让这些团队更加聚焦技术、让我们的 DNA 回归本源”的过程中发现了这一点——而我们的本源就是把工程和设计放在首位，这也是”技术优先”对我的意义。所以我会对其他公司说，找到你的 DNA，然后用非常简单清晰的方式去为它优化。

康威定律与组织阵痛

**Lenny Rachitsky：**好，那你做了很多改变，写了那份宣言，所有人都认同了，做了很多改变——技术优先、职能型组织。对比一下你们的工程团队今天的工作方式和两三年前相比，最大的不同是什么？

**Dhanji R. Prasanna：**并不是所有人都认同的，我告诉你。这是一个相当痛苦的转型。我认为在整个过程中我学到最多的一点就是，康威定律（Conway’s Law）的力量可以非常非常强大。这条定律基本上说的是——你交付的就是你的组织结构。也就是说，你的团队组织方式、协作模式和运营模型，在很大程度上决定了你构建出来的东西。

所以我觉得本质上最大的变化就在于——之前我们每个业务条线都有很强的惯性，不管是 Cash App、Afterpay、Square，还是 TIDAL——我们的音乐流媒体服务。各个团队之间没有真正在交流，没有在技术战略上达成对齐，甚至没有讨论过作为一个整体我们五年后想成为什么。现在这些都不一样了。我不是说一切都很完美，前面还有很长的路要走，但我们至少说着同一种语言了。

大家都使用相同的工具，遵循相同的制度。比如”高级工程师”这个级别在整个公司范围内意味着同样的标准。人们可以从一个团队调动到另一个有需求的团队。所有这些事情都和以前完全不同。但总结一下的话，我会说我们现在聚焦于技术，以推动技术卓越为目标。而在两三年前，这一点并不真正成立。那时候我们在优化的目标是别的。

日常工程工作的变化

**Lenny Rachitsky：**也许再往下一层，聊聊人们每天实际的工作方式。如果你去看一个工程团队——比如说一个普通工程团队，以及一个最顶尖的最优工程团队——他们今天的工作方式和几年前相比有什么不同？

**Dhanji R. Prasanna：**在微观层面上，某些非常 AI 原生或者到处都在以 AI 优先方式构建的团队，工作方式与之前截然不同，因为他们使用 vibe code 工具，基本上不需要逐行手写代码就能构建产品，而三年前这完全不存在。我认为当时全世界都不存在这种情况。所以对于那些仍在处理非常重的遗留代码库的团队来说，变化是非常戏剧性的。

这种情况在遗留代码库团队中没有那么明显，但他们也正在接触各种后台 AI 进程。我们有这些全天候运行或在 CI 流水线中运行的工具，它们在分析漏洞，甚至在查看工单上报的 bug 并尝试构建补丁——而工程师们还在睡觉。所以他们第二天上班就能看到结果。我想说，团队的工作方式在很多方面都发生了变化，但不同团队根据他们与工具的亲近程度，适应方式也各不相同。

AI 生产力：两极分化的观点

**Lenny Rachitsky：**好，那让我深入聊聊 AI 这个话题，我觉得这是你们相比很多其他公司最领先的领域。你们构建了自己的代理（agent），我想你是这样描述 Goose 的。现在有很多关于 AI 带来生产力提升的讨论。有一个阵营的人说，你不了解 AI 能带来多大的生产力提升，它就是未来，一切都会朝这个方向发展。我们都在 10 倍加速。也有另一个阵营的人说，这全是过度炒作，什么都没用。人们只是嘴上说说，那些试点全都失败了，没有人真正在大规模采用。我觉得你可能属于第一个阵营。你在团队中从 AI 工具上实际看到了什么样的收益？

**Dhanji R. Prasanna：**我们的头等要务是通过自动化 Block，意思是把 AI 和 AI 形式的自动化推广到整个公司。我们觉得这还只是所有这些大语言模型（LLM）实用性的起点，而且我认为我们会持续看到它的进步。但即便是现在，我们发现那些非常积极拥抱 AI、每天都在使用 Goose 的工程团队，报告每周节省了大约 8 到 10 个小时——这是自我报告的数据。然后我们还有一系列校验指标来验证这一点。

所以我们查看 PR，查看功能吞吐量，查看一大堆东西，然后让数据科学家设计一个复杂公式，试图把这些提炼成有意义的东西。我们感觉在整个公司范围内，大约节省了 20% 到 25% 的人工工时。我认为这只是这一切的开端。我确实觉得那些更加 AI 原生的公司在实现这一点上做得更好。

所以那些一开始就以 AI 起步的创业公司大多如此，但这种说法也有一定道理——AI 不是万能药，而且它的能力也在不断增长。所以你需要随这股浪潮一起前行。我认为很多公司没有意识到这一点，他们会说：“价值到底在哪里？“而事实是，价值每天都在变。所以你需要保持适应性，看看今天的价值是什么，规划明天的价值会是什么，然后逐步扩展到那些最有效的领域。

非技术团队的自助工具构建

我给你举个例子。我们发现 AI 真正擅长的领域之一，就是让非技术团队能够为自己构建小型软件工具。这已经成为 Goose 在 Block 内部最令人惊喜和振奋的用途之一——我们的企业风险管理团队构建了一整套企业风险自助服务系统，把数周的工作压缩到了几个小时。按照以前的做法，他们要等内部应用团队之类的去构建，然后把它排进第二季度的路线图，所有人只能干等，直到一切到位。但现在你可以直接动手做。

所以在这类用例中，我们看到了巨大的生产力提升。另一个让我非常兴奋的领域是我们还有一个叫做 Gosling 的工具，它实际上就是移动端的 Goose。它通过无障碍 API 在原生层面操控 Android 操作系统，我们用它来自动化 UI 测试。

以前你必须雇一支承包商或 QA 大军，让他们逐屏点击测试，但现在我们可以把这些都做成自动化测试，最后给你一份报告。所以我们在这些类型的领域看到了很多优势。但在那些深度很深、有很多非常强的人汇聚的地方，我认为 AI 仍然不及人类。这一点可能随时间推移而改善，但这也是我们作为人类应该发挥优势的地方。

所以当你有一些非常资深的工程师，他们在思考架构、设计、竞态条件、编排这类问题时，AI 在这些领域还没有到位。因此我认为那些没有感受到 AI 成功的公司，只是把这些工具扔到他们庞大的代码库上，然后期望好事发生——但实际情况并非如此。最终我确实认为它会到达那个阶段，但现在我们仍处于早期实用阶段。

如何衡量 AI 的影响

**Lenny Rachitsky：**天哪，你刚才分享的内容信息量太大了，有五件事我想追问。好，其中一个是你说到的那个指标——你如何衡量 AI 在团队中的影响。就是人工节省工时，你是这么描述的吗？

**Dhanji R. Prasanna：**没错，是的。

**Lenny Rachitsky：**所以目前大约是一个工程师四分之一的时间被 AI 工具节省了。

**Dhanji R. Prasanna：**那个指标是跨所有团队的。包括我们的支持团队、法务团队、风险团队，所有这些加在一起。

**Lenny Rachitsky：**哇。

**Dhanji R. Prasanna：**然后在工程方面，差异非常大，因为像我之前说的，这取决于代码库的规模和复杂程度。如果你在构建一个全新的 Greenfields 代码库，或者为一个新的平台构建应用，那我们看到的效果非常显著，但在已有的非常复杂的代码库中，这些收益还没有完全到位。

**Lenny Rachitsky：**太厉害了。每当我听到这样的数据，我觉得人们需要思考的一个重要因素是：这是它未来最差的表现。这是最低点，这是现在的基线。所以它现在听起来可能还不够疯狂，但它会变得疯狂的。好，你提到的另一件事是 Goose——你还没解释 Goose 是什么。这是一个很重要的事。请解释一下 Goose 是什么，以及它对你们有多重要。

Goose 是什么

**Dhanji R. Prasanna：**Goose 是一个通用 AI 代理（agent）。你可以把它想象成一个桌面工具或程序，你可以下载安装到电脑上，它有一个界面。你可以像跟聊天机器人一样跟它对话，什么都能说——从”嘿 Goose，按类别整理我的照片”，它能够查看你的照片，如果有很多树，就归类为自然照片；如果有很多人物，就归类为人像照片——诸如此类，一直到为你编写软件。

它可以完成所有这些任务，而我们能做到这一点的方式是通过一种叫做模型上下文协议（Model Context Protocol）的东西，也就是 MCP，你的很多听众可能听说过。这是 Anthropic 提出的，我们是其非常早期的贡献者。模型上下文协议（MCP）简单来说就是一组对现有工具或现有能力的形式化封装。所以如果你在企业中使用各种工具，不管是 Salesforce、Snowflake 还是 SQL，任何这些，你都可以用 MCP 封装它们，然后它就会把这些能力暴露给你的大语言模型（LLM），让它能够去操作。

**Dhanji R. Prasanna：**所以在那之前，大语言模型（LLM）除了聊天之外其实做不了太多事情，但 Goose 给了这些大脑胳膊和腿，让它们能够走出去，在我们的数字世界中行动。这也是它产生最大影响的地方，而且它建立在一个相当开放的协议之上，任何人都可以实现。MCP 的数量已经出现了爆发式增长。顺便说一下，Goose 完全是开源的，所以你们任何人都可以下载它、扩展它、编写自己的 MCP，这也是我们通过 Goose 取得的核心成功。

**Lenny Rachitsky：**好的。所以本质上就像是带界面的 Claude Code，一个桌面应用之类的，底层用的是 Claude 和 OpenAI ChatGPT 以及一堆开源模型。对吗？

**Dhanji R. Prasanna：**对，它可以使用任何模型。我们有一个可插拔的 provider 系统，你可以自带 API 密钥，使用 Claude 系列模型或 OpenAI 系列模型，也可以使用开源模型，直接下载使用，或者通过 Ollama 等工具——有好几种工具可以帮助你做到这一点。但本质上，它是把这些模型生成文本和解读文本的能力，应用到真实的场景中。

举一个我特别喜欢的例子——你可以让 Goose 去帮你做营销报告，它有连接 Snowflake、Tableau 和 Looker 的 MCP。所以它会写 SQL 从这些数据源中提取数据，做一些分析生成 CSV，它可以在你的桌面上写 Python 代码来完成这些。它还会用某个它知道的 JavaScript 图表库来生成图表。最后，它会把这些东西整合成一个 PDF 或 Google Doc 之类的文档，甚至可以帮你发邮件或上传到某个地方。而且这一切都是它自己完成的，没有人坐在那里一步步指导它，你只需要说，“嘿，我想要这份报告，发到这个邮箱，我要这些好看的图表”，然后它就在所有这些系统之间进行编排协调。

Block 内部的工具选择

**Lenny Rachitsky：**所以本质上在 Block，你们不是直接使用 Claude 或 ChatGPT，甚至也不是用 Cursor 和那些应用，而是用 Goose？

**Dhanji R. Prasanna：**是的，我们允许工程师和全体员工使用他们想用的任何工具。Goose 是与我们所有系统整合得最好的，因为它是建立在 MCP 之上的，而为现有系统创建一个 MCP 又如此简单。举个例子，如果你在使用某个问题追踪工具，想要给它加一些 AI 自动化能力，在 Goose 之前，我们的团队只能等待供应商来构建那个 AI 功能，或者也许 OpenAI、Anthropic 或 Google 会提供某种通用能力让我们可以接入。但有了 Goose，这就不再需要了——几行代码的 MCP 就能让所有这些系统在一夜之间变成可以被 AI 编排操作的。而且 Goose 可以自己编写 MCP，所以它的自我启动能力也很强。

开源理念

**Lenny Rachitsky：**而且这是开源的，基本上你们花了这么多时间构建这个东西，其他任何公司现在都可以采用它，在你们所有工作的基础上继续构建？

**Dhanji R. Prasanna：**是的，有很多公司在相当活跃地使用 Goose。我不想点太多名字，但从我们的竞争对手到我们的紧密合作伙伴，他们很多团队都在相当频繁地使用 Goose。我知道 Databricks 经常谈到它，你能想到的这个中大型科技公司层级里的每一家，都在以某种形式使用 Goose。

**Lenny Rachitsky：**太疯狂了。这感觉本来可以成为一个巨大的独立业务——世界上增长最快的一些公司，基本上这就是它们的产品，而你们把它做出来然后免费送出去了。

**Dhanji R. Prasanna：**是的，我们相信开源的力量，我们的核心使命之一就是增加开放性，这意味着贡献开放协议和开源项目。作为一家科技公司，我们建立在大量开源软件之上。我认为几乎每家科技公司都是如此，不管你说的是 Linux、Java、MySQL 还是这些基础组件。所以我们觉得自己有强烈的使命去回馈。我们想构建的不仅是对我们和我们的客户有益的东西，而且是能够超越 Block、比 Block 更长寿的东西——这当然是我们核心价值观的一部分，从最开始就是如此，远在这整个 AI 浪潮之前。所以 Goose 延续了这一光荣传统，我们非常高兴它取得了今天的成功。

Goose 名字的由来

**Lenny Rachitsky：**顺便问一下，Goose 这个名字有什么故事？忍不住想问。

**Dhanji R. Prasanna：**Goose 是《壮志凌云》（Top Gun）里的梗。我们有一个工程师想出了这个名字。他长得也跟 Goose 一模一样，所以如果你把他们并排放在一起看，真的很像，他肯定会因为我分享这个而非常尴尬，但他们叫它 Goose 就是这个原因，之后我们就顺势走上了整个鸟类主题路线。

Goose 的极限实验

**Lenny Rachitsky：**太不可思议了。我听过你在另一个播客上分享过一个故事——有个工程师把这件事做到了极致，让 Goose 监视他的一举一动。讲讲那个故事吧。

**Dhanji R. Prasanna：**好的。他非常非常专注于 AI，试图从 Goose 身上榨取各种疯狂的想法。Goose 能做我之前描述的通过特定工具交互来完成的所有事情，但它也可以只是看着你的屏幕——它理解如何处理图像，通过截图来理解它看到的内容。所以他构建了这样一个系统：它基本上就是一直看着他做的一切。他可能在 Slack 或邮件上跟同事讨论某个功能，觉得值得实现。然后几个小时后他会发现 Goose 已经尝试构建那个功能了，并且在 Git 上开了一个 PR，还有各种类似这种疯狂的事情。它还会试图把他从某个工作流中拉出来——如果他一个会议拖得太长，导致下一件事迟到了，它就会想出一些他并没有编程或写提示词的创意方式来提醒他，是它自己觉得这些会帮助他提高效率或改善工作日。所以确实很疯狂。你要有足够强的心理承受力才能接受与自己的工作工具绑定到这种程度，但它展示了这类工具的可能性。

**Lenny Rachitsky：**很明显这是未来的方向。一旦这东西足够成熟——我很喜欢这个家伙在亲身尝试——它基本上就是在看着他工作，预判他应该做什么，然后替他完成初稿，这样他就会觉得，“哦，这个 PR 已经做好了，我们刚才还在会议上讨论这个。“太不可思议了。

**Dhanji R. Prasanna：**没错。

自动化的成熟度

**Lenny Rachitsky：**它现在到底有多好？处于什么水平？如果从零到一百来打分的话——“好的，接下来你只需要思考和说话，它就能替你完成工作”？

**Dhanji R. Prasanna：**是的，语音是另一个重要部分。它有语音处理能力，所以也一直在听他说什么，并试图理解。我想说这主要还是一个实验，因为他是我们 Goose 核心团队的成员，他为 Goose 做贡献，这是他的本职工作，而他开发的这个算是业余项目。所以一旦这演化成 Goose 本身或我们在企业中使用的其他工具的更原生功能，我认为它会有很大发展空间，但它现在已经相当不错了。它可能已经帮他砍掉了大量的繁琐工作。比如说，他会说，“哦，我有个会议冲突，那个时间去不了”，或者”我得去接孩子。”

Goose 会自动重新安排那个会议，而不需要他坐在日历前点来点去十几次。是的，所以这些事情，我们以前一直在等日历供应商把这些做进日历的功能里，但我们不再需要等了，因为 AI 能够替我们编排这一切。

未来工程师的工作方式

**Lenny Rachitsky：**这不是那个同时在四家不同初创公司干四份工作、把所有活儿都搞瘫痪了还雇了人的那位吧？

**Dhanji R. Prasanna：**不，不是他。他是和我共事很久的人，在 Block 也待了很长时间。他就是喜欢做实验，他身上体现了那种实验文化，就像我们 Goose 的创造者一样，做了同样的事情。

**Lenny Rachitsky：**那我来顺着这条线再追问一下。你算是看到了未来走向的一瞥，Block 在很多方面都非常领先。你觉得几年后工程师的工作方式、产品团队的工作方式会和今天有什么不同？

**Dhanji R. Prasanna：**我认为这在很大程度上取决于大语言模型（LLM）性能的提升，但我可以告诉你我正在如何尝试改变自己的工作方式，以及如何改变我们直属团队的工作方式。我认为 vibe code 是一件有趣且令人兴奋的事——你基本上就是跟一个聊天机器人说话，然后它就去替你构建软件，但我觉得这种方式有很大的局限性。

它非常像打乒乓球。你做一步，等三四分钟，它回来一个半成品，你得去推它、引导它、打磨它，才能把它带到你需要的地方。我认为我们会看到更多的自主性。所以我们正在用 Goose 做几个实验，用下一个版本的 Goose，我们真正想把它推向的不仅是每次工作两三分钟或五分钟——我们目前的中位会话长度是五分钟，平均七分钟——但我们想把它推到小时级别。

我们在说，“嘿，所有这些大语言模型（LLM）在晚上和周末人类不在的时候就闲置了，没这个必要。“它们应该一直在工作。它们应该试着预先构建我们可能想要的东西——如果我们回到对话前面讨论的内容的话。但我也认为，它们应该能够以以前不可能的方式来构建。

以前作为人类，我们的资源有限、带宽有限，还有大量的协调开销。所以我们必须选择最佳的路径去尝试一个实验，我觉得我们不再需要这样了。我们现在需要做的是能够以非常详尽的细节描述多个不同的实验。然后也许我们去睡觉，到了早上，所有那些实验都已经构建好了，我们可以直接扔掉其中五六个。

所以我经常做的一件事——我每天都在写代码——但我经常做的一件事就是大量地扔掉代码，这对我来说其实有点难，因为我以前从来没这么干过。我的意思是，工程师当然喜欢删代码，但这是不一样的。你构建了一整套全新的系统或一个全新的功能，然后说，“嗯，感觉不太对。我干脆删了重来。”

所以我认为你会看到更多这样的工作方式。而且我认为你会看到，我们不再是——比如说——对一个应用做重构来换个 UI 或者让它演进到新版本，而是直接从零开始重写整个应用。我一直在推动我们团队思考的一件事是：如果每一次发版都是 rm -rf 删掉整个应用然后从零重建，我们的世界会是什么样子？我们现在还不能真正做到这一点，但我认为这展示了这些工具正在带我们去的方向和可能性。

**Lenny Rachitsky：**这里面很有意思的一点是，软件工程和产品领域有一条常见的规则——永远不要重写。不要试图重写你的东西。你会忘记多年来人们做的那些小改进、微调和 bug 修复，你以为重写会是一件简单直接的事，结果往往要花一年甚至更长时间才能恢复到原来的水平。所以有意思的是，AI 现在让重写成为可能，而你的意思是这也许才是应该采用的工作方式。

**Dhanji R. Prasanna：**我觉得是这样的。而且我认为关键在于让 AI 尊重所有那些渐进式的改进，是的，把它们作为规格说明的一部分融入进去。

**Lenny Rachitsky：**另外你刚才提到的那个观点，关于代理——你给它一堆想法，它 overnight 就构建出来了，然后你可以看——我想象它甚至可以进一步往上走，自己提出想法然后开始构建，然后你一看，“哦，这是个好主意，我现在立刻就能看到效果。”

**Dhanji R. Prasanna：**对，没错。我上周确实就在试你说的事情。我手上有一个我们正在开发的新版 Goose，我让它自己提出改进自身的想法，然后 overnight 去实现。有时候——

**Lenny Rachitsky：**跑偏的问题。

Dhanji R. Prasanna：——有时候它确实会完全跑偏，你得把它拉回来一些。所以我觉得我们还没有完全进入那种完全自主、完全自我改进的时代，但我确实认为我们正处于一个过渡阶段——我们可以给它一个推动，说，“嘿，这是我的愿望清单，十件我希望你能做的事。你去想办法用最好的方式去实现它们。“如果说功能描述得足够好，它大概能在其中百分之六十的事情上取得成功，剩下的百分之四十则表现挣扎，需要你介入去打磨它。

**Lenny Rachitsky：**天哪，我在想象这样一个功能——你给它设定一个目标叫”驱动收入和增长”，然后它就来一句，“好的，所有人都解雇了。这是你们的工资支票。剩下的交给我。“

人的品味作为锚点

**Dhanji R. Prasanna：**我觉得我们不会走到那一步。我确实认为我们会需要大量的人类品味来锚定这些 AI，让它们不至于跑偏。这正是我们的设计负责人和设计团队在推动我们思考的方向，而且我认为这是一个差异化优势，会让我们超越现在大家都在说的那种 AI 粗制滥造的时代。所以是的，核心就是把它锚定到对人真正重要的事情上，锚定到有品味的、有用的、有价值的东西上。

**Lenny Rachitsky：**说得再具体一点，有没有这样一个例子——也许是 AI 在尝试做什么，或者某个团队在推销什么——你觉得这就是人类必须介入、把事情拉回正轨的时候？

**Dhanji R. Prasanna：**我觉得更多是围绕流程自动化这类事情。很多时候我会收到这样的请求——一个团队说，“我们需要从这家供应商买这个新工具，因为我们目前的工具存在某某某某问题。“另一个团队说，“不不不，我们直接用 Goose 构建一个应用就行，能做同样的事，时间只要一半甚至更少。“然后作为一个人，你坐在那里想，“这些有任何一个是必要的吗？如果我们只是改一下流程，还需要考虑构建工具这件事吗？“这正是 AI 不擅长的事——它无法拥有这种组合判断力，或者说在全局层面上判断什么重要、什么有意义的判断力。

质疑基本假设

**Dhanji R. Prasanna：**所以很多时候，我会告诉团队去质疑基本假设，尤其是我们的信息安全团队，因为他们有时候会绞尽脑汁去加固某个东西，然后你就会说，“我们直接让构建它的团队换一种方式做，或者如果这东西不重要就别做了，这样你就不需要扩大安全防护的攻击面。“所以我觉得这些领域更适合由人类来做判断，而 AI 在这方面做得还不够好。

**Lenny Rachitsky：**你刚才提到了自己构建软件和工具而不是购买的观点。这其实是 AI 时代的一个大问题——AI 是否会取代所有这些 SaaS 应用，取代 Salesforce 之类的。你有没有一种感觉，要么是你们自己构建东西省了多少钱，要么是对现有的、大家都在用且花很多钱购买的 SaaS 软件产生了新的敬意？

**Dhanji R. Prasanna：**我觉得这里有一个陷阱，就是偏离公司核心目标。我们的核心目标是经济赋能。所以让客户、商户或艺术家能够完成一笔交易、付得起房租、或者把最新的作品上传到 TIDAL。我认为任何服务于这个目标的事情，我们都应该鼓励和投入，但如果我们纯粹以金钱对金钱来衡量，那就会偏离这个目标。

用内部自建工具替代供应商工具可能带来的成本节约，很可能不值得你在心智带宽上的损失以及团队技术专注力被分散的代价。所以是的，我会说始终回到对你作为一家公司来说最重要的事情上，其余的自然会水到渠成。

自建与购买的维护代价

**Lenny Rachitsky：**对，我觉得人们常常忘记维护自己构建的东西需要付出多少。就像，“好，很酷，我们一个周末就构建完了，但接下来是年复一年无尽的维护、需求和用户支持。“而且正如你所说，这又回到了那个永恒的箴言——专注于你的核心竞争力，其余的就去买。

**Dhanji R. Prasanna：**是的，这就是经典的 80/20 问题，我们在为客户构建的应用中已经充分体验过这一点。我们会做出一些非常有共鸣的优秀实验功能，然后却要花大量时间去打磨那一长串的边缘问题。以 Cash Card 为例，我们基本上在一个周末，或者最多一周的集成和开发时间里，就构建了 Cash Card 的全部功能。

然后却花了非常长的时间去处理各种边缘情况——比如有人给的小费是账单金额的两倍，然后后端就完全崩了；或者人们在加油站使用它，而加油站有不同的刷卡计费方式。所以是的，完全是这样。而且正如你所说，我总是会回到这个问题：我们做这件事的原因是什么？它对我们和我们的客户为什么重要？如果不能清楚地回答这个问题，我就直接把它推掉，认为它不值得投入。

AI 时代的招聘与团队能力

**Lenny Rachitsky：**关于 AI 的讨论中很大一部分是招聘、就业之类的话题。所以我有一个两部分的问题。一个是，所有这些 AI 工具的兴起、生产力的提升，是否影响了你们规划人员编制和招聘的方式？另一个是，既然 AI 已经成为你们工作方式中如此重要的一部分，你在招聘时看重的东西有什么不同？

**Dhanji R. Prasanna：**我觉得事情还没有发展到足以根本性地改变你需要多少人才能构建一个像 Cash App 这样规模的应用的程度。对我们来说真正改变的，和 AI 完全无关，而是我们之前讨论过的——从 GM 结构转向职能型结构。在 GM 结构下，我们的激励机制总是把工程师人手当作一种商品来对待。

所以我们想要构建更多功能，就直接加更多工程师，经典的”人月神话”陷阱。而我觉得转向职能型结构彻底改变了这一点——你开始想，“我们可以利用通用平台、通用模块，可以从全公司引入专家来指导我们如何做得更好。”

所以这些改变我觉得对我们的招聘方式产生了很大影响，我们不再把工程师当作一种商品，不是随便加一百个人就能去构建 Cash App 的下一个产品。但在 AI 方面，我们非常看重那些积极拥抱这些工具、渴望尝试和学习的人。我们并不是要求候选人一上来就是出色的 AI 实践者。

我们确实有那样的人，如果他们想和我们合作我们也欢迎。但我更看重的是那种刚刚毕业的大学生，真心渴望学习这些工具、对它们保持开放态度；或者是那些资深工程师，已经拥抱了这些工具并摸索出了门道。这就是我们在招聘时优化的方向——不是某套特定的技能，而是这种特质。

**Lenny Rachitsky：**所以本质上最大的变化就是寻找那些正在拥抱 AI 的人，而不是那种说，“不，我不需要这些东西。我是一个出色的工程师，不需要用 Cursor 或 Goose 或所有这些工具”的人。

**Dhanji R. Prasanna：**是的，我会把它概括为学习型心态。这是我们的 CEO Jack 经常谈到的一点——他希望我们成为一家学习优先的公司。所以我们做的每一件事、交付的每一个实验，我们能从中学到什么？我们是否觉得已经尽了最大努力？我认为对他来说，这甚至比每次都给出正确的商业答案更重要。

面试中的 AI 工具使用

**Lenny Rachitsky：**那面试的时候呢？你会鼓励工程师在做练习时使用 AI 工具吗？过去一两年这方面有什么变化？

**Dhanji R. Prasanna：**是的，我们现在开始这样做了。传统上我们会用 CoderPad 之类的工具，在白板上写一道题，或者甚至用伪代码或接近伪代码的方式来编程。但现在我们在考察你能否用 vibe code 构建出东西？你对这些工具的熟练程度如何？以及你在思考如何与这些工具一起演进？

不过我想说现在还处于早期阶段。在我看来，一个人是否会使用 Goose 或 Cursor 或其他任何工具，与其是否是一名优秀的工程师之间未必有多大关系。我仍然认为，我们过去面试时所考察的那些素质——批判性思维、对问题技术本质的深入理解——依然远比你是不是一个完全 AI 原生的程序员重要得多。

哪级工程师受益最大

**Lenny Rachitsky：**另一个我一直在思考、很多人也想知道的问题是，哪个级别的工程师从这些工具中受益最大？你可以说现在初级工程师受益最大，因为他们可以完成所有这些工作了。你也可以说是高级工程师，因为他们对系统运作方式了解得更多，现在可以指挥成千上万的代理替他们做事。你观察到哪个级别受益最大？

**Dhanji R. Prasanna：**有两个层面的回答。第一，你说得对，越资深和越初级的人，越愿意、也越积极地采用这些 AI 工具。原因有很多，包括你提到的一些。我认为资深的人对一切如何运作有非常深入的理解，所以他们几乎如释重负——终于有了一个工具可以去完成那些他们做过无数遍、实在不想再亲手做的事。而初级的人呢，就像我侄女侄子在手机上一样，他们飞速地操作——早年是黑莓手机，现在是 iPhone——他们飞速地发短信，而我还在键盘上一个个字母地找，可见我有多老了。

非技术人员也在用 AI 编程

所以我觉得有这些因素，但我认为真正令人惊喜和惊叹的，是非技术人员使用 AI 代理和编程工具来构建东西。我认为这预示着这些角色在未来将如何演变。你是在法务部门、风控部门，还是在工程和设计部门，界限将变得越来越模糊。因此，我认为那些能够拥抱这些工具、将其优化用于自己日常工作日和特定任务集的人，才是展现这些工具最大影响力的人。

**Lenny Rachitsky：**很有意思。没有人谈论过工程生产力中的这个维度——即公司其他部门要求工程师构建各种临时性东西的需求减少了。这感觉像是工程师生产力的巨大提升。

更宽的路引来更多的车

**Dhanji R. Prasanna：**确实影响巨大，不过我觉得这有点像那个比喻——如果你修一条更宽的高速公路，路上只会出现更多的车。所以我认为，所有人都在构建软件这个事实，意味着有更多的软件需要构建、更多的协调工作要做，所有人都更急切地想更快地发布功能、取得更好的成果。所以我们看到的是整体速度的提升和对更多功能的需求在同步增长，如果这说得通的话。是的。

**Lenny Rachitsky：**完全同意。这也呼应了你说的你们没有放缓招聘这一点。我听到的是，对更多工程师、更多产品人员的编制和招聘需求完全没有放缓。基本上就像 AI 根本不存在一样。

招聘与组织架构

**Dhanji R. Prasanna：**我们对此更加深思熟虑了。就像我之前说的，在 GM 时代我们把它当作一种商品来看待，而现在转为职能型架构后，我们需要多少工程师这个问题已经不再与 Square 或 Cash App 有多少功能直接挂钩了。在职能型组织架构中，我们更多地思考：优化的领域在哪里？在哪里可以构建深度？什么才能真正通过模块化、复用和深入平台建设来加速我们的优先事项？

**Lenny Rachitsky：**我很喜欢这个犀利观点——如果你想提高效率，别管 AI 了，先重组为职能型架构吧。

结构比工具效率更重要

**Dhanji R. Prasanna：**在某些方面确实没错。这里有一个很有意思的例子。我们一直在尝试改善构建时间，也在使用 Goose 和许多其他工具来帮助这件事，它们发挥了很大的作用。比如我们有一个非常酷的工具，可以分析我们的测试套件，并根据所做的变更选择正确的测试来运行。通过这种方式，我们基本上减少了 50% 的测试运行量，这相当不错，我们也不再用那些浪费在不必要测试上的 CPU 周期来给地球升温了。但另一方面，像把测试卸载到云端，或者干脆删掉那些不再有意义的测试，大概能省下两到三倍的时间。

所以你仍然需要采取一种组合策略，找不到更好的词来形容的话。就像我之前给你举的那个例子——我们应该买一个供应商的工具吗？还是应该内部自建？但根本问题是：「我们到底需不需要做这件事？」所以在某些方面，结构比你所拥有工具的效率更重要。

**Lenny Rachitsky：**至理名言，让我想起了 Elon 优化事物的一套流程，其中一步就是——在我们开始优化和自动化之前，先想想我们到底需不需要这个东西。在我把视角拉大、问你整个职业生涯中学到的一般性经验之前，你觉得还有什么对那些想要进一步拥抱 AI 或帮助团队更具前瞻性思维的人特别有价值或有用的东西吗？

亲身体验才是最好的推广

**Dhanji R. Prasanna：**我想说，一定要亲自使用这些工具。我认为我们推动工具采用最成功的方式就是——Jack 使用 Goose，我使用 Goose，我们的整个高管团队都用过 Goose，而且经常使用，同时也使用其他 AI 编程工具和助手，我们每天都在用。因此我们对自己的工作流程可以如何改变有了很多了解，这比你读一堆 LinkedIn 或《哈佛商业评论》上的文章然后试图让团队照做，能告诉你更多关于如何改变组织工作流程的信息。所以我认为我们做所有事情都是这样的——亲身感受，自己使用产品，感受它，理解它的优势和劣势以及它的使用体验，然后想清楚如何将其应用到你的团队中。

**Lenny Rachitsky：**我发现在这一点上有一个很有用的方法——我完全同意你的观点，就是别再读关于它的文章了，别再听我们谈论它了，自己动手构建一些东西。我发现一个很有用的做法是：给自己设定一个具体要解决的任务或问题，因为那会真正激励你，让事情变得非常真实。举个例子，就在前几天，我试图从 Google 文档中提取图片。Google 文档就像 Hotel California 一样——你把图片放进去了，但没办法拿出来，除非你做一些疯狂的操作。所以我直接去了 Lovable，让它帮我建一个应用——我给它一个 Google 文档链接，它就能让我轻松下载图片。搞定。

**Dhanji R. Prasanna：**好例子。几个月前我也做过类似的事情。我儿子需要接受很多治疗，他有特殊需求，所以我一直在收集所有这些治疗的收据，分享给我妻子，她会向保险公司申请理赔。但我一直很费劲，因为这些收据的形式五花八门。

Goose 解决实际问题的惊喜

有些是截图，有些是 PDF 或其他什么格式。所以我让 Goose 来处理这件事，这些文件都在我的笔记本电脑上，Goose 想到了一个办法——它可以把所有这些收据放进我的 Apple Notes 应用里，整合到一条笔记中。它还把内容转换成了 HTML，这样就能无缝同步到我的手机上，然后我可以从手机上直接发邮件或分享给我妻子。

这真的是我完全想不到的方案。而且它是用 Apple Script 实现的，也就是说它在后台直接控制了我的电脑。是的，所以这些工具以令人惊喜的方式帮助我们，而且正如你所说，你越是用它们解决真实的问题，就越能了解它们的优势所在以及可以在哪些场景部署它们。

**Lenny Rachitsky：**我喜欢这个例子。所以你是直接打开 Goose 然后说，“这是我遇到的问题，你会怎么解决？“这样吗？

**Dhanji R. Prasanna：**对，差不多是这样。我说，“我有所有这些收据在 Google Drive 里，所以我们的起始问题类似，我需要把它们统一成一种格式，还需要汇总金额、做各种计算。“它先尝试了几种方法。它试着下载文件，试着用 PDF 阅读器来读取，试了各种方式。我觉得 Goose 有一个特点——其他很多 AI 代理也在向我们学习这一点——就是如果它尝试了几种方法都失败了，它会退回来，换一条路径重新尝试，就这样不断推进，直到取得一些进展。

它确实就是这么做的。然后它选择了用 Apple Script 来完成，因为它有 MCP 扩展可以控制我的电脑，这跟我们那位工程师用的一样——就是我们前几天聊到的那个用它来看自己屏幕的工程师——但这次是一个非常聚焦的问题，它成功地解决了。所以是的，这些工具能做到的事情常常出人意料，而允许它们有灵活性去尝试，正是学会使用它们的一个关键部分。

**Lenny Rachitsky：**真酷。顺便问一下，普通人能运行 Goose 吗？能不能直接下载 Goose，用它来替代 Claude？

**Dhanji R. Prasanna：**当然可以。你可以直接从我们的网址下载。我们可以在节目简介里附上链接，你可以安装它。它有 Mac、Windows 和 Linux 版本。它是一个 Electron 应用，所以在所有平台上都能运行。它也有命令行界面，所以对于更喜欢用命令行的人，我们也提供了那种交互方式。

**Lenny Rachitsky：**哇，你们真的是在和那些大型基础模型公司竞争啊。怎么最简单地比较 Goose 和其他工具？比如说跟 Claude Code 比，这样最简单的类比，还是说有别的参照？

Goose 的定位

**Dhanji R. Prasanna：**我觉得它和 Claude Code 还是有区别的，因为 Goose 的核心是一个实现了 MCP 的平台。MCP 赋予了它这种动态可扩展的特性，所以它可以为你做所有这些事情——无论是像我们刚才谈到的自动化 Google 文档、Notes 之类的操作，还是利用其他 MCP 来完成正经的编程任务。

它可以对代码建索引，然后用那种方式来工作。所以它更像是一个可扩展的平台。我会说它介于经典的 AI 助手——就是那种你问它”今天天气怎么样？帮我算算从某个日期到现在过了多少个月？“之类的——和那些更专注的工具比如 Cursor、Claude Code 之间。

**Lenny Rachitsky：**基本上就是集所有功能于一体，而且是免费的。你只需要为大语言模型的 token 付费，但工具本身——

**Dhanji R. Prasanna：**对，没有那种——还有开源模型可以用——

**Lenny Rachitsky：**天哪，这也太疯狂了。在 Block 做 Goose 的团队一定很有意思。肯定玩得很开心吧。天哪。好了，让我把视角拉远一些。你现在担任 CTO 大概快两年了。有什么是你进入这个角色之前希望自己就已经知道的？如果你能回到几年前，在自己耳边悄悄说几条建议或教训，你会说什么？

回望 CTO 角色

**Dhanji R. Prasanna：**我觉得可能有两件事。一个是康威定律（Conway’s Law）的力量，就是我们之前聊过的。就是如果不改变组织中人与人之间关系的结构，要改变结果是多么困难。我想我在某个层面上一直都知道这一点，但真正在直觉层面深刻体会到它，这是另一回事。另一件我算是吃了苦头才学到的是——你只有在出问题的时候才会听到消息。

所以当一切顺利的时候，你反而会感到一种诡异的寂静，你会想，“我做的事情到底对不对？我聚焦的问题到底正不正确？“所以要有一些判断力，要留出时间退后一步、从全局视角来看事情，这些是你真正需要专门腾出时间、定期去做的事情，我希望我在接任这个角色时就知道这些。

**Lenny Rachitsky：**回顾你在 Block 的时间——我一直差点说成 Square，因为我太习惯那个名字了——但我知道 Block 是整个公司的名称，Square 只是其中一个。顺便让大家了解一下，Square 是 Block 旗下的一个业务单元、一个产品。

**Dhanji R. Prasanna：**对，我们有 Square、Afterpay、Cash App 和 TIDAL 四大品牌，然后我们还有 Bitkey 和 Proto，这两个专注于比特币的品牌，我们在这两个品牌中自研硬件芯片。

**Lenny Rachitsky：**好的，我想有些人可能一头雾水，不知道我们在说什么。好的。那么回顾你在 Block 的这段经历，关于打造产品或建设团队，你学到的最反直觉的教训是什么？那种与大多数人所相信的、或者说常见的创业智慧相悖的东西。

代码质量与产品成功

**Dhanji R. Prasanna：**我觉得代码质量是一个。作为一个工程师，我很早就学到了这一点，而且它一次又一次地被验证。很多工程师认为代码质量对于打造成功的产品很重要。这两者其实毫无关系。我最喜欢举的例子是 YouTube。YouTube 被 Google 收购的时候我正好在 Google 工作，我记得当时大家一片焦虑，都在讨论 YouTube 的代码库有多么糟糕、架构有多么糟糕，他们把视频作为二进制大对象存储在 MySQL 里什么的。

但你完全可以说 YouTube 是 Google 最成功的产品，而且远远超出，也许比 Google 许多其他产品加起来还要成功。所以它真的和架构设计得好不好没太大关系，因为反过来看，Google Video——不知道大家还记不记得这个产品，它存在于 YouTube 之前。它支持更多格式，支持更高分辨率。

你可以上传一小时长的视频，而 YouTube 这些统统没有。它只有那一两分钟的短视频功能，但它远远地、彻底地击败了所有竞争对手。所以我觉得始终要把这一点放在心上——我们为什么要打造这些工具、这些应用、这些产品？它们是为了让人们解决特定的问题。在我们的场景下，就是让 Square 的商户完成一笔交易，卖给你一杯咖啡，或者卖出他们亲手做的东西。这才是真正重要的事情。

我们的 Android 平台性能好不好，这件事本身并不重要，除非它是在服务于那个需求。所以我觉得这是我职业生涯中非常难接受的一课。而且我不断遇到工程师说”我们需要重构，我们需要用更好的方式来做这件事”。然后我就说，“不，这些代码明天都有可能被扔掉。专注于我们要构建什么、为谁构建，这才是关键。”

Lenny Rachitsky： 这真是一个令人难以置信的洞见和教训。YouTube 的故事太有趣了，也是一个绝佳的例子。你是说他们把视频内容以 blob 数据的形式存储在 MySQL 的行和列里？

Dhanji R. Prasanna： 是的，这个嘛，我其实没有看过代码，所以没法验证，但这是当时大家普遍的说法。而且他们整个技术栈都是 Python 的，相比我们当时在 Google 精心优化过的最先进的 C++ 和 Java 服务器，速度慢得令人难以置信。

Lenny Rachitsky： 这太搞笑了。这让我也想到，当你深入一家公司内部去看，如果你在一家公司工作，你会觉得”这简直就是纯粹的混乱。没人知道发生了什么。随时都要崩盘了。“而这基本上就是每一家成功的超高速增长公司的真实写照。

Dhanji R. Prasanna： 确实有道理。是的。

Lenny Rachitsky： 所以我觉得，再次说明，对一个商业的成功来说，有太多太多比架构更重要的东西。正如你所说——你在为人们解决真正的问题吗？你能把产品送到他们手上吗？你能持续为他们解决真正的问题吗？关键不在于代码的质量，也不在于内部运营得多好。

从 Cash App 到受控的混乱

Dhanji R. Prasanna： 完全同意。我觉得在 Cash App 上我们也有类似的经历。在 Cash App 早期，我担任工程负责人，从大约 10 名工程师一直发展到 200 多人，用户量增长到大约一千万到两千万左右。那里也有非常相似的情况。从外部看，一切看起来都非常混乱。就好像人们随意构建各种实验然后直接上线，完全看不出我们在遵循什么严格的软件生命周期之类的规范，而某种程度上确实如此。

我的理念一直是，我们有这么多优秀的工程师，如果我把他们硬塞进非常严格的、眼界狭窄的框框里，反而会造成更大的损害。如果他们想花点时间造个轮子，搞一些完全浪费时间的东西——但同时另一方面他们也在交付令人惊艳的成果——那我基本可以接受。我对此是 OK 的。

这是一种微妙的平衡，因为如果你放任不管，工程师确实会钻进兔子洞里出不来。但话说回来，一定程度的混乱能够催生创造力，你必须知道如何在某种程度上构建受控的混乱。所以你必须打造一个不会轻易崩裂的基础。不能有重大的责任风险之类的问题，在我们的情况下就是不能亏钱。只要这些底线稳固了，然后让工程师们拥有自由去实验、迭代、做那些让他们充满热情的事情，那就是最理想的状态。

Lenny Rachitsky： 说到受控的混乱，你在 Block 期间有一个头衔——应该是在 Square 的时候——叫”疯狂科学家”（Mad Scientist），干了四年半。

Dhanji R. Prasanna： 对，那是我做兼职的一段时期，主要是因为我的孩子还很小，有很多额外的需求需要照顾。我当时以顾问身份参与各种不同的项目，试图帮助一些天马行空的想法落地。是的，我非常感激 Block 给了我这样的自由，让我在职业生涯中能够拥有这样一个角色。

核心领导力原则

Lenny Rachitsky： 在我们进入”翻车角落”（Fail Corner）之前——这个环节我待会解释——也许还有最后一个问题。你已经分享了在职业生涯中学到的几条教训。还有没有其他你认为对你取得成功非常重要的核心领导力原则？

Dhanji R. Prasanna： 我觉得做任何事情都要从小处着手。如果你想煮一杯茶却去煮沸整个海洋——不知道这话是谁说的，但这确实是我经常回味的一句话——你永远也到不了终点。所以如果你要泡一杯茶，就只泡那杯茶就好，不需要把世界上所有的水都烧开。

Lenny Rachitsky： 那泡出来的茶肯定很难喝。海水泡的茶。

Dhanji R. Prasanna： 哈哈，我想还有一句话，好像是 Carl Sagan 说的：“如果你想从零开始做一个苹果派，你得先发明整个宇宙。“所以要把范围缩小到你面前那件可达成的事情上。我觉得这一点非常重要，这也是我们的核心原则之一，甚至在我们还只是 Square 的早期阶段就是这样——从小处开始。

Lenny Rachitsky： 有没有哪个例子，可能做得特别好，或者特别不好？

从小处做起的成功与失败

Dhanji R. Prasanna： 有的，Goose 就是从很小的东西开始的。当时只是一个工程师利用自己的时间，试图构建一个有用的东西，来验证他们的一个设想。Goose 的创造者 Brad 很早就相信——远在我们听到这个流行词之前——代理（agent）将是解锁大语言模型（LLM）价值的方式。他做了一个概念验证，分享给了很多人，分享给了 Databricks 和 Anthropic，让他们也兴奋起来，并从中学到了很多。

然后就逐渐积累了势头。在内部其实也差不多。Cash App 本身也是这样——Cash App 最初基本上是一个黑客周（hack week）的想法，然后越滚越大。所以我们的很多项目都是从这些小实验开始的，然后在此基础上不断构建。我们是第一家推出比特币产品的上市公司。那同样是一个黑客周的想法，是 Jack、我和另一个工程师一起做的。

Lenny Rachitsky： 那个黑客马拉松团队就是你、Jack Dorsey 和一个工程师？

Dhanji R. Prasanna： 对，就是我们三个人。

Lenny Rachitsky： 太不可思议了。

Dhanji R. Prasanna： 是的，很棒的经历。我们去买了一杯蓝瓶咖啡，是用比特币通过 Cash Card 支付的。我告诉你，回想起来，那大概是史上最贵的一杯咖啡了。

Lenny Rachitsky： 当时比特币多少钱？两万？

Dhanji R. Prasanna： 好像是六千或者七千吧，我记得。

Lenny Rachitsky： 现在大概十二万了。不错。

Dhanji R. Prasanna： 但这正是一个例子，说明了当你专注于先做一件小事时，如何能够为人们打造出一个可用的、有价值的产品。

Lenny Rachitsky： 我想再强调一下这个反面教训。就是”好吧，我们有了一个宏大的想法，我们要投入大量资源，一开始就大干一场”。

Dhanji R. Prasanna： 对，完全正确。我也参与过那样的团队。在我的职业生涯中，我在 Google 参与过一个叫 Google Wave 的产品，它试图成为所有人的万能工具，我们有七八十个工程师在还没有任何外部用户的情况下就在构建这个东西。所以我觉得那就是一个反面教材——一开始就搞大的，试图从第一天就大张旗鼓，却缺少了那种脚踏实地接触现实、然后相应调整的能力。

Lenny Rachitsky： 我记得 Google Wave。绝对记得。它做得很漂亮，当时也有很多炒作。我不太记得它具体是干嘛的了，但看起来确实很漂亮。

Dhanji R. Prasanna： 是的，那个项目对我来说有很多经验教训。是的。

Lenny Rachitsky： 还有什么？还有其他大的教训吗？

质疑基本假设

Dhanji R. Prasanna： 这两条是最大的教训，但我还想说一点：质疑一切基本假设。有时候我们会陷入这样的陷阱——作为专业人士，我们极度专注于当天、那周、那个月正在构建的东西，却没有停下来想一想：我们到底该不该建这个东西？构建它的目的是什么？我们能不能构建一个完全不同的东西，一个更能触及我们核心使命的东西？所以我想说，是的，质疑那些基本假设。这话听起来有点老生常谈，但你真的需要一遍又一遍地提醒自己去践行它。

Lenny Rachitsky： 之前我请过你的一位同事 IO 上过播客，他和你一起在 Cash App 工作过。

Dhanji R. Prasanna： 对。

Lenny Rachitsky： 他是我的朋友，非常厉害。他说过一句话，大意就是——我记不清原话了——就是”直抵你手头工作的底层金属面”，去触摸你正在构建的东西，回到最基础的层面去真正理解发生了什么。我猜这在构建 Cash App 和 Cash Card 的时候非常重要。

Dhanji R. Prasanna： 是的，IO 是我合作过的最优秀的产品人之一，实际上也是我最亲密的朋友之一。所以在这一点上我完全同意他和你的看法。

失败角

Lenny Rachitsky： 好。接下来进入播客的一个固定环节，我称之为”失败角”。你已经分享过一个你参与过但失败的产品案例。我很好奇还有没有其他的，问题很简单：你做过但没有成功的那个产品是什么？因为听众听到播客上这些了不起的成功人士分享一个又一个成功的故事、无尽的辉煌，但他们听不到那些不成功的案例。所以这个问题就是：“你做过但没有成功的产品是什么？它教会了你什么？”

Dhanji R. Prasanna： 这个问题非常有价值。我的职业生涯基本上就是一个失败产品摞着另一个失败产品的历程。没错，Google Wave 就是一个例子。我还在 Google+ 工作过，那又是一个史诗级的失败。

Lenny Rachitsky： 好例子。

Dhanji R. Prasanna： 我还在一家叫 Secret 的社交网络创业公司工作过，它短暂地火爆了一阵，然后就炸了。之后还有一个电子邮件创业项目，同样前景一片光明，然后就无声无息了。Canva 的联合创始人和我一起做了那个项目。所以一路走来都是失败，但在每一个节点上，我觉得自己都学到了东西，学到了这类失败和错误我永远不能再犯。

所以 Cash App 对我来说大概算是最大的成功——一个我从非常早期就参与的产品，最终成长为这个巨大的业务，成为一个人们喜爱的产品。是的，我的职业生涯本质上就是把所有这些失败中学到的东西汇集起来，在这个过程中也获得了一些谦逊，开始带着愿意倾听他人观点、批评性观点的态度去做事，而不是觉得自己什么答案都有。

Lenny Rachitsky： 我敢打赌所有这些失败的产品都有非常漂亮的代码，做出了很多优秀的架构决策。有些在各方面都很糟糕，失败的原因太多了。太不可思议了。Dhanji，在我们进入非常精彩的快问快答环节之前，还有什么想补充或者强调的吗？

回归本质

Dhanji R. Prasanna： 我想说的是，我认为我们正处于一个充满变革的时代，人们感到恐惧、犹豫或对未来不确定。但我认为，去看看那些对你来说真正重要的事情。对我们来说，那就是开源、开放协议、为所有人改善可及性。我职业生涯中非常幸运的一点是，我只做过免费或几乎免费的产品，或者有免费层级、然后为某些高级服务收费的产品，而且是人人都能使用的。任何人都可以成为一个 Square 商家。

我记得甚至早期的时候，人们用它来互相转账，作为一种点对点汇款系统，这正是我们构建 Cash App 的原因，而它也在这个基础上取得了巨大成功。所以我觉得，真的要去看那些对你重要的事情，并为之优化。技术朝哪个方向发展其实没那么重要，因为技术是来服务我们的，如果我们有重要的使命和目的，那我们就能让技术服务于我们。这比深钻技术或站在每个潮流前沿重要得多。

Lenny Rachitsky： 非常好的建议，尤其是在有太多东西需要关注、有太多事情在发生的当下。很容易感到焦虑——觉得自己就是不够了解所有的事，不如社交媒体上看到的人厉害，AI 到底怎么样了，我就是太落后了。我从你这里听到的就是：到底什么对你来说是真正重要的？就去做那个。不需要觉得必须在所有正在发生的事情上都做到最好、跟上所有最新的 AI 消息。

Dhanji R. Prasanna： 没错，完全同意。而且如果一件事既没有意义又不有趣，那你可能就不应该做它。

快问快答

Lenny Rachitsky： 那么接下来，Dhanji，我们到了非常精彩的快问快答环节。我准备了五个问题。准备好了吗？

Dhanji R. Prasanna： 好，问吧。

Lenny Rachitsky： 我看到你身后有好多书。所以我很喜欢这第一个问题，很期待你的选择。你有哪两三本书是你最常推荐给别人的？

Dhanji R. Prasanna： 我非常认同一个观点：你不应该读那些关于你日常工作或职业的书。我读小说，读经典文学，读诗歌、哲学、历史。这些是我真正喜欢的书。我认为它们能拓展你的思维，给你带来创意，帮助你质疑关于人类处境的种种问题。这比什么自助书或者”如何做好工程经理”之类的书有价值得多。话虽如此，Mikhail Bulgakov 的《大师与玛格丽特》是我非常喜爱的一本，是俄罗斯文学的杰作。另外我一直被丁尼生的诗歌所吸引，我发现在我最迷茫或最悲伤的时候，丁尼生的诗歌总能引起我的共鸣，帮我找到内心的锚点。

Lenny Rachitsky： 哇，从来没听过这些推荐。真的很想去看看。作为一家大型科技公司的 CTO，这些推荐非常特别。你最近最喜欢的电影或电视剧是什么？

Dhanji R. Prasanna： 我觉得《异形：地球》挺棒的。它是 Noah Hawley 做的，就是拍《冰血暴》电视剧的那位。所以这是一个拥有高超艺术电影制作技艺的人在做一部通俗科幻剧，画面令人叹为观止，观感令人叹为观止，它捕捉到了那种异形系列本质上的通俗魅力，让它如此有趣和好看。我非常喜欢这部。另外我还在看《流人》，我觉得这是电视上最好的剧集之一。

Lenny Rachitsky： 我超爱《流人》。新的一季已经出了，我们录制这天好像刚播了第五集。我很喜欢那部剧。《异形：地球》我也刚看完，真的好诡异，就是那些黏糊糊、软塌塌的小生物到处爬。

Dhanji R. Prasanna： 是的，我太喜欢它的美学了，他们捕捉到了原版《异形》中某种本质的东西。《异形：地球》里的每一场戏，感觉都像在看一幅画，或者有人在给你读一本小说。它非常从容地展开。

最喜欢的产品

Lenny Rachitsky： 我这辈子从没看过任何异形相关的作品，但《异形：地球》我真的很喜欢。不过结尾部分，我确实觉得节奏有点慢了下来，心想”好吧，我大概猜到后面要往哪儿走了”。但整体看下来确实很过瘾。好，下一个问题。你有没有最近发现的、特别喜欢的产品？可以是应用，可以是小 gadget，也可以是什么厨房用品。

Dhanji R. Prasanna： 嗯，我是个游戏玩家，很喜欢打游戏。所以对我来说是 Steam Deck，准确说是 Steam Deck OLED，那是他们的最新款。这是一台非常漂亮的硬件设备，能让你玩到市面上最好的游戏，同时又完全可扩展、可定制。在我们所处的这个时代，大科技公司不断告诉我们，必须把一切锁死——必须锁定用户体验和可定制性，才能让产品为大众所用。而我觉得 Valve 证明了这完全没必要，也完全不对。你完全可以打造出 Steam Deck 这样的产品——你可以在上面安装竞争对手的应用商店，可以在上面装 Windows，可以把它当作一台电脑来用，在上面写程序（我就这么干过）。所以，我觉得它是一件不可思议的东西，外观漂亮，运行出色。大爱。

人生信条

Lenny Rachitsky： 你有没有什么特别喜欢的人生座右铭，在工作和生活中经常回想起来的？

Dhanji R. Prasanna： 如果你每天早上醒来，对自己当天要做的事情不再感到充满干劲，那就改变些什么——如果到了必须辞职的地步就辞职，或者换一种新的方式去做你正在做的事。不要接受别人给你安排好的东西。这是我做事的方式，有时管用，有时不管用，但经常问问自己总是好的。

Lenny Rachitsky： 我非常喜欢这个建议。但对很多人来说，做到这一点真的很难。有没有什么方法帮你克服那种恐惧感——就是”天哪，我要放弃这个了，不知道下一步该去哪儿”的感觉？

Dhanji R. Prasanna： 最主要的一点是告诉自己：一年之后回头看，你现在觉得是巨大的问题、改变人生的大事，到时候你会说”哦，那点事不算什么”。很多时候我们会陷入思维陷阱，过度思虑某件事，或者对做出改变感到紧张不安，但事后回顾起来，那些事其实并没有那么大不了。而此后流逝的时光和发生的种种事件都在告诉你：这个世界比你想象的更广阔，做有意义的事永远不会太晚，为自己做点什么、提升自己，也永远不会太晚。所以，我觉得时刻记住这一点很重要——事情在当下看起来也许很大、很暗淡、很关键，但其实未必如此。

疯狂科学家

Lenny Rachitsky： 最后一个问题。你在 Square 做了很多年的”疯狂科学家”。那么在流行文化或现实生活中，你有没有最喜欢的疯狂科学家形象？

Dhanji R. Prasanna： 这个问题很有意思。我脑海中浮现的始终是《回到未来》里的 Doc Brown。我觉得对我们这一代人来说，他就是疯狂科学家的标准范本——当然电子游戏里也有不少，但他是最经典的那一个。他就是那种”我就是要把这件疯狂的事做出来”的人，几乎是一种无法抑制的渴望和冲动——不管想不想，我必须造出这台时间机器。然后整个电影里他都在想办法修复那台机器所制造出来的各种麻烦。但他对我来说一直是一个特别有趣的角色。

Lenny Rachitsky： 你知道吗，我想到的是《Pinky and the Brain》里的 Pinky。

Dhanji R. Prasanna： 哦对，那个也好。

结语

Lenny Rachitsky： 天哪。Dhanji，这次对话太棒了，你太出色了。非常感谢你的到来。在真正结束之前还有最后两个问题。如果有人想联系你、了解更多关于 Goose 或 Block 的其他动态，在网上哪里可以找到你？另外，听众能怎么帮到你？

Dhanji R. Prasanna： 去看看我们在 GitHub 上 Goose 的页面，以及 Block 的其他所有开源项目。那里有很多有用的东西。我们在 Android 开源方面也做了很多，也去看看吧。你随时可以在 LinkedIn 上找到我，欢迎加我好友，我很乐意被联系到。至于大家能怎么帮忙，我想说——回到我们当下所处的这个充满变革与不确定性的时代——我觉得那些对自己的公司、雇主、团队提出更高要求的人，要求做得更好的人，是很有价值的。在 Block，我们总是问自己：“我们能不能默认把它做成开源的？我们能不能不仅为我们自己或我们的客户构建，而是让所有人都能受益？“我觉得在当前的 AI 时代这一点尤其重要——大家都在把自己关在围墙花园里，试图抢占正在涌现的平台中的各个角落。所以，去对人们提出更高的要求吧。互联网被创造出来时的承诺是：开放共享信息，造福所有人。我觉得 AI 应该帮我们实现这个承诺。所以，去向人们提出这个要求吧。

Lenny Rachitsky： 一个非常美好的结尾。Dhanji，非常感谢你来。

Dhanji R. Prasanna： 谢谢你，Lenny。我真的非常感激。谢谢。

Lenny Rachitsky： 感谢你。

Dhanji R. Prasanna： 再见。

Lenny Rachitsky： 大家再见。

术语表

原文中文
AfterpayAfterpay（Block 旗下的先买后付服务平台）
agent代理（agent）
AI-nativeAI 原生
Alien Earth《异形：地球》（科幻剧集）
AnthropicAnthropic（AI 公司，不做翻译）
Back to the Future《回到未来》（经典科幻电影）
BlockBlock（公司名，前身为 Square）
blue bottle蓝瓶咖啡（Blue Bottle Coffee）
BradBrad（Goose 的创造者，人名保留原文）
CanvaCanva（在线设计平台，保留原文）
Carl Sagan卡尔·萨根（美国天文学家、科普作家）
Cash AppCash App（Block 旗下的移动支付应用）
Cash CardCash Card（Block 旗下的借记卡产品）
CoderPadCoderPad（在线编程面试平台）
Conway’s Law康威定律（Conway’s Law）
CursorCursor（AI 代码编辑器）
DatabricksDatabricks（数据与 AI 平台公司）
Doc Brown布朗博士（《回到未来》系列电影中的经典角色）
Fargo《冰血暴》（Noah Hawley 执导的电视剧）
GMGM（General Manager，总经理）
Google WaveGoogle Wave（Google 推出的一款实时协作通信平台）
GooseGoose（Block 开发的通用 AI 代理工具）
GoslingGosling（Block 开发的移动端自动化测试工具）
GreenfieldsGreenfields（全新、无遗留代码的项目）
hack week黑客周（hack week，公司内部的创新马拉松活动）
Hotel CaliforniaHotel California（《加州旅馆》，老鹰乐队经典歌曲，此处比喻”容易进入但难以离开”）
IC个人贡献者（IC）
IOIO（人名，保留原文）
JackJack（指 Jack Dorsey，Block 联合创始人兼 CEO）
LLM大语言模型（LLM）
LookerLooker（商业智能与数据分析平台）
LovableLovable（AI 应用构建平台）
Mikhail BulgakovMikhail Bulgakov（俄罗斯作家，保留原文）
Model Context Protocol / MCP模型上下文协议（MCP）
Noah HawleyNoah Hawley（美国编剧、制片人，保留原文）
OllamaOllama（本地运行大语言模型的开源工具）
Pinky and the Brain《Pinky and the Brain》（美国动画剧集，保留原文）
PRPR（Pull Request，代码/命令不翻译）
QAQA（质量保证，Quality Assurance）
SalesforceSalesforce（企业 CRM 平台，不做翻译）
SecretSecret（社交网络创业公司，保留原文）
Slow Horses《流人》（Apple TV+ 间谍剧）
SnowflakeSnowflake（云数据平台，不做翻译）
Steam DeckSteam Deck（Valve 推出的便携式游戏掌机）
TableauTableau（数据可视化平台）
Tennyson丁尼生（英国桂冠诗人 Alfred, Lord Tennyson）
TIDALTIDAL（Block 旗下的音乐流媒体服务）
Top Gun《壮志凌云》（1986 年美国电影）
ValveValve（游戏公司及 Steam 平台的母公司，保留原文）
vibe codevibe code（一种通过自然语言提示让 AI 生成代码的编程方式）
《大师与玛格丽特》Mikhail Bulgakov 的长篇小说 The Master and Margarita 的中文译名

此文档由 AI 分片翻译（translate_long_document）