中文精炼导读
核心观点
- Werner Vogels（AWS CTO）以"回归两比萨文化"为题，反思了编码 agent 正在如何改变 Amazon 的产品开发流程——尤其是那个曾经支撑公司成长的"逆向工作法"（Working Backwards）。
- 两比萨团队的本意从来不是"喂饱工程师"：它要让团队小到"房间里的每个人都知道别人在做什么，而不需要开会"，成员拥有产品、有自主权、被授权快速行动并敢于试错——可逆的决策不需要审批，"一个错误可逆决策的代价几乎总是低于慢慢做决策的代价"。
- 但公司成长是简单的物理：从三个服务到两百多个服务，组织分层、依赖成倍、审批环出现，增长的惯性开始侵蚀让公司成功的文化，除非主动抵抗，否则交付速度必然下降。
- 转折点是编码 agent：当"任何有想法的人都能在某个晚上用编码 agent 做出一个可用的产品外壳"，写作就不再是让想法变得可触的唯一方式——Amazon Quick 团队一夜之间用 Kiro 做出原型、一周内得到 VP 全力支持，展示了一条"先原型、后文档"的新路径。
- 核心论断：先花一个晚上动手构建，比写两周"你预期会发生什么"学到更多；只有先用过原型、像客户一样使用它、真正理解它能做什么不能做什么，才开始写作——基于构建产出的文档，本质上优于基于假设写出的文档。
内容精讲
文章以 Amazon 的经典管理理念开场：Jeff 有个想法——任何团队都不该大到两比萨喂不饱。早期的团队小到一份披萨就够，但这从来不是关于喂饱饥饿的工程师。披萨是在你和同伴深夜围在白板前的深夜加班时才会点的东西——这个意象意味着"小团队 + 主人翁精神 + 快速行动"。每个成员都拥有产品，有自主权、尽可能少的官僚主义，被授权快速行动、实验、不怕失败。如果决策可逆，你不需要许可就去做：你做了、你学到了、如果错了就逆转。文章强调：可逆的错误决策的成本几乎总是低于慢慢做决策的成本。
随着客户群增长，团队数量也增长。从三个服务到两百多个服务，你不可能保留同样的组织结构——系统增长，熵也随之增长。每个服务需要负责人，负责人需要与依赖的服务团队协调；组织结构分层、依赖成倍、原本不存在的审批环出现。曾经端到端拥有一个问题的团队，现在写第一行代码前就要跨多个团队对齐。在任何成长公司的某个时刻，惯性开始对抗造就它成功的文化——这未必意味着产品质量下降，但如果你不抵抗它，就意味交付速度下降。
文章随后介绍了 Amazon 定义产品的独特方法：从客户出发逆向工作（Working Backwards）。Vogels 在 2006 年就写过这个过程，典型四步：先写新闻稿（Press Release）、写 FAQ 文档、定义客户体验、写用户手册。这四个步骤的共同点是：对问题空间进行深度思考，然后写下来。把想法从脑中拿到纸上，是打磨想法的方式——你戳洞、发现你不知道的、与同事分享以达成共识。写一份清晰文档是困难的工作，如果你对要解决的客户问题没有清晰头脑，几乎不可能写出来。但写作还有另一个刻意的原因：写作让任何人都能构建产品，因为它不要求你会写代码——产品经理、UI 设计师、业务分析师，任何有写得好的想法和有力论证的人都能定义接下来要构建什么。
"但当任何有想法的人都能坐下来用编码 agent 在某个晚上做出一个可用的产品外壳时，会发生什么？"这正是文章的核心转折。2026 年 1 月底，几位 Amazon 科学家各自独立思考着同一个问题空间：如何给 agent 持久记忆？如何让多个 agent 协调而没有中心瓶颈？如何在系统扩展时让人保持控制？他们意识到需要"agent 的操作系统"，决定关起门来几天看看能做点什么。Amazon Quick 团队的首席科学家 Thomas Delteil 一直担心好点子死得太快：提出想法 → 等待讨论 → 构建概念验证 → 基准测试 → 寻求可见性 → 再等下一轮审批——这个循环在想法触达任何客户之前就把它们扼杀了。当对话转向"如果他们不再等待许可"能造什么时，Thomas 用 Kiro 花了一整夜构建出 Amazon Quick 桌面的第一个原型。第二天演示时，团队的第一问是"我现在怎么把它装到我笔记本上？"第二问是"我能帮上什么？"几小时内项目就有了活动流、记忆、知识图谱和 agent 外壳的负责人。一周内，Agentic AI 副总裁 Swami Sivasubramanian 看到原型并全力支持；第二周有了软件开发经理和更多工程师，科学与工程接近五五开。团队刻意不快速扩张：每个加入的人都因特定技能被选中，且必须适应一种与整个组织运作方式完全不同的文化——你要拥有一个问题、自主交付，"你构建它，你拥有它"。
速度的另一个大驱动是：团队每个人都从第一天起把自己的产品当主要 AI 助手使用。Thomas 在按他想要的方式构建助手，不满意的就修；整个团队都这样运作——不留粗糙边缘给设计师后来打磨，也不为前端工程师在下一个 sprint 里处理而提 ticket；用的时候发现不对，你就拥有它、修好它。每次代码评审都附带一段体验视频，因为"隔离地看代码告诉你产品用起来是否舒服"——这是对以前"先基准测试、后琢磨体验"方式的有意反转：在满意体验之前不要基准测试任何东西。Kiro 开发的领导者 Clare Liguori 观察到：当构建原型只需几天而非几个月，先原型后写作就更合理了。
文章最后给出对 Working Backwards 的修订：当你对客户问题有信念、但对方法是否可行真正不确定时，先构建原型；然后像客户一样使用它；弄坏它、找出直觉漏掉的缺口；分享给几位同事；如果围绕你构建的东西有热情，再写文档。写作仍然一如既往重要，而且应该由你来写而不是你的 AI——写作迫使你清晰思考、直面逻辑缺口。改变的是：写作不再是让想法可触的唯一方式，编码 agent 压缩了"定义问题"与"手里有真实可评估的东西"之间的时间。基于构建产出的文档，优于基于假设的文档——因为它不再以你的假设为根基。你在构建中获得的共识是同事点击一个真实的东西，而不是读一份他们必须在脑中想象的文档。
阅读价值
适合技术管理者和产品团队：这篇文章是 AWS CTO 对"编码 agent 如何改变产品流程"的第一手反思——它没有否定两比萨团队与逆向工作法，而是提出"先原型后文档"的修订版流程，并给出 Amazon Quick 团队的真实案例（一夜原型、全员用自家产品、视频化代码评审）；对任何纠结"文档先行 vs 快速原型"的组织都有启发。
本文为中文精炼导读,由 AI 基于原文整理,内容与图片版权归原作者所有。原文: https://www.allthingsdistributed.com/2026/06/return-to-two-pizza-culture.html?utm_campaign=inbound&utm_source=rss