介绍下 AI aPaaS

像字节Coze这样的工具本质上是「AI-first aPaaS」。「aPaaS」是指这些Bot Builder完完全全就是以前的aPaaS，把实现一个应用所需的不同类型代码——数据、状态、API调用、逻辑（工作流、事件系统等）、UI，用不同的可视化工具来实现，比如数据库建模、服务插件、节点图工具、拖拽式UI搭建工具。且生成的不是新应用的完整代码，而是「配置」，所有创建出来的「应用」都是aPaaS本体这个单一应用读取不同配置的运行结果。Bot Builder只是对其中部分类型，换了不同的可视化工具，比如针对「数据」类型用RAG工具，对「状态」类型用Token缓存等工具、对「工作流逻辑」用Agent搭建工具，对「UI」用提示词和卡片配置工具。得到的「应用」一部分作为「配置」存储和运行在Bot Builder平台自身，一部分作为「配置」存储和运行在各种Chatbot平台（比如ChatGPT）。「AI-first」是指它们不但开发应用时用AI辅助或依赖AI，开发出来的也是AI应用（目前主要形态是各平台上的chatbot）。应用的开发阶段有大模型加持（比如用自然语言描述任务），应用的运行阶段也有大模型支撑（大模型扮演两个角色，最平庸的角色是用大模型的prompt调用取代手工编写的代码，更重要的角色是借助大模型做到手工代码做不到的事情）。

像字节Coze这样的工具本质上是「AI-first aPaaS」。「aPaaS」是指这些Bot Builder完完全全就是以前的aPaaS，把实现一个应用所需的不同类型代码——数据、状态、API调用、逻辑（工作流、事件系统等）、UI，用不同的可视化工具来实现，比如数据库建模、服务插件、节点图工具、拖拽式UI搭建工具。且生成的不是新应用的完整代码，而是「配置」，所有创建出来的「应用」都是aPaaS本体这个单一应用读取不同配置的运行结果。Bot Builder只是对其中部分类型，换了不同的可视化工具，比如针对「数据」类型用RAG工具，对「状态」类型用Token缓存等工具、对「工作流逻辑」用Agent搭建工具，对「UI」用提示词和卡片配置工具。得到的「应用」一部分作为「配置」存储和运行在Bot Builder平台自身，一部分作为「配置」存储和运行在各种Chatbot平台（比如ChatGPT）。「AI-first」是指它们不但开发应用时用AI辅助或依赖AI，开发出来的也是AI应用（目前主要形态是各平台上的chatbot）。应用的开发阶段有大模型加持（比如用自然语言描述任务），应用的运行阶段也有大模型支撑（大模型扮演两个角色，最平庸的角色是用大模型的prompt调用取代手工编写的代码，更重要的角色是借助大模型做到手工代码做不到的事情）。

像这样的AI应用开发平台，存在的问题是：aPaaS这种单一应用的模式，跟内容平台（比如微信公众号、Medium、头条抖音，很多内容平台同样有「开发」需求，比如文章的HTML排版和widget组合配置，视频中的AR效果）、乃至元宇宙平台（比如Roblox、堡垒之夜、Decentraland、VRChat、元梦之星，这些平台中用户创建的每个3D世界，都是应用，传统上都需要专门开发）是非常一致或者说一脉相承的。缺点是，不生成完整、专业的应用代码，跟专业应用开发（包括开发方式、最佳实践、技术生态、抽象积累）割裂，自成体系，重新发明一切，无法灵活深度的混搭和优化（我以前写的《「全码」通用搭建》里有讨论过）。优点是，天然趋向把同一个应用在开发阶段的形态和运行阶段的形态统一，类似本帖引用中Ego的说法「a game engine that is also a game」，应用自身就是应用开发工具、就是编辑器，开发应用的同时就是在使用应用，开发游戏的时候就是在玩游戏。aPaaS们（含Bot Builder）显然还远远没实现这种优点，仍然有使用门槛，使用Bot Builder过程中的复杂性也远高于使用Bot。Bot Builder们只做到「AI-first」，并没做到「AI-native」。引用中的Ego是一个「AI-native App Builder」的例子。定位是「AI-native simulation/game engine and platform」