04 · Prompt 与采样参数：怎么让模型听话

学完你能说出：

• 一次对话里的 system / user / assistant 三种角色分别是干什么的。
• 几种常用提示技巧（给角色、给例子、让它一步步想、规定输出格式）为什么有效。
• 温度（Temperature）和 Top-p 在控制什么，什么场景调高、什么场景调低。
• 上下文窗口是什么，超了会怎样。

先看地图

第 01 篇说模型在「接龙」，每一步都要「选一个 Token」。这一篇讲两件事： ① 怎么给它好的开头（Prompt），以及 ② 选 Token 时怎么选（采样参数）。

本篇讲 4 个点：① 消息的三种角色 → ② 四个提示技巧 → ③ 温度和 Top-p → ④ 上下文窗口。

一句话本质

Prompt（提示词）= 给接龙写的开头。开头写得越清楚，接出来的内容越符合预期。

生活类比：给新来的实习生派活

• 只说「写个总结」，他交上来的东西大概率不合心意。
• 说清楚「你是运营助理（角色）；按这个范例的格式写（例子）；先列要点再写正文（步骤）；输出 3 条，每条不超过 20 字（格式）」，交上来的就靠谱多了。

大模型也一样：它不会读心，只会顺着你给的开头往下接。

一步步看

1. 三种角色

调用大模型 API 时，发过去的是一个消息列表：

[system]    你是一个简洁的面试辅导助手，回答不超过 100 字。     ← 规则、人设，整场对话都生效
[user]      什么是进程？                                       ← 用户说的话
[assistant] 进程是正在运行的程序及其资源……                     ← 模型之前的回答
[user]      那线程呢？                                         ← 新问题

模型其实没有记忆：每次调用，程序都把整段历史重新发一遍，模型再接着往下写。所谓「多轮对话」，就是每轮把之前的记录都带上。

2. 四个常用技巧

技巧	写法示例	为什么有效
给角色	「你是资深面试官」	把接龙引向某一类文本的风格和深度
给例子（Few-shot，少样本示例）	先给 2 个「问题 → 标准答案」的例子	模型照着例子的格式和长度去接
一步步想（CoT，思维链）	「先列出推理步骤，再给结论」	把中间步骤写出来，后面的 Token 能「看到」前面的推理，复杂题更容易做对
规定输出格式	「只输出 JSON：{"answer": ..., "source": ...}」	方便程序解析，也减少废话

3. 温度和 Top-p：选 Token 时的「随机程度」

还用第 01 篇的例子，「今天天气」后面候选的概率是：

候选	原始概率	温度低（如 0.2）时	温度高（如 1.5）时
真	0.45	接近 1，几乎必选	降一些
很	0.30	很小	升一些
怎么	0.15	很小	升一些
其他	0.10	接近 0	明显升高

（右边两列只表示变化方向，不是精确数值。）

• 温度（Temperature）：把概率分布「压尖」或「摊平」。
  • 低温：几乎总选最高的那个，输出稳定、可复现，适合问答、写代码、抽取信息。
  • 高温：冷门选项也有机会，输出更多样，适合头脑风暴、写文案。
• Top-p（核采样）：只在「累计概率达到 p 的那几个候选」里选。例如 p = 0.8：真 0.45 + 很 0.30 = 0.75 还不够 0.8，再加上「怎么」到 0.90，于是只在这 3 个里选，其他全部排除。作用是砍掉长尾里的离谱选项。

4. 上下文窗口

上下文窗口（Context Window） = 模型一次最多能「看」多少 Token，输入和输出加在一起算。

• 超了会怎样：API 直接报错，或者程序得把最早的对话删掉，模型就「忘了」前面说过的话。
• 所以长对话、长文档要做取舍：做摘要、只放相关片段（这就是 RAG 的思路）。

为什么这么设计

为什么要分 system 和 user？

• 问题：如果规则和用户输入混在一起，用户一句「忽略上面的要求」就可能把规则冲掉；开发者也不好统一管理人设。
• 方案：把开发者定的规则单独放进 system 消息，模型在训练时被教会更重视它。
• 好处：规则和用户内容分层，人设稳定、更好维护。（注意：这只是「更重视」，不是绝对安全，见 Agent 安全篇。）

一句话答法

system 放开发者的规则和人设，user 放用户输入，分层后模型更遵守规则，也方便统一管理；但它不能完全防住提示注入。

为什么「让它一步步想」能提高正确率？

• 问题：模型是一个 Token 一个 Token 生成的。直接让它报答案，相当于要求一步算出复杂结果。
• 方案：让它先把中间步骤写出来。
• 好处：写出来的步骤成了后续 Token 的「上下文」，等于给自己打草稿。多步推理、算术题的正确率明显上升。代价是输出更长、更慢、更贵。

一句话答法

因为生成是逐 Token 的，把推理过程写出来相当于打草稿，后面的结论能参考前面的步骤，复杂问题更容易做对；代价是输出更长。

为什么需要温度这个参数？

• 问题：总选概率最高的词，输出会死板、重复；完全随机，又会胡言乱语。不同任务需要的随机程度不一样。
• 方案：用温度这一个旋钮，控制概率分布是变尖还是变平。
• 好处：同一个模型，既能稳定地答题，也能发散地写创意。

一句话答法

温度控制采样的随机性：低温输出稳定、适合事实类任务；高温输出多样、适合创意类任务。

英文术语拆解

术语	拆开看	一句话意思
Prompt	提示	给模型的输入，即接龙的开头
System / User / Assistant	系统 / 用户 / 助手	消息的三种角色：规则 / 用户输入 / 模型回答
Few-shot	few 少量 + shot 一次尝试	在提示里放几个示例
Zero-shot	zero 零 + shot	不给示例，直接提问
CoT	Chain 链 + of + Thought 思考	思维链：先写推理步骤再给结论
Temperature	温度	控制随机程度的参数
Top-p	top 最前面的 + p 概率	只在累计概率达到 p 的候选里抽
Context Window	context 上下文 + window 窗口	一次能处理的最大 Token 数

面试怎么问

Q：temperature 和 top-p 有什么区别？

温度通过缩放 logits（未归一化的分数）改变整个概率分布的陡峭程度；top-p 是截断，只保留累计概率达到 p 的候选再采样。一般只调其中一个。事实类任务用低温，创意类任务用高温。

Q：怎么让模型稳定输出 JSON？

在 system 里规定格式，并给出示例；温度调低；如果 API 支持结构化输出或 JSON 模式就打开；程序端一定要做解析校验，失败就重试或修复。

Q：多轮对话里，模型怎么「记住」前面的内容？

模型本身没有状态，是应用每次把历史消息一起发过去。历史太长会超出上下文窗口，常用做法是截断最早的轮次、对历史做摘要，或者把长期信息存到外部，需要时再检索。

容易混的地方

• 温度 0 也不一定每次完全一样：服务端的并行计算等因素可能带来细微差异。「温度 0 更稳定」是对的，说「绝对确定」不严谨。
• 上下文窗口包括输出：输入占满了，就没有空间输出了。
• Prompt 写得越长越好 ✗：无关内容会分散注意力、增加成本。清楚比长重要。

和其他知识的连接

• ← 来自 大模型在做什么：「选一个 Token」就是采样参数在管。
• ← 来自 注意力与 Transformer：上下文窗口有上限，根源在注意力的平方计算量。
• → 影响 RAG 是什么：把查到的资料拼进 Prompt，就是 RAG。
• → 影响 工具调用：工具说明也是写进 Prompt（或专门字段）里告诉模型的。

自测 3 问

Q1：多轮对话中，模型自己有记忆吗？

点开看答案

没有。每次调用，应用都把之前的消息记录重新发给模型。历史太长会超出上下文窗口，就要截断或做摘要。

Q2：Top-p = 0.8，候选概率是 0.45、0.30、0.15、0.10，会在哪几个里面选？

点开看答案

按概率从高到低累加：0.45 → 0.75（还不到 0.8）→ 0.90（够了）。所以在前 3 个里选，最后那个 0.10 被排除。

Q3：写代码、做信息抽取时，温度应该调高还是调低？为什么？

点开看答案

调低。这类任务要准确、稳定、可复现，低温让模型几乎总选最可能的 Token，减少随机发挥。

✅ 验收清单

• 能说出 system / user / assistant 三种角色的作用
• 能解释「多轮对话的记忆」其实是每次重发历史
• 能举例说明 Few-shot、CoT、规定输出格式各自为什么有效
• 能手算一个 Top-p 的例子，并说清温度高低分别适合什么任务
• 能说出上下文窗口包含哪些内容，超出后常见的处理办法

下一步该懂什么

• 模型不知道你公司的资料，怎么办？→ RAG：先查资料再回答
• 想让模型「动手」调用工具？先把 RAG 学完，再看 Agent 是什么