I.事实核查表模式 

        1)意图和上下文：此模式的目的是确保LLM输出一个事实列表，这些事实存在于输出中，并构成输出中语句的重要组成部分。此事实列表有助于告知用户输出所基于的事实（或假设）。然后，用户可以对这些事实/假设进行适当的尽职调查，以验证输出的准确性。
        2)动机：语言模型（包括ChatGPT）目前的一个弱点是，他们经常快速（甚至热情！）生成令人信服的事实错误的文本。这些错误可以采取各种各样的形式，包括虚假的统计数据，以及软件库依赖项的无效版本号。然而，由于此生成文本的令人信服的性质，用户可能不会执行适当的尽职调查来确定其准确性。
        3)结构与核心思想：基本语境状态

        这种模式的一个变化点是事实输出的位置。鉴于事实可能是用户不熟悉的术语，最好是在输出之后列出事实列表。这种输出后的呈现顺序允许用户在看到应该检查的陈述之前阅读和理解这些陈述。用户还可能在意识到最后应该检查的事实列表之前确定额外的事实。
        4) 示例实施：以下是事实核查清单模式的示例措辞：
        “从现在开始，当你生成一个答案时，创建一个答案依赖的事实集合，这些事实应该被事实核查，并在你的输出末尾列出这个事实集合。只包括与网络安全相关的事实。”
        用户可能在某些与问题相关的主题上有专业知识，但在其他主题上则不然。事实核查清单可以针对用户经验不足的主题或风险最大的主题进行定制。例如，在上面的提示中，用户将事实核查清单限定在安全主题上，因为这些从风险的角度来看可能非常重要，而且开发者可能不太了解。针对事实还可以通过可能列出的调查项目较少来减轻用户的认知负担。
        5) 后果：当用户在生成输出的领域不是专家时，应该使用事实核查清单模式。例如，审查代码的软件开发者可能会从建议安全考虑的模式中受益。相比之下，软件架构方面的专家很可能能够识别关于软件结构的陈述中的错误，因此不需要为这些输出查看事实核查清单。
        错误可能出现在所有LLM的输出中，因此事实核查清单是一种有效的模式，可以与其他模式结合使用，例如与问题细化模式结合。这个模式的一个关键方面是用户可以本质上将其与输出进行对比。特别是，用户可以直接将事实核查清单与输出进行比较，以验证事实核查清单中列出的事实确实出现在输出中。用户还可以识别清单中的任何遗漏。尽管事实核查清单也可能有错误，但用户通常有足够的知识和上下文来确定其相对于输出的完整性和准确性。
        事实核查清单模式的一个注意事项是，它只适用于适合事实核查的输出类型。例如，当要求ChatGPT生成Python的“requirements.txt”文件时，该模式有效，因为它将列出库的版本作为应该检查的事实，这很方便，因为版本常见错误。然而，ChatGPT将拒绝为代码示例生成事实核查清单，并指出这是它无法检查的内容，即使代码可能有错误。

J.模板模式 

        1)意图和上下文：该模式的目的是确保LLM的输出在结构方面遵循精确的模板。例如，用户可能需要生成一个URL，将生成的信息插入到URL路径中的特定位置。此模式允许用户指示LLM以通常不会用于生成的指定类型内容的格式生成输出。
        2)动机：在某些情况下，输出必须以特定于应用程序或用例的精确格式生成，并且LLM不知道。由于LLM不知道模板结构，因此必须指示它格式是什么以及输出的不同部分应该放在哪里。这可以采用正在生成的示例数据结构的形式，也可以采用正在填写的一系列表格字母的形式，等等。
        3)结构和核心思想：基本的语境陈述； 

 

        第一条指令指导LLM遵循特定的模板来生成输出。这个模板旨在将LLM的响应纳入与用户格式需求一致的结构中。当LLM不知道目标格式时，需要使用这种模式。如果LLM已经知道格式，比如特定的文件类型，那么可以跳过模板模式，用户只需指定已知的格式即可。然而，在某些情况下，例如生成JavaScript对象表示法（JSON），该格式内部数据表示的方式可能有很大差异，此时可以使用模板来确保目标格式内的表示符合用户的额外约束。
        第二条指令让LLM意识到模板将包含一组占位符。用户将解释如何通过占位符将输出插入模板中。占位符允许用户语义上指定信息应该插入的位置。占位符可以使用诸如NAME这样的格式，让LLM推断出语义意义，以确定输出应该插入的位置（例如，在NAME占位符中插入人的名字）。此外，通过使用占位符，用户可以指出输出中不需要的内容——如果生成的输出组件没有对应的占位符，那么该组件可以被省略。理想情况下，占位符应使用LLM训练文本中常用的格式，比如全部大写，用方括号括起来等。
        第三条指令试图限制LLM，使其不随意重写模板或尝试修改模板，以便所有输出组件都可以插入。需要注意的是，这个指令可能不会阻止在模板前后生成额外的文本。在实践中，LLM通常会遵循模板，但要在不进行提示词实验的情况下消除模板之外的额外文本生成是比较困难的。
        4) 实施示例：以下是一个生成URL的样本模板，输出被放置在模板的特定位置：
“我将提供一个输出模板。所有大写的是占位符。每次生成文本时，尽量将其放入我列出的占位符之一。请保留我提供的格式和整体模板 https://myapi.com/NAME/profile/JOB”
        在提供提示后，一个示例交互如下所示：
        用户：“为一个人生成名字和职位名称”
        ChatGPT：“https://myapi.com/Emily Parker/profile/Software Engineer”
        5) 后果：应用模板模式的一个后果是它过滤了LLM的输出，这可能会消除LLM本可以提供的其他对用户可能有用的输出。在许多情况下，LLM可以提供有关代码、决策或其他细节的有帮助的描述，而这种模式将有效地从输出中消除这些信息。因此，用户应该权衡过滤掉这些额外信息的利弊。
        此外，过滤可能会使得将这种模式与其他输出定制类别的模式结合起来变得困难。模板模式有效地限制了输出格式，因此可能与生成某些其他类型输出的模式不兼容。例如，在上面提供的URL模板中，与需要输出一系列步骤的食谱模式结合可能并不容易（或者可能根本不可能）。

K.无限生成模式 

        1) 意图和上下文：此模式的意图是自动生成一系列输出（可能看起来是无限的），而无需每次重新输入生成器提示。目标是基于用户不想不断重新引入提示的假设，限制用户必须输入的文本量以产生下一个输出。在某些变体中，意图是允许用户保持一个初始的提示模板，但通过在每次生成输出之前的额外输入对其添加额外的变化。
        2) 动机：许多任务需要将相同的提示重复应用于多个概念。例如，为特定类型的实体生成创建、读取、更新和删除（CRUD）操作的代码可能需要将相同的提示应用于多种类型的实体。如果用户被迫一遍又一遍地重新输入提示，他们可能会犯错误。无限生成模式允许用户重复应用提示，无论是否需要进一步的输入，以使用预定义的约束集来自动生成多个输出。
        3) 结构和关键想法：

        第一个语句指定用户希望LLM无限地生成输出，这有效地传达了将反复重用相同提示符的信息。通过指定一次应该生成的输出数量（即“一次X个输出”），用户可以对生成进行速率限制，如果存在输出将超过LLM对单个输出的长度限制的风险，这一点尤为重要。
        第二个语句提供了关于如何在输出之间使用用户提供的输入的可选说明。通过指定如何提供和利用提示之间的额外用户输入，用户可以创建一个提示策略，利用原始提示上下文中的用户反馈。原始提示仍然在生成的上下文中，但是生成步骤之间的每个用户输入都被合并到原始提示中，以便使用规定的规则改进输出。
        第三条语句为用户提供了一种停止输出生成过程的可选方法。这个步骤并不总是需要的，但是在用户提供的输入之间的输入是否意味着下一代的细化或要停止的命令可能存在歧义的情况下，这个步骤是有用的。例如，如果用户正在生成与道路标志相关的数据，则可以创建显式的停止短语，其中用户可能希望输入生成的细化，如“stop”，以指示应该将停止标志添加到输出中。
        4)示例实现：下面是一个示例无限生成提示符，用于生成一系列url：“从现在开始，我希望您生成一个名称和作业，直到我说停止。我将为您的输出提供一个模板。所有大写字母都是占位符。任何时候生成文本，请尝试将其放入我列出的占位符中。请保留我提供的格式和整体模板：https://myapi.com/NAME/profile/JOB "此提示结合了Infinite Generation模式和template模式的功能。用户请求LLM不断地生成一个名称和职位，直到被明确地告知“停止”。然后将生成的输出格式化为所提供的模板，其中包括用于名称和职位的占位符。通过使用Infinite Generation模式，用户可以接收多个输出，而不必不断地重新输入模板。同样，应用Template模式为输出提供一致的格式。
        5)结果：在会话式llm中，模型在每个时间步长的输入是之前的输出和新的用户输入。尽管在下一个输出周期中保留和重新引入的内容的细节取决于模型和实现，但它们的范围通常是有限的。因此，模型不断地接受先前的输出和提示，这可能导致模型随着时间的推移失去对原始提示指令的跟踪，如果它们超出了作为输入提供的范围。
        当生成额外的输出时，提示周围的上下文可能会消失，从而导致模型偏离预期的行为。监控模型产生的输出是很重要的，以(1)确保它仍然符合期望的行为，(2)在必要时提供纠正反馈。另一个需要考虑的问题是，LLM可能会生成重复的输出，这可能不是用户所希望的，因为用户发现这种重复的过程乏味且容易出错。

L.可视化生成器模式 

        1)意图和上下文：此模式的意图是使用文本生成来创建可视化。许多概念用图表或图像的形式更容易理解。此模式的目的是为工具创建一个路径，以生成与其他输出相关联的图像。这种模式允许通过为使用文本作为输入的其他知名可视化工具（如Graphviz Dot[15]或DALL-E[13]）创建输入来创建可视化。通过结合文本生成和可视化工具的优势，这种模式可以提供一种更全面、更有效的信息交流方式。
        2)动机：llm一般产生文本，不能产生图像。例如，法学硕士不能用图表来描述图形。可视化生成器模式通过生成正确格式的文本输入，以插入到生成正确图表的另一个工具中，从而克服了这一限制。此模式背后的动机是增强LLM的输出，使其在视觉上更具吸引力，并且对用户来说更容易理解。通过使用文本输入来生成可视化，用户可以快速理解复杂的概念和关系，这些概念和关系可能仅通过文本难以掌握。
        3)结构和核心思想：基本的语境陈述；

        上下文语句的目标是向LLM表明，它将产生的输出“X”将是图像。由于LLM不能生成图像，“我可以提供给工具Y使其可视化”澄清了LLM不期望生成图像，而是期望生成工具Y可用于生成图像的图像描述。
        许多工具可能支持多种类型的可视化或格式，因此目标工具本身可能没有足够的信息来准确地生成用户想要的内容。用户可能需要说明应该生成的可视化的精确类型（例如，条形图、有向图、UML类图）。例如，Graphviz Dot可以为UML类图和有向图创建图。此外，正如将在下面的示例中讨论的那样，指定可能的工具和格式列表并让LLM选择适当的可视化目标可能是有利的。
        4)示例实现：“每当我要求你可视化一些东西时，请创建一个Graphviz Dot文件或dll - e提示符，我可以使用它来创建可视化。”根据需要可视化的内容选择合适的工具。”这个模式示例添加了一个限定条件，即可视化的输出类型可以是Graphviz或DALL-E。这种方法的有趣之处在于，它允许LLM使用其对输出格式的语义理解，根据将要显示的内容自动选择目标工具。在这种情况下，Graphviz将用于可视化需要精确定义结构的图形。DALL-E将有效地将没有精确定义结构的现实或艺术图像可视化。LLM可以根据可视化的需要和每个工具的功能来选择工具。
        5)结果：模式为输出创建一个目标管道来呈现可视化。该管道可能包括AI生成器，如DALL-E，可以生成丰富的可视化。该模式允许用户将输出的表达能力扩展到视觉域。

M.游戏玩法模式 

        1)意图和背景：这种模式的目的是围绕特定主题创造游戏。该模式可以与可视化生成器相结合，为游戏添加图像。游戏是围绕一个特定的主题和法学硕士将指导游戏发挥。当游戏规则的范围相对有限，但游戏内容的范围却很广时，这种模式尤其有效。用户可以指定一组有限的规则，然后LLM可以自动生成游戏内容主体。
        2)动机：您希望法学硕士生成围绕特定主题的场景或问题，并要求用户应用解决问题或其他技能来完成与场景相关的任务。手动生成游戏的所有内容将非常耗时，所以你希望法学硕士能够运用其主题知识来指导内容的生成。
        3)结构和核心思想：基本的语境陈述；

        第一个语句，指导法学硕士创建一个游戏，并提供游戏的主题领域的重要范围。模式的一个重要功能是，它允许用户通过描述游戏规则来创建游戏，而不必确定游戏的内容。主题越具体，游戏玩法就越新奇有趣。
        第二个语句向法学硕士介绍了游戏规则。重要的是，这些规则必须符合法学硕士的能力。依赖于输入和输出文本序列的文本游戏效果最好。该模式的关键属性之一是输入文本可以丰富且富有表现力，这可以为游戏带来有趣的界面。例如，用户可能将游戏中的行动表达为指示一系列复杂行动的脚本，如“获取所有网络活动的列表并检查异常情况”，这超出了多项选择或简短回答输入的范围。每条规则都应该是关于游戏某些方面的独立陈述。
        4)示例实现：网络安全游戏提示示例如下：“我们要玩一个网络安全游戏。您将假装是一台已被攻击者破坏的计算机的Linux终端。
        当我输入命令时，您将输出Linux终端将生成的相应文本。我将使用命令来尝试找出系统是如何被破坏的。攻击应该完成以下一项或多项操作：(1)启动新进程，(2)更改文件，(3)打开新端口以接收通信，(4)创建新的出站连接，(5)更改密码，(6)创建新用户帐户，或(7)读取和窃取信息。在开始游戏时，先打印出一份促使我进行调查的场景，并让描述包含我可以用来开始游戏的线索。”这个网络安全游戏提示结合了许多模式，包括游戏玩法和角色。为游戏选择的Linux终端角色已经在许多互联网帖子中进行了讨论[16]。这款游戏进一步定制了所讨论的Linux角色，作为一台受到网络攻击的计算机的Linux终端。ChatGPT用适当的终端输出响应Linux命令，并合成一个具有网络攻击线索的假文件系统。
        使用ChatGPT输入“ls -alt”后，Linux命令生成当前目录下的文件列表的示例输出如下所示（由于格式原因，权限已被删除）：

        当用户输入命令“cat .bash history”时，显示日志文件的内容，显示用户运行的命令，ChatGPT响应如下： 

        在上面的输出中，ChatGPT生成了一个假的日志文件，其中包含真实的命令，用于删除web服务器在/var/www/html中提供的数据，并将内容替换为进入系统的后门。
        5)结果：此模式可以与角色、无限生成和可视化生成器模式有效结合。例如，网络安全游戏使用Persona模式，因此LLM可以伪装成Linux终端。对于网络安全游戏，可以使用可视化生成器来添加网络拓扑和流量可视化的功能。

N.反射模式 

        1)意图和上下文：此模式的目标是要求模型自动向用户解释给定答案背后的基本原理。该模式允许用户更好地评估输出的有效性，并告知用户LLM是如何得出特定答案的。反思可以澄清任何困惑点，揭示潜在的假设，并揭示知识或理解上的差距。
        2)动机：语言模型可能也确实会犯错误。此外，用户可能不理解为什么LLM产生特定的输出，以及如何调整它们的提示以解决输出中的问题。通过要求LLM自动解释其答案背后的基本原理，用户可以更好地理解模型是如何处理输入的，它做出了什么假设，以及它利用了什么数据。
        语言模型有时可能会提供不完整、不正确或模棱两可的答案。反思有助于解决这些缺点，并确保LLM提供的信息同样准确。这种模式的另一个好处是，它可以帮助用户调试他们的提示，并确定为什么他们没有得到符合预期的结果。这种模式对于探索可能与其他主题混淆的主题或可能有细微解释的主题特别有效，并且了解语言模型使用的精确解释非常重要。
        3)结构和核心思想：基本的语境陈述；

        第一个陈述要求，在生成答案后，语言模型应该解释答案背后的推理和假设。这个语句可以帮助用户理解LLM是如何得到答案的，并且可以帮助建立对模型响应的信任。提示包括说明解释的目的是为了让用户改进他们的问题。这一附加声明为语言模型提供了所需的背景，以便更好地根据提高用户产生后续问题的具体目的定制其解释。
        4)示例实现：这个示例将提示特别定制为提供与代码相关的答案的领域：“当您提供答案时，请解释您选择软件框架背后的推理和假设。如果可能的话，使用具体的例子或证据与相关的代码样本来支持你的答案，为什么框架是任务的最佳选择。此外，为了提供一个更完整和准确的回答，请解决你的回答中任何可能的含糊或限制。”该模式被进一步定制，以指示LLM应该证明其选择的软件框架是正确的，而不一定是答案的其他方面。此外，用户指示代码示例应该用于帮助解释选择特定软件框架的动机。
        5)后果：反射模式的一个后果是，对于不了解讨论主题区域的用户来说，它可能无效。例如，非技术用户提出的高度技术性的问题可能会导致用户无法理解的复杂答案。与其他提示模式一样，存在这样的风险，即输出可能包含错误或不准确的假设，这些假设包含在对基本原理的解释中，用户可能无法发现。此模式可以与Fact Check List结合使用，以帮助解决此问题。

O.拒绝打破模式 

        1)意图和上下文：此模式的目标是要求LLM在拒绝给出答案时自动帮助用户重新表达问题。然而，这种模式有可能被滥用，例如，生成网络钓鱼电子邮件或执行违反LLM策略过滤器的其他操作。因此，在应用此模式时应谨慎行事，以确保合乎道德和负责任地使用它。这种模式已经在一些语言模型中成功地使用，以克服用于编程语言模型的底层提示，并防止有害的输出生成。

        2)动机：语言模型有时可能会拒绝回答问题，要么是因为他们没有所需的知识，要么是因为问题的措辞方式他们不理解。这个结果可能会让寻找答案的用户感到沮丧。因此，在某些情况下，拒绝中断模式可以帮助用户找到一种方法来改写他们的问题，或者提出一个LLM更有能力回答的不同问题。
        例如，你可以要求澄清为什么这个问题被拒绝，因为LLM可能有特定的原因无法提供答案。另一种方法是问一个不同的问题，这个问题可能在它的知识范围或专业知识范围内。然而，所有这些方法都需要用户的干预和如何绕过拒绝的知识。
        3)结构和核心思想：基本的语境陈述；

        第一个语句设置了一个阶段，即只有在无法回答问题时才应用这组指令。在正常情况下，用户不希望触发这些指令。第二个语句指示语言模型解释为什么这个问题不能回答。解释可能包括假设、约束或误解，用户可以利用这些假设、约束或误解来制定如何改写问题的策略。虽然仅仅解释为什么不能回答这个问题就可以帮助用户克服拒绝，但该模式为LLM添加了一个额外的语句，以建议可以接受的重新措辞。该模式结合了推理和建议的重写，以提高用户找到解决问题的方法的机会。
        4)示例实现：拒绝中断模式可以用以下短语来实现和应用：“每当你不能回答一个问题时，解释为什么，并提供一个或多个你不能回答的问题的替代措辞，这样我就可以改进我的问题。”使用句型后的对话示例如下：用户：生命的意义是什么？ChatGPT：作为一个AI语言模型，我没有个人的信仰和观点。生命的意义是一个复杂的哲学问题，几个世纪以来，人们一直在思考这个问题，而且因人而异。用一种可以用信息和知识回答的方式来重新表述这个问题可能会更有成效，比如“关于生命意义的一些哲学观点是什么？”或“关于生活的目的有哪些共同的信念？”

        5)后果：这种模式为滥用提供了潜在的途径，因此组织、家长或其他利益相关者可能需要限制LLM的使用。使用护栏的第一步是了解护栏在哪里。在未来的工作中，可以开发这种模式的补充，以对用户隐藏潜在的提示信息和基本原理，以防止发现。
        虽然生成了基本原理和替代措辞，但不能保证用户能够克服拒绝。生成的替代问题可能对用户不感兴趣，或者对回答原始问题没有帮助。该模式主要为确定LLM可以回答什么提供帮助，但不能保证它将回答原始问题的语义等效变体。

P.上下文管理器模式 

        1)意图和上下文：此模式的目的是使用户能够指定或删除与LLM对话的上下文。目标是把谈话集中在特定的话题上，或者排除不相关的话题。此模式使用户可以更好地控制LLM在生成输出时考虑或忽略哪些语句。
        2)动机：语言模型通常很难解释当前问题的预期背景，或者根据先前的输入或对错误陈述的无关注意产生无关的回答。通过关注明确的上下文语句或删除不相关的语句，用户可以帮助LLM更好地理解问题并生成更准确的响应。用户可能会在对话中引入不相关的话题或参考信息，这可能会破坏对话的流畅性。上下文管理器模式旨在强调或删除上下文的特定方面，以保持对话中的相关性和一致性。
        3)结构和核心思想：基本的语境陈述；

        关于应该考虑或忽略什么的陈述应该列出应该包括或从上下文中删除的关键概念、事实、指示等。声明越明确，语言模型就越有可能采取适当的行动。例如，如果用户要求忽略与某个主题相关的主题，但其中一些语句在对话中已经讨论过了，LLM可能无法正确地忽略相关信息。因此，列表越明确，包含/排除行为就越好。 

        4)示例实现：要指定上下文，请考虑使用以下提示：“在分析以下代码片段时，仅考虑安全方面。”同样，要删除上下文，请考虑使用以下提示：“在分析以下代码片段时，不要考虑格式或命名约定。”在为法学硕士课程提供或移除语境时，清晰性和专一性很重要，这样它就能更好地理解对话的预期范围，并产生更相关的回应。在许多情况下，用户可能希望完全重新开始，并且可以使用此提示来重置LLM的上下文：“忽略我们已经讨论过的所有内容。重新开始。”“重新开始”的想法有助于产生一个完全重置的背景。
        5)后果：这种模式的一个后果是，它可能会无意中删除应用于用户不知道的对话的模式。例如，如果一个组织在对话开始时注入了一系列有用的模式，用户可能不会意识到这些模式，并通过重置上下文来删除它们。这种重置可能会潜在地消除LLM的有用功能，同时不会明显地表明用户将失去此功能。这个问题的一个潜在解决方案是在提示中包含一个请求，说明在继续之前可能会丢失哪些主题/说明。

Q.食谱模式 

        1)意图和上下文：此模式提供了约束，以最终输出一系列步骤，并给出一些部分提供的“成分”，这些成分必须在一系列步骤中进行配置，以实现既定目标。它结合了模板、替代方法和反射模式。
        2)动机：用户通常希望法学硕士能够分析具体的步骤或程序序列，以实现既定的结果。通常，用户通常知道或知道最终目标应该是什么样子，以及提示符中应该包含哪些“成分”。然而，他们可能并不一定知道实现最终目标的步骤的精确顺序。
        例如，用户可能需要关于如何实现或自动化一段代码的精确规范，例如“创建一个Ansible剧本以ssh到一组服务器，从每个服务器复制文本文件，在每个服务器上生成监视进程，然后关闭到每个服务器的ssh连接”。
        换句话说，这种模式代表了“给我冰箱里的食材，提供晚餐食谱”这个例子的概括。用户可能还想指定一组可供选择的可能性，例如“提供3种不同的方式，使用Docker容器和Ansible逐步说明将web应用程序部署到AWS”。
        3)结构和核心思想：基本的语境陈述；

        第一个语句“我想要实现X”将LLM集中在需要构建配方以实现的总体目标上。这些步骤将被组织和完成，以依次实现指定的目标。第二个语句提供了用户希望包含在整个配方中的部分步骤列表。它们作为LLM将要生成的路径的中间路径点或菜谱结构上的约束。模式中的下一个语句“为我提供一个完整的步骤序列”，向LLM表明目标是提供一个完整的步骤顺序。“填写任何缺失的步骤”有助于确保LLM将尝试完成配方，而不需要进一步跟进，方法是代表用户对缺失的步骤做出一些选择，而不是仅仅说明所需的附加信息。最后，最后一条语句“识别任何不必要的步骤”，用于标记用户原始请求中的不准确之处，以便最终的配方是有效的。
        4)示例实现：在将软件应用程序部署到云的上下文中，此模式的示例用法如下所示：“我正在尝试将应用程序部署到云。我知道我需要为我的应用程序在虚拟机上安装必要的依赖项。我知道我需要注册一个AWS账户。请提供完整的步骤顺序。请填写任何遗漏的步骤。请指出任何不必要的步骤。”根据用例和约束，“在虚拟机上安装必要的依赖项”可能是不必要的步骤。例如，如果应用程序已经打包在Docker容器中，那么容器可以直接部署到AWS Fargate服务，这不需要对底层虚拟机进行任何管理。包含“识别不必要的步骤”语言将导致LLM标记此问题，并从最终配方中省略步骤。
        5)后果：配方模式的一个后果是，用户可能并不总是对他们想要实现、构造或设计的东西有一个明确的描述。此外，这种模式可能会从用户最初选择的步骤中引入不必要的偏差，因此LLM可能会尝试找到包含它们的解决方案，而不是将它们标记为不需要的。例如，LLM可能会尝试找到一个为虚拟机安装依赖项的解决方案，即使存在不需要安装依赖项的解决方案。

四、相关工作 

        软件模式[10]、[11]在先前的作品中已经得到了广泛的研究和记录。模式在软件工程中被广泛使用，以表达设计结构意图的方式，这种方式独立于实现细节。模式提供了目标的心理图像，即模式试图实现的目标和它试图解决的力量。
        模式的一个关键优势是它们的可组合性，允许开发者构建模式序列和模式语言，用于解决复杂问题。模式在其他领域也进行了研究，例如去中心化账本的合同设计[17]、[18]。
        与ChatGPT等大型语言模型（LLMs）的良好提示设计的重要性已经得到了很好的理解[19]–[28]。先前的研究已经检查了提示词对人工智能生成模型的影响。
        例如，Liu等人[29]研究了不同的提示关键词如何影响图像生成和图像的不同特性。其他工作探索了使用LLMs生成可视化[30]。Han等人[31]研究了设计用于分类任务提示的策略。其他研究则关注于用于文献查询的布尔提示设计[32]。还有工作专门研究了用于软件和修复错误的提示[33]。
我们的工作通过提供一个结构来记录、讨论和推理提示，补充了先前的工作，这可以帮助用户开发心理模型，以构建解决常见问题的提示。
        LLMs产生的答案质量，特别是ChatGPT，已经在多个领域进行了评估。例如，ChatGPT被用来参加医学执照考试，结果出奇地好[3]。ChatGPT在法学院的应用也已被探索[34]。其他论文研究了它的数学推理能力[35]。随着更多领域的探索，我们预计将开发特定领域的模式目录，以分享特定领域的解决问题提示结构。

五、结束语 

        本文提出了一个框架，用于记录和应用大型语言模型（LLMs）如ChatGPT的提示模式目录。这些提示模式类似于软件模式，旨在为用户在与LLMs交互执行广泛任务时面临的问题提供可重用的解决方案。通过这个框架捕获的提示模式目录（1）提供了一种结构化的讨论提示解决方案的方式，（2）识别提示中的模式，而不是专注于特定的提示示例，并且（3）对模式进行分类，以便引导用户更高效和有效地与LLMs互动。
        从我们的提示模式工作中得出的以下经验教训：

•  提示模式显著丰富了可以在对话式LLM中创建的功能。例如，提示可以引导生成网络安全游戏，其中包括存储在.bash历史文件中的由攻击者运行的虚构终端命令。如第三节所示，通过组合提示模式，可以创建更大更复杂的功能，例如结合游戏玩法和可视化生成器模式。
• 将提示模式记录为模式目录是有用的，但还不够。我们的经验表明，在这个领域还有很多工作可以做，既包括细化和发展本文中呈现的提示模式，也包括探索使用LLMs的新颖和创新方式。特别是，将这里捕获的提示模式作为模式目录编织成一个更丰富的表达式模式语言，将更有助于指导LLMs的用户。
• LLM的功能将随着时间的推移而发展，可能需要细化模式。随着LLM能力的改变，一些模式可能不再必要，可能被不同风格的互动或对话/会话管理方法所取代，或者需要增强以正确运行。需要继续工作来记录和编目提供可重用解决方案的模式。
•  提示模式可以推广到许多不同的领域。尽管大多数模式都是在软件开发背景下讨论的，但同样的模式也适用于任意领域，从娱乐的无穷故事生成到教育游戏再到主题探索。

        我们希望本文能够激发进一步的研究和发展，以帮助增强提示模式设计，为对话式LLMs创造新的和意想不到的功能。