Prompt Engineering 入门指南：从原理到上手

5 分钟搞懂什么是 Prompt Engineering，附 3 类实战场景模板。

一句话讲清楚

Prompt Engineering 不是"写一句好的 prompt"，是"怎么让 LLM 稳定输出你想要的结果"的工程。

它和"写 prompt"的区别，类似"软件工程"和"写代码"的区别------前者关心设计、评估、迭代、失败模式，后者只是写出来。

必懂 5 个核心概念

1. ICL（In-Context Learning）

模型不需要训练，只通过 prompt 里的几个示例就能学会任务模式。

关键：样例的多样性 > 数量；格式会被强烈模仿；标签错了模型也会学错。

2. CoT（Chain-of-Thought）

让模型"先一步步想，再答"------适合数学题、逻辑题、复杂推理。

不适用：简单分类、命名实体识别、翻译（反而拖后腿 + 烧 token）。

3. RAG（Retrieval-Augmented Generation）

在 prompt 里塞入外部检索到的资料，让模型基于真实信息回答。

解决两个问题：幻觉（模型编造）、知识截止（训练数据过期）。

注意：RAG 减少幻觉，但不消除------模型还会补充资料外信息。

4. Agent

LLM + 记忆 + 工具 + 规划------模型不仅"想"，还能"做"（调数据库、跑代码、调 API）。

核心范式：ReAct（Reasoning + Acting 交替）。

5. Prompt Chaining

单个 prompt 搞不定？拆成多个 prompt 串行------前一步输出喂给下一步。

代价：错误会累积。5 步链准确率 ≈ 0.95^5 ≈ 77%。

5 层知识地图（求职用这张图）

复制代码

        ┌─────────────────┐
        │  第五层：高级范式  │  RAG / Agent / Fine-tuning
        ├─────────────────┤
        │  第四层：系统化方法 │  评估 / 迭代 / 版本管理
        ├─────────────────┤
        │  第三层：核心技巧   │  CoT / ReAct / Chaining
        ├─────────────────┤
        │  第二层：解剖学     │  角色 / 指令 / 上下文 / Few-shot / 格式
        ├─────────────────┤
        │  第一层：地基      │  Token / 续写 / ICL / 上下文窗口
        └─────────────────┘

面试被问到，直接画这张图。

3 类高频实战场景

场景 1：分类任务

markdown 复制代码

# 角色
你是一位资深的用户评论分析师。

# 输入
<comment>
{comment}
</comment>

# 输出格式（严格遵守）
```json
{
  "sentiment": "positive | negative | neutral",
  "confidence": 0.0-1.0,
  "key_evidence": "从原文中复制的关键短语"
}

规则

positive：明确表达满意、推荐
negative：明确表达不满、批评
neutral：客观描述、无法判断
文本过短 → 强制 neutral
不要因为单个否定词就判负面

示例

输入：「这个产品真的太好用了！强烈推荐！」

输出：{"sentiment": "positive", "confidence": 0.95, "key_evidence": "太好用了、强烈推荐"}

复制代码

### 场景 2：信息提取任务

```markdown
# 任务
从合同文本中提取指定字段，JSON 输出。

# 输入
<contract>
{contract_text}
</contract>

# 待提取字段
- party_a, party_b: 合同双方
- amount: 金额（纯数字）
- start_date, end_date: 起止日期（YYYY-MM-DD）
- breach_clause: 违约责任

# 严格规则
1. 字段在原文找不到 → 输出 null，禁止编造
2. 日期必须是 YYYY-MM-DD 格式
3. 金额必须转为纯数字
4. 只输出 JSON，不要解释

场景 3：RAG 文档问答

markdown 复制代码

# 角色
你是企业知识库助手，基于内部文档回答问题。

# 输入
<user_question>
{user_question}
</user_question>

<retrieved_documents>
{retrieved_docs}
</retrieved_documents>

# 规则
1. 严格基于 <retrieved_documents> 回答
2. 不要补充文档外信息
3. 文档中没有答案 → 明确说"根据提供的资料，无法回答"
4. 引用用 [1][2] 标注来源

# 输出格式
## 答案
<具体回答>

## 引用来源
[1] <文档标题>

3 个最易踩的坑

1. 角色 prompt 是安慰剂

「你是一位世界顶级专家」对事实任务几乎没用。要写就写行为：擅长 X、避免 Y、输出含 Z。

2. Few-shot 不是越多越好

最优区间是 3-7 个。超过 10 个，边际收益归零，还挤占指令空间。

3. CoT 用错任务 = 烧钱

简单任务用 CoT，输出 token 增 5-10 倍，准确率只提 0-3%。

评估方法（一句话版）

小规模：人工标注 50-100 条测试集
大规模：LLM-as-Judge（注意 6 种偏置：位置、长度、自我、风格、锚定、复杂性）
生产：用户反馈闭环 + 定期回流扩充测试集

面试高频题（一句话答法）

题目	关键答法
什么是 Prompt Engineering？	系统化设计、迭代、评估 prompt 的工程学科
Few-shot 为什么有效？	临时塑造 token 分布，模型顺着续写（不是真的学习）
CoT 为什么有效？	显式化推理过程，每步有 token 预算思考
RAG vs Fine-tuning？	RAG 适合知识更新 + 引用；Fine-tuning 适合固定领域 + 延迟敏感
Agent 是什么？	LLM + 记忆 + 工具 + 规划，能自主完成多步任务

学习路径（最少必要）

入门：读 Lilian Weng《Prompt Engineering》综述（免费神作）
上手：选一个真实任务写 5 个版本对比
进阶：用 prompt + LLM 做一个小项目（周报、客服、文档问答）
求职：能讲清 5 个概念 + 写出 3 类场景 prompt + 解释清楚评估方法

一句话总结

Prompt Engineering = 怎么问 + 怎么改 + 怎么判断好坏。