最近有个词在科技圈火了：tokenmaxxing。
意思是把「用了多少 AI token」当成一种生产力信号。上下文越堆越多，agent 越开越多，调用次数越刷越高。重点不是结果，而是消耗本身。
但我这段时间真正在用各种 AI coding agent 干活时，体感刚好相反：给 AI 的上下文越多，结果不一定越好。
很多时候，你把代码、文档、报错、历史讨论一股脑全塞进去，AI 反而会迷路。它会改错地方，漏掉重点，甚至自己补出一套并不存在的逻辑。
所以问题根本不是「token 不够多」，而是另一个更关键的东西：有效 token 的浓度够不够高。
问题不在 token 数量，在有效浓度
Tokenmaxxing 最大的问题，是只盯着消耗量，却不看转化率。
同样是 10 万 token，有的人是在给模型提供清晰任务、关键文件、边界条件和验收标准；有的人是在往窗口里堆噪音、背景、重复信息和没整理过的上下文。表面上看，大家都烧了 10 万 token。实际效果，可能完全不是一回事。
真正决定质量的，不是 token 的绝对数量，而是：
有效 token 相对于任务工程量，到底够不够。
这件事可以拆成几个变量：
- Token 总量：你一共喂了多少信息。
- 上下文利用率：这些信息里，有多少真的有用。
- 注意力聚焦度：模型能不能把注意力放在关键部分。
- 任务范围：你让 AI 干的事情到底有多大。
- 任务不确定性：你有没有把需求讲清楚。
这也是为什么很多人会有一种错觉：明明已经给了很多内容，为什么 AI 还是做不好？
因为你增加的，未必是有效信息；你放大的，反而可能是任务的噪音和歧义。
为什么不是越多越好？
因为模型对上下文的吸收能力不是线性的。
一开始加信息，效果通常会明显变好。因为模型终于知道你在说什么，也知道该看哪些文件、遵守哪些约束。
但到了某个点之后，再继续加 token，收益就会越来越小。
第一，模型本身有注意力和能力上限。
第二，长上下文并不等于高质量上下文。研究里反复提到一个现象，叫 "lost in the middle"。也就是模型对开头和结尾的信息利用得更好，中间部分反而更容易被忽略。你把真正重要的约束埋在一大段背景材料中间，模型并不会因为字更多就更理解你。
所以这篇文章真正想说的，其实就一句话：
AI 不是吃得越多越好，而是吃进去的东西要更准、更集中、更贴近任务。
所以实操层面怎么做？
想明白这个模型之后，操作建议就很清晰了：
1. 把任务切小。 不要一口气让 AI 干一个大工程。范围越小，同样的上下文就越「浓」，效果越好。
2. 精心准备上下文。 不是把所有相关文件都丢进去就完事了。要筛选、要组织、要把关键约束和验收标准写清楚。Anthropic 管这叫 "context engineering"——本质上就是在提高上下文的利用率。
3. 把需求写明白。 OpenAI 的 Codex 文档反复强调两件事：explicit context 和 clear definition of done。说白了就是告诉 AI 你要什么、不要什么、怎么算完成。需求越明确，任务的不确定性越低，AI 就越不容易跑偏。
4. 关键信息放在开头和结尾。 既然模型对中间部分的注意力容易衰减，那就别把最重要的约束埋在一大段背景信息里。
这也是为什么现在大家开始谈 harness engineering
如果说 tokenmaxxing 关注的是「我烧了多少 token」，那 harness engineering 关注的就是「我怎么把这些 token 变成更稳定的结果」。
它不是单纯研究提示词，而是在模型外围做系统设计：怎么组织上下文，怎么拆任务，怎么做验证，怎么让 agent 少跑偏、少返工、少浪费。
所以这两个词其实刚好是一组对照：
- tokenmaxxing：追求消耗量
- harness engineering：追求结果转化率
把这个对照放回来看，前者更像一种 AI 时代的绩效表演，后者才更像真正能落地的方法论。
不同模型会影响效率，但不改核心逻辑
当然，不同模型的转化效率确实不一样。
有些模型更擅长长上下文，有些模型更适合代码生成，有些模型第一次就能抓住意图，有些模型则更依赖你把边界写得非常明确。
但这不改变核心结论。
无论你用的是 Claude、GPT 还是 Gemini，真正决定结果的，依然不是你烧了多少 token，而是你有没有把有效信息，以高浓度的方式，喂给一个足够明确的任务。
一句话总结： 别迷信 token 消耗量。Token 是弹药，但打不打得准，取决于你瞄没瞄好、目标有多大。真正重要的，不是烧更多 token，而是提高有效 token 的浓度。
附：形式化模型
上面说的这些直觉，可以压缩成一个公式。这不是某篇论文里的现成定律，而是我根据实际体验和上述研究构造的一个解释性模型：
各变量含义如下：
- — 工作质量。可以理解为代码正确性、完成度、可维护性、一次通过率等指标的综合抽象值。取值范围 。
- — 质量上限。当前模型、工具链、任务条件下理论上能达到的天花板。token 再多，质量也只会逼近这个上限，不会无限上升。
- — Token 总量。输入给模型的所有内容：需求说明、代码上下文、报错信息、约束条件、测试命令、历史决策等。
- — 上下文利用率。你给进去的 token 里，有多少真正被组织成了模型可有效调用的上下文。需求结构清晰、文件筛选精准时 高；上下文混乱、冗余、噪音多时 低。Anthropic 对 context engineering 的定义，本质就是在提高这个系数。
- — 注意力聚焦系数。模型是否能把注意力集中在关键约束和文件上。任务边界明确时 高；信息分散、重点埋在中部时 低。长上下文研究表明模型对开头和结尾的信息利用更好，中间容易被忽视，因此 不是常数。
- — 任务范围。这个任务牵涉多少模块、文件、逻辑路径和系统边界。修一个按钮样式， 很小；重构认证系统， 很大。「任务范围越小，同样 token 越有效」本质上就是 与效果成反比。
- — 任务不确定性。任务的歧义程度、隐藏依赖、需求未定义部分和决策自由度。明确了要改哪些文件、禁止改哪些部分、完成标准是什么， 就小；只说「优化一下」， 就大。OpenAI 反复强调的 clear structure 和 definition of done，本质就是在降低 。
- — Token 转化效率常数。描述单位「有效 token / 工程量比」能多快转化为质量提升。不同模型、不同 IDE agent、不同代码库条件下 不同。
公式的核心思想可以进一步压缩为一个中间量——有效 token 充足比：
于是主公式就变成：
读法很直观： 小的时候，token 相对于任务规模不够，模型只能做出零散、容易漂移的结果； 增大，质量快速上升； 已经很大时，再加 token 收益越来越小，质量逼近 。
如果要写成一段正式说明：
设 为 AI 在给定编程任务上的工作质量， 为输入 token 总量， 为上下文利用率， 为注意力聚焦系数， 为任务范围， 为任务不确定性，则可用模型 描述质量与上下文供给之间的关系。该模型表明：工作质量并不单纯取决于 token 的绝对数量，而主要取决于有效 token 相对于任务工程量的充足程度。随着 增加，质量通常上升，但由于存在边际递减，提升最终会趋于饱和；而当任务范围更小、边界更清晰、不确定性更低时，同样数量的 token 会更有效地转化为高质量产出。
信息来源：
- 长上下文研究中的 "Lost in the Middle" 现象（Liu et al., 2023）
Follow Me ｜ 关注我
- Blog:https://harryis.fish
- X(CN): @harry_is_fish
- X(EN): @harry_isfish
- 公众号
- 📺 Bilibili:海鱼Harry
- 🍠 小红书:海鱼Harry
- 🎵 抖音:海鱼Harry