devgo.cn核心观点
- 双披萨团队的原则是「小到不用开会也知道彼此在做什么」：每个成员拥有产品、可逆决策无需许可、试错成本被刻意压低。
- 规模是文化的敌人：从 3 个服务到 200+ 服务，组织分层、依赖成网、审批流程出现——增长的惯性开始对抗让公司成功过的文化。
- Amazon 的 Working Backwards 方法（先写新闻稿、FAQ、客户体验、用户手册）之所以成立，是因为「写清楚」是所有人可参与的构建门槛——不要求会写代码。
- Agent 时代这个前提正在被改写：任何人带着想法与编码 Agent 一晚就能做出产品雏形，Amazon 的 Amazon Quick 桌面原型就是科学家一夜用 Kiro 做出来的。
内容精讲
双披萨团队是 Amazon 文化里流传最广的原则之一：任何团队都不能大到两片披萨喂不饱。它从来不是真的在讲吃——重点是让团队小到「房间里每个人都知道其他人在做什么，而不用开会」。每个成员拥有自己的产品，有自主权在最小官僚路径下做决定、快速实验、不惧失败；只要决定是可逆的，就不需要征求许可——可逆决定的错误成本，几乎总是低于「慢慢做决定」的成本。
**规模如何侵蚀文化。** 当客户基数增长，团队数量随之膨胀。从 3 个服务走到 200 多个服务，组织不可能维持原结构——这是「物理定律」：系统增长，熵也随之增长。每个服务需要负责人，负责人要与依赖其服务的团队协调；组织变分层、依赖成网、原本不存在的审批环节出现。一个原本端到端拥有问题的团队，现在写一行代码前要先在多个团队之间对齐。增长的惯性开始与使它成功的文化对着干——产品质量未必下降，但交付速度一定会，除非你主动反抗。
**写作：让构建无需编程能力。** Amazon 用 Working Backwards 定义产品：先写新闻稿、FAQ、客户体验文档、用户手册。四步的共性是——先对问题空间深度思考，再把它写下来。把想法从脑子里搬到纸上是打磨想法的过程：你能戳穿它、发现自己不知道什么、与同伴建立对「要建什么」的共识。写一份清晰文档是艰难的，没有对客户问题的清晰认知几乎不可能。而写作还有一个刻意的战略理由：写作让任何人都能参与定义产品，因为写不需要会写代码——产品经理、UI 设计师、业务分析师，只要有写好的想法和有力的论证，就能定义下一个要构建的东西。
**Agent 正在改写这个前提。** 问题随之而来：当任何人有了想法，都能坐下来对着编码 Agent，用一晚做出产品的功能外壳，会发生什么？2026 年 1 月底，Amazon 几位科学家各自在思考同一个问题域——如何给 Agent 持久的记忆、如何让多个 Agent 无需中心瓶颈地协调、如何在系统扩展时保持人类控制。他们需要「Agent 的操作系统」。科学家 Thomas Delteil 注意到好主意死得太快：提出想法、等待讨论、做 PoC、跑基准、寻求曝光、再等下一轮审批——这套循环在想法触达任何客户之前就把它们杀死了。当对话转向「如果不再等许可，我们能建什么」，他整夜用 Kiro 做出了 Amazon Quick 桌面的第一个原型。第二天演示时，团队的第一反应是「怎么现在装到我笔记本上」，第二个是「我能帮上什么」——几小时内，这个项目就有了活动流、记忆、知识图谱和 Agent harness 的负责人；一周内，AWS 高层就加入进来。
**双披萨模型的真正内核。** 团队大小只是表象，内核是「自主权 + 快速失败 + 所有人拥有产品」。Agent 时代把「可以构建的人」的范围从工程师扩展到任何有想法的人，这既放大了双披萨文化的能量，也放大了它被规模侵蚀的速度。结论不是放弃规模，而是更早、更自觉地用「小团队 + 快构建 + 可逆决策」去对抗组织熵增——并且接受「写清楚比写代码更重要」这件事，在 Agent 时代变得更加成立。
阅读价值
对技术管理者，这是一篇关于「组织规模如何对抗文化」的清醒复盘，双披萨 + Working Backwards 的组合在 Agent 时代有了新的解释；对产品与工程团队，Amazon Quick 一夜原型的故事说明「想法死亡循环」是真实存在的，而 Agent 让打破它变得便宜。
内容与图片版权归原作者所有 · 原文: https://www.allthingsdistributed.com/2026/06/return-to-two-pizza-culture.html?utm_campaign=inbound&utm_source=rss