# 附录 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。

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

***

## 小结

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://yeasy.gitbook.io/prompt_engineering_guide/fu-lu/e_anti_patterns.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.