A code review method, device, storage medium and program product

Abstract

The application provides a code review method, device, storage medium and program product. The method comprises: performing semantic labeling on variables in target code according to a requirement document to generate a variable description document; generating a prompt word of a large language model according to the requirement document, the target code and the variable description document; inputting the prompt word of the large language model into the large language model to generate a review result of the target code. Compared with the prior art, the embodiment of the application establishes a mapping relationship between the code and the requirement document by performing semantic labeling on the variables in the target code according to the requirement document to generate the variable description document; and the large language model can accurately understand the meaning of the variables in the target code by further generating the prompt word in combination with the requirement document and the target code, thereby improving the reliability of the code review and the accuracy of the code review result.

Description

Technical Field

[0001] This application relates to the field of code verification technology, specifically to a code review method, device, storage medium, and program product. Background Technology

[0002] In the current field of automotive electronics development, Model-Based Design (MBD) has become the mainstream development approach. Tools such as Simulink, with their intuitive visual modeling capabilities and powerful code generation functions, are widely used in the development of vehicle control unit (VCU) control algorithms. In practical applications, developers only need to build control models based on graphical modules in a visual interface to automatically generate matching code, greatly shortening the development cycle.

[0003] However, code automatically generated by tools like Simulink has shortcomings in readability, maintainability, and structural standardization. Specifically, variable names in automatically generated code are often composed of system-automatic identifiers and abbreviations, making it difficult to intuitively reflect their meaning or functional attributes at the vehicle control level. Furthermore, the generated code structure often lacks an intuitive correspondence with the control model. This leads to developers spending a significant amount of time manually comparing and contrasting complex code with the control model during code reviews. This reliance on manual review is not only inefficient but also prone to causing developers to overlook deep logical errors due to fatigue.

[0004] In related technologies, general code analysis techniques are often used to replace manual code review, thereby improving the efficiency of code review. For example, requirements documents and target code are directly input into a large language model, which then performs matching analysis and logical verification between the code and requirements. However, because this approach does not incorporate the code generation logic, the large language model cannot understand the meaning of variables generated based on specific logic, nor can it understand the design intent behind the code. Therefore, it cannot accurately identify the code logic, resulting in low accuracy of the code review results.

[0005] It should be noted that the information disclosed in the background section of this application is intended only to enhance the understanding of the general background of this application, and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0006] This application provides a code review method, device, storage medium, and program product to solve the problem in the prior art that the code review does not incorporate the code generation logic, resulting in large language models being unable to understand the meaning of variables in the code and inaccurate code review results.

[0007] Firstly, embodiments of this application provide a code review method, including: Based on the requirements document, semantically annotate the variables in the target code and generate variable description documents; Based on the requirements document, the target code, and the variable description document, generate prompt words for the large language model; Input the prompt words from the large language model into the large language model to generate the review results of the target code.

[0008] In one possible implementation, the target code is application-layer code that includes algorithmic logic.

[0009] In one possible implementation, the step of semantically annotating variables in the target code based on the requirements document and generating a variable description document includes: The names of the variables in the target code are semantically matched with the requirements document to obtain the requirements description of the variables; Generate a variable description document based on the variable name and the variable requirement description.

[0010] One possible implementation also includes: If the requirement specification for the variable does not exist, then the variable shall be deleted from the variable specification document.

[0011] In one possible implementation, the step of semantically matching the names of variables in the target code with the requirements document to obtain the requirement description of the variables includes: Map the names of variables in the target code and the requirement description fragments in the requirement document to a first vector representation and a second vector representation, respectively. Based on the comparison result between the vector representation distance and the preset distance, the requirement description of the variable is determined, wherein the vector representation distance is the distance between the first vector representation and the second vector representation.

[0012] In one possible implementation, generating prompt words for the large language model based on the requirements document, the target code, and the variable specification document includes: Based on the requirements document, the target code, the variable description document, and the code review rules, the prompt words for the large language model are generated.

[0013] One possible implementation also includes: The review results of the target code will be submitted for manual review.

[0014] Secondly, embodiments of this application provide an electronic device, including: processor; Memory; And a computer program, wherein the computer program is stored in the memory, and when the computer program is executed by the processor, causes the electronic device to perform the method described in any one of the first aspects.

[0015] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in any one of the first aspects.

[0016] Fourthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements the method described in any one of the first aspects.

[0017] Compared with the prior art, the embodiments of this application establish a mapping relationship between code and requirements document by semantically annotating variables in target code according to requirements document and generating variable description document; by further combining requirements document and target code to generate prompt words, the large language model can accurately understand the meaning of variables in target code, thereby improving the reliability of code review and the accuracy of code review results. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a code review method provided in an embodiment of this application; Figure 2 A flowchart illustrating a semantic annotation method provided in an embodiment of this application; Figure 3 A flowchart illustrating a semantic matching method provided in an embodiment of this application; Figure 4 A flowchart illustrating another code review method provided in this application embodiment; Figure 5 This application provides a schematic diagram of the structure of a code review system according to an embodiment of the present application. Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0020] To better understand the technical solution of this application, the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0021] It should be understood that the described embodiments are merely some, not all, of the embodiments in this application. All other embodiments obtained by those skilled in the art based on the embodiments in this application without inventive effort are within the scope of protection of this application.

[0022] The terminology used in the embodiments of this application is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. The singular forms “a,” “the,” and “the” used in the embodiments of this application and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0023] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0024] With the increasing complexity of automotive electronic and electrical architectures, the Vehicle Control Unit (VCU), as the core control unit of new energy vehicles, directly impacts the vehicle's power performance, safety, and reliability through the quality and efficiency of its software development. In the current field of automotive electronics development, Model-Based Design (MBD) has become the mainstream development approach. Developers do not need to write code directly; instead, they construct visual models to represent system functions and control logic, and then perform simulation testing, automatic code generation, and other development stages based on these models. Tools such as Simulink, with their intuitive visual modeling capabilities and powerful code generation functions, are widely used in the development of VCU control algorithms. In practical applications, developers only need to build control models based on graphical modules in a visual interface to automatically generate matching code, significantly shortening the development cycle.

[0025] However, the code automatically generated by tools like Simulink has shortcomings in terms of readability, maintainability, and structural standardization. Specifically, variable names in automatically generated code are often composed of system-automatic identifiers and abbreviations, making it difficult to intuitively reflect their meaning or functional attributes at the vehicle control level. For example, the semantically clear "target torque" control signal in the control model may be renamed to rtDW.obj_x or a complex identifier containing the prefix "model_" after code generation, making it impossible for developers to directly identify its meaning from the variable name. Furthermore, the generated code structure often lacks an intuitive correspondence with the control model. For example, the hierarchical "battery management" subsystem in the control model may have its code logic scattered and merged into various locations after optimization by code generation tools (such as function inlining or logic expansion), resulting in the loss of the original hierarchical structure of the control model at the code level.

[0026] This results in developers spending a significant amount of time manually comparing and tracing complex code against control models during code reviews. This manual review method is not only inefficient but also prone to causing developers to overlook deep-seated logical errors due to fatigue.

[0027] In related technologies, general code analysis techniques are often used to replace manual code review to improve efficiency. For example, requirements documents and target code are directly input into a large language model, relying on the model to automatically perform matching analysis and logical verification between the code and requirements. However, because this approach does not incorporate the code generation logic, the large language model cannot understand the meaning of variables generated based on specific logic. For instance, for the variable name rtDW.Subsystem1_Gain in the code, the large language model often only recognizes it literally as a common subsystem gain variable, unable to reconstruct its true meaning (such as a torque calibration coefficient) based on the model's generation rules, let alone understand the design intent behind the code. This results in an inaccurate identification of the code logic and low accuracy in code review results.

[0028] To address the aforementioned issues, this application provides a code review method. Compared to existing technologies, this application establishes a mapping relationship between code and requirements documents by semantically annotating variables in the target code based on the requirements document and generating variable description documents. Furthermore, by combining the requirements document and the target code to generate prompts, a large language model can accurately understand the meaning of variables in the target code, thereby improving the reliability and accuracy of code review results.

[0029] Specifically, the following detailed description is provided in conjunction with the accompanying drawings and specific embodiments.

[0030] See Figure 1 This is a flowchart illustrating a code review method provided in an embodiment of this application. Figure 1 As shown, the method specifically includes the following steps.

[0031] Step S101: Based on the requirements document, perform semantic annotation on the variables in the target code and generate a variable description document.

[0032] In this context, target code refers to the code of the target module (such as the torque management module and energy recovery module in a VCU), i.e., the relevant code of the module that needs to undergo code review. Variables are data identifiers defined or referenced in the target code for storing, transmitting, and processing data; variables include, but are not limited to, input signals, output signals, internal state variables, system parameters, and intermediate calculation variables. Requirements documents are documents that describe the functional points, input / output definitions, control strategies, etc., of the target module.

[0033] As mentioned above, model-based design tools like Simulink suffer from deficiencies in code readability and standardization during automatic code generation, particularly in variable naming, which often fails to intuitively reflect their function. This makes it difficult for large language models (such as Deepseek and ChatGPT) to understand the meaning of variables in the code, even with requirements documentation. Therefore, in this embodiment, the variables in the target code are first semantically annotated, providing a standard variable specification document for subsequent parsing by the large language model, thus establishing a direct link between the requirements document and the target code.

[0034] In this embodiment, semantic annotation refers to the process of associating and annotating variables in the target code based on the functional descriptions recorded in the requirements document. By attaching corresponding explanatory information (such as the meaning of the name, functional attributes, etc.) to the non-intuitive variable names, and then generating corresponding variable description documents, a semantic mapping relationship between code variables and the requirements descriptions in the requirements document can be established, avoiding the problem of large models being unable to correctly understand automatically generated code due to non-standard naming.

[0035] In one possible implementation, semantic annotation in the target code can be based on semantic reasoning through context. Specifically, the logical context of the variables in the target code (such as related calculation formulas) is parsed, and descriptive paragraphs with the same control logic are retrieved in the requirements document to deduce the meaning represented by the variables. Then, the variables and the meanings they represent are combined to complete the semantic annotation.

[0036] Of course, those skilled in the art can adjust the above semantic annotation method according to actual needs, and the embodiments of this application do not impose specific limitations on this.

[0037] In practical applications, the code of the target module includes not only code related to the execution logic, but also header files, hardware-related code, and other code that is not related to the execution logic. This code that is not related to the execution logic can affect the analysis of the code execution logic by the large language model.

[0038] Therefore, in one possible implementation, the target code is the application-layer code containing the algorithmic logic. This can be understood as the application-layer code containing the algorithmic logic, which is the function implementation within the target module responsible for executing the specific control strategy, excluding declaration files and hardware-layer code that do not contain specific algorithm implementations. By selecting only the application-layer code containing the algorithmic logic, the amount of target code is significantly reduced while retaining critical code, thereby improving the efficiency and accuracy of semantic annotation, as well as the efficiency and accuracy of subsequent large language model analysis.

[0039] In one possible implementation, before semantically annotating the variables in the target code according to the requirements document, preprocessing is required. This preprocessing includes removing blank lines, comments, and redundant formatting symbols. This operation eliminates data noise in the code and reduces interference from invalid information on subsequent semantic annotation and code analysis, thereby improving overall processing efficiency and the accuracy of semantic annotation.

[0040] In one possible implementation, before semantically annotating the variables in the target code based on the requirements document, the requirements document can be preprocessed. This preprocessing includes structured parsing and reorganization of the requirements document according to functional points. Specifically, the text content in the document is divided into independent functional description units according to functional points, and a functional hierarchy index is established to facilitate rapid location of the correspondence between the requirements descriptions and the variables in the target code.

[0041] Step S102: Generate prompt words for the large language model based on the requirements document, target code, and variable description document.

[0042] Among them, the prompt words of the large language model refer to the set of information input during the reasoning stage of the large language model, which consists of task instructions, context information and input data. They are used to specify the processing logic and input objects of the model in the code review task, thereby guiding the model to output the review results that meet the expectations.

[0043] In this embodiment, to ensure that the prompts are understandable to the large model, the requirements document, target code, and variable specification document can be combined in a logical order. For example, following the code review process, the requirements document can be presented first to establish functional baselines, then the variable specification document can be introduced to build semantic bridges, and finally the target code can be input for the large language model to perform association analysis.

[0044] In one possible implementation, input / output requirements and the form and content of code review (such as syntax rule checks, algorithm time and space complexity checks) can be embedded in the prompts. This allows the large language model to more clearly understand the user's needs and conduct personalized code reviews.

[0045] In practical applications, if prompts generated from requirements documents, target code, variable description documents, and code review tasks are directly input into a large language model, the code review task can be completed. However, since the corpus of the large language model may lack corresponding code review standards, the code review will lack standardization.

[0046] Therefore, in one possible implementation, prompt words for the large language model are generated based on the requirements document, target code, variable specification document, and code review rules.

[0047] The code review rules can be developer-defined code specifications for different vehicle models, or industry technical standards, code review guidelines, and variable validation rules for programming languages ​​(such as C). It is understandable that providing code review rules can significantly improve the standardization and reasonableness of the code review results generated by the large language model.

[0048] Understandably, by generating prompts adapted to the current review scenario based on requirements documents, target code, and variable description documents, it is possible to provide scenario-based guidance for large language models, thereby enabling personalized VCU control algorithm code review.

[0049] Step S103: Input the prompt words from the large language model into the large language model to generate the review results of the target code.

[0050] In step S102, the prompt words for the large language model have been generated. Inputting these prompt words into the large language model will yield the code review results. These results include, but are not limited to, variable validation results, logic validation results, and syntax validation results.

[0051] In one possible implementation, to avoid the generated prompts in step S102 being too long, it is also possible to choose not to introduce code review rules when generating prompts, but instead to input the prompts and code review rules of the large language model into the large language model separately, and use a multi-round interactive mechanism for step-by-step processing.

[0052] Specifically, in the first round of dialogue, prompts containing variable descriptions, target code, and requirements documents can be input. This allows the large language model to establish a contextual understanding of the code logic and variable semantics. Subsequently, code review rules can be input separately in later dialogues to guide the large language model in performing review judgments based on the previously loaded contextual information. This approach effectively reduces the length of each input, prevents information truncation due to context exceeding the processing window limit of the large language model, and avoids lengthy code review rules interfering with code analysis, thereby improving the stability of code review.

[0053] In practical applications, even with strict constraints on large language models, the generated code review results may still have problems.

[0054] Therefore, one possible implementation is to submit the code review results for manual review. In practice, one can choose to submit problematic variables or code segments from the code review results for review, or one can choose to randomly select samples from the code review results according to a preset ratio for review, thus avoiding unnecessary workload for subsequent code iterations and secondary code reviews due to issues such as the illusion of a large language model.

[0055] Compared with the prior art, the embodiments of this application establish a mapping relationship between code and requirements document by semantically annotating variables in target code according to requirements document and generating variable description document; by further combining requirements document and target code to generate prompt words, the large language model can accurately understand the meaning of variables in target code, thereby improving the reliability of code review and the accuracy of code review results.

[0056] The above embodiments introduced a semantic reasoning method for semantic annotation in target code based on contextual association. However, this method matches the specific content of the code with the requirements document, which requires a significant amount of time for retrieval and matching, resulting in low efficiency. Furthermore, due to differences in language expression between the code implementation details and the requirements document description, simple content matching often leads to low annotation accuracy. Therefore, further optimization of semantic annotation is needed.

[0057] See Figure 2 This is a flowchart illustrating a semantic annotation method provided in an embodiment of this application. Figure 2 As shown, the method specifically includes the following steps.

[0058] Step S201: Semantically match the names of variables in the target code with the requirements document to obtain the requirement descriptions of the variables.

[0059] In this embodiment, the names of variables in the target code are used as the index items for matching. Specifically, the variable names are matched against the requirements document. The variable names are used as keywords in the requirements document for searching, and requirement description fragments related to the variable names are retrieved. Explanations of the variables are extracted from these requirement description fragments as the variable's requirement description. These requirement description fragments related to the variable names can be either requirement description fragments containing the variable names themselves or requirement description fragments containing synonyms of the variable names.

[0060] For example, assuming the variable name is "Batt_SOC", the requirements document is searched for requirement description fragments containing "Batt_SOC" or its synonyms or near-synonyms (such as "SOC", "battery state of charge", "remaining battery capacity", etc.). If the retrieved requirement description fragment is "limit output power when battery state of charge (SOC) is below 20%", then the description "battery state of charge" is extracted and used as the requirement description for the variable "Batt_SOC".

[0061] In practical applications, a dictionary of variable name abbreviations can be pre-defined to assist in semantic matching. For example, "Batt" can be mapped to "Battery" and "SOC" to "State of Charge" based on the dictionary, thereby using these full-name terms as synonyms for retrieval in the requirements document.

[0062] Understandably, performing semantic matching directly based on variable names can reduce the workload of semantic matching and improve its efficiency. At the same time, matching based on variable names allows for direct explanations in the requirements document, avoiding misunderstandings that may arise when inferring the meaning of variables solely from the code, thus improving the reliability of semantic annotation.

[0063] In practical applications, searching for requirement documents using variable names or their synonyms and near-synonyms as keywords may sometimes fail due to a lack of intuitive data support. This makes the matching results susceptible to subjective influences (such as the definition of synonyms and near-synonyms), and the objectivity of semantic matching cannot be guaranteed.

[0064] See Figure 3 This is a flowchart illustrating a semantic matching method provided in an embodiment of this application. Figure 3 As shown, the method specifically includes the following steps.

[0065] Step S301: Map the names of variables in the target code and the requirement specification fragments in the requirement document to the first vector representation and the second vector representation, respectively.

[0066] In this embodiment of the application, the variable names in the target code and the requirement description fragments in the requirement document are directly mapped to the first vector representation and the second vector representation in the semantic vector space, respectively, and then the subsequent semantic matching is performed in the form of vectors.

[0067] Step S302: Determine the variable requirements based on the comparison results between the vector distance and the preset distance.

[0068] Here, the vector representation distance is the distance between the first vector representation and the second vector representation. The preset distance refers to the distance of the reference vector representation. It can be understood that the distance between vector representations is the similarity of vectors in the semantic space; the smaller the distance, the higher the similarity, and the larger the distance, the lower the similarity.

[0069] In other words, if the distance between the vectors is greater than or equal to the preset distance, it means that the requirement description fragment and the variable name are highly similar and can be used to determine the requirement description of the variable; if the distance between the vectors is less than the preset distance, it means that the requirement description fragment and the variable name are unrelated.

[0070] In practical applications, Euclidean distance and cosine similarity can be used as methods for calculating the distance between vector representations. For determining the requirements specification of a variable, the requirement document segment with the smallest vector representation distance corresponding to the variable name that meets the preset distance condition can be extracted as the requirement specification for that variable.

[0071] In this embodiment, by mapping the requirement description fragments and variable names in the requirement document to different vector representations and calculating the distance between these vector representations, the similarity of vectors in the semantic space can be intuitively reflected. Using the comparison result between the vector representation distance and a preset distance as the method for determining the variable requirement description not only enables accurate and efficient semantic matching but also provides high interpretability.

[0072] Of course, those skilled in the art can adjust the semantic matching method according to their needs, such as using a hybrid matching strategy, first quickly filtering out candidate requirement description fragments based on keywords or rules, and then calculating the vector distance within the candidate set. This application does not impose specific limitations on this.

[0073] Step S202: Generate a variable specification document based on the variable name and the variable requirement description.

[0074] In the steps above, the requirements specifications corresponding to the variables have been determined. Based on this, step S202 can specifically use the variable name as the main identifier of the document, and the extracted requirements specifications as the semantic explanation content of the main body, and organize and output them according to a preset format (such as key-value pairs) to form a variable specification document containing the variable names and their meanings.

[0075] However, in practical applications, the generation of target code involves not only variables associated with the requirements document, but also many automatically generated intermediate variables. These intermediate variables often do not have actual physical meaning and have low value for code review. If they are retained in the variable specification document, they will bring unnecessary workload to the code review.

[0076] Therefore, in one possible implementation, if the requirement specification for a variable does not exist, the variable is deleted from the variable specification document.

[0077] Understandably, variables not present in the requirements specification are usually intermediate variables automatically generated by the code and lack physical meaning. Removing these variables effectively filters out redundant and distracting information, ensuring that the variable specification document only includes clearly defined key variables, thereby improving the efficiency of code review.

[0078] To illustrate the code review method, the following explanation will be provided with specific examples.

[0079] See Figure 4 This is a flowchart illustrating another code review method provided in an embodiment of this application. Figure 4 As shown, the method specifically includes the following steps.

[0080] Step 1: Target module extraction and preprocessing.

[0081] First, input the Simulink project file and select the target module. Debug the target module's control model based on its inputs and outputs to ensure the overall logic is correct and it can execute correctly. Next, perform automatic code generation to obtain the target module's code. Select the logic code file (including the application layer code of the algorithm logic) from the target module's code that includes the control model's main function as the target code; delete blank lines and comments in the target code and save it as a target code text file.

[0082] Step 2: Structure and organize the requirements document.

[0083] First, locate the requirement paragraphs in the overall requirements document based on the name of the target module, and save them as a requirements document text file. Further, divide the requirements document according to the functional points in the document. Each functional point can be stored separately in a text file named after that functional point, or the requirements document can be organized into a single requirements document text file according to the functional points.

[0084] Step 3: Semantic annotation of key variables.

[0085] First, input the target code text file generated in step 1 and the requirements document text file generated in step 2. Extract variable names, function names, etc., from the target code file and compile them into a list. Then, search for the variable names and their synonyms and near-synonyms in the requirements document, and add these as the variable's requirement descriptions to the list. Further, remove automatically generated intermediate variables that are not included in the requirements document from the list. Finally, convert the list containing key variables and their meanings (requirements descriptions) into a text file (in the form of variable name: meaning).

[0086] Step 4: Dynamically generate prompt words.

[0087] First, input the text files generated in steps 1, 2, and 3. Combine the code review task description, the above text files, and the model output requirements to generate prompt words for the large language model.

[0088] Step 5: Generative model review and result verification.

[0089] Input the prompt words generated in step 4 into the large language model and obtain its returned results. Analyze the key variables in the returned results and locate the problematic variables. Highlight the target modules corresponding to the variables in the Simulink model for manual review.

[0090] See Figure 5 This is a schematic diagram of the structure of a code review system provided in an embodiment of this application. Figure 5 As shown, the code review system 500 includes a client 510 and a server 520. The client 510 includes a code preprocessing module 511, a requirements analysis module 512, a semantic annotation module 513, and a prompt word generation module 514. The server 520 includes a large language model 521.

[0091] Specifically, the code preprocessing module 511 is used to perform... Figure 4 In step 1 of the illustrated embodiment, the requirements analysis module 512 is used to perform... Figure 4 Step 2 in the illustrated embodiment, semantic annotation module 513 is executed. Figure 4 Step 3 in the illustrated embodiment, prompt word generation module 514 is executed. Figure 4 In step 4 of the illustrated embodiment, the large language model 521 is used to perform code review based on the prompt words output in step 4 and output the code review results.

[0092] Corresponding to the above embodiments, this application also provides an electronic device.

[0093] See Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 6As shown, the electronic device 600 may include a processor 601, a memory 602, and a communication unit 603. These components communicate via one or more buses. Those skilled in the art will understand that the electronic device structure shown in the figures does not constitute a limitation on the embodiments of this application. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0094] The communication unit 603 is used to establish a communication channel, thereby enabling the electronic device to communicate with other devices.

[0095] The processor 601 serves as the control center of the electronic device, connecting various parts of the device via various interfaces and lines. It executes software programs and / or modules stored in the memory 602, and calls data stored in the memory to perform various functions and / or process data. The processor may be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 601 may consist only of a central processing unit (CPU). In this embodiment, the CPU may have a single processing core or include multiple processing cores.

[0096] Memory 602 is used to store the execution instructions of processor 601. Memory 602 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0097] When the execution instructions in memory 602 are executed by processor 601, the electronic device 600 is able to perform some or all of the steps in the above method embodiments.

[0098] Corresponding to the above embodiments, this application also provides a computer-readable storage medium, wherein the computer-readable storage medium may store a program, wherein when the program runs, it can control the device where the computer-readable storage medium is located to execute some or all of the steps in the above method embodiments. In specific implementation, the computer-readable storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0099] Corresponding to the above embodiments, this application also provides a computer program product containing executable instructions that, when executed on a computer, cause the computer to perform some or all of the steps in the above method embodiments.

[0100] In this application embodiment, "at least one" refers to one or more, and "more than one" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent the existence of A alone, the simultaneous existence of A and B, or the existence of B alone. A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects have an "or" relationship. "At least one of the following" and similar expressions refer to any combination of these items, including any combination of single or plural items. For example, at least one of a, b, and c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be single or multiple.

[0101] Those skilled in the art will recognize that the units and algorithm steps described in the embodiments disclosed herein can be implemented using electronic hardware, computer software, or a combination of electronic hardware and software. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0102] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0103] In the several embodiments provided in this application, any function, if implemented as a software functional unit and sold or used as an independent product, 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 a 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 USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0104] The above description is merely a specific embodiment of this application. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the protection scope of this application. The protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A code review method, characterized in that, include: Based on the requirements document, semantically annotate the variables in the target code and generate variable description documents; Based on the requirements document, the target code, and the variable description document, generate prompt words for the large language model; Input the prompt words from the large language model into the large language model to generate the review results of the target code.

2. The method according to claim 1, characterized in that, The target code is application-layer code that includes algorithmic logic.

3. The method according to claim 1, characterized in that, The step of semantically annotating variables in the target code based on the requirements document and generating variable description documents includes: The names of the variables in the target code are semantically matched with the requirements document to obtain the requirements description of the variables; Generate a variable description document based on the variable name and the variable requirement description.

4. The method according to claim 3, characterized in that, Also includes: If the requirement specification for the variable does not exist, then the variable shall be deleted from the variable specification document.

5. The method according to claim 3, characterized in that, The step of semantically matching the names of variables in the target code with the requirements document to obtain the requirement description of the variables includes: Map the names of variables in the target code and the requirement description fragments in the requirement document to a first vector representation and a second vector representation, respectively. Based on the comparison result between the vector representation distance and the preset distance, the requirement description of the variable is determined, wherein the vector representation distance is the distance between the first vector representation and the second vector representation.

6. The method according to claim 1, characterized in that, The step of generating prompt words for a large language model based on the requirements document, the target code, and the variable specification document includes: Based on the requirements document, the target code, the variable description document, and the code review rules, the prompt words for the large language model are generated.

7. The method according to claim 1, characterized in that, Also includes: The review results of the target code will be submitted for manual review.

8. An electronic device, characterized in that, include: processor; Memory; And a computer program, wherein the computer program is stored in the memory, and when the computer program is executed by the processor, causes the electronic device to perform the method of any one of claims 1 to 7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 7.

10. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method described in any one of claims 1 to 7.

Images