← #810

回归两张披萨的文化

文章摘要

这是亚马逊 CTO Werner Vogels 发在 All Things Distributed 上的文章（2026 年 6 月 30 日，约 1830 词）。他的核心主张是：AI 编码工具已经改变了产品从想法到落地的路径，亚马逊那套著名的”倒推工作法”（Working Backwards）该修订了，而”两张披萨团队”背后的所有权文化反而比以往更重要。

他先回顾出处。当年贝索斯的想法是：任何团队都不应大到两张披萨喂不饱——早期有些团队一张就够。重点从来不是喂饱工程师，而是让团队小到”每个人不开会也知道别人在做什么”，每个成员都拥有这个产品，能以最少的官僚程序自行决策。他强调其中的一条判断原则：如果一个决定是可逆的，就不需要审批，做了、学了、错了就撤回——做错一个可逆决定的代价，几乎总是低于把这个决定拖慢的代价。

然后是规模带来的熵。从三个服务长到两百多个服务，组织结构不可能不变：每个服务都要有归属，归属者要和上下游协调，层级出现、依赖倍增、原本不存在的审批周期冒出来，一个过去端到端拥有问题的团队，现在写一行代码之前得先跨多团队对齐。他说这未必让产品质量变差，但如果不主动抵抗，交付速度必然下降。

与两张披萨并行的另一套方法是倒推工作法，他在 2006 年就写过其四个步骤：先写新闻稿、再写 FAQ 文档、定义客户体验、写用户手册。这套方法的共同点是先深度思考问题空间，再把想法写下来——写作是打磨想法的方式，逼你发现自己不知道什么，并与同事达成共识。他特别点出亚马逊坚持写作还有一个刻意的理由：写作让任何人都能定义产品，因为它不要求你会写代码——产品经理、设计师、业务分析师，只要有一份写得清楚、论证有力的文档，都能决定下一个要造什么。

但他接着抛出全文的转折设问：当任何有想法的人坐下来和编码 agent 待一个晚上，就能造出一个能跑的产品雏形时，会发生什么？

他用 Amazon Quick 桌面版的诞生做案例。2026 年 1 月底，几位科学家发现彼此在独立思考同一组问题——怎么给 agent 持久记忆、怎么让多个 agent 在没有中心瓶颈的情况下协调、怎么在系统扩张时让人类保持控制——他们需要一个”agent 的操作系统”，于是关进一间屋子几天。其中一位首席科学家 Thomas Delteil 长期困扰于”好点子死得太快”：提案、等讨论、做 PoC、跑基准、争取曝光、再等下一轮审批，想法在触达任何一个客户之前就被耗死了。当话题转到”如果不等审批我们能造什么”，他用 Kiro 通宵做出了第一个原型。第二天演示后，团队的第一个问题是”怎么马上装到我笔记本上”，第二个是”我能帮什么”；几小时内，活动流、记忆、知识图谱、agent 框架各自有了负责人。一周内 VP 给了全力支持，三名工程师加入；第二周有了研发经理，科学与工程大致对半。他们刻意不快速扩编，每个加入的人都因为某项具体技能而被挑中，并且必须适应一种与大组织完全不同的文化。五天后加入的产品经理 Leo Ohannesian 过去习惯的流程是 PRFAQ、评审、拿预算、定负责人和时间表，而这个团队什么都没有——一小群资深的人被完全信任去做正确决定，带来了他职业生涯中从未体验过的速度。

Vogels 归纳出几条具体做法。第一，团队每个人从第一天起就把这个产品当成自己的主力 AI 助手用，不把粗糙之处留给设计师去打磨、不开工单等前端下个迭代接手——你用的时候发现哪里不对，那就是你的，你修。第二，每次 code review 都附一段使用体验的录屏，因为孤立地读代码根本说明不了产品用起来对不对。第三，这是对旧习惯的刻意反转：过去是先跑基准、体验以后再说，现在的规矩是在你对体验满意之前，不许跑任何基准。他还引用了领导 Kiro 开发的资深首席工程师 Clare Liguori 的同类观察：当做一个原型只要几天而不是几个月，先做原型再写文档就更合理。

在”那么倒推工作法该怎么改”这一节，他给出明确答案：写作依然和以往一样重要，而且应该由你来写，不是你的 AI——写作逼你把逻辑想清楚、直面漏洞。变的是写作不再是让想法变得可触摸的唯一方式。当你对客户问题有信念、但对自己的方案是否可行存在真实的不确定性时，先做原型，像客户一样使用它，把它弄坏，找到直觉遗漏的缺口，给几个同事看；如果大家为它兴奋，再写文档。他的说法是：一个晚上的动手所学，胜过两周去写”你以为会发生什么”；而建完之后写出的文档本质上更好，因为它不再建立在假设之上。

结尾回到两张披萨。Quick 桌面团队如今已扩到数百人——这是一个每天被数十万人使用的产品的自然轨迹，而任何越过某个规模阈值的团队都会被同一股引力拖向前面描述的那些开销。他给出的对抗方式是三条：让团队以”一组两张披萨团队”的形式运作，各自有清晰归属和做可逆决定的自主权；保持反馈回路短——build、use、learn、iterate；招那些”不拥有端到端问题就浑身不自在”的人，并给他们工具去纾解这种不适。最后一句是他惯用的落款：”两张披萨从来说的都是所有权文化，而现在工具终于追上了这种文化。”

HN 评论精华

必须如实说明：这篇文章在 HN 上几乎没有引发讨论。 本期指定的帖子（id=49737327）只有 2 分、零条评论。通过 Algolia 搜索同标题可以确认，这篇文章至少被提交过五次（48735528、48743750、48759028、48784184、49737327），最高的一次也只有 17 分，全部五个帖子加起来只有一条评论——用户 ahartmetz 的一句话评价：这是”一个奇怪的、绕了半天的长故事”（a strange shaggy dog story），意思是铺陈很久却没给出与铺陈相称的结论。

也就是说，这篇由亚马逊 CTO 署名、讲 AI 时代如何修订 Working Backwards 的文章，在 HN 上反复提交却始终没有形成讨论。这里不编造任何其他评论。

考虑到讨论区为空，补充几点原文中值得单独拎出来的要点，供读者自行评估那条”shaggy dog story”的批评是否成立：

方法论上的真正改动只有一处：把”写文档 → 评审 → 建原型”的顺序，改成”建原型 → 用它 → 给同事看 → 再写文档”，且只适用于”对客户问题有信念、但对技术方案有真实不确定性”的情形。Vogels 并没有主张取消文档，反而明确要求文档由人自己写。
可逆决定原则被重新强调：可逆的决定不需要审批，慢决策的代价通常高于错决策的代价。这条是全文唯一一条可以直接照搬的管理规则。
两条团队层面的硬规矩较为具体：每个 code review 附使用录屏；在体验令自己满意之前不允许跑基准测试。
文章的结构性张力在于结尾：案例中那支”不等审批、通宵出原型”的团队，在文章写作时已经扩张到数百人——恰恰成为它自己所描述的那种”被引力拖向开销”的组织。作者把这一点当作论据（所以才要回归两张披萨），但读者也可以把它读成反证。