Program updating method and device, computer device, storage medium and program product

Abstract

The application relates to a program updating method and device, computer equipment, a storage medium and a program product. The method comprises the following steps: acquiring requirement description information of a program to be updated; determining a target blueprint file from a plurality of initial blueprint files corresponding to the program to be updated based on the requirement description information; determining an updated blueprint file based on the requirement description information and the target blueprint file; acquiring a target source file of a target module corresponding to the target blueprint file, and updating the target source file based on the updated blueprint file to obtain an updated source file corresponding to the requirement description information. The method can improve the accuracy of program updating.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a program update method, apparatus, computer equipment, storage medium, and computer program product. Background Technology

[0002] With the development of artificial intelligence technology, large language models are widely used to assist programming tasks, such as code generation, refactoring, and bug fixing. Based on natural language descriptions and existing programs, large language models automatically generate or modify program code, significantly improving program development efficiency.

[0003] In traditional technologies, large language models treat all source files of the entire program as context. The effective business logic in the program is overwhelmed by boilerplate code, exception handling branches, and syntactic noise. This causes the attention mechanism of the large language model to be occupied by irrelevant information, making it difficult for the large language model to accurately understand the global architecture and the real dependencies between modules from massive noise, resulting in low accuracy of program updates. Summary of the Invention

[0004] Therefore, it is necessary to provide a program update method, apparatus, computer equipment, computer-readable storage medium, and computer program product that can improve the accuracy of program updates, in order to address the above-mentioned technical problems.

[0005] Firstly, this application provides a method for updating a program. The method includes:

[0006] Obtain the requirement description information of the program to be updated;

[0007] Based on the requirement description information, the target blueprint file is determined from multiple initial blueprint files corresponding to the program to be updated;

[0008] Based on the requirement description information and the target blueprint file, the blueprint file to be updated is determined;

[0009] The target source file of the target module corresponding to the target blueprint file is obtained, and the target source file is updated based on the updated blueprint file to obtain the updated source file corresponding to the requirement description information. Secondly, this application also provides a program update apparatus. The apparatus includes:

[0010] The acquisition module is used to obtain the requirement description information of the program to be updated;

[0011] The determination module is used to determine the target blueprint file from multiple initial blueprint files corresponding to the program to be updated based on the requirement description information;

[0012] The blueprint file update module is used to determine the blueprint file to be updated based on the requirement description information and the target blueprint file;

[0013] The source file update module is used to obtain the target source file of the target module corresponding to the target blueprint file, update the target source file based on the update blueprint file, and obtain the update source file corresponding to the requirement description information.

[0014] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of any of the methods described in the first aspect.

[0015] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects.

[0016] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the first aspects.

[0017] The aforementioned program update method, apparatus, computer equipment, storage medium, and computer program product acquire the requirements description information of the program to be updated; based on the requirements description information, determine the target blueprint file from multiple initial blueprint files corresponding to the program to be updated; based on the requirements description information and the target blueprint file, determine the update blueprint file; acquire the target source file of the target module corresponding to the target blueprint file; update the target source file based on the update blueprint file to obtain the update source file corresponding to the requirements description information. In the above program update method, by introducing a blueprint file as an intermediate representation file, the program update process is transformed from a single-stage process of directly generating update source files based on requirement description information into a two-stage process of generating update blueprint files based on requirement description information and generating update source files based on update blueprint files. This allows the update logic corresponding to the requirement description information to be expressed in a structured form in the update blueprint file. Compared to directly updating the program to be updated based on requirement description information, this avoids interference from a large amount of execution logic code, exception handling branches, and syntax noise in the program to be updated on the core business logic. It enables the process of generating update blueprint files based on requirement description information to perform logical reasoning on the structured target blueprint file, thereby improving the accuracy of the update blueprint file. Then, the target source file is updated according to the update blueprint file to obtain the update source file corresponding to the requirement description information, which improves the accuracy of the update source file and thus improves the accuracy of the program update. Attached Figure Description

[0018] Figure 1 This is a diagram illustrating the application environment of a program update method in one embodiment;

[0019] Figure 2 This is a flowchart illustrating a program update method in one embodiment;

[0020] Figure 3 This is a schematic diagram of the structure of the initial blueprint file in one embodiment;

[0021] Figure 4 This is a schematic diagram illustrating the configuration of the first neural network model and the second neural network model in one embodiment;

[0022] Figure 5 This is a schematic diagram of the second mapping relationship in one embodiment;

[0023] Figure 6 This is a schematic diagram of the verification process for updating blueprint files in one embodiment;

[0024] Figure 7 This is a schematic diagram of the module dependency topology in one embodiment;

[0025] Figure 8 This is a schematic diagram illustrating the process of determining the initial blueprint file in one embodiment;

[0026] Figure 9 This is a schematic diagram of the reverse synchronization process in one embodiment;

[0027] Figure 10 This is a schematic diagram illustrating the data flow of program updates in one embodiment;

[0028] Figure 11 This is a timing diagram of a program update in one embodiment;

[0029] Figure 12 This is a structural block diagram of a program update device in one embodiment;

[0030] Figure 13 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0032] The program update method provided in this application embodiment can be applied to, for example, Figure 1In the application environment shown, terminal 102 communicates with server 104 via a network. A data storage system can store the data that server 104 needs to process. The data storage system can be integrated on server 104 or placed on the cloud or other network servers. Both the terminal and the server can be used independently to execute the program update method provided in this embodiment. The terminal and server can also work together to execute the program update method provided in this embodiment. For example, terminal 102 obtains the requirement description information of the program to be updated; based on the requirement description information, it determines the target blueprint file from multiple initial blueprint files corresponding to the program to be updated; based on the requirement description information and the target blueprint file, it determines the update blueprint file; it obtains the target source file of the target module corresponding to the target blueprint file; and based on the update blueprint file, it updates the target source file to obtain the update source file of the target module. Terminal 102 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart vehicle devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Server 104 can be implemented using a standalone server or a server cluster consisting of multiple servers.

[0033] In one embodiment, such as Figure 2 As shown, a program update method is provided. This embodiment uses the application of this method to a computer device as an example for illustration, including steps 202 to 208.

[0034] Step 202: Obtain the requirement description information of the program to be updated.

[0035] The program to be updated refers to a software program that requires new features, modifications, or optimizations. It consists of multiple modules, each corresponding to multiple source files, and these modules have dependencies on each other. The root directory of the program to be updated includes a source file directory and a blueprint file directory. The blueprint file directory and the source file directory have a isomorphic mapping relationship; this means there is a one-to-one correspondence between the directory structure of the blueprint file directory and the directory structure of the source file directory. The requirement description information refers to natural language information used to describe the program update requirements. For example, adding a capability to obtain a collaboration overview based on business objects to the collaboration recording module. The requirement description information can be input in text or voice format.

[0036] For example, a computer device obtains a requirement description information for a program to be updated.

[0037] Step 204: Based on the requirements description information, determine the target blueprint file from the multiple initial blueprint files corresponding to the program to be updated.

[0038] The initial blueprint file is an intermediate representation file generated from multiple initial source files of the same module to be updated through abstract syntax tree parsing and semantic compression. Each initial blueprint file corresponds one-to-one with a module; that is, each module in the program to be updated corresponds to one initial blueprint file. The initial blueprint file describes the module's responsibility contract, interface signature, dependency topology, and constraints, but does not contain any specific execution logic (such as loop bodies, conditional branches, or variable assignments). The initial blueprint file is a computer-readable intermediate representation file, not executable code. Initial blueprint files are stored in the blueprint file directory. The initial blueprint file includes, but is not limited to, a metadata module, a responsibility contract module, an interface definition module, a dependency module, and a constraint rule module. For example, a structural diagram of the initial blueprint file is shown below. Figure 3 As shown, it includes the metadata module, responsibility contract module, interfaces module, dependencies module, and constraints module. The target blueprint file refers to the blueprint file selected from multiple initial blueprint files based on the requirements description information, and is related to this program update task. The target blueprint file is an intermediate description file of the target source file of the target module corresponding to the target blueprint file. Both the initial blueprint files and the target blueprint file can be in Markdown (Lightweight Markup Language) format.

[0039] For example, the computer device determines keywords in the requirements description information, and determines the target blueprint file from multiple initial blueprint files corresponding to the program to be updated based on the keywords.

[0040] Step 206: Based on the requirements description information and the target blueprint file, determine the updated blueprint file.

[0041] Updating a blueprint file refers to modifying the target blueprint file according to the requirements description information to obtain the new blueprint file.

[0042] For example, the computer device inputs the requirements description information and the target blueprint file into the first neural network model, the first neural network model outputs the updated blueprint file, and the computer device obtains the updated blueprint file.

[0043] Step 208: Obtain the target source file of the target module corresponding to the target blueprint file, update the target source file based on the updated blueprint file, and obtain the updated source file corresponding to the requirement description information.

[0044] Here, the target module refers to the software functional module corresponding to the target blueprint file. The target source file refers to the initial source file belonging to the target module. The updated source file refers to the source file obtained by modifying the target source file based on the updated blueprint file; there can be one or more updated source files.

[0045] For example, the computer device determines the target module corresponding to the target blueprint file, obtains the target source file of the target module, inputs the updated blueprint file and the target source file into the second neural network model, the second neural network model updates the target source file based on the updated blueprint file, the second neural network model outputs the updated source file, and the computer device obtains the updated source file corresponding to the requirement description information.

[0046] In the above program update method, by introducing a blueprint file as an intermediate representation file, the program update process is transformed from a single-stage process of directly generating update source files based on requirement description information into a two-stage process of generating update blueprint files based on requirement description information and generating update source files based on update blueprint files. This allows the update logic corresponding to the requirement description information to be expressed in a structured form in the update blueprint file. Compared to directly updating the program to be updated based on requirement description information, this avoids interference from a large amount of execution logic code, exception handling branches, and syntax noise in the program to be updated on the core business logic. It enables the process of generating update blueprint files based on requirement description information to perform logical reasoning on the structured target blueprint file, thereby improving the accuracy of the update blueprint file. Then, the target source file is updated according to the update blueprint file to obtain the update source file corresponding to the requirement description information, which improves the accuracy of the update source file and thus improves the accuracy of the program update.

[0047] In one embodiment, based on the requirement description information and the target blueprint file, an updated blueprint file is determined, and the target source file is updated based on the updated blueprint file to obtain the updated source file corresponding to the requirement description information, including:

[0048] The first neural network model determines the updated blueprint file based on the requirement description information and the target blueprint file; the second neural network model updates the target source file based on the updated blueprint file to obtain the updated source file corresponding to the requirement description information.

[0049] The first neural network model refers to a machine learning model used to generate an updated blueprint file based on the requirements description information and the target blueprint file. This first neural network model can be a Large Language Model (LLM). Its inputs are the requirements description information and the target blueprint file, and its output is the updated blueprint file. The second neural network model refers to a machine learning model used to generate an updated source file based on the updated blueprint file. This second neural network model can also be a LLM. Its inputs are the updated blueprint file and the target source file, and its output is the updated source file.

[0050] The first and second neural network models have a permission isolation mechanism. The configuration diagrams of the first and second neural network models are shown below. Figure 4 As shown, the first and second neural network models differ in role localization, LLM Temperature parameters, permissions to the blueprint file directory, permissions to the source file target, available toolsets, coefficient prompts, core constraints, and system prompts. The first neural network model has read and write permissions to the initial blueprint file but no permissions to the initial source file. The second neural network model has read and write permissions to the initial source file but only read permissions to the initial blueprint file. For example, the system prompt for the first neural network model could be: "You are an architect agent. You can only read and modify Markdown blueprint files in the .blueprint directory. You are prohibited from reading or inferring source code implementation details (the src directory is not visible to you). Output modified blueprint files in a structured manner using ResponsibilityContract+Interfaces+Dependencies+Constraints. Never include specific technical implementations in blueprint files." The system prompt for the second neural network model could be: "You are an engineer agent. You can only read blueprint files in the .blueprint directory and use them as the sole source of truth for requirements and designs. You can read and modify source files in the src directory, but not .blueprint. You must strictly adhere to the ResponsibilityContract / Interfaces / Dependencies / Constraints in the blueprints. In case of conflicts between blueprint files and existing code, the blueprint file takes precedence."

[0051] For example, the computer device inputs the requirement description information and the target blueprint file into a first neural network model, the first neural network model outputs an updated blueprint file, and the computer device obtains the updated blueprint file; the computer device inputs the updated blueprint file and the target source file into a second neural network model, the second neural network model updates the target source file based on the updated blueprint file, the second neural network model outputs an updated source file, and the computer device obtains the updated source file corresponding to the requirement description information.

[0052] In one embodiment, determining the updated blueprint file based on requirement description information and the target blueprint file using a first neural network model includes: determining update information and dependency information based on requirement description information and the target blueprint file using the first neural network model; determining blueprint file change information based on update information and dependency information; and determining the updated blueprint file based on blueprint file change information and the target blueprint file. Update information refers to information describing the updated content, for example, update information such as "Add an interface getCollabOverviewForBizObject to the CollabRecord module". Dependency information refers to information describing dependency relationships, for example, dependency information such as "The added interface requires the getBizObjectSummary interface of the ERPLink module to obtain a summary of business objects". Blueprint file change information refers to change description information used to describe the differences in the blueprint file before and after the update.

[0053] In this embodiment, an update blueprint file is generated using a first neural network model, and an update source file is generated using a second neural network model. This allows the generation of the update blueprint file and the update source file to be performed by different neural network models, thereby decoupling the functions of architecture deduction and code implementation. By dividing the complex program update task into multiple sub-tasks and processing them by different neural network models, the cognitive burden on a single neural network model is reduced, improving the accuracy of the generated update blueprint file and update source file. Furthermore, compared to directly generating update source files based on all source files and requirement description information of the program to be updated, the second neural network model generates update source files based on the update blueprint file and a target source file (the portion of the source file in the program to be updated corresponding to the target module). This reduces the context size input to the second neural network model, lowers token consumption, and improves the inference efficiency and stability of the generated results.

[0054] In one embodiment, based on requirement description information, a target blueprint file is determined from multiple initial blueprint files corresponding to the program to be updated, including:

[0055] Keyword extraction is performed on the requirement description information to obtain the keywords corresponding to the requirement description information; based on the first mapping relationship between the candidate keywords and the candidate blueprint file paths corresponding to the program to be updated, the target blueprint file path corresponding to the keywords is determined; based on the target blueprint file path, the target blueprint file is obtained.

[0056] Here, keywords refer to words extracted from the requirements description information that characterize the core intent and the modules involved. The first mapping relationship refers to the correspondence between candidate keywords and candidate blueprint file paths, for example, the first mapping relationship is as follows:

[0057] "Chat", "Session", "Chat", "Session" → [.blueprint / ChatSession.md];

[0058] "Message", "Send", "Message", "Send" → [.blueprint / Message.md];

[0059] "ERP", "Orders", "Visibility", "Permissions" → [.blueprint / ERPLink.md];

[0060] "Collab", "Record", "Audit", "Collab" → [.blueprint / CollabRecord.md];

[0061] "Event", "Subscription", "Publish", "Event" → [.blueprint / EventBus.md].

[0062] The target blueprint file path refers to the storage path of the target blueprint file in the blueprint file directory.

[0063] For example, the computer device extracts keywords from the requirement description information to obtain the keywords corresponding to the requirement description information, obtains a first mapping relationship between the candidate keywords and the candidate blueprint file path corresponding to the program to be updated, determines the target blueprint file path corresponding to the keywords based on the first mapping relationship, and obtains the target blueprint file based on the target blueprint file path.

[0064] In this embodiment, by extracting keywords from the requirement description information and utilizing the mapping relationship between candidate keywords and candidate blueprint file paths, the target blueprint file path is quickly determined, and then the target blueprint file is obtained based on the target blueprint file path, thereby improving the efficiency and accuracy of obtaining the target blueprint file.

[0065] In one embodiment, obtaining the target source file of the target module corresponding to the target blueprint file includes:

[0066] Obtain the target blueprint file path of the target blueprint file; based on the second mapping relationship between the candidate blueprint file path and the candidate source file path corresponding to the program to be updated, determine the target source file path corresponding to the target blueprint file path; based on the target source file path, obtain the target source file of the target module corresponding to the target blueprint file.

[0067] The second mapping relationship refers to the correspondence between the candidate blueprint file path and the candidate source file path for the program to be updated. The second mapping relationship is established based on the blueprint file directory and the source file target. For example, a schematic diagram of the second mapping relationship is shown below. Figure 5 As shown, there is a one-to-one correspondence between candidate blueprint file paths and candidate source file paths. The target source file path refers to the source file path corresponding to the target blueprint file path.

[0068] For example, the computer device obtains the target blueprint file path of the target blueprint file, obtains the second mapping relationship between the candidate blueprint file path and the candidate source file path corresponding to the program to be updated, determines the target source file path corresponding to the target blueprint file path based on the second mapping relationship, and obtains the target source file of the target module corresponding to the target blueprint file based on the target source file path.

[0069] In this embodiment, the target source file path corresponding to the target blueprint file path is determined by the second mapping relationship between the candidate blueprint file path and the candidate source file path corresponding to the program to be updated, and the target source file is obtained based on the target source file path, thereby realizing a fast correspondence between the target blueprint file and the target source file, reducing the search process, and improving the efficiency and accuracy of obtaining the target source file.

[0070] In one embodiment, such as Figure 6 As shown, before updating the target source file based on the updated blueprint file, the following steps are also included:

[0071] Step 602: Based on the updated blueprint file and other blueprint files, construct a module dependency topology diagram for multiple modules in the program to be updated; the other blueprint files are the initial blueprint files corresponding to the program to be updated, excluding the initial blueprint file corresponding to the updated blueprint file.

[0072] In this context, "other blueprint files" refers to the initial blueprint files corresponding to the program to be updated, excluding the initial blueprint file used to generate the update blueprint file. The module dependency topology graph is a directed graph structure built based on the dependencies between the update blueprint file and other blueprint files, where nodes represent modules in the program to be updated, and edges represent dependencies between modules. For example, a schematic diagram of the module dependency topology graph is shown below. Figure 7As shown, the module dependency topology diagram includes 5 nodes: CollabRecord (collaboration record module), Message (message management module), ChatSession (session management module), EventBus (domain event bus module), and ERPLink (ERP access facade module), as well as the dependencies between the 5 nodes.

[0073] For example, the computer device obtains other initial blueprint files corresponding to the program to be updated, excluding the initial blueprint file corresponding to the updated blueprint file, and constructs a module dependency topology graph of multiple modules in the program to be updated based on the updated blueprint file and the other blueprint files.

[0074] Step 604: Perform circular dependency verification on the module dependency topology graph to obtain the circular dependency verification result.

[0075] Circular dependency verification refers to the process of checking the module dependency topology graph to determine whether a dependency cycle exists. The circular dependency verification result is the result obtained after verifying circular dependencies in the module dependency topology graph. The result can be either a non-circular dependency or a circular dependency. A non-circular dependency means there is no dependency cycle in the module dependency topology graph, while a circular dependency means there is a dependency cycle in the module dependency topology graph.

[0076] For example, a computer device performs a circular dependency check on the module dependency topology graph and obtains the circular dependency check result.

[0077] In one embodiment, a circular dependency check is performed on the dependency paths that include the target module in the module dependency topology graph to obtain a circular dependency check result. Here, a dependency path refers to a path that includes the target module. For example, if the dependency path is CollabRecord→ERPLink→ERPCore, and this dependency path has no loops, then the circular dependency check result is a non-circular dependency.

[0078] Step 606: Perform a hierarchical dependency direction verification on the architecture level of the target module and the architecture level of the dependent modules that the target module depends on in the module dependency topology graph, and obtain the hierarchical dependency direction verification result.

[0079] In software system architecture, an architectural hierarchy refers to the hierarchical structure formed by dividing modules according to their functional responsibilities and dependencies. Each architectural hierarchy has clearly defined boundaries of responsibility and allowed dependency directions. For example, an architectural hierarchy might include Controller (interface layer), Service (business logic layer), and Repository (data access layer), with the default dependency rule being Controller→Service→Repository. Related modules are those modules that have dependencies on the target module in the module dependency topology, including modules depended upon by the target module and modules that depend on the target module. Hierarchical dependency direction verification is the process of checking whether the dependencies between modules conform to the default hierarchical dependency rules based on the module's architectural hierarchy. The hierarchical dependency direction verification result is the result of the hierarchical dependency direction verification. The result can be either conforming to the hierarchical dependency rules or not conforming. Conforming to the hierarchical dependency rules means that the dependency direction between the target module's architectural hierarchy and the architectural hierarchy of its dependent modules satisfies the default hierarchical dependency rules. Not conforming to the hierarchical dependency rules means that the dependency direction between the target module's architectural hierarchy and the architectural hierarchy of its dependent modules violates the default hierarchical dependency rules.

[0080] For example, the computer device obtains the architecture level of the target module from the target blueprint file of the target module; determines the dependent modules that depend on the target module based on the module dependency topology diagram, and obtains the architecture level of the dependent modules from the initial blueprint file of the dependent modules; obtains the preset hierarchical dependency rules corresponding to the program to be updated; and performs hierarchical dependency direction verification on the dependency relationship between the architecture level of the target module and the architecture level of the dependent modules based on the preset hierarchical dependency rules and the dependency relationship between the target module and the dependent modules, thereby obtaining the hierarchical dependency direction verification result.

[0081] Step 608: Based on the negative constraint range in the updated blueprint file, perform negative constraint verification on the updated blueprint file to obtain the negative constraint verification result.

[0082] The negative constraint scope refers to the set of behavioral constraints that modules are prohibited from executing, defined in the blueprint file. It is used to validate newly added or modified interfaces and behaviors during blueprint file updates. The negative constraint validation result can be either "satisfied" or "not satisfied." "Satisfied" means that none of the newly added or modified module behaviors in the updated blueprint file violate the negative constraint scope defined in the blueprint file. "Not satisfied" means that some of the newly added or modified module behaviors in the updated blueprint file violate the negative constraint scope defined in the blueprint file.

[0083] For example, the computer device obtains the negative constraint range from the updated blueprint file, performs negative constraint verification on the updated blueprint file based on the negative constraint range, and obtains the negative constraint verification result.

[0084] Step 610: If the circular dependency check result is non-circular dependency, the hierarchical dependency direction check result is in compliance with the hierarchical dependency rule, and the negative constraint check result is in compliance with the negative constraint, then update the target source file based on the updated blueprint file.

[0085] For example, when the circular dependency check result is non-circular dependency, the hierarchical dependency direction check result is in compliance with the hierarchical dependency rule, and the negative constraint check result is in compliance with the negative constraint, the computer device performs an update based on the update blueprint file to update the target source file.

[0086] In one embodiment, if the circular dependency check result is a circular dependency, or the hierarchical dependency direction check result is a violation of the hierarchical dependency rule, or the negative constraint check result is a violation of the negative constraint, the execution is returned based on the requirement description information and the target blueprint file to determine the blueprint file to be updated.

[0087] In this embodiment, before updating the target source file based on the updated blueprint file, the updated blueprint file is verified in multiple dimensions by performing circular dependency checks, hierarchical dependency direction checks, and negative constraint checks. Circular dependency checks are used to avoid structural anomalies such as circular dependencies in the module dependency topology graph. Hierarchical dependency direction checks are used to ensure that the dependency relationships between modules conform to preset hierarchical dependency rules. Negative constraint checks are used to prevent newly added or modified interfaces and behaviors in the updated blueprint file from violating the negative constraint range defined in the blueprint file. This allows potential problems to be discovered in advance before the updated source file is generated, improving the stability and reliability of the generated updated source file.

[0088] In one embodiment, before obtaining the requirement description information of the program to be updated, the method further includes:

[0089] Obtain multiple source files from the program to be updated; for each source file, filter out target nodes from each node of the syntax tree corresponding to the source file based on preset filtering rules, and determine the metadata set corresponding to the source file based on the metadata corresponding to the target node; for each module of the program to be updated, determine the initial blueprint file of the module based on the metadata set corresponding to the multiple source files of the module; based on the correspondence between the initial blueprint file path of the initial blueprint file of the module and the initial source file paths of the multiple initial source files of the module, determine the second mapping relationship between the initial blueprint file path and the initial source file path of the program to be updated.

[0090] In this context, the syntax tree (AST) refers to the abstract syntax tree formed after parsing the source file, used to represent the structural information of the source file. Target nodes are nodes selected from the syntax tree according to preset filtering rules. These rules can include retaining class declaration nodes, interface declaration nodes, method signature nodes (including method name, parameter list, and return type), annotation nodes, import declaration nodes, and documentation comment nodes, while discarding concrete implementation nodes of function bodies (including assignment statements, loop structures, conditional branches, exception handling blocks, etc.) and field initialization expression nodes. Metadata refers to the structured descriptive information corresponding to the target nodes. The metadata collection is a set of structured descriptive information corresponding to the target nodes.

[0091] For example, before obtaining the requirements description information of the program to be updated, the computer device obtains multiple source files in the program to be updated; for each source file, the Java parser is called to generate the syntax tree of the source file, the syntax tree is traversed, target nodes are filtered out using preset filtering rules, the metadata of the target nodes is extracted, and the metadata of the target nodes is combined into a metadata set; for each module of the program to be updated, the metadata sets corresponding to the multiple source files of the module are aggregated to obtain the initial blueprint file of the module; the initial blueprint file is written to the blueprint file directory of the program to be updated to obtain the initial blueprint file path of the initial blueprint file, and based on the correspondence between the initial blueprint file path of the module's initial blueprint file and the initial source file paths of the multiple initial source files of the module, a second mapping relationship between the initial blueprint file path and the initial source file path of the program to be updated is determined.

[0092] In one embodiment, a schematic diagram of the process for determining the initial blueprint file is shown below. Figure 8As shown, the process includes: acquiring multiple source files from the program to be updated; parsing each source file using an abstract syntax tree parser to obtain its syntax tree; passing the syntax tree through a preset node type filter, retaining class declaration nodes, interface declaration nodes, method signature nodes, annotation nodes, import declaration nodes, and documentation comment nodes, while discarding function body implementation nodes and field initialization expression nodes; identifying the retained class declaration nodes, interface declaration nodes, method signature nodes, annotation nodes, import declaration nodes, and documentation comment nodes as target nodes, inputting the node information of the target nodes into a semantic inductor to obtain the metadata corresponding to the target nodes, and combining the metadata corresponding to multiple target nodes in the source files into a metadata set; for each module of the program to be updated, inputting the metadata set corresponding to multiple source files of the module into a Markdown generator to obtain the initial blueprint file of the module. The semantic inductor can be a Natural Language Processing (NLP) or a large language model.

[0093] In this embodiment, the source files in the program to be updated are parsed using an abstract syntax tree. Target nodes are then selected from the syntax tree nodes based on preset filtering rules. Metadata corresponding to the target nodes is further extracted and formed into a metadata set. Then, based on the metadata sets of multiple source files under the same module, a corresponding initial blueprint file is generated. This abstracts and compresses the syntactic structure information and its corresponding semantic description information in the source files, constructing a structured intermediate representation in the form of a blueprint file. This transforms complex source files into high-semantic-density initial blueprint files, reducing the interference of irrelevant syntactic information on subsequent processing, reducing context complexity, and improving the accuracy and efficiency of program updates based on the initial blueprint file.

[0094] In one embodiment, the program update method further includes:

[0095] If an adjustment is detected in the target module of the program to be updated, obtain the adjustment source identifier of the target module; if the adjustment source identifier is not triggered by artificial intelligence, determine the adjustment hash value of the adjustment source file of the target module; compare the adjustment hash value with the initial hash value in the target blueprint file corresponding to the target module; if the adjustment hash value is not equal to the initial hash value, determine the adjustment blueprint file of the target module based on the adjustment source file of the target module.

[0096] Monitoring refers to the process of detecting changes in the state of source files, used to identify whether changes such as addition, modification, deletion, or renaming have occurred. Monitoring can be implemented through the file system event listening mechanism, and the monitored events include, but are not limited to, creation, modification, deletion, and renaming. The adjusted source file refers to the source file of the target module that has been adjusted. The adjustment source identifier is information used to identify the source of the change in the target module, distinguishing whether the adjustment was triggered by artificial intelligence. The adjustment source identifier can be either AI-triggered or non-AI-triggered. AI-triggered adjustments refer to the source file being automatically generated or modified by an AI model based on the requirements description information, while non-AI-triggered adjustments refer to modifications made to the source file by human intervention. The adjustment hash value is the digest value obtained by hashing the adjusted source file of the target module. The initial hash value is the hash value recorded in the target blueprint file corresponding to the target module. The adjusted blueprint file is the blueprint file generated based on the adjusted source file of the target module.

[0097] For example, when a computer device detects that an initial source file has been adjusted, it obtains an adjustment source identifier; if the adjustment source identifier indicates that the adjustment was not triggered by artificial intelligence, it determines the target module corresponding to the initial source file that was adjusted, obtains the adjusted source file of the target module, performs a hash calculation on the adjusted source file of the target module to obtain an adjustment hash value; it obtains the initial hash value from the target blueprint file corresponding to the target module, and compares the adjustment hash value with the initial hash value; if the adjustment hash value is not equal to the initial hash value, it determines the adjusted blueprint file of the target module based on the adjusted source file of the target module.

[0098] In one embodiment, a schematic diagram of the reverse synchronization process is shown below. Figure 9 The above includes:

[0099] Step 902: Detect the initial source file change event and obtain the adjustment source identifier.

[0100] Step 904: Determine whether the adjustment source identifier is a non-AI-triggered adjustment.

[0101] Step 906: If the adjustment source is identified as AI-triggered adjustment, mark it as AI adjustment and stop blueprint file updates.

[0102] Step 908: If the adjustment source identifier is non-AI-triggered adjustment, then perform a hash calculation on the adjustment source file of the target module to obtain the adjustment hash value.

[0103] Step 910: Determine whether the adjusted hash value is equal to the initial hash value in the target blueprint file corresponding to the target module.

[0104] Step 912: If the adjusted hash value equals the initial hash value, stop updating the blueprint file.

[0105] Step 914: If the adjusted hash value is not equal to the initial hash value, then use AST parsing to extract the metadata set of the adjusted source file of the target module.

[0106] Step 916: Compare the metadata set of the target module's adjustment source file with the target blueprint file corresponding to the target module.

[0107] Step 918: Determine if there are any interface changes.

[0108] Step 920: If there are interface changes, update the interface definition module of the initial blueprint file.

[0109] Step 922: If there are no interface changes or after step 920 is completed, determine whether there are any dependency changes.

[0110] Step 924: If there are dependency changes, update the dependency module of the initial blueprint file.

[0111] Step 926: If there are no dependency changes or after step 924 has been completed, update the initial hash value in the initial blueprint file.

[0112] Step 928: Output a blueprint file synchronization report.

[0113] In this embodiment, when an adjustment to the source file of the target module is detected, the adjustment source identifier is used to distinguish whether the adjustment is triggered by artificial intelligence. If the adjustment source identifier indicates that the adjustment is not triggered by artificial intelligence, the adjustment hash value of the source file of the target module is further compared with the initial hash value in the target blueprint file to determine whether the source file has undergone substantial changes. When the adjustment hash value is not equal to the initial hash value, it is determined that the source file has undergone substantial changes, and an adjustment blueprint file corresponding to the target module is generated based on the adjustment source file. This achieves automatic synchronization and updating of blueprint files in scenarios where the source file is manually modified, avoiding inconsistencies between blueprint files and source files, and improving the consistency between blueprint files and source files.

[0114] In one exemplary embodiment, the program update system includes a blueprint file directory manager, a reverse semantic extractor, a file system listener, a bidirectional agent, and a consistency verification engine. The blueprint file directory manager maintains a second mapping between the initial blueprint file path and the initial source file path; the reverse semantic extractor synchronizes blueprint files after system initialization or non-AI-triggered blueprint file synchronization; the file system listener monitors file change events in the blueprint file directory and the source file directory; the bidirectional agent includes a first neural network model and a second neural network model for generating updated blueprint files and updated source files; and the consistency verification engine performs multi-dimensional verification on the updated blueprint files.

[0115] A diagram illustrating the data flow of program updates is shown below. Figure 10 As shown, the data flow between the user layer, orchestration layer, artificial intelligence (AI) agent layer, and synchronization layer is as follows:

[0116] (1) The user layer inputs the requirement description information to the orchestration layer.

[0117] (2) The orchestrator in the orchestration layer determines the target blueprint file path from the first mapping relationship based on the requirement description information.

[0118] (3) The orchestrator inputs the requirement description information and the target blueprint file path into the first neural network model in the bidirectional intelligent agent orchestrator.

[0119] (4) The first neural network model obtains the target blueprint file from the blueprint file directory based on the target blueprint file path, updates the target blueprint file based on the requirement description information, and obtains the updated blueprint file.

[0120] (5) The first neural network model sends the updated blueprint file to the orchestrator.

[0121] (6) The orchestrator calls the consistency verification engine to perform circular dependency verification, hierarchical dependency direction verification, and negative constraint verification on the updated blueprint file.

[0122] (7) When the circular dependency check result is non-circular dependency, the hierarchical dependency direction check result is in compliance with the hierarchical dependency rule, and the negative constraint check result is in compliance with the negative constraint, the consistency check engine sends the check result to the orchestrator.

[0123] (8) The orchestrator will update the blueprint file path and the target source file path into the second neural network model in the bidirectional agent orchestrator.

[0124] (9) The second neural network model obtains the updated blueprint file from the blueprint file directory based on the updated blueprint file path.

[0125] (10) The second neural network model obtains the target source file from the source file directory based on the target source file path, and updates the target source file based on the update blueprint file to obtain the updated source file.

[0126] (11) The file system monitor in the synchronization layer monitors the blueprint file directory and the source file directory.

[0127] (12) The reverse semantic extractor in the synchronization layer determines the metadata set of the adjustment source file, thereby generating the adjustment blueprint file of the target module corresponding to the adjustment source file, and the blueprint file directory is updated.

[0128] The timing diagram for program updates is as follows: Figure 11 As shown, it includes:

[0129] (1) User / developer inputs requirement description information.

[0130] (2) The orchestrator performs semantic retrieval based on the requirement description information and the first mapping relationship to obtain the target blueprint file path.

[0131] (3) Based on the target blueprint file path, the orchestrator reads the target blueprint file from the blueprint file directory.

[0132] (4) The orchestrator sends the requirements description information and target blueprint file to the first neural network model.

[0133] (5) The first neural network model updates the target blueprint file based on the requirement description information to obtain the updated blueprint file.

[0134] (6) The first neural network model outputs an updated blueprint file.

[0135] (7) The arranger displays the updated blueprint file and requests approval.

[0136] (8) User / developer input approved.

[0137] (9) The orchestrator sends a verification request to the consistency verification engine for the updated blueprint file.

[0138] (10) The consistency verification engine reads all blueprint files.

[0139] (11) Consistency verification engine building module dependency topology graph.

[0140] (12) The consistency verification engine performs circular dependency verification, hierarchical dependency direction verification and negative constraint verification.

[0141] (13) The consistency verification engine sends the verification results to the orchestrator.

[0142] (14) The editor obtains the target source file from the source file directory.

[0143] (15) The orchestrator sends the updated blueprint file and the target source file to the second neural network model.

[0144] (16) The second neural network model updates the target source file based on the updated blueprint file to obtain the updated source file.

[0145] (17) The second neural network model outputs an update to the source file.

[0146] (18) The editor compiles and tests the updated source files.

[0147] (19) The arranger displays the updated blueprint file and the updated source file.

[0148] In the above program update method, by introducing a blueprint file as an intermediate representation file, the program update process is transformed from a single-stage process of directly generating update source files based on requirement description information into a two-stage process of generating update blueprint files based on requirement description information and generating update source files based on update blueprint files. This allows the update logic corresponding to the requirement description information to be expressed in a structured form in the update blueprint file. Compared to directly updating the program to be updated based on requirement description information, this avoids interference from a large amount of execution logic code, exception handling branches, and syntax noise in the program to be updated on the core business logic. It enables the process of generating update blueprint files based on requirement description information to perform logical reasoning on the structured target blueprint file, thereby improving the accuracy of the update blueprint file. Then, the target source file is updated according to the update blueprint file to obtain the update source file corresponding to the requirement description information, which improves the accuracy of the update source file and thus improves the accuracy of the program update.

[0149] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0150] Based on the same inventive concept, this application also provides a program update apparatus for implementing the program update method described above. The solution provided by this apparatus is similar to the implementation described in the above method; therefore, the specific limitations in one or more program update apparatus embodiments provided below can be found in the limitations of the program update method described above, and will not be repeated here.

[0151] In one embodiment, such as Figure 12 As shown, a program update device is provided, including: an acquisition module 1202, a determination module 1204, a blueprint file update module 1206, and a source file update module 1208, wherein:

[0152] Module 1202 is used to obtain the requirement description information of the program to be updated;

[0153] Module 1204 is used to determine the target blueprint file from multiple initial blueprint files corresponding to the program to be updated based on the requirements description information.

[0154] The blueprint file update module 1206 is used to determine the blueprint file to be updated based on the requirements description information and the target blueprint file;

[0155] The source file update module 1208 is used to obtain the target source file of the target module corresponding to the target blueprint file, update the target source file based on the update blueprint file, and obtain the update source file corresponding to the requirement description information.

[0156] In one embodiment, the blueprint file update module 1206 is further configured to: determine the updated blueprint file based on the requirement description information and the target blueprint file using a first neural network model; the source file update module 1208 is further configured to: update the target source file based on the updated blueprint file using a second neural network model to obtain the updated source file corresponding to the requirement description information.

[0157] In one embodiment, the determining module 1204 is further configured to: extract keywords from the requirement description information to obtain keywords corresponding to the requirement description information; determine the target blueprint file path corresponding to the keywords based on the first mapping relationship between the candidate keywords and the candidate blueprint file path corresponding to the program to be updated; and obtain the target blueprint file based on the target blueprint file path.

[0158] In one embodiment, the source file update module 1208 is further configured to: obtain the target blueprint file path of the target blueprint file; determine the target source file path corresponding to the target blueprint file path based on the second mapping relationship between the candidate blueprint file path and the candidate source file path corresponding to the program to be updated; and obtain the target source file of the target module corresponding to the target blueprint file based on the target source file path.

[0159] In one embodiment, the program update apparatus further includes a verification module, which is configured to: construct a module dependency topology diagram of multiple modules in the program to be updated based on the updated blueprint file and other blueprint files; the other blueprint files are the initial blueprint files corresponding to the program to be updated, excluding the initial blueprint file corresponding to the updated blueprint file; perform cyclic dependency verification on the module dependency topology diagram to obtain a cyclic dependency verification result; perform hierarchical dependency direction verification on the architecture level of the target module and the architecture level of the dependent modules that the target module depends on in the module dependency topology diagram to obtain a hierarchical dependency direction verification result; perform negative constraint verification on the updated blueprint file based on the negative constraint range in the updated blueprint file to obtain a negative constraint verification result; and, if the cyclic dependency verification result is non-cyclic, the hierarchical dependency direction verification result is in accordance with the hierarchical dependency rules, and the negative constraint verification result is in accordance with the negative constraints, execute the update of the target source file based on the updated blueprint file.

[0160] In one embodiment, the program update apparatus further includes a mapping relationship establishment module, which is configured to: obtain multiple source files in the program to be updated; for each source file, filter out target nodes from each node of the syntax tree corresponding to the source file based on preset filtering rules, and determine the metadata set corresponding to the source file based on the metadata corresponding to the target node; for each module of the program to be updated, determine the initial blueprint file of the module based on the metadata set corresponding to the multiple source files of the module; and determine a second mapping relationship between the initial blueprint file path and the initial source file path of the program to be updated based on the correspondence between the initial blueprint file path of the initial blueprint file of the module and the initial source file paths of the multiple initial source files of the module.

[0161] In one embodiment, the program update apparatus further includes a synchronization adjustment module, which is used to: obtain the adjustment source identifier of the target module when an adjustment is detected in the target module of the program to be updated; determine the adjustment hash value of the adjustment source file of the target module when the adjustment source identifier is a non-AI-triggered adjustment; compare the adjustment hash value with the initial hash value in the target blueprint file corresponding to the target module; and determine the adjustment blueprint file of the target module based on the adjustment source file of the target module when the adjustment hash value is not equal to the initial hash value.

[0162] Each module in the aforementioned program update device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0163] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 13 As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a program update method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0164] Those skilled in the art will understand that Figure 13 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0165] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above-described method embodiments.

[0166] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0167] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0168] 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.

[0169] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments described above. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, etc., and are not limited to these.

[0170] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0171] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A program update method, characterized in that, The method includes: Obtain the requirement description information of the program to be updated; Based on the requirement description information, the target blueprint file is determined from multiple initial blueprint files corresponding to the program to be updated; Based on the requirement description information and the target blueprint file, the blueprint file to be updated is determined; Obtain the target source file of the target module corresponding to the target blueprint file, update the target source file based on the updated blueprint file, and obtain the updated source file corresponding to the requirement description information.

2. The method according to claim 1, characterized in that, The step of determining the updated blueprint file based on the requirement description information and the target blueprint file includes: Based on the requirement description information and the target blueprint file, the updated blueprint file is determined using the first neural network model. The step of updating the target source file based on the updated blueprint file to obtain the updated source file corresponding to the requirement description information includes: The target source file is updated based on the updated blueprint file using the second neural network model to obtain the updated source file corresponding to the requirement description information.

3. The method according to claim 1, characterized in that, The step of determining the target blueprint file from multiple initial blueprint files corresponding to the program to be updated based on the requirement description information includes: Keyword extraction is performed on the requirement description information to obtain the keywords corresponding to the requirement description information; Based on the first mapping relationship between candidate keywords and candidate blueprint file paths corresponding to the program to be updated, the target blueprint file path corresponding to the keyword is determined; Obtain the target blueprint file based on the target blueprint file path.

4. The method according to claim 1, characterized in that, The step of obtaining the target source file of the target module corresponding to the target blueprint file includes: Obtain the target blueprint file path; Based on the second mapping relationship between the candidate blueprint file path and the candidate source file path corresponding to the program to be updated, the target source file path corresponding to the target blueprint file path is determined; Based on the target source file path, obtain the target source file of the target module corresponding to the target blueprint file.

5. The method according to claim 1, characterized in that, Before updating the target source file based on the updated blueprint file, the method further includes: Based on the updated blueprint file and other blueprint files, a module dependency topology diagram of multiple modules in the program to be updated is constructed; the other blueprint files are the initial blueprint files corresponding to the program to be updated, excluding the initial blueprint file corresponding to the updated blueprint file; Perform cyclic dependency verification on the module dependency topology graph to obtain the cyclic dependency verification result; The hierarchical dependency direction is verified between the architecture level of the target module and the architecture level of the dependent modules that the target module depends on in the module dependency topology graph, and the hierarchical dependency direction verification result is obtained. Based on the negative constraint range in the updated blueprint file, the updated blueprint file is validated for negative constraints to obtain the negative constraint validation result. If the circular dependency check result is a non-circular dependency, the hierarchical dependency direction check result is in compliance with the hierarchical dependency rule, and the negative constraint check result is in compliance with the negative constraint, then the target source file is updated based on the updated blueprint file.

6. The method according to claim 1, characterized in that, Before obtaining the requirement description information of the program to be updated, the following is also included: Obtain multiple source files from the program to be updated; For each source file, target nodes are selected from each node of the syntax tree corresponding to the source file based on preset filtering rules, and the metadata set corresponding to the source file is determined based on the metadata corresponding to the target nodes. For each module of the program to be updated, the initial blueprint file of the module is determined based on the metadata set corresponding to multiple source files of the module; Based on the correspondence between the initial blueprint file path of the initial blueprint file of the module and the initial source file paths of the multiple initial source files of the module, a second mapping relationship between the initial blueprint file path and the initial source file path of the program to be updated is determined.

7. The method according to claim 1, characterized in that, The method further includes: If an adjustment is detected in the target module of the program to be updated, the source identifier of the adjustment of the target module is obtained; If the adjustment source is identified as being triggered by non-AI, determine the adjustment hash value of the adjustment source file of the target module; The adjusted hash value is compared with the initial hash value in the target blueprint file corresponding to the target module; If the adjusted hash value is not equal to the initial hash value, the adjusted blueprint file of the target module is determined based on the adjusted source file of the target module.

8. A program update device, characterized in that, The device includes: The acquisition module is used to obtain the requirement description information of the program to be updated; The determination module is used to determine the target blueprint file from multiple initial blueprint files corresponding to the program to be updated based on the requirement description information; The blueprint file update module is used to determine the blueprint file to be updated based on the requirement description information and the target blueprint file; The source file update module is used to obtain the target source file of the target module corresponding to the target blueprint file, update the target source file based on the update blueprint file, and obtain the update source file corresponding to the requirement description information.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

11. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 7.

Images