AI incremental editing and visual synchronization method, device, medium and product

Abstract

The application provides an AI incremental editing and visualization synchronization method, device, medium and product, relates to the technical field of large language model application, and the method comprises the following steps: acquiring a first incremental editing instruction output by a large language model and based on a first structured configuration file original line number, merging and verifying a third merged incremental editing instruction generated after being repaired through a preset indentation rule set, and applying the third merged incremental editing instruction to an original file to generate a third structured configuration file; rendering a visual interactive interface by analyzing the third structured configuration file into a memory object, receiving an updated memory object after user modification, reversely serializing and adding a line number prefix, and generating an input context for the next round of dialogue of the large language model. The scheme solves the technical problem that there is a lack of a high-reliability bidirectional real-time synchronization mechanism between AI editing of a structured configuration file and human visual interaction.

Description

Technical Field

[0001] This application relates to the field of large language model application technology, specifically to an AI incremental editing and visualization synchronization method, device, medium and product. Background Technology

[0002] With the improvement of large language model code generation capabilities, AI-assisted programming is widely used in software engineering. In enterprise-level system construction, a large number of design deliverables, such as domain data models and business workflows, are usually in the form of structured configuration files. These files not only need to serve as machine-readable data sources to drive system operation, but also need to be transformed into visual forms such as charts or forms for business personnel to review and interact with intuitively.

[0003] To handle structured configuration files, existing development models typically employ a dual-track parallel operation mechanism. At the code level, developers use AI editing tools to modify the underlying configuration code by outputting a complete new version of the file or a diff patch based on contextual text matching. At the business presentation level, the system provides an independent visual low-code platform where business users configure the application structure by dragging and dropping canvases and filling out forms. The platform then transforms these user interface interactions into internal data models for independent storage and rendering.

[0004] As human-machine collaborative design becomes more sophisticated, AI and business personnel need to frequently make alternating modifications to the same configuration files. Under such complex collaborative requirements, when AI modifies long configuration files based on text matching, it is highly susceptible to positioning offsets or output truncation due to text similarity interference, leading to underlying data corruption. At the same time, because the code editing chain and the visualization rendering chain are independent, the AI's underlying modifications often require manual intervention for comparison before being reflected in the graphical interface. Meanwhile, the adjustments made by business personnel on the interface are also detached from the AI's contextual memory, resulting in frequent data version conflicts and state fragmentation during the alternating editing process. Summary of the Invention

[0005] This application provides a method, device, medium, and product for synchronizing AI incremental editing and visualization, in order to solve the technical problem of the lack of a highly reliable two-way real-time synchronization mechanism between AI editing of structured configuration files and human visual interaction in the prior art.

[0006] Firstly, this application provides a method for synchronizing AI incremental editing and visualization, including: The first incremental editing instruction based on the line number range is obtained from the output of the large language model. The starting and ending line numbers of the first incremental editing instruction are based on the original line numbers of the first structured configuration file in the initial state of the current editing round. The first structured configuration file serves as the editing medium of the large language model, the data source for visualization rendering, and the data carrier for human visualization interaction. For multiple first incremental editing instructions for the same first structured configuration file, the first incremental editing instructions are applied to the first structured configuration file to obtain a second structured configuration file. A first merge incremental editing instruction is generated based on the second structured configuration file. The end line number of the first merge incremental editing instruction is fixed to the original total number of lines in the first structured configuration file. The first merge incremental editing instruction is format-validated and extracted using preset multi-level matching rules to obtain the second merge incremental editing instruction. Based on a preset set of indentation rules, the indentation of the edited text corresponding to the second merge incremental editing instruction is checked and automatically repaired line by line to obtain the third merge incremental editing instruction. The third merge incremental editing instruction is then applied to the first structured configuration file to generate the third structured configuration file. The third structured configuration file is parsed into a memory object, and the corresponding visual interactive interface is rendered based on the memory object. It receives modification operations triggered by the user on the visual interactive interface, updates the memory object, reverse serializes the updated memory object into the fourth structured configuration file, adds a line number prefix to each line of the fourth structured configuration file, and generates the fifth structured configuration file, which serves as the input context for the next round of dialogue in the large language model.

[0007] Optionally, for multiple first incremental editing instructions on the same first structured configuration file, the first incremental editing instructions are applied to the first structured configuration file to obtain a second structured configuration file, and a first merge incremental editing instruction is generated based on the second structured configuration file, specifically including: If there is a first incremental editing instruction with the same start and end line numbers, then retain the first incremental editing instruction with the most recent timestamp to obtain several second incremental editing instructions; Arrange the second incremental editing instructions in descending order of the starting line number; Following the descending order, based on the original line numbers of the first structured configuration file, starting from the end of the first structured configuration file and moving backward, the content of the corresponding line number range in the first structured configuration file is replaced with the content corresponding to the second incremental editing command to obtain the second structured configuration file. Determine the smallest target starting line number in the second incremental editing instruction; Extract all text content from the target starting line number to the end of the file in the second structured configuration file as the merge content. Combine the target starting line number with the original total number of lines in the first structured configuration file to generate the first merge incremental editing instruction.

[0008] Optionally, the first merge incremental editing instruction is format-validated and extracted using preset multi-level matching rules to obtain the second merge incremental editing instruction, specifically including: The following four levels of matching rules are applied sequentially to match and extract the first merge incremental editing command. The four levels of matching rules are: Level 1 matching rule: Match command segments containing standard start and end markers; Level 2 matching rule: Match command segments containing standard start markers and arbitrary end markers; Level 3 matching rule: Match command segments from the standard start marker to the end of the string; Level 4 matching rule: Match command segments without a standard start prefix but containing file and line number identifiers. The first successfully matched and extracted instruction segment will be used as the second merged incremental editing instruction.

[0009] Optionally, based on a preset set of indentation rules, line-by-line indentation verification and automatic repair are performed on the edited text corresponding to the second merge incremental editing instruction to obtain the third merge incremental editing instruction, which specifically includes: The indentation rule set includes several subsets of indentation rules corresponding to different current contexts. Each subset of indentation rules includes several indentation rules with a preset priority order. The indentation rules include matching regular expressions, preset indentation spaces, and target context. The current global context is dynamically determined based on the hierarchical relationship between the edited text and the first structured configuration file; Iterate through the text lines in the edit text sequentially, and perform the following processing steps for the currently encountered target text line: Remove leading white spaces from the target text line to obtain the trimmed text line; Determine the corresponding subset of target indentation rules based on the current global context; Search for target matching regular expressions that match the trimmed text lines in the target indentation rule subset according to a preset priority order; If a target matching regular expression is found, the indentation of the target text line is adjusted to the preset number of indentation spaces corresponding to the target matching regular expression, and the global current context is updated to the target context corresponding to the target matching regular expression. The target context is used to determine the target indentation rule subset corresponding to the next text line. If no matching regular expression is found, the process follows the predefined fallback strategy in the indentation rule set. The fallback strategies include: maintaining the original indentation of the target text line, or applying the preset default number of indentation spaces. After the traversal is complete, a third merge incremental editing instruction is generated based on the processed edited text.

[0010] Optionally, the steps for receiving modification operations triggered by the user on the visual interactive interface and updating the memory object include: During the execution of the first incremental editing instruction generated by the large language model, the dialog input interface is locked while the editing permissions of the visual interactive interface remain open; When the third merge incremental editing command is applied to the first structured configuration file to generate the third structured configuration file, it triggers the re-parsing and overwriting of memory objects; If the user modifies the memory object through the visual interactive interface during execution, the operation of reverse serialization into the fourth structured configuration file will be performed before the next round of dialogue in the large language model, based on the current latest memory object state.

[0011] Optionally, before the step of obtaining the first incremental editing instruction based on the line number range from the output of the large language model, the method further includes: Based on the size characteristics of the set of files to be edited, the maximum number of loops in the large language model and the multi-level reminder parameters are dynamically calculated. During the loop execution of the large language model, the current execution state features are obtained in real time. The current execution state features include at least the current loop number and the total number of tool calls. Based on the current execution state characteristics, the maximum number of loop rounds, and multi-level reminder parameters, the corresponding reminder level is matched, and guidance information corresponding to the reminder level is injected into the large language model to control the reading and reasoning behavior of the large language model.

[0012] Optionally, before the step of performing line-by-line indentation verification and automatic repair on the edited text corresponding to the second merge incremental editing instruction based on preset indentation rules to obtain the third merge incremental editing instruction, the method further includes: By performing a full-domain detection on the edited text using cleanup regular expressions, residual line number prefixes in the edited text are identified and removed; The beginning and end of the edited text are checked to remove any remaining code block markers. Perform full-domain detection on preset special characters in the edited text, and process the detected preset special characters to comply with regulations.

[0013] Secondly, embodiments of this application provide an AI incremental editing and visualization synchronization device, which includes: one or more processors and a memory; the memory is coupled to the one or more processors, and the memory is used to store computer program code, the computer program code including computer instructions, and the one or more processors call the computer instructions to cause the AI ​​incremental editing and visualization synchronization device to perform the method as described in the first aspect and any possible implementation thereof.

[0014] Thirdly, embodiments of this application provide a computer program product containing instructions that, when the computer program product is run on an AI incremental editing and visualization synchronization device, cause the AI ​​incremental editing and visualization synchronization device to perform the method described in the first aspect and any possible implementation thereof.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium including instructions that, when executed on an AI incremental editing and visualization synchronization device, cause the AI ​​incremental editing and visualization synchronization device to perform the method described in the first aspect and any possible implementation thereof.

[0016] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: 1. By adopting the above technical solution, the first incremental editing instruction based on the original line number is obtained, avoiding the positioning failure problem easily caused by traditional text context matching. Multiple editing instructions from the same first structured configuration file are merged, and the format is extracted and automatically repaired line by line through a preset multi-level matching rule and indentation rule set, overcoming the parsing interruption caused by non-standard output format and indentation errors of the large language model. Furthermore, the repaired third structured configuration file is parsed into a memory object to render the visual interactive interface, and the user's modification operation triggered on the interface is updated to the memory object, which is then reverse-serialized into a fifth structured configuration file with a line number prefix as the input context for the next round of dialogue. This process realizes the integration of the underlying configuration file, the large language model editing, and the human visual interactive interface, constructing a two-way real-time synchronous closed loop of data state, and solving the problems of data fragmentation and state conflict in the human-computer alternating editing process.

[0017] 2. By adopting the above technical solution, for multiple first incremental editing instructions in the same first structured configuration file, the most recent timestamp is retained for instructions with identical starting and ending line numbers, eliminating redundant or intermediate modification instructions. Then, the filtered second incremental editing instructions are arranged in descending order of their starting line numbers, and the content is replaced sequentially from the end of the file backwards based on the original line numbers of the first structured configuration file. This backward replacement mechanism ensures that each content replacement operation does not change the original line number coordinates of the unprocessed content before it, effectively avoiding line number offset errors caused by multiple incremental edits. Finally, the smallest target starting line number is determined, and all lines from this target starting line number to the end of the file are extracted as the merged content, generating a first merged incremental editing instruction with an ending line number fixed to the original total number of lines. This mechanism integrates multiple scattered editing operations into a continuous editing block, ensuring the consistency and accuracy of the incremental editing content within the overall file structure.

[0018] 3. By adopting the above technical solution, four levels of matching rules are applied sequentially to extract the first merge incremental editing instruction. The first-level matching rule accurately extracts instruction segments with complete formats. When the large language model output is missing a standard end marker or the format is varied, the second and third-level matching rules relax the end boundary conditions to match instruction segments containing any end marker or extending to the end of the string. If the instruction segment completely omits the standard beginning prefix, the fourth-level matching rule can still extract it using file and line number identifiers as a fallback. This progressively stricter matching mechanism provides multi-level fault tolerance for the instability that often occurs when large language models generate editing instructions, such as missing markers, format variations, or output truncation. The instruction segment successfully extracted in the first match is used as the second merge incremental editing instruction. This ensures extraction accuracy while being compatible with non-standard formatted output text, avoiding overall editing task failure due to local formatting inconsistencies and improving the success rate of instruction parsing.

[0019] 4. By adopting the above technical solution, and utilizing subsets of indentation rules containing different current contexts, the indentation verification and automatic repair are performed line by line on the edited text corresponding to the second merge incremental editing instruction. During the line-by-line traversal, leading spaces in the target text line are removed to eliminate the original incorrect indentation interference, and the target matching regular expression is searched in the target indentation rule subset according to a preset priority order based on the global current context. After finding a match, the indentation of the target text line is directly adjusted to the preset number of indentation spaces, and the global current context is updated to the target context simultaneously to guide the rule matching of the next text line; if no match is found, a backup strategy is executed. This mechanism constructs a dynamic repair process based on a context state machine, which can accurately identify the indentation semantics of the edited text under different hierarchical structures. Through this line-by-line verification and state transition, the common hierarchical disorder and inconsistent indentation problems in the structured configuration text generated by the large language model are effectively corrected, ensuring the syntactic rigor of the final generated third merge incremental editing instruction. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the first process of the AI ​​incremental editing and visualization synchronization method in the embodiments of this application; Figure 2 This is a schematic diagram of the second process of the AI ​​incremental editing and visualization synchronization method in the embodiments of this application; Figure 3 This is a schematic diagram of the third process of the AI ​​incremental editing and visualization synchronization method in the embodiments of this application; Figure 4 This is a schematic diagram of the fourth process of the AI ​​incremental editing and visualization synchronization method in the embodiments of this application; Figure 5 This is a schematic diagram of the fifth process of the AI ​​incremental editing and visualization synchronization method in the embodiments of this application; Figure 6 This is a timing logic diagram of the SSE streaming communication implementation in the embodiments of this application; Figure 7 This is a schematic diagram of the physical device structure of an AI incremental editing and visualization synchronization device in the embodiments of this application. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification 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.

[0022] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0023] In the description of the embodiments of this application, the term "multiple" means two or more. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first," "second," or "third" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized. It should be noted that all data collection in this scheme is conducted after obtaining user consent.

[0024] This application also provides a method for synchronizing AI incremental editing and visualization, see reference. Figure 1 , Figure 1 This is a flowchart of an AI incremental editing and visualization synchronization method provided in an embodiment of this application. The method includes: Step S101: Obtain the first incremental editing instruction based on the line number range output by the large language model. The starting line number and ending line number corresponding to the first incremental editing instruction are both based on the original line number of the first structured configuration file in the initial state of the current editing round. The first structured configuration file serves as the editing medium of the large language model, the data source for visualization rendering, and the data carrier for human visualization interaction. Among them, the large language model refers to an artificial intelligence system with powerful code understanding and generation capabilities, used to output modification instructions for structured configuration files based on the natural language requirements input by the user. For example, after receiving a request from a business user to "add a total amount attribute to the order entity, and this attribute is not required," the large language model can understand the business intent and generate the corresponding text modification operation.

[0025] The first incremental editing instruction refers to the editing protocol data block output by the large language model based on a line number range. For example, the large language model outputs a plain text instruction that explicitly specifies the target file name to be modified, the starting line number of the replacement operation, the ending line number of the replacement operation, and the new multi-line text content after the replacement, rather than outputting a complete new file containing hundreds of lines.

[0026] The starting line number indicates the beginning of the replacement operation range, typically counting from and including the first line. For example, if a large language model decides to insert a new attribute field on line fourteen of the configuration file, its specified starting line number would be fourteen.

[0027] The end-line number indicates the end position of the replacement operation range. It is also counted starting from the first line and includes that line. It also supports the use of special identifiers to indicate the last line of the file. For example, if the specified end-line number is fourteen, it means that the replacement operation only applies to the fourteenth line or appends content to this line. If the end-line number is specified as a special identifier representing the end of the file, it means that the replacement starts from the start-line number and continues to the last line of the file.

[0028] The first type of structured configuration file refers to a configuration file in enterprise-level system construction that exists in a specific hierarchical indentation or key-value pair format. For example, a configuration file named Domain Ontology Definition records the order entity, customer entity, and the subordinate relationships between the two entities in a hierarchical nested manner.

[0029] The original line numbers in the initial state of the current editing round refer to the absolute line number coordinate system of the file before any editing modifications at the start of a round of reasoning and action loop in the large language model. For example, if the large language model inserts five new lines of content on line ten in its first edit, the line numbers in the second edit instruction output by the large language model will still be based on the original line numbers before the modification, without needing to add an offset of five.

[0030] The large language model editing medium refers to a file that can be directly read by the large language model by line number using a reading tool, and whose text content can be added, deleted, or modified by line number range using an editing tool.

[0031] A visual rendering data source refers to a file whose content can be parsed by the system in real time and transformed into a graphical display format. For example, entity and relationship data in a file can be converted into an entity relationship topology diagram or attribute editing form on a webpage in real time.

[0032] The data carrier for human-visualized interaction refers to the file on which a user's modifications on a graphical interface are ultimately reflected. For example, if a business user selects "Yes" as the required field for the total amount attribute in a web form, this action will directly result in an update of the underlying data in the configuration file.

[0033] The timing and scenario for this step are as follows: after the user initiates an editing request for the configuration file, the large language model obtains the original file content with line number prefixes through the file reading tool, and executes it when the editing tool is called to generate modification instructions in the inference and action loop.

[0034] Specifically, the large language model outputs the first incremental editing instruction by invoking the editing tool. This instruction strictly uses absolute start and end line numbers to locate the editing position, instead of using the traditional contextual text matching method. This line number-based positioning mechanism means that the large language model does not need to precisely remember the complete content of the original file, but only needs to know the specific line numbers, while avoiding matching interference caused by duplicate text content in the original file. The large language model can output the first incremental editing instruction multiple times in a loop. These instructions are not immediately applied to modify the file content in the first structured configuration file when they are generated. Instead, the edit object containing the filename, start line number, end line number, and new content is accumulated and recorded in a memory list. All accumulated first incremental editing instructions strictly reference the original line number coordinates of the first structured configuration file in the initial state of the current editing loop. This original coordinate system design solves the line number offset problem caused by inserting or deleting lines during multiple incremental editing processes. For example, if the first edit inserts 5 new lines of content at line 10, the line numbers of subsequent edits do not need to be increased by 5—because all line numbers reference the original file. Meanwhile, the first structured configuration file, as the core of the three-in-one data system, is not only a plain text editing medium for reading and writing large language models, but also a data source for real-time parsing to generate entity relationship diagrams or forms for visualization rendering. Furthermore, it directly serves as a data carrier for receiving drag-and-drop or form modification operations performed by humans on the visualization interface, ensuring the consistency of machine editing and human interaction at the underlying data level.

[0035] Step S102: For multiple first incremental editing instructions for the same first structured configuration file, apply the first incremental editing instructions to the first structured configuration file to obtain a second structured configuration file, and generate a first merge incremental editing instruction based on the second structured configuration file. The end line number of the first merge incremental editing instruction is fixed to the original total number of lines in the first structured configuration file. In this context, multiple first incremental editing instructions for the same first structured configuration file refer to multiple local modification operations based on the original line numbers generated for the same target configuration file during one round of reasoning and action loop in the large language model. For example, in one task, the large language model generates three independent text editing operations based on the original file: modifying line 3, inserting new content on line 6, and modifying line 8.

[0036] The second structured configuration file refers to the intermediate state file data containing all the modification results obtained after uniformly applying the aforementioned multiple scattered incremental editing instructions to the original configuration file content. For example, after safely replacing the contents of the three aforementioned editing instructions with the corresponding positions in the original file, a set of overall updated file content is formed.

[0037] The first merge incremental editing instruction refers to the integration of multiple independent editing instructions into a single, global, continuous block of edit data. For example, three local instructions that were originally scattered on lines 3, 6, and 8 are merged into a single continuous editing block starting from line 3 and continuing to the end of the file.

[0038] This step is executed when and in the following scenario: after the large language model completes a round of inference and action loop, multiple local editing instructions for the same configuration file have accumulated in memory, and the system is ready to output and apply these modifications uniformly. Specifically, when the large language model outputs multiple editing operations on the same first structured configuration file, since each operation is strictly based on the absolute line number of the original file, if applied directly in forward order, the increase or decrease in the number of lines caused by the previous operation will inevitably cause the line number offset of subsequent operations to become disordered. Therefore, the system needs to uniformly merge these first incremental editing instructions. The system uses a specific merging mechanism to safely apply these instructions to the first structured configuration file, generating a second structured configuration file containing all the modified content. Subsequently, based on this second structured configuration file, the system extracts all content from the earliest modified position to the end of the file, generating a continuous first merged incremental editing instruction. In this process, the end line number of the first merged incremental editing instruction is strictly fixed to the original total number of lines in the first structured configuration file, rather than the maximum value of the end line numbers of each individual editing instruction. The reason for this design is that intermediate editing commands may insert or delete lines, causing the actual total number of lines after merging to differ from the original file. Fixing the ending line number to the original total number of lines ensures that the merged new content, when applied to the front end, can completely and accurately replace all affected areas from the earliest modification position to the end of the original file in one go. For example, if the original file has 10 lines, and the large language model edits lines 3, 6, and 8 respectively, and inserts one new line of content on line 6; the first merge incremental editing command generated by the system after merging has a starting line number of 3 and an ending line number fixed at the original total number of lines 10. This command actually contains 8 lines of merged content. After the front end replaces lines 3 to 10 in one go, the total number of lines in the new file becomes 11, thus completely eliminating the line number offset problem caused by multiple incremental editing accumulations.

[0039] Optionally, for multiple first incremental edit instructions on the same first structured configuration file, before applying the first incremental edit instruction to the first structured configuration file: If it is determined that the end line number of the first incremental editing instruction is equal to the starting line number minus one, then the end line number will be automatically corrected to the starting line number; Detect and remove any remaining line number prefixes from the first incremental editing command; When the first structured configuration file is in YAML format, a structural integrity check is performed on the first incremental editing command. The structural integrity check includes detecting duplicate top-level keys, naked asterisk characters, and necessary structural omissions during full file replacement. If structural integrity verification fails or YAML syntax parsing fails, the first incremental edit instruction is intercepted, and a warning message containing the error location and repair suggestions is returned to the large language model so that the large language model can perform self-correction in subsequent dialogue rounds.

[0040] Among these, "ending line number equal to starting line number minus one" refers to a special line number boundary case generated by the large language model when generating editing instructions to express the semantics of "inserting new content before a certain line." For example, if the large language model outputs a starting line number of 15 and an ending line number of 14, the system will automatically correct it to an ending line number equal to 15. "Line number prefix" refers to the large language model incorrectly copying line number identifiers generated by the file reading tool into the new content of the editing instructions when reading file content with line numbers. For example, the new content may contain a string like "425|content." "Structural integrity verification" refers to the grammatical and business rule validity checks performed on configuration files of a specific format before applying editing instructions. "Duplicate top-level key" refers to the presence of multiple identical top-level attributes in a YAML file. For example, an ontology file may incorrectly generate two entities: paragraphs. "Naked asterisk character" refers to an asterisk that is not correctly referenced or escaped in YAML syntax, which usually leads to YAML alias parsing errors. "Missing necessary structure" refers to the situation where, during a full file replacement operation, the generated new content omits the core basic structures that this type of configuration file must possess. For example, an ontology file must contain both entities and relations nodes; the absence of either one constitutes a missing essential structure. Warning messages indicate that after an error is detected during the validation phase, the system intercepts the edit command and generates feedback data containing the specific error location and suggested fixes. This feedback is returned to the large language model to guide its self-correction in subsequent dialogue rounds.

[0041] This step is executed after the large language model calls the editing tool to output the first incremental editing command, and before the system accumulates these commands and actually applies them to the first structured configuration file. It is a defensive verification step on the tool executor side. Specifically, the system first performs a logical check on the line number range of the first incremental editing command. If it determines that the end line number equals the start line number minus one, the system understands that the large language model intends to insert content before the start line, thus automatically correcting the end line number to the start line number to ensure the legality of the line number range. Next, the system detects and removes residual line number prefixes in the new content of the first incremental editing command. It accurately identifies and removes line number markers like "12|" that the large language model mistakenly copied, using regular expressions (such as ^\s*\d{1,6}\s*\|\s?), ensuring the purity of the replaced content. Furthermore, if the first structured configuration file is in YAML format, the system performs a deep structural integrity check on the first incremental editing command. This validation not only checks for duplicate top-level keys and naked asterisk characters that might cause aliasing errors, but also, during a full file replacement, checks for missing essential structures (e.g., ontology files must contain both entities and relations, and workflow files must contain both nodes and edges). Finally, the system attempts a preliminary YAML parsing of the modified content. If the structural integrity check or YAML parsing fails, the system intercepts the first incremental edit command, preventing it from entering the subsequent merging and application process, and returns a warning message (e.g., in the form of a warning field) containing the specific error location and suggested fixes to the large language model. Upon receiving this warning, the large language model can understand the cause of the error and self-correct in subsequent dialogue rounds, re-outputting the correct edit command, thus significantly improving the robustness of automated editing.

[0042] Step S103: The first merge incremental editing instruction is format-verified and extracted using preset multi-level matching rules to obtain the second merge incremental editing instruction; The pre-defined multi-level matching rules refer to a set of regular expressions or parsing strategies pre-defined by the system, arranged in descending order of strictness, to cope with unstable output formats of large language models. For example, this rule set includes multiple degraded matching levels, from strictly requiring standard start and end tags to allowing variations in end tags and even allowing the omission of start prefixes. Format validation and extraction refers to the process of checking the legality of the text stream output by the large language model and accurately extracting the actual editing parameters and clean text content. For example, during extraction, it checks whether the filename in the text matches the current file, converts special values ​​representing the end of the file into actual line numbers, and converts non-standard output formats into standard text. The second merged incremental editing instruction refers to the structured and clean editing data block obtained after multi-level fault-tolerant parsing, successful extraction, and formatting. For example, the final editing instruction object, after removing various redundant tags, automatically converting to JSON format, and specifying line number parameters, can be directly used for subsequent text replacement operations.

[0043] This step is executed after the front-end receives the first merge incremental editing instruction text pushed from the back-end, but before these edits are actually applied to the local configuration file for replacement. It belongs to the front-end's data parsing and fault tolerance processing stage. Specifically, after the front-end receives the first merge incremental editing instruction, due to the instability of the output of the large language model, the start and end tags may be omitted or format variations may occur when generating the instruction. The system performs format verification and extraction on the instruction using preset multi-level matching rules. The parser will try multi-level regular expression matching in descending order of strictness. The system first tries the strictest standard format matching; if it fails, it gradually relaxes the boundary conditions, successively trying to allow variations in the end tag, allow the omission of the end tag, and even allow the complete omission of the standard start prefix at the most lenient level, until the edit block is successfully extracted for the first time. During the matching and extraction process, the system simultaneously performs format verification, including supporting the automatic conversion of special values ​​into the actual total number of lines and performing filename consistency verification. If the filename does not match, it is recorded as an invalid block.

[0044] Furthermore, after successfully extracting the replacement content, the parser will automatically perform conversion processing on the extracted content. When it detects that the large language model outputs the replacement content in JSON array format or JSON object wrapping format, the system will automatically convert it to plain text format. Through this strict to lenient degradation matching mechanism and automatic format conversion, the system can effectively accommodate the non-standard output of the large language model, ultimately obtaining a second merge incremental editing command with standardized format and accurate content.

[0045] Step S104: Based on the preset indentation rule set, perform indentation verification and automatic repair on the edited text corresponding to the second merge incremental editing instruction line by line to obtain the third merge incremental editing instruction. Apply the third merge incremental editing instruction to the first structured configuration file to generate the third structured configuration file. The preset indentation rule set refers to a predefined set of rules used by the system to describe the indentation depth and context switching logic of each level of data structure in a specific configuration file. For example, the rule set defined for the domain ontology configuration file explicitly stipulates that the highest-level entity declaration does not need indentation, the entity's attribute list level needs to be indented by four spaces, and the specific attribute field level needs to be indented by six spaces, etc. Edited text refers to the plain text content that needs to be replaced or inserted in the second merge incremental editing instruction. For example, a multi-line text string containing specific business attribute descriptions such as "Name: Total Amount" and "Data Type: Decimal". The third merge incremental editing instruction refers to the final edited data block whose formatting fully conforms to the syntax of the target configuration file after automatic indentation format correction. For example, the aforementioned incorrectly indented order total amount attribute text, after system correction, has its leading spaces in each line automatically adjusted to the correct number of spaces that meet the nesting requirements of the ontology file, forming an instruction that can be directly and safely written. The third structured configuration file refers to the new version of the file data with correct format and content generated after the corrected final editing instructions are safely replaced in the corresponding positions of the original file. For example, the latest ontology definition file successfully added the total amount attribute and has strict and compliant overall hierarchical indentation.

[0046] This step is executed after the clean editing instruction text has been successfully extracted from the front end, but before it is actually written to the local configuration file for content replacement. It primarily addresses the issue of underlying file parsing failures caused by the large language model's unstable understanding of hierarchical indentation semantics. Specifically, the system first extracts the edited text from the second merge incremental editing instruction and introduces a preset set of indentation rules that matches the current file type. Since the hierarchical nested content generated by the large language model often exhibits inconsistent or incorrect indentation spaces, the system initiates a dynamic repair process based on a context state machine. During processing, the system reads the edited text line by line sequentially, first removing any erroneous spaces at the beginning of each line, and then searching for the corresponding hierarchical rule in the preset indentation rule set based on the current logical context (e.g., whether the system is currently parsing an entity level or an attribute level). Once a matching rule is found, the system automatically adjusts the indentation of that line to the standard number of spaces required by the rule and synchronously switches the current context state based on the content characteristics of that line, thereby accurately guiding the rule matching for the next line. If a mismatch is encountered, the system will employ a fallback strategy of maintaining the original indentation or applying the default number of spaces. Through this rigorous line-by-line validation and dynamic repair, the system can effectively correct typesetting deviations caused by the large language model, generating a well-structured and grammatically correct third merge incremental editing command. Finally, the system precisely replaces the new content in this command according to the line number range (usually using reverse replacement to prevent line number offset) into the first structured configuration file, thereby generating a formatted, updated, and directly parsable and rendered third structured configuration file.

[0047] Step S105: Parse the third structured configuration file into a memory object, and render the corresponding visual interactive interface based on the memory object; The third structured configuration file refers to plain text configuration file data that has been incrementally edited and formatted by the large language model before being securely written to the local machine. For example, it might be the latest ontology YAML text containing the total amount of newly added orders and with fully compliant hierarchical indentation. An in-memory object refers to a program data structure that exists in the system's runtime memory after the plain text configuration file has been converted using a parsing library. For example, it might be a JavaScript object containing arrays of entities and relations, generated after parsing the YAML text using the js-yaml library. A visual interactive interface refers to a graphical display area dynamically generated based on the in-memory data structure, designed for direct viewing and manipulation by human users. For example, it might be an entity relationship topology graph rendered using the Mermaid engine on a webpage, or a dynamic form for modifying entity attributes.

[0048] This step is executed immediately after the third merge incremental editing command is successfully applied to the local configuration file and a third structured configuration file is generated on the front end. This enables real-time one-way synchronization of underlying code modifications to the graphical interface. Specifically, the system first reads the plain text content of the third structured configuration file and calls a specific format parser (e.g., the js-yaml library) to parse it into program-readable memory objects (e.g., JavaScript objects). Then, the system extracts key data sets (e.g., the entities and relations arrays) from these memory objects and standardizes this data, including unifying field names and supplementing missing default values. After processing, the system distributes this standardized data to the corresponding rendering pipeline. For example, entity and relation data are passed to the Mermaid ER graph renderer to redraw relational connections and nodes in real time, while entity attribute data is passed to form components to dynamically generate or refresh attribute editing forms. Through this underlying parsing and rendering mechanism, any modifications to the large language model at the code level can be instantly reflected on the graphical interface, allowing users to intuitively review design results without viewing the original code.

[0049] Step S106: Receive the modification operation triggered by the user on the visual interactive interface, update the memory object, reverse serialize the updated memory object into the fourth structured configuration file, add a line number prefix to each line of the fourth structured configuration file, and generate the fifth structured configuration file. The fifth structured configuration file is the input context for the next round of dialogue of the large language model. The modification operation refers to the specific business data change behavior triggered by a human user through a keyboard and mouse device on a graphical interface. For example, a user might modify the name of an entity attribute in a web form or select an attribute as a required field. The updated memory object refers to the program data structure that has been changed in real-time in runtime memory after the system captures the user's modification operation. For example, a JavaScript entity object whose internal attribute values ​​have changed. The fourth structured configuration file refers to the plain text configuration file generated by reverse conversion after the updated memory object has been simplified and formatted. For example, a plain YAML format string exported through a serialization function that conforms to strict indentation specifications. The line number prefix identifier refers to a specific character sequence appended to the beginning of each line of plain text to indicate the absolute position of that line. For example, a string consisting of right-aligned numbers padded to four digits wide plus a vertical bar separator, such as "14|". The fifth structured configuration file refers to the final text data where each line has a line number prefix identifier. For example, YAML text with complete line number coordinates that reflects the latest human modification results. Input context refers to a data snapshot passed to the large language model as background information when the user initiates a new round of dialogue. For example, the editingFile variable contains the fifth structured configuration file mentioned above.

[0050] This step is executed when and before the user completes data modification through a visual interactive interface and before sending the next round of dialogue requests to the large language model. It serves to achieve reverse synchronization between human interface operations and the underlying memory of the large language model. Specifically, the system first receives the modification operation triggered by the user on the visual interactive interface (such as a form or drag-and-drop canvas) and immediately updates the corresponding memory object in memory (e.g., updating entity or relational attributes in a JavaScript object). Next, the system performs low-level field simplification on this memory object, removing redundant fields used only by the front-end runtime (such as internally generated id, uri, createdAt, etc.) and renaming some attribute names that may conflict with YAML keywords (e.g., renaming type to dataType). Subsequently, the system calls a serialization tool (such as js-yaml.dump) and passes in fixed formatting parameters (e.g., indentation set to 2, disabling quoting, etc.) to deserialize the simplified memory object into a plain text format fourth-structured configuration file. Finally, the system executes a line numbering algorithm, iterating through each line of the fourth structured configuration file, calculating line numbers starting from 1, right-aligning them, padding them to a width of 4, and appending them to the line content using "|" as a separator, thus generating the fifth structured configuration file. This fifth structured configuration file, with precise line number coordinates, will be passed to the large language model as the input context for the next round of dialogue, ensuring that the large language model can accurately perceive and continue incremental editing based on the latest human modifications.

[0051] Optionally, refer to Figure 2 , Figure 2 which is a more specific process schematic diagram of step S102. Steps S10201 - S10205 are more specific solutions for step S102 of this solution; Step S10201: If there is a first incremental edit instruction with exactly the same start line number and end line number, retain the first incremental edit instruction with the most recent timestamp to obtain a number of second incremental edit instructions; Among them, the first incremental edit instruction with the most recent timestamp refers to the editing operation that represents the final intention and is output by the large language model last when there are repeated modifications. For example, retain the instruction that modifies line 3 to "-label: Party A" generated last time. The second incremental edit instruction refers to the set of valid and conflict - free edit instructions retained after duplicate removal within the same range. For example, three independent edit instructions (i.e., Edit 1, Edit 2, and Edit 3 in the figure) for lines 3, 6, and 8 respectively retained after duplicate removal.

[0052] The timing and scenario for this step to execute are: at the initial stage when all edit instructions in one round of loop of the large language model are collected and ready for merging processing, used to eliminate redundant and intermediate state modifications. Specifically, the system traverses all accumulated first incremental edit instructions and checks their start line numbers and end line numbers. If it is found that the scopes of multiple instructions are exactly the same, the system will consider this as the self - correction behavior of the large language model. At this time, the system discards the earlier generated instructions and only retains the first incremental edit instruction with the most recent timestamp (i.e., the last generated one). After this duplicate removal operation within the same range, the system filters out invalid intermediate steps and obtains a set of non - overlapping or representative of the final modification intention second incremental edit instructions, laying a foundation for subsequent merging.

[0053] Step S10202: Sort the second incremental edit instructions in descending order according to the start line number; Among them, sorting in descending order refers to the process of re - sorting the instruction list in the order from the largest line number to the smallest. For example, re - sort Edit 1, Edit 2, and Edit 3 originally arranged in the generation order to Edit 3 (line 8), Edit 2 (line 6), and Edit 1 (line 3).

[0054] The timing and scenario for this step to execute are: after obtaining the second incremental edit instructions through duplicate removal within the same range and before actually applying these instructions to the file content. Specifically, to prevent the line number positioning of subsequent instructions from shifting due to line number increase or decrease when applying edits, the system extracts the start line numbers of all second incremental edit instructions and re - sorts these instructions in descending order from the largest to the smallest based on this. As Figure 2As shown, the system places Edit 3 (for line 8) at the top, Edit 2 (for line 6) in the middle, and Edit 1 (for line 3) at the bottom. This reverse order strategy is a core prerequisite for ensuring that subsequent content replacements proceed from back to front.

[0055] Step S10203: Following the descending order, based on the original line numbers of the first structured configuration file, starting from the end of the first structured configuration file and moving backward, replace the content of the corresponding line number range in the first structured configuration file with the content corresponding to the second incremental editing instruction to obtain the second structured configuration file. Here, "original line number" refers to the absolute coordinates of the file before the replacement operation. For example, regardless of previous modifications, Edit 2 will always replace the original 6th line. "Replace from the end of the file forward" means applying the changes sequentially from the bottom of the file upwards. For example, first replace line 8, then line 6, and finally line 3. The second structured configuration file is the intermediate state file containing all the new content after all descending replacement operations have been performed. For example, after three replacements, the updated file content has 11 lines (because a line was inserted at line 6).

[0056] Specifically, the system applies the second incremental editing commands sequentially from the end of the file backwards, based on the original line numbers of the first structured configuration file, arranged in descending order. For example... Figure 2 As shown, the system first applies Edit 3, which replaces the original line 8 with "-label:Party B". This operation does not affect the line numbers of lines 1 to 7 preceding it. Next, Edit 2 is applied, replacing the original line 6 with "-name:x" and "-name:y". Although this inserts one line, causing a shift in the subsequent content, it still does not affect the original line numbers of lines 1 to 5 preceding it. Finally, Edit 1 is applied, replacing the original line 3 with "-label:Party A". Through this back-to-foreground replacement mechanism, each replacement perfectly avoids the problem of line number offset errors, ultimately resulting in a second structured configuration file containing all the modified content.

[0057] Step S10204: Determine the smallest target starting line number in the second incremental editing instruction; The smallest target starting line number refers to the starting line number that is the earliest (i.e., the smallest) among all the applied second incremental editing instructions. For example, among the three editing instructions for lines 3, 6, and 8, the smallest starting line number is 3, which represents the earliest starting boundary of the entire file where a change occurred.

[0058] This step is executed when and where: after all editing instructions have been applied and the second structured configuration file is obtained, and the final merge instruction range is ready to be generated. Specifically, the system iterates through the starting line numbers of all the second incremental editing instructions involved in the merge, finds the minimum value among them, and determines it as the minimum target starting line number. For example... Figure 2 As shown, the system compares Edit 1 (line number 3), Edit 2 (line number 6), and Edit 3 (line number 8), and finally determines the smallest target starting line number as 3. This value is crucial, as it marks the starting position of the final merged edit block, meaning that the content from this line to the end of the file will be packaged into a single unit for output.

[0059] Step S10205: Extract all text content from the target starting line number to the end of the file in the second structured configuration file as the merge content, and combine the target starting line number and the original total number of lines in the first structured configuration file to generate the first merge incremental editing instruction; The merged content refers to a continuous text block extracted from the second structured configuration file that contains all the modified results. For example, it's a text array consisting of the third line of the modified file up to the last line (a total of 8 lines). The original total number of lines refers to the total number of lines in the first structured configuration file before the modification. For example, as shown... Figure 2 The original file shown has 10 lines, hence the value of 10. The first merge incremental edit instruction refers to the final output, a global continuous edit block used for a one-time front-end replacement. For example, a REPLACE_LINES instruction with a starting line number of 3, a fixed ending line number of 10, and containing 8 lines of merged new content.

[0060] Specifically, the system uses the determined minimum target starting line number (i.e., line 3) as the starting point, extracts all lines from the second structured configuration file up to the end of the file, and combines these lines as the merged content (e.g., ...). Figure 2 The merged content is actually 8 lines. Subsequently, the system combines the minimum target starting line number (3) and the original total number of lines in the first structured configuration file (10) to generate the first merge incremental editing instruction. In this instruction, the ending line number is strictly fixed to the original total number of lines, 10, instead of the maximum value of the ending line number in each editing instruction (8). The reason for this is that the middle editing 2 inserted 1 line, causing the total number of lines after merging to be different from the original file. Using the original total number of lines, 10, as the ending line number ensures that when the front end receives the instruction, it can accurately replace the area from lines 3 to 10 of the original file with these 8 new merged lines in one go, thereby generating a new file with a total of 11 lines, completing the seamless merging of multiple edits.

[0061] Optional, see reference Figure 3 , Figure 3It is a schematic diagram of the process of step S103. Steps S10301 - S10302 are more specific solutions for step S103 of this solution; Step S10301, sequentially apply the following four - level matching rules to match and extract the first merged incremental edit instruction. The four - level matching rules include: The first - level matching rule: Match the instruction segment that contains the standard start tag and the standard end tag; The second - level matching rule: Match the instruction segment that contains the standard start tag and any end tag; The third - level matching rule: Match the instruction segment that contains the standard start tag to the end of the string; The fourth - level matching rule: Match the instruction segment that has no standard start prefix but contains file and line number identifiers; Among them, the four - level matching rule refers to a set of regular expression degradation parsing strategy sets designed in advance by the system for the unstable output format characteristics of the large - language model, in a decreasing order of strictness.

[0062] The first - level matching rule refers to the strictest standard format matching mode. For example, match the instruction segment whose start tag is strictly “<<<<<<<REPLACE_LINES:file:start - end” and the end tag is strictly “>>>>>>>END_REPLACE”. This rule is applicable to the scenario where the large - language model strictly follows the protocol format.

[0063] The second - level matching rule refers to the matching mode that relaxes the end boundary. For example, match the instruction segment whose start tag contains “<<<<<<<” and the line number range, and the end tag is “>>>>>>>” plus any other non - standard text. This rule is applicable to the scenario where there are variants in the end - tag text output by the large - language model.

[0064] The third - level matching rule refers to the matching mode for missing end tags. For example, match the instruction segment that starts from the start tag containing “<<<<<<<” and the line number range and截取 all the content until the end of the entire string. This rule is applicable to the scenario where the large - language model completely misses the end tag.

[0065] The fourth - level matching rule refers to the loosest fallback matching mode. For example, match the instruction segment that has no angle - bracket prefix at the start, only contains the keyword “REPLACE_LINES:file:start - end”, and ends with “>>>>>>>”, the code - block end symbol or the end of the text. This rule is applicable to the scenario where the large - language model completely omits the angle - bracket prefix.

[0066] This step is executed when the front end receives the first merge incremental editing instruction text from the large language model and prepares to extract the actual editing parameters and replacement content. Specifically, the parser applies these four levels of matching rules in descending order of strictness to match and extract the first merge incremental editing instruction. The system first attempts to apply the first-level matching rule to check if the text contains standard start and end markers; if not, the process moves down to the second-level matching rule to check if it contains standard start and arbitrary end markers; if still not, it continues to try applying the third-level matching rule, using all content from the standard start marker to the end of the string as the extraction target; if the first three levels fail, the system enters the final line of defense, attempting to apply the fourth-level matching rule, relying solely on keywords without standard start prefixes but containing file and line number identifiers for extraction. Through this waterfall-style degradation matching mechanism from strict to lenient, the system can accurately correspond to various abnormal applicable scenarios listed in the table, maximizing compatibility with possible marker omissions or format variations that may occur when the large language model generates editing instructions.

[0067] Step S10302: The instruction segment successfully matched and extracted for the first time is used as the second merge incremental editing instruction; The first successfully matched and extracted instruction segment refers to the valid text data block containing the target filename, line number range, and new content, immediately extracted by the system at any level of the four-level waterfall matching process, provided the regular expression matches successfully. For example, a text segment with a variant end marker successfully captured and extracted under the second-level matching rule. The second merge incremental editing instruction refers to the structured editing object obtained after fault-tolerant extraction and completion of special value conversion, filename validation, and automatic data format conversion. This object can be directly used for subsequent text replacement operations. For example, a standard data block containing a clear filename, start and end line numbers converted to actual numbers, and plain text replacement content.

[0068] This step is executed when and where: during the sequential flow of the four-level matching rules, it is executed immediately once a regular expression at a certain level successfully captures a text block that meets the conditions. This terminates the matching process and outputs the final parsing result. Specifically, the system uses a short-circuit evaluation mechanism, taking the instruction segment extracted from the first successful match as the basic data and performing in-depth format validation and conversion. First, the system processes the line number parameter in the extracted instruction segment, supporting and recognizing the special value LAST_LINE representing the end of the file, and automatically converting it to the actual total number of lines in the current file. Second, the system performs filename validation, comparing the filename in the instruction segment with the current target filename. If they do not match, the instruction segment is recorded as an invalid block.

[0069] Optionally, steps S10401-S10407 are a more specific embodiment of step S104 in this scheme. The indentation rule set includes several subsets of indentation rules corresponding to different current contexts. Each subset of indentation rules includes several indentation rules with a preset priority order. The indentation rules include matching regular expressions, preset indentation spaces, and target context. The core of this indentation validation and automatic repair process is building and running a context state machine driven by a set of indentation rules. Here, "state machine" refers to a logical control model used to dynamically track the text parsing hierarchy and determine the appropriate indentation depth. When processing configuration files with strict hierarchical nesting (such as YAML), the state machine defines the different logical levels that the file may have as independent "state nodes" (e.g., ...). Figure 4 (This refers to the `top`, `entities`, `entity`, and `entity_attributes` fields). When the state machine reads the text generated by the large language model line by line, it pauses at a specific state node and uses the node's rules to match the current text. Once a match is successful, the state machine performs two core actions: first, it forces the current line of text to have the standard indentation space count specified by the current node; second, it "flows" along a preset logical path to the next state node, thus guiding the parsing of the next line of text. Through this state transition mechanism, the system can accurately identify the true hierarchical position of the text within the overall data structure, thereby completely correcting the indentation errors generated by the large language model.

[0070] Step S10401: Dynamically determine the current global context based on the hierarchical relationship between the edited text and the first structured configuration file; Here, the global current context refers to the global logical state node where the state machine's internal pointer is currently located when parsing the text line by line. For example, Figure 4 In the state machine transition diagram, "top", "entities", and "entity" represent state nodes at different nesting levels.

[0071] This step is executed before the system begins line-by-line text repair, establishing a baseline state for the entire state machine. Specifically, when indentation repair begins, the system first reads a predefined set of indentation rules, extracts the defined initial entry node, and forcibly initializes the global current context to this preset initial context. It's important to note that the initial context of the state machine is not fixed at the Top level, but dynamically matches the parsing state of the original file based on the starting position of the edit block: when the edit block starts from line 1, the initial context is the preset Top level. When an edit block starts from the middle line, the text content that has not been modified before the edit block needs to be parsed first to obtain the final parsing context of that part of the text (for example, if the edit block starts from the 10th line and the 9th line is the content at the Entity level, then the initial context is Entity) to ensure that the subsequent indentation matching is completely consistent with the context logic of the original file.

[0072] like Figure 4 As shown, the starting point of the state machine is anchored in the "top" context, at which point the state machine is in the ready stage, waiting to receive the first line of text input and trigger subsequent state transitions.

[0073] The text lines in the edit text are traversed sequentially, and the following processing steps are performed on the currently traversed target text line: steps S10402-S10406. Step S10402: Remove leading spaces from the target text line to obtain the trimmed text line; In this context, the target text line refers to the line of plain text data that the state machine is currently reading and processing during its line-by-line traversal. For example, a line of text generated by a large language model containing "-name:EntityName". A leading whitespace refers to the leftmost consecutive whitespace character in the text line. For example, two or three indentation spaces incorrectly generated by a large language model. The pruned text line refers to the clean string retaining only the core business characteristics after removing all leading whitespace characters. For example, "-name:EntityName" after removing the leading whitespace.

[0074] This step is executed first when the state machine enters a processing loop for a specific line of text. It aims to eliminate interference from erroneous indentation generated by the large language model. Specifically, after reading the target text line, the system directly truncates and removes all leading spaces, resulting in the trimmed text line. This operation completely eliminates the potentially chaotic indentation and formatting issues of the large language model, allowing subsequent regular expression matching by the state machine to be based entirely on pure business text features, without being misled by existing erroneous formatting.

[0075] Step S10403: Determine the corresponding target indentation rule subset based on the current global context; The target indentation rule subset refers to a specific list of matching rules bound to the logical node where the current state machine is located, within a preset set of indentation rules. It represents all possible outward transition paths of the state machine under the current node. For example, when the global current context is... Figure 4When the “entity” state node is selected, the corresponding target indentation rule subset includes several specific rules that match “attributes:”, match “-name:\s+[AZ]”, and fall back to the “relations” state.

[0076] This step is executed after the trimmed text lines are obtained, but before regular expression matching is performed. It narrows down the matching range of the state machine and clarifies the syntax expectation at the current level. Specifically, the system directly maps and extracts the corresponding target indentation rule subset from the large set of indentation rules based on the pointer position of the current state machine (i.e., the global current context). For example... Figure 4 As shown, if the current context is "top", the system will only perform subsequent searches in the rule subset containing "entities:" and "relations:", which ensures that the state machine will only make judgments according to the valid hierarchical logic.

[0077] Step S10404: Search for the target matching regular expression that matches the trimmed text line in the target indentation rule subset according to the preset priority order; The preset priority order refers to the predefined order of matching among multiple flow paths within the same subset of target indentation rules. For example, in Figure 4 In the "attribute" context, attribute names starting with a lowercase letter are matched first, followed by entity names starting with an uppercase letter. A target matching regular expression refers to the specific trigger condition within a subset of rules that successfully matches the content of the currently pruned text line. For example, the regular expression "^-name:\s+[AZ]" successfully matches the pruned text line "-name:NewEntity".

[0078] This step is executed after the target indentation rule subset has been determined. It allows the state machine to accurately identify the business semantics of the current text line and find a suitable flow path. Specifically, within the extracted target indentation rule subset, the system strictly follows a preset priority order, sequentially testing the trimmed text line using the built-in regular expressions of each rule from top to bottom. Once a regular expression is found to perfectly match the content of the trimmed text line, the system stops searching and locks that expression as the target matching regular expression. This signifies that the state machine has found the corresponding processing rule.

[0079] Step S10405: If a target matching regular expression is found, the indentation of the target text line is adjusted to the preset number of indentation spaces corresponding to the target matching regular expression, and the current global context is updated to the target context corresponding to the target matching regular expression. The target context is used to determine the target indentation rule subset corresponding to the next text line. The preset indentation space count refers to the standard number of leading spaces that the text in that line should have at the current level, bound to the target matching regular expression. For example, when the state machine matches an entity list item, the preset indentation space count is 2; when it matches an entity attribute list item, the preset indentation space count is 6. The target context refers to the next logical node state that the state machine should jump to after a successful match. For example, after encountering "-name:EntityName" in the "entities" context, the target context is "entity".

[0080] This step is executed immediately after the state machine successfully finds a matching regular expression for the target text. It is used for substantive formatting correction and state machine node transitions. Specifically, if the system finds a matching regular expression, it extracts the preset indentation space number corresponding to the rule and re-concatenates the corresponding number of spaces on the left side of the trimmed text line, thereby precisely adjusting the indentation of the target text line to the standard depth. Simultaneously, the system extracts the target context corresponding to the rule and updates the global current context to that target context. For example... Figure 4 As shown, when the state machine matches the text “attributes:” in the “entity” context, the system adjusts the indentation of that line to 4 spaces and moves the pointer of the state machine (the current global context) to the “entity_attributes” node. This new node state will be used to guide the rule matching of the next line of text.

[0081] Step S10406: If no matching regular expression is found, then the process is handled according to the predefined backup strategy in the indentation rule set. The backup strategy includes: maintaining the original indentation of the target text line, or applying the preset default number of indentation spaces. The fallback strategy refers to the system's backup mechanism when the content of the target text line cannot trigger any transition path under the current state machine node. For example, a retention strategy configured as "keep". The default indentation space count refers to a fixed indentation depth value hard-defined in the fallback strategy. For example, forcing the application of 0 or 2 spaces.

[0082] This step is executed when and where: it occurs after traversing all rules in the current target indentation rule subset if the state machine still hasn't found a matching regular expression. This prevents the state machine from crashing or parsing from interrupting. Specifically, if the system doesn't find a matching regular expression, it means the large language model has generated abnormal content or blank lines that exceed the current indentation rule's expectations. In this case, the system processes the text according to a predefined fallback strategy in the indentation rule set. If the fallback strategy is configured to maintain the original indentation, the system abandons trimming the target text line and directly retains its original indentation state generated by the large language model; if configured as a number, it forcibly applies the preset default number of indentation spaces. After processing, the state machine remains at the original node, the global current context remains unchanged, and it continues to receive the next line of text.

[0083] Step S10407: After the traversal is completed, a third merge incremental editing instruction is generated based on the processed edited text; The processed edited text refers to a collection of multi-line strings that have been reassembled after all text lines have undergone state machine processing, including whitespace removal, matching, indentation reset, and state transitions. For example, a text block with disordered indentation becomes a well-structured, tightly indented, and perfectly aligned text block. Figure 4 The YAML text representing the state machine transition logic. The third merge incremental editing instruction refers to the final edit data block encapsulating the edited text after the above processing. For example, it is an instruction object that can be directly called by the underlying system to replace the corresponding area of ​​the original file.

[0084] This step is executed after all lines of text in the edited text have been traversed and processed line by line by the state machine, and it outputs the final result of the state machine's repair process. Specifically, the traversal process ends after the state machine completes the verification and repair of the last target line of text. The system then reassembles all the processed single-line text in sequence to form a fully compliant edited text. Subsequently, the system replaces this clean and correctly formatted text back into the original instruction object, generating the final third merge incremental editing instruction. This instruction will then be safely applied to the first structured configuration file, completely eliminating the risk of underlying file parsing failure caused by indentation errors in the large language model.

[0085] In addition, when YAML parsing fails on the first attempt (usually due to inconsistent LLM indentation), the system automatically performs a second repair attempt: The execution timing and scenario are as follows: It occurs when the system receives the YAML text generated by the large language model and prepares to parse it into an in-memory object for subsequent rendering or application. This is primarily used to handle high-frequency exceptions where the large language model's content logic is correct but its indentation format is unstable. Specifically, the system first performs a standard parsing of the current YAML text. If the format generated by the large language model is completely correct and parsing is successful, it proceeds directly to the next step. However, if the first parsing fails (usually due to inconsistent indentation levels generated by the large language model), the system does not immediately throw an exception and interrupt the task; instead, it automatically triggers a second attempt. In the second attempt, the system first calls a preset indentation rule set and state machine to perform forced indentation verification and automatic repair on each line of the YAML text, generating a new, well-formatted text. The parsing operation is then performed again on this new text. If parsing still fails after indentation repair (indicating that the content generated by the large language model has not only incorrect indentation but also serious grammatical or structural logical errors), the system will finally terminate parsing and report a warning to the large language model containing information about the location of the first failure. This two-stage strategy greatly improves the robustness of the system, ensuring that as long as the core content and business logic generated by the large language model are correct, even if there are flaws in indentation and formatting, the system can still successfully parse it through an automatic correction mechanism.

[0086] Optionally, steps S10501-S10503 are a more specific version of step S105 in this solution; Step S10501: During the execution of the first incremental editing instruction generated by the large language model, the dialog input interface is locked while the editing permissions of the visual interactive interface remain open. The execution period of the first incremental editing instruction generated by the large language model refers to the time period during which the large language model, after receiving a user request, is executing an inference and action loop (ReAct loop) in the background, continuously reading files and generating editing instructions. For example, the system interface displays the process status as "AI is thinking or outputting." Locking the dialogue input interface refers to the system disabling the user's chat input box or graying out the send button on the front end. For example, to prevent the user from sending new natural language instructions before the AI ​​has completed its current task. The visual interactive interface refers to the graphical operation area displayed to the user. For example, a low-code editing panel containing entity attribute forms and relationship connection canvases. Open editing permissions mean that the system allows users to continue to modify business data on the graphical interface using a mouse or keyboard. For example, while the AI ​​is thinking, the user can still manually modify the name of an entity or drag and drop to adjust the position of a node in the form.

[0087] This step is executed during the entire lifecycle of the large language model, after the user sends an editing request and while the model is processing the task. Its primary purpose is to allow for parallel human-machine collaboration while avoiding instruction-level conflicts. Specifically, when the large language model is in streaming output or background inference mode, the system implements a "semi-isolation" strategy at the front end. On one hand, the system locks the dialogue input interface, cutting off the user's ability to initiate new AI editing requests to prevent the large language model's processing queue from becoming chaotic or its context from becoming fragmented. On the other hand, the system separates the data layer from the text layer, maintaining complete openness to editing permissions on the visual interactive interface. This means that human user operations (acting on the object data layer) and the large language model's operations (acting on the underlying text layer) can occur simultaneously. Users don't need to wait for the AI ​​to finish its work; they can use this time to fine-tune other attributes in the form, greatly improving the efficiency of human-machine collaboration.

[0088] Step S10502: When the third merge incremental editing instruction is applied to the first structured configuration file to generate the third structured configuration file, the memory object is re-parsed and overwritten. The third merge incremental editing instruction refers to the final plain text modification block output by the large language model and after multi-level fault-tolerant parsing and indentation repair by the front end. For example, a correctly formatted YAML text fragment containing newly added attributes. The first structured configuration file refers to the original underlying plain text file before modification. The third structured configuration file refers to the latest plain text file generated after safely replacing the above text blocks to the corresponding line numbers in the original file. A memory object refers to a program data structure existing in the system's runtime memory, which can be directly read and bound by the front-end graphical interface. For example, a JavaScript object containing all current entity and relation attributes. Re-parsing and overwriting refers to the forced refresh process where the system calls the parsing library to convert the latest plain text file back into a program object and replaces the original object in memory with this new object.

[0089] This step is executed immediately after the large language model completes modifications at the text layer and the system successfully generates the third structured configuration file. It serves to unidirectionally synchronize changes to the underlying text to the memory data layer. Specifically, since the large language model's editing operations are essentially line-level replacements of the underlying plain text (text layer), while humans see graphics rendered based on memory objects (object layer) in the visualization interface, the system immediately triggers a re-parsing mechanism at the underlying level when the third merge incremental editing command is applied to the file and generates the third structured configuration file. The system reads the latest content of the third structured configuration file, re-parses it into the latest memory object, and forcibly overwrites the old object in memory. This operation ensures that modifications to the large language model at the code level can instantly refresh the memory state, thereby driving the visualization interface to update automatically and allowing users to immediately see the AI's editing results.

[0090] Step S10503: If the user modifies the memory object through the visual interactive interface during execution, the operation of reverse serialization into the fourth structured configuration file is performed before the next round of dialogue in the large language model, based on the current latest memory object state. The execution period refers to the time window during which the large language model performs inference and output. Modifying the memory object refers to a human user directly altering the properties of a JavaScript object in memory through an open visual form or drag-and-drop operation. For example, while working with the AI, a user manually changes a required field from "no" to "yes". Before the next round of dialogue refers to the critical moment when the user is about to send a new command to the large language model again through the chat box. The current latest memory object state refers to the data snapshot of the memory object after undergoing AI text layer overlay and possible subsequent human form modifications. Reverse serialization to a fourth structured configuration file refers to the process of converting this final memory object back into plain text format. For example, exporting the JavaScript object back into standard YAML text using the js-yaml.dump method.

[0091] This step is executed during the intervals between human and machine editing, especially before the user initiates the next dialogue request. It resolves state conflicts caused by overlapping human and machine editing time, ensuring eventual consistency. Specifically, the system employs a conflict handling strategy based on "Last Writer Wins" and state reconstruction. If the user modifies a memory object (object layer) through the visual interface during AI execution, and the AI's edit results refresh the memory object after re-parsing, the system does not perform complex text-level diff merging. Instead, the system always trusts and relies on the latest memory object state. Before the large language model initiates the next round of dialogue, the system extracts the latest object data in memory (which naturally incorporates AI modifications and human final confirmation), performs reverse serialization, converts it into a fourth structured configuration file, and further adds line numbers to generate a fifth structured configuration file. This line-numbered file, reconstructed based on the latest object layer state, serves as an absolutely accurate context for the large language model, completely avoiding data version conflicts and state fragmentation.

[0092] Optionally, before step S101, this solution may also execute steps S107-S109; Step S107: Based on the size characteristics of the set of files to be edited, dynamically calculate the maximum number of loops in the large language model and the multi-level reminder parameters; The size characteristic of the file set to be edited refers to the basic attribute data acquired by the system at the initial stage of the task, used to measure the workload of this editing task. For example, it includes the total number of lines in each file in the target file set and the system-set upper limit for the number of lines read per chunk (CHUNK_SIZE). The maximum number of loop rounds represents the absolute upper limit set by the system for the large language model, allowing it to alternate between reasoning and action. For example, it is an integer variable (max_rounds) calculated by a formula between 8 and 30, used to prevent the task from being delayed indefinitely. The multi-level reminder parameter refers to the threshold variables used to control when and at what frequency the system intervenes in the large language model. For example, it includes the threshold for the number of tool calls for the first reminder (first_reminder, usually between 3 and 8 times) and the number of tool calls for subsequent reminder intervals (reminder_interval, usually between 3 and 6 times).

[0093] This step is executed after the user initiates an editing task and before the large language model officially starts the ReAct (inference-action) loop to read files and generate instructions. It primarily serves to tailor reasonable operational boundaries for editing tasks of different scales. Specifically, the system first performs dynamic calculations based on the size characteristics of the file set to be edited. The system iterates through the file set, divides the number of lines in each file by the block read limit and rounds up, then sums the results for all files to obtain the estimated number of read calls. Next, the system adds 5 to this estimated number of read calls and limits it to a minimum of 8 rounds and a maximum of 30 rounds, thus calculating the maximum number of loop rounds. Subsequently, the system calculates multi-level reminder parameters: the estimated number of read calls is divided by 2 and limited to between 3 and 8 as the threshold for the first reminder tool call count; the estimated number of read calls is divided by 3 and limited to between 3 and 6 as the interval for subsequent reminders. This dynamic computing mechanism ensures that small-scale edits (such as 1 to 2 files) can be completed quickly within 8 rounds, while large-scale edits (such as more than 10 files and thousands of lines of code) have ample reading and reasoning space of up to 30 rounds.

[0094] Step S108: During the loop execution of the large language model, the current execution state features are obtained in real time. The current execution state features include at least the current loop number and the total number of tool calls. The cyclic execution process refers to the continuous running state of the large language model, driven by the ReAct framework, alternately executing "analyzing the current context" and "calling tools (such as reading files, searching files)". The current execution state features represent a set of progress indicators of the large language model monitored and recorded in real time by the system in the background. The current loop number refers to the numerical variable indicating which inference loop the large language model is currently in since the task started. For example, variable R represents the current 15th loop. The total number of tool calls refers to the absolute number of times the large language model has called various auxiliary tools. For example, variable T represents that the large language model has called the file reading tool 10 times.

[0095] This step is executed in real-time between each round of inference and action after the large language model starts its loop processing task, providing precise real-time data support for subsequent dynamic reminder strategies. Specifically, the system deploys a real-time monitoring mechanism in the ReAct loop engine. Whenever the large language model completes a tool call or ends a round of inference output, the system captures and updates the current execution state features in real time. The system not only accurately records the current loop number (R) and the total number of tool calls (T), but also maintains a historical state variable, namely the number of tool calls (L) when the system reminder was last triggered. These real-time acquired state feature data, reflecting the current behavioral rhythm of the large language model, will be used as core input parameters and directly passed to the reminder matching logic in the next stage.

[0096] Step S109: Based on the current execution state characteristics, maximum number of loop rounds, and multi-level reminder parameters, match the corresponding reminder level and inject guidance information corresponding to the reminder level into the large language model to control the reading and reasoning behavior of the large language model; The "alert level" refers to the intensity of intervention in the large language model, assessed by the system based on its current operational status. For example, it can be categorized into four levels: strong alert, soft alert, moderate alert, and no alert. Guidance information represents system prompts with explicit instructions that are forcibly inserted into the dialogue context. For example, a strong alert might correspond to a natural language control instruction such as "Require immediate editing or a response; further file reading is prohibited." Reading and reasoning behavior refers to the large language model's decision-making tendency in the next step: whether to continue using tools to explore the file or directly use editing tools to output the final result.

[0097] This step is executed when and in what scenarios: after the system obtains the current execution status characteristics in real time, and before the large language model starts the next round of inference. It is primarily used to prevent the large language model from getting stuck in an infinite file reading loop through gradual intervention. Specifically, the system strictly matches the real-time obtained current loop number (R), the total number of current tool calls (T), and the number of calls at the time of the last reminder (L) with the pre-calculated maximum loop number (max_rounds) and multi-level reminder parameters. The system executes logical branches according to a preset progressive reminder strategy: when R is greater than or equal to max_rounds minus 2 and T is greater than L, it matches as a "strong reminder," and the system injects guidance information into the large language model, prohibiting further reading and requiring immediate editing; when T is less than or equal to the initial reminder threshold, or the interval since the last reminder is insufficient (i.e., T minus L is less than the subsequent reminder interval), it matches as a "no reminder," allowing the large language model to read and reason freely; when T is exactly at the critical point of the initial reminder threshold plus 1, it matches as a "soft reminder," and the system injects gentle guidance information, prompting the user to respond if sufficient information has been obtained, otherwise reading can continue; if none of the above conditions are met, it matches as a "moderate reminder," and the system injects guidance information urging the model to organize information and provide an answer as soon as possible. Through this precise matching and guidance information injection, the system achieves effective control over the behavioral rhythm of the large language model.

[0098] Optionally, before performing indentation verification and automatic repair on the edited text corresponding to the second merge incremental editing instruction line by line based on the preset indentation rules to obtain the third merge incremental editing instruction, this scheme can also execute steps S110-S112. Step S110: Perform full-domain detection on the edited text using cleanup regular expressions to identify and remove residual line number prefixes in the edited text; Cleaning regular expressions refers to pre-written code rule strings used by the system to match specific noisy text patterns. For example, regular expression rules specifically for matching combinations of numbers followed by colons or vertical bars. Editing text refers to the raw string data output by the large language model, containing actual business modifications but potentially mixed with system noise. For example, Figure 5 The top text block displays "AI Raw Output". Global detection refers to a thorough scanning and matching operation of every line within the entire text block. Residual line number prefixes indicate that the large language model, when calling a file reading tool, incorrectly copied the system-provided line number format verbatim into the editing commands. For example, Figure 5 The format shown is either "213:" in "213:content" or "425|" in "425|content".

[0099] This step is executed after the front-end parser successfully extracts the edited text, but before YAML indentation fixing or actual application to the configuration file. It serves as the first step in the three-level cleanup pipeline to purify the text data. Specifically, the system initiates the cleanup pipeline, first performing line number prefix cleanup on the edited text. Because large language models are accustomed to contexts with line numbers when reading files, they often mistakenly include these prefixes when outputting new content. The system uses preset cleanup regular expressions to perform a full-domain check on each line of the edited text. For example... Figure 5 As shown, the system can accurately identify and is compatible with various common error formats, such as format 1 (e.g., "213:content") and format 2 (e.g., "425|content"). Once these residual line number prefixes are detected, the system immediately removes them from the beginning of the line, retaining only the actual business content (i.e., the "content" part). Furthermore, this line number prefix cleanup mechanism is deployed in both the backend editing tools and the frontend parser, forming a dual-protection mechanism to ensure the complete elimination of line number noise.

[0100] Step S111: Detect the beginning and end of the edited text and remove any remaining code block markers from the edited text; The "beginning and end" sections refer to the first and last lines of the edited text. Residual code block markers are additional syntax symbols added by the large language model when generating code or configuration text, based on its inherent Markdown formatting conventions, to wrap code snippets. For example, Figure 5 The text shows the "yaml" or "json" language declaration on the first line and the "``" closing symbol on the last line.

[0101] This step is executed after line number prefix removal and before special characters are processed. As the second step in the three-level cleanup pipeline, it eliminates formatting interference caused by typesetting syntax. Specifically, the edited text after the first cleanup step enters the second pipeline, where the system performs targeted detection on the beginning and end of the text. Because large language models tend to automatically use Markdown syntax to beautify multi-line text output, this can lead to the mixing of non-configured markup into plain text instructions. For example... Figure 5 As shown, the system rigorously checks whether the first line of the text contains code block start tags like "yaml" or "json", and also checks whether the last line contains closing "``" tags. If these residual code block tags are detected, the system will strip or delete the entire line. This operation ensures that the final extracted content is purely YAML or JSON configuration data, preventing these Markdown tags from causing syntax errors during subsequent parsing.

[0102] Step S112: Perform full-domain detection on preset special characters in the edited text, and process the detected preset special characters to comply with regulations; Among them, pre-defined special characters refer to symbols that have special reserved semantics in specific configuration file syntax (such as YAML), and whose direct appearance in plain text would cause parsing to crash. For example, Figure 5 The text mentions the naked asterisk character (naked *) mentioned earlier, which is interpreted as an alias reference in YAML syntax. Compliance processing refers to the operation of converting potentially destructive special characters into safe, ordinary string values ​​by adding escape characters or enclosing them in quotes. For example, Figure 5 The process shown in the image is converting a bare asterisk "*" into a single quote "''".

[0103] This step is executed after removing code block markers and before the text is sent to the indentation state machine for repair. As the final step in the three-level cleanup pipeline, it ensures the security of the underlying syntax parsing. Specifically, the system performs a final character-level security check on the edited text after the first two rounds of cleanup. The system performs a full-domain check on the edited text, focusing on finding preset special characters. In structured configurations such as YAML, certain characters have extremely high sensitivity, such as... Figure 5 As shown, if a large language model generates a naked asterisk (naked *) without quotes, the YAML parser will incorrectly identify it as an alias reference, leading to a serious parsing interruption. When the system detects such pre-defined special characters, it immediately performs compliance processing, i.e., performs YAML alias security operation, automatically wrapping the naked asterisk in single quotes (turning it into '*'), forcibly downgrading it to a normal string literal. Through this three-level pipeline of filtering and processing, the originally noisy AI raw output is finally transformed into fully compliant and clean content, laying a solid data foundation for subsequent indentation repair and secure applications.

[0104] In addition, a system for implementing this solution includes a ReAct loop engine, a tool executor, a multi-edit merger, a multi-level fault-tolerant parser, a schema-driven indentation repairer, an LLM output cleaner, a visualization rendering engine, a deserialization module, and an SSE streaming communication module.

[0105] The tool executor manages file context and edit accumulation. It maintains an in-memory copy of the original file content and provides four core tools: read_file (block reading with line numbers), search_file (keyword search), list_files (file list), and apply_edit (edit accumulation), as well as an extensible domain tool registration interface.

[0106] A multi-edit merger is used to combine multiple edits of the same file into a single REPLACE_LINES edit block on the original file content. The merger performs same-range deduplication (keeping the last one), sorting in descending order, and replacing each element from the end to the beginning, ultimately outputting a single edit block covering min_start to the end of the file.

[0107] A multi-level fault-tolerant parser is used to extract REPLACE_LINES edit blocks from AI response text. The parser attempts four levels of regular expression matching in descending order of strictness (standard format → loose end → no end marker → no beginning prefix), and supports LAST_LINE special values ​​and filename validation.

[0108] A schema-driven indentation fixer is used to correct indentation errors in YAML content generated by LLM. The fixer uses a context state machine pattern to correct indentation line by line according to a predefined indentation schema (including context switching rules and the proper indentation depth for each line).

[0109] An LLM output cleaner is used to remove noise from AI output. The cleaner performs line number prefix removal (in both formats), Markdown code block mark removal, and YAML special character safety in sequence.

[0110] A visualization rendering engine is used to parse configuration files into various visualization formats in real time. The rendering engine receives configuration text in YAML or JSON format, converts it into in-memory objects using a format-specific parser (YAML Parser / JSON.parse), and then distributes it to the corresponding rendering pipeline based on the configuration type: Ontology YAML → Mermaid ER diagram syntax generation → Mermaid.js rendered as SVG; Workflow YAML → node-edge data structure extraction → topology graph rendering component; Permissions YAML → role-permission matrix data structure → table component rendering; Project Information YAML → key-value pair extraction → dynamic generation of form controls. Each change to the configuration file (regardless of whether it was edited by AI or modified by humans) triggers a re-parsing and rendering process.

[0111] The deserialization module is used to reverse-update user modifications made in the visual interface to the configuration file. The module receives structured change events generated by users through forms, checkboxes, or drag-and-drop operations, and performs the following processing pipeline: (1) Field normalization - converting UI control values ​​into the types and format conventions of the configuration file; (2) YAML serialization - reserializing the changed data structure into YAML text that conforms to the original indentation style; (3) Line number annotation - adding the LINE_NUMBER| prefix to each line of the serialization result, so that AI can directly locate the change position by line number in the next ReAct loop.

[0112] The SSE streaming communication module establishes a one-way real-time communication channel between the AI ​​agent and the front end, transmitting inference text, tool call progress, and final editing results during the ReAct loop. This solution achieves three-way synchronization between AI editing, configuration files, and the visualization interface through SSE streaming communication. (See reference...) Figure 6 , Figure 6 The timing logic diagram for SSE streaming communication implementation.

[0113] The AI ​​incremental editing and visualization synchronization device in the embodiments of this invention is described below from the perspective of hardware processing. Please refer to [link / reference]. Figure 7 This is a schematic diagram of the physical device structure of an AI incremental editing and visualization synchronization device in the embodiments of this application.

[0114] It should be noted that, Figure 7 The structure of the AI ​​incremental editing and visualization synchronization device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0115] like Figure 7 As shown, the AI ​​incremental editing and visualization synchronization device includes a CPU 701, which can perform various appropriate actions and processes based on a program stored in the read-only memory ROM 4702 or a program loaded from the storage section 708 into the random access memory RAM 703, such as performing the methods described in the above embodiments. The RAM 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An I / O interface 705 is also connected to the bus 704.

[0116] The following components are connected to I / O interface 705: input section 706 including audio input devices, push-button switches, etc.; output section 707 including a liquid crystal display (LCD) and audio output devices, indicator lights, etc.; storage section 708 including a hard disk, etc.; and communication section 709 including a network interface card such as a LAN (Local Area Network) card, modem, etc. Communication section 709 performs communication processing via a network such as the Internet. Drive 710 is also connected to I / O interface 705 as needed. Removable media 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 710 as needed so that computer programs read from them can be installed into storage section 708 as needed.

[0117] In particular, according to embodiments of the present invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of the present invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing computer programs for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by CPU 701, it performs the various functions defined in the present invention.

[0118] It should be noted that specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0119] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Each block in a flowchart or block diagram may represent a module, program segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those shown in the drawings.

[0120] Specifically, the AI ​​incremental editing and visualization synchronization device in this embodiment includes a processor and a memory. The memory stores a computer program, and when the computer program is executed by the processor, it implements the AI ​​incremental editing and visualization synchronization method provided in the above embodiment.

[0121] In another aspect, the present invention also provides a computer-readable storage medium, which may be included in the AI ​​incremental editing and visualization synchronization device described in the above embodiments; or it may exist independently and not assembled into the AI ​​incremental editing and visualization synchronization device. The storage medium carries one or more computer programs, which, when executed by a processor of the AI ​​incremental editing and visualization synchronization device, cause the AI ​​incremental editing and visualization synchronization device to implement the AI ​​incremental editing and visualization synchronization method provided in the above embodiments.

[0122] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This program can be stored in a computer-readable storage medium, and when executed, it can include the processes described in the above method embodiments. The aforementioned storage medium includes various media capable of storing program code, such as ROM or random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for synchronizing AI incremental editing and visualization, characterized in that, The method includes: The first incremental editing instruction based on the line number range output by the large language model is obtained. The starting line number and ending line number corresponding to the first incremental editing instruction are both based on the original line number of the first structured configuration file in the initial state of the current editing round. The first structured configuration file serves as the editing medium of the large language model, the data source for visualization rendering, and the data carrier for human visualization interaction. For multiple first incremental editing instructions for the same first structured configuration file, the first incremental editing instructions are applied to the first structured configuration file to obtain a second structured configuration file. A first merge incremental editing instruction is generated based on the second structured configuration file, and the end line number of the first merge incremental editing instruction is fixed to the original total number of lines of the first structured configuration file. The first merge incremental editing instruction is format-validated and extracted using preset multi-level matching rules to obtain the second merge incremental editing instruction. Based on a preset set of indentation rules, the indentation of the edited text corresponding to the second merge incremental editing instruction is checked and automatically repaired line by line to obtain the third merge incremental editing instruction. The third merge incremental editing instruction is then applied to the first structured configuration file to generate the third structured configuration file. The third structured configuration file is parsed into a memory object, and the corresponding visual interactive interface is rendered based on the memory object; The system receives modification operations triggered by the user on the visual interactive interface, updates the memory object, reverse serializes the updated memory object into a fourth structured configuration file, adds a line number prefix to each line of the fourth structured configuration file, and generates a fifth structured configuration file, which serves as the input context for the next round of dialogue in the large language model.

2. The method according to claim 1, characterized in that, The process of applying the first incremental editing instructions to the first structured configuration file to obtain a second structured configuration file, and generating a first merge incremental editing instruction based on the second structured configuration file, specifically includes: If there exists a first incremental editing instruction with the same start line number and end line number, then retain the first incremental editing instruction with the most recent timestamp to obtain several second incremental editing instructions; Arrange the second incremental editing instructions in descending order according to the starting line number; Following the descending order, based on the original line numbers of the first structured configuration file, starting from the end of the first structured configuration file and moving backward, the content of the corresponding line number range in the first structured configuration file is replaced with the content corresponding to the second incremental editing instruction to obtain the second structured configuration file. Determine the smallest target starting line number in the second incremental editing instruction; Extract all text content from the target starting line number to the end of the file in the second structured configuration file as the merge content, and combine the target starting line number with the original total number of lines in the first structured configuration file to generate the first merge incremental editing instruction.

3. The method according to claim 1, characterized in that, The step of performing format verification and extraction on the first merge incremental editing instruction using preset multi-level matching rules to obtain the second merge incremental editing instruction specifically includes: The following four-level matching rules are applied sequentially to match and extract the first merge incremental editing command. The four-level matching rules include: Level 1 matching rule: matching command segments containing standard start and end markers; Level 2 matching rule: matching command segments containing standard start markers and arbitrary end markers; Level 3 matching rule: matching command segments from the standard start marker to the end of the string; Level 4 matching rule: matching command segments without a standard start prefix but containing file and line number identifiers. The first successfully matched and extracted instruction segment will be used as the second merged incremental editing instruction.

4. The method according to claim 1, characterized in that, The indentation rules are used to perform line-by-line indentation verification and automatic repair on the edited text corresponding to the second merge incremental editing instruction, resulting in the third merge incremental editing instruction, which specifically includes: The indentation rule set includes several subsets of indentation rules corresponding to different current contexts. Each subset of indentation rules includes several indentation rules with a preset priority order. The indentation rules include matching regular expressions, a preset number of indentation spaces, and the target context. The current global context is dynamically determined based on the hierarchical relationship between the edited text and the first structured configuration file; The text lines in the edited text are traversed sequentially, and the following processing steps are performed on the currently traversed target text line: Remove leading spaces from the target text line to obtain the trimmed text line; The corresponding target indentation rule subset is determined based on the current global context; In the target indentation rule subset, search for the target matching regular expression that matches the trimmed text line according to the preset priority order; If the target matching regular expression is found, the indentation of the target text line is adjusted to the preset number of indentation spaces corresponding to the target matching regular expression, and the current global context is updated to the target context corresponding to the target matching regular expression. The target context is used to determine the target indentation rule subset corresponding to the next text line. If no matching regular expression is found for the target, then the process is handled according to the predefined backup strategy in the indentation rule set. The backup strategy includes: maintaining the original indentation of the target text line, or applying the preset default number of indentation spaces. After the traversal is completed, the third merge incremental editing instruction is generated based on the processed edited text.

5. The method according to claim 1, characterized in that, The step of receiving a modification operation triggered by the user on the visual interactive interface and updating the memory object specifically includes: During the execution of the first incremental editing instruction generated by the large language model, the dialog input interface is locked, while the editing permissions of the visual interactive interface remain open; When the third merge incremental editing instruction is applied to the first structured configuration file to generate the third structured configuration file, the memory object is re-parsed and overwritten; If the user modifies the memory object through the visual interactive interface during the execution, the operation of deserializing it into a fourth structured configuration file will be performed before the next round of dialogue in the large language model, based on the current latest memory object state.

6. The method according to claim 1, characterized in that, Prior to the step of obtaining the first incremental editing instruction based on the line number range from the output of the large language model, the method further includes: Based on the size characteristics of the set of files to be edited, the maximum number of loops in the large language model and the multi-level reminder parameters are dynamically calculated. During the cyclic execution of the large language model, the current execution state features are acquired in real time, and the current execution state features include at least the current loop number and the total number of tool calls. Based on the current execution state characteristics, the maximum number of loop rounds, and the multi-level reminder parameters, a corresponding reminder level is matched, and guidance information corresponding to the reminder level is injected into the large language model to control the reading and reasoning behavior of the large language model.

7. The method according to claim 1, characterized in that, Before the step of performing line-by-line indentation verification and automatic repair on the edited text corresponding to the second merge incremental editing instruction based on preset indentation rules to obtain the third merge incremental editing instruction, the method further includes: The edited text is subjected to full-domain detection by cleanup regular expressions to identify and remove residual line number prefixes in the edited text; The beginning and end of the edited text are detected, and residual code block markers in the edited text are removed; The system performs full-domain detection on preset special characters in the edited text and then performs compliance processing on the detected preset special characters.

8. An AI incremental editing and visualization synchronization device, characterized in that, The AI ​​incremental editing and visualization synchronization device includes: one or more processors and a memory; the memory is coupled to the one or more processors, the memory is used to store computer program code, the computer program code includes computer instructions, and the one or more processors call the computer instructions to cause the AI ​​incremental editing and visualization synchronization device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium comprising instructions, characterized in that, When the instruction is run on the AI ​​incremental editing and visualization synchronization device, the AI ​​incremental editing and visualization synchronization device performs the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on the AI ​​incremental editing and visualization synchronization device, the AI ​​incremental editing and visualization synchronization device performs the method as described in any one of claims 1-7.

Images