AI 学习笔记（三）：Token、上下文窗口和 Temperature，为什么同一个问题答案会变
上一篇聊了 Prompt Engineering，本质是在“把需求说清楚”。
这一篇继续补三块最常见、也最容易被误解的基础概念：Token、上下文窗口（Context Window） 和 Temperature。
很多时候我们会遇到这种情况：
- 明明是同一个问题，模型每次回答差异很大
- 对话聊到后面，模型开始“忘事”
- 成本突然升高，但效果没有明显变好
背后通常都和这三个参数直接相关。
1. Token：模型真正“看见”的文本单位
先说结论：模型不是按“字”或“词”计数，而是按 Token 计数。
你输入的提示词、系统指令、历史对话、模型输出，都会被切成 Token。
计费通常按输入 Token 和输出 Token 分开计算。
1.1 为什么开发者要关心 Token
主要有三个原因：
- 影响成本：Token 越多，调用越贵。
- 影响速度：上下文过长时，响应会明显变慢。
- 影响可控性：冗长上下文容易让模型抓不住重点。
1.2 实战建议
- 不要把无关日志、无关文档整段喂给模型。
- 优先给“任务相关的最小上下文”。
- 对重复性调用，抽出稳定模板，减少无效描述。
一句话总结：Token 是成本和延迟的第一控制杆。
2. 上下文窗口：模型“短期工作记忆”的上限
上下文窗口可以理解为：一次请求里，模型最多能处理的 Token 总量。
这个总量包括：
- 系统提示词
- 用户输入
- 历史对话
- 模型即将输出的内容（预留空间）
如果你把窗口塞满，会出现两类问题：
- 新内容进不去（请求报错或被截断）
- 旧内容被挤掉（你感觉它“失忆”了）
2.1 为什么“聊久了变笨”
并不一定是模型能力变差，而是历史对话过长后，真正关键的信息被冲淡或被截断。
尤其是 debug/需求澄清类任务，如果没有阶段性总结，后面很容易跑偏。
2.2 实战建议
- 长对话按阶段做“摘要回填”：把阶段结论压缩后继续。
- 把规范、约束放在系统提示词或固定模板里，减少重复堆叠。
- 给输出留预算，比如限制“最多输出 N 点”或“先给大纲再展开”。
一句话总结：上下文窗口决定你能让模型“记住多少事”。
3. Temperature：控制输出的“发散度”
Temperature 不是“聪明度开关”，而是控制采样随机性的参数。
可以粗略理解为：
- 低 Temperature（如 0~0.3）：更稳定、更保守、复现性更高
- 中 Temperature（如 0.4~0.7）：兼顾稳定与表达变化
- 高 Temperature（如 0.8+）：更发散、更有创意，但更不稳定
3.1 常见误区
- 误区 1：Temperature 越高答案越“高级”
实际上高温更容易跑题或出现不一致细节。 - 误区 2：所有任务都用同一温度
不同任务目标完全不同，参数应随场景调整。
3.2 任务场景建议
- 写代码、生成 SQL、改配置、技术排障：
0~0.3 - 方案讨论、文案润色、头脑风暴：
0.5~0.8 - 需要严格一致输出的自动化流程：尽量低温 + 固定输出格式
一句话总结：Temperature 决定“稳定优先”还是“创意优先”。
4. 三者如何一起影响结果
可以把它们看成一个组合控制面板：
Token：你花多少钱、请求有多重上下文窗口：模型能带着多少历史信息继续思考Temperature：结果是偏稳定还是偏发散
很多“模型不稳定”的问题，最终不是换模型解决，而是：
- 输入太长、重点不清
- 上下文管理混乱
- 参数策略和任务目标不匹配
5. 一个可直接套用的调用策略
如果你在做工程化接入，可以先用这个默认策略起步：
- 先定义任务类型：结构化任务 or 创意任务。
- 结构化任务用低温（0~0.3），并强制输出格式。
- 每轮对话控制上下文长度，必要时做摘要压缩。
- 监控输入/输出 Token，观察成本和耗时变化。
- 根据失败样本迭代提示词，而不是盲目加上下文。
这套做法不花哨，但在项目里稳定且可复用。
总结
Token、上下文窗口、Temperature 是大模型调用里最基础的三个控制点。
理解它们后，你会更容易判断：
- 问题出在提示词、上下文管理，还是采样参数
- 为什么同一模型在不同人手里表现差异很大
- 如何在效果、成本、速度之间做工程化权衡
下一步会进入更实操的一层：从聊天到 API，如何把这些策略落到真实代码里。
如果你刚开始做 AI 接入，先把这三个参数跑通，比盲目追新模型更重要。
下一篇：用 OpenAI API 做一个最小可用的结构化输出示例
本文永久链接: https://www.mulianju.com/learning-notes/ai-learning-notes-token-context-window-temperature/