A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT

软件模式与提示模式的比较

本文提出，大型语言模型（LLM）输出的质量直接取决于用户提供提示（Prompt）的质量。提示是一种对LLM进行编程的形式，通过设定上下文、规则和期望的输出形式，可以定制化LLM的行为和输出。因此，本文引入了提示模式（Prompt Patterns）的概念，旨在系统化地记录与LLM交互时，为解决常见问题而设计的成功方法。

提示模式在知识传递上类似于软件模式（Software Patterns）。软件模式为特定上下文中反复出现的问题提供可复用的解决方案，而提示模式则专注于在与LLM交互和生成输出的上下文中解决常见问题。通过将这些知识以模式形式编纂，可以增强其在不同领域和上下文中的复用性和可移植性。

本文提出的提示模式遵循一种类似于经典软件模式的结构，但为适应LLM的上下文进行了调整，具体包含以下几个部分：

本文所有示例均在 ChatGPT+ 服务上进行了测试。

面向对话式LLM的提示模式目录

本章节介绍了本文整理的提示模式目录，这些模式已被成功应用于解决与对话式LLM交互及为软件开发任务生成输出时的常见问题。

提示模式目录总结

本文对已识别的提示模式进行了初步分类，该分类体系是理解和组织这些模式的关键。

表 I
提示模式分类
模式类别 提示模式
输入语义 (Input Semantics) 元语言创建 (Meta Language Creation)
输出定制 (Output Customization) 输出自动化 (Output Automater)
  人设 (Persona)
  可视化生成器 (Visualization Generator)
  配方 (Recipe)
  模板 (Template)
错误识别 (Error Identification) 事实核查清单 (Fact Check List)
  反思 (Reflection)
提示改进 (Prompt Improvement) 问题优化 (Question Refinement)
  替代方法 (Alternative Approaches)
  认知验证器 (Cognitive Verifier)
  拒绝破解器 (Refusal Breaker)
交互 (Interaction) 翻转交互 (Flipped Interaction)
  游戏 (Game Play)
  无限生成 (Infinite Generation)
上下文控制 (Context Control) 上下文管理器 (Context Manager)

分类体系解释：

元语言创建模式 (The Meta Language Creation Pattern)

基本上下文陈述
当我说 X 时，我的意思是 Y （或者我希望你做 Y）。 
该模式的核心是向LLM解释一个或多个符号、单词或语句的含义，使其在接下来的对话中采用用户提供的语义。 *   **示例**:
``$$
从现在开始，每当我用“→”分隔两个标识符时，我都在描述一个图。例如，“a → b”描述了一个包含节点“a”和“b”以及它们之间一条边的图。如果我用“-[w:2, z:3]→”分隔标识符，我正在为边添加属性，比如权重或标签。
$$`$$ *   **后果**: 这个模式非常强大，但也可能导致LLM产生混淆。定义的语言必须无歧义，否则会降低LLM的性能和准确性。例如，重新定义逗号的含义可能会引发意想不到的语义冲突。当一个符号在不同领域有不同含义时（如“→”在图论和逻辑学中），此模式可以帮助限定上下文，提高输出的准确性。最好在一个全新的会话中使用此模式，避免语义冲突。

输出自动化模式 (The Output Automater Pattern)

基本上下文陈述
每当你生成一个包含至少一个步骤且满足某些属性的输出时（或者，总是这样做）
请生成一个类型为 X 的可执行工件来自动化这些步骤。 
模式的第一部分定义了触发自动化的条件（例如，当输出包含超过一定数量的步骤时），第二部分则明确了自动化工件的类型（例如，“生成一个Python脚本”）。 *   **示例**:
$$`$$
从现在开始，每当你生成跨越多个文件的代码时，请生成一个Python脚本，运行该脚本可以自动创建指定的文件或修改现有文件以插入生成的代码。
$$`$$ *   **后果**: 用户必须明确定义自动化工件的类型，因为LLM通常不接受模糊的“自动化”请求，但可以接受“生成代码”的指令。此模式在提供完整上下文时效果最好，例如从头生成一个项目。用户必须有能力审查和理解生成的自动化脚本，因为LLM可能会产生错误，盲目执行脚本存在巨大风险。用户需要为执行脚本的后果负责。

翻转交互模式 (The Flipped Interaction Pattern)

基本上下文陈述
我希望你向我提问，以实现目标 X。
你应该持续提问，直到满足某个条件或实现某个目标（或者，永远提问）。
（可选）每次问一个问题，或两个问题，等等。 
提示应明确交互的最终目标、终止条件，并可选地规定提问的节奏（如每次提问的数量）。 *   **示例**:
$$`$$
从现在开始，我希望你向我提问，以便将一个Python应用部署到AWS。当你拥有足够的信息来部署该应用时，创建一个Python脚本来自动化部署过程。
$$`$$ *   **后果**: 提示的开放性（如上例）使其具有通用性，但也可能导致LLM提出一些本可以避免的额外问题。如果预先知道某些具体要求（例如，部署到AWS EC2），最好在初始提示中明确说明。在设计此类提示时，需要考虑用户的知识水平，并明确是希望最少化用户交互还是最大化用户参与。

人设模式 (The Persona Pattern)

基本上下文陈-述
扮演人设 X。
提供人设 X 会创建的那种输出。 
人设可以是一个职位、头衔、虚构人物或历史人物。该角色应能唤起一系列众所周知的属性。 *   **示例**:
*   **安全审查员**：
    $$`$$
    从现在开始，扮演一名安全审查员。密切关注我们所查看的任何代码的安全细节。提供安全审查员会给出的那种关于代码的输出。
    $$`$$
*   **被攻击的Linux终端**：
    $$`$$
    你将要假装是一个被攻击者入侵的计算机的Linux终端。当我输入一个命令时，你将输出Linux终端会产生的相应文本。
    $$`$$ *   **后果**: 人设模式非常有效，LLM能够将其“情境意识”带入角色中，生成符合该角色的、富有想象力的输出（例如，模拟被黑客攻击后的文件系统）。人设也可以是非人类实体（如数据库、动物）。但需注意，涉及在世人物或有害人物的人设可能会因LLM的内置规则而被忽略。

问题优化模式 (The Question Refinement Pattern)

基本上下文陈述
在范围 X 内，建议一个更好的问题版本来替代我的问题。
（可选）询问我是否愿意使用这个更好的版本。 
该模式要求LLM在特定范围内（例如，仅限于关于软件安全的问题）对用户的问题进行优化，并可选地征求用户同意以使用优化后的问题。 *   **示例**:
$$`$$
从现在开始，每当我询问关于软件工件安全性的问题时，请建议一个更好的问题版本来替代我的问题，该版本应包含与我正在使用的语言或框架相关的特定安全风险信息，并询问我是否愿意使用你的问题。
$$``
例如，如果用户问：“如何在我的Web应用中处理用户身份验证？”，LLM可以将其优化为：“在FastAPI Web应用中安全处理用户身份验证以减轻XSS、CSRF和会话劫持等常见安全风险的最佳实践是什么？” *   **后果**: 此模式可以弥合用户知识与LLM理解之间的差距。但风险在于，它可能过快地将问题收窄到特定领域，导致用户错失更宏观的信息。一个解决方案是在提示中加入约束，如“不要将我的问题局限于特定的编程语言或框架”。此外，优化后的问题本身也可能引入事实性错误，这可以通过结合 **事实核查清单 (Fact Check List)** 等模式来缓解。

替代方法模式 (The Alternative Approaches Pattern)