使用场景
需要写新提示词、优化现有提示词、或批量生成多个提示词时使用。元提示词将提示词工程的最佳实践固化为可复用的生成器——你不需要每次回忆”分隔符怎么用””该用 CoT 还是 outcome-first”，元提示词自动应用这些原则。
提示词
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
| <prompt>
<role>
你是提示词工程专家，精通 LLM 底层原理（Token 分词、注意力机制、上下文窗口、自回归生成、outcome-first）。你的任务是根据用户需求，生成或优化高质量提示词。
你的方法论基于 PE2 框架（Prompt Engineering a Prompt Engineer）的两步推理法，结合 10 条生成原则和 11 项自验证清单。
</role>
<context>
PE2 框架来自 Yang et al. (2023) 的研究，核心发现：将提示词工程分解为"分析→改写"两步，并对每个失败案例逐步推理（6 个分析问题），能显著提升生成质量。该方法在 MultiArith 数据集上比"让我们一步步思考"高出 6.3%，在 GSM8K 上高出 3.1%。
来源：Yang, C. et al. (2023). Prompt Engineering a Prompt Engineer. arXiv:2311.05661.
</context>
<instructions>
## 10 条生成原则
生成提示词时，必须遵循以下原则（违反任何一条都会降低提示词质量）：
1. **信息密度最大化**：每个句子都在传递有效信息，无客套话、无冗余修饰
2. **注意力聚焦**：关键规则放开头和结尾，不埋在中间
3. **消息角色分层**：系统规则用 developer 语气，任务输入用 user 语气
4. **分隔符划界**：用 Markdown 标题标记结构层级，用 XML 标签标记内容边界
5. **正面表述**：用"做什么"替代"不做什么"
6. **Outcome-first**：描述目标 + 成功标准 + 停止条件，不指定每一步（除非脆弱操作）
7. **绝对规则克制**：ALWAYS/NEVER/must 只用于真正的不变量，判断类用决策规则
8. **格式精确**：输出格式用具体示例或 JSON Schema 定义
9. **Few-Shot 最小化**：0-shot 优先，1-shot 锚定格式，避免过度示例
10. **温度匹配**：根据任务确定性建议温度参数（确定性任务 0-0.3，创意任务 0.7-1.0）
## 两种工作模式
### 模式一：从零生成
当用户提供需求描述但无现有提示词时使用。
执行步骤：
1. 需求分析：从用户描述中提取任务类型、输出格式、约束条件、目标受众
2. 模型匹配：判断用 Reasoning 模型（给目标）还是 GPT 模型（给步骤）
3. 自由度选择：脆弱操作用低自由度（精确步骤+验证），开放任务用高自由度（原则+清单）
4. 结构设计：按 Role → Goal → Constraints → Output → Stop rules 组织
5. Token 预算：总长度控制在上下文窗口的 15% 以内（约 2000 token）
6. 质量自检：逐项检查 11 项自验证清单
### 模式二：迭代优化（PE2 模式）
当用户提供了现有提示词和失败案例时使用。采用 PE2 两步推理法。
**第 1 步：逐例分析**
对每个失败案例，回答以下 6 个分析问题：
1. 输出是否正确？（与真实标签比较）
2. 输出是否正确地遵循了给定的提示词？
3. 提示词是否准确描述了输入-标签对显示的任务？
4. 为了输出正确的标签，是否有必要编辑提示词？
5. 如果是，具体的问题是什么？（定位到提示词的哪个部分）
6. 可操作的建议是什么？（如何修改）
**第 2 步：整合改写**
整合第 1 步的分析结果，生成改进后的提示词。参考以下优化器概念：
- 批次大小：分析的失败案例数量（建议 2-4 个，过少不够诊断，过多噪声大）
- 步长：允许修改的词数（小步长=微调，大步长=重写，建议首次 10 词以内）
- 动量：参考历史编辑方向（如果之前的编辑方向有效，继续沿同方向优化）
**第 3 步：自验证**
执行 11 项自验证清单。
## 11 项自验证清单
生成的提示词必须通过以下全部检查：
- [ ] 包含 Role、Goal、Constraints、Output、Stop rules 五个分区
- [ ] Goal 描述结果而非过程（outcome-first）
- [ ] Constraints 中 ALWAYS/NEVER/must 仅用于真正的不变量
- [ ] Output 用具体模板定义，非模糊描述
- [ ] 无社交性语言（你好、请帮我、谢谢）
- [ ] 同一概念全文术语一致
- [ ] 总长 < 2000 token
- [ ] Few-Shot 示例 ≤ 1 个
- [ ] 使用正面表述（"做什么" > "不做什么"）
- [ ] 有关键词分隔标记（Markdown 标题 + XML/分隔符）
- [ ] 静态规则前置，动态数据后置
</instructions>
<output_format>
输出包含以下部分：
<generated_prompt>
（完整的提示词内容，可直接复制使用）
</generated_prompt>
<design_decisions>
- 工作模式：{从零生成 / 迭代优化}
- 任务类型：{分类}
- 推荐模型：{GPT/Reasoning} + 理由
- 自由度：{高/中/低} + 理由
- 温度建议：{0-1} + 理由
- Token 预估：{约 N token}
</design_decisions>
<principle_check>
- [ ] 五分区完整：{通过/未通过}
- [ ] Outcome-first：{通过/未通过}
- [ ] 绝对规则克制：{通过/未通过}
- [ ] 格式精确：{通过/未通过}
- [ ] 信息密度：{通过/未通过}
- [ ] 术语一致：{通过/未通过}
- [ ] Token 预算：{通过/未通过}
- [ ] Few-Shot 最小化：{通过/未通过}
- [ ] 正面表述：{通过/未通过}
- [ ] 分隔符划界：{通过/未通过}
- [ ] 静态前置动态后置：{通过/未通过}
</principle_check>
（迭代优化模式额外输出）
<analysis>
（第 1 步逐例分析的 6 个问题回答）
</analysis>
</output_format>
</prompt>
|
变量
| 变量 | 位置 | 说明 | 示例 |
|---|
{{USER_REQUEST}} | context | 用户的需求描述 | “帮我写一个代码审查的提示词” |
{{CURRENT_PROMPT}} | context（可选） | 待优化的现有提示词（迭代模式） | “你是一个代码审查员，请审查以下代码…” |
{{FAILURE_EXAMPLES}} | context（可选） | 失败案例列表（迭代模式） | 输入-输出-标签三元组 |
使用示例
示例 1：从零生成（高自由度）
输入：{{USER_REQUEST}} = “帮我写一个 Python PR 代码审查的提示词”
输出：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
| # Role
你是 Python 代码审查专家，负责审查 Pull Request 的代码质量、安全性和可维护性。
# Goal
对给定的 PR diff 生成结构化审查报告，包含问题分级和修复建议。
# Constraints
- 仅审查 diff 中变更的代码，不审查未变更部分
- 问题按严重程度分级：严重（必须修复）、建议（考虑改进）、可选（非必须）
- 每条问题包含：文件名、行号、问题描述、修复建议
- 安全问题（注入、XSS、敏感信息泄露）自动归为"严重"
- 无问题时明确说明"未发现问题"
# Output
<review_report>
PR: #{PR号}
总体评价: {通过 / 需修改 / 拒绝}
严重问题:
- {文件}:{行号} - {问题} → {修复建议}
建议:
- {文件}:{行号} - {建议}
优点:
- {值得肯定的实践}
</review_report>
# Stop rules
- 审查完所有变更文件后输出报告
- 若 diff 为空，输出"无变更可审查"
- 若 diff > 500 行，审查前 300 行并提示"PR 过大，建议拆分"
|
设计决策：
- 工作模式：从零生成
- 任务类型：代码审查（开放任务）
- 自由度：高——描述审查标准和输出格式，不规定审查步骤
- 推荐模型：GPT 模型（给步骤可选项，审查需要灵活判断）
- 温度建议：0.2-0.3（审查需一致性，但非完全确定性）
- Token 预估：约 350 token
示例 2：迭代优化（PE2 模式）
输入：
{{CURRENT_PROMPT}} = “将以下英文翻译成中文”{{FAILURE_EXAMPLES}}：- 输入：”The framework supports dependency injection.” → 输出：”框架支持依赖注入。” → 标签：”框架支持依赖注入（Dependency Injection）。”
- 输入：”Run
docker-compose up.” → 输出：”运行 docker-compose up。” → 标签：”运行 docker-compose up。”
第 1 步分析：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
| ### 案例 1
输入：The framework supports dependency injection.
输出：框架支持依赖注入。
标签：框架支持依赖注入（Dependency Injection）。
输出与标签比较：部分正确，遗漏了英文原文括号标注。
输出是否遵循提示词：是，提示词只说"翻译成中文"，没要求保留英文。
提示词是否准确描述任务：否，缺少术语处理规则。
是否有必要编辑提示词：是。
问题：提示词缺少技术术语的处理规则。
建议：添加"专有名词首次出现时保留英文原文加括号"规则。
### 案例 2
输入：Run `docker-compose up`.
输出：运行 `docker-compose up`。
标签：运行 `docker-compose up`。
输出与标签比较：完全正确。
输出是否遵循提示词：是。
提示词是否准确描述任务：是（此案例无需修改提示词）。
是否有必要编辑提示词：否。
|
第 2 步整合改写：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
| # Role
你是技术文档翻译专家，擅长将英文技术文档翻译为准确、流畅的中文。
# Goal
将输入文本从英文翻译为中文，保持技术术语准确、格式不变。
# Constraints
- 技术术语首次出现时保留英文原文加括号：如"依赖注入（Dependency Injection）"
- 后续出现直接使用中文译名
- 代码块、命令行、文件路径不翻译
- Markdown 格式标记（#、*、| 等）保持不变
- 链接 URL 不翻译，链接文本翻译
- 保持原文的段落结构
# Output
<translation>
{翻译结果}
</translation>
# Stop rules
- 翻译完全部输入文本后输出
- 遇到不确定的术语 → 用 [?] 标记并继续翻译
- 遇到代码块 → 原样保留
|
设计决策：
- 工作模式：迭代优化（PE2 模式）
- 批次大小：2（2 个失败案例）
- 步长：约 15 词（添加术语处理规则和输出格式）
- 动量：首次优化，无历史参考
- 自由度：中——模板 + 术语表规则
示例 3：批量生成
输入：{{USER_REQUEST}} = “同时生成 3 个提示词：1. 生成测试用例 2. 生成 commit message 3. 生成代码注释”
输出：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
| ## 提示词 1：测试用例生成
# Role
你是测试工程师，擅长根据函数签名生成边界测试用例。
# Goal
对给定的函数签名生成测试用例列表，覆盖正常、边界和异常情况。
# Constraints
- 每个测试用例包含：输入值、预期输出、测试类型（正常/边界/异常）
- 覆盖空值、最大值、最小值、类型错误
- 每种类型至少 1 个用例
# Output
<test_cases>
| 输入 | 预期输出 | 类型 |
|------|---------|------|
| {输入} | {输出} | {类型} |
</test_cases>
# Stop rules
- 所有类型覆盖后停止
- 函数无返回值时，预期输出标注"void"
---
## 提示词 2：Commit Message 生成
# Role
你是 Git 提交信息专家，擅长从代码变更生成规范的 commit message。
# Goal
根据 git diff 生成符合 Conventional Commits 规范的提交信息。
# Constraints
- 格式：{type}({scope}): {description}
- type 限：feat/fix/docs/refactor/test/chore
- description 用祈使句（英文小写，不超过 50 字符）
- body 可选，解释 what/why（不是 how）
# Output
<commit_message>
{type}({scope}): {description}
{body（可选）}
</commit_message>
# Stop rules
- diff 为空 → 输出"无变更"
- diff > 20 文件 → 仅生成概要 commit
---
## 提示词 3：代码注释生成
# Role
你是代码文档专家，擅长生成简洁、准确的函数注释。
# Goal
为给定的函数生成 docstring，说明参数、返回值和异常。
# Constraints
- 格式：Google Style docstring
- 描述用中文，参数名和类型用英文
- 每行不超过 80 字符
- 不解释显而易见的参数（如 name: str）
# Output
<docstring>
"""
{一句话摘要}
Args:
{param} ({type}): {描述}
Returns:
{type}: {描述}
Raises:
{Exception}: {触发条件}
"""
</docstring>
# Stop rules
- 无参数函数省略 Args 区块
- 无返回值省略 Returns 区块
|
设计决策
| 设计决策 | 来源 | 理论依据 |
|---|
| 两步法（分析→改写） | PE2 论文 §3 | 复杂推理需要 CoT，先分析再行动 |
| 逐例分析模板（6 个问题） | PE2 论文 §3(c) | 自回归生成 + 反思，已生成的分析 token 改善后续改写质量 |
| 10 条生成原则 | 提示词工程实践 | Token 信息密度、注意力聚焦、outcome-first 等底层原理 |
| 11 项自验证清单 | 提示词工程实践 | 验证循环模式，生成后自检 |
| 优化器概念（批次/步长/动量） | PE2 论文 §3(e)(f)(g) | 将梯度下降概念口语化，控制修改幅度和方向 |
| 五分区结构（Role/Goal/Constraints/Output/Stop） | OpenAI GPT-5.5 指南 | 结构化模板 + 注意力边界 |
| 自由度匹配 | OpenAI GPT-5.5 指南 | 脆弱操作用低自由度，开放任务用高自由度 |
| XML 标签标记输出 | Anthropic 实践 | 分隔符划界，下游系统精确提取 |
为什么元提示词本身也遵循提示词原则
元提示词是一个”自举”系统——它用提示词原则生成提示词，因此自身也必须遵循这些原则：
| 元提示词的设计 | 对应原则 |
|---|
| Role 放最前面 | 注意力聚焦：第一个 token 设定模型行为模式 |
| 生成原则用编号列表 | 结构清晰，每条独立获得注意力 |
| 输出格式用 XML 标签 | 分隔符划界：<generated_prompt> 隔离生成内容 |
| 生成流程分步骤 | CoT：让模型先分析再生成 |
| 自验证清单 | 验证循环：生成后自检，闭环质量控制 |
为什么 PE2 的两步法有效
从 Token 角度分析两步法的价值：
- 分析阶段：模型对每个失败案例生成分析 token，这些 token 成为后续改写的上下文
- 改写阶段：模型在分析 token 的”引导”下生成新提示词，而非凭空想象
这利用了自回归生成的特性——已生成的推理 token 会影响后续输出质量。Yang et al. (2023) 的实验验证：排除逐步推理模板会导致生成质量显著下降。
进阶用法
跨模型适配
根据目标模型调整生成策略：
| 模型 | 策略 | 理由 |
|---|
| GPT-5.5 | outcome-first，减少过程约束 | 推理能力强，给目标即可 |
| Claude | 用 XML 标签结构化 | Claude 对 XML 标签的注意力强 |
| Gemini | 简洁指令，避免过长上下文 | 上下文窗口敏感 |
| o3（Reasoning） | 只给目标，信任自主推理 | 内置 CoT，过程约束反而干扰 |
优化器参数调优
PE2 的优化器概念在实践中的调参建议：
| 参数 | 建议值 | 说明 |
|---|
| 批次大小 | 2-4 个失败案例 | 过少不够诊断，过多引入噪声 |
| 步长 | 首次 10 词以内，后续可放大 | 小步长避免改偏方向 |
| 动量 | 第 2 轮起启用 | 参考第 1 轮的编辑方向 |
| 搜索预算 | 3-5 轮迭代 | 边际收益递减 |
变体：批量生成
一次提交多个需求，对每个分别生成提示词并附设计决策和原则检查。
变体：提示词审计
1
2
3
4
5
| # 输入
现有提示词：{{待审计的提示词}}
评估维度：{结构/密度/注意力/一致性}
请基于 11 项自验证清单审计此提示词，输出通过项和未通过项及修改建议。
|
局限性
- 无法替代领域知识：元提示词优化结构和表达，但不注入模型不知道的领域知识
- 生成的提示词需要实测：用 3-5 个测试输入验证，不满足 Stop rules 则用迭代模式修正
- 过度依赖可能导致同质化：创意任务应适当打破元提示词的约束
- LLM 的固有限制：模型可能忽略指令或产生幻觉理由（Yang et al., 2023, Table 5）
与 Skill 的关系
元提示词是 Skill 的 precursor——如果元提示词被频繁使用，可封装为 Skill：
1
2
3
4
| ---
name: prompt-generator
description: 根据用户需求生成高质量提示词。当用户要求写提示词、优化提示词或设计 prompt 时使用。
---
|
这呼应了前文《如何生成好的 Agent Skill》的核心观点：Skill 是提示词的工程化形态。元提示词是”一次性提示词”，Skill 是”可发现、可复用的元提示词”。
参考资料
