Code detection method and device, equipment and medium

Abstract

The invention relates to a code detection method and device, equipment and a medium in the technical field of computers, and the method comprises the steps that after a to-be-detected code is preprocessed, structured code information of each function in the obtained target to-be-detected code is extracted; constructing a detection prompt text based on the structured code information of all the functions and the target to-be-detected code so as to guide a large language model to judge whether a function exception exists in the target to-be-detected code or not; obtaining a judgment result information set corresponding to the output of the large language model guided by the detection prompt text for multiple times, and determining the total ratio of the results corresponding to the representation of the existence of the function exception in the judgment result information set; and when the ratio of the result to the total exceeds a first preset threshold value or does not exceed a second preset threshold value, correspondingly determining a target detection result representing that the function anomaly exists in the judgment result information set or a target detection result representing that the function anomaly does not exist in the judgment result information set, and the first preset threshold value is greater than the second preset threshold value. The code function can be efficiently and accurately detected.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, in particular to a code detection method and a corresponding device, computer equipment and computer readable storage medium. BACKGROUND

[0002] In the software development process, code quality is one of the key factors to ensure the stability and reliability of the application. With the continuous expansion of the code size and the increasing complexity of business logic, traditional manual code review or testing often fails to cover all potential defects, and is prone to omissions, which may cause serious failures or security incidents once exposed in the online environment. In the prior art, a common type of code detection method is mainly based on pre-defined rules for static analysis. This type of method usually scans the source code according to specific syntax rules, type constraints or coding specifications before compilation or code submission, and identifies code segments that do not meet the rules. The detection capability of this type of method is highly dependent on the pre-written rule library, and its detection range is usually limited to the syntax level or obvious surface defects, making it difficult to effectively identify the execution logic, resource leakage, complex condition boundaries and potential logic dead loops of the code. Therefore, in view of the deficiencies of the prior art, the present application takes a different approach to solve the problem of code detection. SUMMARY

[0003] The primary purpose of the present application is to solve at least one of the above problems and provide a code detection method and a corresponding device, computer equipment and computer readable storage medium.

[0004] To meet the various purposes of the present application, the present application adopts the following technical solutions: A code detection method provided to adapt to one of the purposes of the present application, comprising the following steps: After preprocessing the code to be detected, extracting the structured code information of each function in the target code to be detected obtained; Based on the structured code information of all functions and the target code to be detected, constructing a detection prompt text to guide the large language model to determine whether there is a function anomaly in the target code to be detected; Obtaining a set of judgment result information corresponding to the output of the large language model guided by the detection prompt text multiple times, and determining the proportion of the results representing the existence of function anomaly in the judgment result information set; When the proportion of the results exceeds a first preset threshold or does not exceed a second preset threshold, the target detection result representing the existence of function anomaly or the target detection result representing the non-existence of function anomaly in the judgment result information set is determined, and the first preset threshold is greater than the second preset threshold.

[0005] In another aspect, a code detection device is provided for one of the purposes of the present application, comprising an information extraction module, an anomaly judgment module, an anomaly proportion module, and a result determination module. The information extraction module is configured to extract structured code information of each function in a target code to be detected after preprocessing the code to be detected. The anomaly judgment module is configured to construct a detection prompt text based on the structured code information of all functions and the target code to be detected, to guide a large language model to determine whether there is a function anomaly in the target code to be detected. The anomaly proportion module is configured to obtain a set of judgment result information corresponding to the large language model output multiple times guided by the detection prompt text, and determine a total proportion of results representing the existence of a function anomaly in the set of judgment result information. The result determination module is configured to determine a target detection result representing the existence of a function anomaly or a target detection result representing the non-existence of a function anomaly in the set of judgment result information when the total proportion of results exceeds a first preset threshold or does not exceed a second preset threshold, wherein the first preset threshold is greater than the second preset threshold.

[0006] In yet another aspect, a computer device is provided for one of the purposes of the present application, comprising a central processing unit and a memory. The central processing unit is configured to invoke a computer program stored in the memory to execute the steps of the code detection method described in the present application.

[0007] In yet another aspect, a computer readable storage medium is provided for another purpose of the present application, which stores a computer program implemented according to the code detection method in the form of computer readable instructions. When the computer program is invoked and run by a computer, the steps included in the method are executed.

[0008] The technical solutions of the present application have multiple advantages, including but not limited to the following aspects: The present application first extracts the structured code information of each function in the code to be detected, and constructs a detection prompt text based on this and the complete code, which can guide the large language model to focus on the logical structure and functional context of the code, thereby overcoming the dependence on surface syntax or fixed rules, and effectively identifying deep function anomalies such as execution logic, complex condition boundaries, and potential resource management defects of the code, significantly improving the depth and coverage of code detection.

[0009] Secondly, the same detection prompt text is used multiple times to guide the large language model in making judgments, and the proportion of abnormal results is statistically analyzed. The final detection result is then determined by comparing a first preset threshold with a second preset threshold, cleverly utilizing the probabilistic output characteristics of the large language model. By integrating multiple inferences to mitigate the uncertainty of single judgments and setting decision threshold intervals to filter out ambiguous cases with insufficient confidence, the stability and reliability of the detection conclusions are effectively improved while fully leveraging the powerful semantic understanding capabilities of the large language model.

[0010] Furthermore, this application possesses excellent versatility and scalability. Its core relies on the general understanding of natural language instructions and code semantics by a large language model, rather than a pre-compiled, sophisticated rule base specific to a particular language or defect type. Therefore, it can adapt to different programming languages ​​and diverse anomaly detection needs. By adjusting or enriching the task descriptions and knowledge information in the prompt text, it can generalize to address new code quality challenges, reducing the maintenance costs and application limitations caused by the lagging rule base updates of traditional methods. Attached Figure Description

[0011] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein: Figure 1 This is a flowchart illustrating a typical embodiment of the code detection method of this application; Figure 2 This is a schematic block diagram of the code detection device of this application; Figure 3 This is a schematic diagram of the structure of a computer device used in this application. Detailed Implementation

[0012] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0013] Those skilled in the art will understand that, unless specifically stated otherwise, the singular forms “a,” “an,” “the,” and “the” used herein may also include the plural forms. It should be further understood that the term “comprising” as used in this application means the presence of the stated features, integers, steps, operations, elements, and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. It should be understood that when we say an element is “connected” or “coupled” to another element, it can be directly connected or coupled to the other element, or there may be intermediate elements. Furthermore, “connected” or “coupled” as used herein can include wireless connections or wireless coupling. The term “and / or” as used herein includes all or any units and all combinations of one or more associated listed items.

[0014] Those skilled in the art will understand that, unless otherwise defined, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. It should also be understood that terms such as those defined in general dictionaries should be understood to have the same meaning as in the context of the prior art, and should not be interpreted in an idealized or overly formal sense unless specifically defined as herein.

[0015] Those skilled in the art will understand that the terms "client," "terminal," and "terminal device" as used herein include both devices that receive wireless signals, devices that only possess wireless signal receiver capabilities without transmission capabilities, and devices with receiving and transmitting hardware, devices that have receiving and transmitting hardware capable of bidirectional communication over a bidirectional communication link. Such devices may include: cellular or other communication devices such as personal computers or tablets, having single-line displays, multi-line displays, or cellular or other communication devices without multi-line displays; PCS (Personal Communications Service) that can combine voice, data processing, fax, and / or data communication capabilities; PDAs (Personal Digital Assistants) that may include radio frequency receivers, pagers, internet / intranet access, web browsers, notebooks, calendars, and / or GPS (Global Positioning System) receivers; and conventional laptops and / or handheld computers or other devices that have and / or include radio frequency receivers. As used herein, "client," "terminal," and "terminal device" can be portable, transportable, installed in a means of transportation (air, sea, and / or land), or suitable and / or configured to operate locally and / or in a distributed manner, operating in any other location on Earth and / or in space. "Client," "terminal," and "terminal device" as used herein can also be a communication terminal, an internet access terminal, or a music / video playback terminal, such as a PDA, a MID (Mobile Internet Device), and / or a mobile phone with music / video playback capabilities, or a smart TV, set-top box, etc.

[0016] The hardware referred to by the names "server," "client," and "service node" in this application is essentially an electronic device with the equivalent capabilities of a personal computer. It is a hardware device with the necessary components revealed by the von Neumann architecture, such as a central processing unit (including an arithmetic logic unit and a control unit), memory, input devices, and output devices. The computer program is stored in its memory, and the central processing unit loads the program stored in the secondary storage into the main memory to run it, execute the instructions in the program, and interact with the input and output devices to complete specific functions.

[0017] It should be noted that the concept of "server" used in this application can also be extended to apply to server clusters. Based on network deployment principles as understood by those skilled in the art, the servers should be logically divided; physically, these servers can be independent yet accessible through interfaces, or they can be integrated into a single physical computer or a computer cluster. Those skilled in the art should understand this flexibility and should not use it to constrain the implementation of the network deployment method described in this application.

[0018] One or more of the technical features of this application, unless explicitly specified herein, can be deployed on a server and accessed by a client remotely calling the online service interface provided by the server, or can be directly deployed and run on a client for access.

[0019] Unless otherwise specified, all data involved in this application may be stored remotely on a server or on a local terminal device, as long as it is suitable for use by the technical solution of this application.

[0020] Those skilled in the art will understand that although the various methods in this application are described based on the same concept and thus present commonality among them, they can be performed independently unless otherwise specified. Similarly, the various embodiments disclosed in this application are all based on the same inventive concept; therefore, concepts expressed in the same way, as well as concepts that are appropriately changed for convenience but are expressed differently, should be understood equivalently.

[0021] Unless otherwise expressly stated, the various embodiments disclosed in this application can be combined in a cross-cutting manner to flexibly construct new embodiments, as long as such combination does not depart from the inventive spirit of this application and can meet the needs of the prior art or solve a certain deficiency in the prior art. Those skilled in the art should be aware of such modifications.

[0022] The code detection method of this application can be programmed into a computer program product and deployed on a client or server for execution. For example, in an exemplary application scenario of this application, it can be deployed on the server of an e-commerce platform. In this way, the method can be executed by human-computer interaction with the process of the computer program product through a graphical user interface by accessing the interface opened after the computer program product is run.

[0023] Please see Figure 1 The code detection method of this application, in its typical embodiment, includes the following steps: Step S1100: After preprocessing the code to be detected, extract the structured code information of each function in the target code to be detected; First, the code to be checked is tightly integrated with the development workflow, typically triggered by code submissions in the front-end's visual code editing interface. Specifically, the server responds to code submission events, automatically determining the presence of incremental code—that is, the code added or modified in this submission—by comparing the current submission with the previous submission (or a baseline version). If incremental code exists, the changed code files or code snippets are selected as the code to be checked in the current round. If no incremental code was generated in this submission, or if a full scan is manually triggered, all source code files of the current version of the entire project or the code of a specified module are selected as the code to be checked. In this way, the code to be checked is dynamically defined: in automated detection scenarios, priority is given to immediate and focused detection of incrementally changed code; when necessary, it can be extended to a comprehensive check of the entire project codebase. This ensures that the detection focus is efficiently concentrated on the latest modifications while not overlooking legacy issues.

[0024] It's understandable that the code to be tested often contains a lot of distracting information that isn't necessary for logical analysis, such as comment text and concrete literal constants. This information can distract the model and even lead to misunderstandings. More importantly, presenting the logical structure of the code to the model in a clear way makes it easier for the model to understand the code's intent and execution unit.

[0025] Therefore, preprocessing and structured extraction of the code to be analyzed is essentially a feature engineering approach for code analysis tasks, aiming to improve the information quality of the input model. In practice, preprocessing begins with automatically identifying the programming language type of the code file, such as Python, Java, C++, or JavaScript. Identification can be based on file extensions (e.g., .py, .java), specific syntax markers within the file, or a pre-trained classifier. After determining the language type, a parser corresponding to that language is invoked or used (e.g., the ast module for Python, and a parser generated by Eclipse JDT or ANTLR for Java) to perform syntax parsing on the code file. The purpose of parsing is not to execute the code, but to understand its abstract syntax tree structure. Based on this structure, the definition boundaries of all functions (or methods) in the code can be accurately identified, including named functions and anonymous functions (such as lambda expressions). For anonymous functions, a unique identifier with specific rules is automatically assigned as their temporary "function name" based on their order of appearance in the file or their context, such as "lambda_1" or "anonymous_func_2," to ensure that each code unit can be independently identified and referenced.

[0026] During the parsing process, code decluttering is also performed. This involves removing all commented lines and inline comments from the source code. Comments are natural language descriptions for developers, typically lacking executable logic, and their varied expressions can interfere with the model's understanding of the code itself. Furthermore, a key decluttering operation is "constant replacement." By traversing the source code, literal constants directly used within function bodies can be identified, such as numbers (e.g., 100, 0) and strings (e.g., "timeout"). These concrete constant values ​​may be important in specific code, but for general logical pattern recognition (e.g., determining the possibility of infinite loops or unreleased resources), their specific numerical value is not significant and may cause the model to overemphasize specific values ​​rather than logical structure. Therefore, these literal constants are replaced with generic placeholders, such as replacing the number 5 with the marker [NUMERIC_LITERAL] and the string "error" with [STRING_LITERAL]. This helps the model focus on operators, control flow structures (e.g., if, while), function calls, and variable relationships, thereby better generalizing the detection of logical defects. The code content obtained after deleting comments, formatting, and replacing constants is the rectified target code to be detected.

[0027] Based on the well-organized target code to be tested, the structured code information of each function is further extracted. Structured information refers to transforming the corresponding source code into a data object with clearly defined fields. For each identified function (including named functions and renamed anonymous functions), the following information units are extracted and organized, including but not limited to: the function name, i.e., the identifier declared in the function declaration or the assigned temporary identifier; the function body content, i.e., the complete internal code text of the function after the aforementioned regularization operations (deleting comments, formatting, and constant replacement); the input parameter set, i.e., the names of all formal parameters declared when the function is defined and their possible data type information (if the source code contains type annotations); and the output information, which may include the function's declared return type (if it exists), or the possible return behavior inferred through simple static analysis of the function body. All this information is encapsulated into a structured data object, such as a dictionary or JSON object, whose fields can be designed as {"function_name": "...", "cleaned_body": "...", "parameters":[...], "return_type": "..."}. Through the above operations, the large language model can simultaneously learn about the global environment (other functions and structures in the file) in which the detected function exists, as well as the detailed implementation of the function itself, thereby performing more accurate context-aware analysis.

[0028] Step S1200: Construct detection prompt text based on the structured code information of all functions and the target code to be detected, so as to guide the large language model to determine whether there is a function anomaly in the target code to be detected; Detection prompts provide explicit instructions and context for large language models, enabling them to analyze and judge specific code anomaly detection tasks. The generative reasoning behavior of large language models is guided by the input prompts. These specially crafted prompts guide the model to focus on detecting anomalies such as resource leaks, logical vulnerabilities, boundary conditions, or infinite loops. Therefore, it essentially transforms the code data to be detected and the detection task requirements into a language task that the model can understand and execute.

[0029] In practical implementation, the first step is to directly call the corresponding preset prompt template based on different anomaly detection types, including resource leaks, logical vulnerabilities, boundary conditions, or infinite loops, or to configure the corresponding prompt template in real time. Each prompt template is a structured text framework containing key components to guide the model in completing the detection task for the corresponding anomaly type. These components may include: descriptive text for the anomaly detection task, clearly informing the model what analysis needs to be performed; detection knowledge information related to this type of anomaly, which can include not only common patterns, definitions, typical code characteristics, or judgment logic of this type of code anomaly (this knowledge provides the model with professional domain background and judgment basis), but also relevant detection examples; and clear task instructions requiring the model to review the provided code. Furthermore, the components may also include explicit requirements for the model's output format, such as specifying that it must return the judgment result, cause analysis, and modification suggestions in a specific JSON structure, which ensures that subsequent steps can reliably parse the model output in a programmatic manner. Those skilled in the art can flexibly construct the prompt templates disclosed herein.

[0030] After obtaining the preset prompt template, the target code to be detected, along with the structured code information of all functions extracted from it, obtained in the previous steps, is embedded into the corresponding reserved position in the template. The target code to be detected refers to the entire code file content after preprocessing and normalization. It serves as the complete context for all functions within the file, providing the model with the overall code environment, external dependencies, and possible call relationships of the function being detected. The structured code information specifically indicates the function that needs to be examined. For example, for a function named `process_data`, the embedded prompt text would explicitly instruct the model: "Please judge the following function code in the file context code. The code to be judged is as follows: (Enter the normalized code of the `process_data` function here)."

[0031] The detection prompt text constructed in this way achieves an effective integration of tasks, knowledge, and data. It solves the problems of ambiguous intent and inconsistent judgment criteria caused by simply throwing a piece of code at the model and asking "Is there a problem with this code?" Clear detection knowledge information provides the model with a reference baseline for judgment, reducing the risk of "free-flowing" and hallucinations; the structured output format requirements ensure the consistency of the model's output, facilitating subsequent automated processing and decision-making. Therefore, this key technical step in adapting large language models to professional code white-box testing scenarios provides the model with the standardized input necessary for accurate and controllable analysis.

[0032] Step S1300: Obtain the judgment result information set corresponding to the output of the large language model after being guided multiple times by the detection prompt text, and determine the proportion of the results in the judgment result information set that represent the existence of function anomalies. To overcome the randomness and uncertainty that may exist in a single generation of a large language model, and thus improve the reliability and confidence of the final detection conclusion / result, a strategy of repeatedly and independently calling the large language model to perform statistical analysis on the output results is adopted.

[0033] In practice, the same pre-constructed detection prompt text is independently used as input to the large language model multiple times. "Multiple times" here refers to an integer greater than 1, such as 5 times in a typical implementation. Those skilled in the art can choose 3 times, 7 times, or other suitable numbers based on the trade-off between result stability and computational cost. The prompt text input each time is exactly the same—the detection prompt text. Due to the inherent probabilistic randomness of the large language model generation process, the model may produce slightly different outputs each time, even with the same input. Through multiple independent calls, a set of judgment results for the same code and the same detection task can be obtained, forming a judgment result information set.

[0034] Each element in the judgment result information set, i.e., the judgment result information of a single model output, is structured data generated according to the prompt text requirements. As mentioned earlier, the prompt template explicitly specifies that the output must be in a specific format, such as a JSON object. This JSON object contains fields used to characterize the detection conclusion. Specifically, the structured output can contain any number of the following fields: a boolean field has_defect (or a string field judgment, with a value of "indicates the existence of a function exception" or "indicates the absence of a function exception"), used to directly indicate whether the target function is considered to be exception-prone; a string field reason, used to explain the reason analysis for making this judgment; and an optional string field suggestion, used to provide repair suggestions. Therefore, each valid model call will return a structured object containing a clear judgment conclusion.

[0035] After obtaining a preset number of valid outputs (e.g., 5), this set of judgment results will be parsed and statistically analyzed. Statistical analysis refers to calculating the proportion of results indicating the presence of a function anomaly. Operationally, each element in the judgment result set can be traversed, parsing the key fields representing the conclusion in its structured data (e.g., reading the value of the `has_defect` field). If the value of this field is true (or corresponds to the semantics of "indicating the presence of a function anomaly"), this result is counted as one judgment of "considering an anomaly." Ultimately, the proportion of results is the number of outputs indicating an anomaly divided by the total number of valid outputs. For example, if the `has_defect` field is true in 4 out of 5 outputs, the proportion of results is 0.8 (or 80%).

[0036] As can be easily understood from the above, large language models, as generative models, do not output deterministic logical reasoning results, but are influenced by model parameters, decoding strategies, and random seeds. The result of a single query may be unreliable due to the model's "illusion" or accidental bias in its focus on the problem. By introducing a mechanism of multiple independent judgments and statistical analysis, a voting-based ensemble method is essentially adopted to improve robustness. This smooths out random errors in a single query, making the final conclusion more inclined towards the consensus reached through multiple judgments, thus significantly improving the credibility of automated detection results and providing a more robust data foundation for subsequent decision-making steps. Therefore, the key quality control and technical enhancement methods implemented to apply large language models to engineering analysis tasks requiring high reliability are crucial.

[0037] Step S1400: When the proportion of the result exceeds the first preset threshold or does not exceed the second preset threshold, the corresponding judgment result information set is determined to represent the target detection result with function abnormality or the target detection result without function abnormality, wherein the first preset threshold is greater than the second preset threshold.

[0038] After repeatedly calling the large language model and obtaining a set of judgment results, and calculating the proportion of results indicating functional anomalies, a final, definitive detection conclusion is made based on this proportion. In this process, by pre-setting a clear decision threshold, the statistical consensus presented by the model's multiple judgments is transformed into a clear "yes" or "no" binary judgment, thus completing the automated detection process.

[0039] The pre-set first and second preset thresholds directly correspond to and act on the two mutually exclusive directions in the aforementioned binary decision. Specifically, the first preset threshold is used to determine whether the proportion of results representing the presence of functional anomalies reaches the critical value of consensus required to conclude that functional anomalies exist; while the second preset threshold is used to determine whether the proportion of results representing the absence of functional anomalies reaches the critical value of consensus required to conclude that no anomalies exist. Since the determination of the presence and absence of anomalies in a single detection is mutually exclusive and complete, i.e., the sum of their proportions is always 1, the setting of these two thresholds is essentially a decision boundary set from two directions for the same statistic (i.e., the proportion of results in the result information set representing the presence of functional anomalies). When the proportion of the presence of anomalies exceeds the higher first preset threshold, it is equivalent to the proportion of results in the result information set representing the presence of functional anomalies being lower than (1 - the first preset threshold), at which point anomalies can be directly determined. When the proportion of results in the result information set representing the presence of functional anomalies does not exceed the lower second preset threshold (i.e., the proportion of results in the result information set representing the absence of functional anomalies exceeds 1 - the second preset threshold), no anomalies can also be directly determined.

[0040] The core technical principle of setting two unequal thresholds (first preset threshold > second preset threshold) lies in establishing a confidence interval for automated decision-making that includes three regions: a high-confidence region for the presence of function anomalies, a high-confidence region for the absence of function anomalies, and an uncertain region in between. This reflects a refined utilization of the model's judgment performance and a conscious management of decision-making risks. The motivation stems from the potential bias in the ability of large language models to detect different types of code function anomalies. For example, a model that has undergone specific training or fine-tuning may be highly sensitive to identifying certain resource leakage patterns (i.e., excessively high recall), making it more likely to output judgments of the presence of function anomalies, but these judgments may contain a certain proportion of false positives; conversely, the model is more conservative and accurate in identifying safe code logic (i.e., higher precision).

[0041] This can be achieved by asymmetrically adjusting two thresholds, meaning the sum of the two thresholds is not equal to 1. In practice, the thresholds can be calibrated and optimized based on the model's performance on the actual test set. Implementation methods can include the following examples: First, based on historical validation data, if the model is validated to have a high accuracy rate in judging the absence of function anomalies (i.e., a low false alarm rate), the second preset threshold for concluding that there are no function anomalies can be set relatively low (e.g., 0.2). This means that as long as the model considers the code to be free of function anomalies in more than 80% of its judgments, the conclusion of no function anomaly is confidently adopted. Simultaneously, to balance and control false negatives, the first preset threshold for concluding that there are function anomalies can be set relatively high (e.g., 0.8), requiring stronger consensus. Second, conversely, if the business scenario has extremely high requirements for capturing potential function anomalies (high recall priority), the first preset threshold can be appropriately lowered (e.g., 0.6) to better determine the presence of function anomalies; at the same time, the second preset threshold can be correspondingly increased (e.g., 0.4), raising the threshold for concluding that there are no function anomalies, thereby directing more boundary cases to the "uncertain" area for further review. Third, the threshold can also be designed as a dynamic parameter, which can be fine-tuned based on the importance of the detected code module, the historical distribution of the anomaly detection type, or the confidence score of the model's binary judgment.

[0042] Correspondingly, two thresholds can also be configured symmetrically. For example, in an embodiment with extremely high accuracy requirements, the first preset threshold can be set to 0.8, and the second preset threshold to 0.2. This means that a function anomaly is directly determined only when more than 80% of the model's judgments indicate its presence; and a function anomaly is directly determined only when more than 80% of the model's judgments indicate its absence (i.e., the proportion of results indicating a function anomaly is less than 20%). In another embodiment with higher recall requirements, the first preset threshold can be set to 0.6, and the second preset threshold to 0.4. This makes it easier to directly determine whether a function anomaly exists or not, and the uncertainty range is thus reduced. The specific values ​​of the thresholds can be configured as needed based on actual business requirements.

[0043] Finally, when the binary judgment is a clear "yes", the judgment result information set representing any judgment result information with functional anomaly, or the judgment result information with the highest inference confidence that the model believes has functional anomaly, is used as the target detection result; when the binary judgment is a clear "no", the judgment result information set representing any judgment result information without functional anomaly, or the judgment result information with the highest inference confidence that the model believes has functional anomaly, is used as the target detection result.

[0044] As can be seen from the typical embodiments of this application, the technical solution of this application has many advantages, including but not limited to the following aspects: This application first extracts the structured code information of each function in the code to be detected, and then constructs detection prompt text based on this information and the complete code. This guides the large language model to focus on the logical structure and functional context of the code, thereby going beyond the reliance on surface syntax or fixed rules. It enables the effective identification of deep function anomalies such as code execution logic, complex condition boundaries, and potential resource management defects, significantly improving the depth and coverage of code detection.

[0045] Secondly, the same detection prompt text is used multiple times to guide the large language model in making judgments, and the proportion of abnormal results is statistically analyzed. The final detection result is then determined by comparing a first preset threshold with a second preset threshold, cleverly utilizing the probabilistic output characteristics of the large language model. By integrating multiple inferences to mitigate the uncertainty of single judgments and setting decision threshold intervals to filter out ambiguous cases with insufficient confidence, the stability and reliability of the detection conclusions are effectively improved while fully leveraging the powerful semantic understanding capabilities of the large language model.

[0046] Furthermore, this application possesses excellent versatility and scalability. Its core relies on the general understanding of natural language instructions and code semantics by a large language model, rather than a pre-compiled, sophisticated rule base specific to a particular language or anomaly detection type. Therefore, it can adapt to different programming languages ​​and diverse anomaly detection needs. By adjusting or enriching the task description and knowledge information in the prompt text, it can generalize to address new code quality challenges, reducing the maintenance costs and application limitations caused by the lagging rule base updates of traditional methods.

[0047] In a further embodiment, step S1200, constructing detection prompt text based on the structured code information of all functions and the target code to be detected, includes the following steps: Step S1210: Obtain a preset prompt template associated with the anomaly detection type. The prompt template includes a description text and detection knowledge information corresponding to the anomaly detection task. Anomaly detection types specifically refer to the specific categories of code function anomalies that need to be identified, such as resource leaks, logical vulnerabilities, boundary conditions, or infinite loops.

[0048] A prompt template is a predefined, structured text framework whose core function is to transform abstract detection tasks into standardized instructions that a large language model can accurately understand and execute. The template contains at least two key components: first, descriptive text specific to the anomaly detection task, clearly defining the analytical work the model needs to perform; and second, detection knowledge information closely related to this type of anomaly.

[0049] The role of detection knowledge information is to provide the model with the domain background and logical basis required for execution judgment. Its content is not limited to the formal definition of the type of exception, the typical characteristic patterns manifested in the code (for example, resource leaks often manifest as opening files, database connections or network sockets without closing them in all paths), and the logical rules for judgment (for example, judging an infinite loop requires analyzing whether the loop condition may be always true or whether the loop variable has not been updated correctly in the loop body).

[0050] In addition, the detection knowledge information can also include positive and / or negative code examples to further enhance the model's understanding.

[0051] For ease of understanding, here's a sample example: For the "Resource Leak" warning template, the detection knowledge information section can be specifically described as follows: "Resource leak refers to the failure to properly release dynamically allocated resources such as memory, file handles, and network connections after use. Typical characteristics include: calls to allocation functions such as 'open', 'connect', and 'malloc', but missing corresponding release functions such as 'close', 'disconnect', and 'free' in certain conditional branches or exception handling paths. Judgment logic: Check whether the function calls for resource allocation and resource release appear in pairs on all possible execution paths, including normal return and exception throwing paths." One specific implementation of obtaining the preset prompt template is to directly load the template text corresponding to the selected anomaly detection type (such as "dead loop detection") from the configuration file of the client's local machine or a remotely accessible server.

[0052] It's easy to understand that directly submitting a piece of code to a large language model and vaguely asking if there are any problems will lead to unclear model intent and inconsistent judgment criteria, resulting in a large amount of irrelevant or erroneous output. By providing structured prompt templates rich in domain knowledge, we essentially set clear task boundaries and a professional analytical framework for the model, significantly reducing the risk of model "illusion" and enabling its output to focus on the specific anomaly detection types of interest. In other words, we have achieved the key technical preparation for successfully adapting a general-purpose large language model to professional code inspection scenarios.

[0053] Step S1220: Embed the structured code information of all functions and the target code to be detected into the prompt template to obtain the detection prompt text.

[0054] After obtaining the preset prompt template, the structured code information of all functions and the target code to be detected need to be embedded into the reserved positions in the template to obtain the final detection prompt text submitted to the large language model. The structured code information is the structured data about each function extracted from the regularized code in the previous steps. For a specific function to be detected, this information at least includes its function name and the regularized (e.g., removing comments, replacing constants) function body code. The target code to be detected refers to the entire regularized source code file content, providing the complete context of the function being detected. The embedding operation refers to identifying the preset placeholders or variable positions in the prompt template for inserting code content and filling them with the actual code content.

[0055] For ease of understanding, an illustrative example is provided, suggesting that the prompt template can contain placeholders such as "{global code context}" and "{function code to be detected}". In practice, the template string is parsed, replacing "{global code context}" with the target code to be detected and "{function code to be detected}" with the structured function body code extracted from the structured code information. This constrains the quality of code analysis by the large language model to be highly dependent on the contextual information it receives, rather than simply providing isolated function code. Otherwise, the model might be unable to make accurate judgments due to a lack of understanding of crucial contextual information such as global variables, external function calls, class structures, or program entry points. Conversely, providing only global code without specifying the specific analysis object prevents the model from focusing. Therefore, the embedding operation technically combines "global context" and "local focus": the target code to be detected provides the model with the necessary background to understand the function; while the embedded specific function code clearly indicates the core objective of this review. This ensures that the model can perform in-depth analysis of the specified function unit with a full understanding of the code environment, thereby significantly improving the accuracy and relevance of the detection. The final detection prompt text is a complete prompt that integrates task instructions, expertise, global context, and specific function code, which can be directly input into the large language model to start the analysis process.

[0056] In this embodiment, a centralized, standardized, and scalable domain knowledge hub is constructed by systematically collecting and structuring core knowledge entries (including definitions, features, and decision logic) for each anomaly detection type, and establishing a mapping relationship between anomaly types and knowledge entry sets stored in a searchable knowledge base. This ensures that authoritative and unified professional knowledge can be quickly and accurately extracted and injected from this knowledge base when constructing detection prompts for any specific anomaly type. Thus, a standardized domain prior and decision framework necessary for performing specialized code analysis is provided for the general-purpose large language model, fundamentally guaranteeing the high professionalism and consistency of the task instructions input to the model, and laying a solid foundation for generating reliable and interpretable detection conclusions.

[0057] In a further embodiment, step S2400, when the proportion of the result to the total does not exceed a first preset threshold or exceeds a second preset threshold, includes the following steps: Step S2410: Filter the target result information that represents the presence of function anomalies and the target detection results that represent the absence of function anomalies in the judgment result information set, and construct the corresponding posterior knowledge information to embed into the detection prompt text to obtain the re-inspection prompt text; When the information set of judgment results obtained from multiple prior model calls is statistically analyzed, if the proportion of results indicating the presence of function anomalies neither exceeds a higher first preset threshold nor falls below a lower second preset threshold, it indicates that the large language model has significant disagreements regarding the multiple judgments on whether the code contains function anomalies, and has failed to reach a high-confidence consensus. In this case, a supplementary and more guided analysis process is further executed to obtain a more definitive conclusion.

[0058] First, the results from the initial query are filtered. This set of results contains structured results from multiple independent queries, each with a clear conclusion field (e.g., "Function anomaly exists" or "Function anomaly does not exist") and a corresponding cause analysis field. In practice, based on the conclusion field, all results are divided into two subsets: one containing all results with the conclusion "Function anomaly exists," and the other containing all results with the conclusion "Function anomaly does not exist." Then, at least one representative result is selected from each subset. The selection can be random or based on certain rules, such as selecting the result with the most detailed or logically clear cause description. The representative result selected from the "Function anomaly exists" subset is denoted as the opinion supporting the existence of a function anomaly, and its cause analysis field is denoted as the function anomaly cause analysis; the representative result selected from the "Function anomaly does not exist" subset is denoted as the opinion supporting the non-function anomaly cause analysis, and its cause analysis field is denoted as the non-function anomaly cause analysis.

[0059] Next, based on the original detection prompt text used in the initial query, a new prompt text, namely the re-examination prompt text, is constructed. The construction method involves inserting, for example, a clear description of the aforementioned expert disagreement at the end of the original detection prompt text. Specifically, the existing task instructions, detection knowledge information, global code context, and the code of the function to be detected in the original detection prompt text are kept unchanged. A new paragraph is added that clearly states that there are different expert opinions regarding the code, and clearly cites the content of the function exception cause analysis and the non-function exception cause analysis respectively. For example, the new paragraph could be stated as: "There is a disagreement among existing experts: one opinion is that the code has a function exception, the reason being [function exception cause analysis here]; the other opinion is that the code does not have a function exception, the reason being [non-function exception cause analysis here]. Please act as the arbitrator, referring to both opinions, and give a final judgment." In this way, the re-examination prompt text provides the disagreement itself generated in the initial query as new and important contextual information to the large language model.

[0060] It's easy to understand that when a model produces inconsistent outputs based on basic information, it indicates that the case may be on the borderline or in a gray area of ​​judgment. In this situation, presenting the model with its own generated opposing reasoning paths (i.e., the reasons from both sides) guides it to act as a "reviewer" or "arbitrator," prompting it to compare, evaluate, and synthesize existing arguments, thereby engaging in deeper reasoning and potentially breaking the deadlock to reach a more consistent opinion. This is a key mechanism for improving the reliability of automated detection in handling complex cases.

[0061] Step S2420: Obtain the set of secondary judgment results corresponding to the output of the large language model after being guided multiple times by the re-examination prompt text, and determine the proportion of secondary judgment results in the set of secondary judgment results that represent the existence of function anomalies. Next, using the constructed re-examination prompt text as input, it is resubmitted to the large language model for multiple independent queries. Similar to the initial query, this process requires a preset number of independent calls, such as five queries. Each call uses the same re-examination prompt text. Upon receiving this enhanced prompt containing contradictory arguments, the large language model performs a new round of analysis and judgment, outputting structured results. All valid outputs from these preset number of queries are collected, forming a new result set called the second-order result information set. For each result in this second-order result information set, its conclusion field is parsed. Then, the number of results with the conclusion "function anomaly exists" is counted, and the proportion of this number to the total number of valid results in the second-order result information set is calculated, yielding the proportion of second-order results to the total. Thus, this process essentially quantifies and statistically analyzes the collective opinion of the model under the guidance of controversial information. The motivation is that even if opposing viewpoints are provided, the output of a single model may still be random. By querying and statistically analyzing multiple times, the new consensus tendency formed by the model group after absorbing controversial information can be assessed, thereby providing a basis for the final ruling based on statistical confidence.

[0062] Step S2430: Determine whether the proportion of the two judgment results exceeds the third preset threshold, and correspondingly determine whether the two judgment result information set represents the target detection result with function abnormality or the target detection result without function abnormality.

[0063] Finally, the calculated proportion of the two-stage decision results is compared with a pre-set third threshold, and a final judgment is made accordingly. In one embodiment, the third threshold is a decision threshold for secondary decision-making, typically set to 0.5, indicating adherence to the "simple majority" principle. The specific judgment rule is as follows: if the proportion of the two-stage decision results is greater than the third threshold, the target code is determined to have a function anomaly; in this case, a structured result with the conclusion "function anomaly exists" is selected from the two-stage decision result information set as the final target detection result output. The selection method can be random selection or selection of the most detailed cause analysis. Conversely, if the proportion of the two-stage decision results is not greater than the third threshold (i.e., less than or equal to), the target code is determined not to have a function anomaly; and a structured result with the conclusion "no function anomaly exists" is selected from the two-stage decision result information as the final target detection result output.

[0064] In this embodiment, the entire disagreement handling process is completed in a closed loop. During this process, the collective opinion formed after supplementing the context is transformed into a definite binary decision through a clear threshold. The necessity of setting a third preset threshold (e.g., 0.5; those skilled in the art can also set this threshold as needed with reference to the disclosure herein) lies in providing a clear and operable final decision rule, ensuring a clear conclusion is reached for all inputs, and avoiding infinite loops or indecisive situations. This entire process of "disagreement identification - information supplementation - revote - majority decision" significantly enhances the robustness and reliability of the code detection method based on large language models when handling cases with ambiguous boundaries and complex problems.

[0065] In a further embodiment, before step S1210, obtaining the preset prompt template associated with the anomaly detection type, the following steps are included: Step S2210: For each anomaly detection type, collect the knowledge entry set corresponding to the anomaly detection type. The knowledge entry set includes any one or more knowledge entries describing the definition, typical features, and judgment logic of the corresponding anomaly. For each type of code anomaly requiring automated detection, such as resource leaks, logical vulnerabilities, boundary conditions, or infinite loops, a systematic set of corresponding professional knowledge—a knowledge entry set—is collected. The purpose of constructing this knowledge entry set is to transform the tacit knowledge scattered throughout technical documents, specifications, and experience—which human experts rely on during code reviews—into explicit, structured information that can be understood and utilized by a large language model. Specifically, each knowledge entry set contains several descriptive knowledge entries, which cover, but are not limited to, the explicit definition of the corresponding anomaly type, typical characteristic patterns presented in the code, and rules for making logical judgments.

[0066] For ease of understanding, as an example, for the anomaly detection type of "resource leakage," the knowledge items collected may include: a definition item is "resources such as memory, file handles, and network connections dynamically allocated by the program are not properly released on all program execution paths after use"; typical characteristic items are "resource allocation functions such as open(), connect(), and malloc() are called in the code, but there are no matching release function calls such as close(), disconnect(), and free(), or the release calls exist in some branches but not all necessary branches"; and a judgment logic item is "through data flow or control flow analysis, check whether resource allocation operations and release operations appear in pairs on all possible program execution paths (including normal flow and exception handling flow).

[0067] The methods for collecting data are diverse. It can be extracted and summarized from publicly available programming style guides, code editing documents published by developers, and secure coding standards (such as CERT C++); it can also be analyzed and summarized from historical bug reports and code review records; or it can be compiled directly by domain experts based on their experience. To ensure the accuracy and representativeness of the knowledge, manual review and adaptation can be performed on the collected content when the information source is not entirely reliable, striving to cover the main manifestations of this type of anomaly in different programming languages ​​and common contexts.

[0068] Step S2211: Map and associate the knowledge entry set corresponding to each anomaly detection type to the retrieval knowledge base, which is used to construct the detection knowledge information in the prompt template associated with the anomaly detection type.

[0069] Subsequently, the collected and organized knowledge entries are mapped to their corresponding anomaly detection types, and stored in a structured format in a centralized retrieval knowledge base. Specifically, the storage structure can be designed as key-value pairs, with the anomaly detection type name (e.g., "DeadLoop") as the key and its corresponding knowledge entry set (a list of multiple text entries or a structured document) as the value. This retrieval knowledge base can be implemented as a relational database table, a collection in a document-oriented database (e.g., MongoDB), or an in-memory dictionary data structure; the key is to support fast retrieval based on type name. For example, when performing "dead loop" detection, all knowledge entries related to the definition, characteristics (e.g., loop condition always true, loop variable not updated within the loop body), and judgment logic of dead loops can be quickly retrieved by querying this knowledge base. These retrieved entries will be directly used as the core content of the detection knowledge information section in the subsequent construction of the detection prompt text.

[0070] In this embodiment, through this construction and storage process, scattered and unstructured expert knowledge is systematized and digitized, injecting domain-specific prior knowledge for specific code detection tasks into the general large language model. This enables it to follow a professional logical framework when performing analysis, thereby significantly improving the accuracy and reliability of detection. This is the key technical foundation for solving the problem of knowledge gaps in the application of large language models in professional fields.

[0071] In a further embodiment, before step S1200, which involves constructing the detection prompt text based on the structured code information of all functions and the target code to be detected, the following steps are included: Step S1000: Collect multiple historical detection prompt texts as samples, and label the historical target detection results of each sample as supervision labels; Historical detection prompt texts refer to instances of prompt texts accumulated before or during the implementation of this method and already used for actual code detection. Their construction follows the methods described in the preceding steps, including an anomaly detection task description, detection knowledge information, code context, and the code of the function to be detected. Sample sources include, but are not limited to: code snippets and their corresponding detection contexts extracted from historical code review records that have been confirmed to contain or not contain specific types of function anomalies; known function anomaly cases and their associated code collected from the commit history and issue tracking systems of open-source projects or internal enterprise projects; and code snippets that simulate and generate known function anomaly patterns and construct corresponding prompt texts. Each sample corresponds to a historical target detection result, which serves as a supervision label and is a known, verified conclusion, such as "resource leak exists" or "no infinite loop exists."

[0072] The labeling process involves associating each historical detection prompt text with its corresponding correct detection conclusion. In implementation, labels can be confirmed manually by developers or testers based on code review results or function exception fixing records; alternatively, the detection results of authoritative static analysis tools or code scanning tools can be used as reference labels, but they must be verified to ensure accuracy.

[0073] It's easy to understand that to improve the performance and relevance of general language models on specific code detection tasks, it's necessary to provide them with task-related supervision signals. While general language models possess broad code understanding capabilities, they haven't been specifically optimized for identifying specific function anomalies such as "resource leaks" and "infinite loops." By collecting detection prompts and their corresponding conclusions from real-world scenarios as training samples, we essentially construct a supervised learning dataset for code function anomaly detection. This provides necessary input-output pairs with clearly defined expected outputs for subsequent model fine-tuning. This is a crucial data preparation stage for adapting general models to specialized domain tasks. Its necessity lies in enabling the model to learn from historical detection experience, thereby making more accurate and consistent judgments when encountering similar code patterns in the future.

[0074] Step S1010: Associate all samples with their supervisory labels to form a dataset, and use the dataset to fine-tune the large language model until it converges.

[0075] All samples are associated with their supervision labels to form a dataset, which is then used to fine-tune the large language model until it converges. The dataset consists of all samples and their corresponding supervision labels collected in the preceding steps, typically organized as structured data pairs. Each data pair contains a corresponding historical detection prompt text (input) and a historical object detection result (expected output). Fine-tuning training refers to the supervised updating of the model parameters based on a pre-trained large language model using this dataset, adapting the model to a specific downstream detection task.

[0076] In practice, the dataset is first divided into training, validation, and test sets. The training set is used to directly update model parameters; the validation set is used to monitor model performance during training, prevent overfitting, and for hyperparameter tuning; the test set is used to finally evaluate the generalization ability of the fine-tuned model. The fine-tuning process typically employs gradient descent and its variants (such as the AdamW optimizer). Forward propagation calculates the model's output under the current sample prompt text, compares it with the supervision labels (usually converted to the form required by the model's output layer, such as the probability distribution of a specific token or matching embedding vectors), and calculates the loss function (such as cross-entropy loss). Then, backpropagation is used to calculate the gradient of the loss with respect to the model parameters, and the optimizer is used to update the parameters. This process iterates multiple times until the model's performance on the validation set stabilizes or reaches a preset stopping condition, i.e., convergence.

[0077] Specific implementation methods for parameter adjustment include, but are not limited to: full parameter fine-tuning, which updates all parameters of the model; and efficient parameter fine-tuning, such as LoRA (Low-Rank Adaptation), which updates only a small number of adapter parameters introduced into the model while keeping the original pre-trained parameters frozen.

[0078] It's easy to understand that the training objective of fine-tuning is to enable the model to, upon receiving a pre-constructed code detection hint text, generate an output with a probability distribution that corresponds as closely as possible to the correct detection conclusion. In other words, the model is trained to be more inclined to generate structured judgments consistent with historically validated conclusions. Furthermore, while pre-trained large language models possess general and broad knowledge and capabilities, without specialized training, they often lack stability and accuracy for tasks requiring precise judgment and expertise, such as determining whether "the code contains a specific logical function anomaly." Supervised fine-tuning using domain-specific datasets essentially involves targeted optimization within the model's parameter space, making its internal representation more focused on understanding and discriminating features and patterns related to code function anomalies.

[0079] This embodiment reveals the complete process of pre-fine-tuning and training a large language model to a convergent state. This significantly improves the model's professionalism, reliability, and output consistency on the white-box testing task described in this invention, and is a technical means to improve the detection accuracy and practicality of the entire solution. It helps solve the overall technical problem; specifically, the fine-tuned model becomes a specialized code function anomaly analysis engine, capable of more reliably executing multiple detection and judgment steps in subsequent steps, thereby more effectively identifying deep-seated problems such as resource leaks and logical vulnerabilities, reducing false negatives and false positives, and achieving the invention's objective of improving the lower limit of code quality.

[0080] In a further embodiment, the step S1400, or step S2430, after determining the target detection result where the characterization function is abnormal, includes the following steps: Step S2500: Map and bind the target detection result representing the function anomaly to the corresponding function source code in the target code to be detected; It's understandable that the target detection results output by the large language model can be constrained to structured text information containing, but not limited to, function names, exception types, cause analysis, and modification suggestions, while the code to be detected is a source code file composed of specific characters. These two exist at different levels of abstraction and must be mapped and bound to locate the abstract detection conclusion back to its source code location through mapping and binding operations. This provides developers with actionable feedback. In practice, the data structure of the target detection result can be constrained to include the identifier information of the function it targets, such as the function name. The mapping and binding process involves using the function name as a key index to search and match function definition nodes with the same name in the abstract syntax tree structure of the target code or in the parsed function list. Once a match is found, a reference link is established from the detection result instance to the start and end line numbers of the function definition in the source code, as well as its file path, forming a mapping and binding relationship.

[0081] For ease of understanding, as an example, if the detection results indicate that the function `calculate_total` has a resource leak, then the relevant information can be specifically recorded in the code database, including but not limited to: exception report ID-001 is bound to the function `calculate_total` on lines 45 to 62 of the file ` / src / order.py`.

[0082] It is easy to understand that the above implementation is to provide visual feedback for the subsequent process, ensuring that the problem indication can be accurately located, avoiding the workload of developers manually searching for the corresponding code segment, and is a necessary technical link to realize the closed loop of the automated detection process.

[0083] Step S2510: In the visual editing interface of the target code to be detected, the source code of the function is marked with differences based on the mapping binding relationship to highlight the target detection result.

[0084] To integrate the detection results intuitively and efficiently into the developers' coding environment, achieving a seamless transition from problem identification to problem remediation, the mapping and binding relationships established in the previous step are transformed into visual graphical interface elements by fully leveraging the user interface extension capabilities of integrated development environments (IDEs) or code editors. Specifically, the visual editing interface refers to the front-end interface used by developers to write and browse code. Based on the established mapping and binding relationships, the specific line number range of the source code of the function with the anomaly can be obtained within the file. Subsequently, the code within these lines is visually highlighted in the editing interface, i.e., difference highlighting. Specific implementation methods include, but are not limited to: adding a prominent warning icon or error mark in the gutter area next to the code line; setting the background color of the corresponding code line to a highlighted yellow or red; adding a colored wavy underline below the code text; and adding a new record to the problem panel or list in the editor's sidebar, which can be clicked to jump to the corresponding code line. For ease of understanding, as an example, when a developer opens a file containing the problematic function `calculate_total` in the aforementioned interface, the background of the code block containing the function is highlighted in light yellow, and a red exclamation mark icon appears on the left. When the mouse hovers over the icon, a tooltip will display the anomaly type and cause summary in the target detection results.

[0085] In this embodiment, by directly converting the results of automated static analysis into the most prominent and easily operable signals in the developer's perception interface, the path from discovering a problem to locating the problematic code is greatly shortened, and the repair efficiency is improved. This is a user interaction design that enhances the practicality and efficiency of the entire white-box testing method.

[0086] In a further embodiment, after step S2510 performs differential annotation on the function source code based on the mapping binding relationship in the visual editing interface of the target code to be detected, so as to highlight the target detection result, the following steps are included: Step S2511: In response to the user adoption event of the target detection result, map and bind the anomaly detection type and modification suggestion in the target detection result to the structured code information of the corresponding function in the target code to be detected, and obtain a sample example; User adoption events refer to the explicit actions taken by developers in the visual editing interface to confirm the validity of detection results and decide to adopt them. These actions include, but are not limited to, clicking the "Confirm Issue" button or selecting the "Apply Fix" option on the interface. This allows human feedback to be used as a high-quality supervisory signal, transforming validated detection cases into reusable knowledge assets for the system, thereby continuously optimizing detection accuracy.

[0087] It's understandable that the initial detection results of a large language model, even after ensemble voting and threshold filtering, may still contain biases or uncovered code patterns. Developer adoption behavior provides accurate labels for real-world scenarios, which can be directly used to enhance professional capabilities. In practice, user adoption events are captured through an event listening mechanism, such as binding a button click event handler in a graphical user interface. Once an event is triggered, the corresponding target detection result is retrieved from the event context. This result is stored in structured data, including an anomaly detection type field and a modification suggestion field. Simultaneously, based on the previously established mapping and binding relationship, the structured code information database generated during the code parsing phase is queried using the function name or a unique identifier as the key. The structured code information of the function corresponding to the detection result is retrieved, including the function name, the rectified function body content, the input parameter list, and the output information. Then, the anomaly detection type and modification suggestion are associated and combined with the retrieved structured code information to construct a new data object as a sample example.

[0088] Once a sample example is obtained, it represents a manually verified piece of labeled data that can be directly used for subsequent model training or knowledge base expansion. Specific implementation methods include, but are not limited to: fine-tuning the model by formatting it as input-output pairs, where the input is a prompt text constructed based on structured code information and anomaly types, and the output is text containing suggested modifications; if the user edits the sample example upon adopting the modification suggestions, the final edited content is recorded to learn more accurate expert knowledge. Thus, the large language model can learn more reliable and trustworthy detection knowledge.

[0089] Step S2512: Store the sample example in the detection knowledge base to construct the detection knowledge information in the prompt template associated with the anomaly detection type.

[0090] The detection knowledge base can be a persistent database used to centrally manage expertise in code anomaly detection. It can also dynamically update suggestion templates by accumulating verified cases, thereby improving the accuracy and adaptability of large language models in subsequent detections. This enables the self-evolution of code detection, allowing the knowledge base to continuously enrich itself based on user feedback, covering a wider range of anomaly patterns and related detection knowledge.

[0091] It's easy to understand that a statically initialized knowledge base may not be able to handle emerging programming practices or complex boundary situations, while a persistent storage mechanism based on user adoption ensures that detection knowledge is iterated in real time to maintain long-term effectiveness. In practice, sample examples are written into the detection knowledge base, which can be implemented in relational databases or document databases. The stored procedure first parses and classifies the sample examples, assigning them to the corresponding category based on their anomaly detection type field. For example, all sample examples identified as "infinite loop" are stored under the "infinite loop" category.

[0092] In one embodiment, content that can be used to construct detection knowledge information can be extracted from sample examples, including but not limited to: summarizing typical error patterns, judgment rules, or remediation strategies from modification suggestions and structured code information, and converting this content into text descriptions or structured rule entries. In specific implementations, this content can be summarized using a natural language processing model.

[0093] The entries in the detection knowledge base are organized in a searchable format, with each entry containing an ID, type, descriptive text, and a reference to the source sample. Then, when constructing the detection prompt template, based on the anomaly detection type specified for the current detection task, all relevant entries under that type are retrieved from the detection knowledge base. The contents of these entries are then concatenated or summarized and embedded into the reserved space for detection knowledge information in the prompt template. In this way, the large language model receives guidance that incorporates the latest and most comprehensive practical knowledge when analyzing code, improving the reliability of its judgments.

[0094] In another embodiment, the detection knowledge base can also support similarity retrieval. When a new detection task arrives, based on the code similarity and the anomaly detection type required by the task, the corresponding sample example that matches the type and has a high similarity is recalled from the library. This sample example is then directly inserted as a case into the reserved position of the retrieval knowledge information in the prompt template, and together with the corresponding knowledge entry therein, it serves as the information.

[0095] Furthermore, the detection knowledge base can be designed to support version management to track the history of entries being added or deleted. Sample examples can also be stored with attached metadata such as timestamps, user IDs, and project contexts to evaluate entry weights (preferably for embedding prompt templates) or to filter outdated knowledge.

[0096] In this embodiment, by transforming the code anomalies and corresponding repair suggestions confirmed by user adoption events into structured sample examples and persistently storing them in the detection knowledge base, the programmatic capture and accumulation of domain expert knowledge is achieved. This not only allows manual verification results to be fed back as high-quality supervisory data to the model training process, but also dynamically enriches and updates the background knowledge base upon which various anomaly detections rely. This enables the subsequently constructed detection prompt text to incorporate judgment logic and repair examples derived from real-world scenarios and tested in practice, thereby guiding the large language model to make more accurate and practically aligned professional judgments, forming a self-evolving "detection-feedback-optimization" closed loop. This significantly improves the adaptability, accuracy, and practical value of the entire detection system in long-term applications.

[0097] Please see Figure 2 This document describes a code detection device provided to meet one of the purposes of this application. It is a functional embodiment of the code detection method of this application. The device includes an information extraction module 1100, an anomaly judgment module 1200, an anomaly proportion module 1300, and a result determination module 1400. The information extraction module 1100 is used to extract the structured code information of each function in the target code to be detected after preprocessing the code. The anomaly judgment module 1200 is used to construct detection prompt text based on the structured code information of all functions and the target code to be detected, guiding a large language model to determine whether there are function anomalies in the target code to be detected. The anomaly proportion module 1300 is used to obtain the corresponding judgment result information set output by the large language model after multiple guidance from the detection prompt text, and determine the proportion of results in the judgment result information set that represent the presence of function anomalies. The result determination module 1400 is used to determine the target detection result in the judgment result information set that represents the presence of function anomalies or the absence of function anomalies when the proportion of results exceeds a first preset threshold or does not exceed a second preset threshold, wherein the first preset threshold is greater than the second preset threshold.

[0098] In a further embodiment, the anomaly judgment module 1200 includes: a template acquisition submodule, used to acquire a preset prompt template associated with anomaly detection type, the prompt template including descriptive text and detection knowledge information corresponding to the anomaly detection task; and a prompt construction submodule, used to embed the structured code information of all functions and the target code to be detected into the prompt template to obtain detection prompt text.

[0099] In a further embodiment, after the anomaly proportion module 1300, the module includes: a re-examination preparation submodule, used to filter target result information representing the presence of function anomalies and target detection results representing the absence of function anomalies in the judgment result information set, and construct corresponding posterior knowledge information to embed into the detection prompt text to obtain a re-examination prompt text; an anomaly proportion submodule, used to obtain the corresponding set of secondary judgment result information output by the large language model after being guided multiple times by the re-examination prompt text, and determine the proportion of secondary judgment results representing the presence of function anomalies in the secondary judgment result information set; and a result determination submodule, used to determine whether the proportion of secondary judgment results exceeds a third preset threshold, and correspondingly determine the target detection results representing the presence of function anomalies or the target detection results representing the absence of function anomalies in the secondary judgment result information set.

[0100] In a further embodiment, before the template acquisition submodule, there is a knowledge acquisition submodule, used to acquire a set of knowledge entries corresponding to each anomaly detection type, the set of knowledge entries including any one or more descriptions of the definition, typical features and judgment logic of the corresponding anomaly; and a first knowledge storage submodule, used to store the set of knowledge entries corresponding to each anomaly detection type in a retrieval knowledge base, for constructing the detection knowledge information in the prompt template associated with the anomaly detection type.

[0101] In a further embodiment, before the anomaly judgment module 1200, there are: a training preparation submodule, used to collect multiple historical detection prompt texts as samples, and label the historical target detection results of each sample as supervision labels; and a model training submodule, used to associate all samples with their supervision labels to form a dataset, and use the dataset to fine-tune the large language model to a convergent state.

[0102] In a further embodiment, the result determination module 1400 or the result determination submodule includes: a source code binding submodule, used to map and bind the target detection result representing the existence of function anomalies to the corresponding function source code in the target code to be detected; and an explicit annotation submodule, used to perform differential explicit annotation on the function source code in the visual editing interface of the target code to be detected based on the mapping and binding relationship, so as to highlight the target detection result.

[0103] In a further embodiment, after the explicit annotation submodule, there is an event response submodule, used to respond to the user adoption event of the target detection result, and map the anomaly detection type and modification suggestion in the target detection result to the structured code information of the corresponding function in the target code to be detected, to obtain a sample example; and a second knowledge storage submodule, used to store the sample example in the detection knowledge base, and to construct the detection knowledge information in the prompt template associated with the anomaly detection type.

[0104] To address the aforementioned technical problems, embodiments of this application also provide computer equipment. For example... Figure 3 The diagram shows the internal structure of a computer device. The computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected via a system bus. The computer-readable storage medium stores an operating system, data, and computer-readable instructions. The data may store a sequence of control information. When the computer-readable instructions are executed by the processor, they enable the processor to implement a code detection method. The processor of the computer device provides computing and control capabilities, supporting the operation of the entire computer device. The memory of the computer device may store computer-readable instructions. When these computer-readable instructions are executed by the processor, they enable the processor to execute the code detection method of this application. The network interface of the computer device is used for communication with a terminal. Those skilled in the art will understand that… Figure 3 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.

[0105] In this embodiment, the processor is used to execute... Figure 2 The specific functions of each module and its submodules are defined within the system. The memory stores the program code and various data required to execute the aforementioned modules or submodules. The network interface is used for data transmission between the user terminal and the server. In this embodiment, the memory stores the program code and data required by the code detection device of this application to execute all modules / submodules. The server can call the server's program code and data to execute the functions of all submodules.

[0106] This application also provides a storage medium storing computer-readable instructions, which, when executed by one or more processors, cause the one or more processors to perform the steps of the code detection method of any embodiment of this application.

[0107] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. The aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM).

[0108] In summary, this application can efficiently and accurately detect code functions.

[0109] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those disclosed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

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

Claims

1. A code detection method, characterized in that, Includes the following steps: After preprocessing the code to be detected, the structured code information of each function in the target code to be detected is extracted; Based on the structured code information of all functions and the target code to be detected, a detection prompt text is constructed to guide the large language model to determine whether there are function anomalies in the target code to be detected; Obtain the set of judgment results information corresponding to the output of the large language model after being guided multiple times by the detection prompt text, and determine the proportion of the total results in the judgment result information set that represent the existence of function anomalies; When the proportion of the results exceeds the first preset threshold or does not exceed the second preset threshold, the corresponding judgment result information set is determined to represent the target detection result with functional abnormality or the target detection result without functional abnormality, wherein the first preset threshold is greater than the second preset threshold.

2. The code detection method according to claim 1, characterized in that, The detection prompt text is constructed based on the structured code information of all functions and the target code to be detected, including the following steps: Obtain a preset prompt template associated with the anomaly detection type. The prompt template includes a description text and detection knowledge information corresponding to the anomaly detection task. The structured code information of all functions and the target code to be detected are embedded into the prompt template to obtain the detection prompt text.

3. The code detection method according to claim 1, characterized in that, When the percentage of the result in the total does not exceed a first preset threshold or exceeds a second preset threshold, the following steps are included: The target result information representing the presence of function anomalies and the target detection results representing the absence of function anomalies are filtered from the judgment result information set, and corresponding posterior knowledge information is constructed and embedded into the detection prompt text to obtain the re-inspection prompt text; Obtain the set of secondary judgment results corresponding to the output of the large language model after being guided multiple times by the re-examination prompt text, and determine the proportion of secondary judgment results in the set of secondary judgment results that represent function anomalies. If the proportion of the two judgment results exceeds a third preset threshold, the two judgment result information set is determined to represent either the target detection result with functional anomalies or the target detection result without functional anomalies.

4. The code detection method according to claim 1, characterized in that, Before obtaining the preset prompt template associated with the anomaly detection type, the following steps are included: For each anomaly detection type, a knowledge entry set corresponding to the anomaly detection type is collected. The knowledge entry set includes any one or more knowledge entries describing the definition, typical features, and judgment logic of the corresponding anomaly. Each anomaly detection type is mapped and associated with a corresponding set of knowledge entries, which are stored in the retrieval knowledge base to construct the detection knowledge information in the prompt template associated with the anomaly detection type.

5. The code detection method according to claim 1, characterized in that, Before constructing the detection prompt text based on the structured code information of all functions and the target code to be detected, the following steps are included: Multiple historical detection prompt texts were collected as samples, and the historical target detection results of each sample were labeled as supervision labels; All samples are associated with their supervisory labels to form a dataset, and the large language model is fine-tuned and trained to convergence using the dataset.

6. The code detection method according to any one of claims 1 to 5, characterized in that, After determining the target detection results where the representation exhibits functional anomalies, the following steps are included: The target detection results representing the functional anomalies are mapped and bound to the corresponding function source code in the target's code to be detected. In the visual editing interface of the target code to be detected, the source code of the function is marked with differences based on the mapping and binding relationship to highlight the target detection results.

7. The code detection method according to claim 6, characterized in that, In the visual editing interface of the target code to be detected, after highlighting the target detection results by annotating the function source code based on the mapping binding relationship, the following steps are included: In response to the user adoption event of the target detection result, the abnormal detection type and modification suggestion in the target detection result are mapped and bound to the structured code information of the corresponding function in the target code to be detected, so as to obtain a sample example; The sample examples are stored in the detection knowledge base to construct the detection knowledge information in the prompt template associated with the anomaly detection type.

8. A code detection device, characterized in that, include: The information extraction module is used to extract the structured code information of each function in the target code to be detected after preprocessing the code to be detected. The anomaly detection module is used to construct detection prompt text based on the structured code information of all functions and the target code to be detected, so as to guide the large language model to determine whether there are function anomalies in the target code to be detected; The anomaly percentage module is used to obtain the corresponding judgment result information set output by the large language model after being guided multiple times by the detection prompt text, and to determine the proportion of the total results in the judgment result information set that represent the existence of function anomalies. The result determination module is used to determine the target detection result that represents a function abnormality or the target detection result that does not have a function abnormality when the proportion of the result exceeds a first preset threshold or does not exceed a second preset threshold. The first preset threshold is greater than the second preset threshold.

9. A computer device comprising a central processing unit and a memory, characterized in that, The central processing unit is used to invoke and run a computer program stored in the memory to perform the steps of the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores, in the form of computer-readable instructions, a computer program implemented according to any one of claims 1 to 7, which, when invoked by a computer, executes the steps included in the corresponding method.

Images