高级 Prompt Engineering
基础技巧让模型"能用"，高级技巧让模型"好用"——这是产品经理从及格到优秀的分水岭。
前置阅读
本文是 Prompt Engineering 基础 的进阶篇。如果你还不熟悉角色设定、结构化输出、Few-Shot 等基础技巧，建议先阅读基础篇。
提示词的高级推理框架
基础的 Prompt 技巧（角色设定、格式要求）解决的是"让模型听懂你"的问题。高级框架解决的是"让模型像专家一样思考"的问题。
提示词技术演进路线：
基础技巧 高级框架 自动化
─────────────────────────────────────────────────────────────
Zero-Shot ──→ Chain-of-Thought ──→ Auto-CoT
Few-Shot ──→ ReAct ──→ APE
角色设定 ──→ Reflexion ──→ ART
格式要求 ──→ 逆向提示词 ──→ Context Engineering
"告诉模型做什么" "教模型怎么想" "让模型自己优化"Chain-of-Thought（思维链）深度解析
为什么 CoT 有效？
普通提示：
问题 → 答案
模型直接跳到结论，容易出错
CoT 提示：
问题 → 思考步骤 1 → 思考步骤 2 → ... → 答案
模型被迫展示推理过程，准确率显著提升在复杂推理任务中，CoT 可以将准确率从 ~60% 提升到 ~90%+。
CoT 的三种实现方式
1. 手动 CoT（Manual CoT）
手动编写思维链示例，适合你对任务非常了解的场景：
你是一个 AI 产品需求评估专家。请按步骤分析：
示例：
用户需求："我们想用 AI 自动审核用户上传的图片"
步骤 1 - 场景分析：
这是一个图像内容审核场景，属于计算机视觉 + 内容安全领域。
步骤 2 - 技术可行性：
多模态模型（如 GPT-4o、Claude）已具备图像理解能力，
但审核准确率需要 > 99% 才能满足合规要求。
步骤 3 - 成本评估：
假设日均 10 万张图片，每张约 1000 tokens，
使用 GPT-4o-mini 约 $15/天，可接受。
步骤 4 - 风险评估：
误判风险高（误删用户内容 / 漏放违规内容），
需要人工复审兜底机制。
结论：技术可行，建议采用"AI 初筛 + 人工复审"的方案，
先从低风险类别开始上线。
现在请分析以下需求：
[用户的实际需求]2. Zero-Shot CoT
最简单的 CoT——只需在提示末尾加一句话：
[你的问题]
请一步一步思考。（Let's think step by step.）效果出奇地好，在数学推理任务上可以将 GPT 系列模型的准确率提升 2-3 倍。
3. Auto-CoT（自动思维链）
让模型自动生成思维链示例，省去人工编写的成本：
流程：
原始问题集
│
▼
聚类分析 → 将问题分成若干类别
│
▼
每类选一个代表性问题
│
▼
用 Zero-Shot CoT 生成思维链
│
▼
组合成 Few-Shot CoT 示例集
│
▼
应用于新问题产品经理应用场景
当你需要为产品构建大量 Prompt 模板时，Auto-CoT 可以大幅降低人工编写成本。让 AI 先为不同场景生成推理示例，你只需要审核和调整。
自我一致性（Self-Consistency）
核心思想
让模型对同一个问题生成多个答案，然后取多数投票的结果：
┌── 推理路径 A → 答案：方案 1
│
同一问题 ──┼── 推理路径 B → 答案：方案 1
│
├── 推理路径 C → 答案：方案 2
│
├── 推理路径 D → 答案：方案 1
│
└── 推理路径 E → 答案：方案 2
多数投票结果：方案 1（3/5 = 60%）
置信度：中等（不是压倒性多数）产品化应用
适用场景：
✓ 高风险决策（金融分析、医疗建议）
✓ 答案有明确对错的任务
✓ 需要置信度评估的场景
不适用场景：
✗ 创意生成（每次结果本就不同）
✗ 成本敏感场景（需要多次调用）
✗ 低延迟要求的场景成本提醒
Self-Consistency 需要多次调用模型（通常 5-10 次），成本和延迟线性增加。在产品中使用时要权衡准确性提升和成本增加。
ReAct 框架：推理 + 行动
什么是 ReAct？
ReAct（Reasoning + Acting）让模型在思考和行动之间交替进行：
传统模式：
问题 → 思考 → 回答
ReAct 模式：
问题 → 思考 → 行动 → 观察 → 思考 → 行动 → 观察 → 回答
┌─────────────────────────────────────────────────────┐
│ │
│ 用户问题："我们产品的月活用户趋势如何？" │
│ │
│ Thought 1: 需要查询最近几个月的 MAU 数据 │
│ Action 1: [查询数据库] SELECT month, mau FROM ... │
│ Observation 1: 1月=120K, 2月=135K, 3月=142K │
│ │
│ Thought 2: MAU 在增长，需要计算增长率 │
│ Action 2: [计算] (142K-120K)/120K = 18.3% │
│ Observation 2: 季度增长率 18.3% │
│ │
│ Thought 3: 增长健康，但需要看是否有加速/减速趋势 │
│ Action 3: [计算] 月环比：12.5%, 5.2% │
│ Observation 3: 增长在放缓 │
│ │
│ Final Answer: MAU 呈增长趋势，季度增长 18.3%， │
│ 但月环比增速从 12.5% 降至 5.2%，增长正在放缓。 │
│ │
└─────────────────────────────────────────────────────┘ReAct 在 AI 产品中的角色
ReAct 是 AI Agent 的核心推理框架。当你设计一个能调用工具的 AI 产品时，底层就是 ReAct 模式：
| 产品形态 | ReAct 的体现 |
|---|---|
| AI 数据分析助手 | 思考 → 查询数据库 → 分析结果 → 生成报告 |
| AI 客服 | 理解问题 → 查询知识库 → 判断是否需要转人工 |
| AI 编程助手 | 分析需求 → 生成代码 → 运行测试 → 修复问题 |
| AI 旅行规划 | 理解偏好 → 搜索航班 → 搜索酒店 → 组合方案 |
Reflexion：自我反思框架
核心思想
让模型评估自己的输出，发现问题后自我修正：
第一次生成
│
▼
┌─────────────────────────┐
│ 自我评估 │
│ "我的回答准确吗？" │
│ "有没有遗漏关键信息？" │
│ "逻辑有没有漏洞？" │
└───────────┬─────────────┘
│
┌──────┴──────┐
│ │
没问题 有问题
│ │
▼ ▼
输出答案 修正后重新生成
│
▼
再次自我评估
│
...产品化的 Reflexion 模式
System Prompt 示例：
你是一个产品文档审查专家。请按以下流程工作：
1. 首先生成你的分析结果
2. 然后用以下清单自检：
□ 是否遗漏了关键用户场景？
□ 技术可行性分析是否充分？
□ 成本估算是否合理？
□ 风险评估是否完整？
□ 指标定义是否可量化？
3. 如果发现不足，修正后输出最终版本
4. 标注修正了哪些内容为什么 Reflexion 对产品很重要？
在 AI 产品中，用户看到的第一次回答就是最终回答。Reflexion 通过内置自我审查机制，让模型在"交卷"前先检查一遍，显著提升输出质量——这比让用户反复修改体验好得多。
自动推理并使用工具（ART）
ART（Automatic Reasoning and Tool-use）让模型自动决定何时使用哪个工具：
┌─────────────────────────────────────────┐
│ ART 框架 │
│ │
│ 1. 任务库：存储各类任务的推理模板 │
│ 2. 工具库：可用工具及其描述 │
│ 3. 推理引擎：根据任务自动选择模板和工具 │
│ │
│ 用户输入 │
│ ↓ │
│ 匹配最相似的任务模板 │
│ ↓ │
│ 生成推理步骤（含工具调用占位符） │
│ ↓ │
│ 执行工具调用，填入结果 │
│ ↓ │
│ 输出最终答案 │
└─────────────────────────────────────────┘与 ReAct 的区别：ART 更侧重"自动化"，通过任务模板库减少人工编写 Prompt 的工作量。
自动提示工程师（APE）
让 AI 帮你写 Prompt
APE（Automatic Prompt Engineer）的核心思想是用模型来优化模型的 Prompt：
APE 流程：
1. 定义任务和评估标准
│
▼
2. 让 LLM 生成多个候选 Prompt
│
▼
3. 在评估数据集上测试每个 Prompt
│
▼
4. 选择表现最好的 Prompt
│
▼
5. 对最佳 Prompt 进行变异和优化
│
▼
6. 重复 3-5 直到满意产品经理的 APE 实践
场景：你需要为客服机器人优化 System Prompt
Step 1: 准备 20 个真实用户问题和期望回答
Step 2: 让 Claude 生成 10 个不同的 System Prompt 变体
Step 3: 用 20 个问题测试每个变体，人工打分
Step 4: 选出 Top 3，让 Claude 分析它们的共同特征
Step 5: 基于分析结果生成优化版本
Step 6: 再次测试，选出最终版本
这个流程可以在 1-2 天内完成，
比靠直觉调试 Prompt 效率高 5-10 倍。方向性刺激提示（Directional Stimulus Prompting）
核心概念
给模型一个"方向性提示"，引导它关注特定方面：
普通提示：
"请分析这个产品功能的优劣势"
→ 模型可能泛泛而谈
方向性刺激提示：
"请分析这个产品功能的优劣势。
特别关注：数据隐私风险、边际成本曲线、
用户学习成本这三个维度。"
→ 模型会深入分析指定维度常用方向性刺激模式
| 刺激类型 | 示例 | 效果 |
|---|---|---|
| 关键词提示 | "重点关注：安全性、成本、可扩展性" | 聚焦特定维度 |
| 反面思考 | "请特别指出可能失败的原因" | 发现风险和盲点 |
| 角色对比 | "从 CTO 和 CFO 两个角度分别分析" | 多维度视角 |
| 约束提示 | "假设预算只有 5 万元" | 在限制条件下思考 |
逆向提示词（Reverse Prompting）
从输出反推 Prompt
当你看到一个好的 AI 输出但不知道 Prompt 怎么写时，可以让模型逆向推导：
逆向提示：
"以下是一段高质量的产品需求文档：
[粘贴优秀的 PRD 示例]
请分析这段文档的写作特点，并生成一个 System Prompt，
使得 AI 能够生成类似质量和风格的产品需求文档。"逆向提示词的产品应用
场景：标准化团队的 AI 使用质量
1. 收集团队中最好的 AI 使用案例
2. 用逆向提示提取其 Prompt 特征
3. 生成标准化的 Prompt 模板
4. 在团队中推广使用
这比让每个人自己摸索 Prompt 写法高效得多。Prompt 质量评估四步法
产品经理如何判断一个 Prompt 的好坏？
评估框架
┌─────────────────────────────────────────────┐
│ Prompt 质量评估四步法 │
├─────────────────────────────────────────────┤
│ │
│ Step 1: 明确性评估 │
│ ├── 任务描述是否清晰？ │
│ ├── 输出格式是否明确？ │
│ └── 边界条件是否定义？ │
│ │
│ Step 2: 鲁棒性测试 │
│ ├── 模糊输入能否正确处理？ │
│ ├── 极端情况会不会崩溃？ │
│ └── 多语言混合能否应对？ │
│ │
│ Step 3: 一致性验证 │
│ ├── 相同输入多次运行结果是否稳定？ │
│ ├── 相似输入的输出是否逻辑一致？ │
│ └── 格式是否始终符合要求？ │
│ │
│ Step 4: 效率评估 │
│ ├── Token 消耗是否合理？ │
│ ├── 能否在更少 Token 内达到同等效果？ │
│ └── 有无冗余指令？ │
│ │
└─────────────────────────────────────────────┘评估打分模板
| 维度 | 评分（1-5） | 权重 | 加权分 |
|---|---|---|---|
| 明确性 | ？ | 30% | ？ |
| 鲁棒性 | ？ | 25% | ？ |
| 一致性 | ？ | 25% | ？ |
| 效率性 | ？ | 20% | ？ |
| 总分 | ？/5 |
评分标准：
- 5 分：生产级质量，可直接上线
- 4 分：良好，少量调优即可
- 3 分：可用，但有明显改进空间
- 2 分：问题较多，需要重写
- 1 分：不可用
上下文工程（Context Engineering）
从 Prompt Engineering 到 Context Engineering
2025 年以来，业界开始提出"上下文工程"概念——Prompt 只是上下文的一部分，真正影响模型输出的是整个上下文窗口的内容组织：
上下文工程的四个组成部分：
┌─────────────────────────────────────────────┐
│ 上下文窗口 │
│ │
│ ┌──────────────────────┐ │
│ │ System Prompt │ ← 角色和规则 │
│ │ （系统提示） │ │
│ └──────────────────────┘ │
│ │
│ ┌──────────────────────┐ │
│ │ Retrieved Context │ ← RAG 检索结果 │
│ │ （检索上下文） │ │
│ └──────────────────────┘ │
│ │
│ ┌──────────────────────┐ │
│ │ Conversation History │ ← 对话历史 │
│ │ （对话上下文） │ │
│ └──────────────────────┘ │
│ │
│ ┌──────────────────────┐ │
│ │ User Message │ ← 当前用户输入 │
│ │ （用户消息） │ │
│ └──────────────────────┘ │
│ │
└─────────────────────────────────────────────┘上下文工程的核心原则
| 原则 | 说明 | 实践 |
|---|---|---|
| 相关性优先 | 只放与当前任务相关的信息 | 动态裁剪对话历史 |
| 距离效应 | 模型更关注上下文开头和结尾 | 关键信息放头尾 |
| 信息密度 | 高密度信息比冗长描述更有效 | 用结构化格式 |
| 一致性 | 上下文内的信息不能自相矛盾 | 定期检查冲突 |
上下文管理策略
对话轮次增多时的上下文管理：
轮次 1-3: 完整保留所有对话
轮次 4-8: 压缩早期对话为摘要
轮次 9+: 只保留关键信息 + 最近 3 轮
┌────────────────────────────────────┐
│ System Prompt（固定） │
│ ─────────────────────────────── │
│ 对话摘要（压缩的历史） │
│ ─────────────────────────────── │
│ 最近 3 轮完整对话 │
│ ─────────────────────────────── │
│ RAG 检索结果（动态） │
│ ─────────────────────────────── │
│ 当前用户消息 │
└────────────────────────────────────┘产品设计建议
上下文管理直接影响产品体验。如果对话超过 10 轮后模型"忘记"了之前的设定，通常是上下文管理策略的问题，而不是模型本身的问题。
高质量 Prompt 模板库
模板 1：需求分析 Prompt
你是一位资深 AI 产品经理。请对以下需求进行深度分析：
## 需求描述
{user_requirement}
## 请按以下框架分析：
### 1. 场景拆解
- 核心用户画像
- 使用场景和频率
- 现有解决方案的痛点
### 2. AI 可行性评估
- 适合用 AI 解决的部分
- 不适合用 AI 的部分
- 当前技术成熟度（1-5）
### 3. 方案建议
- 推荐的技术方案（Prompt/RAG/微调）
- 预估成本区间
- MVP 范围建议
### 4. 风险清单
- 技术风险
- 体验风险
- 合规风险
请用表格和列表组织输出，确保可操作性。模板 2：竞品分析 Prompt
你是一位 AI 行业分析师。请对以下 AI 产品进行深度竞品分析：
产品列表：{product_list}
分析维度：{dimensions}
请从以下角度分析：
1. **产品定位**：目标用户、核心价值主张
2. **AI 能力**：使用的模型、核心 AI 功能
3. **商业模式**：定价策略、变现方式
4. **差异化**：独特优势、护城河
5. **不足之处**：用户吐槽、体验短板
输出格式：先用对比表格总览，再逐个深入分析。模板 3：PRD 生成 Prompt
你是一位专业的产品文档撰写者。
请根据以下信息生成一份 AI 功能的产品需求文档：
功能名称：{feature_name}
功能描述：{description}
目标用户：{target_user}
PRD 结构要求：
1. 功能概述（50 字以内）
2. 用户故事（3-5 个 As a... I want... So that...）
3. 功能详细设计
- 输入/输出规格
- AI 模型要求
- 边界情况处理
4. 非功能需求
- 延迟要求
- 准确率要求
- 成本预算
5. 评估指标
6. 上线计划对大模型"叮嘱"：修复无灵魂回答
当模型回答太泛、太套路时，用以下技巧改善：
常见问题与修复策略
| 问题 | 原因 | 修复提示 |
|---|---|---|
| 回答太泛 | 缺少具体约束 | "请给出具体数据和案例，不要泛泛而谈" |
| 套话太多 | RLHF 过度对齐 | "直接给结论，跳过'这是一个好问题'等客套" |
| 不敢下判断 | 安全对齐 | "请给出你的明确建议，不要说'取决于具体情况'" |
| 格式混乱 | 指令不明确 | 提供输出示例模板 |
| 遗漏关键点 | 上下文不足 | 补充背景信息和约束条件 |
| 回答过长 | 缺少长度约束 | "请控制在 200 字以内" |
万能修复模板
在回答时请遵循以下原则：
1. 直接给结论，不要铺垫
2. 用具体数据/案例支撑，不要空谈
3. 如果不确定，说明置信度而不是回避问题
4. 控制在 {word_count} 字以内
5. 用 {format} 格式输出延伸阅读
- Prompt Engineering 基础 — 基础技巧回顾
- AI 应用架构模式 — Prompt 在系统架构中的位置
- RAG 深度实战 — 当 Prompt 不够时，用 RAG 增强
- 模型选型实战指南 — 不同模型对 Prompt 的响应差异