Shire.run：Prompt 即代码到 Prompt 即程序，思考 Prompt 的无限可能性

发布日期：2024-09-09 22:21:57 浏览次数： 2678

作者：phodal

微信搜一搜，关注“phodal”

TL；DR：https://shire.run/

随着 Shire 的持续迭代，我们有了一些新的体会和感触，即 Prompt 不仅仅是一段提示词，而是可以直接执行的代码。而当是可执行的代码时，就是可执行、可共享的智能体。因此，我们创建了 Shire Run，一个轻量级的共享平台，以支持用户共享、下载、执行智能体。Shire Run 是 Shire 智能体共享平台，你可以在上面下载、分享和共享编程智能体（当然，现在只是一个原型，感谢卷王 @CGQAQ 创建了该网站），详细见：https://shire.run/

为什么 Prompt 应该是程序？理解 Prompt 的工程化演进

在过去的一年多时间里，Prompt 不仅存在代码库中，还涌现越来越多的 Prompt 即代码实践。如下是我们可以看到的行业最佳实践：

Prompt 代码分离。将 Prompt 代码与业务代码分离，通过变量化与模板化的方式，以更好地降低代码的耦合度。
Prompt 版本化管理。LLM 在持续迭代，prompt 也会随之变化。通过版本化管理，可以更好地管理 prompt 的变化，回溯到历史版本，检查 prompt 的变化。
模块化 Prompt 设计。不同背景下，最终 prompt 会由大量的不同上下文所构建。在代码逻辑设计上，体现的就是模块化设计，或者通过注册表、依赖注入等方式来实现。
Prompt 单元测试。AI 返回的结果会存在一定的不确定性，因此我们需要检查必要的格式、字段等，测试是最好的方式。在智能体的场景下，我们还需要预期它可以调用到对应的工具和函数。
Prompt 集成测试。对于复杂的场景，我们需要对整个 prompt 的执行流程进行测试。这种测试通常会涉及到 IDE 的交互、AI 模型的调用等等。
Prompt 组织。对大型项目，我们还面临如何更好通过目录结构、文件结构来组织 prompt 的挑战。

当然了，对于 AI 平台来说，可能还会存在 prompt 的协作等等实践。举一个简单的例子，我们计划使用 prompt 来生成补全代码，那么 prompt 可能是这样的：

补全代码。- 相关上下文：${selection.ast}- 光标前代码：${selection.before}- 光标后代码：${selection.after}

代码中包含了一系列的变量，以将 prompt 与代码解耦出来。而这个简单的 prompt 在实际使用时，还需要针对模型进行调整、对结果进行后处理等等。当我们的 AI 应用变得越来越复杂时，我们需要更好地管理我们的 Prompt。

Prompt 即程序：可执行的 Prompt 代码

随着 AI 应用工程化的深入，越来越多的 prompt 在直接在应用中直接执行。即由 prompt 生成平台所需要的数据、语言、代码等，再基于这些数据动态创建对应的应用程序，诸如于低代码平台、AI IDE 等等。与此同时，工程化 + 智能体也让应用变得越来越智能：

AI 平台自带的 Code Interpreter 就可以直接执行，生成表格、图表等。
IDE 插件在自动化生成测试，会根据结果来执行测试，并在测试失败时，自动化生成对应的修复代码等等。
低代码平台会直接将 prompt 生成的代码，直接执行，以生成对应的程序、应用。

因此，在我看来：

Prompt 即程序是将 Prompt 视作一段可以像代码一样运行的程序。它不仅仅是简单的提示词，而是通过模板化、模块化等方式进行设计和管理，能够生成动态的功能和操作。就像软件开发中的代码一样，Prompt 也可以进行版本控制、单元测试、集成测试等，从而确保它在不同环境中的稳定性和可维护性。

而事实上，它们可以抽象为一个模式：DSL（领域特定语言） + Runtime（运行环境）。对于现在的 LLM 能力而言，直接生成复杂的程序是不靠谱的，如果想驾驭这种复杂度，我们需要在 DSL 做更多的抽象与繁琐设计，诸如于：

提供原子操作能力。如将与应用的交互、与 IDE 的交互、与 AI 模型的交互等等，抽象为一个个的原子操作。
封装复杂逻辑（繁琐设计）。将复杂的逻辑，如代码生成、代码检索、代码分析等等，封装为一个个的函数。

那么，剩下的就是 Runtime 的设计。在 AI IDE 场景下，Runtime 是 IDE，在手机 APP 场景下，Runtime 是 APP，诸如此类。也因此，我们还需要在 Runtime 中提供这种基础能力，以支持这种 DSL 的执行，比如 AutoDev 直接提供 /refactor 的指令，以支持代码重构。