02. 你必须真正理解的核心概念 大模型学习（基础篇）

1. Prompt 是什么

Prompt就是你输入给模型的内容。

但在真实系统里，Prompt 往往不是一句话，而是一整组内容的组合，例如：

• system instruction
• 历史消息
• 当前用户问题
• 检索出来的文档片段
• 输出格式约束

一个糟糕的 Prompt

Tell me about Java.

问题：

• 太宽泛
• 没有说明面向谁
• 没有说明要输出什么结构

一个更好的 Prompt

请向一个有 2 年经验的后端开发解释 Java 是什么。 用通俗语言。 包含： 1. Java 的定义 2. 企业为什么常用 Java 3. 一个简单代码例子 总长度控制在 200 字以内。

为什么更好：

• 目标受众明确
• 范围明确
• 输出结构明确
• 长度约束明确

2. System Prompt 和 User Prompt

在 Chat 场景里，消息通常带有角色。

2.1 System Prompt

System Prompt 决定“这个助手整体应该怎么说、怎么做”。

例如：

你是一个 Java 教学助手，解释时要尽量通俗，每次都给出一个小例子，不要使用未解释的术语。

2.2 User Prompt

User Prompt 则是“当前这一轮具体要完成什么任务”。

例如：

解释一下 Spring Boot 的自动配置是什么意思。

2.3 为什么这俩要分开理解

你可以把它理解成：

• system prompt = 这一轮请求里的长期规则
• user prompt = 这一轮请求里的当前任务

这有点像：

• system prompt 决定“这个接口的通用约束”
• user prompt 决定“这次具体传入了什么业务参数”

3. Token 是什么

Token是模型内部处理文本时使用的切分单位。

它不是严格等于：

• 一个字
• 一个单词
• 一个句子

不同 tokenizer 对文本的切法不同。

例如：

• Hello world可能被切成几个 token
• LangChain4j可能会被切成和你直觉不一样的片段
• 中文通常和字符更接近，但也不是绝对一字一 token

为什么你必须关心 Token

Token 会直接影响：

• 成本
• 响应速度
• 上下文窗口占用
• 历史内容是否会被截断

一个实际例子

如果你一次请求里塞了这些东西：

• 很长的 system prompt
• 十几轮聊天历史
• 三段检索文档
• 一个新的用户问题

那么模型在“正式回答前”，已经消耗了一大堆 token 预算。

而回答本身也会继续消耗输出 token。

4. Context Window 是什么

Context Window，上下文窗口，可以简单理解成：

这次请求中，模型一次最多能处理的输入和输出总量。

它更像“这一轮请求的工作记忆”，而不是永久记忆。

如果超出限制，常见结果一般是：

• 请求失败
• 早期消息被裁剪
• 检索内容被缩减
• 输出被截断

一个直观例子

假设你的一次请求里包含：

• 8000 token 的历史消息
• 6000 token 的检索文档
• 500 token 的当前问题

如果你的模型或配置承受不了这么大体量，就必须裁掉一部分内容。

一定要分清

上下文窗口不是记忆系统。

如果产品需要“记住之前说过的话”，通常是应用层在做这些事：

• 重新发送部分历史消息
• 对历史消息做摘要
• 把事实存进数据库后再检索回来

5. Temperature 是什么

Temperature控制生成时的随机性倾向。

你可以先这样理解：

• 温度低：更保守、更稳定、更像固定答法
• 温度高：更发散、更有变化、更像在创作

例子

Prompt：

给一家咖啡店写一句宣传语。

低温度风格可能更像：

新鲜咖啡，用心呈现。

高温度风格可能更像：

让整座城市在一口烘焙香气里醒来。

什么时候适合低温度

• 信息抽取
• 分类
• 事实性总结
• 稳定业务输出

什么时候可以适当高一点

• 头脑风暴
• slogan 生成
• 创意写作
• 需要多个版本时

6. 低温度不等于真

这是初学者非常容易踩的坑。

低温度只能让模型“更稳定地按一种风格输出”，不代表它更知道事实。

如果它本来就不知道某个事实，低温度只是可能让它更稳定地说错。

真正影响真实性的，通常是：

• 有没有可靠上下文
• 有没有做检索
• 有没有调用工具
• 有没有做校验

7. 幻觉是什么

幻觉就是：

模型给出了一段流畅、自然、像真的一样，但其实没有依据或者是错的内容。

例子：

总结一下公司 X 在 2027 年年报里的收入变化。

如果这个年报根本没给它，它也可能照样写出一段“看起来很像分析报告”的话。

常见诱因

• 没有提供源材料
• Prompt 模糊
• 问题涉及变化很快的事实
• 强迫模型必须给出答案

一个更稳的 Prompt 模式

只能基于提供的材料回答。 如果材料中没有答案，就明确说“提供的材料中未找到”。

这不能百分百杜绝幻觉，但会明显降低胡编乱造的概率。

8. Structured Output 为什么重要

很多时候，你根本不想要“一段写得很好看的话”，你要的是可解析、可验证、可落库的结构化数据。

例如：

{"category":"billing","urgency":"high","sentiment":"negative"}

对 Java 系统来说，结构化输出的价值非常大：

• 更容易解析
• 更容易校验
• 更容易进入后续业务流程

9. Prompt 是怎么一步步变好的

版本 1

Analyze this customer message.

太模糊。

版本 2

Analyze this customer message. Tell me the sentiment and urgency.

比刚才好，但仍然偏松。

版本 3

分析下面这条客户消息。 以 JSON 返回，并且只能包含这些字段： - sentiment: positive、neutral、negative - urgency: low、medium、high - summary: 一句话总结 客户消息： I was charged twice and nobody has replied for three days.

这个版本就更接近“可控的业务输入”了。

10. 用 Java 后端思维类比 Prompt

如果你熟悉 REST API，可以这样理解：

差的 API 契约：

• 输入不清楚
• 输出不清楚
• 错误行为不清楚

差的 Prompt：

• 任务不清楚
• 边界不清楚
• 输出格式不清楚

所以 Prompt Engineering 不是什么玄学，它更像是：

为模型设计一个清晰、稳定、可约束的接口契约。

11. 本章结论

• Prompt 质量会直接影响输出质量。
• Token 是成本、延迟、上下文容量的预算单位。
• Context Window 是单次请求的工作记忆，不是永久记忆。
• Temperature 控制随机性，不控制真伪。
• 幻觉是大模型系统的常见风险，必须通过设计来压制。
• 对 Java 项目来说，结构化输出尤其关键。