本文来自Cursor官网，探讨提示词设计与网页设计的相似之处

尽管我通常不喜欢将新兴事物与过往的事物进行对比，但这次我想冒一次险：我认为提示设计应被称为提示设计，并将其与网页设计进行类比。

在我看来，提示是与时间紧迫的对象进行有效沟通的工具。虽然特定于大型语言模型（LLM）的一些技术，比如思维链，的确很有帮助，但我发现提升效果的最佳途径之一是给出极其明确且高质量的指令，这与人类在理解上所需的清晰简洁的指导相似。

将提示视为清晰的沟通方式，使其类似于写作。然而，我在提示工作中大多是参数化的：我有许多输入变量，需要灵活调整这些提示。

因此，最恰当的方式是将提示视作与动态输入之间的清晰沟通。
哪个领域也涉及到与动态输入的清晰沟通？网页设计。
让我们来列举两者之间的相似之处。提示和网页设计都有：

• 清晰度至关重要，沟通是其核心目标；

• 需要对动态内容做出响应，区别于传统写作或杂志排版；

• 内容需要根据不同的显示尺寸进行调整——网页设计关注屏幕尺寸，而提示则关注上下文窗口。

从我在提示与网页设计方面的经验来看，我发现我在这两个领域的开发者偏好存在相似之处：

• 查看实际提示的过程至关重要，这就像查看渲染后的网页同样重要。如果我必须在脑海中模拟HTML和CSS的渲染过程，我就无法有效设计网页。同理，若不查看填充了所有输入变量的提示的渲染结果，就难以撰写高质量且清晰的提示。

• 例如，提示 Hi ${username} ${message} 看似合理，直到渲染后发现用户名和消息混在了一起。

• 可组合组件在提示与网页设计中同样重要。

• 声明式编程优于命令式编程。通过document.createElement调用创建的网页难以修改所有HTML元素。同样，阅读和修改由一长串str += "…"构成的提示也会变得复杂。

• 在这两者中，我有时希望实现“像素完美”。在提示能力较弱的模型（如GPT-3.5及以下）中，我希望确保没有多余的换行或其他格式上的瑕疵，而在网页设计中，有时每个像素都至关重要。

• 对于LLM代理而言，这种类比可以进一步深化：代理提示可以被视为为代理构建交互式网站，代理通过调用函数“点击按钮”进行互动，提示会根据这些函数调用进行相应的渲染，就像网页响应按钮点击后进行重新渲染一样。

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

• 提示目前仅处理文本。

• 缓存机制存在差异：特别是对于代理，确保重新渲染过程的成本低廉至关重要，只需改变提示的后半部分。这与网页的缓存优化存在某种类比，但我认为这是一个本质上不同的挑战。

尽管如此，二者的相似性让我坚信提示设计更应被称为提示设计，而非提示工程。编写提示的过程与设计网页相似，因此也应该以相同的方式进行命名。

这种提示设计的视角激励我创建了Priompt，这是一个类似于React的基于JSX的提示设计库。

Priompt v0.1：提示设计库的首次探索

Priompt是借鉴现代网页设计原则而构建的提示设计库的初步尝试。我们在Anysphere内部使用它，并且非常满意。

我认为它的抽象可能尚不完美，但我坚信JSX是一种比字符串模板更具人性化的提示编写方式。即使只是简单地能够轻松注释掉提示的一部分，也让我在迭代过程中更加高效。

探索JSX提示设计的未来

Priompt还提供了一个快速构建的预览网站，用户可以在真实数据上体验和查看自己的提示。在应用程序开发过程中，可以记录每次请求所涉及的序列化属性。当遇到意外情况时，可以直接访问Priompt的预览功能，查看具体的提示内容，并相应地修改源代码，以确保提示与真实请求一致。这种方法显著简化了提示的迭代过程。

预览提示

如果你尝试这些功能，欢迎分享你的反馈！我期待看到更多有趣的想法，或者如果你认为我的观点完全错误，也请告诉我，毕竟提示设计可能会被认为是无效的。

需要关注的几点

鉴于模型的快速变化，提示技术也需紧跟步伐。因此，我认为在提示设计上有几个值得注意的事项：

• 对于GPT-4而言，完美的设计并非必需，而对于更先进的GPT-4.5及以上版本，可能会显得不再适用。

• 根据近期的发展趋势，长上下文模型的上下文窗口限制可能会被突破，但这一点我并不确定。

• OpenAI似乎正在减少开发者对提示的控制；或许在未来一年内，提示将不复存在，API调用将仅要求提供基本输入和指令。这一趋势始于聊天格式，并在最近发布的函数调用中得以延续。

• 在提示设计中，缓存可能是极为重要的元素，这使得设计的性质更趋向于工程而非创意。

• 提示设计或许过于基础，应该由更高层次的框架或编译器（如langchain）来承担。我认为这一说法有其道理，但考虑到大型语言模型的快速演变，我个人更倾向于尽量接近原始模型。