预算又超了，而且这一次不是因为代码写得多，而是因为 AI 帮忙“想得太多”。上个月底我拉了一下账单，光是在各类编码任务上消耗的 Token 费用就比预期高出一大截。仔细排查之后发现，真正吃掉预算的大头，居然不是我写的业务代码，而是每次请求都会跟着走一遍的系统提示词。我用的主力工具是 Claude Code，它的默认系统提示词一度堆到了 1.4 万字符左右，这意味着哪怕只是让它改一个变量名，也要把这 1.4 万字符全部送进模型重新计算一遍。钱就是这么悄悄溜走的。
后来我花了两周时间，把主要工作流从 Claude Code 迁到了一个更轻量的工具 Pi 上，把系统提示词从 1.4W 砍到了 200 字符，Token 账单直接暴降 85%。整个过程谈不上复杂，但里面有些坑确实值得单独写出来分享。如果你也在用 AI 编程工具，并且对成本敏感，这篇文章应该能帮你省下真金白银。
1. 先从账单说起：AI 编程的成本究竟烧在哪里
很多刚开始用 AI 编程工具的同学，对成本的理解基本停留在“按量付费”这个模糊概念上。我也一样，最初觉得每次对话也就几分钱，能有多贵？直到看到月度账单才发现，真正的问题不是单次价格，而是重复计算。
1.1 系统提示词才是隐藏的“常驻租客”
你可以把一次 AI 请求想象成一次外卖配送。你点的菜是对话内容，但骑手从取餐到送达整个过程中，平台会额外加收打包费、配送费、餐盒费。在 AI 请求里，系统提示词就是那笔“打包费”——不管你聊什么，它都得先完整走一遍。
Claude Code 在默认状态下，系统提示词包含了工具定义、权限说明、工作流程指引、输出格式约束、安全策略等一大堆内容。我实际测了一下自己常用版本的字符数，大概在 13800 到 14200 之间浮动。按 token 换算，大约是 6000 到 7000 个 token。也就是说，每发起一次请求，无论你的对话多么简短，模型都要先把这 6000 多个 token 读一遍。
想象一下，你每次去便利店买一瓶水，都要先绕商场走一整圈才能到收银台。单次看好像无所谓，但当你一天发起几百次请求时，这部分“绕路成本”就非常可观了。
1.2 Token 计费模型里的乘法效应
为什么系统提示词影响这么大？因为 API 计费是按输入 token 加输出 token 分别计算的，而多轮对话还有一个更隐蔽的机制：历史消息累积。
拿我比较常用的模型来算一笔账。假设输入价格是每百万 token 3 美元，输出价格是每百万 token 15 美元。一次普通代码修改请求，用户输入可能只有 1000 token，但系统提示词就占了 6500 token。那么：
- 单次输入成本 = (6500 + 1000) / 1000000 * 3 = 0.0225 美元
- 如果对话持续 10 轮，历史消息还会不断追加，输入 token 越滚越大
这里还没算输出。如果你让 AI 重构一个大型函数，输出 2000 token，那输出成本就是 0.03 美元。综合下来，一次多轮任务可能就要 0.2 到 0.5 美元。听起来不多？但你一天跑 50 个任务试试，一个月下来就是 300 到 700 美元。
我在最开始估算成本时犯过一个严重错误：只算了“对话内容”的费用，完全忽略了系统提示词的固定消耗。实际跑了一周之后，我发现系统提示词占总输入 token 的比例，竟然高达 70% 到 80%。这是促使我认真研究迁移方案的根本原因。
2. 为什么选择 Pi：轻量，但不等于功能残缺
在决定迁移之前，我也考虑过其他几种方案：手动精简 Claude Code 的提示词、换别的工具、自己写一个封装层。最终我选了 Pi，理由其实挺朴素的：它足够轻，但核心能力没有缩水。
2.1 对比几套方案时的实际考量
先说手动精简提示词这条路。理论上可行，我也确实尝试过。Claude Code 允许自定义 system prompt 或修改配置，但问题在于它的工具调用协议很复杂。你要保留哪些工具定义？删掉哪些安全限制？这些都需要反复试错。我花了大概一个晚上把提示词从 1.4W 压到 5000 字符，但代价是部分工具行为变得不稳定，偶尔会出现权限错误或格式异常。对于一个生产力工具来说，这种不确定性非常致命。
换其他重型工具呢？市面上的很多 AI 编程助手其实都存在类似问题，只是程度不同。有的把系统提示词藏在模型层里，你想改也改不了。这种“黑盒”风格对我来说很难接受，因为我看不到每次请求到底消耗了多少 token，自然也无法做成本优化。
最后我注意到 Pi。它的设计思路和 Claude Code 很不一样：Pi 把系统提示词拆成了极简核心加可插拔模块。默认系统提示词只有 200 多字符，只交代最基本的角色和输出要求，剩下的能力全部通过工具定义在请求时动态注入。这意味着，如果你用不到某些工具，那些工具定义就根本不会出现在请求里。
2.2 Pi 的核心就是“按需付费”的逻辑
Pi 给我最大的启发是：AI 工具的能力不该是一碗大杂烩，而应该是自助餐。你取什么、用多少，完全由自己的需求决定。
举个例子，我用 Claude Code 时，即使只是做一个简单的字符串格式化，系统提示词里关于代码执行、文件编辑、终端操作的工具定义也全都会走一遍。而用 Pi 时，如果我的任务只涉及文本处理，那模型上下文里就只会有文本处理相关的工具定义。单次请求能省下多少 token，完全取决于你做的事情有多少。
从账单数据也能体现这种差异。我迁移之后跑同样的任务集，平均每个请求的输入 token 从 9500 左右降到了 1800 左右。输出 token 变化不大，但输入部分是降维式的缩减。一个月跑下来，总成本降了 85% 还真不是夸大其词。
有人可能会问，少这么多能力，是不是很多功能用不了了？我的体会是，日常开发中 80% 的需求其实只需要几个核心工具：文件读取、代码编辑、终端命令。那些花哨的自动化流程、跨模块联动，听着很高级，但实际使用频率远没有想象中高。砍掉低频能力，换来的是更快的响应速度和更低的成本，这笔账怎么算都值。
3. 迁移过程实录：从 1.4W 到 200 的完整拆解
真正动手迁移是在一个周末的下午。我给自己定了一个目标：用 Pi 完全替代 Claude Code 处理三类任务——代码编辑、文件操作、终端命令执行。下面记录的是我实际的操作过程，每一步都基于真实环境。
3.1 第一步：盘点自己真正需要的核心能力
在迁移之前，我先把 Claude Code 里日常高频使用的功能全部列了出来，做一个“必须项/可选项目”的清单。
必须项：
- 多文件代码编辑，尤其是跨文件修改
- 文件读写和内容搜索
- 终端命令执行和输出捕获
- 错误信息理解与修复建议
可选项：
- 网页搜索集成
- 项目脚手架生成
- 自定义工作流编排
- 多步骤任务规划
做完这个盘点之后，我发现一个很有意思的事实：真正影响效率的核心能力，也就前面那四项。后面那些可选项，看起来功能很丰富，但在我过去一个月的使用记录里，使用占比不到 15%。
这也给迁移打下了基础——因为 Pi 允许你按需添加工具，我只需要配好四个核心工具，就能覆盖绝大多数的日常工作场景。
3.2 第二步：配置 Pi 的最小系统提示词
Pi 初始化配置很简单，我花了大概 15 分钟就全部搞定了。核心就在一个配置文件中，指定模型端点、设置 API key、定义系统提示词。
我当时写的系统提示词只包含三个要素：
- 角色身份：我是谁，我负责什么
- 输出要求：代码必须完整、可运行，不做多余解释
- 约束条件：不主动修改无关文件，不推测用户意图之外的需求
全部加在一起，一个字符数很少的字符串，token 换算下来不到 60 个。再加上 Pi 框架自身的基础声明，整个系统提示词总共稳定在 200 字符上下。
这里有个小技巧值得分享：不要把这 200 字符浪费在“你要扮演……”“你应该理解……”这类话术上，而是把有限的字符空间全部用于“用户在什么场景下会发起什么请求，你要输出什么样的结果”。比如说“当用户贴出错误日志时，提取关键报错点并提供修复建议”，这样一句话就比“你是一个编程助手”有用得多。
3.3 第三步：工具定义的按需注入策略
Pi 工具的配置方式让我很舒服，每个工具都是独立定义的 JSON 或代码模块，在需要时动态附加到请求中。
我配置了四个核心工具。以代码编辑工具为例，我的定义包含了：
{ "name": "code_editor", "description": "编辑指定文件，支持多行替换、插入、删除", "parameters": { "file_path": "string", "operation": "replace|insert|delete", "start_line": "integer", "end_line": "integer", "new_content": "string" } }终端执行工具的定义更简洁，只需要命令字符串和工作目录两个参数就够了。
配置完成之后，我实际发起了一次请求测试。模型在识别到“修改文件”意图时，会主动加载 code_editor 工具定义，并调用相应参数。如果请求只是“解释这段代码的逻辑”，工具定义根本不会进入模型视线。这就是 token 大幅缩减的秘密。
3.4 第四步：工作流切换和习惯适配
配置只是第一步，真正的挑战在于习惯的改变。用 Claude Code 时，我习惯了那种“把任务丢给它，它自己拆解自己执行”的互动模式。而 Pi 的整体交互更偏向“明确意图 + 快速执行”。
刚开始的适应期大约有两天，主要就是调整自己的提问方式。以前我会说“帮我看看这个项目有没有 bug”，切换完之后我学会了更精确的描述：“扫描 src 目录下的所有 Python 文件，检查未定义变量和类型错误，列出可疑行号”。
这不是说 Pi 不能理解模糊指令，而是说当你的指令越具体，工具选择的路径就越短，token 消耗就越低，结果质量也越高。这种调整实际上是在帮你优化提问习惯，反而是个意外的收获。
迁移完成之后，我跑了一组实际项目的代码审查和修改任务，Pi 在功能覆盖和代码质量上和之前基本持平，但在响应速度上明显更快了。因为输入 token 少了，模型首字返回时间也相应缩短，体感非常直观。
4. 成本对比：85% 的降幅是怎么算出来的
数字是会上瘾的。迁移后我连续观察了整整一个月的成本数据，从多个维度做了对比，这里把结论分享出来。
4.1 单请求 token 消耗对比
| 对比项 | Claude Code | Pi | 降幅 |
|---|---|---|---|
| 系统提示词字符数 | 约 14000 | 约 200 | 98.6% |
| 系统提示词 token 数 | 约 6500 | 约 80 | 98.8% |
| 平均单次请求输入 token（含对话历史） | 约 9500 | 约 1800 | 81.1% |
| 平均单次请求输出 token | 约 1200 | 约 1150 | 基本持平 |
| 平均单次请求总成本（估） | 约 0.045 美元 | 约 0.009 美元 | 80% |
这个表格是基于我用同型号模型、同样任务集跑出来的数据。可以看到输出 token 变化不大，因为任务本身的复杂度没变。真正节省的部分全部集中在输入侧，而输入侧的绝对大头就是系统提示词。
4.2 月度账单的实际变化
我迁移前一个月的 API 账单是 428 美元，迁移后一个月是 61 美元。算下来降幅正好落在 85% 到 86% 之间。这 61 美元里还有一部分是我自己测试时反复调节产生的费用，如果按正常工作负载算，大概能压到 50 美元左右。
如果年化看，这等于从每年 5100 美元降到了每年 730 美元。省下来的钱，说实话拿来订输入法皮肤都能用好几年。当然，更重要的是这个成本降下来之后，我敢放心大胆地让 AI 处理更多琐碎任务，不用每次发起请求都心理斗争一遍。
4.3 除了省钱，还有两个隐性的收益
成本大幅下降的同时，我还注意到两个不太容易量化的变化。
第一个是响应速度。输入 token 减少直接降低了排队和计算时间，平均首token延迟从之前的 2.5 秒左右降到了 0.8 秒左右。在需要快速迭代的开发场景下，这个差异对手感影响非常大。
第二个是错误率降低。之前用 Claude Code 时，偶尔会出现因为提示词太长导致注意力分散、模型忽略某些约束的情况。Pi 的系统提示词极短，模型可以更集中地关注对话内容和工具调用。我统计了一下，迁移后一周内的失败重试次数，比之前一周少了将近一半。
5. 踩过的坑与排查经验：希望你能绕开
没有任何迁移是一帆风顺的。我把这一路遇到的问题整理成速查式的避坑清单，每一个都是我真金白银换回来的教训。
5.1 坑一：自定义工具定义格式不严谨
迁移初期，我犯过一个很典型的错误：在工具定义里写了过于复杂的参数约束，导致模型在某些边界情况下无法理解参数之间的关联关系，频繁出现工具调用错误。
后来我把每个工具的参数尽量扁平化，能用一个字符串传 JSON 就绝不用多个嵌套对象。比如代码编辑工具，我干脆把操作类型、起始行、结束行、新内容全部合并成一个对象，并且在描述里用最直白的语言写明每个字段。实测下来，工具调用的成功率从 86% 提到了 97% 以上。
5.2 坑二：对话历史累积让 token 悄悄反弹
Pi 虽然系统提示词很短，但如果多轮对话不主动清理，历史消息累积还是会推高输入 token。有一次我连续工作了三小时没清会话，最后一查，单次请求的输入 token 已经涨到了 6000 多，虽然还没到 Claude Code 那么夸张，但已经违背了轻量化的初衷。
解决方案很简单：给 Pi 配置一个自动截断策略，当对话超过一定轮次时，只保留最近 5 轮消息，更早的内容压缩成摘要。我在配置里加了一个 max_turns_per_session=5 的参数，之后 token 消耗就稳定住了。
5.3 坑三：不同模型对系统提示词的敏感度差异
不是所有模型都吃同一套提示词策略。我用同一个 200 字符的提示词分别测试了两个不同的模型版本，发现在更老的模型上，由于指令遵循能力偏弱，需要额外补充一些格式示例才能稳定输出。而在最新版本上，同样的提示词已经足够。
这说明一个问题：提示词精简是一个动态过程，不是一劳永逸的。当你升级模型版本时，最好重新测一遍提示词的效果，看看有没有可以进一步删减的空间，或者是否需要增加新的约束。
5.4 坑四：别把工具能力压得太狠
有段时间我追求极致 token 缩减，把文件搜索、代码格式化这些功能也砍掉了。结果就是每次需要搜索时，都得手动切到终端，用 grep 跑一遍再贴回来。效率反而更低了。
后来我重新加回了文件搜索工具，输入 token 多了一些，但整体效率明显提升。这个平衡点需要根据自己的使用习惯去摸索，核心原则是：砍掉那些你一个月都用不到一次的功能，但保留那些你每天要碰好几次的基础能力。
6. 迁移后的经验沉淀：给想要入手的你几点建议
距离完成迁移又过了一段时间，现在回头看，愈发觉得这个决定是对的。不过我也知道，不是所有人都需要走完全相同的路径，所以我把这些经验里的核心原则抽出来，作为更通用的参考。
6.1 先算账，再动手
很多人看到系统提示词 1.4W 砍到 200，第一反应是“我也要干”。但在此之前，建议你先拉一下自己最近一个月的用量和账单，算出系统提示词在总 token 中的真实占比。如果占比不到 30%，那优化提示词的收益可能没那么大；如果占比超过 50%，那迁移就非常值得做。
这个算账过程并不复杂，绝大部分 API 控制台都会提供 token 消耗明细，稍微汇总一下就能得出结论。我自己当时算出来的占比接近 75%，所以迁移的决心下得非常果断。
6.2 给自己留一周的“双轨运行”时间
不要周一决定迁移，周二就删掉旧工具。更稳妥的做法是并行运行一周：日常任务优先用 Pi 处理，遇到搞不定的场景再回退到 Claude Code。一周下来，你不仅会积累足够的 Pi 使用经验，还能统计出到底有哪些任务比较适合它。
用这种方式切换，我几乎没有任何生产力损失，整个过程平滑得像根本没迁过一样。一周之后，我把 Claude Code 的相关自动化配置全部停掉了，算是彻底完成交接。
6.3 定期复盘提示词和成本结构
迁移完成不代表优化结束。我的习惯是每两周看一次 token 消耗明细，每次升级模型之后做一轮新的最小化测试，确保提示词没有冗余、工具定义没有过时。
有一次我在排查一个响应异常时，发现 Pi 的配置里有一个旧版本的代码编辑工具定义和当前任务完全不匹配。删除之后，那个异常就消失了。这种问题如果不定时检查，根本不会注意到。
7. 最后分享一点个人的体会
这件事绕了一圈，给我留下最深的感触倒不只是省了多少钱，而是让我重新理解了 AI 工具设计的底层逻辑：大而全不等于好，恰到好处才是最优解。Claude Code 本身是个很棒的工具，只是它的设计取向和我的使用方式不太匹配。它那套庞大的系统提示词给足了上限能力，但也带来了持续的成本和延迟代价。而 Pi 用近乎“极简主义”的方式，帮我把每一分 token 都花在了刀刃上。
如果你正在用的 AI 编程工具也有系统提示词偏重的问题，不妨先别急着换工具，尝试用自己的配置去精简它。即使最后没有做到像 Pi 这样激进的 200 字符，哪怕只是从 1.4W 砍到 6000，也能带来接近一半的成本下降。这属于典型的“做了就有收益”的优化方向。
最后再分享一个小技巧：在 Pi 的系统提示词里加一句“如果用户请求信息不足以执行，请先提出一个澄清问题，而不是盲目执行”。这句话虽然多占了十几个字符，却帮我避开了好几次因为理解偏差导致的无效修改。有时候，好的提示词不是看你写了多少，而是看你写对了什么。
