📚 系列：[大模型入门：从原理到实践，技术人的认知升级指南]
同一个问题，三种完全不同的结果
来看一个实验。
针对同一个任务------"解释递归是什么"------用三种不同方式提问：
问法一 ：解释递归是什么
模型给你一段教科书式的定义，提到函数调用自身、终止条件、栈溢出，语言规范但干燥。
问法二 ：你是一位有十年经验的程序员，正在给一个刚入行的实习生解释递归。用一个生活中的类比来说明。
模型给你一个"俄罗斯套娃"或者"镜子对着镜子"的类比，生动易懂，然后再回到代码层面做对应。
问法三 ：你是一位有十年经验的程序员，正在给一个刚入行的实习生解释递归。先用一个生活中的类比，再给一个简单的例子，最后说明什么时候用递归、什么时候不该用。分三个部分，每部分不超过三句话。
模型给你一个结构清晰、层次分明、长度恰当的回答，完全符合你的实际需求。
同一个模型，同一个问题，三种结果的差距，完全来自于 Prompt 的写法。
为什么 Prompt 这么重要
在第 2 章我们说过，模型在处理你的问题时，只能"看见"上下文窗口里的内容。而你的 Prompt，就是你放进这个窗口里最重要的信息。
模型没有你的工作背景，不知道你是谁，不知道你要这个答案用来做什么，不知道你期望的格式，不知道你的目标受众。它唯一能依据的，就是你在 Prompt 里告诉它的一切。
更本质地说：你的 Prompt 在很大程度上决定了模型从它的"语言空间"里往哪个方向走。
打个比方：模型的能力像一个巨大的迷宫，里面有无数条路，每条路通向不同质量、不同风格、不同视角的答案。你的 Prompt 是你手里的地图------它决定了你从哪个入口进，沿着哪条路走，最终到达哪个出口。
模糊的 Prompt，迷宫随机走；清晰的 Prompt，直达你想要的地方。
清晰 Prompt
角色+受众+结构+长度限制
模型明确
方向和约束
符合预期的
结构化回答
模糊 Prompt
解释递归
模型不确定
受众/深度/格式
教科书式定义
（可能不是你想要的）
图 6-1：模糊 Prompt 与清晰 Prompt 的效果对比。Prompt 越明确，模型的"搜索空间"越小，结果越接近你的真实需求。
技巧一：角色设定
角色设定是最直接、效果最稳定的 Prompt 技巧之一。
做法很简单：在问题之前，告诉模型它应该扮演什么角色，这个角色有什么背景。
你是一位资深的数据安全专家，擅长向非技术背景的管理层解释安全风险......
你是一位儿科医生，正在用五岁孩子能理解的语言解释......
你是一位严格的代码审查员，关注性能、可读性和潜在的安全漏洞......
为什么这有效？因为角色设定给了模型一个清晰的"出发点"------什么专业背景、什么沟通风格、什么关注重点。模型在训练数据里见过大量不同角色的人是如何表达的，角色设定让它调用对应的语言模式。
一个有用的规律：角色越具体，效果越好。"专家"比没有角色好，"有十年医院临床经验的心内科医生"比"医疗专家"好得多。
技巧二：思维链提示
思维链（Chain of Thought，CoT）是让模型在给出最终答案之前，先把推理过程一步一步写出来。
对于需要推理的问题，这个技巧效果显著。
直接问："一个项目有 5 名开发，平均每人每天提交 3 次代码，两周工作日共产生多少次提交？"
模型可能直接给你一个答案，但中间跳过了步骤，出错概率很高。
加上思维链提示："请先列出计算步骤，再给出最终答案。"
模型会先写：两周工作日 = 10 天，5 名开发 × 3 次/天 × 10 天 = 150 次。答案：150 次。
步骤拆开之后，每一步都有机会被校验，整体准确率明显提升。
思维链回答
复杂问题
+「先列步骤」
步骤1：分析条件
步骤2：中间计算
步骤3：验证逻辑
最终答案
（每步可被校验）
直接回答
复杂问题
直接跳到答案
（可能跳过错误步骤）
图 6-2：直接回答 vs 思维链回答。强制模型"先推理、再结论"，让每个中间步骤都显式可见，有效减少推理跳跃导致的错误。
技巧三：少样本示例
有时候，与其用文字描述你想要什么，不如直接给模型几个例子。
这个技巧叫做 少样本提示（Few-shot Prompting）：在问题之前提供 2-5 个"输入→输出"的示例对，让模型从示例中推断出你期望的模式，然后应用到新的输入上。
示例：
我会给你一些产品评价，请把情绪分类为"正面"、"负面"或"中性"。
评价："这个键盘手感超好，打字很舒服"→ 正面
评价："快递太慢了，等了一周"→ 负面
评价："产品和描述基本一致"→ 中性
现在请判断：
评价："充电速度还行，续航一般"→模型看完三个示例，几乎不需要再解释任务描述，直接给出"中性"。
少样本提示特别适合以下情况：格式要求复杂、风格不好用文字描述、任务需要特定的分类标准。三到五个好的示例，往往比一段详细的文字描述更有效。
技巧四：明确输出格式
如果你对输出的格式有要求，最好直接说出来，不要让模型猜。
模型在没有格式要求时，会用它认为"最合理"的格式输出，这往往是一大段流畅的自然语言。但很多实际场景需要的是：JSON、Markdown 表格、分点列表、固定长度的摘要、特定结构的报告......
有效的格式指令示例：
用 JSON 格式返回，包含 name、age、department 三个字段用 Markdown 表格列出，三列：优点、缺点、适用场景总结为不超过 5 点，每点一句话用一段话概括，不超过 80 字
格式越具体，模型输出的结构越稳定，也越容易被程序或工作流直接使用。
图 6-3：四种核心 Prompt 技巧的适用场景对比。角色设定适合所有场景；思维链针对推理任务；少样本示例针对格式/分类任务；输出格式指令在需要结构化输出时必加。
技术人最常见的五个 Prompt 误区
理解了基本技巧，我们来看技术背景的人最容易犯的几个错误------
误区一：Prompt 越短越好
技术文化崇尚简洁，很多程序员写 Prompt 的本能是"越精简越好"。但对模型来说，信息越完整，结果越准确。一个好的 Prompt 往往比你想象的要长。
误区二：用技术术语描述需求
"给我一个 O(n log n) 复杂度的排序算法的直觉解释"------这个 Prompt 对模型没问题，但如果你的目标是让非技术读者能看懂，就应该在 Prompt 里说"用不懂算法的产品经理能理解的方式解释"。Prompt 里描述的是你的真实需求，不是技术规格。
误区三：一次问题塞太多任务
"帮我分析这段代码的性能问题，给出优化建议，顺便解释一下这里用的设计模式，再告诉我有没有安全漏洞。"
四个任务混在一起，模型的注意力被分散，每个任务的输出质量都不如单独问。好的做法是分轮提问，一次一个任务。
误区四：不迭代
写一个 Prompt，看了结果不满意，换一个完全不同的写法重来------这是效率最低的做法。更好的方式是把上一个结果的问题找出来，针对性地改 Prompt，就像调试代码一样，一次改一个变量。
误区五：把模型当搜索引擎用
"最新版本的 React 有哪些新特性"------这应该去官网或 changelog 查，不应该问模型（知识截止问题）。"帮我解释 React 并发模式的核心设计思路"------这是模型擅长的。两类问题长得像，但适合的工具完全不同。
Prompt 工程的本质
学完这些技巧，可以提炼一个底层规律：
Prompt 工程，本质上是在用语言精准地指定你想要的输出空间。
你的角色设定、受众说明、格式要求、步骤指令，每一个都在缩小模型的搜索范围，让它更快、更准地到达你真正想要的答案。
但 Prompt 工程有它的边界：它只能影响模型如何组织和呈现它已有的知识，它无法让模型知道它不知道的事，也无法让它访问它看不到的数据。
如果你的任务需要模型处理你的私有文档、实时数据、特定知识库，只靠 Prompt 是不够的------这就是下一章 RAG 要解决的问题。
本章小结
- Prompt 决定了模型从能力空间的哪个方向、以哪种姿态生成回答；
- 角色设定：告诉模型扮演谁，越具体效果越好；
- 思维链提示：要求模型先列步骤再给结论，提高推理准确率；
- 少样本示例：用 2-5 个例子直接展示期望的输入输出模式；
- 输出格式指令：明确告知期望的结构，让结果可直接使用；
- 技术人常见误区：过于简短、滥用术语、任务堆叠、不迭代、用作搜索引擎；
- Prompt 工程的边界：无法让模型知道它不知道的事------RAG 解决这个问题。