最近在做 AI 应用开发时，几乎每天都会看到一个熟悉的报错：context length exceeded (36,183 tokens). cannot compress further.一个不算复杂的任务，输入加上几轮历史记录，就能轻松触到上下文窗口的边界。这个报错背后，是 AI 热潮中一个很少有人真正重视的问题——我们都在消费 token，但多数人并不清楚 token 如何计算、如何用得更省、如何避免在狂热中不断为模型能力“充值”，却得不到稳定的结果。
“AI Mania: From Tulips to Tokens”这个标题，其实是一个很好的隐喻。它把历史上著名的郁金香狂热和当下 AI 热潮放在同一条时间轴上：疯狂、涌入、价格飞涨、后来者接盘。区别在于，郁金香交易的是球茎，AI 交易的是 token。Token 既是模型理解人类语言的输入单元，也是按量计费的输出单元，更是衡量上下文长度、成本、性能的统一度量。如果说 AI 是一个新大陆，token 就是这片大陆上唯一的货币。
这篇文章不打算讨论 AI 会不会取代人、未来会不会有意识这类宏大话题。我更想聊一个更实际的问题：当 AI 热潮退去一部分水分，真实工具真正落地时，我们该怎么管理 token、控制成本、减少幻觉、避免盲目追新。换句话说，把 AI 从“话题”变成“工程”。
1. 为什么说这是一场从郁金香到 Token 的狂热
1.1 郁金香泡沫和 AI 热点的相似之处
荷兰的郁金香热，发生在 17 世纪。那时一株稀有郁金香球茎的价格，可以买下一套运河边的房子。人们买郁金香并不是因为它能开出多漂亮的花，而是因为“下一个买家会出更高的价格”。当预期反过来，价格崩塌，很多人一夜之间背负债务。放到今天的 AI 热潮，相似的迹象并不少：模型发布会越来越密集，每条新功能都被包装成颠覆性突破；社交平台上到处是“AI 改变一切”的叙事；市场上出现大量只有 PPT 没有产品、只有界面没有场景的“AI 创业项目”；甚至出现了靠注册送 token 来拉新用户的模型厂商。
并不是说所有 AI 热潮都是泡沫。真正的泡沫，往往出现在“概念先行、价值滞后”的阶段。技术是真实的，但短期被高估，长期又被低估。大模型的能力是真实的，但多数普通用户和中小团队真正用到的场景，可能只是几轮对话、摘要、写作辅助和简单代码生成。相比之下，热词里出现的“AI 编程”“AI Agent”“AI 绘画”等方向，确实有工具价值，但距离“人人可用、稳定可靠”还有不小的距离。
1.2 Token 接力了郁金香的叙事位置
郁金香热潮中，球茎的价格是围绕稀缺性波动的。而在 AI 热潮里，token 是围绕算力和模型能力波动的。不同模型有不同的 token 计价规则，输入和输出分开计费，上下文越长费用越高。很多普通消费者对“模型有多聪明”没有感知，反而对“注册送多少 token”有直接感受。于是，token 成了 AI 热潮里最像货币的符号。
token 这个单词本身也很有意思。它原意是代币、记号。在加密货币世界里，token 代表资产；在 AI 世界里，token 代表文本片段。两者都有吸引投机者的一面。注册送 token、充值买 token、任务消耗 token，这套商业模型和当年郁金香球茎交易的逻辑并没有本质区别：都是一种可度量、可交易、能引发预期的东西。区别是，郁金香球茎最终会枯萎，而 token 一旦被消耗就永久消失，不能转卖。
1.3 狂热未必是坏事，但会放大误判
写过一段时间 AI 应用之后，我的感受是：狂热会让新鲜感快速消退，也会让质量问题提前暴露。
一个新模型发布时，很多人急着注册、体验、写评测。但这些评测大多停留在“能不能答对某道题”“能不能写出一段像样的文案”上，很少关心它在生产环境中的稳定性。等到真正做开发时，才会遇到上下文溢出、输出格式不稳定、延迟波动、token 成本超出预期等一系列问题。这些不是模型能力不够，而是工程化程度不够。
狂热还会放大一种误判：以为“AI 能力越强，应用就越简单”。实际上，强模型不等于好产品。一个能够写代码的模型，如果被错误地接入业务流程，可能会生成有安全隐患的代码；一个能够画图的模型，如果被用来执行批量任务，可能会对成本和版权都造成麻烦。热潮中，人容易高估工具的“自主性”，低估人的“设计和约束”价值。
所以，与其一边焦虑一边跟风，不如把“AI 狂热”看作一个提醒：工具越强大，越需要清楚的边界、可控的流程和扎实的工程基础。
2. Token 才是 AI 世界的硬通货
2.1 先搞清楚 Token 是什么、怎么算
模型并不是直接理解文字本身，而是把文字切分成一个个片段，这些片段就是 token。不同模型切分规则不同：英文单词可能一个词是一个 token，中文可能一个字或一个词被拆成多个 token。常见的经验是，一个英文单词大约 1.3 到 1.5 个 token，一个汉字大约 1.5 到 2 个 token。但这不是绝对标准，遇到代码、表情符、生僻字时，差异更大。
计费方式通常按“输入 token + 输出 token”计算。比如请求一次模型，系统提示词、用户输入、对话历史、工具返回的结果都属于输入；模型生成的内容属于输出。一次请求的总 token 数，就是两者之和。有些厂商还设置了 TPM（Tokens Per Minute）限制，也就是每分钟最多能消耗的 token 总数，这会影响并发请求的吞吐量。热词里提到的“tpm = 输入 token + 输出 token 的总和”，就是这个计费限制。
2.2 计费、窗口和压缩：三个绕不开的概念
做 AI 应用时，你马上会接触三个概念：
- 计费：不同模型的价格差异可能很大。同一个任务，用 A 模型可能花几毛钱，用 B 模型可能花几十块。你需要根据成本选择模型，而不是一味追求最强。
- 窗口：模型一次能接收的 token 总量叫上下文窗口。窗口大小直接决定了你能放进去多少文字、代码、历史记录。窗口不够用，就会出现
context length exceeded报错。 - 压缩：有些框架会自动压缩历史对话，把早期的内容改写成摘要，从而腾出空间。但压缩有代价：信息丢失、摘要失真、模型可能忘记细节。报错里写着
cannot compress further，说明已经压无可压，只能截断或失败。
这三点是 AI 应用开发的底层约束。不理解它们，你会写出“看起来能跑、一上线就崩”的应用。
2.3 为什么上下文管理这么难
很多人以为上下文管理就是“把历史消息都传过去”，实际上没那么简单。
首先，模型并没有无限记忆。即使你有 128K 的上下文窗口，模型对长文本中不同位置的注意力也不均匀。放在中间的信息容易被忽略，这是模型结构带来的通病。也就是说，即使 token 没有超限，也不能保证模型真的“记住”了所有内容。
其次，token 消耗随对话轮次增长得非常快。假设每轮用户输入 200 token，模型输出 400 token，历史第 10 轮就积累了 6000 token；到了 20 轮，光历史就已经 12000 token。如果不做裁剪，一个简单的客服机器人也能把上下文撑爆。
最后，压缩策略会影响输出质量。把早期内容压成摘要，模型可能失去细节。比如用户说“我的订单号是 12345，帮我改地址”，如果这段内容被压成“用户要求改地址”，之后模型再跟快递系统交互时，就不知道订单号是多少。上下文管理不是简单的“省 token”，而是权衡信息完整性和成本之间的一套策略。
3. AI 编程、绘画和 Agent：看起来很美，先看账单
3.1 AI 编程的效率与隐性成本
“AI 编程”是当前最热的几个方向之一。Cursor、IDEA 插件、Spring AI 等工具频繁出现在讨论中。AI 编程的体验确实好：它能根据注释生成函数、补全代码、解释报错信息。但实际用于项目开发时，隐性成本不小。
首先是 token 消耗速度。一个稍大的函数重构，可能就需要几千 token 的输入和输出。如果你频繁让它分析整个项目文件，一次对话消耗上万 token 很正常。其次是质量问题。AI 生成的代码可能看起来逻辑正确，但缺少边界判断、类型约束和异常处理。你还要花时间 review、测试、修改，这些时间成本没有计入 token 账单。
更典型的是误解。很多人以为 AI 编程就是“提出需求，得到完整代码”，但现实是，模型只理解你描述的需求片段，不了解项目的整体架构、历史决策和技术债。你需要把它当成一个“非常熟练但不懂业务的新同事”，给它足够上下文，同时严格 review 它的输出。否则，它能帮你生成 200 行代码，也能帮你埋下一颗雷。
3.2 AI 绘画的 token 消耗密度
AI 绘画看起来不像编程那样需要大量文字，但它的 token 消耗集中在描述和反复调整上。你写一段提示词，生成一张图，然后不满意，改几个关键词再来一张。一张图消耗的 token 可能不多，但一晚上试下来，很容易消耗数十万 token。如果使用更精细的控制网络、局部重绘，每一次请求都会拉高消耗。
另外，AI 绘画的“效率”容易被误读。生成一张图只要几十秒，但找到理想构图可能要试几十次。中间还需要人工筛选、修图、拼接，最终时间成本并不低。对于批量生成脚本，比如“AI 营销视频一键成片”这类工具，思路也类似。看起来一键完成，实际上模板、素材、脚本、配音、字幕每个环节都需要消耗 token 和算力。如果没控制好参数和用量，成本很容易失控。
3.3 Agent 的失控风险与 Token 爆炸
AI Agent 是一个被讨论很多的方向。它的大致思路是：让模型根据任务目标，自己规划步骤、调用工具、读取反馈，再循环迭代直到完成。听起来像是一个能自主工作的同事，但工程实现比想象复杂得多。
一个 Agent 任务通常会产生多轮“模型—工具”循环。每一轮调用都包含系统提示词、工具返回结果、模型推理输出，Token 消耗比单轮对话高出一个数量级。如果 Agent 陷入死循环或错误分支，token 会像流水一样消耗，甚至卡在某个cannot compress further的报错上。
更麻烦的是，Agent 的不可预测性。它可能会调用一个本来不该调用的工具，也可能会按照错误的理解反复重试。在缺少严格边界的情况下，Agent 既不可控也难排查。我的建议是：先用小样本任务测试，明确工具列表、调用权限、最大迭代次数，并设置 token 预算上限。把 Agent 当成一个有风险的流程，而不是一个无脑的自动化工具。
3.4 让人头疼的 AI 幻觉，和 Token 有什么关系
AI 幻觉指的是模型一本正经地给出错误信息。很多人觉得这是模型“不聪明”，其实和 token 也有关系。
模型生成输出时，是根据概率预测下一个 token，而不是检索事实。它的知识来自训练数据，而不是实时数据库。当输入 token 中包含的问题超出它的知识边界，它可能用编造的信息来填补。另外，上下文过长也会加剧幻觉：关键信息被淹没，模型只能根据最近的 token 强行生成，错误概率自然上升。
减少幻觉的方向不是“换一个更大模型”，而是做好检索和约束。你可以把外部资料作为上下文输入，让模型基于资料回答；你也可以限制输出格式，甚至让模型先列出可验证的事实，再给出结论。Token 在这里不仅代表成本，也代表你能提供给模型的信息质量。信息越干净、越有结构，模型的输出就越稳定。
4. 把 AI 应用当成工程来做的五个控制点
如果只是体验 AI，怎么做都行。但如果要放进真实业务里，就一定要把它当成工程问题来对待。下面是一套我反复使用的控制框架，按优先级排列。
4.1 控制点一：输入净化与压缩
在把文本交给模型之前，先做净化。删掉无意义的重复内容、网页模板、广告标签；把长文档按章节切分，只保留与任务相关的部分；如果输入是网页爬取的内容，先转成纯文本。这样能直接减少输入 token，便宜又有效。
对于日志、评论、长文章这类非结构化输入，可以用摘要模型先做一轮粗筛。比如先用一个小模型生成摘要，再把摘要交给更强的模型。虽然多调用了一次，但整体成本可能更低，因为小模型速度快、价格低，还能提取关键信息。
4.2 控制点二：上下文裁剪策略
不要一次性把全部历史记录塞给模型。常见做法是：
- 设定最大轮次，比如只保留最近 10 轮对话；
- 超过限制时，用摘要替换最早的内容；
- 对于结构化任务，只保留关键字段，不保留原始对话。
这里有一个容易踩坑的点：不要为了节省 token 而压缩掉必要的信息。建议先观察模型在完整上下文下的输出质量，再逐步压缩，找到“能接受”的平衡点。如果你有一个“订单号、地址、金额”之类的关键槽位，永远不要把它合并进摘要里，否则后面模型无法完成操作。
4.3 控制点三：请求频率与并发
很多应用会把所有用户请求实时同步发送给模型，结果一上线就遇到 TPM 限制。常见做法是：
- 在应用层增加队列，控制每分钟的请求量；
- 对长任务拆成多个短任务，分批执行；
- 对可缓存的请求做缓存，比如同一个提示词生成的固定文案，没必要重复调用模型。
TPM 限制不只是计费问题，它还影响应用的可用性。如果超过限制，接口会返回限流错误，这时候必须做重试和退避。建议在代码里统一封装一个请求模块，包含限流、重试、超时、错误分类，而不是在每个业务逻辑里单独调用。
4.4 控制点四：成本与日志监控
先用小样本估算成本，再上批量。假设每次请求 1000 输入 token、500 输出 token，单价是每百万 token 20 元，那一次请求的成本就是 0.03 元。听起来不高，但一天跑 10 万次，就是 3000 元。这个账一定要提前算。
日志方面，至少记录以下信息：
- 每次请求的模型名、输入 token、输出 token、耗时、状态码
- 每个业务功能消耗的 token 总量和成本
- 出现
context length exceeded、限流、超时的次数
有了这些数据，你才能知道哪些功能是成本大头，哪些高频功能可以被简化。
4.5 控制点五：异常处理与兜底
模型接口不稳定，网络也可能抖动。一个合格的 AI 应用，必须有兜底方案。
- 设置最大重试次数和退避时间，避免无限重试；
- 当请求失败或超时时，返回固定的友好提示，而不是让用户看到崩溃栈；
- 对于关键业务，增加人工审核或规则校验，防止模型输出直接进入核心流程。
比如 AI 生成的文章，在发布前应该经过敏感词过滤、格式校验、事实抽查。AI 生成的代码，必须经过编译、测试、代码审查。不要假设模型不会出错，机器和流程都会出错。
5. 从狂热回归理性：现在该怎么用 AI
5.1 适合做的事情与不适合做的事情
根据我的经验，现在的 AI 适合做以下事情：
- 文案初稿、内容改写、摘要提炼、翻译；
- 代码补全、单元测试生成、简单脚本编写、错误解释；
- 非结构化数据的初筛和分类，比如判断客户反馈类型；
- 在有资料约束的场景下回答问题，比如客服机器人。
暂时不适合做的事情：
- 完全无人值守的金融交易、医疗诊断、法律建议；
- 需要高精度事实判断的任务；
- 没有规则和权限约束的 Agent 自动化；
- 一次生成上百万字的书籍或完整系统。
不是模型能力做不到，而是风险不可控。尤其在涉及人身安全、财产安全、法律责任的地方，AI 应该作为辅助者，而不是决策者。
5.2 从最小可用流程开始，而不是一步到位
最稳妥的落地方案是：先跑通一个最小可用流程，再扩展到批量、再优化成本。
第一步，用一个小样本验证输入输出是否符合预期。例如 100 条测试数据，手动检查输出质量。第二步，把流程脚本化，加入日志、重试、错误处理。第三步，跑一批真实数据，观察 token 消耗和失败率。最后才考虑优化成本，比如换更便宜的模型、压缩上下文、加缓存。
不要一上来就搞“AI 全家桶”：语言模型、视觉模型、Agent、向量数据库全上。每多一个环节，就多一个失败点，也多一层 token 消耗。先从最小闭环开始，比什么都重要。
5.3 一个可复用的判断清单
当你要使用一个 AI 能力时，可以按这份清单问自己：
- 这个任务必须用大模型解决吗？用规则、正则、字典能做到吗？
- 输入数据是什么格式？最大长度是多少？需要预处理吗？
- 输出结果会被谁消费？需要稳定结构吗？是给人看还是给系统看？
- 失败后会造成什么后果？可以重试吗？需要人工介入吗？
- 单次成本是多少？每天调用量是多少？有没有预算上限？
- 如果模型升级或调整价格，这个流程还能稳定运行吗？
这些问题没有标准答案，但能帮你在热潮中保持清醒。AI 是一种工具，不是信仰。工具的职责是解决问题，而不是成为话题。
5.4 现在最该做的事情
回到开头那个context length exceeded报错。它提醒我的是：AI 开发的第一课不是“怎么提示词写得更好”，而是“怎么理解 token 的边界”。
不要把目光只盯在“哪个模型更强”上。多花点时间记录自己的 token 消耗，分析任务失败原因，建立成本监控，设计一层容错缓冲。这些工作看起来不够酷，却决定了 AI 应用能不能活过上线后的第三个月。
从郁金香到 token，浪潮会过去，留下来的不是炒作，而是真正被沉淀下来的工程能力。如果一个工具让你产生热情，下一步应该是耐心，而不是冲动。最好的使用方式，不是追着热度跑，而是把它放在真实的问题里，反复打磨，直到能稳定地为别人创造价值。
所以，下一次打开 AI 应用之前，可以先想清楚一个问题：你准备让它做什么，你愿意为它消耗多少 token，如果它失败了，你的备选方案是什么。想清楚这三点，你才算真正开始使用 AI。
