最近一个朋友找我吐槽，他用 GPT-6 Astra 跑了两周项目，账单是我的三倍。
我翻了他的使用记录，问题一眼就看穿了：所有任务无脑开最高推理档，几十个工具一次性全塞给模型，长对话从头到尾不压缩，模型每改一行代码就把全部测试重新跑一遍。
钱就是这么烧掉的。
后面我花时间实测了十几条策略，又补上一批实战验证过的补充打法，拼成这份能直接抄的清单。先说透一件事，省 Token 的核心思路只有一个，让模型少做没用的事。
1、推理档位先低档，复杂了再升很多人一上来就把档位拉满，这是最贵的习惯。简单问答、改文案、翻译、格式整理、普通代码小改，低档完全够用。真正吃 Token 的往往不是回答本身，是模型那些看不见的深度思考。
Astra 支持中途动态调档，从低档切到高档不用重写提示词，缓存还能续上。我的习惯是先 medium 起步，真遇到复杂分析、架构设计、疑难排错再升 high / xhigh，搞定后立刻调回来。
普通任务默认 medium 档。复杂分析、架构设计、疑难排错，先说明理由再切 high / xhigh。问题解决后立即调回 medium。
2、多模型编排：盖楼的活给最强，垒砖的活给主力这是编排层面最值钱的一条，核心就一句：别一上来就上最贵的模型。
把任务先拆成两类。设计类的活是盖楼——架构设计、跨模块改动、安全审计、支付和数据相关的部分，错一次代价极大，必须最强模型上场；执行类的活是垒砖——普通 bug 修复、边界清楚的小功能，交给主力模型的中级档就行。
盖楼前的设计是复杂任务，垒砖头是执行任务，两种活不该一个价。
请先把这次需求拆成两类任务。A类，涉及架构、跨模块、安全、支付、数据结构的设计工作。B类，边界清楚的功能实现和bug修复。A类留给最强模型处理，B类用主力模型中档完成。拆完先给我看清单，再动手。
3、轻量模型先改，测试过了再交付B 类任务还有更省的玩法。先让轻量模型改，测试、lint、构建全绿了再交付，挂了再升级到主力模型。 大部分情况下根本走不到升级那一步——边界清楚的功能，轻量模型一次过的概率其实很高。
你先用中档完成这次修改。改完只跑与本次直接相关的测试、lint和构建。全部通过就停，把diff发我。如果测试失败，说明原因，我再决定是否升级到更强模型。
4、长对话一定要开上下文压缩聊天记录每轮都完整重发一遍，输入 Token 会滚雪球。第 1 轮 5k，第 10 轮可能就是 50k，其中九成是重复的旧内容。
Compaction 的作用是把前面很长的历史压成一个短状态再继续，关键信息保留，重复内容不传。 连续改网页、改方案的长任务，这一条省得最多。
当前对话超过50k token后，启用Compaction。压缩时保留，原始目标、已完成的改动、当前方案状态、未解决的问题。历史对话细节可以丢弃。
5、提示词缓存，固定放前面，动态放后面系统提示词、技能规则、输出规范、工具说明、长期参考资料，这些每轮都不变的内容放最前面；用户本轮的新需求、时间、临时变量放后面。前半段稳定，就能命中 Prompt Cache，重复输入部分的费用和延迟都会明显降下来。
这里有个特别容易踩的坑：有人为了省 Token 拼命删系统提示词，结果把缓存前缀改坏了，总成本反而上升。一段 5000 Token 的规则只要每次都一样、能稳定命中缓存，经常比每轮重新组织提示词更便宜。
固定区，放最前System Prompt、角色设定、Skill规则、输出规范、工具定义、稳定参考资料动态区，放最后用户本轮需求、临时变量、新增要求每轮只改动动态区，固定区一个字不动。
6、工具别一次全塞，用延迟加载一个 Agent 同时挂着浏览器、搜索、Figma、数据库、命令行等几十个工具，光工具的结构说明就可能占几千甚至几万 Token。当前需要哪个，才加载哪个。
defer_loading: true配合 Tool Search 使用本轮只需要查网页时只加载 Browser 和 Search真正用到 Figma 时再加载 Figma
如果你在做 Agent 或者 MCP，这一项优化性价比极高。
7、明确让模型少说一点GPT 默认解释得比较详细。你只要结果，它给你完整分析报告，输出 Token 就这么浪费了。省 Token 最简单的一招，是明确告诉它输出格式。
分析这个网页。只输出，1. 设计风格2. 布局3. 字体4. 配色每项最多3句话。不要复述我的需求，不要解释分析过程，不要总结。
更省事的做法是在系统提示词里长期写上：默认简洁回答，优先直接给结果，避免背景介绍、总结段和不必要的重复。
8、别让编程智能体反复验证Astra 这类模型很谨慎，代码改完会自动继续检查、重跑测试、扩大测试范围。必要的测试过了以后，这些动作全是白烧钱。
仅执行与本次修改直接相关的测试。必要测试通过后立即停止验证，除非出现错误、新修改或未解决的问题。不要为了完整性重复运行已经通过的测试。
9、多轮任务接着上一轮跑，别从头再来复杂 Agent 任务经常是调浏览器、拿结果、再调代码工具的连环流程。每一步都用 previous_response_id 接着上一轮的状态走，别像全新请求一样把整个背景重新解释一遍。
本轮请求携带 previous_response_id，沿用上一轮的推理内容和工具结果继续。不要重新建立整个任务的背景说明。
10、跨会话只带四样东西新开一个会话，很多人习惯把上一个会话的内容大段粘贴过去。没必要。跨会话真正需要的只有四样：原始目标、改动文件、当前 diff、失败日志。 多一个字都是浪费。
新会话开场请只包含以下内容，1. 原始目标2. 已改动的文件清单3. 当前代码diff4. 最近一次失败的日志其他历史对话一律不带。
11、不放心就 A 写、B 审、A 定向改想用便宜模型又怕质量翻车，可以走一个三角流程。A 负责写，B 只读代码做审查不改东西，A 根据 B 的意见定向修改。B 全程只读，不产生大量输出 Token，审查成本很低，质量却能兜住。
分工如下，A负责所有代码修改。B只读A的改动，输出审查意见，格式为问题、风险、建议，每项不超过2句。B不直接改代码。A根据B的意见做定向修改。
12、质量靠验收门槛守住，不靠模型自觉以上所有省 Token 的手段，前提都是质量不能掉。把验收标准写成硬门槛，模型过了才能停，不过就得继续，比事后返工便宜得多。 测试、构建、类型检查、截图对比，能自动判定的都写成门槛。
本次任务的验收门槛，1. 单元测试全部通过2. 构建零报错3. 类型检查零警告4. 页面截图与设计稿对比，差异点列出全部达标才算完成。达标后立即停止，不要额外优化。
13、分不清边界，就把常规模型设成默认很多人在多模型之间反复纠结，纠结本身也在浪费时间。一个务实的做法是，拿不准任务难度时，默认用中等档位的常规模型，效果不满意再升级，比自己猜要省心。
我的常规模型设为 GPT-5.6，档位中。只有任务明确标注为复杂时，才切换到最强模型。切换前先说明切换理由。
14、多开 Session 不天然省钱，简单任务别编排这条是给追新病用的。多 Session、多模型编排听着高级，但每个会话都有独立的上下文开销，简单任务硬要拆成多模型编排，钱花得更多，还更慢。 编排是为复杂任务服务的，不是省钱手段本身。
判断标准：任务能在单个会话内3轮对话内完成的，不拆分Session。不需要多角色协作的，不上多模型编排。只有长链路、多依赖的复杂任务才走编排。
15、Goal 模式前，先要一份施工清单Goal 模式适合长任务，但直接开跑容易跑偏，跑偏返工才是最大的浪费。 开工前先让它交施工清单，你确认过边界再放行。
在进入Goal模式前，先输出施工清单，1. 任务拆解，每一步做什么2. 每步需要哪些工具3. 预计修改哪些文件4. 哪些步骤可能需要人工确认清单经我确认后再开始执行。执行过程中不要偏离清单范围，超出范围先暂停请示。
16、记一笔账，别凭感觉最后这条最容易被忽略。觉得自己省了，和真的省了，经常是两回事。把每次的模型、档位、重试次数和总消耗记下来，跑一两周你就知道钱到底花在哪了，下个版本该砍什么一目了然。
每次任务结束后，在记录文件中追加一行，日期、任务名、使用的模型、推理档位、重试次数、输入token、输出token、总消耗。每周汇总一次，指出消耗最大的三个环节。
写在最后把这些策略连起来用，效果最好。
固定区加动态区保住缓存，medium 起步按需升档，盖楼垒砖分开派活，工具按需加载，长会话压缩，输出严格限制，编程智能体禁止重复验证，跨会话只带四样东西，简单任务别瞎编排，账本每周看一次。
模型不会替你省钱，会省钱的是安排任务的人。
另外补一句扎心的。如果你连自己要做什么都说不清，先去补相关知识或者问问别的模型把方向理顺，再回来干活，这本身就是最大的省 Token。别再许愿式地使唤大模型了，它不会读心术，但计费器会一直读你的钱包。
如果这篇对你有用，点个赞、在看，转发给那个最近在心疼账单的朋友。