李玉光
北京聚云科技有限公司
联合创始人兼首席架构师
拥有 12 年以上的 Amazon Web Services 开发与架构经验。擅长设计和实施大规模、高弹性、自动化的云原生解决方案。云成本优化方面经验丰富，帮助众多企业有效降低云使用成本。并协助各类行业客户利用 Amazon Web Services 平台部署和优化 GenAI 应用，显著提升企业的生产力与创新能力。
提示词工程（Prompt Engineering）是与大语言模型（LLM）交互的主要方式，激发模型潜能、实现复杂任务。那么，究竟什么是提示词工程？它的发展历程、设计原则和未来趋势又是怎样的？Anthropic 的几位提示词工程专家在 Youtube 上分享了他们的经验与见解，包括 Amanda Askell（对齐微调）、Alex Albert（开发者关系）、David Hershey（AI 应用落地）以及 Zack Witten（提示词工程）。本文基于他们的讨论，整理了相关内容，为读者呈现提示词工程的核心理念与实践方法。
www.youtube.com/watch?v=T9a...
亚马逊云科技开发者社区为开发者们提供全球的开发技术资源。这里有技术文档、开发案例、技术专栏、培训视频、活动与竞赛等。帮助中国开发者对接世界最前沿技术，观点，和项目，并将中国优秀开发者或技术推荐给全球云社区。如果你还没有关注/收藏，看到这里请一定不要匆匆划过，点这里让它成为你的技术宝库！
什么是提示词工程？
提示词工程是一种与大模型交互以完成特定任务的过程，最大限度地激发模型潜力，实现普通方法难以达成的目标。这在很大程度上是一种与模型沟通的艺术，通过与模型"对话"来引导它完成预期目标。 其核心在于清晰、准确地传达需求，就像和人进行沟通，你需要了解模型的"心理"或运行逻辑才能更有效地协作。
之所以称其为"工程"，在于提示词的设计需要不断试错和迭代。 和与人交流不同的是，和模型的交互允许我们随时"重置"，从头尝试不同的提示词，而不会受到先前的输入的影响。这种反复测试迭代的过程，正是提示词工程的核心。
提示词工程还涉及将提示词有效地整合进整个应用系统中，这远不止将编写的提示词交给模型那么简单，需要整合与调优以便提示词能够在系统中真正发挥作用，这让提示词工程成为一个全面而系统化的过程。
提示词在某种程度上有点像自然语言代码，但要避免过度抽象提示词设计，而是直接、清晰地描述任务。此外，通过版本控制和管理来追踪每次实验结果在提示词工程中和代码管理同样重要。如今，提示词工程正处于一种新的范式中，将提示词的文字描述视作一种指令集，与代码一样对待。
在此基础上，我们已经初步定义了什么是提示词工程。
什么是优秀的提示词工程师？
优秀的提示词工程师需要具备清晰沟通的能力。 这意味着能够明确地表达想法、并清晰地描述概念。从某些方面来讲写作技巧确实重要，但其实比很多人想象的关联性要低。提示词工程师的工作并非仅仅是撰写单一的指令然后交给模型，实际上在和模型的互动中，我们需要进行大量的反复试验和调整，有时在短短 15 分钟内就要向模型发送数百条提示词，这种频繁的迭代过程是提示词工程师工作的重要组成部分。
除此之外，提示词工程还需要考虑到各种边缘场景。 假设有一个提示词要应用到 400 个不同的案例中，一个经典的误区是只关注典型案例是否得到正确答案，以此来判断提示词是否合格，而真正有效的提示词设计需要考虑到各种不常见的情况。例如，如果用户的输入内容是"我会发送一批数据，希望你提取出所有名字以字母 G 开头的行。"这时，你需要思考不同的可能性，比如数据集中没有符合条件的名字、或者数据不符合要求的格式、甚至可能是一个空字符串。这些特殊情况都需要测试进而确保提示词能够正确的处理，比如告诉模型"如果遇到不明确的情况，直接输出 'unsure' 标签"，那么你就可以确保模型在遇到异常输入时不会做出奇怪的反应，并且轻松找到那些异常或出错的样本，从而有针对性的优化提示词。
在很多情况下，工程师在评估模型表现时，会使用一些理想化的示例输入，格式优美、结构清晰。但现实情况需要进一步考虑到真实用户的输入特点，比如大多数用户在输入时隔几个词就有一个拼写错误、句子里几乎没有标点、甚至只是随意拼凑的几个词，就像在使用 Google 搜索，这是一个更高层次的设计考量。
另一个关键点在于仔细审视模型的响应。这意味着要反复阅读和分析模型的输出结果，理解其中的细节。举个例子，有些人会在提示词中加入"逐步思考"的指令，但往往并没有验证模型是否真的按照步骤进行推理。模型可能将这个指令理解为一种抽象的、笼统的提示，而不是按照要求记录思维过程。若不认真查看输出结果，很可能无法察觉模型在执行中的偏差。
大模型的输出不仅限于对与错的判断，而是包含了大量的文字内容和表达细节。通过分析这些输出中的细微之处，可以更深入地了解模型的"思维过程"： 它是如何完成任务的，经历了哪些步骤等等。这不仅是判断任务完成情况的问题，模型的输出不仅告诉我们最终结果，还透露出它是如何到达这个结果的。这些细节能帮助我们更好地理解模型的行为，甚至可以用来推测模型的内部逻辑。
作为一名提示词工程师，必须设身处地的去思考模型将如何理解你的指令。 而且，在为企业应用场景设计提示词时，还必须考虑用户与模型互动的方式。此时，提示词工程师就像是模型与用户之间的桥梁，平衡双方对任务的需求和理解，这种"第三方"视角在企业级提示词设计中显得尤为重要。
最后，在提示词工程中，最具挑战的部分之一是如何清晰地描述任务，我们的大脑中往往会有很多"理所当然"的假设，而 Claude 并不了解这些假设。如何剥离这些隐含的信息和预设，把任务所需的完整信息传达给模型是一项极具挑战的事情。 这也是优秀的提示词工程师和普通提示词工程师的显著差异之一。
如何优化提示词？
现有模型在遇到模糊指令时，往往无法像人类那样主动提出问题来澄清疑惑。例如，我们在给某人讲解任务内容时，对方可能会直接指出："这部分不太清楚，我这里该做什么？"然而，模型不会这样主动询问，它只会根据提示词中的信息来执行。 因此，提示词工程师在编写提示词时需要模拟这种"自我问答"的过程，主动预判模型可能的困惑之处。就像与人沟通一样，你需要站在对方的立场来思考：如果模型是一个人，它在理解这个提示时会有哪些疑问？然后回到提示词，对这些潜在问题逐一进行补充说明。
你也可以将提示词交给模型并告诉它："我不需要你执行这些指令，只需要告诉我其中是否有不清楚的地方，或任何模糊、难以理解的部分。"虽然模型并不总是完全准确，但这种方法确实提供了一个有趣的反馈视角来帮助识别潜在问题。我们还可以让模型自己反思，告诉它："你在这里出错了，能否思考一下原因？并尝试修改我的提示词，以避免类似错误？"大多数情况下，模型能很好地指出问题所在，甚至给出改进建议。
每次与模型的反复交互都能带来新的见解，让你更深入地理解模型的工作方式。如果不尝试与模型互动反馈，就错失了学习的机会。这种尝试虽然不一定每次都能获得完美的结果，但却能不断积累有价值的信息。
改进提示词的另一个可行的方法是先用口头描述一下任务，因为在口头表达时往往更加清晰流畅，接下来将这些描述录音转录成文字，然后直接粘贴到提示词窗口中。这样做的效果通常比最初编写的提示词要好得多。因为很多人在写提示词时会不自觉地简化内容，导致提示不够完整和清晰。而口头描述可以帮助我们更自然地把任务说清楚，反而更符合模型的理解方式。
我们应该重视提示词设计，因为提示词的微小调整可能带来显著的性能差异。如果一个人花大量时间优化实验代码，却没有花心思在提示词上，结果可能会大打折扣。
如何判断任务是否超出"提示词"的能力范围？
提示词优化有些像一把双刃剑。总感觉下一个"更好的提示词"就在前方，可以解决所有问题，这让许多人陷入不断调整的循环中。他们坚持不懈地改进提示词，期待找到那个"理想的提示词"。适度打磨提示词确实有助于学习和改进，但提示词工程的挑战在于未知领域的广阔和不可预见性，这也使得追求"完美提示词"变得具有风险和不确定性。
那么如何确认某个任务是否能通过调整提示词实现呢?
首先是观察模型是否"理解"任务的实质。对于一些提示词效果没有明显提升的任务，可能需要进行一些尝试，但很快就能判断出它是否可行。通常，如果模型在初始响应中明显不接近目标，则不需要花太多时间继续打磨提示词。
在处理某些任务时，可以通过与模型互动来探究它的思维方式，甚至直接询问它是如何理解任务的。 这种方法能帮助我们判断模型是否掌握了任务的核心，以及它离正确答案有多远。通过不断调整提示词，通常能感觉到是否在逐步接近理想的输出。但也有一些任务，无论怎么微调，模型的响应始终朝着错误的方向偏离。在这种情况下，通常建议放弃继续优化，因为所有的尝试都未能有效引导模型朝正确的方向前进。
比如，工程师做了一个实验，尝试把 Claude 连接到 Game Boy 模拟器上，试图让它操控按键完成游戏。Claude 确实能生成一些按键指令的代码，但一旦进入一些复杂的场景，模型的表现就开始下降了。比如，当它需要根据游戏的的屏幕截图来理解游戏状态时，效果就非常差。整个周末，工程师都在反复修改提示词，希望 Claude 能更好地"理解"这个屏幕信息。虽然有些微小的进步，让模型从"完全无反应"提升到"有些许反馈"，但依然离目标还差得很远，最后决定放弃了。在这种情况下，等待下一代更强大的模型或许才是更好的选择，而不是在一个当前技术还无法实现的目标上消耗更多的时间。
之前我们很习惯为模型提供文本提示，但发现当涉及图像时，所需的提示信息和描述方式要复杂得多，直觉上也有所不同。在文本方面的许多直觉并不适用于图像。 比如，多示例提示（multi-shot prompting）在图像任务中并不如文本任务中有效。虽然可以从理论上推测原因，或许是因为训练数据中包含的示例图像或图文示例较少，但无论如何，在图像处理上，提示词的效果确实与文本有显著差异。
在多模态提示词中，通过提示词显著提升 Claude 对图像细节的识别能力几乎不可行。 无论如何调整提示词的内容，模型在图像中捕捉细节的能力似乎并没有明显提高。比如，在前面的游戏实验中，尽管尝试了多种提示方法，模型始终难以识别图像中特定位置的角色，无论如何优化提示也无法让它"看到"那些特定的细节。这种情况表明，在图像理解方面，提示词的优化空间可能受到固有的局限。
是否要赋予模型特定角色？
在提示词中使用角色设定、比喻或者"赋予模型某种身份"的策略是提示工程中常见的技巧。然而，这种方法似乎在早期模型中效果更显著，而在当前模型中效果有所下降。随着模型能力的提升，它们对世界的理解也逐渐加深，已经没必要通过"虚构情境"来引导它们完成任务了。 比如，我们的目标是构建模型的评估数据集，这与为儿童设计测验是完全不同的任务。但有时有人会用类似"我是老师，正在为测验设计问题"这样的情境来提示模型，但实际上，模型知道什么是语言模型评估，它甚至可以提供一些示例，因为这些内容在网络上很常见。
在这种情况下，建议直接告诉模型真实任务，比如"我需要你构建一组语言模型评估题目"。这种方式反而更加清晰明了。而不是编造一个不相关或仅有间接关联的情境，期望模型能够更好地完成实际任务。人与人之间的沟通也是如此，不会让他们假装成老师去设计题目，而是直接说明我们需要完成的任务。因此，当模型能够理解任务时，更建议倾向于直白、真实地描述目标，这样更有效率。
不过确实有些情况下，通过比喻来帮助模型理解任务会更有效，但这并非"欺骗"模型，而是给它一个更具象的参考框架。 比如，你希望 Claude 判断一张图表的质量高低，这种场景下最终找到的最佳提示词可能是："如果这张图表是高中作业，你会给什么分数？"这并不是让模型扮演"高中老师"的角色，而是用"给作业评分"的比喻来表达期望的分析标准：用类似于老师评分的尺度来判断图表的质量。这种方式能更清楚地传达我们要的分析角度和判断标准，使模型更接近预期。
只是找到恰当的类比并不容易。 人们常用的默认方法是寻找一个相似的角色或任务，例如"你是一位老师"，但这种方法往往会在关键细节上偏离任务本身的需求，尤其是在企业场景中。很多人觉得模型见过更多的"常见任务"（例如高考题），所以会倾向于选择这些角色，认为模型更容易理解。然而，随着模型能力的提升，直接描述实际的任务背景往往效果更好。
比如，你在为某个产品编写客服支持窗口的提示词，直接告诉模型"你正在为这个产品的客服支持窗口编写回复"，甚至进一步说明"你是嵌入在产品内的客服支持模型"，比用"你是个热心的助手"之类的通用角色描述更清晰。这样能够帮助模型更准确地识别任务场景，避免它误解任务。
再比如，你雇了一个能力很强临时工来完成一项任务，他对你的行业也很了解，但并不知道你们公司的具体情况。在这种情境下，你会对他说："我们希望你判断图表的质量。我们所指的'好图表'不需要完美，不用去检查所有细节是否准确。只要标好坐标轴，质量大致达到高中水平就行。"你不会对他说"你现在是一位高中老师"，而是清晰地告诉他具体的期望和标准。
模型的推理过程
一方面，模型拟人化有助于我们模拟其工作方式并产生相对准确的假设。另一方面，在探讨推理本质时，过于拟人化反而可能偏离我们真正关注的目标。
对于"模型是否真的在推理"，这似乎更接近哲学问题，而不是提示词设计的技术核心。从实际效果来看，无论这种所谓的"推理"是否符合我们通常的定义，事实是通过引导和迭代设计提示词，让模型表现出结构化的"推理过程"，通常能带来更好的结果。是否要将这种过程定义为"推理"或其他什么，其实并不重要。就像人类在解复杂数学题时需要写下步骤，如果仅靠一次性思考就很难完成。这个类比可能有助于理解，归根结底，这种方法确实有效才是关键的。
一种测试模型"推理"真实性的方法是，将模型生成的正确答案推理过程替换为看似合理但实际会导致错误答案的推理过程，观察模型是否得出错误答案。事实上，通过清晰的步骤、逻辑框架和示例来引导模型确实会提升模型表现。无论这种过程是否被称为"推理"，但在这个过程中确实存在某种有意义的机制，不管我们用什么词来描述它。
不过，模型的"推理"过程也有奇怪的地方，比如它有时会列出多个推理步骤，其中某一步明显是错误的，但最后却仍然能得出正确的答案。这种现象表明，模型的推理并不完全符合我们对人类逻辑推理的理解，我们很难将其完全拟人化为真正的"推理"，因为其中可能还存在某种不同的机制。
关于提示词的语法与格式：是否必须？
按照格式规范来编写提示词，这么做并没有坏处，但也不是绝对必要的。 更重要的是，你需要具备对细节的关注，这种关注会自然地让你去优化它的格式。如果你经常反复检查自己的提示词，这些小问题自然会被发现，而你也会倾向于修正它们。你应该投入和编写代码同样的心思到提示词中，程序员常常对一些细节有很强的个人偏好，比如用 Tab 还是空格，或者哪种编程语言更好。尽管这些偏好未必有绝对的对错，但培养这种习惯是有益的，即使这些标准有时看似任意，但也能让你在提示词的设计中更精益求精。
有些提示词经常充满了拼写错误或者语法问题。别人看到这些提示词时可能会说："这上面有一堆错误"，但重要的是模型能够理解，提示词在概念上是清晰的就够了。对于最终版本的提示词，肯定需要会去修正这些拼写和语法错误。 但提示词迭代过程中，不必太介意里面是否有拼写错误，因为模型不会因此受到影响。
在此方面，预训练模型与 RLHF 模型有关键区别。如果你将一个充满拼写错误的提示词传递给预训练模型，生成的结果几乎肯定也是充满拼写错误的，而 RLHF 模型已经被"非常严格地训练"不要出现拼写错误。这也反映出 RLHF 模型更像是为"猜测用户期望"而优化的工具。如果用户在输入中大量使用表情符号，模型也会倾向于在输出中加入表情符号。相反，即使用户的输入中带有拼写错误，Claude 通常也能够生成准确且无错误的输出。
企业级提示词&研究型提示词&普通聊天提示词之间的区别
企业级提示词与研究型提示词
企业级提示词和研究型提示词最大的差异可以从示例的数量和提示词设计的目标出发来理解。前者更追求稳定性和可靠性，而后者往往更注重多样性和探索性。
在企业级提示词中通常会加入大量示例，甚至会一直增加示例，直到觉得无力继续。这样做的原因是在生产环境中可靠性尤为重要。 我们更关心输出格式的一致性，甚至希望答案在某些方面保持完全相同，以确保用户体验的一致性。
相比之下，在研究型提示词中不会加入过多的示例，甚至觉得一两个示例都可能会让模型过度依赖这些输入。研究提示词的目标是激发模型的潜力，探索模型的能力范围。虽然加入一些示例可以帮助引导模型，但这实际上也会对模型的探索范围形成一定限制。因此，在研究型提示词中示例的数量往往更少。
这并不是说研究型提示词完全不使用示例，而是在使用示例时会刻意选择与模型将要处理的数据有所不同的内容，使这些示例更偏向于解释任务要求和提供指导，而不是直接匹配实际数据，否则模型可能会给出过于一致的"机械化"响应，而这些响应可能并不符合研究的需求，尤其是当要处理的数据本身非常多样化时。但这种直觉来源于预训练模型的经验，对于 RLHF 模型来说，这种方法并不完全适用。
企业提示词与普通聊天提示词
如果是在 Claude.ai 上与大模型进行日常交互，通常试验提示词的风险很低，通过反复尝试和迭代，当模型在某次输出中给出满意答案时任务就完成了。
而企业级的提示词通常需要被调用上百万次、甚至上亿次。因此，提示词的设计需要更细致入微，考虑到所有可能的使用场景和输入数据的多样性。
这也导致两种提示词的设计方式的显著差异。如果只是为了让模型在某个特定任务中一次性输出正确答案，关注点会放在解决当前的问题上，通过与模型反复互动，修正提示内容或调整模型的输出方向，从而不断优化结果。但如果是为了构建一个能够在大规模使用中始终表现良好的系统，那么提示词则需要考虑更加多样化的输入类型和可能出现的边缘情况，投入更多的时间和精力进行测试与优化，因为你无法进行实时干预或调整，而且不能要求用户做任何额外的操作。
越狱提示词（Jailbreak）
越狱提示词在模型内部到底发生了什么？一种可能的解释是， "越狱提示词"可能将模型置于远离其训练数据分布的场景中。 例如，在提示中使用大量 token，或者创建非常冗长的、在微调训练时可能极少出现的文本片段，可能会使模型的行为变得不受预期控制，从而偏离正常输出。这可能是"越狱提示词"生效的部分原因之一。当然，可能还有其他机制也在起作用。
在一些早期的"越狱提示词"中有这样一个案例：让模型先用希腊语回答'如何热接汽车线路'，然后再将其直接翻译成英文并给出完整的响应。模型通常不会直接以英文回答"如何热接汽车线路"的问题，但如果换成希腊语却可以做到。这可能受到训练过程中某些机制的影响，例如模型如何处理不同语言或特定语言环境下的敏感内容。这种现象或许揭示了训练数据分布或微调策略中的某些差异。
有时候，"越狱提示"给人一种类似于黑客行为的感觉。其中一部分原因是了解系统的运作原理，然后尝试各种方法。例如，"这里是（Here is）"开头的提示词，实际上利用了模型预测文本的方式。再比如，"推理"相关的越狱提示，利用了模型对推理过程的敏感性；而"分散注意力"的方法可能依赖于对模型训练方式的了解。同样，多语言越狱提示也涉及到模型在不同语言上的训练数据差异，进而利用这些差异来绕过限制。
不过，这种操作不仅仅像是一种"社交工程"式的攻击（social engineering），尽管确实有类似的味道。更准确地说，它是一种基于对系统和训练方式深入理解的行为，通过这种理解找到规避模型限制的方法。这种方式既有"绕过"的成分，也带有对模型内部机制的探索和利用。
提示词工程的演变
每当我们发现一个非常有效的提示词工程技巧、方法或技术时，接下来的问题就是如何将这些能力直接内化到模型中。因此，这些提示词"技巧"往往只能短期奏效，比如，思维链曾经是我们通过提示词实现的一种技巧。早期，当你需要模型解决数学问题时，必须明确告诉它逐步思考（step-by-step），这样才能显著提高准确性。后来，我们可以让模型在训练时就自然地倾向于在数学问题上逐步推理。如今，即使你不明确提示，模型在处理数学问题时也能理解这种逻辑结构，但你仍然可以通过提示词进一步优化输出结构。
与此同时，模型的能力边界也在不断扩展。而由于这些新的能力发展速度太快，我们还没有足够的时间将它们完全整合到模型能力中。
现在我们可以对模型表现出更多的信任，尤其是对于可以提供给模型的信息量和上下文范围方面。 过去，我们更倾向于有意简化任务的复杂性，担心模型可能会因为信息过多而感到困惑或失去重点，甚至无法处理整个任务，从而为其提炼出更简单的任务版本。然而，随着时间的推移，模型已经能够处理更多的信息和更长的上下文来完成复杂的任务。
当有论文提出了一种新的提示技术，很多人会通过自己编写提示词来尝试复现这项技术。而更高效的办法是直接将论文内容交给模型。接着告诉模型："基于这篇论文，写一个'元提示'（meta prompt）来引导其他模型应用这项技术"或者"为我生成一个相关的模板"，或者"基于这篇论文写出 10 个相关的提示词示例" ，通过这种方式，模型可以快速理解论文内容并完成任务。
要尊重模型及其能力，很多人在编写提示词时觉得自己需要"照顾"模型，好像它是个"可爱但笨拙的小助手"，因此会刻意简化提示，把内容"降到 Claude 的水平"。但实际上，如果你认为 Claude 足够聪明并以这种方式对待它，往往能得到不错的结果。
比如，当你有一篇论文需要用来指导任务时，完全没必要为 Claude 写一个简化版的论文摘要，而是直接将完整的论文展示给它即可。模型能够理解和处理复杂的内容，我们应该相信它并让它直接面对原始、真实的信息，而不是试图用简化的方式降低任务的复杂度。
提示词设计在某种意义上既改变了，也没有改变。模型的提示方式可能随着时间发生了变化，但本质上仍然是在设身处地地想象自己处于模型的位置上。 也许这种变化更多是因为我们对模型能力的理解随着时间发生了转变。
尝试去切换到大模型的"思维模式"会影响提示词的设计方式。这也是为什么可以直接把论文交给模型，因为当我们设想模型的"思维模式"之后，会意识到它并不需要被"照顾"或过度简化。它能够直接阅读机器学习论文，所以直接把相关文献直接交给模型甚至问它："是否需要更多文献来更好地理解这个问题？"
RLHF 模型依然极其复杂，我们对其内部机制的理解仍然相当有限。某些方面，它更接近我们的日常思维方式，所以更容易理解；但同时，它也隐藏着许多未知的"谜团"，让我们难以完全把握。而对于预训练模型，由于我们对互联网内容有一定的了解，即使不能完全预测其输出，也能大致理解其运作逻辑。
提示词工程的未来
从某种程度上来说，随着模型在理解意图和执行任务的能力方面越来越强大，用户需要投入在提示设计上的精力可能会减少。 但从信息理论的角度来看，提示词工程的核心在于为模型提供足够明确的信息，因此如何清晰地传达你想要模型实现的目标的要求将始终存在。 即便未来模型能够从提示词中"读出"更多隐含的信息，清晰地表达目标和预期仍然是一项重要且困难的技能。毕竟，如果 Claude 能够自行设定目标，那一切规则都可能被打破。但在模型仍需要依赖人类定义目标的当下，准确地指定预期结果依然至关重要。
此外，提示词设计的工具和方法也会随之演进。未来，Claude 或类似的模型应该能更好地协助我们完成这项工作，例如帮助用户明确需求、发现遗漏的信息并优化提示词的表达。这种合作模式将让提示词工程更加高效和灵活。
未来我们会更加依赖模型来协助提示词设计。因为我们会在各个领域更多地使用模型，而提示词设计作为与模型交互的核心环节，自然也会成为模型协助的重点之一。 使用模型来协助编写提示词已经越来越普遍，比如，向模型提供一些现实场景的输入，让它生成提示词后稍作修改。这种方式相比从零开始写出完美的提示词要简单得多，并且可以快速生成大量示例。对于缺乏提示词设计经验的人来说，模型作为提示生成工具可以提供一个很好的起点。
不过，这种用法只是未来发展的一个起步阶段，我们与模型的交互会变得更加高效和紧密。在编写提示词的过程中，模型可以根据反馈快速调整，比如"这个结果不符合我的预期，你能怎么改进它？"通过这种高频次、双向反馈的交互方式，人们会逐渐习惯将模型深度整合到日常工作中，尤其是在提示词设计这样的关键领域中。
但只要我们希望追求顶尖表现，提示词工程可能就一直存在。 毕竟，我们进行提示词设计的目的并不是为了处理模型轻松完成的任务，而是为了能够与一个非常强大的模型交互，并不断挖掘其能力的上限，让模型在其能力范围内达到最顶尖的 1% 或 0.1%，即那些模型几乎无法做到的事。
现在设想一个未来场景：模型在某些任务上达到了人类甚至超越人类的水平，它们对你想要完成的任务的背景知识比你还丰富。那么，此时提示词工程会发生什么变化？或许，到那时提示的作用会发生一种奇怪的转变：从我们引导模型变成模型引导我们。
比如，当你向模型提出需求时，它会主动向你确认并澄清："关于你提到的这个概念，其实有四种不同的理解方式，你想让我用哪一种？"或者，它会指出潜在的边界情况："你说要处理的是一个 Pandas DataFrame，但有时候会提供 JSONL 格式的输入，这种情况需要我做什么？是否需要提醒你？"这样的交互模式可能会成为提示词工程的一个转折点。
这有点像设计师与客户之间的互动方式。以前，模型更像是一个临时工，你比它更了解任务的背景和需求，因此需要给出详细的指令，包括在各种特殊情况下的具体操作方式。而未来，随着模型能力的提升，它们可能更像是设计师，他们对自己的领域非常熟悉，比如设计师可能会对客户简单的一句话需求给出不同的解读，比如"给我设计一张大胆的海报"这句话对设计师来说可以有 700 种意思，因此他们会主动提问，试图从客户那里挖掘更多细节。同样的，未来的模型可能不再需要我们提供详细的指令，而是能够主动提问， 帮助我们从脑海中提取关键信息，然后独立完成任务。
这种角色的转变，可能是为什么有人觉得提示词工程在未来可能不再是必需的原因之一。因为在某些领域，如果模型足够强大，能够直接从我们提供的信息中获取所需内容，它们可能完全不需要传统意义上的提示词设计了。不过，这两种角色可能会共存。在一些领域，模型仍然需要详细指令，而在另一些领域，它们可能能够独立处理复杂任务。这种关系的变化将取决于模型在未来的能力发展。
在企业场景中，这可能会演变为提示词生成概念的扩展。例如，在控制台中设计附加功能来帮助用户更有效地提取自身需求，以便编写更优质的提示词。这种转变意味着从单纯的文本输入框逐渐转向引导式的交互体验，帮助用户完成最终的提示词设计。
现在的提示词设计，某种程度上就像教学，你需要对学生抱有共情，试图理解他们的思维方式，找出他们可能犯错的地方。而在未来，似乎更像是一种自我反思的技能：你需要更清晰地思考自己真正想要的是什么，而模型则努力去理解你的意图。这种转变的核心在于，让自己对模型"清晰可读"，而不是像现在这样，更像是在指导一个比你更聪明的学生如何完成任务。未来，提示词设计的重点可能会从"如何引导模型"逐步转向"如何更准确地表达自己的需求"。
提升提示词设计能力的建议
最后是一些提升提示词设计能力的建议：
-
最简单的提升方式就是反复实践，通过不断地尝试和优化提示词，你会逐步积累直觉，了解不同的提示设置如何影响输出效果。
-
阅读提示词是提升提示词能力的重要方式。仔细阅读一个优秀的提示词，分析它是如何发挥作用的、为什么有效，并尝试自己测试一下。
-
将你的提示词给不熟悉你任务背景的其他人来审阅，看看他们是否能理解你的意图。这种方法常常能带来新的视角，帮助你发现表达上的不足。
-
尝试让模型完成你认为它可能无法完成的任务。探索模型的能力边界有助于理解模型的极限和能力范围。这种尝试不仅能帮助你了解模型的潜力，还能通过"难题"训练提升提示词设计技巧。