不要 Tokenmaxing，要 Interruption Minimizing

Part 1 — Tokenmaxing 的问题

Tokenmaxing 不是完全没有道理。

在 AI 发展的早期，团队确实需要先把 AI 用起来。你不大量使用，就不知道 agent 能做什么；你不把任务交给模型，就不知道新的工作流边界在哪里。

所以最开始，鼓励大家多用 AI 是对的。

问题是，一旦 token 消耗变成 KPI，它就开始失真。

Uber 的案例很典型。公开报道里提到，Uber 在 2026 年前几个月就用完了全年 AI 预算，很大一部分来自 Claude Code 这类 coding agent 的快速普及。更关键的是，管理层后来也开始质疑：token 用量上升，并没有清楚对应到更多用户可见的产品改进。

工程团队很兴奋，agent 跑了很多，账单增长很快，但最后沉淀下来的产品价值，不一定成比例增长。

这就是 tokenmaxing 的核心问题：它把“AI 很忙”误认为“组织更有效率”。

token 本质上只是消耗，不是产出。它可能对应一次高质量的代码重构，也可能对应十轮没必要的上下文重复；可能对应一个真正减少人工的自动化流程，也可能对应一堆没人会读的总结、计划和中间稿。

只看 token，就像只看键盘敲击次数来判断工程师生产力。数字很热闹，但意义很可疑。

不过，完全否定 token 指标也不对。它之所以会流行，是因为背后有一个合理类比：在成熟工业体系里，用电量确实可以在一定程度上反映生产活跃度。

一个地区工业用电上升，往往意味着机器在运转、工厂在生产、物流在流动。电力不是最终产品，但在稳定、成熟、可计量的生产系统里，它可以成为生产强度的代理指标。

token 未来也可能类似。等 AI 工作流足够成熟，任务定义、质量评估、成本归因、自动化闭环都稳定下来以后，token 消耗也许可以成为某种生产活跃度指标。

但今天还不是。现在的大多数 AI 系统仍然处在试验期。流程不稳定，评估不稳定，成本结构不稳定，输出质量也不稳定。在这种情况下，token 消耗更像实验室里的试剂消耗，而不是工厂里的用电量。

它能说明你在试，但不能说明你在生产。它能说明系统在运行，但不能说明人被解放了。

Part 2 — 要 Interruption Minimizing

真正应该优化的，是 interruption minimizing：把人类被迫介入系统运行的次数降到最低。

这里不是说把人从公司里拿掉，也不是幻想所有事情立刻无人化。它指的是减少低价值的 interruptions：补上下文、确认显而易见的信息、搬运数据、检查半成品、在不同工具之间做人工胶水。

随着 AI 和 agent 能力变强，一个变化会越来越明显：人的介入本身会变成瓶颈。

过去我们说，人和人之间的沟通是瓶颈。一个事情要推进，需要开会、对齐、写文档、等回复、找负责人。现在 agent 变强以后，新的瓶颈会出现：人和 agent 的沟通也会变成瓶颈。

不是因为人不重要，而是因为每一次系统停下来问人，都会打断自动化的连续性。

理想情况下，一个 AI Native 系统应该以 100% 自动化运营为目标。这个目标不一定马上达到，但它应该是系统设计的北极星。

系统应该默认自己读取上下文、判断状态、调用工具、推进任务、验证结果。只有在真正关键、不可逆、涉及价值判断或责任归属的节点，才把问题交还给人。

这就需要把人的价值和系统的价值分开。

系统的价值，是稳定地运行，是吸收信息、处理任务、执行流程、反馈状态。人的价值，不是反复告诉系统“刚才发生了什么”，也不是帮系统复制粘贴，而是判断方向、设定标准、做关键取舍、承担最终责任。

人和系统的沟通，应该主要发生在两个位置。

第一个位置，是输入端。不要先纠结 prompt 怎么写得更漂亮，也不要只把注意力放在 instruction engineering 上。更重要的是，把公司里所有正在发生的事情变成 AI-readable。

会议、销售通话、客服记录、代码变更、产品反馈、内部文档、决策历史、运营数据，都应该尽可能被记录、结构化、进入知识库，成为系统可以自动读取的输入。

好的系统不应该老是问人“背景是什么”。背景应该已经在那里。

第二个位置，是输出端。系统不应该把所有中间过程都丢给人看，也不应该每走一步就请人确认。它应该在大量自动处理之后，只把最 critical 的输出交给人。

这个客户要不要特殊处理。这个产品方向要不要调整。这个风险要不要接受。这个方案要不要进入执行。

中间当然仍然需要人设计系统。流程怎么定义，权限怎么划分，质量怎么评估，什么节点必须升级给人，这些都需要人的判断。但系统设计的目的，不是让人永远站在系统旁边操作它，而是设计好之后，系统能够尽可能自行运转。

Part 3 — 重新定义人的位置

Interruption minimizing 绝对不是在说“人不重要了”。

恰恰相反，它是在 AI 能力越来越强之后，重新区分人和系统各自应该负责什么。

过去很多 AI 产品喜欢讲 human-in-the-loop，好像只要每个关键环节都有人看一眼，系统就更安全、更可靠。但当 agent 可以连续执行几十步、几百步任务时，人在 loop 里会越来越吃不消。

人类不适合永远站在高速系统的中间。

未来最好的黑客松，可能也应该是这样：大家先把想法、目标和判断标准讲清楚，然后全程尽量不要人参与，过一段时间直接比拼结果，而不是让人在中间操作太多环节。

每一步都让人确认，每个中间结果都让人阅读，每次不确定都把问题抛回给人，这在早期可能是必要的安全机制，但它不可能成为长期的工作方式。AI 的速度越快，人的注意力就越稀缺。到最后，人不是在控制系统，而是在被系统不断打断。

所以 interruption minimizing 的真正目的，不是减少人的价值，而是让人逐步从 AI 已经能够掌握的工作里脱离出来。

那些可以被系统读取、判断、执行、验证的工作，应该尽可能交给系统。人不应该反复做机器已经能做的上下文整理、信息搬运、初步分析、格式转换、状态同步和流程推进。

人的注意力应该被释放出来，放在 AI 还不能真正承担的事情上。

比如，和客户建立信任。比如，理解复杂关系里的真实动机。比如，在不确定条件下做取舍。比如，判断什么值得做，什么不值得做。比如，为一个决策承担责任。

这些事情不是 token 吞吐量可以直接替代的。AI 可以提供信息、建议、模拟和执行能力，但信任、责任、品味、战略判断，仍然需要人来承担。

这件事当然不会一蹴而就。真正的过程一定是逐步发生的：先把信息变成 AI-accessible，再把流程变成 AI-executable，再把反馈变成 AI-readable，最后才有可能让系统在大多数情况下自行运转，只在最关键的节点升级给人。

也正因为它是一个逐步成熟的过程，所以我们需要新的指标。

比起问“我们消耗了多少 token”，更应该问 IPB：Interruptions Per Billion Tokens，也就是每 10 亿 token 需要多少次 interruption。

IPB 可以作为 AI Native 系统成熟度的一个粗略指标。IPB 越低，说明系统越能自己吸收信息、推进任务和处理异常，人越少被打断。

大概可以分五个阶段：IPB 在 3000 以上，基本还是人在操作 AI；1000 到 3000，是熟练工具用户，但人仍然频繁介入；300 到 1000，开始进入异步委托和批量 agent 工作流；50 到 300，说明系统已经有任务状态、自动 retry 和自动验证；如果能低于 50，才比较接近成熟的 AI Native 系统。低于 5，则更像 AI factory，大家把目标讲清楚，系统自己全程运行，最后直接比结果。

这有点像自动驾驶里的 L5。L5 自动驾驶不是说人类不会出行了，而是说人在正常情况下不需要接管方向盘。人仍然决定去哪、为什么去、什么时候去，但具体驾驶过程由系统完成。

成熟的 AI 系统也应该类似：人决定目标、边界、责任和关键取舍，系统负责高速运行、持续处理、自动执行。

最终理想的状态，不是人被 AI 替代，也不是人被 AI 淹没，而是人用一种更轻、更清醒的方式工作。

人专注于 critical work。AI 系统全速运行。高 token 吞吐量转化成真实智能产出。低 interruption rate 让人不再被系统反复拖回低价值细节。

这才是 AI 时代真正值得追求的组织形态：不是更会烧 token 的公司，而是更少 interruption、更能释放人的公司。