Claude命令行Token配置：三类Token、参数调优与成本排查

1. Token 这件事先分清三种再谈配置很多人第一次打开 Claude 命令行CLI的配置文档时会以为Token 配置就是填一个密钥字符串填完回车就完事。真跑起来才发现报错是它、账单是它、输出被截断还是它。我在带新人的时候反复强调一句话在 Claude 命令行里Token 至少有三个完全不同的含义混着理解配置永远配不明白。这篇文章就是要把这三层拆开一层一层讲清楚该怎么配、为什么这么配、配错了会出现什么现象。适合刚接触命令行调用模型接口的朋友也适合已经能跑通、但账单和输出质量总是不对劲的中级使用者。先说清楚它能解决什么问题。当你用命令行方式调用模型时本质上是在做三件事证明我是谁、告诉模型最多能说多少话、以及为说出去的每一句话付钱。这三件事分别对应凭证、输出上限和计费额度业内习惯都叫 Token但它们的作用域完全不重叠。把这三者搞混最典型的后果是明明只想限制回答长度却把上下文窗口压到很小结果模型读不完你的文件或者反过来为了保险把上限拉到最大一个月下来账单翻了好几倍。我见过太多人在这里翻车原因往往不是技术难而是概念糊。下面这四小节就是把这团糊拆成四块干净的砖。1.1 计费 Token你真正花钱的那部分计费 Token 是模型处理文本的最小计量单位。它不是字也不是词而是一种介于字符和词之间的切分结果。一个粗略的经验值英文大约 4 个字符对应 1 个 Token中文因为编码方式不同通常 1 个汉字对应 1 到 2 个 Token标点和换行也各自计数。这个估算不精确但足够你心算成本。关键在于计费 Token 分成输入和输出两部分而且两者的单价通常不一样输出往往比输入贵数倍。这意味着同样是一万 Token 的消耗你让它读一万 Token 的资料和让它写一万 Token 的代码花的钱差距很大。新手最容易忽略的点就在这里他们只盯着我发了多长的提示词却没意识到模型返回的长篇解释才是成本大头。我建议你在任何一次正式调用之前先做一个动作把提示词和预期输出都粗略估算一遍 Token 数写在小本子上。跑完之后对照返回的用量字段看估算偏差有多大。做上五六次你对这段文字大概多少 Token就会有肌肉记忆后面所有参数配置都有据可依。另外要提醒的是多轮对话的成本是累加的。命令行里做连续对话时每一轮请求都会把之前的完整历史重新发一遍。第十轮对话的输入 Token 可能是第一轮的十倍以上。这是很多人账单突然爆掉却找不到原因的根源他们以为是模型变贵了其实是自己在为重复发送的历史买单。1.2 上下文 Token决定模型记得住多少上下文 Token 指的是模型在一次请求中能同时看到的总量上限包括你的系统提示、历史对话、粘贴的文件内容和它自己即将生成的回答。这是个硬性天花板超了就报错或者被静默截断。这里有个非常容易踩的坑上下文上限不等于输出上限。举例来说某个模型档位宣称支持很长的上下文但单次回答的长度上限是另一个更小的数字。你不能因为它能读很长就认为它能写很长。配置的时候输出上限那个参数必须单独设置而且必须留出足够的余量给输入。我的习惯是这样先确定这次任务需要喂进去多少资料比如一份 3 万 Token 的代码库摘要那么输入部分就占掉 3 万。然后再看模型档位允许的总窗口减去输入剩下的才是理论上可用的输出空间。如果剩余空间小于我需要的回答长度方案只有一个——要么切分输入要么换更大窗口的档位绝不能在参数上硬顶硬顶的结果就是报错。命令行工具通常会在启动时读取一个配置文件里面的上下文相关参数会被应用到每一次会话。如果你发现自己的 CLI 老是提示输入过长第一反应不应该是模型不行而是去翻配置文件看看是不是把窗口值设小了或者是历史记录累积太多没清理。1.3 凭证 TokenCLI 的通行证第三层是凭证。命令行工具没有浏览器那套登录态它需要一个字符串来证明调用方身份也就是我们常说的 API Key 或者访问令牌。这个字符串跟计费完全无关它只是门禁卡。凭证配置的核心矛盾只有一个便利性和安全性怎么平衡。直接写在命令行参数里最方便但会留在 shell 历史记录里写进配置文件最省事但如果这个文件被同步到公共仓库就是灾难每次手动输入最安全但你不会想这么干的。我个人的做法是分环境本地开发用环境变量注入配合一个只在当前终端会话生效的写法持续集成环境用平台自带的密钥管理功能绝不落地成文件共享机器上宁可多打一次命令也不留痕。这个分层策略后面第 2 章会展开讲具体写法。还有一点容易被忽略凭证是有作用范围和有效期的。有些密钥绑定了特定项目或者特定额度换一个工作目录就可能失效。遇到昨天还好好的今天就不行了的情况先别怀疑代码去确认凭证本身的状态。1.4 三种 Token 的对照速查把这三种概念放进一张表里很多困惑会立刻消解。类型作用配错后的典型现象调整入口计费 Token决定花多少钱账单远超预期单次费用异常输出上限、历史裁剪、缓存策略上下文 Token决定能看到多少内容输入过长报错长文档读不全窗口档位、文件切分、历史清理凭证 Token决定能不能调用鉴权失败无权限配额不足环境变量、配置文件、密钥管理看这张表你会发现三种 Token 的调整入口几乎不重叠。所以排查问题的第一步永远是先归类是调不通还是读不全还是花太多归类之后方向就明确了不用在三个方向上同时乱试。2. 上手前的环境准备把地基打平配置 Token 之前有几个前置条件必须先确认。我见过不少配置无效的求助最后查出来根本不是配置问题而是工具版本太老、运行时环境不对、或者工作目录里躺着一份优先级更高的旧配置文件。这章讲的就是怎么在动手之前把这些变量消掉。准备工作做扎实后面所有步骤都能一次过跳过这步你可能要在报错里泡一整个下午。这不是危言耸听命令行工具的配置加载是有优先级的多层配置叠加时你改的那一份很可能被另一份覆盖而你完全不知道它存在。2.1 版本与运行时的确认动作第一步永远是问工具本身你是什么版本。命令行工具大多支持版本查询参数跑一下把版本号记下来。这个数字后面排查问题时非常关键因为不同版本的配置键名、默认值、支持的能力都可能不同。第二步是确认运行时。如果这个 CLI 是基于某种脚本语言运行的那运行时的版本必须满足最低要求。老版本运行时可能出现的情况很隐蔽——工具能启动但读取配置时某些语法不被支持导致配置被静默忽略。这种问题最难查因为没有任何报错。第三步是确认工作目录。绝大多数 CLI 会从当前目录开始向上逐级查找配置文件找到第一个就用。这意味着你在 A 目录调试好的配置切到 B 目录之后可能完全失效因为 B 目录或者它的父目录里有一份别的配置。我的习惯是在项目根目录放一份显式的配置并在文档里写清楚以本目录这份为准避免团队里有人被上层目录的配置坑到。提示排查任何配置问题时先确认工具加载的是哪一份配置文件再确认里面的值是否被更高优先级的环境变量覆盖。这两步能解决八成以上的配置不生效。2.2 凭证的三种存放位置与取舍第一种环境变量。这是我最推荐给个人开发者的方式。优点是进程级隔离不会写入文件退出终端就失效。缺点是每开一个新终端都要重新设置容易忘。缓解办法是写进 shell 的启动脚本但要确保那个脚本本身不被版本控制追踪。第二种配置文件。适合需要长期保存的场景比如固定工作机。配置文件的关键是权限创建之后立刻把权限收紧到只有自己能读这个动作花不了两秒钟但能避免很多麻烦。同时务必确认这个文件在版本控制的忽略清单里我见过有人把带密钥的配置提交上去然后在日志里被人翻出来。第三种密钥管理服务。适合团队和自动化环境。它的好处是密钥不落地用完即弃还能按需轮换。代价是需要额外的初始化步骤对个人小项目来说有点重。选不选它看你的团队规模和合规要求。三种方式不是互斥的实际项目里常见的是组合本地开发用环境变量预发布环境用配置文件加权限控制生产环境用密钥管理。分层之后任何一层出问题都不会连累其他层。2.3 最小可用配置的样子在深入参数细节之前先把一个能跑起来的最小配置写出来让你有个可对照的锚点。通常只需要三样东西凭证、模型档位、输出上限。# 仅当前终端会话生效不落盘 export CLAUDE_API_KEY你的凭证字符串 export CLAUDE_MODEL你的模型档位 export CLAUDE_MAX_OUTPUT_TOKENS1024对应的配置文件写法多数 CLI 支持类似结构{ model: 你的模型档位, maxOutputTokens: 1024, temperature: 0.7 }注意这里的键名只是示意不同版本的 CLI 可能用不同的命名风格。拿到工具后第一件事是跑一次帮助命令看它自己列出的配置项名称不要照抄网上的旧文章。命名风格在版本之间变动是很常见的照抄的结果就是配置被当成未知键忽略掉而工具不会报错只会用默认值跑让你误以为配置生效了。这份最小配置的意义在于建立基线。先让它在最简状态下跑通一次看到正常的返回再往上叠加参数。一次只改一个变量改完立刻验证。这个笨办法能帮你准确定位每一个参数的真实效果比一次性堆十个配置项然后对着报错发呆高效得多。3. 核心参数逐个拆解每个数字背后的成本与效果参数配置这块我不打算给你一份抄了就完事的清单因为每个项目的输入长度、输出要求、预算都不一样机械照搬只会浪费钱。我更想讲清楚每个参数在干什么、调大调小分别会导致什么后果这样你自己就能算出该填多少。命令行场景下真正需要你操心的参数其实不超过五个。剩下的那些要么有合理默认值要么影响微乎其微。把精力集中在关键的几个上收益最大。3.1 模型档位与输出上限的绑定关系模型档位决定了能力天花板也决定了单次输出上限的上限。有的档位擅长快速响应和短输出有的档位支持更长的推理和更长的回答。你在配置里写的输出上限不能超过该档位允许的最大值超了会直接报参数错误。选择档位的判断标准我总结成三个问题这次任务需要多深的推理需要多长的输出预算是多少如果只是做格式转换、提取字段、简单分类这类任务低档位完全够用速度快、单价低没必要上高档位。如果是长文档分析、代码重构、多步推理那档位的差距会非常明显省下的钱抵不上返工的时间。我踩过的一个坑是为了省钱全项目都用最低档位结果在一个需要理解复杂业务逻辑的任务上模型反复给错答案我改了七八轮提示词都没用换成高档位一次就过。那次之后我算了一笔账反复调试消耗的 Token 加时间成本早就超过了直接用高档位的差价。档位选择的正确逻辑是按任务难度分层不是全局取最低。具体做法在项目里维护一张任务类型对照表明确哪类任务走哪个档位。这份表放在仓库里团队共用。长期看它比任何省钱技巧都管用因为大部分浪费来自用错档位而不是单价太高。3.2 输出上限到底该怎么算输出上限这个参数很多人是凭感觉填的。填小了回答说到一半被切断你还得重跑一次等于付了两遍钱填大了虽然不一定会用完但某些实现会按上限预留资源影响响应速度。我的计算方法分三步。第一步估算输入的 Token 数。把要发送的文本按字符数除以经验系数粗算中文按每字 1.5 个 Token 估英文按每 4 字符 1 个 Token 估加上系统提示和格式开销再乘一个 1.2 的安全系数。第二步估算你期望的输出长度。要一段两百字的总结就按 300 个 Token 留要一份完整代码文件就按文件实际规模算。第三步把输出上限设成期望值的 1.5 倍左右。为什么要留 1.5 倍余量因为模型有时候会先解释再给结果或者输出格式比你预期的啰嗦。留足余量能避免差一点点被截断这种最恶心的情况。但也不要设到十倍那没有意义只是让参数失去约束作用。举个例子。我要让它分析一份 5000 字的中文文档并输出一份 800 字的分析报告。输入大约 5000 × 1.5 7500 Token加系统提示算 8000。输出期望 800 字约 1200 Token乘 1.5 得 1800。那么输出上限设 2000 是合理的总窗口需求约 10000任何支持这个规模的档位都能跑。反过来如果那次调用被截断了返回值里通常会有一个表示因长度限制而停止的结束原因字段。看到这个字段你就知道该调大输出上限而不是怀疑模型能力。养成每次检查结束原因的习惯能省下大量无谓的调试。3.3 采样参数对消耗的隐性影响温度这类采样参数表面上跟 Token 数量无关实际上有间接影响。温度调高输出的随机性变强模型更容易跑偏、重复、发散从而生成更长的文本。我做过一个粗略对比同一个提示词低温下输出 400 Token 就收敛了高温下可能写到 900 Token 还在绕。差距超过一倍。所以当你在调创造性的时候其实也在调成本。对于需要确定性的任务比如信息抽取、格式转换、代码生成温度压低到接近零输出更紧凑、更可控、更省。对于需要发散的场景比如头脑风暴、文案变体才需要调高。还有一个参数控制候选词的筛选范围调小会让输出更保守。命令行场景下我一般不动它除非遇到输出重复、卡壳的情况。参数之间是会互相影响的一次只动一个改完跑三次看结果确认有效再动下一个。同时改两个参数你永远不知道是哪个起了作用。3.4 一份可以直接改的配置模板把上面的结论落成一份带注释的模板你按自己的场景改数字就行。{ model: 按任务难度选择档位, maxOutputTokens: 2000, temperature: 0.2, systemPrompt: 固定不变的前置说明放这里便于命中缓存, historyLimit: 6 }几个注释点。maxOutputTokens按 3.2 的三步法算别拍脑袋。temperature默认给低值需要发散时再单独提。systemPrompt内容越固定越好因为不变的前缀更容易被缓存机制命中长期看能省下可观的输入成本。historyLimit是多轮对话保留的轮数这个数字直接决定输入 Token 的增长曲线后面第 6 章会细说。这份模板不是终点是起点。跑通之后每次调整都记一笔改了什么、为什么改、结果如何。攒够十次记录你对这套参数的理解就超过大部分人了。4. 完整实操从零跑通一次可控调用理论讲完该动手了。这一章我把整个流程拆成四步每一步都有明确的产出物和验证方法。按顺序走中间任何一步失败都能立刻定位不用回头重来。我特意把读返回的用量字段单独列成一步因为太多人跑通就完事从来不看得返回了什么。用量字段是唯一能告诉你真实成本的来源不读它你所有的成本估算都是猜的。4.1 第一步凭证注入与环境自检先注入凭证然后立刻做一次自检确认它真的进去了。很多配置失败其实是环境变量没导出成功比如写在了子 shell 里、拼写有误、或者被同名变量覆盖。export CLAUDE_API_KEY你的凭证 # 检查长度不要打印完整内容 echo -n $CLAUDE_API_KEY | wc -c打印长度而不是内容这个习惯很重要。长度对得上说明变量有值长度是 0 说明没注入成功。如果长度明显不对比如只有几位那可能是复制的时候被截断了。这类低级错误我在不同的人身上见过至少十几次检查一次只要两秒钟能省掉半小时的困惑。再补一个动作确认当前目录没有其他配置文件在抢优先级。跑一次工具的配置查询命令看它报告的是哪份文件、哪些值生效。这一步做完你对当前环境的认知就是确定的后面出问题可以放心往参数方向查。4.2 第二步写一个带自检的调用脚本别直接在命令行里手打一长串参数写成脚本可复用、可版本管理、可加自检逻辑。下面是一个最小示例重点是里面的校验思路。import os import json key os.environ.get(CLAUDE_API_KEY) if not key: raise SystemExit(凭证未注入检查环境变量) model os.environ.get(CLAUDE_MODEL, 按需填写) max_out int(os.environ.get(CLAUDE_MAX_OUTPUT_TOKENS, 1024)) prompt 把下面这段文字压缩成三条要点 open(input.txt, encodingutf-8).read() payload { model: model, max_tokens: max_out, temperature: 0.2, messages: [{role: user, content: prompt}] } print(预计输入字符数:, len(prompt)) print(json.dumps(payload, ensure_asciiFalse)[:200])脚本里那两个print是刻意加的。第一个让你知道输入规模第二个让你看清实际拼出来的请求长什么样。很多人调试了半天其实提示词拼错了或者字段名写错了打印出来一眼就能发现。请求体的字段名一定要以你手上这个版本的文档为准不同版本之间字段命名有差异比如上限字段有的叫max_tokens有的叫max_output_tokens。写错字段名不会报错会被静默忽略然后你用的就是默认值行为跟预期完全不一样。这是最隐蔽的一类问题靠打印请求体来发现。4.3 第三步观察返回里的用量字段调用成功后返回结构里通常有一个用量对象包含输入 Token 数、输出 Token 数缓存命中的情况下还会多出缓存相关的字段。这三个数字是你所有的成本分析和参数调优的依据。我第一次认真看这个字段的时候很意外原来系统提示也计入输入原来我自以为很短的提示词实际消耗比估计高了三成。这种偏差光靠猜是永远猜不准的必须看真实数据。建议你建一个简单的记录表每次调用记一行任务类型、模型档位、输入 Token、输出 Token、缓存命中量、耗时。攒上二三十行你会发现一些很清楚的规律比如某类任务的输出总是远超预期某类提示词的缓存命中率特别高。这些规律直接指导你后面怎么优化。如果你不做记录所有的优化都是玄学。我看过太多人凭感觉调参今天觉得这样快明天觉得那样省钱最后一问数据什么都没有。记录本身就是最有效的优化手段因为它把模糊的直觉变成了可对比的事实。4.4 第四步把成本算成人民币有了用量数据成本就能算。计算方式是输入 Token 数乘以输入单价输出 Token 数乘以输出单价两者相加。不同档位单价不同输出单价通常是输入的几倍。具体数字请以你使用的服务当期公布的价目为准我这里只讲方法。关键不在于算出精确到分的数字而在于建立量级感。跑一次长文档分析你知道大概是几分钱还是几块钱这个判断力决定了你能不能在项目启动前估算出总预算。我一般用每千次调用成本这个口径来估算把单次成本乘以预期的日调用量看是否在可接受范围内。如果算下来超预算优化的顺序是这样的先看能不能降档位再看能不能减输出长度再看能不能提高缓存命中率最后才考虑减少调用次数。这个顺序是有讲究的——前两项不损失功能后两项会损失功能。很多人一上来就砍调用次数把有用的功能砍掉了其实稍微压一下输出上限就能省下大部分钱。5. 报错与异常排查实录排查这件事最怕的是没有方向地乱试。我的原则是先归类再动手调不通、读不全、花太多这三类问题对应的排查路径完全不同。下面按错误类型整理出来都是我在实际项目里真实碰到过的。5.1 鉴权类问题明明填了却说没有最常见的现象是返回一个表示未授权的状态码提示凭证无效或缺失。排查顺序第一确认环境变量真的注入了用打印长度的方法验证第二确认凭证本身没过期、没被轮换、没被撤销第三确认这个凭证有权限调用你指定的档位有些凭证绑定了项目范围。还有一个很隐蔽的情况配置文件和环境变量同时存在且值不一样。工具通常有明确的优先级规则但如果你不知道规则就会觉得我明明改了啊。解决办法是只保留一处配置其他全部清掉把变量降到最少。最后一种配置文件里多了空格或者引号。凭证字符串被引号包裹时某些实现会连引号一起当成凭证内容导致校验失败。遇到这种情况把引号去掉再试一次。5.2 参数类问题400 背后的十种可能参数错误的状态码通常是同一个但原因可以有很多种。我按出现频率排了个序。现象可能原因处理方式提示模型不存在档位名称拼错或该档位不可用用工具自带的列表命令确认名称提示上限超范围输出上限超过该档位允许值降到档位允许的最大值以内提示输入过长输入加输出超出窗口切分输入或减少历史轮数提示字段非法参数键名写错或类型不对打印请求体逐一核对提示格式错误消息结构不符合要求确认角色和内容字段层级这张表里最值得说的是输入过长。它经常不是因为你真的发了太多内容而是历史记录没清理。跑了几十轮对话之后每一轮都在重发全部历史很快就顶到天花板。解决办法是给历史设一个轮数上限或者做摘要压缩。5.3 频率与配额类问题返回限流状态码说明触发了调用频率或者额度限制。这种情况的正确处理是退避重试不是立刻重发。立刻重发只会让情况更糟还可能被判定为异常行为。我的重试策略是阶梯式第一次等一秒第二次等两秒第三次等四秒最多重试三次。同时给整个批次加一个总时长上限避免卡死在某个请求上。这套逻辑写进脚本里比每次手动重跑省心得多。额度耗尽是另一回事它不会自己恢复需要去后台查看剩余额度或者调整配额。区分方法很简单限流重试几次能过额度耗尽重试多少次都过不了。5.4 输出被截断不报错但最坑这个必须单独讲因为它不返回错误码很容易被当成模型能力不行。判断依据是返回的结束原因字段如果是长度限制导致的停止你就知道问题在哪。三种处理方式按优先级第一种提高输出上限前提是窗口还有余量第二种把任务拆成多次比如让它先给大纲再逐段展开第三种在提示词里明确要求用不超过多少字回答用指令约束代替参数约束。我常用的组合是第二种加第三种。先约束输出规模再给足上限余量两头夹住。实测下来被截断的概率能降到很低。单纯调大上限而不约束内容模型可能依然啰嗦钱花了还没拿到想要的结果。5.5 一份可以贴在显示器旁边的速查清单下面这几条是我排查时的固定动作按顺序做大部分问题三步内能定位。打印凭证长度确认非空且长度合理跑配置查询命令确认加载的是哪份文件打印请求体核对字段名与类型看返回的结束原因区分是报错还是截断读用量字段确认输入输出规模是否符合预期换最小提示词重试排除内容本身的问题最后一条特别有用。换个最简单的输入还报错吗这个问题能把问题范围一刀切成两半还报错是配置或环境问题不报错是内容或参数规模问题。这个二分法我用得最多几乎百试百灵。6. 省钱提速的实战心得前面讲的都是怎么正确配这一章讲怎么配得划算。这两件事不一样正确是及格线划算是竞争力。同样的任务不同配置下的成本差距可以到好几倍而这个差距完全来自配置策略而不是模型能力。我把自己项目里验证过的几条经验整理出来都是可以直接落地的不需要额外工具只改配置和调用方式。6.1 让固定的前缀尽量被缓存命中缓存机制的原理是如果多次请求的前缀内容完全一致服务端可以复用之前的处理结果对这部分内容按更低的费率计费。这意味着把不变的内容放在最前面把变化的内容放在最后面是一个纯赚不赔的优化。具体怎么做系统提示写死在配置里不要每次动态拼接时间戳或者随机串长文档如果反复使用把它放在提示词的最前面问题放在最后面不要在小改动里改变前缀的措辞一个标点变化都可能导致缓存失效。我做过一个对比同一份两万字的参考资料反复问二十个问题。不缓存的情况下二十次请求每次都重新处理两万字把资料固定在提示词前缀之后后续请求的输入成本明显下降。这个优化不需要改代码逻辑只调整拼接顺序就行投入产出比极高。要注意的是缓存有有效期隔太久会失效。批量处理任务时尽量集中在一个时间窗口内跑完别今天跑一半明天跑一半。6.2 长文档的切片策略文档超过窗口限制时新手的做法是硬切切成等长的块分别处理。这样做的后果是上下文断裂模型看不到跨段落的关联回答质量明显下降。我用的策略是三层。第一层先让模型生成一份结构化摘要把摘要作为后续所有请求的公共前缀这样每次请求只需要带摘要加当前片段成本大幅下降。第二层切片时保留一定的重叠区域比如每块结尾多带两百字保证边界处的语义连贯。第三层最后做一次汇总请求把各块的处理结果合并成整体结论。这套流程听起来步骤多但总成本通常比硬塞进去更低因为每次请求的输入都很小而且摘要部分还能命中缓存。质量控制上也更好因为每块的处理都是聚焦的模型不容易在长文本里迷路。切片大小的经验值单块控制在窗口容量的三分之一左右留出足够的空间给输出。切太大输出空间不够切太小请求次数太多每次都要付固定的系统提示成本。6.3 多轮对话的历史管理多轮对话是成本失控的重灾区。每一轮都要重发全部历史第十轮的输入是第一轮的十倍。如果不做管理一个稍微长一点的会话就能吃掉大量额度。我的做法是滑动窗口加摘要的组合。保留最近若干轮原文更早的内容压缩成一段摘要插在系统提示后面。这样既保住了近期上下文又不至于无限膨胀。{ historyLimit: 6, summarizeBeyondLimit: true, summaryMaxTokens: 300 }轮数上限设多少合适我一般设 6 到 8 轮。超过之后对话的连贯性收益递减但成本线性上升。如果任务确实需要很长的上下文那就不是多轮对话该解决的问题了应该改成一次性把关键信息整理好发过去。还有一个细节历史里的大段文件内容用完之后要主动清掉。很多人把整份文件粘进对话后面十几轮都在为这份文件反复付费。正确做法是处理完就把它从历史里摘出来只保留结论。6.4 我自己踩过的一个坑最后分享一个真实的教训。有段时间我发现某类批处理任务的成本异常高查了半天参数都觉得没问题档位也是最低的输出上限也很紧。后来把每次请求的用量字段拉出来逐条比对才找到原因提示词里带了一个每次都会变的请求编号导致缓存永远无法命中每次都在全量重新处理前缀。那个编号是我为了排查日志方便加进去的当时觉得无伤大雅实际代价是整批任务的输入成本翻了好几倍。把它从提示词前缀挪到请求的元数据字段之后缓存立刻恢复命中成本降下来了日志也没受影响。这件事之后我形成了一个习惯任何要放进提示词的内容都先问一句它需要每次都变吗。如果不需要就固定住如果需要就往后挪别放在前缀里。这个检查动作只花几秒钟但它拦住的是最容易忽视、代价又最高的一类浪费。配 Token 这件事说到底不是把数字填对就完了而是要清楚每个数字在为什么服务。你填的每一个上限背后是对成本的约束你设的每一个缓存策略背后是对重复劳动的消除。想清楚这一层剩下的就是按部就班地试、记录、再调整。