GPT驱动低代码平台生产完整应用的已验证策略

今天早上我试了一下，GPT3.5已经可以理解元模型、模型差量、领域特定语言DSL的概念，可以直接驱动Nop平台生成前后端全套应用。Nop平台与GPT沟通的策略如下：

1. 通过当前所使用DSL的xdef元模型（类似json schema但更紧凑）帮助GPT更快、更精确的理解DSL结构
2. 通过可逆计算的差量合并规则，指导GPT直接返回差量描述
3. 将返回差量合并到当前模型上，成为新的当前模型，在此基础上可以无限次与GPT沟通。

这里利用可逆计算理论，通过差量计算可以很自然的实现一般性程序与AI大模型的协作。实际上，DSL可以成为用户、AI大模型、程序员之间的沟通桥梁。通过DSL解析器我们可以向AI模型引入领域特定的世界知识，让AI模型在不需要掌握领域知识的情况下操纵DSL来完成功能。

借助于DSL，Nop平台可以直接与GPT对话，成为AI驱动的低代码平台。

NopPlatform开源地址：

• gitee: canonical-entropy/nop-entropy
• github: entropy-cloud/nop-entropy
• 开发示例：tutorial

以下是与GPT沟通的实例：

提问：
你是计算机程序员，了解元模型。以下元模型是描述数据表定义的。

    
。你能根据这个元模型设计一个用户登录记录表吗，返回格式符合这个元模型的要求

2023/3/17 08:05:55

Yes, I can design a user login record table based on the given meta-model. Here is an example of how the table definition would look like based on the provided meta-model:


  
    
    
    
    
    
  


This table will have the following columns:

    id: The unique identifier for each login record (primary key).
    user_id: The ID of the user who performed the login.
    login_time: The timestamp of the login event.
    logout_time: The timestamp of the logout event.
    ip_address: The IP address used by the user for the login.

All the columns are defined according to the meta-model provided, with their respective names, codes, display names, standard SQL types, and any necessary precision or scale values. The user_login_record entity is also defined with its corresponding name, display name, and tag set, and the tableName attribute specifies the name of the actual database table that will be created.

2023/3/17 08:10:27
xdef:body-type="list"表示子节点是列表，xdef:key-attr="name"表示子节点的name属性是唯一键。以上元模型可以表达差量修正的概念，例如 表示将user_id的类型修改为VARCHAR。你能为user_login_record表用差量的形式增加一个字段nick_name吗

2023/3/17 08:11:07

Yes, I can add a new column nick_name to the user_login_record table using the delta modification concept.

Here is an example of how the delta modification would look like based on the provided meta-model:


  
    
  


This delta modification adds a new column nick_name to the user_login_record table, with its respective name, code, display name, and standard SQL type. The x:extends attribute is used to inherit the definition of the original user_login_record entity, and the new column definition is added under the columns element, which is defined as a list according to the meta-model.

With this delta modification, the user_login_record table will have an additional column nick_name, which can store the user's nicknam

提问：

========== intro[商品介绍] ================
                goodsSn[商品编号] name[商品名称]
                counterPrice[市场价格]
                isNew[是否新品首发] isHot[是否人气推荐]
                isOnSale[是否上架]
                gallery[商品宣传图片列表，采用JSON数组格式]
                unit[商品单位，例如件、盒]
                keywords[商品关键字，采用逗号间隔]
                categoryId[商品所属类目ID] brandId[Brandid]
                brief[商品简介]
                detail[商品详细介绍，是富文本格式]

                =========specs[商品规格]=======
                !specifications

                =========goodsProducts[商品库存]=======
                !products

                =========attrs[商品参数]========
                !attributes

你是计算机程序员，理解DSL。以上是界面布局的DSL。要求你在商品介绍这个区块的第三行增加一个字段 商品图片，在商品参数这个区块增加一个字段name，与attributes放置在一行，结果以上面的DSL形式返回。


2023/3/17 09:44:02

以下是更新后的DSL：

========== intro[商品介绍] ================
goodsSn[商品编号] name[商品名称] 
image[商品图片] counterPrice[市场价格]
isNew[是否新品首发] isHot[是否人气推荐]
isOnSale[是否上架]
gallery[商品宣传图片列表，采用JSON数组格式]
unit[商品单位，例如件、盒]
keywords[商品关键字，采用逗号间隔]
categoryId[商品所属类目ID] brandId[Brandid]
brief[商品简介]
detail[商品详细介绍，是富文本格式]

=========specs[商品规格]=======
!specifications

=========goodsProducts[商品库存]=======
!products

=========attrs[商品参数]========
name[名称] !attributes

在第三行新增了一个字段image[商品图片]，并将原来的市场价格counterPrice后移了一位。

在商品参数这个区块，将新增的字段name[名称]与原来的attributes放在了同一行，并添加了相应的注释。

第一个问题是告诉GPT元模型定义，要求GPT的设计结果按照元模型要求返回。第二个问题是在已有模型基础上修改，要求GPT以差量形式返回。第三个问题是要求GPT识别自定义的前端布局DSL，按照该DSL格式修改前端布局。

基于返回的差量，我们可以自动将它合并到原始模型上，再次向GPT询问局部修改如何操作。因为此前返回的所有差量可以按照可逆计算原理合并在一起，因此与GPT的对话长度可以始终保持有限，可以无限次与GPT对话下去。

Nop平台与GPT的集成策略

在Nop平台中，目前内置了从后端数据模型直接产生前端界面的推理管线：

XORM = Generator + Delta
XMeta = Generator + Delta
XView = Generator + Delta
XPage = Generator + Delta

• Excel是用户可理解的可视化模型

• ORM是面向存储层的持久化模型

• XMeta是用于提供GraphQL服务的接口层模型

• XView是从业务角度理解、技术中立的前端页面操作模型，仅包含Page/Form/Grid/Action等少量交互元素

• XPage是依赖于某种具体前端框架的页面模型。

在可逆计算的视角下，这些模型之间可以建立递进推导关系，从Excel可以直接生产得到Page。但是这一推理链条是完全可选的，我们可以选择从某个环节中断，完全手写替代。每个模型在某种意义上说都是具有独立存在的价值，可以独立被理解的。例如，即使XORM模型不存在，则我们也可以使用XMeta模型。所以这种架构的持续更新类似于深度学习中的深度分解，它可以帮助不同抽象层次的概念整合成一个完整的整体。

如果接入专门针对GPT简化的模型，我们可以进一步对上面的推理管线进行细化。例如通过来直接嵌入专为gpt简化的DSL，但是同时还可以通过delta差量来保留完整的编程能力。

<view>
    <x:gen-extends>
          <gpt:GenViewFromDSL src="gpt-model.xml" /> 
    x:gen-extends>
     这里可以在gpt模型基础上进行新的修正 
view>


<orm>
       <x:gen-extends>
          <gpt:GenOrmFromDSL src="gpt-model.xml" />
       x:gen-extends>
orm>

相当于是 XView = Genearator + Delta, XORM = Generator + Delta

DSL可以明显提升程序语义的精确性，降低和GPT沟通所需token的数量，并且差量形式的返回也更容易验证、分析、保存。现在AI平台与低代码平台的结合已经没有任何障碍。

我们注意到，长期维护的生成式代码必须解决两个问题：

1. 自校验：能够提供自动化和直观的方式验证自身的正确性
2. 差量修正：可以进行局部修改，并且可以用独立的差量形式表达、传输这种局部描述

可逆计算理论为基于差量的自动演算和演化提供了完整的理论基础，它的概念不是一种经验积累或者某种聪明的最佳实践，体现的是一种通用、普适的规律。Nop平台为可逆计算理论提供了完整的技术支撑，使得它的概念可以被通用的方式实现出来，应用到各类领域模型的构建中，可以快速开发自定义的DSL。

基于可逆计算理论设计的低代码平台NopPlatform已开源：

• gitee: canonical-entropy/nop-entropy
• github: entropy-cloud/nop-entropy
• 开发示例：docs/tutorial/tutorial.md
• 可逆计算原理和Nop平台介绍及答疑_哔哩哔哩_bilibili