企业官网建设流程全解析

我从上周开始，把主力开发环境从 Claude Code 完整迁到了 Pi。最直接的变化是：系统提示词从 14000 字符压缩到 200 字符，每天的 Token 账单成本降了 85%。这不是在换一个更便宜的模型，是在换一种更不浪费的使用方式。这篇文章我会完整拆解这次的迁移过程，包括为什么 Claude Code 会这么费 Token、我是怎么一步步把提示词压下来的、迁移后的实际账单对比，以及踩过的那些坑。适合所有在用 AI 编程助手、按 Token 付费、或者被长系统提示词恶心过的开发者参考。

1. 为什么我必须离开 Claude Code：1.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 成本模型的真相：不是模型单价贵，是“口粮”太大

我做了一个很简单的数学模型，把所有请求分成三类：

短需求在低频场景下没什么感觉，但如果你跟我一样高频使用，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 字符的提示词后，我第一件事不是改，而是先分类。我是用成本思维去分类的，每一类内容在请求中承担的职责是什么：

结论很明显：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 迁移前后一周的数据对比

取其中代表性的一天，都是正常开发日，任务强度差不多：

从表格里能看到一个关键点：请求次数几乎没有变化，但平均输入 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 账单大概率也会经历一次两位数级别的下降。