1. 从一次账单惊吓说起为什么要做这次迁移去年年底对账的时候我发现一个个人项目的月度 API 支出悄悄爬到了四位数。项目本身并不复杂就是一个跑在本地的小型代码助手日常帮我做几件事读代码、改 bug、写测试、偶尔生成一些脚本。按理说这种轻量级用法不该烧这么多钱但账单不会骗人。我把调用日志拉出来逐条分析发现问题出在两个地方。第一每次请求携带的系统提示词system prompt长得离谱光这一块就稳定占用一万四千多个 token第二多轮对话里历史上下文没有做有效裁剪导致每一轮都在重复计费。两件事叠加单次会话的实际消耗被放大了好几倍。这个现象其实很普遍。很多人在用某个成熟的代码助手工具时默认它已经帮你优化好了成本但事实是工具本身的设计目标往往不是最省钱而是最省心。它宁可塞进去一大堆规则、示例、约束也要保证输出质量稳定。代价就是你的 token 账单。我决定做一次彻底的迁移实验把原来那套臃肿的系统提示词架构换成一个极简的、自己可控的方案。目标很明确——系统提示词从 1.4 万 token 砍到 200 以内整体 token 消耗下降 80% 以上同时不牺牲日常使用的核心体验。这篇文章就是这次迁移的完整记录。我会把思路、踩过的坑、具体的配置方法、以及最终的效果数据全部摊开讲。如果你也在为 API 账单头疼或者单纯想搞清楚系统提示词到底该写多少这篇内容应该能帮你省下不少冤枉钱。2. 先搞清楚钱花在哪Token 消耗的构成拆解2.1 一次请求里到底有哪些 token很多人对 token 消耗的认知停留在我输入了多少字但实际上一次 API 请求的 token 由好几部分组成每一部分都在计费。以典型的对话式代码助手为例组成部分说明典型占比系统提示词每次请求都完整发送定义角色、规则、输出格式40%~60%对话历史之前几轮的问答记录逐轮累积20%~40%当前用户输入你这次问的问题5%~15%工具定义如果用了 function calling工具描述也占 token5%~20%模型输出生成的内容按输出 token 计费单独计算关键点在于系统提示词和对话历史是每轮重复发送的。你问第一个问题时系统提示词发一次问第二个问题时系统提示词加第一轮问答一起发问第三个问题时前面所有内容再发一次。这就是为什么长会话的成本会指数级上升。2.2 1.4 万 token 的系统提示词是怎么来的我拆解了原来那套系统提示词发现它的膨胀有几个典型原因角色设定过度详细用了大量篇幅描述你是一个经验丰富的工程师你擅长……你应当……这些描述对模型行为的实际影响很小但 token 消耗实打实。规则堆砌几十条必须禁止注意很多规则互相重叠甚至互相矛盾。示例冗余为了覆盖各种边界情况塞了七八个完整的输入输出示例每个示例几百 token。格式说明重复在系统提示词里讲一遍输出格式在工具定义里又讲一遍在用户消息模板里再讲一遍。防御性内容大量如果用户要求 X你不要做 Y之类的安全约束很多在实际使用中根本触发不到。我做过一个粗略统计这 1.4 万 token 里真正对输出质量有显著影响的可能不到 2000 token剩下的都是心理安慰式的冗余。2.3 为什么砍系统提示词是最划算的优化优化 token 成本有好几个方向裁剪对话历史、压缩用户输入、减少工具定义、换更便宜的模型。但这些方向各有各的麻烦裁剪历史容易丢上下文导致模型失忆体验下降明显。压缩用户输入受限于你实际要问的问题空间有限。减少工具定义会削弱功能。换模型可能影响输出质量。而系统提示词不一样。它是每次请求的固定开销砍掉 1 万 token意味着每一轮对话都省 1 万 token。假设一次会话有 10 轮那就是省 10 万 token。这个杠杆效应是其他优化方向比不了的。更重要的是系统提示词里的大部分内容对模型的实际行为影响远没有想象中大。现代大模型对简短、明确的指令遵循度已经很高堆砌大量规则反而可能让模型抓不住重点。3. 迁移方案设计从臃肿到极简的架构思路3.1 核心设计原则我给这次迁移定了三条原则第一系统提示词只保留不可省略的内容。什么叫不可省略就是如果删掉它模型的行为会明显跑偏。比如你是一个代码助手这种角色定位可以留但你应当保持专业、礼貌、耐心这种就纯属浪费。第二把规则从系统提示词里挪出去。很多规则其实可以通过其他方式实现比如放在用户消息的模板里、放在工具描述里、或者干脆靠模型自己的能力。系统提示词应该只放那些每次都必须生效的全局约束。第三用结构化代替自然语言。同样一条规则用自然语言描述可能要 50 个 token用结构化的键值对或者简短标签可能只要 10 个 token。模型对结构化信息的理解能力已经足够好。3.2 200 token 系统提示词的实际内容经过反复迭代我最终的系统提示词控制在了 180 个 token 左右。它的完整内容大致是这样的结构Role: coding assistant. Output: code first, brief explanation after. Style: concise, no filler. Tools: use when needed, dont over-call. Safety: refuse harmful requests. Context: users project is local, assume standard conventions.就这么几行。你可能会怀疑这么简单模型能好好干活吗实测下来对于代码助手这个场景答案是能。原因在于现代模型在预训练阶段已经见过海量的代码和编程对话它对代码助手应该怎么表现有很强的先验知识。你不需要教它怎么当代码助手你只需要告诉它现在你是代码助手剩下的它自己会。3.3 被砍掉的内容去了哪里那原来 1.4 万 token 里的内容是不是就全扔了不是。我做了分类处理真正重要的规则挪到了用户消息的模板里只在需要的时候出现。比如生成测试时要用 pytest 风格这条规则只在用户要求写测试时才附加平时不占 token。示例全部删除。现代模型不需要通过示例来学习基本行为示例更多是给旧模型或者特殊格式需求用的。格式说明挪到了工具定义和输出解析逻辑里系统提示词里不再重复。安全约束保留最核心的一条其余靠模型自身的安全对齐。这个思路的核心是把每次都发送变成按需发送。系统提示词是固定成本用户消息是可变成本把内容从固定挪到可变总体成本就下来了。4. 实操过程一步步完成迁移4.1 第一步审计现有系统提示词动手之前先把你现在用的系统提示词完整导出来做一次逐段审计。我的方法是把提示词按段落切分然后对每一段问三个问题如果删掉这段模型的行为会有明显变化吗这段内容是否在其他地方已经出现过这段内容能否用更短的表达替代审计的时候建议用表格记录我当时的记录格式是这样的段落原 token 数删除后影响处理方式角色详细描述800几乎无影响删除保留一句话输出格式规则1200有影响压缩到 30 token示例 1-75000无影响全部删除安全约束2000部分有影响保留核心一条工具使用说明3000有影响挪到工具定义这一步做完你基本就能看到哪些是水分。4.2 第二步重写极简系统提示词重写的时候我建议用最小可行提示词的思路先写一个极简版本然后测试发现哪里不对再补。而不是先写一个完整版本再删。我的极简版本最初只有三行You are a coding assistant. Be concise. Output code with minimal explanation.然后我开始测试各种场景让它改 bug、写测试、解释代码、生成脚本。每次发现行为不对就补一条规则。补的时候严格遵守能短则短的原则。比如发现它解释太多我补的不是请在解释时保持简洁不要啰嗦只说明关键点而是直接加一个词Concise.。模型完全能理解。4.3 第三步把规则挪到按需位置这一步是省 token 的关键。我建了一个规则库把原来系统提示词里的规则分类存起来然后在构造用户消息时按需拼接。举个例子原来系统提示词里有一条生成代码时要包含类型注解。迁移后这条规则只在用户明确要求写一个函数或生成代码时才附加到用户消息里。如果用户只是问这段代码什么意思就不附加。实现上我用了一个简单的规则匹配逻辑def build_user_message(user_input, context): rules [] if any(kw in user_input for kw in [写, 生成, 实现, create, write]): rules.append(Include type hints.) if any(kw in user_input for kw in [测试, test]): rules.append(Use pytest style.) if any(kw in user_input for kw in [解释, explain, 什么意思]): rules.append(Explain concisely.) prefix .join(rules) return f{prefix}\n\n{user_input} if prefix else user_input这段逻辑本身不复杂但它把固定成本变成了可变成本。大部分请求根本不需要那些规则自然就不花那个 token。4.4 第四步对话历史的裁剪策略系统提示词砍完之后对话历史成了新的成本大头。我用了两个策略滑动窗口加摘要。保留最近 N 轮完整对话更早的对话压缩成一段摘要。摘要用便宜的小模型生成成本远低于把原文一直带着。按相关性裁剪。如果当前问题和早期某轮对话无关就把那轮删掉。实现上可以用简单的关键词匹配或者用 embedding 相似度。实测下来这两个策略能把长会话的历史成本压掉 60% 以上而且对体验的影响很小。4.5 第五步验证与调优迁移完成后我做了一轮对比测试。用同一批任务20 个典型的代码助手请求分别跑旧方案和新方案记录 token 消耗和输出质量。指标旧方案新方案变化系统提示词 token14200180-98.7%单次请求平均 token185002800-84.9%输出质量主观评分8.5/108.3/10基本持平响应速度基准快约 30%明显提升质量评分是我自己按是否解决了问题、代码是否可用、解释是否清晰三个维度打的分。新方案略低一点点主要是在一些边缘场景下模型偶尔会少做一些锦上添花的事比如主动加注释。但核心功能完全没受影响。5. 常见问题与排查技巧实录5.1 砍完之后模型不听话了怎么办这是最常见的问题。系统提示词砍太狠模型开始放飞自我输出格式乱、废话多、不按套路来。我的排查思路是逐条加回而不是一次加一堆。具体做法记录下模型跑偏的具体表现然后针对性地加一条最短的规则测试再观察。比如模型开始输出大段解释就加Concise.模型开始用错误的代码风格就加Use standard style.。关键是不要一上来就恢复原来的长提示词那样等于白干。每次只加一条加完测试确认有效再保留。5.2 哪些内容绝对不能砍有几类内容我建议保留哪怕它占 token角色定位一句话就够但不能没有。没有角色定位模型可能不知道自己在干什么。核心安全约束这个不用多说必须有。输出格式的关键约束如果你的下游系统依赖特定格式比如 JSON那格式说明不能省但可以压缩到最简。工具调用的基本说明如果用了 function calling工具的基本用途要讲清楚否则模型不会正确调用。5.3 按需拼接规则会不会漏掉重要规则会这是这个方案的主要风险。我的应对方法是建立回归测试集。把常见的请求类型整理成一个列表每次修改规则拼接逻辑后跑一遍测试集看有没有场景漏掉了规则。另外我建议在规则拼接逻辑里加日志记录每次请求实际附加了哪些规则。这样出问题的时候能快速定位。5.4 迁移后成本没降多少是怎么回事如果你迁移后账单没明显下降检查这几个点对话历史是不是没裁剪系统提示词省了但历史还在膨胀总体成本可能没降多少。输出 token 是不是变多了有时候系统提示词砍了模型反而输出更多内容来补偿导致输出成本上升。这时候要在提示词里明确约束输出长度。是不是换了更贵的模型迁移过程中如果顺手换了模型成本对比就不准了。缓存有没有生效很多 API 提供 prompt caching系统提示词短了之后缓存命中率可能变化要确认计费逻辑。5.5 常见问题速查表问题现象可能原因解决方向模型输出格式乱格式约束砍太多加回最简格式说明模型废话变多缺少简洁性约束加Concise.类短指令模型不调用工具工具说明不足在工具定义里补说明长会话成本仍高历史未裁剪加滑动窗口和摘要输出 token 上升模型补偿性输出明确约束输出长度特定场景行为异常按需规则漏配补规则并加回归测试6. 一些实操心得和踩坑记录6.1 关于极简的度极简不等于越短越好。我试过把系统提示词压到 50 token 以内结果模型开始频繁跑偏补规则的频率反而上升总体体验下降。180 token 左右是我实测下来比较舒服的平衡点。这个度因场景而异。纯代码生成场景可以更短涉及复杂格式或多工具调用的场景需要更长。建议你自己做几轮测试找到适合你的那个点。6.2 关于模型选择这次迁移我没有换模型因为想单独验证系统提示词优化的效果。但如果你愿意换模型成本还能再降。现在很多中小模型在代码任务上的表现已经相当不错价格却只有大模型的几分之一。我的建议是先用系统提示词优化把成本降下来再考虑换模型。两个变量一起动出问题不好定位。6.3 关于长期维护极简系统提示词的一个隐性成本是维护。因为规则被拆散了散落在各个地方时间长了容易忘记哪条规则在哪。我的做法是维护一个规则清单文档记录每条规则的内容、存放位置、触发条件。每次改动都更新这个文档。另外建议定期重新审计系统提示词。随着使用场景变化有些规则可能不再需要有些新需求可能需要新规则。我大概每个月会花半小时做一次快速审计。6.4 一个容易被忽略的点缓存很多 API 对系统提示词有缓存机制。如果你的系统提示词是固定的缓存命中后这部分 token 可能不计费或者打折。但如果你把系统提示词改得很短缓存带来的收益也变小了。这不意味着不该砍系统提示词而是说在计算收益的时候要把缓存因素考虑进去。如果你的系统提示词本来就命中缓存那砍它的实际收益可能没有账面上那么大。但对话历史通常不缓存所以裁剪历史的收益是实打实的。6.5 最后的建议如果你现在也在为 token 账单头疼我的建议是先审计再动手小步迭代。不要一上来就把系统提示词全删了重写那样容易翻车。先做审计看清楚钱花在哪然后从最明显的水分开始砍每砍一刀测试一次。这个过程可能需要几天时间但一旦调好省下来的钱是持续的。我这次迁移之后月度账单从四位数降到了三位数而且日常使用体验基本没变。这笔时间投入值。后续如果你想让成本再降一个台阶可以考虑的方向有换更便宜的模型、把部分任务本地化处理、对高频请求做结果缓存。但这些都属于另一个话题了先把系统提示词这块吃透收益已经足够大。