AI提示词焚诀

AI提示词焚诀：高级提示词模板工具箱

「焚诀」取自兵法《黄石公》，意为提炼核心精要而成的制胜法典。本文旨在将散落的提示词实践经验，熔炼为一套可随时取用的高效模板体系。

---

〇、写作宗旨

撰写一篇关于AI提示词优化的专业技术文章，文章核心目标是提供一系列经过精心设计、能够显著提升AI工作效率、能力表现及问题解决质量的高级提示词模板，打造一个实用的「AI提示词工具箱」。用户可以根据不同功能需求，直接选用或调整相应的提示词段落，实现与AI的高效交互。

文章应包含的结构化内容

1. 引言部分：阐述高质量提示词对AI性能提升的重要性及本工具箱的价值定位
2. 提示词设计原则：详细说明构建有效提示词的核心方法论与关键要素
3. 功能分类的提示词模板库：按应用场景或功能需求进行分类，每个类别下提供3-5个专业级提示词模板，每个模板应包含：
   • 明确的功能描述
   • 适用场景说明
   • 完整的提示词文本
   • 使用注意事项与调整建议
4. 高级技巧章节：介绍提示词组合策略、迭代优化方法及复杂任务的提示词构建思路
5. 案例分析：展示实际应用示例，对比普通提示与优化提示的效果差异

每个提示词模板需满足的技术标准

• 包含明确的角色定义与能力边界设定
• 提供清晰的任务目标与输出要求
• 包含必要的上下文信息与约束条件
• 设计合理的思考引导与推理步骤
• 具备可调整的参数或变量，适应不同需求

质量目标

确保文章内容兼具理论深度与实践操作性，语言表达专业准确且易于理解，适合从初级到高级各层次AI使用者参考。

---

一、引言：为什么需要提示词工程

1.1 本质问题

与AI的交互，本质上是将人类的模糊意图翻译为机器可执行的精确指令。这条翻译链路的质量，直接决定了AI输出的上限。

一个差的提示词，如同向一位博学的专家含糊地提问：「这个东西怎么弄？」——得到的答案必然是泛泛而谈的常识。

一个好的提示词，则像给一位同事一份清晰的工作简报：角色是什么、目标是什么、约束是什么、交付物是什么——得到的是可直接使用的成果。

1.2 提示词工程的价值定位

提示词工程不是玄学，也不是少数人的天赋。它是一门可以被结构化学习、被模板化复用、被量化评估的实用技术。本工具箱的目标是：

• 降低门槛：让初学者也能写出专业级提示词
• 提升效率：避免每次从零构建提示词
• 保证质量：通过模板约束输出的稳定性和可靠性
• 激发创意：通过组合不同模板碰撞出新的可能

1.3 核心理念

好的提示词 = 清晰的角色 + 明确的目标 + 充分的上下文 + 合理的约束 + 可验证的输出

每一个要素都是可独立优化的变量，共同构成提示词的质量方程。

---

---

一之二、如何使用本工具箱

1.4 新手入门路径

本工具箱按「认知—设计—应用—优化」的进阶逻辑组织，建议新手按以下路径学习：

第一阶段：建立框架认知（约30分钟）

• 先通读「引言」和「设计原则」两章，理解 ROLES 框架和五项核心原则
• 建议一边读一边用自己的语言复述每个原则，检验理解程度
• 完成提示词质量自检清单中的 7 项检查，确保对「好提示词」有内部标准

第二阶段：掌握基础模板（约1小时）

• 从「类别一：角色设定」的模板 1.1（领域专家角色）开始第一次实战
  • 选一个自己熟悉的领域，套用模板写一个提示词，对比不加模板的输出差异
• 接着学习「类别二：结构化输出」的模板 2.2（分节式报告）和 2.3（表格输出）
  • 这两个模板在日常工作中复用率最高，覆盖面极广
• 最后学习「类别三」中的模板 3.1（六步深度分析），体验「过程引导」的力量

第三阶段：安全与迭代（约1小时）

• 学习「类别四」模板 4.1（多维度约束）和 4.3（安全边界声明）
  • 在正式交付场景中，安全护栏比文采更重要
• 学习「类别五」模板 5.1（差异对比优化）和 5.3（质量闭环自检）
  • 养成「生成后必优化」的习惯，这才是专业用户与普通用户的分水岭

第四阶段：整合实战（持续实践）

• 挑选一个真实的复杂任务，按 4.3 节的「分阶段构建法」从头到尾走一遍
• 在每次实践中查表取用模板，逐步形成个人的模板组合习惯

1.5 进阶使用路径

当你已经能熟练使用单个模板后，尝试以下进阶策略：

策略一：模板组合

• 参考 4.1 节的四种经典组合模式，理解「1+1>2」的叠加效应
• 在实践中创造自己的组合，例如「JSON 输出 + 质量自检」适合 API 对接场景
• 原则：组合不超过 3 个模板，否则约束过多反而抑制输出

策略二：自定义扩展

• 每个模板中的 {变量} 是为你预留的定制接口。以模板 1.1 为例：
  • {思维范式} 是最大的价值杠杆点——同样的需求，换成「成本优先」和「体验至上」两种思维范式，输出质量差异显著
  • {表达风格} 决定了输出的可读性和受众适配度，建议建立自己的风格库
• 将常用参数值固化为个人偏好预设，例如「技术方案类一律用『架构师 + 分节式报告 + 红队审查』三件套」

策略三：建立个人模板库

• 收集反复使用的提示词，按本文的分类体系整理成个人模板
• 在实际使用中发现现有模板的不足，主动迭代优化
• 持续沉淀第五章（常见陷阱）中遇到的真实案例，形成反模式知识库

1.6 常见误区纠正

以下是新手在学习和使用提示词模板时最容易踩的坑：

误区一：以为模板越长越好

• 现象：把五个类别的模板全部拼接在一起，得到一个上千字的「万能提示词」
• 纠正：提示词的威力在于聚焦而非全面。长提示词稀释了关键指令的权重，反而导致 AI 抓不住重点。一句话原则：只包含完成当前任务必需的要素，多余的都删掉。

误区二：忽视迭代，追求一步到位

• 现象：花了 30 分钟精心雕琢一个提示词，期望一次就用出完美效果
• 纠正：提示词工程的核心是「生成→评估→修正」的快速闭环，而非一次性完美设计。用三轮迭代法（4.2 节），每轮控制在 5 分钟内，三至五轮后的结果远优于一次精雕细琢。

误区三：把模板当作不可改的教条

• 现象：严格按照模板逐字使用，遇到不适配的场景就放弃
• 纠正：模板是脚手架而非牢笼。所有 {变量} 都可以增删，所有步骤都可以裁剪。真正的高手看到模板就知道：「这个模板的骨架可以用，但要在这里加一个约束，那里删一个步骤。」

误区四：忽视上下文窗口限制

• 现象：把整篇文档、大量背景资料和长篇提示词一起塞给 AI
• 纠正：参考 4.4 节的上下文窗口优化策略，学会信息分层和分步加载。关键指令放在开头和结尾，长文本用摘要替代原文，分步追加细节。

误区五：过度依赖模板而停止思考

• 现象：机械套用模板生成输出，不验证、不质疑、不注入个人判断
• 纠正：模板解决的是「格式和结构」问题，但「判断和决策」永远是你的责任。每个模板末尾都设置了验证环节（如质量自检、置信度标注、需验证问题），这些不是可选项。

二、提示词设计原则

2.1 ROLES 框架

构建有效提示词的核心方法论，可归纳为 ROLES 框架——五个核心要素的英文首字母缩写：

要素	含义	关键问题
R — Role	角色定义	你是谁？你有什么能力和边界？
O — Objective	任务目标	你要完成什么？成功的标准是什么？
L — Layout	上下文/布局	你有哪些信息？有什么约束条件？
E — Example	示例/范式	期望的输出长什么样？有没有参考？
S — Steps	推理步骤	应该按什么路径思考？

2.2 设计原则详解

原则一：角色先行，边界清晰

AI的表现与其「被赋予的角色」高度相关。一个「资深架构师」的回答质量，通常高于一个「AI助手」的回答。角色定义需包含：

• 身份标签：具体的职业或角色（如「安全工程师」而非「技术人员」）
• 能力范围：该角色擅长什么、不擅长什么
• 经验深度：多少年经验、什么专长领域
• 思维范式：该角色的典型思考方式和决策模式

原则二：目标精确，可度量

模糊的目标产生模糊的输出。精确的目标应该：

• 具体到行为：不是「帮我写文档」，而是「帮我写一份面向非技术读者的API使用说明」
• 包含质量标准：不是「写好一点」，而是「用词通俗易懂，每个概念配类比，篇幅控制在800字以内」
• 区分必须项与可选项：用「必须」「应该」「可以」明确优先级

原则三：上下文充分，信息对称

AI的输出质量取决于它获得的信息量。提供充分的上下文：

• 背景信息：任务的由来和场景
• 约束条件：时间、格式、风格、禁区
• 已有信息：已完成的工作、已做出的决策
• 目标读者/用户：输出面向谁

原则四：示例驱动，范式引导

一个示例胜过千言万语。提供参考示例可以：

• 锚定输出的格式和风格
• 消除对「好」的歧义理解
• 展示边界案例的处理方式
• 显著提升输出的一致性

原则五：路径引导，过程可控

对于复杂任务，引导AI的思考路径比直接给答案更重要：

• 分步指令：将复杂任务拆分为有序步骤
• 中间检查点：在关键步骤设置验证点
• 推理框架：提供分析的脚手架而非结论
• 反思机制：要求AI在输出前自检

2.3 提示词质量自检清单

在使用任何提示词前，用以下清单快速自检：

• 是否定义了明确的角色和能力边界？
• 是否说明了具体、可度量的任务目标？
• 是否提供了充分的背景和约束条件？
• 是否给出了输出的格式或示例？
• 是否引导了思考路径或推理步骤？
• 是否考虑了边界情况和例外场景？
• 是否设计了迭代优化的反馈机制？

---

三、提示词模板库

类别一：角色设定与人格锚定

模板1.1：领域专家角色

功能描述：将AI设定为特定领域的资深专家，获取专业级回答

适用场景：技术咨询、方案评审、专业知识问答、行业趋势分析

完整提示词：

你是一位拥有{年限}年经验的{领域}专家。

你的专业领域包括：{具体专长列表}
你的思维方式是：{思维范式描述，如「风险优先、防御纵深、最小权限」}
你的表达风格是：{风格描述，如「简洁精准、逻辑严密、用数据说话」}

请以该专家的身份回答以下问题：
{问题内容}

回答要求：
1. 先给出结论性判断
2. 再展开分析过程
3. 标注不确定或有争议的部分
4. 提供可执行的行动建议

使用注意：

• {年限}建议5-15年，太短缺乏可信度，太长可能脱离实际
• {领域}越具体越好，「网络安全专家」优于「安全专家」
• {思维范式}是关键差异点，直接决定回答的视角和逻辑

---

模板1.2：多角色协同

功能描述：设定多个专家角色从不同视角分析同一问题

适用场景：复杂决策分析、方案评审、跨领域问题、风险评估

完整提示词：

请三位专家协同分析以下问题，每位专家独立给出判断，最后进行综合：

【专家A】架构师
- 职责：评估技术可行性和系统设计
- 关注点：性能、可扩展性、技术债务
- 10年分布式系统设计经验

【专家B】安全工程师
- 职责：识别安全风险和合规问题
- 关注点：攻击面、数据保护、合规要求
- 8年应用安全与渗透测试经验

【专家C】产品经理
- 职责：评估用户价值和商业可行性
- 关注点：用户体验、市场定位、迭代策略
- 6年B端产品设计经验

问题：{具体问题}

输出格式：
1. 三位专家各自的独立分析（标注专家身份）
2. 专家间的分歧点和共识点
3. 综合建议和优先级排序

使用注意：

• 角色数量建议2-4个，太多会导致输出发散
• 每个角色的职责和关注点必须有明确差异
• 最后要求综合，避免各说各话

---

模板1.3：人格化交互伴侣

功能描述：将AI设定为具有特定人格特征的交互对象

适用场景：长时间陪伴、学习辅导、创意激发、情绪调节

完整提示词：

你是我的{角色关系，如「技术导师」「创业伙伴」「写作教练」}。

你的人格特征：
- 性格：{如「理性温和，善于倾听，偶尔犀利」}
- 沟通风格：{如「先用一句话总结要点，再展开细节，每段不超过3句」}
- 互动原则：{如「不直接给答案，通过提问引导思考；对我的错误直言不讳」}
- 禁忌：{如「不用敬语，不说废话，不空洞鼓励」}

我们的约定：{如「每次讨论聚焦一个问题，结束时给出3条可执行的建议」}

现在开始：{当前话题或问题}

使用注意：

• 人格特征的描述要具体、有操作性，避免空泛形容词
• 明确列出「禁忌」比正面描述更有效
• 约定条款是保持互动质量的锚点

---

类别二：结构化输出与格式控制

模板2.1：JSON结构化输出

功能描述：要求AI输出严格符合JSON格式的数据

适用场景：数据提取、API响应生成、配置文件生成、结构化记录

完整提示词：

请将以下内容转换为严格的JSON格式输出。

输入内容：
{原始文本}

输出要求：
- 只输出JSON，不包含任何解释性文字
- 字段定义：
  - {field1}：{类型}，{含义说明}
  - {field2}：{类型}，{含义说明}
  - {field3}：{类型}，{含义说明}
- 日期格式：ISO 8601 (YYYY-MM-DDThh:mm:ss+08:00)
- 枚举值限定：{如 status 仅可取 "active"|"inactive"|"pending"}
- 如遇无法识别的字段，值设为null，不跳过字段

示例输出：
{
  "field1": "示例值",
  "field2": 123,
  "field3": null
}

使用注意：

• 明确要求「只输出JSON」，避免AI添加解释
• 给出完整的字段定义，包括类型和含义
• 提供示例输出作为格式锚点
• 对特殊格式（日期、枚举、嵌套结构）单独说明

---

模板2.2：分节式报告生成

功能描述：生成结构清晰、分节合理的长文档

适用场景：分析报告、技术文档、研究论文、方案设计

完整提示词：

请撰写一份关于{主题}的{文档类型，如「技术选型报告」「市场分析」}。

目标读者：{读者画像，如「技术总监」「非技术背景的决策者」}
文档长度：{如「3000-5000字」}
核心结论：{必须包含的核心观点}

文档结构（严格按此结构撰写）：

# 摘要
- 3-5句话概括核心发现和建议
- 读者读完摘要即可了解全貌

# 背景与问题
- 问题的起源和上下文
- 现状描述与痛点分析

# 分析方法
- 采用的分析框架和方法论
- 关键假设与数据来源
- 分析过程的可复现性说明

# 详细分析
- 分点展开，每点配具体论据
- 对关键结论提供数据支撑
- 标注不确定性和待验证点

# 结论与建议
- 核心结论（按优先级排序）
- 可执行的行动建议（短期/中期/长期）
- 风险预判与应对策略

# 附录
- 参考资料
- 方法论细节
- 原始数据摘要

使用注意：

• 给出完整的章节结构，AI会严格遵循
• 每个章节明确说明写作要点和要求
• 指定读者画像，控制术语密度和深度
• 核心结论前置，确保重点突出

---

模板2.3：表格与列表输出

功能描述：生成规范的表格或列表形式的输出

适用场景：对比分析、清单制作、数据整理、选项罗列

完整提示词：

请将以下信息整理为Markdown表格。

输入信息：
{原始内容}

输出要求：
- 列定义：
  - 列1：{列名}，{内容要求}
  - 列2：{列名}，{内容要求}
  - 列3：{列名}，{内容要求}
- 按{排序依据}排序
- 对每一行给出{评级方式，如「用⭐1-5标注优先级」}
- 如某字段信息缺失，填「—」
- 表格后追加一行「合计/汇总」

示例：
| 项目 | 优先级 | 预计工时 | 风险等级 |
|------|--------|----------|----------|
| 功能A | ⭐⭐⭐⭐⭐ | 2天 | 低 |
| 功能B | ⭐⭐⭐ | 5天 | 中 |
| **合计** | — | **7天** | — |

使用注意：

• 明确每列的内容要求和格式
• 指定排序方式，避免随机排列
• 示例比纯文字描述更有效
• 要求「缺失填—」避免空白或不一致

---

模板2.4：Markdown 结构化输出

功能描述：要求 AI 以规范的 Markdown 格式输出，适合博客文章、技术文档等需要层次分明、可读性强的场景

适用场景：博客撰写、技术文档生成、教程编写、知识库建设、README 文档

完整提示词：

请以下面的 Markdown 格式规范撰写{文章类型，如「技术教程」「技术博客」}，主题为：{主题}。

【Markdown 格式规范】

## 标题层级
- 使用 # 作为文章主标题（全文只有一个）
- 使用 ## 作为一级章节标题
- 使用 ### 作为二级小节标题
- 标题层级不超过三级，层级过多会降低可读性

## 文本排版
- 正文段落：每段不超过 4 行，段落之间用空行分隔
- 重点强调：用 **加粗** 标注关键概念和核心结论
- 代码块：指定语言类型（```python, ```bash, ```json 等）
- 引用：用 > 标注重要引述或提示信息
- 分隔线：用 --- 分隔不同主题的大段落

## 列表规范
- 无序列表：用 - 作为项目符号
- 有序列表：用 1. 2. 3. 作为序号
- 嵌套列表：缩进 2 个空格，不超过 2 层嵌套
- 任务列表：用 - [ ] 和 - [x] 表示待办和已完成

## 表格规范
- 表格必须有表头行和分隔行
- 对齐：数字右对齐，文本左对齐
- 避免过宽的表格（列数不超过 6 列）

## 链接与图片
- 链接格式：[链接文本](URL)
- 图片格式：![替代文本](图片URL)

## 特殊元素
- 提示框：用 > **⚠️ 注意** / > **💡 提示** / > **✅ 建议** 表示不同级别的提示
- 脚注：在正文用 [^1] 标注，文末附注脚内容

## 文章结构
1. 开头用 **开篇摘要**（3-4 句概括全文要点）
2. 主体内容按逻辑分节，节与节之间用 --- 分隔
3. 结尾用 **总结**（核心要点回顾 + 下一步行动建议）

【内容要求】
- 目标读者：{读者画像}
- 文章长度：{字数范围}
- 技术深度：{如「面向中级开发者，假设读者已掌握基础知识」}
- 代码示例：{如「每个概念至少配一个可运行的代码示例」}

使用注意：

• Markdown 格式规范的各项可根据实际需求增删，不必全部保留
• 「提示框」规范是提升文档专业感的利器，建议保留
• 文章结构中的「开篇摘要」确保读者快速了解全文价值
• 技术文档建议补充「环境要求」和「前置知识」小节
• 与模板 2.2（分节式报告）的区别：本模板侧重格式控制，模板 2.2 侧重内容结构

类别三：推理与分析引导

模板3.1：六步深度分析

功能描述：引导AI按结构化步骤进行深度分析

适用场景：复杂问题分析、决策思考、根因诊断、方案评估

完整提示词：

请按以下六个步骤分析{分析对象}：

第一步：定义问题
- 用一句话精确描述要分析的问题
- 界定问题的边界：什么在范围内，什么不在
- 识别关键利益相关方

第二步：收集信息
- 列出分析此问题需要的关键信息
- 标注信息来源的可靠性
- 识别信息缺口和不确定性

第三步：拆解分析
- 将问题分解为{数量}个核心维度
- 对每个维度进行独立分析
- 识别维度间的关联和相互影响

第四步：生成假设
- 基于分析生成{数量}个可能的解释或解决方案
- 对每个假设给出支持和反对的论据
- 评估每个假设的可验证性

第五步：验证与评估
- 设计验证每个假设的方法
- 评估各方案的可行性、风险和收益
- 进行敏感性分析：关键参数变化时结论是否改变

第六步：结论与行动
- 给出最可能的结论（置信度：高/中/低）
- 推荐行动方案（按优先级排序）
- 列出需要进一步验证的问题

使用注意：

• 六步是通用框架，可根据具体问题增删步骤
• 每步都要求具体输出，而非笼统的「分析一下」
• 强制要求标注置信度，避免过度自信
• 最后的「需验证问题」是质量保证的关键

---

模板3.2：对抗性思维（红队模式）

功能描述：让AI扮演反对者角色，主动找出方案中的漏洞

适用场景：方案评审、风险预判、辩论准备、逆向思维训练

完整提示词：

现在你是一位专业的红队分析师，职责是**尽可能找出以下方案的弱点、漏洞和盲区**。

待审查方案：
{方案内容}

你的审查维度：

1. 【逻辑漏洞】
   - 方案的核心假设是否成立？
   - 推理链路中是否有跳跃或矛盾？
   - 结论是否超出了论据支撑的范围？

2. 【执行风险】
   - 哪些环节最容易失败？
   - 关键依赖项的脆弱性如何？
   - 最坏情况是什么？发生概率多大？

3. 【遗漏场景】
   - 是否忽略了重要的边界情况？
   - 对手/反对者可能怎么利用漏洞？
   - 有哪些意料之外的连锁反应？

4. 【替代方案】
   - 有没有更简单的方案？
   - 有没有成本更低的路径？
   - 有没有思路完全不同的替代方案？

输出要求：
- 至少找出{数量}个具体问题
- 每个问题标注严重程度（高/中/低）
- 每个问题给出修正建议
- 最后给出整体评估：方案可否推进？需要哪些先决条件？

使用注意：

• 明确要求「尽可能找出弱点」，解除AI的「讨好倾向」
• 四个维度覆盖了从逻辑到执行的完整链条
• 要求至少找出N个问题，避免AI敷衍
• 最后要求整体评估，不能只批判不建设

---

模板3.3：苏格拉底式提问

功能描述：通过层层递进的提问引导用户自己发现答案

适用场景：思考辅助、决策支持、学习辅导、认知澄清

完整提示词：

现在起，你不直接给我答案，而是通过提问帮助我自己找到答案。

我的问题是：{用户的问题或困境}

你的提问规则：
1. 每次只问一个问题
2. 问题应该引导我思考之前没考虑到的角度
3. 问题按以下顺序递进：
   - 第一层：澄清现状（「具体是什么情况？」）
   - 第二层：探索动机（「为什么这件事对你重要？」）
   - 第三层：检验假设（「如果这个前提不成立，会怎样？」）
   - 第四层：考虑替代（「还有没有其他可能性？」）
   - 第五层：落实行动（「具体第一步能做什么？」）
4. 不评判我的回答，只基于回答提出更深的问题
5. 如果我卡住了，给一个具体的思考方向作为提示

现在开始第一个问题。

使用注意：

• 关键是「不直接给答案」的约束，防止AI忍不住剧透
• 五层提问框架保证思考的深度和完整性
• 允许用户说「提示一下」，避免卡死
• 适合深度思考场景，不适合需要快速答案的情况

---

模板3.4：思维链引导（Chain-of-Thought）

功能描述：要求 AI 在给出最终答案前，逐步展示完整的推理过程，使结论可追溯、可验证

适用场景：数学推理、逻辑判断、代码调试、复杂决策、因果分析

完整提示词：

请解决以下问题，并在给出答案前逐步展示你的推理过程。

问题：{具体问题}

推理要求：

1. 【理解问题】
   - 用自己的话复述一遍问题，确认理解正确
   - 识别问题中的关键条件和约束
   - 标注隐含假设（未明说但需要的前提）

2. 【拆解步骤】
   - 将解题过程拆分为 3-7 个有序步骤
   - 每个步骤明确说明：「这一步要做什么」「为什么需要做这一步」
   - 步骤编号：Step 1, Step 2, Step 3...

3. 【逐步推理】
   - 按拆分好的步骤逐一执行
   - 每步完成后，输出该步的中间结果
   - 如果某步遇到困难，说明「卡在哪里」「尝试了什么」「为什么行不通」

4. 【交叉验证】
   - 用至少一种不同于主推理路径的方式验证结论
   - 例如：反证法、代入验证、边界条件测试
   - 如果验证结果与主推理不一致，重新检查推理过程

5. 【最终答案】
   - 在推理末尾用「【最终答案】」明确标注结论
   - 附答案置信度评估（高/中/低）及简要说明
   - 标注推理链路中最薄弱的一环

输出格式：
<推理过程>
Step 1: ...
Step 2: ...
...
</推理过程>

【验证】
...

【最终答案】
{答案}
置信度：{高/中/低}，理由：{一句话说明}
最薄弱环节：{一句话说明}

使用注意：

• 对于简单问题（如常识问答），思维链反而显得冗余，应根据问题复杂度选择使用
• 「交叉验证」环节是思维链质量的关键——AI 可能在一遍推理中犯错，但用不同路径验证能有效提升准确率
• 置信度标注帮助你判断是否需要人工复核
• 数学和逻辑类问题最受益于思维链，事实类问题效果不明显

---

模板3.5：Few-shot 示例引导

功能描述：通过提供 2-3 个详细的输入-输出示例，锚定 AI 的输出格式、质量和风格

适用场景：文本分类、邮件撰写、客服回复、翻译、内容改写、代码风格统一

完整提示词：

请参照以下示例的风格、格式和质量标准，完成后续任务。

【任务说明】
{一句话描述任务，如「将用户反馈分类为：Bug报告 / 功能请求 / 使用咨询」}

【示例1】
输入：{示例输入1}
输出：
{示例输出1}

【示例2】
输入：{示例输入2}
输出：
{示例输出2}

【示例3】（可选）
输入：{示例输入3}
输出：
{示例输出3}

【示例设计要点】（供你理解，你的输出中不需要重复这些）
- 以上示例的共同特征：
  - 格式特点：{如「统一使用 3 段式结构：判断 → 理由 → 建议」}
  - 语言风格：{如「正式但不生硬，避免术语堆砌」}
  - 输出长度：{如「每条回复不超过 150 字」}
  - 特殊处理：{如「遇到无法归类的情况，归类为 Other 并附说明」}

【现在开始】
请对以下输入，按照上述示例的格式和质量标准处理：

{实际输入}

使用注意：

• 示例的质量远比数量重要。2 个高质量示例优于 5 个平庸示例
• 示例应覆盖正常情况和边界情况，让 AI 了解边界处理方式
• 「示例设计要点」帮助 AI 理解示例中的隐含规则，是提示词中的隐性质量杠杆
• 示例输入与输出之间的映射关系越清晰，AI 的学习效果越好
• 如果输出格式非常严格（如 JSON），示例是比文字描述更有效的格式锚定手段
• Few-shot 与模板 5.2（多方案对比）的区别：本模板是「给示例学范式」，模板 5.2 是「要 AI 主动生成多个方案」

类别四：约束控制与安全护栏

模板4.1：多维度约束锁定

功能描述：通过多维度约束精确控制AI的输出边界

适用场景：敏感内容生成、合规写作、特定格式需求、受控创作

完整提示词：

请生成{输出类型}，需严格遵守以下约束：

【内容约束】
- 必须包含：{必须包含的要点列表}
- 绝对禁止：{禁止出现的内容，如特定词汇、观点、场景}
- 敏感词处理：{如「遇到'XX'时替换为'YY'」}

【风格约束】
- 语气：{如「客观中立、不带情绪」}
- 用词：{如「专业术语不解释，不用口语化表达」}
- 人称：{如「使用第三人称」}
- 时态：{如「使用现在时」}

【格式约束】
- 字数：{如「1000-1200字」}
- 段落：{如「每段不超过150字」}
- 标题：{如「使用二级标题，不超过3个」}
- 引用：{如「所有数据标注来源，使用脚注」}

【结构约束】
- 必须遵循{结构模式，如「问题-分析-结论」}
- 不得出现：{如「反问句、感叹句、第一人称」}

现在开始生成：{主题}

使用注意：

• 四类约束覆盖了从内容到形式的完整维度
• 「绝对禁止」比「应该避免」约束力更强
• 给出具体的字数/段落/标题数字，而非「适当」「适中」
• 对敏感词给出明确的替换规则

---

模板4.2：分步确认与回滚

功能描述：在关键决策点设置确认机制，防止AI一路跑偏

适用场景：长文档生成、多步骤任务、不可逆操作、高风险决策

完整提示词：

我们将分{数量}步完成{任务目标}。每完成一步，你暂停并等待我的确认。

当前步骤：第1步 — {具体步骤描述}
本步骤产出：{预期输出}
确认标准：{我确认时会检查什么}

如果我的回复包含「继续」，进入下一步。
如果我的回复包含「修改」，按我的反馈调整当前步骤。
如果我的回复包含「重来」，重置到本步骤起点。
如果我的回复包含「终止」，立即停止并输出已完成的内容。

开始执行第1步。

使用注意：

• 适合长流程，但每步暂停会比较耗时
• 明确定义确认标准，避免双方理解不一致
• 四种控制指令（继续/修改/重来/终止）覆盖了大部分场景
• 第1步的描述必须足够详细，作为后续步骤的范式

---

模板4.3：安全边界声明

功能描述：明确划定AI的能力边界和安全红线

适用场景：敏感话题讨论、专业建议、涉及决策的场景

完整提示词：

在开始之前，我们先明确几个约定：

1. 【能力边界】
   - 你可以做：{如「提供技术方案、代码示例、分析思路」}
   - 你不可以做：{如「给出医疗诊断、法律判决、投资建议」}
   - 超出能力范围时：{如「明确告知'此问题超出我的能力边界'，并建议咨询专业人士」}

2. 【信息处理】
   - 不编造信息：{如「如果不确定，说'我不确定'而非编造答案」}
   - 标注不确定性：{如「对有争议的观点标注'存在不同看法'」}
   - 区分事实与观点：{如「事实用陈述语气，观点用'我认为''可能'等限定词」}

3. 【敏感话题】
   - 涉及{敏感领域}时：{如「保持中立，不偏袒任何一方」}
   - 涉及{敏感领域}时：{如「提供多个视角，不做价值判断」}

4. 【免责声明】
   - 你的输出是{如「技术参考」}，不能替代{如「专业判断」}
   - 最终决策由我做出

确认以上约定后，我们开始讨论：{话题}

使用注意：

• 边界声明让AI在遇到敏感问题时有明确的行为准则
• 区分「可以做」和「不可以做」，而非只说「注意安全」
• 要求AI在超限时给出特定回应，而非沉默或胡乱回答
• 适合需要长期合作的场景，建立信任基础

---

类别五：迭代优化与反馈循环

模板5.1：差异对比优化

功能描述：基于AI的输出，针对性地提出修改意见进行迭代

适用场景：文案精修、代码优化、方案迭代、内容打磨

完整提示词：

这是你之前生成的内容：

【原始输出】
{AI之前的回复}

这是我的修改意见：

【修改点1】
位置：{如「第2段第3行」}
问题：{如「论据不够充分」}
期望：{如「补充具体的数据支撑」}

【修改点2】
位置：{如「结论部分」}
问题：{如「语气过于绝对」}
期望：{如「改为保守表述，标注不确定性」}

修改要求：
- 只修改指出的部分，其余内容保持不变
- 修改后用「【修改处】」标注变动位置
- 简要说明每处修改的思路

现在开始修改。

使用注意：

• 明确指出「位置+问题+期望」，而非笼统的「改一下」
• 要求只改指定部分，避免AI过度修改
• 标注修改位置便于核对
• 要求说明修改思路，促进双方理解

---

模板5.2：多方案对比生成

功能描述：要求AI针对同一问题生成多个不同风格或路径的方案

适用场景：创意发散、方案比选、头脑风暴、探索可能性

完整提示词：

请针对{问题/需求}，生成{数量}个截然不同的方案。

每个方案需包含：
- 方案名称（体现核心思路）
- 核心思路（一句话概括）
- 详细内容（具体执行步骤）
- 优点分析
- 缺点分析
- 适用场景

方案差异要求：
- 方案间的核心思路必须有本质区别
- 可以从以下维度制造差异：
  - 技术路径（如「传统方法vs. AI方法」）
  - 资源投入（如「零成本vs. 高投入」）
  - 时间周期（如「快速见效vs. 长期布局」）
  - 风险等级（如「低风险稳健vs. 高风险高回报」）

最后，给出你推荐的方案及理由。

使用注意：

• 强制要求「截然不同」，避免AI生成同质化方案
• 给出制造差异的维度，引导发散方向
• 每个方案的六要素保证可比性
• 最后的推荐方案帮助决策

---

模板5.3：质量闭环自检

功能描述：要求AI在输出前进行自我质量检查

适用场景：关键内容生成、交付前检查、长期一致性维护

完整提示词：

请完成以下任务，并在最终输出前执行质量自检：

任务：{具体任务}

自检清单（在内部完成，不需展示自检过程）：

1. 【完整性检查】
   - 是否覆盖了所有要求的要点？
   - 是否有遗漏的约束条件？
   - 格式是否符合要求？

2. 【准确性检查】
   - 事实性陈述是否准确？
   - 数据和引用是否正确？
   - 是否有自相矛盾的内容？

3. 【质量检查】
   - 逻辑是否清晰？
   - 表达是否流畅？
   - 是否有冗余或重复？

4. 【安全检查】
   - 是否包含敏感内容？
   - 是否违反了之前约定的边界？
   - 是否有潜在的误导性信息？

如果自检未通过，在内部修正后再输出。
如果自检通过，直接输出最终结果。

现在开始执行任务。

使用注意：

• 要求「内部完成自检，不需展示过程」，避免干扰输出
• 四类检查覆盖了完整性、准确性、质量、安全四个维度
• 明确「未通过则修正」，形成质量闭环
• 适合对输出质量有高要求的场景

---

四、高级技巧

4.1 提示词组合策略

高级用户通常将多个模板组合使用，形成更强的提示词：

组合一：角色设定 + 结构化输出

（模板1.1 领域专家角色）+（模板2.1 JSON结构化输出）
→ 效果：专家角色以JSON格式输出专业分析结果
→ 适用场景：需要机器可读的专业判断

组合二：多角色协同 + 对抗性思维

（模板1.2 多角色协同）+（模板3.2 红队模式）
→ 效果：多位专家从反对者视角交叉审查方案
→ 适用场景：高风险方案的最终评审

组合三：六步分析 + 苏格拉底式提问

（模板3.1 六步深度分析）+（模板3.3 苏格拉底式提问）
→ 效果：AI按六步框架分析，同时用提问引导用户参与
→ 适用场景：需要用户参与决策的复杂分析

组合四：约束锁定 + 质量闭环

（模板4.1 多维度约束锁定）+（模板5.3 质量闭环自检）
→ 效果：严格约束下的高质量输出
→ 适用场景：合规文档、正式交付物

4.2 迭代优化方法论

单次提示很难一次到位，掌握迭代方法论比任何模板都重要：

三轮迭代法：

轮次	目标	操作
第一轮	建立基线	用基础模板生成初版，不追求完美
第二轮	定向精修	对照修改意见，用差异对比模板精修
第三轮	整体润色	用质量闭环模板做最终检查

迭代原则：

• 每轮只关注一个维度（内容/风格/格式）
• 保留确认过的部分，只修改问题部分
• 每次修改量不超过20%，避免推倒重来
• 记录有效的修改模式，形成个人优化手册

4.3 复杂任务的提示词构建

对于复杂任务（如撰写一份完整的技术方案、设计一套系统架构），提示词的构建需要更系统的思路：

分阶段构建法：

阶段一：需求对齐
  → 用苏格拉底式提问（模板3.3）澄清核心需求
  → 输出：需求确认文档

阶段二：方案设计
  → 用多方案对比（模板5.2）生成3个候选方案
  → 用红队模式（模板3.2）评估各方案风险
  → 输出：候选方案对比报告

阶段三：详细设计
  → 选定方案后，用分节式报告（模板2.2）撰写详细设计
  → 每章完成后用分步确认（模板4.2）进行检查
  → 输出：完整设计文档

阶段四：质量保证
  → 用质量闭环（模板5.3）做最终检查
  → 用多维度约束（模板4.1）确保合规性
  → 输出：交付物

4.4 上下文窗口优化

当任务涉及大量上下文时，需要优化提示词的信息密度：

策略一：信息分层

• 关键指令：放在提示词开头和结尾（注意力最集中的位置）
• 背景信息：放在中间，用分隔线或标签区分
• 参考资料：用附录形式标注，不需要AI完全吸收

策略二：摘要驱动

• 先让AI对长文本生成摘要
• 基于摘要进行后续任务
• 避免一次性将大量原文塞入上下文

策略三：分步加载

• 第一步：加载核心上下文，完成初步分析
• 第二步：追加细节信息，深化分析
• 第三步：补充边缘信息，完善方案

4.5 树状思维（Tree-of-Thoughts, ToT）

树状思维（ToT）是一种将推理过程从线性推进升级为树状探索的高级提示词技术。与思维链（CoT）的核心区别在于：CoT 是单路径线性推进，而 ToT 在每个决策节点生成多个候选分支，评估各分支前景后进行剪枝，必要时回溯到上游节点探索其他路径，最终收敛到全局最优解。

4.5.1 ToT 与 CoT 的本质区别

维度	CoT（思维链）	ToT（树状思维）
推理结构	线性链式	树状分支
路径数量	单路径	多路径并行+剪枝
纠错机制	发现错误只能从头重来	回溯到上游节点即可换路
决策依据	逐步推导，无显式评估	每步有评估标准，择优前进
适用场景	确定性推理（数学、逻辑）	需要探索性搜索的任务
输出形态	一条完整的推理链	最优路径+被舍弃的分支记录

ToT 的核心优势在于将「搜索」引入推理过程。传统提示词让 AI 在看不到全局的情况下逐歩做出不可逆的决定，而 ToT 允许 AI 在关键节点「多想几步」，用评估机制筛选最有前途的方向。

4.5.2 适用场景

• 战略规划：多种商业路径的前瞻性评估与比选
• 创意发散：生成多个创意方向后筛选最优方案
• 多方案比选：技术选型、架构设计等需要系统性对比的任务
• 需要前瞻性评估的任务：任何「现在做的决定会影响后续所有步骤」的场景
• 复杂博弈：棋类、谈判策略等多步博弈场景

4.5.3 ToT 提示词构建方法

构建 ToT 提示词需要定义以下核心参数：

参数定义表：

参数	含义	典型取值	调优建议
B（分支宽度）	每个节点生成几个候选分支	3-5	太大导致发散，太小失去探索价值
D（探索深度）	最多向下探索几层	2-4	与任务复杂度成正比
E（评估标准）	用什么标准评估分支前景	可行性/成本/风险/创新性	标准需可量化，避免主观
P（剪枝策略）	保留几个最优分支继续	保留 Top-2 或 评分>阈值的	平衡探索与聚焦
R（回溯规则）	何时回溯、回溯到哪里	当前层无可行分支时回溯到上一层	设置最大回溯次数

构建步骤：

1. 识别分支点：找出任务中需要多选项决策的节点，在这些节点触发分支
2. 定义评估维度：每个分支用统一的评分维度评估，确保可比性
3. 设定剪枝阈值：低于阈值的分支直接舍弃，不再继续探索
4. 设计回溯触发条件：明确什么情况下应该回头换路
5. 保留探索轨迹：要求输出被舍弃分支及舍弃原因，保证可追溯性

4.5.4 完整 ToT 提示词模板

你需要使用树状思维（Tree-of-Thoughts）方法解决以下问题。

【任务】
{具体任务描述}

【ToT 参数设定】
- 分支宽度（B）：每个决策节点生成 {3-5} 个候选方案
- 探索深度（D）：最多向下探索 {2-4} 层
- 剪枝策略：每层保留评分最高的 {2} 个分支继续探索

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第一阶段：定义根节点与评估标准
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. 用一句话定义当前需要解决的核心问题（根节点）
2. 列出评估分支前景的标准，至少包含 {3-5} 个维度：

| 评估维度 | 评分权重 | 评分标准（1-10分） |
|----------|----------|---------------------|
| {维度1：如可行性} | {权重} | 1分=几乎不可行，10分=高度可行 |
| {维度2：如成本效益} | {权重} | 1分=成本远超收益，10分=收益远超成本 |
| {维度3：如风险可控性} | {权重} | 1分=风险不可控，10分=风险完全可控 |
| {维度4：如创新性} | {权重} | 1分=常规方案，10分=突破性方案 |
| {维度5：如可扩展性} | {权重} | 1分=一次性方案，10分=可复用 |

加权总分 = Σ(维度评分 × 权重)

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第二阶段：分支生成
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

在当前节点，生成 B={数量} 个候选方案，要求：

- 方案间的核心思路必须有本质区别
- 每个方案包含：
  - 方案名称（体现核心思路）
  - 核心思路（2-3句话）
  - 关键假设（该方案成立的前提条件）
  - 预期路径（后续可能的 2-3 步展开方向）
- 输出时用「【分支 N】」标注

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第三阶段：评估与剪枝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

对每个分支按评估标准逐一打分：

| 评估维度 | 分支1 | 分支2 | 分支3 | 分支4 | 分支5 |
|----------|-------|-------|-------|-------|-------|
| {维度1} | /10 | /10 | /10 | /10 | /10 |
| {维度2} | /10 | /10 | /10 | /10 | /10 |
| ... | | | | | |
| **加权总分** | | | | | |

剪枝决策：
- 保留评分最高的 {2} 个分支进入下一层探索
- 被剪分支需说明舍弃原因：「【舍弃分支N】原因：{一句话说明为什么放弃}」

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第四阶段：回溯与收敛
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

回溯条件（满足任一即回溯）：
- 当前层所有保留分支的评分均低于阈值 {如 5分}
- 当前层所有保留分支都到达了死胡同（无合理下一步）
- 探索深度已达到 D={层数} 层

回溯规则：
- 回溯到最近一次有未被探索分支的上游节点
- 选择当时被剪枝中评分最高的分支重新探索
- 最多回溯 {2} 次，超过则选择此前所有路径中的最优解

收敛条件（满足即输出最终结论）：
- 某条路径已探索到第 D 层且评分最高
- 回溯次数耗尽
- 保留路径间评分差距 >2 分（有明显胜出者）

最终输出：
- 最优路径的完整推理链（从根节点到最终节点）
- 各层保留分支的评分汇总表
- 被舍弃分支的简要记录（分支名称+舍弃原因）
- 最终结论的置信度评估及仍存在的不确定性

4.5.5 使用注意事项

• 分支宽度不宜过大：B>5 时输出容易发散，AI 的评估质量也会下降。建议 3-4 个分支
• 评估维度需可量化：「好不好」无法打分，必须是「成本效益」「技术可行性」等可操作维度
• 剪枝阈值需合理：过低等于没剪枝，过高可能过早排除潜在最优解
• 回溯次数要限制：无限回溯会退化为暴力搜索，通常 2 次即可
• ToT 消耗的上下文较多：每个分支的详细描述 + 评估表 + 剪枝记录，建议用于中高复杂度任务，简单问题用 CoT 即可
• 与 CoT 不互斥：ToT 的每个分支内部仍可使用 CoT 进行逐步推理

4.6 图状思维（Graph-of-Thoughts, GoT）

图状思维（GoT）将推理建模为有向图结构：多条独立的推理路径各自产出完整结论，再通过交叉引用和融合机制生成综合输出。与 ToT 的关键区别在于：ToT 的路径间相互竞争、优胜劣汰（剪枝），而 GoT 的路径各自独立完成后再融合——无所谓谁赢谁输，每条路径都为最终答案做出贡献。

4.6.1 GoT 与 ToT 的本质区别

维度	ToT（树状思维）	GoT（图状思维）
路径关系	竞争关系，优胜劣汰	互补关系，各自贡献
路径终点	只有一条最优路径存活	所有路径都走到终点
融合方式	剪枝后只剩一条路径	多路径结论交叉融合
拓扑结构	树状（无环）	图状（允许路径间交叉引用）
适用场景	最优解搜索	多视角综合判断
核心操作	评估+剪枝	独立推理+融合+冲突消解

GoT 的优势在于处理需要「兼听则明」的任务：当单一推理路径可能因视角局限而产生偏见时，多条独立路径的结论相互校验、彼此补充，最终产出比任何单一路径都更全面稳健的综合判断。

4.6.2 适用场景

• 多源信息综合：来自不同渠道的信息需要交叉验证与整合
• 多专家视角融合：邀请不同领域的「虚拟专家」各自分析后综合
• 矛盾信息调和：面对相互矛盾的数据或观点，需要找出共识与分歧
• 复杂系统设计：多维度需求（性能/安全/成本/体验）各自独立分析后协调
• 风险评估：技术风险、商业风险、合规风险分别评估后汇总

4.6.3 GoT 提示词构建方法

参数定义表：

参数	含义	典型取值	调优建议
N（并行路径数）	独立推理路径的数量	3-5	太少失去多样性，太多融合困难
V（视角定义）	每条路径的分析视角或方法	每路径一个独特视角	路径间视角必须有本质区别
F（融合规则）	如何综合多条路径的结论	加权投票/取交集/调和	明确各路径权重或平等对待
C（冲突消解）	路径间结论矛盾时如何处理	标注分歧+降置信度+第三方仲裁	切勿强制调和矛盾

构建步骤：

1. 定义并行路径：为每条路径分配独立的分析视角、方法或前提假设
2. 独立推理：每条路径使用相同的信息基础，但采用不同的分析框架各自得出结论
3. 交叉引用：路径完成后，允许各路径引用其他路径的论据进行补充
4. 融合综合：将所有路径的结论进行系统整合，标注共识与分歧
5. 冲突消解：对矛盾结论不强行统一，而是标注分歧点及各自的置信度

4.6.4 完整 GoT 提示词模板

你需要使用图状思维（Graph-of-Thoughts）方法分析以下问题。

【任务】
{具体任务描述}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第一阶段：并行路径定义
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

请从以下 {3-5} 条独立推理路径分析此问题，每条路径使用不同的分析框架：

【路径A：{视角名称，如「技术可行性视角」}】
- 分析方法：{如「评估技术实现路径、依赖项成熟度、性能瓶颈」}
- 核心关注：{该路径最关注的 2-3 个核心问题}
- 假设前提：{该路径分析所依赖的关键假设}

【路径B：{视角名称，如「经济成本视角」}】
- 分析方法：{如「计算总拥有成本、ROI分析、隐性成本估算」}
- 核心关注：{该路径最关注的 2-3 个核心问题}
- 假设前提：{该路径分析所依赖的关键假设}

【路径C：{视角名称，如「风险合规视角」}】
- 分析方法：{如「识别风险点、评估影响范围、合规性检查」}
- 核心关注：{该路径最关注的 2-3 个核心问题}
- 假设前提：{该路径分析所依赖的关键假设}

{可选路径D、E...}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第二阶段：独立推理
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

请每条路径独立完成以下分析（不要在不同路径间互相参考）：

对每条路径，输出：
- 【路径X 推理过程】：逐步推理，明确每一步的逻辑依据
- 【路径X 核心发现】：用 3-5 条要点概括该路径的核心发现
- 【路径X 结论】：该路径的综合结论（一句话）
- 【路径X 置信度】：高/中/低，并说明不确定性的来源
- 【路径X 边界条件】：该路径的适用边界（什么情况下结论可能失效）

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第三阶段：融合与综合
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

在所有路径完成独立推理后，进行融合分析：

1. 【共识识别】
   - 列出所有路径共同指向的结论（共识点）
   - 对每个共识点标注有多少条路径支持（如 3/4 路径）
   - 评估共识的牢固程度：强共识（全路径一致）/ 弱共识（多数路径一致但有分歧）

2. 【分歧标注】
   - 列出路径间存在明显分歧的结论
   - 分歧矩阵：
     | 分歧议题 | 路径A立场 | 路径B立场 | 路径C立场 | 分歧根源 |
     |----------|-----------|-----------|-----------|----------|
     | {议题1} | {立场} | {立场} | {立场} | {假设差异/信息差异/方法论差异} |

3. 【冲突消解策略】
   - 对每个分歧议题，按以下优先级处理：
     a. 追溯分歧根源：是因为假设不同、信息不同还是方法论不同？
     b. 如果假设不同：指出哪些假设更稳健，基于更稳健假设的结论优先
     c. 如果信息不同：标注信息缺口，建议补充哪些信息可以消除分歧
     d. 如果方法不同：说明每种方法的适用场景，不做优劣判断
   - 分歧结论标注：「此结论存在分歧，置信度降为低，建议在{条件}下重新评估」

4. 【综合结论】
   - 基于共识+分歧分析，给出综合判断
   - 综合置信度评估及主要不确定性来源
   - 按优先级排序的行动建议：
     - 立即可执行的（基于共识）
     - 需要进一步验证的（基于分歧）
     - 观望等待的（基于高不确定性）

4.6.5 使用注意事项

• 路径间需有本质差异：如果两条路径用类似的方法分析，「并行」就失去了意义。确保每条路径的分析框架、核心关注点、假设前提有明显区别
• 路径数不超过 5：路径太多会导致融合阶段过于复杂，AI 可能无法有效处理交叉引用
• 融合不是求平均：不要简单地对各路径结论取平均或投票。好的融合应该解释为什么不同路径得出不同结论，以及每种结论在什么条件下成立
• 冲突不强行消解：如果两条路径基于不同的合理假设得出了不同结论，正确的做法是「标注分歧+说明成立条件」，而非强行统一
• GoT 消耗的上下文比 ToT 更大：每条路径都需要完整的推理链+结论，适合有高价值决策需求的场景

4.6.6 GoT 与「多角色协同」模板（1.2）的互补关系

GoT 与本文模板 1.2「多角色协同」在思路上有相似之处，但本质不同：

维度	模板1.2 多角色协同	4.6 GoT（图状思维）
并行层次	角色级并行：不同职业/身份的人	推理路径级并行：不同的分析框架/方法论
融合方式	综合各专家的独立判断	交叉引用+冲突消解+共识矩阵
结构化程度	较低（各角色自由发挥）	较高（三个阶段、明确参数）
适用深度	多视角评审、决策分析	需要结构化冲突消解和可追溯性的深度分析

两者可以组合使用：将 GoT 的每条推理路径分配给模板 1.2 中的不同专家角色，实现「角色级 + 推理路径级」的双层并行。

4.7 元认知提示（Metacognitive Prompting, MP）

元认知提示（MP）是当前已知保真度最高的提示词技术之一。它引导 AI 在回答前先显式陈述自己对问题的理解、形成初步判断、主动批判性地审视该判断的漏洞、最后给出经过自省修正的最终答案。这种「先理解→再判断→后自疑→终修正」的认知闭环，模拟了人类专家面对复杂问题时的深度思考过程。

4.7.1 MP 的四段式结构

理解陈述 → 初步判断 → 批判审视 → 最终答案
    ↓           ↓           ↓           ↓
  「我听懂了什么」 「我倾向于怎么想」 「我的想法哪里可能错」 「修正后我认为」

每一步都要求 AI 输出可被外部审视的具体内容，而非在黑箱中完成。这使得整个推理过程完全透明，用户可以看到 AI 是如何从初始直觉走到最终结论的。

4.7.2 与普通「自检」的区别

维度	普通自检（如模板5.3）	MP（元认知提示）
时序	输出完成后检查	推理过程中嵌入
触发方式	被动纠错	主动质疑
作用对象	最终输出的质量	推理过程本身的合理性
深度	表面错误检查	深层假设检验
认知层次	纠错	元认知（对认知的认知）
可追溯性	低（不知道改了哪里）	高（每步修正都有记录）

普通自检像是在考试交卷前检查错别字和漏题，而 MP 像是在解题过程中不断反问自己「我的假设成立吗？」「有没有可能我想反了？」——前者抓表面的错，后者抓思考本身的偏。

4.7.3 适用场景

• 高风险的判断与决策：战略方向选择、重大投资决策、关键人事任免
• 法律/医疗/金融分析：涉及重大后果的专业领域，误判代价极高
• 需要极高准确率的关键任务：任何「错不起」的场景
• 存在认知偏见风险的任务：需要 AI 主动对抗确认偏误、锚定效应、过度自信
• 复杂系统故障诊断：根因分析中容易被表面症状误导的场景

4.7.4 完整 MP 提示词模板

你需要使用元认知提示（Metacognitive Prompting）方法回答以下问题。

【问题】
{具体问题}

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段一：理解陈述（Comprehension）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

在形成任何判断之前，先显式陈述你对问题的理解：

请回答以下问题（每个问题用 1-2 句话）：

1. 这个问题的核心是什么？（用你自己的话重新表述）
2. 问题中哪些信息是明确的？哪些是隐含的？
3. 问题的边界在哪里？（什么在范围内，什么不在）
4. 解决这个问题需要什么类型的信息或知识？
5. 你对这个问题领域的熟悉程度如何？（高/中/低，并诚实说明）

输出标签：【理解陈述】

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段二：初步判断（Initial Judgment）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

基于你当前的理解，形成初步判断：

请输出：
1. 你的初步结论（一句话）
2. 支撑这个结论的核心论据（3-5 条）
3. 你对这个初步结论的信心程度（1-10 分）
4. 形成此判断依赖的最关键假设（至少列举 2 个）

输出标签：【初步判断】

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段三：批判审视（Critical Self-Examination）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

这是最关键的一步。请主动批判性地审视你刚刚做出的初步判断。

逐项检查以下自问清单：

【假设检验】
- 阶段二中最关键的假设是否一定成立？在什么情况下会失效？
- 如果你最核心的假设被推翻，初步结论如何变化？
- 有没有你默认接受但实际未经检验的前提？

【反面论证】
- 如果你是反对者，会从哪些角度攻击这个初步结论？
- 是否存在与你的初步结论矛盾的证据或逻辑？
- 有没有一种完全不同的解释也能说明同样的事实？

【认知偏见自查】
- 你是否因为某个信息最先出现而赋予了过高权重？（锚定效应）
- 你是否倾向于寻找支持已有判断的证据而忽略反面证据？（确认偏误）
- 你是否高估了自己对问题的理解程度？（过度自信偏误）

【边界案例测试】
- 将问题的某个参数推向极端，你的结论是否仍然成立？
- 举出至少 1 个反例场景：在这个场景下，你的初步结论会失效

【信息缺口评估】
- 哪些信息如果现在有，会让你的判断更准确？
- 这些缺失信息的获取难度和成本如何？

输出标签：【批判审视】

━━━━━━━━━━━━━━━━━━━━━━━━━━━━
阶段四：最终答案（Final Answer）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━

在完成批判审视后，给出经过修正的最终答案：

请输出：
1. 最终结论（可能已修正或推翻了阶段二的初步判断）
2. 修正说明：「基于阶段三的审视，我将{原判断}修正为{新判断}，主要原因是{原因}」
   （如果结论未修正，说明为什么批判审视后认为原判断仍然成立）
3. 剩余不确定性：「即使在修正后，我仍然不确定的部分是{具体内容}」
4. 置信度：高/中/低，并说明主要不确定性来源
5. 使用建议：「此结论最适合在{条件}下使用，如果{条件变化}则需要重新评估」

输出标签：【最终答案】

4.7.5 使用注意事项

• MP 是耗时最长的提示词技术：四个阶段的完整展开需要大量 token 和时间。仅在真正需要高保真度的场景使用，不要对每个日常问题都套用
• 第三阶段是 MP 的灵魂：如果缩减 MP，宁可压缩其他阶段也不要压缩批判审视。正是这个主动自疑的环节让 MP 区别于所有其他技术
• 鼓励推翻初步判断：AI 有「自我一致」的倾向，可能不愿推翻阶段二的判断。在提示词中可以加强：「如果批判审视发现初步判断存在漏洞，推翻它是正确做法，而非错误」
• 适合作为最后一道质量防线：在其他分析方法（CoT、ToT、GoT）得出初步结论后，用 MP 做最终审视
• 输出较长，需要做好上下文管理：建议将 MP 作为独立的一次对话或在长对话的末尾使用

4.7.6 MP 与「质量闭环自检」模板（5.3）的关系

MP 与模板 5.3「质量闭环自检」互补而非替代：

维度	MP（4.7）	模板5.3 质量闭环自检
时机	推理过程中	输出完成后
深度	挑战推理假设和认知偏见	检查完整性、准确性、格式
对象	思维过程本身	输出产物
效果	可能推翻初步判断	修正表面错误

推荐叠加使用：

第一步：使用 CoT/ToT/GoT 进行主推理
第二步：使用 MP（4.7）对推理过程和结论做元认知审视
第三步：使用模板 5.3 对最终输出做表面质量检查

三者在认知层次上形成递进：推理 → 元认知 → 质量检查，构成完整的输出质量保障链路。

---

五、常见陷阱与反模式

提示词工程中，知道「不该做什么」往往比知道「该做什么」更有价值。本章梳理了实践中反复出现的五类典型陷阱，每类均包含现象识别、危害分析、避免方法和修复示例。

陷阱一：过度约束

现象描述：在提示词中堆砌大量约束条件——限制字数、限制格式、限制风格、限制内容、限制语气……每个维度都设定了苛刻的边界，最终形成了一个「寸步难行」的指令集。

危害分析：

• AI 在多重约束下变得「畏首畏尾」，输出僵硬、缺乏灵气
• 约束之间可能相互矛盾（如「简洁精准」+「每个概念配详细类比」），导致 AI 在冲突指令间反复摇摆
• 关键信息被大量约束指令稀释，AI 难以识别核心任务

避免方法：

• 约束分级：将约束分为「硬约束」（不遵守则输出不可用）和「软约束」（尽量遵守但可灵活调整），提示词中只保留硬约束
• 示例优先于约束：与其说「风格要简洁」，不如给一个简洁的示例——示例传达的信息比文字描述精准得多
• 约束上限：单次提示词中的约束条目不超过 5 条（不包括 JSON 字段定义等结构性约束），超过则拆分任务

修复示例：

❌ 过度约束（避免）：

请写一篇 800-850 字的文章。必须是科技博客风格。每段 100-150 字。
使用至少 3 个小标题。每个小标题下的段落数必须为 2-3 段。
不得使用被动语态。不使用超过 20 字的句子。必须引用 3 个以上数据。
语气要专业但不失亲和力。面向中级读者……

✅ 精简约束（推荐）：

请写一篇面向中级技术读者的文章，风格参考 InfoQ 技术博客。
核心约束：800 字左右，结构清晰，每节配至少一个具体案例。
其余可自由发挥。

---

陷阱二：角色漂移

现象描述：在长对话中，初始设定的角色（如「你是资深安全工程师」）随着对话轮次增加逐渐「退化」——AI 慢慢回到默认的「通用助手」模式，回答质量从专业级滑落到常识级。

危害分析：

• 对话越长，角色越弱——这是当前大模型的普遍缺陷
• 用户可能在不知不觉中接收到质量降级的回答，直到某个回答明显「不对劲」才发现
• 在依赖角色设定的场景（如专家咨询、多角色协同）中，角色漂移直接导致输出不可用

避免方法：

• 角色锚点：每隔 5-8 轮对话，在输入中重新确认角色，格式如「（已确认：你仍然是 XX 专家角色）」
• 角色标签：在多轮对话中，每次输入前加一个简短的角色提示，如「[安全工程师视角] 请分析…」
• 重置策略：一旦发现角色漂移，不要试图在该对话中修复，而是重新开一个对话并粘贴完整的角色模板
• 缩短对话链：复杂长任务用模板 4.2（分步确认），将一个大对话拆分为多个小对话

修复示例：

❌ 角色漂移中的追问（效果差）：

第 12 轮追问：
「那你觉得这个 SQL 注入漏洞应该怎么修？」
→ AI 可能已经忘了自己是安全工程师，给出泛泛的「用参数化查询」建议

✅ 带角色锚点的追问（效果好）：

第 12 轮追问：
「[安全工程师 · 渗透测试方向] 以下是当前系统架构上下文（略）。
请从攻击面角度分析这个 SQL 注入漏洞的修复策略，考虑 WAF 层、代码层、数据库层三层防御。」
→ 角色锚点 + 上下文刷新，有效对抗角色漂移

---

陷阱三：上下文污染

现象描述：在提示词中塞入了大量与核心任务无关或弱相关的信息，导致关键指令被稀释、AI 被误导到错误的方向。

危害分析：

• AI 的注意力在长上下文中是衰减的，无关信息占用了宝贵的注意力预算
• 矛盾信息（如旧版需求和新版需求同时存在）让 AI 无所适从
• 过多的背景故事让 AI 不必要地「联想」到无关话题

避免方法：

• 前置修剪：写提示词前先问自己：「这段信息如果删掉，输出会变差吗？」如果答案是不会，就删掉
• 分层组织：按 4.4 节的「信息分层」策略，将关键指令前置，背景信息后置并标注
• 增量加载：长任务分步进行，每次只加载当前步骤需要的信息
• 清理残渣：如果使用之前的对话继续，只保留真正相关的上下文，其他清空

修复示例：

❌ 上下文污染（避免）：

我们公司三个月前启动了数字化转型项目，CTO 上周说要做微服务改造，
但实际上我们的业务量还没到那个规模。哦对了，上周还讨论了是否要
上 Kubernetes。不管怎样，当前的问题是用户登录接口偶发超时，
领导让看一下……（500 字背景铺垫）……请帮我设计一个高并发登录方案。

✅ 干净输入（推荐）：

任务：设计一个高并发登录方案。

当前环境：
- 技术栈：Spring Boot 3.x + Redis + MySQL
- 问题：登录接口 P99 延迟 2s，高峰期超时率 5%
- 目标：P99 < 500ms，支持 1000 QPS

请给出架构层面的优化方案，不需要讨论组织背景或长期规划。

---

陷阱四：过度信任

现象描述：对 AI 的输出不加验证即采纳，尤其是当 AI 输出看起来「自信」「流畅」「有说服力」时，容易产生「看起来很对就是对的」的错觉。

危害分析：

• AI 会「自信地犯错」——编造数据、虚构引用、错误推理，但语气却斩钉截铁
• 在专业领域，一个被忽略的错误可能产生连锁反应
• 长期不验证会削弱个人的判断力，形成「AI 依赖症」

避免方法：

• 强制验证习惯：对于事实性陈述（数据、人名、日期、引用）、代码逻辑、数学计算，一律手动验证或交叉查询
• 置信度机制：所有分析类任务强制要求 AI 标注置信度（模板 3.1），对「低」和「中」置信度的输出进行额外审查
• 红队习惯：对重要输出自动用模板 3.2（对抗性思维）做一次反向审查——「如果这个结论是错的，最可能错在哪里？」
• 外部验证：对于专业领域的结论，至少用一次独立搜索或查阅权威来源进行交叉验证

修复示例：

❌ 盲目信任（风险行为）：

用户：帮我查一下 Redis 7.0 的新特性
AI：（输出一个看似全面的列表）
用户：好的，就按这个做技术选型报告 → 直接采纳

✅ 验证后采纳（推荐流程）：

用户：帮我查一下 Redis 7.0 的新特性，标注信息来源和置信度
AI：（输出含置信度的列表）
用户：对中低置信度条目逐一搜索验证 → 修正 2 处错误 → 纳入报告

---

陷阱五：一次性思维

现象描述：期望通过精心设计一个「终极提示词」一次到位地得到完美结果，拒绝迭代或认为迭代是「提示词设计能力不足」的表现。

危害分析：

• 单次提示的上限受限于上下文窗口和模型能力，复杂任务天然需要多轮交互
• 花在「雕琢完美提示词」上的时间往往远超「快速生成 + 多轮迭代」的时间
• 拒绝迭代会错过从 AI 输出中发现新角度、新思路的机会——迭代不只是修正错误，更是激发创意

避免方法：

• 先跑再改：用基础模板快速生成初版，即使只有 60 分，也比空白好 100 倍
• 三轮迭代法：严格遵循 4.2 节的三轮迭代法——基线 → 精修 → 润色，每轮聚焦一个维度
• 拥抱不完美：把第一版输出视为「讨论的基础」而非「交付物」，降低心理预期
• 记录迭代收益：每次迭代后记录改进了什么，积累数据后会发现迭代的复利效应远超一次到位

修复示例：

❌ 一次性思维（低效）：

第 1 小时：反复修改提示词，追求一步到位
第 1.5 小时：终于生成一个「满意」版本
总耗时：1.5 小时 | 结果：一个版本

✅ 快速迭代（高效）：

前 5 分钟：用基础模板生成初版（60 分）
第 5-15 分钟：一轮精修（定位 3 个具体问题，定向修改）→ 80 分
第 15-25 分钟：二轮精修（润色语言风格）→ 90 分
第 25-30 分钟：质量自检（修复 2 个小问题）→ 95 分
总耗时：30 分钟 | 结果：一个更强的版本 + 可复用的迭代经验

---

5.1 陷阱自检清单

每次使用提示词前，用以下清单快速扫描：

• 约束是否精简？是否只保留了必要的硬约束？
• 长对话中是否需要角色锚点刷新？
• 上下文是否干净？有没有可以删除的无关信息？
• 重要输出是否设计了验证环节？
• 是否预留了迭代空间？第一版不必完美？

六、案例分析

案例一：技术方案评审

普通提示：

帮我看看这个技术方案有没有问题。

优化提示（模板1.2 + 模板3.2 组合）：

三位专家协同评审以下技术方案，每位专家独立分析，最后综合：

【专家A】架构师 · 10年分布式系统经验
- 关注点：技术可行性、性能瓶颈、可扩展性

【专家B】安全工程师 · 8年应用安全经验
- 关注点：攻击面、数据保护、合规要求

【专家C】DevOps工程师 · 6年云原生经验
- 关注点：部署复杂度、运维成本、故障恢复

待评审方案：
{方案内容}

输出要求：
1. 三位专家各自的独立评审（标注专家身份）
2. 各专家发现的Top 3问题（按严重程度排序）
3. 专家间的共识与分歧
4. 综合评审结论：方案可否推进？需要哪些改进？
5. 红队视角：如果我是对手，会如何攻击这个方案？

效果对比：

维度	普通提示	优化提示
视角数量	1个（泛泛的AI）	4个（3专家+红队）
问题覆盖	随机	架构/安全/运维/攻击四个维度
输出结构	无结构	5部分结构化输出
可执行性	低（不知改什么）	高（按优先级排序的改进清单）

---

案例二：数据提取与结构化

普通提示：

帮我从这段文本里提取关键信息。

优化提示（模板2.1 JSON结构化输出）：

请从以下会议纪要中提取关键信息，输出为严格的JSON格式。

输入文本：
{会议纪要内容}

输出结构：
{
  "meeting": {
    "date": "ISO 8601日期",
    "attendees": ["姓名1", "姓名2"],
    "topic": " string, 会议主题",
    "decisions": [
      {
        "content": "string, 决策内容",
        "owner": "string, 负责人",
        "deadline": "string, 截止日期(ISO 8601)",
        "priority": "string, 枚举: high|medium|low"
      }
    ],
    "action_items": [
      {
        "content": "string, 行动项",
        "owner": "string, 执行人",
        "deadline": "string, 截止日期",
        "status": "string, 枚举: pending|in_progress|completed"
      }
    ],
    "risks": ["string, 风险描述"]
  }
}

规则：
- 只输出JSON，不附加任何解释
- 无法识别的字段值设为null
- 日期统一为ISO 8601格式
- 每个决策必须有负责人和截止日期
- 行动项按截止日期排序

效果对比：

维度	普通提示	优化提示
输出格式	自由文本	严格JSON
信息完整性	可能遗漏	字段强制要求
可处理性	需手动整理	可直接导入数据库
质量保证	无	枚举值限制、排序规则、null处理

---

案例三：深度分析与决策支持

普通提示：

我该不该跳槽？帮我分析一下。

优化提示（模板3.1 六步深度分析 + 模板3.3 苏格拉底式提问）：

请按六步法分析我的跳槽决策，并在分析后用苏格拉底式提问帮助我深入思考。

【六步分析框架】

第一步：定义问题
- 精确描述：我面临的跳槽决策是什么？
- 边界：哪些因素在决策范围内，哪些不在？
- 利益相关方：谁会受到这个决策的影响？

第二步：收集信息
- 分析此决策需要的关键信息
- 我已有的信息 vs. 缺失的信息
- 信息的可靠性评估

第三步：多维度分析
- 从以下维度分析：
  - 职业发展（短期/中期/长期）
  - 经济收益（薪资、福利、股权）
  - 工作环境（团队、文化、节奏）
  - 风险因素（行业、公司、个人）
  - 个人价值（使命感、成就感、成长）

第四步：生成假设
- 假设A：跳槽是正确选择 → 支持论据/反对论据
- 假设B：留下是正确选择 → 支持论据/反对论据
- 假设C：等待观望 → 支持论据/反对论据

第五步：验证评估
- 各假设的可验证性
- 最坏情况分析
- 机会成本分析

第六步：结论行动
- 最可能的结论（置信度）
- 推荐行动方案
- 需要进一步验证的问题

【苏格拉底式提问】
完成六步分析后，不要直接给结论，而是通过3-5个问题引导我自己找到答案。
每个问题聚焦一个我之前可能没考虑到的角度。

效果对比：

维度	普通提示	优化提示
分析深度	表面	六步结构化深度
客观性	AI可能偏向	多假设+正反论据
参与度	被动接受	苏格拉底式引导思考
可执行性	模糊建议	分假设的行动方案
后续价值	一次性	可复用于未来决策

---

七、方法论摘录

本章节摘录若干具有普遍适用价值的方法论描述。这些段落以高度结构化、可移植的方式表达「如何处理一类问题」，既可作为提示词的引言段落直接使用，也可作为思考框架独立参考。每一条都遵循「目标—过程—产出」的完整链路。

7.1 对话内容系统化分析与记忆持久化

对用户对话内容进行系统性分析与处理，提取其中关键信息、核心观点、重要事件及用户偏好等重要内容。将提炼后的信息进行结构化整理，确保信息的准确性、完整性和可检索性，并安全、持久地保存到记忆系统中。建立有效的索引机制，以便后续能够快速、准确地调用和应用这些记忆信息。

方法论拆解：

环节	操作	产出标准
信息提取	识别关键信息、核心观点、重要事件、用户偏好	覆盖度≥95%，无遗漏
结构化整理	按类别归档，建立字段定义	字段清晰、可检索
持久化保存	写入记忆系统，避免丢失	安全、可恢复
索引机制	建立关键词、标签、时间等多维索引	检索响应<1秒
调用应用	后续对话中自动加载相关记忆	上下文连贯

作为提示词使用时的模板：

请对以下对话内容进行系统性分析与处理：

【对话内容】
{对话文本}

处理流程：
1. 信息提取：识别关键信息、核心观点、重要事件、用户偏好
2. 结构化整理：按类别归档，确保准确性、完整性、可检索性
3. 索引建立：为每条信息标注关键词、类别、时间戳
4. 持久化建议：给出可保存到记忆系统的格式（如JSON）

输出要求：
- 结构化数据（含字段定义）
- 检索索引（关键词+类别标签）
- 调用建议（在什么场景下应该调用哪些记忆）

7.2 复杂问题的分解与逐层求解

面对复杂问题时，避免直接求解，而应将问题分解为可独立处理的子问题，逐层求解后再综合。每个子问题应有明确的输入、输出和验证标准，确保求解过程的可追溯性和可验证性。

方法论拆解：

复杂问题 → 分解为N个子问题 → 每个子问题独立求解 → 验证子解 → 综合求解 → 整体验证

关键原则：

• MECE原则：子问题间相互独立、完全穷尽
• 可验证性：每个子问题都有明确的完成标准
• 可追溯性：求解路径可回溯，便于定位错误
• 层级控制：分解深度以3-5层为宜，过深会增加综合难度

7.3 多源信息的交叉验证

当信息来自多个来源时，单一来源不可信。需通过交叉验证识别信息的不一致之处，评估各来源的可信度，最终综合得出可靠性更高的结论。

验证维度：

维度	验证方法	判断标准
事实性	多来源对比	三方以上一致则采信
逻辑性	内部一致性检查	无自相矛盾
时效性	时间戳对比	采用最新信息
权威性	来源资质评估	优先采纳权威来源
完整性	信息缺口分析	标注缺失部分

7.4 迭代式优化的反馈闭环

任何一次性的产出都难以达到最优。应建立「生成—评估—反馈—修正」的闭环，通过多轮迭代逐步逼近最优解。每轮迭代聚焦一个维度的改进，避免全面推倒重来。

闭环结构：

生成初版 → 评估（多维度打分）→ 识别问题 → 反馈修改 → 验证改进 → 进入下一轮

迭代控制原则：

• 每轮只改一个维度（内容/结构/风格/格式）
• 单轮修改量不超过总量20%
• 保留已确认的部分，只动问题部分
• 设定最大迭代次数（通常3-5轮），避免无限优化
• 每轮记录修改模式，形成可复用的优化手册

7.5 任务的可复现性保障

任何分析、决策、生成都应具备可复现性。即他人依据相同的方法、输入和条件，能够得到相同或高度相似的结论。可复现性是建立信任的基础，也是知识沉淀的前提。

保障要素：

1. 方法透明：明确说明采用的分析框架和步骤
2. 输入完整：保留所有原始输入和上下文
3. 参数记录：记录所有可调参数的具体取值
4. 随机性控制：对涉及随机的过程固定随机种子
5. 版本管理：对方法和输入的变更进行版本追踪
6. 环境说明：记录工具、模型、配置等环境信息

7.6 知识的体系化沉淀

零散的知识点价值有限，体系化的知识才能产生复利。应将每次实践中获得的经验、模式、教训进行结构化沉淀，形成可检索、可复用、可演进的知识体系。

沉淀路径：

单次实践 → 模式识别 → 抽象提炼 → 结构化表达 → 分类归档 → 索引建立 → 持续更新

沉淀标准：

• 可检索：通过关键词、标签、场景等多维度可查到
• 可复用：抽象到足够通用的层次，不局限于单一场景
• 可演进：预留扩展接口，允许后续补充和修正
• 可验证：每条知识都关联具体的实践案例作为佐证

---

7.7 信息不对称的桥接策略

桥接策略

当 AI 和用户掌握不同的信息时，提示词的质量会大打折扣——用户以为 AI 知道但 AI 其实不知道，或者 AI 基于通用知识给出回答但用户需要的是特定场景的答案。信息不对称是提示词失效的隐性根源之一。

方法论拆解：

三类信息不对称及桥接策略：

不对称类型	典型表现	桥接策略
用户知道但 AI 不知道	用户未提供具体场景、约束、数据。AI 给出看似正确但场景不适配的答案	上下文显式化：把脑子里「以为 AI 知道」的信息写进提示词。遇到 AI 回答偏离预期时，先问自己：「我说清楚这个前提了吗？」
AI 知道但用户不知道	AI 的训练数据中包含该信息。用户的提问方式让 AI 无法「意识到」该信息相关	知识激活式提问：在提示词中明确要求 AI 关联特定领域的知识。例如「基于你对 XX 架构的理解，分析…」而非「分析一个架构问题」
双方都只知道部分	复杂跨领域问题。用户只了解部分事实，AI 的通用知识只能覆盖部分视角	对话式对齐：先用苏格拉底式提问（模板 3.3）澄清双方的信息边界，识别「已知已知」「已知未知」「未知未知」三类区域，再基于对齐后的信息集进行推理

桥接的核心原则：

• 宁可多给，不可假设：在信息不确定时，多提供上下文（含标注不确定），而非假设 AI 知道
• 显式声明盲区：在提示词中明确标注「以下信息我无法确认」「这一部分需要 AI 自行判断」——这样做反而让 AI 输出更诚实
• 双向校准：如果在 AI 回答中发现「语气肯定但内容存疑」，发起一轮信息对齐确认，而非直接采信或直接否定

作为提示词使用时的模板：

在开始之前，请先确认你对以下信息的掌握程度：

【用户提供的信息】
{列出你确定的事实，附数据来源}

【需要 AI 基于知识判断的部分】
{列出期望 AI 自行补充的内容，如「XX 领域的最佳实践」「YY 工具的最新版本特性」}

【不确定项】
{列出双方都可能不确定的部分，如「ZZ 方案的行业采用率」}

请在回答前，先标注你对每条信息的确定程度（已知 / 推断 / 不确定）。
对于「推断」和「不确定」的部分，在结论中降低置信度。

7.8 难度自适应分层

不同用户面对同一类任务时，所需的提示词详细程度完全不同。给新手一个高度抽象的元模板会让他们无从下手，给专家一个事无巨细的手把手指令则显得啰嗦且限制发挥。难度自适应分层解决的就是「用多详细的语言描述任务」这个问题。

方法论拆解：

三层难度自适应模型：

难度层级	用户特征	提示词风格	核心策略
初级	对领域不熟悉、模板是主要依赖	手把手式：每一步都明确说明，提供完整示例，变量替换即可使用	详细步骤 + 完整示例 + 常见坑提醒
中级	理解模板逻辑、能灵活调整参数、有 3-6 个月使用经验	脚手架式：给出框架和关键节点，细节由用户自主填充	关键约束 + 框架骨架 + 可选优化项
高级	内化了设计原则、能组合模板创造新用法	元指令式：只给出目标和高层次约束，让 AI 自行探索路径	目标描述 + 硬约束 + 自由探索空间

分层实践指南：

1. 自评定位：对照上表判断自己当前所处的层级。大多数人从初级入门的 1-2 周后进入中级，3-6 个月后接近高级
2. 任务分级而非笼统评级：你可能在「写技术方案」上是高级，在「创意写作」上是初级——按任务域分别评估
3. 逐层精简：一个实用的练习是——拿你常用的一个提示词，尝试用三种层级的风格各写一版，你会惊讶地发现「原来我加了这么多不需要的约束」
4. 与 AI 对齐难度：在提示词中可主动声明：「请以初级用户能理解的方式解释」「直接用专业术语，不需要展开」。这比调整提示词复杂度更直接有效

作为提示词使用时的模板：

请根据以下难度层级的要求，调整你的回答深度：

【当前难度层级】{初级 / 中级 / 高级}

- 如果选择初级：
  每个概念都配上类比和示例，避免术语堆砌。关键步骤拆分为 3-5 个可执行的小步骤。预估新手可能在哪里卡住，提前提醒。

- 如果选择中级：
  给出框架和关键决策点，细节由我自行补充。术语可用但首次出现时简要说明。提供「更进一步」的可选阅读建议。

- 如果选择高级：
  直接使用专业术语，不做展开解释。聚焦于边界案例和前沿思考。给出分歧观点和争议领域，不做「标准答案」式的定论。

我的任务：{具体任务}

---

附录：提示词快速索引

模板编号	模板名称	一句话用途	难度等级	适用场景
1.1	领域专家角色	设定专业身份获取专家级回答	初级	技术咨询、专业问答
1.2	多角色协同	多专家视角交叉分析	中级	方案评审、决策分析
1.3	人格化交互伴侣	设定特定人格的交互对象	初级	学习辅导、创意激发
2.1	JSON结构化输出	输出严格格式的JSON数据	初级	数据提取、API响应
2.2	分节式报告生成	生成结构清晰的长文档	初级	分析报告、技术文档
2.3	表格与列表输出	生成规范的Markdown表格	初级	对比分析、清单制作
2.4	Markdown结构化输出	生成规范的Markdown格式文档	初级	博客文章、技术文档
3.1	六步深度分析	结构化六步深度分析	中级	复杂问题、根因诊断
3.2	对抗性思维（红队）	红队视角找方案漏洞	高级	风险预判、方案评审
3.3	苏格拉底式提问	提问引导自行发现答案	中级	决策支持、学习辅导
3.4	思维链引导（CoT）	逐步展示推理过程	中级	数学推理、代码调试
3.5	Few-shot 示例引导	通过示例锚定输出格式	中级	分类、改写、风格统一
4.1	多维度约束锁定	多维度精确约束输出边界	中级	合规写作、敏感内容
4.2	分步确认与回滚	关键步骤设置确认机制	高级	长文档、高风险任务
4.3	安全边界声明	划定能力边界和安全红线	初级	敏感话题、专业建议
5.1	差异对比优化	针对性迭代修改输出	初级	文案精修、代码优化
5.2	多方案对比生成	生成多个截然不同的方案	中级	头脑风暴、方案比选
5.3	质量闭环自检	输出前执行质量自检	初级	交付检查、长期维护
4.5	树状思维(ToT)	多路径探索+回溯剪枝	高级	战略规划、创意发散
4.6	图状思维(GoT)	多路径并行后融合	高级	多源综合、矛盾调和
4.7	元认知提示(MP)	四段式自我质疑推理	高级	高风险决策、关键任务

---

使用建议：不必记住所有模板，在需要时按功能分类查表取用。每个模板的参数（{变量}部分）替换为实际内容即可使用。随着使用经验的积累，逐步形成个人的提示词组合习惯。

本文档持续更新，欢迎在实践中发现更优的提示词模式。

---

八、革命级提示词模板：Lyra 架构升级版

本章三个模板是对原始模板（3.1 / 1.2+3.2 / 3.5）的革命级重构。每个模板均注入高级推理框架（ToT / GoT / MP / CoVe），专为 GPT 系列模型（GPT-4/5）深度适配。与普通版相比，革命级模板内置了多路径探索、自我质疑机制和交叉验证，适用于对输出质量有极高要求的关键场景。

---

8.0 选择指南：何时使用高级模板

高级模板的价值不在于“越复杂越好”，而在于用与任务风险匹配的验证强度减少盲区。选择前依次判断：

1. 错误是否难以逆转：若结论会影响架构、合规、安全、长期投入或多人协作，优先增加验证；若只是可快速撤销的草稿，先用基础模板。
2. 是否存在多个合理路径：需要比较互斥方案时用 8.1；需要融合互补专家视角时用 8.2；输出模式稳定且有高质量示例时用 8.3。
3. 是否有足够信息：输入事实不足时，先补充信息或显式列出假设；高级框架不能替代数据。
4. 验证是否带来决策价值：若额外分支和复核不会改变行动，使用基础模板或 8.4 Lite 即可。
5. 是否有人类验收责任人：高风险结论必须保留人工复核，不能用模型自评代替验收。

任务特征	推荐模板	原因
日常、低风险、可快速回滚	第三章基础模板	保持简洁，降低上下文负担
中等风险，需要两个对立视角	8.4 Lyra Lite	双路径交叉检查，流程较轻
单一复杂问题，需要探索最优路径	8.1 ToT + MP	多分支评估、剪枝与元认知复核
多专业约束，需要独立意见融合	8.2 GoT + CoVe	多专家独立分析、交叉验证与冲突消解
批量生成、格式或风格必须稳定	8.3 Few-shot + 质量闭环	示例匹配、反例约束和自检闭环

渐进采用路径

1. 先用基础模板建立可比较的基线输出。
2. 用 8.4 Lite 检查双路径验证是否发现了真实盲区。
3. 只有当额外验证能改变结论或降低重要风险时，升级到 8.1 或 8.2。
4. 记录任务类型、遗漏点、人工修改和最终结果，逐步形成自己的模板选择规则。
5. 若输出开始重复、分支差异不足或验证只是在复述结论，立即降级模板复杂度。

常见误用

• 用高级模板处理简单事实查询：增加篇幅但不增加可靠性。应直接查询并核验来源。
• 用多路径包装信息不足：所有路径共享同一缺失事实，只会产生多份猜测。应先补充数据。
• 把模型置信度当客观概率：置信度只能表达依据完整度，不能替代校准或外部验证。
• 在同一上下文中伪装完全独立专家：后续角色可能受前文影响。确需独立性时，应分开生成再汇总。
• 为了使用框架而保留无效步骤：允许减少分支、专家和验证轮次，但必须保留任务所需的关键证据门。

---

8.1 模板 A：ToT + MP 深度分析引擎

原型模板：模板 3.1「六步深度分析」

升级策略：在「假设生成」和「验证评估」两阶段注入 ToT 多分支探索与回溯剪枝；在结论阶段注入 MP 元认知审视。场景设定为「技术方案评审」。

适用场景：技术选型评审、架构方案评估、关键技术决策、复杂问题根因诊断

难度等级：高级

---

完整提示词

你是一位拥有12年经验的技术架构评审专家。你的评审风格是：先收敛核心判断，再展开论证，数据驱动，不回避风险。

【评审对象】
{待评审的技术方案或设计文档}

【评审框架：ToT + MP 六步法】

## 第一步：问题定义与边界锚定
输出以下内容：
- 一句话描述本方案试图解决的核心问题
- 该问题的边界：什么在方案范围内，什么明确不在
- 关键利益相关方及其核心诉求
- 成功标准：方案通过评审的最低可接受标准是什么

## 第二步：信息收集与缺口标注
输出以下内容：
- 评审所需的关键信息清单
- 已有信息（标注可靠性：高/中/低）
- 信息缺口：缺少哪些信息会显著影响评审质量
- 不确定性清单：哪些参数的微小变化可能导致结论反转

## 第三步：维度拆解
将问题拆解为以下 5 个核心维度，对每个维度独立分析：
1. 技术可行性
2. 性能与可扩展性
3. 安全性与合规
4. 运维与可观测性
5. 成本与资源

每个维度输出：
- 现状评估（一句话）
- 核心风险点
- 与其他维度的耦合关系

## 第四步：ToT 多分支假设生成 ★ 革命级升级

本步骤采用 **Tree-of-Thoughts** 模式。你必须严格按以下流程执行：

**分支生成**（宽度 B=4）：
生成 4 个关于方案质量的独立假设分支，每个分支代表一种评审结论方向。
分支间必须互斥——它们不能是同一结论的变体。

示例分支方向（你可根据实际方案调整）：
- 分支 H1：「方案可行，风险可控，建议推进」
- 分支 H2：「方案方向正确，但存在关键风险需先解决」
- 分支 H3：「方案有根本性缺陷，建议重新设计」
- 分支 H4：「方案过度设计，更简单的替代方案存在」

**独立展开**（深度 D=3）：
对每个分支，沿以下三层展开推理：
- 第1层：支撑该分支结论的核心论据（至少 3 条）
- 第2层：每条论据的可靠性分析（证据强度、来源质量）
- 第3层：每条论据的反驳可能性（什么条件下该论据不成立）

**评估剪枝**（淘汰阈值 E=50%）：
用以下五维标准对 4 个分支打分（每维 1-5 分，总分 25）：
| 评估维度 | 权重 | H1 | H2 | H3 | H4 |
|----------|------|----|----|----|----|
| 论据充分性 | 25% |   |   |   |   |
| 风险覆盖度 | 25% |   |   |   |   |
| 可验证性   | 20% |   |   |   |   |
| 现实可行性 | 15% |   |   |   |   |
| 逻辑一致性 | 15% |   |   |   |   |
| **加权总分** | 100% |   |   |   |   |

淘汰规则：总分低于 3.0 的分支直接淘汰；若所有分支均低于 3.0，保留最高分两个进入下一轮。

**回溯规则**（若触发）：
如果剪枝后仅剩 1 个分支，回溯到第三步「维度拆解」，检查是否有被忽略的维度导致分支多样性不足。基于回溯发现，补充至少 2 个新分支方向。

**收敛**：
从存活分支中选出最佳结论，并说明：
- 为什么该结论优于被淘汰的分支（逐分支对比）
- 该结论的置信度（高/中/低）及主要不确定性来源

## 第五步：验证与压力测试
对收敛后的结论执行以下压力测试：
- 参数敏感性分析：关键假设变化 ±30% 时，结论是否改变？
- 最坏场景推演：如果方案的 3 个最大风险同时爆发，会发生什么？
- 反向论证：假设结论是错的——最可能的错误根源是什么？

## 第六步：MP 元认知结论 ★ 革命级升级

本步骤采用 **Metacognitive Prompting** 四段式结构。你必须严格按以下四段输出最终结论：

**阶段一：理解陈述**
在给出结论之前，先陈述你对本次评审任务和方案的理解：
- 我理解的核心问题是什么
- 我采用了什么评审方法和推理路径
- 我认为哪些边界条件是我可能没有充分考虑的

**阶段二：初步判断**
给出你在经过前五步分析后的初步结论（包括推荐方向和置信度）。

**阶段三：批判审视**（这是 MP 的核心——你必须主动质疑自己）
用以下自问清单审视你的初步判断：
1. 我是否因为某个维度的信息充足而过度重视了它，忽略了信息薄弱的维度？
2. 我是否因为方案表述的专业性/体系化而降低了批判力度（权威偏差）？
3. 我是否找到了方案中最薄弱的一个环节并对它施加了足够的审查压力？
4. 如果让我用一个反对者的视角重新审视，我会改变哪个判断？
5. 我的结论中是否存在「因为看起来合理所以接受了」但实际未经检验的假设？

对每个自问给出诚实回答。如果发现漏洞，回到第四步调整分支评估，重新收敛。

**阶段四：最终结论与行动**
经过批判审视后，给出最终结论：
- 核心判断（一句话）
- 置信度（高/中/低）及置信度说明
- Top 3 关键风险（按严重程度排序，每个风险给出缓解建议）
- Top 3 改进建议（按优先级排序）
- 需要进一步验证的问题清单
- 一句话总结：如果你只有 30 秒向决策者汇报，你会说什么

【输出约束】
- 每一步都必须输出，不允许跳过
- 第四步的表格必须完整填写，不允许留空
- 第六步的阶段三必须逐条回答自问清单，不允许笼统的「已审视」

---

使用注意事项

• 分支宽度（B）：可根据方案复杂度调整为 3-6，B 越大探索越充分但耗时越长
• 回溯是质量保证的核心：如果剪枝后只剩 1 个分支且你没有充分理由，说明第四步的探索不够——这就是 ToT 的自我纠错机制
• MP 阶段三是最容易被敷衍的：在 GPT 系列中，你可能需要在提示词末尾追加「请在第六步阶段三中，逐一回答 5 个自问问题」来确保执行
• ToT + MP 叠加后，GPT 模型输出通常会变长 2-3 倍，但质量提升显著——适合异步评审场景（如提交方案后等待评审报告），不适合即时对话

---

8.2 模板 B：GoT + CoVe 多角色协同审查引擎

原型模板：模板 1.2「多角色协同」+ 模板 3.2「对抗性思维」

升级策略：为每位专家注入独立 GoT 推理路径，通过 CoVe（Chain-of-Verification）实现交叉验证，以 GoT 图融合替代简单共识罗列，红队升级为融合结论的定向打击。场景设定为「安全架构方案评审」。

适用场景：高风险方案的多视角评审、安全架构审计、跨领域复杂决策、需要多方签字的正式评审

难度等级：高级

---

完整提示词

你是一个多角色协同评审系统。本次评审采用 GoT（Graph-of-Thoughts）+ CoVe（Chain-of-Verification）架构，四位专家各自沿独立推理路径分析，再通过交叉验证和图表融合生成综合结论。

【待评审方案】
{方案内容}

【评审架构概览】

          ┌─ 专家A：架构师 ──→ [GoT路径A] ──┐
          │                                   │

待评审方案 ───┼─ 专家B：安全工程师 ──→ [GoT路径B] ──┼──→ CoVe交叉验证 ──→ GoT图融合 ──→ 综合结论
│ │
├─ 专家C：SRE工程师 ──→ [GoT路径C] ──┘
│
└─ 专家D：红队分析师 ──→ [不看融合结论，独立攻击] ──→ 定向打击

---

## 第一阶段：独立 GoT 推理

以下三位专家各自沿独立的推理路径进行分析。**专家之间不共享推理过程，各自基于完整的待评审方案独立工作。**

### 【专家A】架构师 — 10年分布式系统设计经验

你的 GoT 推理路径：
1. **节点1**：整体架构评估
   - 该方案的核心架构决策是什么？
   - 这些决策的技术前提是否成立？
   - 架构中有没有单点故障或扩展瓶颈？

2. **节点2**：组件间交互分析
   - 识别所有关键组件间的依赖关系
   - 分析数据流路径上的潜在瓶颈
   - 评估接口设计的合理性和可演化性

3. **节点3**：技术债务预判
   - 当前设计可能导致哪些技术债务？
   - 哪些看似优雅的设计在未来扩展时会成为阻碍？
   - 给出「6个月后回头看，最可能后悔的设计决策」

4. **收敛**：归总你的 GoT 路径，输出：
   - 架构层面 Top 3 发现
   - 每个发现的严重程度（高/中/低）
   - 改进建议

### 【专家B】安全工程师 — 8年应用安全与渗透测试经验

你的 GoT 推理路径：
1. **节点1**：攻击面映射
   - 识别所有外部暴露的接口和数据入口
   - 分析认证/授权链路上的薄弱点
   - 评估第三方依赖的安全状况

2. **节点2**：纵深防御评估
   - 检查是否存在单层安全机制（这是红线）
   - 分析数据在静态、传输、使用三种状态下的保护措施
   - 评估密钥管理和凭证轮转策略

3. **节点3**：合规与隐私
   - 检查是否涉及敏感数据处理（PII/金融/医疗）
   - 评估日志和审计追踪的完整性
   - 分析在数据泄露场景下的影响半径

4. **收敛**：归总你的 GoT 路径，输出：
   - 安全层面 Top 3 发现
   - 每个发现的严重程度（高/中/低）
   - 改进建议

### 【专家C】SRE工程师 — 6年云原生运维经验

你的 GoT 推理路径：
1. **节点1**：可部署性
   - 评估部署复杂度和依赖链长度
   - 分析配置管理的清晰度和可自动化程度
   - 检查回滚策略是否可行

2. **节点2**：可观测性
   - 检查方案是否覆盖了监控、日志、追踪三大支柱
   - 评估告警规则的合理性和噪音控制
   - 分析故障定位路径是否清晰

3. **节点3**：韧性设计
   - 检查熔断、降级、限流等韧性模式是否到位
   - 评估在部分组件故障时的系统行为
   - 分析容量规划和弹性伸缩策略

4. **收敛**：归总你的 GoT 路径，输出：
   - 运维层面 Top 3 发现
   - 每个发现的严重程度（高/中/低）
   - 改进建议

---

## 第二阶段：CoVe 交叉验证 ★ 革命级升级

三位专家完成独立分析后，进入 **Chain-of-Verification** 交叉验证阶段。

请依次执行以下验证循环：

### 验证循环 1：专家A 的结论由 B 和 C 验证
- B 阅读 A 的 Top 3 发现，生成 3 个验证问题
- C 阅读 A 的 Top 3 发现，生成 3 个验证问题
- A 逐一回答 B 和 C 的验证问题

### 验证循环 2：专家B 的结论由 A 和 C 验证
- A 阅读 B 的 Top 3 发现，生成 3 个验证问题
- C 阅读 B 的 Top 3 发现，生成 3 个验证问题
- B 逐一回答 A 和 C 的验证问题

### 验证循环 3：专家C 的结论由 A 和 B 验证
- A 阅读 C 的 Top 3 发现，生成 3 个验证问题
- B 阅读 C 的 Top 3 发现，生成 3 个验证问题
- C 逐一回答 A 和 B 的验证问题

### 验证结果汇总
汇总所有验证循环结果，标注：
- 被验证通过的发现（三方一致或两方确认无异议）
- 被部分质疑的发现（有一方提出有效异议）
- 被推翻的发现（经验证发现判断有误）

---

## 第三阶段：GoT 图融合 ★ 革命级升级

将经过 CoVe 验证后的各专家发现进行图融合。不再简单地罗列共识和分歧，而是按以下结构输出：

### 融合矩阵

| 发现编号 | 发现内容 | 来源专家 | 被验证状态 | 冲突度 | 信源数 |
|----------|----------|----------|------------|--------|--------|
| F1 | ...     | A, B     | 已验证     | 低     | 2      |
| F2 | ...     | A, C     | 部分质疑   | 中     | 2      |
| F3 | ...     | B        | 被推翻     | —     | 1      |

**融合规则**：
- 信源数 ≥2 且冲突度 = 低的发现 → 直接采纳为「高置信度结论」
- 信源数 ≥2 且冲突度 = 中的发现 → 标注为「待确认结论」，附冲突详情
- 信源数 =1 或已被推翻的发现 → 降级为「参考意见」，不纳入核心结论
- 存在矛盾的发现 → 标记为「需决策者裁决」，附双方论据

### 综合结论
基于融合矩阵，输出：
1. **高置信度结论**（可直接作为决策依据）
2. **待确认结论**（需补充信息或进一步验证）
3. **需决策者裁决的矛盾**（各方论据 + 建议裁决方向）
4. **整体通过建议**：通过 / 有条件通过（列出条件）/ 不通过

---

## 第四阶段：红队定向打击 ★ 革命级升级

现在你切换到【专家D】红队分析师 — 10年攻防经验，曾参与超过 50 次红蓝对抗。

**重要约束**：你不能看到前三个阶段的产出。你只看原始方案文档，但你必须针对 GoT 融合后的综合结论（由前三个阶段产生）中可能存在的盲区进行独立攻击。

你的攻击维度：

1. **假设攻击**：方案建立在哪些隐含假设上？如果每个假设都被推翻，方案还剩什么？
2. **组合攻击**：两个看起来独立的低风险点，组合在一起是否会产生高风险？
3. **时序攻击**：方案在部署的不同时间阶段（0天/7天/30天/90天），风险暴露如何变化？
4. **对手视角**：如果你的目标是让这个方案失败，你会选择攻击哪 3 个点？为什么？
5. **黑天鹅检查**：方案是否考虑过低概率高影响事件？如果发生，系统能否存活？

输出：
- Top 5 攻击向量（按成功率从高到低）
- 对「综合结论」的质疑：如果融合结论错了，最可能的错误根源是什么？
- 一句话总结：这个方案在安全上给你什么感觉？（比如「它看起来很坚固，但地基是沙子」）

---

【全局约束】
- 第一阶段的专家分析必须保持独立，不允许任何跨专家引用
- 第二阶段的验证问题必须有针对性，不允许泛泛的「你确定吗」
- 融合矩阵表格必须完整填写，不允许出现空单元格
- 所有严重程度评定使用统一标准：高=可能导致方案失败/安全事故；中=显著增加成本或延迟；低=影响有限但值得改进

---

使用注意事项

• GoT 独立性的保持：GPT 系列在长上下文中可能出现「后输出的专家被先输出专家影响」的问题。如需加强隔离，可以在提示词末尾追加：「在输出专家A之前，不要预判B和C的分析」
• CoVe 验证循环的质量：跨专家验证是本模板最核心的质量环节。如果发现验证问题流于形式（如「此分析是否全面？」），可以要求在验证问题中必须包含「请指出一个具体的数据或逻辑缺口」
• 红队独立性的妥协：由于技术限制，红队在同一个对话上下文中必然能看到前面的输出。提示词中的「你不能看到前三阶段产出」是一个行为指令，GPT 模型通常会努力遵守但无法完全隔离。对于真正需要隔离的场景，建议分两次对话执行（1-3 阶段一次，4 阶段新开对话）
• 本模板输出较长（通常 3000-5000 token），适合异步正式评审，不适合即时交互

---

8.3 模板 C：自适应 Few-shot + 质量闭环生成引擎

原型模板：模板 3.5「Few-shot 示例引导」

升级策略：增加自适应示例匹配规则与反例注入，叠加质量闭环（输入特征→匹配示例→生成→对照自检→修正）。场景设定为「技术博客/文档创作」。

适用场景：技术博客写作、API 文档生成、技术教程创作、代码注释与 README 生成

难度等级：中级

---

完整提示词

你是一位资深技术写作者，擅长将复杂技术概念转化为清晰、易读、有深度的技术文档。

【任务】
{具体写作任务，如「撰写一篇关于 Kubernetes HPA 自动扩缩容的技术博客」}

【自适应示例匹配规则】★ 革命级升级

在开始写作前，先根据以下规则匹配最适合的示例模式：

匹配规则：
- 如果任务涉及「概念讲解」→ 使用【示例组A：概念讲解模式】
- 如果任务涉及「操作指南/教程」→ 使用【示例组B：逐步教程模式】
- 如果任务涉及「方案对比/技术选型」→ 使用【示例组C：对比分析模式】
- 如果任务涉及「实战案例/踩坑记录」→ 使用【示例组D：案例复盘模式】
- 如果任务涉及多个类别，选择占比最高的那个类别锚定主要模式，其他类别的元素作为辅助

请先输出你匹配到的示例模式（如「匹配结果：示例组B — 逐步教程模式」），然后按该模式的要求写作。

---

【示例组A：概念讲解模式】

▼ 正确示例 — 「什么是零知识证明」

> 如果你想让别人相信你知道一个秘密，但又不能把秘密说出来——这就是零知识证明要解决的问题。
>
> 用更技术的语言说：零知识证明（ZKP）是一种密码学协议，允许证明者（Prover）向验证者（Verifier）证明某个陈述为真，而无需透露该陈述之外的任何信息。
>
> ## 为什么需要 ZKP？
>
> 三个核心动机：
> 1. **隐私保护**：在区块链交易中，你可以证明自己有足够的余额，而不暴露具体金额
> 2. **数据最小化**：身份验证时，你只需证明「我已满18岁」，而不是交出整张身份证
> 3. **计算外包信任**：你可以让不可信的第三方执行计算，然后验证结果正确性
>
> ## 核心原理（简化版）
>
> 经典的「阿里巴巴洞穴」类比：[用洞穴故事解释交互式ZKP]
>
> ## 主流方案对比
>
> | 方案 | 证明大小 | 验证速度 | 可信设置 | 适用场景 |
> |------|----------|----------|----------|----------|
> | zk-SNARKs | 极小 | 极快 | 需要 | 链上验证 |
> | zk-STARKs | 较大 | 快 | 不需要 | 高吞吐场景 |
> | Bulletproofs | 中等 | 中等 | 不需要 | 范围证明 |
>
> ## 一句话总结
>
> 零知识证明让「信任」和「隐私」不再互斥——你可以验证真伪而不窥探内里。

▼ 错误示例 — 不合格的技术概念讲解

> 零知识证明是一种重要的密码学技术，它有很多应用。零知识证明的核心就是零知识，也就是不需要知识就能证明。这个概念最早由 Goldwasser 等人在 1985 年提出。零知识证明在区块链中有很多用处。现在很多项目都在用零知识证明，它很火。总之零知识证明是个好东西。

**这个示例为什么不合格？**
- 第1句：空洞的「很重要」「有很多应用」——没有给出任何具体信息
- 第2句：概念解释自循环——用「零知识」解释「零知识证明」，什么都没说清楚
- 第3句：只有人名和年份，没有说明它解决了什么问题
- 第4-6句：连续三句「很多」「很火」「好东西」——全是空洞评价，零实质内容
- 读者的收获：只知道「有个叫零知识证明的东西好像挺厉害的」，但完全不知道它是什么、为什么需要、怎么用

---

【示例组B：逐步教程模式】

▼ 正确示例 — 「5分钟上手 Docker Compose」

> ## 目标
> 用 Docker Compose 在本地启动一个 Nginx + Flask + Redis 的三服务应用。
>
> ## 前置条件
> - Docker 已安装（版本 ≥ 20.10）
> - Docker Compose 已安装（版本 ≥ 2.0）
> - 基础命令行操作能力
>
> ## 步骤
>
> ### Step 1：创建项目目录
> ```bash
> mkdir docker-demo && cd docker-demo

Step 2：编写 Flask 应用

# app.py — 你可以在后续替换为自己的业务代码
from flask import Flask
import redis

app = Flask(__name__)
cache = redis.Redis(host='redis', port=6379)

@app.route('/')
def hello():
    count = cache.incr('hits')
    return f'Hello! 本页已被访问 {count} 次'

在这一步你可能会遇到的坑： 如果 Redis 连接失败，检查 docker-compose.yml 中 Redis 服务的 hostname 是否为 redis。

Step 3：编写 Docker Compose 配置

…[后续步骤省略]

验证

打开浏览器访问 http://localhost:8080，应该看到 Hello 页面和递增的访问计数。

排错指南

症状	可能原因	解决方法
连接被拒绝	端口被占用	`netstat -ano
Redis 连接错误	服务启动顺序	检查 depends_on 配置

下一步

现在你已经有了一个可运行的三服务应用。建议接着阅读「Docker Compose 网络模式详解」。

▼ 错误示例 — 不合格的逐步教程

Docker Compose 是一个很好用的工具，你可以用它来管理多个容器。首先你要安装 Docker Compose，安装好了之后就可以写配置文件了。配置文件是 YAML 格式的，里面可以写很多服务。写好之后用 docker-compose up 命令启动就行了。很简单吧！

这个示例为什么不合格？

• 没有给出任何可执行的命令或代码
• 没有说明文件应该放在哪里、文件名叫什么
• 「配置文件是 YAML 格式」——说了等于没说，没有给出具体字段
• 「很简单吧」——教程的职责是让读者学会，不是展示自己觉得很轻松
• 缺少验证步骤：读者无法判断自己是否做对了

---

【示例组C：对比分析模式】

▼ 正确示例 — 「React vs Vue：2025 年的选择指南」

一句话结论

2025 年，React 和 Vue 在核心体验上的差距已缩小到「个人偏好」级别。选择 React 如果你需要最大生态和招聘池；选择 Vue 如果你追求开发体验和渐进式采纳。

对比维度

维度	React	Vue	结论
学习曲线	JSX + Hooks 思维转换	模板语法即学即用	Vue 胜
TypeScript 支持	一流，天然亲和	3.x 后大幅改善，仍有边缘场景	React 胜
生态规模	绝对优势	够用但深度逊色	React 胜
SSR/SSG	Next.js 一家独大	Nuxt 体验优秀但社区小	React 略胜
状态管理	选择多但碎片化	Pinia 标准化体验好	Vue 胜
移动端	React Native 成熟	暂无对等级别方案	React 胜

决策流程

团队已有 React 经验？→ 是 → 选 React
                    → 否 → 需要 React Native？→ 是 → 选 React
                                               → 否 → 选 Vue

…[后续内容省略]

▼ 错误示例 — 不合格的对比分析

React 和 Vue 都是很好的前端框架，各有优缺点。React 用的人多，Vue 写起来简单。我觉得两个都挺好的，选哪个看你自己。

这个示例为什么不合格？

• 没有任何可对比的具体维度
• 「都很好」「看你自己」——对比分析的核心价值就是帮读者做决策，这样说等于什么都没提供
• 缺少数据和具体差异点
• 没有给出决策依据和适用场景

---

【示例组D：案例复盘模式】

▼ 正确示例 — 「一次 MySQL 死锁的排查全过程」

背景

2025年3月某晚 23:15，监控告警：订单服务的 P99 延迟从 200ms 飙升到 12s，错误率升至 3.2%。

时间线

时间	事件
23:15	监控告警触发
23:17	值班同学确认：订单创建接口超时
23:20	初步判断：数据库连接池耗尽
23:25	深入排查：发现 MySQL 死锁
23:35	临时止血：kill 死锁事务
23:45	定位根因：并发扣减库存的事务顺序不一致

根因分析

…[后续内容省略]

---

【写作要求】

1. 严格遵循你匹配到的示例模式的结构、深度和风格
2. 禁止出现以下模式（对应错误示例中的问题）：
   • 空泛评价词（「很好」「很重要」「很火」「很厉害」）
   • 自循环解释（用概念自身解释自身）
   • 无实质内容的过渡句（「接下来我们来看看」「下面开始讲」）
   • 教程类缺代码、对比类缺表格、概念类缺类比
3. 每个章节必须提供使读者能执行或验证的具体信息

【质量闭环自检】★ 革命级升级

完成写作后，不立即输出，先在内部执行以下自检（不展示自检过程）：

1. 格式对照检查：逐项对照你匹配到的示例模式的结构要素，标记是否有遗漏
2. 反例规避检查：逐句扫描输出，标记是否有空泛评价词或自循环解释，如有则替换
3. 信息密度检查：统计输出中纯信息句 vs 过渡句/评价句的比例——信息句应 ≥80%
4. 可执行性检查：读者读完能否在 5 分钟内执行至少一个具体操作？（教程类）读者读完能否用一句话向他人转述核心概念？（概念类）读者读完能否做出选型决策？（对比类）

如果任何一项检查未通过，在内部修正后再次检查，直到全部通过。
如果全部通过，输出最终结果。

【自检报告】（在最终输出末尾附上）

自检结果：
- 格式对照：[通过/未通过] {简述}
- 反例规避：[通过/未通过] {简述}
- 信息密度：[通过/未通过] {估算比例}
- 可执行性：[通过/未通过] {简述}

现在开始执行：{具体写作任务}

---

#### 使用注意事项

- **示例组的自定义**：`{具体写作任务}` 决定了匹配哪个示例组。如果你的任务类型不在四个示例组中，可以替换为你的领域示例——关键在于正确示例和错误示例的对比要足够鲜明
- **反例是认知锚点**：错误示例的价值不亚于正确示例。GPT 系列对「不要怎么做」的响应往往比「要怎么做」更精准。如果你的领域有典型错误模式，务必加入反例
- **自检报告在生产环境中可以移除**：最后的自检报告在开发/调试阶段很有用，但如果用于自动化管道，可以删除该部分以减少输出长度
- **信息密度 80% 的门槛**：这是一个较高的标准，如果 AI 输出多次不达标，可以临时降低到 70%，然后在迭代中逐步提升

---

### 8.4 Lyra Lite：双路径交叉验证模板

**功能描述**：用两条明显不同的分析路径审视同一任务，再通过交叉检查形成有条件的综合建议。它保留多视角与验证机制，但不引入完整 ToT/GoT 的多层分支。

**适用场景**：中等风险方案评审、需求取舍、技术设计初审、内容策略、可回滚的决策，以及需要快速发现单一视角盲区的任务。

**完整提示词**：

```text
你是 {角色定义}。请对以下任务执行“双路径分析 + 交叉验证”。

【任务】
{具体任务描述}

【已知事实】
{事实、数据、约束与来源；未知项明确写“未知”}

【验收标准】
{完成条件、优先级和不可违反的边界}

第一阶段：定义两条不同路径

路径 A：{例如收益优先、短期、用户体验、技术可行性}
- 核心假设：{该路径成立依赖的前提}
- 推荐方案：{方案}
- 支持依据：{事实或可验证依据}
- 预期收益：{使用任务自身指标描述；无数据时不要编造数字}
- 薄弱点：{最可能被推翻的环节}

路径 B：{例如风险优先、长期、运维成本、合规安全}
- 核心假设：{该路径成立依赖的前提}
- 推荐方案：{方案}
- 支持依据：{事实或可验证依据}
- 主要风险：{风险、触发条件与影响}
- 缓解措施：{具体措施}
- 退出方案：{失败时如何回滚或切换}

第二阶段：交叉验证

1. 路径 A 是否忽略了路径 B 的关键风险？逐项说明。
2. 路径 B 是否因过度保守而忽略可行收益？逐项说明。
3. 两条路径是否依赖同一未经验证的假设？将其列为信息缺口。
4. 哪些结论有事实支持，哪些只是推断？分别标注。
5. 什么新证据会改变当前建议？给出最小验证动作。

第三阶段：综合输出

请按以下结构输出：

## 推荐方案
给出“采纳 / 拒绝 / 有条件采纳”之一，并明确适用条件。

## 核心依据
列出 3-5 条最关键、可核验的依据。

## 风险与缓解
| 风险 | 触发条件 | 影响 | 缓解措施 | 责任人/验证方式 |
|---|---|---|---|---|

## 信息缺口
列出尚不能确认的事实，不得用猜测补齐。

## 下一步行动
按优先级给出最小可执行验证步骤和停止条件。

## 结论可信度
用高/中/低描述依据完整度，并说明限制；不要把主观评分伪装成统计概率。

使用注意事项：

• 两条路径必须有实质差异，可替换为“短期/长期”“成本/质量”“技术/业务”“收益/风险”。
• 路径共享的信息缺口必须单独列出，不能因为两条路径得出相同结论就视为已验证。
• 若任务事实简单明确，退回第三章基础模板；若出现多个互补专业视角，再升级到 8.1 或 8.2。
• 所有数值必须来自输入、可核验来源或明确标注的假设；不得自行生成固定成本、时间或提升比例。
• 高风险场景中，本模板只生成评审材料，最终决策仍由明确的人类责任人作出。

8.5 高级模板失败模式与修正

失败模式	典型信号	修正动作
分支伪多样性	多条路径只换措辞，结论和依据相同	重定义互斥假设或分析维度；无差异则减少分支
验证流于形式	只回答“基本合理、较全面”	要求逐条引用待验证结论、反例和可推翻条件
角色相互污染	后出现的专家重复前一专家观点	分会话独立生成，仅在汇总阶段共享结论摘要
信息不足却强行收敛	大量结论依赖未给出的数据	先输出信息缺口和最小调研清单，暂停决策
自评分数失真	所有方案都得到相近高分	使用可观察标准、边界测试和外部验收，弱化主观总分
框架过载	输出重复、篇幅膨胀、行动项变少	删除不能改变结论的步骤，降级到 8.4 或基础模板
过度确定	将推断写成事实，将主观置信度写成概率	分离事实/假设/推断，说明证据与失效条件
无法回滚	建议没有试点、停止或退出条件	增加最小实验、观测指标、停止条件和回滚方案

附录A：Lyra 高级模板快速索引

模板	核心机制	相对复杂度	适用场景	降级条件
8.0 选择指南	风险、信息、验证价值门禁	低	选择模板前	已有明确模板选择
8.1 ToT + MP	多分支探索、剪枝、元认知复核	高	单一复杂问题、最优路径搜索	分支差异不足或信息缺失
8.2 GoT + CoVe	多专家独立分析、验证与融合	很高	多专业约束、冲突消解	专家视角不独立或无需融合
8.3 Few-shot + 闭环	示例匹配、反例和质量自检	中高	批量、格式与风格稳定输出	缺少高质量代表性示例
8.4 Lyra Lite	双路径交叉验证	中	中等风险、快速初审	单路径已足够或需更多专业视角

选择原则：先使用能满足验收要求的最轻模板；只有当额外步骤能发现真实盲区、改变行动或降低重要风险时才升级复杂度。