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

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

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


E.1 冗余与过度限定

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

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

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

正确做法:直接切入正题,保持信息高密度。

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

E.2 负向指令优先

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

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

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

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


E.3 单次调用的超载

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

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

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


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

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

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

正确做法:改用工业标准(如 JSON、YAML、Mermaid,或 Markdown List),依靠下游去解析并自行渲染视觉 UI。


E.5 缺乏退路

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

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

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

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


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。

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


小结

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

最后更新于