企业官网建设流程全解析

1. 从一次账单复盘说起：为什么我要动系统提示词

去年年底做季度成本复盘的时候，我发现一个很反直觉的现象：团队里几个用 AI 编程助手的项目，实际写业务代码的 token 消耗只占了三成不到，剩下七成全部砸在了系统提示词和上下文注入上。最夸张的一个项目，单次会话的固定开销就有一万四千多个 token，还没开始干活，钱已经花出去了。

这个项目标题里的数字不是标题党。系统提示词从 1.4 万砍到 200，账单降 85%，是我自己一步步压出来的真实结果。核心思路其实不复杂：把"每次都要塞给模型的固定内容"和"真正需要模型知道的内容"彻底分开。前者越少越好，后者按需加载。

这篇文章适合三类人看：一是正在用 AI 编程助手、但没仔细算过 token 账的开发者；二是被系统提示词臃肿问题困扰、想自己动手瘦身的人；三是对 AI 工具链成本结构好奇、想搞清楚钱到底花在哪的技术负责人。我会把整个迁移和优化过程拆开讲，包括为什么原来的方案会膨胀到 1.4 万、200 token 的方案怎么设计、中间踩了哪些坑、以及怎么验证效果。

先说结论性的判断：系统提示词的膨胀，本质上是"把配置当代码写"的思维惯性造成的。很多人习惯把所有可能用到的规则、示例、工具说明全塞进系统提示，觉得"多给点总没错"。但在按 token 计费的场景下，这个习惯就是纯粹的浪费。真正高效的做法是分层：核心指令极简，扩展能力按需注入。

2. 拆解 1.4 万 token 的构成：钱到底花在哪了

2.1 系统提示词的四大膨胀源

我先把原来那套方案的 token 构成拉出来做了个拆解。用的是一个常见的 token 估算方式，中文按 1.5 字/token 粗算，英文按 4 字符/token 粗算，代码块单独统计。结果如下：

看这个表就能发现问题：工具调用说明和代码风格示例加起来占了 55%，但这两块内容在绝大多数会话里根本用不上。比如一个只做代码审查的会话，根本不需要知道怎么写新文件的工具怎么调用；一个只改 bug 的会话，也不需要完整的代码风格示例。

2.2 为什么"多塞点"是个陷阱

这里要讲一个很多人没意识到的机制：系统提示词是每次请求都要重新计费的。它不是一次性的投入，而是像房租一样，每次对话都要交一遍。假设一天跑 200 次请求，1.4 万 token 的系统提示就是 280 万 token 的固定开销。按主流模型的定价，这笔钱一个月下来相当可观。

更隐蔽的问题是，过长的系统提示会稀释模型的注意力。模型在处理长上下文时，对开头和结尾的内容关注度更高，中间部分容易被"忽略"。你把十几条规则塞在中间，模型可能只记住了前三条和后两条。结果就是：你写了一大堆规则，模型该犯的错还是犯，钱却照花。

我做过一个对比测试：同样一个"重构这个函数"的任务，用 1.4 万 token 的系统提示和用 200 token 的系统提示，输出质量几乎没有差别。因为重构任务真正需要的指令就那几条，多出来的内容全是噪音。

2.3 一个关键认知：系统提示不是文档

很多人把系统提示词当成项目文档来写，恨不得把所有背景、所有规范、所有历史决策都写进去。但系统提示的本质是给模型的即时操作指令，不是知识库。知识库应该放在外部，需要的时候再检索注入。

这个认知转变是整件事的起点。一旦你接受"系统提示只放最核心的操作指令"，后面的优化就顺理成章了。

3. 200 token 极简方案的设计逻辑

3.1 核心指令只保留三件事

我把系统提示词压缩到 200 token 左右，只保留三件事：

1. 身份与目标：一句话说清楚这个助手是干什么的。
2. 输出格式约束：规定回答的结构，比如"先给结论再给理由"。
3. 边界规则：什么能做、什么不能做，用最简短的否定句表达。

具体长这样（示意，非真实配置）：

你是一个代码助手，负责在给定代码库中完成指定任务。 输出要求：先给结论，再给必要说明，代码用代码块包裹。 约束：不修改未指定的文件；不确定时先提问；不编造不存在的 API。

就这么多。没有角色扮演，没有长篇大论的风格示例，没有十几个工具的详细说明。

3.2 工具说明按需注入

原来那 4200 token 的工具说明，我改成了按需注入。具体做法是：系统提示里只写"你可以调用工具，工具列表会在需要时提供"，然后在具体任务里，只把这次任务可能用到的工具说明附上。

比如一个"读取文件并分析"的任务，只注入读取类工具的说明，大概 150 token。一个"修改并保存"的任务，只注入写入类工具的说明。这样每次实际加载的工具说明从 4200 降到 150 到 300 之间。

3.3 代码风格用外部配置

代码风格示例那 3500 token，我全部移到了外部配置文件里。系统提示里只写一句"遵循项目根目录的 style 配置"。模型需要的时候，通过工具去读取这个文件。这样风格规范可以写得很详细，但不占用每次请求的固定开销。

3.4 安全规则用最短表达

安全与边界规则从 2100 压到 50 token 以内。核心就几条否定句："不执行破坏性操作""不访问未授权路径""不输出敏感信息"。原来那些长篇的解释性文字全部删掉，因为模型不需要你解释为什么，它只需要知道是什么。

3.5 优化前后的对比

账单降 85% 而不是 98%，是因为还有用户输入、模型输出、以及按需注入的那部分内容。但固定开销的大头已经被砍掉了。

4. 迁移实操：一步步把提示词瘦下来

4.1 第一步：给现有系统提示做"体检"

动手之前，先把你现在的系统提示词完整拉出来，按功能分块，统计每块的 token 数。我用的方法很简单：把提示词按段落拆开，每段单独估算 token，然后归类。

这里有个实操技巧：不要凭感觉判断哪块重要，要看实际调用频率。我统计了两周的实际会话，发现工具说明里只有三个工具被真正调用过，其余十几个从来没触发过。那十几个工具的说明就是纯浪费。

4.2 第二步：区分"常驻"和"按需"

把体检出来的所有内容分成两类：

• 常驻类：每次会话都必须有的，比如身份、核心约束。
• 按需类：只在特定任务里需要的，比如工具说明、风格示例、项目背景。

分类的标准是问自己一句："如果这次会话完全用不到这块内容，删掉它会不会影响结果？"如果不会，就归到按需类。

4.3 第三步：重写核心提示

核心提示的重写原则是能删就删，能短就短。我给自己定了几条硬规则：

• 不用形容词，只用动词和名词。
• 不解释原因，只给指令。
• 不举例，除非例子本身就是指令的一部分。
• 每条规则不超过一行。

按这个规则重写，1.4 万 token 的内容能压到 200 以内。

4.4 第四步：搭建按需注入机制

按需注入需要一个简单的调度逻辑：根据任务类型，决定注入哪些扩展内容。我用的是一个映射表：

这个映射表放在外部，每次任务开始时根据类型查表注入。这样既保证了任务需要的信息都在，又不会把无关内容塞进去。

4.5 第五步：验证与回归测试

瘦身之后必须验证效果。我准备了一组标准任务，优化前后各跑一遍，对比输出质量和 token 消耗。标准任务包括：改一个 bug、加一个函数、审查一段代码、生成一份文档。

验证的关键指标有两个：任务完成率和单任务平均 token。如果完成率没降、token 降了，说明优化成功。如果完成率降了，说明砍过头了，需要把某些内容加回来。

注意：验证时要用同一组任务、同一个模型版本，否则对比没有意义。模型版本更新会带来输出差异，干扰判断。

5. 踩过的坑与排查实录

5.1 砍太狠导致模型"失忆"

第一次瘦身我砍到了 80 token，结果模型开始犯低级错误：不遵守输出格式、忘记用代码块、甚至开始编造 API。原因是核心约束被砍得太简略，模型没有足够的信号来判断边界。

解决办法是保留必要的冗余。200 token 里，有大约 50 token 是"重复强调"核心约束的。看起来浪费，但实测下来能显著降低出错率。这个平衡点需要自己试，我的经验是：核心约束至少出现两次，一次在开头，一次在结尾。

5.2 按需注入的时机问题

按需注入有个坑：注入太晚，模型已经开始回答了。我一开始把工具说明放在用户消息之后，结果模型经常在没看到工具说明的情况下就开始规划，导致工具调用失败。

正确做法是把按需内容放在系统提示之后、用户消息之前，确保模型在开始思考前就拿到完整信息。

5.3 外部配置读取失败

代码风格移到外部文件后，偶尔出现读取失败的情况。排查发现是路径问题：不同工作目录下相对路径解析不一致。解决办法是用绝对路径，或者在系统提示里明确写清楚配置文件的完整位置。

5.4 常见问题速查表

5.5 一个反直觉的经验

优化过程中我发现，有时候加一点内容反而能降 token。比如在核心提示里加一句"不确定时先提问"，能减少模型反复试错产生的多余输出，整体 token 反而降了。所以优化不是一味地删，而是让每一分 token 都花在刀刃上。

6. 效果验证与长期维护

6.1 怎么量化优化效果

我用的量化方法是单任务 token 成本：把一个标准任务从开始到结束的所有 token 消耗加起来，除以任务数。优化前平均每个任务约 1.8 万 token，优化后降到约 2700，降幅约 85%。

这个数字和标题里的 85% 对得上。注意这是综合成本，包含了系统提示、用户输入、模型输出和按需注入的全部消耗。

6.2 长期维护的三个习惯

优化不是一次性的，需要长期维护。我养成了三个习惯：

1. 每月做一次 token 审计：统计各类内容的占比，发现异常膨胀及时处理。
2. 新功能先问"是否常驻"：任何要加进系统提示的内容，先判断能不能按需加载。
3. 保留优化前后的对比数据：方便回滚，也方便向团队说明效果。

6.3 什么情况下不该过度优化

不是所有场景都值得把提示词压到极致。如果调用频率很低，比如一天就几次，那 1.4 万 token 的开销其实可以接受，优化投入产出比不高。优化的前提是调用频率足够高，固定开销的累积效应明显。

另外，如果任务类型非常单一，比如只做一件事，那系统提示本来就不需要很复杂，也就没有优化空间。优化的价值主要体现在任务类型多样、调用频繁的场景。

6.4 后续可以扩展的方向

这套思路可以继续往下延伸。比如把按需注入做成更细粒度的检索：根据任务关键词，从知识库里动态检索最相关的片段注入，而不是按预设的映射表。再比如把系统提示做成可版本管理的配置，每次改动都有记录，方便回溯。

我个人在实际操作中的体会是：token 优化的本质是信息架构问题，不是提示词技巧问题。你把信息放对位置，成本自然就降下来了。反过来，如果信息架构是乱的，再怎么调提示词技巧都是治标不治本。所以动手之前，先想清楚哪些信息该常驻、哪些该按需、哪些该外置，比急着改提示词更重要。