现代提示词工程总论

日期：2026-06-10

一、直觉

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

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

一句成熟的判断是：

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

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

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

二、结构化概念

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

1. 任务目标

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

差的写法：

帮我看看这个判决书。

好的写法：

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

2. 角色与专业标准

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

差的写法：

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

好的写法：

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

3. 上下文与输入边界

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

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

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

4. 约束条件

约束要具体，避免空泛。

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

5. 输出格式

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

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

6. 质量标准与自检

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

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

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

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

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

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

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

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

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

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

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

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

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

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

# 任务
...

# 规则
...

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

# 输出格式
...

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

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

成熟做法：

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

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

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

7. Agent 类任务要写工作流

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

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

例如：

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

8. 提示词也要版本管理

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

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

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

普通请求：

帮我总结这份判决书。

成熟版本：

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

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

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

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

这份提示词好在哪里：

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

五、常见误区

误区 1：提示词越长越好

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

误区 2：角色越厉害越好

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

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

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

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

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

误区 5：只写禁止项

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

六、理解检查

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

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

七、下一步

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