第七章给了待审队列一个硬上限：两三份。很多人（包括我）听到这个的第一反应是不安：就留这么点？万一呢？这一章专门对付这个「万一」——把库存的伪装一层层剥掉，看看它到底是个什么东西。
库存的第一张脸：安全感
人为什么爱囤待办？因为队列长看起来「手里有粮」。37 份待审稿子躺在那里，感觉上像 37 个可能性、37 条退路。
但请注意一个关键区别：库存不是产出，是产出的承诺。承诺要兑现，必须穿过瓶颈。你的瓶颈一晚一份，37 份承诺就是 37 个晚上——五个多星期。承诺排到五周之后，它给你的就不是安全感，而是两笔暗账：
暗账一：它掩盖问题。高德拉特有个说法：库存像河里的水，问题是河底的石头。水位高的时候，船开得很稳，你看不见任何石头——生成质量在下降？prompt 模板有问题？选题方向跑偏了？全都被厚厚的「待审」盖着，因为你总在审三周前生成的东西，反馈环路慢到失真。水位降下来，石头露出来，船才会真的开得更好。
暗账二：它拖慢一切。排队论里有个朴素又残酷的结果：队列里的平均等待时间，和队列长度成正比。队列 37 份时，一份新生成的稿子要等 37 个晚上才被审；等审到时，上下文全忘光了（第四章的「保鲜期折旧」），审出「不行，重做」的反馈时，你早已忘了当时怎么写的 prompt——返工成本翻倍。队列 3 份时，反馈三天内闭环，每一次生成都在吸收上一次审核的教训。短队列不只是让人舒服，它直接提高学习速度。
波动：为什么队列不能是零，但只能是「一点点」
那为什么不干脆不留缓冲，做一份审一份？因为第二章远足队伍里那条规律：波动会积累。
你的流水线每一步都有随机性：今晚临时加班，审核空转一次；某份稿子生成质量崩了，要回炉；AI 服务偶尔抽风。如果缓冲是零，任何一次小波动都会直接砸在瓶颈上——瓶颈一旦空转，那一晚的产能永远损失，补不回来（你不能在后天晚上审两份今天的稿，注意力不存银行）。
所以缓冲要存在，但它的尺寸由「吸收波动」决定，不由「万一我想多读几份呢」决定。两三份，恰好是吸收常见波动、又小到反馈环路不失真的量。缓冲是保险丝，不是粮仓。
焦虑的机械结构：不是你想太多，是队列真的在压你
这一章还想给「看到待审 37 就烦」一个公道：那不是心理素质差，是排队规律的体感版本。
长队列通过三条机械通道制造压力：
- 完成遥遥无期。37 份 ÷ 每晚 1 份 = 37 晚，大脑一算这个账，直接判定「不可能完成」，启动回避（不想打开文件夹）；
- 选择瘫痪。今晚审哪份？选项从 3 个变 37 个，光做「选哪个」这个决定就消耗了一波本应用于审核的专注力；
- 每一份都在贬值。你清楚它们放越久越陌生，于是每拖一天，隐性损失都在涨——「亏着」的感觉本身就是压力源。
而队列压到 3 份之后，同一个大脑的计算是：今晚一份，三天清零，搞定。焦虑不药而愈——因为制造焦虑的机械结构被拆掉了。
大白话：待办清单不是用来证明你有多少事可做的，是用来喂瓶颈的。喂过量了，先撑死的是你自己。
去库存：那 37 份已经堆出来的怎么办
道理都通了，可库存是既成事实。TOC 的去库存原则同样反直觉：先关上游的水龙头，再处理水池，而且处理水池的默认动作是扔。
具体三步。一，生成端立即冻结，一份新的都不生成。二，用第六章的验收清单做一轮快速分拣：每份稿子只给 10 分钟，只答「四条标准过几条」，明显不过的当场删——删的不是稿子，是已经收了一个月租金的负债。三，剩下的少数几份按「保鲜度」排序，最新鲜的先审（上下文还活着、返工成本最低），排到三周以后的，承认自己永远不会审，删掉。
舍不得删？问自己一个工厂经理常问的问题：这份库存如果现在不存在，我会花钱（一个晚上）重新把它造出来吗？不会的话，它现在的价值就是零，删了无损失——你删掉的只是「以为它有价值的错觉」。
库存清完，节奏立稳，挖尽和迁就都到位了。如果产出还是不够——下一章，终于轮到花钱的那一步：打破瓶颈。