基于流的编程，一种人类与 AI 协同开发的方式

这篇文章来自于 NoFlo 作者、也是 Flowhub 创始人身份的 Henri Bergius

我认为现在所有阅读这篇文章的人都会看到新一代的大型语言模型像 ChatGPT 能够产生有点用的代码. 像软件开发中的任何进步——从集成开发环境到高级语言——这在我们的领域内也引发了一些关于未来就业前景的讨论。

这让我思考这些新工具如何适应基于流编程，我参与了相当长时间的软件开发技术。在基于流的编程中，可重用的“库代码”（称为_组件_）和“应用逻辑”（称为_图表_）。

这是已故的保罗·莫里森在他的开创性著作中就这个问题进行了论述，基于流的编程：一种新的应用程序开发方法（2010）：

正如在食物的准备和消费中存在厨师和食客这两个角色一样，在FBP应用程序开发中也存在两个不同的角色：组件构建者和组件用户或应用程序设计者。

…应用程序设计者使用已经存在的组件构建应用程序，或者在没有令人满意的组件存在的情况下，他/她将指定一个新的组件，然后设法将其构建出来。

回想起那段话，我不禁好奇，我能让LLMs产生有用的无流组成部分？ 配备了新的必应，我开始探索。

第一次尝试是指定一个非常简单的组件：

实际上看起来相当合理！我也尝试让新必应减少组件的冗余，同时生成了 TypeScript 和 CoffeeScript 版本的相同组件。所有这些似乎都能产生可行的东西！当然，可能需要做一些整理，但这可以减少组件创建的繁琐。

除了这个微不足道的数学组件，我还能够生成一些调用外部REST API等的组件。根据要求，Bing甚至能够在HTTP库之间进行切换。

更酷的是它实际上_建议_问它如何_测试组件_按照我被告知的去做，结果非常惊人：

那是fbp规范我们想出的声明性测试工具！绝对是测试NoFlo（或任何其他FBP框架）组件的最优雅方式。

根据我的结果，你肯定想在运行它们之前检查生成的组件和测试。但你得到的并不坏。

我当然还试图让Bing为我生成NoFlo图。这就是它相当绊脚的地方。有趣的是，结果在FBP 语言比在JSON图形格式中更进一步。但也许这更加强化了_最佳点将是人工智能编写组件，人类创建运行这些组件的图表_他是一个好人。

由于我现在没有工作，所以我目前没有使用这种合作方式的案例。但我相信这对任何（特别是基于流程的）应用开发来说都可能是一个巨大的生产力提升器，我期待着无论我的下一份工作是什么，我都会尝试使用它。

原文链接：Flow-Based Programming, a way for AI and humans to develop together

本文使用 🐝 A C(Collect) -> T(Transform) -> P(Publish) automation workflow for content creator. 全自动采集 - 翻译 - 发布