我通常不太赞成用旧世界的类比去解释新世界的现象。所以请容我犯一次这样的错：让我阐述一下，为什么 prompting 应该被称为 prompt design（提示设计） ，并且可类比于 web design（网页设计）。

我将提示视为与一位时间受限的人进行沟通。尽管特定于 LLM 的技巧（尤其是 chain-of-thought）确实有用，但我发现提升效果的最佳方式之一，就是提供极其清晰且高质量的指令——就像对真实的人一样，清晰与简洁同样能帮助他们更好地理解。

将提示视为清晰沟通（Prompting-as-clear-communication）让提示听起来像是在写作。然而，我现在进行的大部分提示是参数化的：我有若干输入变量，需要根据它们动态调整我的提示。

因此，将提示视为包含动态输入的清晰沟通似乎是最准确的表述。

还有哪个领域是围绕着用动态输入进行清晰沟通的？Web 设计。

让我们列出所有相似之处。Prompting 与网页设计都：

1. 要求清晰，以沟通为首要目标；
2. 需要响应动态内容，不同于写作或杂志版式；以及
3. 需要将其内容适配为不同的尺寸——用于网页设计的屏幕尺寸、用于提示的上下文窗口。

根据我在提示工程和网页设计两方面的实践经验，我发现自己在这两个领域的开发偏好也很相似：

1. 查看实际的提示词 非常重要，就像 查看已渲染的网站 非常重要一样。如果只能在脑海中模拟 HTML 和 CSS 的渲染过程，我是无法设计网站的。同样地，如果不查看填充了所有输入变量后提示词的渲染输出，要写出优秀而清晰的提示词就会非常困难。
   1. 例如，提示词 "Hi ${username} ${message}" 看起来似乎合理，但在渲染后你会发现用户名与消息混在一起了。
2. 可组合组件在提示工程与网页设计中都很有用。
3. 在这两种情况下，声明式都优于命令式。修改一个所有 HTML 元素都通过 document.createElement 调用创建的网站非常困难。同样地，阅读和修改由长串 str += "..." 组成的提示也很容易变得难以管理。
4. 在这两种情况下，我有时都想追求“像素级完美”。在与较弱模型（GPT-3.5 及更早版本）交互时，我希望确保没有多余的换行或其他任何不完美的格式；而在设计网站时，有时每一个像素都至关重要。

对于 LLM 代理，这个类比甚至可以更进一步：代理提示可以被视为为代理构建一个交互式网站，他们可以通过调用函数来“点击按钮”，并且提示会在函数调用后重新渲染，就像网站会在按钮点击后重新渲染一样。

当然，提示设计与网页设计之间也存在差异：

1. 目前提示仅支持文本（暂时如此！）。
2. 缓存思路不同：尤其在使用代理时，你需要通过只修改提示词的后半部分来确保重新渲染的成本很低。这里可以勉强类比到网页（你希望对网站进行缓存优化），但我认为本质上这是一个完全不同的挑战。

不过，这些相似之处让我相信，prompting 应该被称为提示设计（prompt design），而不是提示工程（prompt engineering）。编写一个提示感觉就像在设计一个网站，因此命名也应当一致。

从提示设计的视角出发，我受到启发创建了 Priompt，一个类似 React、基于 JSX 的提示设计库。

Priompt v0.1：首次尝试的提示设计库

Priompt 是首次尝试创建的提示词设计库，灵感源自现代网页设计原则。我们在 Anysphere 内部使用它，而且我们非常喜欢。

我认为它在所有抽象层面上可能并不完全准确，但至少我确信，相比字符串模板，JSX 是一种更符合工程实践的人性化提示编写方式。哪怕只是能轻松将提示中的部分内容注释掉这一简单能力，也能显著加快迭代循环。

Priompt 还附带一个（非常仓促搭建的）预览网站，你可以在其中用真实数据预览你的提示。在开发应用时，你可以在每次请求中记录进入某个组件的序列化 props。然后，当你遇到异常行为时，可以前往 Priompt 预览，查看精准的提示，并修改源代码，使提示在使用与真实请求相同的 props 的情况下更新。我们发现这能让提示的迭代更容易

如果你试用了，请告诉我你的想法！我很想看到更多同类思路，或者直接告诉我我完全错了，提示工程很蠢 :)。

注意事项

模型变化很快，提示技巧也必须随之演进。基于此，我认为对提示设计的描述有几点需要注意：

1. 对 GPT-4 来说，像素级完美的设计并不重要，而且在 GPT-4.5 或更先进的模型中很可能会变得过时。
2. 如果外推近期长上下文模型的发展趋势，上下文窗口的限制可能会消失。不过，我对此并不完全信服。
3. OpenAI 似乎正朝着让开发者对提示词拥有越来越少控制权的方向发展；有可能在一年后，“提示词”这一概念将不复存在，API 调用只需提供原始输入外加一条指令。这种控制权收缩的趋势始于聊天格式，并在最近公布的函数调用功能中延续
4. 缓存很可能是提示工程中最重要的要素之一，这么说来，它听起来更像工程而非设计。
5. 也许提示词设计过于底层，应该交由更高层的框架或编译器处理（例如 langchain）。我认为这可能确实如此，但鉴于 LLM 迭代变化很快，我个人更倾向于尽可能贴近原始模型。

最后的必要说明

……因为我很想和你一起共事：在 Anysphere，我们正在打造 Cursor，一款以 AI 为先的代码编辑器。如果你对提示工程、用于编程的 LLM，或打造优雅的产品感到兴奋，请发邮件至 arvid@anysphere.co 联系我。我们在旧金山有 5 名成员，我的每位同事都非常出色，我们也希望再邀请几位同样出色的人——工程师与设计师——加入我们，一起构建编程的未来。