为什么需要 Prompt 模板化
我们已经讲了 Role Prompting（角色）、Instruction Engineering（指令精准）。但一个新问题浮现：
团队里每个人都在重复造轮子。
运营 A 写了个周报 Prompt 效果不错，运营 B 不知道，又从头写了一个。客服 C 的回复模板很高效，销售 D 遇到类似场景却不会用。一个月后，团队用了 50 个 Prompt，质量参差不齐，最佳实践无法沉淀。
Prompt 模板化解决三个问题：
- 复用：把验证过的 Prompt 封装成模板，一键复用
- 标准化：统一输出格式与质量标准
- 沉淀：个人经验转化为组织资产，人员流动不丢失
Prompt 模板的设计原则
原则 1：单一职责
一个模板只解决一类任务：
❌ "全能助手模板"（周报+邮件+总结+翻译）
✅ "周报生成模板"（只做周报）
✅ "客户跟进邮件模板"（只做邮件）
原则 2：变量抽象
把会变化的部分抽象为变量，固定部分写死：
✅ 固定：角色、输出格式、质量要求
✅ 变量：{{员工姓名}}、{{本周完成}}、{{下周计划}}、{{遇到问题}}
原则 3：自包含
模板应能独立使用，无需额外说明：
✅ 模板内含：
- 角色定义
- 任务描述
- 输入格式
- 输出格式
- 质量要求
- 自检清单
原则 4：可测试
模板应有验证标准，便于回归测试：
✅ 给定标准输入 A，期望输出包含 X、Y、Z
给定边界输入 B，期望输出标注"信息不足"
变量设计
变量类型
| 类型 | 示例 | 说明 |
|---|---|---|
| 必填变量 | {{content}} | 每次必填的核心输入 |
| 可选变量 | {{tone?}} | 有默认值的可选参数 |
| 条件变量 | {{if_urgent}} | 满足条件才生效 |
| 循环变量 | {{#items}}...{{/items}} | 列表循环 |
变量命名规范
✅ 语义化命名：{{employee_name}}、{{report_period}}
❌ 缩写命名：{{en}}、{{rp}}
✅ 标注类型：{{content:text}}、{{count:number}}、{{tags:array}}
❌ 无类型：{{content}}（不知是文本还是 JSON）
变量默认值
角色：{{role:资深数据分析师}}
语气：{{tone:专业简洁}}
长度：{{max_length:500字}}
用户不填时用默认值，降低使用门槛。
模板结构标准
一个完整的 Prompt 模板应包含六个区块：
## 元信息
- 模板名：周报生成器
- 版本：v1.2
- 作者：@zhangsan
- 适用场景：团队周报
- 推荐模型：GPT-4o / Claude 3.5
## 角色
你是一位{{role}}，负责{{responsibility}}。
## 任务
{{task_description}}
## 输入
- 汇报人：{{reporter}}
- 周期：{{period}}
- 本周完成：{{done}}
- 下周计划：{{plan}}
- 问题与风险：{{issues}}
## 输出格式
{{output_format}}
## 质量要求
1. {{quality_1}}
2. {{quality_2}}
## 自检
- [ ] 字数 ≤{{max_length}}
- [ ] 包含"本周完成""下周计划""问题"三段
- [ ] 每个完成项有量化结果
实战：从零设计一个"客户跟进邮件"模板
第 1 步：分析高频场景
销售团队每天写跟进邮件，场景包括：
- 首次接触
- 报价后跟进
- 方案发送后
- 成交后感谢
- 流失挽回
第 2 步：抽象共性
所有跟进邮件的共性：
角色：销售顾问
任务：写跟进邮件
输入：客户名、跟进阶段、上次沟通要点、本次目的
输出：邮件正文
质量：专业、简洁、有行动号召
第 3 步：设计变量
{{customer_name}} 必填，客户姓名
{{stage}} 必填，跟进阶段（首次/报价后/方案后/成交后/挽回）
{{last_contact}} 必填，上次沟通要点
{{this_purpose}} 必填，本次目的
{{product}} 可选，产品名
{{tone:专业友好}} 可选，语气
{{max_length:300字}} 可选，长度限制
第 4 步：编写模板
你是一位资深销售顾问，擅长撰写专业且有温度的客户跟进邮件。
## 任务
为以下场景撰写一封跟进邮件：
## 客户信息
- 客户姓名：{{customer_name}}
- 跟进阶段：{{stage}}
- 上次沟通要点：{{last_contact}}
- 本次目的：{{this_purpose}}
- 相关产品：{{product:我们的解决方案}}
## 输出要求
1. 语气：{{tone:专业友好}}
2. 长度：{{max_length:300字}}
3. 结构：称呼 → 上下文回顾 → 本次目的 → 行动号召 → 落款
4. 避免套话（如"希望您一切顺利"），用具体内容替代
## 自检
- 是否有明确的行动号召？
- 是否避免了通用套话？
- 长度是否在限制内？
第 5 步：测试与迭代
用 5 个不同阶段测试，记录输出质量，优化模板。
模板版本管理
像代码一样管理 Prompt 模板：
版本号规范
v1.0.0
│ │ │
│ │ └── 修复（不改逻辑）
│ └──── 功能（加变量/改格式）
└────── 重大（改架构）
变更日志
## v1.2.0 (2026-08-10)
- 新增 {{tone}} 变量
- 优化输出格式要求
- 修复"行动号召"偶尔缺失问题
## v1.1.0 (2026-08-05)
- 新增 {{product}} 变量
- 调整角色描述
## v1.0.0 (2026-08-01)
- 初始版本
Git 管理
把模板存为 .md 或 .yaml 文件，用 Git 管理：
prompts/
├── sales/
│ ├── follow-up-email.md
│ └── proposal-generator.md
├── marketing/
│ ├── seo-title.md
│ └── content-calendar.md
└── ops/
├── weekly-report.md
└── meeting-notes.md
团队共享机制
机制 1：模板库
建立团队模板库（如 我们的 Prompt 模板库），分类管理：
| 分类 | 模板数 | 示例 |
|---|---|---|
| 编程开发 | 5+ | 代码审查、提交信息 |
| 办公效率 | 5+ | 周报、会议纪要 |
| 营销文案 | 5+ | SEO 标题、多平台改写 |
| 数据分析 | 5+ | SQL 优化、竞品分析 |
| 学习研究 | 5+ | Few-shot 生成、Prompt 优化 |
机制 2：使用指南
每个模板附带：
- 适用场景说明
- 变量填写示例
- 输入输出示例
- 常见问题
机制 3：反馈与优化
用户使用模板 → 标记"好用/需改进" → 收集反馈 → 定期优化 → 发版
机制 4：权限控制
| 角色 | 权限 |
|---|---|
| 普通员工 | 使用模板 |
| 团队主管 | 编辑本团队模板 |
| 管理员 | 管理全库 |
模板的进阶模式
模式 1：嵌套模板
模板内调用其他模板：
{{include:weekly-report-header}}
{{include:weekly-report-body}}
{{include:weekly-report-footer}}
模式 2：条件模板
根据条件选择不同模板：
{{if stage == "首次"}}
{{include:first-contact-template}}
{{else if stage == "挽回"}}
{{include:win-back-template}}
{{else}}
{{include:general-follow-up}}
{{end}}
模式 3：链式模板
多个模板串联（Prompt Chaining）：
模板 1：生成周报草稿
↓ 输出
模板 2：润色语言
↓ 输出
模板 3：提取关键指标
模式 4：动态模板
根据输入自动选择最佳模板：
输入 → 分类器 → 选择模板 → 填充变量 → 生成
常见误区
- 误区 1：模板越多越好。10 个高质量模板胜过 100 个低质量模板，贵精不贵多。
- 误区 2：模板写完就结束。模板需要持续迭代，根据反馈优化。
- 误区 3：变量越多越灵活。过多变量增加使用门槛，3-7 个变量最佳。
- 误区 4：模板只给新人用。资深员工也应该用模板保证一致性。
- 误区 5：模板限制创造力。模板处理"格式与流程"，创意部分仍由人控制。
- 误区 6：用文档管理模板。文档难版本控制，用 Git 或专门平台管理。
工具推荐
| 工具 | 特点 | 适合 |
|---|---|---|
| Prompt 模板库（本站） | 内置 30+ 模板，在线使用 | 快速起步 |
| LangSmith Hub | LangChain 生态 | 开发者 |
| Promptflow | 微软出品 | 企业级 |
| Promptable | 开源 | 自部署 |
| Notion | 文档+数据库 | 轻量团队 |
与其他 Prompt 技巧的关系
| 技巧 | 与模板化的关系 |
|---|---|
| Role Prompting | 模板的"角色"区块 |
| Instruction Engineering | 模板的"任务"与"约束"区块 |
| Few-shot | 模板可内嵌示例 |
| Prompt Chaining | 模板的链式模式 |
最佳实践：先写好指令（Instruction Engineering），再封装为模板（模板化），最后按需串联（Chaining）。
小结
Prompt 模板化是 Prompt 工程的工程化阶段：从"个人写 Prompt"进化到"团队管理 Prompt 资产"。核心要点：
- 单一职责：一个模板解决一类任务
- 变量抽象：变化部分变量化，固定部分写死
- 版本管理：像代码一样管理模板
- 团队共享：个人经验沉淀为组织能力
当你发现团队里有人在重复写相似 Prompt 时，就是启动模板化的信号。
Prompt 工程进阶系列下一篇将讲 Prompt 评估与优化：如何量化衡量 Prompt 质量。