提示词通胀正在吃掉你的预算：一场没人帮你算过的 AI 账
先说结论：很多人以为用 AI 是为了省钱。用着用着发现，AI 变成了你账上最贵的一项支出——而且最气人的是，你花的钱里有一大半是重复劳动产生的。
我给自己搭了一整套"数字小龙虾"：定时写作、跑测试、写文章、发稿、自动汇报。听着很美，直到我认真拉了一次账单，发现自己最大的成本不是模型调用，而是我一直在犯蠢地重复喂它同样的东西。
这篇不聊玄学，就聊钱。聊完你大概能省下三成到五成的调用开销，还能顺带学会一套挺有意思的"跟 AI 谈预算"的话术。
一、先搞懂：AI 的账单为什么这么反直觉
大多数人第一次看到 AI 账单都会懵：为什么我只是聊了几句天，扣的比我一个月的云服务器还多？
核心有三条，知道了就不再心慌。
1. 输入 token 才是真正的吞金兽
大多数人只盯着"输出多贵"，其实绝大多数场景下，输入才是大头。你每次提问，系统都要把系统提示词、工具定义、历史对话、检索到的文档、以及你这次贴进来的内容，重新读一遍。输出写得再短，输入那一坨永远是背景板。
所以有个反直觉的结论：把 prompt 从 5000 字砍到 800 字，效果可能还更好（因为噪音少了），成本却掉一大截。
2. 输出是按"生成长度"计费的，不是按"你读到的长度"
模型脑子里想了 800 个 token，最后只吐出 200 字，这 800 个照样计费。这就是"思考模型"的成本来源：思考是隐藏账单。让模型想更久确实更准，但你得清楚自己在为什么买单。
3. 缓存是真的能省钱，但只有一半人用对
主流平台都提供"提示词缓存"：你那段几千字的系统提示词，如果多次调用内容完全相同，第二次开始按折扣价算。但缓存只认前缀——只有开头一模一样的部分能命中。
这意味着：把你每次都一样的"人设、规则、参考资料"放最前面，把每次都变的"这次要干什么"放最后。顺序反了，缓存当场作废。
二、提示词通胀：你的上下文是怎么烂掉的
"提示词通胀"不是学术词，是我自己造的。它指的是：一个智能体跑得越久，它的上下文就越像滚雪球——每轮对话、每次工具输出、每段推理记录全都堆进去，最后你付的钱里有 70% 是在重复读同一份东西。
常见的四个通胀源头：
源头一：把"思考过程"当成"记忆"存
很多人的做法是：让 AI 每次都"先思考再回答"，然后把思考过程也存进历史，下一轮再原封不动喂回去。这相当于让一个人每次开会前，先把上次的会议记录全文念一遍再开口。上下文越来越长，注意力越来越散。
心法：过程留在日志里，结论才进上下文。中间产物要提炼成一句结论，而不是整段搬运。这跟你写代码注释一个道理——写给人和读给机器的，中间产物不是一回事。
源头二：工具输出不裁剪
这一条是最大的浪费源。一次搜索返回 5000 字、一次目录列举 300 行、一次日志 tail 2000 行——这些全进上下文，下一轮再来一遍。而模型真正需要的可能只是"匹配到的那一行"。
心法：在工具与模型之间加一层"漏斗"。先过滤，再入上下文。搜索结果只保留标题和摘要，文件只保留命中段落，日志只保留异常行。这一层薄薄的过滤逻辑，通常能省掉一半以上的 token，而且答案质量反而更稳。
源头三：每轮都重新"介绍一遍自己"
每次新会话都要重新交代：我是谁、我用什么风格、我的偏好、我的禁区。这些本可以放在固定的系统提示词/记忆文件里一次搞定，缓存还能命中。结果你每次都手打一遍，每次都在重复计费，而且经常漏。
源头四：失败重试不带"少废话"指令
工具调用失败、格式不对、字段缺失——重试的时候，你往往把整个错误堆栈 + 完整历史又喂一遍。模型于是重新表演一遍它刚才的错误。
心法：重试要带增量信息。只告诉它"上次错在哪"，别让它重跑全片。
三、实测：我怎么把一条流水线砍掉一半成本
拿我自己的写作流水线举例。我有一条自动化的流程：抓选题 → 生成草稿 → 转 HTML → 发布 → 回读确认。原版每一环的输入输出都是"完整文本传递"，上下文像接力赛，一棒比一棒沉。
改造只做了三件事：
- 固定前缀：人设、风格规范、禁用词表、格式模板全部前置固化，一字不改地放在最前面 —— 缓存全程命中；
- 中间产物字段化：草稿环节输出的不是一整篇文章，而是固定的"标题 / 正文 / 标签 / 摘要"四个字段，下一环只取它要的那个字段；
- 失败即停：发布失败不重试整条链，只重跑发布那一环，前面几步的产物直接复用。
结果是：同样的输出质量，单次链路的总 token 掉了接近一半，耗时也跟着缩短。最爽的是第三点——以前一次发布抖动，整条链重跑，那叫一个肉疼。
一句话总结这三条：让不变的东西待在前面，让变化的东西待在后面，让重试只发生在真正失败的那一步。
四、跟 AI 谈预算：Prompt 心法升级
大部分人跟模型说话像点菜："帮我写一篇 2000 字的文章。"模型就真给你 2000 字，每个段落都要面面俱到，因为你的要求就是"2000 字"。
更聪明的说法是给它一份预算合同。几个我实测有效的写法：
# 直接给预算约束
请在 1200 字以内完成。先给结论，再给 3 条理由。
预算超了你自己先砍，不要问我。
# 给结构配额，避免模型在某个段落上写嗨
标题不超过 20 字
每节不超过 250 字
至少 2 处有观点的吐槽
举例不超过 2 个
# 明确"信息不足时怎么办"
信息不足时不要编造，标注"需确认：xxx"，继续完成其余部分。
为什么有效？因为模型本质是一个倾向填满输出空间的生成器。你不划边界，它就自己找边界，而且往往找得比你还大。
再补一条容易被忽略的：给它"停止条件"。比如"当你觉得信息足够支撑结论时就停，不要为了完整而展开"。这句话对控制输出长度和提升信息密度的效果，出乎意料地好。
五、行业趋势：当模型便宜到不值得思考的时候
价格曲线一路往下掉之后，一个反直觉的策略开始变得划算：不再所有任务都用最贵的模型。
现在的常见打法是分层路由：
- 日常活（分类、摘要、格式转换、字段抽取）—— 交给便宜的小模型，甚至本地模型，成本可以低到近乎免费；
- 难活（架构决策、复杂重构、需要多步推理的方案）—— 才动用推理模型，并允许它"想久一点";
- 审判活—— 产出之后再用一个便宜模型做格式/事实校验，错误比想象中少。
我的实测感受是：绝大多数被当成"难题"的任务，其实是被糟糕的提示词撑成了难题。把输入整理干净、用便宜模型跑一遍、再把异常挑出来给贵模型——这条链路的总成本经常只有"全部用贵模型"的三分之一，效果还更稳。
另一个正在发生的趋势是上下文成本从"输入侧"往"缓存侧"迁移。平台方越来越 incentivize 长文档 + 前缀缓存的用法，因为那部分存储便宜、还能锁定用户习惯。谁先把自己的提示词结构设计成"缓存友好型"，谁就先拿到成本红利。
六、三个立刻能用上的动作
- 把不变的东西固化到最前面。人设、规则、模板、参考资料，各自存成固定文件，永远放在提示词开头。缓存一命中，你就是在白嫖。
- 给工具输出加漏斗。这一步不需要多聪明的代码，只需要你决定"模型到底需要看哪几行"。
- 给模型写预算合同。字数上限、结构配额、停止条件、禁止编造时的兜底动作。这四条加上，输出质量和成本会同时改善。
最后再吐槽一句行业：所有厂商都在卷上下文能塞多少 token，但真正决定你花多少钱的，往往是你塞进去的东西有多脏。上下文工程的核心不是"放更多"，是"放得更准"。把这句话刻在脑门上，比买任何一家的无限套餐都管用。
（另外，如果你正打算在服务器上跑一堆自己的 AI 工具，别跟 Docker 死磕——我这边提供代部署服务，一键把 n8n、Open WebUI、AnythingLLM 这些搬上去，省下的时间正好用来优化你的提示词。）
