一个通过与之对话来成长的 Lisp 应用

看到所有这些关于软件工厂……之类的讨论，感觉有点奇怪。看到关于编程语言的对话，或者声称 $language 是最好的，好像这在未来仍然会成立，也很奇怪。然而，很明显，编程语言将会向某种方向趋同，但那个“某种”目前尚未定义。

我还没看到的是，人们真正深刻地理解我们所拥有的新基底的力量。人们仍然过于执着于他们现在所拥有的东西，以及系统是如何构建的，以至于无法从根本上重新思考事物可以发生多大的变化。

对我来说，软件工厂不仅仅关乎流程自动化；它不是要把你现在所拥有的一切都自动化。它是关于利用这个基底，让你在产品运行的同时，在产品内部开发你的产品。

公司里的每个人（无论其专业或背景如何）都应该能够在产品内部开发产品，而不必去使用某个外部供应商提供的工具。

唯一存在的工具就是你的产品本身。产品应该在产品内部构建产品。

在未来的博客文章中，我将进一步探讨在产品内部由产品开发产品意味着什么，但现在我有一件简单的事情让你想象：

为什么软件是按照现在的方式构建的，而不是通过 LLM 的迭代使用生长出来的？如果你只需要通过与它聊天就能开发你的应用程序会怎样？实时且交互式，没有编译步骤。

为了演示这一点，我构建了 Jiti，这是一个小型内核，用于通过与 LLM 的对话来生长一个正在运行的 Lisp 应用程序。你请求一个功能，模型编写 Lisp，应用程序就永久获得该功能，直到你请求移除该功能。

内核提供了检查、更改、执行和恢复受管 Lisp 世界的机制。应用程序的行为来自于你通过提示这些结果而决定添加到应用程序中的任何内容。使用 Jiti，你可以从空白开始，或者通过提示来修改现有应用程序以添加更多行为。

源代码在 GitHub 上可用，我鼓励你运行它并尝试一下。它非常通用，从某种意义上说，它可以做你想要的任何事情。你所要做的就是请求，它就会将该功能编程到应用程序中。

其工作原理相对简单。从宏观层面看，OpenAI 模型会接收你的请求、操作应用程序的指令、工具定义以及对其当前状态的观察。内核可以请求检查可用函数、读取定义、提议新源代码或执行表达式。

一旦定义被接受，它就是一个普通的 Lisp 函数。调用它本身并不需要另一次推理请求。你可以从 Lisp、从另一个应用程序函数或通过聊天界面调用它。

OpenAI 模型用于扩展程序，而运行中的 Lisp 世界则承载由此产生的功能。

代理工具接口有两个有用的意图。

• develop_form 添加、重新定义或移除功能。
• execute_form 调用已存在的功能，包括现有函数的组合。

两者使用相同的求值器和事务机制。这种区分有助于模型判断用户是要求更改应用程序还是仅仅使用它。

假设我已经要求应用程序添加了 uppercase-string 和 reverse-string。然后我可以提示内核将某些文本转为大写并反转结果。这种组合就是 Lisp：

(reverse-string (uppercase-string "Hello"))

如果我希望这种组合成为一个可重用的能力，我可以提示它将此保存为一个函数。

(defun shout-backwards (text)
  (reverse-string (uppercase-string text)))

该函数会将其参数和源代码加入目录，准备好供检查和后续使用。未来的请求可以发现它并在此基础上构建。应用程序通过使用不断积累可执行的词汇表。Lisp 已经为我们提供了组合规则；内核则使不断演进的定义保持可用，并使其受管理的变更效果可追溯。

Lisp 值得为这种交互式编程机制记上一功。定义、检查、条件和重启几十年前就已存在。这挺酷的，不是吗？

对我来说，代理编写源代码然后涉及 CI/CD 的昂贵编译阶段这一想法，在我们拥有 AI 之后如今已真正不复存在。唯一的限制因素将是人们对他们能用这个新基座做什么的好奇心……

ps. 社交媒体