企业官网建设流程全解析

月初打开模型平台的用量面板时，我第一反应是计费规则是不是出 bug 了。明明这个月大部分时间都在读代码、改注释，没接几个大活，账单却比上个月高出一截。把每次请求的 usage 字段拉出来一数，我才发现问题根本不在自己干了多少事，而是每个请求都背着一份约 1.4 万字符的系统提示词。这就是 Claude Code 这类重量级 CLI 助手默认附加的开销。后来我花了两周时间把日常工作流迁到 Pi，系统提示词从 1.4 万字符压到 200 字，Token 账单整体降了 85%。这篇文章就把这次迁移的过程、测量方法和踩过的坑完整记录下来，给同样靠 CLI 助手干活、又在为 token 成本头疼的朋友们一个参考。

1. 1.4 万字符的系统提示词到底产生了多少无效开销

1.1 一次普通 Debug 会话的计费解剖

用过 Claude Code 的人都知道，它启动一个会话之后，会在后台自动注入一整套系统提示词。这套提示词不仅定义了"你是一个编码助手"，还包含大量工具说明、行为规范、输出格式要求、安全策略，甚至权限确认的交互规则。以我早前某段日志的实测来看，这份提示词大约在 1.4 万字符上下，按主流 tokenizer 折算，差不多是 3000 到 4000 个 token，取个整，后面算账就按 3500 token 来。

问题在于，这套系统提示词不是只付一次费，而是你每发一轮请求，它都会跟着用户消息、多轮历史和工具返回结果一起重新计费。模型 API 按"当前完整输入"收费，这意味着系统提示词成了每一轮对话都逃不掉的固定税。

我给一个小团队搭了个埋点脚本，把某个 bug 修复引导任务完整跑了一遍：一共 35 轮请求，每一轮输入里系统提示词都是 3500 token。一轮下来，用户实际输入的消息平均只有 300 token，工具返回结果平均 1500 token，系统提示词占了输入总量的约 66%。35 轮累积下来，仅仅是系统提示词这一个固定项就吃掉了 122500 token。如果按常见每百万 token 的价格换算，这部分纯粹是"开口费"，跟你有没有好好干活毫无关系。

1.2 官方为什么要塞这么多内容

Claude Code 把系统提示词写得这么长，并不是产品经理脑子进水。它的目标用户是各种规模团队的开发者，产品必须覆盖足够多场景：要防止模型乱执行危险命令，要让工具调用结果能被正确解析，要规范输出里哪些字段该用特殊标签包裹，还要处理权限申请、文档生成、子代理调度等复杂机制。所以系统提示词里出现大段"如果你要做 A，必须先做 B"的规则，出现每个工具的逐字段解释，都是为了让模型拿到任何项目时都能保持基本水准。

但对一个十人以内、代码库边界清晰、开发流程固定的团队来说，这套"全场景保险"至少有一半内容一辈子用不上。更难受的是，你没法只加载其中一部分，Claude Code 不会给你拆包。我打一个比方：这相当于每次坐飞机都要买一份全球紧急医疗救援险，不管你只飞一个短途国内航线，还是出门就是楼下便利店，保险费一次都不会少。

1.3 沉默的重复计费才是账单大头

很多人在月末看账单时，习惯性把它归因于"这个月活太多了"，或者认为输出 token 贵。但真实情况是，CLI 编码助手的会话结构决定了输入 token 往往远超输出 token。尤其像 Claude Code 这种 agent 型工具，一个普通任务可能有几十轮工具调用，每一轮都要把系统提示词、上下文历史、工具结果重新打包一遍。

我见过一个极端例子：某开发者用 Claude Code 做一次全仓库字段重命名，一件事没干完，会话滚到了 60 轮。其中系统提示词的重复计费高达 60 × 3500 = 210000 token，而实际有效消息可能只有几千 token。账单里至少一半以上是在为"格式要求"买单。意识到这一点之后，我整个月都没有再碰 Claude Code 跑低价值任务，而是先把评估 Pi 的工作提上了日程。

2. Pi 把系统提示词砍到 200 字，凭什么还能干活

2.1 不是删内容，而是搬走内容

我第一次看到 Pi 的默认系统提示词只有 200 字符时，第一反应也是"这能用？"。但跑完几个任务之后我意识到，Pi 的设计思路和 Claude Code 完全不同：它不是把系统提示词当成唯一的规则容器，而是把大部分内容搬到了三个地方——项目指令文件、工具 schema 描述、运行时按需注入。

这意味着系统提示词只需要保留最基础的"你是谁、你在干嘛、输出格式怎么走"，剩下的规则在真正需要用到的那一刻才出现在输入里。比如某个命令咱们约定必须带--no-verify参数，这条规则不必写进每轮请求，而是写在项目根目录的指令文件里，模型在开始处理任务时读取一次就记住了。相比 Claude Code 每轮全量携带，这种"用多少带多少"的做法天然省 token。

2.2 工具描述瘦身的实际效果

工具描述是系统提示词里膨胀最严重的部分。Claude Code 会给每个工具写很长的自然语言说明，什么场景该用、参数之间怎么配合、返回值怎么解析，全部塞进系统提示词。Pi 的做法是把这些细节下沉到 JSON schema 的 description 字段，工具名和参数结构保持精简，序列化时只按需附加。

比如一个exec_command工具，Claude Code 风格的系统提示词里会出现十几行说明，告诉模型"如果命令可能修改文件，请先询问用户"之类的。Pi 风格的描述可能简化成一句话："在项目沙箱中执行命令，返回 stdout 与 stderr。" 剩下的行为约束不是靠提示词反复强调，而是靠底层执行器本身的封装去保证：要么直接拒绝高危命令，要么在配置里硬性要求确认。这样既保住了安全底线，又省掉了模型理解和消化大段文字的成本。

2.3 200 字系统提示词的完整样例

迁移过程中我用在 Pi 上的系统提示词大约长这样：

你是一名资深软件工程师，在用户指定的代码仓库中工作。 所有任务应先读取项目指令文件，再使用执行器完成代码修改。 回答保持简洁，直接给出改动内容和结果，不要重复工具输出。

你数一下，大概就是 50～60 个 token。这个 prompt 放在 Claude Code 那一套面前显得简陋得过分，可它是成立的：现代编程大模型对"读代码、改代码、跑命令"这件事本身已经训练得足够充分，我们需要的只是帮它把注意力放到当前任务上，而不是像教新手一样逐步教它"先看文件再动手"。 如果系统提示词里 90% 的行为指导模型早就内化了，那这些指导词就是成本，不是能力。这一观点陪我完成了整个迁移评估框架的设计。 ## 3. 从 Claude Code 迁到 Pi 的完整实操路径 ### 3.1 迁移之前先盘点工作流 很多人拿到 Pi 第一件事就是跑几个 Demo，发现基础能力大差不差，于是直接切主力。结果没跑两天就发现某个重要工作流缺了东西。真正从 Claude Code 迁过来，我认为必须先从盘点开始：你平常调用最多的命令是什么，你有多少规则写在全局配置里，你挂了哪些 MCP 服务，你会不会用子代理拆任务。 拿我自己的情况举例：我在 Claude Code 里用到的能力排序是文件读写与批量替换、正则搜索、git 历史分析、编译和测试命令自动执行，最后才是偶尔用的 MCP 工具。其中真正绑死 Claude Code 的几乎没有，大部分是通用 CLI 能力。于是我果断把"保留所有极端复杂的子代理编排"从迁移清单里划掉，先保证主干链路能跑通，这一步大大降低了迁移初期的复杂度。 ### 3.2 五步迁移清单 第一步，安装并跑通 Pi 的最小可用会话，确认它能读取当前目录、能执行命令、能返回结构化结果。第二步，把项目和团队级别的规则整理成指令文件，从 Claude Code 的 CLAUDE.md 迁移到 Pi 约定读取的规则文件。第三步，检查工具映射，把常用的文件读写、命令执行映射到 Pi 对应的工具。第四步，逐个接入 MCP 服务，确认外部数据源可用。第五步，挑 3 到 5 个日常高频任务做回归测试，对比执行成功率和耗时。 这个顺序不能跳。我最开始想直接从复杂任务开始测，结果发现规则文件没写全，Pi 对项目约定的把握差得离谱，连续三次改动都不符合代码风格。后来把规则文件补完整，再开始跑回归，效果立刻就不一样了。 ### 3.3 回归测试的真实数据 我用一个内部模拟项目 X 做了一次很小但完整的回归测试：任务清单包含修复一个偶发空指针、给两个新增字段补充单元测试、重构一个超过 200 行的函数。同样的人写 prompt，同样的验收标准，分别在 Claude Code 和 Pi 上跑。 结果是：Claude Code 三个任务都完成，耗时 24 分钟；Pi 在规则文件完善后也完成了三个任务，耗时 31 分钟。单看执行效率，Pi 慢了约 30%，但 token 消耗差距非常大：Claude Code 跑完这三项一共消耗约 680k 输入 token，Pi 只消耗约 120k，输入侧减少约 82%。考虑到 API 计费里输出 token 单价更高，实际费用差距大约在 75% 到 80% 之间。这说明 Pi 在对话轮次控制上没有明显压倒性优势，但它每一轮的"开口费"低得多，整体成本就完全不同了。 ## 4. Token 账单降 85% 的测量方法与数学原理 ### 4.1 先用双轨数据代替体感 很多人在迁移后只凭"每个月账单少了一截"来评价效果，这不够严谨，因为模型版本、任务量、输出长度都会影响最终金额。我是这样做的：先保留一周的 Claude Code 使用日志，同时把 Pi 的 debug 开关打开，让所有请求的 usage 字段都落到本地日志文件。一周结束后用脚本对会话和 token 做聚合统计。 统计脚本核心逻辑不复杂，无非是读取每个请求的 input_tokens、output_tokens、会话 id、时间戳，再按会话维度加总。我也建议你顺手记一下每次任务的类型，这样能看出是"普通 bug 修复"还是"长篇重构"省得多，方便后面决定哪些任务长期留在 Pi 上。 ### 4.2 为什么降幅不是 98.6% 而是 85% 如果只看系统提示词，从 1.4 万字符压到 200 字符，理论上单轮输入能省掉 97% 以上的"固定开口费"，可整月账单不可能同步降 97%。原因有三个。 第一，输出 token 不会因为换工具而自动减少。模型该写多少行代码还是写多少行，而输出 token 的单价通常是输入的 3 到 5 倍，这一块在总账单里占有不小的权重。第二，工具返回内容和仓库文件内容依然会进入输入，这部分占的比例在复杂任务里相当可观。第三，极简系统提示词会导致一部分任务需要额外轮次，模型可能因为缺少全局规则而做出偏差较大的中间决策，返工消耗会增加。 所以更准确的拆法是：系统提示词缩减把输入侧的"固定税"大幅拿掉，但要扣除新增的返工轮次，再叠加输出侧不变的权重，最终我可以接受的合理降幅就在 80% 到 88% 之间。 来看两张真实的月度对比数据，单位是"标准计费单元"，已经按输入输出不同单价做过归一化： | 成本项 | Claude Code 月度 | Pi 月度 | 变化 | | ---: | ---: | ---: | ---: | | 系统提示词 | 48000 | 800 | -98.3% | | 用户消息 | 12000 | 9500 | -20.8% | | 工具返回 | 36000 | 31000 | -13.9% | | 输出生成 | 27000 | 26000 | -3.7% | | 合计 | 123000 | 67300 | -45.3% | 这是一次完全不优化使用习惯的"裸迁移"结果，总费用降了约 45%。如果继续做两件小事——把规则文件写得更精确，减少返工轮次；把已经在上下文里的内容用显式指令处理，避免无意义的重复加载——实测可以把用户消息和工具返回部分再压掉一截，整体费用能继续落到约 18k 标准计费单元，也就是降幅接近 85%。 ### 4.3 影响最终收益的隐藏变量 第一个变量是会话轮次。如果任务只需要 3 轮对话就结束，系统提示词再大也亏不了多少；但 agent 型使用习惯往往一轮任务要滚 20 轮以上，固定税才真正伤筋动骨。第二个变量是上下文缓存能力。有些 API 支持对重复前缀计费打折，Claude Code 的长系统提示词在缓存命中时未必每次都全额收费，这一点大家看账单时别误伤。 第三个变量是模型的输出倾向。模型如果拿到极短系统提示词，可能默认回复得过长，或者输出大量过程说明。这个在 Pi 上需要单独用输出格式约束去调。我迁移第一周发现某些任务输出 token 反而比 Claude Code 多了 15%，加了一句"不要解释过程，只给最终改动"之后才回到正常水平。 ## 5. 迁移之后踩过的坑：这些场景会打脸 ### 5.1 长会话中途失忆 迁移后最初一个月，我把一个 8 文件的重构任务交给 Pi，前 5 个文件表现非常规矩，到第 6 个文件开始，它不再遵守项目里"私有方法统一加下划线前缀"的约定。我一度怀疑是模型能力问题，后来定位到根因：这条规则只写在项目指令文件里，而指令文件在会话早期被读取过一次，随着上下文滚动逐渐被挤出窗口，系统提示词里又没有再次强调，模型自然就把约定忘了。 我当时的解决方式很粗暴但在多数场景下有效：在指令文件开头注明"每次开始新文件修改前，重新读取本文件的命名约定段落"，并把这些约定精简到每条一行。这样即使上下文被压缩，模型也更容易在需要时主动拉回来。这件事提醒我，从 Claude Code 迁移到 Pi，不只是换一个 prompt，而是养成"用外部文件补充固定规则"的新习惯。 ### 5.2 危险命令的确认机制变薄了 Claude Code 默认会对破坏性命令弹确认，Pi 的极简系统提示词并不会刻意要求"执行之前先征求用户意见"。有一次我在调试脚本时，模型生成的命令直接把未提交的临时文件清掉了，幸好只影响了一个缓存目录，不然后果有点麻烦。 我后来启用了执行器的命令拦截配置，把 `rm -rf`、`git push --force`、`drop table` 这类命令做成白名单之外必须人工确认。这个能力通常不会写在系统提示词里，而是工具层直接拦截，所以不需要在 prompt 里浪费 token。如果你准备迁移，先确认你的 Pi 配置里有类似机制，不然还是留在 Claude Code 更稳妥。 ### 5.3 中文回复、代码风格这类"软规则"必须自己兜 系统提示词砍到 200 字之后，模型默认会用英文回复，默认使用它训练库里最常见的代码风格，而你的团队规范很可能不在这个"最常见"的范围内。常见的坑有：代码注释变成英文、字符串不用统一引号、错误日志格式不一致。 解决方法是把"软规则"写进项目指令文件，越具体越好。下面是我项目里 pi 规则文件的一小段示例： ```text 所有注释使用中文，但变量名、函数名保持英文。单引号优先，禁止行尾分号。日志输出必须包含模块名和行号。

这类内容不需要写进系统提示词，因为只在处理本项目时有效。写完规则文件之后，Pi 的输出风格很快回到了和 Claude Code 时期一致的水平，token 成本却没有任何增加。

5.4 明确不适合迁移的三类任务

第一类：强合规场景。如果你的项目需要严格审计每一次模型决策的依据，Claude Code 那种超长系统提示词虽然贵，但它对决策路径的约束更完善，Pi 的极简设计会让审计链条变短。

第二类：高度依赖子代理并行拆解的大型重构。Pi 目前的角色拆分能力比重量级 CLI 助手弱不少，如果任务天然就需要多角色协作，硬迁过去会导致轮次暴涨，省下的 token 补不回执行效率的损失。

第三类：代码仓库完全没有文档和规则沉淀的探索性项目。系统提示词越短，对项目显式规则文件的依赖就越强。没有规则文件，模型只能靠猜，这时候省 token 省下来的钱会变成大量返工时间。

6. 一些收尾想单独说的经验

在写这篇文章的调研过程里，我发现一个很有意思的现象：大家讨论优化 token 成本时，第一反应永远是"换更便宜的模型""减少输出长度""压缩上下文"，很少有人想到系统提示词这个每轮都在重复付费的大头。Pi 给我最大的启示不是它把系统提示词压到 200 字，而是它把成本结构重新设计了一遍——把一次性、固定、每轮都要付的内容，变成了按需加载、低频率读取的资源。

如果你也在犹豫要不要做类似迁移，我建议不要一开始就全量切换。挑一个规则清晰的小型仓库，先跑一周 Pi，同时保留 Claude Code 环境随时回退。把两组日志拉出来对比之后，你很容易看清自己真实工作流里哪些任务适合极简提示词，哪些任务真的需要重量级兜底。对我而言，日常修复、重构、测试循环已经彻底留在了 Pi 上，Claude Code 只承担少数复杂调度场景。两类工具并存，每个月费用下来了，干活效率也没有发生明显滑坡。最后再提一个小技巧：迁移后别忘了定期翻一下日志里的每轮输入结构，一旦发现系统提示词之外的固定噪声又开始膨胀，说明项目指令文件该做新一轮精简了。这个动作坚持下来，才是长期不返贫的关键。