14个AI术语扫盲（二）：Prompt、RAG、CoT——用好LLM的实战核心概念
约 3,800 字 | 预计阅读 14 分钟 | 系列第 2/5 篇
产品经理小林花了三天写了一份产品需求文档，决定用 GPT-5 润色。她输入：「帮我把这个文档写得更好一点。」
GPT-5 返回的版本把所有技术术语都删掉了，行文变成了小红书风格。小林气得在群里吐槽：「这模型根本不懂产品。」
不是模型不懂产品——是她没告诉模型她想要什么。
LLM 不是读心术。你给它模糊的输入，它就给你模糊的输出。本篇要讲的 14 个概念，核心只有一句话：如何让模型听懂你的人话，并且说真话。
读这篇文章你会得到：
- Prompt 的本质不是「指令」，理解这一点你的 Prompt 质量会跃升一个层次
- RAG 是当前性价比最高的幻觉解决方案——但 80% 的人做错了第一步
- CoT、Few-shot、Function Calling 不是高级技巧，它们是 LLM 的「基础操作系统」
目录
- Prompt 的本质：你不是在下命令，你是在写「前缀」
- Prompt Engineering 的四个核心杠杆
- Few-shot、Zero-shot、In-context Learning：不给例子 vs 给例子
- CoT：让模型「说出思考过程」为什么有效
- RAG：给模型配一个「资料库」
- Vector Database、Embedding、Chunking：RAG 的三根支柱
- Function Calling / Tool Use：让模型「动手」
- 术语速查表
- FAQ
- 结语
1. Prompt 的本质：你不是在下命令，你是在写「前缀」 {#1}
这句话在第一篇说过，但值得单独展开——LLM 的本质是「给定前缀，预测下一个 Token」。
这意味着什么？意味着Prompt 不是指令，它是上下文前缀。你输入「把这段话翻译成英文」，模型不是「理解并执行」这个指令——它是在根据海量训练数据判断：「在我见过的所有文本里，这段话后面，最常出现的是对应的英文翻译。」
System Prompt（系统提示词）vs User Prompt（用户提示词）：System Prompt 设定模型的「人设」和约束——「你是一个严谨的技术文档写手，不要使用比喻，不要添加主观评价」。User Prompt 是具体任务。System Prompt 的优先级通常高于 User Prompt——这就是为什么你可以用 System Prompt 限制模型不乱说话。
Prompt Template（提示词模板）是预置的 Prompt 结构，把变量部分留空。比如「请用{风格}风格，以{角色}的身份，写一篇关于{主题}的{文体}」。模板的价值不是省时间，是保证每次的 Prompt 结构一致——在批量生产中，一致性的重要性远超单次的灵光一现。
Token Limit / Max Tokens（Token 上限）是模型单次能输出的最大 Token 数。注意区分——Context Window 限制的是「输入 + 输出」的总量；Max Tokens 只限制输出。如果你设置 Max Tokens = 500，模型写到 500 个 Token 就戛然而止，哪怕话还没说完。
2. Prompt Engineering 的四个核心杠杆 {#2}
Prompt Engineering（提示词工程）不是「会写 Prompt」——它是系统性地设计、测试和迭代 Prompt 以提高输出质量和可靠性的工程实践。之所以叫「工程」，是因为好的 Prompt 需要像代码一样版本管理、A/B 测试、持续优化。
四个核心杠杆，按重要性排序：
杠杆一：角色设定（Role Prompting）
「你是一个有 10 年经验的 Python 架构师」——这句话不是心理安慰，它会真实改变模型的输出分布。为什么？因为训练数据中，「架构师写的代码」和「普通程序员写的代码」的模式不同，模型会采样到不同的区域。
杠杆二：输出格式约束
「返回 JSON 格式，字段包括 name、reason、confidence_score」——这比任何「请认真回答」都有用。格式约束 = 缩小采样空间 = 减少不确定性。不确定性越低，幻觉越少。
杠杆三：分步指令
把「写一篇技术方案」拆成「第一步：列出核心需求；第二步：给出三个可选架构；第三步：对每个架构做优缺点分析」。分步指令让模型从「一篇写到底」变成「每步聚焦一个子任务」——每步子任务的 Context Window 利用率更高。
杠杆四：负面约束
「不要使用’首先’‘其次’'最后’这类过渡词」「不要写超过 50 字的段落」。告诉模型不该做什么，和告诉它该做什么同样重要。负面约束在抑制幻觉和格式错误时尤其有效。
Prompt Engineering 的第一原则：你不是在「说服」模型，你是在「缩小它的采样空间」。每一次约束——角色、格式、步骤、负面指令——都是在概率分布上划一道边界。
3. Few-shot、Zero-shot、In-context Learning：不给例子 vs 给例子 {#3}
Zero-shot（零样本）：不给示例，直接描述任务。「将以下文本分类为正面、负面或中性：{文本}」。模型仅靠预训练阶段学到的能力完成任务。
Few-shot（少样本）：在 Prompt 里给出 2-5 个示例。「示例1：文本：‘很棒’ → 正面。示例2：‘很烂’ → 负面。现在分类：‘还行’ → ？」模型从示例中「学会」了任务格式和预期输出。
In-context Learning（上下文学习）是 Few-shot 的底层机制——模型不是真的从示例中「学习」，而是在上下文中找到了与示例匹配的模式。关键区别：In-context Learning 不更新模型参数，所有「学习」在推理时发生，对话结束就消失。这和 Fine-tuning 有本质区别——下篇详讲。
为什么 Few-shot 有效？一篇经典论文（Brown et al., 2020）发现，GPT-3 在 Few-shot 设置下的表现可以接近甚至超过专门微调的模型——而它从未被训练过这个任务。Few-shot 的本质是「用示例做锚定」：模型看到你给的输出格式和风格，就会在该方向上继续生成。
Few-shot 的陷阱：示例越多不总是越好。超过 8-10 个示例后，边际收益急剧下降。而且示例的顺序会影响结果——这叫Order Sensitivity（顺序敏感性），目前没有完美的解决方案。
| 模式 | 示例数 | 适用场景 | 局限 |
|---|---|---|---|
| Zero-shot | 0 | 简单分类、通用知识问答 | 复杂任务表现差 |
| Few-shot | 2-5 | 格式敏感任务、风格模仿、小众领域 | 占 Token，顺序敏感 |
| Many-shot | 10+ | 极复杂模式、高度定制输出 | 边际收益递减，可能混淆 |
4. CoT：让模型「说出思考过程」为什么有效 {#4}
CoT（Chain-of-Thought，思维链）是目前最简单、最有效的 Prompt 技巧之一。做法是：在 Prompt 里加一句「让我们一步步思考」（Let’s think step by step），或者给一个展示推理过程的示例。
为什么有效？回到第一篇的核心原理——LLM 是一个「逐 Token 预测」系统。当你要求模型直接给出答案时，它只有一个 Token 的机会——答对就答对，答错就没救。但当你要求它一步步推理时，每一步的 Token 都为下一步提供了更准确的上下文前缀——推理链越长，每一步的「前缀」越精准，最终答案越可靠。
CTO 老王不信这个邪。他说：「加一句话就能提高准确率？这是玄学。」于是他让团队做了一个对照实验——同样的 100 道数学推理题，不加 CoT 准确率 43%，加一句「Let’s think step by step」飙到 78%。「我信了，」他说，「这他妈不是玄学，这是统计学。」
CoT 的变体：
- Zero-shot CoT：只加「让我们一步步思考」，不给示例。简单高效，适合大多数场景。
- Few-shot CoT：给出 2-3 个带推理过程的示例。效果更好，但更占 Token。
- Self-Consistency：跑多次 CoT，取多数答案。CoT 的随机性 ≠ 错误——多次采样 + 投票能让准确率再提升 10-20%。
- Tree-of-Thought（ToT）：每一步探索多个分支，评估后选最优路径。效果最好，但 Token 消耗爆炸。
什么时候该用 CoT？数学推理、逻辑推理、多步骤分析——一定用。简单事实查询、情感分类——没必要，浪费 Token。
5. RAG：给模型配一个「资料库」 {#5}
RAG（Retrieval-Augmented Generation，检索增强生成）是当前业界性价比最高的幻觉对抗方案。核心思路一句话：不要让模型「回忆」答案——先检索相关文档，让模型「阅读」后再回答。
为什么出现？LLM 有两个致命限制：① 知识截止于训练日期，训练后发生的事情一概不知；② Hallucination，模型会自信地编造不存在的事实。RAG 同时缓解了这两个问题——让模型基于你提供的真实文档回答，而不是基于它模糊的记忆。
RAG 的工作流程：
用户提问 → 将问题转成向量 → 在向量数据库中检索最相似文档 → 将检索到的文档片段 + 原始问题一起发给 LLM → LLM 基于文档生成回答为什么 RAG 有效？它把 LLM 的角色从「事实数据库」变成了「阅读理解器」——后者是 LLM 真正擅长的。
RAG 的秘诀不在检索，在分块。分块策略错了——块太大检索不准，块太小语义丢失——后面全错。这不是一个工程决策，这是整个系统的命运转折点。
RAG vs Fine-tuning 的关键区别：RAG 解决「知识更新」问题——给模型外部知识，不改变模型本身。Fine-tuning 解决「行为改变」问题——改变模型的内在能力或风格。实践中，两者常组合使用：Fine-tuning 模型让它学会「如何引用文档」，RAG 提供「要引用的文档」。
6. Vector Database、Embedding、Chunking：RAG 的三根支柱 {#6}
Embedding Model（嵌入模型）
第一篇讲过 Embedding 是什么——把文本变成向量。但在 RAG 语境下，Embedding Model 是一个专门的模型，它的任务不是生成文本，而是把文本映射成语义向量。常用的有 OpenAI 的text-embedding-3、BGE、Jina 等。
选择 Embedding Model 的核心指标：MTEB 基准分（越高越好）、最大输入长度（决定了单次能 Embed 多大的文本块）、向量维度（越高表达能力越强，但存储和检索越贵）。
Vector Database（向量数据库）
向量数据库是专门存储和检索高维向量的数据库。它不按「字段值」查询，而是按「向量距离」查询——「找出与这个向量最相似的 5 个向量」。常用的有 Pinecone、Weaviate、Milvus、Qdrant。
为什么需要专门的向量数据库？传统数据库用 B-Tree 索引，在高维向量上效率极低（「维度灾难」）。向量数据库用近似最近邻（ANN）算法，如 HNSW——在亿级向量中做毫秒级相似检索。
Chunking（文本分块）
Chunking 是 RAG 系统中最被低估的环节。它决定了检索质量的下限。
将文档切分成适当大小的「块」，每个块被 Embedding 成一个向量存入向量数据库。当用户提问时，系统检索最相关的 N 个块作为上下文。
Chunking 的核心权衡：
| 分块策略 | 优点 | 缺点 |
|---|---|---|
| 小块（128-256 Token） | 检索精准，上下文干净 | 可能切断完整语义 |
| 大块（512-1024 Token） | 语义完整 | 检索噪音大，相关性低 |
| 重叠分块 | 防止语义边界断裂 | 存储冗余 |
| 语义分块 | 按自然段落/章节分割 | 实现复杂 |
最佳实践：没有银弹。512 Token + 10% 重叠是常见的起始基线，然后根据具体文档类型迭代。100 个 RAG 系统有 100 种 Chunking 策略——如果你的 Chunking 策略是「随便选的」，那你的 RAG 大概率不如关键词搜索。
Semantic Search（语义搜索）是向量检索的本质——不是匹配关键词，而是匹配「意思」。「如何提升员工积极性」和「怎样让团队更有干劲」在关键词上没有重叠，但在语义空间中距离极近。
7. Function Calling / Tool Use：让模型「动手」 {#7}
Function Calling（函数调用）是 LLM 的一个关键能力——模型不只是生成文本，还能「决定」调用外部工具，并生成结构化的调用参数。
为什么出现？LLM 被关在沙箱里——它不能查实时天气、不能发邮件、不能查数据库。Function Calling 给它开了一扇窗：你定义一批可用函数（工具），模型判断什么时候该用哪个、参数填什么，你把函数执行结果返回，模型基于结果继续生成。
工作流程：
用户：「明天北京天气怎么样？」 1. LLM 判断：需要调用 get_weather(city="北京", date="2025-07-27") 2. 你的代码执行这个函数，获得结果：「晴，25-35°C」 3. 将结果返回给 LLM 4. LLM 生成最终回复：「明天北京晴，气温 25 到 35 度，注意防暑。」Function Calling vs Tool Use：本质是同一件事。OpenAI 叫 Function Calling，Anthropic 叫 Tool Use，Google 叫 Function Declaration。核心协议正在趋同：JSON Schema 定义函数签名 + 模型输出结构化调用请求。
Function Calling ≠ Agent。Function Calling 是 Agent 的眼睛和手——但 Agent 远不止这一个能力。Agent 还涉及多步规划、状态管理、错误恢复——这些是第四篇的核心内容。
8. 术语速查表 {#8}
| 缩写/术语 | 英文全称 | 中文 | 本质一句话 |
|---|---|---|---|
| — | Prompt | 提示词 | 发给模型的上下文前缀，不是指令 |
| — | Prompt Engineering | 提示词工程 | 系统化设计、测试、迭代 Prompt 的工程实践 |
| — | System Prompt | 系统提示词 | 设定模型人设和全局约束的顶层提示词 |
| — | Prompt Template | 提示词模板 | 预置结构、留空变量的可复用 Prompt |
| — | Zero-shot | 零样本 | 不给示例，直接描述任务 |
| — | Few-shot | 少样本 | 给 2-5 个示例，模型模仿格式和风格 |
| — | In-context Learning | 上下文学习 | 模型在推理时从上下文示例中「学习」任务模式 |
| CoT | Chain-of-Thought | 思维链 | 让模型逐步推理而非直接给答案 |
| RAG | Retrieval-Augmented Generation | 检索增强生成 | 先检索文档，再让模型基于文档回答 |
| — | Embedding Model | 嵌入模型 | 专门把文本转成语义向量的模型 |
| — | Vector Database | 向量数据库 | 按语义相似度检索高维向量的专用数据库 |
| — | Chunking | 文本分块 | 将文档切分为可检索的语义单元 |
| — | Semantic Search | 语义搜索 | 按「意思」相似度检索，而非关键词匹配 |
| — | Function Calling | 函数调用 | 模型输出结构化参数以调用外部工具 |
9. FAQ {#9}
Prompt Engineering 是不是一个会被淘汰的临时技能？
「写 Prompt」这件事不会被淘汰，但「Prompt 作为玄学」会被淘汰。随着模型推理能力增强，模型对模糊 Prompt 的容忍度在提高。但另一方面，复杂任务（Agent、多步推理）对 Prompt 结构的要求反而更高了。趋势是：简单任务 Prompt 在退化，复杂任务 Prompt 在进化。
RAG 和 Fine-tuning 到底选哪个？
先 RAG，后 Fine-tuning。RAG 解决「知识更新」——成本低、见效快、可解释。Fine-tuning 解决「行为改变」——需要标注数据、成本高、但能定制模型的「思维方式」。大部分场景 RAG 就够了；只有当 RAG 调无可调（检索质量达标但输出质量不达标）时，才考虑 Fine-tuning。
CoT 对所有模型都有效吗？
对推理型模型更有效。小模型（7B 以下）加 CoT 有时反效果——它们的推理能力不够支撑多步思维。大模型（70B+）几乎总是受益。判断标准：把 CoT 当成一个实验，用你的真实数据跑 A/B 测试。
向量数据库必须用专用的吗？PostgreSQL 的 pgvector 够用吗？
百万级向量以下，pgvector 够用。千万级到亿级，专用向量数据库（Milvus、Qdrant、Pinecone）的优势开始显现——检索速度、内存效率、分布式扩展。先上线再优化：不要为了「将来可能需要的规模」过度设计。
Function Calling 和 Agent 是什么关系？
Function Calling 是 Agent 的一个子能力。Agent 还包括：多步规划、状态管理、记忆、错误恢复、多工具协调。Function Calling 只解决「何时调用哪个工具、参数填什么」这一个环节。第四篇会展开讲 Agent 的完整架构。
Few-shot 示例的顺序重要吗？
重要。同一个任务、同样的 3 个示例，顺序不同，准确率可能差 10-15%。把最典型、最干净的示例放在最后（离用户问题最近的位置），效果通常最好。这叫 Recency Bias（近因效应）。
10. 结语 {#10}
三个月后，小林学会了 Prompt Engineering。她不再写「帮我把这个文档写更好」，而是写：「你是资深产品架构师。第一步，保留所有技术术语，不要降级语言。第二步，优化逻辑结构——每个章节的开头加一段 50 字以内的核心观点。第三步，输出时标注你改变了什么以及为什么。」
「模型返回的文档，」她说，「可以直接进评审会。」
从「帮我把这个写好」到「按这个规范执行」，中间隔着一整套思维方式的转变。Prompt Engineering 的本质从来不是学几个模板——是学会把所有模糊的期望，翻译成模型能精确执行的约束。这个能力，在接下来的五年里，会比写代码本身更重要。
📬 下一篇预告：《AI 术语扫盲（三）：Fine-tuning、RLHF、LoRA、量化——让模型「听话」的核心技术》
你用 Prompt Engineering 踩过最大的坑是什么？评论区聊聊。
