When I joined Amazon, Jeff had an idea: no team should be so large that it couldn’t be fed by two pizzas. In those early days, some teams were so small that one pizza would’ve been enough to get the job done. But it was never really about feeding hungry engineers. We could’ve just as easily said a “six sandwich team”, but sandwiches don’t evoke the same imagery as pizza. Pizza is what you order when you and your peers are crowded around the whiteboard late into the evening.当我加入亚马逊时，杰夫有一个想法：任何团队的规模都不应大到两个披萨无法喂饱的程度。在早期，有些团队规模很小，一个披萨就足以完成工作。但这从来不是为了喂饱饥饿的工程师。我们完全可以称之为“六个三明治团队”，但三明治无法像披萨那样唤起同样的意象。披萨是你和同事在深夜围着白板讨论时会点的食物。

We wanted to keep teams small enough so that everyone in the room knew what everyone else was working on, without requiring meetings. Each member of the team owned the product. You had the autonomy to make decisions with as little bureaucracy as possible. You were empowered to move fast, to experiment, and to not be afraid of failure. If the decision was reversible, you didn’t need permission to make it. You made it, you learned from it, and if it was wrong, you reversed it. The cost of a wrong reversible decision is almost always lower than the cost of making that decision slowly.我们希望保持团队规模足够小，这样房间里的每个人都知道其他人正在做什么，而无需开会。团队中的每个成员都拥有该产品。你有自主权在尽可能减少官僚主义的情况下做出决策。你有权快速行动、进行实验，并且不惧怕失败。如果决策是可逆的，你不需要获得许可就可以做出决定。你做出了决定，从中学习，如果错了，就将其撤销。做出错误的可逆决策的成本，几乎总是低于缓慢做出该决策的成本。

As our customer base grew, so did the number of our teams. When you go from three services to over two hundred, you do not get to keep the same organizational structure. It’s simple physics: as systems grow, so does their entropy. Each service requires owners, and owners need to coordinate with the teams whose services they depend on. Org structures become layered, dependencies multiply, and approval cycles appear where none existed before. Suddenly, a team that used to own a problem end-to-end now needs alignment across multiple teams before they write a single line of code. At some moment, the inertia of any growing company begins to work against the very culture that made it successful. This doesn’t necessarily mean the quality of the product will suffer, but unless you fight it, it means your speed of delivery will decrease.  随着我们的客户群增长，我们的团队数量也在增加。当你从三个服务扩展到两百多个服务时，你无法保持相同的组织结构。这很简单：随着系统的增长，其熵值也会增加。每个服务都需要所有者，而所有者需要与他们所依赖的服务团队进行协调。组织结构变得层级化，依赖关系成倍增加，审批周期在以前不存在的地方出现了。突然之间，一个曾经端到端负责某个问题的团队，现在在写一行代码之前，需要跨多个团队进行对齐。在某个时刻，任何成长中公司的惯性都会开始对抗使其成功的文化。这并不一定意味着产品质量会受损，但除非你与之抗争，否则这意味着你的交付速度将会下降。

Along with the two-pizza approach to manage team size, we used a unique approach to define our products—working backwards from the customer. I wrote about this back in 2006:除了用“两个披萨”的方法来管理团队规模外，我们还使用了一种独特的方法来定义我们的产品——从客户出发进行逆向工作（Working Backwards）。我曾在 2006 年写过关于这一点的内容：

The Working Backwards product definition process is all about fleshing out the concept and achieving clarity of thought about what we will ultimately go off and build. It typically has four steps:“逆向工作”产品定义流程的核心在于充实概念，并对我们最终要构建的内容达成清晰的思考。它通常有四个步骤：

1. Start by writing the Press Release首先撰写新闻稿
2. Write a Frequently Asked Questions document撰写常见问题解答文档
3. Define the customer experience定义客户体验
4. Write the user manual编写用户手册

We’ve achieved remarkable successes working backwards, and have solved real problems for millions of customers using feats of engineering that still amaze me to this day. Our teams are still sized around our two-pizza model. They still move fast and break things, but they wait until they have fully defined the problem and the entire business line clearly understands how they’ll solve it together.  我们在逆向工作方面取得了显著的成功，并利用至今仍令我惊叹的工程壮举为数百万客户解决了实际问题。我们的团队规模仍然围绕我们的“两个披萨”模型。他们仍然快速行动并勇于尝试，但他们会等到完全定义了问题，并且整个业务线都清楚地理解他们将如何共同解决该问题之后再行动。

But there’s a shift happening in our industry, and I keep hearing stories across Amazon that are challenging me to think a bit differently about the process of bringing products to life. If you look at the four steps above, what they have in common is deep thinking about the problem space, then writing about it. Getting the idea out of your head and onto paper is how you hone the idea. You poke holes in it, discover what you don’t know, and share it with your peers to arrive at a shared understanding of what will be built. It’s hard work to write a crisp document, and nearly impossible if you don’t have clarity of mind about the customer problem you want to solve. But there’s another very deliberate reason we use writing at Amazon: writing allows anyone to build a product because it doesn’t require you to know how to code. A product manager, a UI designer, a business analyst, anyone with a well-written idea and compelling argument could define what gets built next.但我们的行业正在发生转变，我不断在亚马逊听到一些故事，这些故事促使我以不同的方式思考将产品变为现实的过程。如果你看看上面的四个步骤，它们的共同点是对问题空间进行深入思考，然后将其写下来。将想法从脑海中提取出来并写在纸上，是打磨想法的过程。你会找出其中的漏洞，发现你不知道的事情，并与同事分享，从而对要构建的内容达成共识。撰写一份清晰的文档是一项艰苦的工作，如果你对想要解决的客户问题没有清晰的认识，这几乎是不可能的。但在亚马逊，我们使用写作还有另一个非常深思熟虑的原因：写作允许任何人构建产品，因为它不需要你懂得如何编码。产品经理、UI 设计师、业务分析师，任何拥有写得好的想法和令人信服的论点的人，都可以定义接下来要构建什么。

But what happens when anyone with an idea can sit down with a coding agent and produce a functional shell of a product in a single evening?但是，当任何有想法的人都可以与编码代理（coding agent）坐在一起，并在一个晚上就制作出产品的功能外壳时，会发生什么呢？

In late January 2026, a handful of our scientists were talking among each other and realized they’d all been thinking about the same problem space independently. How do you give an agent memory that persists? How do you let multiple agents coordinate without a central bottleneck? How do you keep humans in control while the system scales? They needed an operating system for agents. They decided to get into a room together for a few days and see what they could come up with.2026 年 1 月下旬，我们的一些科学家在交流时意识到，他们都在独立思考同一个问题空间。如何赋予代理持久的记忆？如何让多个代理在没有中心瓶颈的情况下进行协调？如何在系统扩展的同时保持人类的控制权？他们需要一个代理操作系统。他们决定聚在一个房间里几天，看看能想出什么办法。

Thomas Delteil, who is a principal scientist on our Amazon Quick team, had been concerned by the pace at which good ideas were dying. The cycle of proposing an idea, waiting for discussion, building a proof of concept, benchmarking it, seeking visibility for it, then waiting again for the next round of approvals was killing ideas before they ever reached a single customer. So when the conversation turned to what they could build if they stopped waiting for permission, Thomas spent the entire night using Kiro to build the first prototype of what would become Amazon Quick Desktop. When he demoed it the next day, the first question from the team was “how do I get this on my laptop right now?” and the second was “what can I help with?” Within hours of first seeing it, the project had an owner for the activity feed, an owner for memory, an owner for the knowledge graph, and an owner for the agentic harness.Thomas Delteil 是我们 Amazon Quick 团队的首席科学家，他一直担心好想法消亡的速度。提出想法、等待讨论、构建概念验证、进行基准测试、寻求可见性，然后再次等待下一轮审批的周期，在想法触达任何客户之前就已经将其扼杀了。因此，当谈话转向如果不再等待许可他们能构建什么时，Thomas 整晚都在使用 Kiro 构建后来成为 Amazon Quick Desktop 的第一个原型。当他在第二天演示时，团队的第一个问题是“我现在怎么才能把它装到我的笔记本电脑上？”，第二个问题是“我能帮上什么忙？”在首次看到该项目的几个小时内，它就有了活动流的所有者、内存的所有者、知识图谱的所有者以及代理框架的所有者。

Within a week, Swami Sivasubramanian, our VP of Agentic AI, saw the prototype and gave the team his full support. Three engineers joined. By the second week, they had a software development manager and a few more engineers, reaching a roughly even split between science and engineering. They were deliberate about not scaling too fast. Each person who was brought on was selected because they had a specific skill, and they had to adapt to a culture that was a complete departure from how the broader organization operated. They were expected to own a problem and deliver with autonomy, and ownership meant the same thing it has always meant at Amazon: you build it, you own it. 一周之内，我们的代理 AI 副总裁 Swami Sivasubramanian 看到了原型并给予了团队全力支持。三名工程师加入了进来。到第二周，他们有了一名软件开发经理和更多的工程师，科学和工程人员的比例大致相当。他们刻意不进行过快扩展。每个被引入的人都是因为拥有特定的技能而被选中，并且他们必须适应一种与更广泛组织运作方式完全不同的文化。他们被期望拥有一个问题并自主交付，而“拥有（ownership）”在亚马逊一直意味着同样的事情：你构建它，你拥有它。

Leo Ohannesian, the product manager recruited to join the Quick team five days into the effort, had spent years working in organizations that started with a PRFAQ, would go through review cycles, secure funding, assign owners, and set timelines. On this early team, there was none of that. Switching to a model where a small group of senior people were fully trusted to make the right decisions produced a velocity he’d never experienced in his career.Leo Ohannesian 是在项目开始五天后被招募加入 Quick 团队的产品经理，他曾在那些从 PRFAQ（新闻稿与常见问题解答）开始、经历审查周期、获得资金、分配所有者并设定时间表的组织中工作多年。在这个早期团队中，这些统统没有。切换到一个由一小群资深人士完全信任并做出正确决策的模型，产生了他在职业生涯中从未体验过的速度。

A big driver of what made this pace possible was that every person on the team used the product as their primary AI assistant from day one. Thomas was building it the way he wanted an assistant to be, and anything he didn’t like, he fixed. Everyone on the team operated the same way. They didn’t leave rough edges for a designer to smooth out later or file a ticket for a frontend engineer to pick up in the next sprint. If you noticed something was wrong while you were using it, you owned it, and you fixed it. Every code review came with a video of the experience because reviewing the code in isolation tells you nothing about whether the product feels right to use. This was a deliberate inversion of how the team had worked before, where you’d benchmark first and figure out the experience later. Here, the rule was: don’t benchmark anything until you’re happy with the experience you have.这种速度之所以成为可能，一个很大的驱动力是团队中的每个人从第一天起就将该产品作为他们的主要 AI 助手使用。Thomas 正按照他希望助手成为的样子来构建它，任何他不喜欢的，他都会修复。团队中的每个人都以同样的方式操作。他们不会留下粗糙的边缘让设计师以后去修补，也不会提交工单让前端工程师在下一个冲刺阶段去处理。如果你在使用过程中发现有问题，你就会负责并修复它。每个代码审查都附带一段体验视频，因为孤立地审查代码并不能告诉你产品使用起来感觉是否正确。这是对团队以前工作方式的一种刻意颠倒，以前是先进行基准测试，以后再弄清楚体验。在这里，规则是：在你对所拥有的体验感到满意之前，不要对任何东西进行基准测试。

Clare Liguori, a senior principal engineer who led the development of Kiro, spoke about her experience at my re:Invent keynote last year and recently wrote about this same pattern. Her observation is that when building a prototype takes days, not months, it makes more sense to prototype before writing. Her team started using their IDE full-time from the moment the first prototype worked, and evolved it daily based on what they actually needed.Clare Liguori 是一位领导 Kiro 开发的资深首席工程师，她在去年我的 re:Invent 主题演讲中谈到了她的经历，最近也写到了同样的模式。她的观察是，当构建原型需要几天而不是几个月时，在写作之前进行原型设计更有意义。她的团队从第一个原型工作的那一刻起就开始全职使用他们的 IDE，并根据他们实际需要的内容每天进行演进。

Writing is still as important as ever, and it should be you doing the writing, not your AI. Writing forces you to think clearly and confront gaps in your logic. What has changed is that writing is no longer the only way to make an idea tangible. Coding agents are compressing the time between defining the problem and having something real in our hands to evaluate. It is time to amend the way we think about the process that’s brought us this far. You will learn more in one evening of building than in two weeks of writing about what you think will happen. Only after you’ve spent time with the prototype, used it the way a customer would, and developed a real understanding of what it can and cannot do, do you begin the writing process. The document you produce after building is fundamentally better than the one you would have written before, because it’s no longer grounded in your assumptions. 写作仍然像以往一样重要，而且应该是你自己在写，而不是你的 AI。写作迫使你清晰地思考并面对逻辑中的空白。改变的是，写作不再是使想法具体化的唯一途径。编码代理正在压缩定义问题与手头有实际东西可供评估之间的时间。是时候修改我们对这一路走来的流程的看法了。你在一个晚上的构建中学到的东西，比花两周时间写下你认为会发生什么学到的更多。只有在你花时间使用原型、像客户一样使用它，并真正理解它能做什么和不能做什么之后，你才开始写作过程。你在构建之后生成的文档从根本上优于你在之前写的文档，因为它不再基于你的假设。

So how do we amend Working Backwards? When you have conviction about the customer problem but have genuine uncertainty about whether your approach will work, you start by building a prototype. Then you use it the way a customer would. You break things, you find the gaps your intuition missed, then you share it with a few colleagues, and if there’s excitement around what you’ve built, you write the doc. Having something tangible to click through as you write changes the quality of the document. You’re no longer describing something you’ve only imagined in your head. You’re describing something that now exists and has been pressure-tested, and your writing will reflect that.那么我们如何修改“逆向工作”流程呢？当你对客户问题有确信，但对你的方法是否有效有真正的疑虑时，你从构建原型开始。然后像客户一样使用它。你打破东西，发现直觉遗漏的空白，然后与几位同事分享，如果大家对你构建的东西感到兴奋，你就写文档。在写作时拥有可以点击的实物会改变文档的质量。你不再是在描述你脑海中想象的东西。你是在描述一个现在已经存在并经过压力测试的东西，你的写作将反映这一点。

The Quick Desktop team is no longer a handful of people in a conference room. They’ve grown to several hundred engineers, scientists, designers, and product managers. That is the natural trajectory of a product that hundreds of thousands of people now use every day. Every team that grows past a certain threshold faces the same gravitational pull toward the overhead I described earlier. The way you fight that is allowing your teams the freedom to operate as a collection of two-pizza teams, each with clear ownership and the autonomy to make reversible decisions without asking permission. You fight it by keeping the feedback loop short: build, use, learn, iterate. You fight it by hiring people who are uncomfortable when they don’t own their problem end-to-end, and by giving them the tools to act on that discomfort. Quick Desktop 团队不再是会议室里的几个人。他们已经发展到数百名工程师、科学家、设计师和产品经理。这就是现在每天有数十万人使用的产品的自然轨迹。每个超过一定阈值的团队都会面临同样的引力，即我之前描述的开销。对抗它的方法是允许你的团队自由地作为“两个披萨”团队的集合来运作，每个团队都有明确的所有权和在不请求许可的情况下做出可逆决策的自主权。你通过缩短反馈循环来对抗它：构建、使用、学习、迭代。你通过雇佣那些在不能端到端拥有问题时会感到不舒服的人，并为他们提供应对这种不适的工具来对抗它。

Two pizzas were always about ownership culture, and the tools have caught up to the culture. What made the Quick Desktop team successful is the same thing that has always produced the best work I’ve seen at Amazon: a small group of people who trusted each other, owned the problem end to end, and acted on their conviction.“两个披萨”始终关乎所有权文化，而工具已经跟上了文化的发展。使 Quick Desktop 团队成功的原因，与我在亚马逊见过的产生最好工作成果的原因相同：一小群彼此信任、端到端拥有问题并根据信念采取行动的人。

Now, go build!现在，去构建吧！