A dynamic synergistic controllable generation system and method thereof

Abstract

The application relates to the technical field of software development, and particularly discloses a dynamic cooperative controllable generation system and a method thereof, which comprises a data layer used for storing instruction set configuration data, business requirement data and output data; an instruction set layer comprising a plurality of standardized paradigm instruction sets, each of which internally comprises an atomic instruction chain; a cooperative routing layer used for dynamically organizing and connecting the paradigm instruction sets according to a current business scene of a user and executing the paradigm instruction sets; the cooperative routing layer is also used for receiving output results and checking states of the instruction set layer, combining the business requirement data and error marking data of the data layer, and making real-time decisions on the next executed paradigm instruction set, atomic instruction, or triggering a rollback, repair or termination operation; and an application layer used for receiving business requirement data submitted by the user, analyzing the business requirement data and sending the analyzed business requirement data to the cooperative routing layer. The technical scheme of the application can realize controllability and accountability in an enterprise-level business generation scene.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a dynamic, collaborative, and controllable generation system and method thereof. Background Technology

[0002] Currently, agent technology in the field of artificial intelligence is developing rapidly. The core design of mainstream agent platforms revolves around "role division + external tool invocation." Its core logic is: after receiving user requests, it autonomously plans and executes steps through a large model, invoking corresponding roles or external tools (such as search engines, code interpreters, database APIs, etc.) to complete the task. This type of technology has certain applicability in scenarios such as general question answering and simple task processing. However, in enterprise-level, high-standard, and highly constrained business generation scenarios, it suffers from the following intractable technical shortcomings: Unreasonable core abstraction and uncontrollable generation process: Mainstream intelligent agents take "roles / tools" as the core abstraction, and have not been customized for the "standardization and high compliance" requirements of enterprise-level business generation. The generation process is a black box-style single-round coarse-grained generation, which cannot control the generation details and is prone to problems such as output format errors, logical contradictions, and non-compliance with business specifications, making it difficult to meet enterprise-level commercial requirements.

[0003] The collaboration path is rigid or disordered, lacking a balance between flexibility and controllability: In existing technologies, either a fixed preset workflow is used, and the instruction execution path is rigid, which cannot cope with the complex and ever-changing enterprise-level business needs; or the collaboration path is planned autonomously by a large model, which has problems such as being unreproducible, undebuggable, and prone to deviation, and cannot guarantee the stability of online services.

[0004] Errors are difficult to attribute to causes, and iterative optimization is costly: The output of mainstream intelligent agents is a holistic result. If an error occurs, it is impossible to accurately locate the specific link and cause of the error. Optimization can only be achieved by rewriting the entire code or by generalizing and fine-tuning. This results in low iteration efficiency, high computing and human resource costs, and makes it difficult to form a closed loop of continuous optimization.

[0005] Poor multi-task adaptability and high operation and maintenance costs: Most platforms adopt the model of "one model per task" or "one agent per scenario". Core capabilities cannot be reused between multiple tasks, and the cost of model operation and maintenance and data management increases exponentially, making it difficult to support enterprise-level deployment in multiple industries and scenarios.

[0006] In summary, existing intelligent agent technologies cannot address the core requirements of "controllability, attributability, iterability, and low cost" in enterprise-level high-standard business generation scenarios. There is an urgent need for a dynamic collaborative controllable generation system and method that can achieve controllability and attributability in enterprise-level business generation scenarios. Summary of the Invention

[0007] One of the objectives of this invention is to provide a dynamic, collaborative, and controllable generation system that can achieve controllability and attributability in enterprise-level business generation scenarios.

[0008] To solve the above-mentioned technical problems, this application provides the following technical solution: A dynamic, collaborative, and controllable generation system, comprising: The data layer is used to store instruction set configuration data, business requirement data, output data, error marker data, correction marker data, domain-specific correction datasets, and model fine-tuning related data. The instruction set layer includes multiple standardized paradigm instruction sets. Each paradigm instruction set contains atomic instruction chains, which are composed of several atomic instructions connected sequentially or in branches. The collaborative routing layer is used to dynamically organize and connect paradigm instruction sets according to the user's current business scenario, and execute them; it is also used to receive the output results and verification status of the instruction set layer, and combine them with the business requirement data and error marking data of the data layer to make real-time decisions on the next paradigm instruction set and atomic instruction to be executed, or to trigger rollback, repair, and termination operations, so as to realize dynamic collaboration between paradigm instruction sets. The application layer is used to receive business requirement data submitted by users, parse the business requirement data and send it to the collaborative routing layer; it is also used to display the final generated results, output data and correction records.

[0009] Furthermore, the instruction set configuration data includes the unique identifier of the paradigm instruction set, business scenario tag, and applicable domain type; the structural information of the atomic instruction chain; the configuration information of each atomic instruction; the association between paradigm instruction sets and their operating parameters; and keywords. Paradigm instruction set mapping relationships and error marking rules.

[0010] Furthermore, each atomic instruction performs only a single task; the execution process of each atomic instruction is as follows: receive input data, generate output results according to the instruction description and Prompt template, verify the output according to the verification rules, if the verification passes, send the output results and verification status to the cooperative routing layer; if the verification fails, mark the error type, send the output results and verification status to the cooperative routing layer, and the cooperative routing layer decides whether to trigger repair or rollback.

[0011] Furthermore, the application layer is also used to provide a manual correction entry point, receiving user modifications to the output of each stage and adding correction markers.

[0012] The second objective of this invention is to provide a dynamic, collaborative, and controllable generation method, characterized by comprising the following steps: S1. The application layer receives the business requirements input by the user, parses the business requirement data to obtain the requirement keywords, business scenario tags, and generation targets, and sends them to the collaborative routing layer. S2. The collaborative routing layer selects an initial paradigm instruction set from the instruction set layer based on the requirement keywords and business scenario tags, and triggers the execution of the first atomic instruction in the atomic instruction chain within the instruction set. After the atomic instruction is executed, the collaborative routing layer receives its output result and verification status. S3, the collaborative routing layer, combines verification status, error marking rules from the data layer, and business scenario constraints to determine the following through a decision algorithm: If the current atomic instruction is the last atomic instruction within the paradigm instruction set and the verification passes, proceed to step S4; if the verification fails, the corresponding repair instruction set is executed, and after the repair is completed, return to step S2. If the instruction set is not executed to the end and the verification passes, the next atomic instruction of the instruction set is executed and the process returns to step S2; if the verification fails, the corresponding repair instruction set is executed and the process returns to step S2 after the repair is completed. S4. The collaborative routing layer determines whether the output of the current paradigm instruction set meets the user's overall requirements: if it does, the final result is output to the application layer and the process terminates; if it does not, based on the current output result and business requirements, the next associated paradigm instruction set is scheduled from the instruction set layer, and the process returns to step S2 until a result that meets the requirements is generated or the termination condition is triggered.

[0013] Furthermore, in step S3, the decision algorithm combines hard rules and model assistance to make a judgment. Hard rules are used to handle deterministic scenarios; model assistance is used to handle fuzzy scenarios. The specific steps are as follows: During the rule matching phase, the current execution status is received and matched with the preset routing rule base. If the match is successful, the scheduling result is output directly. During the model-assisted phase, if rule matching fails, a preset base model is invoked, and the current context and associated instruction set list are input to obtain priority sorting suggestions from the model output. In the decision output phase, the final scheduling instruction is output based on the rule matching results or model priority suggestions, and the scheduling log is recorded.

[0014] Furthermore, it also includes: S5. After the execution of each atomic instruction and paradigm instruction set is completed, the application layer provides a manual correction entry point to obtain the user's modifications to the output content and the added correction flags, and generate correction flag data. S6. The data layer stores the correction marker data, the original output data, and the corrected output data, classifies and archives them to form a domain-specific correction dataset. S7. Regularly analyze the error rate and error type distribution of each instruction set and each atomic link to identify weak links; S8. For weak links, the following two optimization methods are adopted: Optimize the atomic instruction Prompt and verification rules in this step; Extract the correction dataset for this step, use the QLoRA lightweight fine-tuning method to perform directional fine-tuning of the base model, and record the relevant data of model fine-tuning; S9. Update the optimized atomic instruction Prompt and verification rules to the corresponding paradigm instruction set, and deploy the fine-tuned base model to the platform to complete one iteration; repeat steps S6-S9 to achieve continuous optimization.

[0015] This solution's atomic instructions, with their single-task attributes and built-in verification rules, decompose the generation process from a black-box, coarse-grained output into standardized, monitorable, and verifiable steps, solving the technical problems of uncontrollable generation processes and difficulty in locating errors. The collaborative routing layer dynamically decides the next execution unit or triggers repair based on real-time verification status and preset rules, avoiding path rigidity and ensuring the reproducibility and debuggability of the collaborative process. The manual correction entry provided by the application layer can accurately collect correction marks from each step and store them in the data layer. Combined with error marking rules and relationships in the instruction set configuration data, it provides an attributable data foundation for continuous optimization, achieving a low-cost, high-efficiency iterative closed loop, and ultimately supporting the stable output of highly compliant generation results in multiple business scenarios.

[0016] In summary, this solution achieves controllability, attributability, and iterability in the enterprise-level business generation process. Attached Figure Description

[0017] Figure 1 This is a logic block diagram of a first embodiment of a dynamic, collaborative, and controllable generation system; Figure 2 This is a flowchart of an embodiment of a dynamic, collaborative, and controllable generation method. Detailed Implementation

[0018] The following detailed description illustrates the specific implementation method: Example 1 like Figure 1 As shown, a dynamic collaborative controllable generation system in this embodiment includes: a data layer, an instruction set layer, a collaborative routing layer, and an application layer.

[0019] The data layer is used to store instruction set configuration data, business requirement data, output data, error flag data, correction flag data, domain-specific correction datasets, and model fine-tuning related data; Instruction set configuration data includes, but is not limited to: the unique identifier, name, version number, business scenario tag, and applicable domain type of the paradigm instruction set; the structural information of the atomic instruction chain: the execution order, dependencies, and serial / branch logic of the atomic instructions; the configuration information of each atomic instruction: instruction description, input data specifications, output data specifications, validation rules, and prompt template; the association between paradigm instruction sets and the identifier of the target instruction set to jump to; the instruction set's activation status, priority, execution timeout threshold, number of retries, and iteration update records; runtime parameters; and keywords. Paradigm instruction set mapping relationships and error marking rules, etc.

[0020] Error marking rules are predefined conditions for judging the validity of output, including conditions for missing fields, format errors, logical contradictions, syntax errors, and incorrect relationships. Specifically, examples include: rules for missing fields, rules for JSON syntax errors, rules for master-detail table relationship errors, and rules for empty output.

[0021] Error flags include, but are not limited to: a unique error identifier; the identifier of the instruction set to which it belongs, the identifier of the atomic link, and the sequence number of the execution step; the error type: such as format error, missing field, logical contradiction, syntax error, out-of-bounds range, incorrect association, non-compliance, etc.; the error description: a textual description of the error content; the original input content and the original output content; the validation rule identifier: indicating which validation rule triggered the error; the error level: fatal / general / warning; and the suggested handling methods: rollback, retry, call the repair instruction set, and terminate the process.

[0022] Correction marker data includes, but is not limited to: the associated unique error identifier; the identifier of the instruction set of the paradigm, the identifier of the atomic link, and the sequence number of the execution step; the error type and the error reason; the original output content; the corrected output content; the business scenario label; the person who made the correction and the correction time; and the correction description.

[0023] The instruction set layer includes multiple standardized paradigm instruction sets. Each paradigm instruction set corresponds to a fixed enterprise-level business generation paradigm (such as production system architecture generation, Python data model code generation, JSON format repair, etc.). Each paradigm instruction set contains a fine-grained atomic instruction chain. The atomic instruction chain consists of several atomic instructions connected in sequence or by branches. Each atomic instruction performs only a single task and has clear input / output specifications and verifiable rules.

[0024] Specifically, the paradigm instruction set in this embodiment is a standardized, reusable, and independently iterable minimum business execution unit, and its core attributes include: Instruction set identifier: Uniquely identifies a paradigm instruction set, used for coordinated routing layer scheduling and error attribution; Business paradigm description: Clearly define the business scenario and generation goal corresponding to this instruction set; Atomic instruction chain: Consists of several atomic instructions connected sequentially or in branches; each atomic instruction is the smallest execution unit, including an agent prompt based on a large model, and specific program call interfaces or function execution logic; among them: 1) Atomic instructions based on agent prompts are used to handle unstructured and flexible processing scenarios that require understanding of business scenarios, semantic parsing, content generation, etc.; 2) Atomic instructions based on program calls are used to handle rigid processing scenarios such as predictable, mechanical, and strongly rule-based validation, such as deduplication, format validation, syntax checking, and field completion of the output results of the previous step; each atomic instruction includes: instruction description, input specifications, output specifications, and validation rules.

[0025] Associated instruction set list: Records other paradigm instruction sets that can be associated with this instruction set (e.g., the format repair instruction set can be associated with various generation instruction sets), used for collaborative routing layer decision-making; Iteration Log: Records iterative information such as Prompt optimization, atomic instruction adjustment, and verification rule update for this instruction set.

[0026] The execution process of each atomic instruction is as follows: receive input data → generate output results according to the instruction description and Prompt template → validate the output according to the validation rules → if the validation passes, send the output results and validation status to the cooperative routing layer; if the validation fails, mark the error type, send the output results and validation status to the cooperative routing layer, and the cooperative routing layer decides whether to trigger repair or rollback.

[0027] The collaborative routing layer, as the core scheduling unit of the architecture, adopts a dynamic routing mechanism that combines program-driven, rule-driven, and model-assisted routing, without relying on a preset fixed execution path. In this embodiment, two collaborative methods are used to determine which paradigm instruction sets to select and how to chain them in sequence: Predictable, mechanized scenarios: The program adopts a fixed arrangement method and determines the execution order of the instruction set directly based on the standardized business scenario through preset routing rules and decision algorithms, resulting in high execution efficiency and stable and controllable paths; For complex and changing scenarios: An AI-assisted decision-making approach is adopted. A pre-set large model analyzes and intelligently orchestrates the existing system structure and user needs to determine the sequence of instruction sets. The program only verifies the format compliance and execution legality of the orchestration results output by the large model, without interfering with the business logic orchestration. At the same time, the collaborative routing layer records the paradigm instruction set and the sequence of instruction sets selected by the large model. When an error occurs or the business needs are not met during the execution of this sequence path, the error marking capability mentioned above is actively triggered to mark the error link and the cause of the error, and trigger manual intervention for correction. After manual correction is completed, the correction and marking data (including error data and corrected data) are synchronously stored in the data layer, and finally used for targeted fine-tuning training of the large model to achieve continuous optimization of the large model's decision-making capabilities.

[0028] Based on the above mechanism, the collaborative routing layer can dynamically organize and connect the paradigm instruction set according to the user's current business scenario: When the user's requirement is to create a completely new system, a fixed program arrangement is adopted, and multiple paradigm instruction sets such as menu generation, form design, permission configuration, report definition, and PDA functions are actively selected and linked to form a complete system generation chain; When the user's requirement is to modify the existing business process, artificial intelligence is used to assist decision-making. First, the existing system structure is read and analyzed, and then the corresponding paradigm instruction set is intelligently matched and scheduled to be executed serially in combination with the user's modification requirements. When a verification failure occurs during system execution, the collaborative routing layer re-examines and updates the set of paradigm instructions to be executed based on the returned error type and error path, and continues execution after the repair is completed.

[0029] Specifically, when a verification failure occurs during system execution and triggers a repair instruction set, the collaborative routing layer performs adaptive context pruning and dynamic assembly of prompts based on error-marked data before scheduling the repair instruction set. First, the collaborative routing layer parses the error type and verification rule identifier in the error-marked data, then backtracks through the execution history stack of the current atomic instruction chain to locate the source atomic instruction causing the error and its corresponding local input / output data, pruning the context information of other atomic instructions unrelated to the error type. Subsequently, using the extracted source atomic instruction identifier and error type as the joint retrieval key, the collaborative routing layer retrieves the historical correction record with the highest feature matching degree from the domain-specific correction dataset of the data layer as a small sample reference. Finally, the collaborative routing layer concatenates the pruned local input / output data, the specific verification rule constraints that triggered the error, and the extracted historical correction record to dynamically generate highly targeted local repair prompts, which are then passed as input parameters to the repair instruction set. This mechanism avoids the context overload and attention distraction problems caused by directly inputting the full context into the model during traditional repair processes, significantly improving the single-shot repair success rate for complex business logic errors.

[0030] The collaborative routing layer is also used to receive the output results and verification status of the upper layer. Combined with the business requirement data and error marking data of the data layer, it makes real-time decisions on the next paradigm instruction set or atomic instruction to be executed, or triggers operations such as rollback, repair, and termination, through preset routing rules and decision algorithms, so as to realize dynamic collaboration between paradigm instruction sets.

[0031] The application layer is used to receive enterprise-level business requirements submitted by users, i.e., business requirement data, and send the business requirement data to the collaborative routing layer after parsing it; it is also used to display the final generated results, output data and correction records; and it is also used to provide a manual correction entry point, supporting users to modify the output of each stage and add correction marks.

[0032] like Figure 2 As shown, based on the above system, this embodiment also provides a dynamic, collaborative, and controllable generation method, including the following steps: S1. The application layer receives the business requirements input by the user, parses the business requirement data to obtain the requirement keywords, business scenario tags, and generation targets, and sends them to the collaborative routing layer. S2. The collaborative routing layer selects an initial paradigm instruction set from the instruction set layer based on the requirement keywords and business scenario tags, and triggers the execution of the first atomic instruction in the atomic instruction chain within the instruction set. After the atomic instruction is executed, the collaborative routing layer receives its output result and verification status. In this embodiment, the requirement keywords are structured feature extractions of user business requirements. The collaborative routing layer uses preset keywords... The paradigm instruction set mapping relationship automatically matches the initial paradigm instruction set that best fits the current business needs from multiple paradigm instruction sets, realizing automatic scheduling and binding from natural language requirements to standardized business paradigms.

[0033] When parsing user requirements, the application layer extracts keywords such as: Architecture, system, and module correspond to the "Production System Architecture Generation Instruction Set"; Menus, pages, and navigation correspond to the "Menu Generation Instruction Set"; JSON, format, and syntax, corresponding to the "JSON Format Repair Instruction Set"; Table structure, master-detail tables, fields, and corresponding "master-detail table design instruction set"; In this embodiment, keywords The paradigm instruction set mapping relationship uses a keyword-instruction set mapping table, for example: Keywords: architecture, system, MES, mapped to: production system architecture generation instruction set; Keywords: JSON, format, syntax; mapping to: JSON format repair instruction set; The routing layer selects the initial paradigm instruction set based on the principle of highest matching degree; in this embodiment, if it is a partial match, it is also matched by weighted matching according to business scenario tags. After selecting the initial paradigm instruction set, the first atomic instruction of the instruction set is automatically triggered. For example, the requirement is "Stamping production line MES system architecture JSON", with keywords: stamping production line, MES, architecture, JSON. The instruction set is automatically matched with the production system architecture and the first atomic instruction is executed: requirement structure extraction.

[0034] S3, the collaborative routing layer, combines verification status, error marking rules from the data layer, and business scenario constraints to determine the following through a decision algorithm: If the current atomic instruction is the last atomic instruction within the paradigm instruction set and the verification passes, proceed to step S4; if the verification fails, the corresponding repair instruction set is executed, and after the repair is completed, return to step S2. If the instruction set is not executed to the end and the verification passes, the next atomic instruction of the instruction set is executed and the process returns to step S2; if the verification fails, the corresponding repair instruction set is executed and the process returns to step S2 after the repair is completed. In this embodiment, the business scenario constraints are derived from business requirement data and instruction set configuration data. The constraints include industry, compliance requirements, output format, and required fields, which are parsed from the business requirement data, and the constraints themselves, which are derived from the instruction set (belonging to the instruction set configuration data).

[0035] In this embodiment, the decision-making algorithm combines hard program rules with model-assisted judgment: hard program rules are used to handle deterministic scenarios (e.g., triggering repair upon verification failure, determining when an instruction set has finished executing); model-assisted judgment is used to handle fuzzy scenarios (e.g., prioritizing multiple associated instruction sets). However, the algorithm prioritizes matching hard program rules and supplements them with model-assisted judgment. The model-assisted judgment only provides suggestions, and the final decision is dominated by program rules, ensuring the controllability and flexibility of scheduling. The steps are as follows: During the rule matching phase, the current execution status (atomic instruction output results, verification status, error type, etc.) is received and accurately matched with the preset routing rule base. If the match is successful, the scheduling result is directly output. In the model-assisted phase, if rule matching fails (i.e., there are multiple associated instruction sets and the priority cannot be determined by hard rules), the base model is invoked, the current context and the list of associated instruction sets are input, and priority ranking suggestions output by the model are obtained. During the decision output phase, the final scheduling instructions (the next set of instructions / atomic instructions to be executed, rollback, repair, termination, etc.) are output based on the rule matching results or model priority suggestions, and the scheduling log is recorded for subsequent traceability and optimization.

[0036] In this embodiment, a single dense base model (e.g., Qwen3-32B-Chat) is used to support the execution and generation of all paradigm instruction sets. By adding instruction set identifiers to the system prompts, task differentiation between different paradigm instruction sets is achieved, enabling the model to quickly switch to the generation mode of the corresponding business paradigm. Combined with the targeted fine-tuning of the multi-instruction set hybrid correction dataset, the single dense base model has the ability to generate multiple business paradigms without having to deploy a separate model for each instruction set, thus reducing operation and maintenance costs.

[0037] S4. The collaborative routing layer determines whether the output of the current paradigm instruction set meets the user's overall requirements: if it does, the final result is output to the application layer and the process terminates; if it does not, based on the current output result and business requirements, the next associated paradigm instruction set is scheduled from the instruction set layer, and the process returns to step S2 until a result that meets the requirements is generated or the termination condition is triggered.

[0038] In this implementation, the criteria for determining whether the output of the current paradigm instruction set meets the overall user requirements include: The output matches the business requirement data stored in the data layer, covering requirement keywords, fitting business scenario tags, and achieving the preset generation goals; The output conforms to the preset output specifications of the instruction set configuration data stored in the data layer and passes all the verification rules of this instruction set paradigm. During the execution of the current paradigm instruction set, there is no uncorrected error-marked data, and the verification status of all atomic instructions is passed.

[0039] If all three conditions are met, the user's overall needs are considered met; if any one condition is not met, the user's needs are not met.

[0040] Termination conditions include: Normal termination: The current paradigm instruction set output meets the user's overall needs, outputs the final result to the application layer, and the process terminates normally.

[0041] Abnormal Termination 1: If multiple repair attempts still fail to pass the verification for the same atomic instruction or the same paradigm instruction set, and the cumulative number of repair attempts reaches the preset retry threshold in the instruction set configuration data (which belongs to the instruction set configuration data running parameters), and the verification still fails, termination is triggered, and the current result and error record are output to the application layer.

[0042] Abnormal Termination 2: No available associated instruction set. The output of the current paradigm instruction set does not meet the overall user requirements. However, the collaborative routing layer cannot match any schedulable next associated paradigm instruction set based on the business requirement data and instruction set configuration data (associated instruction set list) of the data layer. Therefore, the generation process cannot continue, triggering termination and outputting the current result and unmet requirements to the application layer.

[0043] Abnormal Termination 3: Triggered Timeout / Manual Termination; Timeout Termination: The cumulative execution time of the entire generation process reaches the execution timeout threshold preset by the collaborative routing layer (belonging to the running parameters of the instruction set configuration data), triggering termination; Manual Termination: The application layer user actively triggers the process termination through manual operation (corresponding to the application layer manual interaction function).

[0044] Example 2 The difference between this embodiment and Embodiment 1 is that this embodiment also implements continuous optimization of platform operation—problem labeling—data accumulation—model optimization—platform iteration, including the following steps: S5. After the execution of each atomic instruction and paradigm instruction set, the application layer provides a manual correction entry point to obtain the user's modifications to the output content and the added correction flags (including error type and error reason), and generate correction flag data. S6. The data layer stores correction marker data, original output data, and corrected output data, and classifies and archives them according to the dimensions of "instruction set - atomic link - error type" to form a domain-specific correction dataset. S7. Periodically analyze the error rate and error type distribution of each instruction set and atomic link to locate weak links; in this embodiment, "periodically" means monthly.

[0045] S8. For weak links, the following two optimization methods are adopted: Optimize the atomic instruction Prompt and verification rules in this step; Extract the corrected dataset from this step, and use the QLoRA lightweight fine-tuning method to perform directional fine-tuning on the unified dense pedestal model, recording the relevant data of model fine-tuning; S9. Update the optimized atomic instruction Prompt and verification rules to the corresponding paradigm instruction set, deploy the fine-tuned model to the platform, and complete one iteration; repeat steps S6-S9 to achieve continuous optimization.

[0046] Example 3 Based on Embodiments 1 and 2 above, this embodiment further illustrates the specific deployment of a dynamic, collaborative, and controllable generation system by combining the business scenario generated by the MES system architecture of the stamping production line.

[0047] In the data layer deployment of this embodiment, the system uses a MySQL database to store instruction set configuration data and business requirement data, and utilizes MinIO to store correction marker data, correction datasets, and model files. The correction datasets are strictly classified and archived according to multiple dimensions, such as "production system architecture instruction set—step 1 (structured extraction of requirements)—error type (missing field)," thus providing structured support for the construction of the domain-specific correction dataset in the subsequent step S7.

[0048] In terms of instruction set layer deployment, this embodiment configures six core paradigm instruction sets, specifically including: production system architecture generation instruction set, requirement structure extraction instruction set, module splitting instruction set, menu generation instruction set, master-slave table design instruction set, and JSON format repair instruction set. Among them, the production system architecture generation instruction set internally constructs a fine-grained atomic instruction chain, whose execution order follows: requirement structure extraction → module splitting → menu generation → master-slave table design → JSON formatting. Each step has explicit verification rules to ensure the accuracy of atomic instruction execution.

[0049] In the collaborative routing layer deployment, a routing program written in Python is used as the core scheduling unit, with preset routing rules to achieve rule-driven operation. For example, when the application layer's parsed requirements contain keywords such as "architecture" and "system," the routing rules automatically schedule the initial paradigm instruction set; if JSON format verification fails during atomic instruction execution, the JSON format repair instruction set is automatically scheduled. Its routing decision algorithm strictly adheres to a program-driven + model-assisted mechanism, using a single dense base model, Qwen3-32B-Chat, only to handle fuzzy scenarios such as priority ordering of multiple related instruction sets, ensuring the traceability and controllability of the scheduling path.

[0050] The application layer is implemented through a web-based platform that integrates requirement input, result display, and manual correction access. After submitting requirements in step S1, users can view the output data of each atomic step in real time at the application layer. In step S6, users can modify outputs that do not conform to business specifications (such as missing menu levels) and add correction marks. The relevant correction records will be fed back to the data layer.

[0051] For base model deployment, this system uses a single dense base model, Qwen3-32B-Chat, deployed on a high-performance GPU server. By injecting instruction set identifiers into system prompts, the model can quickly switch between different business paradigms. Addressing the weaknesses identified in step S9, the system employs the QLoRA lightweight fine-tuning method to perform targeted fine-tuning of this single base model. Combined with optimized atomic instructions (Prompt), this achieves continuous evolution of the generated results, significantly improving the generation compliance rate in enterprise-level scenarios.

[0052] Example 4 This embodiment, based on the previous embodiments, takes the user submitting a requirement to the stamping production line MES system for work order management and production line data collection to generate an architecture JSON as an example to explain in detail the execution process of the dynamic collaborative and controllable generation method: S1. The application layer receives user requests, parses them to obtain the request keywords "stamping production line MES system, architecture JSON" and the business scenario tag "manufacturing industry", and sends them to the collaborative routing layer. S2, the collaborative routing layer matches the initial paradigm instruction set - production system architecture generated instruction set according to the requirement keywords and business scenario tags, and triggers the first atomic instruction of its internal atomic instruction chain - the requirement structure extraction instruction execution; The demand structure extraction instruction receives input, generates structured requirements containing "Industry: Manufacturing, Core Module: Work Order Management, Production Line Data Acquisition, Constraint: Architecture JSON", and sends them to the collaborative routing layer after verification. S3. The collaborative routing layer determines that the instruction has not been executed to the end of the instruction set, and triggers the next atomic instruction "module splitting" to be executed. The splitting results in "work order management module, production line data acquisition module, and basic data module". After the verification is passed, proceed to the next step. The menu generation and master-slave table design atomic instructions are triggered sequentially. After the master-slave table design instructions are output, the verification finds that there are duplicate fields in the master table and slave table. The error type is marked and sent to the collaborative routing layer. The collaborative routing layer repeats the error type field, schedules the associated master-slave table design instruction set (re-executes this step), and passes the verification after correction; Trigger the execution of the JSON formatting atomic instruction to generate the complete architecture JSON. Validation reveals JSON syntax errors. Coordinate with the routing layer to schedule the JSON format repair instruction set. After repair, validation passes. S4. The collaborative routing layer determines that the production system architecture has completed the execution of the instruction set and that the output meets the user's requirements. It then sends the final JSON result to the application layer, and the process terminates. S5. After viewing the results, the user finds that the menu hierarchy is missing. The menu content is modified through the manual correction entry in the application layer, and a correction mark "Error type: missing hierarchy, step: menu generation" is added. The data layer stores the correction record for subsequent iteration optimization.

[0053] Example 5 This embodiment, based on the aforementioned embodiments, provides a detailed explanation of the iterative closed-loop execution process: S6-S7: After one month of platform operation, the data layer accumulated 200 correction records for the production system architecture generation instruction set. Among them, the "missing hierarchy" error in the "menu generation" process accounted for 30%, and this process was identified as a weak link. Extract 60 "missing hierarchy" correction records from the "menu generation" step and organize them into a correction dataset in JSONL format. Each data record contains system (instruction set identifier), current_chain_step (menu generation), instruction, input, and output (corrected content). S8. The QLoRA lightweight fine-tuning method is used to fine-tune the Qwen3-32B-Chat base model. The learning rate is set to 1e-4 and epoch=1, and only the hierarchical integrity of the "menu generation" stage is strengthened. Optimize the Prompt of the "Menu Generation" atomic instruction, add the constraint that "a three-level menu must be generated, with clear hierarchy and no missing parts", and update it to the production system architecture generation instruction set; S9. Redeploy the fine-tuned model, update the Prompt configuration, and complete the iteration; after the iteration, the "hierarchical missing" error rate in the "menu generation" stage drops to below 5%.

[0054] The above are merely embodiments of the present invention. The invention is not limited to the fields covered by these embodiments. Commonly known structures and characteristics in the solutions are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are able to access all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, based on the guidance provided in this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A dynamic, collaborative, and controllable generation system, characterized in that, include: The data layer is used to store instruction set configuration data, business requirement data, output data, error marker data, correction marker data, domain-specific correction datasets, and model fine-tuning related data. The instruction set layer includes multiple standardized paradigm instruction sets. Each paradigm instruction set contains atomic instruction chains, which are composed of several atomic instructions connected sequentially or in branches. The collaborative routing layer is used to dynamically organize and connect paradigm instruction sets according to the user's current business scenario, and execute them; it is also used to receive the output results and verification status of the instruction set layer, and combine them with the business requirement data and error marking data of the data layer to make real-time decisions on the next paradigm instruction set and atomic instruction to be executed, or to trigger rollback, repair, and termination operations, so as to realize dynamic collaboration between paradigm instruction sets. The application layer is used to receive business requirement data submitted by users, parse the business requirement data and send it to the collaborative routing layer; it is also used to display the final generated results, output data and correction records.

2. The dynamic collaborative controllable generation system and method according to claim 1, characterized in that: The instruction set configuration data includes the unique identifier of the paradigm instruction set, business scenario tag, and applicable domain type; the structural information of the atomic instruction chain; the configuration information of each atomic instruction; the association between paradigm instruction sets and their operating parameters; and keywords. Paradigm instruction set mapping relationships and error marking rules.

3. The dynamic collaborative controllable generation system according to claim 2, characterized in that: Each atomic instruction performs only a single task; the execution process of each atomic instruction is as follows: receive input data, generate output results according to the instruction description and Prompt template, verify the output according to the verification rules, and if the verification passes, send the output results and verification status to the cooperative routing layer; If the verification fails, the error type is marked, and the output result and verification status are sent to the cooperative routing layer, which then decides whether to trigger repair or rollback.

4. The dynamic collaborative controllable generation system according to claim 3, characterized in that: The application layer is also used to provide a manual correction entry point, allowing users to modify the output of each stage and add correction markers.

5. A dynamic, collaborative, and controllable generation method, characterized in that, Includes the following steps: S1. The application layer receives the business requirements input by the user, parses the business requirement data to obtain the requirement keywords, business scenario tags, and generation targets, and sends them to the collaborative routing layer. S2. The collaborative routing layer selects an initial paradigm instruction set from the instruction set layer based on the requirement keywords and business scenario tags, and triggers the execution of the first atomic instruction in the atomic instruction chain within the instruction set. After the atomic instruction is executed, the collaborative routing layer receives its output result and verification status. S3, the collaborative routing layer, combines verification status, error marking rules from the data layer, and business scenario constraints to determine the following through a decision algorithm: If the current atomic instruction is the last atomic instruction within the paradigm instruction set and the verification passes, proceed to step S4; if the verification fails, the corresponding repair instruction set is executed, and after the repair is completed, return to step S2. If the instruction set is not executed to the end and the verification passes, the next atomic instruction of the instruction set is executed and the process returns to step S2; if the verification fails, the corresponding repair instruction set is executed and the process returns to step S2 after the repair is completed. S4. The collaborative routing layer determines whether the output of the current paradigm instruction set meets the user's overall requirements: if it does, the final result is output to the application layer and the process terminates; if it does not, based on the current output result and business requirements, the next associated paradigm instruction set is scheduled from the instruction set layer, and the process returns to step S2 until a result that meets the requirements is generated or the termination condition is triggered.

6. The dynamic collaborative controllable generation method according to claim 5, characterized in that: In step S3, the decision algorithm combines hard rules and model assistance to make a judgment. Hard rules are used to handle deterministic scenarios, while model assistance is used to handle fuzzy scenarios. The specific steps are as follows: During the rule matching phase, the current execution status is received and matched with the preset routing rule base. If the match is successful, the scheduling result is output directly. During the model-assisted phase, if rule matching fails, a preset base model is invoked, and the current context and associated instruction set list are input to obtain priority sorting suggestions from the model output. In the decision output phase, the final scheduling instruction is output based on the rule matching results or model priority suggestions, and the scheduling log is recorded.

7. The dynamic collaborative controllable generation method according to claim 6, characterized in that: Also includes: S5. After the execution of each atomic instruction and paradigm instruction set is completed, the application layer provides a manual correction entry point to obtain the user's modifications to the output content and the added correction flags, and generate correction flag data. S6. The data layer stores the correction marker data, the original output data, and the corrected output data, classifies and archives them to form a domain-specific correction dataset. S7. Regularly analyze the error rate and error type distribution of each instruction set and each atomic link to identify weak links; S8. For weak links, the following two optimization methods are adopted: Optimize the atomic instruction Prompt and verification rules in this step; Extract the correction dataset for this step, use the QLoRA lightweight fine-tuning method to perform directional fine-tuning of the base model, and record the relevant data of model fine-tuning; S9. Update the optimized atomic instruction Prompt and verification rules to the corresponding paradigm instruction set, and deploy the fine-tuned base model to the platform to complete one iteration; repeat steps S6-S9 to achieve continuous optimization.

Images