我从上周开始把主力开发环境从 Claude Code 完整迁到了 Pi。最直接的变化是系统提示词从 14000 字符压缩到 200 字符每天的 Token 账单成本降了 85%。这不是在换一个更便宜的模型是在换一种更不浪费的使用方式。这篇文章我会完整拆解这次的迁移过程包括为什么 Claude Code 会这么费 Token、我是怎么一步步把提示词压下来的、迁移后的实际账单对比以及踩过的那些坑。适合所有在用 AI 编程助手、按 Token 付费、或者被长系统提示词恶心过的开发者参考。1. 为什么我必须离开 Claude Code1.4W 提示词是怎么吃钱的先交代背景。我日常用 AI 编程的强度很高一天大概发起 120 到 200 次请求涉及代码生成、重构、测试用例补写、跨文件修改等场景。之前我一直用 Claude Code功能确实强但账单也真让人坐不住。从一个月的实际消耗来看费用从几百直接上千而且我没觉得自己用了那么多。账要一笔一笔算清楚。1.1 先用一周时间记下我的真实 Token 消耗在迁移之前我做了个很笨但有用的动作手动把每天的请求日志拉下来统计每一次请求的输入 token、输出 token、缓存 token 和缓存命中情况。我不完全信任平台自带的成本估算直接对着日志里的 usage 字段算。整理一周数据后发现一个极其扎眼的事实我的平均输入 token 中有 30% 到 45% 来自系统提示词和工具定义20% 左右来自历史对话里的冗余重复内容真正用来放代码上下文的只占一半上下。举个例子一次简单的“帮我给这个函数加个参数”的请求模型实际上接收到的内容包含大量系统级指令、工具 JSON Schema、环境信息、使用风格说明。而这些内容跟用户这次的真实需求完全无关但它们每一轮都会重新占输入长度。你每问一句它就收一次“入场费”。1.2 Claude Code 的提示词为什么这么“胖”很多人不知道 Claude Code 的系统提示词到底有多长。我实际把完整 system prompt 拉出来数过字符量在 1.4 万左右换成 Token 大概是 5000 到 7000 上下具体取决于切分方式。这 1.4W 字符都包含什么拆开看大概是这几块身份与角色设定、工具描述和 JSON Schema、文件操作和环境指令、代码风格约束、输出格式要求、安全规则与边界限制、用户协作协议和交互方式说明。每一块单拎出来都有它存在的理由但合在一起就是一个基线非常高的“固定开销”。固定开销的可怕之处在于跟你的请求次数成正比。你一天请求 100 次它就膨胀 100 次。哪怕你每次只写 50 个字符的 prompt模型读完你写的内容之前先要吃掉 6000 个 Token 的系统提示词。1.3 成本模型的真相不是模型单价贵是“口粮”太大我做了一个很简单的数学模型把所有请求分成三类请求类型平均输入 Token系统提示占比短需求改参数、加日志800075%中需求写函数、改逻辑1800033%长需求跨文件重构4500013%短需求在低频场景下没什么感觉但如果你跟我一样高频使用75% 的输入是固定开销这就是灾难。按当前主流 API 的价格换算一个 8000 输入 Token 的短请求里真正为“用户需求”付费的部分不到四分之一。换句话说我过去有差不多七成的 API 费用买的是每次对话都会被重复加载一遍的说明书。后来我意识到这既是产品机制设计的结果也是我自己没有认真做成本优化的结果。2. 为什么是 Pi迁移方案选型背后的硬逻辑其实我也看过几个替代方案有的模型本身很便宜但功能接口我不满意有的框架能自己改提示词但工程侵入性太强。最后选 Pi是因为它从架构层面解决了“固定开销”的问题。2.1 我筛选工具的几条硬标准坦白讲换工具不是一句“哪个便宜用哪个”这么简单不然直接换更低价模型就完了。我当时的筛选标准明确列出来系统提示词必须完全可自定义且可控不接受“平台帮你优化”的黑盒。工具调用接口必须支持按需动态注入不能把所有工具定义都塞进每一轮请求。上下文管理要透明我得能看清每一轮实际发了什么内容。支持主流模型切换不要锁死某一家。开源或者至少有完整可审查的日志能力。对照下来Pi 是少数几条都满足的。它把系统提示词抽成了一个用户可以完全改写的独立模块工具的 Schema 也不再是常驻的“全家桶”而是等用户真正触发某个工具时才拼到请求里。2.2 Pi 的核心架构优势Pi 的设计思路和我之前用的工具有本质差异它默认认为“每一轮请求都应该尽量小”。具体体现在几个方面第一主提示词模块极短。它只保留了模型必须知道的基本角色和行动边界剩下的细节全部外置。第二MCP/工具定义采用动态加载。写代码时常用的读文件、写文件、执行命令这类工具Pi 有“常驻白名单”选项低频工具像请求外部接口、搜索文档、操作数据库则在你发出相应指令时才把对应 Schema 动态拼进 prompt。第三请求前自动做上下文裁剪和语义去重。比如前面的对话里已经完整出现过某个文件内容后面再次引用时Pi 会生成一个轻量摘要而不是把原文再送一遍。这些机制相加造成的结果是同样一个任务在 Claude Code 下输入 2 万 Token在 Pi 下可能只需要 3000 到 5000 Token。2.3 迁移前我想清楚的三个问题选型不是理论上能省钱就行还得落地。我花了两个晚上验证三件事核心工作流能不能覆盖。我常用的“写文件—编译—运行测试—看报错—修改”整条链路Pi 都接得住。习惯迁移成本高不高。Claude Code 的一些交互习惯跟 Pi 不同我给自己做了一个小的指令别名映射把高频操作缩成短命令。模型切换怎么处理。Pi 支持我自定义模型供应商和模型版本我只改动配置文件就完成了切换没有改任何业务代码。迁移过程比预想顺利。花了一个晚上完成基础配置第二天直接用 Pi 处理了三个真实开发任务其中一个还是跨文件的接口重构。从结果上看输出质量没有明显下降但输入成本肉眼可见地缩水。3. 系统提示词从 1.4W 砍到 200 的实操压缩方法论这是整个迁移里最核心的一步。很多人以为压缩系统提示词就是把字删删少实际上不是。200 字符和 14000 字符之间差的不是“字数”而是“职责边界”。3.1 先用“三段式拆分”看清提示词的真正职责拿到原始 1.4W 字符的提示词后我第一件事不是改而是先分类。我是用成本思维去分类的每一类内容在请求中承担的职责是什么分类占比目的是否可以外置身份角色与全局设定5%让模型知道自己是谁可精简到极短工具描述与 JSON Schema35%告诉模型有哪些工具可用可以按需加载代码风格与行为约束20%让输出符合用户预期可以拆到动态指令安全边界与拒绝规则20%限制模型不要做危险操作保留硬约束即可输出格式与协作说明15%指导模型如何组织回答可精简示例与扩展上下文5%演示期望行为可以直接删除结论很明显35% 的工具定义是可以在绝大多数请求里省掉的20% 的行为约束其实很多条目模型根本不会触发还有 20% 的安全规则可以压缩成更短的正向默认约定。3.2 我的 200 字符核心提示词长什么样这是我现在实际在用的系统提示词不多做解释直接照抄你是可靠的编码助手。依据用户代码库完成读、写、改、查等任务。优先做最小改动不臆测接口不输出多余解释保持既有代码风格。涉及破坏性操作前需用户确认。数一下不到 150 个汉字转成英文 Token 大概是 200 上下。这份提示词覆盖了角色、行动、约束、确认机制全部核心需求。有人会问这么短模型真的够用吗答案是够的因为接下来每轮请求中Pi 会根据当前任务动态拼入工具定义和相关约束而不是把所有知识一次性灌给模型。3.3 工具定义如何从“常驻”变成“按需”这是整个优化里收益最大的一块也是我认为 Claude Code 这类产品最“花冤枉钱”的地方。它们的系统提示词会一次性加载全部工具定义包括你一辈子都用不上的接口说明。Pi 的解法是懒加载。它把工具 Schema 分成几个层级常驻层比如 read_file、write_file、run_command这些高频工具保留在提示词里因为调用频率极高动态加载反而会产生额外延迟和 Token 开销。按需层比如 search_code、list_directory、调用外部 API这些在用户提出相关意图时才由调度模块注入。手动层比如数据库查询、部署脚本必须知道用户明确调用此功能时才加载。3.4 安全规则怎么压缩不再写“不要做 xxx”改写“默认做 yyy”系统提示词里的安全规则往往是重灾区。原始提示词里可能有十几条负面清单每一条都占 token。我采用的做法是把负面清单改成正向默认。举例“不要删除未确认的文件” → “涉及删除操作前先列出将被影响的文件并等待确认”“不要臆测不存在的接口” → “遇到不确定的接口先搜索代码库确认”正向默认的好处不只是字数少还在于模型在行动时更不容易产生“边界感模糊”的问题。负面规则要求模型时刻判断“什么不能做”正向默认则要求模型不假思索执行一个安全动作。3.5 一个容易被忽略的细节把“语言风格”从提示词里删掉原始提示词里有一段很长的语言风格说明比如“请使用技术社区风格”“禁止使用口语化表达”“输出遵循某种格式”。这些内容看着无害但对成本影响很大。我的处理是把语言风格从系统提示词里移到用户轮次里在真正需要某种风格时用一次性的动态指令注入。没有特殊要求时模型就自然输出。就这么一个改动每个请求减少了大概 800 到 1200 Token。单个不显眼积累多了一天下来也省出一两百次请求的输入预算。4. Token 账单暴降 85%实测数据与成本复盘光说方法论没用直接看数据。4.1 我是怎么统计 Token 的迁移之后我依然保留了每天的日志统计习惯。Pi 的日志里可以直接拿到每次请求的 usage 字段我写了一个简单的统计脚本按天汇总输入 Token、输出 Token、缓存 Token 和请求次数。成本按当前的公开 API 单价统一折算方便对比。统计口径明确说明一下迁移前后用的是同一个基础模型档位模型单价没有变化变的只是请求内容的体积和缓存利用率。4.2 迁移前后一周的数据对比取其中代表性的一天都是正常开发日任务强度差不多指标Claude Code 期间Pi 期间变化日均请求次数158163相当平均输入 Token176006200-65%平均输出 Token34003100-9%日总输入 Token278万101万-64%日缓存命中 Token12万61万提升 5 倍估算日成本接近 100 元约 15 元-85%从表格里能看到一个关键点请求次数几乎没有变化但平均输入 Token 从 17600 降到了 6200。这 11400 Token 的差距完全来自系统提示词压缩、工具按需加载和上下文裁剪。4.3 85% 到底省在哪四笔细账我按原因做了一个拆解帮助自己确认钱省在哪个环节第一笔系统提示词压缩。从 14000 字符砍到 200 字符单次请求省约 4000 Token贡献约 25% 的成本下降。第二笔工具按需加载。低频工具不再常驻单次请求省约 3000 到 5000 Token贡献约 20%。第三笔上下文与历史裁剪。Pi 会把已经确认过的代码段落生成摘要不再全文重放单次请求省约 3000 Token贡献约 30%。第四笔缓存命中提升。由于前缀内容保持稳定更多请求能命中缓存输入费用打折扣贡献约 10%。4.4 迁移后我注意到的额外收获响应变快、错误变少成本降低之外有几件事是我没想到的。响应速度明显变快。输入 Token 少了首字延迟从原来的 1.5 秒左右下降到了 0.7 秒以内编码心情好了不少。错误率也下降了。之前偶尔出现的“模型突然进入拒绝状态”或者“忽然开始输出我不知道的接口”在缩减提示词后反而更少见了。原因是原始提示词里有些模糊的规则描述模型会在某些边界场景里过度诠释导致行为偏差。这让我重新理解了系统提示词的本质它不是你给模型的“全部智慧”而是模型行为的一个锚点。锚点太多太杂反而会让模型失去主心骨。5. 实战中最重要的几个坑压提示词不是越短越好如果这篇文章到这里就收尾你照着做可能会遇到一堆问题。事实上我在压缩到 200 字符的过程中就踩了不止一个坑这些才是最有价值的实战部分。5.1 把提示词压到 200 字后模型开始“说胡话”刚压缩完的第一天我用得很痛苦。问题集中在模型开始自作主张地补全接口明明代码库里没有这个函数它硬是给我写了一段“看起来合理的假代码”。我一度怀疑是模型换了个低档的其实不是是我把安全规则压过头了。原始提示词里有一条“不要臆测接口”被我当成废话删了。结果模型每次面对不太确定的地方都会用概率最高的“看似合理”答案填上。这对编码场景几乎是致命伤。后来我把这条加进了动态指令层就是在代码补全、接口引用这类任务时由调度模块额外注入一条“不确定的接口先搜索仓库确认找不到就明确说不存在”。问题立刻消失。得到的教训是有一些硬约束不属于压缩范围它们不应该在系统提示词里占大量篇幅但必须在关键行为点上动态存在。5.2 只看到输入降价忘了输出也会变差另一个坑更隐蔽。系统提示词压缩后输入成本确实降了但有几类请求的输出质量不稳定尤其是需要解释复杂设计决策的时候。模型的回答变得非常干没有前因后果也没有备选方案。原因很好理解原先系统提示词里有一段“输出格式与协作说明”里面写了“提供结构化分析、说明背景与权衡、列出备选方案”压缩后这些引导消失了。处理方式不是加回系统提示词而是把这些引导挪到了特定任务的用户上下文里。处理复杂重构时我主动追加一句“说明两个备选方案的权衡”简单任务不加。5.3 别把“缓存”当万灵丹缓存命中失效的坑用 Pi 之后我看到缓存命中数据很漂亮以为成本已经智能降下来了。直到某一天我发现自己改了几行工具配置缓存命中率当场暴跌一半日成本回升了接近 30%。原因是缓存生成的 key 包含系统提示词的前缀内容。只要前缀内容有任何变动哪怕只是一行注释全部缓存的命中都会失效。工具配置、角色描述、上下文摘要策略这些东西每改一处之前的缓存就白建了。所以我的建议是优化要集中做不要白天改一版、晚上又改一版。每改一次等于把之前几天的缓存积累全清空。等你把提示词和策略完全调稳定了再上线运行让缓存充分堆积。5.4 工具按需加载的极限调用频率高也要考虑“少量常驻”虽然我说工具要按需加载但有一个反向问题如果某项工具每两轮就要用到动态加载反而更费。因为每次动态加载产生的调度开销、判定逻辑也会消耗少量 Token 和延迟。我在实测中发现read_file、write_file、run_command 这类工具还是常驻更划算。而像 Git 操作、搜索、网络请求这类中频工具可以放在动态层。我至今还在动态调整这个分层边界原则是“凡是出现在 50% 以上请求里的工具考虑升级为常驻”。5.5 一个我至今仍在用的自查清单最后分享一个我自己压提示词的检查清单虽然不长但每次改完配置都会过一遍模型的核心身份和一行动边界清晰吗高频工具是否存在重复加载或常驻过多的情况每次改动是否会大面积破坏缓存 key危险操作是否有一个默认的安全动作而不是单纯地“禁止”输出风格要求在本次请求是否真的需要最后再分享一个小经验我个人实际操作中的体会是迁移到 Pi 并不是单纯换个更便宜的工具而是逼自己重新思考 AI 编码助手里每一分钱到底花在哪。以前在 Claude Code 里我总觉得提示词是平台的事反正它已经写好了我不用管结果就是每个月为大量闲置的工具定义和重复的历史上下文买单。把系统提示词砍到 200 字符之后我才发现模型真正需要的确定性远比我以为的少。如果你也想做类似的迁移不要一上来就追求极致压缩。先把原始提示词完整拆一遍理解每部分是干嘛用的然后问一个问题这个能力是每轮都需要还是碰到了再加载按这个思路做一轮你的 Token 账单大概率也会经历一次两位数级别的下降。