prompt-lab

Prompt Lab

用结构化方法取代试错式提示词工程：定义目标、分析当前提示词、生成变体（指令清晰度、示例策略、输出格式规范）、设计评估标准、创建测试用例，并识别失败模式。

参考文件

文件	内容	何时加载
references/prompt-patterns.md	提示词结构目录：零样本、少样本、CoT、角色设定、结构化输出	始终
references/evaluation-metrics.md	质量指标（准确性、格式合规性、完整性）、评估标准设计	需要评估时
references/failure-modes.md	常见提示词失败分类、检测策略、缓解措施	请求失败分析时
references/output-constraints.md	限制大模型输出格式的技巧、JSON 模式、模式约束	需要格式控制时

前置条件

• 明确目标：提示词应实现什么？
• 目标模型（GPT-4、Claude、开源模型）——提示技巧因模型而异
• 当前提示词（用于改进时）或任务描述（用于创建时）

工作流

阶段 1：定义目标

1. 任务说明——大模型应生成什么？请具体说明：“将客户支持工单分为 5 类”，而不是“处理支持工单”。
2. 成功标准——如何判断输出正确？在编写任何提示词之前，先定义可衡量的标准。
3. 失败模式——糟糕的输出是什么样的？信息缺失？格式错误？内容幻觉？拒绝回答？

阶段 2：分析当前提示词

如果提供了现有提示词：

1. 结构评估——指令是否清晰？是否提供了示例？是否指定了输出格式？
2. 歧义检测——模型可能会在哪里误解指令？
3. 缺失组件——有哪些应该说明但尚未指定的内容？（输出格式、语气、长度限制、边缘情况处理）
4. 失败模式映射——哪些已知的失败模式（见 references/failure-modes.md）适用于此提示词？

阶段 3：生成变体

创建 2-4 个提示词变体，每个变体测试一种不同的假设：

变体类型	假设	适用场景
直接指令	清晰的指令已足够	简单任务、能力强的模型
少样本	示例能提高输出一致性	遵循模式的任务
思维链	推理能提高准确性	多步骤逻辑、数学、分析
角色/身份设定	角色设定能改善语气和专业能力	特定领域的任务
结构化输出	格式规范能避免错误	JSON、CSV、特定模板

对于每个变体：

• 说明假设（为什么这个变体可能有效）
• 指出风险（可能出现什么问题）
• 提供完整的提示词文本

阶段 4：设计评估

1. 评分标准 — 定义加权标准：

   标准	衡量内容	典型权重
   正确性	输出与预期答案相符	30-50%
   格式合规性	遵循指定结构	15-25%
   完整性	包含所有必需元素	15-25%
   简洁性	不包含多余内容	5-15%
   语气/风格	符合要求的表达风格	5-10%

2. 测试用例 — 至少 5 个用例，涵盖：

   • 常规场景（标准输入）
   • 边缘情况（不常见但有效的输入）
   • 对抗性情况（旨在造成混淆的输入）
   • 边界情况（最小/最大输入）

阶段 5：输出

以结构化格式呈现变体、评分标准和测试用例，便于执行。

输出格式

## Prompt Lab: {Task Name}

### Objective
{What the prompt should achieve — specific and measurable}

### Success Criteria
- [ ] {Criterion 1 — measurable}
- [ ] {Criterion 2 — measurable}

### Current Prompt Analysis
{If existing prompt provided}
- **Strengths:** {what works}
- **Weaknesses:** {what fails or is ambiguous}
- **Missing:** {what's not specified}

### Variants

#### Variant A: {Strategy Name}

{完整提示词文本}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

#### Variant B: {Strategy Name}

{完整提示词文本}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

#### Variant C: {Strategy Name}

{完整提示词文本}

**Hypothesis:** {Why this approach might work}
**Risk:** {What could go wrong}

### Evaluation Rubric

| Criterion | Weight | Scoring |
|-----------|--------|---------|
| {criterion} | {%} | {how to score: 0-3 scale or pass/fail} |

### Test Cases

| # | Input | Expected Output | Tests Criteria |
|---|-------|-----------------|---------------|
| 1 | {standard input} | {expected} | Correctness, Format |
| 2 | {edge case} | {expected} | Completeness |
| 3 | {adversarial} | {expected} | Robustness |

### Failure Modes to Monitor
- {Failure mode 1}: {detection method}
- {Failure mode 2}: {detection method}

### Recommended Next Steps
1. Run all variants against the test suite
2. Score using the rubric
3. Select the highest-scoring variant
4. Iterate on the winner with targeted improvements

校准规则

1. 每个变体只改变一个变量。 每个变体都应仅与基线有一处不同。 同时更改指令风格、示例和格式，会导致结果无法解读。
2. 先测试，再宣布成功。 一个提示词在 3 个示例上有效，不代表在第 4 个上也有效。得出某个变体有效的结论前，至少要测试 5 个不同的用例。
3. 失败模式比成功更有价值。 了解提示词为何失败，比确认它有效更能指导改进。
4. 针对特定模型优化。 针对 GPT-4 优化的提示词未必适用于 Claude 或 Llama。务必注明目标模型。
5. 最简单有效的提示词胜出。 如果零样本提示词的得分与少样本提示词相同，就使用零样本提示词。Token 越少，成本和延迟越低。

错误处理

问题	解决方案
目标不明确	请用户通过 2-3 个示例定义什么样的“输出才算好”。
提示词针对的是大模型不擅长的任务（数学、计数）	指出这一局限。建议采用工具增强方法或预处理/后处理。
待测试的变量过多	优先关注影响最大的变量。迭代优化优于组合式测试。
没有现有提示词可供分析	从最简单的提示词开始。第一个变体即为基线。
输出格式要求严格	使用结构化输出模式（JSON 模式、函数调用），而不是仅依靠提示词约束。

不适用情况

遇到以下情况时应提出异议：

• 任务不需要大模型（确定性规则、正则表达式、SQL）——使用合适的工具
• 用户想要执行提示词，而不是设计提示词——此技能用于设计和评估，不会运行提示词
• 提示词用于安全关键决策，且没有人工审核——大模型输出不应作为唯一依据