LLM、Token、Prompt 与 Context

很多 AI 术语单独看都不难，但一放进真实链路里，就很容易开始混。

最常见的几个混法其实就这几种：

1. 把 LLM 理解成“什么都知道”的系统
2. 把 Token 理解成简单字数
3. 把 Prompt 理解成模型看到的全部输入
4. 把 Context 理解成和 Prompt 完全一样的东西

这一篇只盯这 4 个词：顺着一条最小生成链路，把它们各自的能力、使用场景和边界讲清楚。

1. 一条最小生成链路

可以把一次最普通的模型调用理解成这样：

flowchart LR
    A[业务目标] --> B[写 Prompt]
    B --> C[拼完整 Context]
    C --> D[切成 Token]
    D --> E[LLM 生成输出]

这条线看起来简单，后面很多 AI 工程问题其实都能落回这几个环节：

1. 模型为什么不理解任务
2. 成本为什么突然变高
3. 历史消息为什么把答案带偏
4. 为什么明明提示词写了要求，结果还是不稳定

所以这 4 个词不是孤零零的名词，而是一条主线上的不同层次。

2. LLM 是什么

LLM 是 Large Language Model，通常翻成“大语言模型”。

一句话看：

一个根据已有上下文继续生成最可能输出的模型。

单看这句话会有点抽象，放到能力上就好懂了。

2.1 LLM 具备哪些能力

它常见的能力包括：

1. 理解自然语言输入
2. 生成连续文本
3. 对已有材料做总结、改写和归纳
4. 在一定范围内完成推理、分类、抽取和判断

所以在项目里，LLM 很适合拿来做：

1. 问答
2. 摘要
3. 信息抽取
4. 文本改写
5. 基于上下文的分析和生成

2.2 LLM 不擅长什么

这里的边界比定义更重要。

LLM 并不天然知道：

1. 你的实时业务数据
2. 你的私有文档
3. 外部系统当前状态
4. 某次工具调用之后的最新结果

它不是天然连着数据库、搜索引擎和业务系统的。

这也是为什么后面才会需要：

1. RAG
2. Tool Calling
3. Workflow
4. Agent

它们本质上都不是在替代模型，而是在补模型和外部世界之间的鸿沟。

2.3 真实场景里怎么理解 LLM

可以拿一个常见场景来想：

如果你让模型“解释一下 Redis 持久化”，它通常能给出一版还不错的通用答案； 但如果你问“我们生产环境里为什么昨天那次缓存恢复不完整”，这时候它就不再只靠参数里的知识够用了，而是需要外部日志、配置、监控和业务上下文。

一句话压缩：

LLM 擅长基于上下文生成和推理，不擅长凭空知道系统外部的实时事实。`

3. Token 是什么

Token 可以理解成模型处理文本时的基本单位。

它既不是“一个字”，也不等于“一个单词”，更像模型切分后的计算片段。

例如一句很短的话，在模型内部往往会被拆成多个 Token。中文、英文、数字、符号的切分方式也不完全一样。

3.1 为什么 Token 这么重要

因为它不只是内部实现细节，它会直接影响：

1. 上下文长度上限
2. 成本
3. 延迟
4. 截断风险

举个很常见的工程问题：

你觉得自己只是多拼了几段资料，但在模型眼里，可能已经多塞进去了几千个 Token。结果就是：

1. 请求更贵
2. 返回更慢
3. 旧对话或新资料被截断
4. 输出开始偏题

3.2 Token 最常出现在哪些场景

Token 这个词通常会频繁出现在这些场景里：

1. 长对话上下文管理
2. RAG 上下文拼接
3. Prompt 调优
4. 成本统计
5. 延迟优化

也就是说，你一旦开始认真做工程落地，几乎不可能绕开它。

3.3 Token 最容易被误解成什么

最常见的误解是：

1. 以为它只是计费单位
2. 以为它只和“贵不贵”有关
3. 以为上下文问题和 Token 没关系

其实很多“模型没答全”“资料没带进去”“对话突然失忆”的问题，最后都和 Token 长度管理直接相关。

🌟 很多时候，不是模型没能力，而是你想给它的材料根本没完整塞进去。

4. Prompt 是什么

Prompt 可以看成：

你为了让模型完成某个任务，主动组织出来的输入内容。

它不只是“提一个问题”，更像是你把任务交给模型的方式。

一个更完整的 Prompt，通常会包含：

1. 角色设定
2. 任务目标
3. 输入数据
4. 输出要求
5. 必要时的示例

例如：

你是一名售后助手。
请根据用户问题判断属于退款、物流还是产品咨询。
只返回 JSON，字段包括 category 和 reason。

这已经不是单纯的提问，而是在明确：

1. 模型该扮演什么角色
2. 要完成什么任务
3. 输出应该长什么样

4.1 Prompt 在项目里主要解决什么问题

它最核心的作用不是“让模型变聪明”，而是：

让模型更准确地理解当前这次任务。

所以项目里 Prompt 常常会承担这些职责：

1. 定义任务边界
2. 收紧输出格式
3. 约束回答风格
4. 提醒模型注意某些业务规则

4.2 Prompt 常见场景

Prompt 最常见的使用场景包括：

1. 问答和解释
2. 分类和抽取
3. 结构化输出
4. 工具调用约束
5. RAG 场景里的回答指令

也就是说，只要系统在用模型，就一定绕不开 Prompt。

4.3 Prompt 的边界是什么

它能组织任务，但不能凭空补充：

1. 实时知识
2. 私有业务数据
3. 外部系统状态

所以它更像“任务组织层”，不是“知识来源层”。

4.4 Prompt 最容易踩的坑

最常见的坑有：

1. 以为写得越长越好
2. 以为只要语气严厉就更稳定
3. 以为 Prompt 能替代外部知识和流程治理

很多时候问题不在于它写得不够长，而在于：

1. 任务目标没写清
2. 输出要求不够明确
3. 上下文材料太乱
4. 模型根本缺外部知识

5. Context 是什么

Context 可以理解成：

模型在当前这一轮生成时，真正拿到的全部上下文材料。

这一定义比 Prompt 更大。

因为模型真正看到的往往不只有你手写的那段 Prompt，还可能包括：

1. 系统提示
2. 用户输入
3. 历史对话
4. 检索结果
5. 工具返回值

5.1 为什么 Context 比 Prompt 更重要

因为最终影响模型输出的，通常不是某一句 Prompt 单独写得好不好，而是整份 Context 最后长成什么样。

看一个很典型的结构：

flowchart TD
    A[系统提示] --> E[最终 Context]
    B[用户问题] --> E
    C[历史消息] --> E
    D[RAG 检索结果 / Tool 结果] --> E

这时用户看到的可能只是当前问题，但模型处理的却是完整 Context。

5.2 Context 在项目里主要解决什么问题

它决定的是：

1. 模型这一轮到底知道什么
2. 模型要优先参考哪些材料
3. 历史对话和外部资料会不会相互干扰

很多链路设计，本质上都在处理 Context：

1. 多轮对话记忆
2. RAG 检索结果拼接
3. 工具调用结果回灌
4. 长上下文裁剪

5.3 Context 最容易踩的坑

最常见的问题其实不是“没有上下文”，而是“上下文太多但太乱”。

例如：

1. 历史消息过长
2. 检索结果相关性不够
3. 工具结果太啰嗦
4. 多种来源内容互相打架

这时你会感觉模型“忽好忽坏”，但根子很可能不是模型本身，而是 Context 组织失控了。

6. 把这 4 个词放到一起看

可以再回到最前面的那条主线：

flowchart LR
    A[任务目标] --> B[写 Prompt]
    B --> C[拼出完整 Context]
    C --> D[切成 Token]
    D --> E[LLM 生成输出]

把这条线拆开看会更清楚：

1. Prompt 负责把任务说清楚
2. Context 负责把本轮该带进去的材料拼完整
3. Token 负责把这些内容变成模型可处理的单位
4. LLM 负责基于这些输入生成结果

后面很多工程问题，本质上都可以往这 4 层回溯。

7. 真实项目里最常见的几个误区

7.1 只改 Prompt，不看 Context

很多时候你以为在调提示词，实际上真正影响结果的可能是：

1. 历史消息太长
2. 检索结果太乱
3. 工具返回内容把上下文挤满了

7.2 只看模型名，不看 Token 规模

同样一条链路里：

1. 上下文越长，成本通常越高
2. 上下文越长，延迟通常也越高
3. 上下文越乱，模型越容易偏题

7.3 把 LLM 当成外部世界的事实源

模型能总结、能归纳、能生成，但它并不会天然知道：

1. 你数据库里的最新数据
2. 你的内部文档刚刚更新了什么
3. 刚才那次工具调用的真实结果

这也是为什么后面还需要 RAG、Tool、Workflow 和 Agent。

8. 一段更稳的总结

如果把这 4 个词压成一句话，可以记成：

LLM 是负责基于上下文生成结果的模型，Token 是模型处理输入和输出的基本单位，Prompt 是你组织任务的方式，Context 是模型这一轮真正拿到的全部材料。后面很多 AI 工程问题，本质上都不是单个词没背下来，而是没有把这 4 层放回同一条链路里理解。