Blog

Blog

PHODAL

Prompt 即程序:从 Prompt 即代码到 Shire.run,探索 Prompt 的无限可能性

去年,在那篇《Prompt 即代码:设计和管理 AI 编程的最佳实践》,我们分享了如何去在团队中 分享和管理 Prompt。因此,在设计 AutoDev 时,我们也加入了大量的相关设计,诸如于 Prompt 覆写、自定义 prompt 等等。而随着 Shire 的持续迭代, 我们有了一些新的体会和感触。

TL;DR:

  • Prompt 即程序是将 Prompt 视作一段可以像代码一样运行的程序。它不仅仅是简单的提示词,而是通过模板化、模块化等方式进行设计和管理, 能够生成动态的功能和操作。就像软件开发中的代码一样,Prompt 也可以进行版本控制、单元测试、集成测试等,从而确保它在不同环境中的稳定性和可维护性。
  • Shire Run 是 Shire 智能体 prompt 共享平台,你可以在上面下载、分享和共享编程智能体。 详细见:https://shire.run/marketplace

为什么 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 即程序?智能体即可执行程序?

随着 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 的指令,以支持代码重构。

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Engineer, Consultant, Writer, Designer

ThoughtWorks 技术专家

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《前端架构:从入门到微前端》、《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 最新技术分享

标签