把同一个问题连续发给大模型，答案可能不一样。聊得太久，它又可能忘记前面定好的规则。很多人碰到这些现象，会用“模型今天状态不好”来解释。
这个说法就不对，而且对排查问题没什么帮助。我们换一个更直管的理解：模型接收一段 Token，在有限的上下文里计算接下来可能出现什么，再按采样参数选出一个结果。先做这三件事，后面的 API、RAG、工具调用和 Prompt就能慢慢搞清楚了。
Token 不是一个汉字，也不等于一个单词
模型不会直接读取我们眼中的句子。文本要先经过 Tokenizer，也就是分词器，转换为一串 Token ID。Token 可以是一个汉字、词的一部分、标点，也可能是一段常见字符组合。
拿“订单晚到了”做例子。我们肉眼看到五个汉字，某个模型可能把它切成几个常见词片段，另一个模型可能切得更细。英文、数字、代码和少见字符也会影响结果。不同模型可能使用 BPE、Unigram、WordPiece 或其他分词方案，所以“一个汉字等于一个 Token”只能当粗略估计，不能拿来做精确预算。
如果你要计算费用或判断请求会不会超过限制，应使用目标模型对应的 Tokenizer 或服务端返回的用量。不要拿模型 A 的计数去推断模型 B。
模型生成的是下一个 Token
Transformer 的核心工作可以先简化成一句话：根据当前上下文，计算下一个 Token 的候选概率。
输入“订单晚到了，客服应该”后，候选结果可能包含“道歉”“查询”“解释”等。模型选出一个 Token，把它接到已有文本后面，再计算下一个。这个过程不断重复，直到生成结束标记或达到长度限制。
它和搜索框的差别就在这里。搜索通常从已有资料中找结果，语言模型则是在当前输入条件下生成序列。生成内容读起来很完整，不代表每句话都来自一个可靠来源。涉及版本、价格、法规或实时事件时，仍要接入检索并核对出处。
上下文窗口决定模型这一轮能看到什么
上下文窗口可以理解为模型一次请求能够处理的 Token 总量。系统指令、历史消息、当前问题、工具结果以及准备生成的答案都会占空间。
聊天界面看起来一直记得对话，是因为应用通常会在新请求中把历史消息再次发送给模型。模型本身不会替应用永久保存所有聊天记录。对话越来越长后，应用可能截断旧消息、先做摘要，或从外部存储中召回相关内容。
这也解释了一个常见问题：开头写了规则，几十轮以后模型没有遵守。可能不是规则“失效”，而是它已经没被放进当前请求，或者被大量无关内容覆盖。
需要长期保存的信息，应交给数据库、知识库或专门的记忆模块。上下文窗口更像工作台，不是档案室。
Temperature 和 Top P 控制怎么选
候选 Token 有了概率，还要决定如何选择。Temperature 会调整概率分布的平缓程度。数值较低时，高概率候选更占优势，输出通常更稳定；数值升高后，低概率候选更容易被选中，变化也会增加。
Top P 会保留累计概率达到阈值的一组候选，再从中采样。它不是“回答正确率”，也不是越高越好。百炼的文本生成文档建议通常只调整 Temperature 或 Top P 中的一个，避免两个参数一起变化后难以判断原因。
分类、字段提取和固定格式生成更重视稳定，可以从较低随机性开始。头脑风暴或文案变体需要更多差异，再逐步放宽。具体取值要看模型文档和自己的样例结果，不能跨模型照搬。
做一次可重复的小实验
准备一条固定输入：
请把“订单晚到了”改写成一句不超过 30 字的客服回复。
只输出回复内容。
在同一个模型、同一套系统指令下连续调用五次。先用较低 Temperature，保存每次输出；再只提高 Temperature，其他参数保持不变，再调用五次。
检查结果时别只看“哪句更好”，还要记录：
- 五次回答有多少种不同表达；
- 是否都满足 30 字限制；
- 是否擅自承诺退款或赔偿；
- 提高随机性后，格式错误有没有增加。
如果你同时改模型、Prompt、Temperature 和 Top P，最后看到差异也不知道是谁造成的。一次只改一个变量，才能把感觉变成可复查的结果。
你是否真的理解了
可以用四个问题检查：
- 同一文本的 Token 数为什么会随模型变化？
- 聊天产品为什么需要把历史消息重新放进请求？
- Temperature 变高为什么不等于答案更正确？
- 需要长期记住的信息为什么不能只依赖上下文窗口？
能把这四个问题搞清楚，已经足够进入 API 实操。下一篇会把这些概念放进一次真实请求中，同时补上环境变量、异常处理和日志，让调用出错时有东西可查。