摘要 — 记录提示词工程中的常见错误，帮助开发者避免在实际使用中反复踩坑。核心反模式包括：过度指令导致模型"指令疲劳"、模糊上下文导致模型猜测、缺少输出格式约束、角色设定空洞化。正确做法是优先级指令放前面、明确数据结构、明确输出格式、角色设定具体化。
提示词反模式
记录提示词工程中的常见错误，避免在实际使用中反复踩坑。
1. 过度指令（Instruction Overload）
反面典型
请务必认真对待这个问题，你要仔细理解用户的需求，
确保回答准确、全面、专业、详细、有深度、有逻辑，
不能有任何错误，不能遗漏任何重要信息，...
问题
指令堆砌导致模型"指令疲劳"，权重被稀释，关键指令反而被忽略。
正确做法
优先级的指令放前面，每条指令说明原因。
合并同类指令，删除相互矛盾的约束。
2. 模糊上下文（Vague Context）
反面典型
分析这个数据
问题
"这个数据"指什么？CSV？JSON？一段话？模型需要猜测。
正确做法
# 数据格式
传入的是一份 JSON 格式的服务器监控数据，字段包括：
- cpu_usage: 浮点数，0-100
- memory_usage: 浮点数，0-100
- timestamp: ISO 8601 时间字符串
# 任务
统计过去 24 小时内 CPU 使用率超过 80% 的记录数，
并计算平均内存使用率。
3. 缺少输出格式约束
反面典型
提取这段文本中的人名和公司名
问题
输出可能是一段话、可能是逗号分隔、可能是 JSON，格式不确定导致后续处理困难。
正确做法
以 JSON 格式返回，结构如下：
{
"persons": ["人名列表"],
"organizations": ["公司名列表"]
}
如果未找到，返回空数组。
4. 角色设定空洞化
反面典型
你是一个经验丰富的软件工程师
问题
角色设定过于抽象，模型无法从中提取具体的行为约束。
正确做法
你是一位后端架构师，专精于分布式系统设计。
你习惯用第一性原理分析问题，每次建议必须包含：
1. 方案名称
2. 适用场景
3. 潜在风险
4. 替代方案
回答时先说结论，再展开分析。
5. 假设正面情况（Assuming Positive Path）
反面典型
这个函数接收用户输入，返回处理结果
问题
只描述正常路径，边界情况（空输入、非法格式、超长输入）全部交给模型自由发挥。
正确做法
函数签名: processUserInput(input: string) -> string
输入约束:
- 非空字符串
- 最大长度 1000 字符
- 仅允许 ASCII 可打印字符
异常处理:
- 空输入: 返回 "INVALID_INPUT"
- 超长: 截断至 1000 字符并附加 " [TRUNCATED]"
- 非法字符: 返回 "INVALID_CHARACTER"
6. 一次做太多事（Multi-Task Confusion）
反面典型
分析这段用户评论，判断情感是正面还是负面，
提取关键词，生成摘要，判断是否需要人工介入，
最后以 JSON 格式返回所有结果
问题
多任务未分解，模型容易顾此失彼，且各任务的最优 Prompt 策略不同。
正确做法
分步调用，或使用明确的分隔符：
【任务 1: 情感分析】
...
【任务 2: 关键词提取】
...
【任务 3: 摘要生成】
...
【任务 4: 人工介入判断】
...
输出格式: { "sentiment": "...", "keywords": [...], "summary": "...", "needs_human": true/false }