亚马逊回归"两块披萨"小团队文化：从 Amazon Quick 看 AI 时代的组织变革

2026年6月30日 • 1830字

当我加入亚马逊时，杰夫有一个想法：任何团队都不应大到无法用两个披萨喂饱。在早期，有些团队小到一个披萨就足以搞定工作。但这从来都不是真的为了喂饱饥饿的工程师。我们完全可以称之为“六个三明治团队”，但三明治无法像披萨那样唤起同样的意象。披萨是当你和同伴们围在白板前讨论到深夜时会点的东西。

我们希望保持团队足够小，这样房间里的每个人都知道其他人在做什么，而无需开会。团队的每个成员都拥有产品。你拥有自主权，可以尽可能少地受到官僚程序束缚地做决定。你被赋予快速行动、实验和不怕失败的能力。如果决定是可逆的，你不需要许可就能做出。你做了决定，从中学习，如果错了，就撤销它。一个错误可逆决定的成本几乎总是低于缓慢做出该决定的成本。

随着客户群的增长，我们的团队数量也在增长。当你从三个服务发展到两百多个时，你不可能保持相同的组织结构。这是简单的物理规律：随着系统增长，其熵也会增长。每个服务都需要所有者，而所有者需要与他们所依赖的服务的团队协调。组织结构变得分层，依赖关系成倍增加，以前不存在的审批周期出现了。突然间，一个曾经端到端拥有问题的团队，现在在写一行代码之前就需要跨多个团队对齐。在某个时刻，任何成长型公司的惯性开始与使其成功的文化背道而驰。这不一定意味着产品质量会受损，但除非你与之抗争，否则意味着你的交付速度会下降。

除了用两个披萨方法来管理团队规模，我们还使用了一种独特的方法来定义我们的产品——从客户出发逆向工作。我在2006年就写过这个：

逆向工作产品定义过程的核心是充实概念，并清晰地思考我们最终将去构建什么。它通常有四个步骤：

1. 从写新闻稿开始
2. 写一份常见问题文档
3. 定义客户体验
4. 写用户手册

我们在逆向工作方面取得了显著成功，并通过至今仍让我惊叹的工程壮举为数百万客户解决了实际问题。我们的团队仍然按照两个披萨模型来设定规模。他们仍然快速行动并打破常规，但他们会等到完全定义问题，并且整个业务线清楚理解他们将如何共同解决它。

但我们的行业正在发生转变，我在 Amazon 不断听到一些故事，促使我以略微不同的方式思考将产品变为现实的过程。如果你看看上面的四个步骤，它们的共同点是对问题空间进行深入思考，然后把它写下来。把想法从你的头脑中拿出来、落到纸面上，正是你打磨想法的方式。你在其中找漏洞，发现你不知道的东西，并与你的同行分享，从而对将要构建的东西达成共识。写出一份清晰简洁的文档是件苦差事，而如果你对自己想要解决的客户问题没有清晰的思路，那几乎是不可能的。但我们在 Amazon 使用写作还有另一个非常刻意的原因：写作让任何人都能构建产品，因为它不要求你会写代码。产品经理、UI 设计师、业务分析师，任何有一个写得好的想法和有说服力论据的人，都可以定义接下来要构建什么。

但当任何一个有想法的人都能坐下来，用一个编码智能体在一个晚上就做出一个可运行的产品外壳时，会发生什么？

2026 年 1 月下旬，我们的几位科学家在彼此交谈时意识到，他们一直在各自独立地思考同一个问题空间。如何给智能体赋予持久化的记忆？如何让多个智能体在没有中心瓶颈的情况下协调？如何在系统扩展的同时让人类保持控制？他们需要一个面向智能体的操作系统。他们决定一起进到一个房间里待上几天，看看能想出什么来。

Thomas Delteil 是我们 Amazon Quick 团队的首席科学家，他一直对好想法消亡的速度感到担忧。提出一个想法、等待讨论、构建概念验证、对它进行基准测试、为它争取关注、然后再等待下一轮批准的循环，在想法触达哪怕一个客户之前就把它们扼杀了。所以当话题转向如果他们不再等待许可、能构建出什么时，Thomas 花了一整晚用 Kiro 构建了后来成为 Amazon Quick 桌面版的第一个原型。当他第二天演示时，团队的第一个问题是“我现在怎么把它装到我的笔记本电脑上？”，第二个问题是“我能帮上什么忙？”。在第一次看到它后的几个小时内，这个项目就有了动态流负责人、记忆负责人、知识图谱负责人和智能体框架负责人。

不到一周，我们的智能体 AI 副总裁 Swami Sivasubramanian 看到了这个原型，并给予团队全力支持。三名工程师加入进来。到第二周，他们有了一位软件开发经理和更多几名工程师，科学和工程人员大致各占一半。他们刻意不扩张得太快。每一个被引入的人都是因为拥有特定技能而被选中，而且他们必须适应一种与更广泛组织运作方式完全不同的文化。他们被期望自主负责一个问题并自主交付，而负责在 Amazon 一直意味着同一件事：你构建它，你拥有它。

Leo Ohannesian是在项目启动五天后被招募加入 Quick 团队的产品经理，他多年来工作过的组织都从 PRFAQ 开始，经历评审周期、争取资金、指派负责人、设定时间表。而在这个早期团队里，这些全都没有。转向一种由一小群资深人员被完全信任、自主做出正确决策的模式，带来了他职业生涯中从未体验过的速度。

让这种节奏成为可能的一大驱动因素是，团队中的每个人从第一天起就把这款产品作为自己的主要 AI 助手来使用。Thomas 按照自己期望助手应有的样子来构建它，任何他不喜欢的地方，他就直接修掉。团队里的每个人都以同样的方式运作。他们不会把粗糙的边缘留给设计师日后打磨，也不会提一张工单让前端工程师在下一个冲刺里处理。如果你在使用时发现哪里不对，你就负责它，并把它修好。每一次代码评审都附带一段体验视频，因为孤立地审查代码根本无法告诉你产品用起来感觉对不对。这是对团队以往工作方式的有意颠覆——过去你会先做基准测试，之后再琢磨体验。而在这里，规则是：在你对现有体验满意之前，不要做任何基准测试。

Clare Liguori是一位领导 Kiro 开发的高级首席工程师，她在去年的 re:Invent 主题演讲中谈到了自己的经历，并最近撰文讲述了同样的模式。她的观察是，当构建一个原型只需几天而非几个月时，先做原型再写文档就更合理。她的团队从第一个原型跑通的那一刻起就全天候使用他们的 IDE，并根据实际需要每天对它进行演进。

写作依然和以往一样重要，而且应该由你来写，而不是你的 AI。写作迫使你清晰地思考，直面逻辑中的漏洞。改变的是，写作不再是让想法变得可触可感的唯一方式。编码智能体正在压缩从定义问题到手中握有真实可评估之物之间的时间。是时候修正我们对这一路走来所遵循流程的思考方式了。你用一个晚上动手构建所学到的，会比花两周写下你认为将会发生什么所学到的更多。只有在你花时间与原型相处、像客户那样使用它、并真正理解它能做什么和不能做什么之后，你才开始写作过程。你在构建之后产出的文档，从根本上优于你在构建之前会写出的文档，因为它不再建立在你假设的基础之上。

那么，我们该如何修正 Working Backwards？当你对客户问题有坚定信念，但对你的方法是否奏效存在真正的不确定性时，你就从构建一个原型开始。然后像客户那样使用它。你把它弄坏，找出直觉遗漏的缺口，再与几位同事分享，如果大家对你构建的东西感到兴奋，你就写文档。写作时手边有可点击体验的实物，会改变文档的质量。你不再是在描述只存在于你脑海中的东西。你描述的是已经存在、并经过压力测试的东西，你的写作也会反映出这一点。

Quick 桌面团队不再只是会议室里的几个人。他们已经发展到数百名工程师、科学家、设计师和产品经理。这是一个如今每天有数十万人使用的产品的自然发展轨迹。每个团队发展到超过一定规模后，都会面临我之前描述的那种走向管理开销的引力。对抗它的方式，是让你的团队能够像由多个“两个披萨团队”组成的集合那样运作，每个团队都有明确的所有权，以及无需请示就能做出可逆决策的自主权。对抗它的方式，是保持反馈循环足够短：构建、使用、学习、迭代。对抗它的方式，是招聘那些如果无法端到端负责自己的问题就会感到不安的人，并给他们工具，让他们能基于这种不安采取行动。

两个披萨始终关乎所有权文化，而工具已经追上了这种文化。让 Quick 桌面团队成功的，与在 Amazon 一直催生我所见过的最佳工作的东西是同一件事：一小群彼此信任的人，端到端地负责问题，并按照自己的信念行动。

现在，去构建吧！