一个问错了的问题
前面十章把「要不要层级」的两个答案都拆了。「不要」派省下了线性的工资，付出了平方级的协调和一张以增长为抵押的账单；「要」派赢得了结构，常常输掉速度和官僚的泥潭。吵了一百年的架，很可能从一开始就问错了。
「要不要层级」预设层级是一个形式——一张组织架构图，一顶头衔，一层办公室。但第二章的解剖已经告诉我们，层级是一组功能：压缩、翻译、缓冲。形式可以删，功能删不掉。删掉形式的后果，第七章也演过一遍：功能转入地下，变成没有问责的影子层级。
所以正确的问题不是「要不要层级」，而是：压缩、翻译、缓冲这三件活，由谁干、以什么形式干、怎么让干活的人被问责？组织架构图只是这个问题的一个答案，不是唯一答案，更不该是问题的本身。
好层级的三条设计原则
如果把层级当成一件工程品而不是一种意识形态，设计目标就清楚了：用最小剂量的层级，覆盖三件活的工作量，同时保留扁平的全部好处。具体是三条原则。
第一条：层数按功能算，不按面子算。一个组织需要几层，取决于一件事：上一层能不能吃下下一层的信息量。管理幅度 5 到 10 是人脑的物理限制，AI 把压缩成本打下来之后幅度可以变大（第八章），但缓冲和背书的负载没变。所以「几层」的答案应该像算服务器配置一样算出来：多少人、多少信息流、多少跨团队接口，推导出需要多少压缩节点——而不是照抄别的公司的架构图，也不是为了「显得扁平」硬砍一层。
第二条：权力必须可见、可问责、可更换。这是从弗里曼的檄文里直接长出来的原则。层级最坏的不是存在，是隐形。所以哪怕组织名义上扁平，也必须把实际权力画出来：谁对什么决定负责，白纸黑字，全员可查。亚马逊的做法是一个好例子——它不搞扁平化的名头，但要求每个团队小到「两张披萨能喂饱」，并且每个团队有明确的单一负责人和可度量的目标。层级被缩小、被透明化、被职责化，而不是被否认。
第三条：结构要可逆。贝索斯有个著名的区分：决策分「单向门」和「双向门」——单向门穿过去回不来，要慎重；双向门走错了可以退回来，要快速试错。组织结构调整大多是双向门：新设一个层级、合并两个团队，试了不行可以改回来。把「要不要经理」当成一次性的意识形态宣誓（Zappos 式），就是把双向门焊死成单向门。聪明的做法是当软件发版：小步快跑，观察指标，随时回滚。
大白话：别问「我们公司要不要层级」这种信仰问题。问三件活各要多少人手、权力画没画出来、这次调整能不能回滚——这是三个工程问题。
一个比「扁平 vs 科层」更好的光谱
放弃二维的站队之后，真正的设计空间其实是一维的：功能的分布方式。
光谱的一端，三件活全部集中在专职经理身上——传统科层。另一端，三件活全部摊给每个人自己干——教科书式扁平。但中间地带大得很：压缩交给 AI（第八章），翻译交给轮值的资深工程师，缓冲留给少数专职的「对人的负责人」；或者像戈尔那样，用 150 人的物理分裂把三件活的工作量在源头就切小（第六章）；或者像晨星那样，用书面合同把协调显式化（第九章）。
每一种都是「层级」，只是形态不同。它们的共同点是诚实地回答了三件活由谁干；它们的失败案例的共同点，是假装这三件活不存在。
AI 时代真正的组织问题
站在这个框架里回头看 AI 公司的扁平化，它既不是革命也不是笑话，而是一次剂量问题被当成了方向问题。AI 把压缩成本打下来，最优层数确实变少了——这是真红利，值得拿。但从「层数变少」到「层级归零」之间隔着缓冲和背书这两件 AI 接不住的活，跨过去的那一步不是技术进步，是信仰跳跃。
那么这场弯路——如果它真是弯路——白走了吗？最后一章，给它一个公道。