提示词工程已死，不再需要掌握 AI “咒语” 了？

就在大多数人刚刚摸清提示词工程的门道时，已经有人在断言这条路走不远了。这些观点认为，现有的提示词工程技术，最快6个月、最长两年内就会变得无关紧要。它所解决的问题，要么会被全新的方法替代，要么干脆不再成为问题——至于具体怎么实现，大家的看法倒是五花八门。

不妨仔细拆解一下这些论断，看看它们到底靠不靠谱。

什么是提示词工程，我们为什么要关心它？

一个简单的提示词，比如“ChatGPT，请给我的员工写一封邮件，表扬他们在2023年的利润增长，同时以富有同情心的方式宣布大规模裁员”，确实不需要什么高深的工程技巧。直接写出来，效果通常也不差。

但提示词工程真正发力的场景，是在

的背景下。换句话说，当模型作为平台的一部分，需要处理大量重复查询或复杂数据集时，提示词工程就成了不可或缺的一环。

在应用程序中，提示词工程的目标很明确：尽可能多地触发正确响应，同时严防死守那些不该出现的回答。比如一个

，就得精心设计，确保机器人能：

• 基于用户的问题检索相关信息

• 处理信息
  ，给出准确、易懂且简洁的答案

• 判断自己是否有能力回答问题
  ，并指引用户去获取更多信息
• 坚决不被用户操控，不会给出折扣、优惠券或升级福利
• 不参与

  离题
  对话，比如整治、宗教或强制疫苗接种这类话题
• 不讲

  关于空乘人员和飞行员的模棱两可的笑话
• 不允许

  提示词劫持

提示词工程的核心作用，是给模型提供它生成响应所需的数据、明确指定任务、描述输出格式、提供正反面示例、设定话题白名单、定义边界情况，并防止用户恶意利用提示词。

其实，除了少数几个关键短语，提示词并不依赖什么神秘咒语来触发模型内部的隐藏开关。它更像是在用一种高度结构化的方式，向一个聪明但完全不了解你公司、客户、产品的新人解释任务。

那么，为什么提示词工程是无功？

主张“提示词工程无用”的人，通常基于以下几个理由，只是强调的程度各有不同。

：

尽管依然必要，但具体的提示词编写——也就是选择正确的措辞——已经没那么关键了。

模型越来越聪明，能更好地理解我们。我们只需大概描述任务，。

模型将变得，它们，甚至能预见我的需求。

模型能，或帮我们优化提示词。

模型会被整合到中，自己制定计划、检查解决方案。

我们将不再手动编写提示词，而是来“写”提示词。

下面，我们逐一看看这些说法是否站得住脚。

1) 提示词工程已死。但模型的问题表述仍然需要，并且变得更加重要。

例如，《哈佛商业评论》就持这种观点。事实确实如此：模型的问题表述

。

但这恰恰是

：精确指定模型应该如何响应、如何处理数据。

这就像软件开发的关键不在于花括号放对位置，而在于

来解决实际问题。

AUTO 等——提示词工程备忘单中的 AUTOMAT 框架

例如，上图展示的 AUTOMAT 框架，它规定了如何构建提示词指令。其中大约90%的工作，是清晰且结构化地向模型传达任务。剩下的

——那些能让提示词效果更出色的特殊表达方式。

所以，从这个角度看，“提示词工程已死”的说法可能站不住脚。

2) 模型将越来越理解我们。因此，在未来，我们将用几个要点勾勒出我们的任务，模型将以某种方式理解我们。因为它很聪明。

这类观点在网上很常见，比如一些Medium文章和Reddit讨论。模型能力确实在飞速发展，未来我们将能交给它们更复杂、更广泛的任务。问题的关键在于指令的质量和规模。

做个比喻：假设我们有几个能变出东西的精灵，一个变勺子，一个变西装，一个变汽车，一个变房子，还有一个变城堡。随着物品越来越复杂，我们对精灵的指令也必须越来越详细、精准。因为复杂的东西，意味着更多的可能性。

上述论点中唯一靠谱的部分是：随着模型能力的提升，提示词工程的效率也在提高。在较新的模型上投入两倍的工程精力，获得的输出价值、复杂度和精确度，可能接近于在老模型上投入四倍精力才能得到的结果。

至少实践下来，感受就是如此。

3) 模型将会个性化并针对我进行调整。所以它们会知道我想要什么，我不需要向它们解释。

这个论点有一定道理。比如，让未来的模型为五周年结婚纪念日策划一个周末，它已经知道我妻子是素食主义者，我更喜欢山而不是海滩，而且我们刚买了房手头紧。这些信息都不需要再重复输入。

但个性化的最大潜力，不在于个人偏好，而在于

。

想象一下，如果一个模型能正确执行这样的指令：“问问特斯拉的人，他们是否已经将最后的交付物发送给客户，然后再跟财务部门确认我们何时能开具最终发片？”

哪怕是最聪明的模型，也无法直接执行这个指令。因为它不知道“特斯拉的人”是谁（是特斯拉公司的项目，还是尼古拉特斯拉的传记？），不知道“交付物”是什么，不知道“财务部门”是谁，也不知道如何联系他们。

如果模型能理解这样的指令，那将是碘伏性的变化。它就像一个全知全能的资深同事。经验丰富的员工和新人的区别，往往不在于知识广度，而在于上下文知识：他们熟悉组织里的人、数据、流程。他们知道什么有效、什么无效，出问题时该找谁。

这种能力不仅适用于像“特斯拉指令”这样的临时任务，也能用于设置基于AI的结构化系统处理保险理赔。例如，一个了解你保险公司理赔部门处理客户邮件方式的模型，就能提供巨大帮助——帮你设置算法和提示词，实现自动化处理。

目前还不清楚模型如何获取这种知识。使用结构化训练材料进行传统微调，需要投入大量精力准备数据。让模型持续跟读团队或部门的对话和消息，或许是一个可行方案。

4) 模型将编写自己的提示词，或至少优化我们的提示词

我们已经看到，这并不容易，因为模型无法确切知道你想要什么、你具体想要什么方式。

但有一个方法很有用：与其直接给任务指令，不如用大量例子“轰炸”它，然后让它自己编写提示词。比如，

：

### 指令
作为一个聪明的提示词工程师。为我编写一个提示词，能够将以下所有输入转换为输出。
如果你认为有意义，可以添加更多输入/输出示例，这些示例不要过于接近现有示例。
将所有内容格式化为一个精心编写的提示词
### 输入 / 输出
输入: 'Fagoideae', 输出: 'Fagaceae'
输入: 'Washington', 输出: '<错误输入>'
输入: 'Ciconiidae', 输出: 'Ciconiiformes'
输入: 'Pizza', 输出: '<错误输入>'
输入: 'Fungi', 输出: 'Eukaryota'
提示词:

这是

：

### 提示词
你是一个高度准确的生物分类翻译器。你的任务是将表示生物分类的输入翻译成它们正确的更高级分类组。如果输入不代表有效的生物分类，请回答'<错误输入>'。以下是一些指导你进行翻译的示例：
输入: 'Fagoideae' 输出: 'Fagaceae'
输入: 'Washington' 输出: '<错误输入>'
输入: 'Ciconiidae' 输出: 'Ciconiiformes'
输入: 'Pizza' 输出: '<错误输入>'
输入: 'Fungi' 输出: 'Eukaryota'
附加示例:
输入: 'Felidae' 输出: 'Carnivora'
输入: 'Hominidae' 输出: 'Primates'
输入: 'Canis' 输出: 'Carnivora'
输入: 'Table' 输出: '<错误输入>'
输入: 'Chordata' 输出: 'Animalia'
请相应地翻译以下输入:
输入:

这个提示词写得确实不错。开头第一句甚至包含了一些我作为提示词工程师可能不知道或没必要主动写进去的内容——

：

你的任务是将表示生物分类的输入翻译成它们正确的更高级分类组。如果输入不代表有效的生物分类，请回答'<错误输入>'。

模型仅从几个示例中推导出了这个概括——我并没有明确提供这类信息。它还找到了更好、更显眼的示例。

不过，这个提示词仍有改进空间。比如，它开头写了“### 提示词”，这其实没必要，因为发送给模型的内容自然就知道自己是提示词。另外，“附加示例”这种标题在提示词正文中没有意义，只有在提示词工程师和助手之间的讨论中才有用。而且这些示例对少样本提示来说，数量偏多、相似度也高。

除了自动提示词工程（APE），

（APO）也很有前景。不过，这通常需要评估数据来驱动优化，系统必须能测试提示词是否针对输入输出数据做了优化。当然，大多数情况下，我们并没有这类现成的大规模数据。

：如果模型这么聪明，为什么还需要自己编写或优化提示词？难道它不是直接在内部用更好的提示词来输出结果吗？

没错——如果只需要用一次提示词，确实没必要。但在应用程序中，同一个提示词可能被使用数百万次，或者被发送到不同模型，因此专门优化是值得的。

5) 模型将被整合到智能体设置中

AI智能体方法比自动提示词工程更进一步。作为用户，可能只需要输入一两句话，比如：

“提供三个从伦敦出发去哥本哈根的美食周末建议，包括具体日期和价格。预算大约800欧元，供两人使用。”

自主智能体会自动制定计划：确定所需信息、从哪里获取、如何处理和检查，最终打包成建议。在寻找解决方案的过程中，它会为自己编写一系列提示词、搜索查询或API调用。

然后，它把这些内容发送给自己、其他模型、搜索引擎或应用程序。

，至少不如当前模型单次调用处理这类查询的能力——

未来，可能会出现这样的系统：通过少量输入，迭代地寻找复杂问题的解决方案，尝试不同方法。

但是，在商业环境中，超越美食周末的任务需要更详细的规范。比如，必须为智能体编写详细的提示，具体说明它在我公司处理保险索赔的流程。

所以，智能体并不会消除对提示词工程的需求。

6) 我们将编程提示词

目前已经有不少方法，可以将提示词原生集成到编程语言中，或者直接对提示词进行编程（例如dspy、APPL）。

，这将彻底消除提示词工程的需求。

以下是一些示例。在Dspy中，一个链式思维提示词可以这样写：

class CoT(dspy.Module):
    def __init__(self):
        super().__init__()
        self.prog = dspy.ChainOfThought("question -> answer")
    def forward(self, question):
        return self.prog(question=question)

在APPL中，一个简单的提示词看起来是这样：

import appl
from appl import gen, ppl
appl.init()
@ppl
def greeting(name: str):
    f"Hello World! My name is {name}."
    return gen()
print(greeting("APPL"))

提示词编程的核心动机之一，是能够

。在这些框架中，这件事可以变得很简单。

另一方面，编程也让提示词工程

了，整个过程变得更不透明。提示词工程之所以广受欢迎，一个关键原因就是提示词是用写的，而不是代码。

，有时会带来意想不到的优秀结果。有些模型在解决数学问题时，如果提示词被嵌入到一个《星际迷航》场景中，表现反而更好。

星际迷航提示词，来源：Battle, Gollapudi: 古怪自动提示词的非凡效果。

（至少对八年级数学题这类简单任务有效）。然而，由于各种原因，这类数据往往不存在，而且商业问题通常要复杂得多。对于聊天机器人或助手来说，系统性地衡量答案是否正确非常困难——很多问题可能有任意数量的正确答案。

尽管如此，未来提示词工程很大一部分可能会涉及提示词编程。但回到最初的问题：提示词工程会死吗？

那么，提示词工程的未来究竟如何？它会消亡吗？还是会经历巨大演变？

这里给出四个判断：

。

可以确定的是，模型能力将持续大幅扩展。但这反而会让提示词编写更具挑战性。模型越聪明，它能做的事情越多，可能的解决方案空间也越大。因此，必须以更详细、更结构化的方式，精确描述想要什么以及想要它以什么方式实现。

个性化模型将深入了解用户——用户的兴趣、工作、团队和组织。这些知识将直接贡献给任务解决。到时，用户可能会像对资深同事一样，用简短指令告诉模型“去问一下特斯拉那边交付物的情况”，它就能理解。这无疑会大幅简化提示词编写。

可以把提示词及其集成的确定性算法——比如调用的API、多提示词处理流程——

支持这一场景所需的所有要素，实际上已经在各种分散的解决方案中存在，

好消息是：

坏消息则是：它也会变得更复杂。

模型将观察、监控自身以及其他模型的响应，在出现幻觉、输出偏移或错误时发出提醒，并主动提出解决方案。

这一过程不再是纯粹的编码任务。设置这样系统的指令，可以用自然语言，一种“元提示”。

再次强调：很多工具和思路已经存在——只是还没有整合成一个便捷易用的框架。

亲爱的AI爱好者们和提示词工程师们：一个令人难以置信的激动人心的未来正在前方等待。我们尚不完全了解它具体会带来什么，但可以肯定的是，它将继续极其令人兴奋，也极具挑战性。