和 AI 聊得越久，它就越容易漏掉前面的要求；上传文件后，有时又提示内容太长。遇到这些问题，先别急着换提示词，应该分清三个概念：Token 是处理单位，上下文窗口是容量边界，输出上限是单次能生成多少内容的限制。

本篇用“客服答复草稿”练习，教你整理输入、测量用量、预留输出空间，再核验答案。它属于 AI 基础知识，不需要本地部署大模型。文中的数字预算都是教学示例，不是某款模型的真实额度，也不代表本站做过性能测试。

一、Token 不是字数，也不是次数

模型不会直接按人眼看到的字数处理文本，而是先把内容切成 Token。一个 Token 可能对应单个字符、一个词或词的一部分，取决于模型的分词方式。相同的文章，换模型或分词器后，Token 数可能不同。

中文、英文、数字、网址、代码和表情符号的切分也不一样。网上常见的“一个 Token 等于几个字”，至多适合粗略估算，不能当作中文稿件的准确换算公式。要精确核算，使用对应供应商的计数接口或使用量记录。

另外，“一天能问多少次”和 Token 配额不是同一回事。网页产品可能按消息数、时段或套餐限制使用；API 通常还有请求频率、输入输出用量及其他计费规则。看到一个额度数字时，先确认它的单位是什么。

Token、上下文窗口、输出上限和对话历史四个概念的关系示意

上图是概念示意，不表示任何产品的具体窗口大小。

二、上下文窗口里，可能不只有你最后那句话

一次请求需要处理的内容，可能包括系统要求、应用指令、当前问题、保留的历史对话、检索结果、工具返回以及文件内容。不同平台组织上下文的方式不同，不能只数最后输入框里的两句话。

可以把它理解为一次任务的工作台：放入太多旧材料，新任务的重要信息就更难管理。容量大并不等于每条信息都会被同样可靠地使用。“装得下”与“答得对”需要分别验收。

例如，你先讨论品牌口吻，随后粘贴大量商品资料，又让 AI 修改多次答复。最后一句“按前面说的来”，既依赖平台是否仍保留原要求，也依赖模型能否正确找到它。更稳妥的做法是，为当前任务重新提供精简、明确的规则和必要证据。

这里也要区分上下文与长期记忆。某些产品提供跨对话偏好或记忆功能，但它们是否开启、保存哪些内容、如何检索，都由具体产品决定。开一个新对话，不意味着之前所有资料会自动带入；历史记录存在，也不等于全部进入当前请求。

三、输出上限为什么需要单独预留

输入还有空间，不代表模型就能一次写出任意长度的答案。模型或接口通常分别约束输入、输出和其他用量项，部分推理模型还有思考用量。请阅读目标模型的当前说明，不能把一个窗口数字直接当成可输出字数。

为了练习，可以自行设定一个较小的输入预算和输出目标，例如：只保留完成这次客服任务所需的政策、问题和关键历史，答案限制在六个要点内。这是你给任务设的工作预算，不是产品规格。

如果输入已经接近边界，却还要求生成完整报告、多个版本和附录，就容易出现请求被拒、输出被截断或关键结论来不及写的问题。长任务更适合分成有明确交付的阶段：先核验事实，再生成一份答复，再检查遗漏，而不是让模型一口气完成所有工作。

四、实际练习：整理一份最小可用上下文

准备下面的虚构客服材料。它不涉及真实订单和个人信息，可以直接用来做练习。

政策 A：未使用的数字模板，购买后 7 天内可申请退款。
政策 B：已下载且已使用的模板，需要人工审核，不自动承诺退款。
政策 C：无法确认购买时间或使用状态时，先收集必要信息。

用户问题：我上周买的模板已经下载了，还能退款吗？
已知历史：用户只说已下载，没有说明是否使用，也未提供准确购买日期。

第一步，把内容按用途分开：政策属于依据；用户原话是待回答问题；已知历史用于识别缺失项。删除和这次退款判断无关的旧营销活动、其他商品介绍和反复修改的历史草稿。

第二步，提供一份清楚的任务指令：

请只依据下面的政策和已知信息，生成客服答复草稿。
先列出已确认的事实，再列出缺失信息，最后写不超过 150 字的答复。
不要将“已下载”推断成“已使用”。
不要把“上周”换算成具体购买日期。
不确定时提出必要问题，不承诺审核结果。

第三步，在指令下放入政策与用户材料。完成后检查：答复是否询问准确购买时间和使用状态，是否避免直接保证退款，是否区分“下载”和“使用”。这些才是本次练习的正确性检查点。

第四步，加入一段明显无关的旧活动材料，再比较两次答案。这只是读者可自行开展的小实验；不要因为某次结果相同就断言无关内容永远无影响，也不要把一次变化解释成普遍规律。记录输入变化、模型、设置和结果，才便于复查。

五、需要精确用量时，怎样计数

普通网页用户可以先查看产品提供的用量信息。若没有计数入口，不必把字符数冒充 Token 数。开发者则应使用目标供应商的计数能力；下面用 Gemini 官方 Python SDK 的 count_tokens 展示方法，只计量输入，不生成答复。

  1. 准备可使用 Gemini API 的账号和密钥，确认当前账号、区域、模型及调用限制。SDK 是接口客户端，不能让不具备权限的账号获得访问资格。
  2. 在独立 Python 环境安装官方 SDK，并设置环境变量。示例中的模型名由你从官方模型列表选择，不填虚构名称。
py -m venv .venv
.\.venv\Scripts\python.exe -m pip install google-genai
$env:GEMINI_API_KEY = "你的接口密钥"
$env:GEMINI_MODEL = "你账号可用且支持计数的模型标识"
  1. 将完整练习输入保存为 UTF-8 编码的 request.txt，新建 count_input.py：
import os
from pathlib import Path
from google import genai

client = genai.Client(api_key=os.environ["GEMINI_API_KEY"])
contents = Path("request.txt").read_text(encoding="utf-8")
result = client.models.count_tokens(
    model=os.environ["GEMINI_MODEL"],
    contents=contents,
)
print("输入 Token 数：", result.total_tokens)
  1. 运行脚本，再删掉无关材料重新计数：
.\.venv\Scripts\python.exe count_input.py

本例数的是传入 `contents` 的文本，不是最终答复，也不是某个聊天网页自动附带的所有内部内容。正式应用若还有系统要求、工具说明、图片或历史消息，应按该接口支持的真实请求结构核算，而不是只测一份文本后假装测完全部上下文。

计数调用的可用范围、速率与费用请查看当前官方说明。示例不展示伪造的运行数值；读者实际获得结果后，再填写自己的用量记录。

六、成本与缓存，不能混为一谈

一次 AI 任务的成本，可能涉及普通输入、缓存输入、输出、思考、工具及多模态处理等不同项目。不同模型口径不同，不能把一项 Token 单价乘以所有内容，得到一个看似精确的账单。

如果每次传入相同的大段材料，供应商可能提供上下文缓存。Google 官方说明区分相关接口与缓存机制，缓存命中和适用门槛由模型及接口决定。缓存不是长期记忆，也不保证每次请求都省钱，应从真实响应的使用量字段确认，不能仅凭“内容相同”推断已命中。

个人使用时，先优化任务组织通常更直接：删除无关内容、限制不必要的多版本输出、保留关键事实和明确验收标准。为了减少一点输入而删掉退款条件、金额单位或引用依据，反而会增加后续返工。

七、怎样判断这次优化确实有效

上下文优化同时检查信息完整、输出正确、用量记录和异常排查的清单示意

上图为原创检查清单示意。建议保存四份结果：

  1. 输入清单：保留了哪些依据、删掉了哪些无关材料，敏感数据是否已最小化。
  2. 正确性记录：客服草稿是否保留不确定信息，有没有把已下载改写成已使用，有没有编造日期。
  3. 用量记录：使用哪个模型、计数覆盖哪些字段、实际响应有哪些用量项。不把不同模型的 Token 数当作同一把尺子。
  4. 修改结论：若减少输入后漏掉重要政策，就恢复依据或重新组织材料；若只是要求更短而没有核验事实，不能算有效优化。

常见故障也可以依次排查。请求超长时检查完整输入结构；答复截断时检查输出设置与停止原因；记不住要求时检查是否仍传入关键指令；计数不一致时检查模型、文件编码、历史消息和多模态内容是否相同。

最终要得到的是一份材料够用、规则清楚、结果可核对的请求，而不是单纯追求最少 Token。

官方资料