提示工程（Prompt Engineering）¶

提示工程是不修改模型参数的前提下，通过精心设计输入提示（Prompt），引导 LLM 输出高质量回答的技术。它是当前使用 LLM 最直接、最高效的方式。

为什么 Prompt 如此重要？¶

同一个模型，不同的 Prompt 可能带来天壤之别的效果：

Prompt 质量对比

差的 Prompt： "写一首诗"
→ 模型可能输出一首平庸的诗

好的 Prompt： "请以李白的风格，写一首关于月亮和思乡之情的五言绝句，要求意境深远、用词古朴"
→ 模型更可能输出高质量的诗作

Prompt Engineering 的本质是：用语言精确地传达你的意图、约束和期望，让模型准确理解你想要什么。

基础技巧¶

1. 角色设定（System Prompt）¶

给模型设定一个角色/身份，影响其回答的风格和专业度。

你是一位资深的 Python 后端工程师，有 10 年经验。
请用专业但易懂的方式回答技术问题。
如果不确定，请坦诚说明而不是猜测。

2. 明确任务和格式¶

不要让模型猜你想要什么格式——直接说明。

请分析以下代码的性能问题，输出格式如下：
1. 问题描述（一句话）
2. 问题原因（详细解释）
3. 优化方案（给出修改后的代码）

3. 提供上下文¶

模型不知道你的具体场景，你需要提供足够的背景信息。

我正在开发一个实时聊天应用，后端使用 FastAPI + WebSocket，
前端使用 React。当前用户量约 1000 人同时在线。
请帮我设计消息推送的架构方案。

4. 分隔符¶

用明确的分隔符区分指令和内容，避免歧义。

请将以下文本翻译为英文：

---
今天天气真好，适合出去散步。
---

核心策略¶

Few-shot Learning（少样本学习）¶

在 Prompt 中给出几个示例，让模型理解你期望的输入-输出模式。

策略	示例数量	适用场景
Zero-shot	0 个	任务简单明确
One-shot	1 个	需要明确格式
Few-shot	2~5 个	任务复杂或格式特殊

Few-shot 示例

将以下评论分类为"正面"或"负面"：

评论："这家餐厅的菜太好吃了！"
分类：正面

评论："等了一个小时才上菜，服务态度很差。"
分类：负面

评论："环境一般，但性价比还不错。"
分类：

模型会根据前面的示例，理解任务的模式并输出"正面"。

Few-shot 的选择技巧

示例应该覆盖多样性：包含不同类型的输入/输出
示例的质量要高：错误的示例会误导模型
示例与目标问题具有相关性：越相似效果越好

Chain-of-Thought（思维链推理） ⭐¶

CoT 是提示工程中最具突破性的技术——让模型逐步推理而非直接给出答案，显著提升了 LLM 在数学、逻辑、编程等推理任务上的表现。

有无 CoT 的对比

无 CoT：

问：一个牧场有 15 头牛和 20 只羊，又买了 3 头牛。牧场现在有多少动物？
答：38

有 CoT：

问：一个牧场有 15 头牛和 20 只羊，又买了 3 头牛。牧场现在有多少动物？
答：让我一步步思考：
1. 初始：15 头牛 + 20 只羊 = 35 只动物
2. 又买了 3 头牛：15 + 3 = 18 头牛
3. 总数：18 + 20 = 38 只动物
答案是 38。

CoT 的实现方式：

方式一：Zero-shot CoT（最简单）

只需在问题末尾加一句话：

问题：[你的问题]
让我们一步步思考。(Let's think step by step.)

这句话就像一把"钥匙"，能激活模型的推理能力。

方式二：Few-shot CoT

在示例中展示推理步骤，模型会模仿这种推理模式：

问：Roger 有 5 个网球，他又买了 2 罐网球，每罐有 3 个。他现在有多少个网球？
答：Roger 初始有 5 个球。2 罐 × 3 个/罐 = 6 个球。5 + 6 = 11。答案是 11。

问：食堂有 23 个苹果，用了 20 个做午餐，又买了 6 个。现在有多少个苹果？
答：

Self-Consistency（自一致性）¶

核心思想：多次推理，投票选最佳。

用 CoT 让模型对同一个问题推理多次（比如 5 次），每次用不同的推理路径
对所有最终答案进行多数投票，选出出现次数最多的答案

推理路径 1 → 答案：42
推理路径 2 → 答案：42
推理路径 3 → 答案：38
推理路径 4 → 答案：42
推理路径 5 → 答案：40

多数投票 → 最终答案：42 ✓

这种方法牺牲了推理速度，但显著提升了准确率。

Tree-of-Thought（思维树）¶

CoT 是线性推理（一条路走到底），而 ToT 将推理过程变成一棵树：

在每个推理步，生成多个可能的思路（分支）
对每个分支评估其前景（自评或投票）
选择最有前景的分支继续深入，剪掉差的分支
支持回溯——走到死胡同可以退回来尝试其他路径

graph TD
    A["问题"] --> B1["思路 A"]
    A --> B2["思路 B"]
    A --> B3["思路 C ✗"]
    B1 --> C1["A-1"]
    B1 --> C2["A-2 ✗"]
    B2 --> C3["B-1"]
    C1 --> D1["最终答案 ✓"]

适用于需要探索和回溯的复杂问题，如创意写作、数学证明、策略规划。

ReAct（Reasoning + Acting）¶

ReAct 让 LLM 交替进行思考和行动，将推理与外部工具调用结合起来。

问题：2024 年奥斯卡最佳影片的导演出生在哪个城市？

思考：我需要先查2024年奥斯卡最佳影片是什么。
行动：搜索("2024 奥斯卡最佳影片")
观察：2024年奥斯卡最佳影片是《奥本海默》，导演是克里斯托弗·诺兰。

思考：现在我需要查克里斯托弗·诺兰的出生地。
行动：搜索("克里斯托弗·诺兰 出生地")
观察：克里斯托弗·诺兰出生于英国伦敦。

思考：我现在有了完整的答案。
最终答案：克里斯托弗·诺兰出生于英国伦敦。

ReAct 是 Agent（智能体） 框架的核心推理模式，让 LLM 能够调用搜索引擎、计算器、代码执行器等外部工具。

高级技巧¶

输出约束¶

明确要求输出格式，便于程序解析：

请将以下文章的关键信息提取为 JSON 格式：
{
  "title": "文章标题",
  "summary": "一句话摘要",
  "keywords": ["关键词1", "关键词2"],
  "sentiment": "positive/negative/neutral"
}

负面指令¶

告诉模型不要做什么，有时比正面指令更有效：

请解释量子纠缠。
- 不要使用任何数学公式
- 不要假设读者有物理学背景
- 不要超过 200 字

拆解复杂任务¶

将复杂任务分解为多个简单步骤，逐步完成：

我需要你帮我完成一篇技术博客的写作。请按以下步骤进行：

第 1 步：根据主题"Transformer 注意力机制"列出文章大纲（5~7 个小节）
第 2 步：等我确认大纲后，逐节展开写作
第 3 步：最后添加一段总结和参考文献

Prompt 模板参考¶

通用问答模板¶

角色：你是 [领域] 的专家。
背景：[提供相关上下文]
任务：[明确的具体任务]
格式：[期望的输出格式]
约束：[限制条件]

输入：[具体问题或内容]

代码审查模板¶

请审查以下代码，从这几个维度评估：
1. 正确性：逻辑是否正确？
2. 性能：有无性能瓶颈？
3. 安全性：有无安全漏洞？
4. 可读性：命名和结构是否清晰？

对每个问题给出：[问题描述] → [修复建议] → [修改后的代码]

代码如下：
[粘贴代码]

常见误区¶

误区	正确做法
Prompt 写得越长越好	精练清晰更重要，去除冗余信息
一次让模型做所有事	复杂任务拆分为多步
认为 Prompt 对所有模型通用	不同模型对 Prompt 的响应不同，需要调试
不给示例直接问复杂问题	对复杂/格式敏感的任务，Few-shot 显著更好
忽略温度参数（Temperature）	事实性问题用低温（0_{0.3），创意任务用高温（0.7}1.0）