1. 从一次账单复盘说起为什么我要动系统提示词去年年底做年度成本复盘的时候我把几个主力 AI 编程助手的账单拉出来横向对比结果有点扎心。同样一个中型重构项目用 Claude Code 跑完整个流程光输入侧的 Token 消耗就比预期高出一大截。我一开始以为是自己的用法有问题——上下文塞太多、历史对话没清理、文件反复读取。排查了一圈才发现真正的隐形大户是每次请求都要携带的那份系统提示词。Claude Code 的系统提示词规模在 1.4 万 Token 左右这个数字意味着什么意味着你哪怕只问一句这个函数干嘛的背后也要先吞掉 1.4 万 Token 的固定开销。按当时主流模型的输入计价单次请求的固定成本就摆在那里日积月累下来非常可观。我算过一笔账如果一天交互 200 次光系统提示词这一项一天就是 280 万 Token 的输入量。这个量级下账单想不涨都难。后来我把目光转向了 Pi 这个方案。它的系统提示词经过精简后只有 200 Token 左右从 1.4 万砍到 200压缩比接近 70 倍。实测迁移完成后整体 Token 账单下降了约 85%。这个数字不是理论值是我自己项目里跑出来的真实结果。这篇内容适合两类人看一类是正在用 AI 编程助手、但没仔细算过成本账的开发者另一类是对系统提示词设计、上下文工程感兴趣想搞清楚提示词到底该怎么瘦身的技术同学。我会把迁移的完整思路、每一步的操作细节、踩过的坑都摊开讲你可以直接照着复现。2. 系统提示词到底在干什么先搞懂成本从哪来2.1 系统提示词的三个核心职责很多人对系统提示词的理解停留在给 AI 定个角色这个层面其实远不止。一份完整的系统提示词通常承担三件事第一是行为约束。告诉模型该怎么做事、不该做什么、遇到边界情况怎么处理。比如修改文件前必须先读取不要臆测不存在的 API这类规则。第二是工具定义。AI 编程助手要能读写文件、执行命令、搜索代码这些能力都靠工具描述来声明。每个工具的用途、参数、返回格式都要写清楚模型才知道什么时候调用哪个。第三是上下文注入。把当前项目结构、技术栈、约定规范等信息塞进去让模型知道自己在哪。Claude Code 的 1.4 万 Token 里这三块都有而且写得非常详尽。详尽本身不是坏事问题是大部分内容对大部分请求是冗余的。你改一个 CSS 颜色不需要知道完整的 Git 提交规范你问一个语法问题不需要加载整个工具链的详细说明。2.2 固定开销的复利效应系统提示词的成本特点是固定且重复。它不像对话历史那样可以裁剪每一次 API 调用都要完整携带。这就形成了一个复利结构交互频率单次系统提示词日固定开销月固定开销按22天50 次/天1.4 万 Token70 万1540 万100 次/天1.4 万 Token140 万3080 万200 次/天1.4 万 Token280 万6160 万200 次/天Pi200 Token4 万88 万看最后两行同样的交互频率光系统提示词这一项月开销从 6160 万降到 88 万。这就是 85% 降幅的主要来源。注意这还没算上因为提示词变短、模型响应更快、上下文窗口更宽裕带来的间接收益。2.3 为什么砍不等于删这里要澄清一个误区。把系统提示词从 1.4 万砍到 200不是简单地把内容删掉而是把静态的、通用的内容转成动态的、按需加载的内容。打个比方Claude Code 像是一个每次出门都把所有家当背在身上的旅行者不管今天是要去爬山还是去开会。Pi 的做法是出门只带钥匙和手机需要什么再回家拿。核心思路是延迟加载和按需注入。具体来说原来写在系统提示词里的工具详细说明改成工具被调用时才返回原来写死的项目规范改成从项目根目录的配置文件里动态读取原来一大段的角色设定压缩成几句最关键的约束。这样既保住了能力又砍掉了冗余。3. 迁移前的准备工作别急着动手3.1 先做一次成本基线测量迁移之前一定要先测基线否则你根本不知道省了多少。我的做法是选一个典型工作日记录以下数据当天总交互次数每次请求的输入 Token 和输出 Token系统提示词占比这个可以从 API 返回的 usage 字段里拆出来当天总花费把这些记在一个表格里作为对比基准。我用的是一个简单的脚本每次调用后把 usage 信息追加到日志文件晚上统一统计。这一步花不了多少时间但能让你后面有据可依。提示如果你用的是按量计费务必确认计价口径是输入还是输入输出两者差距很大。系统提示词属于输入侧重点看输入单价。3.2 梳理你真正依赖的能力不是所有人都需要完整的工具链。我建议你列一张清单问自己三个问题我平时用得最多的三个功能是什么比如读文件、改代码、跑测试哪些功能我一个月都用不到一次哪些智能行为其实是我可以手动完成的我梳理下来发现自己 90% 的交互集中在读代码 改代码 解释这三件事上而 Claude Code 里有一大堆高级工具我几乎没碰过。这些用不到的工具定义就是纯浪费。3.3 环境与依赖确认Pi 的部署相对轻量但有几个前置条件要确认运行环境支持你选择的模型接口项目目录结构清晰方便动态读取配置有一个可以存放精简后系统提示词的位置通常是一个配置文件或环境变量我建议先在一个独立的小项目上试跑别一上来就在主力项目上动刀。等流程跑通了再迁移到正式环境。4. 核心迁移实操从 1.4 万到 200 的完整过程4.1 第一步拆解原系统提示词的结构要砍先得知道砍什么。我把 Claude Code 的系统提示词按功能分成了几大块逐块评估模块大致占比是否可精简处理方式角色与行为约束15%部分可精简保留核心删掉重复表述工具定义45%大幅可精简改为按需返回项目上下文20%可动态化改为运行时读取输出格式规范10%可精简合并同类项示例与边界说明10%大部分可删只留高频场景工具定义是最大头占了将近一半。这部分内容的特点是写的时候很爽用的时候很少。每个工具的完整参数说明、返回值格式、错误处理加起来就是几千 Token。而实际上模型在调用工具时只需要知道有这个工具、大概干什么、关键参数是什么就够了细节可以在调用返回时再补充。4.2 第二步重写精简版系统提示词我的精简版系统提示词控制在 200 Token 左右结构大致是这样你是一个代码助手。规则 1. 修改文件前先读取内容 2. 不确定的 API 不要臆测先搜索 3. 保持代码风格与现有文件一致 4. 只做被要求的修改不擅自重构 可用工具读文件、写文件、执行命令、搜索。 项目规范见 .pi/config 文件需要时读取。就这么几句。你可能会问这么少够用吗实测下来对于日常的读写改查场景完全够。因为模型本身的能力已经很强系统提示词的作用是约束而不是教学。你不需要教它怎么写代码只需要告诉它你的规矩。关键技巧在于把原来教学式的内容改成约束式的。比如原来可能写了一大段当你需要修改文件时应该先使用读取工具获取文件内容然后分析……精简后就是一句修改文件前先读取内容。意思一样Token 省了 90%。4.3 第三步工具定义的按需加载这是省 Token 的关键一招。原来的做法是把所有工具的完整说明都塞进系统提示词Pi 的做法是系统提示词里只列工具名称和一句话用途工具被调用时返回详细的参数说明和示例如果模型调用出错错误信息里附带正确用法这样只有真正被用到的工具才会产生详细说明的 Token 开销。我统计过日常交互中平均只会用到 2-3 个工具相比原来一次性加载十几个工具的完整定义省下的量非常可观。具体配置上我是在 Pi 的工具注册文件里把每个工具的description字段写得很短把详细文档放到onCall返回里。这样模型第一次看到的是简版调用时才拿到详版。4.4 第四步项目上下文的动态注入原来写死在系统提示词里的项目信息技术栈、目录结构、编码规范改成运行时从项目根目录读取。我的做法是在项目根放一个.pi/config文件里面写项目相关的约定language: typescript framework: react style: 2空格缩进单引号 test: vitest系统提示词里只留一句项目规范见 .pi/config需要时读取。这样只有当模型真的需要了解项目规范时才会去读这个文件平时不占用 Token。注意动态注入的前提是模型有主动读取的能力和意愿。如果发现模型经常忽略这个提示可以在系统提示词里稍微加强语气比如修改代码前必须读取 .pi/config。4.5 第五步灰度切换与对比验证别一次性全切。我的做法是第一周新旧方案并行同一类任务分别用两套跑记录 Token 消耗和结果质量第二周以新方案为主遇到问题回退到旧方案第三周完全切换到新方案持续监控对比的重点不只是 Token 数还有结果质量。我当时的记录表大概是这样任务类型旧方案 Token新方案 Token质量对比单文件修改1.5 万0.3 万持平多文件重构3.2 万0.8 万持平代码解释1.4 万0.2 万持平复杂调试4.5 万1.5 万略降需补充上下文可以看到简单任务省得最多复杂任务因为需要补充上下文省得少一些但整体依然可观。复杂调试那个略降是因为精简后模型对项目背景了解变少需要我手动补充一些信息。这个可以通过在复杂任务前主动喂一段项目说明来弥补。5. 成本账怎么算85% 降幅的来源拆解5.1 直接节省系统提示词本身最直接的一块。假设原来系统提示词 1.4 万 Token现在 200 Token单次节省 1.38 万 Token。按一天 200 次交互算一天省 276 万 Token。这是最硬的一块。5.2 间接节省上下文窗口的释放系统提示词占用的窗口变小了意味着同样的上下文预算下可以塞更多有用的对话历史或代码内容。反过来说为了达到同样的效果你需要的总 Token 更少。这块的节省不好精确量化但实测下来大概能再贡献 10%-15% 的降幅。5.3 隐性节省响应速度与重试率提示词变短模型处理更快首 Token 延迟降低。更重要的是长提示词容易让模型迷失产生不符合预期的输出导致重试。精简后输出更聚焦重试率下降。我自己的重试率从大概 15% 降到了 5% 左右这部分省下的 Token 也不容忽视。把这三块加起来就是我实测的 85% 降幅。注意这个数字会因使用习惯不同而有差异。如果你交互频率低、任务简单降幅可能更高如果你经常做超复杂任务降幅可能略低但 60% 以上是稳的。6. 踩过的坑与排查技巧实录6.1 精简过头导致能力下降我一开始砍得太狠把一些看起来没用的约束也删了结果模型开始自作主张改代码时顺手重构了无关部分。后来加回了两条关键约束只做被要求的修改保持现有风格问题就解决了。经验精简的是说明性内容不是约束性内容。约束是底线不能省。6.2 动态读取失败.pi/config文件有时候读不到排查发现是路径问题。模型执行命令时的工作目录和项目根目录不一致。解决办法是在系统提示词里明确写清楚配置文件的绝对路径或者在启动时把路径注入环境变量。6.3 工具调用参数错误率上升工具定义精简后模型偶尔会传错参数。我的处理方式是在工具的错误返回里附带正确的参数格式和示例。这样模型第一次错了第二次就能改对总体 Token 反而更省。6.4 常见问题速查表现象可能原因解决办法模型不遵守约束约束被精简掉了加回核心约束条款读不到项目配置路径不对用绝对路径或环境变量工具参数传错定义太简错误返回里补充示例复杂任务质量下降上下文不足任务前主动补充背景节省不明显交互频率低检查是否有其他 Token 大户6.5 一个容易被忽略的细节系统提示词里的换行和空格也占 Token。我原来写提示词喜欢用大量空行分隔看着舒服但每个空行都是成本。精简时把多余空行去掉又能省一点。这个量不大但积少成多。7. 迁移后的日常维护与扩展思路7.1 建立提示词版本管理精简后的系统提示词虽然短但也是代码需要版本管理。我把它放在 Git 里每次修改都记录原因和效果。这样万一改坏了能快速回滚。7.2 按项目类型准备多套配置不同项目对助手的要求不一样。前端项目可能更关注样式规范后端项目更关注接口约定。我准备了几套.pi/config模板新项目直接复制对应模板省去重复配置。7.3 定期复盘 Token 账单迁移不是一劳永逸。我每个月会看一次账单对比系统提示词占比、平均单次消耗等指标。如果发现某类任务消耗异常就针对性优化。7.4 可以继续深挖的方向系统提示词精简只是第一步。后续还可以考虑对话历史的智能裁剪、代码上下文的按需检索、多轮交互的摘要压缩。这些方向每一个都能再挤出一些空间。我目前在做的是对话历史的自动摘要把超过一定轮数的历史压缩成一段摘要进一步降低长对话的成本。我个人在实际操作中的体会是成本优化的核心不是抠门而是把资源花在刀刃上。系统提示词从 1.4 万砍到 200省下的不只是钱还有每次交互的响应速度和上下文空间。这些省下来的空间可以用来塞真正有用的代码和需求描述让助手更懂你在做什么。如果你也在为 AI 编程助手的账单发愁不妨从系统提示词这一块先动手投入产出比是最高的。