国内大部分做无代码、低代码的公司，标榜自己能适应的领域，以轻应用、快应用为主。但对于一些非常复杂的，不是表单加流程的业务场景，就没有办法了。

数据驱动本身，我们定义的不仅是在软件的应用构建，这个仅停留在软件的开发阶段。我们定义的数据驱动，对应的是软件工程全过程，从需求分析、应用设计、应用构建到测试运维，是全生命周期。

我们是把整个软件工程所有的过程数据、结果数据等，都作为数据进行沉淀。再通过这些数据，利用AI的能力，构建知识库，自动化进行应用的全生命周期构建。

smardaten的数据驱动，增强了需求分析的准确性，降低了设计门槛，加速了软件构建，提升了交互界面配置的无代码化，也加快了业务逻辑的开发效率。

数据驱动提升了需求分析的准确性。比如需求分析阶段的问卷、需求描述、功能需求、核心页面等等，这些都是数据。沉淀后，在特定的阶段，可以直接使用，帮助分析人员快速分析，同步也降低了分析人员行业背景知识、沟通技巧的门槛等，甚至可以跟客户直接开聊。

数据驱动软件构建，它有三个步骤。

第一个步骤是建模，领域模型怎么建。本质上说是数据驱动，但是所有的软件底层都是数据模型。我们底层也要建领域模型，只不过我们的建立，第一不是靠行业领域的专家，也不是靠笼统的表单拖拽，而是把两者结合，通过业务人员拖出表单或者页面，然后做自动融合建模的算法。他只要关心界面和逻辑，最后的模型我们按照最优的建模思路去做优化调整，相当于通过表单驱动的形式配出来的应用，却具有模型驱动通过专家构建的底层模型。

我们也可以利用样例数据或者说已有的业务数据，通过实体识别的算法关系发现的算法，自动构建领域模型。

第二个步骤，我们通过沉淀好的领域模型数据，帮助推荐出客户需要的模型。

第三个步骤，把模型做成知识库。客户提出他的需求，我们会帮他自动生成甚至是跨领域的模型。

数据怎么驱动交互界面配置的无代码？

业务的应用界面，传统上只能通过人去拖。在界面的配置上面，我们也是同样分了三个阶段。

首先一定是数据驱动。还没有沉淀数据的时候，怎么让用户更好地驱动开发界面？我们可以使用图像识别技术生成交互界面，或者一些需求描述的文档数据，通过自然语言处理，把它变成交互的界面。也可以通过分析前期构建的领域模型数据，自动生成界面等。

当项目有了一定积累，界面本身也会沉淀数据，形成样式库、组件库，进而沉淀为知识库，可以通过算法自动生成需要的交互界面。

数据驱动业务逻辑开发也是一样的思路。

smardaten使技术与业务得以分离。通过数据定义业务，底层技术将业务转化成技术语言，相当于DSL。DSL与实际的技术又没有过密的关系，因为本质是数据定义，因此两者只是在运营阶段存在关系，也就是从紧耦合中把业务和技术抽象出来。不会因为技术的升级换代而更改业务，也就可以避免使技术成为业务的负担，实现业务的稳定与灵活，高速换胎得以实现。

Q:数据驱动将数据表、实体关系、逻辑流程等都看作是数据。这个标准是数睿数据自己定义的，还是采用早期UML的标准，只是把它零代码化了？

是数睿数据自己定义的一套标准。

UML的方式太细，太繁琐，没有流行起来，是有原因的。数睿数据做企业级无代码平台，更多是将核心、常用的东西做抽象，颗粒度相对粗一些，开箱即可用，方便开发人员快速上手。

Q:数睿数据在smardaten的开发中，是如何把多环节的逻辑、展现等高度抽象为数字的？有成熟的方法论吗？

无代码并不代表所有的场景都能基于平台「天生」支持。

我们的无代码是面向应用构建人员的无码化。

那碰到不满足的情况怎么办？

第一种情况，是看无法满足的需求是否是通用场景，如果是，平台会做一个通用的模型。做完以后，用户不用写代码就能直接使用。

第二种，针对行业特定场景，通过二开以插件的方式去满足，就不需要做任何抽象了，后台通过Restful API满足，前台类似。

插件的话，我们不会限制它的具体语言，JS、react-view等都可以，只要能实现关键的接口，比如数据接口、样式接口、交互等。

Q:数据驱动对客户有什么显著的价值吗？

数睿数据的数据驱动对应的是整个软件工程的全过程，从需求分析、应用详设、应用构建到测试运维，全生命周期都是通过数据进行驱动。

对于客户的价值也可以对应分为三个阶段。

首先是使用现有的数据，提升开发效率。

第二阶段，是可以帮助客户进行行业数据的沉淀，包括软件数据、需求数据等等。软件工程全生命周期的数据沉淀后，基于推荐算法可以半自动化生成应用，进而提升效率和效能。

第三阶段，以知识库的形式，实现全自动。人参与的程度越来越低。

关于「大局观」、「安全感」的解读将在下期呈现，不见不散。