一个 AI 应用工程师的日常，看起来就是一行代码：把提示词发给 API，拿回一段文本。但这一行代码里藏着四五个旋钮，绝大多数人从头到尾没拧过，只是用了默认值。架构师和工程师的第一个分水岭就在这里：你能不能说出每个旋钮拧动时，模型内部发生了什么。
token：模型眼中的「字」不是字
模型读的不是汉字或单词，而是 token——把文本切成的小片段，每个片段对应词表里的一个编号。切法很务实：常见词整个算一个 token，生僻词拆成几块。英文里 unbelievable 可能被切成 un、believ、able 三段；中文里一个汉字通常占一到两个 token。
为什么工程师必须在乎这个？因为计费、限速、窗口长度，全都按 token 算，不按字算。你估算成本时用「这段文字大概三百字」是错的；而且切分有反直觉的后果：模型做算术差，部分原因就是「12345」可能被切成奇怪的几段，它从没把「12345」当成一个整体数字见过。
大白话：token 是模型的「像素」。你看的是一张图，它看的是一格一格的色块。账也是按色块算的。
上下文窗口：一块会计费的桌面
上下文窗口（context window）是模型一次能看到的全部文本——你的系统提示、对话历史、塞进去的资料，加起来不能超过这个上限。它是模型唯一的工作记忆：窗口之外的东西，模型一个字都不知道。
两个工程后果常被忽视。第一，窗口大不等于用得好：塞进二十万字，模型对中间部分的注意力会变稀，答案质量常常反而下降，这就是所谓的「迷失在中间」现象。第二，窗口里的每个 token 每次请求都要重新付一遍钱。多轮对话里历史越滚越长，如果不做裁剪，第十轮对话的成本可能是第一轮的十倍。
温度：不是「创造力」，是「掷骰子的歪斜程度」
模型生成文本的方式，本质是每一步算出下一个 token 的概率分布，然后从中抽样。温度（temperature）拧的是这个分布的形状：温度低，概率最高的那几个 token 几乎垄断选择权，输出稳定、趋同；温度高，长尾上的怪词也有机会被抽中，输出多变、也容易跑偏。
大白话：温度不是「聪明程度」也不是「创造力」，是骰子的公平程度。温度 0 像灌了铅的骰子，永远落在最可能的选项上。
工程含义很直接：凡是要进程序、要被解析的输出，温度调低——你要的是可重复，不是惊喜。文案头脑风暴可以调高。线上事故里有一大类，就是有人把温度留在默认值，结果同样的输入昨天能解析、今天解析炸了。
结构化输出：把「求你了」变成「保证」
应用工程师最常干的事是让模型输出 JSON 给程序用。早年的做法是提示词里写「请只输出 JSON，不要别的」——这是请求，不是保证，模型随时可能送你一句「好的，以下是结果：」然后整个解析器崩溃。
现在的主流 API 提供 结构化输出（structured output）：你把 JSON Schema 传给接口，模型在生成时被约束解码——每走一步，不允许出现在语法上走不通的 token 会被直接屏蔽。这不是「模型更听话了」，而是采样时被硬约束在合法空间里，格式错误从物理上不可能发生。
架构上的意义：可靠性问题一旦能被机制保证，就不要靠提示词祈祷。这条原则在第七章还会回来。
这一章的账
回头看，一次调用里真正属于你的决策有：塞多少上下文（成本与质量的权衡）、温度定多少（稳定性与多样性的权衡）、用什么输出约束（祈祷与保证的权衡）。把这三个权衡说清楚，你就已经超过大多数「会调 API」的人了。
但旋钮拧得再好，提示词本身写得一团糟也没用。下一章的问题是：提示词到底是个什么东西？答案是——它不是咒语，是一份接口契约。