最近在看公司的 codebase 的 openAPI 时，发现了一个设计上的写法，所有的 openAPI 都使用同一个 path，用 action=xxx 来区分不同的调用方法。 而在他们的前端页面上，大部分接口是直接调用的 openAPI 的接口，感觉是一个不错的工作范式。

之前听到很多人说， ai 出来后各种低代码平台变得处境很尴尬，以前大兴低代码平台的搭建，但现在都去拥抱 ai 了，毕竟低代码是 config to ui，还需要人来拖拖拽拽以及做很多配置，但现在，似乎对着 ai 做自然语言的描述，就能让 ai 完成所有工作， 生成一个看起来效果很不错的页面。

这让我想到一个有趣的概念， lowcode for ai， 低代码设计出来是干嘛的？ 比如低代码搭建营销页，低代码搭建表单，就是降低门槛，降低操作的复杂度。本来可能需要一个开发人员去改代码，完全走开发流程的步骤，现在只需要一个外包拖拖拽拽，改改文案，点点按钮就能上线了。

但这样的门槛降级，正好命中了 ai 的好球区。本来需要一个外包的任务，是不是可以托付给 ai 来做？ ai 在面对它整个神经网络世界知识库的上下文中，它要做各种各样的技术选项，用哪个依赖包，用哪个框架的抉择，同时还有各个代码的依赖，底层方法。 虽然现在它能挑出一个相对还不错的实现，但涉及整体上下文的内容，以及对历史代码的编辑，它还不能很好地胜任。

那 lowcode 是不是就是我们包装给 agent 的世界作为上下文，告诉 agent 有多少 tool，让 agent 用给定的积木来搭建小屋。

如果想要拥抱 ai 的话，我觉得要把后端的接口 openAPI 化，前端的页面组件化，同时积极维护文档和测试用例，提供给 ai 尽可能优质的上下文。