承认「我有瓶颈」很容易，难的是承认瓶颈在哪。因为它几乎总是你心里最不愿意是瓶颈的那个东西——在罗哥的工厂里，瓶颈是一台老旧但关键的机床；在我的书桌上，瓶颈是我自己。
先画你的流水线
找瓶颈之前，得先有一张地图。拿「用 AI 做电子书」这件事来说，一件成品要流过这些环节：
- 想：决定做什么主题、什么角度；
- 喂：写 prompt、准备素材；
- 生成：AI 跑任务（消耗 token）；
- 审：读结果，判断好坏，决定留、改还是扔；
- 发：整理成可交付的形态，发布出去。
现在给每个环节标上「单位时间产能」。生成环节：一晚上三亿 token，几十份书稿。发布环节：点几下鼠标，快得很。想主题：一小时能想十个。写 prompt：一个熟练的人十分钟一个。
剩下那个「审」呢？认真读一份五万字的书稿、做出判断，按两小时算——一个晚上审一份，还得是状态好的晚上。
不用算了。瓶颈是「审」，而且比第二名慢出一到两个数量级。管子粗细差成这样，地图都不用画完，答案已经糊在脸上。
三个验证：别凭感觉认瓶颈
但凭感觉认瓶颈是危险的——你会倾向认领那个「看起来最忙」的环节。TOC 给了几个更硬的判据，一一对照：
第一，看谁面前堆着库存。瓶颈的定义性特征，是上游的产出在它面前排队。我的任务栏里，排队的几十份书稿全部卡在「待审核」状态——没有一份卡在「待生成」。工厂里找瓶颈，老师傅有个土办法：看哪台机器前面在制品堆得最高。一模一样。
第二，看谁的时间最值钱。瓶颈的一小时，是整个系统的一小时；非瓶颈的一小时，什么都不是。如果生成端歇一晚上，我只是少了几份待审稿，系统产出不变（反正也审不过来）；如果我（审核）歇一晚上，系统产出直接归零。让整个系统停转的环节，就是瓶颈。
第三，看你在焦虑什么。这是一条不那么正式但异常准的线索：系统会逼着所有人围着瓶颈转。我那周的真实状态是——看到「待审核 37」的数字就烦，周末计划全被打乱，满脑子都是「这么多怎么看得完」。我的焦虑精确地指向了瓶颈的位置。系统早就知道答案，只是我还没听懂。
为什么瓶颈几乎总是「判断」而不是「生成」
把镜头拉远一点，这不只是我个人的毛病，是这个时代的结构性事实。
过去几百年，技术一直在降低「生成」的成本：印刷术降低了复制的成本，互联网降低了分发的成本，生成式 AI 把「从 0 到初稿」的成本打到接近零。但链条的另一头——读、理解、判断、决定——依然由一个碳基生物用平均每分钟几百字的速度完成，几千年来几乎没有升级过。
所以只要你的系统里同时有「AI 生成」和「人来把关」两个环节，瓶颈的位置就是确定的，像水往低处流一样确定。变化的不是瓶颈在哪，而是它暴露得越来越刺眼：以前写一本书要三个月，审核占用的时间藏在写作的时间里，不显；现在生成只要一晚，审核那两周就赤裸裸地横在那儿。
大白话：以前是水管各节差不多粗，大家凑合着流；现在有一节忽然换成了消防栓，其他节还是吸管——喷得到处都是的水，就是你的待办列表。
一个陷阱：瓶颈不是「最忙的」，是「最决定产出的」
最后纠正一个容易犯的错。有人会说：我瓶颈明明是「想主题」啊，我憋一晚上想不出一个好点子。注意区分长期瓶颈和眼前的堵塞：如果你任务栏里已经有 37 份书稿在排队，那么此刻系统的产出完全由审核速度决定，「想主题」环节就算停摆一个月也不影响产出。它可能是下个月的新瓶颈——这正是第十章要讲的事——但它不是现在该管的。
TOC 有一条冷峻的纪律：一次只认一个瓶颈，只对它采取行动。多线作战等于没有作战。
现在瓶颈认了：是我的审核时间。下一章先看清楚，如果不认它、继续让生成端撒欢跑，代价到底是什么——会比「浪费」难看得多。