1. 从一次账单复盘说起为什么我要动系统提示词去年年底做季度成本复盘的时候我发现一个很反直觉的现象团队里几个用 AI 编程助手的项目实际写业务代码的 token 消耗只占了三成不到剩下七成全部砸在了系统提示词和上下文注入上。最夸张的一个项目单次会话的固定开销就有一万四千多个 token还没开始干活钱已经花出去了。这个项目标题里的数字不是标题党。系统提示词从 1.4 万砍到 200账单降 85%是我自己一步步压出来的真实结果。核心思路其实不复杂把每次都要塞给模型的固定内容和真正需要模型知道的内容彻底分开。前者越少越好后者按需加载。这篇文章适合三类人看一是正在用 AI 编程助手、但没仔细算过 token 账的开发者二是被系统提示词臃肿问题困扰、想自己动手瘦身的人三是对 AI 工具链成本结构好奇、想搞清楚钱到底花在哪的技术负责人。我会把整个迁移和优化过程拆开讲包括为什么原来的方案会膨胀到 1.4 万、200 token 的方案怎么设计、中间踩了哪些坑、以及怎么验证效果。先说结论性的判断系统提示词的膨胀本质上是把配置当代码写的思维惯性造成的。很多人习惯把所有可能用到的规则、示例、工具说明全塞进系统提示觉得多给点总没错。但在按 token 计费的场景下这个习惯就是纯粹的浪费。真正高效的做法是分层核心指令极简扩展能力按需注入。2. 拆解 1.4 万 token 的构成钱到底花在哪了2.1 系统提示词的四大膨胀源我先把原来那套方案的 token 构成拉出来做了个拆解。用的是一个常见的 token 估算方式中文按 1.5 字/token 粗算英文按 4 字符/token 粗算代码块单独统计。结果如下构成部分估算 token 数占比是否每次会话都加载角色设定与行为准则约 280020%是工具调用说明十几个工具约 420030%是代码风格与规范示例约 350025%是安全与边界规则约 210015%是项目上下文注入约 140010%是合计约 14000100%全部常驻看这个表就能发现问题工具调用说明和代码风格示例加起来占了 55%但这两块内容在绝大多数会话里根本用不上。比如一个只做代码审查的会话根本不需要知道怎么写新文件的工具怎么调用一个只改 bug 的会话也不需要完整的代码风格示例。2.2 为什么多塞点是个陷阱这里要讲一个很多人没意识到的机制系统提示词是每次请求都要重新计费的。它不是一次性的投入而是像房租一样每次对话都要交一遍。假设一天跑 200 次请求1.4 万 token 的系统提示就是 280 万 token 的固定开销。按主流模型的定价这笔钱一个月下来相当可观。更隐蔽的问题是过长的系统提示会稀释模型的注意力。模型在处理长上下文时对开头和结尾的内容关注度更高中间部分容易被忽略。你把十几条规则塞在中间模型可能只记住了前三条和后两条。结果就是你写了一大堆规则模型该犯的错还是犯钱却照花。我做过一个对比测试同样一个重构这个函数的任务用 1.4 万 token 的系统提示和用 200 token 的系统提示输出质量几乎没有差别。因为重构任务真正需要的指令就那几条多出来的内容全是噪音。2.3 一个关键认知系统提示不是文档很多人把系统提示词当成项目文档来写恨不得把所有背景、所有规范、所有历史决策都写进去。但系统提示的本质是给模型的即时操作指令不是知识库。知识库应该放在外部需要的时候再检索注入。这个认知转变是整件事的起点。一旦你接受系统提示只放最核心的操作指令后面的优化就顺理成章了。3. 200 token 极简方案的设计逻辑3.1 核心指令只保留三件事我把系统提示词压缩到 200 token 左右只保留三件事身份与目标一句话说清楚这个助手是干什么的。输出格式约束规定回答的结构比如先给结论再给理由。边界规则什么能做、什么不能做用最简短的否定句表达。具体长这样示意非真实配置你是一个代码助手负责在给定代码库中完成指定任务。 输出要求先给结论再给必要说明代码用代码块包裹。 约束不修改未指定的文件不确定时先提问不编造不存在的 API。就这么多。没有角色扮演没有长篇大论的风格示例没有十几个工具的详细说明。3.2 工具说明按需注入原来那 4200 token 的工具说明我改成了按需注入。具体做法是系统提示里只写你可以调用工具工具列表会在需要时提供然后在具体任务里只把这次任务可能用到的工具说明附上。比如一个读取文件并分析的任务只注入读取类工具的说明大概 150 token。一个修改并保存的任务只注入写入类工具的说明。这样每次实际加载的工具说明从 4200 降到 150 到 300 之间。3.3 代码风格用外部配置代码风格示例那 3500 token我全部移到了外部配置文件里。系统提示里只写一句遵循项目根目录的 style 配置。模型需要的时候通过工具去读取这个文件。这样风格规范可以写得很详细但不占用每次请求的固定开销。3.4 安全规则用最短表达安全与边界规则从 2100 压到 50 token 以内。核心就几条否定句不执行破坏性操作不访问未授权路径不输出敏感信息。原来那些长篇的解释性文字全部删掉因为模型不需要你解释为什么它只需要知道是什么。3.5 优化前后的对比维度优化前优化后变化系统提示 token约 14000约 200降 98.6%单次会话固定开销高极低显著下降工具说明加载方式全量常驻按需注入动态代码风格内嵌外部配置解耦综合账单基准降约 85%大幅下降账单降 85% 而不是 98%是因为还有用户输入、模型输出、以及按需注入的那部分内容。但固定开销的大头已经被砍掉了。4. 迁移实操一步步把提示词瘦下来4.1 第一步给现有系统提示做体检动手之前先把你现在的系统提示词完整拉出来按功能分块统计每块的 token 数。我用的方法很简单把提示词按段落拆开每段单独估算 token然后归类。这里有个实操技巧不要凭感觉判断哪块重要要看实际调用频率。我统计了两周的实际会话发现工具说明里只有三个工具被真正调用过其余十几个从来没触发过。那十几个工具的说明就是纯浪费。4.2 第二步区分常驻和按需把体检出来的所有内容分成两类常驻类每次会话都必须有的比如身份、核心约束。按需类只在特定任务里需要的比如工具说明、风格示例、项目背景。分类的标准是问自己一句如果这次会话完全用不到这块内容删掉它会不会影响结果如果不会就归到按需类。4.3 第三步重写核心提示核心提示的重写原则是能删就删能短就短。我给自己定了几条硬规则不用形容词只用动词和名词。不解释原因只给指令。不举例除非例子本身就是指令的一部分。每条规则不超过一行。按这个规则重写1.4 万 token 的内容能压到 200 以内。4.4 第四步搭建按需注入机制按需注入需要一个简单的调度逻辑根据任务类型决定注入哪些扩展内容。我用的是一个映射表任务类型注入内容估算 token代码审查审查规则 读取工具说明约 250代码修改修改规则 读写工具说明约 300问题排查排查流程 日志工具说明约 200文档生成文档模板 写入工具说明约 180这个映射表放在外部每次任务开始时根据类型查表注入。这样既保证了任务需要的信息都在又不会把无关内容塞进去。4.5 第五步验证与回归测试瘦身之后必须验证效果。我准备了一组标准任务优化前后各跑一遍对比输出质量和 token 消耗。标准任务包括改一个 bug、加一个函数、审查一段代码、生成一份文档。验证的关键指标有两个任务完成率和单任务平均 token。如果完成率没降、token 降了说明优化成功。如果完成率降了说明砍过头了需要把某些内容加回来。注意验证时要用同一组任务、同一个模型版本否则对比没有意义。模型版本更新会带来输出差异干扰判断。5. 踩过的坑与排查实录5.1 砍太狠导致模型失忆第一次瘦身我砍到了 80 token结果模型开始犯低级错误不遵守输出格式、忘记用代码块、甚至开始编造 API。原因是核心约束被砍得太简略模型没有足够的信号来判断边界。解决办法是保留必要的冗余。200 token 里有大约 50 token 是重复强调核心约束的。看起来浪费但实测下来能显著降低出错率。这个平衡点需要自己试我的经验是核心约束至少出现两次一次在开头一次在结尾。5.2 按需注入的时机问题按需注入有个坑注入太晚模型已经开始回答了。我一开始把工具说明放在用户消息之后结果模型经常在没看到工具说明的情况下就开始规划导致工具调用失败。正确做法是把按需内容放在系统提示之后、用户消息之前确保模型在开始思考前就拿到完整信息。5.3 外部配置读取失败代码风格移到外部文件后偶尔出现读取失败的情况。排查发现是路径问题不同工作目录下相对路径解析不一致。解决办法是用绝对路径或者在系统提示里明确写清楚配置文件的完整位置。5.4 常见问题速查表问题现象可能原因排查方向解决办法模型不遵守格式核心约束太简略检查约束是否出现两次补回关键约束工具调用失败工具说明注入时机晚检查注入位置移到用户消息前风格不一致外部配置未加载检查路径用绝对路径输出质量下降砍过头对比优化前后加回必要内容token 没降按需内容仍常驻检查注入逻辑确认按需生效5.5 一个反直觉的经验优化过程中我发现有时候加一点内容反而能降 token。比如在核心提示里加一句不确定时先提问能减少模型反复试错产生的多余输出整体 token 反而降了。所以优化不是一味地删而是让每一分 token 都花在刀刃上。6. 效果验证与长期维护6.1 怎么量化优化效果我用的量化方法是单任务 token 成本把一个标准任务从开始到结束的所有 token 消耗加起来除以任务数。优化前平均每个任务约 1.8 万 token优化后降到约 2700降幅约 85%。这个数字和标题里的 85% 对得上。注意这是综合成本包含了系统提示、用户输入、模型输出和按需注入的全部消耗。6.2 长期维护的三个习惯优化不是一次性的需要长期维护。我养成了三个习惯每月做一次 token 审计统计各类内容的占比发现异常膨胀及时处理。新功能先问是否常驻任何要加进系统提示的内容先判断能不能按需加载。保留优化前后的对比数据方便回滚也方便向团队说明效果。6.3 什么情况下不该过度优化不是所有场景都值得把提示词压到极致。如果调用频率很低比如一天就几次那 1.4 万 token 的开销其实可以接受优化投入产出比不高。优化的前提是调用频率足够高固定开销的累积效应明显。另外如果任务类型非常单一比如只做一件事那系统提示本来就不需要很复杂也就没有优化空间。优化的价值主要体现在任务类型多样、调用频繁的场景。6.4 后续可以扩展的方向这套思路可以继续往下延伸。比如把按需注入做成更细粒度的检索根据任务关键词从知识库里动态检索最相关的片段注入而不是按预设的映射表。再比如把系统提示做成可版本管理的配置每次改动都有记录方便回溯。我个人在实际操作中的体会是token 优化的本质是信息架构问题不是提示词技巧问题。你把信息放对位置成本自然就降下来了。反过来如果信息架构是乱的再怎么调提示词技巧都是治标不治本。所以动手之前先想清楚哪些信息该常驻、哪些该按需、哪些该外置比急着改提示词更重要。