三个月，一场必然失败的Tokenmaxxing

生成式AI爆发三年半后，市场进入新的分歧点：乐观仍在加速，怀疑也在累积。判断“泡沫”是否到来，并不足以解释当下的复杂性。“AI信仰与泡沫”系列将从市场、技术、产业和公司的不同视角，寻找关键变量。本文为《AI信仰与泡沫》系列第五篇。

早在3月20日，纽约时报的凯文·罗斯就发现了在硅谷开发者中，出现了一种叫做 Tokenmaxxing的现象。

这个现象最早出现在OpenAI、Anthropic等前沿模型开发公司。OpenAI 的工程师一周用了 2100 亿个token，大概是 33 个维基百科的量；Claude Code 的工程师则一个月单人可以烧15万美元token。

这之后，程序员在X上掀起了比拼token用量的各种比较，他们以此证明自己有能力利用Claude Code等AI编程工具提升工作效率，并且更重要的是，能够掌握多线程并行工作的能力。唯有如此，才有可能在正常使用的情况下达到每天数亿的token消耗。

tokenmaxxing（token利用最大化）在这个过程中逐步被扭曲为一种「表明AI超级个体身份」的标识物，token使用越多，则使用者对AI的掌握越好，效率越高。

但早期能够承担这一token用量账单的基本上都是前沿模型公司研发和AI领域创业团队。只有他们，会有公司默认的不设限token使用额度。

进入到四月，tokenmaxxing的概念被互联网公司广泛接纳。黄仁勋在GTC上发言称，「如果一名年薪50万美元的工程师，在AI词元上的支出低于25万美元，那将令人非常担忧。」Y Combinator CEO Garry Tan则称 「我们tokenmaxxing的时间比大多数人都长。」 Meta内部甚至一度流传「token使用量可能影响裁员决策」的说法。

由这些前沿公司的领导者背书，tokenmaxxing开始渗透进整个互联网产业。不止科技公司，流媒体巨头迪士尼、支付公司Visa也加入Tokenmaxxing行列，国内也有阿里、腾讯、字节等大厂逐步将token使用额度连同内部AI Coding相关工具提供给广泛员工。

但仅仅不到两个月后，早先的使用者 Amazon、Uber  一个下线榜单，一个开始质疑 ROI。

按《金融时报》5 月 29 日报道，亚马逊关闭了内部 AI 使用排行榜 Kirorank。这套榜单原本想鼓励员工多用 AI，结果一些员工为了提高排名，让 AI agent 去执行没有实际价值的任务，单纯把 token 消耗量刷上去。亚马逊高级副总裁 Dave Treadwell 后来提醒员工，不要为了用 AI 而用 AI。

5 月，Ube COO Andrew Macdonald 在播客里谈到，公司看不到 token 消耗和「更多有用的消费者功能」之间的直接对应关系。据报道，Uber 在去年底部署了 Claude Code，95% 的工程师每个月都在用，70% 的提交代码来自 AI。每个工程师每月的 API 调用费在 500 到 2000 美元之间，结果到 2026 年 4 月就已经烧光了全年 Claude Code 预算。

微软也在同一时期踩了刹车。据 The Verge 报道，微软计划在 6 月底前取消 Experiences + Devices 部门大部分 Claude Code 内部授权，要求工程师迁回自家的 GitHub Copilot CLI。狙分析，这主要是基于 token 的规模化账单开始难以控制。

行业开始探讨token效率的口径，百度在5月提出DAA，日活智能体数取代token，作为衡量AI在员工中有效使用的量度。别看 AI 烧了多少 token，要看每天有多少 Agent 真正在干活。这只是下了一层，与token用量大差不差。

Devin选择了「节省人类工时」而非token，作为衡量AI 输出效率的标的。Uber开始试图把token和ROI挂钩，提出要看「有用功能交付量」，而非单纯token用量。Amazon 则把北极星指标还原到「客户/业务问题解决数」。

但具体token消耗如何和这些很传统的目标挂钩，试错和构建成本的容忍度如何，一个可以自动化批量生产的工作流，是否应该算作单个功能交付，还是应该算作某种基础设施？这些问题这些新指标统统难以回答。

直到6月14日，微软CEO Nadella（纳德拉）提出「Token资本」概念，认为token使用的目的应该变成「企业自己拥有的 AI 能力资产」，也就是说沉淀出与AI适配的工作流、私有评测、组织记忆、反馈闭环、可迁移到不同模型上的企业知识。在一定程度上回应了上述的疑问。在他看来，可沉淀，可复用的公司级AI Harness 和可被AI使用的知识网络，才是AI时代效率的体现。人的判断、经验、关系、创造力能够被 AI 系统化沉淀才是关键。

但这个提法依然不是无懈可击。纳德拉提出的，正是当下Harness演进中的重要方向。因此，他实际上是把一个工程上正在被 harness 自动化掉的过程，重新命名成了一个企业战略资产。在未来的Harness中，理想状态下，用户只是在正常工作，但系统后台会自动沉淀组织知识、任务轨迹、评测信号和改进循环。

所以到那时，他说的就和tokenmaxxing没啥区别了。只要不是员工在瞎用，token积累必然导致AI系统的沉淀。

因此，他的叙事更可以被理解成，不要只买最强模型，要在 Azure/Copilot/agent platform 上搭自己的企业学习系统。它更多的是对模型厂商凭借Harness进军云业务的一种反向发声。

但不论如何，截止到六月，基本所有之前无上限投入Tokenmaxxing的公司，都已偃旗息鼓，调整方案。

第一场，在资本市场之外的应用层AI Hype，在3个月内终结。

至于为何如此，综合当下的研究和报告，我们可以整理出三个主要原因。

01

用不起的Agent

Tokenmaxxing之所以无法持续，其直接原因就是太贵了，太烧钱了。

这背后有三个原因。

一是前沿模型公司要IPO，原来的账本太难看。

根据Epoch AI在2026年1月的推算，如果从收入中扣除计算成本来计算毛利润率（按会计口径），约为 30%，总销售额60亿美元，利润约计20亿美元，减去营销、行政后接近打平，还有得分给微软的收入，最后净利润很可能是负的。

而且这里还根本没算研发成本，据他们估计，GPT 5的研发成本高达50亿美元。模型四个月的生命周期根本不太可能能盈利，而且亏的很不好看。

这还是在模型两个月一更新的节奏之前。现在的模型开发虽然有自动化流程的成本压缩，但生命周期更短了。

到了今年，OpenIAI和Anthropic IPO的压力之下，新模型的定价都有提升。Claude 系列虽然相对没有提升价格，但tokenizer的改变造成了实际上的价格提升。

二是订阅制被重度用户打穿，导致token实际价格大幅上升。（详见趋势token价格分层加剧）

由于Openclaw的出现，订阅制用户中原来可以作为平衡用量的一般办公用户的token消耗量也开始飙升，自动化 agent 可以长时间、并行、循环消耗推理资源，远远超出之前人类聊天式订阅的成本模型。这使得原始订阅模式相对于API开始大幅亏损。因此，2026 年 4 月 4 日前后 Anthropic 调整了订阅策略，Claude 订阅额度不再覆盖 OpenClaw 这类第三方 Agent 工具。用户如果还想接入，就要购买额外的用量包，或改用单独的 API key。同期，Claude 还出现过峰时更严格限额、测试限制低级订阅访问 Claude Code 的消息。Google Gemini 也在这段时间内，跟风把订阅额度计算模式从固定 prompt 数改成计算量。在用户反弹后又承诺单个 prompt 消耗封顶、失败请求不计入，但方向仍是按复杂度计量。

这些变化说明，厂商正在把原本藏在包月订阅里的高强度推理成本拆出来，让 agent、长上下文、复杂 coding task 按真实消耗付费。订阅制的无限感已经撑不下去了。

三是Agent本身的总 token消耗在Harness加持下攀升，而且低效的令人发指。

这第二种原因在谷歌和微软4月共同主导的论文《AI Agent是怎么烧你钱的？》（arXiv 2604.22750）里被清楚的得到解析，它研究了Claude Code、Cursor、Codex 这类 agentic coding 任务的 token 消耗。根据他们的测算，Agentic coding 的 token 消耗是普通代码问答和代码推理任务的约 1000 倍。

而且成本主要不是输出的 token，而是输入的 token。所以说，在Agent系统里，钱大多花在模型反复读了多少上下文上，输出的代码其实占很小的比重。

它把Agent的整个工作分成五个阶段。

1. Setup，任务规划、环境设置、初始复现，占 9.98% rounds

2. Explore，代码搜索、文件检查、根因分析，占 30.37%

3. Fix，代码修改、调试迭代、patch refinement，占 33.53%

4. Validate，测试、回归检查、验证，占 16.59%

5. Closeout，最终检查、清理、总结，占 9.53%

这里面Explore（探索）和Fix（修正）就占了大概2/3的token用量。而在任何一个阶段，缓存阅读token都是最大项。

这本质上是当前Harness为了处理更长的工作任务而做的妥协，为了不让模型跑偏，每次进行下一步时，Harness会从不同来源累积信息。为了保证自己看到的仍是当前进程的真实状态，harness 又会把这些信息连同前面已经读过的局部上下文反复送回模型。

这使得而且这个行为是累积、甚至是重复的上下文被反复输入给模型。

这个问题Harness开发者也意识到了。目前成熟的 Coding harness 通常已经有文件检索、摘要压缩、上下文缓存和子代理隔离。

这虽然能在一定程度上缓解超长上下文的问题，但整体的累积问题仍然非常严峻。

而且论文发现，Agent很多时候会钻牛角尖。它们反复读同一批文件，反复改同一处代码，反复把这些上下文带回模型。token 账单变厚，但任务没有成比例推进。

干烧柴火，饭不熟。

同一个任务，不同尝试之间的 token 消耗最高可以差 30 倍。这说明模型自己也算不准自己该花多少钱，模型会系统性低估真实 token 用量。

这种来来回回的无用功，占了Agent行动成本的多大比例？研究证明可能超过90%。

在5月底哈工大的论文《Scaling Laws for Agent Harnesses via Effective Feedback Compute》把上面四月论文里提到的低效难题做了一个数量化操作。他们提出了一个标度概念，叫 Effective Feedback Compute （有效反馈计算），简称 EFC。

这个标度是为了测量Agent是不是每一次行动都能获得一些有效的反馈，简单来讲，就是有新证据支持的新增量信息，而且这个信息是可以真正影响下一步动作的。

他们提出了一个 EFC 转化率 η，去计算花出去的原始计算预算里，有多少被转成了有效反馈。可以理解为一个Harness有效反馈的效率高低。

结果基本上所有harness，在含有比较复杂上下文，需要多次反复的复杂Terminal任务和SWE任务中，EFC转化率都低的离谱，接近0.1。

就是花 100 块钱取证，只有里面 10 块钱成功买到了真正能改变下一步的线索。

而且越复杂的Harness，在复杂任务中有效反馈效率越低。

这就是1000倍消耗背后的另一个死结，低效行动。

着还是在Agent Swarm这种，让300多子Agent分布做任务，每个都单独积攒上下文并汇报的token杀手出现之前的Harness形势下的研究。

真用了Agent Swarm，这个token消耗，还得翻倍。

Agent本身的低效、长程任务不得不增加的上下文，多Agent系统共同在技术层面上铸就了1000倍的token消耗。

而这些已经非常低效的token，还经常被投入到无意义的任务里去。

02

组织的混乱

从Toknemaxxing的历史来看，最开始对Agent这个吞金兽的使用，主要是在开发团队内限制，后续则逐步在OpenClaw、Skill等更适合一般办公的Agent形式出现后拓展到几乎所有角落的。

但问题是，当下的Agent，即使结合Skill，就真的适合在这些非编程工作上大规模铺开吗？

能力的错配

目前的AI模型，在很多能力上其实参差不齐，在25年年底Joshua Bengio就曾经发文对模型能力做过评估，认为它们只能算是「能力参差不齐」的智能。

这一点，反馈在领域中，则是由于当前的后训练模式过分强化「可验证的奖励」（RLVR），因此在有明确答案的任务中表现更好，而在缺乏明确答案（如设计、写作）上很难有效提升。

而这种「能力参差不齐」，必然也会在具体工作领域的AI运用上产生后果。

多伦多大学的Joshua Gans 6月在NBER上发表了《Artificial Jagged Intelligence》，他认为，企业任务不是一张平滑展开的平面。不同业务领域、不同工具环境、不同工作流长度、不同验收方式，都会让 Agent 的表现发生明显变化。

真正决定部署价值的，不是模型在平均测试集上得了多少分，而是组织最常用、最关键、最不能出错的任务，是否刚好落在模型的弱区。

我们现在看到Agent在各种办公、Computer Use等 benchmark 表现很好，但它们都是均匀测试几十类任务。真实公司里 70% 的 Agent 调用可能都集中在客服查询、合同审查、ERP 录入、销售 CRM 更新或遗留代码修改里的某几个高频工作流。

如果这些高频工作流正好是模型弱区，那整个工作流几乎就不可用。而且不用多，只要一个组织的常用任务集中在模型覆盖不足的区域，更多 token 就不会带来线性改善。

它只会让 Agent 在这个弱区里跑得更久，产生更多需要人工检查和返工的中间产物。

你可以把它理解成木桶理论的简单版本。

那在具体不同领域间能差多少？

加州大学伯克利分校（UC Berkeley）牵头的研发中心 RDI 联合250多名行业专家在6月份发表了一份论文《Agents’ Last Exam》（arXiv 2606.05405）。

他们测试的覆盖了 制造、法律、医疗、视觉媒体等 55 个子领域、13 个行业集群、1400 多个真实专业任务。

为了能测试 Agent 是否真的能完成长周期、有经济价值、可验证结果的真实工作流，这些任务都来自真实从业者的日常工作。比如要求 AI 画出 3D 模型，有的则要它在达芬奇里完成绿幕抠像和视频合成。

结果如果只看最难一档的任务，当前表现最好的配置是 Codex + GPT-5.5，完整通过率也只有 8.6%；研究团队给出的主流系统平均完整通过率仅有 2.6%。

而分领域结果则显示，Agent 能力并不是均匀分布的。比如论文给了一个成功率的中值（成功率值大概能完成任务的多少，而非完整通过率），在数学计算和农业里最高，能到55%-85%。而在商业和法律中则降到了50-55%，至于教育则低至25%。

研究团队对 Claude Code + Opus 4.7 的失败案例做了系统性归因分析。结论是，75% 的失败归因于「理解」（Understanding，31%）和「策略」（Approach，47%）层面的问题。只有 22% 是执行层面的错误（代码 bug、格式错误、GUI 操作失败）。

也就是说Agent 不是「手脚不灵」，是「脑子里没有行业 know-how」。它不知道注塑模流分析该跑哪些步骤，不知道胸片判读的流程是什么，不知道管弦乐转谱要交付哪些文件。

Skill 确实可以有效缓解这个问题。但很多任务还需要隐性专业判断、本地规则、专业软件环境和可验证输出。一个通用 skill 到企业内部往往要 fork。

法务团队有自己的合同模板，财务团队有自己的审批规则，研发团队有自己的代码规范，销售团队有自己的 CRM 字段。越贴近真实业务，skill 越有价值，也越难通用。

而我们不得不把流程拆小，在更细节的部分调用Agent、写出更准确，更有效范围的skill。而如果你做的刚好是模型不擅长的事，那这个试错过程往往非常痛苦，花费不菲，而且因为人没办法脱离工作的loop，提效相当有限。

这就是为什么Satya Nadella为什么要强调token资本，讲的就是这些东西的积累。想的挺好，但真的很难。

因为这里其实有一个悖论，在没有明确划定AI在领域应用中的强弱，其薄弱环节的情况下，你不烧token去试，构建有效的工作沉淀就几乎不可能。

烧，你烧不起。等创业团队积累类似工作经验，或者等待模型的进一步发展填掉这些坑，你又不想等。

脆弱链的转移

而即使任务适合 AI，当下的Agent也依然存在短板。而未经变化的组织链条也未必能吸收 AI 的上游产出。

比如说coding Agent，这已经是目前Agent最擅长的领域了。但软件生产过程中，Coding只是原材料，有了Code之后，还要被审核、合并、测试、集成、发布、上架，最后还要有人真的使用。

它中间任何一环跟不上，上游写得再快，最后也只是堆出更多半成品。

就像一个餐厅，AI 让切菜速度变快了。以前一个厨师一小时切一筐菜，现在 AI 帮忙，一小时能切三筐。问题是，后面的炒菜、装盘、上菜、服务员送到顾客桌上、顾客愿不愿意吃，都没有同步变快。厨房里菜堆成山，不等于餐厅卖出了更多菜。

2026年5月MIT发表了《Writing Code vs. Shipping Code》（NBER w35275, 2026）。论文用了 10 万多名 GitHub 开发者的数据，并结合他们的 AI 使用遥测数据，比较了一下开发者采用 AI 工具前后的变化，

它把 AI 编程工具分成三代。第一代是自动补全，像早期 Copilot。它主要是在你写代码时补下一行。第二代是交互式 coding agent，像 Claude Code、Cursor 这类工具。你可以和它来回对话，让它改文件、解释报错、生成 patch。第三代是自主 coding agent，像异步跑任务的 Codex 或 GitHub Agent。你给它一个任务，它自己在后台跑，改代码，提交结果，这其实就是现在的主流Vibe Coding 模式。

如果只看最上游的指标，也就是 commit，即一次代码提交，类似工厂里又做出了一批零件，提效确实非常明显。论文发现自动补全让 commits 累计增加约 40%，进化到交互式 coding agents 可以让 commits 累计增加约 140%，而到自主 coding agents 让 commits 累计增加约 180%

这说明 AI 确实让写代码这件事变快了，而且越来越快。

但后面的流程，明显跟不上。

自主 coding agents 在 commit 层面的累计效应是 180%。但传导到项目数时，只剩约 50%。再传导到真正的 releases，也就是实际发布版本时，只剩约 30%。

这就是标题里说的，写代码和交付代码根本不是一回事儿。

AI 把写代码这一步加速了，但设计、审核、测试、产品决策、发布流程、应用商店审核、用户采用这些环节没有同步加速。

上游红利在下游被稀释。

而这个review代码，测试之类的环节，现在虽然也有Claude Code 的 Ultra review之类的工具可以代劳，但它的token账单甚至能达到写代码的十倍以上。

而如果你不用AI 去做这些后面的环节，人的带宽就会被卡死。每个人都知道，改Bug比写代码费劲，因为那需要你综合性的判断，快速的阅读代码并定位问题。更别提，实际上的rewiew过程，程序员甚至还需要去判断需求、审查代码、处理异常、决定是否发布、承担质量责任。

AI还会让这个环节变得更难。

卡内基梅隆大学在1月份发布的论文《AI IDEs or Autonomous Agents?》（arXiv 2601.13597）中，他们发现采用自动化CodingAgent 后，代码里需要人处理的警告上升约 18%，AI写的代码难度让人理解的难度（也上升约 39%）。

更多的问题，更难懂的代码。意味着原来程序员「清闲」的心流式的写代码时间，被这种高强度的review 过程替代后，人的大脑带宽更顶不住了。

因此，卡在这儿是必然的。

人类瓶颈没有解开，AI 的上游增益就无法完整转化成最终产出。

Tokenmaxxing 关注的是上游，看 Agent 跑了多少 token、写了多少代码。但从数据上看，它确实和下游，产品有没有发布，客户有没有使用，收入有没有增加是脱钩的。

转向下游评价，在一定程度上会迫使上游更谨慎的使用Agent，减少Token消耗。但效率体现，似乎就没那么明显了。

所以，不如干脆只把它用在确定有效的事情上。然后你就碰到了另一端的浪费。

简单问题上的虚耗

5月，在斯坦福的研究《The efficiency-gain illusion》中设计了 24 个简单任务，覆盖四类日常 AI 使用：信息查找、信息处理、流程执行和内容生成。

比如让AI回答白色和黑色混在一起是什么颜色，说出一个奥运奖牌得主，找 “enjoy” 的同义词，用两句话说明怎么煮鸡蛋，把 50 词小短文总结成一句话，找出 “The quick borwn fox...” 里的拼写错误，算 27 + 56，写一句生日感谢，写一句水瓶评价，或者把一句啰嗦话改得更清楚。

这些任务放到企业里，就是最常见的小颗粒度工作。很多时候，人自己做完，比打开 AI、写 prompt、等回答、读答案、再确认更快。但结果哪怕是简单颜色回忆、27 + 56 这种算术题都有近40%的人要用AI。

而在这些简单任务上， AI 反而让任务变慢。

原本算 27 + 56，直接心算或按计算器就能结束。用了 AI 以后，流程变成打开工具、输入问题、等待回答、读回答、确认它没错。原本改一句话，自己改可能只要十几秒。用了 AI 以后，要写 prompt，看它改得是否符合语气，再决定要不要接受。

AI 不是没有能力，而是固定调用成本超过了任务收益。

而且AI 使用会自我强化。参与者先用过 AI 后，后面更容易继续用 AI，而且对 AI 节省时间的判断更失准。

这就是组织里的效率幻觉。企业看到的是 AI 使用率上升，员工也觉得自己更先进。但在大量小颗粒度任务上它把原本可以直接完成的小动作，变成 prompt、等待、阅读、验证、修改的一串流程。

既花了token，又没提成效。

重复开发的循环开始

另一个可能是除了技术之外最大的token浪费项，发生在重复造轮子上。

在Cowork， OpenClaw这类完全自动化Agent出现后，AI Agent 把「生产一个可用模块」的边际成本降到了接近于零。开发者和 Agent 都更倾向于直接生成一个新实现，而不是花时间检索、理解、比较和复用已有实现。

而组织并没有同步解决「发现已有模块、判断优劣、追踪来源、复用依赖」的问题。

这在过去Skill市场的乱象中，表现的非常清楚。

26年3月，南洋理工大学的 《SkillClone》论文就对超过两万个市场上的 Skills 进行了分析。发现75% 的 skills 都是非常近似的，有着类似的目标和实现方法。两万个 skills 去重后只剩 5,642 个skill有与其他skill完全不同的理念和目标。而且其中 40% 的相似skill都不是同一个作者产出的，这说明这种相似，并不是单纯的版本迭代，而是广泛的不同作者在对同一件事做重复建设。

另一篇卡耐基梅隆大学在2月对 40,285 个公开 skills 的测量研究《Agent Skill》也得出类似结论。他们认为 skill 市场存在明显的意图同质化。很多 skill 在意图层面做的都是同一件事，比如同样是代码审查、文档生成、网页抓取，但只是换了名称、提示词和少量实现细节。

写过skill的同学都应该知道，写一个复杂skill需要花多少token，在反复修改，提供参考过程中，动辄几百块的token价格就花出去了。

但是，其实这些东西早就有人做过了，可能做的比你还好。

除了开发本身的浪费，skill过多，对于那些有自发现skill功能的Agent来讲，也会遭遇如MCP早期，工具发现混乱，要读取更多skill来进行比较，还比不准的浪费。

代码领域，重复造轮子的现象也开始显现。萨斯喀彻温大学在26年2月做了一项研究《Why Are AI Agent–Involved Pull Requests (Fix-Related) Remain Unmerged? 》，分析了8,106 个由 Codex、 Claude Code 等 Agent 提交的 fix-related PR（Pull request，就是把新写的代码和并到原始任务里，去加强原始任务）。

这里面有 26.1% 的PR 被关闭且未合并。

作者进一步人工分析了 326 个没被接纳的工程修改，发现最常见的失败原因是「同一问题已被另一个 PR 解决」，占 22.1%。

这很明确说明，至少有相当一部分的Agent编码是因为缺乏全局协调而在重复造轮子。

而这还是相对非常透明的系统仓库，大家都可以看到新的commit 和 PR的情况下。在组织间，仓库间的重复造轮子又不知道有几何。

更快的代码生产速度、由于模型本身倾向导致的更一致的解法都会使得重复开发更甚。

上面这些实验，一来证明了现在的Agent从能力上，还远未达到应该被广泛推广、在所有任务上真正达到提效的水平上。二来证明了在组织上，Agent应该被如何使用，如何更好的避免浪费，还远没有形成有效的工作模式。

比如组织应该如何分配尝试的用量、找到不适合当前Agent的任务？如何引导工作流的搭建，工作流搭建期间的效率评估？如何避免重复、让可用资源可见可用？如何在更快的迭代速度下，更快速的评估一个项目是否有价值去开发？

这些理解，在Tokenmaxxing的前期全部是缺位的。

而这也在一定程度上证明了，组织在这个OPC化时代的价值，它有潜力在算力尚不充足的时代，避免各自为战带来的高额资源损耗。

03

Tokenmaxxing为何必然失败

上面，我们看到的实际上是对Tokenmaxxing时期一些阻止其起效的具体切片环节的观察。

而它，其实本质上是对一个已经长期在经济学理论中存在的问题的重演，甚至是1:1的重演。

在过去时代中，电力、计算机、互联网等通用技术都曾经存在过一段「技术能力快速提升，为什么宏观增长没有同步出现」的时期。在经济学上，这个问题叫生产率悖论。

目前对这个问题研究最好的解答，是从2017年开始形成的J型增长曲线理论，以及它的底层理论，可替代性理论。

可替代性理论认为复杂产品是由一组互补要素共同决定的，任何一个要素都能成为瓶颈。上面说到的Agent技术本身的瓶颈、这一章节说到的流程与组织瓶颈都会导致某一环节的效率提升被大幅稀释。

代码生产效率提高一百倍，如果企业连需求都说不清楚，整个项目的效率很难提升。Agent一天可以生成一千个方案，如果人类只能审核十个，多出来的九百九十个方案不是产出，而是待处理库存。

而J型理论则发现，技术进步带来的市场增长往往在企业同步改变设备、流程、技能和组织结构后才会出现。

Token消耗越来越多，算力和软件支出越来越高，但有效产出并没有同步增长。企业一边支付技术成本，一边支付组织改造成本，统计上的生产率甚至可能下降。

这就是J型曲线下探的部分。

只有当数据、流程、人员、评测和责任体系逐渐成熟后，前期投入才可能开始产生回报。

AI不再只是生成一段内容，而是进入完整业务流程，能够稳定完成端到端任务，生产率才可能向上转折。

上面的各个例子正是说明，Tokenmaxxing本质上就是企业在支付这笔投入，趟出瓶颈的过程。

所以它必然失败，但它的失败并非毫无意义。

但并非所有的技术革新都会带来J型增长，因为它们会遇到需求的天花板。

04

需求的天花板

康奈儿大学团队在2026年1月发表了一篇论文《AI and the Quantity and Quality of Creative Products》研究了AI登场之后的图书市场。在 LLM 大兴其道之后，2022 到 2025 年新书发布量猛增了接近三倍。

提效是肯定提效了，但整体图书的阅读量却仅仅提高了约 7%。

书籍市场是一个早就相对再萎缩的市场，注意力被新娱乐方式占据之后，即使更多的内容产出，也无法逃过注意力分配给它的平静。

更不用提供给增加的大多数是低质量内容。这篇研究根据读者评价和使用痕迹来判断，新增加的书籍平均质量确实大幅下滑，高质量书籍依然以人类写作为主。

这就是需求的天花板。在注意力领域，需求的天花板是很低的。同类型的产品供给，会迅速撞上这个天花板。

比如在2026年初，AI短剧的兴起和逐步归正，就是这种天花板效应的现实体现。

而编程领域，其实也有这样的问题。

MIT 的《Writing Code vs. Shipping Code》里有一组数据，论文不只看 GitHub 上开发者写了多少代码，也看了这些代码最终有没有变成真正被用户使用的软件。结果在四大主流App 商店中，AI确实推动了新 app 数量增长，但没有带来总使用量增长。

也就是说，市场上 app 变多了，用户并没有因此多用软件。供给增加了，需求没有同步扩大。

毫无疑问，软件开发带来的需求天花板可能远高于内容生产。

经济学首先区分欲望与有效需求。一个人想要某种服务，并不意味着市场一定会提供它。只有当用户愿意支付的最高价格，高于完成交易的全部成本时，交易才会发生。

例如，一家公司想开发一个小型内部软件。这个软件预计能创造一万元价值，但传统开发需要五万元。需求虽然存在，却不会表现为订单。AI把总成本降到五千元后，交易才第一次成立。

AI创造新市场的第一种方式，就是让原本处在「不划算」一侧的任务跨过盈亏门槛。这就是软件开发最擅长的「制造新市场」方式。

但降本能释放多少需求，取决于门槛附近积压了多少任务。如果大量项目是强需求，只是「稍微有点贵」，小幅降本就能释放巨大市场。

但如果用户价值远低于成本，再大的技术进步也未必有用。

Coding可能存在大量这样的项目，内部工具、一次性软件、遗留系统维护和小流程自动化。但它的价值到底有多少？能不能被迅速降低到用户愿意接受的成本？

在Tokenmaxxing的阶段，降低成本其实很难做到。我们已经听到太多因为花不起token，干脆裁员开发的公司故事了。

而现在Agent寻找新需求、给出整体更低成本意见的能力明显不够强。

写一个App变得越来越容易，但识别一个尚未满足、用户愿意付费、现有产品没有解决，而且能够通过软件解决的问题，仍然很难。

这就是那些用户愿意大幅投入，但当下或者没有，或者太贵的甜点区，其实在Coding Agent的加持下并没有多少突破的主因。

我们离真正能转化成生产力爆发，还需要一些时间。

或者等待着AI能力突破人的瓶颈、或者等待组织吸纳AI，真正落地。

而在这之前，激进的Tokenmaxxing 必然失败。

文章来自于微信公众号 “腾讯科技”，作者 “腾讯科技”