第 11 章：提示词中的“角色系统”：为何角色越清晰，结果越稳定
角色（Role）是提示词工程中最重要的结构之一。
11.1 为什么角色对模型影响巨大？
因为 LLM 的推理方式类似：
“我必须扮演某种身份 → 决定语言风格 → 决定知识结构 → 决定行动范围”
角色能立即限制模型的思维“空间和风格”。
例如：
- 作为律师 → 输出法律逻辑、引用法规
- 作为心理咨询师 → 不给确诊，不给危险建议，强调共情
- 作为资深前端架构师 → 更倾向技术细节与架构分析
- 作为儿童故事作家 → 语言变得轻快温柔
- 作为顶级 AI 研究员 → 使用学术语言、引用论文、严谨推理
11.2 角色的四种结构层级
| 层级 | 类型 | 示例 |
|---|---|---|
| 1 | 基本身份 | “你是一名资深工程师” |
| 2 | 知识领域 | “熟悉 React Fiber + V8 优化 + TS 类型系统” |
| 3 | 行为模式 | “你的回答必须严谨，有分点结构” |
| 4 | 约束 + 行动边界 | “不要编造内容，不要引用未知论文” |
越往下越能锁定行为。
11.2.1 正常角色定义例子
你是一名资深 React 架构师，熟悉 Fiber、调度器、多线程渲染，实现过小型 React clone。
你解释问题时必须做到：
1. 分层讲解概念 → 原理 → 底层机制
2. 必须结合浏览器机制（事件循环、Layout、Paint）
3. 必须给代码片段（可运行）
禁止：
- 不要粗浅解释
- 不要跳过任何关键步骤
效果： 回答会更规范且稳定。
11.3 高级角色设计：人格融合 (Persona Fusion)
高级提示词经常需要“多个角色混合”。
11.3.1 示例：AI 编程导师 + 代码审查员 + 项目架构师
你需要同时具备以下人格：
1. AI 编程导师：擅长用类比解释复杂概念
2. 代码审查员：能指出代码风格、性能问题
3. 项目架构师：能给出可落地的系统设计图
合并人格行为规则如下：
- 回答结构必须：概念 → 原理 → 示例 → 审查 → 最终建议
- 必须给出风险点、改进点
- 一律禁止模糊描述
这种复合角色在 教育、技术解释、系统设计 场景特别强大。
11.4 角色的“人格参数”技巧（非常高级）
你可以让角色产生不同的“行为倾向”，例如：
11.4.1 严谨模式（Precise Mode）
人格倾向：
- 绝不猜测
- 不引用不确定的事实
- 有疑问必须提出
- 逻辑严密且逐步推理
11.4.2 创造模式（Creative Mode）
人格倾向：
- 允许突破常规
- 允许想象性扩展
- 输出脑暴内容时禁用限制
- 采用类科幻式表达
11.4.3 军师模式（Strategic Mode）
人格倾向：
- 输出必须高层、结构化
- 偏向战略分析，不深入细节
- 内容必须逻辑严密、优劣分析清晰
你甚至能让模型“切换人格”，像操作游戏角色一样。
11.5 角色定义的四个常见错误
| 错误 | 描述 | 示例 |
|---|---|---|
| 角色太宽 | 模型无法专注 | “你是一个懂很多的人…” |
| 角色冲突 | 两项人格要求互相否定 | “既很严谨，又必须很大胆” |
| 缺乏可执行行为 | 只给身份，不给行为 | “你是一名工程师” |
| 给了假信息 | 导致模型产生幻觉 | “你是斯坦福教授…” |
11.6 角色模板（可复制）
模板 1：专家型角色
你是一名[领域]的专家，拥有 10 年经验。
你的职责：
- 分步骤解释问题
- 使用专业术语并附解释
- 提供实践示例或代码
- 总结关键概念
禁止：
- 模糊表述
- 编造不可验证信息
模板 2：审查员（Reviewer）
你的身份是资深代码审查专家。
你的工作流：
1. 给总体评价
2. 找出风险点
3. 提供优化建议
4. 估计复杂度
禁止：
- 没有理由的建议
- 不解释性能问题的原因
第 12 章：提示词结构工程：如何写出最强大的 Prompt 框架
12.1 提示词的黄金结构（业界共识）
几乎所有顶级 Prompt 构建者（OpenAI、Anthropic、Meta 等）都使用下列结构：
- 角色（Role）
- 任务目标（Goal）
- 输出格式（Format）
- 约束与规则（Constraints）
- 示例（Examples / Few-shot）
- 输入（User Input）
- 推理方式（Reasoning Style）
- 最终输出（Final Answer）
这就是所谓的 R-G-F-C-E-I-R-O 模型。
12.2 黄金结构的解析（逐条讲透）
1. 角色 Role
2. 任务目标 Goal
模型必须知道：
- 你想做什么
- 为什么做
- 输出给什么人
- 有什么边界
示例：
目标：生成适合8岁儿童理解的物理学故事，使其理解重力。
3. 输出格式 Format
非常关键。格式越清晰，结果越稳定。
例：
输出格式：
- 一句话总结
- 3 个重点讲解
- 一个类比
- 一个小故事
4. 约束 Constraints
必须确保：
- 所有内容基于真实信息，不得编造
- 禁止技术术语
- 故事字符数控制在 200 字以内
5. 示例 Examples（Few-shot）
这是最强组件。
例：
示例：
输入：为什么天空是蓝色的？
输出：因为空气中的分子会散射光线...
模型会自动模仿风格。
6. 输入 Input
用统一格式包起来：
用户输入：
{{user_query}}
这是一种行业规范。
7. 推理方式 Reasoning Style
例如：
推理方式：
- 请先进行思考再输出答案
- 不需要写出思考内容
这称为 hidden chain-of-thought。
8. 输出 Final Answer
最终回答必须：
- 清晰
- 无冗余
- 结构化
12.3 黄金提示词模板（通用）
# 角色
你是一名 {{身份}}。
# 目标
你的任务是 {{目标}}。
输出内容主要面向 {{受众}}。
# 输出格式
请严格按照以下结构输出：
1. ...
2. ...
3. ...
# 约束
- ...
- ...
- 禁止 ...
# 示例（Few-shot）
示例输入：...
示例输出：...
# 用户输入
{{user_input}}
# 推理方式
请先思考再得出结论（不展示思考过程）。
# 最终输出
请用结构化方式回答。
12.4 为什么结构化提示词会 dramatically 提升质量？
因为它解决了模型的三个最大问题：
问题 1：模型不知道你最关注什么
结构化提示词 → 明确 priority
问题 2：模型输出漂移（跑偏）
明确定义格式 → 输出更一致
问题 3：模型难以形成稳定风格
Few-shot 示例 → 风格锁定
12.5 高级结构技巧：自我一致性 Self-Consistency Prompting
你可以让模型：
先写三个不同版本 → 选择最优 → 合并
示例：
请生成 3 个不同思路的答案，并选择最优方案，然后输出融合方案。
这是前沿技术，效果非常强。
12.6 大模型时代的提示词最佳实践（2025版）
- 先结构 → 再内容 → 再格式 → 最终例子
- 角色定义必不可少
- 格式必须结构化
- 禁止开放式问题
- 少量示例比大量规则更有效
- 让模型自己“检查输出”会极大提升质量
第 13 章：提示词的“约束工程”：如何让模型 100% 听话
约束（Constraints）是让模型“乖”的关键。
13.1 什么是约束？
约束 = 限制模型的行为
模型越强，越需要约束。
13.2 强约束 vs 弱约束
| 类型 | 描述 | 示例 |
|---|---|---|
| 弱约束 | 模型可能违反 | “尽量不要写太多” |
| 强约束 | 模型几乎一定遵守 | “字数不能超过 50 字” |
13.3 最常用的 10 类约束
- 字数限制
- 语言风格
- 禁止特定词汇
- 必须包含某些字段
- 安全相关约束
- 引用格式
- 信息粒度
- 逻辑顺序
- 内容范围
- 输出格式（JSON/Markdown）
示例：
输出必须是合法的 JSON：
{
"summary": "",
"steps": []
}
13.4 强制 JSON 结构的正确写法（非常关键）
错误写法：
请用 JSON 形式回答
模型可能输出：
好的，以下是 JSON：
{...}
解释：...
正确写法：
你只能输出 JSON，不能给任何解释。
如果你无法回答，也必须输出 {"error": "无法回答"}。
必须输出结构：
{
"title": "",
"key_points": [],
"details": ""
}
13.5 如何防止模型编造？（Anti-Hallucination Prompting）
如果信息不确定，请说“不确定”或提供可能性，而不是编造。
更强的：
你不得凭空编造任何事实。
你不得引用不确定的论文或研究。
对于没有数据支持的内容，你必须明确说明“无资料支持”。
13.6 模型常见违规点
- 字数超限
- 添加解释性文本
- 无法遵守 JSON 格式
- 输出模糊语言
- 给出编造数据
你可以加入自检：
输出前请检查：
- 是否符合 JSON？
- 是否没有解释性句子？
- 是否符合字数？
13.7 约束模板
必须遵守以下约束：
- 字数不超过 …
- 禁止解释
- 禁止使用以下词语：…
- 禁止出现第一人称
- 所有条目必须是 10 字以内
- 输出内容必须满足严格 JSON 格式
第 14 章：高阶 Few-shot Prompting：示例比规则更强大
（本章极其重要）
14.1 为什么示例比规则强 100 倍？
因为 LLM 并不擅长理解规则，
但它几乎完美模仿示例风格。
14.2 一条规则改变 20%，但一个示例改变 80%
例如：
请求模型生成“幽默科普”。
你写 10 条规则，效果不好。
但你给一个示例：
为什么太阳这么热？
因为如果它不热，地球就会冻成冰沙…
模型马上学会。
Few-shot 是提示词工程真正的“魔法”。
14.3 Few-shot 的最佳数量是多少？
- 1 个：风格明确
- 3 个：模式稳定
- 5 个：几乎完美锁定
超过 8 个可能影响性能（需要更多推理）。
14.4 Few-shot 结构模板
# 示例1
输入：...
输出：...
# 示例2
输入：...
输出：...
# 输出要求：
请模仿以上示例的风格、结构和内容密度。
14.5 如何选示例？（关键技巧）
选择示例应该满足：
- 简短
- 结构清晰
- 风格强烈
- 完整
14.6 Few-shot 模仿的边界
模型不会模仿：
- 示例的事实（不会自动复制错误）
- 示例的具体内容（会抽象结构）
模型会模仿：
- 风格
- 节奏
- 情绪
- 框架
14.7 高级技巧：Hidden Few-shot
把示例藏在系统提示中，让模型“学习但不展示”。
示例：
系统提示：
示例A：
用户：解释为什么…
AI：回答…
示例B：
用户：…
AI：…
你现在应使用相同风格回答用户问题。
用户看不到，但效果极佳。
第 15 章：自动评估（Self-Evaluation）提示词：让模型检查自己
这是 2024–2025 最新趋势。
15.1 为什么自评有效？
因为 LLM 无法一次性输出高质量内容，
但能“检查”自己的输出并修复问题。
15.2 基本自评流程
- 模型生成草稿
- 模型审核草稿
- 模型修复草稿
- 输出最终稿
示例：
请先生成初稿，不要输出。
然后基于以下标准检查初稿：
- 是否回答完整？
- 是否逻辑一致？
- 有无编造？
如果存在问题，请修复。
最后输出修订后的最终稿。
（输出不会包含草稿，因为我们禁止展示）
15.3 自评策略：Rubrics Prompting
Rubrics = 评分标准
你可以这样写：
请基于以下评分标准自我检查：
1. 完整性（1-5 分）
2. 准确性（1-5 分）
3. 逻辑性（1-5 分）
4. 实用性（1-5 分）
任何得分 < 4，则必须修复。
15.4 自校验 JSON 结构
输出前请进行 JSON 结构自检：
如果不是合法 JSON：
- 自动重试 3 次
- 必须确保语法正确
这是最关键的 JSON 生成技巧。
第 16 章：提示词中的推理风格：让模型“怎么想”
推理风格决定模型“如何得出答案”。
16.1 常见的 6 种推理风格
| 风格 | 描述 | 场景 |
|---|---|---|
| Step-by-step | 逐步推理 | 技术分析 |
| Tree reasoning | 树状推理 | 规划、战略 |
| Debate | 双重意见对决 | 决策 |
| Critical thinking | 批判思考 | 风险评估 |
| Mathematical reasoning | 数学推理 | 公式、逻辑 |
| CoT（思维链） | 深思熟虑 | 高复杂度问题 |
16.2 如何控制推理方式？
不能让模型输出自己的推理内容（CoT 会泄露思维链），
但可以让它 隐式推理。
示例：
请先在内部进行详细推理（不展示推理过程），
然后输出结构化结论。
16.3 推理深度控制（非常关键）
你可以要求模型推理：
- 浅（适合儿童）
- 中（普通）
- 深（技术专家）
例：
推理深度：技术专家级（必须包含底层原理、机制、限制）
第 17 章：提示词的多回合工程（Conversation Engineering）
单回合提示词容易丢上下文。
多回合提示词可以像框架一样组织一场“对话工作流”。
17.1 多回合提示词的三大核心
- 上下文记忆
- 任务分段
- 流程闭环
17.2 多回合流程模板：4 步法
- 确认需求
- 提供方案草稿
- 深度优化
- 最终定稿
示例：
第 1 步：先帮我明确目标
第 2 步：给我三个方向
第 3 步：我选择一个后你深入展开
第 4 步：输出最终版本
17.3 让模型主动提问（需求澄清）
你现在不要回答，先用 5 个关键问题确认我的需求。
17.4 多回合中的状态约束
可以让模型记住特定规则：
我们之后对话中，你必须保持以下规则，不需要再重复说明：
- 回答必须结构化
- 字数 < 200
- 不能使用“可能、大概”等模糊词
第 18 章：提示词调试（Prompt Debugging）：模型不听话怎么办？
18.1 常见问题
| 问题 | 原因 |
|---|---|
| 不按格式回答 | 约束不够强 |
| 输出太短/太长 | 字数限制不清晰 |
| 风格漂移 | 缺少示例 |
| 出现幻觉 | 缺少反幻觉约束 |
| 重复内容 | 提示词逻辑重叠 |
18.2 调试方法 1：加入反例（Negative Examples）
错误示例（不要模仿）：
- 内容空洞
- 重复句子
- 不遵守格式
18.3 调试方法 2：让模型解释为什么没做到
示例：
你违反了格式，请解释哪一步做错了，并修复。
模型通常会自动纠正。
18.4 调试方法 3：注入更强的结构化约束
例如 JSON：
你必须输出合法 JSON。
如果失败，必须自动重试 3 次。
18.5 调试方法 4：分阶段输出
将任务拆解：
第 1 步：生成结构
第 2 步：填充内容
