LLM 如何工作（直觉版）

一句话理解：大模型是一台“一次预测一个 Token”的续写机器；它的聪明、它的不稳定、它的编造，都是从这一个机制里长出来的。

很多产品经理第一次设计 AI 功能时，会不自觉地把模型想象成三种东西之一：一个能查到答案的数据库、一个会上网的搜索引擎，或者一个“什么都懂的实习生”。这三种想象都会带来错误的产品决策：以为它能精确记住公司的价格表，以为它知道昨天发生的事，以为同一个问题问两次答案一定一样。

这一课不碰数学，只建立一个足够准确的直觉。有了它，后面理解 Token 成本、幻觉、结构化输出、推理模型，都会顺理成章。

先看一眼本模块的全景：本课讲的“续写机器”位于中间，其余各课分别讨论它的输入与窗口、调用方式、思考预算、输出约束、幻觉与多模态，以及选型和与程序的分工。

图 1 · 大模型基础全景：一次调用的输入、机制、输出，以及贯穿其中的分工

续写机器：一次只产出一个 Token

大模型做的事情，本质上只有一件：给定前面的所有文字，预测下一个 Token 最可能是什么。

Token 是模型处理文本的最小单位，可能是一个词、半个词、一个汉字或一个标点（下一课 Token 与上下文窗口会细讲）。假设一个客服工单分类 Agent 收到这样一段上文：

工单 #10231 内容：我上周付款的订单到现在还没有发货。该工单的分类是：

模型内部会为“下一个 Token”算出一张概率表，大致像这样（数字仅为示意）：

候选 Token	概率
发货	38%
退款	21%
订单	12%
商品	6%
……	……

选出一个 Token 之后，把它接到上文末尾，再预测下一个，如此循环，直到模型输出“结束”标记或者达到长度上限：

图 2 · 自回归生成：一次一个 Token，循环直到结束

这个循环叫 自回归生成。它直接解释了几个日常现象：

回答是一个字一个字“流”出来的：因为它确实是逐个 Token 生成的，流式输出只是把这个过程实时展示给用户。
输出越长越慢、越贵：每多一个 Token 就多一次计算，输出 Token 的单价通常也比输入高。
说错了很难自己“收回”：已经生成的 Token 会成为后续预测的上文，模型倾向于顺着前面的话继续圆下去。

注意模型预测的是“在这段上文之后，什么样的文字最像是会出现的”，而不是“什么是真的”。多数时候两者一致，这正是模型有用的原因；两者不一致的时候，就出现了幻觉。

训练给了它什么，没给它什么

模型的这张“概率表”是训练出来的，可以粗略分成两个阶段：

预训练：让模型在海量文本上反复练习“猜下一个 Token”。为了猜得准，它被迫学会了语法、常识、推理套路、代码写法，以及大量世界知识的统计规律。
后训练：用指令数据、人类或 AI 的反馈，把一个“什么都续写”的模型调教成一个“听指令、会拒绝、按格式回答”的助手。

由此可以推出三条重要的产品约束：

训练的特点	带来的约束	产品上该怎么办
知识被“压缩”进参数，而不是逐条存储	记得住概念与常识，记不准具体数字、SKU、价格	精确事实通过工具或检索提供，见 RAG 与知识
训练数据有截止日期	不知道截止日期之后的事，也不知道你的内部数据	实时信息交给 API、搜索与数据库
后训练塑造了“助手人格”	倾向于给出一个完整、流畅、自信的回答	在指令里明确允许“不知道”，并设计拒答路径

以 SEO 诊断 Agent 为例：模型“知道”标题标签、Canonical、Core Web Vitals 是什么，也知道常见的排查思路；但它不知道你网站上周的抓取错误数，除非你把 Search Console 的数据通过工具交给它。

采样与温度：为什么同一个问题答案会不同

每一步模型都有一张概率表，接下来要从中“选”一个 Token，这一步叫采样。选法不同，输出风格就不同：

总是选概率最高的：输出稳定但容易呆板、重复。
按概率随机抽取：输出更多样，也更可能走偏。

温度（temperature） 是调节这种随机性的旋钮：温度低，高概率的 Token 更占优势，输出更保守；温度高，概率表被“压平”，低概率 Token 也有机会被选中，输出更发散。top_p、top_k 则是另一类旋钮：只在概率最高的一部分候选里抽取。

同一张概率表在低温度和高温度下的样子，大致如下：

图 3 · 温度改变的是概率表的“形状”（数字仅为示意）

旋钮	直觉	过去常见的用法
低温度	更确定、更保守	抽取、分类、代码
高温度	更多样、更有创意	头脑风暴、文案
top_p / top_k	只从头部候选里挑	砍掉“离谱”的长尾选项

这里有一个必须知道的时效性事实：采样参数正在从新一代模型的 API 中淡出。 以 Claude 为例，从 Claude Opus 4.7 起（包括 Claude Opus 5），把 temperature、top_p 或 top_k 设为非默认值会直接返回 400 错误，官方建议改用提示词来引导模型行为，并特别提醒：即使在旧模型上，temperature = 0 也从来不保证输出完全一致。其他厂商的推理类模型也有各自的参数限制，接入前请查阅对应文档。

所以对产品设计来说，正确的心态是：不要指望靠一个参数换来确定性。 需要稳定时，靠的是清晰的指令、结构化输出、程序校验与评测；需要多样性时，靠的是在提示词里明确要求“给出 5 个风格不同的方案”。

从机制到产品直觉：一张对照表

把前面的机制和你在产品里会遇到的现象连起来：

你观察到的现象	机制上的原因	产品对策
同一个问题，两次回答措辞甚至结论不同	每一步都在采样	关键结论用结构化字段约束；评测时同一用例跑多次
自信地给出一个不存在的订单状态	预测“像真的”，而非“是真的”	事实必须来自工具结果；无数据时要求明确说“查不到”
大数相加、日期推算偶尔出错	数字被切成 Token 处理，不是真正在算	交给计算器或代码执行，见 LLM 与确定性程序的分工
前面一步判断错了，后面越错越远	已生成内容成为后续上文	在 Agent Loop 里加入验证步骤，见初识 Agent Loop
让它“先分析再下结论”效果更好	中间生成的 Token 给了模型更多“计算量”	复杂任务使用推理模型与思考预算
长报告生成很慢、成本很高	逐 Token 生成，输出单价高	控制输出长度，只让模型写必要的部分

回到 Coding Agent 的例子：模型写出一段“看起来完全正确”的代码非常容易，因为它见过无数相似代码；但这段代码能不能跑通，续写机器本身无法保证。这就是为什么 Claude Code、Codex 这类产品都会让 Agent 自己去跑测试——用程序的反馈弥补续写机器的不确定性，这也是整个课程反复出现的主线。

常见误区

“模型记住了训练数据，所以能当知识库用。” 模型记住的是规律，不是条目。越具体、越冷门、越新的事实，越不可靠。
“把温度调成 0，输出就稳定了。” 在很多新模型上这个参数已经不可调；即使可调，也从不保证完全一致。稳定性应该来自格式约束和校验。
“模型会思考，所以它知道自己对不对。” 模型对自身输出的置信度并不可靠，“确认无误”的表述同样是续写出来的。需要外部验证。

产品经理检查清单

评审一个 AI 功能时，先问：

这个功能依赖模型“记得”的哪些事实？这些事实是否应该改由工具或检索提供？
如果同一个输入得到两个不同的输出，用户和下游系统能否接受？
哪些输出需要精确（金额、数量、日期、ID），是否交给了程序处理？
模型输出错误时，有没有机制能在交给用户或执行动作之前发现它？
需求里是否假设了模型知道“最新情况”？数据从哪里来？

练习

用你常用的 AI 产品或 API，完成下面三个小实验（约 40 分钟），每个实验记录输入、输出和你的解释：

随机性：把“为一家做在线协作工具的公司官网写一个 SEO 标题”连续问 5 次，比较差异。
知识边界：问一个你所在公司内部才知道的事实（例如某个 SKU 的价格），观察它是拒答、追问还是编造。
计算：让它直接心算两个 12 位数相乘，再让它“一步一步算”，最后用计算器核对。

最后用一两句话写下：这三个现象分别对应本课哪个机制，你会在产品里如何兜底。

下一步

下一课「Token 与上下文窗口」会把“Token”这个词落到成本、长度限制和“模型此刻到底能看到什么”上。

LLM 如何工作（直觉版）