最近在Cursor博客上发现了一个颇具启发性的观点：与其将提示工程（prompting）视为纯粹的技术操作，不如将其重新定义为“提示设计”（prompt design），并拿网页设计来做类比，这样更容易理解。

说白了，写提示就像是在跟一个时间有限的人沟通——你提供的信息越清晰、越简洁，对方理解得就越快。虽然大语言模型（LLM）有一些特定技巧（比如链式思维）确实有效，但经验反复告诉我们：提升提示效果最直接的方法，就是给出高质量、无歧义的指令。这和人类之间的高效沟通本质上是相通的。

如果仅仅把提示看作“清晰的交流”，那它更像写作。但问题是，大多数提示设计是动态的——里面嵌入了多个输入变量，需要根据这些变量不断调整提示内容。所以，更准确的定位应该是：“带动态输入的清晰沟通”。

那么，哪个领域也跟“动态输入的清晰沟通”密切相关？仔细一想，网页设计恰好符合。

提示设计和网页设计，两者之间的相似之处还真不少：

• 两者都需要清晰的表达，交流是核心目标；
• 都需要响应动态内容，而不像写文章或杂志排版那样是静态输出；
• 都需要根据不同的“尺寸”调整内容——网页设计调整屏幕尺寸，提示设计调整上下文窗口大小；
• 而且，开发者的偏好也惊人地相似：
• 一定要亲眼看看实际的提示长什么样。比如，提示里写“Hi {message}” 看起来没问题，但一渲染出来，可能发现用户名和消息直接粘在一起了。
• 可组合的组件在两边都特别好用。
• 声明式编程（declarative）比命令式（imperative）优雅太多了。想想看，一个网站如果全用 document.createElement 来拼接HTML，维护起来简直噩梦。同样，一长串 str += "..." 拼出来的提示，读起来和改起来都让人头大。
• 像素级完美。在为较弱的大语言模型（比如GPT-3.5及以下）设计提示时，多一个换行符都可能引发问题；而在设计网站时，有时候每个像素都很关键。

如果延伸到AI智能体（LLM Agent），这个类比还能进一步深化：智能体的提示设计，就像在给智能体做一个交互式网站——它可以通过调用函数来“点击按钮”，提示则根据函数调用的结果重新渲染，就像网页在按钮点击后刷新一样。

当然，两者也有明显的区别：

• 提示设计目前还只跟文本打交道（至少现阶段是这样）。
• 缓存机制不同。特别是对智能体来说，为了降低重新渲染的成本，通常只改提示的后半部分。这虽然可以类比网页缓存优化，但本质上是两种不同的挑战。

顺着这个思路，有人开发了一个名为 Priompt 的提示设计库——它有点像React，基于JSX，允许开发者用写网页的方式来设计提示：使用JSX语法、有预览功能、还支持组件化和复用。

潜在的局限性和未来展望

• 随着模型能力越来越强，对“像素级完美”的需求可能会逐渐降低；
• 上下文窗口的限制可能某天就会消失；
• API 可能会朝着提供更少控制权的方向发展；
• 缓存可能成为提示工程中越来越重要的方面；
• 提示设计最终可能被更高层次的框架或编译器所取代。

对行业的启示

• 提示工程可能需要更多设计思维，而不仅仅是工程思维；
• 开发更好的提示设计工具，可能会成为一个重要的研究方向；
• 网页设计领域的最佳实践，很可能对提示工程产生直接的影响。