每当讨论提示工程(Prompt Engineering)时，我注意到一个始终存在的困惑点，我认为这种困惑源于使用语言模型的两种截然不同的方式：交互式提示和事务型提示。提示工程主要针对事务型提示，而当有人试图将其套用到交互式提示上时，就会产生大量困惑或负面情绪。

交互式提示是指 ChatGPT 式的提示方式，你更像是在与语言模型进行讨论。如果模型返回了不清晰的回答，你可以利用已有的上下文进行澄清，引导模型走向正确的回答。此外，交互式提示主要由人来驱动。

事务型提示则把语言模型更像编程语言中的一个函数来对待：你给它一些输入，期望得到某种输出。这并不限于单个提示，你可以将多个提示串联起来，或执行类似"代理"的行为。关键在于，你是以事务化的方式将语言模型用于一个非常具体的问题，通常规模很大，并且由软件驱动。

提示工程对两者都有帮助，因为从理论上讲，提示工程的知识应该能让任何人无论采用哪种风格，都能更有效地从模型中获得期望的结果。不过，我认为提示工程的主要价值在于事务型用例。

提示工程的目标是以最高的准确性和最低的成本从语言模型中获得期望的结果。这些目标更契合事务型用例。

客观性与主观性

一个流程是交互式还是事务式，其性质还不够细致，无法清晰地区分提示工程的价值所在。我们可以划分的另一个维度是客观性与主观性。

如果我们的输入能够产生客观上正确（我甚至愿意说是"大体正确"）的输出，那么提示工程就可以成功应用。具有客观正确结果的问题示例包括：信息抽取、分类、有限形式的代码生成等。

然而，如果我们的输入产生的是主观上正确的结果，那么提示工程的作用就小得多。主观结果的最佳例子是创意类任务，例如艺术生成、写作、语义搜索。

正如你无法"工程化"地让艺术在客观上变得好或坏一样，你也不可能通过"提示工程"让 LLM 在主观任务上达到客观上的好或坏。你可以通过提示工程提高主观任务输出被主观接受的可能性，但无法获得与客观任务同等的确定性或准确性。

当然，你可能会指出，针对主观任务存在大量知名的"提示模板"，有助于达到期望的结果。例如，有一些模板可以稳定地生成特定风格的艺术作品。然而，得出这些提示模板的过程远不是工程或科学实践，而更接近一种创意写作过程。

我把"代码生成"视为既是客观任务又是主观任务的一个例子。理论上，代码生成可以客观正确：如果软件对其行为有足够精确的规格说明，那么软件可以客观地被判定为通过或不通过该规格。现实中，几乎没有软件具备这种精确程度。因此，代码生成任务越大，它就越主观。反之，代码生成任务越小，测试用例或输入语言就越有可能被精确规定，任务也就越客观¹。

客观的、事务型的提示

总体而言，提示工程的知识会让任何人在从语言模型中提取所需信息时更加高效，无论手头的任务是什么。然而，针对交互式提示的提示工程更像是一个善于"用 Google 搜索的人"（Google 搜索用户），而针对事务型提示的提示工程则更接近于一名数据科学家。

提示工程试图把 LLM 变成一个客观、可预测、事务型的 API，就像程序可能对接的任何其他 API 一样，例如支付、进程内函数调用、SaaS 调用等。当然，语言模型并不是一台确定性的、100% 可靠的机器，因此其用途和用例必然有所不同。

总而言之，提示工程并不适用于与语言模型的所有提示交互。有些交互更具创造性，较少依赖数据驱动或方法论。但同样，也存在一些语言模型用例，可以应用工程方法论来取得最佳结果。两者并存，互不否定。