Code generation method, electronic device, and storage medium

Abstract

The application discloses a code generation method, an electronic device and a storage medium, and relates to the technical field of artificial intelligence and models. The method comprises the following steps: in response to receiving a function development requirement of a target project, acquiring original project code and a function configuration file corresponding to the function development requirement, and starting an isolated container environment, wherein the isolated container environment is used to represent a container environment isolated from a local environment of a server; creating a code change area corresponding to the original project code in the isolated container environment; in the isolated container environment, generating at least one code generation task corresponding to the function development requirement by using a first model; and in the code change area, performing code change on the original project code by using a second model according to the function configuration file and the at least one code generation task, so as to obtain target project code. The application solves the technical problem of low code generation efficiency in the prior art.

Description

Technical Field

[0001] This application relates to the fields of artificial intelligence technology and computer programming, and more specifically, to a code generation method, an electronic device, and a storage medium. Background Technology

[0002] Current mainstream artificial intelligence (AI) programming tools rely on a single intelligent agent. Although they can generate partial code, in cross-module development tasks that take several hours, the loss of state or lack of workspace isolation often leads to AI-generated code overwriting user-manual modifications, causing irreversible code conflicts and data loss, which seriously hinders the continuity and reliability of automated development processes.

[0003] There is currently no effective solution to the above problems. Summary of the Invention

[0004] This application provides a code generation method, an electronic device, and a storage medium to at least solve the technical problem of low code generation efficiency in related technologies.

[0005] According to one aspect of the embodiments of this application, a code generation method is provided, applied to a server, comprising: responding to receiving a functional development requirement for a target project, obtaining the original project code and functional configuration file corresponding to the functional development requirement, and starting an isolated container environment, wherein the isolated container environment is used to represent a container environment isolated from the local environment of the server; creating a code modification area corresponding to the original project code in the isolated container environment; generating at least one code generation task corresponding to the functional development requirement using a first model in the isolated container environment; and modifying the original project code using a second model in the code modification area according to the functional configuration file and at least one code generation task to obtain the target project code.

[0006] According to one aspect of the embodiments of this application, a code generation method is provided, comprising: responding to an input instruction applied to an operation interface, displaying the functional development requirements of a target project on the operation interface; and responding to a processing instruction applied to the operation interface, displaying the target project code on the operation interface, wherein the target project code is obtained by modifying the original project code corresponding to the functional development requirements in a code modification area according to a functional configuration file and at least one code generation task using a second model, the at least one code generation task is generated in an isolated container environment using a first model according to the functional development requirements, the code modification area is created in the isolated container environment based on the original project code, and the isolated container environment is started according to the functional development requirements.

[0007] According to one aspect of the embodiments of this application, a code generation method is provided, comprising: obtaining functional development requirements of a target project by calling a first interface, wherein the first interface includes a first parameter, and the parameter value of the first parameter includes the functional development requirements; obtaining the original project code and functional configuration file corresponding to the functional development requirements, and starting an isolated container environment, wherein the isolated container environment is used to represent a container environment isolated from the local environment of the server; creating a code modification area corresponding to the original project code in the isolated container environment; generating at least one code generation task corresponding to the functional development requirements using a first model in the isolated container environment; modifying the original project code in the code modification area according to the functional configuration file and at least one code generation task using a second model to obtain the target project code; and outputting the target project code by calling a second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter includes the target project code.

[0008] According to another aspect of the embodiments of this application, a computing device is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0009] According to another aspect of the embodiments of this application, an electronic device is also provided, including: a memory storing an executable program; and a processor connected to the memory via a bus for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0010] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0011] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0012] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the methods in various embodiments of this application.

[0013] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0014] In this embodiment, in response to receiving the functional development requirements of the target project, the original project code and functional configuration file corresponding to the functional development requirements are obtained, and an isolated container environment is started. The isolated container environment represents a container environment isolated from the local environment of the server. A code change area corresponding to the original project code is created in the isolated container environment. In the isolated container environment, at least one code generation task corresponding to the functional development requirements is generated using a first model. In the code change area, based on the functional configuration file and at least one code generation task, the original project code is modified using a second model to obtain the target project code. Based on the project specifications and component constraints in the functional configuration file, the first model decomposes the functional development requirements into at least one code generation task, and the second model executes the code changes item by item in the code change area of ​​the isolated container environment. Due to the independent file system and process space of the isolated container environment, it can be ensured that code modifications only affect the code change area and do not interfere with the original environment of the server. Simultaneously, the continuity of task execution and configuration consistency are guaranteed, thereby improving the automation accuracy and execution efficiency of code generation, and thus solving the technical problem of low code generation efficiency in related technologies.

[0015] It is worth noting that the general description above and the detailed description that follow are merely for illustrative purposes and do not constitute a limitation on this application. Attached Figure Description

[0016] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0017] Figure 1 This is a schematic diagram illustrating an application scenario of a code generation method according to an embodiment of this application;

[0018] Figure 2 This is a flowchart of a code generation method according to an embodiment of this application;

[0019] Figure 3 This is a system architecture diagram according to an embodiment of this application;

[0020] Figure 4 This is a schematic diagram of module interaction according to an embodiment of this application;

[0021] Figure 5 This is a flowchart of a workspace distributed version control system according to an embodiment of this application;

[0022] Figure 6 This is a flowchart of a conflict resolution method according to an embodiment of this application;

[0023] Figure 7 This is a flowchart of a code generation method according to an embodiment of this application;

[0024] Figure 8 This is a flowchart of a code generation method according to an embodiment of this application;

[0025] Figure 9 This is a schematic diagram of a code generation apparatus according to an embodiment of this application;

[0026] Figure 10 This is a schematic diagram of a code generation apparatus according to an embodiment of this application;

[0027] Figure 11 This is a schematic diagram of a code generation apparatus according to an embodiment of this application;

[0028] Figure 12 This is a structural block diagram of a computing device according to an embodiment of this application;

[0029] Figure 13 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0030] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0031] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0032] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0033] The technical solution provided in this application is mainly implemented using a deep learning model. Deep learning models can be widely applied in fields such as Natural Language Processing (NLP), computer vision, and speech processing. Specifically, they can be applied to computer vision tasks such as Visual Question Answering (VQA), Image Captioning (IC), and Image Generation, as well as to NLP tasks such as text-based sentiment classification, text summarization, and machine translation. Therefore, the main application scenarios of this application include, but are not limited to, digital assistants, intelligent robots, search, online education, office software, e-commerce, and intelligent design.

[0034] First, some nouns or terms that appear in the description of the embodiments of this application shall be interpreted as follows:

[0035] A sandbox environment is an isolated computing container that provides an independent file system, process space, and network environment for securely executing at least one code generation task.

[0036] Multiple agents, including planner agents, encoder agents, and other specialized agents, each responsible for specific duties and working together.

[0037] The state machine orchestration system, based on an orchestration framework of state nodes and transition rules, defines the state transition logic between intelligent agents and realizes complex task process management.

[0038] Skills repository is a collection of structured files that store knowledge in areas such as project specifications, component documentation, and interface definitions.

[0039] The rules engine is a hierarchical system that manages global rules, platform rules, and user-defined rules, and supports rule prioritization and merging.

[0040] The asynchronous communication channel, based on the asynchronous communication mechanism of the streaming message queue, supports real-time push by producers and blocking listening by consumers.

[0041] The workspace is an independent working directory created in the sandbox. Modifications made by the agent only affect the shadow workspace and do not directly impact the source repository.

[0042] A soft link, a symbolic link in the file system, points to a dependent file in a shared storage area, avoiding duplicate storage.

[0043] The key center is a service that centrally manages encryption keys and sensitive credentials, and supports credential decryption, dynamic rotation, and access control.

[0044] Persistent storage, in a sandbox environment, is storage space that can be retained after the container restarts; it usually has size limitations.

[0045] According to an embodiment of this application, a code generation method is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0046] The technical solutions provided in this application can employ deep learning models with relatively large parameter scales, such as large models containing billions or even more model parameters. Here, "large model" is merely an example; this application does not limit the number of model parameters supported by the deep learning model used, aiming to meet actual needs. The deep learning models involved in this application can be artificial intelligence-based language models (LM) or multimodal models (MM).

[0047] Considering the limited computing resources of mobile terminals, the methods described above in this application embodiment can be applied to, for example... Figure 1 The application scenarios shown are not limited to these. Figure 1 This is a schematic diagram illustrating an application scenario of a code generation method according to an embodiment of this application. Figure 1 In the application scenario shown, the deep learning model is deployed on server 10. Server 10 can connect to one or more client devices 20 via a local area network (LAN), wide area network (WAN), internet connection, or other types of data network. These client devices 20 may include, but are not limited to, smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices. Client devices 20 can interact with users through a graphical user interface to invoke the deep learning model, thereby implementing the method provided in this embodiment.

[0048] In this embodiment, the system consisting of a client device and a server can perform the following steps: The client device generates the functional development requirements for the target project. The server obtains the original project code and functional configuration file corresponding to the functional development requirements and starts an isolated container environment; a code modification area corresponding to the original project code is created in the isolated container environment; in the isolated container environment, at least one code generation task corresponding to the functional development requirements is generated using a first model; in the code modification area, based on the functional configuration file and at least one code generation task, the original project code is modified using a second model to obtain the target project code.

[0049] It should be noted that with the rapid development of high-performance computing units, the methods provided in this application embodiment can also be applied to model-in-the-loop machines in other application scenarios. In one optional embodiment, the model-in-the-loop machine has multiple built-in models. Users can select one model to adjust as needed to obtain their own model. The high-performance computing unit built into the model-in-the-loop machine can then directly call the adjusted model to execute the methods provided in this application embodiment. In another optional embodiment, the deep learning model-in-the-loop machine has a pre-trained model built-in. Therefore, the high-performance computing unit built into the model-in-the-loop machine can directly call this model to execute the methods provided in this application embodiment.

[0050] Furthermore, when users need to train their own models, they can upload their own datasets via the client. These datasets are then sent to the server, allowing the server to adjust the pre-trained model using the dataset to obtain the user's customized model, which can then be deployed to the production environment. To facilitate users' model adjustment needs, the server provides complete adjustment tools, development frameworks, and processes, supporting multiple adjustment strategies. This allows the adjusted model to better adapt to different application domains and achieve a high degree of customization.

[0051] Under the aforementioned operating environment, this application provides the following: Figure 2 The code generation method shown. Figure 2 This is a flowchart of a code generation method according to an embodiment of this application. For example... Figure 2 As shown, the method may include the following steps:

[0052] In step S202, in response to receiving the functional development requirements of the target project, the original project code and functional configuration file corresponding to the functional development requirements are obtained, and the isolated container environment is started.

[0053] Among them, the isolated container environment is used to refer to the container environment isolated from the local environment of the server.

[0054] The aforementioned functional development requirements can be descriptions of user intent, input via natural language or structured commands, clearly indicating the need to add or modify functions. Functional development requirements may include functional boundaries, behavioral expectations, input / output conditions, and information about related modules.

[0055] The original project code mentioned above refers to the source code files, resource files, and directory structure contained in the current version of the target project. It is hosted by a version control system and includes program logic, interface definitions, dependency declarations, and build scripts. It constitutes the initial state baseline for code generation operations. Changes to the target project's code can be made incrementally by starting with the original project code.

[0056] The aforementioned functional configuration file is a metadata file stored in a structured text format, describing the development constraints and specifications of the target project. This configuration file includes module interface definitions, coding style rules, component call restrictions, naming conventions, permission model definitions, data format standards, and third-party library usage agreements. It provides semantic constraints and contextual guidance for the code generation process, ensuring that the output conforms to the project architecture and quality requirements.

[0057] The isolated container environment described above is an independent running instance built in the local environment of the server. An isolated container environment can have an independent file system view, process tree, network protocol stack, user and group permission context, and resource quota restrictions. File reading and writing, process startup, network connections, and system calls within the isolated container environment are restricted to the container boundary and cannot directly access other files, services, or configurations on the host operating system, ensuring the purity of the execution environment and the predictability of operations.

[0058] The local environment of the aforementioned server is the main operating system running on the physical server or virtual machine where the code generation service is deployed, along with its globally configured runtime components, including system-level library files, global environment variables, system services, user permission configurations, installed global toolchains, and persistent storage paths.

[0059] In one optional embodiment, after receiving the feature development requirements of the target project, the corresponding original project code can be obtained from the remote code repository according to the requirement identifier, and the feature configuration file associated with the feature development requirements can be read. Then, an independent isolated container environment is started in the local environment of the server. This isolated container environment is independent of the local environment's file system, process space and runtime configuration. It is mainly used to load the original project code and feature configuration file as initial content to ensure that subsequent operations are not affected by dynamic changes in the local environment, thereby providing a stable and reproducible execution foundation for code generation.

[0060] Optionally, upon receiving the feature development requirements for the target project, a unique session identifier for the target project can be created. Based on this unique session identifier, an isolated container environment corresponding to the original project code can be created in the local environment of the server, and the isolated container environment can be started to implement the feature development requirements of the target project. Alternatively, upon receiving the feature development requirements, the isolated container environment created based on the target project can be determined based on the unique session identifier of the target project, and then the isolated container environment can be started.

[0061] Step S204: Create a code change zone corresponding to the original project code in the isolated container environment.

[0062] The aforementioned code modification area is an independent file directory created in an isolated container environment based on a complete copy of the original project code. This directory and the original project code are different path entities in the file system. Code modification behavior only applies to the directory. The path where the original project code is located remains read-only. The code modification area does not share file nodes with the host environment, nor is it allowed to directly write to the storage location of the original project code. This ensures that any changes during the generation process are restricted to an independent copy, avoiding any impact on the source code.

[0063] The aforementioned code modification area can also be called the shadow working area. This shadow working area is an independent operating space formed by a complete copy of the original project code within an isolated container environment. Its name comes from the fact that this area exists as a mirror copy of the original code. Code generation and modification actions are performed on this copy, while the original project code remains silent and untouched. Just as a shadow follows the main body but does not interfere with it, this ensures that any changes during the generation process are confined to the independent copy, achieving non-intrusive operation on the source code.

[0064] In the already started isolated container environment, read all the files and directory structure of the original project code, and create a new directory with the same content in the isolated container environment according to its original path hierarchy. This new directory serves as the code change area, and the location of the original project code remains unchanged. All subsequent code operations point to this code change area, ensuring that the generation process is decoupled from the original project code.

[0065] Step S206: In the isolated container environment, utilize the first model generation function to develop at least one code generation task corresponding to the requirements.

[0066] The aforementioned at least one code generation task refers to a set of code operation instructions with a clear change target, output by the first model after parsing the functional development requirements. Each task specifies the complete path of the target file, the operation type (create, update, or delete), and describes the semantic change content to be implemented. The aforementioned at least one code generation task can be the smallest indivisible operation unit output by the first model after parsing the functional development requirements and the functional configuration file. Each code generation task explicitly specifies the complete path of the target file and the operation type (create, update, or delete). When at least one code generation task contains multiple tasks, each task can correspond to a single modification of a single file, or it can cover collaborative changes to multiple related files within the same functional module.

[0067] The first model described above is a processing unit with task decomposition and planning capabilities, running in an isolated container environment. This first model receives functional development requirements as input and, based on the project structure, interface specifications, and coding constraints defined in the functional configuration file, decomposes these requirements into multiple atomic-level code generation tasks. Each task explicitly specifies the target file path, change type, and expected behavior. For example, this could involve adding a configuration file in a specified directory or modifying the parameter validation logic of a function. This first model does not directly generate code content; it primarily outputs a task sequence for subsequent processing units to use.

[0068] In an optional embodiment, the first model can be used to perform semantic parsing of functional development requirements. Combining the module relationships, interface definitions and development constraints defined in the functional configuration file, the abstract functional development requirements can be transformed into a series of clear and executable code generation tasks. Each task can contain an independent change target. There are no dependencies or nesting between tasks, forming a linear executable sequence. The task content does not contain implementation details, but only describes the change intention and target location, providing clear operation instructions for the second model.

[0069] Step S208: In the code change area, based on the function configuration file and at least one code generation task, the original project code is modified using the second model to obtain the target project code.

[0070] The second model described above is a processing unit capable of generating and modifying code. It runs in an isolated container environment and can receive the code generation task list output by the first model. Combined with the specification information in the function configuration file, it performs file creation, content update, or deletion operations on the copy of the original project code in the code change area to generate target code that meets semantic and structural requirements. Code changes can be limited to the code change area and do not access or modify the original project code path or other files in the host environment. Its output is a complete set of code that has been validated by specifications and can be directly used for subsequent integration.

[0071] The aforementioned functional configuration files define project-level coding standards and architectural constraints, providing a consistent basis for code generation. These configuration files do not specify concrete modifications, but rather define the structure, style, security policies, dependency usage methods, and design principles that the code should follow. When implementing changes, the second model uses the functional configuration files as a verification benchmark to ensure that the generated code, in addition to semantic implementation, also meets the project's existing engineering standards. The functional configuration files ensure "how to write correctly," while the code generation task determines "what to write." Under the joint constraints of both, the second model transforms abstract functional development requirements into concrete code changes that conform to engineering standards, achieving a unification of intent and standards.

[0072] In one optional embodiment, within the code change area, the second model analyzes and adjusts the original project code based on the coding standards and system constraints specified in the functional configuration file, combined with the modification locations and semantic goals indicated by at least one code generation task, gradually generating a final code version that conforms to the specifications. The functional configuration file provides a consistency standard for changes, ensuring that the code structure and style do not deviate from the project's established requirements; the code generation task clarifies the scope of operation, guiding the model to focus on specific modifications and avoiding meaningless inferences. Under the joint constraints of both, the second model completes precise changes, ensuring that the generated results both respond to the intended requirements and maintain engineering consistency, thereby improving code acceptability and subsequent maintainability.

[0073] Through the above steps, in response to receiving the functional development requirements of the target project, the system obtains the original project code and functional configuration file corresponding to the functional development requirements, and starts an isolated container environment. The isolated container environment represents a container environment isolated from the local environment of the server. A code change area corresponding to the original project code is created within the isolated container environment. Within the isolated container environment, at least one code generation task corresponding to the functional development requirements is generated using a first model. In the code change area, based on the functional configuration file and at least one code generation task, the original project code is modified using a second model to obtain the target project code. Based on the project specifications and component constraints in the functional configuration file, the first model decomposes the functional development requirements into at least one code generation task, and the second model executes the code changes item by item in the code change area of ​​the isolated container environment. Due to the independent file system and process space of the isolated container environment, it can be ensured that code modifications only affect the code change area and do not interfere with the original environment of the server. Simultaneously, it ensures the continuity of task execution and configuration consistency, thereby improving the automation accuracy and execution efficiency of code generation, and thus solving the technical problem of low code generation efficiency in related technologies.

[0074] In the above embodiments of this application, in the code change area, the original project code is modified using a second model according to the functional configuration file and at least one code generation task to obtain the target project code. This includes: in the code change area, modifying the original project code using a second model according to the functional configuration file and at least one code generation task to obtain modified project code; in response to receiving a modification event of the original project code, synchronizing the modified project code contained in the modification event to the code change area; and determining the target project code based on the modified project code and the modified project code in the code change area.

[0075] The aforementioned modification event is a change notification triggered by the client and transmitted to the server after the user manually edits the original project code in the local environment. The carrier of the modification event is structured data containing file paths and content snapshots, which is used to synchronize the user's intervention behavior to the code change area.

[0076] The aforementioned change project code is the code version generated by the second model in the code change area after modifying the original project code according to the function configuration file and at least one code generation task. This change project code exists in the code change area and has not yet been merged with the user's modifications.

[0077] The modified project code mentioned above refers to the user's local modifications synchronized to the code change area by the modification event. The modified project code and the changed project code share the same file path, but the content originates from manual operation, representing the user's direct adjustment to the code.

[0078] The target project code mentioned above is the final consistent code state formed after file-level comparison and merging strategy processing, based on the coexistence of changed project code and modified project code in the code change area.

[0079] In one optional embodiment, the original project code is first loaded into the code change area. Then, the second model generates the changed project code based on the functional configuration file and at least one code generation task. When the server receives a modification event from the client, it can write the modified project code contained therein into the same code change area, so that the manual modification and the model-generated result are in the same space. Subsequently, the system compares the changed project code and the modified project code file by file, identifies common modification areas, and determines the final content to be retained according to the preset merging rules, forming the target project code.

[0080] In this embodiment, the code change area provides a unified change execution environment for both the model and manual operations, eliminating overwrite conflicts caused by the shared file system in traditional models. The functional configuration file ensures that the code generated by the second model always conforms to the project's established structure and specifications, preventing the generated results from deviating from engineering expectations. At least one code generation task provides the model with clear change boundaries, guiding it to focus on the code location and behavioral goals indicated by the user's intent. The modification event mechanism incorporates user-initiated modifications into the system processing flow, making manual intervention a legitimate input for code evolution. The coexistence and comparison mechanism of changing project code and modifying project code ensures that model generation and manual modification are aligned in an isolated environment, rather than being a one-way overwrite. This process does not rely on external tools, completing collaborative processing solely through local file system operations and structured data synchronization.

[0081] This application's embodiments achieve spatial isolation between model generation and manual modification through code change areas, ensure the standardization and consistency of the generated results through functional configuration files, guide change intentions through at least one code generation task, incorporate manual intervention through modification events, and achieve collaborative integration through a coexistence comparison mechanism of changed project code and modified project code, ultimately forming the target project code. This effectively reduces the risk of code coverage and logical conflicts caused by parallel model generation and manual editing, and improves the stability of the collaboration process and the predictability of the results.

[0082] In the above embodiments of this application, determining the target project code based on the changed project code and modified project code in the code change area includes: comparing the modified project code and the changed project code in the code change area, obtaining a comparison result, and outputting the comparison result, wherein the comparison result is used to represent the difference between the modified project code and the changed project code; and determining the target project code based on the feedback information received from the comparison result.

[0083] The comparison results above are a structured description of the differences formed after analyzing the differences between the modified project code and the changed project code line by line in the same file path. It includes the line numbers and content fragments of the added, deleted, and modified files, and is used to clarify the overlapping of modifications made to the same file by both humans and machines.

[0084] The feedback information described above represents the user's selection instructions based on the comparison results. These instructions allow the user to confirm whether to retain the changed project code, retain the modified project code, or accept the merge suggestion. The feedback is in the form of structured response data and does not contain implementation logic; it only expresses the user's intention to handle the differences. The target project code is the final consistent code status determined based on the feedback information. The content of the target project code integrates the results of model generation and manual intervention, and final confirmation is completed in the code change area.

[0085] In one optional embodiment, the changed project code and the modified project code are first stored together in the code change area. Then, the contents of the two under the same file path can be compared line by line to identify the added, deleted, and modified code segments, generate a structured comparison result, and output it to the user terminal through the communication channel. After the user views the comparison result, they can choose to retain the model-generated content, retain the manually modified content, or confirm the merging suggestion according to their actual needs. The system receives the feedback information and determines the final code segments to be retained based on its content, and combines them to form the target project code.

[0086] In another optional embodiment, the feedback information can be: retaining the modified project code, indicating that the user approves of the modifications generated by the second model and chooses to overwrite the local modifications; retaining the modified project code, indicating that the user insists on their own adjustments to the code and rejects the changes generated by the model; or accepting the merging suggestion, indicating that the user confirms that the non-conflicting modifications suggested in the comparison results can be retained simultaneously, and the non-overlapping parts of the modified project code and the modified project code can be integrated according to the feedback information to form the final target project code.

[0087] In this embodiment, the comparison result generation mechanism enables users to clearly recognize the specific conflict points between the model-generated content and their own modifications, rather than merely perceiving the ambiguous state of the modified file, thus improving the transparency of human-computer collaboration. The feedback information serves as the user's explicit authorization for handling differences, incorporating human decision-making power into the system process and avoiding the uncontrollable risks brought about by automatic system overwriting or forced merging. The process of determining the target project code relies entirely on the synergistic effect of the comparison results and feedback information, ensuring that the final code state reflects both the model's automation capabilities and respects the user's direct intervention intentions.

[0088] This application embodiment clearly demonstrates the specific differences between modified project code and changed project code through comparison results. It enables users to make controllable decisions on the handling of differences through feedback information. By coordinating the two to determine the target project code, the integration process of model generation and manual modification is made visible, operable, and verifiable. This effectively reduces the risk of erroneous coverage caused by opaque code changes and improves the certainty of the collaboration process and the acceptability of the results.

[0089] In the above embodiments of this application, the method further includes: determining the task type of at least one code generation task; configuring the second model into the execution node in the state machine based on the task type; and using the first model to send at least one code generation task to the second model according to the triggering condition of the execution node.

[0090] The above task types are an abstract classification of the intent expressed by at least one code generation task. Based on the nature, scope and dependency of the code operations involved in the task, they are divided into categories such as creating files, updating methods, refactoring modules, adding configurations, and importing dependencies, in order to distinguish development behaviors with different semantic dimensions.

[0091] The state machine described above is a task orchestration framework built on nodes and directed edges. Nodes represent executable processing units, and edges represent the triggering conditions and execution order between nodes. The whole system is used to coordinate the collaborative process of multiple agents.

[0092] The aforementioned execution nodes are pre-defined processing units in the state machine that are bound to specific task types. Each execution node encapsulates the execution strategy, tool calling specifications, and context constraints required for the corresponding task type. Each execution node is associated with a specific second model for code generation to execute that type of task.

[0093] The first model described above is an intelligent agent with task parsing and scheduling capabilities. It can understand the user's original needs, break down at least one code generation task, match the execution node in the state machine according to the task type, and then determine whether the execution environment is ready based on the node's triggering conditions, thereby deciding whether to initiate task distribution.

[0094] In one optional embodiment, a first model can perform semantic parsing on at least one code generation task, determining the task type of the at least one code generation task based on the target operation and context. Subsequently, based on the task type, the execution node bound to it can be located in the state machine, and the corresponding second model can be loaded into the execution node, completing the static binding between the model and the task type. The first model verifies whether the current environment meets the execution prerequisites based on the triggering conditions defined by the execution node, including whether the sandbox environment is initialized, whether the function configuration file is loaded, whether the dependency directory is established through soft links, and whether the code change area is ready. After all conditions are met, the first model takes at least one code generation task as input, which is dispatched by the execution node to the bound second model to start the code generation process.

[0095] In this embodiment, the division of task types allows complex development requirements to be structured into identifiable semantic units, avoiding intent confusion and output deviation caused by mixed tasks in a single model. The state machine, through the structured design of nodes and edges, realizes the visual orchestration and sequential control of the task execution process, ensuring the dependencies and execution order between multiple tasks. The execution node serves as the adaptation interface between the task type and the second model, allowing tasks of different semantic categories to be handled by specialized models, improving generation accuracy and consistency. The first model, as the scheduling hub, performs environment pre-verification based on the triggering conditions of the execution node, ensuring that the code generation task starts under conditions of complete resources and appropriate state, avoiding execution failure due to missing dependencies or abnormal environment. This mechanism decouples task identification, model selection, environment verification, and instruction distribution into independent links, forming a reusable and scalable task execution chain.

[0096] For example, based on the task type, the "update method" can be bound to the coding node in the state machine, which is associated with a second model that has method-level generation capabilities; the "add configuration" can be bound to the configuration node in the state machine, which is associated with a second model that has configuration file generation capabilities. The first model checks the triggering conditions of the execution node: the sandbox environment has been started, the feature configuration file has been loaded, the project dependencies have been mounted via symbolic links, and the source code of the code change area has been cloned. After confirming that all conditions are met, the corresponding code generation tasks are sent to the coding node and the configuration node respectively. The second model of the coding node generates the verification method, and the second model of the configuration node generates the configuration items. The two are executed sequentially under the control of the state machine without interfering with each other.

[0097] This application embodiment achieves semantic classification of requirements by determining the task type of at least one code generation task, achieves precise adaptation between the model and the task by configuring the second model to the execution node of the state machine, and achieves compliance control of the execution environment by scheduling tasks according to the trigger conditions of the execution node through the first model. This enables complex development tasks to have a clear execution path, adaptable processing capabilities and stable startup guarantee in multi-model collaborative scenarios, thereby improving the rationality of task decomposition and the reliability of the execution process.

[0098] In the above embodiments of this application, at least one code generation task is multiple code generation tasks, the second model is multiple sub-models, the second model is configured into the execution nodes in the state machine based on the task type, and the first model is used to send at least one code generation task to the second model according to the triggering conditions of the execution nodes, including: configuring multiple sub-models into multiple sub-execution nodes in the state machine based on the task type, and using the first model to distribute multiple code generation tasks to the second model according to the triggering conditions of the multiple sub-execution nodes.

[0099] The aforementioned code generation tasks are user-submitted sets of instructions consisting of multiple independent semantic units. Each task explicitly specifies the file path to be operated on, the expected functional behavior and change type, and they can be executed independently semantically without strong coupling or dependency.

[0100] The aforementioned sub-models are multiple specialized intelligent agents. Each sub-model has specific types of code generation capabilities, such as file creation, method updating, configuration injection, and test generation. The scope of their capabilities is limited by the preset training data and constraint rules.

[0101] The aforementioned sub-execution nodes are multiple processing units in the state machine that correspond one-to-one with multiple sub-models. Each sub-execution node is bound to a sub-model and encapsulates the context specifications, tool call permissions, and execution order constraints required for the sub-model to execute tasks.

[0102] The aforementioned state machine is a task orchestration framework built on nodes and directed edges, used to coordinate the start time, execution order and dependencies of multiple sub-execution nodes; the first model is an intelligent agent with task parsing and scheduling capabilities, which can decompose the user's original requirements into multiple code generation tasks, identify their task types, and determine whether the execution environment is ready based on the triggering conditions of the sub-execution nodes, thereby triggering task distribution.

[0103] In one optional embodiment, the first model performs semantic analysis on multiple code generation tasks one by one, and determines the task type of each code generation task based on the operation goal and context features of the first model. Subsequently, based on each task type, multiple sub-execution nodes matching it can be located in the state machine, and the corresponding multiple sub-models can be configured into the corresponding sub-execution nodes to complete the static binding between the model and the task type. On this basis, the first model sequentially verifies the triggering conditions defined by each sub-execution node, including the sandbox environment status, the loading status of the function configuration file, the existence of soft links in the dependency directory, and whether the code change area has been initialized. When all the triggering conditions of a certain sub-execution node are met, the first model sends the corresponding code generation task as input to the sub-model bound to the sub-execution node to start its code generation action. The triggering and execution processes of multiple sub-execution nodes are independent of each other, supporting concurrent or sequential scheduling, and do not depend on global synchronization.

[0104] In this embodiment, the structured decomposition of multiple code generation tasks breaks down complex development requirements into parallelizable atomic units, avoiding inference bias caused by task overload in a single model. The specialized design of multiple sub-models allows each model to focus on a specific task type, improving generation accuracy and consistency. Multiple sub-execution nodes act as an isolation and adaptation layer between task types and sub-models, enabling models with different capabilities to work collaboratively within a unified orchestration framework without interference. The state machine achieves controllable orchestration of task execution order through inter-node dependencies, ensuring that preconditions for tasks are met. The first model acts as the scheduling hub, performing environmental checks based on the independent triggering conditions of each sub-execution node, ensuring that tasks only start when resources are complete and the state is compliant, avoiding overall process blockage due to missing local resources. This mechanism achieves parallel task scheduling, specialized model reuse, and autonomous execution conditions, improving the stability and resource utilization of multi-task collaboration.

[0105] For example, based on task type, "update method" can be bound to the coding sub-execution node and associated with a sub-model capable of method generation; "create file" can be bound to the creation sub-execution node and associated with a sub-model capable of file generation; and "add configuration" can be bound to the configuration sub-execution node and associated with a sub-model capable of configuration generation. The first model verifies the triggering conditions of the three sub-execution nodes: the coding sub-execution node's dependent configuration file has been loaded, the creation sub-execution node's dependent code change area has been initialized, and the configuration sub-execution node's dependent directory symbolic links have been established. Once all conditions are met, the first model sends the corresponding tasks to the three sub-execution nodes in parallel. The coding sub-model generates verification logic, the creation sub-model generates test files, and the configuration sub-model generates fields. These three processes execute independently within the state machine framework, without affecting each other, ultimately completing the full functionality.

[0106] This application embodiment establishes a one-to-one correspondence between multiple code generation tasks and multiple sub-models and multiple sub-execution nodes. Combined with the independent verification and distribution mechanism of the first model for the triggering conditions of each sub-execution node, it realizes the parallelization, specialization and conditional execution of multiple tasks, improves the decomposition granularity of complex development requirements, the accuracy of model invocation and the fault tolerance of task scheduling, and makes the multi-agent collaborative process have higher scalability and execution efficiency.

[0107] In the above embodiments of this application, obtaining the original project code and functional configuration file corresponding to the functional development requirements includes: determining the project code information and project request information in the functional development requirements; retrieving the original project code from the project repository corresponding to the target project based on the project code information; and determining the functional configuration file based on the project request information.

[0108] The project code information mentioned above is identifying data that explicitly refers to the target project in the functional development requirements. It includes the project's unique identifier, source code repository address, branch name, or commit version number, and is used to accurately locate the code set to be operated on.

[0109] The project request information mentioned above refers to the contextual constraints and specification requirements implicitly or explicitly expressed in the functional development requirements, including technology stack preferences, component usage specifications, interface definitions, security policies, or coding standards, which are used to guide the compliance of the generated content.

[0110] The aforementioned project repository is a remote code hosting system that stores the complete source code and historical versions of the target project, and supports accessing specific branches or committed code snapshots through version control protocols.

[0111] In one optional embodiment, project code information and project request information can be extracted from functional development requirements. The project code information is used to locate the target code repository, and the project request information is used to determine the knowledge basis. Subsequently, based on the repository address and branch identifier in the project code information, the system connects to the project repository via a version control protocol and pulls the original project code of the corresponding version to the code change area of ​​the sandbox environment. On this basis, the project request information can be parsed, and based on the technical terms, component names, or specification keywords mentioned in the project request information, the system can retrieve the semantically matching functional configuration files and load them into the current session context as the constraint basis for subsequent code generation.

[0112] In this embodiment, the extraction of project code information enables precise location of the target project, avoiding code misoperation due to project confusion; the complete retrieval of the original project code ensures that the generation operation is based on a consistent and traceable baseline state, preventing semantic deviations caused by local environment differences; the structured parsing of project request information transforms unstructured user intent into executable specification constraints, making the generated content domain-adaptable; the dynamic loading mechanism of the functional configuration file achieves context sensitivity of knowledge injection, enabling the model to adapt to different project styles without global learning, reducing model size dependence. This mechanism decouples project location, code acquisition, and knowledge loading into independent stages, forming a stable and reusable initialization process.

[0113] This application embodiment achieves precise positioning of the target project by extracting project code information from functional development requirements, ensures consistency of change benchmarks by retrieving original project code from the project repository, and dynamically injects domain knowledge by determining functional configuration files through project request information. This ensures that the code generation process is based on the correct project context and specification constraints, thereby improving the accuracy, consistency, and deliverability of the generated content.

[0114] In the above embodiments of this application, retrieving the original project code from the project repository corresponding to the target project based on the project code information includes: determining the project repository address and code branch name of the target project based on the project code information; and retrieving the original project code from the project repository based on the project repository address and code branch name.

[0115] The aforementioned project repository address is a structured access path used to uniquely identify the storage location of a target project in a remote version control system. Its form is a Uniform Resource Identifier that conforms to the version control protocol specification, including the protocol type, host domain name or address, path level, and project identifier.

[0116] The code branch name mentioned above is a naming identifier used in the project repository to identify a specific development line or version snapshot. The code branch name is the branch reference name maintained by the version control system within the project repository.

[0117] In one optional embodiment, project code information is first extracted from the functional development requirements, and the project repository address and code branch name are parsed out. Then, a communication connection with the remote project repository can be established through a version control protocol based on the project repository address, and the latest commit node pointed to by the code branch can be located based on the code branch name. After the connection and location are successful, a code cloning operation can be performed to completely copy all the file contents corresponding to the branch to the local code change area to form the original project code.

[0118] In this embodiment, extracting the project repository address ensures that the system can access the correct code storage source, avoiding code obfuscation or access failure due to incorrect addresses; identifying the code branch name ensures that the obtained code version matches the user's intent. Figure 1 To prevent semantic discrepancies caused by incompatibility between the default branch or trunk version and the target development environment; the complete retrieval of the original project code establishes a unified code baseline, ensuring that subsequent generation actions are performed in a consistent context, reducing generation errors caused by local environment differences, uncommitted modifications, or branch misalignment; the use of version control protocols ensures that the code retrieval process has version traceability and atomicity, avoiding the loss of some files or inconsistencies in their state.

[0119] This application embodiment achieves accurate identification of the target code version by extracting the project repository address and code branch name from the functional development requirements, and fully pulls the original project code through the version control protocol, establishing a stable and reusable code benchmark, ensuring that subsequent code generation behavior is executed in a consistent and controllable context, and improving the matching degree and deliverability of the generated content with the target project environment.

[0120] In the above embodiments of this application, determining the functional configuration file based on project request information includes: performing semantic analysis on the project request information to obtain target keywords and project function descriptions, wherein the target keywords are keywords associated with the target project; and determining the functional configuration file based on the target keywords and project function descriptions.

[0121] The semantic analysis described above is a process of parsing the language structure and extracting intent from project request information. It uses natural language processing technology to identify semantic units, extract semantic entities and functional intents that are strongly related to the project context, and output structured semantic elements.

[0122] The target keywords mentioned above are semantic identifiers extracted after semantic analysis that are directly related to the existing architecture, technology stack, or specification system of the target project. Target keywords are terms with clear directional characteristics within the project domain of the target project.

[0123] The above-mentioned project function descriptions are abstract summaries of the functional behaviors that users expect to achieve, extracted after semantic analysis. They are used to define the boundaries and goals of the generated tasks, such as "adding login failure retry restrictions", "integrating log tracking modules", and "supporting multi-tenant configuration".

[0124] In one optional embodiment, semantic analysis is first performed on the project request information. Through lexical parsing, named entity recognition, and semantic role labeling (SLA), target keywords and project function descriptions are identified. Subsequently, the target keywords are matched with preset metadata tags in the function configuration file. These metadata tags include a keyword set, applicable technology stack, associated component names, and applicable scenario descriptions. When the semantic overlap between the target keywords and the metadata tags of a function configuration file exceeds a preset threshold, the function configuration file is determined to be a candidate file associated with the current request. Based on this, the candidate files can be further analyzed in conjunction with the project function description. Figure 1 Consistency verification confirms whether the content covers the functional intent described by the user; ultimately, the functional configuration file with high semantic overlap and complete intent coverage can be selected as the constraint basis for the current task.

[0125] In this embodiment, semantic analysis transforms unstructured natural language requirements into computable semantic elements, enabling a mapping from user intent to system resources. Target keywords serve as semantic anchors for project domain knowledge, preventing matching failures due to differences in expression. Project function descriptions provide functional boundary constraints, ensuring that the functional scope supported by the selected configuration file aligns with user intent. The metadata tagging mechanism of the function configuration file achieves knowledge retrieval and scalability, allowing specifications to be loaded on demand without global learning. This mechanism, through dual verification of keywords and intent, improves the accuracy of configuration file matching and the precision of context adaptation, avoiding prompt pollution or model deviation caused by irrelevant knowledge injection.

[0126] This application embodiment extracts target keywords and project function descriptions by performing semantic analysis on project request information, and then matches the function configuration file based on the two to achieve accurate and dynamic loading of domain knowledge. This enables the code generation process to be executed according to constraints consistent with the actual specifications of the target project, improving the consistency and context adaptability of the generated content, and reducing the risk of erroneous generation due to knowledge gaps or mis-injection.

[0127] In the above embodiments of this application, the method further includes: storing the original project code and functional configuration files in the target storage area, wherein the target storage area and the isolated container environment interact through a preset communication link.

[0128] The aforementioned target storage area is an independent directory space in the isolated container environment dedicated to the persistent storage of the original project code and functional configuration files. It is bound to the container runtime environment, has file read and write permissions, and can be accessed by internal processes, but cannot be directly exposed to external systems. Its design purpose is to provide a stable and accessible input data source for code generation tasks, avoiding data loss or inconsistency caused by temporary caching or memory loading.

[0129] The aforementioned preset communication link is a standardized data channel configured by the system before the isolated container environment starts, used to transfer data between external storage services and the target storage area inside the container. It takes the form of a mount point, a shared volume, or a controlled file copy interface, and only allows pre-authorized file transfer actions. Remote access, command execution, or network services are not allowed, ensuring the security and controllability of data transmission.

[0130] The default communication link is a path mapping relationship built on a link mechanism to establish a data access channel between the isolated container environment and the external persistent storage area of ​​the server. The default communication link is essentially a file system node in the target storage area within the container. This node does not store actual data, but points to a pre-defined source file path in the external shared storage area. The creation of this link is statically configured by the system before the container starts. Its target path is located in a controlled shared storage space outside the container, and neither the source nor the target of the link contains temporary directories, user home directories, or network mount points. This link supports read-only or restricted write permissions, prohibits cross-domain jumps, relative path resolution, or symbolic link chaining, and ensures that the data transmission path is fixed, the source is clear, and the access is controllable. This enables stable access to input files in the isolated environment without copying data, reducing storage overhead and ensuring data consistency.

[0131] In one optional embodiment, the acquired original project code and functional configuration files are first synchronized from an external source to the target storage area. This process is completed through a preset communication link and does not rely on active fetching or network requests within the container. After synchronization, the system verifies the integrity and consistency of the files in the target storage area to ensure that the original project code and functional configuration files have been completely written and have not been tampered with. Subsequently, the isolated container environment is started, and the code generation component inside it can only read the above data through the target storage area and cannot bypass this path to obtain information from other sources.

[0132] In this embodiment, the target storage area serves as the sole access point for the original project code and functional configuration files, enabling centralized control of data input; the preset communication link serves as the sole legitimate transmission channel, ensuring traceability of data sources and auditability of paths, preventing malicious injection or unauthorized access; the isolated container environment relies on this mechanism to obtain input, rather than directly connecting to external systems.

[0133] For example, after a user initiates a development request, the original project code can be pulled from a remote repository, and the matching functional configuration file can be loaded based on semantic analysis. The original project code and functional configuration file are written to the pre-allocated target storage area in the isolation container through a preset communication link. After the isolation container environment is started, the agent component reads the file from the target storage area, which can be set to be inaccessible from the network, host path, or local cache. Even if the container is restarted, the file in the target storage area can still be remounted to ensure context continuity.

[0134] This application embodiment constructs a data input control mechanism for an isolated container environment by uniformly storing the original project code and functional configuration files in the target storage area and achieving secure injection through a preset communication link. This ensures that the input source of the code generation task is reliable, the path is controllable, and the state is stable, thereby improving the security of the execution environment and the consistency of task reproduction.

[0135] In the above embodiments of this application, the method further includes: uploading the target project code to the project repository and deleting the isolated container environment.

[0136] In one optional embodiment, the integrity and consistency of the target project code in the isolated container environment are first verified to confirm that the target project code has passed file conflict detection, merging strategy application, and version difference verification, forming a deliverable final state. Subsequently, the changes to the target project code can be pushed to the specified target branch in the project repository in an incremental manner through a version control protocol. This operation can transfer the differences without overwriting the entire repository and can be executed on authorized branches, or the entire file can be transferred. After the push operation is confirmed to be successful, the destruction process of the isolated container environment can be triggered to release the computing resources, network ports, and storage space occupied by it, including clearing all temporary files, memory caches, and runtime configurations to ensure that there is no residual state in the container.

[0137] In this embodiment, the upload of the target project code constitutes the delivery outlet of the code generation task. The structured submission is completed through the version control protocol to ensure that changes are traceable and rollbackable. The deletion of the isolated container environment is the final action of the task lifecycle. Its purpose is to completely clear the execution environment and prevent pollution, confusion or security risks caused by container reuse, state residue or uncleaned intermediate files. It ensures that all results are only reflected through the project repository and achieves strict separation between the execution process and the output results.

[0138] For example, the agent completes the development of the password strength verification function in the user management module, generating the newly added password verification function, the modified login interface call logic, and the corresponding unit test files; it performs a conflict comparison with the user's manual modifications in the shadow workspace, and applies a merging strategy to confirm the final changes; it pushes the above three changes as a single commit to the designated branch of the project repository through the protocol; after the push is successful, it can terminate and destroy the isolated container environment, clearing its internal temporary files, dependency caches, log outputs, and runtime configurations, while retaining the new commit records in the project repository as the carrier of the results.

[0139] This application embodiment achieves standardized delivery of generated results and thorough cleanup of the execution environment by pushing the target project code to the project repository and deleting the isolated container environment. This ensures that all code changes are retained only through an authoritative version control system, thereby improving the traceability of results, the independence of the environment, and the security of the system.

[0140] In this application, the sandbox environment provides an isolated container environment, including a file system, process space, and network environment; multi-agent orchestration includes planner agents and encoder agents, which work collaboratively through a state machine orchestration system; the skill library management stores and manages skill files such as project specifications and component documents, supporting dynamic loading; the rule engine manages global rules, platform rules, and user-defined rules in a hierarchical manner; message flow communication enables asynchronous communication between the sandbox and the server based on an asynchronous communication channel; the workspace management provides an independent shadow working directory, offering conflict detection and merging functions; persistent storage management manages the sandbox's persistent space, supporting soft links and object storage; key management manages sensitive credentials based on a key center service, supporting dynamic rotation; the preview service automatically detects the development server port and establishes a secure tunnel; and the terminal service provides a standardized command execution interface, supporting background tasks and real-time output.

[0141] Figure 3 This is a system architecture diagram according to an embodiment of this application, such as... Figure 3 As shown, it includes underlying dependencies, a model layer, an application layer, a client-side layer, and a project-side layer. The underlying dependencies include core components, storage, third-party services, and others. The core includes an AI development platform (AI Studio), a sandbox, etc. Storage includes various databases (MySQL, PostgreSQL, Redis). Third-party services include basic capabilities such as object storage (SLS, OSS), a key center (KeyCenter), and unified login (BucLogin). Other services provide replay functionality (eXtended Replay, or XReplay for short). The underlying dependencies primarily provide computational and storage support for the upper-layer functions.

[0142] The model layer consists of three parts: Deep Agents, Memory Context, and Tools. The Deep Agents include modules such as Coder, Planner, Coordinator, and Sub Agents. The Memory Context is responsible for managing Rules, Message History, Knowledge Base, Prompt Template, and Working Memory. The Tools provide capabilities such as handoff, file operations, global search, fast apply, terminal, and human-in-the-loop interaction.

[0143] At the application layer, modules such as Function as a Service (Faas) services, server-side applications, and sandboxes are provided. Faas includes page templates, file management, application management, and session management; server-side applications include streaming processing, protocol conversion, message subscription, and baseline management; and the sandbox includes runtime environment, file system, and tool invocation.

[0144] On the client side, three core functionalities are provided: a code site, a web-based integrated development environment (WIDE), and a data dashboard, enabling full-process support from application management and online coding to data analysis. The code site includes application management, file management, session management, page preview, and creative inspiration; the WIDE includes online coding, a terminal, and deployment submission; the data dashboard includes code volume statistics, iteration analysis, requirement coverage, code coverage, trend analysis, and cost statistics; and the top-level project side displays the specific project scenarios supported by this architecture.

[0145] During the initialization of the session and sandbox environment, users can submit development requirements, including project repository addresses and branch information. The server creates a session identifier, starts the sandbox container, and allocates computing resources. The sandbox container clones the project code to the working directory and initializes an independent shadow workspace. Dependency directories are linked to the shared storage area via symbolic links to save persistent storage space. Temporary credentials are retrieved from the key center and loaded into memory, without being stored on disk. An asynchronous message queue channel and a WebSocket connection are established between the sandbox and the server.

[0146] During the loading of the skill library and rules, semantic analysis can be performed based on user requests to extract key technical terms and functional descriptions. Semantic retrieval is then used to match structured files such as project specifications and component documents within the skill library. Global rules, platform rules, and user-defined rules are merged according to hierarchical priority. Deduplication and compression middleware is used to improve the context content and reduce token consumption. The improved skill file content is then injected into the agent's prompt context.

[0147] During the collaborative task execution by multiple agents, the planner agent receives the requirements, decomposes the task into a sequence of subtasks, and delegates these subtasks to the encoder agent through a state machine orchestration system. The encoder agent reads the project file, calls tools to generate code modifications, and writes the changes to the shadow workspace. Task status, code changes, and execution logs are pushed in real time via a message queue. The model output is converted to the Agent Client Protocol (ACP) standard protocol format via the Agent Client Protocol Client (ACP Client), and the streaming content is pushed to a remote data service stream (Redis Stream). The server subscribes to the Redis Stream, reads it, and routes it to the corresponding WebSocket connection according to the session identifier. The user receives and displays the generation progress in real time.

[0148] During workspace management and conflict resolution, a file monitoring mechanism captures local manual modifications. These modifications are then communicated to the server via WebSocket and forwarded to the sandbox. User modifications are synchronized to the shadow workspace. When an agent attempts to modify a file that has already been changed by a user, conflict detection is triggered. Merge strategy options are provided, supporting retaining agent modifications, retaining user modifications, or manual merging. Users can pull the latest code or roll back to a previous version at any time.

[0149] During persistence and session recovery, project source code, configuration files, and critical logs are periodically persisted to the limited space. Dependency directories point to the shared storage area via symbolic links, without consuming persistence quotas. Large files exceeding the limit are uploaded to object storage services for archiving. Upon session restart, persistent files are loaded, symbolic links and shadow workspace states are automatically restored, and unfinished tasks continue to execute.

[0150] Figure 4 This is a schematic diagram of module interaction according to an embodiment of this application, such as... Figure 4 As shown, it includes a web client (Web), a server side (Server), an isolated execution sandbox (Sandbox), an intelligent agent (Agent), and a remote dictionary server (Redis). Figure 4This demonstrates the message passing and data interaction process across five modules: web client, server, sandbox, agent, and remote data service. The top-level web client is responsible for user interaction. It controls the server through file synchronization and commands, and ordinary messages, while also receiving streaming messages from the server via WebSocket. The server, acting as an intermediate layer, invokes the sandbox to execute specific operations and stores data requiring caching or fast read / write in the remote data service. The sandbox is the execution environment, and it also exchanges messages with the agent. The sandbox can send messages to the agent, which then returns the execution results to the sandbox via streaming output and protocol translation, ultimately feeding back to the user through a final feedback chain.

[0151] The multi-agent collaborative orchestration mechanism in this application uses a state machine orchestration system to define the state transitions between agents. The nodes include planning nodes, encoding nodes, tool invocation nodes, and manual intervention nodes. The state transition conditions between agents are defined, such as starting encoding when planning is completed and reverting to planning when encoding fails. Each node maintains an independent state, supports concurrent execution and exception recovery. The planner delegates subtasks to the encoder through a message queue, and the encoder returns the result after completing the task.

[0152] The agent application switching adopts the Agent Client Protocol (ACP protocol) to support dynamic switching between different agents and ensure protocol layer consistency.

[0153] In the dynamic loading mechanism of the skill library, the skill files adopt the Markdown language format and contain metadata annotations, such as name, description, keywords, allowed-tools, etc. The dynamic loading process first captures the semantic meaning of the user's request through semantic analysis, then detects and removes duplicate content through deduplication middleware to avoid the repeated injection of the same knowledge, then improves the context length through compression middleware, deletes irrelevant details and folds example code, and finally injects the improved skill file into the agent's prompt context.

[0154] The message flow protocol is designed to use an asynchronous communication channel to achieve efficient communication between the sandbox and the server. Message types include task status messages, which can include PENDING, RUNNING, COMPLETED, and FAILED; code change messages, which include file path, change type, and change content, with change types including CREATE, UPDATE, DELETE; execution log messages, which include command output, error messages, and warnings; and tool call messages, which include tool name, parameters, and return value. Redis Stream is used to implement message multicast and prevent message loss. The reliability guarantee mechanism includes idempotency verification based on message ID to prevent duplicate consumption, automatic retries for failed messages with a preset number of attempts, message ordering within the same session by timestamp to ensure sequence, and consumers being routed to the corresponding WebSocket connection based on session identifier.

[0155] During the implementation of the workspace, an independent source workspace can be created in the sandbox. This workspace clones the original code from the remote repository, allowing agents to modify it while isolating it from the user's local and remote environments. It only takes effect when the user manually triggers a commit. The conflict detection algorithm captures the user's local modifications through the file system monitoring mechanism. Before synchronizing to the shadow workspace, it checks whether the target file has been modified by the agent. If a conflict exists, it calculates the differences between the source version, agent version, and user version, and provides three strategies: retain agent modifications, retain user modifications, or manual merging.

[0156] In the symbolic link persistence strategy, project data can be stored in categories. Project source code, configuration files, and critical logs are stored in the persistent space, while dependency directories, build artifacts, and cached files point to the shared storage area via symbolic links. Large files exceeding the persistence limit are uploaded to the object storage service for archiving. During the recovery process, when the sandbox restarts, the source code and configuration files are first loaded from the persistent space, and then symbolic links pointing to the shared storage area are automatically rebuilt according to the configuration. If the shared storage area is missing dependencies, the installation command is automatically executed, and the archived large files are downloaded from the object storage.

[0157] In the key security management process, sensitive configurations are centrally stored in the key center before the application starts. When the application starts, it requests decryption from the key center to obtain plaintext credentials. The plaintext credentials are only loaded into memory and not written to the file system. The sandbox environment obtains temporary credentials through a secure channel and sets an expiration time. After expiration, the credentials automatically become invalid. At the same time, the code in the sandbox is compressed and obfuscated to enhance security protection.

[0158] Figure 5 This is a flowchart of a workspace distributed version control system according to an embodiment of this application, such as... Figure 5As shown, at the start of a new session, you can obtain the code repository and branch information through the `git clone` operation. In an existing session, you can perform sandbox persistence recovery and enter the model coding (AI coding) stage for development. After development is complete, you can execute the code repository commit operation (`git commit`) to synchronize the code changes to the file staging area (`File`). The code is pushed to the web client through the file synchronization operation, which supports manual modification in the web client and re-execution of the code repository commit. The committed code will generate a unique commit ID. If you need to revert, you can execute the undo operation. Finally, you can merge the commits of the current branch into the target branch through `git rebase`. After completion, the baseline of the update session is determined to be the latest commit ID returned by the push.

[0159] Figure 6 This is a flowchart of a conflict resolution method according to an embodiment of this application, such as... Figure 6 As shown, in the event of a conflict, the system can select the latest code from the remote repository on the same branch and the latest code in the current session based on the session baseline code. After processing, the code can be pushed. When a conflict occurs, four versions of code can be compared: the original version at the start of the session, the latest version from the remote repository, the version manually modified by the user, and the version generated by the agent. By analyzing the differences between these four versions, the conflicting parts can be automatically identified. Based on the specifications in the project skill library and the rules set by the user, three options are provided: retain the user's modifications, retain the agent's modifications, or manually merge. After user confirmation, the merge result can be saved in the sandbox's shadow workspace without affecting the original code. Simultaneously, the status is synchronized in real time via message streams. Finally, the user can safely push the code to the remote repository. The entire process is isolated, controllable, and traceable.

[0160] In one alternative embodiment, distributed deployment of agents based on a microservice architecture enables independent deployment and elastic scaling of agent modules, supports parallel processing of multiple tasks in high-concurrency scenarios, and improves overall throughput and task scheduling flexibility. Agent execution based on serverless functions can automatically trigger resource allocation upon request, achieving zero-maintenance on-demand computing, reducing idle resource overhead, and improving resource utilization efficiency. Agent integration based on local integrated development environment (IDE) plugins can seamlessly connect with the developer's workflow, achieving low-latency response and real-time code interaction, improving the developer's operational fluency and contextual coherence.

[0161] A fully isolated virtual machine-based environment provides a runtime space completely separate from the host machine, supporting customized deployments of arbitrary operations and dependent environments, and ensuring the integrity of complex execution environments. A lightweight sandbox based on WebAssembly enables server-side code execution on the client side, ensuring user data never leaves the local device, thus enhancing privacy protection and deployment ease.

[0162] This application presents a multi-agent collaborative orchestration method based on a sandbox environment. It deploys multiple specialized agents, including a planner and an encoder, within an isolated sandbox container. A graph-structured state machine orchestration framework facilitates state transitions and task delegation between agents. An asynchronous communication mechanism based on message queues decouples interactions between agents, and persistent storage ensures the sandbox environment can restore historical states and continue sessions after a restart. This method automates the processing of long-duration, complex development tasks, improves task execution isolation and security, supports parallel collaboration among multiple agents to enhance development efficiency, and reduces the impact of single agent failures on the overall task flow.

[0163] This application presents a context-based dynamic enhancement method using a skill library and rule engine. This method structures professional knowledge such as project specifications, component documentation, and interface definitions into standardized skill files. Based on the semantic content of the user's natural language request, it dynamically retrieves and injects relevant skills into the agent's prompt context. A hierarchical management mechanism integrates global rules, platform rules, and user-defined rules, and deduplication and compression middleware is used to improve context length. This method achieves accurate injection of domain knowledge, reduces interference from irrelevant information, improves the standardization and consistency of code generation, reduces prompt token consumption for large model calls, improves operational costs, and supports rapid adaptation to the specific coding standards of different projects.

[0164] This application utilizes a real-time state synchronization and streaming transmission method based on message streams. It employs a streaming message queue as the communication channel between the sandbox and the server. An agent within the sandbox acts as the producer, pushing real-time information such as task status, code changes, and execution logs. The server acts as the consumer, routing messages to the corresponding WebSocket connection based on session identifiers through a blocking listening mechanism. Simultaneously, message idempotency verification and automatic retry mechanisms ensure transmission reliability. This technology achieves a low-latency, real-time interactive experience between the user client and the backend sandbox environment, effectively reducing the impact of network latency on user experience, supporting message isolation under multi-session concurrency, and improving scalability and fault tolerance.

[0165] The version management method of shadow workspace and incremental synchronization in this application creates a shadow workspace independent of the source code repository in a sandbox environment. All code modifications made by agents only affect this area and do not affect the original project. A monitoring mechanism captures user modifications locally and synchronizes them to the shadow workspace. When agents and users have conflicting modifications to the same file, the system can automatically detect the differences and provide a three-way comparison and merging strategy (preserving agent modifications, preserving user modifications, or manual merging). Users can pull the latest version or roll back their history at any time. This technology effectively isolates interference between AI-generated code and manual modifications, supports flexible user intervention and correction, reduces the risk of version conflicts, improves the collaborative development experience, and ensures that all code changes are traceable and rollbackable.

[0166] The lightweight persistent storage method based on dependency symbolic links in this application allows large dependency directories (such as node_modules) to point to a shared storage area via file symbolic links, writing only core content such as project source code, configuration files, and critical logs to the limited sandbox persistent space. When the sandbox restarts, the symbolic links are automatically rebuilt and the persistent files are loaded. If dependencies are missing in the shared storage, the installation process is automatically triggered. Large files exceeding the persistent storage capacity are automatically archived to object storage services. This technology successfully overcomes the traditional 512MB storage limit of sandboxes, supports large-scale project development, shortens sandbox initialization and session recovery time, reduces storage costs and resource consumption, and ensures dependency version consistency, avoiding duplicate installations.

[0167] The sensitive information security storage method based on an encrypted key center in this application can store sensitive configurations (such as keys and database passwords) in an independent key center before application startup; when the service starts, it requests decryption from the key center through a secure channel, loading only plaintext credentials in memory and strictly prohibiting them from being written to disk; access permissions are obtained through temporary tokens in the sandbox environment, and the tokens have an expiration date and expire automatically; dynamic credential rotation and least privilege policy configuration are supported. This technology effectively prevents sensitive information from being leaked within the sandbox container, significantly reduces the risk of credentials being maliciously used or laterally disseminated, and constructs an end-to-end secure closed loop for sensitive data.

[0168] This application addresses the limitations of traditional AI-assisted programming tools in handling long-duration, complex development tasks. It enables multi-agent collaborative orchestration within an isolated sandbox. Through multi-agent collaboration and task delegation, and leveraging a file system, complex tasks are automated through sub-agent orchestration, supporting long-term continuous execution. Dynamic skill library loading allows project specifications and component documentation to be structured into skill files, dynamically loaded based on semantics, and generated code automatically conforming to project specifications. Workspace management allows the creation of independent workspaces to isolate agents and user modifications, providing conflict detection and merging strategies to resolve code coverage issues. Cloud execution enables real-time synchronization between the sandbox and server, running in a remote sandbox, using asynchronous communication channels for a streaming, low-latency user experience.

[0169] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0170] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, they can also be implemented by hardware. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods of the various embodiments of this application.

[0171] According to an embodiment of this application, a code generation method is provided. Figure 7 This is a flowchart of a code generation method according to an embodiment of this application, such as... Figure 7 As shown, the method includes:

[0172] Step S702: In response to the input command applied to the operation interface, display the functional development requirements of the target project on the operation interface.

[0173] Step S704: In response to the processing instructions applied to the operation interface, display the target project code on the operation interface.

[0174] The target project code is obtained by modifying the original project code corresponding to the functional development requirements using the second model in the code change area, based on the functional configuration file and at least one code generation task. The at least one code generation task is generated in the isolated container environment using the first model based on the functional development requirements. The code change area is created in the isolated container environment based on the original project code. The isolated container environment is started according to the functional development requirements.

[0175] Through the above steps, in response to input commands applied to the operation interface, the functional development requirements of the target project are displayed on the operation interface; in response to processing commands applied to the operation interface, the target project code is displayed on the operation interface. The target project code is obtained by modifying the original project code corresponding to the functional development requirements using the second model in the code change area, based on the functional configuration file and at least one code generation task. The at least one code generation task is generated in an isolated container environment using the first model based on the functional development requirements. The code change area is created in the isolated container environment based on the original project code, and the isolated container environment is started according to the functional development requirements. Based on the project specifications and component constraints in the functional configuration file, the first model decomposes the functional development requirements into at least one code generation task. The second model executes the code changes item by item in the code change area of ​​the isolated container environment. Due to the independent file system and process space of the isolated container environment, it can be ensured that code modifications only affect the code change area and do not interfere with the original environment of the server. At the same time, it ensures the continuity of task execution and configuration consistency, thereby improving the automation accuracy and execution efficiency of code generation, and thus solving the technical problem of low code generation efficiency in related technologies.

[0176] According to an embodiment of this application, a code generation method is provided. Figure 8 This is a flowchart of a code generation method according to an embodiment of this application, such as... Figure 8 As shown, the method includes:

[0177] Step S802: Obtain the functional development requirements of the target project by calling the first interface.

[0178] The first interface includes a first parameter, and the value of the first parameter includes the functional development requirements.

[0179] The aforementioned first interface can be an interface for data interaction between the server and the client. The client can pass the functional development requirements into the interface function as the first parameter of the interface function, thereby achieving the purpose of uploading the functional development requirements to the cloud server.

[0180] Step S804: Obtain the original project code and function configuration file corresponding to the function development requirements, and start the isolated container environment.

[0181] Among them, the isolated container environment is used to refer to the container environment isolated from the local environment of the server.

[0182] Step S806: Create a code change zone corresponding to the original project code in the isolated container environment.

[0183] Step S808: In the isolated container environment, utilize the first model generation function to develop at least one code generation task corresponding to the requirements.

[0184] Step S810: In the code change area, based on the function configuration file and at least one code generation task, the original project code is modified using the second model to obtain the target project code.

[0185] Step S812: Output the target project code by calling the second interface.

[0186] The second interface includes a second parameter, the value of which includes the target project code.

[0187] The second interface in the above steps can be an interface for data exchange between the cloud server and the client. The cloud server can pass the target project code into the interface function as the second parameter of the interface function, so as to achieve the purpose of distributing the target project code to the client.

[0188] Through the above steps, the functional development requirements of the target project are obtained by calling the first interface, wherein the first interface includes a first parameter, and the parameter value of the first parameter includes the functional development requirements; the original project code and functional configuration file corresponding to the functional development requirements are obtained, and an isolated container environment is started, wherein the isolated container environment is used to represent a container environment isolated from the local environment of the server; a code change area corresponding to the original project code is created in the isolated container environment; in the isolated container environment, at least one code generation task corresponding to the functional development requirements is generated using the first model; in the code change area, according to the functional configuration file and at least one code generation task, the original project code is modified using the second model to obtain the target project code; the target project code is output by calling the second interface, wherein the second interface includes a second parameter, and the parameter value of the second parameter includes the target project code. Based on the project specifications and component constraints in the functional configuration file, the first model decomposes the functional development requirements into at least one code generation task. The second model executes code changes item by item in the code change area of ​​the isolated container environment. According to the independent file system and process space of the isolated container environment, it can be ensured that the code modification only affects the code change area and does not interfere with the original environment of the server. At the same time, it ensures the continuity of task execution and configuration consistency, thereby improving the automation accuracy and execution efficiency of code generation, and thus solving the technical problem of low code generation efficiency in related technologies.

[0189] According to an embodiment of this application, a code generation apparatus for implementing the above-described code generation method is also provided. Figure 9 This is a schematic diagram of a code generation apparatus according to an embodiment of this application, such as... Figure 9 As shown, the device 900 includes: an acquisition module 902, a creation module 904, a generation module 906, and a modification module 908.

[0190] The module includes: an acquisition module, which, in response to receiving the functional development requirements of the target project, acquires the original project code and functional configuration file corresponding to the functional development requirements, and starts an isolated container environment, where the isolated container environment represents a container environment isolated from the local environment of the server; a creation module, which creates a code change area corresponding to the original project code in the isolated container environment; a generation module, which generates at least one code generation task corresponding to the functional development requirements in the isolated container environment using a first model; and a modification module, which modifies the original project code in the code change area according to the functional configuration file and at least one code generation task using a second model to obtain the target project code.

[0191] It should be noted that the acquisition module 902, creation module 904, generation module 906, and modification module 908 correspond to steps S202 to S208 in the above embodiments. The four modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware or software components stored in memory and processed by one or more processors. The above modules can also run as part of the device in the server 10 provided in the above embodiments.

[0192] In the above embodiments of this application, the modification module is used to modify the original project code in the code modification area according to the function configuration file and at least one code generation task, using a second model to obtain modified project code; in response to receiving a modification event of the original project code, the modified project code contained in the modification event is synchronized to the code modification area; and the target project code is determined based on the modified project code and the modified project code in the code modification area.

[0193] In the above embodiments of this application, the change module is used to compare the modified project code and the changed project code in the code change area, obtain the comparison result, and output the comparison result, wherein the comparison result is used to represent the difference between the modified project code and the changed project code; in response to receiving the feedback information of the comparison result, the target project code is determined based on the feedback information.

[0194] In the above embodiments of this application, the device is further configured to determine the task type of at least one code generation task; configure the second model into the execution node in the state machine based on the task type; and use the first model to send at least one code generation task to the second model according to the triggering condition of the execution node.

[0195] In the above embodiments of this application, at least one code generation task is multiple code generation tasks, the second model is multiple sub-models, and the device is further configured to configure multiple sub-models to multiple sub-execution nodes in the state machine based on task type, and to distribute multiple code generation tasks to the second model using the first model according to the triggering conditions of multiple sub-execution nodes.

[0196] In the above embodiments of this application, the acquisition module is used to determine the project code information and project request information in the functional development requirements; based on the project code information, it retrieves the original project code from the project repository corresponding to the target project; and based on the project request information, it determines the functional configuration file.

[0197] In the above embodiments of this application, the acquisition module is used to determine the project repository address and code branch name of the target project based on the project code information; and to retrieve the original project code from the project repository based on the project repository address and code branch name.

[0198] In the above embodiments of this application, the acquisition module is used to perform semantic analysis on the project request information to obtain target keywords and project function descriptions, wherein the target keywords are keywords associated with the target project; based on the target keywords and project function descriptions, the function configuration file is determined.

[0199] In the above embodiments of this application, the device is also used to store the original project code and functional configuration files to the target storage area, wherein the target storage area and the isolated container environment interact through a preset communication link.

[0200] In the above embodiments of this application, the device is also used to upload the target project code to the project repository and delete the isolated container environment.

[0201] According to an embodiment of this application, a code generation apparatus for implementing the above-described code generation method is also provided. Figure 10 This is a schematic diagram of a code generation apparatus according to an embodiment of this application, such as... Figure 10 As shown, the device 1000 includes: a first display module 1002 and a second display module 1004.

[0202] The first display module responds to input commands applied to the operation interface and displays the functional development requirements of the target project on the operation interface. The second display module responds to processing commands applied to the operation interface and displays the target project code on the operation interface. The target project code is obtained by modifying the original project code corresponding to the functional development requirements using a second model in the code modification area, based on the functional configuration file and at least one code generation task. The at least one code generation task is generated in an isolated container environment using a first model based on the functional development requirements. The code modification area is created in the isolated container environment based on the original project code, and the isolated container environment is started according to the functional development requirements.

[0203] It should be noted that the first display module 1002 and the second display module 1004 mentioned above correspond to steps S702 to S704 in the above embodiments. The two modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should be noted that the above modules or units can be hardware components or software components stored in memory and processed by one or more processors. The above modules can also be part of the device and run in the server 10 provided in the above embodiments.

[0204] According to an embodiment of this application, a code generation apparatus for implementing the above-described code generation method is also provided. Figure 11 This is a schematic diagram of a code generation apparatus according to an embodiment of this application, such as... Figure 11 As shown, the device 1100 includes: a calling module 1102, an acquisition module 1104, a creation module 1106, a generation module 1108, a modification module 1110, and an output module 1112.

[0205] The system comprises the following modules: a calling module for obtaining the functional development requirements of the target project by calling a first interface, wherein the first interface includes a first parameter whose value includes the functional development requirements; an acquisition module for obtaining the original project code and functional configuration file corresponding to the functional development requirements, and starting an isolated container environment, wherein the isolated container environment represents a container environment isolated from the local environment of the server; a creation module for creating a code modification area corresponding to the original project code in the isolated container environment; a generation module for generating at least one code generation task corresponding to the functional development requirements in the isolated container environment using a first model; a modification module for modifying the original project code in the code modification area according to the functional configuration file and at least one code generation task using a second model to obtain the target project code; and an output module for outputting the target project code by calling a second interface, wherein the second interface includes a second parameter whose value includes the target project code.

[0206] It should be noted that the aforementioned calling module 1102, obtaining module 1104, creating module 1106, generating module 1108, modifying module 1110, and output module 1112 correspond to steps S802 to S812 in the above embodiments. The six modules and their corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the above embodiments. It should also be noted that the aforementioned modules or units can be hardware or software components stored in memory and processed by one or more processors. These modules can also run as part of a device in the server 10 provided in the above embodiments.

[0207] It should be noted that the preferred embodiments involved in the above embodiments of this application are the same as the solutions, application scenarios and implementation processes provided in the above embodiments, but are not limited to the solutions provided in the above embodiments.

[0208] Embodiments of this application may provide a computing device. Figure 12 This is a structural block diagram of a computing device according to an embodiment of this application. Figure 12 As shown, the computing device 100 may include one or more (only one is shown in the figure) processors 102, memory 104, memory controller, and peripheral interfaces.

[0209] The aforementioned computing device can be understood as an integrated smart terminal, including but not limited to servers, desktop computers, PCs (Personal Computers), all-in-one model machines, etc., and the computing device may have the model in the above embodiments of this application pre-installed.

[0210] Specifically, this computing device can pre-install various types of models, including but not limited to models in natural language processing, visual processing, speech processing, code processing, and multimodal task processing, thus providing diverse model selection. In different product forms, this computing device can support one or more model usage methods, including but not limited to model training, model invocation, model fine-tuning, model deployment, model inference, and application. In some product forms, this computing device also supports model management, including but not limited to multi-type model management (supporting the management of discriminative, generative, and other model types), model version control (supporting the control of different model versions), and model evaluation (evaluating model performance and effectiveness based on model evaluation tools). In other product forms, this computing device can also create applications based on models, providing API calling capabilities, allowing models to be called into created applications through API interfaces, and providing application management tools to achieve application control.

[0211] Furthermore, the computing device can also include data management (supporting the creation and management of model tuning datasets), a training center (providing abundant training resources to help users learn and master AI technology), and basic control capabilities (providing enterprise-level basic control capabilities to ensure the security and efficient operation of the system). Through the above functions, it provides a comprehensive and integrated device for AI development, training, deployment, and application.

[0212] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the methods in the above embodiments. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to terminal A via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0213] The processor can invoke an executable program stored in memory via a transmission device to execute any of the methods described in the above embodiments.

[0214] Embodiments of this application may provide an electronic device. Figure 13 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 13 As shown, the electronic device may include: an input / output device 112; a memory 114; and a processor 116, wherein the processor 116 is connected to the input / output device 112 and the memory 114 via a bus 118.

[0215] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the methods in the above embodiments. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to terminal A via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0216] The processor can invoke an executable program stored in memory via a transmission device to execute any of the methods described in the above embodiments.

[0217] Those skilled in the art will understand that, Figure 13 The structure shown is for illustrative purposes only. The electronic device may also be a smartphone, tablet, PDA, mobile internet device (MID), PAD, or other terminal device. This diagram does not limit the structure of the aforementioned electronic device. For example, the electronic device may include more or fewer components (such as network interfaces, display devices, etc.) than shown in the diagram, or may have a different configuration than shown in the diagram.

[0218] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0219] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium can be used to store program code executed by the method provided in the above embodiments.

[0220] Optionally, in this embodiment, the storage medium may be located in a computing device or an electronic device.

[0221] Optionally, in this embodiment, the computer-readable storage medium is configured to store an executable program, which, when the executable program is running, controls the device where the computer-readable storage medium is located to execute the method described in any of the above embodiments.

[0222] Embodiments of this application also provide a computer program product. Optionally, in this embodiment, the computer program product may include a computer program that, when executed by a processor, implements the methods provided in the embodiments described above.

[0223] Embodiments of this application also provide a computer program product. Optionally, the computer program product may include a non-volatile computer-readable storage medium, which can be used to store a computer program that, when executed by a processor, implements the method provided in the above embodiments.

[0224] Embodiments of this application also provide a computer program. Optionally, in this embodiment, when the computer program is executed by a processor, it implements the method provided in the above embodiments.

[0225] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0226] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0227] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0228] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0229] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0230] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A code generation method, characterized in that, Applied to the server side, including: In response to receiving the feature development requirements of the target project, the system obtains the original project code and feature configuration file corresponding to the feature development requirements and starts the isolated container environment. Create a code change zone corresponding to the original project code within the isolated container environment; In the isolated container environment, at least one code generation task corresponding to the functional development requirements is generated using the first model; In the code modification area, based on the functional configuration file and the at least one code generation task, the original project code is modified using the second model to obtain the target project code.

2. The method according to claim 1, characterized in that, In the code modification area, based on the functional configuration file and the at least one code generation task, the original project code is modified using a second model to obtain the target project code, including: In the code change area, based on the function configuration file and the at least one code generation task, the original project code is modified using the second model to obtain the changed project code; In response to receiving a modification event of the original project code, the modified project code contained in the modification event is synchronized to the code change area; The target project code is determined based on the changed project code and the modified project code in the code change area.

3. The method according to claim 2, characterized in that, Based on the changed item code and the modified item code in the code change area, the target item code is determined, including: The modified project code and the changed project code are compared in the code change area to obtain a comparison result, and the comparison result is output. The comparison result is used to indicate the difference between the modified project code and the changed project code. In response to receiving feedback information about the comparison results, the target project code is determined based on the feedback information.

4. The method according to claim 1, characterized in that, The method further includes: Determine the task type of the at least one code generation task; Based on the task type, the second model is configured into the execution node in the state machine, and the first model is used to send the at least one code generation task to the second model according to the triggering condition of the execution node.

5. The method according to claim 4, characterized in that, The at least one code generation task comprises multiple code generation tasks, and the second model comprises multiple sub-models. Based on the task type, the second model is configured into execution nodes in the state machine, and the first model, according to the triggering conditions of the execution node, sends the at least one code generation task to the second model, including: Based on the task type, the multiple sub-models are configured to multiple sub-execution nodes in the state machine. The first model then distributes the multiple code generation tasks to the second model according to the triggering conditions of the multiple sub-execution nodes.

6. The method according to claim 1, characterized in that, Obtain the original project code and feature configuration files corresponding to the aforementioned feature development requirements, including: Determine the project code information and project request information in the aforementioned functional development requirements; Based on the project code information, retrieve the original project code from the project repository corresponding to the target project; Based on the project request information, the functional configuration file is determined.

7. The method according to claim 6, characterized in that, Based on the project code information, the original project code is retrieved from the project repository corresponding to the target project, including: Based on the project code information, determine the project repository address and code branch name of the target project; Based on the project repository address and the code branch name, retrieve the original project code from the project repository.

8. The method according to claim 6, characterized in that, Based on the project request information, the functional configuration file is determined, including: Semantic analysis is performed on the project request information to obtain target keywords and project function descriptions, wherein the target keywords are keywords associated with the target project; Based on the target keywords and the project function description, the function configuration file is determined.

9. The method according to any one of claims 1 to 8, characterized in that, The method further includes: The original project code and the functional configuration file are stored in the target storage area, wherein the target storage area and the isolated container environment interact through a preset communication link.

10. The method according to any one of claims 1 to 8, characterized in that, The method further includes: Upload the target project code to the project repository and delete the isolated container environment.

11. A code generation method, characterized in that, include: In response to input commands applied to the user interface, the functional development requirements of the target project are displayed on the user interface. In response to a processing instruction applied to the operation interface, the target project code is displayed on the operation interface. The target project code is obtained by modifying the original project code corresponding to the functional development requirements using a second model in the code modification area, based on the functional configuration file and at least one code generation task. The at least one code generation task is generated in an isolated container environment using a first model based on the functional development requirements. The code modification area is created in the isolated container environment based on the original project code, and the isolated container environment is started according to the functional development requirements.

12. A code generation method, characterized in that, include: The functional development requirements of the target project are obtained by calling the first interface, wherein the first interface includes a first parameter, and the parameter value of the first parameter includes the functional development requirements. Obtain the original project code and function configuration file corresponding to the function development requirements, and start the isolated container environment, wherein the isolated container environment is used to represent the container environment isolated from the local environment of the server. Create a code change zone corresponding to the original project code within the isolated container environment; In the isolated container environment, at least one code generation task corresponding to the functional development requirements is generated using the first model; In the code modification area, based on the functional configuration file and the at least one code generation task, the original project code is modified using the second model to obtain the target project code; The target project code is output by calling a second interface, wherein the second interface includes a second parameter, and the value of the second parameter includes the target project code.

13. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor, connected to a memory via a bus, is used to run the program, wherein the program, when running, executes the method described in any one of claims 1 to 12.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes a stored executable program, wherein, when the executable program is executed, it controls the device on which the computer-readable storage medium is located to perform the method according to any one of claims 1 to 12.

15. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 12.

Images