参考资料

• OpenAI Prompt Engineering
• OWASP Prompt Injection

Prompt Engineering（11） - 提示词模板与复用

读完后，你应能完成以下任务：

• 绘制“Prompt Engineering（11） - 提示词模板与复用 / 为什么要建模板库”的关键对象与数据流，解释“好提示词是你的劳动成果，不存下来就等于每次都白干。”，并用源码位置、日志或 Trace 标注证据。
• 为“Prompt Engineering（11） - 提示词模板与复用 / 什么样的提示词值得做成模板”设计正常与异常输入，验证“周报、日报、会议纪要这类周期性写作。”，输出首个偏差位置与回归测试结果。
• 实现“Prompt Engineering（11） - 提示词模板与复用 / 模板设计的三个原则”的最小代码或配置，检验“模板化的核心动作，就是把变的部分挖空，变成变量占位符。”，输出命令、结果与 Diff，并说明不适用边界。

本章目标：把零散的、调试好的提示词沉淀成可复用资产，学会用变量占位符做参数化，并系统地组织和管理自己的提示词库。

---

一、为什么要建模板库

你有没有过这种经历：上周费了好大劲调出一个特别好用的提示词，这周遇到类似任务，却怎么也想不起来当时怎么写的，又得从头折腾一遍。

好提示词是你的劳动成果，不存下来就等于每次都白干。 模板库要解决的就是这个：

• 省时间：同类任务直接套，不重复造轮子。
• 稳质量：用的是验证过的版本，不靠临场发挥。
• 能积累：用得越久，库越值钱，你的效率越高。
• 可分享：团队里一人调好，所有人都能用。

这一章讲的是「沉淀与复用」——把单个好提示词变成可反复使用的模板。注意和第 13 章区分：第 13 章是从零做一个完整项目，这一章是经营你的「提示词资产」。

---

二、什么样的提示词值得做成模板

不是每个提示词都要存。判断标准就一条：这类任务你以后还会反复遇到吗？

值得做成模板的：

• 周报、日报、会议纪要这类周期性写作。
• 数据提取、分类、打标签这类结构固定的处理任务。
• 翻译、润色、改写这类风格稳定的转换任务。

不值得的：一次性的、临时的、几乎不会再遇到的问题，问完就忘没关系。

---

三、模板设计的三个原则

3.1 原则 1：把「会变的」抽成变量，把「不变的」固化下来

一个提示词里，有些部分每次都一样（任务说明、格式要求、语气），有些部分每次都变（具体主题、具体数据）。模板化的核心动作，就是把变的部分挖空，变成变量占位符。

坏例子（写死了，只能用一次）：

请帮我把「第 3 季度华东区销售下滑」这件事，写成一段给销售总监看的周报汇报。

好例子（挖空成模板）：

请帮我把「{事件}」这件事，写成一段给{汇报对象}看的周报汇报。

下次换个事件、换个对象，填进去就能用。{事件} {汇报对象} 就是变量占位符。

3.2 原则 2：占位符要清晰、好认、不歧义

• 用 {变量名} 这种一眼能认出来的格式（也有人用 [变量名]、{{变量名}}，统一就好）。
• 变量名用有意义的词：写 {目标读者} 别写 {x}，过段时间你自己才看得懂。
• 在模板开头列出所有变量并说明，方便填空，也方便交给别人用。

3.3 原则 3：模板要自带「使用说明」

一个成熟的模板，不只是提示词正文，最好还附带：

• 用途：这个模板解决什么问题。
• 变量清单：每个变量填什么、举个例子。
• 适用 / 不适用场景：什么时候别用它。

这样三个月后的你，或者同事，拿来就能用，不用猜。

---

四、一个完整的模板长什么样

给你一个「可以直接抄进库里」的模板范本：

# 模板名称：客户反馈分类器
# 用途：把一条客户反馈自动归类，并判断紧急程度，输出 JSON
# 版本：v1.2
# 变量：
#   {反馈内容}  —— 客户原始反馈文本，例如「App 老闪退，给我退钱」
# 适用：单条反馈分类；不适用：批量（批量请改成循环调用）

----------- 提示词正文 -----------

请对下面这条客户反馈进行分类，按指定 JSON 格式输出。

【分类维度】
- category：只能是 ["功能问题", "体验建议", "价格疑问", "投诉", "其他"] 之一
- urgency：紧急程度，只能是 ["高", "中", "低"] 之一
- summary：一句话概括这条反馈

【输出要求】
- 严格输出 JSON，不要任何额外说明
- 拿不准的归到「其他」，不要硬塞

【反馈内容】
"""
{反馈内容}
"""

看，正文部分综合用上了前面的所有技巧（结构化、枚举约束、格式控制），头部注释让它成为一个可管理、可传承的资产，而不只是一段临时文字。

---

五、怎么组织和管理你的库

库小的时候随便放，库一大就乱。给几个实用建议：

5.1 按场景分类目录

我的提示词库/
├── 写作/
│   ├── 周报生成.md
│   ├── 公众号推文.md
│   └── 邮件回复.md
├── 数据处理/
│   ├── 客户反馈分类.md
│   └── 信息提取.md
├── 翻译/
│   └── 商务邮件翻译.md
└── 复杂工作流/
    └── 访谈转文章-四步链.md

按你最常用的维度分（场景、项目、客户都行），能快速找到就是好分类。

5.2 命名要见名知意

文件名直接说清「干什么的」：周报生成.md 比 prompt1.md 强一百倍。

5.3 做版本管理

提示词是会迭代的（第 08 章）。简单做法：在模板头部标 版本：v1.2，大改时保留旧版本（比如存成 周报生成-v1.md、周报生成-v2.md），方便对比和回退。讲究一点，可以把整个库丢进 Git 仓库，天然有版本历史。

5.4 记录「为什么这么写」

在模板里留一两句注释，说明某个约束是为了解决什么问题（比如「这里强制要 null 是因为之前模型会瞎编手机号」）。否则过段时间你可能会手贱删掉一个其实很关键的约束。

---

六、从手动套用到自动渲染

手动「复制模板 → 填空」已经能解决大部分场景。如果你会一点编程，可以再进一步：写个小脚本，传入变量字典，自动把占位符替换成实际值。 这样就能批量生成提示词，甚至接进自己的程序里。

本章的配套 Demo 就是这么一个用纯 Python 标准库写的「模板渲染器」：定义带 {变量} 的模板，传一个字典进去，自动渲染出最终提示词，还会在变量缺失时报错提醒你。这就是模板库从「文档」走向「工具」的第一步。

---

七、常见错误

1. 该抽变量的没抽：把具体内容写死在模板里，结果只能用一次，失去模板意义。
2. 变量名随便起：{a} {x} 这种，过两周自己都不知道填什么。
3. 存了不维护：模板用着用着发现有坑，却不更新回库里，下次又踩同一个坑。
4. 不写使用说明：光存一段提示词，过段时间忘了怎么用、变量填什么。
5. 过度模板化：把一次性问题也做成模板，徒增管理负担。值得复用的才存。

---

八、最佳实践

• 调好一个就顺手存一个：花力气调出来的好提示词，趁热存进库，别等以后。
• 变量清单写在模板头部：每个变量填什么、给个示例，自己和别人都省心。
• 按你最常用的维度分类：场景、项目、客户都行，能快速找到最重要。
• 大改保留旧版：方便对比效果、随时回退，最好用 Git 管。
• 关键约束写明原因：注释清楚「为什么有这条」，防止以后误删。

---

九、本章小结

• 好提示词是劳动成果，沉淀成模板才能反复复用、持续积累。
• 模板化核心三原则：抽变量、占位符清晰、自带使用说明。
• 库的管理：按场景分目录、命名见名知意、做版本管理、记录设计原因。
• 核心心法：把「会变的」挖成 {变量}，把「不变的」固化下来，让好提示词从一次性文字变成可复用资产。

下一章，我们聊一个做产品时绕不开的话题：当你的提示词要面对真实用户输入时，怎么防止它被「劫持」。

---

十、配套 Demo

见 提示词工程-demo/11-demo/：一个纯 Python 标准库写的模板渲染器 template_engine.py，用 {变量名} 占位符 + 字典渲染最终提示词，内置示例模板，变量缺失会报错提示。README 说明用法，不联网、不装包，直接 python3 跑通。

十一、动手实践：demo：提示词模板渲染器（纯 Python 标准库）

一个把「带 {变量名} 占位符的模板 + 变量字典」渲染成最终提示词的小工具。 对应第 11 章：把好提示词抽成模板、用占位符参数化、自动填充。只用标准库，不联网、不装包。

11.1 运行

python3 template_engine.py

会依次演示：正常渲染、另一个模板渲染、缺失变量报错、非严格模式保留占位符。

11.2 核心 API

11.3 两种模式

• 严格模式（默认 strict=True）：模板里有占位符却没在字典里给值，会抛 MissingVariableError，并列出缺了哪些变量。适合「一次性把提示词填完整」的场景，防止漏填。
• 非严格模式（strict=False）：缺失的占位符原样保留，方便「分多次填充」（比如先填固定部分，运行时再填动态部分）。

11.4 占位符规则

• 写法：{变量名}，变量名可用中文、字母、数字、下划线（如 {反馈内容}、{user_name}）。
• 同一个变量名出现多次，会被同一个值统一替换。
• 想输出字面的大括号文字（暂不支持转义），就避开占位符语法即可。

11.5 怎么扩展成你自己的模板库

把你调好的提示词加进 BUILTIN_TEMPLATES 字典，键是模板名、值是带 {变量} 的正文：

再大一点，可以把每个模板单独存成 .md 文件、按场景分目录（见第 11 章的库管理建议），用脚本读取后丢给 render 渲染。这就是从「文档型模板库」走向「工具型模板库」的起点。

十二、总结

• 为什么要建模板库：好提示词是你的劳动成果，不存下来就等于每次都白干。
• 什么样的提示词值得做成模板：判断标准就一条：这类任务你以后还会反复遇到吗？
• 模板设计的三个原则：模板化的核心动作，就是把变的部分挖空，变成变量占位符。
• 一个完整的模板长什么样：看，正文部分综合用上了前面的所有技巧（结构化、枚举约束、格式控制），头部注释让它成为一个可管理、可传承的资产，而不只是一段临时文字。
• 怎么组织和管理你的库：按你最常用的维度分（场景、项目、客户都行），能快速找到就是好分类。
• 从手动套用到自动渲染：这就是模板库从「文档」走向「工具」的第一步。