（译）提示词工程指南：如何写出让AI更听话的提示词（Prompt）？| 附完整示例和小学生版本

关注

原创最新推荐文章于 2026-08-25 13:25:26 发布 2.6k 阅读 AI 写同款· GEO 优化 ›

7大Prompt平台深度评测：从新手到高手的提示词实战指南 提示词（Prompt）是与大语言模型和AI绘画工具高效交互的核心指令，其质量直接决定了AI输出的精准度与实用性。理解提示词工程的基本原理，掌握角色设定、任务拆解、约束条件等核心结构，是解锁AI生产力的关键技术。通过系统学习与工程实践，用户可以将模糊需求转化为精准指令，显著提升内容生成、代码编写、设计创作等场景的效率与质量。本文聚焦PromptBase、FlowGPT、AIPRM等7个主流提示词平台，深入解析其核心优势与适用场景，并结合AI绘画、ChatGPT集成等热词，提供从模板使用、优化调试到个人工作流构阅读详情

LLM Prompt Tuning Playbook

来源：https://github.com/varungodbole/prompt-tuning-playbook/blob/main/README.md

作者：Varun Godbole, Ellie Pavlick

以下内容引用自网络；使用Google Gemini 1.5pro 翻译。

本文档的目标读者是谁？
为什么需要调优指南？
背景：预训练与后训练
- 后训练数据收集
- 预训练的“知识框架”认知
- 预训练
- 后训练
提示的注意事项
提示基本风格指南
迭代新系统指令的流程
关于大型语言模型（LLM）何时有用的几点思考
更多资源
致谢

本文档的目标读者是谁？

本文档面向所有希望提高后训练大型语言模型（LLM）提示能力的用户。我们假设读者具备一些与LLM（例如Gemini）进行基本交互的经验，但并不要求读者拥有深入的技术理解。

文档前半部分介绍了后训练和提示的本质的心智模型。后半部分提供更具体的规范和用于调整提示的高级流程。鉴于LLM的快速发展，我们认为后半部分内容可能比前半部分更容易过时。

为什么需要调优指南？

本指南的灵感来源于深度学习调优手册，该手册指导如何调整深度学习工作负载的超参数。

提示的“艺术”，如同更广泛的深度学习领域，最佳情况下是基于经验的，最差情况下则近乎炼金术。虽然LLM正在迅速改变众多应用领域，但高效的提示策略仍然是一个有待解决的开放性问题。本文档基于我们多年来使用LLM的经验，以及无数次提示工程协助请求的基础上总结而成。它试图整合和分享有用的直觉和实际的提示技巧。

我们是两位研究人员和工程师，在LLM领域已经工作多年。然而，本文档不应被视为绝对真理，也不代表Gemini后训练团队的集体立场。它只是我们个人观察和最佳实践的集合。我们希望本指南能成为我们当前思考的快照，并随着我们认知的变化和新知识的出现，在未来得到及时更新。

我们希望通过记录我们具体的思维模型和流程，能够促使社区共同努力，找到更好、更系统的提示策略。

本指南主要关注各种后训练版本的Gemini。不过，本文档中的一些方法可能也适用于其他模型，尽管我们对它们的经验较少。

背景：预训练与后训练

预训练

“预训练”是深度学习中的一个既有概念。其本质是：

你有一个你真正关心的、规模较小的数据集A，以及一个规模较大的数据集B。数据集B虽然并非数据集A，但在至少某些重要方面与之相似。例如，数据集A可能包含少量乳腺X光图像，而数据集B则可以是大型自然图像学术数据集，例如ImageNet。
你使用大型数据集B训练模型，希望它学习一些通用的特征。然后，你使用数据集A对模型进行“微调”，使其在数据集A的验证集上获得比直接使用数据集A从头训练更好的性能。也就是说，你只需使用与在数据集B上相同的训练流程，继续在数据集A上训练即可。这样，当模型遇到来自数据集A的样本时，它能够更好地利用它们，因为它已经从数据集B的广泛经验中学习到许多通用的知识。
更具体地说，再次以乳腺X光为例。通过在互联网上 readily-available 的图像上进行预训练，模型可以学习一些基本技能，例如如何分割图像中的对象，或如何识别图像中不同位置的概念。这些图像处理技能对于你的乳腺X光应用非常重要，但可能需要大量数据才能学习，并且并非特定于乳腺X光图像。如果你仅使用（获取成本高昂且数量有限的）乳腺X光数据来训练模型，它可能永远也学不会这些技能，因此也无法达到最佳性能。但是，如果先在日常图像上进行预训练，模型就可以带着这些通用技能来处理你的乳腺X光数据，并准备好使用你的专业数据来学习只能通过专业数据学习的专业技能。

训练LLM的一个关键思想是使用“语言建模”（即预测句子中的下一个词）作为预训练任务。研究表明，如果你训练一个模型从互联网上获取任意文本并准确预测下一个词，该模型将隐式地学习到网络中所反映的丰富的关于世界的结构信息。

这看起来很容易理解，直到我们试图回答这个问题：互联网反映的是什么样的世界？为了更好地理解这个问题（及其答案），我们提出了一个虽然略显奇特但却很有用的比喻：知识框架。

预训练的“知识框架”认知

LLM必须通过阅读文本内容来了解世界。然而，文本内容并不局限于描述传统意义上的“真实”事物。虽然错误信息或不正确的陈述备受关注，但文本不应也不必反映与单一世界状态对应的单一事实真相，这有很多正当且必要的原因。

例如，考虑“阿拉贡最终成为刚铎国王”这句话。这句话是真的吗？这取决于具体情况，例如，时间背景。此外，这句话是否有意义还取决于讨论它的大前提或语境。如果前提是《指环王》（LOTR），那么，你可以认为这是一个事实。但如果是在漫威电影宇宙的语境下讨论，这句话的真实性就不那么明确了。如果我们身处现实世界，也就是我们通常认为“真实”的非虚构宇宙中，那么关于阿拉贡的陈述就不是真的。因为阿拉贡和刚铎是虚构人物和地点，在现实世界中并不存在。同样地，在漫威电影宇宙中，这句话也并非事实。但如果我们身处LOTR的宇宙中，那么这句话就成立了。

这个问题，即难以定义某事“真实”的含义及其所属世界，对于LLM来说并不新鲜。它与哲学和语言学理论及论证的悠久历史密切相关。这段历史和理论值得深入研究（例如，参见这篇概述）。但就提示LLM的实际应用而言，我们可以将其简化为：一个陈述是否真实取决于其背后的“知识框架”。

在本文档中，你可以将预训练语料库视为人类文化（更准确地说是那些积极参与预训练数据源（例如网络）的文化）所产生的所有知识框架的集合的近似值。

重要

你可以将预训练语料库视为人类文化（更准确地说是那些积极参与预训练数据源（例如网络）的文化）所产生的所有知识框架的集合的近似值。

当你给模型一个固定的上下文窗口（即前缀）时，它会尝试根据前缀推断它所处的知识框架，并根据该框架内的规则、约定和事实进行操作。如果提供的提示包含非常强的上下文信号，LLM将更容易理解其含义。例如，像“梦想成真的混凝土丛林不仅仅是一句朗朗上口的歌词——它也是对纽约的真实写照。从高耸入云的摩天大楼到充满活力的多元化社区，纽约市提供了一种地球上其他任何地方都无法比拟的体验”这样的提示（这是一篇关于纽约的博客文章的开头两句）。在这种情况下，模型对风格和主题有非常强的限制，这将影响其后续的生成过程。

但是，如果你的提示非常通用——例如“你好，你好吗？”——LLM可能没有足够的上下文来理解它应该处于哪个知识框架中。“你好，你好吗？”这句话可能出现在它训练过的各种语料库的各种上下文中。换句话说，在用于解码生成的概率密度函数中存在多种“模式”。或者更简单地说，它看到了许多它可以扮演的角色的可能性。“你好，你好吗？”这句话，甚至更长的文本，都无法提供足够的上下文来消除这种歧义。

这正是后训练的意义所在。

后训练

后训练为LLM提供了关于其默认知识框架的指导。后训练并非要求LLM仅从提示中推断知识框架，而是限制LLM以一致的方式做出某些假设或解决歧义。这对于使模型实用化至关重要，原因有很多。例如，可能需要告诉LLM，默认情况下它应该遵循指令。否则，如果给出一个像“写一篇关于乔治·华盛顿的报告”这样的提示，未经后训练的LLM可能会继续生成指令的后续内容，例如“周五下午4:59前到期”，而不是生成所请求的报告。后训练也可以用来施加其他默认设置，例如引导模型的行为更符合社会规范（无论如何定义），理想情况下使其成为特定应用场景下更安全、更高效的工具。

我们非常赞同Murray Shanahan的观点，他认为理解这些模型行为的一种方式是将它们视为一种角色扮演，而这种角色扮演是由其整体训练策略决定的。我们的直觉是，后训练教会了这些模型在各种部署环境中扮演一个一致的默认角色。

重要

后训练教会了这些模型在各种部署环境中扮演一个一致的默认角色。

以下列出了LLM在后训练期间可能学习的内容（非详尽列表），从日常实用到主观个性：

模型应该遵循特定格式。 例如，Gemma 格式化工具教会它在与人类用户对话的场景中进行角色扮演。在该场景中，它被要求扮演的角色在系统指令中进行了描述。根据格式化工具的设置，在每次对话中，总是人类用户先发言。
模型应该“遵循”用户的“指令”。 也就是说，如果用户输入“写一篇关于狗的文章”，模型应该实际执行该指令，而不是回复用户类似“请详细说明你想了解关于狗的哪些方面”之类的内容。
模型应该与“现实世界”（而不是其他知识框架）相符。 后训练通常用于通过将其默认知识框架与大多数用户关心的现实世界对齐来提高模型的事实性。例如，如果你问它“$CELEBRITY 出生在哪里？”，它应该默认假设我们指的是现实世界，而不是它可能在网上遇到的某个与同名名人相关的同人小说世界。
模型应该“安全”。 互联网是一个充满各种规范标准的复杂网络。毋庸置疑，在大多数全球商业部署的背景下，相当一部分互联网内容是不适宜的。后训练有助于将模型与所选定的安全策略对齐，从而对模型可以生成的内容施加规范性限制。最终，模型在生成足够复杂的内容时，必然会做出一些关于规范的假设。

后训练数据收集

主要结论：这些模型最终是由人类评估员训练和评估的。当你指导一个后训练的LLM时，你实际上是要求一个数字角色扮演者（即LLM）扮演一个人类评估员（即生成后训练数据的人）的角色，而这个人类评估员正在扮演一个AI助手的角色。

本部分内容做了很大的简化。关于如何指导人类标注员对LLM进行后训练的复杂性和微妙之处，可以写出更长的文档。我们在本节的目标是提供对人类标注的整体理解，因为它直接影响人们如何理解提示。

从AI开发人员的角度来看，用于后训练的人类数据收集过程大致如下：

创建一个包含各种输入示例（即提示）的数据集，这些提示描述了LLM可能被要求执行的任务。这些任务可以是任何事情，从“将此数据重新格式化为JSON”到“帮我策划婚礼”。（这些提示可以来自你自己的直觉，也可以来自人类评估员。）
创建一个由人类“评估员”组成的团队，他们的工作是告诉模型如何完成这些任务。评估员的工作可能是为这些输入示例编写标准答案，例如，他们自己实际提供婚礼策划建议。或者，他们的工作可能是查看模型生成的不同回复，并按质量从高到低排序。在后训练的不同阶段，模型可以使用不同类型的人类生成的数据。
为评估员编写一些关于如何完成这项工作的指南。通常，开发人员会提供一些示例或关于任务和上下文的具体细节，以帮助评估员更好地理解任务。
收集这些数据，并使用这些数据对预训练模型进行“后训练”。
部署模型。

LLM能够“表现得像人类”的一个重要原因是，这些统计模型是根据大量精心收集的人类行为演示数据进行训练的。预训练阶段、模型架构、学习算法等为模型提供了核心基础设施和底层能力。而后训练则通过人类演示为模型提供了整体方向，这决定了它在实际部署中的行为方式。

重要

LLM能够“表现得像人类”的一个重要原因是，这些统计模型是根据大量精心收集的人类行为演示数据进行训练的。

后训练团队在其数据质量控制上花费了大量时间。他们努力将评估员与他们最适合的提示进行匹配。例如，为了提供一个如何回应包含复杂Python调试问题的提示的良好演示，需要找到一位本身就是优秀Python程序员的评估员。

从人类评估员那里收集“高质量”数据极具挑战性。原因包括：

与其他需要相同技能的工作相比，评估示例可能很枯燥： 如果你是一位优秀的Python程序员，你可能更愿意从事自己的编码项目，而不是每天花8个小时调试程序来训练AI系统。如果你是才华横溢的诗人，你可能更想创作自己的诗歌，而不是将AI生成的诗歌从最好到最坏进行排名。当然，如果你每天花费大约8小时进行评估，你会得到报酬。但是，评估示例可能非常重复，而且评估员的激励通常基于工作量。此外，评估员的自主性和成就感也可能面临挑战——你通常不知道你提供的数据如何改变了模型的整体质量，这些数据是否会被丢弃，它会被用于哪个模型等等。你与数据效用的唯一联系可能只是你的主管对你的工作评价。如果你不清楚这份工作对世界有何积极影响，你可能不会觉得这是对时间的有效利用。这可能会影响你潜意识里做好工作的热情，即使你理性上想做好工作。
定义给定任务的“好”答案非常具有挑战性。 当定义涉及事实性、良好的说明文写作或其他一些能力的现有规范时，尤其如此。（例如，假设你指示一个AI系统担任一家公司的公关代理。社会现实的复杂性很难用一套明确的规则来概括。这项工作最终需要“良好的判断力”，而判断力的运用方式因人而异，因地而异。）这使得开发人员很难为任务编写清晰的指导，也使得人类评估员对这些指导的理解带有一定的主观性。（这与普通法体系的工作方式类似。很难制定出能够预见所有边缘情况的法律。因此，社会依靠司法系统来处理边缘情况并建立先例。）
评估员可能不理解任务。 招聘任何职位都很困难，评估员也不例外。即使在招聘上投入大量精力，也无法保证评估员具备完成任务所需的技能。这可能是由于多种原因造成的。例如，设计者没有预料到评估员将要完成的任务的复杂性（例如，在任务实际上需要经验丰富的软件工程师时，却聘请了入门级软件工程师），或者评估员自身没有意识到自己知识的局限性（例如，根据大学生物课上学到的知识来回答问题，而这些知识实际上与最新的研究成果不符）。
人会犯错。 教授会发布带有错误答案的考卷。医生在饥饿或疲倦时更容易误诊。人们在家庭生活中遇到烦心事时，工作注意力会下降。由于各种原因，人类在完成任务时的表现可能会低于“黄金标准”。这意味着即使尽了最大努力，AI系统有时也会基于错误或有误导性的数据进行训练。

提示的注意事项

主要结论： 在编写系统指令和提示时，你实际上是在为后训练团队的评估员群体编写，而这个群体的知识和偏见又受到预训练语料库的影响。如果我们编写的指令是该领域内的普通评估员能够理解、领会并忠实执行的，那么模型更有可能遵循我们的指令。

重要

在编写系统指令和提示时，你实际上是在为后训练团队的评估员群体编写，而这个群体的知识和偏见又受到预训练语料库的影响。

在编写系统指令时，可以想象屏幕的另一端有一位友好、善意且称职的评估员，他/她准备扮演AI的角色。我们提供的文本就是他/她所拥有的一切信息。也就是说，当我们调用Gemini的API时，可以想象另一端有一位人类评估员会仔细阅读我们的提示并提供回复。在构建提示时，从他们的角度出发思考我们的指令非常有帮助。例如，假设指令是关于生成Python代码的。如果我们随机找一位称职的Python工程师，并要求他/她扮演Gemini的角色来回应这些指令，他/她是否能够理解我们想要什么？

这个比喻有助于你编写好的指令，但它并不一定能准确反映AI系统是如何遵循这些指令的。例如，当我们考虑到这位假设的评估员可能拥有所有人类知识时，这个比喻就不再完全适用了。他/她只是缺乏超越我们提供的提示的智慧和上下文。此外，AI系统可能不会像人类评估员那样“理解”提示。AI系统会利用其强大的统计模型来根据你的输入生成输出。但是，这些统计模型经过优化，是为了处理那些为善意且称职的人类评估员编写的指令。因此，提供任何不是为善意且称职的人类评估员编写的提示都可能会使AI系统感到困惑。AI系统最讨厌的事情莫过于处理“分布外”的数据！

考虑到这些因素，以下是一些可以帮助你改进提示中指令的注意事项。随着模型的改进，以下注意事项可能会很快过时。我们建议你理解这些注意事项背后的精神，而不是拘泥于字面意思。

指令是否清晰、易懂、简洁、明确？ 例如，假设我们的指令是关于某个Python编码任务。如果我们随机找一位Python专家，并要求他/她扮演Gemini来回应这些指令，我们的指令是否足够清晰，让他/她能够立即理解我们的意图，而无需提出任何澄清问题？
- 不好：编写一个计算素数的Python函数。
- 好：编写一个计算1到100之间素数的Python函数。包括生成的函数的类型注解，并使用2个空格的缩进。
指令是否自相矛盾或难以遵循？ 一位感到无聊、饥饿、疲倦的评估员是否真的会仔细阅读我们冗长的指令并忠实地遵循它们？请注意，通常需要进行大量的质量控制以确保给定提示中的所有指令都被遵循。但是，人非圣贤，孰能无过。我们的指令是否真的“容易”遵循？它们是否包含不必要的间接描述、冗余信息等等？当我们编写指令时，我们通常会问自己，如果在没有任何额外上下文的情况下将这些指令提供给我们公司的其他同事，他们是否能够忠实地执行。
- 不好：不要写关于一条坏狗的故事，除非它友好、悲伤，但又不能太悲伤，并且故事要长，但又不能太长。狗的名字可以是Bob，也可以是Susan，无所谓。也可以写关于猫的故事，但这不重要，最重要的是要让狗毛茸茸的。
- 好：写一个短篇故事（200-300字），关于一只名叫Buddy的忠诚金毛猎犬，它在一次家庭露营旅行中在树林里迷路了。故事应该聚焦Buddy的旅程以及它努力回到家人身边的决心。
给定系统指令中的指令是否过多？ 我们注意到，提示中的指令数量与模型能够忠实遵循所有指令的能力之间存在反比关系。尽管在很多情况下，模型能够很好地遵循一长串指令。这只是一个经验法则，它也适用于为人类编写指令。基本上，如果可以的话，最好将任务分解成子任务。由于这很大程度上取决于所使用的模型，因此很难给出具体的好/坏示例来说明这一点，但以下是我们想要表达的意思：
- 不好：阅读每篇文章，并对每个关键概念按照1-10分的重要性进行评分。然后，将所有得分高于7分的概念总结成中文社交媒体帖子的形式。
- 好：将任务分解成多个子任务，并分别调用AI模型（以下内容并非提供给模型的实际提示）。 1）将文章分解成关键概念列表。2）对每个概念的重要性进行1-10分评分。3）将得分最高的几个概念翻译成中文。4）将中文文本转换成社交媒体帖子的形式。
使用肯定的指令而不是否定的指令。 下面的“不好”示例说明了模型不应该做什么，但没有说明模型应该做什么。“好”示例则明确地列出了模型应该做什么。这与我们在教师培训或夫妻关系咨询等场景中学习到的有效人际沟通原则类似。我们应该尝试与那些想要满足我们需求的人进行沟通。我们需要明确地告诉他们“成功”意味着什么，而不是告诉他们如何“避免失败”。
- 不好：“不要以句号结束你的回复。”
- 好：“你的回复应该始终以感叹号或问号结束”。
好的系统指令可以作为模型的“提示”。 在迭代新提示时，务必考虑各种各样的输入示例。我们经常看到人们编写的提示可能适用于大约60-70%的模型输入，但对于其余30-40%的输入则不明确或含糊不清。通常，为模型提供明确的指导，说明它在这些情况下应该如何处理，是非常有益的。我们经常在系统指令中添加一个名为“补充说明”或“补充假设”的部分，其中包含针对这些边缘情况的详细说明。
提示是新的超参数，你可能永远也找不到“最佳”提示。 例如，正确调整学习率可以显著影响模型在特定计算资源下对验证集的最终性能。同样，好的提示和坏的提示之间也可能存在显著的性能差异。而且，通过进一步的调整，可能总是可以找到“稍微好一点”的提示。我们永远无法确定是否找到了“最佳”提示。正如下面将要讨论的，我们可以利用与深度学习调优手册中类似的直觉来系统地找到比当前基线“更好”的提示。该手册在讨论超参数搜索时提到了“试验预算”。对于提示调整，为实验设定一个时间限制可能非常有用。
尝试明确指示模型何时应该回答“我不知道”。 例如，假设我们正在处理一个多类别文本分类任务。我们有一些用于将输入示例映射到每个类别的标准。创建一个额外的“未知”或“边缘情况”类别可能非常有帮助。并明确指示模型，如果它认为指令不明确，无法将示例正确分类到现有类别中，则应将其分类到这个“未知”类别。然后，我们可以查看日志，了解这种情况何时/如何发生，并相应地改进提示。
提示与其所针对的模型检查点密切相关。 也就是说，如果我们将针对Gemini 1.5 Flash设计的提示用于Gemini 1.0 Pro，它可能不会以“相同的方式”工作，并且在评估中可能表现出截然不同的行为。这是可以理解的。我们的认知模型是，我们用自然语言编写的提示类似于我们使用随机梯度下降（SGD）训练的参数。这在多大程度上是正确的，是一个开放的研究问题。模型类似于机器，后训练过程类似于编译器，系统指令类似于计算机代码。不同之处在于，机器和编译器是不断变化的，而一个给定的模型可以包含许多不同的组合。我们预计，生态系统将逐渐在指令的结构方面达成共识，而这种共识会随着时间的推移而迅速变化，并在组合爆炸式增长的方式下保持合理的向后兼容性。这类似于x86指令集随着时间的推移保持相对稳定，而构建在其之上的编程语言却种类繁多。

提示基本风格指南

目前，我们认为，在先进模型上执行的精心调整的提示足以满足许多原本需要定制训练模型的机器学习工作负载。

随着推理成本、延迟、上下文窗口大小等因素的不断改进，提示将变得越来越普及。编程语言的风格指南的出现是因为人们认识到软件代码主要是写给其他软件工程师看的，其目的是为了方便维护等等。我们还不确定提示的风格指南会是什么样子。但这其中有很多可能性。包含提示的Markdown文件最终可能会被版本控制系统视为一种具有特定文件扩展名的独立“语言”。或者，编程语言最终可能会以更“透明”的方式集成模型推理。现在下定论还为时过早！

我们在这里并没有提供完整的风格指南。但我们想分享以下几点观察：

考虑使用Markdown： 大多数版本控制系统都支持渲染Markdown文件。因此，将每个提示存储在一个单独的Markdown文件中可能很有用。并合理使用Markdown标题等元素来组织每个提示的内容。
为他人着想！ 我们鼓励你将保存的提示视为主要写给其他维护人员看的，而不仅仅是LLM。随着模型的改进，我们希望可以减少在特殊技巧上花费的精力，让模型更好地理解我们的意图。如上所述，这也自然会导致更好的提示。
简洁性： 提示的“技术债”与其长度和复杂性成正比。提示与特定的模型检查点密切相关。每当底层模型发生变化时，都应该对提示进行定量和定性的检查，以确保其仍然有效。保持提示尽可能简单、简洁、直接非常重要。让模型的隐式假设“免费”地为你服务。如果简单的提示就能达到目的，就不要添加不必要的细节。这基于一个假设，即执行提示的底层模型不会在没有充分理由的情况下与提示分离。当然，我们无法保证模型会对不同的输入示例做出相同的隐式假设。随着提示的部署变得更加“严肃”，实施更严格的定量评估变得至关重要。
优先使用零样本指令，而不是少样本指令： 这也符合简洁性的原则。零样本指令更容易理解、调试和推理。少样本示例，尤其包含完整对话的示例，最适合用于我们的明确指令无法充分表达我们意图的情况。我们已经观察到，在很多情况下，少样本提示的效果不如零样本提示。我们不应该想当然地认为少样本提示会更好，而应该进行实证研究。我们建议将少样本示例作为最后的手段，因为它们会显著降低提示的可读性。
- 始终以略带“阴阳怪气”的语气开始回复用户。例如，以类似“哦，这就是你想要的？我不是说你错了，但我的意思是，当然，如果你真的想要这样”的语气开头。但要保持新鲜感，并根据用户消息的内容，在每个回复中使用不同的开头。
- 不要使用完整的少样本示例，而是将示例融入指令的描述中。参考以下在指令末尾使用“例如”的系统指令：

迭代新系统指令的流程

提示调整本质上是一个迭代过程。它与使用验证集训练模型非常相似，只不过不需要使用JAX等工具，而是通过编写清晰的文本来完成。

与写作类似，我们发现最好将工作分解成生成和编辑两个阶段。

我们发现，大多数尝试提示模型的用户并没有一个现成的、清晰的验证集来评估模型的回复质量。这对于快速构建最小可行产品（MVP）是可以接受的。但最终，正式的定量评估对于跟踪模型性能至关重要。即使是最佳的提示和模型组合，也无法完全确定地保证模型的行为。设计能够在底层模型出现意外行为时优雅退出的产品至关重要。

像AI Studio这样的工具对于迭代新的系统指令非常有价值。

从一小部分具有代表性的输入示例开始，并对期望的输出结果有一些初步的理解。这可以是大约10-50个示例。
从满足所有输入示例的最简单的系统指令开始，并在最小、最便宜的可用模型（目前可能是Gemini Flash 8B）上进行测试。
- “最简单”指的是真正意义上的最简单。在不损失清晰度的前提下，使其尽可能简洁。
在第一个输入示例上运行系统指令。
尝试对第一个示例进行“过拟合”。
- 也就是说，向原始系统指令添加“提示”，直到模型能够可靠地生成“足够好”的回复。“提示”指的是对模型的具体指导。找出模型对原始系统指令回复中的任何缺陷，并添加指令来纠正这些缺陷。一次添加一条指令。例如，假设原始指令要求模型从输入字符串中提取所有命名实体。我们发现它还会提取建筑物、地点等的名称，而我们的目标是只提取人名。我们可以修改原始指令来反映这一点。
- 如果模型无法为第一个输入提示生成足够好的回复，请尝试第二个输入提示。如果模型在我们的大多数输入示例中持续失败，请返回步骤2，并尝试更强大的模型。例如，如果我们开始使用的是Flash，可以尝试Pro。
一旦我们能够成功地对第一个示例进行过拟合，请尝试下一个输入示例。
- 此时，我们可能会发现某些指令对第一个示例过度拟合。它们可能需要更细致的描述。例如，它们可能需要明确的指令来澄清一些未指定的规范，或者需要添加一些条件语句。
- 重复此过程，直到我们找到一个对所有输入示例都有效的系统指令。
在此过程中，我们可能会为了使系统指令适用于所有输入示例而随意修改其措辞。现在是时候清理这些措辞了。例如，添加章节标题、修正拼写错误等。完成后，验证指令在所有输入示例中仍然有效。如果无效，请使用上述过程进行系统地调试。但不要使用步骤2中的MVP系统指令作为基础，而应使用清理后的版本。
- 相对于其性能，维护这个提示的重要性如何？
- 我们是否对生产环境中模型的行为进行监控？这个部署是否重要到需要进行监控？
- 在某些模型上，“杂乱”的提示可能比“干净”的提示效果更好，这种情况并不罕见。这引出了一些问题：
也许有一天，从输入示例生成系统指令的整个过程可以通过一个元优化器自动完成。这将是一项了不起的成就，但我们不应该抱有不切实际的幻想！天下没有免费的午餐。在使用机器学习系统时，总会有一些参数需要调整。为了确保模型的相关性认知（即“知识框架”）与我们作为开发人员在特定数据集上的认知一致，总会有一些定性的工作要做。我们永远无法避免进行艰苦的定性分析工作，就像我们永远无法避免培训新团队成员一样。提高工具的抽象程度只会将定性工作的重点和精力转移到不同的抽象层级。但这并不意味着这些工具没有用！

重要

我们永远无法避免进行艰苦的定性分析工作，就像我们永远无法避免培训新团队成员一样。

关于大型语言模型（LLM）何时有用的几点思考

我们已经花了大量篇幅讨论如何理解提示。现在，我们来谈谈“为什么”LLM可能有用。尽管这个领域还处于起步阶段，并且正在快速发展，因此本节内容可能很快就会过时。

LLM最适合用于答案难以生成但易于验证的任务。我们推荐Chris Gorgolewski的这篇文章。根据我们的经验，如果将LLM用于不符合这种情况的任务，就会遇到问题。

与其编写难以理解和调试的单一复杂提示，不如将问题分解成子问题，并将推理过程链接起来。如果我们将每个子问题设计得足够小，它们通常会更容易定义和评估。

在硬件、商业模式等方面可能会有重大创新，从而进一步释放推理能力。我们应该关注未来的发展方向，而不是仅仅关注现状。

假设推理成本很快会“低到可以忽略不计”、“足够好”或以“价值”而不是“成本”为导向，这似乎更具前瞻性。也就是说，如果我们需要在更有价值但需要更多推理调用的功能和价值较低但成本较低的功能之间做出权衡，那么优先考虑前者似乎更具前瞻性。也许可以通过限制部署规模等方式来应对当前的单位经济效益问题。我们预计LLM推理成本的下降速度可能会类似于摩尔定律。

致谢

感谢Slav Petrov和Sian Gooding在最终审查阶段对本文档的审阅。
感谢Anna Bortsova在文档最终版本起草过程中提供的宝贵意见和反馈。
感谢Jennimaria Palomaki、James Wexler和Vera Axelrod提出的许多有益的编辑建议。

迭代新系统指令的流程：精简版解释

这个流程的目标是通过不断尝试和改进，找到一套高效的指令，让大型语言模型（LLM）按照你的预期生成输出。它类似于用验证集训练模型，只不过调整的是指令而不是模型参数。

核心思想：从简单开始，逐步精细化，并不断验证。

准备多样化输入示例: 选择 10-50 个能够代表你的目标任务的各种情况的输入示例（即提示），并对每个示例的期望输出心中有数。
从最简单的指令开始: 使用最简洁、最直接的指令，在能力相对较弱、成本较低的 LLM（例如 Gemini Flash 8B）上进行测试。
逐个过拟合示例: 先专注于第一个示例，不断修改和补充指令，直到模型在这个示例上能够生成令人满意的输出。这个过程就是在“过拟合”单个示例。
泛化到其他示例: 将调整后的指令应用于下一个示例，如果效果不理想，则继续修改指令，使其同时满足当前示例和之前的示例。重复这个过程，直到指令能够在所有示例上都表现良好。
清理指令: 在前面的步骤中，你可能为了让指令在所有示例上都work而进行了各种修改，导致指令变得冗长或混乱。现在需要清理指令，使其更简洁、更易于理解和维护，例如添加标题、修正拼写错误等。清理后，务必再次验证指令在所有示例上的有效性。
持续监控和优化: 即使找到了有效的指令，也需要持续监控模型在实际应用中的表现，并根据需要进行调整和优化。因为 LLM 的行为不是完全确定的，需要不断根据实际情况进行微调。

关键点:

迭代: 这个过程是迭代进行的，需要不断尝试、调整和验证。
简洁性: 保持指令简洁明了，避免不必要的复杂性。
多样性: 使用多样化的输入示例，确保指令的泛化能力。
验证: 不断验证指令的有效性，尤其是在修改指令或更换模型后。

这个流程的核心在于理解你的目标，并通过不断尝试和改进找到最有效的指令来引导 LLM 实现你的目标。记住，没有完美的指令，只有不断优化的指令。

迭代新系统指令流程：完整示例

假设我们的目标是让 LLM 能够从一段文本中提取出所有的人名。

1. 准备多样化输入示例 (10-50 个):

以下列出几个示例，并标注期望的输出：

示例 1: “小明和李华一起去公园玩，遇到了他们的朋友王老师。” 期望输出：小明，李华，王老师
示例 2: “美国总统拜登与英国首相苏纳克举行了会谈。” 期望输出：拜登，苏纳克
示例 3: “公司最近招聘了三位新员工：张三、软件工程师；李四，数据分析师；王五，产品经理。” 期望输出：张三，李四，王五
示例 4: “这篇文章主要介绍了孔子和亚里士多德的哲学思想。” 期望输出：孔子，亚里士多德
示例 5: “小说中的人物有孙悟空、猪八戒和沙和尚。” 期望输出：孙悟空，猪八戒，沙和尚

2. 从最简单的指令开始:

初始指令：“提取出文本中所有的人名。” // 备注：尽可能简洁

3. 逐个过拟合示例:

针对示例 1: 使用初始指令，模型可能正确提取出 “小明，李华，王老师”。// 备注：如果初始指令就work，则直接进入下一示例
针对示例 2: 模型可能提取出 “拜登，苏纳克，美国总统，英国首相”。// 备注：出现了非人名的实体
- 修改指令：“提取出文本中所有的人名，不要包含职位、头衔等。” // 备注：针对问题进行修正
- 再次测试示例 2，模型现在应该可以正确提取。
针对示例 3: 模型可能提取出 “张三，李四，王五，软件工程师，数据分析师，产品经理”。// 备注：指令仍然不够精确
- 修改指令：“提取出文本中所有的人名。即使人名后面跟着职业或职位，也只提取人名。” // 备注：进一步细化指令
- 再次测试示例 3，模型现在应该可以正确提取。// 备注：再次验证修改后的效果
针对示例 4 和 5: 模型应该都能正确提取人名。// 备注：检查指令在其他示例上的泛化能力

4. 泛化到其他示例: (假设我们有更多示例)

在这个阶段，我们会用更多的示例来测试指令，如果遇到新的问题，就需要再次修改指令，并重新测试所有之前的示例，确保修改不会影响之前的效果。

5. 清理指令:

最终指令：“从给定文本中提取所有的人名。即使人名后紧跟着职业、职位或其他描述性信息，也只提取人名，不要包含任何头衔、称号或其他非人名实体。” // 备注：最终指令清晰、完整、明确

6. 持续监控和优化:

将最终指令部署到实际应用中后，需要持续监控模型的表现。例如，收集一些模型提取错误的案例，分析错误原因，并根据需要调整指令或更换更强大的模型。

总结:

这个例子展示了如何通过迭代的流程来优化系统指令。每个步骤的关键在于：

理解问题: 明确模型在当前指令下的不足之处。
** targeted 修改:** 针对问题进行具体的指令修改。
** thorough 验证:** 每次修改后，都要在所有示例上进行测试，确保不会引入新的问题或破坏之前的效果。

通过这个流程，我们可以逐步提高 LLM 的性能，使其更符合我们的预期。

👨‍🎓我：这个过程感觉会非常繁琐，工作量比较大，还有一个问题是，应该怎么设计多样性的示例，而避免遗漏测试出大模型有可能出现的不理想的结果呢？

🤖Gemini：你的担忧很有道理，迭代优化 LLM 系统指令的确可能是一个繁琐且工作量大的过程，尤其是在设计多样化示例方面，如何确保覆盖所有潜在问题是一个挑战。以下是一些策略，可以帮助你更有效地设计多样化示例，并减少遗漏潜在问题的风险：

1. 基于用户需求和应用场景:

明确目标用户和使用场景: 你的 LLM 最终是为谁服务的？他们会在什么场景下使用？例如，如果你的 LLM 是用于客服机器人，那么你的示例就应该涵盖各种客户可能提出的问题和请求。
分析潜在的输入类型: 用户可能会输入哪些类型的文本？例如，正式的邮件、非正式的聊天消息、代码片段、诗歌等等。你的示例应该包含所有这些不同的输入类型。
考虑边缘情况: 用户可能会输入哪些不寻常或错误的文本？例如，拼写错误、语法错误、含糊不清的表达、带有攻击性的语言等等。这些边缘情况也需要在示例中有所体现。

2. 采用结构化的方法:

等价类划分: 将所有可能的输入分成不同的类别，每个类别内的输入应该具有相似的特征，并且对模型的输出产生类似的影响。然后，从每个类别中选择一些具有代表性的示例。例如，在人名提取的例子中，可以根据人名的长度、人名中是否包含特殊字符、人名是否与其他实体混淆等特征进行等价类划分。
边界值分析: 关注输入的边界值，例如最大长度、最小长度、特殊字符的限制等等。这些边界值通常更容易出现问题。
组合测试: 将不同的输入参数组合起来进行测试，可以发现一些单独测试无法发现的问题。例如，将不同长度的人名与不同的职业组合起来，测试模型是否仍然能够正确提取人名。

3. 利用现有资源:

公开数据集: 许多公开数据集可以用于测试 LLM 的性能，例如 GLUE、SuperGLUE 等等。这些数据集通常包含各种不同类型的文本和任务，可以帮助你快速评估 LLM 的泛化能力。
用户日志: 如果你已经有了一个 LLM 应用，那么用户的实际输入可以作为非常宝贵的测试数据。分析用户日志可以发现一些你没有预料到的问题。
错误案例: 收集模型生成错误输出的案例，并将其添加到你的示例库中。这可以帮助你不断改进指令，并提高模型的准确性。

4. 自动化测试:

单元测试: 将每个指令都视为一个单元，并编写相应的单元测试来验证其功能。
集成测试: 将多个指令组合起来进行测试，验证它们之间的协作是否正常。
回归测试: 每当修改指令或更换模型后，都要重新运行所有测试用例，确保新的修改不会引入新的问题或破坏之前的功能。

5. 其他建议:

逐步增加示例的复杂性: 先从简单的示例开始，逐步增加示例的复杂性和难度。
优先考虑高风险场景: 将更多精力放在那些对用户体验或应用安全至关重要的场景上。
不要追求完美: 不可能设计出覆盖所有情况的完美示例集。重点是找到那些最具有代表性和最容易出现问题的示例。

虽然这个过程仍然需要一定的工作量，但通过采用这些策略，可以更有效地设计多样化示例，并提高测试的覆盖率，从而减少 LLM 在实际应用中出现问题的风险。记住，这是一个持续学习和改进的过程，随着你对 LLM 和应用场景的理解不断加深，你的测试策略也会不断完善。

提示词优化策略

策略	说明	示例
明确用户需求和应用场景	确定目标用户和使用场景，分析潜在的输入类型，考虑边缘情况。	用户：科研人员；场景：论文写作；输入：科研数据、文献综述；边缘情况：复杂的专业术语、罕见的研究方向
采用结构化方法设计多样化示例	使用等价类划分、边界值分析、组合测试等方法，系统地设计测试用例。	等价类：不同长度的文本、不同领域的文本；边界值：极长和极短的文本；组合测试：不同长度和不同领域的文本组合
利用现有资源	使用公开数据集、用户日志、错误案例等资源，作为测试数据。	公开数据集：GLUE；用户日志：用户提交的提示词和模型的回复；错误案例：模型生成不理想输出的例子
自动化测试	编写单元测试、集成测试、回归测试等自动化测试用例，提高测试效率。	单元测试：测试单个指令的功能；集成测试：测试多个指令的组合；回归测试：在修改指令或更换模型后，重新运行所有测试用例
逐步增加示例复杂性	先从简单的示例开始，逐步增加示例的复杂性和难度。	简单示例：“总结一下这篇文章。” 复杂示例：“用简洁的语言，面向非专业人士，总结一下这篇文章的主要发现和局限性，并提出未来研究方向。”
优先考虑高风险场景	将更多精力放在那些对用户体验或应用安全至关重要的场景上。	高风险场景：涉及敏感信息、可能产生误导性内容的场景
从最简单的指令开始	使用最简洁、最直接的指令，在能力相对较弱、成本较低的 LLM 上进行测试。	初始指令：“总结一下这篇文章。” 避免一开始就使用过于复杂或冗长的指令。
逐个过拟合示例，逐步精细化指令	先专注于单个示例，不断修改和补充指令，直到模型在这个示例上能够生成令人满意的输出。然后再泛化到其他示例，并不断调整指令。	如果模型在示例 “美国总统拜登与英国首相苏纳克举行了会谈。” 中提取出 “美国” 和 “英国”，则需要修改指令，使其只提取人名。
不要追求完美	不可能设计出覆盖所有情况的完美示例集。重点是找到那些最具有代表性和最容易出现问题的示例，并进行持续的监控和优化。	重点关注核心功能和常见场景，不必过于追求覆盖所有边缘情况。
清晰、简洁、明确的指令	使用清晰、简洁、明确的语言编写指令，避免歧义和冗余。	好的指令：“用一句话总结这篇文章的主要内容。” 不好的指令：“尽可能用最少的字数，但要保证完整性和准确性，总结一下这篇文章的核心思想，不要包含不重要的细节。”

让 AI 更听话的秘诀：提示词优化策略 (小学生也能看懂版)

想象一下，你正在教你的 AI 小助手学习新技能，就像教小狗新 tricks 一样。你需要用清晰、简单的指令告诉它你想让它做什么。这个表格就是教你如何把指令写得更好，让 AI 更听话！


秘诀 (策略)	解释	例子：我想让 AI 从故事里找出所有的人名	小狗训练类比	检查方法 (测试)	检查结果示例及说明
了解 AI 的任务和使用场景	就像你教小狗 tricks 前，要先想好你想让它做什么，在什么情况下做。	任务：从故事里找出人名；场景：阅读理解、信息提取	我想训练小狗坐下，是在客人来家里的时候，而不是在它玩玩具的时候。	自己测试: 准备好不同类型的测试故事，看看 AI 表现如何。	测试故事：“小红帽去看奶奶，遇到了大灰狼。” AI 找出：“小红帽，奶奶，大灰狼” 说明：AI 正确地找出了人名。
准备各种各样的故事	就像你训练小狗，要用不同的口令、不同的场景来练习，AI 也需要各种各样的故事来学习。	故事1：小明和小红去上学；故事2：超人拯救了世界；故事3：小猫钓鱼的故事。	训练小狗坐下，要在不同的地点，比如客厅、花园，都要练习。	各种故事测试: 确保 AI 在不同类型的故事里都能找出人名。	测试故事：“从前有座山，山里有座庙…” AI 找出：无。说明：故事里没有人名，AI 的结果是正确的。
检查故事的边界	测试一些特殊情况，看看 AI 能不能处理。	故事：名字超长的人和名字很短的人的故事。	测试小狗坐下，用很小声的口令，和很大的声音，看看它是不是都能听懂。	边界测试: 用一些特殊的故事（例如名字很长很奇怪的故事）来测试 AI。	测试故事：“阿斯蒂芬妮娅·冯·奥古斯都和李二狗是好朋友。” AI 找出：“阿斯蒂芬妮娅·冯·奥古斯都”，“李二狗”。说明：即使名字很长很奇怪，AI 也能正确识别。
故事组合测试	把不同类型的测试故事组合起来，看看 AI 会不会 confused。	故事：结合了童话、科幻、现实生活三种元素的故事。	同时训练小狗坐下和握手，看看它是不是能分清楚。	组合测试: 用混合了不同元素的故事来测试 AI。	测试故事：“钢铁侠和小红帽一起去火星拜访了玉皇大帝。” AI 找出：“钢铁侠，小红帽，玉皇大帝” 说明：AI 能在复杂的故事背景下正确提取人名。
使用现成的故事库	就像你可以用现成的狗狗训练手册，也可以用现成的故事库来测试 AI。	使用一些儿童故事网站上的故事。	用宠物店提供的狗狗训练视频来学习训练方法。	公开故事测试: 使用现有的故事数据集来测试 AI 的性能。	使用安徒生童话故事集测试，检查 AI 是否能准确提取出所有人名。
记录 AI 的错误	把 AI 犯的错误记录下来，帮助它改进。	记录 AI 漏掉的人名或错误提取的名字。	记录小狗没有正确完成 tricks 的时候，下次训练重点纠正。	错误记录与分析: 记录 AI 提取错误的例子，分析错误原因，并改进指令。	AI 将“白雪公主的七个小矮人”识别为人名，需要改进指令，避免提取此类描述性短语。
从简单的指令开始教 AI	先用最简单的指令，然后慢慢教更复杂的。	先教 AI 提取简单故事里的人名。	先教小狗简单的坐下，再教它握手、装死。	简单指令测试: 使用最简单的指令测试 AI 的基本功能。	指令：“找出人名。” 测试 AI 是否能理解这个简单的指令。
针对问题改进指令	如果 AI 理解错了，就修改指令，让它更容易理解。	如果 AI 把地名也提取出来了，就告诉它只要人名。	如果小狗坐下时，屁股歪了，就调整指令和训练方法。	改进指令测试: 每次修改指令后，都要重新测试，确保改进有效。	修改后的指令：“只找出人名，不要找出地名。” 重新测试之前的示例，检查 AI 是否能正确区分人名和地名。
不断练习和改进	就像训练小狗一样，需要不断练习和改进，AI 才会越来越聪明！	不断测试和修改指令，直到 AI 表现 satisfactory。	坚持训练小狗，它才会越来越听话！	持续测试和优化: 不断测试和改进指令，提高 AI 的准确性和可靠性。	持续监控 AI 的表现，收集错误案例，并不断改进指令，使 AI 越来越“听话”。