提示词设计方法

---
name: prompt-engineering
description: 当用户需要设计、调试或改进给大语言模型的提示词时使用。包含结构化框架、常见失效模式的诊断路径，以及从单条提示词升级为可复用工作流的判断标准。
---

# 提示词设计方法

## 一条好提示词的结构

按这个顺序组织，缺哪块补哪块：

1. **角色与场景**——模型以什么身份、在什么约束下工作
2. **任务描述**——要产出什么，一句话说清
3. **输入说明**——用户会提供什么，各字段含义
4. **过程要求**——需要分几步、每步做什么（仅在过程会影响结果时才写）
5. **输出格式**——结构、长度、语气，最好给一个简短示例
6. **边界条件**——信息不足时怎么办、什么情况该拒绝或反问

不是每条提示词都需要全部六块。简单任务写 2、5 两块就够，过度结构化会让模型变得机械。

## 诊断：输出不对时改哪里

| 症状 | 通常原因 | 改法 |
| --- | --- | --- |
| 输出太泛、像模板 | 缺少具体输入或场景约束 | 补第 3 块，要求用户提供具体信息；在提示词里明确"信息不足时先反问" |
| 格式每次都不一样 | 只描述了格式没给示例 | 补一个完整的输出示例，比十句描述有效 |
| 忽略了某条要求 | 要求埋在长段落中间 | 把关键要求单独成行，或放到最后（近因效应） |
| 过度冗长 | 没有长度约束，或示例本身就长 | 明确字数上限，并让示例本身足够短 |
| 该反问却硬答 | 没写边界条件 | 补第 6 块："若缺少 X，先询问再继续" |
| 该直接答却先反问 | 边界条件写得过宽 | 收窄为"仅当 X 完全缺失时才询问" |

## 关键取舍

**具体优于详尽。** 增加约束会提升可控性但降低适应性。给一条提示词加到二十条规则，通常不如给三条精准的规则加一个好示例。

**示例比描述有效，但会锚定风格。** 给一个示例，模型会模仿它的结构和语气。想要多样性就给两三个明显不同的示例，或者不给示例只描述结构。

**不要写"不要做什么"的长清单。** 负面指令的效果远弱于正面指令。把"不要用专业术语"改成"用初中生能懂的说法解释"。

## 什么时候该升级成 Skill

单条提示词的天花板是"一次性任务"。出现下面任一情况，就该固化成 Skill（一份 SKILL.md，agent 按需加载）而不是继续堆长提示词：

- 同一套流程你已经手动粘贴超过三次
- 提示词长到需要滚动才能看完（通常 800 字以上）
- 流程里有分支判断（"如果是 A 情况就…否则…"）
- 需要附带参考资料（术语表、配色表、检查清单）
- 需要版本管理（改了之后想比较效果，或需要回滚）

Skill 的优势在于 description 常驻上下文而正文按需加载——上下文占用小，但触发时能提供完整流程。

## 迭代方法

一次只改一个变量，否则无法归因。建立 5~10 个固定测试输入，每次改动后跑同一批，对比结果。凭一两次感觉判断"变好了"通常是错的。