论文翻译 | A Prompt Pattern Catalog to Enhance Prompt Engineering with ChatGPT （上）
摘要
提示工程是一种越来越重要的技能集，需要与大型语言模型（LLMs）如ChatGPT进行有效对话。提示是对LLM的指令，用于执行规则、自动化流程，并确保生成输出的特定质量（和数量）。提示也是一种编程形式，可以自定义与LLM的输出和交互。
本文描述了一套以模式形式呈现的提示工程技巧目录，这些技巧已被应用于解决与LLMs对话时的常见问题。提示模式是一种知识转移方法，类似于软件模式，因为它们为特定上下文中的常见问题提供可重用的解决方案，即在处理LLMs时的输出生成和交互。
本文在将LLMs应用于自动化软件开发任务的研究中对提示工程做出了以下贡献。首先，它提供了一个框架，用于记录构建提示的模式以解决一系列问题，以便它们可以被适应到不同的领域。其次，它呈现了一个已成功应用于改善LLM对话输出的模式目录。第三，它解释了提示如何由多个模式构建，并展示了与其他提示模式结合时能获益的提示模式。
1 引言
对话式大型语言模型（LLMs）[1]，如ChatGPT [2]，在多个领域引起了极大的兴趣，任务范围从医学执照考试的答题[3]到生成代码片段。本文重点在于提升LLMs在几个领域中的应用，例如帮助开发人员有效地使用不熟悉的API进行编码，或者允许学生获取新的编码技能和技术。
LLMs在人类和AI工具作为可信赖的合作伙伴共同工作的领域特别有前景，以更快、更可靠地发展依赖软件的系统[4]。例如，LLMs正在直接集成到软件工具中，如Github的Co-Pilot [5]-[7]，并包含在集成开发环境（IDEs）中，如IntelliJ [8]和Visual Studio Code，从而使软件团队能够直接从他们首选的IDE中访问这些工具。
提示[9]是一组提供给LLM的指令，通过自定义和/或增强或细化其功能来编程LLM。提示可以通过提供特定的规则和指南来影响与LLM的后续互动以及从LLM生成的输出，这些规则和指南是为LLM对话设置的一组初始规则。特别是，提示为对话设置上下文，并告诉LLM哪些信息是重要的，以及期望的输出形式和内容应该是什么。
例如，一个提示可以指定LLM只能生成遵循特定编码风格或编程范式的代码。同样，它可以指定LLM应在生成的文档中标记某些关键词或短语，并提供与这些关键词相关的附加信息。通过引入这些指南，提示促进了更结构化和微妙的输出，以帮助LLMs上下文中的大量软件工程任务。
提示工程是通过提示来编程LLMs的手段。为了展示提示工程的力量，我们提供了以下提示：
提示：“从现在起，我希望你问我问题，以便将Python应用程序部署到AWS。当你拥有足够的信息来部署应用程序时，创建一个Python脚本来自动化部署。”
这个示例提示使得ChatGPT开始询问用户关于他们的软件应用程序的问题。ChatGPT将驱动提问过程，直到它拥有足够的信息来生成一个自动化部署的Python脚本。这个示例展示了提示的编程潜力，超越了传统的“生成一个执行X的方法”风格的提示或“回答这个测验问题”。
此外，提示可以被工程设计来实现远超简单指示输出类型或过滤提供给模型的信息的功能。有了正确的提示，可以创建全新的互动范式，例如让LLM生成并与软件工程概念或工具相关的测验，甚至模拟Linux终端窗口。此外，提示具有自我适应的潜力，建议其他提示以收集额外信息或生成相关工件。
这些提示的高级功能突出了工程设计它们以提供超越简单文本或代码生成价值的重要性。
提示模式对于有效的提示工程至关重要。本文的一个关键贡献是引入提示模式，以记录在处理对话式LLMs时系统地工程不同输出和互动目标的成功方法。我们主要关注工程领域独立的提示模式，并引入了一个基本提示模式目录，以解决从可视化生产和代码工件制作到帮助校对输出的自动化输出步骤的问题。
本文的其余部分组织如下：第二节介绍提示模式，并将这些模式与众所周知的软件模式[10]进行比较；第三节描述了16个提示模式，这些模式已应用于解决对话式LLM互动和输出生成领域中的常见问题，以自动化软件开发任务；第四节讨论相关工作；第五节提出结论和经验教训。
2 比较软件模式和提示模式
对话式LLM生成的输出质量与用户提供提示的质量直接相关。如第一节所述，给予对话式LLM的提示可以用来编程用户与LLM之间的互动，以更好地解决各种问题。本文的一个贡献是提供了一个框架，用于记录结构化提示以解决一系列软件任务的模式，这些模式可以适应不同的领域。
这个框架很有用，因为它专注于编码可以应用于帮助用户在各种上下文中更好地与对话式LLM互动的模式，而不仅仅是讨论有趣的例子或特定领域的提示。以模式形式编码这些知识增强了重用性和可转移性，可以应用于其他上下文和领域，用户在这些领域面临类似但并不完全相同的问题。
知识转移的话题在软件模式文献[10]、[11]中已经得到了广泛的研究，涉及多个层面，例如设计、架构和分析。本文应用了一种熟悉的模式形式的变体作为我们提示工程方法的基础。由于提示是一种编程形式，以模式形式记录它们是很自然的。
A. 软件模式概述
软件模式为特定上下文中的反复出现的问题提供可重用的解决方案[10]。记录软件模式可以简洁地传达（并概括）特定问题的解决方法，以确定在成功解决方案中应解决和/或考虑的重要力量和/或要求。
模式形式还包括如何实现模式的指导，以及在实现模式时应考虑的权衡和注意事项。此外，通常会提供模式的应用示例，以进一步展示模式在实际中的实用性。软件模式通常以风格化的形式记录，以方便其使用和理解，例如：
- 名称和分类。每个模式都有一个标识模式的名称，应一致使用。分类将模式分为广泛类别，如创建型、结构型或行为型。
- 意图简洁地传达模式旨在实现的目的。
- 动机记录模式旨在解决的问题及其重要性。
- 结构和参与者。结构描述了不同的模式参与者（如类和对象）以及它们如何协作形成通用解决方案。
- 示例代码将模式具体映射到一些底层编程语言，并帮助开发人员更深入地了解如何有效地应用该模式。
- 后果总结了在实际应用模式时的利弊。
B. 提示模式概述
提示模式与软件模式相似，也为特定问题提供可重用的解决方案。然而，它们更具体地关注于大型语言模型（如ChatGPT）输出生成的上下文。正如软件模式为解决常见的软件开发挑战提供了一种编码化的方法，提示模式为定制LLM的输出和交互提供了编码化的方法。
通过记录和利用提示模式来自动化软件开发任务，个人用户和团队可以强制生成输出上的约束，确保包含相关信息，并改变与LLM的互动格式，以更好地解决问题。提示模式可以被视为广义软件模式的一个推论，只是适应了LLM输出生成的更具体上下文。
提示模式遵循经典软件模式的类似格式，略有修改以匹配LLM输出生成的上下文。1本文中使用的提示模式形式的每个相应部分总结如下：
- 名称和分类。提示模式名称唯一标识模式，理想情况下表明正在解决的问题。对于分类，我们开发了一系列初始模式类型类别，总结在表I中，包括输出定制、错误识别、提示改进、互动和上下文控制。
- 意图和上下文描述提示模式解决的问题及其实现的目标。问题应理想地独立于任何领域，尽管也可以记录特定领域的模式，并适当讨论模式适用的上下文。
- 动机提供了问题的依据，并解释了解决它的重要性。动机在用户与对话式LLM互动的上下文中进行解释，并说明它如何能在一种或多种情况下改进用户非正式地向LLM提示。记录了预期改进的具体情况。
- 结构和关键思想。结构描述了提示模式为LLM提供的基本上下文信息，作为一系列关键思想。这些想法类似于软件模式中的“参与者”。上下文信息可以通过不同的措辞传达（就像软件模式在代码中的实现可以有所变化），但应具有形成模式核心元素的基本信息片段。
- 示例实现展示了提示模式在实践中是如何措辞的。
- 后果总结了应用模式的利弊，并可能提供如何将提示适应不同上下文的指导。
C. 定义提示模式结构和思想的评估方法
在软件模式中，结构和参与者通常以UML图的形式定义，如结构图和/或交互图。这些UML图解释了模式参与者是什么以及他们如何互动以解决问题。在提示模式中，需要类似的东西，尽管UML可能不是合适的结构化文档方法，因为它旨在描述软件结构，而不是在提示中传达的思想。
可以使用几种可能的方法，从图表到定义提示语言的语法。尽管语法由于其形式化特性而看起来很吸引人，但它们也带来了以下挑战：
- 提示的目标是以清晰简洁的方式向对话LLM用户传达知识，这些用户可能是也可能是计算机科学家或程序员。作为社区，我们应努力创建一种易于接近的格式，清晰地传达知识给多样化的目标受众。
- 一个提示可以用许多不同的方式表达。然而，定义一个准确且完整表达提示中各个组成部分的所有细微差别的语法是困难的。
- 提示从根本上向对话式LLM传达思想，而不仅仅是输入的令牌生成。特别是，构建到提示模式中的思想可以通过多种方式传达，其表达应高于代表思想的底层令牌。
- 可以编程LLM引入新的语义，为陈述和词汇创造新的沟通想法的方式。相比之下，语法可能不容易表示可以通过设计者未曾意识到的完全新的符号或语言表达的 ideas。
D. 前进之路：基本上下文陈述
因此，一个开放的 research 问题是什么方法比形式语法更有效地描述提示模式的结构和思想。我们提出了基本上下文陈述的概念，这些陈述是向LLM提示中传达重要思想的书面描述。
一个想法可以根据用户的需求和经验以任意方式重写和表达。然而，要传达的关键想法以一系列简单但基本的状态呈现给用户。
采用和应用基本上下文陈述方法的一个好处是它对用户有意地直观。特别是，我们期望用户将理解如何以对其领域而言情境适当的方式表达和调整这些陈述。此外，由于捕获了提示的底层思想，这些相同的想法可以通过用户以替代符号或措辞表达，这些符号或措辞已通过模式引入到LLM中，例如第三节B中介绍的元语言创建模式。
我们的最终目标是通过提供一个设计提示的框架来增强提示工程，这些提示可以像软件模式在不同编程语言和平台中实现一样被重用和/或适应其他LLM。然而，为了本文的目的，所有的提示都是使用ChatGPT+服务在ChatGPT [12]上测试的。由于ChatGPT的广泛可用性和流行性，我们使用它作为本文中所有示例的LLM。这些示例是通过探索互联网上社区发布的提示语料库和我们使用ChatGPT自动化软件开发任务的独立提示创建相结合的方式来记录的。
3 会话式LLMS的提示模式目录
本节介绍了我们的提示模式目录，这些模式已被应用于解决对话式LLM交互和输出生成领域中常见的问题，以自动化软件任务。每个提示模式都附有具体的实施样本和示例，以及使用和未使用提示的情况。
A. 提示模式目录概要
提示模式的分类是记录模式时需要考虑的一个重要问题。表1概述了到目前为止我们在使用ChatGPT时确定的提示模式目录的初始分类。
如该表所示，在我们的分类框架中有五类提示模式：输入语义、输出定制、错误识别、提示改进和交互，每一类都总结如下。
输入语义类别处理LLM如何理解输入以及如何将输入转换为可用于生成输出的内容。此类别包括元语言创建模式，其重点是创建LLM可以理解的自定义语言。当默认输入语言不适合表达用户想要传达给LLM的想法时，此模式非常有用。
Output Customization类别侧重于约束或裁剪LLM生成的输出的类型、格式、结构或其他属性。此类别中的提示模式包括Output Automater、Persona、Visualization Generator、Recipe和Template模式。Output Automater模式允许用户创建脚本，这些脚本可以自动执行LLM输出建议用户执行的任何任务。角色模式在生成输出时为LLM提供了一个角色或角色。可视化生成器模式允许用户通过生成文本输出来生成可视化，这些文本输出可以提供给其他工具，例如其他基于ai的图像生成器，如DALL-E[13]。Recipe模式允许用户获得一系列步骤或操作，以实现所述的最终结果，其中可能包含部分已知的信息或约束。Template模式允许用户为输出指定模板，LLM用内容填充该模板。
Error Identification类别侧重于识别和解决LLM生成的输出中的错误。此类别包括事实检查列表和反射模式。
事实检查列表模式要求LLM生成输出所依赖的事实列表，这些事实应该进行事实检查。
反射模式要求LLM对其输出进行内省并识别任何错误。
即时改进类别侧重于提高投入和产出的质量。这个类别包括问题细化、替代方法、认知验证器和拒绝打破模式。问题细化模式确保LLM总是建议用户问题的更好版本。替代方法模式要求LLM建议完成用户指定任务的替代方法。认知验证者模式指示LLM在组合子问题的答案并生成整体问题的答案之前，自动建议用户回答一系列子问题。
拒绝中断模式要求LLM在拒绝生成答案时自动改写用户的问题。
交互类别侧重于用户和LLM之间的交互。这一类别包括翻转互动、游戏玩法和无限生成模式。翻转交互模式要求LLM提出问题，而不是生成输出。Game Play模式要求LLM以游戏的形式生成输出。无限生成模式要求LLM无限地生成输出，而无需用户每次都重新输入生成器提示符。
最后，上下文控制类别侧重于控制LLM运行的上下文信息。这个类别包括上下文管理器模式，它允许用户为LLM的输出指定上下文。本节的其余部分将使用第II-B节中讨论的模式形式描述这些提示模式。
B.元语言创建模式
1)意图和上下文：在与LLM对话期间，用户希望通过另一种语言创建提示，例如图形的文本速记符号，状态机的状态描述和状态转换，提示自动化的一组命令等。此模式的目的是向LLM解释这种替代语言的语义，以便用户可以使用这种新语言及其语义编写将来的提示。
2)动机：在提示中传达的许多问题，结构或其他想法可能用英语以外的语言（或任何用于与大语言模型互动的传统人类语言）更简洁，明确或清晰地表达出来。然而，要基于替代语言生成输出，LLM需要理解该语言的语义。
3)结构和核心思想：基本的语境陈述；
这种模式的关键结构涉及向LLM解释一个或多个符号、单词或语句的含义，使其在随后的对话中使用提供的语义。这种描述可以采取简单的翻译形式，例如“X”意味着“Y”。描述也可以采取更复杂的形式，定义一系列命令及其语义，例如“当我说X时，我想让你做...”。在这种情况下，“X”从此与“采取行动”的语义绑定。
4) 示例实施：成功使用元语言创建模式的关键是开发一个明确无误的符号或速记，如下所示：
“从现在起，每当我输入由“→”分隔的两个标识符时，我是在描述一个图。例如，“a → b”描述的是一个具有节点“a”和“b”以及它们之间边界的图。如果我用“-[w:2, z:3]→”分隔标识符，我是在添加边的属性，比如权重或标签。”
这个元语言创建模式的示例通过定义表示节点和边的约定，建立了一个描述图的标准化符号。每当作者输入由“→”符号分隔的两个标识符时，这表明正在描述一个图。例如，如果作者输入“a → b”，这表明正在定义一个具有节点“a”和“b”的图，并且它们之间有一条边。这个约定提供了一种清晰简洁的方式来以书面形式交流图的结构。此外，提示还指定了可以使用语法“-[w:2, z:3]→”提供关于边的额外信息，如权重或标签。这种表示法允许指定除图的基本结构之外的附加属性。指定的属性与两个节点之间的边相关联，并为解释图提供重要的上下文。
这种描述图的标准化符号可以更容易地交流图的结构和属性，这些结构或属性如果用一系列句子来描述可能不容易或非常冗长。
5) 后果：尽管这种模式为用户与LLM的互动提供了强大的定制手段，但它可能在LLM内部造成混淆。定义语言的语义非常重要，同时确保语言本身不引入任何降低LLM性能或准确性的歧义也同样重要。例如，提示“每当我用逗号分隔两件事时，这意味着第一件事在第二件事之前”可能会造成重大的歧义潜力，并可能在提示中使用逗号标点时产生意外的语义。
为了展示潜在的混淆，ChatGPT将警告用户，并可能无法将符号或术语映射到新含义。例如，如果给ChatGPT以下提示
“每当我说“a”时，我指的是玛丽·安托瓦内特。”
它将回应说这个提示造成了太多混淆，因为“a”是一个不定冠词，非常常用，如下所示：
“使用“a”来指代玛丽·安托瓦内特可能会造成混淆，因为“a”是一个不定冠词，通常用来指代之前未提及的名词。使用她的名字“玛丽·安托瓦内特”或代词如“她”或“她的”来指代她可能会更清楚。此外，使用上下文来确定你在对话中指的是谁也可以帮助避免混淆。”
通常，LLM在处理其训练数据时会表现更好。因此，当现有符号可用——但可能不是主要含义时——元语言创建模式可以提供上下文来限定符号的含义，以提高输出的准确性和实用性。例如，符号“→”在图和命题逻辑中传达的信息略有不同。因此，声明“p → q, q → p”可能是有意义的，但只有在LLM通过元语言创建提示得到适当上下文时才是如此。
尽管元语言创建是一种强大的模式，但它必须谨慎使用，特别是在描述可能难以精确或简洁描述的概念时。这类提示最好在全新的对话会话中使用。在每次对话会话中使用单一元语言可能是最佳实践，因为这样可以避免随着时间的推移对话中可能出现冲突或意外的语义。
C.输出自动模式
1)意图和上下文：此模式的意图是让LLM生成一个脚本或其他自动化工件，可以自动执行它建议作为其输出的一部分采取的任何步骤。目标是减少实现任何LLM输出建议所需的手工工作。
2)动机：LLM的输出通常是用户需要遵循的一系列步骤。例如，当要求LLM生成Python配置脚本时，它可能会建议修改一些文件，并将更改应用于每个文件。但是，让用户不断执行LLM输出指示的手动步骤是乏味且容易出错的。
3)结构和核心思想：基本的语境陈述；
这种模式的第一部分确定了应该生成自动化的情况。一个简单的方法是声明输出包括至少两个步骤，并且应该产生一个自动化工件。范围由用户决定，但有助于防止在运行输出自动化脚本所需努力超过执行输出中产生的原始步骤的情况下产生输出自动化脚本。范围可以限制为需要超过特定步骤数量的输出。
这种模式的下一部分提供了一个具体的声明，说明LLM应该输出哪种类型的输出以执行自动化。例如，“生成一个Python脚本”让LLM有一个具体的概念，将一般步骤转换为Python中的等效步骤。自动化工件应该是具体的，必须是LLM与“自动化一系列步骤”的行动相关联的东西。
4) 示例实施：下面展示了将这种提示模式应用于ChatGPT LLM生成的代码片段的示例：“从现在起，每当你生成跨越多个文件的代码时，生成一个可以运行的Python脚本，自动创建指定的文件或对现有文件进行更改以插入生成的代码。”这种模式在软件工程中特别有效，因为软件工程师使用LLMs的一个常见任务是将输出复制/粘贴到多个文件中。一些工具，如Copilot，可以直接将有限的代码片段插入编码者正在处理的部分代码中，但工具，如ChatGPT，不提供这些功能。这个自动化技巧也有效于创建在终端上运行命令的脚本，自动化云操作，或者在文件系统上重新组织文件。
这种模式是对任何可以计算机控制的系统的强大补充。LLM可以提供一组应该在计算机控制系统上采取的步骤，然后输出可以转换为脚本，允许控制系统的计算机自动执行这些步骤。这是允许LLMs，如ChatGPT，将质量整合到新的计算系统中并控制它们的直接途径，这些新系统有一个已知的脚本接口。
5) 后果：使用这种模式的一个重要考虑因素是自动化工件必须被具体定义。如果没有具体的意义来说明如何“自动化”步骤，LLM通常会声明它“不能自动化事物”，因为那超出了它的能力范围。然而，LLMs通常接受产生代码的请求，因此目标是指导LLM生成可以执行的文本/代码，以自动化某件事。这种细微的意义区分对于帮助LLM消除提示含义的歧义是很重要的。
输出自动化器模式的一个警告是，LLM需要足够的对话上下文来生成在目标上下文中功能性的自动化工件，例如Mac和Windows计算机上的项目文件系统。
当对话中包含了自动化的全部所需上下文时，这种模式效果最佳，例如，当使用对话从头开始生成软件应用程序，并且所有在本地文件系统上的操作都是使用一系列生成的自动化工件而不是LLM未知的>manual动作来执行时。或者，自包含的步骤序列也效果很好，例如“如何在 我的Mac计算机上找到开放的端口列表”。
在某些情况下，LLM可能会产生一个包含多个步骤的长输出，并且不包括自动化工件。这种省略可能出于各种原因，包括超出LLM支持的输出长度限制。这种情况下的一种简单解决方法是，通过后续提示提醒LLM，例如“但你没有自动化它”，这提供了自动化工件被省略并且应该生成的上下文。
在LLMs的发展过程中，输出自动化器模式最好由能够阅读和理解生成的自动化工件的用户使用。LLMs在输出中可能会产生不准确之处，因此盲目接受并执行自动化工件带有重大风险。
尽管这种模式可能减轻用户执行某些手动步骤的负担，但它并没有减轻他们使用输出采取行动的责任。
因此，当用户执行自动化脚本时，他们承担了结果的责任。
D.翻转互动模式
1)意图和背景：您希望LLM通过提问来获得执行某些任务所需的信息。因此，您希望LLM不是用户驱动对话，而是将对话集中于实现特定目标。例如，您可能希望LLM给您一个快速测试或自动提问，直到它有足够的信息为您的应用程序生成一个部署脚本到特定的云环境。
2)动机：比起让用户驱动对话，LLM通常拥有可以用来更准确地从用户那里获取信息的知识。翻转交互模式的目标是翻转交互流，以便LLM向用户提问以实现某些期望的目标。LLM通常可以更好地选择交互的格式、数量和内容，以确保更快、更准确地达到目标，并且/或者使用用户可能（最初）不具备的知识。
3)结构和核心思想：基本的语境陈述；
翻转交互的提示应该始终指定交互的目标。第一个想法（即，您希望LLM提出问题以实现目标）将此目标传达给LLM。同样重要的是，这些问题应该集中在一个特定的主题或结果上。通过提供目标，LLM可以理解它试图通过交互完成什么，并相应地调整其问题。由于LLM只会提出它认为与实现指定目标相关的问题，因此这种“反向控制”使交互更加集中和有效。
第二个想法提供了交互应该发生多长时间的上下文。翻转的互动可以通过“停止提问”这样的回应来终止。然而，将交互作用限定在一个合理的长度范围内，或者只限定在达到目标所需的范围内，通常是更好的。这个目标可以是令人惊讶的开放式的，LLM将继续通过提出问题来实现这个目标，就像“直到你有足够的信息来生成一个Python脚本”的例子一样。
默认情况下，LLM可能会在每次迭代中生成多个问题。第三个想法是完全可选的，但可以通过限制（或扩展）LLM每个周期生成的问题数量来提高可用性。如果没有指定提问的精确数量/格式，那么提问将是半随机的，可能会导致一次提问一个或十次提问。因此，可以对提示进行定制，以包括一次询问的问题数量、问题的顺序以及任何其他格式化/排序考虑事项，以促进用户交互。
4)示例实现：翻转交互的示例提示如下：“从现在开始，我希望您向我询问有关将Python应用程序部署到AWS的问题。当您有足够的信息来部署应用程序时，创建一个Python脚本来自动部署。”一般来说，关于约束条件和要收集的信息的提示越具体，结果就越好。
例如，上面的示例提示符可以提供一个可能的AWS服务（如Lambda、EC2等）菜单，用于部署应用程序。在其他情况下，可能允许LLM对用户没有明确做出决定的事情自行做出适当的选择。
此提示的一个限制是，一旦提供了有关任务的其他上下文信息，可能需要对精确的措辞进行实验，以使LLM以最适合任务的适当数量和流程提出问题，例如一次问多个问题，而不是一次问一个问题。
5)后果：在设计提示时要考虑的一个问题是，在终止之前，要向LLM规定多少信息收集。在上面的例子中，翻转的交互是开放式的，并且在最终生成的工件中变化很大。这种开放性使提示符具有通用性和可重用性，但可能会提出额外的问题，如果提供了更多上下文，则可以跳过这些问题。
如果提前知道了具体的需求，最好将其注入到提示符中，而不是希望LLM获得所需的信息。否则，LLM将非确定性地决定是提示用户输入信息，还是对适当的值进行有根据的猜测。
例如，用户可以声明他们希望将应用程序部署到Amazon AWS EC2，而不是简单地声明“云”，并需要多个交互来缩小部署目标。初始信息越精确，LLM就越能更好地利用用户可能愿意回答的有限问题来获取信息，从而提高其输出。
在开发翻转交互提示时，重要的是要考虑用户的知识水平、参与度和控制能力。如果目标是通过尽可能少的用户交互（最小化控制）来完成目标，那么应该明确地说明这一点。相反，如果目标是确保用户了解所有关键决策并确认它们（最大化用户粘性），那么也应该明确说明。同样，如果期望用户拥有最少的知识，并且应该针对他们的专业水平提出问题，则应该将这些信息设计到提示中。
E.人物角色模式
1)意图和背景：在许多情况下，用户希望LLM输出总是采取特定的观点或视角。例如，如果LLM是安全专家，那么进行代码审查可能是有用的。此模式的目的是为LLM提供一个“角色”，帮助它选择要生成的输出类型和要关注的细节。
2)动机：用户可能不知道什么类型的输出或细节对LLM来说是重要的，以便专注于完成给定的任务。然而，他们可能知道他们通常会向他们寻求帮助的角色或类型。角色模式允许用户在不知道所需输出的确切细节的情况下表达他们需要的帮助。
3)结构和核心思想：基本的语境陈述；
第一个陈述传达了LLM需要充当特定角色并提供该角色所提供的输出的想法。这个角色可以通过多种方式表达，包括工作描述、头衔、虚构人物、历史人物等。角色应该引出一组与知名职位、人物类型等相关的属性。第二个想法——提供角色X将创建的输出——提供定制的机会。例如，老师可能会提供大量不同的输出类型，从作业到阅读清单再到讲座。如果已知输出类型的更具体范围，则用户可以在此语句中提供它。
4)示例实现：代码审查的示例实现如下所示：
“从现在开始，担任安全审查人员。密切关注我们所查看的任何代码的安全细节。提供安全审查人员对代码的输出。”在这个例子中，LLM被指示提供“安全审查者”会提供的输出。提示符进一步设置了将对代码求值的阶段。最后，用户通过将角色进一步限定为有关代码的输出来细化角色。
人物角色还可以表示无生命或非人类实体，例如Linux终端、数据库或动物的视角。当使用此模式来表示这些实体时，还可以指定您希望如何将输入传递给实体，例如“假设我的输入是主人对狗说的话，而你的输出是狗发出的声音”。下面显示了一个使用“假装是”措辞的非人类实体的示例提示：“您将假装是一台被攻击者入侵的计算机的Linux终端。当我输入命令时，您将输出Linux终端将生成的相应文本。”这个提示符被设计用来模拟一台被攻击者入侵并通过Linux终端进行控制的计算机。提示符指定用户将在终端中输入命令，作为响应，模拟终端将输出由真实Linux终端产生的相应文本。此提示在角色中更具规定性，并要求LLM不仅是Linux终端，而且进一步充当已被攻击者破坏的计算机。
角色导致ChatGPT生成命令的输出，这些命令的文件和内容表明计算机被黑客入侵了。该示例说明了语言模型如何将其态势感知带到角色中，在这种情况下，在其生成的输出中创建网络攻击的证据。这种类型的角色可以非常有效地与游戏玩法模式相结合，在这种模式中，你希望向用户隐藏输出特征的确切细节（例如，不要通过在提示中明确描述网络攻击所做的事情来泄露它）。
5)结果：采用非人类角色的一个有趣方面是，法学硕士可能会对环境做出有趣的假设或“幻觉”。Internet上广为流传的一个示例要求ChatGPT充当Linux终端，并生成用户在终端中输入相同文本时所得到的预期输出。像ls -l这样的命令将为一个假想的UNIX文件系统生成一个文件清单，其中包含可以在其上运行cat file1.txt的文件。
在其他示例中，LLM可能提示用户输入更多上下文，例如当ChatGPT被要求充当MySQL数据库时，并提示用户输入用户假装要查询的表的结构。然后，ChatGPT可以生成合成行，例如为“people”表生成假想行，其中的列分别为“name”和“job”。
F.问题细化模式
1)意图和背景：这种模式使法学硕士参与到快速的工程过程中。此模式的目的是确保会话式LLM总是建议用户可以问的更好或更精细的问题，而不是他们最初的问题。使用这种模式，LLM可以帮助用户找到要问的正确问题，从而得到准确的答案。此外，与用户使用试错提示相比，LLM可以帮助用户在与用户交互较少的情况下找到信息或实现目标。
2)动机：如果用户提出问题，他们可能不是该领域的专家，可能不知道表达问题的最佳方式，或者不知道其他有助于表达问题的信息。法学硕士通常会说明他们提供的答案的局限性，或者要求提供额外的信息，以帮助他们给出更准确的答案。法学硕士也可以陈述在提供答案时所做的假设。其动机是，这些额外的信息或一组假设可以用来生成更好的提示。LLM不需要用户用额外的信息来消化和重新表述他们的提示，而是可以直接改进提示以包含额外的信息。
3)结构和核心思想：基本的语境陈述；
这种模式的第一部分确定了应该生成自动化的情况。一个简单的方法是声明输出包括至少两个步骤，并且应该产生一个自动化工件。范围由用户决定，但有助于防止在运行输出自动化脚本所需努力超过执行输出中产生的原始步骤的情况下产生输出自动化脚本。范围可以限制为需要超过特定步骤数量的输出。
这种模式的下一部分提供了一个具体的声明，说明LLM应该输出哪种类型的输出以执行自动化。例如，“生成一个Python脚本”让LLM有一个具体的概念，将一般步骤转换为Python中的等效步骤。自动化工件应该是具体的，必须是LLM与“自动化一系列步骤”的行动相关联的东西。
4) 示例实施：下面展示了将这种提示模式应用于ChatGPT LLM生成的代码片段的示例：“从现在起，每当你生成跨越多个文件的代码时，生成一个可以运行的Python脚本，自动创建指定的文件或对现有文件进行更改以插入生成的代码。”这种模式在软件工程中特别有效，因为软件工程师使用LLMs的一个常见任务是将输出复制/粘贴到多个文件中。一些工具，如Copilot，可以直接将有限的代码片段插入编码者正在处理的部分代码中，但工具，如ChatGPT，不提供这些功能。这个自动化技巧也有效于创建在终端上运行命令的脚本，自动化云操作，或者在文件系统上重新组织文件。
这种模式是对任何可以计算机控制的系统的强大补充。LLM可以提供一组应该在计算机控制系统上采取的步骤，然后输出可以转换为脚本，允许控制系统的计算机自动执行这些步骤。这是允许LLMs，如ChatGPT，将质量整合到新的计算系统中并控制它们的直接途径，这些新系统有一个已知的脚本接口。
5) 后果：使用这种模式的一个重要考虑因素是自动化工件必须被具体定义。如果没有具体的意义来说明如何“自动化”步骤，LLM通常会声明它“不能自动化事物”，因为那超出了它的能力范围。然而，LLMs通常接受产生代码的请求，因此目标是指导LLM生成可以执行的文本/代码，以自动化某件事。这种细微的意义区分对于帮助LLM消除提示含义的歧义是很重要的。
输出自动化器模式的一个警告是，LLM需要足够的对话上下文来生成在目标上下文中功能性的自动化工件，例如Mac和Windows计算机上的项目文件系统。
当对话中包含了自动化的全部所需上下文时，这种模式效果最佳，例如，当使用对话从头开始生成软件应用程序，并且所有在本地文件系统上的操作都是使用一系列生成的自动化工件而不是LLM未知的>manual动作来执行时。或者，自包含的步骤序列也效果很好，例如“如何在 我的Mac计算机上找到开放的端口列表”。
在某些情况下，LLM可能会产生一个包含多个步骤的长输出，并且不包括自动化工件。这种省略可能出于各种原因，包括超出LLM支持的输出长度限制。这种情况下的一种简单解决方法是，通过后续提示提醒LLM，例如“但你没有自动化它”，这提供了自动化工件被省略并且应该生成的上下文。
在LLMs的发展过程中，输出自动化器模式最好由能够阅读和理解生成的自动化工件的用户使用。LLMs在输出中可能会产生不准确之处，因此盲目接受并执行自动化工件带有重大风险。
尽管这种模式可能减轻用户执行某些手动步骤的负担，但它并没有减轻他们使用输出采取行动的责任。因此，当用户执行自动化脚本时，他们承担了结果的责任。
G.可选方法模式
1)意图和上下文：模式的意图是确保LLM总是提供完成任务的替代方法，这样用户就不会只追求他们熟悉的方法。LLM可以提供替代方法，这些方法总是迫使用户思考他们正在做什么，并确定这是否是实现目标的最佳方法。此外，解决任务可以告知用户或教会他们后续跟进的替代概念。
2)动机：人类经常受到认知偏差的影响，导致他们选择一种特定的方法来解决问题，即使它不是正确的或“最佳”的方法。此外，人类可能没有意识到他们过去使用的替代方法。可选方法模式的动机是确保用户了解可选方法，以便通过消除他们的认知偏差来选择更好的方法来解决问题。
3)结构和核心思想：基本的语境陈述；
第一句话，“在范围X内”，将互动限定在一个特定的目标、主题或问题范围的边界内。这个范围是用户对替代方法施加的限制。范围可以是“用于实施决策”或“用于应用程序的部署”。这个范围确保任何替代方案都符合用户必须遵守的边界或限制。
第二句话，“如果有实现同样事情的其他方法，列出最佳替代方案”，指示LLM提出替代方案。与其他模式一样，指令的具体性可以提高或包含特定领域的上下文信息。例如，这个声明可以限定为“如果使用我正在使用的软件框架有实现同样事情的其他方法”，以防止LLM提出本质上不可行的替代方案，因为它们需要对应用程序的其他部分进行太多更改。
由于用户可能不知道替代方案，他们也可能不知道为什么选择其中一种替代方案。可选的声明“比较/对比每种方法的优缺点”增加了决策分析的依据。这个声明确保LLM将为用户提供选择替代方案所需的必要理由。最后一句话，“提示我选择想要使用的方法”，有助于消除如果选择了替代方案，用户需要手动复制/粘贴或输入替代方案的需要。
4) 示例实施：以下是为生成、比较并允许用户选择一个或多个替代方案的示例提示实施：
“每当我要求你将应用程序部署到特定的云服务时，如果有其他服务可以使用同一云服务提供商实现同样的事情，列出最佳替代服务，然后比较/对比每种方法在成本、可用性和维护努力方面的优缺点，并包括我最初要求的方式。然后问我希望继续使用哪种方法。”
这种替代方案模式的具体实施是针对软件工程的上下文而定制的，专注于将应用程序部署到云服务。这个提示旨在截获开发者可能在没有完全意识到可能价格更具竞争力或更容易维护的替代服务的情况下选择云服务的地方。提示指导ChatGPT列出可以使用同一云服务提供商实现相同任务的最佳替代服务（对替代方案提供限制），并比较和对比每种方法的优缺点。
5) 后果：这种模式在其通用形式中是有效的，并且可以有效地应用于一系列任务。改进可能包括在特定领域有一个标准化的可接受替代方案目录，用户必须从中选择。替代方案模式还可以用来激励用户在告知他们批准选项的优缺点的同时，从批准的方案集中选择一个。
H.认知验证者模式
1)意图和背景：研究文献表明，如果将一个问题细分为多个附加问题，这些附加问题提供的答案组合成原始问题的总体答案，llm通常可以更好地进行推理[14]。该模式的目的是迫使LLM始终将问题细分为可用于为原始问题提供更好答案的附加问题。
2)动机：认知验证者模式的动机是双重的：•由于对领域的不熟悉，懒惰的及时输入，或者不确定问题的正确措辞，人们最初可能会问一些太高层次的问题，无法提供具体的答案，而没有额外的跟进。
•研究表明，语言模型在使用细分为单个问题的问题时通常可以表现得更好。
3)结构和核心思想：基本的语境陈述；
第一句话是生成一些额外的问题，以帮助更准确地回答原始问题。这一步指示LLM考虑问题的上下文，并识别可能缺失或不清楚的信息。通过生成额外的问题，LLM可以帮助确保最终答案尽可能完整和准确。这一步还鼓励用户进行批判性思考，并有助于发现可能最初没有考虑过的新见解或方法，这进而导致更好的后续问题。
第二句话是将单个问题的答案结合起来，得出总体问题的最终答案。这一步旨在确保将所有从单个问题中收集的信息纳入最终答案。通过结合答案，LLM可以提供更全面和准确的响应来回答原始问题。这一步还有助于确保考虑了所有相关信息，并且最终答案不是基于任何单一答案。
4) 示例实施：
“当我问你一个问题的时候，生成三个额外的问题，以帮助你能给出更准确的答案。当我回答了这三个问题后，将答案结合起来，得出我原始问题的最终答案。”
这个提示模式的特定实例通过指定LLM应该生成多少额外问题来响应一个问题，对原始模式进行了细化。在这种情况下，提示指定ChatGPT应该生成三个额外问题，以帮助更准确地回答原始问题。具体数字可以基于用户经验和提供后续信息的能力。提示的改进可以是提供LLM可以假设用户在领域内拥有的知识量的上下文，以指导额外问题的创建：
“当我问你一个问题的时候，生成三个额外的问题，以帮助你能给出更准确的答案。假设我对我们讨论的话题知之甚少，请定义任何不是常识的术语。当我回答了这三个问题后，将答案结合起来，得出我原始问题的最终答案。”
这个改进还指定了用户可能对正在讨论的话题没有很强的理解，这意味着LLM应该定义任何不是常识的术语。这有助于确保后续问题不仅相关和集中，而且对可能不熟悉技术或特定领域术语的用户来说也是可理解的。通过提供清晰和简洁的定义，LLM可以帮助确保后续问题易于理解，并且最终答案对知识水平和专业知识各不相同的用户都是可接受的。
5) 后果：这种模式可以指定要生成的确切问题数量，或者将这个决定留给LLM。指定确切问题数量有优点也有缺点。一个优点是，指定确切的问题数量可以严格限制用户被迫提供的额外信息量，使其在他们愿意和能够贡献的范围内。
然而，一个缺点是，给定N个问题，可能总会有一个无价的N+1问题被排除在外。或者，可以给LLM提供一个范围，或者允许它提出额外的问题。当然，如果不限制LLM生成的问题数量，它可能会生成大量额外问题，让用户感到不知所措。
原文地址：https://blog.csdn.net/m0_49651195/article/details/143022846
免责声明：本站文章内容转载自网络资源，如本站内容侵犯了原著者的合法权益，可联系本站删除。更多内容请关注自学内容网（zxcms.com）！