从兼职工程师直接跳到 CTO，他用两个月让一款 Agent 干掉 60% 复杂工作并放话：“代码质量与产品成功没有直接关系”！

当大多数公司仍在摸索如何让开发人员有效使用 AI 编程工具时，金融科技公司 Block 已在 8 周内将 AI 智能体部署给全体员工，覆盖规模达 1.2 万人。

Block 是由美国知名互联网企业家、Twitter 联创 Jack Dorsey 与合伙人于 2009 年创立的金融科技公司，当时公司名为 Square, Inc。

该公司初期的核心产品是 Square 支付设备——一个可插入手机、将手机变为刷卡终端的方形读卡器。该产品诞生于 Dorsey 与合伙人 Jim McKelvey 在圣路易斯的一个小办公室中，为了解决小商户无法接受信用卡的问题而设计。

随着业务不断扩展，公司于 2015 年在纽约证券交易所上市。2021 年 12 月 10 日，公司正式将名称由 Square, Inc. 更名为 Block, Inc.，以体现其从支付服务扩展至更广泛金融与区块链生态的战略意图。至 2024 年，Block 在美国已服务约 5,700 万用户、约 400 万商户。

在 AI 与自动化方面，Block 在 2025 年初推出了一个名为 “Goose” 的开源 AI Agent 框架。Goose 的设计初衷是：将大型语言模型输出与实际系统行为（如读取／写入文件、运行测试、自动化工作流）连接起来，从而不仅让模型能“聊”而且能“干活“。

近日，Block（原 Square）的 CTO Dhanji R. Prasanna 做客了一档名为《Lenny‘s Podcast》的访谈节目，分享了如何内部开源工具 Goose 如何为员工每周抢回 10 小时黄金时间以及从 Google Wave、Google+等失败产品中淬炼出的生存法则等内容。

作为 Block（原 Square）的首席技术官，Dhanji R. Prasanna 在过去两年间领导着超过 4000 名工程师团队，将公司打造成全球 AI 原生程度最高的大型企业之一。而这一切变革的起点，源于他写给 CEO Jack Dorsey 的那份引发组织震荡的“AI 宣言”——正是这份纲领性文件推动了公司级转型，也让他本人走上了 CTO 的岗位。

Lenny Rachitsky 是播客主持人，曾在 Airbnb 担任产品经理，现在运营自己的科技与创业领域的通讯和播客。

以下为对话实录，经由 AI 前线翻译并整理：

Lenny：我想从一封信开始。据说你曾写过一封信给 Jack Dorsey，劝说他和 Block 应该更加重视人工智能。你称它为你的 “AI 宣言”，看起来它确实起了作用。能说说那封信写了什么？你发给 Jack 之后发生了什么？

Dhanji：大约两年半前，Jack 意识到公司需要一些改变。他察觉到整个行业的方向正在发生转变，于是他召集了公司大约 40 名高管，每周开一次会，深入讨论公司的发展。我当时也被邀请加入这个小组。那时候我注意到，大家谈了很多深刻的问题，也讨论了各种战略方向，但几乎没人关注 AI。于是，我写下了那封信。

老实说，那封信其实很简单，主要的意思就是：我们必须认真对待 AI，要在公司层面集中投入，并且要成为一个“AI 原生（AI-native）”的公司——因为那是未来整个行业前进的方向。

Lenny：要特别说明的是，当时你还不是 CTO，对吗？

Dhanji：没错。当时我只是一个兼职的高级工程师，因为刚有了孩子，正在慢慢回到工作中，帮一个工程团队处理一些事情。后来 Jack 来到悉尼，我们一起散步聊了两天，几乎走遍了整个城市。他向我详细谈了对公司未来的设想，最后邀请我担任 CTO。我觉得那是一次难得的机会，于是答应了。

Lenny：在 Jack 和高管团队都认可了你的想法之后，你做了哪些重大变革？其他公司如果也想向 AI 转型，可以从中学到什么？

Dhanji：我首先想让 Block 重新以“科技公司”的身份去思考自己。过去一段时间，我们的定位有点漂移，开始更多地把自己当作一家金融服务公司，甚至自称“金融科技公司（fintech）”。但我刚加入 Square（Block 旧名）时，我们一直把自己看作科技公司——像 Google 或 Facebook 那样。我想让公司回到这种状态。

于是我推动了很多内部举措，比如组织顶尖工程师定期交流，启动多个特别项目，每个项目有两到五名工程师，共有八九个项目同步推进。同时我们恢复了公司范围的 Hack Week（黑客周）。这些举措重新点燃了团队的创造热情——大家重新觉得自己是在“造技术”，在推动前沿。

接下来，我们进行了一个关键性的组织变革：从“总经理制”（GM structure）转向“职能制”（functional structure）。这一步，是我们成为 AI 原生公司的重要转折点。

Lenny：能解释一下这意味着什么？为什么这很重要？

Dhanji：在 Square 的成熟阶段，我们采用的是 GM 模式。比如 Square、Cash App、Afterpay、Tidal（音乐流媒体）等业务，都像独立公司一样运作，各自有 CEO、独立的工程和设计团队，只共享少量基础资源，如法务和平台技术。这种架构在当时很合适，让业务快速成长。

但当你想真正深入技术、参与到行业级的技术变革中时，就需要“统一的技术焦点”。因此我们调整了组织结构——所有工程师归属于同一个工程部门，所有设计师归属于统一的设计团队。我们设立了统一的工程负责人、统一的设计负责人。

这种转型让我们可以集中力量推进 AI、平台建设以及整体技术深度。这也是我们真正变得 AI 原生的基础。

Lenny：总结下来，就是两点：一是重新把自己看作科技公司，二是让工程师向工程领导汇报，而不是向不懂技术的总经理汇报。对吗？

Dhanji：对，这正是我们做的。其实这也和乔布斯当年重组苹果的做法类似，他回到苹果后也改成了职能型结构。我们并没有照搬谁的做法，而是在探索过程中发现这是让团队重新聚焦技术的关键。所谓“技术优先”，其实就是把工程与设计重新放到公司核心位置。

Lenny：那么，这些改变带来了什么不同？现在的工程团队和两三年前相比，最大的区别是什么？

Dhanji：这场变革并不轻松，并不是所有人一开始都同意。过程中我体会最深的是 “康威定律” 的力量——你的组织结构会直接影响你产出的产品结构。

过去我们的各个产品线（Cash App、Afterpay、Square、Tidal）各自为政，没有统一的技术战略，也没有共同的长期目标。而现在，我们至少讲着同一种“技术语言”，使用统一的工具、政策和评估体系。工程师可以在不同团队之间灵活流动，整个公司也把“技术卓越”视为共同目标。两三年前，这种技术导向还并不明显。

Lenny：能具体说说，现在工程团队在日常工作中有哪些变化？

Dhanji：那些“AI 原生”的团队与两三年前完全不同。他们使用像 Vibe Code 这样的工具，几乎不再手写代码，而是通过 AI 辅助生成和修改。这在两年前根本不可能实现。

而那些还依赖旧系统的团队，也在慢慢引入后台 AI 工具，比如自动检测漏洞、在夜间生成补丁。工程师第二天上班就能直接查看修复结果。不同团队的应用深度不同，但总体上 AI 已经深入到我们的日常开发流程中。

Lenny：接下来谈谈 AI 部分。你们开发了自己的 AI 智能体 “Goose”。外界对 AI 提升生产力的讨论很多，一派认为 AI 将带来 10 倍加速，另一派觉得这是炒作。你怎么看？你们团队实际看到了哪些成效？

Dhanji：我们的首要目标是“让 Block 实现自动化”，也就是让 AI 渗透到公司的每个角落。现在还只是刚起步阶段，但我们已经看到显著成效。

那些深度使用 Goose 的工程团队，每周平均节省 8～10 小时人工工作时间。我们通过多维度数据验证，比如 PR 数量、功能吞吐量等，估算公司整体的人工节省率约为 20%～25%。而这仅仅是开始。

AI 原生的公司，比如从 AI 创业起家的企业，更容易获得这种成效。但确实，AI 不是万能药——它仍在快速进化，价值每天都在变化。企业需要灵活地顺势而为，持续探索 AI 最有效的落地场景。

举个例子，我们发现 Goose 特别适合让非技术团队自建小工具。比如企业风险管理部门现在能自己开发内部系统，以前这要花上几周、等待应用团队排期，现在几个小时就能完成。

另一个让我兴奋的应用是 “Gling”——可以理解为 Goose 的移动端版本。它通过 Android 的辅助功能接口直接操作系统，用于自动化 UI 测试。过去我们需要一整支 QA 团队来手动点测试，现在都能自动完成并生成报告。

当然，AI 目前仍不擅长高层次的架构和设计决策，这些仍需要资深工程师来思考。但我相信，随着模型能力的提升，这些界限也会逐步模糊。

Lenny：听起来 Goose 不只是一个工具，而是 Block 转型为真正“AI 原生公司”的象征。对吗？

Dhanji：是的。它不只是技术项目，更是一种文化信号——让每一位员工，无论是否工程师，都能用 AI 去构建、去创造。我们希望让 AI 成为公司最自然的“操作系统”。

如何衡量 AI 在团队中的生产力提升

Lenny：你刚才提到了一个很有意思的指标，用来衡量 AI 在你们团队中的影响。能具体说说吗？比如，是按照“节省的人类人工工时”来计算的吗？

Dhanji：没错，我们主要用“节省的人工工时”来衡量 AI 带来的生产力提升。根据目前的数据，大约相当于节省了一名工程师四分之一的时间。

Lenny：这个指标是只针对工程团队，还是整个公司？

Dhanji：是针对所有团队的，包括支持团队、法务团队、风控团队等的综合数据。不过在工程团队内部，这个比例会有波动。比如，从零开始的新项目或新平台应用，AI 的效率提升会非常明显；而在已有的、复杂度高的老代码库中，提升就相对有限。

Lenny：这已经很惊人了。而且可以预见，这只是 AI 能力最“差”的时候，未来只会更强。

Dhanji：没错，现在只是一个起点。后面会“疯狂”得多。

Goose 是什么，以及它如何工作

Lenny：你刚刚多次提到“Goose”，但还没解释它到底是什么。听起来像是件大事。能详细介绍一下吗？

Dhanji：Goose 是一个通用型 AI 代理（AI Agent），你可以把它理解成一款桌面应用。安装后，它有一个类似聊天机器人的界面，你可以直接跟它对话，比如说：“Goose，帮我把照片按类别整理一下。”

它能识别照片中的内容，比如有很多树的会被分成“自然风光”，有很多人像的会归类到“人像摄影”。除此之外，它还能帮你写代码、生成报告、处理数据等各种任务。

Lenny：听起来像一个能动手干活的 AI，不只是聊天。

Dhanji：对，关键是我们基于一个叫“模型上下文协议”（Model Context Protocol，简称 MCP）的框架构建了它。这个协议最早由 Anthropic 提出，我们很早就参与了贡献。

MCP 的作用是：为现有的企业工具（比如 Salesforce、Snowflake、SQL 等）提供一层封装，让这些工具能被大模型直接调用和操作。换句话说，过去大模型只能“聊天”，而现在它有了“手和脚”，能在数字世界中执行实际任务。

Lenny：Goose 是开源的吗？

Dhanji：是的，完全开源。任何人都可以下载、使用、甚至扩展它，编写自己的 MCP 模块。目前已经出现了大量基于 MCP 的扩展。

Lenny：所以 Goose 本质上是一个桌面应用，有 UI，可以连接各种云服务和开源模型，对吗？

Dhanji：对。Goose 支持接入任何模型。你可以自己带 API Key 来用 OpenAI 或 Anthropic 的云模型，也可以使用开源模型（通过 Olama 等工具本地运行）。它能把大模型的语言理解与生成能力，真正用在现实场景中。比如，你可以让 Goose 生成一份营销报告：会自动连接到 Snowflake、Tableau、Looker，写 SQL 抽数据，用 Python 处理，生成图表、导出 PDF 或 Google 文档，甚至还能自动发邮件发送报告。而这些任务完全由它自主完成。

Lenny：那你们在 Block 内部也都是用 Goose 来做事的吗？

Dhanji：我们允许员工自由选择任何 AI 工具，但 Goose 因为和内部系统的整合最好，所以用得最广。过去如果我们想在某个系统（比如 Bug 追踪工具）中加入 AI 功能，要么等厂商更新，要么依赖外部 API。现在有了 Goose，只需几行代码就能实现 AI 自动化。甚至，Goose 可以自己生成新的 MCP 扩展。

Lenny：而且其他公司也可以直接用你们的 Goose？

Dhanji：是的。我们有很多合作伙伴和竞争对手都在用它，包括像 Databricks 这样的公司。

Goose 是完全开放的，我们相信开源的力量。我们的目标不是只让 Block 受益，而是让这些工具超越 Block 的生命周期，成为开放生态的一部分。

Lenny：那“Goose”这个名字是怎么来的？

Dhanji：是电影《壮志凌云》（Top Gun）的梗。起这个名字的工程师长得也像片中的 Goose，我们干脆就顺势用了这个名字。

Lenny：哈哈，有意思。我听说你们有个工程师甚至让 Goose“看着他工作”？

Dhanji：是的，他非常痴迷 AI 实验。他让 Goose 实时观察他的屏幕——Goose 能识别截图内容。

有时候他在 Slack 或邮件里讨论某个功能，几小时后就发现 Goose 已经自动帮他写好代码、提交 PR 了。甚至如果他在会议中超时，Goose 会提醒他该去开下一个会。更厉害的是，如果他临时要接孩子，Goose 会自动帮他重排会议日程。这些功能原本要靠日历厂商去做，但现在 AI 已经能自己协调完成了。

AI 在工程和生产力的未来

Lenny：你觉得未来两三年，AI 会怎样改变工程师和产品团队的工作方式？

Dhanji：我认为关键取决于大模型性能的提升。现在所谓“对话式编程”（vibe coding）还很原始——需要不停地来回对话，等待回应。我们正在做的实验是让 AI 有更强的自主性。现在 Goose 平均一次交互大约持续 5 分钟，我们希望它能持续几个小时甚至几天工作。比如，AI 可以在夜间或周末继续工作，提前构建我们第二天要用的功能。未来，我们可以一次性描述多个实验方向，让 AI 在夜里全部实现。第二天醒来，我们只需挑出最好的方案。

Lenny：这意味着工程师可以大量“重写”，甚至每次版本发布都重建整个应用？

Dhanji：是的。过去我们讲“不要轻易重写代码”，因为代价太大。但 AI 可以让这一点成为可能。未来我们可能每次发布都能“删除再重建”，用 AI 生成最优的新版本。关键是让 AI 能保留那些细微的经验和优化。

Lenny：你甚至让 Goose 自己改进自己？

Dhanji：没错，我最近就在试。让 Goose 提出改进建议并在夜间实现。虽然有时会“跑偏”，但总体上有大约 60%的任务能成功完成，剩下的需要人类介入。

人类的“品味”仍然关键

Lenny：听起来未来 AI 可能连增长和营收都能自己优化了。不过，这会不会让人类失业？

Dhanji：我不这么认为。AI 仍然需要人类的“品味”和判断来防止跑偏。我们团队的设计负责人一直提醒我们：AI 的工作要有“人味”，要真正对人有价值。这将成为下一阶段的关键差异点。

Lenny：能举个例子吗？什么时候你们会觉得必须由人来做决定？

Dhanji：比如流程自动化。很多团队会提需求说要买新的厂商工具，另一部分团队则主张用 Goose 自建。但有时我会问：我们真的需要这个流程或工具吗？如果只是调整一下流程，也许什么都不用做。AI 还做不到这种全局判断——它不会思考“什么才是真正重要的”。这些领域仍然需要人类决策。

Lenny：那你怎么看“自己开发 vs 购买 SaaS 工具”这个问题？AI 会让企业不再需要那些软件吗？

Dhanji：我认为要回到公司的核心使命。对 Block 来说，我们的使命是“经济赋能”——帮助商家、艺术家和个人实现收入和创作。只要能推动这个目标的，无论是自己开发还是购买现成工具，都值得投资。如果只是为了节省成本去自建，而让团队分心、偏离使命，那是得不偿失的。所以关键不是省钱，而是保持专注：持续做对用户真正有意义的事。

Lenny：所以，总的来说，现在你们在招聘时最看重的变化，是不是在于寻找那些愿意主动拥抱 AI 的人？不是那种觉得“我自己是个超强工程师，不需要用什么 Cursor、Goose 之类 AI 工具”的人？

Dhanji：没错。我们更看重的是一种“学习型思维”。这是我们 CEO Jack Dorsey 经常提到的。他希望 Block 成为一个“学习优先”的公司。无论我们在做什么实验、发布什么功能，最重要的问题始终是：我们从中学到了什么？我们有没有尽力去尝试？ 对 Jack 来说，这比每次都得出“正确的商业答案”还要重要。

Lenny：那在招聘环节，你们会鼓励工程师在做面试题时使用 AI 工具吗？比如，看看他们怎么借助这些工具解决问题？这和过去一两年相比有什么变化？

Dhanji：是的，我们现在开始这样做了。传统上，我们会用像 CoderPad 这样的在线白板工具，让候选人手写伪代码或讲解解题思路。但现在我们会观察他们是否会使用 AI 工具，比如“vibe coding”（与 AI 协作式编程）去构建某些功能，看看他们对这些工具的熟悉度，以及他们如何思考 AI 的协同作用。

当然，现在还处于早期阶段。就我个人看法而言，一个人是否熟练使用 Goose 或 Cursor，并不一定能决定他是不是一个好工程师。真正重要的，仍然是他们是否具备批判性思维，能否深入理解技术问题的本质。这些能力比是否是“AI 原生程序员”更关键。

Lenny：我一直在想一个问题——AI 工具到底对哪一层级的工程师帮助最大？有人认为是初级工程师，因为他们能快速完成大量工作；也有人认为是资深工程师，因为他们更懂系统架构，能指挥“上千个 AI 代理”为自己服务。你怎么看？

Dhanji：其实两种观点都对。我的观察是：资历越深的工程师，和刚入行的新手，反而是最愿意使用 AI 工具的两类人。

资深工程师因为深知系统的复杂性，他们对 AI 的到来几乎是“如释重负”——终于有工具能自动完成那些他们已经做了一百万遍、不想再重复的事。而年轻工程师，就像我侄女侄子玩 iPhone 那样，上手极快、毫无包袱，他们“闪电般”地使用这些工具，比我们老一辈敲键盘要高效太多。

不过，真正让我感到惊讶的是那些“非技术岗位”的人。比如法务、风险控制或设计团队，他们开始用 AI 代理和编程工具来完成任务，效率惊人。这也预示了未来岗位的界限会越来越模糊——法务可能也在写代码，工程师也可能在做设计。能主动利用 AI 来优化自己工作流程的人，往往能带来最大的影响力。

Lenny：这点很有意思——大家谈论工程师生产力时，往往忽略了一个关键点：AI 帮工程师减少了来自其他部门的随机需求。比如法务或市场团队临时让他们“写个小工具”，AI 帮忙后，这部分负担大大降低了。这是不是工程师生产力提升的重要来源？

Dhanji：完全正确。这其实是一种“隐形红利”。不过，它也有点像“修更宽的公路”：一旦你提高了产能，就会有更多车上路。因为现在每个部门都能自己构建软件，所以反而带来了更多协作需求，更多的开发任务，大家都更急于发布新功能、更快地交付结果。结果就是：整体开发速度在提升，但任务量也在增加。

Lenny：听起来你们的招聘节奏并没有因为 AI 而放慢。现在各团队对工程师和产品经理的需求仍然很旺盛？

Dhanji：对，不过我们更有策略地去思考“怎么招人”。在过去，我们把工程师数量与产品功能数量挂钩，比如 Square 或 Cash App 的功能越多，就要更多工程师。但现在我们更关注“结构性优化”——比如在哪些领域可以深入挖掘、模块化、重用，从系统层面去加速我们的重点业务。换句话说，AI 让我们更关注“深度”和“效率”，而不是简单地扩张团队。

Lenny：你这观点太棒了——“想提升生产力，不只是用 AI，还要重新组织结构”。

Dhanji：确实有点道理。举个例子，我们最近想提升构建速度，就同时使用了 Goose 和其他工具，效果非常显著。我们开发了一个工具，能智能分析测试套件，只运行与代码改动相关的测试，从而减少了 50%的测试运行量。这不仅节省了时间，也降低了能耗（CPU 周期不再被浪费）。

而进一步的优化，比如把测试转移到云端，或者删除那些已经没意义的测试，甚至能再额外节省两到三倍的资源。所以最终你需要的是一种“组合策略”——就像我之前提到的，有时我们要问自己：“这个流程我们还需要吗？”在某些情况下，组织结构的合理性，比你用什么 AI 工具更重要。

先亲自用 AI，再推动团队用

Lenny：在聊你职业生涯的经验之前，我想问最后一个问题：对于那些正在尝试更深入拥抱 AI 的团队，你有什么建议？

Dhanji：最重要的一点是——一定要自己先用这些 AI 工具。我们能推动内部广泛采用 AI，关键就在于：Jack Dorsey 自己每天都在用 Goose，我自己也用，我们整个高管团队都用。我们亲自去体验 AI 助手、AI 编程工具的使用场景，每天都在实践。这样我们才能真正理解 AI 如何改变我们的工作流。这种亲身体验，比在 LinkedIn 或哈佛商业评论上读十篇分析文章都管用。只有自己去感受 AI 产品的优缺点、操作体验，才能找到适合团队的应用方式。

Lenny：我完全同意。其实别光听我们聊 AI，真正的诀窍是“别想太多，直接动手”。去做点什么、解决一个真实问题，你就会学得更快。比如前几天我想从 Google 文档中导出图片。众所周知，Google 文档就像“数字版的加州旅馆”——图片能放进去，却很难拿出来。于是我用 AI 工具 Lovable 写了个小程序，只要输入文档 URL，就能一键下载所有图片，几分钟搞定。

Dhanji：太棒的例子！我前阵子也遇到类似的事。我儿子需要做一些康复治疗，我要整理所有治疗的收据发给我太太，好去保险报销。问题是，这些收据有的是截图，有的是 PDF，还有邮件附件，格式混乱。于是我让 Goose 帮我整理。它识别出这些文件都在我笔记本里，然后自动将所有收据整合到 Apple Notes 里的一个笔记中。更厉害的是，它还把内容转成 HTML 格式，让我能在 iPhone 上无缝查看，并直接分享给我太太。

整个过程是 Goose 自己在后台用 Apple Script 控制我的电脑完成的。这完全是我自己不会想到的解决方案。

Lenny：听起来真的很酷。那普通人也能直接下载 Goose 来用吗？

Dhanji：当然可以。Goose 可以在我们的官网上直接下载，我们会把链接放在节目备注里。它支持 Mac、Windows 和 Linux，是个 Electron 应用，也提供命令行版本，方便喜欢用命令行的用户操作。

Lenny：那 Goose 和类似 Cloud Code 这样的工具比，有什么不同？

Dhanji：Goose 的核心是 MCP（Model Context Protocol）平台，这让它具有动态可扩展性。它既能自动化办公任务，比如整理 Google 文档或笔记，也能通过其他 MCP 执行编程任务，比如索引和处理代码。可以说，它介于传统的 AI 助手（回答天气、做计算）与专注于代码生成的工具（如 Cursor、Cloud Code）之间，是一个“可扩展的智能平台”。

Lenny：而且它是免费的？

Dhanji：对，Goose 本身是免费的，你只需要为使用的大模型 tokens 付费。我们主要基于开源模型开发，所以用户门槛很低。

漂亮的代码不代表会成功

Lenny：你现在担任 Block 的 CTO 已经大约两年了。如果能回到两年前给当时的自己提点建议，你最希望自己知道什么？

Dhanji：有两点。第一是 康威定律（Conway’s Law） 的力量——如果不改变组织中人与人之间的关系结构，就很难改变结果。我以前“知道”这个道理，但直到亲身感受到它的影响，才真正理解。

第二是，作为 CTO，你通常只在事情出问题时才会听到反馈。当一切顺利时，反而会陷入“安静”的不安中，不确定自己是否在关注正确的问题。所以要学会定期退后一步，从整体上反思方向和重点。

Lenny：很多人还不太清楚 Block 和 Square 的关系，你能简单解释一下吗？

Dhanji：当然。Block 是母公司，旗下有四大主要品牌：Square、Afterpay、Cash App 和 TIDAL。此外，我们还有 BitKey 和 Proto 两个专注于比特币硬件的团队。

Lenny：在你看来，关于产品开发或团队建设，你学到的最“反直觉”的经验是什么？

Dhanji：我觉得是“代码质量与产品成功没有直接关系”。工程师通常认为高质量代码等于成功的产品，但事实完全不是这样。举个例子，YouTube 被 Google 收购时，很多人抱怨它的代码结构糟糕——视频数据存 MySQL 里、架构混乱。但它成为了 Google 最成功的产品之一。

相反，Google 自己的 “Google Video” 技术更先进、功能更多，却被 YouTube 彻底击败。

所以关键不在代码，而在：产品是否真正解决了用户的问题。

Lenny：哈哈，这个例子太经典了。你还提到，有时候团队看起来乱七八糟，其实那种“受控的混乱”反而有价值？

Dhanji：没错。在我负责 Cash App 的早期，我们团队从 10 个工程师扩张到 200 多个，看起来非常混乱——大家同时做实验、快速上线，没有严格流程。但这种自由让工程师们充满创造力。当然，你得确保基础系统稳固，不会出可靠性事故或损失资金，然后在安全的边界内，让工程师们自由探索。受控的混乱（controlled chaos），往往能激发最有价值的创新。

Lenny：你觉得有哪些核心的领导力经验，是你一路以来最受用的？

Dhanji：最重要的一条是：从小处开始（Start small）。如果你想泡一杯茶，却非要“煮沸整个海洋”，那你永远也泡不成茶。要专注在眼前能完成的小目标。

比如 Goose 的起点，只是一个工程师的业余项目，他相信“Agent 会是释放大模型价值的关键”。他做了个原型，分享给 Databricks、Anthropic，逐渐形成共鸣和合作，最终发展成现在的 Goose。Cash App 也是从一次 Hack Week 小实验开始的。

我们甚至连最早的比特币项目，也是我、Jack Dorsey 和另一位工程师在 Hackathon 上做出来的——用 Cash Card 买了一杯 Blue Bottle 的咖啡，那大概是我人生中最贵的一杯咖啡。

Lenny：是个精彩的故事。那反过来，有哪些项目是你参与但失败了的？

Dhanji：太多了。Google Wave、Google+、Secret（一个匿名社交应用）、还有一个邮件创业项目（后来 Canva 的联合创始人也参与过），都失败了。

但每一次失败都教会我一些东西，也让我更谦逊——学会倾听别人的观点，而不是以为自己全都懂。真正的成功，比如 Cash App，就是在那些失败的经验基础上建立起来的。

Lenny：我猜那些失败的项目，代码质量都特别好？

Dhanji：哈哈，有些确实很漂亮，有些则各方面都糟糕透顶。失败的原因很多，但漂亮的代码从来不是决定因素。

参考链接：

https://www.youtube.com/watch?v=JMeXWVw0r3E

https://thenewstack.io/how-block-got-12000-employees-using-ai-agents-in-two-months/