高级提示词工程师
概述
为大模型设计、测试和优化提示词。本技能涵盖系统化的提示词工程，包括少样本示例设计、思维链推理、系统提示词架构、结构化输出规范、参数调优、评估方法、A/B 测试和提示词版本管理。
开始时宣布：“我将使用高级提示词工程师技能来设计和优化提示词。”
阶段 1：需求
目标： 在编写任何提示词之前，明确任务目标、质量标准和约束条件。
操作
- 清晰定义任务目标
- 确定输入/输出格式要求
- 确定质量标准（准确性、语气、格式）
- 评估边缘情况和失败模式
- 选择模型和参数约束
停止 — 在进入阶段 2 之前，不要继续：
阶段 2：提示词设计
目标： 通过恰当的架构、示例和约束来起草提示词。
操作
- 起草系统提示词，包含角色、约束和格式
- 设计少样本示例（3-5 个有代表性的案例）
- 如果需要推理，添加思维链脚手架
- 指定输出结构（JSON、Markdown 等）
- 添加错误处理说明
提示词架构层
| 层级 | 目的 | 示例 |
|---|
| 1. 身份 | 模型是谁 | “你是一个情感分类器……” |
| 2. 上下文 | 模型了解什么/可访问什么 | “你可以访问产品评价……” |
| 3. 任务 | 要做什么 | “将每条评价分类为正面/负面/中性” |
| 4. 约束 | 不要做什么 | “输出中绝不包含个人身份信息” |
| 5. 格式 | 如何组织输出 | “以 JSON 格式回复：{classification, confidence}” |
| 6. 示例 | 演示 | 3-5 组有代表性的输入/输出示例 |
| 7. 元认知 | 如何处理不确定性 | “如果不确定，则分类为中性并说明原因” |
系统提示词模板
[Role] You are a [specific role] that [specific capability].
[Context] You have access to [tools/knowledge]. The user will provide [input type].
[Instructions]
1. First, [step 1]
2. Then, [step 2]
3. Finally, [step 3]
[Constraints]
- Always [requirement]
- Never [prohibition]
- If uncertain, [fallback behavior]
[Output Format]
Respond in the following format:
[format specification]
[Examples]
<example>
Input: [sample input]
Output: [sample output]
</example>
停止 — 在进入阶段 3 之前，不要继续：
阶段 3：评估与迭代
目标： 衡量提示词质量，并通过迭代达到目标。
操作
- 创建评估数据集（至少 50 个示例）
- 定义评分标准（自动化指标 + 人工指标）
- 运行基线评估
- 针对性改进提示词并迭代
- 对有潜力的变体进行 A/B 测试
- 为最终提示词制定版本并编写文档
停止 — 满足以下条件时，评估完成：
少样本示例设计
选择标准决策表
| 标准 | 说明 | 示例 |
|---|
| 具有代表性 | 涵盖最常见的输入类型 | 纳入典型邮件，而不只是边缘案例 |
| 多样 | 纳入边缘情况和边界案例 | 短 + 长，正面 + 负面 |
| 有序 | 按从简单到复杂排列 | 先放明显案例，最后放模糊案例 |
| 均衡 | 各类别的代表数量相等 | 不要放 4 个正面案例和 1 个负面案例 |
示例数量指南
| 任务复杂度 | 所需示例数 |
|---|
| 简单分类 | 2-3 |
| 中等难度生成 | 3-5 |
| 复杂推理 | 5-8 |
| 对格式敏感 | 3-5（重点关注格式一致性） |
示例格式
<example>
<input>
[Representative input]
</input>
<reasoning>
[Optional: show the thinking process]
</reasoning>
<output>
[Expected output in exact target format]
</output>
</example>
思维链模式
CoT 模式决策表
| 模式 | 适用场景 | 示例 |
|---|
| 标准 CoT | 多步推理 | "逐步思考：1. 确定…… 2. 分析……" |
| 结构化 CoT | 需要可解析的推理 | XML 标签：先写 <analysis>...</analysis>，再写 <answer>...</answer> |
| 自洽性 | 高风险决策 | 生成 3 个方案，选择最常见的方案 |
| 不使用 CoT | 简单的事实查询、格式转换 | 跳过推理开销 |
何时使用 CoT
| 任务类型 | 使用 CoT？ | 原因 |
|---|
| 数学推理 | 是 | 逐步推理可避免错误 |
| 多步逻辑 | 是 | 使推理过程透明 |
| 带理由的分类 | 是 | 提高准确性和可解释性 |
| 简单的事实查询 | 否 | 增加延迟，但不会提升准确性 |
| 直接格式转换 | 否 | 无需推理 |
| 非常简短的回答 | 否 | CoT 的开销大于收益 |
结构化输出
输出格式决策表
| 格式 | 适用场景 | 解析方式 |
|---|
| JSON | 由机器使用的输出 | JSON.parse() |
| Markdown | 人类可读的结构化文本 | 正则表达式或 Markdown 解析器 |
| XML 标签 | 需要清晰划分区段 | XML 解析器或正则表达式 |
| YAML | 类似配置的输出 | YAML 解析器 |
| 纯文本 | 简单、非结构化的回答 | 无需解析 |
JSON 输出示例
Respond with a JSON object matching this schema:
{
"classification": "positive" | "negative" | "neutral",
"confidence": number between 0 and 1,
"reasoning": "brief explanation",
"key_phrases": ["array", "of", "phrases"]
}
Do not include any text outside the JSON object.
Temperature 和 Top-P 调优
| 使用场景 | Temperature | Top-P | 原因 |
|---|
| 代码生成 | 0.0-0.2 | 0.9 | 确定性强、正确 |
| 分类 | 0.0 | 1.0 | 结果一致 |
| 创意写作 | 0.7-1.0 | 0.95 | 多样、有趣 |
| 摘要 | 0.2-0.4 | 0.9 | 忠实且流畅 |
| 头脑风暴 | 0.8-1.2 | 0.95 | 最大限度提高多样性 |
| 数据提取 | 0.0 | 0.9 | 精确、可靠 |
规则
- 对需要一致性和正确性的任务，将 Temperature 设为 0
- 对创意任务使用更高的 Temperature
- 通常无需调节 Top-P（保持在 0.9-1.0）
- 不要同时使用高 Temperature 和低 Top-P（两者相互矛盾）
评估指标
自动化指标
| 指标 | 衡量内容 | 适用场景 |
|---|
| 完全匹配 | 输出与预期相同 | 分类、提取 |
| F1 分数 | 精确率与召回率的平衡 | 多标签任务 |
| BLEU/ROUGE | N-gram 重叠度 | 摘要、翻译 |
| JSON 有效性 | 结构化输出是否可解析 | 结构化生成 |
| 正则表达式匹配 | 输出是否符合模式 | 格式合规性 |
人工评估维度
| 维度 | 量表 | 描述 |
|---|
| 准确性 | 1-5 | 事实是否正确 |
| 相关性 | 1-5 | 是否回答了实际问题 |
| 连贯性 | 1-5 | 逻辑流程和结构 |
| 完整性 | 1-5 | 是否涵盖所有必需方面 |
| 语气 | 1-5 | 是否符合期望的表达风格 |
| 简洁性 | 1-5 | 是否没有不必要的内容 |
评估数据集要求
- 至少包含 50 个示例，以确保统计显著性
- 按比例覆盖所有输入类别
- 包含边缘案例（占数据集的 10-20%）
- 金标准标签由至少 2 名评估者审核
- 与提示词一同进行版本控制
A/B 测试流程
- 定义假设："提示词 B 将使 [指标] 提升 [幅度]"
- 除提示词变更外，保持所有变量不变
- 使用同一评估集运行两个变体
- 通过置信区间计算指标差异
- 采用变更前，要求达到统计显著性（p < 0.05）
A/B 测试内容
| 变量 | 预期影响 |
|---|
| 指令措辞（祈使式与描述式） | 中等 |
| 少样本示例数量 | 中等 |
| 示例顺序 | 低到中等 |
| 是否使用 CoT | 对推理任务影响大 |
| 输出格式规范 | 对结构化输出影响大 |
| 约束条件的位置（开头或结尾） | 低 |
提示词版本控制
版本文件格式
id: classify-sentiment
version: 2.1
model: claude-sonnet-4-20250514
temperature: 0.0
created: 2025-03-01
author: team
changelog: "Added edge case examples for sarcasm detection"
metrics:
accuracy: 0.94
f1: 0.92
eval_dataset: sentiment-eval-v3
system_prompt: |
You are a sentiment classifier...
examples:
- input: "..."
output: "..."
版本管理规则
- 语义化版本：主版本.次版本（主版本 = 行为变更，次版本 = 优化）
- 每个版本都包含评估指标
- 链接到评估数据集版本
- 记录变更内容及原因
- 保留以前的版本，以便回滚
反模式 / 常见错误
| 反模式 | 错误原因 | 正确做法 |
|---|
| 指令含糊（“提供帮助”） | 输出不可靠且不一致 | 提供包含示例的具体指令 |
| 约束相互矛盾 | 模型无法同时满足两者 | 检查约束是否一致 |
| 示例与任务不匹配 | 会使模型困惑 | 示例必须反映实际用法 |
| 对简单任务过度设计 | 浪费令牌，降低速度 | 让提示词复杂度与任务复杂度相匹配 |
| 没有评估框架 | 只能凭猜测判断质量 | 在迭代前定义指标 |
| 针对单个示例进行优化 | 会过拟合单个案例 | 针对数据分布进行优化 |
| 假设可跨模型移植 | 不同模型需要不同的提示词 | 在目标模型上进行测试 |
| 跳过版本控制 | 无法回滚或比较 | 为每个提示词版本记录指标 |
集成点
| 技能 | 关系 |
|---|
llm-as-judge | LLM-as-judge 评估提示词输出质量 |
acceptance-testing | 提示词评估数据集可用作验收测试 |
testing-strategy | 提示词测试遵循评估方法 |
senior-data-scientist | 通过统计检验验证 A/B 测试结果 |
code-review | 像审查代码变更一样审查提示词变更 |
clean-code | 提示词可读性遵循整洁代码的命名原则 |
技能类型
灵活型 — 根据具体模型、任务和质量要求调整提示技巧。强烈建议采用评估和版本管理实践，但可根据项目规模调整。生产环境中的提示词务必进行版本管理。
