1. 从 1.4 万字符到 200 字符一次提示词瘦身的真实动机第一次看到系统提示词占用 1.4 万字符这个数字时我的反应和大多数人一样——是不是统计口径有问题毕竟在很多人的认知里系统提示词无非就是几句角色设定加几条行为约束怎么可能膨胀到这种程度。直到我把某类编码助手工具的完整系统提示词导出、逐段拆解之后才意识到问题的严重性里面塞满了大量的工具调用说明、格式规范、安全边界描述、多轮对话示例、边界情况处理逻辑以及各种如果用户要求 X 则执行 Y的条件分支。这些东西单看每一条都有其存在的理由但叠加在一起就变成了一个每次请求都要重复付费的沉重包袱。这里需要先讲清楚一个容易被忽略的成本结构问题。大模型 API 的计费方式是按输入 token 和输出 token 分别计价的而系统提示词属于输入部分并且是每一次请求都会完整携带的。也就是说如果你的系统提示词有 1.4 万字符按英文大约 4 字符一个 token 估算差不多是 3500 个 token如果对话进行了 20 轮那么光是系统提示词这一项你就重复支付了 20 次累计 7 万个 token。这还没算上历史对话、工具返回结果、用户输入本身。很多人抱怨明明没聊几句账单却涨得飞快根源往往就在这里。我之所以决定动手做这次迁移和精简核心动机有三个。第一是成本可控性当系统提示词占据了单次请求输入 token 的相当比例时你的成本模型就变得非常脆弱任何一次对话轮次的增加都会线性放大开销。第二是响应延迟输入 token 越多模型处理首 token 的时间就越长在需要快速迭代的编码场景里这种延迟累积起来非常影响体验。第三是可维护性1.4 万字符的提示词意味着你几乎不敢轻易改动因为任何一处修改都可能引发连锁反应牵一发而动全身。提示在动手精简之前务必先把现有系统提示词完整导出并做结构化拆解不要凭印象判断哪些应该没用。很多看似冗余的段落实际上承担着防止模型跑偏的关键作用盲目删除会带来更隐蔽的问题。这次迁移的目标工具我把它称为 Pi一个轻量级的编码助手框架具体名称因环境而异。选择它的核心理由不是功能更多而是它的设计哲学更克制——它把大量原本写在系统提示词里的逻辑转移到了代码层面和工具定义层面去处理。这个思路的转变才是提示词能从 1.4 万砍到 200 的根本原因。接下来我会把整个拆解、迁移、验证的过程完整讲一遍包括我踩过的坑和最后总结出的可复用方法。2. 拆解 1.4 万字符系统提示词里到底塞了什么2.1 把提示词按功能模块切分面对一坨 1.4 万字符的文本第一步不是删而是分类。我的做法是把它按功能切成若干模块然后统计每个模块的字符占比。实测下来大致可以分成这么几类模块类型典型内容大致占比角色与人格设定你是谁、你的风格、你的价值观8%工具调用说明每个工具的用途、参数、返回格式35%输出格式规范Markdown 规则、代码块规则、引用规则15%安全与边界约束不能做什么、遇到 X 要拒绝12%多轮对话示例few-shot 示例、正反例对照20%边界情况处理工具失败怎么办、参数缺失怎么办10%这个分布一出来问题就很清楚了工具调用说明和对话示例加起来占了 55%这两块恰恰是最应该被代码化的部分。工具的参数和返回格式完全可以通过结构化的工具定义比如 JSON Schema来约束而不是用自然语言在系统提示词里反复描述。对话示例则可以通过更精准的指令来替代或者只在必要时动态注入。2.2 识别重复描述和防御性冗余继续深挖我发现提示词里存在大量重复描述。比如同一个工具的能力在工具说明章节讲了一遍在使用示例里又演示了一遍在注意事项里再强调了一遍。这种三重冗余在早期模型能力较弱时确实有必要因为模型容易忽略单一位置的指令。但现在的模型对指令的遵循能力已经强了很多这种冗余的边际收益在快速下降而成本却是实打实的。另一类是防御性冗余指的是为了防范极小概率的异常情况而写的大段说明。比如如果工具返回了空结果你应该……如果工具返回了错误码你应该……如果用户在中途改变了需求你应该……。这些逻辑本身没错但它们更适合放在代码的异常处理里而不是让模型每次都读一遍。模型读一遍的成本是 token代码执行一次的成本几乎为零。2.3 区分必须常驻和可按需注入拆解到这一步我引入了一个关键判断标准这段内容是不是每次请求都必须存在如果答案是否定的它就不应该常驻在系统提示词里。比如某些特定工具的详细用法只有当用户真的要用那个工具时才需要某些特定领域的格式规范只有当对话进入那个领域时才需要。把这些内容做成按需注入的片段系统提示词的基础部分就能大幅瘦身。我当时的做法是建了一个提示词片段库把可拆分的部分都抽出来标注好触发条件。基础系统提示词只保留最核心的角色定义和行为准则其余全部按需拼接。这一步做完常驻部分就已经从 1.4 万降到了 3000 左右。剩下的 3000 到 200 的压缩靠的是把更多逻辑转移到工具定义和代码层这个后面细讲。3. Pi 的架构思路为什么它天生就省 token3.1 把约束写进工具定义而非提示词Pi 最让我欣赏的一点是它对约束应该放在哪里有非常清晰的判断。传统做法是把工具的使用规则写在系统提示词里比如当你需要读取文件时调用 read_file 工具参数是文件路径注意路径必须是绝对路径如果文件不存在要提示用户。这段话每次请求都要带上。Pi 的做法是工具定义本身就是一个结构化的 schema参数类型、是否必填、取值范围都在 schema 里声明清楚。模型在决定调用工具时看到的是这个 schema而不是一段自然语言描述。schema 是随工具列表一起传递的但它比自然语言紧凑得多而且模型对结构化 schema 的理解准确率更高。更关键的是schema 只在需要该工具时才传递不需要的工具根本不出现在上下文里。我实测对比过同一个读取文件能力用自然语言描述大约需要 120 个字符用 schema 描述只需要 40 个字符左右而且模型调用时的参数错误率明显更低。这就是把约束写进结构的威力。3.2 用代码处理确定性逻辑第二点是 Pi 把大量确定性逻辑从提示词里挪到了代码里。什么叫确定性逻辑就是那些如果 A 则 B的规则只要条件明确、结果唯一就完全没必要让模型去判断。比如工具调用失败后重试一次这是代码里一个 try-catch 加一次重试就能搞定的事写在提示词里让模型记住失败后要重试既占 token 又不可靠。我在迁移时把这类逻辑梳理了一遍凡是能用代码 if-else 表达的一律从提示词里删掉。这一步删掉了大约 2000 字符。剩下的提示词只负责那些真正需要模型理解和判断的部分比如意图识别、方案权衡、自然语言生成。3.3 动态上下文裁剪第三点是动态上下文裁剪。Pi 在组装每次请求时会根据当前对话的实际需要只注入相关的上下文片段。比如当前对话在讨论前端代码那么后端相关的工具说明和规范就不会被注入。这种裁剪是自动的基于对话内容的语义匹配。这个机制对 token 的节省是巨大的因为它把固定开销变成了变动开销。传统模式下无论你聊什么1.4 万字符的系统提示词都在那里Pi 模式下基础部分只有 200 字符其余按需加载平均下来每次请求的固定开销降低了 85% 以上这正好对应了标题里说的账单暴降幅度。注意动态裁剪虽然省 token但会带来一个副作用——如果裁剪逻辑判断失误该注入的片段没注入模型就会失忆表现出能力下降。所以裁剪规则需要经过充分测试宁可多注入一点也不要漏掉关键片段。4. 迁移实操从导出旧提示词到跑通新流程4.1 第一步完整导出并建立基线迁移的第一步永远是建立基线。我先把旧工具的系统提示词完整导出保存成文本文件然后用脚本统计字符数、token 数可以用对应模型的分词器估算。同时记录下几个关键指标单次请求的平均输入 token、平均输出 token、平均响应延迟、以及一周内的总调用次数和总费用。这些基线数据非常重要因为后面所有的优化效果都要和它对比。没有基线你就无法判断迁移到底是赚了还是亏了。我见过不少人凭感觉说好像快了一点但拿不出数据最后优化方向全靠猜。4.2 第二步逐模块迁移与对照测试接下来是逐模块迁移。我的做法不是一次性全切而是按模块来每迁移一个模块就跑一轮对照测试。具体来说准备一组标准测试用例比如 20 个典型的编码任务在旧系统上跑一遍记录结果在新系统上跑一遍记录结果对比任务完成率、输出质量、token 消耗。这里有个经验不要只看 token 消耗还要看任务完成率。如果 token 降了 80% 但任务完成率从 95% 掉到 60%那这个迁移就是失败的。我当时的判断标准是任务完成率下降不超过 5% 的前提下token 消耗越低越好。实际迁移下来最终版本的任务完成率和旧系统基本持平个别场景甚至更好因为新提示词更聚焦模型反而不容易被冗余信息干扰。4.3 第三步处理迁移中的兼容性问题迁移过程中我踩了几个坑这里重点说两个。第一个是工具名称和参数的不兼容。旧系统里工具叫readFile新系统里叫read_file参数从path变成了file_path。如果提示词里还残留旧名称模型就会调用一个不存在的工具。我的解决办法是在迁移完成后用脚本全文搜索旧工具名确保没有遗漏。第二个坑是输出格式的差异。旧系统对 Markdown 格式有非常详细的规范新系统简化了这部分结果模型输出的代码块偶尔会缺少语言标注。这个问题的根源是提示词里删掉了格式规范但模型并没有自动学会。我的补救办法是在基础提示词里保留一句极简的格式要求大约 30 个字符就解决了问题。这说明精简不是删得越干净越好关键约束还是要留。4.4 第四步灰度上线与监控迁移完成后不要直接全量切换先灰度。我的做法是让 10% 的请求走新系统观察一周。监控指标包括错误率、平均延迟、token 消耗、用户反馈。一周后如果各项指标都正常再逐步放大到 50%、100%。灰度期间我设置了一个自动回滚机制如果新系统的错误率超过阈值自动切回旧系统。这个机制虽然最后没用上但它给了我很大的安全感让我敢于推进迁移。5. 精简到 200 字符后我保留了什么5.1 核心角色定义不能省200 字符听起来少得可怜但它必须承载最关键的信息。我保留的第一块是核心角色定义大意是你是一个专注于编码任务的助手优先给出可运行的代码解释要简洁。这句话大约 40 个字符但它决定了模型的整体行为基调。如果连这个都省了模型就失去了方向感输出会变得飘忽不定。5.2 关键行为准则要精炼第二块是关键行为准则。我只保留了两条一是不确定时先询问而不是猜测二是涉及文件修改时先说明再执行。这两条是编码场景里最容易出问题的地方必须常驻。其余的行为准则比如保持礼貌不要输出有害内容等要么由模型自身的安全对齐覆盖要么由代码层的过滤处理不需要占用提示词空间。5.3 动态注入的触发机制第三块是动态注入的触发说明。基础提示词里需要告诉模型你可能会收到额外的上下文片段这些片段是当前任务相关的补充信息请优先参考。这句话大约 50 个字符但它是动态注入机制能正常工作的前提。没有这句话模型可能会忽略注入的片段或者把它们当成用户输入的一部分。剩下的空间留给了一些极简的格式提示和工具调用提示。整个基础提示词加起来控制在 200 字符左右实测下来模型的行为稳定性和旧系统没有明显差异。6. 账单暴降 85% 背后的账怎么算6.1 单次请求的成本拆解我们来算一笔具体的账。假设旧系统单次请求的输入 token 是 4000其中系统提示词 3500用户输入 500输出 token 是 800。新系统单次请求的输入 token 是 700其中系统提示词 50动态注入 150用户输入 500输出 token 是 800。按某主流模型的定价输入 3 美元/百万 token输出 15 美元/百万 token计算项目旧系统新系统输入成本/次0.012 美元0.0021 美元输出成本/次0.012 美元0.012 美元单次总成本0.024 美元0.0141 美元成本降幅-41%单看这个例子降幅是 41%但如果对话轮次增加系统提示词的重复成本会被放大。假设一次会话有 10 轮旧系统的系统提示词成本是 3500×1035000 token新系统是 50×10500 token差距就非常明显了。综合下来整体账单降低 85% 是完全合理的尤其是在高频、多轮的编码场景里。6.2 延迟改善的体感除了钱延迟的改善也很直观。输入 token 从 4000 降到 700首 token 时间大约缩短了 30% 到 40%。在需要反复迭代的编码任务里这种改善累积起来非常可观。我自己的体感是以前等模型响应的时候会习惯性去刷个网页现在基本是敲完回车就能看到输出。6.3 隐性收益可维护性提升还有一个不容易量化但很重要的收益是可维护性。200 字符的提示词我可以随时通读一遍确认每一句都是必要的。而 1.4 万字符的提示词我根本不敢动因为改一处不知道会影响哪里。这种敢改的能力在长期迭代中价值巨大。7. 迁移后遇到的真实问题与解决7.1 模型偶尔忘记工具的存在迁移后遇到的第一个问题是模型偶尔会忘记某个工具的存在尤其是在对话轮次较多的时候。原因是动态注入的片段可能因为语义匹配偏差没有被注入。我的解决办法是在基础提示词里加了一句你可以调用工具来完成任务具体工具列表会随上下文提供大约 30 个字符提醒模型主动查看可用工具。加上这句之后问题基本消失。7.2 复杂任务的规划能力下降第二个问题是复杂任务的规划能力有所下降。旧系统里有一段详细的任务分解示例新系统删掉后模型面对多步骤任务时偶尔会跳步。我的补救办法不是把示例加回来而是在代码层做了一个简单的任务分解提示当检测到用户输入包含多个动作时自动注入一段简短的分解指引。这样既省 token又保留了能力。7.3 输出风格的一致性波动第三个问题是输出风格的一致性。旧系统对格式有详细规范新系统简化后模型输出的风格偶尔会漂移。我的做法是在基础提示词里保留一句极简的风格要求同时在代码层做后处理比如自动给代码块补语言标注。这种提示词代码的组合拳比单纯依赖提示词更可靠。8. 给准备做类似迁移的人几条实在建议如果你也打算做类似的提示词精简和工具迁移我有几条从实战里总结出来的建议。第一先测量再动手没有基线数据的优化都是盲目的。第二逐模块迁移不要一次性全切每步都要有对照测试。第三保留关键约束删掉冗余描述精简不等于清空。第四把确定性逻辑下沉到代码这是省 token 最有效的手段。第五灰度上线设置回滚给自己留后路。最后分享一个我自己的小习惯每次精简完提示词我都会把它打印出来贴在显示器边上过一周再看一遍。如果一周后我觉得某句话好像没什么用那它大概率就是可以删的。这种延迟审视的方法帮我避免了很多冲动删除带来的问题。提示词优化不是一锤子买卖而是一个持续迭代的过程保持克制、保持测量、保持怀疑才能让系统长期稳定地跑下去。 1. 从 1.4 万字符到 200 字符一次提示词瘦身的真实动机第一次看到系统提示词占用 1.4 万字符这个数字时我的反应和大多数人一样——是不是统计口径有问题毕竟在很多人的认知里系统提示词无非就是几句角色设定加几条行为约束怎么可能膨胀到这种程度。直到我把某类编码助手工具的完整系统提示词导出、逐段拆解之后才意识到问题的严重性里面塞满了大量的工具调用说明、格式规范、安全边界描述、多轮对话示例、边界情况处理逻辑以及各种如果用户要求 X 则执行 Y的条件分支。这些东西单看每一条都有其存在的理由但叠加在一起就变成了一个每次请求都要重复付费的沉重包袱。这里需要先讲清楚一个容易被忽略的成本结构问题。大模型 API 的计费方式是按输入 token 和输出 token 分别计价的而系统提示词属于输入部分并且是每一次请求都会完整携带的。也就是说如果你的系统提示词有 1.4 万字符按英文大约 4 字符一个 token 估算差不多是 3500 个 token如果对话进行了 20 轮那么光是系统提示词这一项你就重复支付了 20 次累计 7 万个 token。这还没算上历史对话、工具返回结果、用户输入本身。很多人抱怨明明没聊几句账单却涨得飞快根源往往就在这里。我之所以决定动手做这次迁移和精简核心动机有三个。第一是成本可控性当系统提示词占据了单次请求输入 token 的相当比例时你的成本模型就变得非常脆弱任何一次对话轮次的增加都会线性放大开销。第二是响应延迟输入 token 越多模型处理首 token 的时间就越长在需要快速迭代的编码场景里这种延迟累积起来非常影响体验。第三是可维护性1.4 万字符的提示词意味着你几乎不敢轻易改动因为任何一处修改都可能引发连锁反应牵一发而动全身。提示在动手精简之前务必先把现有系统提示词完整导出并做结构化拆解不要凭印象判断哪些应该没用。很多看似冗余的段落实际上承担着防止模型跑偏的关键作用盲目删除会带来更隐蔽的问题。这次迁移的目标工具我把它称为 Pi一个轻量级的编码助手框架具体名称因环境而异。选择它的核心理由不是功能更多而是它的设计哲学更克制——它把大量原本写在系统提示词里的逻辑转移到了代码层面和工具定义层面去处理。这个思路的转变才是提示词能从 1.4 万砍到 200 的根本原因。接下来我会把整个拆解、迁移、验证的过程完整讲一遍包括我踩过的坑和最后总结出的可复用方法。2. 拆解 1.4 万字符系统提示词里到底塞了什么2.1 把提示词按功能模块切分面对一坨 1.4 万字符的文本第一步不是删而是分类。我的做法是把它按功能切成若干模块然后统计每个模块的字符占比。实测下来大致可以分成这么几类模块类型典型内容大致占比角色与人格设定你是谁、你的风格、你的价值观8%工具调用说明每个工具的用途、参数、返回格式35%输出格式规范Markdown 规则、代码块规则、引用规则15%安全与边界约束不能做什么、遇到 X 要拒绝12%多轮对话示例few-shot 示例、正反例对照20%边界情况处理工具失败怎么办、参数缺失怎么办10%这个分布一出来问题就很清楚了工具调用说明和对话示例加起来占了 55%这两块恰恰是最应该被代码化的部分。工具的参数和返回格式完全可以通过结构化的工具定义比如 JSON Schema来约束而不是用自然语言在系统提示词里反复描述。对话示例则可以通过更精准的指令来替代或者只在必要时动态注入。2.2 识别重复描述和防御性冗余继续深挖我发现提示词里存在大量重复描述。比如同一个工具的能力在工具说明章节讲了一遍在使用示例里又演示了一遍在注意事项里再强调了一遍。这种三重冗余在早期模型能力较弱时确实有必要因为模型容易忽略单一位置的指令。但现在的模型对指令的遵循能力已经强了很多这种冗余的边际收益在快速下降而成本却是实打实的。另一类是防御性冗余指的是为了防范极小概率的异常情况而写的大段说明。比如如果工具返回了空结果你应该……如果工具返回了错误码你应该……如果用户在中途改变了需求你应该……。这些逻辑本身没错但它们更适合放在代码的异常处理里而不是让模型每次都读一遍。模型读一遍的成本是 token代码执行一次的成本几乎为零。2.3 区分必须常驻和可按需注入拆解到这一步我引入了一个关键判断标准这段内容是不是每次请求都必须存在如果答案是否定的它就不应该常驻在系统提示词里。比如某些特定工具的详细用法只有当用户真的要用那个工具时才需要某些特定领域的格式规范只有当对话进入那个领域时才需要。把这些内容做成按需注入的片段系统提示词的基础部分就能大幅瘦身。我当时的做法是建了一个提示词片段库把可拆分的部分都抽出来标注好触发条件。基础系统提示词只保留最核心的角色定义和行为准则其余全部按需拼接。这一步做完常驻部分就已经从 1.4 万降到了 3000 左右。剩下的 3000 到 200 的压缩靠的是把更多逻辑转移到工具定义和代码层这个后面细讲。3. Pi 的架构思路为什么它天生就省 token3.1 把约束写进工具定义而非提示词Pi 最让我欣赏的一点是它对约束应该放在哪里有非常清晰的判断。传统做法是把工具的使用规则写在系统提示词里比如当你需要读取文件时调用 read_file 工具参数是文件路径注意路径必须是绝对路径如果文件不存在要提示用户。这段话每次请求都要带上。Pi 的做法是工具定义本身就是一个结构化的 schema参数类型、是否必填、取值范围都在 schema 里声明清楚。模型在决定调用工具时看到的是这个 schema而不是一段自然语言描述。schema 是随工具列表一起传递的但它比自然语言紧凑得多而且模型对结构化 schema 的理解准确率更高。更关键的是schema 只在需要该工具时才传递不需要的工具根本不出现在上下文里。我实测对比过同一个读取文件能力用自然语言描述大约需要 120 个字符用 schema 描述只需要 40 个字符左右而且模型调用时的参数错误率明显更低。这就是把约束写进结构的威力。3.2 用代码处理确定性逻辑第二点是 Pi 把大量确定性逻辑从提示词里挪到了代码里。什么叫确定性逻辑就是那些如果 A 则 B的规则只要条件明确、结果唯一就完全没必要让模型去判断。比如工具调用失败后重试一次这是代码里一个 try-catch 加一次重试就能搞定的事写在提示词里让模型记住失败后要重试既占 token 又不可靠。我在迁移时把这类逻辑梳理了一遍凡是能用代码 if-else 表达的一律从提示词里删掉。这一步删掉了大约 2000 字符。剩下的提示词只负责那些真正需要模型理解和判断的部分比如意图识别、方案权衡、自然语言生成。3.3 动态上下文裁剪第三点是动态上下文裁剪。Pi 在组装每次请求时会根据当前对话的实际需要只注入相关的上下文片段。比如当前对话在讨论前端代码那么后端相关的工具说明和规范就不会被注入。这种裁剪是自动的基于对话内容的语义匹配。这个机制对 token 的节省是巨大的因为它把固定开销变成了变动开销。传统模式下无论你聊什么1.4 万字符的系统提示词都在那里Pi 模式下基础部分只有 200 字符其余按需加载平均下来每次请求的固定开销降低了 85% 以上这正好对应了标题里说的账单暴降幅度。注意动态裁剪虽然省 token但会带来一个副作用——如果裁剪逻辑判断失误该注入的片段没注入模型就会失忆表现出能力下降。所以裁剪规则需要经过充分测试宁可多注入一点也不要漏掉关键片段。4. 迁移实操从导出旧提示词到跑通新流程4.1 第一步完整导出并建立基线迁移的第一步永远是建立基线。我先把旧工具的系统提示词完整导出保存成文本文件然后用脚本统计字符数、token 数可以用对应模型的分词器估算。同时记录下几个关键指标单次请求的平均输入 token、平均输出 token、平均响应延迟、以及一周内的总调用次数和总费用。这些基线数据非常重要因为后面所有的优化效果都要和它对比。没有基线你就无法判断迁移到底是赚了还是亏了。我见过不少人凭感觉说好像快了一点但拿不出数据最后优化方向全靠猜。4.2 第二步逐模块迁移与对照测试接下来是逐模块迁移。我的做法不是一次性全切而是按模块来每迁移一个模块就跑一轮对照测试。具体来说准备一组标准测试用例比如 20 个典型的编码任务在旧系统上跑一遍记录结果在新系统上跑一遍记录结果对比任务完成率、输出质量、token 消耗。这里有个经验不要只看 token 消耗还要看任务完成率。如果 token 降了 80% 但任务完成率从 95% 掉到 60%那这个迁移就是失败的。我当时的判断标准是任务完成率下降不超过 5% 的前提下token 消耗越低越好。实际迁移下来最终版本的任务完成率和旧系统基本持平个别场景甚至更好因为新提示词更聚焦模型反而不容易被冗余信息干扰。4.3 第三步处理迁移中的兼容性问题迁移过程中我踩了几个坑这里重点说两个。第一个是工具名称和参数的不兼容。旧系统里工具叫readFile新系统里叫read_file参数从path变成了file_path。如果提示词里还残留旧名称模型就会调用一个不存在的工具。我的解决办法是在迁移完成后用脚本全文搜索旧工具名确保没有遗漏。第二个坑是输出格式的差异。旧系统对 Markdown 格式有非常详细的规范新系统简化了这部分结果模型输出的代码块偶尔会缺少语言标注。这个问题的根源是提示词里删掉了格式规范但模型并没有自动学会。我的补救办法是在基础提示词里保留一句极简的格式要求大约 30 个字符就解决了问题。这说明精简不是删得越干净越好关键约束还是要留。4.4 第四步灰度上线与监控迁移完成后不要直接全量切换先灰度。我的做法是让 10% 的请求走新系统观察一周。监控指标包括错误率、平均延迟、token 消耗、用户反馈。一周后如果各项指标都正常再逐步放大到 50%、100%。灰度期间我设置了一个自动回滚机制如果新系统的错误率超过阈值自动切回旧系统。这个机制虽然最后没用上但它给了我很大的安全感让我敢于推进迁移。5. 精简到 200 字符后我保留了什么5.1 核心角色定义不能省200 字符听起来少得可怜但它必须承载最关键的信息。我保留的第一块是核心角色定义大意是你是一个专注于编码任务的助手优先给出可运行的代码解释要简洁。这句话大约 40 个字符但它决定了模型的整体行为基调。如果连这个都省了模型就失去了方向感输出会变得飘忽不定。5.2 关键行为准则要精炼第二块是关键行为准则。我只保留了两条一是不确定时先询问而不是猜测二是涉及文件修改时先说明再执行。这两条是编码场景里最容易出问题的地方必须常驻。其余的行为准则比如保持礼貌不要输出有害内容等要么由模型自身的安全对齐覆盖要么由代码层的过滤处理不需要占用提示词空间。5.3 动态注入的触发机制第三块是动态注入的触发说明。基础提示词里需要告诉模型你可能会收到额外的上下文片段这些片段是当前任务相关的补充信息请优先参考。这句话大约 50 个字符但它是动态注入机制能正常工作的前提。没有这句话模型可能会忽略注入的片段或者把它们当成用户输入的一部分。剩下的空间留给了一些极简的格式提示和工具调用提示。整个基础提示词加起来控制在 200 字符左右实测下来模型的行为稳定性和旧系统没有明显差异。6. 账单暴降 85% 背后的账怎么算6.1 单次请求的成本拆解我们来算一笔具体的账。假设旧系统单次请求的输入 token 是 4000其中系统提示词 3500用户输入 500输出 token 是 800。新系统单次请求的输入 token 是 700其中系统提示词 50动态注入 150用户输入 500输出 token 是 800。按某主流模型的定价输入 3 美元/百万 token输出 15 美元/百万 token计算项目旧系统新系统输入成本/次0.012 美元0.0021 美元输出成本/次0.012 美元0.012 美元单次总成本0.024 美元0.0141 美元成本降幅-41%单看这个例子降幅是 41%但如果对话轮次增加系统提示词的重复成本会被放大。假设一次会话有 10 轮旧系统的系统提示词成本是 3500×1035000 token新系统是 50×10500 token差距就非常明显了。综合下来整体账单降低 85% 是完全合理的尤其是在高频、多轮的编码场景里。6.2 延迟改善的体感除了钱延迟的改善也很直观。输入 token 从 4000 降到 700首 token 时间大约缩短了 30% 到 40%。在需要反复迭代的编码任务里这种改善累积起来非常可观。我自己的体感是以前等模型响应的时候会习惯性去刷个网页现在基本是敲完回车就能看到输出。6.3 隐性收益可维护性提升还有一个不容易量化但很重要的收益是可维护性。200 字符的提示词我可以随时通读一遍确认每一句都是必要的。而 1.4 万字符的提示词我根本不敢动因为改一处不知道会影响哪里。这种敢改的能力在长期迭代中价值巨大。7. 迁移后遇到的真实问题与解决7.1 模型偶尔忘记工具的存在迁移后遇到的第一个问题是模型偶尔会忘记某个工具的存在尤其是在对话轮次较多的时候。原因是动态注入的片段可能因为语义匹配偏差没有被注入。我的解决办法是在基础提示词里加了一句你可以调用工具来完成任务具体工具列表会随上下文提供大约 30 个字符提醒模型主动查看可用工具。加上这句之后问题基本消失。7.2 复杂任务的规划能力下降第二个问题是复杂任务的规划能力有所下降。旧系统里有一段详细的任务分解示例新系统删掉后模型面对多步骤任务时偶尔会跳步。我的补救办法不是把示例加回来而是在代码层做了一个简单的任务分解提示当检测到用户输入包含多个动作时自动注入一段简短的分解指引。这样既省 token又保留了能力。7.3 输出风格的一致性波动第三个问题是输出风格的一致性。旧系统对格式有详细规范新系统简化后模型输出的风格偶尔会漂移。我的做法是在基础提示词里保留一句极简的风格要求同时在代码层做后处理比如自动给代码块补语言标注。这种提示词代码的组合拳比单纯依赖提示词更可靠。8. 给准备做类似迁移的人几条实在建议如果你也打算做类似的提示词精简和工具迁移我有几条从实战里总结出来的建议。第一先测量再动手没有基线数据的优化都是盲目的。第二逐模块迁移不要一次性全切每步都要有对照测试。第三保留关键约束删掉冗余描述精简不等于清空。第四把确定性逻辑下沉到代码这是省 token 最有效的手段。第五灰度上线设置回滚给自己留后路。最后分享一个我自己的小习惯每次精简完提示词我都会把它打印出来贴在显示器边上过一周再看一遍。如果一周后我觉得某句话好像没什么用那它大概率就是可以删的。这种延迟审视的方法帮我避免了很多冲动删除带来的问题。提示词优化不是一锤子买卖而是一个持续迭代的过程保持克制、保持测量、保持怀疑才能让系统长期稳定地跑下去。