提示工程 vs. 汇编语言

目前人工智能领域流传着一种观点，认为精心编写的提示是专有的黄金。如果你能引导模型输出正确的结果，你就创造出了某种可以捍卫的东西。

我理解这种直觉。当某种方法有效，而且似乎没有人想到它时，它就感觉像是知识产权。但这种感觉不会持续太久。并非因为提示没有用，而是因为它们清晰易懂、可复制且非常容易丢弃。

提示的本质是规范。它们描述了在给定特定输入和输出格式的情况下，你希望模型做什么。你用英语编写指令，将它们集成到用户体验或工具中，如果运气好，系统就能按预期运行。

但我们以前也见过这种模式。每一代软件开发都始于精心设计的指令，然后逐渐走向抽象和自动化。

最初，我们用二进制编写代码。然后是汇编语言。接着是 C 语言。然后是 Python。我们构建了编译器和解释器，它们能够理解你模糊的意图，并将其优化成高性能的程序。

我们即将迎来 LLM（逻辑层模型）的类似转折点。

像 DSPy 这样的工具已经开始像早期编译器一样工作，它们接收高级意图并生成提示图，并随着时间的推移不断优化。在 Selvedge 项目中，我一直在探索如何将提示视为可组合的程序，而不是文本。这些程序结构化、类型化，并且与模型本身抽象出来。系统会根据规范来处理编排——选择哪个模型、哪种格式、哪个链。

这就是提示作为护城河失效的地方。如果编译器承担了大部分工作，那么提示本身就不是护城河。它只是一个临时接口，一个会根据开发者的需求自动重写、调整或弃用的层。

那么，真正起作用的是什么呢？

使用。反馈循环。分发。构建防御能力的关键在于掌控用户表达意图的层面，而不是表达式的语法。优势并非来自提示本身，而是来自随着每次交互而不断改进的基础设施。

我们正在从提示编写者转变为编译器设计者。从精心设计措辞转变为构建能够从目标反向推理的系统。因此，护城河根本不是指令，而是接口。

提示只是起点。真正的优势在于用户发出指令之后你所做的一切。

原文链接：Prompt Engineering Is the New Assembly Language

汇智网翻译整理，转载请标明出处