去年,在那篇《Prompt 即代码:设计和管理 AI 编程的最佳实践》,我们分享了如何去在团队中 分享和管理 Prompt。因此,在设计 AutoDev 时,我们也加入了大量的相关设计,诸如于 Prompt 覆写、自定义 prompt 等等。而随着 Shire 的持续迭代, 我们有了一些新的体会和感触。
TL;DR:
在过去的一年多时间里,Prompt 不仅存在代码库中,还涌现越来越多的 Prompt 即代码实践。如下是我们可以看到的行业最佳实践:
当然了,对于 AI 平台来说,可能还会存在 prompt 的协作等等实践。举一个简单的例子,我们计划使用 prompt 来生成补全代码,那么 prompt 可能是这样的:
补全代码。
- 相关上下文:${selection.ast}
- 光标前代码:${selection.before}
- 光标后代码:${selection.after}
代码中包含了一系列的变量,以将 prompt 与代码解耦出来。而这个简单的 prompt 在实际使用时,还需要针对模型进行调整、对结果进行后处理等等。当我们的 AI 应用变得越来越复杂时,我们需要更好地管理我们的 Prompt。
随着 AI 应用工程化的深入,越来越多的 prompt 在直接在应用中直接执行。即由 prompt 生成平台所需要的数据、语言、代码等,再基于这些数据动态创建 对应的应用程序,诸如于低代码平台、AI IDE 等等。与此同时,工程化 + 智能体也让应用变得越来越智能:
因此,在我看来:
Prompt 即程序是将 Prompt 视作一段可以像代码一样运行的程序。它不仅仅是简单的提示词,而是通过模板化、模块化等方式进行设计和管理, 能够生成动态的功能和操作。就像软件开发中的代码一样,Prompt 也可以进行版本控制、单元测试、集成测试等,从而确保它在不同环境中的稳定性和可维护性。
而事实上,它们可以抽象为一个模式:DSL(领域特定语言) + Runtime(运行环境)。对于现在的 LLM 能力而言,直接生成复杂的程序是不靠谱的,如果想 驾驭这种复杂度,我们需要在 DSL 做更多的抽象与繁琐设计,诸如于:
那么,剩下的就是 Runtime 的设计。在 AI IDE 场景下,Runtime 是 IDE,在手机 APP 场景下,Runtime 是 APP,诸如此类。也因此,我们还需要在
Runtime 中提供这种基础能力,以支持这种 DSL 的执行,比如 AutoDev 直接提供 /refactor
的指令,以支持代码重构。
围观我的Github Idea墙, 也许,你会遇到心仪的项目