★ FEATURED ARTICLE 本月账单出来的时候我盯着那串数字沉默了很久。一个中等规模的日常开发项目一个月光 Token 费用就烧掉了近千美元而真正让我肉疼的不是模型输出而是每次请求都跟着走的系统提示词。当时主力工具是 Claude Code功能确实强文件读写、终端执行、多工具调度都很顺手。问题出在它的系统提示词太长随便打开一次交互光系统提示词就是 1.4 万字折合下来接近 1.6 万 tokens。这意味着哪怕我一句话都没说模型还没开始干活这一万多 tokens 就已经在计费了。后来我把主力工具迁到了一个主打轻量化的开源 CLI 编码代理 Pi把系统提示词从 1.4W 砍到 200 字左右Token 账单直接降了 85% 以上。这篇文章就把我迁移前后踩过的坑、算过的账、砍掉的每一块提示词都拆开讲清楚。如果你也在用带重型系统提示词的编码工具或者正被 API 账单折磨这篇文章会告诉你问题出在哪、怎么迁移、迁移后要注意什么。1. 为什么系统提示词会成为账单大头1.1 先把 Token 计费这件事掰开很多人对 Token 账单的理解停留在我输了多少字模型回了多少字。实际上本地编码工具走 API 时每次请求都会拆成三部分计费系统提示词、对话上下文、模型输出。前两部分合并成输入 tokens第三部分是输出 tokens。输入和输出单价不同通常输出更贵但输入胜在量太大。以我当时用的某款主流模型为例输入侧价格大约是每百万 tokens 3 美元如果命中了服务端的提示词缓存价格可以降到每百万 0.3 美元左右输出侧每百万 tokens 15 美元上下。看着不贵但乘上请求次数就完全不一样了。假设每天有 600 次请求每次请求的系统提示词是 16000 tokens哪怕全命中缓存一天就是 600 乘以 16000 tokens。这个量级算下来一个月光系统提示词的缓存读取就是一笔不小的数目。更要命的是如果工具在系统提示词后面拼了动态的日期、当前目录、临时任务描述那整个缓存就失效了全部按正常输入价计费成本直接翻十倍。我当时打开用量明细输入 tokens 的占比高达 7 成以上而巨额输入里系统提示词又占了接近一半。也就是说我每个月有差不多三分之一到一半的钱花在了一堆我根本没写过的固定文字上。1.2 1.4 万字的提示词到底装了什么Claude Code 这类工具的系统提示词不是简单一段人设话术它更像一本被塞进每次请求里的产品说明书。翻开那 1.4 万字里面大致有这些内容模型身份设定、当前日期时间、操作系统与运行环境描述、几十个工具的 JSON Schema 定义、每个工具的功能说明和参数约束、文件编辑规则、代码风格规范、安全策略、输出格式要求、内置示例对话。其中占空间最大的是工具定义。每个工具的描述动辄几十行字段、枚举值、参数校验规则全都要写清楚。比如一个读取文件的操作要告诉模型路径怎么传、权限怎么处理、找不到文件时返回什么格式。几十个工具叠在一起篇幅自然就上去了。这些内容不是没用而是每次都用就不划算。工具定义确实重要但绝大多数请求只用到其中四五个工具可计费却是按全部工具定义来的。这就像你去超市买东西收银员每次结账都要把所有货架的商品目录从头到尾念一遍才能找到你要的那瓶酱油。更麻烦的是动态内容。日期、当前项目路径、最近打开的终端输出这些是每次请求都会变的。服务端缓存对这种动态拼接的系统提示词几乎无效等于每次都是全额付费。我后来做过一个测试把系统提示词末尾的日期字段删掉后缓存命中率从不到 10% 提升到了 70% 以上。这个数据直接让我下定决心动刀。1.3 迁移到 Pi 之前我试过的三种优化我一开始没想直接换工具先尝试了三种常规优化。第一手工精简系统提示词。把一些不常用的工具说明删掉保留核心工具。结果发现这类工具普遍会把校验逻辑内置如果我删掉了某些字段描述工具调用就开始出错模型频繁报参数不完整。老老实实改回原样等于白折腾。第二开提示词缓存。把动态日期和 cwd 拼到用户消息里让系统提示词保持静态。这招有效但只解决了缓存命中问题。系统提示词本身那 1 万多 tokens 还是在每次请求里占着只不过单价便宜了。账单从吓人变成肉疼离根治还远。第三换更便宜的模型。把主力模型换到一个小参数模型上。结果能力跟不上复杂代码推理经常答非所问所谓省钱就是降质不实用。这三条路走完我开始意识到问题不在模型而在工具架构。Claude Code 把大量指令内置在自己的系统提示词里用户能做的手脚很少。我需要一个把系统提示词控制权完全交出来的工具Pi 就是在这个背景下进入我视野的。2. 提示词从 1.4 万砍到 200设计思路还原2.1 原始提示词结构拆解在做任何操作之前我先把 Claude Code 的系统提示词完整导出一段一段拆开看。这里分享一个笨办法直接把系统提示词复制到文本里按工具定义、环境信息、行为约束、输出规范、示例几个大类打标签然后统计每个大类的行数和 tokens 占比。我导出的结果大致是这样内容模块占提示词比例说明工具定义约 45%几十个工具的 JSON Schema字段多、描述长行为约束约 20%禁止操作、调用顺序、错误处理规则环境信息约 15%系统版本、时间、路径、平台差异说明输出规范约 12%Markdown 格式、代码块风格、回复结构内置示例约 8%少量几轮对话样例拆分之后我心里有数了真正无法绕开的核心指令可能只占两成剩下八成都属于可以在适当时候按需加载的内容。工具定义是最大的肉。但仔细看模型在具体任务里只用得到少数几个工具。如果能把全部工具定义改成按需注入当前任务可能用到的工具定义理论上可以把这 45% 的篇幅全部省下来。这也是 Pi 做法的核心思路。我还注意到很多行为约束其实是重复的。比如修改文件前先读取文件这句话在系统提示词里出现了一次在某些工具描述里又写了一遍对话示例里还演示了一遍。三处内容指向同一规则对模型来说不一定有害但每处都占 tokens。2.2 精简到 200 字之后保留了什么Pi 的默认系统提示词极短。我迁移后导出来看完整内容翻译成大白话是你是一个在代码仓库内运行的编码代理。所有操作必须在仓库上下文内完成。修改文件前必须先读取文件执行命令前先确认命令意图。遇到不确定的路径或符号先搜索再操作。不要臆造不存在的文件。加上少量格式要求总共不超过 250 tokens也就是 200 字左右。你有没有发现这段提示词里没有提到任何一个具体工具。它不写你有读写文件的工具因为工具定义被放到了请求的更底层由运行时按需注入。模型在某个回合需要读文件时系统才会把 read_file 这个工具的真正 schema 塞进当轮请求。这就好比把一本 500 页的 API 手册从每次开机都自动加载改成了你按下对应快捷键才弹出对应章节。职责分离之后固定开销被压缩到了极限。当然200 字不是随便拍脑袋砍出来的。它保留了四类不可省略的信息第一身份边界。明确告诉模型你是仓库内的编码代理避免它把自己当成通用聊天助手跑偏。第二操作底线。修改前先读取命令前先确认这些是防止模型乱来最关键的约束。第三错误原则。不要臆造不存在的文件这句省掉之后模型偶尔会虚构路径导致一连串报错。第四上下文锚点。告诉它在仓库上下文内完成相当于给所有后续推理装了一个定位器。其余的复杂规则、工具 Schema、示例对话全部从静态提示词里移出去了。2.3 为什么瘦反而跑得更快最初我有个疑问提示词砍这么狠模型还能理解复杂任务吗实际跑下来发现非但没有变笨很多场景反而更稳定了。原因是当代大模型的注意力机制对输入长度很敏感。系统提示词越长模型在生成时需要考虑的信息越多。长提示词里的工具定义和规则会在推理过程中形成大量与当前任务无关的注意力权重稀释真正重要的用户指令。我甚至遇到过原工具在长提示词下把规则中的示例当成任务执行的情况。Pi 的轻量提示词等于给模型创造了一个极简工作台桌面上只有你交给它的任务、少量必要工具、极少数规则。它不用在几十个工具描述里做排除法直接把注意力放在文件和代码上。第二点是缓存效率。短提示词的缓存效果出奇地好。因为内容几乎不变服务端缓存命中率可以稳在 90% 以上。而长提示词一旦带动态字段缓存基本全废。这部分的成本差距比单纯看 tokens 数量还夸张。第三点是我的个人感受任务可预期性变强了。一个只有 200 字提示词的工具它的行为边界和可控性反而更清晰。你明确知道模型手里有什么牌不会出现我以为它知道某个工具结果它自己 discover 了一堆奇怪行为的情况。3. 迁移实操全流程3.1 适合迁移的项目画像不是所有项目都适合从重型工具切到 Pi 这种轻量工具。我先说结论如果你做的是单仓库、常规编码任务比如写接口、修 bug、补测试、重构函数那非常适合迁移。如果你重度依赖多仓库联动、复杂 MCP 服务、需要跨系统深度编排那要慎重。我迁移的是一个约 4.2 万行的 TypeScript 和 Go 混合仓库日常任务集中在 bug 修复、单元测试、接口实现。整个迁移过程在周末两天内完成没有影响业务开发。动手前我列了一个检查清单检查项我的情况是否满足仓库是否单目录可理解是各服务有清晰目录结构满足是否有大量自动化测试部分主要服务有测试满足是否重度依赖 IDE 绑定否CLI 为主满足是否使用自定义 MCP 服务是一个内部文档检索服务需要适配团队是否多人共用同一账号是需要统一 API key 管理满足如果第 4 项依赖特别多建议先做小范围试点。我自己的 MCP 服务后来也成功接入了 Pi只是配置方式不一样。另一个要注意的是迁移不是把原工具的配置搬过来而是要用新工具的思维方式重新组织项目。你在原工具里设置的复杂规则大概率在 Pi 里用不上要忍痛删掉。3.2 安装与初始化Pi 的安装很简单和大多数 Go 或 Rust 写的 CLI 工具一样一条命令就能拉下来。我用的方式curl -fsSL https://example-cli.pi/install.sh | bash如果你的环境不允许管道执行脚本也可以直接下载二进制放到 PATH 目录里。装完之后先初始化pi init这个命令会生成一个配置文件目录通常是~/.pi/config.yaml。里面最核心的是 API key 和默认模型配置。Pi 兼容 OpenAI 格式的接口所以大多数模型服务商都能直接配。我当时是这样配置的provider: base_url: https://api.example-model.com/v1 api_key: ${PI_API_KEY} model: default: coding-model-latest temperature: 0.2 max_tokens: 4096 prompt: mode: lite这里有个细节容易被忽略${PI_API_KEY}这种写法是让 CLi 从环境变量读取 key不要直接写在配置文件里。团队多人协作时各人用自己的 key既安全也方便权限隔离。初始化完了之后进入项目目录跑一次pi status确认它能正常读取仓库结构和 git 状态。如果这一步通过了说明基本链路已经通了。3.3 项目级配置与工具链适配Pi 和原工具在项目配置上最大的区别在于它推崇约定优于配置。它会在项目根目录找AGENTS.md或者CONVENTIONS.md这类文件当模型需要了解项目规范时才按需读取。这比把所有规范塞进系统提示词聪明得多。我在项目根目录建了一个很短的CONVENTIONS.md# 项目约定 - 测试文件与被测源码放在同级 test 目录下 - 新函数必须附带 JSDoc 注释 - 数据库迁移文件命名timestamp_description.sql - 提交信息格式类型(模块): 描述全文只有 4 行但它覆盖了团队最在意的四件事。Pi 不会把这个文件的内容预先注入每次请求而是在模型要写新代码或提交时通过工具调用动态读取。接下来是工具链适配。原工具里的自定义 MCP 服务在 Pi 里可以通过 MCP 配置接入。我那个内部文档检索服务是这样配置的mcp: servers: docs-search: command: python args: [mcp_docs_server.py] transport: stdio如果你用的是远程 MCP 服务配置里换成 URL 和 headers 就行。接入之后的效果和原工具几乎一样模型需要检索内部文档时会自动调用。还有一个重点是 shell 工具。原工具默认会有一些经过打磨的 shell 工具Pi 这边的实现更简洁。对于日常的 grep、find、git log 这类操作简版工具完全够用。但如果你的项目里大量使用 Docker 容器操作我建议先测试一下 Pi 的 shell 工具能否正确捕获容器日志这一块容易出问题。3.4 模型路由与关键参数迁移初期我直接照搬了原工具的 temperature 和输出长度设置结果发现效果不理想。后来认真把每个参数试了一遍。temperature 这个参数原工具在代码生成任务中默认给了一个比较低的数值我保持一致。但如果模型输出明显变得保守、不敢改代码可以微调到 0.3。max_tokens 我建议给到 4096 以上。轻量提示词下模型有更多生成空间用来写长函数如果限制在 2048复杂任务容易被截断。还有一个值得说的是按需注入工具这个参数。Pi 支持设置工具注入策略默认是 auto。如果你的项目经常用到的工具比较固定可以手动指定一个工具白名单让系统每次都只注入这几个。我最初手动圈了 read_file、edit_file、run_command 三个后来发现不够用重新切成 auto 才解决。日志级别也有讲究我建议迁移期间把日志开到 debug。Pi 的调试日志会打出每个回合实际注入的工具定义和 tokens 数这对排查为什么这次请求这么贵非常有用。看到实际注入的工具数量后你就知道哪些参数设置没生效。4. 实测一周账单、速度、质量三方对比4.1 成本测算方法与数据迁移完成之后我连续跑了五个工作日收集了完整的用量数据。为了不被不同时段的模型价格波动干扰我用的测算方法是记录每天的请求次数、输入 tokens、输出 tokens然后用固定单价计算。下面这张表选取的是第五天的实际数据这一天比较有代表性指标原工具Pi降幅日均请求次数约 600约 600平系统提示词 tokens/次约 16000约 250-98.4%上下文 tokens/次约 6000约 2200-63.3%输出 tokens/次约 200约 200平单次输入成本约 0.066约 0.0066-90%单次输出成本约 0.003约 0.003平单次总成本约 0.069约 0.0096-86.1%日均成本约 41.4 美元约 5.76 美元-86.1%这里假设输入单价每百万 tokens 3 美元输出单价每百万 tokens 15 美元。Pi 侧系统提示词按缓存命中计费所以单次成本更低。可以看到真正省下的钱集中在输入侧尤其是系统提示词部分。输出成本占比不大因为日常轻量任务本身输出量就不高。五天综合下来平均降幅在 85% 左右。如果算上缓存命中率差异原工具因为动态字段导致缓存基本失效Pi 的固定提示词长期稳定命中实际差距还会拉大。这里也给大家一个提醒如果你的任务大量输出长文本比如让模型生成长文档那么输出成本会占据大头提示词瘦身的收益会被稀释。不要期待任何项目都能降到 85%这个数字和任务类型强相关。4.2 延迟和吞吐变化迁移之前最担心的是工具响应变慢。因为提示词精简了模型的思考步骤应该更短但工具调用需要按需注入会不会拖慢节奏实测结果让我放心。单次请求的端到端延迟从平均 3.8 秒降到了 3.1 秒左右。原因不复杂模型需要处理的输入 tokens 大幅减少首 Token 生成时间明显缩短。虽然工具注入增加了一次内部查找但整体还是快了接近 20%。吞吐量的变化更直接。原工具时代我是串行地让它一个任务接一个任务做。Pi 的轻量上下文解放了并发我在测试中同时开了三个会话处理不同子任务彼此没有出现明显的上下文互相污染。不过也发现一个值得注意的现象如果请求太过频繁API 服务端的限流会先打到输入侧。因为短提示词让请求速度变快每个小时请求数变高更容易触发 rate limit。我的解决办法是给 CLi 工具配了请求间隔参数避免瞬时并发过高被服务端 429。4.3 代码生成质量边界省钱归省钱质量才是底线。我专门设计了三组任务来对比原工具和 Pi 的生成效果。第一组是 bug 修复。给两个工具同样一段报错日志和一个出错的模块让它们定位并修复。两者都能完成但 Pi 因为上下文干净给出的修复方案反而更聚焦。原工具偶尔会把无关模块的文件也卷进来改完一个 bug 弄出两个新的。第二组是单元测试生成。给一个复杂函数让两个工具生成测试用例。这里的差距出现了。原工具因为有大量内置示例和规则生成的测试用例风格更统一边界条件覆盖更全面。Pi 默认状态下生成的测试某些极端边界分支没有覆盖到。我后来在 CONVENTIONS.md 里补了一句测试必须包含空输入、超长输入、非法参数三个边界效果立刻改善。第三组是跨文件重构。让工具把某个模块从函数式风格重构为类风格涉及多个文件联动。Pi 在这个任务上表现出了明显的短板因为它不会预先把整个仓库的所有相关文件扫描进上下文需要在执行过程中逐步查找依赖遇到隐藏的循环依赖时容易卡住。原工具虽然有更长的系统提示词但实际上也没有解决这个问题反而因为上下文里混入太多信息导致修改路径更绕。所以我的结论很明确对于聚焦型任务轻量提示词全面占优对于全局型重构任务需要配合额外的仓库分析工具。不要指望一个 200 字提示词的代理能自动搞定所有仓库级的语义理解。后来我给 Pi 配了一个轻量的索引脚本把模块依赖关系在任务开始前生成摘要然后再让 Pi 干活。这个组合基本填上了跨文件重构的短板。5. 常见问题与排查实录5.1 系统提示词砍太狠的副作用迁移后第一周我遇到了两次模型失控的情况。一次是它在没读文件的情况下直接编辑了一个代码块导致语法错误另一次是它凭直觉创建了一个实际不存在的目录。后来定位到原因我用的自定义增强提示词把修改前必须读取文件这条规则写得太靠后被模型忽略了。解决办法是把操作底线重新放回提示词开头并且用强制语句而不是建议语句。比如禁止在未读取文件的情况下执行写操作比建议先读取文件管用得多。系统提示词瘦身之后副作用集中爆发在约束被稀释这件事上。原来长提示词里几百条规则即使模型不能完全遵循至少有一条可能被触发现在提示词短了每条规则的权重变高但也意味着每条都至关重要。如果要加规则一定要想清楚它是否真的不可省略。每加一句都会增加一次请求的 token 基数回到老路上去。5.2 工具调用与上下文丢失另一个常见问题是工具调用频率下降。原工具因为有完整的工具定义模型知道什么时候用什么工具Pi 在按需注入模式下如果某个工具不在当轮注入列表里模型就不会主动想到使用它。我的排查思路是看 debug 日志。当模型某个任务卡住我会检查那一轮请求到底注入了哪些工具。如果工具列表里没有文档检索服务模型自然无法搜索文档。解决办法是在需要频繁使用某类工具的任务开头手动强调一下。比如告诉模型先搜索相关文档再开始写代码可以促使运行时在下一轮注入搜索相关工具。这本质上是从系统提示词控制行为转变为用户指令动态触发工具注入需要从操作习惯上适应。上下文丢失的问题也出现过。Pi 不会把整个会话历史无限保存在上下文里它会做截断。当一个任务涉及步骤太多早期的一些关键决定可能会被挤出窗口。我的应对方式是把重要决策写在项目里的DECISIONS.md文件里让模型遇到不确定时回读这个文件。这算是用文件系统代替上下文记忆效果出奇地好。5.3 多模型切换下的行为漂移我配置了两个模型一个擅长代码推理一个擅长快速响应。在不同任务间切换时发现同一个精简提示词在不同模型上的表现差异很大。大模型对 200 字提示词的执行精度很高能准确平衡自由度和约束小模型则容易漏掉关键约束经常出现明明告诉它先读文件它还是直接改的情况。这说明精简提示词是有能力门槛的模型越强提示词越可以短模型弱一点反而需要稍微加长提示词做行为锚定。给多模型用户一个建议不要所有模型共用同一套精简提示词。为弱模型准备一个稍微完整一点的版本比如把先读文件再修改展开成具体步骤为强模型保留极简版。损失一点点 tokens换取稳定输出很划算。5.4 常见问题速查表现象可能原因解决办法模型不读文件直接改代码精简提示词里操作底线丢失强制规则重新前置工具调用频率明显下降按需注入未命中目标工具检查 debug 日志任务开头强调工具用途长任务早期信息被遗忘上下文截断用 DECISIONS.md 文件固化关键决策多模型切换后行为不一致弱模型无法消化极简提示词为弱模型单独准备增强版提示词API 请求频繁被限流短提示词导致请求速率上升配置请求间隔控制并发会话数缓存命中率反而变低系统提示词被动态字段污染把动态内容移到用户消息跨文件重构频繁卡住上下文未预加载仓库依赖先跑依赖索引脚本生成摘要再任务这张表基本覆盖了我迁移过程中遇到的所有典型问题。如果你迁移后遇到别的问题第一件事永远是看 debug 日志确认当轮请求实际注入的 tokens 数和工具列表。数据不会说谎先定位再调参。最后分享一个我踩过几次坑之后沉淀下来的习惯每次调整系统提示词不要在线上项目里直接改。复制一份精简提示词到临时项目里跑几个代表性任务对照测试输出和 token 消耗。这个流程最多花二十分钟能避免线上环境中一次无效调整带来的整周波动。系统提示词这个东西少就是多稳就是快但它永远只是工具链里的一环。想要真正把成本压下来还要配合按需工具注入、缓存策略和任务规划一起看。迁移到 Pi 不是我编程习惯的终点而是一套成本思维方式的起点。
阅读完成 · 觉得有帮助？
