1. 先说说为什么会有人想从 Claude Code 换到 Pi1.1 Claude Code 好用但账单真的有如针刺Claude Code 在编码助手圈子里名声不小我试用过一段时间它的交互设计确实讨喜多文件修改、自动跑测试、还能自己排查报错拿到一个仓库就能像真人一样干活。可问题也出在这里——它每干一件事都会把一大堆系统提示词一起算进 token 消耗里。默认配置下系统提示词动辄 1.4 万 token你再接上一些长一点的上下文每个会话的“固定支出”就摆在那里不管模型干了多少正事这部分钱都是要付的。我做了一个很简单的测试不写任何代码只启动一个脚本让它读一遍配置再退出。结果一个“什么都没干”的会话账上已经走了两万多 token。看到账单的那一刻我真有一种自己变成了冤大头的感觉。更难受的是这些消耗里很大一部分不是模型“思考”出来的而是被一个又长又重、每轮都要跟着请求一起发送的系统提示词吃掉的。1.2 Pi 是什么凭什么能替下 Claude Code后来我在一个开发者小群里看到有人提到 Pi说它是一个特别克制的终端 Agent——它的设计思路和 Claude Code 那种“全家桶”完全相反Pi 把系统提示词当成一个可配置的、按需加载的模块而不是默认塞满一整套风格规范、工具说明和示例输出。开发者可以自己决定这轮会话系统提示词到底放多少内容甚至可以压到只剩几句核心规则。这个思路让我眼前一亮。我需要的不是一个大而全的编码助手我只需要一个能读代码、能跑命令、能改文件的最小骨架其余能力完全可以通过“临时指令”在每一轮里按需求注入。换句话说Claude Code 是“开局给你一整栋精装房”Pi 则是“给你一间毛坯房装什么隔断完全自己定”。对于想把 token 变量控制在自己手里的人后者天然更友好。2. 动手前先解剖 1.4W 的系统提示词都去哪了2.1 默认配置里塞了哪些“隐形”内容很多人以为系统提示词就是最顶上那几句“你是一个编程助手”其实不是。我用日志抓取的方式把 Claude Code 默认系统提示词完整导出来看过里面大体包含这么几块角色设定与价值观约束通常占 3000 到 5000 token工具调用格式说明包含每个工具的参数示例、返回值约定几千 token 很常见十几条 few-shot 示例每条都带着完整的多轮交互模板编码规范、注释风格、测试要求等通用建议循环执行的控制信息包括如何判断任务完成、如何汇报进展等多文件编辑、代码检索的提示模板和系统级安全约束。这些内容单看都不算离谱但它们加在一起就会变成每轮请求都要携带的“固定重装备”。特别是当你只是想让模型帮你改一行代码的时候这一万四千 token 的“行李”也全程跟着你跑——这就是账单虚高的根本原因。2.2 哪些能砍哪些不能砍我针对每一块内容都会问同一个问题这一块真的需要每一轮都出现吗把这个问题想清楚削减方案就非常清晰了。角色设定和价值观约束可以在不必要时砍到一句话工具格式说明只在第一次调用工具前需要后续完全可以交给会话记忆few-shot 示例中真正有价值的也许只有一两条其余都可以删掉。但也有一条底线安全约束和核心输出格式不能动。比如“不要在修改前删除用户未确认的文件”“代码变更后需要展示 diff 摘要”这类规则一旦砍掉Agent 的行为就会变得不可控。我这里说的“砍到 200 token”不是把所有东西都删光而是把固定长期保留的内容压缩到极致其余全部变成临时指令随用随发、用完即走。3. 迁移实操5 步把系统提示词压到 2003.1 第一步安装 Pi 并接上模型源Pi 本质上是一款由某开源团队维护的终端 Agent安装方式非常简单一条命令拉取二进制文件然后初始化工作目录。初始化时会让你选择模型源我这里用的是兼容底座服务配好环境变量之后Pi 就能直接跑起来。curl -sSf https://pi-agent.example.com/install.sh | bash pi init --model-source remotepi init会生成一个配置文件建议把配置文件单独放到项目的.pi/目录里和代码一起提交到版本库。这样团队里其他人拉下仓库就能直接用同一套提示词配置不会出现各写各的混乱局面。3.2 第二步清空默认提示词从零搭建最小结构我的做法是先不看默认配置直接把它改成空文件然后一行一行往上加。这样做的原因是默认配置看多了会产生“路径依赖”总觉得哪句话都舍不得删干脆先归零再从实际需求出发写。第一版我写了三个模块system_prompt 你是终端编码助手。 每次回答前先列出将使用的命令。 代码修改后必须给出 diff 摘要。 这三句话加起来的 token 数连 30 都不到。换上之后我立刻跑了一个简单的“查找函数定义并解释”任务模型可以正常工作而且响应质量没有明显下降。关键就在于工具调用方式、上下文填充规则、历史记录摘要这些事并不需要放在系统提示词里教模型——Agent 框架本身会在请求拼装时自然加上。3.3 第三步用变量裁剪器检视每个词空系统提示词验证通过之后我开始做精细化修剪。这里的重点是分清楚“系统提示词”和“每轮请求的实际消耗”。Pi 配置里提供了几个变量占位符比如{os}、{cwd}、{branch}这些变量会在每轮请求前动态替换成具体内容。如果这些内容不是每一轮都必需把它们留在系统提示词里就是在烧钱。我用的方法是在本地跑一个小脚本把系统提示词里的每一行拿出来做“高频与低频”统计。具体思路是连续 10 次对话中某一句话都在每轮重复出现的标记为 high-frequency某一句话只在第一次对话时出现、之后基本不出现的标记为 startup-only某一句话会被变量替换成非常长的内容比如当前仓库文件列表的标记为 dynamic-heavy。对于 startup-only 和 dynamic-heavy 的内容我直接把它们移除出系统提示词改成在任务开始前通过一条临时指令注入。这样一个很常见的重构就发生了原先系统提示词里写“你可以使用rg搜索代码搜索时注意忽略 node_modules”改成在真正需要搜索的时候我再手动补一句“用 rg 搜索 XXX跳过 node_modules”。3.4 第四步用缓存复用把 200 token 变成 0 token在主流模型的 pricing 里输入 token 是计费大头尤其是那种每轮都要发送的长期提示词。但许多模型支持“前缀缓存”意思是只要请求的开头部分和上一轮一模一样这一部分就不再按完整费用计算只会按缓存命中收取极低费用。我利用的是这个特点。pi 的请求拼装是按固定页面对齐的系统提示词会被放在第一段紧跟其后放历史消息。只要我的系统提示词始终保持不变并且总长度不超过缓存页的大小后续请求就能一直命中缓存。我把提示词控制在 200 token 以内就是为了让这部分稳定地落入缓存里。实际测试中当会话进行到第三轮之后系统提示词部分的输入费用基本降到了零。注意缓存命中的前提是提示词不能发生任何字节级变化。如果你在系统提示词里加了时间戳、随机变量缓存就会整段失效反而更贵。3.5 第五步给 Pi 挂上“瘦身巡检”提示词又不是一劳永逸的东西——用久了总会手痒看到模型某个回答不满意就想在系统提示词里加一句“你回答得更详细一点”。这句话一加200 token 变成 210 token虽然不多但如果在里面混进去一段几百字的“补充说明”缓存页面可能直接翻倍。我给自己的规矩是系统提示词只允许在新增“输出格式”或“安全约束”时改动其余一概写成临时指令。同时我写了一小段监控脚本每次会话开启时把当前系统提示词长度打印出来超过 220 token 就直接报错。这种强制克制很有效至少把“顺手加两句话”这个坏习惯堵住了。4. Token 账单暴降 85% 的前前后后4.1 成本对标方法把三次采样算清楚要验证迁移效果不能只看一次对话的 token 数就下结论。我把对比拆成了三个场景场景A修改一个函数并补充测试交互轮次大约 6 轮场景B在项目中新增一个模块并运行测试交互轮次大约 10 轮场景C只读任务查找某个 Bug 的线索交互轮次 3 轮。每个场景分别在 Claude Code 和 Pi配同一型号的底座模型下跑三遍取 token 消耗的中位数。我做的是粗略的估算但即便如此样本方差也不会太大因为编码会话的特点就是固定消耗部分占大头。4.2 真实效果85% 是怎么算出来的我这里取一个比较有代表性的会话来说明修改代码并跑测试共 8 轮交互每次模型回复约 1800 token。Claude Code 场景下每轮的输入是“1.4 万系统提示词 以往轮次的累计历史消息 新的用户指令”到了第 4 轮以后单轮输入 token 就突破 2 万。中位数估算下来一个 8 轮会话的总输入 token 在 12 万左右。而 Pi 场景下系统提示词只有 200 token 且被缓存命中每轮追加的历史消息也更少因为我把总结历史的操作替换成了“只保留最近两轮原始消息 更早内容的一句话摘要”。整体算下来这个 8 轮会话的总输入 token 在 1.8 万左右节省幅度刚好达到 85% 这个量级。我把这个数据贴出来之后群里几个朋友也做了复现。他们的结论是会话轮次越多、系统提示词越长节省比例越接近 90%反之如果你只是跑个一两轮的简单问答节省幅度会缩水到 40% 左右。这也解释了为什么长任务、多文件重构、复杂 Bug 排查才是这种优化最受益的场景。5. 踩坑实录提示词砍得太狠会出人命5.1 砍掉代码规范后输出直接变成“自嗨”我第一次把提示词压到 30 token 时模型确实能干活但风格完全放飞。它会在一个 Python 文件里混进 JavaScript 风格的驼峰命名法还会在 commit message 里写各种情绪化文案。原因很好理解系统提示词里关于代码风格和项目结构的指引全部被我删了模型只能靠自身的“默认人格”去发挥。后来我在 200 token 里强制加了一句话“代码风格与仓库保持一致不确定时参照旧文件。”就这一句解决了大部分自嗨问题。它也让我意识到系统提示词压缩不是追求绝对最短而是在最短的前提下保住那些模型无法从上下文中自己推断出来的关键约束。5.2 语言提示没留中文对话直接崩还有个有意思的坑。我在压缩提示词的时候把“始终用中文回答”也删了结果模型在回答技术问题时中英文混杂得厉害有时还会整段输出英文。如果你用英文回复倒也无所谓但对中文用户来说这种割裂感非常难受。压倒性教训是语言提示一定要保留在系统提示词中不能放在临时指令里。因为不是每一轮你都会记得说“中文回答”而历史消息一旦以英文为主模型就会被带跑偏。现在我的 200 token 里固定包含这一个字段。5.3 200 token 平时的维护方式提示词压缩到 200 token 之后我基本不给它留加减 Counter 的余地。只有两种情况会动它换底座模型不同模型对角色设定的敏感性差异很大换模型时我会顺手清理一些针对旧模型风格的描述词把某个频繁使用的临时指令提升为固定指令如果我发现某条临时指令连续出现在 5 个以上会话中才会把它写进系统提示词同时删掉一句不那么重要的旧内容保持总量不变。我会维护一个“提示词版本说明”文件记下每次删改的原因和效果。比如“V3-2删掉工具调用格式示例减少 110 token理由是工具调用格式已由框架自动注入”。这个习惯帮我避免了很多“过了两周想改回旧版但毫无头绪”的尴尬。6. 谁适合照着这份实战做迁移如果你只是偶尔用编码助手改几行配置、问几个 API 用法那 Claude Code 这种开箱即用的工具完全够用省那点 token 的意义不大。但如果你和我一样每天要在终端里开很多长会话、频繁做多文件重构、或者在一个团队里共享同一套 Agent 配置那系统提示词从 1.4 万压到 200 带来的收益就不容忽视了。我在实际使用中还有一个体会token 优化这件事本身会倒逼你把“Agent 到底哪些行为是必要的”想得更清楚。以前我默认它什么都能干结果就是它什么都想干连带账单也一起膨胀现在提示词被压缩到只剩骨架我把更多能力放在按需临时注入上反而更容易控场。建议第一次动手的朋友不要一上来就追求极限压到 200先给自己设一个 500 token 的中间目标跑一周看看有没有不习惯的地方再逐步往下收。压缩提示词是一个动态调优的过程宁可多保留一点安全边际也别为了省钱把 Agent 变成不听指挥的野马。