第6章：Prompt —— 如何与 AI 高效对话

本章解决的核心问题：Prompt 不是玄学，它有逻辑、有结构、有方法论。什么是好 prompt？Zero-shot 和 Few-shot 有什么区别？思维链（CoT）为什么有效？System Prompt 怎么用？读完这一章，你写出来的 prompt 不再靠运气。

6.1 Prompt 的本质

6.1.1 Prompt 不是一个「问题」

很多人把 prompt 理解成「给 AI 提一个问题」。这个理解太窄了。

Prompt 的本质是：你给模型的上下文信息，模型用它来完成「下一个 token 预测」这个唯一任务。

你给了模型一段文本开头，它的任务就是续写。Prompt 的作用是把这个「续写」往你希望的方向引导。如果 prompt 是一个问题，模型会续写成「回答」。如果 prompt 是一段未完成的代码，模型会续写成「完成这段代码」。如果 prompt 是一篇文章的开头，模型会续写成「继续写这篇文章」。

核心洞察：你不是在「和 AI 对话」——你是在提供一个开头，让 AI 用最合理（概率最高）的方式续写它。

这个视角很重要，因为它解释了为什么：

• 结构化的 prompt 比随意的 prompt 效果好——模型从中学到「续写的正确模式」。
• 示例（few-shot）非常有效——模型从示例中「读取」你想要的风格和格式，然后照这种模式续写。
• 「不要做 X」的 prompt 效果不如「请做 Y」——因为模型学的是「接下来应该是什么」而不是「接下来不应该是什么」。

6.1.2 System Prompt 和 User Prompt

在 ChatGPT API、Claude API 等实际使用中，prompt 分为两个角色：

flowchart LR
    SP[System Prompt
系统指令
「你是谁 + 你要怎么回答」] --> Model[模型]
    UP[User Prompt
用户消息
「这次的具体任务」] --> Model

• System Prompt（系统指令）：设定模型的行为准则——「你是谁」「你要用什么风格回答」「你有什么约束」。这个在整个对话过程中保持不变（不被用户看到）。
• User Prompt（用户消息）：每次对话的具体输入——问题、任务、需要处理的内容。

在 ChatGPT 的 Web 界面，用户看不到 System Prompt——它是在背后悄悄设定的。但在 API 调用或定制产品中，System Prompt 的设定是 prompt engineering 的重要部分。

实战技巧：一个好的 System Prompt 通常包含：角色设定 + 输出格式要求 + 禁止行为。例如：

你是一个专业的技术文档翻译，擅长将英文技术文档翻译成精准且流畅的中文。翻译时要保持原文的技术准确性，使用专业术语的统一中文对应词。如果遇到不确定的术语，在翻译后附括号标出英文原文。不要添加任何你没有读到的信息。

6.2 三种 Prompt 模式：从零基础到高手

6.2.1 Zero-shot：不给示例，直接问

这是最简单也最常见的方式——不给任何示例，直接描述任务。

Zero-shot 示例：
「把下面这句话翻译成英文：今天天气真好」

优点：简单、节省 token。
缺点：对复杂任务效果不佳——模型可能理解偏差。

适合的场景：简单翻译、基础问答、众所周知的常识性问题。

6.2.2 Few-shot：给几个示例再问

在 prompt 的开头给出几个「输入 → 期望输出」的示例，然后再给出真正的输入。

Few-shot 示例：

英文 → 中文技术翻译：
Input: The model achieved state-of-the-art results on all benchmarks.
Output: 该模型在所有基准测试上均达到了当前最佳水平。

Input: Gradient descent converges faster with appropriate learning rate scheduling.
Output: 采用合适的学习率调度策略，梯度下降的收敛速度更快。

Input: The attention mechanism allows the model to focus on relevant parts of the input.
Output: （模型自己生成）

为什么 Few-shot 这么有效？

回到 prompt 的本质——你在给模型续写的开头。Few-shot 示例在告诉模型：「接下来你要续写的格式和风格，和上面这几个例子一模一样。」模型不需要「理解你的指令」——它只需要接着示例的规律往下走：

• 示例输入是英文 → 新的输入也是英文
• 示例输出是中文技术翻译 → 模型输出也是中文技术翻译
• 示例翻译风格有特点（如在专业术语后附英文原文）→ 模型会模仿

关键结论：Few-shot 是在利用模型的模式匹配能力，而不是指令理解能力。对于 LLM 来说，模式匹配比指令理解更可靠——这是 prompt engineering 里最被低估的洞察之一。

6.2.3 Chain-of-Thought（思维链）：让模型「先想想再说」

2022 年 Google 的一篇论文《Chain-of-Thought Prompting Enables Reasoning Capabilities in Large Language Models》展示了 prompt engineering 中最惊人的一个发现：在 prompt 里加入「我们一步步来思考」之类的引导，模型的推理能力会显著提升。

没有 CoT：
Q: 小明有 5 个苹果，给了小红 2 个，又买了 3 个。他现在有几个苹果？
A: （模型可能直接答对——也可能出错）

有 CoT：
Q: 小明有 5 个苹果，给了小红 2 个，又买了 3 个。他现在有几个苹果？
请一步一步推理。
A: 开始时小明有 5 个苹果。
   给出 2 个后：5 - 2 = 3 个苹果。
   买了 3 个后：3 + 3 = 6 个苹果。
   所以小明现在有 6 个苹果。

为什么 CoT 有效？

回到模型的工作方式——它是一个自回归的逐 token 生成器。在生成「A: 6 个苹果」这条路径上，它必须先经过「5 - 2 = 3」「3 + 3 = 6」这些中间 token。

和直接跳到答案相比，走过中间推理步骤让模型「被迫」在概率空间里走一条更严谨的路径——每一步推理都约束了下一步的可能范围，减少了「跳向错误答案」的概率。

此外，对于数学和逻辑问题，训练数据中「有推理过程」的答案本来就比「只给答案」的答案更常见——所以 CoT 实际上是在引导模型模仿训练数据中高质量的推理范例。

flowchart LR
    A[问题] --> B{直接回答}
    A --> C[CoT 推理]
    B --> D[可能对
可能错
不可靠]
    C --> E[步骤 1] --> F[步骤 2] --> G[步骤 3] --> H[答案
更可靠]

6.2.4 进阶：Zero-shot CoT

你甚至不需要在 prompt 里给完整的推理示例——只要加上一句神奇的咒语：

「Let's think step by step.」（让我们一步一步想。）

这句简单的指令就能触发模型的推理行为。东京大学和 Google 的研究（2022）发现，仅仅添加这句话，就能让 GPT-3 在多个推理基准上的准确率大幅提升。

原理是：这句话作为 prompt 的开头，引导模型进入「推理模式」——生成的概率分布向「包含中间步骤的详细解释」倾斜。

6.2.5 自动 CoT 与推理模型

2023-2024 年，CoT 思想进一步发展：

• Auto-CoT：自动生成推理链示例（而不是手工写），用聚类选取多样化的示例。
• Tree-of-Thought (ToT)：不只是线性思维链，而是分叉探索多条推理路径，在其中搜索最佳路径。
• 推理模型（o1、DeepSeek-R1）：在训练阶段就融入了推理链生成——模型不需要 prompt 引导就会自动「先想再答」。o1 的「invisible reasoning tokens」（不可见的推理 token）在生成用户可见的回答之前，先进行内部推理。

6.3 好 Prompt 的结构

没有万能的模板，但好 prompt 有一些共通的要素。以下是广泛验证有效的结构框架：

框架：「角色 + 任务 + 格式 + 约束」

[角色] 你是一个...
[任务] 请帮我做 X...
[格式] 请以 Y 格式输出...
[约束] 注意不要...；确保...

完整的例子（把「帮我写周报」变成可执行的工程级指令）：

# 角色
你是一个互联网产品团队的资深产品经理。

# 任务
根据我下面提供的一周工作流水，生成一份结构化的周报。

# 格式
- 标题：本周工作总结（2024.XX.XX - 2024.XX.XX）
- 第一部分：本周关键成果（3-5 条，每条不超过两行）
- 第二部分：进行中的事项（列表）
- 第三部分：遇到的问题和风险（如有）
- 第四部分：下周计划

# 约束
- 用客观陈述，不要写「我感觉」「我觉得」
- 每个条目要对齐具体的业务指标或交付物
- 不要添加我没有提到的工作内容
- 不要用过于夸张的形容词（如「非凡」「史诗级」）

# 输入
[这里粘贴工作流水]

这个结构之所以有效：

1. 角色：缩小了「可能怎么续写」的概率空间。模型不会用「小学生」或「客服」的口吻——而是用「产品经理」的。
2. 任务：明确的动作，减少歧义。
3. 格式：告诉模型输出结构——模型在续写时会贴合这个结构。
4. 约束：砍掉了你不想要的——防止模型「脑补」工作内容和添加花哨的修饰词。

6.4 让模型输出结构化的数据

6.4.1 为什么需要结构化输出

在日常使用 ChatGPT 时，结构化输出的需求不如在程序化调用时明显。但对于需要用代码处理模型输出的场景（Agent 工作流、自动化流水线），让模型输出 JSON 而不是自然语言是至关重要的：

• 程序可以解析 JSON，但解析自由文本很痛苦。
• 结构化的输出可以被下游系统直接使用。
• 明确的输出格式减少了模型「自由发挥」的空间——反而提高了可靠性。

6.4.2 简单方式：在 Prompt 中指定格式

请以 JSON 格式输出，结构如下：
{
  "summary": "一段总结",
  "sentiment": "positive / negative / neutral",
  "key_points": ["要点1", "要点2", "要点3"]
}

对大多数场景这已经足够好用。

6.4.3 进阶：Function Calling / Tool Use

现代大模型 API（GPT-4、Claude 3.5 等）提供了 Function Calling（函数调用）或 Tool Use（工具使用）能力。这比在 prompt 里要求 JSON 更可靠，因为：

• 模型被专门训练过如何选择和使用「工具」——这本身也是一种对齐（不输出自由文本，而是输出结构化的函数调用）。
• API 服务端会确保输出的 JSON 符合你定义的 schema。
• 你可以定义多个函数（工具），让模型自主决定在什么情况下调用哪个。

这种能力是现代 AI Agent 的基础设施——我们会在第7章的「Agent」词条中进一步展开。

6.5 常见 Prompt 技巧速览

6.6 Prompt 的常见误区

本章小结

下一章预告

最后一章是一本随手可翻的工具书——不需要从头读到尾。当你看到 LLM、AGI、RAG、Fine-tuning、Embedding、多模态、Agent 这些术语时，翻开它，30 秒就能搞清楚。

→ 第7章：术语速查