引言：由于编程语言的灵活性，同一个功能可以有无数种实现的方式，虽然AI大模型给出了一种实现方式，但是实现的正确性还需要我们自己进一步验证，许多个性化的需求还需重新处理。由于生成的都是片段代码，因此需要首先设计系统架构体系，让AI大模型在具体的架构框架下进行代码生成。所以说目前直接使用AI大模型是否能真正的减少工作量还有待确定。   

      相比编程的粒度，建筑的粒度也许更能让人直观地理解，一个建筑最细的粒度可能是沙子，水泥和砖块，当然还有更细的，但不在我们讨论范围之内。这些基本要素组成墙体，墙体组成了房间，房间组成了楼层，楼层组成了大楼。下层粒度都是组成上层粒度的基础，在每层粒度上只要考虑本层及底层粒度的组合，而无须考虑更细粒度的问题。这在编程上同样适用。编程的过程也是不断分层抽象的过程，没有什么问题是不能通过增加一个抽象层解决的，如果有的话就再增加一层。一般情况下，越小的粒度越灵活，功能也越强大，同时使用起来也越复杂；越大的粒度虽然使用相对简单，但功能和灵活性也会受到限制。这里我们介绍一下从编程语言到软件系统之间的几个粒度。

      第一层粒度是编程语言。几乎所有的语言都包含基础数据类型、关键字和一些基本类库，如C、C++、Java、C#、JavaScript，Python等。这些语言都是图灵完备的，也就是说可以实现计算机能够实现的任何功能。但是不同的语言也有不同的针对性，使用的难度也不相同。如C语言则偏向于底层与硬件交互的驱动程序开发，或者对性能要求很高的模块；C++是C语言的升级，具有面向对象的特性，也更加适合应用程序的开发；Java是一门跨平台的面向对象语言，更加简单易学，目前更多的用于Web服务端开发；C#是微软开发的在Windows平台上的面向对象语言，与Java语言类似，也是很简单易用；JavaScript是基于浏览器运行的动态语言，与HTML，CSS一起共同支撑Web前端页面的展现和交互；Python是一个面向对象的动态语言，在目前人工智能的开发中应用广泛，由于运行环境轻量，语言规则简单，非常适合编程入门。在实际系统开发中，首先会选择开发语言，每个语言都有其不同的生态，生态越成熟，则提供的类库、框架、功能模块就越多，开发过程中遇到问题也就更加容易解决。

      第二层粒度是类库。类库是在语言的基础上对数据模型和常用算法的封装，优秀的语言总是拥有一个更为强大的类库体系，如Java的JDK，C#的.NET Framework，Python的WxPython等，这些类库多种多样，包罗万象，涵盖了编程的方方面面，包括图像处理，文本处理，网络通信，Web开发，数据库操作，音视频处理，科学计算，游戏开发，GUI，人工智能，搜索引擎，硬件相关等等。大多数的程序员都是在类库和框架之上进行开发的，每种类库都有一定的专业性，通过对类库的灵活使用，就可以完成各种各样的业务要求。

      第三层粒度是框架。框架不仅仅是类库的集合，而且通过类库实现了一个更为强大的架构体系。框架往往更具领域特性和设计思想，可以更好地完成某一方面的工作。比如著名的Java Spring框架已经成为大部分Java Web应用的标准实践，包含了大量企业应用的基础设施，网络请求处理模型，数据库交互模型等。不仅简化了系统的开发，还提供了一整套稳定可靠的架构策略。类似的互联网应用的开发框架还有C#的ASP.NET MVC，Python的Django ，PHP的ThinkPHP等；适合信息管理系统的框架有C++的Qt，C#的WinForm等；适合前端交互页面开发的有JavaScript的React、Angular、Vue等框架；适合自动化测试框架的有：Java的JMeter 等；还有适合专业软件的算法框架，如Python的人工智能开发框架TensorFlow，Keras等。值得注意的是，这些框架并不涉及到具体的应用业务逻辑，保证了易用性和灵活性的平衡。

      第四层粒度是组件。组件是指具体的功能模块，可以利用框架或者直接使用类库实现的一组功能组件，如搜索模块，Elastic Search；数据存储组件Redis，MongoDB，MySQL等；可视化展现组件，Echart，D3等；音视频处理组件WebRTC，Jitsi；即时通信组件OpenIM；消息中间件组件：RocketMQ，RabbitMQ；工作流组件：Activity Flow；地图处理组件：MapServer，GeoServer，Leaflet，Cesium等；数据库操作的ORM组件：Hibernate，Mybatis等；众多的界面交互组件：Antd，ElementUI，Swing等；这些组件可以单独部署，也可以与系统集成，但是在功能上并不能独立使用，需要与具体的业务相结合。

      在上述粒度分层中，我们有意少介绍了第五层，这是因为这一层在目前的很多软件开发中都被忽略了，直接从组件到系统。事实上，组件作为很多信息管理软件系统的下层粒度还是过于细小，以及组件的业务无关也是导致目前软件编程实现复杂度增加的一个重要原因。一方面我们可以通过提高组件的封装度来减少复杂性；另一个更为有效的办法就是在组件和系统之间增加一个业务相关的通用模型层，通过模型层来屏蔽组件的复杂度，同时对其进行通用化设计以增加灵活性。

      值得注意的是，这里的模型更类似于模板，是预先存在的，是通用化的业务逻辑设计。传统的软件需求分析设计的最小粒度是组件，设计的结果是类图、ER图、流程图、界面原型图等，而低代码开发中，设计的最小粒度为模板模型，设计的结果为设计元模型。设计元模型是一个更加易懂、更加强大也更容易交流的设计形式。在传统的开发过程中设计思想很少能够完整的记录下来，分析设计的结果都是分散在了会议的讨论中或者程序员的思考中，设计也很难在代码中得到直观体现。利用设计元模型，不仅可以充分记录设计思想，将设计清晰直观的呈现，而且还可以生成设计文档、测试代码甚至整个原型系统。设计元模型也可以看作是通用模型的一个实例，通用模型可以分为通用领域模型，通用界面模型，通用流程模型三种。

      （1）通用领域模型：领域模型是对系统中的数据和服务进行建模，分为数据模型和服务模型。数据模型是用户需求描述中的公共概念模型，能够完整地表达系统的整个逻辑体系，是系统设计的核心。通用领域模型是对领域模型的泛化，如基础模型、层次模型、查询模型、基础服务模型等；

     （2）通用界面模型：界面模型是对系统中的功能菜单和界面要素进行建模。功能菜单代表了系统的层次结构，大部分的子菜单都会对应一个界面，界面中包含各种组件要素。界面可以通过布局和应用方式进行分类抽象得到通用界面模型，如单表操作界面、左右结构一对多操作界面、可视化统计界面等等；

      （3）通用流程模型：流程模型是对不同角色在系统中的操作过程进行建模。通过对用户需求的分析，将需求分解为多个流程，每个流程中有多个步骤，每个步骤由一个参与角色进行一系列的功能操作。通用流程模型有增删改查、流程审核、报表展示、统计查询、导入导出等。

     通过AI大模型可以从一段用户的需求描述中提取出软件系统的设计元模型吗？

      在目前ChatGPT的应用中，已经有很多案例已经表明，经过一定的引导提示可以得到一个系统的功能模块，数据模型和流程操作。

 以下是使用ChatGPT对学生成绩管理系统的需求分析：

 学生成绩管理系统的数据模型 

 学生成绩管理系统的界面模型 

 学生成绩管理系统的流程模型 

      得到学生成绩管理系统的设计模型之后，进一步通过领域模型和界面模型的提示词，可以生成具体的代码实现。虽然其中的代码并不确定或者需要进一步调整和完善，但是这已经代表了更多的可能性。

 从领域模型生成实体类 

 从界面模型生成代码 

      从上述AI大模型的应用中可以看到，根据合理的表达提示，AI大模型确实可以直接生成大部分我们需要的内容。在设计模型抽取中，其提取的数据模型，功能菜单和业务流程能达到70%的实际要求。在代码生成中，由于篇幅没有全部写出，其代码的实现也非常规范，虽然在实际的开发中还需要更多边界和权限的处理，也许还需要更多的提示才能生成。

      正如前面所述，由于编程语言的灵活性，同一个功能可以有无数种实现的方式，虽然AI大模型给出了一种实现方式，但是实现的正确性还需要我们自己进一步验证，许多个性化的需求还需重新处理。由于生成的都是片段代码，因此需要首先设计系统架构体系，让AI大模型在具体的架构框架下进行代码生成。所以说目前直接使用AI大模型是否能真正的减少工作量还有待确定。

      编程的粒度并不是严格定义的，而是一个代表。在这些粒度之间还可以存在更多的粒度模型，很多技术的创新就是在这些粒度上不断地进行完善的结果。面对AI大模型，我们也许需要重新设计组件和模型，寻找一个更合适的粒度。

关联文章：

AI低代码开发宣言：一场新的软件工程革命

AI低代码开发宣言之核心：编程的粒度​

AI低代码开发宣言之过程：软件工程化

代码、无代码、低代码、AI提示代码、AI低代码

再厉害的程序员都有这三个痛点，然而它没有