Promptware Engineering: Software Engineering for Prompt-Enabled Systems
本文提出了“提示词工程”（promptware engineering），这是一种将既有的软件工程原则进行适配的新型方法论，旨在解决开发提示词驱动系统时存在的随机性与试错性问题，从而为整个提示词驱动软件的全生命周期提供一个系统性的框架。
原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。 阅读完整免责声明
核心理念：从“西部荒野”到“文明城市”
想象一下，过去进行软件开发就像是按照严格蓝图盖房子。你有一套精确的语言（代码）和一个可预测的建筑师（计算机）。如果你犯了错，建筑师会停下来大喊：“错误！你忘了一个钉子！”
现在，我们正在使用大语言模型（LLMs）建造一种新型房屋。我们不再使用蓝图，而是使用提示词（prompts）（即自然语言指令）来告诉建筑师该做什么。问题在于？这位建筑师有点像一位非常有才华但又捉摸不定的艺术家。他们不讲“计算机代码”，而是讲充满细微差别、歧义和情绪波动的“人类语言”。
论文作者将这种新的构建方式称为**“提示词软件”（Promptware）。他们认为，目前的提示词构建就像是“西部荒野”。开发者只是在凭感觉尝试，不断试错，并寄希望于它能奏效，然后在出错时进行修复。他们称之为“提示词软件危机”（Promptware Crisis）**。
为了解决这个问题，他们提出了**“提示词软件工程”（Promptware Engineering）**。其核心思想是：我们需要将传统软件工程中那种严谨、有序的规则，引入到这个混乱的提示词世界中。我们不能再把提示词仅仅视为随手记下的笔记，而要将其视为严肃、结构化的软件制品。
为什么如此不同？（10 大差异）
论文通过强调 10 个关键差异，将传统软件与这种新型“提示词软件”进行了对比。以下是类比说明：
- 结构 vs. 混沌： 传统代码就像一套僵硬的乐高积木；每个零件都严丝合缝。提示词则像一袋黏土；你可以随意塑形，但很难每次都让它完美契合特定的形状。
- 确定性 vs. 猜测： 如果你运行一个传统程序两次，它会执行完全相同的内容。如果你问 LLM 同一个问题两次，它可能会给出两个略有不同的答案，因为它具有概率性（就像掷骰子一样）。
- 正确 vs. “足够好”： 在代码中，缺少一个分号就是致命错误。在提示词中，一个拼写错误可能只会让答案听起来有点奇怪，或者可能导致 AI 产生幻觉，编造虚假事实。这里不存在唯一的“正确答案”。
- 黑盒问题： 当传统程序崩溃时，你会得到一份详细的故障位置地图。当 LLM 失效时，它只会给你一个错误的答案，却不解释原因。这就像魔术师从帽子里变出一只兔子；你看到了兔子，却不知道它是怎么进去的。
- 类人特质： 传统计算机是机器人，没有感情。LLM 则表现得像人类。它们会有偏见、情绪化或表现得很有礼貌。这对于对话很棒，但对于可预测的工程设计来说却很糟糕。
- 记忆问题： 传统程序会记住你告诉它的所有事情，直到你命令它忘记。LLM 则有着短暂的注意力；除非你不断提醒它，否则它会忘记长对话开头的细节（就像金鱼一样）。
- 安全性： 传统软件有锁着的门和守卫。LLM 则像是一座开放式房屋；人们很容易诱导它们泄露秘密或执行不该做的事情（这被称为“提示词注入”）。
路线图：如何解决问题
作者提出了一个管理提示词的全生命周期，类似于工程师管理软件的方式。以下是他们基于论文特定研究机会提出的建议，并使用了类比：
1. 需求阶段（“做什么”）
在编写提示词之前，你需要明确知道自己想要什么。但由于 LLM 是不可预测的，你不能只说“做得完美”。你必须定义：
- AI 应该做什么。
- 它应该如何表现（语气、风格）。
- 避免什么（偏见、安全风险）。
- 类比： 不仅仅是说“建一座桥”，你还得说：“建一座看起来像悬索桥、能承重 10 吨，且在发出嘎吱声时听起来不像海盗在说话的桥。”
2. 设计阶段（“计划”）
我们需要设计模式（Design Patterns）。正如建筑师有建造厨房或浴室的标准方式一样，我们也需要编写提示词的标准方式。
- 想法： 创建一个“提示词库”，包含针对常见任务（如文本摘要或编写代码）经过预先批准且经过测试的结构，这样开发者就不必每次都重新发明轮子。
3. 实现阶段（“构建”）
我们需要更好的工具。目前编写提示词就像是在一台没有自动纠错功能的打字机上打字。
- 想法： 开发 提示词 IDE（集成开发环境），使其充当智能编辑器。它们可以检查你的提示词是否存在歧昧之处，建议更好的措辞，甚至能将你凌乱的自然语言“编译”成 AI 更容易理解的结构化格式。
4. 测试与调试（“质量控制”）
这是最难的部分。如何测试一个每次都会变化的东西？
- 不稳定测试（Flaky Tests）： 如果一个测试这次失败了，下次又通过了，那是提示词坏了，还是 AI 只是今天状态不好？我们需要能够应对这种随机性的新测试方法。
- 判别器问题（The Oracle Problem）： 在普通软件中，你知道正确答案。但在 AI 领域，所谓的“正确”答案往往是主观的。我们需要新的方法来判断 AI 的回答是否“足够好”。
- 调试： 由于我们无法窥探 AI 的大脑内部，我们需要像玩侦探游戏一样进行调试。我们必须一次只改动提示词中的一个词，观察它如何修复问题，并详细记录每一次改动。
5. 演进与部署（“更新”）
提示词不是静态的，它们需要成长。
- 版本控制： 正如软件有版本（v1.0, v1.1）一样，提示词也需要版本控制。如果某个提示词在 AI 更新后失效了，我们需要能够立即回滚到旧版本。
- 监控： 提示词上线后，我们需要持续观察。它是否变得越来越有偏见？是否在泄露秘密？它是否变慢了？我们需要“护栏（guardrails）”来实时捕捉这些问题。
总结
论文指出，我们不能再把提示词仅仅视为一种“临时方案（hack）”或快速修补。随着我们将 AI 集成到更关键的系统（如银行、医疗或客户服务）中，这种“试错法”是过于危险的。
提示词软件工程（Promptware Engineering） 是一个行动号召，旨在使这一领域专业化。其目标是将自然语言的混沌转化为工程学的严谨，将“猜谜游戏”转变为可靠、安全且可扩展的软件系统。
注：该论文是一篇“愿景论文（vision paper）”，这意味着它概述了一个路线图和一种新的思考方式。它目前尚未提供成品或经过充分测试的工具集，而是为这一领域的未来应有的样子提供了一份蓝图。
您所在领域的论文太多了？
获取与您研究关键词匹配的最新论文每日摘要——附技术摘要，使用您的语言。