> For the complete documentation index, see [llms.txt](https://yeasy.gitbook.io/prompt_engineering_guide/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://yeasy.gitbook.io/prompt_engineering_guide/fu-lu/e_anti_patterns.md).

# 附录 E：提示词常见反模式与排错指南

在长期的提示词工程实践中，开发者们总结出了一些普遍存在的“错误做法”。我们称之为 **反模式**。使用反模式虽然也能让大模型输出结果，但往往会带来不稳定性、冗余或过高的成本。

本附录总结了最常见的 8 种提示词反模式，并给出了推荐的修正方案。

***

## E.1 冗余与过度限定

**反模式**：在提示词中堆砌大量毫无必要的背景故事、同义词重复、或冗长的礼貌用语。

```
[反模式示例]
你好，亲爱的人工智能助手。我今天遇到了一点小麻烦，希望你能帮我。请你务必、一定、千万要记住，扮演一个非常有礼貌、非常专业的程序员。你知道吗，这对我特别重要，因为我要把这段代码展示给老板看……请写一个 Python 函数反转字符串。
```

**后果**：消耗额外的 Token，分散模型的注意力，并且可能触发模型在回复结尾额外加入一大段不需要的寒暄环节。

**正确做法**：直接切入正题，保持信息高密度。

```
[修正示例]
你是一个高级 Python 工程师。请写一个时间复杂度为 O(n) 的字符串反转函数。不要输出问候语和解释。
```

***

## E.2 负向指令优先

**反模式**：花费大量篇幅告诉模型“不要做什么”，而不是“你该做什么”。

```
[反模式示例]
不要用第一人称，不要用长句子，不要带有感情色彩，绝对不要输出任何 markdown 格式的标题，不要写总结词。现在帮我写一份会议记录。
```

**后果**：模型（特别是较弱的模型）如果看到大量自己不该做的事情的实体描述，有时反而会受该词语触发（负面启动效应），输出被禁止的内容。

**正确做法**：将负向约束转化为正向的、具有操作性的指南。

```
[修正示例]
请用第三人称、平实的语气写一份段落式会议记录。输出纯文本（禁止任何格式符号）。
```

***

## E.3 单次调用的超载

**反模式**：试图用一个包含十几条任务指令的巨大 Prompt 来让模型一次性完成数据提取、翻译、情感分析、打分并输出 HTML 报告。

```
[反模式示例]
请阅读这 10 份研报。先将它们翻译成中文，然后每一份写个 200 字摘要。另外，评估它们的情感倾向并给出 1-5 分的评分。最后将这些汇总成一个带有柱状图数据的 HTML 网页。
```

**后果**：必然导致部分指令被忽视。

**正确做法**：使用提示词链或 Pipeline 分步处理。

***

## E.4 强制格式的硬换行与缩进敏感

**反模式**：强迫模型输出基于空格对齐的 ASCII 图表，或极难书写的特定非标格式。

```
[反模式示例]
请输出一个树状图，每层子节点必须缩进 4 个空格，且必须用 `|-- ` 连接。如果有多行，必须对齐。
```

**后果**：几乎 100% 会触发对齐错位。

**正确做法**：改用工业标准（如 JSON、YAML、Mermaid，或 Markdown List），依靠下游去解析并自行渲染视觉 UI。

***

## E.5 缺乏退路

**反模式**：没有为模型提供“不知道”或“数据异常”的处理选项。

```
[反模式示例]
提取这段文字中的人名并输出 JSON: {"person_name": "xxx"}
```

*(如果文字是一段风景描写呢？)*

**后果**：模型陷入幻觉，强行编造一个名字以满足 JSON 格式。

**正确做法**：设计显式的逃生通路。

```
[修正示例]
提取文字中的人名。如果未找到任何人名，返回: {"person_name": null, "reason": "未提及人物"}
```

***

## E.6 在系统提示词中附带用户请求

**反模式**：将应该放在 `user` 角色中的临时任务或动态数据硬编码进入 `system` 角色。

**后果**：System 角色被污染。当未来出现多轮对话时，底层上下文无法正确刷新，逻辑会陷入死循环。

**正确做法**：**分离数据与指令**。用 System 规定系统规则与输出格式，用 User 承载当次请求的内容数据。

***

## E.7 盲目依赖 Few-Shot

**反模式**：未经筛选，随便找几条历史数据作为 Few-Shot 塞进提示词中。

**后果**：如果历史数据中包含由于人工失误造成的拼写错误、逻辑不一，模型会立刻学到这些“坏习惯”，反而比 Zero-Shot 表现得更差。另外，例子如果缺乏多样性，会导致模型严重过拟合于例子的类别。

**正确做法**：只有在发现模型难以理解格式或风格要求时才引入 Few-Shot。仔细挑选最具代表性、最高质量的“金标准”示例。

***

## E.8 上下文污染与无差别检索

**反模式**：为模型提供与问题完全不相关，或者内容过于庞杂以至于淹没核心问题的参考资料，例如在使用 RAG（检索增强生成）时进行文档无脑拼接而缺乏过滤与重排策略。

**后果**：模型的注意力会被大量无关内容分散（容易触发 “Lost in the Middle” 遗忘现象），或被无关信息误导产生幻觉，强行建立不存在的逻辑关联。此外还会浪费大量 Token。

**正确做法**：精细化检索结果（使用重排策略过滤低相关段落）。同时增强提示词的防御性，例如明确声明：“如果给定的参考资料不足以回答问题，请直接回答'资料不全'，禁止尝试强行关联上下文。”

***

## 小结

避免这些反模式的核心在于一句话：**将模型视为一个极度聪明但记忆力只有几秒钟，且非常容易受暗示的新员工**。提供清晰、结构化、分步骤的操作手册，永远好过一纸天马行空的需求单。