企业官网建设流程全解析

1. 半古法更新这根线，到底在整理什么

先交代一下背景。这个系列的定位，我一直是用“半古法”三个字来框定的。古法意味着不追新、不迷信官方默认，凡事多问一句“为什么”；半古法则承认时代变了，该用新工具的地方不硬扛老办法，该省的成本也不装看不见。第三期这个标题，落点非常聚焦：每天被模型消耗的token，其实一半以上是可以不花或者少花的。

这期内容面向的读者，主要是这几类人：一是日常把大模型当搜索引擎用，但月底看到账单觉得不对劲的普通用户；二是用API做自动化脚本、批量跑文本处理的开发者；三是在团队里负责AI工具选型，需要平衡效果和成本的决策者。无论你属于哪一类，这期的核心思路都一样：让模型只在它真正擅长、且你真正需要的地方干活，其余环节能省则省，能糙就糙。

说句实在话，大模型的token计费机制，本质上和当年按流量算手机费是一个道理。早期移动互联网刚起来的时候，很多人不懂为什么一个网页才几百KB，刷半小时却要几十块钱流量费——因为图片、脚本、样式表都在悄悄消耗配额。换成token也一样，你以为自己只让模型写了一句话，但系统提示词、历史对话、工具调用记录、格式说明全在按token计费。真正干活的是那句话，真正烧钱的是那堆看不见的上下文。

所以这期我打算从四个角度来拆：先讲清楚token到底被谁消耗掉的，再给出“按需选模型”的实操策略，接着分享一套省token的调用习惯和提示词写法，最后把常见翻车现场和一些不得不说的经验教训汇总成速查表。整篇东西不看版本号、不绑定具体厂商，思路和流程在任何主流大模型平台上都能直接套用。

2. token为什么总是不够用：先搞懂你的钱花哪了

2.1 一次请求里，到底哪些部分在吃token

很多人的直观理解是：我发一段话给模型，模型回一段话，那token消耗就等于“我发的字数 + 模型回复的字数”。这个理解没全错，但漏掉了大头。

一次标准的API调用，实际计费覆盖四个部分：

1. 系统提示词（System Prompt）：你设置的角色、行为规范、输出格式要求，这部分每个请求都会完整发送一次。
2. 历史对话记录（History）：多轮对话场景下，之前的问题和答案会全部重新发送给模型，以此维持上下文连贯。
3. 本次用户输入（User Input）：当前这一轮你实际问的内容。
4. 模型输出（Output）：模型生成的回答，按生成字数计费。

这里有个非常反直觉的点：前三个部分加起来叫“输入token”，最后一个叫“输出token”。好多平台的定价策略是“输出token比输入token贵”，但也有平台反过来，输入便宜输出贵。不管怎么定价，共同规律是：历史对话和系统提示词，是普通人最常忽视的隐形消耗源。

我见过一个比较典型的案例：某团队做客服问答机器人，系统提示词写了两千字，要求模型记住所有产品规格、退换货政策、物流说明、售后话术，然后每次用户提问，这两千字都原封不动发一遍。表面上看每人一句提问没多少token，但一天几千次调用下来，光系统提示词就烧掉了总量的六成多。

还有个常见的理解偏差，是把“上下文窗口大小”当成“免费容量”。上下文窗口只是模型能处理的输入上限，比如某模型支持128K上下文，意思是它最多能“看”这么多token的内容，但看的内容每一帧都在计费，不是按“窗口占用率”计费，更不存在“窗口内的部分免费”这种好事。

2.2 为什么说“对话轮次越长，单价越贵”

这个规律很少有人仔细算过，但实际体验非常明显。

假设你和一个模型连续对话20轮，模型每轮记住前文才能接话。到了第20轮，整个请求的输入内容是什么？是第1轮到第19轮的所有问答记录，加上第20轮你的新提问。这意味着：对话越深，单次调用的输入token就越贵，而且是线性增长甚至超线性增长。

举一组直观的数据。假设平均每轮问答消耗500个token（输入输出合计），那么：

• 第1轮调用：输入很少，输出500，总消耗约500+。
• 第10轮调用：需要重新发送前9轮约4500个token的历史记录，再加当前输入，总消耗轻松破5000。
• 第20轮调用：历史记录接近9500个token，单次消耗直接逼近1万。

写到这里有人可能问，那模型不是有“记忆”吗？不是把它训练好的东西存在脑子里吗？这个误会源于把人类记忆和模型上下文机制搞混了。模型的“记忆”只存在于当前对话的上下文窗口里，窗口一关、会话一结束，什么都留不下。它不像人脑有长期记忆存储，而是像一张白板，每次你写字上去它才能看到，字越多它处理越慢、越贵，擦掉字它就全忘了。

理解这一点，就明白了省token的第一原理：控制上下文长度，比控制提问字数重要得多。

2.3 token消耗的度量与计算：不该凭感觉，要有数

想要做到“节省token”，不能只靠口号，得能自己算账。这里给一套最简单实用的估算方法：

• 中文环境下，粗略可以按“1个汉字 ≈ 1到2个token”来估计。因为大部分模型的词表是基于子词切分的，常用汉字和常见词组的编码效率不同。比如“你好”可能算2个token，但一个冷僻成语可能算3到4个。英文环境下，一般是“1个英文单词 ≈ 1到1.5个token”，标点和空格也会占位。
• 系统提示词如果写满800字，大约相当于1000到1600个token。
• 一次带完整历史记录的请求，输入token可以通过平台后台的日志查询，也可以自己在代码里调用tokenizer工具统计。
• 输出token通常按回复的实际生成量算，你让模型写一篇长文和让它只回“是”或“否”，差距可能是几百倍。

如果想精确统计，可以在代码里直接调用模型厂商提供的tokenizer接口，也可以在平台控制台看每次请求的token明细。不过对大多数普通用户来说，用上面这个粗略估算方法就够了，关键是建立“用量感”，而不是追求毫米级精确度。

提示：如果你经常忘记这个估算关系，可以记住一句口诀——1000字中文文本，后台计费大概率在1500到3000个token之间。这个区间对应着日常使用的安全估算值。

算清这笔账之后，下面自然就引出选模型和调用的优化策略。

3. 按需选模型：不是所有请求都用顶配

3.1 不同模型档位，到底差在哪

现在的模型市场很有意思，同一个厂商通常同时提供好几个档位：有参数量大的旗舰版本，有速度快的轻量版本，有专门优化过代码的版本，还有便宜到几乎可以忽略成本的蒸馏小模型。

这些模型的区别，主要体现在三个维度：

1. 推理能力：旗舰模型更擅长复杂逻辑、长文本理解、多步推理；轻量模型在简单问题上基本够用，但遇到微妙任务容易答偏。
2. 生成速度：轻量模型通常更快，因为计算量小；旗舰模型可能更慢，尤其在长输出场景下。
3. 价格差异：旗舰和轻量之间，价格往往能差一个数量级，甚至更多。

很多人日常使用有个惯性思维：同一个工具用顺手了就不换，所有任务都丢给最贵的模型。这就好比出门买菜开跑车，去超市买瓶酱油也用物流专线送，不是不行，但成本远高于需求本身。

3.2 一个实用的分级调用策略

我在实际项目中长期使用一套三级分级策略，整理出来供参考：

• 第一级：轻量模型，负责高频低难度任务。比如关键词提取、简单分类、格式转换、生成摘要、口语化翻译、日常问答。这类任务模型只需要“理解个大概”再加一点语言能力就能完成，用旗舰模型未免太奢侈。
• 第二级：中端模型，负责需要一定推理但不算复杂的任务。比如中等长度的文案润色、结构化数据整理、代码debug、多条件筛选排序等。这类任务需要模型具备一定的逻辑处理能力，但还没到需要深度思考的程度。
• 第三级：旗舰模型，只负责真正的硬骨头。比如长文深层分析、多文档综合推理、复杂业务逻辑设计、代码架构规划、创意构思与风格模仿等。这类任务写错代价高，或者本身包含大量隐含约束，需要模型动用最多的参数和能力。

这套分级策略，核心原则只有一条：根据任务的“难度上限”选模型，而不是根据你对模型的“熟悉程度”选模型。

顺便提醒一个容易忽略的点：同一个任务在不同阶段可能适合不同档位的模型。比如你让模型写一篇文章，初稿阶段用轻量模型拉个框架，修改阶段用旗舰模型做深度润色，最终校对阶段又可以用轻量模型扫一遍错别字。分阶段的模型混用，往往比全程用一个模型省好几倍成本，质量反而更好。

3.3 什么样的任务必须上旗舰，什么样的任务别浪费

为了帮你更快做决策，我列一个对照表。这个表不是绝对标准，但长期实测下来非常实用：

使用中还有一个小技巧：如果某个任务只有8成把握，但你在用旗舰模型，那就先想想这20%的不确定性是否值得付那么多钱。很多时候，用一个便宜模型跑三遍，再从中挑一个最好的答案，效果反而比旗舰模型一把过还要稳，成本却低得多。

4. 节省token的实操手段：从提示词到调用链

4.1 把系统提示词精简到够用为止

系统提示词是省token最值得下手的地方，因为它是每个请求必带的“固定开销”。很多人的系统提示词像写作文，其实大可不必。

我的经验是，系统提示词应该做减法，只保留三类信息：

1. 角色与任务边界（你是谁、你要干什么）
2. 输出格式要求（结构、长度、是否要JSON等）
3. 关键约束（绝对不要做的事，比如别说废话、别重复用户内容）

其他可有可无的客套话、背景介绍、举例说明，能省则省。举例说明只保留一个最典型的，不要一次给五个例子，因为每个例子都要吃token。

我自己有个习惯：每次写完系统提示词，都会自问一遍“如果去掉这句话，模型会跑偏吗？”如果不会，就直接删掉。一句话看起来不多，但乘以每天的调用量，积少成多就是一笔不小的开销。

还有一个小建议：如果平台支持“动态系统提示词”，尽量利用。也就是说，普通请求使用精简版系统提示词，只有特定任务才临时拼接详细版。这比全量使用详细提示词灵活得多，也省得多。

4.2 控制历史对话长度：该截断时就截断

历史对话管理，是省token最见效也最容易被忽视的环节。很多人不做任何处理，几十轮对话全部带上，最后一轮请求的输入token已经爆炸。正确的做法是：

• 只保留最近N轮对话：根据任务需要，一般保留最近5到10轮就够用，再早的内容基本已经是噪声，不仅耗token，还可能干扰模型回答。
• 关键信息压缩：如果旧对话里有必须记住的信息，把它手动提取成一两句话的“摘要”，放在系统提示词里，比保留完整对话记录省太多。
• 分轮清理：如果对话本身是阶段性的，比如先讨论方案A再讨论方案B，那在进入方案B时完全可以把方案A的讨论清空，避免上下文污染。

有人担心截断会丢信息，这个担心合理，但要分场景。对多轮闲聊来说，模型的“短期记忆”本来就不需要那么长；对严肃任务来说，重要的信息应该被你主动提炼出来放到提示词里，而不是指望模型帮你从一坨历史聊天记录里捞。

4.3 提示词写法上的省钱套路：少输出、要结构、免重复

提示词写法对token消耗的影响，经常被严重低估。我分享三个实战中验证过的套路：

套路一：明确限制输出长度。直接告诉模型“回答控制在100字内”“只返回三个要点”“每个要点不超过20字”。这比让模型自由发挥再到外面截断要省钱得多，因为输出token是按生成量计费的，限制输出长度等于直接卡住计费上限。

套路二：要求结构化输出。让模型按固定格式输出，比如“请用JSON格式返回：字段A、字段B、字段C”。结构化的好处是模型不会绕来绕去，输出干净，也方便你程序化解析，省掉事后的清洗加工。

套路三：禁用无关话术。很多模型默认会生成过度礼貌的开场白和结束语，比如“好的，我来帮您分析一下”“希望对您有所帮助”。这些礼貌用语在正式调用中没有任何价值，白白吃掉输出token。直接在系统提示词里写清楚“不要客套，不要重复用户问题，直接给答案”即可。

还有一个很多人不知道的技巧：用“填空式提示词”代替“问答式提示词”。比如你想提取客户反馈里的产品名和问题类型，与其问“请从下面这段客户反馈中提取产品名和问题类型，并解释为什么”，不如直接给一个模板：

客户反馈：{{feedback}} 请按以下格式输出： 产品名： 问题类型： 严重程度：

填空式提示词的好处是让模型输出范围更收敛、更直接，也不容易产生多余解释。同样一段话，用填空式能比问答式省下10%到30%的输出token。

4.4 缓存与复用：同一个大段内容，别反复发送

现在不少主流平台提供了上下文缓存功能，如果你频繁使用同一段系统提示词、同一份参考资料，可以尝试把这些固定内容设为缓存前缀。缓存机制的原理是，当请求中的某一段内容与之前请求完全一致时，该部分的计费会大幅降低，甚至按固定费用计算。

这在批量处理任务时效果尤其明显。比如你要用相同的规则模板处理1000条数据，如果把规则模板放进缓存前缀，每一次调用只需要为新增的那一条数据计费，模板部分不重复吃钱。实测下来，这种场景能省掉70%以上的输入token费用。

当然，缓存也不是无脑用：一是缓存有有效期和容量限制，太久没调用会被清除；二是内容必须完全一致才能命中缓存，哪怕改了一个标点都得重新算。所以在设计提示词时，固定不变的部分要单独拎出来放到前面，变化的部分放到后面，尽可能保证前面那段内容长期稳定。

5. 真实项目复盘：一套省token方案的完整落地

5.1 场景设定与基线数据

为了便于理解，我拿一个模拟项目X来演示完整的操作流程。某跨平台系统需要定期抓取一批文章，自动提取关键信息并生成摘要，每天处理约200篇。早期版本是这样写的：

• 系统提示词：约600字，包含背景介绍、角色定义、格式要求、两个示例。
• 每篇文章单独调用一次API，不缓存任何内容。
• 模型统一使用旗舰版本。
• 输出要求是“完整的3段式摘要”，包括背景、分析、建议。

跑了一周之后看后台数据，日均消耗token约120万，按平台的计费规则折合人民币大概日均100块出头。一个月下来光摘要这一个功能就烧掉3000多，这在当时看来非常不可接受。

5.2 优化动作与量化结果

这个项目前后做了五轮改动，每一轮都验证了不同的省钱思路。我把关键动作列出来：

1. 替换轻量模型：将简单的关键词提取任务独立出来，交给轻量模型处理，旗舰模型只负责最终的摘要生成。这一步直接把日均token消耗压到了75万左右，降幅超过35%。

2. 裁剪系统提示词：把600字压到250字，删掉了背景介绍和第二个示例，只保留角色、格式、约束。因为很多背景信息对模型来说没必要知道，它只需要明白“怎么输出”就行。这一步又带来大约10%的降幅。

3. 限制输出长度：从“3段式摘要”改成“200字以内结构化摘要”，要求按固定模板输出。输出token大约少了40%。

4. 引入缓存机制：把每篇文章共同的规则模板放进缓存前缀，让模板部分不再重复计费。日均消耗再次下降约30%。

5. 启动截断机制：因为每篇文章的调用相互独立，不存在多轮对话的累积问题，但最初代码里把上一篇文章的摘要结果当作下一篇文章的参考上下文传入了，这部分属于完全多余的历史记录，删掉后输入token又小降了一截。

整个优化做完后，日均token消耗从120万降到了大约30万，成本从日均100块出头降到约30块。也就是说，同样的任务量，花了原来四分之一不到的钱。

5.3 踩过的坑和应对方案

光讲成功路径不够，我把过程中踩过的坑也摆出来，都是真实做出来之后才发现的：

• 坑一：轻量模型在个别复杂文章上输出质量明显下降。关键词提取可以，但遇到那种逻辑绕的文章，摘要会遗漏关键信息。应对方案是增加“质量检测”环节：对每一篇摘要计算长度和关键词命中率，低于阈值就自动升级到旗舰模型重跑。这样既保证质量，又不会让旗舰模型成为默认选择。
• 坑二：限制输出长度导致摘要过于简略，丢失了必要的背景信息。后来改成了“必须包含三个固定要素，每个要素一句话”，这样既控制了长度，又防止模型顾此失彼。
• 坑三：缓存前缀因为格式微调而失效。有一次我在规则模板末尾加了个换行符，结果整个缓存全部失效，当天成本又升回去了。这个问题排查了很久才发现是字符细节的问题。以后凡是改动模板，必然检查缓存命中率。
• 坑四：过度裁剪系统提示词导致模型频繁输出错误格式。有次我把格式说明压缩得太狠，结果模型在10%的请求中不按模板输出，数据解析直接崩溃。后来在“简洁”和“示例”之间找平衡，只留一个最短的示例，稳定性和成本兼顾。

这套方案跑了一个多月，目前整体运行稳定。每天批量处理+少量人工抽检的时间成本几乎可以忽略，而费用已经降到可控区间。

6. 常见问题与排查技巧实录

6.1 哪些问题最容易让token偷偷溜走

日常使用中，有几个问题几乎每隔一阵就会出现，非常具有迷惑性。我整理了排查清单：

• 问题一：没有设置单次请求的最大输出上限。有些API可以在参数里直接指定max_tokens，如果不设，模型可能在某次输出上放飞自我，一篇长文就烧掉几千token。设置上限之后，即使偶尔需要长文，也会先出截断版本，再针对性地补写，成本是可控的。
• 问题二：自动重试机制导致重复计费。有的代码框架在请求超时或返回错误时会自动重试，但如果你没留意重试次数上限，一次请求可能被重复执行五六次，每次都完整计费。排查方案是看后台日志的请求次数和耗时分布，把异常重复的请求打上标记。
• 问题三：把非必要内容塞进上下文。比如你只是想问一个点，却把整篇文章复制进去；或者做数据处理时，把整个数据集格式带进提示词。大部分场景其实不需要把全文带给模型，只需要带上关键段落或提炼后的要点。
• 问题四：多个流程共享一个上下文长会话。假如你的脚本在一个进程里连续处理多个不同任务，且没有清空历史记录，那么任务B启动时，任务A的全部对话记录还被带着，白白吃token。规范做法是：每个独立任务单独开一个会话，处理完即关闭。

6.2 排查流程：从后台数据到代码逻辑

排查token消耗异常，我通常会按这个流程走：

1. 看总量趋势：到平台控制台查看按小时或按天的token消耗曲线。如果某个时段突然蹿高，先把异常时段对应的调用记录捞出来。
2. 看单次请求明细：找到峰值请求，查看它的输入token构成——是系统提示词占大头，还是历史记录占大头，还是本次输入占大头。
3. 看代码调用逻辑：对照代码确认是否存在多次调用、长会话未清理、错误重试未限制等问题。这一步通常能解决80%的“莫名其妙烧token”案例。
4. 看提示词大小：把当前使用的系统提示词和历史记录量估算一遍，和实际记账数据对一下，看是否存在明显偏差。

这个流程走下来，基本都能找到问题根源。不要一上来就怀疑平台计费有误，平台计费出错的情况极少，大多数是自己代码或使用习惯的问题。

注意：如果发现某次请求的token消耗突然异常，但又没改动任何代码，优先检查是不是平台侧的模型版本自动更新导致的，新版本模型的tokenizer可能和旧版本略有差异。这种情况只能重新评估和适配。

6.3 经验积累：长期低成本使用模型的心得

最后分享几条我个人长期实践下来的心法，不一定适合所有场景，但确实帮我省了很多不必要的开支：

第一，永远不要把“最贵”和“最好”绑定。旗舰模型确实是工具库里最锋利的刀，但不是所有活都值得用最锋利的刀去切。切水果用水果刀，砍骨头用砍骨刀，这是最基本的生活常识，放在模型选型里同样成立。

第二，在代码里埋好统计点。每次调用API就把请求token数、输出token数、消耗金额记下来，存成日志。没有数据支撑，你永远不知道自己到底烧了多少钱。等出了账单再复盘，已经晚了。

第三，按季度重新评估一次模型选型。模型市场变化很快，今天很贵的能力，三个月后可能已经很便宜；今天很弱的轻量模型，三两个月后可能能力大涨。如果一直用半年前的选型策略，很可能在为一个已经降级的成本支付过高的费用。

第四，敢于让模型帮忙优化它自己的调用方式。偶尔我会直接问模型“如果要你用少量token完成这个任务，你会怎么设计提示词”，模型给出的方案往往比我自己想的还精简。这听起来有点套娃，但实际效果确实不错。

7. 写在最后的个人体会

这个系列的“半古法更新”写到现在，第三期终于把最核心的成本问题摆到了台面上。我自己最深的体会是：省token这件事，不是靠某一次“惊为天人的骚操作”实现的，而是靠一整套不性感但有效的小习惯累积起来的——该换模型时换模型，该裁提示词时裁提示词，该截断时截断，该缓存时缓存。

以前我也犯过所有请求一把梭的毛病，总觉得换模型麻烦、调提示词费事、写缓存逻辑又要多几行代码，不如全用旗舰模型省心。直到某天看到月度账单的时候，我才意识到，那种“省心”其实是用钱买来的，而且买得相当不值。

现在我的习惯是：哪怕只是一个非常简单的提炼任务，也会先想一想，这个任务放到哪个档位的模型上，性价比最高。这不是抠门，而是对资源有清楚认识后的从容选择。模型能力再强，也只是工具；会用工具的人，应该知道什么时候用大炮，什么时候用匕首。

这一期的内容就到这里。下一期我会接着聊“半古法更新”这个系列里的另一个核心话题——如何在不牺牲效果的前提下，让模型输出的可控性更好。如果你也在日常使用模型时遇到过类似的成本困扰，欢迎把你的账单异常案例拿出来聊一聊，或许下一期就会拿你的场景做示例。