# 现代提示词工程总论

日期：2026-06-10

## 一、直觉

提示词工程不是“写一句神奇的话让 AI 变聪明”。

更准确地说，提示词工程是在给模型写一份任务说明书。模型越强，越不需要复杂咒语；但它仍然需要知道你要什么、基于什么材料回答、用什么格式输出、什么算合格、遇到不确定信息时如何处理。

一句成熟的判断是：

> 好提示词不是更长，而是更明确、更可验证、更少歧义。

本讲常见术语先按下面理解，详细定义和更多例子见 [00.5-术语词典与最小用例](00.5-术语词典与最小用例.md)。

| 术语 | 直觉解释 | 最小例子 |
| --- | --- | --- |
| 任务规格 | 把“想让 AI 做什么”写成可执行说明 | 目标、输入、约束、输出格式、验收标准 |
| zero-shot | 不给示例，直接提要求 | “请把下面文章总结成 5 条” |
| few-shot | 给少量示例让模型模仿 | 给 2 个“原文 -> 合格摘要”的例子 |
| 分隔符 / XML 标签 | 把材料和指令隔开，减少混淆 | `<原文>...</原文>` |
| JSON Schema | 程序能检查的 JSON 结构规则 | 字段必须有 `title`、`risk_level` |
| 思维链 | 模型内部推理细节 | 不要求完整展示，改要“结论、依据、核查点” |

## 二、结构化概念

现代提示词工程可以拆成六层。

### 1. 任务目标

先说明你要模型完成的最终任务。

差的写法：

```text
帮我看看这个判决书。
```

好的写法：

```text
请对以下民事判决书做结构化总结，重点提取案号、当事人、诉讼请求、法院查明事实、争议焦点、裁判理由和判决结果。
```

### 2. 角色与专业标准

角色不是越夸张越好。成熟写法是让角色服务于任务标准。

差的写法：

```text
你是全世界最厉害的律师。
```

好的写法：

```text
你是一名严谨的法律文书分析助手。只基于原文归纳，不补充案外事实，不提供未经原文支持的结论。
```

### 3. 上下文与输入边界

模型不知道哪些内容是材料，哪些内容是指令。要用明显边界隔开。

```text
<判决书全文>
这里粘贴原文
</判决书全文>
```

长文档任务尤其要注意：材料、问题、输出格式要分区。不要把要求和正文混在一起。

### 4. 约束条件

约束要具体，避免空泛。

```text
- 只基于原文。
- 原文未载明的信息写“原文未载明”。
- 金额、日期、案号、法院名称必须尽量按原文摘录。
- 不要把“原告诉称”“法院查明”“法院认为”混为一谈。
```

### 5. 输出格式

输出格式越稳定，后续越容易复用。总结类任务适合用标题和条目；程序处理类任务适合 JSON Schema 或表格；法律分析类任务适合按文书结构输出。

```text
请按以下结构输出：
一、案件基本信息
二、案件背景
三、诉讼请求
四、被告答辩
五、法院查明事实
六、争议焦点
七、法院裁判理由
八、判决结果
九、后续注意事项
```

### 6. 质量标准与自检

不要只说“写得好一点”。要告诉模型怎么检查。

```text
输出前请自检：
- 是否遗漏判决主文。
- 是否遗漏金额、日期、履行期限。
- 是否把一方主张误写成法院认定。
- 是否出现原文没有支持的推断。
```

## 三、先进但成熟的核心方法

### 1. 先定义成功标准，再改提示词

成熟提示词工程的第一步不是写提示词，而是定义“什么叫好”。例如判决书总结任务，可以设置这些检查项：

- 案件基本信息完整。
- 诉讼请求逐项列出。
- 裁判理由和判决结果分开。
- 金额、日期没有错。
- 没有原文外推断。

没有成功标准，就无法判断提示词是否变好。

### 2. 先试 zero-shot，再加 few-shot

现代强模型通常不需要一开始就塞很多例子。先用清晰直接的任务说明测试。如果输出格式不稳定、风格不稳定、分类边界不清，再加入 2-5 个高质量示例。

示例要覆盖真实边界情况，而不是只给最简单的样例。

### 3. 对推理模型少用“逐步思考”

新一代推理模型会在内部完成推理。很多官方实践都建议：不要机械要求模型展示完整思维链。更好的写法是要求它给出“结论、依据、检查过程、关键不确定点”。

推荐：

```text
请给出结论，并列出支持结论的关键依据。不要展开无关推理过程。
```

不推荐：

```text
请一步一步展示你的全部思考过程。
```

### 4. 用分隔符管理复杂上下文

当提示词里同时有任务、规则、材料、样例、输出格式时，使用 Markdown 标题或 XML 标签能显著减少误解。

```text
# 任务
...

# 规则
...

<输入材料>
...
</输入材料>

# 输出格式
...
```

### 5. 长文档任务要做“上下文工程”

长文档总结的关键不是让模型“认真读”，而是明确让它如何处理材料。

成熟做法：

- 把原文放入明确标签。
- 问题和输出要求放在材料之后。
- 要求模型区分“原文事实”和“分析归纳”。
- 对关键结论要求给出原文位置或原文依据。
- 文档特别长时，先分段提取，再合并总结。

### 6. 需要稳定结构时，不只靠自然语言

如果结果要进入程序、表格、数据库或自动流程，优先使用结构化输出、JSON Schema、函数调用或表单字段。自然语言提示词可以提高质量，但不能替代机器可校验的输出约束。

### 7. Agent 类任务要写工作流

让 AI 操作文件、写代码、查资料、调用工具时，只说“帮我完成”不够。要写清楚：

- 先读哪些信息。
- 什么时候计划。
- 什么时候执行。
- 什么时候验证。
- 什么时候停下来问用户。
- 如何汇报结果。

例如：

```text
你是一个代码助手。请先阅读相关文件，确认现有模式，再实现最小必要改动。修改后运行相关测试。如果测试无法运行，说明原因和剩余风险。不要改动无关文件。
```

### 8. 提示词也要版本管理

生产环境或长期使用的提示词，应该像代码一样管理：

- 记录版本。
- 记录修改原因。
- 保存失败样例。
- 建立小型测试集。
- 每次改提示词后跑同一组样例对比。

## 四、小例子：把普通请求升级成成熟提示词

普通请求：

```text
帮我总结这份判决书。
```

成熟版本：

```text
你是一名严谨的法律文书分析助手。请只基于我提供的民事判决书原文进行结构化总结，不补充案外事实，不给出未经原文支持的法律结论。

要求：
1. 原文未载明的信息写“原文未载明”。
2. 金额、日期、案号、法院名称、当事人名称必须尽量按原文摘录。
3. 区分原告诉称、被告辩称、法院查明、法院认为、判决结果。
4. 如果存在多个请求或多个被告，请分别列出。
5. 输出前检查是否遗漏判决主文、履行期限和费用承担。

请按以下结构输出：
一、案件基本信息
二、案件背景
三、原告诉讼请求
四、被告答辩意见
五、法院查明事实
六、争议焦点
七、法院裁判理由
八、判决结果
九、对当事人的影响
十、后续注意事项
十一、150 字以内极简摘要

<判决书全文>
在这里粘贴原文
</判决书全文>
```

这份提示词好在哪里：

- 任务清楚：结构化总结民事判决书。
- 边界清楚：只基于原文。
- 风险控制清楚：未载明就写未载明。
- 输出结构清楚：按判决书关键部分拆分。
- 自检标准清楚：检查主文、期限、费用。

## 五、常见误区

### 误区 1：提示词越长越好

不是。长提示词如果充满重复、冲突和空话，反而会降低效果。好的提示词应该信息密度高。

### 误区 2：角色越厉害越好

不是。“世界顶级专家”通常不如“按什么标准完成任务”有效。

### 误区 3：所有任务都要让模型一步一步思考

不是。对推理模型，过度要求展示思维过程可能无效甚至干扰。应该要求它输出结论、依据和核查点。

### 误区 4：靠提示词解决所有问题

不能。资料缺失要补资料，实时信息要联网或检索，稳定 JSON 要用结构化输出，复杂流程要用工具和评估。

### 误区 5：只写禁止项

“不要乱写、不要啰嗦、不要遗漏”不够。要告诉模型应该怎么写、按什么结构写、怎么判断完整。

## 六、理解检查

请你下次可以回答这 5 个问题：

1. 为什么说提示词工程不是“咒语”，而是“任务规格设计”？
2. 一个成熟提示词通常包含哪六个部分？
3. 为什么长文档任务要使用分隔符或 XML 标签？
4. 为什么不建议机械要求推理模型展示完整思维链？
5. 如果 AI 总是输出格式不稳定，你会优先改提示词的哪个部分？

## 七、下一步

下一讲建议学习：`01.5-AI辅助Prompt开发工作流.md`。先学习怎样让 AI 帮你把模糊需求变成可测试 Prompt，再进入 `02-从提示词到上下文工程.md`，把单条 Prompt 升级为完整上下文设计。