企业官网建设流程全解析

Token 与上下文窗口，这两个词几乎决定了你用大模型时的体验和账单，但大多数人是在收到第一笔费用之后才被迫去了解它们。我做了很长一段时间的大模型应用落地，也踩过不少坑，被“失忆”坑过，也被账单吓到过。这个主题我故意放到很靠后才写，因为它是一个底层问题，前面几篇讲的提示词技巧、模型选择、对话风格，其实都在间接和这两个概念打交道。

从一次非常典型的对话说起：你早上问模型“帮我梳理下周要交的季度报告大纲”，聊了十几轮细化之后，下午再打开窗口，问它“第三部分的数据口径是按上个月还是这个月”，它一脸茫然，仿佛没见过你。你气得不行，觉得这产品真健忘。其实不是产品健忘，是Token与上下文窗口在背后给你划了一道物理边界。这篇文章我会把这些边界讲透，并分享我长期实践中沉淀下来的省钱和防遗忘方法，适合刚接触大模型的用户，也适合做应用开发的工程师。

1. 先搞懂Token是什么：模型嘴里最小的“单词”

1.1 中文1个字约等于1.5个Token？别急着背这个数

大模型不直接读文字，它读的是Token。你可以把它理解为模型处理文本时最小的语义碎片。英文里一个词常常被切成1到2个Token，所以英文文档里的“一个单词”和Token数大体对应；中文不一样，一个汉字可能在1到2个Token之间浮动，标点符号、空格、换行也会被算进Token。

我第一次看到Token统计的时候也很疑惑：一段70个字的中文，后台显示105个Token，怎么多出来35个？后来才发现是标点和一些常见词组被切碎了。不同模型用的分词器不一样，同一个句子，在A模型是90个Token，在B模型可能变成110个。所以那句“一个汉字约等于1.5个Token”只能用来做粗略估算，不能当作精确换算。

如果你用API，每个请求返回的结果里通常会带usage字段，里面有prompt_tokens、completion_tokens和total_tokens。这才是计费的唯一依据，也是监控成本时最需要关注的数据。

1.2 为什么切词方式直接影响“智商”和“账单”

Token切分方式不只是计费问题，它还影响模型的理解能力。模型看到的不是字符，而是Token ID序列，如果切得太碎，模型可能抓不住词与词之间的整体语义；切得太粗，又可能把不常见的组合词揉在一起，导致理解泛化能力变差。

我打一个比方：Token像你在菜市场买肉，摊主默认给你切成块，你可以要求切丝、切片还是剁成馅。同一个词在不同模型里被切成不同大小，本质上就是不同摊主的刀法。刀法决定了后面炒菜的口感，对应到模型上就是回答质量的差异。

这也是为什么同样一个问题，两个模型回答水平差不多，账单上的Token数却可能差出一倍。理解了Token的底层逻辑，你才算真正看懂了“为什么同样一段文字，有的接口便宜，有的接口贵”。

1.3 从Token看长文本的“隐藏成本”

长文本对Token的消耗是很多人没概念的。一份两三万字的项目文档，我粗略折算过，大概要消耗两万到三万个Token。如果你把这整份文档塞进对话让模型帮你“通读并总结”，光输入这一步，Token数就轻松破万。

最容易被忽略的是附件和格式。我之前有个项目，用户上传了一个PDF让模型提取表格数据，模型平台会自动把PDF转成文本，这一转，Token量比PDF原始字数膨胀了20%。因为PDF里包含大量格式控制字符、页眉页脚和无意义的断行，模型不能像人眼一样忽略它们，它必须为每个字符付费。

所以我现在处理长文档，习惯是先做一道“清洗”：用脚本把PDF里明显的页眉页脚去掉，把表格转成CSV格式再喂给模型。清洗前后的Token差距，能到30%以上。

2. 上下文窗口就是工作桌面：模型不是不想记，是它只能记这么多

2.1 窗口之内：模型怎么“记住”前面说的话

先澄清一个最常见的误解：模型本身没有记忆。它本质上是一个无状态的推理函数，你输入什么，它输出什么，一轮聊完，它脑子里不残留任何东西。所谓多轮对话的“记忆”，是应用层在每次请求时，把所有历史聊天记录重新发送给模型，让它能“看到”之前的对话。

上下文窗口，就是这个应用层能塞给模型的最长输入长度，通常以Token为单位。打个比方：模型是一个在办公桌上临时工作的顾问，你的历史聊天记录是摊在桌上的文件，新来的问题是一张待办便签。桌面总大小固定，桌上只能放这么多纸，新纸要放上来，旧纸就得被抽走。

不同模型的桌面大小不一样。有的模型桌面能放8000个Token，大约能装下几千字的中文对话；有的能放128K甚至更多，可以容纳长文档。但无论窗口多大，它都有边界，不存在无限记忆。

2.2 窗口之外：超限之后到底发生了什么

这是“为什么它会忘”的第一个核心答案：当历史消息加上新的提问超过了上下文窗口上限，应用后端最常见的处理方式是直接截断。截断不是从最早开始断，就是从最中间找一段砍掉。不同平台策略不一样，但结果都一样——模型的“眼前世界”里已经没有那些内容了。

你问它“我上周提过的预算范围是多少？”，它看到的是几轮被截断后的碎片，当然答不上来。更麻烦的是，很多平台截断时并不会提醒你，它在后台悄悄删掉旧记录，只保留最近几轮，所以你感觉它“失忆了”，其实它是“文件被桌面管理程序清走了”。

我自己遇到过最夸张的一次：一个对话聊到上下文快满时，模型开始反复重复同样的建议，我以为它变笨了，后来查了请求日志才发现，最早的十几轮内容已经被截断，它只能根据最后几轮内容“盲猜”我的项目背景，越猜越离谱。

2.3 所谓“失忆”其实是三种情况混在一起

第一种是“截断失忆”，就是上面说的窗口超限被清理。第二种是“注意力失忆”，这个更隐蔽。就算上下文窗口完全没超限，模型对同一段长文本中不同位置内容的关注度也不是均匀的，很多研究都发现，模型对开头和结尾部分记得更牢，对中间部分的利用效率明显偏低。你如果有一份关键信息藏在长对话的中部，模型很可能真的“看过”却“没注意”。

第三种是“会话隔离”。你新建了一个对话窗口，以前的对话记录完全不会带过来。这不算模型失忆，是应用设计如此，但产品上体验起来就是“你换了个人说话，它不认识你了”。很多新手把这种隔离误当成模型能力问题，其实换个窗口，钱也省了，记忆反而更专注。

搞清楚这三种情况，你会发现“它会忘”并不是随机bug，而是有规律可循的：要么超了边界，要么注意力分配不均，要么根本不在同一个会话里。

3. 账单为什么越来越吓人：Token是唯一的计价单位

3.1 计费规则：输入、输出、缓存，三笔钱别搞混

主流API平台的计费逻辑很简单：输入Token和输出Token分开计价，而且输出通常比输入贵3到5倍。输入是你发给模型的所有内容，包括系统提示词、历史对话和当前提问；输出是模型生成的回复。这个价格差异是有原因的，生成过程比理解过程更消耗算力。

如果一个模型按百万Token计价，输入0.15美元、输出0.6美元，看起来单价很低，但一旦乘上频繁调用的次数，费用就会迅速累积。我经常看到有人只盯着“单次响应”的价格，觉得一次几分钱很便宜，却忽略了每天几十上百次调用之后积少成多的账单。

除了输入输出，现在很多平台还多了一笔“缓存费”。上下文缓存会把相同的前缀Token缓存下来，二次请求时命中缓存，输入价格能打一个折扣，但缓存本身按存储时间计费。这个功能用得好能省不少钱，用不好反而会多出一笔固定开销。

3.2 为什么多轮对话越聊越贵：每次都把整本“聊天记录”重新读一遍

这是“为什么会贵”最核心的机制。因为模型无状态，所以每次请求你要把所有历史消息重新发一遍。你在第10轮提问时，输入里包含的不只是第10轮的新问题，还有前9轮的完整对话。这意味着上下文越长，每一轮的输入Token越多，费用呈线性增长，甚至比新开一个会话贵好几倍。

我用一个简化的例子来说明。假设每轮你输入500Token，模型输出1000Token，系统提示词固定600Token：

• 第1轮：输入1100Token，输出1000Token
• 第5轮：输入7100Token，输出1000Token
• 第10轮：输入14600Token，输出1000Token

第10轮单次请求的费用大概是最开始第1轮的10倍以上。如果你连续聊30轮，光是输入历史对话消耗的Token累计就有几十万。这就是为什么一款产品明明单次调用很便宜，实际跑起来账单却很吓人。

3.3 平台不告诉你的细节：长提示词衰减和重复计费

除了输入输出，还有几个隐藏成本点。第一是思考链Token，部分模型在输出最终答案之前会生成一段“内部思考”过程，这些思考内容同样按输出Token计费，你看到回复只有500字，后台可能已经生成了800字思考内容。第二是输出截断浪费，如果模型生成到一半被max_tokens截断，前面已经生成的部分照样全额计费。

更隐性的成本是“长提示词衰减导致的重试”。上下文太长、中间信息利用率低的时候，模型回答质量会下降。你发现答得不对，就会重新提问，提问次数翻倍，费用跟着翻倍。这不是平台在骗你，而是Token机制本身造成了两头损失：既花钱买了历史，又没换回相应的质量。

我现在的建议是：把“历史记录”看成一种有价格的文件，别随便囤着。能用摘要解决的，不要整段原文搬运；能新开对话的，不要无限续聊。

4. 实测记录：一场对话从第1轮到第30轮的Token消耗

4.1 测试设计：从一句“帮我写个大纲”开始

为了让你直观感受Token是怎么涨上去的，我做了一次模拟测试。假设一个常见场景：用户让模型写一篇产品介绍的大纲，然后一轮一轮地提修改意见，比如“第二段语气再正式一点”“数据部分换一种说法”“把卖点加到第三点”。每次用户新增大约500Token，模型输出大约1000Token，系统提示词固定600Token。

在实际请求里，应用会把每轮的用户消息和模型回复都追加到messages列表里，所以到第N轮时，输入Token就是“系统提示词 + 前N-1轮完整对话 + 当前轮用户输入”。我把近似计算结果放在下面。

4.2 实测结果：第3轮、第10轮、第20轮、第30轮的变化

下表是按输入0.15美元/百万Token、输出0.6美元/百万Token估算的单次请求费用和累计费用：

单看每一个数字都不高，但累计30轮，虚拟对话一共消耗了约60万Token，其中大头全在反复发送旧历史。这还只是很克制的对话节奏。一旦用户每次提问都喜欢把要求重复一遍，或者模型回答偏向长篇大论，Token增长会更加夸张。

换成企业场景就更吓人了。比如做一个文档问答助手，每次提问都要把一份15万Token的项目文档作为背景发送，再加上最近20轮的聊天记录。

• 单次输入：约15万 + 5万 = 20万Token
• 单次成本：20万 x 0.15美元/百万 = 0.03美元，加上输出约0.005美元，合计约0.035美元
• 假设100个用户，每人每天提问10次：0.035 x 1000 = 35美元/天
• 一个月按22个工作日算：770美元

一个月大几千元人民币的成本，就这么花在了“反复读同一份文档”上。这是很多团队上线第一个AI应用后，账单翻车的最常见原因。

4.3 这组数据告诉我们的真话

“为什么贵”的本质不是单价高，而是重复发送历史内容的次数太高了。模型是无状态的，你每次都要把旧内容重新喂一遍，这就像每天早上把上周所有的会议记录重新朗读一遍，然后才开始今天的工作。时间久了你当然觉得累，放在服务器上，换来的就是一笔一笔的Token账单。

理解了这组数据，你就能理解我后面给的实战清单：所有省钱方法的本质，都是减少“重复发送的Token”；所有防遗忘方法的本质，都是把关键信息放到模型更容易注意到的地方。

5. 长期实战后总结的省Token与防遗忘清单

5.1 开聊之前：把项目背景写进系统提示词，而不是每轮重复

很多人在对话里反复说“我之前跟你说的那个项目”，然后发现模型一脸懵。正确做法是开一个会话时，就用一小段话把项目背景、目标、约束条件写清楚。如果你用的是API，就放到system消息里；如果你用的是聊天产品，就放在第一轮提问里。

系统提示词不是越长越好，控制在200Token以内效果通常最佳。背景信息越精准，模型越不需要靠历史记录去猜，你也就越不容易触发上下文超限造成的“失忆”。

我通常的格式是这样：

{ "system": "你是一名产品运营顾问。项目背景：面向中小企业的一站式发票管理工具，本季度目标是提升老用户续费率。回答时保持简洁，不重复用户原话。" }

这个做法同时减少了历史里的冗余内容，也把关键信息固定在模型更容易注意到的开头位置。

5.2 聊到一半：定期让模型“复述重点”而不是无限续聊

当你发现对话轮数已经超过七八轮，或者感觉模型开始忽略早期信息时，别硬着头皮继续聊。用一个临时指令，让模型把当前已经达成的结论整理成结构化摘要，比如“请把到目前为止的关键结论、已确认参数、待办事项用50个Token以内总结出来”。

拿到摘要后，新建一个会话，把这段摘要作为系统提示词，再继续提问。这一步相当于把你桌上已经堆乱的文件整理成一张索引卡，然后换一张干净桌子继续工作。Token成本立刻从那几十万的历史记录，变成几百Token的摘要。

我实测过，同样是修改一份文案，用“摘要+新会话”的方式，整体费用能降低60%以上，而且模型对前文关键信息的遵循度反而更高，因为它不再需要从海量历史里大海捞针。

5.3 对话快到底时：主动截断历史或清理无关内容

如果你用的是API接口，可以在每次请求时只保留最近N轮消息。比如设置成只传最近4轮，再加一条系统提示词说明“只根据给定对话记录回答”。这能让上下文窗口保持清爽，代价是更早的内容会被遗忘，所以它适合对信息连贯性要求不高的场景。

你还可以手动清理对话里已经被修改过的旧版本。很多人贴了第一版文案，模型又给了第二版，他们会在后面的对话里继续保留第一版全文。这些第一版内容已经没有任何信息价值，却依然每个字都在收费。我的习惯是：一旦采纳了某个版本，就把旧版本从消息数组里删掉，只保留最终版本。

5.4 模型选择也影响成本：长窗口不是默认选项

长上下文窗口确实方便，但它通常也更贵。如果你的任务只是日常问答、写邮件、改文案，几百Token就能搞定，完全没必要选一个128K窗口的高价模型。小窗口模型在成本和响应速度上都更友好，而且因为窗口小，输入Token也很难越积越多，相当于变相强制你控制历史长度。

反过来，如果你的任务就是处理长文档，短窗口模型才是真正的坑。因为长文本一进来就超限，应用后台只能截断，结果就是钱没少花，模型还漏看内容。选模型之前，先估算一下你需要的最小上下文长度，然后在这个长度附近找一个窗口和价格都合适的模型。

5.5 用好缓存，而不是迷信缓存

上下文缓存能降低重复部分的输入费用，这对“多次提交相同系统提示词”的场景特别有用。命中缓存后，重复前缀的输入单价可以便宜很多，输出价格不变。

但缓存有代价：存储按时间计费，而且缓存内容一旦更新，旧缓存就失效了。所以缓存适合那种系统提示词固定、用户输入变化不大的场景。如果你的每次请求内容都高度不同，缓存不仅帮不上忙，还会多一笔存储费。

我见过一个团队把缓存用在“每次生成不同推广文案”的接口上，结果每次前缀都不同，缓存命中率几乎为零，账单里多出一项不小的缓存存储费。后来关掉缓存，成本立刻降了。

5.6 防遗忘的应急技巧：把关键信息“移动”到对话边缘

根据前面说的注意力偏差，模型对对话开头和结尾的内容更敏感。如果有一段信息非常重要，你可以在当前提问里再复述一次，而不是只让模型回头去翻中间轮次。

比如你可以这样写：“注意：预算上限是5000元，这个约束在之前的讨论里已确认。请基于这个数字给出方案。”把关键约束放到提问末尾，模型正确响应的概率会高很多。这招不能解决所有遗忘问题，但在关键时候能抢救一下，也是我自己最常用的应急手段。

6. 最后说几句私货：Token意识是使用大模型的分水岭

我现在养成了一个习惯：每次对话跑完，都会下意识看一眼Token统计；每次设计一个AI功能，第一版一定会先估算输入输出Token的量级。这不是强迫症，而是被账单教育过之后的身体记忆。

如果你刚开始接触大模型，我建议你也建立一个“Token意识”。它不复杂，就是随时问自己两句话：我这次发了多少Token？其中有多少是真正有用的？只要这两个问题有答案，你就不会在“为什么它会忘”和“为什么这么贵”这两个问题上踩太多坑。

至于那些想把历史记录全都堆给模型、指望它长点记性的做法，我的建议是尽快放弃。Token与上下文窗口的边界就在那里，与其对抗物理边界，不如顺着边界设计你的对话和应用。桌面上的文件永远放不完，聪明人知道什么时候把旧文件归档。