DSL-based AI native application generation and synchronization method and system

Abstract

The invention relates to the field of data processing, in particular to a DSL-based AI native application generation and synchronization method and system. In the method, a natural language input by a user is converted through a multi-node hybrid agent, and a DSL conforming to a preset grammar specification is output. Compiling the executable DSL into a program source code of business logic, logic intermediate representation and data model definition through a dual-mode compiling engine; performing visual logic compiling on the business logic based on the logic intermediate representation, and updating a compiling result to a program source code; and / or updating the logic intermediate representation based on the modification result of the program source code. The certainty and reliability of application logic generated by a natural language are remarkably improved, bidirectional and lossless synchronization between visual logic editing and program source codes is achieved, and the construction and maintenance process of the application has the double advantages of being visual, efficient, flexible and accurate.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a method and system for generating and synchronizing AI native applications based on DSL. Background Technology

[0002] As enterprises deepen their digital transformation, the need to rapidly build and iterate complex business applications is becoming increasingly urgent. Currently, in the field of assisting or realizing application software construction, there are various technical approaches, such as using low-code / no-code platforms for visual configuration, or leveraging large language models to generate program code snippets based on natural language descriptions. These technical approaches aim to improve development efficiency and lower the professional threshold.

[0003] However, these existing methods still have limitations in the process of building an executable application system from natural language requirements, especially in ensuring consistency between different forms of business logic representation. How to achieve efficient and accurate generation of executable applications from natural language, while ensuring lossless, bidirectional synchronization between visual logic editing and program source code, has become a pressing technical problem. Summary of the Invention

[0004] To address the above issues, this application provides a method and system for generating and synchronizing AI native applications based on DSL.

[0005] In a first aspect, embodiments of this application provide a method for generating and synchronizing AI native applications based on a DSL. The method includes: converting user-input natural language through a multi-node hybrid intelligent agent to output a DSL that conforms to a preset syntax specification; the DSL is used to define business data, business logic, and interactive visuals of a business entity; verifying and correcting the DSL to output an executable DSL; compiling the executable DSL into program source code, intermediate logical representation, and data model definition of business logic through a dual-mode compilation engine; performing visual logic compilation on the business logic based on the intermediate logical representation and updating the compilation result to the program source code; and / or updating the intermediate logical representation based on the modification result of the program source code.

[0006] In one possible implementation of the first aspect above, the multi-node hybrid agent includes: The requirements analysis module is configured to perform element analysis on the natural language based on the structured requirements meta-model, and to fill in the missing elements from the domain knowledge base through retrieval enhancement generation technology to form a structured requirements specification; the encoding module is configured to generate the DSL based on the structured requirements specification; and the verification module is configured to verify the DSL based on deterministic rules.

[0007] In one possible implementation of the first aspect above, the DSL takes an entity model as its root node, and the entity model includes: an attribute definition matrix, used to define the attributes of each field in the business entity in the form of a row and column matrix; wherein, columns correspond to fields, and rows correspond to different attribute definition dimensions; and a declarative logic unit, used to define the business logic for the business entity through an ordered sequence of declarative operation instructions.

[0008] In one possible implementation of the first aspect above, the attribute definition matrix is ​​a 12-row definition matrix, with each row defining the following attributes in sequence: physical field name, business alias, data type, field length, default value, enumeration value and value range, form component type, list component type, data filtering configuration, data update constraint, data validation condition, and interface grouping information.

[0009] In one possible implementation of the first aspect above, the declarative operation instructions include at least one of the following types: instructions for declaring or referencing context variables, instructions for performing data persistence operations, instructions for implementing flow control, and assertion instructions for performing verification or confirmation.

[0010] In one possible implementation of the first aspect above, the step of configuring the verification module to verify the DSL based on deterministic rules includes: performing pattern verification to verify whether the tag structure of the DSL conforms to a predefined XML pattern definition; performing integrity verification to verify whether the DSL includes a specified attribute definition; performing reference consistency verification to verify whether the variables or data sources referenced in the DSL have all been correctly defined; if the tag structure of the DSL conforms to the predefined XML pattern definition, the DSL includes the specified attribute definition, and the variables or data sources referenced in the DSL have all been correctly defined, the verification passes, and a DSL conforming to the preset syntax specification is output; or, if the tag structure of the DSL does not conform to the predefined XML pattern definition, the DSL does not include the specified attribute definition, or the variables or data sources referenced in the DSL have not all been correctly defined, the verification fails, and the encoding module corrects the DSL.

[0011] In one possible implementation of the first aspect above, the step of correcting the DSL includes: if the verification module fails to verify, feeding back the verification result containing error information to the encoding module; the encoding module corrects the DSL based on the verification result and generates a corrected DSL, which is then submitted to the verification module for verification; the above steps are repeated until the verification module outputs that the verification has passed, or a preset iteration termination condition is reached, or a user termination instruction is received.

[0012] In one possible implementation of the first aspect described above, the dual-mode compilation engine includes a forward generation module and a reverse extraction module. The step of compiling the executable DSL into program source code and intermediate logical representation of business logic using the dual-mode compilation engine includes: using the forward generation module to convert the declarative business logic instructions in the executable DSL into function code conforming to the specifications of a first target programming language, as the program source code; using the forward generation module to generate an intermediate logical representation semantically equivalent to the program source code based on the semantic structure of the declarative business logic instructions; and using the reverse extraction module to parse the program source code using a specific syntax tree parsing tool to extract the intermediate logical representation.

[0013] In one possible implementation of the first aspect above, the step of compiling the executable DSL into the data model definition by the dual-mode compilation engine includes: parsing the data storage-related attribute definitions in the executable DSL to generate the data model definition independent of a specific database engine.

[0014] In one possible implementation of the first aspect above, the method further includes: displaying the data model definition in a structured form through a data model editing interface; and generating and executing a corresponding database migration script in response to modifications made to the data model definition through the editing interface, so as to synchronize the modifications to the physical database constructed according to the data model definition.

[0015] Secondly, embodiments of this application provide an application generation and bidirectional synchronization system based on DSL. The system includes: a demand conversion module configured to convert user-input natural language into DSL conforming to a preset syntax specification through a multi-node hybrid intelligent agent; a verification and correction module configured to verify and correct the DSL and output an executable DSL; a dual-mode compilation module configured to compile the executable integrated special-purpose language into program source code, logical intermediate representation, and data model definition of business logic; and a bidirectional synchronization module configured to achieve bidirectional synchronization between visual logic editing and the program source code based on the logical intermediate representation.

[0016] Thirdly, embodiments of this application provide a computer program product, including: a computer program / instruction, which, when executed by a processor, implements the first aspect described above, and the computer program code for generating and synchronizing AI native applications based on DSL mentioned in the first aspect.

[0017] Fourthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the first aspect described above, as well as the computer program code for generating and synchronizing AI native applications based on DSL mentioned in the first aspect.

[0018] The beneficial effects of the second, third, and fourth aspects mentioned above can be referred to the first aspect mentioned above, as well as the relevant descriptions in the various possible implementations of the first aspect, which will not be repeated here. Attached Figure Description

[0019] Figure 1 According to some embodiments of this application, a schematic diagram of a process for generating and synchronizing AI native applications based on DSL is shown; Figure 2 According to some embodiments of this application, a schematic diagram of a specific workflow is shown for a multi-node hybrid intelligent agent to convert natural language requirements into an executable, integrated domain-specific language; Figure 3 According to some embodiments of this application, a schematic diagram of an integrated domain-specific language code structure is shown; Figure 4 According to some embodiments of this application, a schematic diagram of a dual-mode compilation engine workflow is shown; Figure 5 According to some embodiments of this application, a schematic diagram of the interaction principle between a visual editor and a logical intermediate representation (IR) is shown; Figure 6 According to some embodiments of this application, a schematic diagram of the architecture of an integrated domain-specific language application generation and bidirectional synchronization system is shown; Figure 7 According to some embodiments of this application, a schematic diagram of agent generation and bimodal interaction is shown. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] In some related technologies, during the process of building a final executable application system from natural language requirements, especially in ensuring consistency between different forms of business logic representation, directly converting natural language requirements into program code using a large language model at the requirement input stage results in a high error rate and instability due to the lack of deterministic constraints on the business structure, making it difficult to directly generate a reliable application system. If a low-code platform with visual configuration is adopted instead, its closed meta-model prevents natural language from directly driving the process, thus failing to leverage the understanding advantages of the large language model.

[0022] Secondly, during the application building and maintenance phases, the logic generated through visual configuration and the logic implemented through code programming exist in two incompatible representations. Modifications to the visual configuration are difficult to map to code changes, while directly modifying the code would take us outside the visual editing environment. This leads to a sharp decline in system maintainability as business complexity increases, creating a permanent separation between the editing state and the runtime state.

[0023] To address the aforementioned issues, this application proposes an integrated domain-specific language. This integrated domain-specific language can simultaneously describe the business data attributes, interactive visuals, and business logic of business entities within a structured definition, thereby providing a unified and highly cohesive core model for the entire application system. To address the challenge of converting from natural language to this language, a multi-node hybrid intelligent agent is designed. Through a collaborative workflow of "analysis-generation-verification-correction" and a reflective loop of "verification-correction," vague requirements are gradually solidified into precise language definitions, effectively ensuring the accuracy of the generated definitions. To facilitate the conversion from definition to the running system and subsequent maintenance, a dual-mode compilation engine is further designed. This dual-mode compilation engine not only compiles executable program source code and data model definitions from the integrated domain-specific language but also simultaneously generates a logical intermediate representation as an intermediary bridge. It is based on this logical intermediate representation that the system is able to achieve its key features: any edits made by developers to the business logic flowchart in the visual interface can be synchronously updated to the program source code through this logical intermediate representation; conversely, direct modifications to the program source code can also be reversely synchronized to the visual interface, thus fundamentally bridging the gap between the editing state and the running state.

[0024] Through the above technical solutions, this application effectively addresses the core issues in related technologies. On the one hand, the structured conversion and verification process significantly improves the determinism and reliability of application logic generated from natural language. On the other hand, the intermediate logical representation enables bidirectional, lossless synchronization between visual logic editing and program source code, giving the application's construction and maintenance process both intuitive and efficient advantages as well as flexible and precise. Simultaneously, it ensures the inherent consistency of the entire application system across data, logic, and presentation layers, greatly improving the efficiency of full lifecycle management for complex business applications.

[0025] See Figure 1 , Figure 1 This is a schematic diagram of a process for generating and synchronizing AI native applications based on DSL, provided in an embodiment of this application.

[0026] This application provides a method for generating and synchronizing AI native applications based on DSL, the method including steps S101-S105: S101: A multi-node hybrid intelligent agent converts the natural language input by the user and outputs a DSL that conforms to a preset syntax specification. The DSL defines the business data, business logic, and interactive visuals of the business entities.

[0027] S102: Verify and correct the DSL, and output an executable DSL.

[0028] S103: Compiles the executable DSL into program source code, logical intermediate representation and data model definition of business logic through a dual-mode compilation engine.

[0029] S104: Based on the program source code, logical intermediate representation and data model definition of business logic, construct and generate the target application software system.

[0030] S105: Perform visual logic compilation of business logic based on the logical intermediate representation, and update the compilation results to the program source code; and / or, update the logical intermediate representation based on the modification results of the program source code.

[0031] It is understood that the core of the method mentioned in the embodiments of this application lies in using a unified structured language as a hub to achieve automatic conversion from human natural language descriptions to runnable software systems, and to ensure that different forms of logical expression can remain synchronized in subsequent maintenance. Specifically, this method connects the process of creating an application with the process of modifying and maintaining the application through the same technical foundation.

[0032] First, a multi-node hybrid intelligent agent converts the natural language input by the user. Specifically, the multi-node hybrid intelligent agent can be a system or module composed of multiple artificial intelligence modules with different specializations working collaboratively. These modules can include modules with different specializations, such as requirements analysis, code generation, and logic verification. Working together sequentially, these modules gradually transform vague and incomplete user instructions (e.g., "I need an employee leave approval system") into a precise, structured, machine-readable description—that is, an integrated domain-specific language conforming to preset grammatical rules.

[0033] In some embodiments, the natural language input by the user can refer to business requirements expressed in a conversational manner. For example, the natural language input by the user might be, "I need an employee leave approval system that can submit applications, have managers approve them, and automatically deduct annual leave." These statements conform to human communication habits but lack the precise structure and terminology required for computer programming.

[0034] In some embodiments, a DSL (domain-specific language) can be a computer language used to describe software applications. Its key feature is "integration," meaning that the language can simultaneously define the core objects involved in the business, the data structure of the objects, the interaction rules between objects, and the specific business process logic within a unified file or structure. An integrated domain-specific language differs from languages ​​that only describe data interfaces or only describe user interfaces; it integrates all three. In this embodiment, a business entity can refer to the core business objects that the software system needs to manage, such as "orders," "customers," and "leave requests." Specifically, the integrated domain-specific language is used to define the business data, business logic, and interactive visuals of a business entity. Specifically, through this language, one can simultaneously declare which fields (business data) a "leave request" entity contains, the corresponding interactive component types (such as dropdown boxes and date pickers) in the front-end user interface (such as forms and lists) for these fields, their configurable behavioral attributes (such as whether they are read-only or required) (interactive visuals), and the check steps required when submitting a new leave request (business logic). Clearly, in this embodiment, interactive visuals mainly refer to front-end interactions.

[0035] Next, the method includes verifying and correcting the generated unified domain-specific language (IDE) to output an executable IDE. Verifying and correcting the IDE is a quality assurance step. Verification can refer to checking the generated IDE for syntactic and semantic correctness and completeness according to a series of predetermined technical rules. Correction can refer to the process of automatically or semi-automatically modifying and improving it after errors or incompleteness are found. The purpose of this step is to ensure that the blueprint upon which subsequent steps rely is accurate, thereby producing an executable IDE—a language file that can be correctly understood and processed by computer compilation tools without human intervention.

[0036] Then, the executable unified domain-specific language is compiled into three parallel output products using a dual-mode compilation engine. The dual-mode compilation engine can be a translation and generation system with two working modes. The function of the dual-mode compilation engine can be to convert the executable unified domain-specific language file output from the previous stage into multiple different but equivalent technical results in parallel. This conversion and generation process is called compilation.

[0037] The first type of output is the source code for the business logic, which consists of functions or classes written in a general-purpose programming language (such as Python) that implement the defined business processes. This source code implements the business processes and rules defined in the unified domain-specific language and can be executed directly by a computer or after secondary compilation. For example, for the business rule "check leave balance when submitting a leave request," the dual-mode compilation engine can generate a Python function named check_leave_balance.

[0038] The second output is a logical intermediate representation, which is a standardized data structure that lies between the unified domain-specific language and the final program source code. The logical intermediate representation does not depend on any specific programming language. Its core value lies in fully and unambiguously carrying the semantic structure of business logic (such as sequence, branching, and looping), while discarding the syntactic details of specific programming languages, serving as a "universal translation medium" for mutual synchronization between subsequent visual editing and source code.

[0039] The third output is the data model definition, which is a formal description of the business data of a business entity. It specifies the data table structure that needs to be persistently stored, including field names, types, constraints, etc. The data model definition is usually independent of a specific database product (such as MySQL or Oracle) and provides a blueprint for the final generation of the physical database table structure.

[0040] Finally, the various technical outputs generated by the aforementioned compilation steps are integrated, configured, and instantiated to ultimately form a complete software system that users can access, interact with, and use. Specifically, this process can be understood as the "assembly" and "activation" of the various components of the application system.

[0041] Build generation is a comprehensive process. It begins with integration, which involves organizing components such as the business logic source code, database initialization scripts derived from the data model definition, and UI configurations describing front-end interactions, according to the predetermined system architecture, and in accordance with correct dependencies and deployment specifications. For example, this might involve placing the Python program source code in a specific directory on the server and writing its dependency information into a configuration file.

[0042] Furthermore, the build process includes configuration and instantiation. The system utilizes the business process information carried by the logical intermediate representation to configure the runtime behavior of the application system, such as registering API routes and initializing the background task scheduler. Simultaneously, based on the data model definition, the system executes table creation or migration scripts in the target physical database to complete the instantiation of the data storage layer. For the front-end, the system generates or configures corresponding static resources and routes according to the interface description, thereby instantiating a user-interactive browser interface.

[0043] The target application software system is the final product of this series of building actions. It refers to a software application that includes a complete data layer, business logic layer, and user interaction layer, with all layers correctly connected and in a run-ready state. For example, a built "leave approval system" would include a deployed Python backend service (providing an approval API), initialized MySQL database tables (stored leave application data), and a React frontend page accessible through a browser (for submitting and approving leave applications). This system is already a complete entity capable of receiving user requests, processing business logic, and returning results.

[0044] This method achieves bidirectional synchronization capabilities based on a logical intermediate representation. Visualizing business logic through this intermediate representation is a user-oriented approach to logic orchestration. Visual logic compilation refers to users intuitively combining and configuring business logic flows on a graphical interface by dragging and dropping graphical components (such as icons and blocks) and connecting lines. This process does not directly manipulate the program's source code, but rather operates on the underlying logical intermediate representation. A user's connection or parameter modification to the flowchart is essentially an update to the logical intermediate representation data in memory.

[0045] In this embodiment, updating the compilation result to the program source code can mean that after a user completes logic editing visually, the system automatically converts (i.e., compiles) the corresponding, updated intermediate logic representation back into a standardized program source code file, overwriting or updating the original source code file. Conversely, updating the intermediate logic representation based on modifications to the program source code means that when a developer directly modifies the program source code using a text editor, the system can automatically parse the new source code, extract its semantics, and generate an updated intermediate logic representation, thus synchronously refreshing the graphical workflow in the visual interface. Synchronization supports simultaneous execution in any direction or both directions, from visualization to source code and from source code to visualization.

[0046] Thus, by introducing an integrated domain-specific language as a unified core model and building a complete technology chain around it, including intelligent conversion, multiple compilation, and bidirectional synchronization, this approach aims to systematically solve the problem of accuracy in converting natural language to software applications, as well as the disconnect between visual editing and code maintenance in the later stages of application development. This method enables the rapid generation of reliable applications and ensures that applications can evolve and be maintained flexibly and consistently throughout their lifecycle, significantly improving the efficiency of building and iterating complex business applications.

[0047] In some embodiments, a multi-node hybrid agent may include multiple specialized modules that work together to achieve accurate translation from natural language to an integrated domain-specific language. Specifically, the multi-node hybrid agent may include: a requirements analysis module, an encoding module, and a verification module.

[0048] The requirements analysis module can be a component of a multi-node hybrid agent responsible for initially understanding and structuring user requirements. This module can be configured to perform element analysis on natural language based on a structured requirements meta-model, and then use retrieval-enhanced generation techniques to complete missing elements from the domain knowledge base, forming a structured requirements specification. The structured requirements meta-model is a predefined framework that specifies the categories of elements that should be included in describing a complete business requirement, such as core entities, entity attributes, business operations, and rules. The requirement analysis module parses natural language text, identifies, and extracts information related to these element categories. When the analysis finds missing elements in the user description—for example, if the user only mentions "managing customers" without specifying customer attributes—the requirements analysis module will retrieve relevant information from the domain knowledge base using retrieval-enhanced generation techniques.

[0049] In some embodiments, the domain knowledge base can be a data source storing a large amount of business knowledge, best practice documents, and cases related to a specific domain (such as customer relationship management or human resource management). By retrieving knowledge fragments relevant to the current context, the requirements analysis module can automatically complete missing elements, ultimately forming a complete and explicit structured requirements specification. For example, for the requirement of "managing customers," the structured requirements specification formed after completion may explicitly include the "customer" entity, as well as attributes such as "name," "level," and "contact person," and operations such as "add customer" and "edit customer information."

[0050] The encoding module can be a module within a multi-node hybrid agent responsible for generating specific code descriptions. This module can be configured to generate an integrated domain-specific language based on structured requirement specifications. The function of the encoding module is to map and convert structured, machine-readable requirement specifications into an integrated domain-specific language that conforms to a preset syntax specification (e.g., a specific XML schema). This process relies on strict adherence to the syntax rules of the integrated domain-specific language. For example, the encoding module might generate corresponding... <model>Labels and internal <content>Matrix definition.

[0051] The validation module can be a quality control module within a multi-node hybrid agent. This module can be configured to validate the integrated domain-specific language based on deterministic rules. Deterministic rules are a set of explicit, unambiguous, and programmable checking logics, unlike uncertain judgments based on probabilistic models. The validation module's function can be to apply these rules to check the legality, completeness, and internal consistency of the integrated domain-specific language, such as checking whether label closures are correct, whether necessary fields are defined, and whether referenced data sources exist, thereby detecting and preventing errors from propagating to subsequent processes at an early stage.

[0052] In this embodiment, the requirements analysis module ensures accurate understanding and completion of ambiguous requirements, providing high-quality structured input for subsequent steps. The coding module is responsible for the reliable conversion from structured requirements to standardized language code. The verification module acts as a quality checkpoint, ensuring the correctness of the intermediate output (an integrated domain-specific language). This modular and collaborative design effectively improves the overall accuracy, reliability, and automation of the conversion process from natural language to formal language, reducing manual intervention and rework caused by misunderstandings of requirements or errors in code generation.

[0053] See Figure 2 , Figure 2 This is a schematic diagram illustrating the specific workflow of a multi-node hybrid intelligent agent in this application, which converts natural language requirements into an executable, integrated domain-specific language.

[0054] Figure 2 The flowchart describes the specific workflow and internal collaboration mechanism of a multi-node hybrid intelligent agent in converting natural language requirements into an executable, integrated domain-specific language.

[0055] like Figure 2 As shown, the process begins with a natural language requirement input by the user. This requirement is first processed by the requirement analysis module (or Analyst Node). This module uses a general reasoning model to parse the requirement and combines retrieval enhancement generation technology to access the domain knowledge base to fill in missing business elements, forming a more complete and structured requirement description.

[0056] The analyzed or completed requirements are passed to the coding module (or DSL generation node, Coder Node). This coding module, based on a pre-defined unified domain-specific language specification and examples, uses a large programming class model to convert the structured requirement description into an initial unified domain-specific language.

[0057] The generated initial unified domain-specific language then enters the validation module (or validation node, ValidatorNode). This validation module is not based on a probabilistic model, but rather relies on a deterministic rule engine and XML parser. It performs multiple validations, primarily including: schema validation (checking the validity of the XML structure), integrity validation (checking whether essential elements such as attribute definition matrices are complete), and reference consistency validation (checking whether references such as variables are valid). If validation fails, the validation module generates a detailed error log and sends it back to trigger a correction process.

[0058] The process includes manual verification or correction, reflecting human-machine collaboration. Finally, once the integrated domain-specific language passes all checks, it is output as an executable version of the integrated domain-specific language for use in subsequent compilation processes.

[0059] See Figure 3 , Figure 3 This is a schematic diagram of an integrated domain-specific language code structure provided in an embodiment of this application.

[0060] In some embodiments, the unified domain-specific language uses an entity model (corresponding to...) Figure 3 The root node is ModelDefinition, and the entity model includes: an attribute definition matrix and declarative logical units.

[0061] Among them, the attribute definition matrix (corresponding to) Figure 3 The Field Matrix is ​​used to define the attributes of each field in a business entity in the form of a row and column matrix, where columns correspond to fields and rows correspond to different attribute definition dimensions.

[0062] Declarative logic unit (corresponding to) Figure 3 Logic Hooks are used to define business logic for business entities through an ordered sequence of declarative operation instructions. Specifically, this includes logic for data creation (insertOpts) and logic for data writing and updating (writeOpts).

[0063] In some embodiments, an integrated domain-specific language (DNS) uses an entity model as its root node. This means that within a DNS file or code block, all content describing a specific business entity is encapsulated within a top-level structural unit that serves as the starting point. This top-level structural unit is called the entity model. For example, to describe the business entity "leave application," all definitions related to leave applications would be placed within a DNS file or code block... <model name=""leaveapplication”">Within the code blocks that begin and end with the tag, this <model>The label is the root node.

[0064] In some embodiments, the attribute definition matrix can be a component within the entity model, used to systematically define the technical characteristics of each data field contained in a business entity. It is organized as a row-column matrix, where each column corresponds to a specific data field of the business entity, such as "Applicant" or "Start Time." Each row corresponds to a specific attribute definition dimension, describing the characteristics a field should possess from different technical perspectives. These different attribute definition dimensions may include data storage dimensions (such as field type and length), user interaction dimensions (such as component types used in forms), and business rule dimensions (such as validation conditions). Through this matrix layout, all key attributes of a field can be centrally defined and managed in a compact, interconnected view.

[0065] In some embodiments, a declarative logic unit can be another core component within the entity model, used to define the business processes and rules related to that business entity. It adopts a declarative paradigm, defining business logic by orchestrating a series of ordered sequences of operational instructions that describe "what to do" rather than specific "how to do it." A declarative operational instruction is a high-level, semantically clear command; for example, one instruction might declare "create a new leave application record," while another might declare "interrupt the process if the number of leave days exceeds the balance." The ordered sequence ensures that these operational instructions are executed in the expected logical order. For example, in the declarative logic unit of a leave application entity, the sequence of operational instructions could be defined as: validate input data, calculate deductions for leave, create an approval task, and save the leave application record.

[0066] By defining the structure of the unified domain-specific language (DNS) as a root node based on the entity model, and including an attribute definition matrix and declarative logic units, the attribute definition matrix enables centralized and unambiguous definitions of multi-dimensional field attributes, changing the traditional development approach where similar information is scattered across different configuration files. The declarative logic units describe logic in a way that closely aligns with business concepts, making it easier to analyze and automate. This clear and unified structured design makes the DNS not only relatively easy for humans to understand and write, but more importantly, it provides a stable and precisely parsable technical foundation for subsequent automated verification, compilation, and bidirectional synchronization. It is crucial for achieving a reliable conversion from high-level descriptions to executable systems.

[0067] In some embodiments, the attribute definition matrix is ​​specifically implemented as a 12-row definition matrix, with each row corresponding to a specific attribute definition dimension, thereby systematically and completely depicting the full lifecycle attributes of a data field from storage to display. The 12 rows of the definition matrix define the following attributes in sequence: physical field name, business alias, data type, field length, default value, enumeration value and value range, form component type, list component type, data filtering configuration, data update constraints, data validation conditions, and interface grouping information.

[0068] Specifically, the first row of the 12-row definition matrix is ​​used to define the physical field name. The physical field name is the column name corresponding to the field in the underlying database table, serving as a unique technical identifier for storing and identifying the field internally within the system. For example, a field displayed as "Employee Name" on the interface might have its physical field name defined as employeename.

[0069] The second line is used to define field aliases. Field aliases are text labels displayed to users on the front-end user interface (such as form titles and list headers), and are typically in Chinese or other natural languages ​​that better reflect the business context. For example, a field whose physical name is "employee name" could have its field alias set to "Employee Name".

[0070] The third line is used to define the data type. The data type specifies the physical storage format of the field value in the database, such as string, integer, boolean, date and time, which determines how the data is stored and processed.

[0071] The fourth line is used to define the field length. The field length specifies the maximum storage space allocated to the field in the database. For example, the maximum length of a string field can be limited to 50 characters.

[0072] The fifth line is used to define the default value. The default value specifies the initial value that the system automatically assigns when a new record is created and the field value is not explicitly provided.

[0073] The sixth line defines the enumeration value and its range. This line limits the allowed range of values ​​for the field. Specifically, it supports not only static enumeration lists (e.g., defining the range of a status field as "(1: enabled, 9: disabled)"), but also dynamic expressions implemented by referencing context variables. For example, by referencing a predefined list of departments, the option source for the current field can be dynamically bound to the content of another data table, thereby achieving cross-table joins.

[0074] The seventh line is used to define the form component type. The form component type specifies the interactive control used by the field on the data addition or editing page, such as a single-line input box, a drop-down selection box, a date picker, or a hidden field.

[0075] The eighth line defines the list widget type. The list widget type specifies how the field's content is presented on the data list page, such as plain text, hyperlink, tag, or image.

[0076] The ninth line defines the data filter configuration. The data filter configuration declares whether the field is used as a search condition on the list page and configures the type of interactive component used during the search, such as whether range filtering is supported.

[0077] The tenth line is used to define the data update constraint. The data update constraint specifies the behavior pattern of the field under different data operation scenarios (such as creation and update), such as whether editing is allowed, whether assignment is only allowed during creation, and whether it is automatically populated by the server (such as setting it to the current system time).

[0078] The eleventh line is used to define data validation conditions. Data validation conditions specify the legality rules that field values ​​must meet. These rules are usually enforced uniformly on the front end and back end, such as whether a field is required or must match a certain regular expression pattern.

[0079] The twelfth line is used to define UI grouping. UI grouping is used to organize related fields into different groups (such as FieldSet) or tabs in complex detail pages or edit pages, thereby improving the readability and usability of the form.

[0080] By explicitly limiting the attribute definition matrix to the aforementioned 12 rows, developers or systems can complete the definition of all key attributes of fields, from backend storage to frontend interaction and business rules, within a compact and consistent view. This changes the fragmented state of these attributes, which are scattered across multiple places such as database scripts, backend model comments, and frontend configurations in traditional development, greatly improving the efficiency, consistency, and maintainability of the definition, and laying a precise data foundation for subsequent automated generation and synchronization.

[0081] In some embodiments, the specific categories of declarative operation instructions used in declarative logic units collectively constitute the basic set of terms defining business logic. Declarative operation instructions may include at least one of the following types: instructions for declaring or referencing context variables, instructions for performing data persistence operations, instructions for implementing flow control, and assertion instructions for performing verification or confirmation.

[0082] In some embodiments, instructions for declaring or referencing context variables function to create temporary data storage units or reference existing variable values ​​during business logic execution. These instructions enable the logic flow to pass and manipulate intermediate data. For example, one instruction might declare a variable named "total amount" for accumulating amounts, while another might reference the value of a previously defined "order status" variable in a conditional statement.

[0083] In some embodiments, instructions for performing data persistence operations function to add, delete, modify, and query data in the database to achieve persistent storage and modification of business data, which is the foundation for implementing core business operations. For example, one instruction can create a new order record, and another instruction can query a list of customers that meet certain conditions.

[0084] In some embodiments, instructions used to implement flow control function to change the execution path of business logic, implementing complex logical structures such as branches and loops. These instructions endow the business logic flow with the ability to evolve dynamically. For example, the if instruction can determine to execute different logical branches based on specific conditions, and the foreach instruction can traverse a collection and execute the same sub-logical sequence on each element.

[0085] In some embodiments, assertion instructions used to perform validation or confirmation function whether certain business conditions are met, and to interrupt or redirect a specific processing flow in a predictable manner if the conditions are not met. These instructions are used to encapsulate business rules, ensuring data integrity and process compliance. For example, a `check` instruction can verify that an order amount must be greater than zero, and a `confirm` instruction can require confirmation before performing critical operations.

[0086] By limiting declarative operation instructions to types such as variable management, data persistence, flow control, and assertion validation, these instruction types, in a declarative style, cover the core operations required to build complex business logic. This allows the orchestration of business rules to focus on "what to do" rather than specific programming language implementation details. This structured instruction classification not only makes the defined business logic easier to understand and verify, but also provides a clear and precisely processable semantic foundation for subsequent automated compilation, execution, and bidirectional synchronization.

[0087] In some embodiments, the specific verification steps and decision logic executed by the verification module are based on a set of explicit, non-probabilistic deterministic rules, executed sequentially or in parallel according to predefined inspection dimensions, and make a deterministic pass or fail judgment based on the inspection results, thereby driving subsequent processes. Specifically, configuring the verification module to verify an integrated domain-specific language based on deterministic rules may include the following steps: Perform schema validation to verify whether the tag structure of the unified domain-specific language conforms to the predefined XML schema definition.

[0088] Perform an integrity check to verify that the unified domain-specific language includes the specified attribute definitions.

[0089] Perform a reference consistency check to verify that all variables or data sources referenced in the unified domain-specific language have been correctly defined.

[0090] If the tag structure of the unified domain-specific language conforms to the predefined XML schema definition, the unified domain-specific language includes the specified attribute definition, and the variables or data sources referenced in the unified domain-specific language have been correctly defined, the validation passes and the output is a unified domain-specific language that conforms to the preset syntax specification.

[0091] If the tag structure of the integrated domain-specific language does not conform to the predefined XML schema definition, the integrated domain-specific language does not include the specified attribute definition, or the variables or data sources referenced in the integrated domain-specific language are not all correctly defined, the validation fails, and the encoding module corrects the integrated domain-specific language.

[0092] In some embodiments, schema validation is the first basic check, verifying whether the language file being checked conforms to the syntax and structural specifications required of an XML document. Predefined XML schema definitions (such as an XSD file) precisely specify the allowed tag names, tag attributes, and allowed nesting levels between tags. Schema validation verifies the validity of the tag structure by comparing the unified domain-specific language file being checked against this schema definition. For example, it checks whether each start tag has a corresponding end tag. <model>Is it allowed to include inside the tag? <content>Sub-tags, etc., ensure that the file is syntactically well-structured and can be correctly parsed by a standard XML parser.

[0093] In some embodiments, integrity verification is a semantic integrity check performed after the syntax check has passed. Its function is to verify whether the language file contains the core attribute definitions necessary to describe a complete business entity. Specified attribute definitions are a set of mandatory elements predetermined based on the type of the business entity or general rules. For example, for an entity model defined as "leave application," integrity verification checks whether its attribute definition matrix (such as the 12-row matrix mentioned above) fully defines all required fields (such as applicant, start time, and end time), and whether the key attribute rows (such as data type and form components) for each required field are filled in. This ensures that the generated application blueprint is complete in terms of core elements.

[0094] In some embodiments, reference consistency checks are a deeper level of logical consistency checks. Their function is to check whether all referenced symbols (such as variable names, query data source identifiers) in declarative logical units or attribute definitions have been explicitly defined in the appropriate location in the current language file (e.g., in the `defs` section). For example, if a business logic instruction references the variable `approver_id`, the validator will check if that variable has been defined somewhere; if an enumeration value of a field is configured to dynamically reference another data table `department`, the validator will verify whether the `department` data source has been correctly defined and is available. This prevents runtime errors caused by non-existent or misspelled references.

[0095] Based on the results of the three checks mentioned above, the validation module makes a definitive decision. If the tag structure of the unified domain-specific language (DOM) conforms to the predefined XML schema, the DOM includes the specified attribute definitions, and all variables or data sources referenced in the DOM are correctly defined, the validation passes. At this point, the validation module outputs the DOM that conforms to the preset syntax specifications and semantic integrity requirements for use in subsequent compilation steps.

[0096] Conversely, validation fails if the tag structure of the unified domain-specific language (DOM) does not conform to the predefined XML schema, the DOM does not include specified attribute definitions, or the variables or data sources referenced in the DOM are not correctly defined. In this case, the validation module will not output the file but will trigger a correction process. Specifically, the validation failure result (usually containing specific error type and location information) will be fed back to the encoding module. The encoding module will then correct the original DOM description based on this feedback, such as adding missing tags, adding undefined attribute lines, or correcting erroneous reference names, thereby generating a corrected DOM and resubmitting it for validation.

[0097] By explicitly defining the execution mode of the verification module, and implementing a three-tiered, progressive deterministic verification process encompassing integrity and reference consistency, and clearly defining the output and subsequent actions for both successful and failed verification states, this multi-dimensional, deterministic checking mechanism systematically identifies and prevents issues such as syntax errors, missing elements, and logical inconsistencies, significantly improving the quality and reliability of the generated integrated domain-specific language. Furthermore, the setting that triggers encoding module correction upon verification failure initiates an automated "generation-verification-correction" iterative cycle, providing crucial support for an automated process that delivers high-quality output.

[0098] In some embodiments, the specific correction loop steps triggered after the integrated domain-specific language (DNS) verification fails are further defined, describing an automated iterative process including feedback, correction, and re-verification. Specifically, the steps for correcting the DNS include: if the verification module fails, feeding back the verification result containing error information to the encoding module. The encoding module corrects the DNS based on the verification result and generates the corrected DNS, which is then submitted to the verification module for verification. The above steps are repeated until the verification module outputs a successful verification, or a preset iteration termination condition is met, or a user termination instruction is received.

[0099] In some embodiments, feeding back the verification result containing error information to the encoding module is the first step performed after the verification module determines that the verification has failed. This step transmits the verification failure event and its specific cause (i.e., the error information) from the verification module to the encoding module. The error information is typically structured data that not only indicates the verification failure but also includes diagnostic details such as the type of error (e.g., "tag not closed," "definition of required field 'approver' missing," "reference to undefined variable approver_id"), and the specific location of the error in the unified domain-specific language file (e.g., line number, tag path). This structured feedback is a prerequisite for the encoding module to make targeted corrections.

[0100] In some embodiments, the encoding module corrects the unified domain-specific language (DNS) based on the verification results. This is the core operation performed by the encoding module after receiving feedback. The function of the encoding module is to parse the error information in the verification results, understand the problems it indicates, and apply corresponding correction strategies to modify the original DNS description. Correction strategies may include completing missing tags or attributes, correcting erroneous syntax structures, adding missing variable definitions, or correcting reference names. After the correction is complete, the encoding module generates a new, corrected DNS file.

[0101] In some embodiments, submitting the generated modified integrated domain-specific language to the verification module for verification means re-submitting the modified output to the quality control process. This essentially initiates a new "generate-verify" cycle to verify whether the corrective measures have effectively resolved the previously identified issues.

[0102] Repeating the above steps means that the series of operations "error feedback -> code module correction -> resubmit for verification" constitutes a loop. This loop will continue to execute, and its operation is subject to a clearly defined termination condition.

[0103] In some embodiments, the ideal state and primary goal of loop termination is when the verification module outputs a successful verification. This means that after several iterative corrections, the latest version of the unified domain-specific language has successfully passed the verification of all deterministic rules, meeting usable quality requirements, and the loop ends.

[0104] Alternatively, reaching a preset iteration termination condition serves as a safeguard mechanism for loop termination. The preset iteration termination condition is a pre-defined rule to prevent the loop from continuing indefinitely. For example, the condition could be set to "maximum number of loops is 10" or "total processing time does not exceed 30 seconds." When the number of loops or the time reaches the preset limit and the verification still fails, the system will forcibly terminate the loop to avoid wasting resources and may report the problem for manual handling.

[0105] Alternatively, receiving a user-initiated stop command is a user intervention mechanism for terminating the loop. A user-initiated stop command is a command actively issued by the user during the loop's execution. This grants the user control over the automated process; when the user observes that the loop may be stuck or wishes to intervene, they can interrupt the process at any time.

[0106] By explicitly defining the correction steps as a closed-loop process encompassing structured feedback, targeted correction, and re-verification, and by setting three clear termination methods—verification success, reaching preset iteration conditions, and user termination—this mechanism enables the system to autonomously attempt to correct errors generated during the generation process without human intervention. This significantly improves the success rate and automation of the conversion from a flawed initial description to a final, acceptable integrated domain-specific language. Simultaneously, the introduction of preset termination conditions and user termination commands ensures the reliability and security of this automatic loop process, preventing infinite loops or uncontrolled processing, making the entire system's behavior more predictable and manageable.

[0107] In some embodiments, the dual-mode compilation engine is designed to include two complementary sub-modules that collaborate to generate and maintain the association between code and intermediate representations. Specifically, the dual-mode compilation engine includes a forward generation module and a reverse extraction module. The steps of compiling an executable unified domain-specific language into program source code and a logical intermediate representation of business logic using the dual-mode compilation engine include: using the forward generation module, converting declarative business logic instructions in the executable unified domain-specific language into function code conforming to the specifications of a first target programming language, as program source code; using the forward generation module, generating a logical intermediate representation semantically equivalent to the program source code based on the semantic structure of the declarative business logic instructions; and using the reverse extraction module, parsing the program source code using a specific syntax tree parsing tool to extract the logical intermediate representation.

[0108] In some embodiments, the forward generation module is a component of the dual-mode compilation engine responsible for converting high-level descriptions to low-level implementations. One of its core functions is to convert declarative business logic instructions from an executable, unified domain-specific language into function code conforming to the specifications of a first target programming language, serving as the final program source code. The first target programming language can be a general-purpose programming language with a well-established ecosystem, such as Python or Java. Conformity means that the generated code follows the language's accepted standards in terms of syntax, naming conventions, etc. For example, the forward generation module might convert a set of declarative instructions describing "checking the balance and creating a record when submitting a leave request" into a set of source code files containing functions such as `check_balance` and `create_leave_record`. Simultaneously, another core function of the forward generation module is to generate a logical intermediate representation in parallel, based on the semantic structure of the same declarative business logic instructions, during the process of converting and generating the program source code. This logical intermediate representation is semantically equivalent to the generated program source code, meaning that the business rules, execution order, and control flow expressed by both are logically identical, despite their different forms (one is concrete code text, and the other is structured data). This establishes a strict correspondence between the logical intermediate representation and the program source code from the outset.

[0109] In some embodiments, the reverse extraction module is a component of the dual-mode compilation engine responsible for reversing the structured logic description from an existing implementation. Its function is to use a concrete syntax tree (PTB) parsing tool to parse existing program source code and extract an intermediate logical representation. A PTB parsing tool is a software library capable of parsing source code text into a tree structure (i.e., a concrete syntax tree) that preserves all syntactic details (including comments, spaces, and formatting), such as the LibCST library for Python. The reverse extraction module utilizes such tools to deeply analyze the syntactic structure of the source code, identify elements such as function definitions, control flow statements (e.g., if, for), and variable operations, and, according to predefined mapping rules, restore (i.e., extract) these specific code structures into a corresponding, standardized intermediate logical representation. For example, when a developer directly modifies the implementation code of the check_balance function, the reverse extraction module can parse the Python source code file, identify the updated conditional logic, and generate an updated intermediate logical representation data structure accordingly.

[0110] By defining the dual-mode compilation engine as comprising a forward generation module and a reverse extraction module, and clarifying their collaborative working steps, the forward generation module achieves reliable and synchronous generation from a unified DSL to executable code and a standard intermediate representation, laying the foundation for application operation and subsequent synchronization. The reverse extraction module provides the ability to losslessly reconstruct the logical structure from modified code, which is crucial for synchronizing code-side modifications with the visualization side. These two modules work together to ensure the authority and bridging role of the intermediate logical representation as a "single source of truth," enabling accurate and reliable bidirectional conversion and synchronization between the two distinct modification methods of visual logic editing and program source code editing. This technically supports an efficient and seamless hybrid development and maintenance model.

[0111] In some embodiments, the specific compilation step of generating a data model definition using a dual-mode compilation engine is a refinement of the "compile to data model definition" action, focusing on how to extract and form an abstract blueprint for the persistence layer from the unified description. Specifically, the steps of compiling an executable unified domain-specific language into a data model definition using a dual-mode compilation engine include: parsing the data storage-related attribute definitions in the executable unified domain-specific language to generate a data model definition independent of a specific database engine.

[0112] In some embodiments, parsing the data storage-related attribute definitions in the executable unified domain-specific language is the primary operation for generating data model definitions. Here, "parsing" refers to the dual-model compilation engine reading and analyzing the validated unified domain-specific language file, identifying and extracting all attribute information specifically describing how data should be persistently stored. These data storage-related attribute definitions may include, but are not limited to, the relevant rows in the 12-row definition matrix described in the above embodiments, such as physical field names (corresponding database column names), data types, field lengths, default values, etc. The compilation engine's function is to systematically collect these storage attributes scattered across the fields in the attribute definition matrix and logically aggregate and organize them.

[0113] In some embodiments, generating a data model definition independent of a specific database engine is the target output of the parsing step. Here, "independent of a specific database engine" means that the generated data model definition is an abstract logical model that only describes the structure, constraints, and relationships of the data itself (for example, a model named "Leave Application" contains a character-type "Title" field and an integer-type "Days" field, and the "Title" field cannot be empty), without containing any dialects, syntax, or implementation details specific to a particular database management system (such as MySQL, Oracle, or PostgreSQL). The data model definition is typically expressed in a neutral, standardized data format (such as JSON or YAML). Its core value lies in serving as a "design draft" of the database structure, providing a unified description of business requirements while connecting to various possible specific database physical implementations, thus playing a crucial decoupling role. For example, based on the same data model definition, the system can subsequently generate CREATE TABLE statements for MySQL or table creation scripts for Oracle using different database adapters.

[0114] By explicitly defining the generation method of the data model definition as storage attributes in the parsing language and forming a database engine-neutral abstract model, the business data design of business entities can be completed uniformly at a high level in an integrated domain-specific language, and then flexibly mapped to different database technology stacks during deployment. This approach improves decoupling, portability, and maintainability because any modification to the data structure only needs to be performed once in the integrated domain-specific language, and can be automatically synchronized to the abstract data model definition through this step, and then applied to the physical database through subsequent mechanisms, avoiding repetitive and error-prone modifications in multiple places (such as SQL scripts in multiple databases).

[0115] like Figure 4 The diagram showing the workflow of the dual-mode compilation engine illustrates the internal processes and data conversion relationships of the dual-mode compilation engine in compiling an executable, unified domain-specific language into multiple runtime components in parallel.

[0116] The process takes an executable, unified domain-specific language as input, which is then uniformly parsed and distributed by a dual-mode compilation engine. The engine initiates parallel processing pipelines based on the definitions of different properties within the executable unified domain-specific language.

[0117] For data storage-related attribute definitions (parsing Content storage attributes), the dual-model compilation engine performs data layer compilation. This process generates a data model definition independent of a specific database, which is then converted into a specific SQL data definition language through a database adapter (such as the MySQL adapter in the example shown in the figure) and executed. Finally, the corresponding table structure is created or updated in the physical database, completing the physical instantiation of the data.

[0118] For declarative instructions related to business logic (parsing Insert / Edit Opts), the dual-model compilation engine performs logic layer compilation. This process relies heavily on the forward generation module (labeled as Programming Model / AI Coder in the diagram), which converts declarative instructions into executable, compliant business logic source code (as shown in the Python code example in the diagram). This code is then deployed to a server-side container for execution. Simultaneously, the forward generation module generates an intermediate logical representation that is semantically completely equivalent to the source code. Furthermore, the diagram uses a "reverse extraction" arrow to indicate the working path of the reverse extraction module (labeled as Code Converter / Python Parser in the diagram), which can parse and extract the intermediate logical representation from existing source code.

[0119] For user interaction-related attribute definitions (parsing UI interaction attributes), the dual-mode compilation engine performs presentation layer compilation. This process converts the UI attributes defined in the executable unified domain-specific language into attribute configuration objects, and drives the dynamic instantiation of a generic front-end module through parameter injection, ultimately generating a business management page that runs in the browser.

[0120] The generated logical intermediate representation serves as the core hub. On the one hand, it can be used to drive the visual logic editor, rendering the logical structure into a draggable and editable flowchart. On the other hand, as mentioned earlier, it is also the technical foundation for connecting the program source code and the visual editor, and achieving bidirectional synchronization.

[0121] In some embodiments, the application generation process is extended to include the ability to sustainably maintain the data structure. Specifically, the method may further include: displaying the data model definition in a structured form through a data model editing interface; and generating and executing a corresponding database migration script in response to modifications made to the data model definition through the data model editing interface to synchronize the modifications to the physical database constructed according to the data model definition.

[0122] In some embodiments, a data model editing interface, which displays the data model definition in a structured form, provides developers or operations personnel with a dedicated graphical interface. The function of this interface is to present the abstract data model definition in an intuitive, readable, and easy-to-operate structured format. Specifically, this structured format can be represented as a two-dimensional table, where each row corresponds to a field in the data model definition, and columns correspond to different attributes of the field, such as field name, data type, whether it is a primary key, and whether null values ​​are allowed. For example, developers can see an Excel-like table in this interface, clearly listing all the fields and their technical attributes contained in the "Leave Request" entity. This design greatly reduces the technical barrier to directly understanding and manipulating the original definition file (such as JSON).

[0123] In some embodiments, responding to modifications to the data model definition via the data model editing interface means that the system listens for and processes operations performed by the user on the data model editing interface. Users can perform operations such as adding or deleting fields, modifying field types or constraints. These operations directly affect the data model definition stored in memory or on the server, modifying its internal structured descriptive data.

[0124] In some embodiments, generating and executing a corresponding database migration script is an automated response by the system to the aforementioned modifications. Specifically, when a change in the data model definition is detected, the system automatically calculates the structural differences between the old and new versions. Based on the calculated differences (e.g., adding a remark field or changing the type of the status field from integer to string), the system calls a template or rule engine to generate a standard data definition language script that matches the target database type—the database migration script. After generating the script, the system automatically or after confirmation submits it to the target database for execution.

[0125] In some embodiments, synchronizing modifications to the physical database built according to the data model definition indicates the ultimate goal of the aforementioned automated process. "Physical database built according to the data model definition" refers to the actual database tables initially created based on that data model definition. By executing the generated migration script, edits made to the data model definition are applied precisely and in real-time to the corresponding physical database table structure, thereby ensuring strict consistency between the visual design view and the underlying database runtime state.

[0126] By employing visual editing and automatic synchronization of the data model, a complete closed loop for low-barrier, visual maintenance of the data persistence layer is constructed. It allows users to adjust the data structure through an intuitive interface rather than writing complex SQL statements, while the system automatically translates design changes into executable database operations. This mechanism significantly reduces the technical difficulty and error risk of database structure management, and ensures real-time consistency between the data model definition and the physical database structure throughout the entire lifecycle from design and generation to operation and maintenance. This greatly improves the efficiency and reliability of data model iteration when requirements change.

[0127] like Figure 5 The diagram shows the interaction principle between the visual editor and the logical intermediate representation (IR).

[0128] The visual editor does not directly manipulate the source code; instead, it is bidirectionally bound to the logical intermediate representation in memory. When users edit the business logic flowchart by dragging, connecting, or configuring graphical blocks (each block corresponds to a node in the logical intermediate representation, such as a conditional block or a data manipulation block), all user operations are translated into data update instructions for the logical intermediate representation in real time. For example, if a user adds an "IF" block, the visual editor creates the corresponding control node in the logical intermediate representation and updates the connection relationships between the nodes.

[0129] Connecting the visual editor, the intermediate logical representation, and the program source code are two clear bidirectional arrows, representing bidirectional data flow. From code to visualization (reverse synchronization): When a developer directly modifies and saves text in the source code editor, the reverse extraction module (part of the dual-mode compilation engine) is triggered. The reverse extraction module uses a specific syntax tree parsing tool to parse the new source code, understand its semantic structure, and reconstruct (extract) the updated intermediate logical representation accordingly. This new intermediate logical representation is synchronized into memory and immediately drives the visual editor to re-render, causing the graphical flowchart to automatically update to match the modified code.

[0130] From Visualization to Code (Forward Synchronization): After the user completes graphical editing in the visual editor, the intermediate logical representation in memory has been updated. At this point, the system can manually or automatically trigger the forward generation module (part of the dual-mode compilation engine). The forward generation module uses the latest intermediate logical representation as its sole input and, through a pre-built code generator or template engine, regenerates complete, compliant program source code, overwriting or updating the original source code files.

[0131] Regardless of which end initiates the modification, it must be completed by updating the intermediate logical representation, which is then synchronized to the other end. This architecture completely decouples visual editing from code writing, allowing the two editing modes to be used independently, in parallel, or alternately, while always maintaining strict consistency in the business logic semantics expressed by both, thus achieving true and reliable bidirectional synchronization.

[0132] This application transforms natural language requirements into a structured, executable, integrated domain-specific language through a multi-node hybrid intelligent agent, and verifies and corrects this language. This effectively ensures the determinism of the generated application business logic and significantly reduces common logical errors or semantic ambiguities when directly generating program code from natural language.

[0133] Furthermore, through a dual-mode compilation engine, standard program source code and intermediate logical representation are simultaneously generated from the unified domain-specific language. Using this intermediate logical representation as the core medium, a bidirectional, lossless synchronization channel is established between visual logic editing operations and program source code. This allows developers to intuitively and efficiently edit business logic visually while directly maintaining or optimizing program source code. Modifications made in both methods are automatically and accurately synchronized to the other, completely resolving the problem of the separation between visual editing and code execution. Since the entire application (including data models, business logic, and interaction definitions) originates from a single unified domain-specific language description and is maintained through the same compilation and synchronization mechanism, the inherent consistency of the data layer, logic layer, and presentation layer within the application system is ensured, greatly reducing the complexity and inconsistency risks of later system maintenance.

[0134] See Figure 6 , Figure 6 This is a schematic diagram of the architecture of an integrated domain-specific language application generation and bidirectional synchronization system provided in this application embodiment.

[0135] This application provides an application generation and bidirectional synchronization system based on an integrated domain-specific language, including: The requirements understanding and definition layer is configured to convert user-input natural language into an integrated domain-specific language that conforms to preset grammatical rules through a multi-node hybrid intelligent agent.

[0136] The verification and correction layer is configured to verify and correct the integrated domain-specific language and output an executable integrated domain-specific language.

[0137] The multidimensional compilation and generation layer is configured to compile the executable integrated special-purpose language into program source code, logical intermediate representation and data model definition of business logic, and is configured to build and generate the target application software system based on the program source code, logical intermediate representation and data model definition of business logic.

[0138] The runtime and interaction layer is configured to achieve bidirectional synchronization between the visual logic editing and the program source code based on the logical intermediate representation.

[0139] like Figure 6 As shown, in some specific application scenarios, the Input & Definition layer serves as the system input and requirement structuring component. The process begins with user input, which is processed by a multi-node hybrid intelligent agent (illustrated in the diagram as multimodal parsing & RAG and architect large model translation, illustrating their internal collaboration), ultimately outputting a structured, unified domain-specific language (labeled as the full business DSL (XML Protocol) in the diagram). The multidimensional compilation and generation layer (CompilationEngine) is the core compilation and transformation component, centered on a dual-mode compilation engine (specifically represented as an AI code generator and an SQL migration executor in the diagram). It receives the unified domain-specific language output from the previous layer and performs parallel compilation, generating three products: the program source code for the business logic (Python source code), the intermediate logical representation (labeled as the logical AST model (LogicIR) in the diagram), and the data model definition (driving the SQL migration executor).

[0140] The system may also include an Agent Factory, which is responsible for the construction and management of agents. Based on the generated logical intermediate representation and business context, it creates a dedicated digital agent for each business entity through a DAG process generator and tool wrapper.

[0141] The Runtime & Interaction layer is the part where the final application runs and interacts with the user. The generated application system (Application GUI) runs in a general front-end host. Users can interact with the system in two modes: Agent mode (Mode 1), where users directly drive the digital employee through natural language commands; Assistant mode (Mode 2), where the digital employee listens for events and proactively provides suggestions when the user operates the graphical interface.

[0142] like Figure 7 The diagram shown illustrates agent generation and bimodal interaction. Figure 7 It describes the architecture for generating dedicated intelligent agents for business entities, and the two core interaction modes of these intelligent agents during application runtime.

[0143] The starting point of the process (left side) is the definition layer, which is based on the generated structured deliverables, including: data model definitions describing the data structure, logical operation definitions describing business rules (such as declarative operation instruction sequences), and structured requirements documents containing business context. These definitions together constitute the business knowledge foundation of the intelligent agent.

[0144] These definitions are input into the construction layer. This layer contains a DAG process generator, used to orchestrate standardized cognitive and execution workflows (directed acyclic graphs) for agents; it also contains a prompt word builder, responsible for transforming the aforementioned business definitions and rules into system prompt words that can be understood by a large language model. The output of this layer is a runnable, dedicated agent (or native AI agent) bound to a specific business entity.

[0145] The generated dedicated intelligent agent is activated at the runtime layer and works collaboratively with the final user interface (React business pages, i.e., part of the generated application system) in a built-in or plug-in manner. The intelligent agent provides two deep interaction modes: the first is the agent mode, where the user inputs natural language commands through an independent dialogue interface, and the intelligent agent autonomously analyzes, calls toolsets (such as functions for manipulating data), and completes the task; the second is the assistant mode, where when the user performs routine operations such as clicking and browsing on the business page, the intelligent agent listens to the context in the background, actively infers, and pushes suggested cards, which the user can click to execute the intelligent agent's suggested operations with one click.

[0146] This application also provides a server, including: a memory and one or more processors, wherein the memory is used to store instructions executed by the one or more processors, and the processors are used to execute the generation and synchronization of DSL-based AI native applications mentioned in any of the above embodiments of this application.

[0147] This application also provides a computer-readable medium storing instructions that, when executed on a server, cause the server to perform the DSL-based AI native application generation and synchronization mentioned in any of the above embodiments of this application.

[0148] This application also provides a computer program product, including: a computer program / instruction, which, when executed by a processor, implements the computer program code for generating and synchronizing AI native applications based on DSL mentioned in any of the above embodiments of this application.

[0149] It should be noted that all units / modules mentioned in the device embodiments of this application are logical units / modules. Physically, a logical unit / module can be a physical unit / module, a part of a physical unit / module, or a combination of multiple physical units / modules. The physical implementation of these logical units / modules themselves is not the most important factor; the combination of functions implemented by these logical units / modules is the key to solving the technical problems proposed in this application. Furthermore, to highlight the innovative aspects of this application, the above-described device embodiments of this application have not introduced units / modules that are not closely related to solving the technical problems proposed in this application. This does not mean that the above-described device embodiments do not contain other units / modules.

[0150] It should be noted that, in the examples and description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one" does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0151] Although this application has been illustrated and described with reference to certain embodiments thereof, those skilled in the art should understand that various changes in form and detail may be made thereto without departing from the spirit and scope of this application.

[0152] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the protection scope of this application.< / content> < / model> < / model> < / model> < / content> < / model>

Claims

1. A method for generating and synchronizing AI native applications based on DSL, characterized in that, The method includes: The natural language input by the user is converted by a multi-node hybrid intelligent agent and outputs a DSL that conforms to the preset syntax rules; the DSL is used to define the business data, business logic and interactive visuals of the business entity. The DSL is verified and corrected, and an executable DSL is output. The executable DSL is compiled into the program source code, logical intermediate representation and data model definition of business logic by a dual-mode compilation engine; Based on the program source code, logical intermediate representation and data model definition of the business logic, the target application software system is constructed and generated; The business logic is visualized and compiled based on the intermediate logical representation, and the compilation result is updated to the program source code; and / or, the intermediate logical representation is updated based on the modification result of the program source code.

2. The method according to claim 1, characterized in that, The multi-node hybrid agent includes: The requirements analysis module is configured to perform element analysis on the natural language based on the structured requirements meta-model, and to fill in the missing elements from the domain knowledge base through retrieval enhancement generation technology to form a structured requirements specification. The encoding module is configured to generate the DSL based on the structured requirements specification; The verification module is configured to verify the DSL based on deterministic rules.

3. The method according to claim 1, characterized in that, The DSL uses the entity model as its root node, and the entity model includes: An attribute definition matrix is ​​used to define the attributes of each field in the business entity in the form of a row and column matrix; where columns correspond to fields and rows correspond to different attribute definition dimensions. A declarative logic unit is used to define the business logic for the business entity through an ordered sequence of declarative operation instructions.

4. The method according to claim 3, characterized in that, The attribute definition matrix is ​​a 12-row definition matrix, with each row defining the following attributes in sequence: physical field name, business alias, data type, field length, default value, enumeration value and value range, form component type, list component type, data filtering configuration, data update constraint, data validation condition, and interface grouping information.

5. The method according to claim 3, characterized in that, The declarative operation instructions include at least one of the following types: instructions for declaring or referencing context variables, instructions for performing data persistence operations, instructions for implementing flow control, and assertion instructions for performing verification or confirmation.

6. The method according to claim 2, characterized in that, The steps of configuring the verification module to verify the DSL based on deterministic rules include: Perform pattern validation to verify whether the tag structure of the DSL conforms to the predefined XML pattern definition; Perform an integrity check to verify whether the DSL includes the specified attribute definition; Perform a reference consistency check to verify that all variables or data sources referenced in the DSL have been correctly defined; If the tag structure of the DSL conforms to the predefined XML schema definition, the DSL includes specified attribute definitions, and all variables or data sources referenced in the DSL have been correctly defined, the validation passes, and a DSL conforming to the preset syntax specification is output; or, If the tag structure of the DSL does not conform to the predefined XML schema definition, the DSL does not include the specified attribute definition, or the variables or data sources referenced in the DSL are not all correctly defined, the verification fails, and the encoding module corrects the DSL.

7. The method according to claim 6, characterized in that, The steps for correcting the DSL include: If the verification module fails, the verification result containing error information will be fed back to the encoding module. The encoding module corrects the DSL based on the verification result and generates a corrected DSL, which is then submitted to the verification module for verification. Repeat the above steps until the verification module outputs a verification pass, or reaches the preset iteration termination condition, or receives a user stop instruction.

8. The method according to claim 1, characterized in that, The dual-mode compilation engine includes: a forward generation module and a reverse extraction module; The steps of compiling the executable DSL into program source code and intermediate logical representation of business logic using the dual-mode compilation engine include: The forward generation module converts the declarative business logic instructions in the executable DSL into function code that conforms to the first target programming language specification, which serves as the program source code. The forward generation module generates a logical intermediate representation that is semantically equivalent to the program source code, based on the semantic structure of the declarative business logic instructions. The reverse extraction module uses a specific syntax tree parsing tool to parse the program source code in order to extract the logical intermediate representation.

9. The method according to claim 1, characterized in that, The steps of compiling the executable DSL into the data model definition using the dual-mode compilation engine include: Parse the data storage-related attribute definitions in the executable DSL to generate the data model definition that is independent of a specific database engine.

10. The method according to claim 1, characterized in that, The method further includes: The data model definition is displayed in a structured form through the data model editing interface; In response to modifications made to the data model definition through the data model editing interface, a corresponding database migration script is generated and executed to synchronize the modifications to the physical database constructed based on the data model definition.

11. A DSL-based AI native application generation and synchronization system, characterized in that, The system includes: The requirements understanding and definition layer is configured to convert user-input natural language into a DSL that conforms to a preset syntax specification through a multi-node hybrid intelligent agent; The verification and correction layer is configured to verify and correct the DSL and output an executable DSL. The multidimensional compilation and generation layer is configured to compile the executable integrated special-purpose language into program source code, logical intermediate representation, and data model definition of business logic; and is configured to build and generate the target application software system based on the program source code, logical intermediate representation, and data model definition of the business logic. The runtime and interaction layer is configured to achieve bidirectional synchronization between the visual logic editing and the program source code based on the logical intermediate representation.

12. A computer program product, characterized in that, It includes a computer program / instruction, which, when executed by a processor, implements the DSL-based AI native application generation and synchronization method as described in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the DSL-based AI native application generation and synchronization method as described in any one of claims 1 to 10.

Images