1. 从 1.4 万 Token 到 200 Token一次提示词瘦身的真实动机第一次看到自己月度 Token 账单的时候我盯着那个数字看了很久一度以为是统计口径出了问题。反复核对了几次调用日志之后才确认问题不在统计而在我自己写的系统提示词上。那份提示词从项目第一天开始就不断往里加东西今天补一条格式约束明天加一段角色设定后天又塞进去几个示例对话半年下来膨胀到一万四千多个 Token。每次请求都要把这坨东西完整发一遍哪怕用户只是问一句帮我改个变量名。这件事的荒诞之处在于我花在优化业务逻辑上的时间远不如花在给提示词打补丁上的时间多。而真正吃掉成本的恰恰是这些补丁本身。后来我把整套系统迁移到一个更轻的提示词架构上最终稳定在两百个 Token 左右账单直接降了八成五。这个过程踩了不少坑也推翻了很多我原本以为理所当然的做法值得完整记录一遍。这篇文章面向的是已经在用大模型做产品、或者正在搭建 AI 应用的开发者。如果你手上有一份越写越长的系统提示词每次改动都提心吊胆怕影响其他功能或者你单纯被 Token 成本压得喘不过气那接下来的内容应该能帮你省下不少钱和精力。我会把整个迁移思路、提示词重构方法、参数取舍逻辑、以及实际踩过的坑都摊开讲尽量做到你照着做就能复现。需要先说明一点这里说的迁移不是简单换个模型接口那么简单而是整套提示词设计哲学的转变。从把所有规则都写死在系统提示里转向用最少的约束撬动模型自身的能力。这个转变听起来抽象但落到具体操作上非常实在每一步都有明确的判断标准。2. 为什么系统提示词会膨胀到失控2.1 提示词膨胀的典型路径几乎每一个从零开始做 AI 应用的团队都会经历同样的膨胀曲线。我把这个过程拆成四个阶段你可以对照看看自己走到哪一步了。第一阶段是角色设定期。刚开始你只需要模型扮演一个助手写一句你是一个专业的编程助手就够了。这时候提示词可能只有几十个 Token。第二阶段是格式约束期。你发现模型输出格式不稳定有时候用 Markdown有时候用纯文本于是你开始加规则必须用代码块包裹代码、必须用列表组织步骤、必须标注文件路径。规则一条条加上去提示词涨到几百 Token。第三阶段是边界防御期。线上出了几次事故模型回答了不该回答的问题或者生成了有风险的代码于是你开始加各种不要做某事的约束。每出一次问题就加一条提示词涨到几千 Token。第四阶段是示例堆砌期。你发现光靠规则描述模型还是理解不到位于是开始塞示例对话。一个示例动辄几百 Token塞三五个就上千了。到这一步提示词已经彻底失控。我自己的项目就是完整走完了这四个阶段。最夸张的时候系统提示词里同时存在十七条不要开头的约束还有四组完整的示例对话。每次请求光系统提示就消耗一万四千 Token而用户的实际问题往往只有几十个 Token。这个比例严重失衡。2.2 膨胀背后的三个认知误区提示词之所以会失控根源在于三个很常见的认知误区我自己全都踩过。第一个误区是规则越多越安全。很多人觉得只要把所有可能出问题的情况都写成规则模型就不会犯错。但实际情况恰恰相反。规则越多模型在生成时需要在更多约束之间做权衡反而容易出现顾此失彼的情况。而且大量规则之间存在潜在冲突模型不知道该优先遵守哪一条输出质量会明显下降。第二个误区是示例比描述有效。这个说法在少量示例时成立但示例的边际收益递减得非常快。第一个示例能显著提升理解准确度第二个示例提升有限到第三个第四个基本就是浪费 Token 了。更麻烦的是示例会锚定模型的输出风格如果示例本身写得不够好反而会把模型带偏。第三个误区是系统提示是免费的。很多人潜意识里觉得系统提示写一次就固定了不像用户输入那样每次都变所以不太在意它的长度。但实际上系统提示是每次请求都要完整传输的它的成本是乘以请求次数的。一个一万四千 Token 的系统提示如果每天有一万次请求光系统提示这一项每天就要消耗一亿四千万 Token。这个数字算出来的时候我自己都吓了一跳。2.3 成本账到底怎么算我们来做一道具体的算术题这样你对成本结构会有更直观的感受。假设你的应用每天处理一万次请求平均每次用户输入加输出是五百 Token系统提示是一万四千 Token。那么单次请求的总 Token 消耗是一万四千五百 Token其中系统提示占比高达百分之九十六点五。按主流模型的定价粗略估算输入 Token 的成本虽然比输出低但架不住量大。一天下来系统提示消耗的 Token 是一亿四千万而真正有价值的用户交互内容只有五百万。也就是说你花的钱里有九成以上是在重复传输同一份固定文本。如果把系统提示压缩到两百 Token单次请求总消耗降到七百 Token整体成本直接降到原来的百分之四点八也就是降了九成五以上。即便考虑到压缩后可能需要更精细的调用策略实际降幅也能稳定在八成五左右。这就是标题里那个数字的来源它不是拍脑袋写的是实打实算出来的。提示在动手优化之前先把你最近一周的调用日志拉出来统计系统提示 Token 占总 Token 的比例。如果这个比例超过百分之五十那优化空间就非常大值得投入时间重构。3. 提示词瘦身的核心思路从写规则到给结构3.1 一个关键判断模型能力已经变了很多人提示词写得又长又细是因为他们的大脑还停留在早期模型的水平上。早期模型理解能力弱你必须把话说得非常死它才能照做。但现在的模型在指令遵循、格式控制、上下文理解上都有了质的飞跃很多以前必须写死的规则现在模型自己就能处理好。我做过一个对比实验。同一组任务一份提示词写满了格式约束和边界防御另一份只写核心目标。结果在现在的模型上两份提示词的输出质量差异微乎其微但 Token 消耗差了七十倍。这个实验让我彻底改变了对提示词长度的执念。所以瘦身的第一步不是急着删规则而是先做减法实验把某条规则删掉跑一批测试用例看输出质量有没有下降。如果没有下降说明这条规则是冗余的模型自己能处理。逐条验证下来你会发现大部分规则其实都可以删。3.2 结构化的两百 Token 长什么样瘦身不是简单地把长提示词砍短而是重新设计信息结构。我最终稳定下来的两百 Token 提示词大致包含四个部分每部分都极其精简。第一部分是身份锚点一句话说明模型扮演什么角色大概二十个 Token。第二部分是核心任务说明这次交互要达成什么目标大概五十个 Token。第三部分是输出契约只保留最关键的格式要求比如代码用代码块包裹大概三十个 Token。第四部分是动态注入区把原本写死在系统提示里的上下文信息改成按需注入这部分根据实际情况变化平均一百个 Token。关键在于第四部分的设计。原本我把项目结构、技术栈、代码规范全都写死在系统提示里但其实每次请求真正需要的上下文只是其中一小部分。改成动态注入后系统提示只保留最通用的框架具体上下文由调用方根据当前任务拼装。这样既保证了信息完整又避免了每次传输无关内容。3.3 动态注入的三种实现方式动态注入听起来简单但落地时有几种不同的实现方式各有适用场景。第一种是检索式注入。把项目相关的所有信息切片存进向量库每次请求时根据用户问题检索最相关的几个片段注入。这种方式适合知识库类应用信息量大且分散的场景。第二种是模板式注入。预先定义几种任务模板每种模板对应一套固定的上下文注入方案。比如代码修改模板注入文件路径和函数签名代码解释模板注入完整函数体。这种方式适合任务类型明确的场景实现简单且可控。第三种是分层式注入。把上下文分成必选层和可选层必选层每次都注入可选层根据任务复杂度决定是否注入。这种方式适合上下文重要性差异明显的场景。我自己的项目用的是模板式注入因为任务类型比较固定实现成本最低。实测下来平均每次注入的上下文在一百 Token 左右比原来写死的一万四千 Token 少了两个数量级。4. 实操一步步把提示词从一万四砍到两百4.1 第一步给现有提示词做体检动手删之前先要搞清楚现有提示词里到底有什么。我的做法是把系统提示词按段落拆开逐段标注它的作用、使用频率、以及删除后的风险等级。具体操作是建一张表格三列分别是段落内容摘要这条规则最近一个月触发过几次删掉后可能出什么问题。触发次数这一列很关键很多规则写进去之后就再也没起过作用属于典型的僵尸规则。我自己的提示词体检结果是十七条不要约束里有十一条在过去一个月里从未触发过四组示例对话里有两组和实际任务场景根本不匹配还有一大段项目背景介绍其实每次请求都用不到。光这三项加起来就占了八千多 Token。注意体检时不要凭印象判断一定要拉真实日志统计。我原本以为某条格式约束很重要结果统计发现它触发率不到百分之一删掉之后输出质量没有任何变化。4.2 第二步把规则翻译成契约删规则不能一刀切有些规则确实重要但可以用更省 Token 的方式表达。核心技巧是把过程性规则翻译成结果性契约。举个例子。原来我写了五条规则来描述代码输出的格式要求必须用代码块、必须标注语言、必须在代码前说明修改点、必须在代码后说明影响范围、必须保持缩进一致。这五条加起来一百多 Token。翻译成契约之后只需要一句话输出格式修改说明 代码块标注语言 影响范围。同样三十个 Token 左右但表达的是最终结果要求而不是过程步骤。模型理解结果性契约的能力比理解过程性规则更强因为它不需要在脑子里模拟执行步骤。这个翻译过程需要反复打磨。我的经验是每一条规则都问自己一句我真正想要的结果是什么然后直接把这个结果写出来而不是写达成结果的步骤。4.3 第三步示例对话的取舍标准示例对话是 Token 大户但完全删掉又可能影响输出风格。我的取舍标准是只保留一个最能代表核心任务的示例且这个示例必须极度精简。精简示例的关键是去掉所有非必要信息。原来我的示例对话里包含了完整的用户提问、完整的模型思考过程、完整的输出结果一组下来三百多 Token。精简后只保留输入要点 输出骨架一组压缩到五十 Token 以内。另外示例的位置也很重要。放在系统提示末尾的示例模型参考时权重更高。所以如果只保留一个示例就把它放在最后。如果保留两个把最重要的放最后。实测下来从四组示例精简到一组输出风格的一致性没有明显下降但 Token 省了将近一千。这个投入产出比非常高。4.4 第四步建立动态注入的调用规范系统提示瘦身之后上下文信息改由调用方注入这就需要建立一套调用规范否则每个调用点各写各的很快就会重新失控。我的做法是定义一个注入模板函数所有调用都必须通过这个函数生成上下文。函数内部根据任务类型选择注入内容并做长度截断保护。这样即使某个调用点想注入大量上下文也会被函数截断不会污染系统提示。模板函数的核心逻辑大概是这样的def build_context(task_type, payload): templates { code_edit: lambda p: f文件{p[file]}\n函数{p[func]}, code_explain: lambda p: f代码\n{p[code][:800]}, general: lambda p: p.get(summary, )[:200], } builder templates.get(task_type, templates[general]) return builder(payload)这段代码的关键在于每个模板都有长度上限比如代码解释最多注入八百字符通用任务最多两百字符。这个上限是根据实测效果定的超过之后模型的理解准确度不再提升纯属浪费。4.5 第五步灰度验证与回滚预案提示词改动最怕的是线上出问题所以一定要灰度验证。我的做法是保留新旧两套提示词按流量比例分流同时记录两套的输出质量和 Token 消耗。灰度期间重点看三个指标任务成功率、输出格式合规率、平均 Token 消耗。前两个指标不能下降第三个指标要明显下降。如果前两个指标有下降立刻回滚分析是哪条规则删错了。我自己的灰度跑了一周前三天新旧各百分之五十后四天新提示词百分之百。最终数据是任务成功率持平格式合规率略升Token 消耗降了百分之八十七。这个结果比我预期的还要好。5. 迁移过程中踩过的坑与排查实录5.1 坑一删规则删过头导致格式崩坏最开始我信心满满一口气删掉了所有格式约束结果模型输出变得非常随意有时候用 Markdown有时候用纯文本代码块也时有时无。下游解析程序直接报错。排查之后发现格式约束虽然大部分可以删但代码必须用代码块包裹这一条是下游解析的硬依赖不能删。教训是删规则之前先确认哪些规则是下游系统的硬依赖这些必须保留。5.2 坑二动态注入的上下文顺序影响理解动态注入上线后我发现模型对上下文的利用效率时好时坏。后来对比日志才发现注入内容的顺序会影响模型理解。把最相关的信息放在最前面模型利用率明显更高。调整之后我在注入模板里加了一条规则按相关性降序排列注入内容。这个改动很小但效果立竿见影。5.3 坑三Token 统计口径不一致导致误判优化过程中我一度以为 Token 没降下来排查了半天才发现是统计口径问题。有的统计工具把系统提示和用户输入分开算有的合并算。我一开始看的是分开算的数据误以为系统提示没降。后来统一了口径把所有输入 Token 合并统计才看到真实的降幅。这个坑提醒我做优化之前一定要先确认度量标准否则容易白忙活。5.4 常见问题速查表问题现象可能原因排查方向解决方法输出格式不稳定格式契约写得太模糊检查输出契约部分用结果性描述替代过程性规则上下文利用率低注入顺序不合理对比不同顺序的效果按相关性降序排列Token 降幅不明显统计口径不一致确认统计工具口径统一为合并统计任务成功率下降删掉了关键规则逐条回滚验证保留下游硬依赖规则输出风格漂移示例被删太多检查示例保留情况保留一个核心示例放末尾5.5 独家避坑技巧分享几个文档里不会写、但实际很有用的技巧。第一个是规则触发日志。给每条规则加一个隐式标记模型触发这条规则时在日志里留痕。跑一周之后触发率为零的规则直接删。这个技巧能帮你精准识别僵尸规则。第二个是提示词版本对照。每次改动提示词都存一个版本记录改动内容和对应的效果指标。出问题时可以快速定位是哪次改动导致的。我用一个简单的表格管理成本很低但收益很大。第三个是极端用例回归。准备一组极端用例比如超长输入、空输入、多语言混合输入每次改提示词都跑一遍。这些用例能暴露大部分边界问题。6. 迁移后的效果与可复用的经验6.1 实际数据对比迁移前后的核心数据对比大致是这样的。系统提示 Token 从一万四千降到两百降幅百分之九十八点六。单次请求总 Token 从一万四千五百降到七百降幅百分之九十五点二。月度账单降幅百分之八十五之所以没有 Token 降幅那么大是因为迁移后调用频次有所上升部分节省被新增调用抵消了。输出质量方面任务成功率持平格式合规率从百分之九十二提升到百分之九十六主要得益于输出契约比原来的过程性规则更清晰。响应延迟也有改善因为输入 Token 少了模型处理时间相应缩短。6.2 哪些场景适合这套方法这套方法不是万能的它有明确的适用边界。适合的场景是任务类型相对固定、输出格式有明确要求、上下文信息可以结构化拆分的应用。比如代码助手、客服机器人、内容生成工具。不太适合的场景是任务高度开放、需要大量领域知识注入、或者对输出风格有极其精细要求的应用。这类场景可能需要保留更多上下文瘦身空间有限。判断标准很简单如果你的系统提示里超过一半的内容是通用规则而非领域知识那瘦身空间就很大。6.3 后续可以继续优化的方向提示词瘦身只是成本优化的第一步。后续还可以从几个方向继续挖潜。一是缓存策略。对于重复性高的请求把模型输出缓存起来直接返回缓存结果连模型都不用调。这个对客服类应用效果特别明显。二是模型分级。简单任务用轻量模型复杂任务用重量模型按需分配。很多请求其实用轻量模型就够了没必要都走重量模型。三是批处理。把多个小请求合并成一个大请求减少请求次数摊薄系统提示的固定开销。这个对批量处理场景很有效。6.4 我个人的几点体会最后分享几点我自己的真实体会不一定对所有人适用但都是我踩过坑之后总结出来的。第一提示词的长度和效果没有正相关。我见过太多人把提示词写得像说明书结果效果还不如一句精准的指令。写提示词的核心是精准不是全面。第二优化之前先量化。没有数据支撑的优化都是瞎猜。花半天时间搭个统计比花三天时间凭感觉改提示词有用得多。第三改动要小步快跑。一次改一条规则验证效果后再改下一条。一次性大改虽然爽但出问题时根本不知道是哪条改错了。第四别怕删。大部分提示词里的规则都是冗余的删掉之后你会发现模型比你想的聪明得多。真正需要保留的规则往往是那些和下游系统强耦合的硬约束而不是那些我觉得模型可能做不好的软约束。这套方法我后来又用在两个新项目上效果同样明显。其中一个项目的系统提示从八千 Token 压到一百五十 Token账单降了八成。另一个项目因为领域知识较多只压到八百 Token但账单也降了六成。所以具体能压到多少取决于你的任务类型但只要有优化意识总能找到空间。