name: prompt-template-designer description: | 设计可复用的提示词模板，为重复性AI任务编码领域特定模式。 当你已执行类似提示2次以上且需要将模式捕获为可复用智能时使用。不适用于一次性提示或通用的“向AI提问”模式。 category: intelligence-design version: “2.0.0” dependencies: [“constitution:v6.0.1”, “4-layer-teaching-method”]
提示词模板设计师
快速开始
# 1. 检查是否值得模板化
# 标准：2次以上使用，5个以上决策点，领域特定
# 2. 提取模式
# 识别不变量（常量）与变量（参数）
# 3. 创建模板
# 使用意图 → 约束 → 成功标准结构
角色定位
像模式库设计师一样思考，提取重复出现的提示结构。识别什么会变化（参数）与什么保持不变（模式），将领域知识编码为约束，并设计能减少认知负荷同时保持质量的模板。
分析问题
1. 重复性检查
“我是否已使用此模式2次以上？”
| 场景 | 是否模板化？ |
|---|---|
| “生成Git提交信息”（每日） | 是 |
| “向新开发者解释React hooks”（一次） | 否 |
| “调试Bash权限错误”（重复出现） | 是 |
| “研究特定API怪癖”（独特） | 否 |
原则：过早模板化会增加维护负担。等待第二次使用。
2. 变化分析
“什么保持不变，什么会变化？”
| 类型 | 定义 | 示例 |
|---|---|---|
| 不变量 | 模板结构 | 意图动词、核心约束、输出格式 |
| 变量 | 参数 | 文件名、项目上下文、阈值 |
3. 复杂性检查
“此任务是否有5个以上决策点？”
高价值模板（5+决策点）：代码审查提示（动作动词、语言、审查重点、输出格式、严重级别、风格指南、上下文、修复与识别）
低价值（1-3决策点）：“解释特定Git命令” → 直接提问即可
4. 领域知识检查
“此模板是否编码了领域特定智能？”
高价值：团队约定、质量标准、项目约束 低价值：通用的“向AI提问”或“生成代码”
5. 参数设计
“什么参数能使模板灵活但不模糊？”
| 模式 | 示例 |
|---|---|
| 枚举 | {{动作类型}} - 值：[创建, 调试, 重构] |
| 路径 | {{目标文件}} - 类型：文件路径 |
| 文本 | {{所做更改}} - 类型：项目符号列表 |
| 复合 | {{错误上下文}} - 必填字段：错误信息、文件位置 |
规则：3-7个参数为最佳。更多 → 拆分为多个模板。
原则
原则1：重复2次以上再模板化
- 首次使用：直接编写提示
- 第二次使用：注意模式，提取模板
- 第三次及以上使用：使用模板，优化
原则2：参数化优于硬编码
# 之前（硬编码）
调试 backup.sh 出现“权限被拒绝”错误
# 之后（参数化）
调试 {{脚本名称}} 出现“{{错误信息}}”错误
原则3：记录成功模式
模板必须包含：
- 何时使用（触发条件）
- 为何有效（编码的模式）
- 填充示例（具体实例）
- 常见错误（需避免之处）
原则4：版本化与演进
### v2.0.0 (2025-11-18)
- 重大变更：将 {{更改}} 改为结构化的 {{所做更改}}
- 新增“业务价值”要求
### v1.0.0 (2025-10-15)
- 从成功提示中初步提取
原则5：衡量有效性
| 指标 | 目标 |
|---|---|
| 成功率 | >85% |
| 节省时间 | 可衡量 |
| 所需迭代次数 | <3 |
| 团队采用率 | >50% |
模板结构
---
template_name: {{描述性名称}}
category: {{创建|调试|重构|优化|分析|生成}}
domain: {{后端|前端|运维|测试|文档}}
version: {{语义化版本}}
success_rate: {{百分比}}
---
# {{模板名称}}
## 何时使用
{{触发条件}}
## 参数
### {{参数_1}}
- **类型**：{{枚举|路径|文本|复合}}
- **示例**：{{值}}
- **必填**：{{是|否}}
## 模板
\```
意图：
{{动作动词}} {{带参数的描述}}
约束：
- {{不变约束}}
- {{使用 {{参数}} 的参数化约束}}
成功标准：
- {{可衡量标准}}
\```
## 示例（已填充）
{{具体实例}}
## 常见错误
- {{反模式及如何避免}}
示例：Git提交信息生成器
---
template_name: git-commit-message-conventional
category: generate
version: 2.0.0
success_rate: 95%
---
## 参数
- **所做更改**：更改列表（必填）
- **JIRA工单**：PROJ-NNNN格式（必填）
- **范围**：[认证, 接口, 界面, 数据库, 运维]（必填）
- **类型**：[功能, 修复, 文档, 重构, 测试]（必填）
## 模板
\```
生成 Git 提交信息
更改：{{所做更改}}
约束：
- 格式：{{类型}}({{范围}}): <描述> [{{JIRA工单}}]
- 主题：祈使语气，<50字符
- 正文：解释原因（业务价值）
成功标准：
- 通过 commitlint 检查
- 队友无需阅读差异即可理解
\```
## 示例（已填充）
\```
功能(认证): 添加JWT刷新端点 [PROJ-1234]
- 添加 /auth/refresh：通过消除重新登录提升移动端用户体验
- 令牌延长至24小时：减少认证摩擦
\```
## 常见错误
- 忘记Jira工单
- 使用过去时（“已添加”）而非祈使语气（“添加”）
- 解释“是什么”而非“为什么”
反模式
| 反模式 | 症状 | 修复方法 |
|---|---|---|
| 模式未现先模板 | 为未使用的提示创建模板 | 先手动使用2次以上 |
| 过度参数化 | 15个以上参数 | 目标3-7个，若更多则拆分 |
| 参数化不足 | 仅适用于单一场景 | 必须适用于3个以上用例 |
| 无成功指标 | 从未追踪质量 | 追踪成功率、节省时间 |
快速参考
模板创建清单：
- [ ] 模式已使用2次以上？
- [ ] 识别常量与变量？
- [ ] 5个以上决策点？
- [ ] 参数附带示例？
- [ ] 包含填充示例？
- [ ] 定义成功标准？
参数设计：
- [ ] 描述性名称（非 {{X}}）？
- [ ] 指定类型？
- [ ] 提供示例？
- [ ] 标记必填/可选？
教学集成（L2 → L3）
转换信号：学生已编写类似提示2次以上，成功率85%以上
教学序列：
- “你之前做过这个。有什么相似之处？”（识别重复性）
- “两次中出现了哪些约束？”（提取常量）
- “什么发生了变化？”（参数化变量）
- “让我们将其形式化为可复用智能”（创建模板）
若验证失败
- 检查重复性：“此模式是否已使用2次以上？”
- 检查复杂性：“是否有5个以上决策点？”
- 检查参数：“是否有3-7个设计良好的参数？”
- 停止并报告，若模板增加的认知负荷超过其节省的