Appearance
Prompt Engineering
不是"写更好的问题"，而是理解 LLM 的推理机制并系统性设计输入以控制输出。Prompt Engineering 是 LLM 应用开发中最基础、最普适的技能——它决定了你是把 GPT-4 用成 GPT-3，还是把 GPT-3 用成 GPT-4。
Overview
Prompt Engineering（提示工程）指通过精心构造输入文本（Prompt）来引导大语言模型产生期望输出的技术与方法论。它不修改模型参数，完全通过输入层面的设计来释放模型能力。
随着模型能力增强，Prompt Engineering 的重心已从" tricks 和 hacks"转向系统性设计模式：清晰的指令结构、恰当的上下文组织、以及利用模型内在推理能力的策略性引导。
Core Techniques
基础范式
| 技术 | 描述 | 适用场景 |
|---|---|---|
| Zero-shot | 直接给出任务指令，不提供示例 | 模型能力已足够强的简单任务 |
| Few-shot | 提供 1-5 个输入-输出示例 | 需要特定格式、风格或复杂映射的任务 |
| System Prompt | 在对话开头设定角色、规则、约束 | 需要持续行为控制的对话/Agent 场景 |
| Role Prompting | 让模型扮演特定角色（"你是一位资深医生..."） | 需要领域专业知识或特定口吻 |
高级技术
| 技术 | 核心思想 | 效果 |
|---|---|---|
| Chain-of-Thought (CoT) | 在示例中展示推理步骤，引导模型逐步思考 | 数学、逻辑、多步推理任务准确率提升 20-40% |
| Self-Consistency | 多次采样取多数表决 | 进一步降低推理错误，计算成本换取可靠性 |
| Tree of Thoughts (ToT) | 维护多个推理路径，评估后选择最优 | 复杂决策、游戏、规划任务 |
| ReAct | 推理（Reasoning）+ 行动（Acting）交替 | Agent 场景，模型自主决定何时调用工具 |
| Prompt Chaining | 将复杂任务拆分为多个子 Prompt 串行执行 | 提高可靠性，降低单 Prompt 复杂度 |
The Prompt Structure Formula
一个生产级 Prompt 的标准结构：
[角色定义] → [任务描述] → [输入数据] → [输出格式] → [约束条件] → [示例]具体要素：
- 角色（Role）："你是一位专业的数据分析师..."
- 任务（Task）：清晰、具体、可验证的目标描述
- 上下文（Context）：模型需要知道但输入中未包含的背景信息
- 输入（Input）：待处理的具体数据
- 输出格式（Output Format）：JSON、Markdown、表格、特定字段——越具体越好
- 约束（Constraints）：长度限制、禁止内容、必须包含的元素
- 示例（Examples）：Few-shot 的核心，展示期望的输入-输出映射
Common Patterns
RAG Prompt 模板
基于以下检索到的上下文信息回答问题。如果上下文不足以回答，请明确说明。
上下文：
{retrieved_chunks}
问题：{user_question}
要求：
- 仅基于上下文回答
- 如果信息不足，回答"根据现有信息无法确定"
- 引用来源编号 [1], [2]...结构化输出 Prompt
将以下用户评论分析为 JSON 格式：
{
"sentiment": "positive|neutral|negative",
"topics": ["topic1", "topic2"],
"urgency": 1-5,
"action_required": true|false
}
评论：{user_comment}Agent 编排 Prompt（ReAct 风格）
你可以使用以下工具：
- search(query): 搜索网络信息
- calculator(expression): 计算数学表达式
- code_interpreter(code): 执行 Python 代码
每步思考后，以以下格式输出：
Thought: [你的推理过程]
Action: [工具名]([参数])
Observation: [工具返回结果]
最终答案以 "Final Answer:" 开头。Anti-Patterns & Pitfalls
| 反模式 | 问题 | 修正 |
|---|---|---|
| 过度指令 | 10 条以上的约束让模型困惑 | 聚焦 3-5 条核心约束 |
| 模糊目标 | "分析一下"——分析什么？ | 明确输出格式和评估标准 |
| 忽视 Token 限制 | Prompt 占满上下文窗口 | 精简示例，使用变量替换 |
| 静态 Prompt | 一套 Prompt 走天下 | A/B 测试、动态组装、版本管理 |
| 假设模型知道 | "像之前那样做" | 每次对话独立，提供完整上下文 |
| 过度依赖 Jailbreak | 用 trick 绕过安全限制 | 设计合法方式达成目标 |
Evaluation & Iteration
Prompt Engineering 是一个迭代优化过程：
- 建立评估集：20-50 个代表性输入，覆盖边界情况
- 定义成功标准：准确率、格式合规率、幻觉率
- A/B 对比：每次只改一个变量
- 版本管理：用 Git 管理 Prompt 模板，记录变更和效果
- 监控生产指标：真实用户输入的分布可能与测试集不同
工具生态：
- PromptLayer / LangSmith：Prompt 版本管理与 A/B 测试
- Weights & Biases Prompts：与训练流程集成的 Prompt 追踪
- OpenAI Evals：标准化评估框架
Why It Matters
- 零成本性能提升：同样的 GPT-4，好 Prompt vs 差 Prompt 的效果差距可达 2-3 倍——无需重新训练
- 应用开发的基础设施：所有 LLM 应用（RAG、Agent、代码生成）的底层能力
- 模型能力的风向标：Prompt 技术的演进（CoT → ReAct → ToT）反映了我们对模型推理机制理解的深化
- 与模型迭代的互补关系：模型变强会降低某些 Prompt 技巧的必要性，但系统性设计原则永远适用
Relationships
- 核心依赖：Chain-of-Thought & Reasoning — CoT 是 Prompt Engineering 最重要的技术突破
- 相关工具：AI Agents — Agent 的推理-行动循环依赖精心设计的 ReAct Prompt
- 输出控制：Structured Output / JSON Mode — JSON Mode / constrained generation 是 Prompt 结构化输出的技术保障
- 数据增强：Retrieval Augmented Generation — RAG 的 Prompt 设计决定了检索内容如何被有效利用
- 安全边界：AI Safety & Alignment — Prompt 注入（Prompt Injection）是 LLM 应用的核心安全威胁
Open Questions
- 随着模型推理能力增强（o1/R1 类模型），传统的 Few-shot CoT Prompt 是否会被模型自主推理取代？
- Prompt Engineering 是否会像 SQL 一样成为开发者的标准技能，还是被更高层的抽象（可视化编排工具）替代？
- 多模态 Prompt（图文混合输入）的设计范式尚未成熟——最佳实践是什么？
- 如何量化 Prompt 的"鲁棒性"——即对输入微小变化的敏感程度？