1. 省 token 这件事为什么越省越亏先把结论摆在前面在 Claude Code 这类按 token 计费的编码代理里盲目压缩上下文、砍掉重试预算、把 effort 调到最低短期看账单确实好看但只要触发一次失败重试前面省下来的全部吐回去甚至倒贴。这个账我算过很多次。假设你一次任务正常消耗 8 万 token其中输入占大头。你把 effort 从 high 降到 low单次可能压到 5 万省了 37%。听起来很香。但问题是effort 降低之后模型对复杂任务的规划能力下降第一次跑出来的代码大概率有结构性错误——不是少个分号那种小错而是目录结构、依赖关系、接口签名全错。你让它重试它得把整个上下文重新读一遍包括之前所有的文件内容、对话历史、工具调用结果。这一次重试的输入 token 往往比第一次还多因为上下文里多了上次失败的输出和错误信息。我实测过一组数据同一个重构任务策略首次消耗是否一次通过重试次数总消耗efforthigh完整上下文82k是082keffortlow裁剪上下文51k否251k 74k 68k 193keffortmedium适度裁剪63k是063k省了 31k赔了 111k。这就是标题说的省过头一次重试就全赔回去。关键在于token 成本不是线性的而是和任务一次成功率强相关的。你把单次成本压得越低往往意味着给模型的信息越少、思考预算越紧一次成功率就越低。而重试的成本是叠加的不是重置的。很多人算账的时候只算了单次没算期望值。正确的算法应该是期望总成本 单次成本 / 一次成功率。effortlow 时单次 51k但一次成功率可能只有 40%期望成本就是 127kefforthigh 单次 82k一次成功率 85%期望成本 96k。谁更省一目了然。所以这篇不是教你怎么把 token 压到最低而是教你怎么在 token 预算和一次成功率之间找到那个真正的甜点以及当重试不可避免时怎么让重试的代价最小。2. 缓存命中率才是真正的省钱杠杆聊 token 成本绕不开缓存。Claude Code 的计费里缓存读取的 token 价格通常只有正常输入 token 的十分之一左右缓存写入则比正常输入略贵。这个价差结构决定了真正会省钱的人不是把上下文砍短而是把稳定的前缀内容喂给缓存。2.1 什么内容该进缓存什么内容不该进缓存的基本逻辑是前缀匹配从对话最开始往后只要内容逐字节一致就能命中缓存。一旦某个位置出现差异后面全部失效。所以你要做的是把不变的东西放前面变的东西放后面。该进缓存的系统提示词、角色设定、项目规范代码库的目录结构说明、核心接口定义长期不变的架构文档、编码约定工具定义tool schema不该进缓存的每次都在变的用户指令实时读取的文件内容尤其是频繁改动的文件时间戳、随机 ID、临时路径我见过最常见的反模式是把当前时间或者本次会话 ID塞在系统提示词开头。这一下就把整个缓存前缀打碎了后面几千 token 的规范文档全部无法命中。改法很简单把这类动态字段挪到用户消息里或者干脆去掉。2.2 缓存失效的几种隐蔽触发点缓存失效不总是因为内容变了有些触发点很隐蔽文件读取顺序变化同样的文件集合如果读取顺序不同拼出来的上下文就不同缓存直接失效。解决办法是固定文件遍历顺序比如按路径字典序。工具调用结果的格式抖动比如 JSON 序列化时 key 的顺序不稳定或者浮点数精度表示不一致都会导致前缀不匹配。空白字符和换行差异Windows 的 CRLF 和 Unix 的 LF 混用肉眼看不出来缓存全废。模型版本切换不同模型版本的缓存是不共享的切模型等于缓存清零。提示如果你发现账单里缓存命中率突然掉到很低先别急着改 prompt去检查是不是有动态字段混进了前缀区或者文件读取顺序不稳定。2.3 用缓存把重试成本压下来重试之所以贵是因为它要把整个上下文重新输入一遍。但如果你的前缀缓存是有效的重试时那部分内容走的是缓存价成本能降到十分之一。这就是为什么**缓存友好比上下文短更重要**。一个实用的做法把项目里最稳定的那部分内容——比如架构说明、核心模块的接口签名、编码规范——单独整理成一个文件固定在上下文最前面。这样无论你后面怎么折腾这部分永远命中缓存。重试的时候真正按全价计费的只有新增的失败输出和错误信息。我自己的项目里这个稳定前缀大概占 15k token。命中缓存后这部分每次实际成本相当于 1.5k。重试三次也就多花 4.5k 的等效成本完全可以接受。反过来如果你为了省这 15k 把它删了模型每次都要重新理解项目结构一次成功率暴跌重试成本反而更高。3. effort 参数不是越低越划算effort 这个参数控制的是模型在推理时投入的思考预算。调低它模型生成的中间推理步骤变少输出更快、更短、更便宜。但代价是复杂任务的规划质量下降。3.1 什么任务适合低 effort不是所有任务都需要高 effort。判断标准很简单这个任务需不需要多步规划适合低 effort 的单文件的小改动比如改个函数名、加个日志格式转换、简单的代码补全明确的、无歧义的替换操作生成样板代码、配置文件这些任务路径清晰模型不需要反复权衡低 effort 完全够用而且省得实实在在。不适合低 effort 的跨多文件的架构重构需要理解复杂业务逻辑的 bug 修复涉及多个模块交互的新功能开发需要权衡多种方案的技术选型这些任务一旦 effort 不够模型容易想当然给出看起来对但实际跑不通的方案。你省下的那点 token会在重试里加倍还回去。3.2 我的 effort 分级实践我现在的做法是按任务类型分三档任务类型effort理由单文件小改、格式调整low路径明确不需要规划常规功能开发、局部重构medium需要一定规划但边界清晰跨模块重构、复杂 bughigh规划质量直接决定成败关键是别一刀切。很多人为了省 token 全局设成 low结果复杂任务频繁失败。正确的做法是让 effort 跟着任务复杂度走。还有一个技巧先让模型做规划再执行。对于复杂任务我会先让它输出一个执行计划我确认没问题之后再让它动手。这样即使 effort 是 medium规划阶段的质量也有保障执行阶段反而不容易出错。规划本身的 token 消耗很小但能大幅提升一次成功率。3.3 effort 和重试的耦合关系这里有个容易被忽略的点effort 越低重试时的上下文膨胀越严重。为什么因为低 effort 下模型输出的错误方案往往更离谱错误信息更多你纠正它的时候要解释的东西也更多。而高 effort 下即使出错也通常是接近正确的方案差一点点纠正起来一句话就够。我遇到过极端情况low effort 下模型把一个模块的依赖搞反了导致连锁报错我花了三轮对话才把它拉回正轨总消耗是 high effort 一次成功的四倍。从那以后我就明白了effort 省的是单次赔的是重试而重试的膨胀系数在低 effort 下更高。4. 一次重试到底贵在哪里很多人对重试成本没有概念觉得不就是再跑一遍吗。实际上重试的成本结构比首次执行复杂得多。4.1 重试的上下文是叠加的首次执行时上下文里只有系统提示 项目背景 任务描述 相关文件。重试时上下文里多了上次的完整输出 错误信息 你的纠正说明 可能新增的文件读取。也就是说重试的输入 token ≈ 首次输入 首次输出 错误上下文。如果首次输出是 5k错误上下文 3k那重试的输入就比首次多了 8k。这 8k 还是按全价算的除非命中缓存。更麻烦的是如果重试又失败了第三次的上下文会继续膨胀。这就是为什么省过头的策略会雪崩——单次省的那点在第二次、第三次重试里被成倍放大。4.2 重试还会污染后续任务一次失败的重试不只是这一次任务变贵。它产生的错误输出、错误代码、错误理解会留在对话历史里。如果你接着做下一个任务模型可能会被之前的错误上下文带偏导致后续任务也容易出错。我踩过这个坑一个重构任务失败两次后我放弃重试直接开始新任务。结果模型一直记得之前那个错误的架构理解新任务也按错误的方向做。最后我不得不清空会话重来前面所有上下文全部作废。所以重试的隐性成本还包括上下文污染。一旦发现某个方向彻底错了及时止损、清空重来往往比硬着头皮重试更省。4.3 重试成本的量化估算给你一个粗略的估算公式方便你判断该不该重试重试总成本 ≈ (首次输入 首次输出 错误上下文) × 重试次数 清空重来成本 ≈ 首次输入 × 1重新建立上下文当重试次数 × (首次输入 首次输出 错误上下文) 首次输入 × 2时清空重来更划算。举个例子首次输入 50k首次输出 5k错误上下文 3k。重试一次的成本是 58k。如果预计要重试两次以上总成本超过 116k而清空重来只需要 50k 重新建立上下文。这时候果断清空。注意清空重来的前提是你的稳定前缀缓存还在。如果缓存也失效了清空的成本会更高需要重新权衡。5. 让重试变便宜的几个实操手段既然重试不可避免那就想办法让每次重试都便宜。核心思路是把重试的增量成本压到最低把可缓存的部分最大化。5.1 把失败输出精简后再喂回去模型上次的错误输出没必要原封不动地塞回上下文。你可以只保留关键部分报错信息、出错的代码片段、你的纠正说明。把那些冗长的、无关的推理过程删掉。我通常这样做让模型自己总结上次失败的原因然后只把这段总结和错误信息放进重试上下文。这样能把重试的增量从 8k 压到 2k 左右。5.2 用文件引用代替文件内容如果重试涉及的文件没变不要在上下文里重复粘贴文件内容而是用文件路径引用。让模型自己去读。这样文件内容走的是工具调用而不是直接进上下文缓存和计费都更友好。当然这有个前提你的工具调用结果也要能被缓存。如果每次读取的文件内容都一样理论上可以命中缓存。但如果文件在两次重试之间被改动了缓存就失效了。5.3 固定重试的锚点重试时尽量保持上下文的前缀不变只改最后那部分纠正说明。这样前面的缓存还能命中。具体做法是把纠正说明放在对话的最后不要插到中间去。中间插入内容会破坏前缀匹配。我见过有人为了让模型看清楚把错误信息插到系统提示后面。这一插整个缓存前缀全废。正确做法是追加到末尾。5.4 设置重试上限及时止损给自己定个规矩同一个任务重试不超过两次。两次还搞不定说明要么任务描述有问题要么模型能力不够要么方向根本错了。这时候继续重试就是烧钱。止损之后怎么办三个选择拆解任务把大任务拆成几个小任务分别做换更高的 effort 重新来一次人工介入把关键部分自己写好让模型只做辅助我个人的经验是拆解任务的成功率最高。一个复杂的重构任务拆成先改接口定义再改实现最后改调用方三步每步都是 medium effort 一次过总成本比 high effort 硬啃一次还低。6. 一套可复用的 token 预算配置说了这么多原理最后给一套我实际在用的配置你可以直接抄。6.1 上下文分层把上下文分成三层稳定层放最前面进缓存系统提示、项目规范、架构说明、核心接口定义。这部分控制在 10-20k一次写好长期复用。半稳定层放中间当前任务相关的文件内容、模块说明。这部分按任务变化但同一个任务内保持稳定。动态层放最后用户指令、错误信息、纠正说明。这部分每次都可能变放最后不影响前面缓存。6.2 effort 选择决策树任务是否跨多文件 ├─ 否 → 是否涉及复杂逻辑 │ ├─ 否 → low │ └─ 是 → medium └─ 是 → 是否需要架构级规划 ├─ 否 → medium └─ 是 → high6.3 重试决策规则第一次失败分析原因如果是小问题重试一次medium/high effort第二次失败停止重试评估是拆解任务还是清空重来任何情况下重试不超过两次6.4 监控指标定期看这几个数缓存命中率低于 60% 就要检查前缀是不是被污染了一次成功率低于 70% 说明 effort 或上下文配置有问题平均重试次数超过 1.5 说明任务拆解不够细我按这套配置跑下来token 成本比之前无脑省的策略低了大概 40%而且任务完成质量明显更稳定。省 token 的正确姿势从来不是砍而是让每一次调用都值得。7. 几个我踩过的具体坑最后分享几个真实踩过的坑都是文档里不会写的。坑一为了省 token 把项目结构说明删了。结果模型每次都要花大量 token 去探索目录结构而且经常找错文件。加上结构说明后虽然前缀多了 3k但探索成本省了 10k 以上。坑二在系统提示里放了动态的当前分支名。每次切分支缓存全失效。后来把分支名挪到用户消息里缓存命中率从 30% 涨到 85%。坑三重试时把整个错误日志贴进去。一个报错日志 20k token贴了三次就是 60k。后来改成只贴关键几行加一句总结重试成本直接砍半。坑四以为 effortlow 一定便宜。在一个跨模块重构任务上用了 low失败三次总消耗是 high 一次成功的三倍。这个教训最贵。坑五缓存失效了不知道。有段时间账单突然涨了查了半天才发现是文件读取顺序不稳定导致的。固定顺序后恢复正常。这些坑的共同点是省 token 的动作本身制造了更大的 token 消耗。省 token 是个系统工程不是单点优化。你得看整体期望成本而不是单次账单。 1. 省 token 这件事为什么越省越亏先把结论摆在前面在 Claude Code 这类按 token 计费的编码代理里盲目压缩上下文、砍掉重试预算、把 effort 调到最低短期看账单确实好看但只要触发一次失败重试前面省下来的全部吐回去甚至倒贴。这个账我算过很多次。假设你一次任务正常消耗 8 万 token其中输入占大头。你把 effort 从 high 降到 low单次可能压到 5 万省了 37%。听起来很香。但问题是effort 降低之后模型对复杂任务的规划能力下降第一次跑出来的代码大概率有结构性错误——不是少个分号那种小错而是目录结构、依赖关系、接口签名全错。你让它重试它得把整个上下文重新读一遍包括之前所有的文件内容、对话历史、工具调用结果。这一次重试的输入 token 往往比第一次还多因为上下文里多了上次失败的输出和错误信息。我实测过一组数据同一个重构任务策略首次消耗是否一次通过重试次数总消耗efforthigh完整上下文82k是082keffortlow裁剪上下文51k否251k 74k 68k 193keffortmedium适度裁剪63k是063k省了 31k赔了 111k。这就是标题说的省过头一次重试就全赔回去。关键在于token 成本不是线性的而是和任务一次成功率强相关的。你把单次成本压得越低往往意味着给模型的信息越少、思考预算越紧一次成功率就越低。而重试的成本是叠加的不是重置的。很多人算账的时候只算了单次没算期望值。正确的算法应该是期望总成本 单次成本 / 一次成功率。effortlow 时单次 51k但一次成功率可能只有 40%期望成本就是 127kefforthigh 单次 82k一次成功率 85%期望成本 96k。谁更省一目了然。所以这篇不是教你怎么把 token 压到最低而是教你怎么在 token 预算和一次成功率之间找到那个真正的甜点以及当重试不可避免时怎么让重试的代价最小。2. 缓存命中率才是真正的省钱杠杆聊 token 成本绕不开缓存。Claude Code 的计费里缓存读取的 token 价格通常只有正常输入 token 的十分之一左右缓存写入则比正常输入略贵。这个价差结构决定了真正会省钱的人不是把上下文砍短而是把稳定的前缀内容喂给缓存。2.1 什么内容该进缓存什么内容不该进缓存的基本逻辑是前缀匹配从对话最开始往后只要内容逐字节一致就能命中缓存。一旦某个位置出现差异后面全部失效。所以你要做的是把不变的东西放前面变的东西放后面。该进缓存的系统提示词、角色设定、项目规范代码库的目录结构说明、核心接口定义长期不变的架构文档、编码约定工具定义tool schema不该进缓存的每次都在变的用户指令实时读取的文件内容尤其是频繁改动的文件时间戳、随机 ID、临时路径我见过最常见的反模式是把当前时间或者本次会话 ID塞在系统提示词开头。这一下就把整个缓存前缀打碎了后面几千 token 的规范文档全部无法命中。改法很简单把这类动态字段挪到用户消息里或者干脆去掉。2.2 缓存失效的几种隐蔽触发点缓存失效不总是因为内容变了有些触发点很隐蔽文件读取顺序变化同样的文件集合如果读取顺序不同拼出来的上下文就不同缓存直接失效。解决办法是固定文件遍历顺序比如按路径字典序。工具调用结果的格式抖动比如 JSON 序列化时 key 的顺序不稳定或者浮点数精度表示不一致都会导致前缀不匹配。空白字符和换行差异Windows 的 CRLF 和 Unix 的 LF 混用肉眼看不出来缓存全废。模型版本切换不同模型版本的缓存是不共享的切模型等于缓存清零。提示如果你发现账单里缓存命中率突然掉到很低先别急着改 prompt去检查是不是有动态字段混进了前缀区或者文件读取顺序不稳定。2.3 用缓存把重试成本压下来重试之所以贵是因为它要把整个上下文重新输入一遍。但如果你的前缀缓存是有效的重试时那部分内容走的是缓存价成本能降到十分之一。这就是为什么**缓存友好比上下文短更重要**。一个实用的做法把项目里最稳定的那部分内容——比如架构说明、核心模块的接口签名、编码规范——单独整理成一个文件固定在上下文最前面。这样无论你后面怎么折腾这部分永远命中缓存。重试的时候真正按全价计费的只有新增的失败输出和错误信息。我自己的项目里这个稳定前缀大概占 15k token。命中缓存后这部分每次实际成本相当于 1.5k。重试三次也就多花 4.5k 的等效成本完全可以接受。反过来如果你为了省这 15k 把它删了模型每次都要重新理解项目结构一次成功率暴跌重试成本反而更高。3. effort 参数不是越低越划算effort 这个参数控制的是模型在推理时投入的思考预算。调低它模型生成的中间推理步骤变少输出更快、更短、更便宜。但代价是复杂任务的规划质量下降。3.1 什么任务适合低 effort不是所有任务都需要高 effort。判断标准很简单这个任务需不需要多步规划适合低 effort 的单文件的小改动比如改个函数名、加个日志格式转换、简单的代码补全明确的、无歧义的替换操作生成样板代码、配置文件这些任务路径清晰模型不需要反复权衡低 effort 完全够用而且省得实实在在。不适合低 effort 的跨多文件的架构重构需要理解复杂业务逻辑的 bug 修复涉及多个模块交互的新功能开发需要权衡多种方案的技术选型这些任务一旦 effort 不够模型容易想当然给出看起来对但实际跑不通的方案。你省下的那点 token会在重试里加倍还回去。3.2 我的 effort 分级实践我现在的做法是按任务类型分三档任务类型effort理由单文件小改、格式调整low路径明确不需要规划常规功能开发、局部重构medium需要一定规划但边界清晰跨模块重构、复杂 bughigh规划质量直接决定成败关键是别一刀切。很多人为了省 token 全局设成 low结果复杂任务频繁失败。正确的做法是让 effort 跟着任务复杂度走。还有一个技巧先让模型做规划再执行。对于复杂任务我会先让它输出一个执行计划我确认没问题之后再让它动手。这样即使 effort 是 medium规划阶段的质量也有保障执行阶段反而不容易出错。规划本身的 token 消耗很小但能大幅提升一次成功率。3.3 effort 和重试的耦合关系这里有个容易被忽略的点effort 越低重试时的上下文膨胀越严重。为什么因为低 effort 下模型输出的错误方案往往更离谱错误信息更多你纠正它的时候要解释的东西也更多。而高 effort 下即使出错也通常是接近正确的方案差一点点纠正起来一句话就够。我遇到过极端情况low effort 下模型把一个模块的依赖搞反了导致连锁报错我花了三轮对话才把它拉回正轨总消耗是 high effort 一次成功的四倍。从那以后我就明白了effort 省的是单次赔的是重试而重试的膨胀系数在低 effort 下更高。4. 一次重试到底贵在哪里很多人对重试成本没有概念觉得不就是再跑一遍吗。实际上重试的成本结构比首次执行复杂得多。4.1 重试的上下文是叠加的首次执行时上下文里只有系统提示 项目背景 任务描述 相关文件。重试时上下文里多了上次的完整输出 错误信息 你的纠正说明 可能新增的文件读取。也就是说重试的输入 token ≈ 首次输入 首次输出 错误上下文。如果首次输出是 5k错误上下文 3k那重试的输入就比首次多了 8k。这 8k 还是按全价算的除非命中缓存。更麻烦的是如果重试又失败了第三次的上下文会继续膨胀。这就是为什么省过头的策略会雪崩——单次省的那点在第二次、第三次重试里被成倍放大。4.2 重试还会污染后续任务一次失败的重试不只是这一次任务变贵。它产生的错误输出、错误代码、错误理解会留在对话历史里。如果你接着做下一个任务模型可能会被之前的错误上下文带偏导致后续任务也容易出错。我踩过这个坑一个重构任务失败两次后我放弃重试直接开始新任务。结果模型一直记得之前那个错误的架构理解新任务也按错误的方向做。最后我不得不清空会话重来前面所有上下文全部作废。所以重试的隐性成本还包括上下文污染。一旦发现某个方向彻底错了及时止损、清空重来往往比硬着头皮重试更省。4.3 重试成本的量化估算给你一个粗略的估算公式方便你判断该不该重试重试总成本 ≈ (首次输入 首次输出 错误上下文) × 重试次数 清空重来成本 ≈ 首次输入 × 1重新建立上下文当重试次数 × (首次输入 首次输出 错误上下文) 首次输入 × 2时清空重来更划算。举个例子首次输入 50k首次输出 5k错误上下文 3k。重试一次的成本是 58k。如果预计要重试两次以上总成本超过 116k而清空重来只需要 50k 重新建立上下文。这时候果断清空。注意清空重来的前提是你的稳定前缀缓存还在。如果缓存也失效了清空的成本会更高需要重新权衡。5. 让重试变便宜的几个实操手段既然重试不可避免那就想办法让每次重试都便宜。核心思路是把重试的增量成本压到最低把可缓存的部分最大化。5.1 把失败输出精简后再喂回去模型上次的错误输出没必要原封不动地塞回上下文。你可以只保留关键部分报错信息、出错的代码片段、你的纠正说明。把那些冗长的、无关的推理过程删掉。我通常这样做让模型自己总结上次失败的原因然后只把这段总结和错误信息放进重试上下文。这样能把重试的增量从 8k 压到 2k 左右。5.2 用文件引用代替文件内容如果重试涉及的文件没变不要在上下文里重复粘贴文件内容而是用文件路径引用。让模型自己去读。这样文件内容走的是工具调用而不是直接进上下文缓存和计费都更友好。当然这有个前提你的工具调用结果也要能被缓存。如果每次读取的文件内容都一样理论上可以命中缓存。但如果文件在两次重试之间被改动了缓存就失效了。5.3 固定重试的锚点重试时尽量保持上下文的前缀不变只改最后那部分纠正说明。这样前面的缓存还能命中。具体做法是把纠正说明放在对话的最后不要插到中间去。中间插入内容会破坏前缀匹配。我见过有人为了让模型看清楚把错误信息插到系统提示后面。这一插整个缓存前缀全废。正确做法是追加到末尾。5.4 设置重试上限及时止损给自己定个规矩同一个任务重试不超过两次。两次还搞不定说明要么任务描述有问题要么模型能力不够要么方向根本错了。这时候继续重试就是烧钱。止损之后怎么办三个选择拆解任务把大任务拆成几个小任务分别做换更高的 effort 重新来一次人工介入把关键部分自己写好让模型只做辅助我个人的经验是拆解任务的成功率最高。一个复杂的重构任务拆成先改接口定义再改实现最后改调用方三步每步都是 medium effort 一次过总成本比 high effort 硬啃一次还低。6. 一套可复用的 token 预算配置说了这么多原理最后给一套我实际在用的配置你可以直接抄。6.1 上下文分层把上下文分成三层稳定层放最前面进缓存系统提示、项目规范、架构说明、核心接口定义。这部分控制在 10-20k一次写好长期复用。半稳定层放中间当前任务相关的文件内容、模块说明。这部分按任务变化但同一个任务内保持稳定。动态层放最后用户指令、错误信息、纠正说明。这部分每次都可能变放最后不影响前面缓存。6.2 effort 选择决策树任务是否跨多文件 ├─ 否 → 是否涉及复杂逻辑 │ ├─ 否 → low │ └─ 是 → medium └─ 是 → 是否需要架构级规划 ├─ 否 → medium └─ 是 → high6.3 重试决策规则第一次失败分析原因如果是小问题重试一次medium/high effort第二次失败停止重试评估是拆解任务还是清空重来任何情况下重试不超过两次6.4 监控指标定期看这几个数缓存命中率低于 60% 就要检查前缀是不是被污染了一次成功率低于 70% 说明 effort 或上下文配置有问题平均重试次数超过 1.5 说明任务拆解不够细我按这套配置跑下来token 成本比之前无脑省的策略低了大概 40%而且任务完成质量明显更稳定。省 token 的正确姿势从来不是砍而是让每一次调用都值得。7. 几个我踩过的具体坑最后分享几个真实踩过的坑都是文档里不会写的。坑一为了省 token 把项目结构说明删了。结果模型每次都要花大量 token 去探索目录结构而且经常找错文件。加上结构说明后虽然前缀多了 3k但探索成本省了 10k 以上。坑二在系统提示里放了动态的当前分支名。每次切分支缓存全失效。后来把分支名挪到用户消息里缓存命中率从 30% 涨到 85%。坑三重试时把整个错误日志贴进去。一个报错日志 20k token贴了三次就是 60k。后来改成只贴关键几行加一句总结重试成本直接砍半。坑四以为 effortlow 一定便宜。在一个跨模块重构任务上用了 low失败三次总消耗是 high 一次成功的三倍。这个教训最贵。坑五缓存失效了不知道。有段时间账单突然涨了查了半天才发现是文件读取顺序不稳定导致的。固定顺序后恢复正常。这些坑的共同点是省 token 的动作本身制造了更大的 token 消耗。省 token 是个系统工程不是单点优化。你得看整体期望成本而不是单次账单。