Code detection method and system, computing device, storage medium and program product

Abstract

The invention provides a code detection method and system, computing equipment, a storage medium and a program product, and is applied to a code detection system, the code detection system comprises a code management tool and a detection agent, and the method comprises the following steps: calling the code management tool to monitor a code submission event, and when the code submission event is monitored, sending the code submission event to a server; submission information of a to-be-detected code corresponding to the code submission event is obtained; identifying the event type of the code submission event, and determining a target prompt template based on the event type; and constructing a target prompt word based on the submission information and the target prompt template, calling a detection agent, executing a code detection task based on the target prompt word, and obtaining a detection result for the to-be-detected code. The problems that manual examination efficiency is low and research and development resources are occupied are effectively solved, the overall code examination efficiency and quality are improved, and the method can be widely applied to the fields of digital culture product manufacturing software, digital culture creative software and the like in a new generation of information technology.

Description

Technical Field

[0001] This specification relates to the field of software technology for creating digital cultural products, and in particular to a code detection method. This specification also relates to a code detection system, a computing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] In the field of digital cultural product creation software technology within next-generation information technology, during the research and development and implementation of software projects, the source code submitted by the development team typically undergoes rigorous code review to ensure the stable operation and correct functional implementation of the software system. With the continuous evolution of software development, the frequency of code submissions has increased dramatically. However, existing code review models primarily rely on manual review, where experienced personnel examine and analyze the submitted code line by line based on their understanding and experience. The review results are significantly affected by the varying technical levels and experience of the reviewers, leading to difficulties in standardizing review criteria and significant quality fluctuations. In large or continuously iterating projects with frequent code submissions, manual review consumes substantial R&D and management resources, reducing overall work efficiency. Therefore, there is an urgent need for a method that can automatically and intelligently perform targeted, on-demand checks on submitted code during project execution to address these issues. Summary of the Invention

[0003] In view of this, embodiments of this specification provide a code detection method to address the technical deficiencies existing in the prior art. Embodiments of this specification also provide a code detection system, a computing device, a computer-readable storage medium, and a computer program product.

[0004] According to a first aspect of the embodiments of this specification, a code detection method is provided, comprising:

[0005] Obtain the task attribute features of the task to be processed and the code detection features of each processing set, wherein the processing set includes at least one processing end, and the code detection features characterize the information of the task processed by the processing end.

[0006] The task attribute features are matched with the code detection features of each processing set to determine the target processing set;

[0007] Based on the performance metrics of each processing terminal in the target processing set and the performance requirements of the task to be processed, the task to be processed is assigned to the target processing terminal for processing.

[0008] According to a second aspect of the embodiments of this specification, a code detection system is provided, comprising:

[0009] The acquisition module is configured to acquire the task attribute features of the task to be processed and the code detection features of each processing set, wherein the processing set includes at least one processing end, and the code detection features characterize the information of the task processed by the processing end.

[0010] The determination module is configured to match the task attribute features with the code detection features of each processing set to determine the target processing set;

[0011] The allocation module is configured to allocate the task to be processed to the target processing terminal for processing based on the performance indicators of each processing terminal in the target processing set and the performance requirements information for the task to be processed.

[0012] According to a third aspect of the embodiments of this specification, a computing device is provided, including a memory and a processor;

[0013] The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions. When the computer programs / instructions are executed by the processor, they implement a code detection method.

[0014] According to a fourth aspect of the embodiments of this specification, a computer-readable storage medium is provided that stores a computer program / instructions, which, when executed by a processor, implement a code detection method.

[0015] According to a fifth aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement a code detection method.

[0016] The code inspection method provided in this manual automatically monitors and responds to code submission events through code management tools, effectively solving the problems of low efficiency and high resource consumption associated with manual review. When a code submission event is triggered, the code management tool acquires the submission information and invokes a detection agent for automated inspection, providing immediate and objective feedback at the moment of submission. This significantly shortens the feedback cycle and greatly improves the timeliness and accuracy of code quality issue detection. By identifying the event type of code submission and matching it with corresponding target prompt templates, differentiated and customized inspections are achieved for different types of code submission events. This unifies the inspection standards, eliminates quality fluctuations caused by differences in the technical skills of reviewers, and improves the overall efficiency and quality of code review. It can be widely applied in fields such as digital cultural product creation software in next-generation information technology. Attached Figure Description

[0017] Figure 1 A flowchart of a code detection method provided in one embodiment of this specification is shown;

[0018] Figure 2 This specification illustrates a schematic diagram of a detection agent detecting a code development task for an AI review function, according to an embodiment of this specification.

[0019] Figure 3 This specification shows a flowchart illustrating the specific process of filtering and hierarchically parsing Diff information according to an embodiment of the present specification;

[0020] Figure 4 This specification illustrates a schematic diagram of the specific process of hierarchical parsing and obtaining an updated front-end and back-end abstract syntax tree according to an embodiment of this specification.

[0021] Figure 5 This diagram illustrates an interface diagram of a detection report display interface applied to a task management system according to an embodiment of this specification;

[0022] Figure 6 This specification illustrates a flowchart of an embodiment of an artificial intelligence intelligent analysis that generates a code detection report and issues an early warning notification;

[0023] Figure 7 This diagram illustrates a visual interface of a notification example on a collaborative communication tool, specifically an embodiment of the code detection method provided in this specification.

[0024] Figure 8 This specification shows a visual interface diagram of a submission record in a task management system provided in one embodiment of the present specification;

[0025] Figure 9 This specification shows a schematic diagram of the structure of a code detection system according to an embodiment of the present specification;

[0026] Figure 10 A structural block diagram of a computing device provided in one embodiment of this specification is shown. Detailed Implementation

[0027] Many specific details are set forth in the following description to provide a full understanding of this specification. However, this specification can be implemented in many other ways than those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this specification. Therefore, this specification is not limited to the specific implementations disclosed below.

[0028] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “described,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification refers to and includes any or all possible combinations of one or more associated listed items.

[0029] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this specification, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."

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

[0031] First, the terminology used in one or more embodiments of the present invention will be explained:

[0032] Git (Distributed Version Control System): Used to track changes to files (especially source code) during the development process.

[0033] GitHub (a distributed version control system code management repository) is an online code hosting platform based on the Git version control system, mainly used for version control and collaborative work in software development projects.

[0034] SVN (Apache Subversion, a centralized version control system) is an open-source, centralized version control system used to manage and track the change history of files and directories. In SVN, the version history of all project files is centrally stored on a single central server. Users check out code from the server through a client and need an internet connection to commit updates and obtain the latest version.

[0035] JavaParser (Java code parsing library) is an open-source Java library used for parsing, analyzing, and manipulating Java source code. It provides a rich set of interfaces that allow developers to programmatically read, modify, or generate abstract syntax trees (ASTs) of Java code, and is widely used in code analysis, refactoring, code generation, and tool development.

[0036] Abstract Syntax Tree (AST): An abstract tree-like data structure that represents the syntactic structure of source code. It expresses the syntactic rules of code in a hierarchical tree structure, ignoring specific syntactic details such as parentheses and semicolons, and retaining only the core logical structure such as operators, operands, and control flow. It is the core intermediate representation form of compilers, interpreters, and code analysis tools.

[0037] Babel is an open-source JavaScript compiler used to convert JavaScript code written using the latest ECMAScript standards (such as ES6 and ES7) into backward-compatible code, enabling it to run in older browsers or environments that do not yet support the new features. Babel offers high extensibility through plugins and presets, supporting syntax transformation, feature auto-completion, and code transformation, making it a core component of modern front-end development toolchains.

[0038] Babel Parser (formerly babylon): is the JavaScript parser in the Babel toolchain, used to convert JavaScript source code into a specification-compliant abstract syntax tree.

[0039] Regular expressions (regex or regexp, a string matching language) are a special text format used to describe patterns in character sequences. They are primarily used for searching, matching, replacing, and validating strings. By defining matching patterns through specific syntax rules, they enable efficient processing and analysis of text.

[0040] This specification also relates to a code detection system, a computing device, a computer-readable storage medium, and a computer program product, which are described in detail in the following embodiments.

[0041] In the field of digital cultural product creation software technology within next-generation information technology, to ensure the stable operation and correct functional implementation of software systems, the source code submitted by R&D teams typically undergoes rigorous code review. With the continuous evolution of software development, the frequency of code submissions has increased dramatically. However, existing code review models primarily rely on manual review, where experienced personnel examine and analyze the submitted code line by line based on their understanding and experience. To address the resource waste and inefficiency of manual code review in next-generation digital cultural product creation software, an automated code detection system is needed. This system requires a management tool capable of collecting and managing all code and related information to be detected, as well as a detection tool capable of performing task detection on the code under various scenarios. Based on this concept, this specification provides an embodiment of a code detection method applied to a code detection system. The code detection system includes a code management tool and a detection agent. Figure 1 The flowchart of the code detection method is shown, which includes the following steps.

[0042] Step 102: Call the code management tool to monitor code commit events. If a code commit event is detected, obtain the commit information of the code to be monitored corresponding to the code commit event.

[0043] Code management tools refer to platforms or systems used to coordinate and manage source code version control during software development. These tools typically include hook mechanisms to trigger custom scripts. Code management tools listen for code commit events and capture information about the committed code, as well as other information related to or characterizing the commit event (such as commit time, committer or committing end, code summary provided by the code developer or development end, etc.). For example, code management tools can be version control systems like Git or SVN, or their hosting platforms such as GitHub or GitLab. Hooks include client-side hooks or server-side hooks, used to automatically trigger preset operations when specific events (such as code commits or merge requests) occur.

[0044] A detection agent is an artificial intelligence model or automated program that performs code detection tasks based on the detection methods required for code submission events. The detection agent is used to automatically detect submitted code for quality, security, and compliance issues, and generates detection results containing findings and suggestions. For example, the detection agent can be a large language model, a dedicated static code analysis engine, or a hybrid system combining rule bases and AI analysis. For example, code management tools provide an API (Application Programming Interface) for calling the detection agent; accordingly, the code management tool can use this interface to call the detection agent to perform code detection.

[0045] A code commit event consists of one or more actions, including the code commit itself and specific actions indicating that code changes have been formally recorded or proposed for inclusion in the repository. Code commit events are the starting point for triggering subsequent automated code review processes. For example, this event can be a local or remote repository update event triggered by the `git commit` or `git push` commands, or an event generated when a merge request or pull request is created on a code hosting platform.

[0046] The code to be inspected refers to the specific set of code content that needs to be automatically inspected, triggered by a code commit event. This code can be newly written code or updated code that updates existing code. It is the direct object of analysis by the inspection agent. For example, the code to be inspected can be the changed code obtained by comparing version differences, it can be all or part of the code from the initial version of an application, or it can be a complete snapshot of all files involved in this commit after the commit.

[0047] Commit information refers to a set of information associated with a specific code commit event, describing the background, content, and context of the commit. Commit information provides the detection agent with crucial context for understanding the intent and background of code changes. For example, the commit information includes, but is not limited to, a hash value uniquely identifying the commit, the identity information of the person performing the commit, the time the commit occurred, log messages written by the developer describing the purpose of the code changes, and a list of files modified, added, or deleted in this commit.

[0048] In one implementation of this specification, the code management tool is Git (a distributed version control system), and a client hook is configured. When a developer executes the Git commit command in the local repository and successfully creates a commit, the hook is triggered, detecting the code commit event. The hook script then works to obtain the hash identifier of this commit, the commit log message, and the corresponding code change differences, using these as commit information and the code to be detected, to initiate the subsequent detection process.

[0049] In one implementation of this specification, the code management tool is GitHub (a code hosting platform), and the GitHub App (GitHub application) is used to listen for "Pull Request" events in repositories. When a new pull request is created, a code commit event is triggered. The GitHub App receives this event push and then obtains detailed information about the pull request through the platform API (Application Programming Interface), including the request title, description, associated code differences, and comment information. This information is used as the commit information and the code to be detected to build the detection context and is then passed to the detection agent.

[0050] In one implementation of this manual, the code management tool is SVN (Subversion, a centralized version control system), and a hook script is configured in the SVN server repository. When a developer successfully commits code to the server repository using the `svn commit` command, the hook script is automatically triggered to detect the code commit event. The hook script then executes, parsing the revision number of this commit and using SVN commands (such as `svn diff` and `svn log`) to obtain the commit log information, committer, commit timestamp, and code changes (i.e., diff information). This information is used as the commit information and the code to be checked to initiate the subsequent automated code inspection process.

[0051] By monitoring code commit events and obtaining commit information of the code to be inspected, code commit events can be linked to automated code inspection, providing a data foundation for subsequent code inspection operations.

[0052] Step 104: Identify the event type of the code submission event and determine the target prompt template based on the event type;

[0053] Event type refers to a category identifier that classifies the attributes or purpose of a code commit event. Event type is used to distinguish different types of code commit behaviors, and it determines the focus and strategy of subsequent code inspection. Event type can include code change commit type and new code commit type. For example, in the field of software development, event type can be the type of code commit event corresponding to the development of a new feature for a certain function of a certain software, the type of code commit event corresponding to the bug fix, the type of code commit event corresponding to the hotfix, the type of code commit event corresponding to the refactoring, the type of code commit event corresponding to the security patch, etc.

[0054] A prompt template is a predefined text framework that contains specific detection instructions, context, and constraints. It serves as a structured input framework providing task guidance and background knowledge to the detection agent. For example, a prompt template for a defect repair event might focus on instructions regarding the completeness of the code logic patching and whether new regression test cases have been introduced; while a template for new feature development might emphasize the code structure design, scalability, and unit test coverage.

[0055] The target prompt template refers to the prompt template selected from multiple predefined prompt templates based on the identified specific event type, which is most suitable for guiding the detection agent to analyze the current code submission event.

[0056] In one implementation of this specification, a pre-defined mapping relationship between event types and prompt templates is established. For example, the event type "Hotfix" is mapped to a prompt template related to hotfixes, and the event type "Feature Development" is mapped to a prompt template corresponding to feature development. When a code commit event is identified as having the event type "Hotfix," the system directly determines the corresponding target prompt template based on this mapping relationship. The preset detection instructions in this template emphasize checking the accuracy of code modifications, assessing the impact on upstream and downstream processes, and basic testing requirements in emergency situations.

[0057] In one implementation of this specification, the event type is identified by parsing the commit information (such as the commit message) in the code commit event. For example, a commit message starting with "fix:" or "bugfix:" is identified as a "Bug Fix" type; one starting with "feat:" is identified as a "Feature Development" type. After identifying the event type, the system selects the corresponding target prompt template according to preset matching rules. For example, if identified as a "Bug Fix" type, a prompt template focusing on root cause analysis, minimizing the scope of patching, and updating related test cases is selected as the target prompt template.

[0058] By identifying submission intent and dynamically adapting detection strategies, the relevance, efficiency, and usability of the entire automated code detection process are improved.

[0059] Step 106: Construct target prompt words based on the submission information and target prompt template, and call the detection agent to perform code detection tasks based on the target prompt words to obtain detection results for the code to be detected.

[0060] Target prompts refer to complete and executable instruction text ultimately submitted to the detection agent, generated by filling or integrating specific submission information into reserved positions in the target prompt template. Target prompts provide the detection agent with task input containing a specific detection context, the code content to be detected, and explicit detection requirements. For example, target prompts may include code style identification instructions, such as code style examples obtained from a code style knowledge base; risk identification instructions, such as a specific code content as a risk example; and checklist output instructions, such as specific checklist examples indicating specific formats and content.

[0061] Executing a code inspection task refers to the process by which an intelligent inspection agent receives and parses target prompts, understands their instructions, and then analyzes, reasons about, and evaluates the code to be inspected specified in the target prompts. This process aims to discover potential quality defects, security vulnerabilities, specification violations, compliance with requirements, possible implementation deviations, and potential risks in the code.

[0062] The detection result refers to the structured or unstructured information output by the detection agent after completing the code detection task, containing its analysis findings and conclusions. The detection result is used to provide feedback on code quality to developers or the system. For example, the detection result may be a list of defects described in natural language, a report including the location and severity level of the problems, or a judgment on whether the detection passed.

[0063] In one implementation of this specification, the target prompt template is a text containing placeholders, such as, "Please check the commit log for..."<commit_message> The code changes (differences are as follows)<code_diff> The system will conduct a focused analysis to check whether it is dedicated to fixing the claimed issues and has not introduced irrelevant modifications or new security risks. The system will then populate the relevant commit logs and code difference details into...<commit_message> and<code_diff> The placeholders are used to construct a complete and specific target prompt word. Then, the configured large language model is invoked as the detection agent, using this target prompt word as input. After analysis, the detection agent returns a textual detection result, indicating potential logical incompleteness or side effects of the code modifications.

[0064] Figure 2 This specification illustrates a schematic diagram of a detection agent for a code development task related to an AI review function, as provided in one embodiment of the specification. Figure 2As shown, the AI ​​review summary includes a summary of the submission content and code suggestions. The submission content summary is an overview of the event of this code submission, including analysis of the submitted code, what functions were added or implemented, what fixes were made, and what effects were achieved. The code suggestions are specific recommendations for the code that needs improvement, including the corresponding line number, the principles violated, and suggested modifications. In one implementation of this specification, the target prompt template is a text containing placeholders, such as, "Please review the submission log for..."<commit_summary> The code changes were analyzed in detail, examining the rationality of the newly added AI code review function and identifying any violations of coding principles. The system will then populate the specific commit log content (e.g., "This commit mainly added the AI ​​code review function, including adding an AI code review project configuration item to the configuration class DevsimpleConfig, integrating AI code review logic into BaseWorkItemCommittedListener and its subclasses, adding entity classes, DAOs, service interfaces, and implementation classes, and fixing the issue of inconsistent return type in the associateToRelease method") into the...<commit_summary> The placeholders are used to construct a complete and specific target prompt word. Then, the configured large language model is invoked as the detection agent, using this target prompt word as input. After the detection agent performs analysis, it returns a text-based detection result, pointing out specific problems in the code changes, such as the failure to synchronize the caller after adjusting the method return type in BaseWorkItemCommittedListener, which may lead to logical errors; the improper use of System.out.println instead of the logging framework in AiCodeReviewService; and manually obtaining Beans in BaseWorkItemCommittedListener, which violates the dependency injection mechanism. Corresponding modification suggestions are also provided.

[0065] In one implementation of this specification, the target hint template is a structured JSON object that defines fields such as inspection type ("inspection_type"), rule set ("rule_set"), and context information ("context"), with some field values ​​being variables to be populated. The system populates the corresponding variable positions in the template with submission information (such as a list of files and the submitter), constructing a structured target hint. Then, a dedicated static code security analysis tool is invoked as the detection agent, and this JSON-formatted target hint is passed to the tool via API. The detection agent performs a scan according to the instructions in the hint, ultimately generating a standardized report containing vulnerability details, severity level, and line number as the detection result.

[0066] The code inspection method provided in this manual automatically monitors and responds to code submission events through code management tools, effectively solving the problems of low efficiency and high resource consumption associated with manual review. When a code submission event is triggered, the code management tool acquires the submission information and invokes a detection agent for automated inspection, providing immediate and objective feedback at the moment of submission. This significantly shortens the feedback cycle and greatly improves the timeliness and accuracy of code quality issue detection. By identifying the event type of code submission and matching it with corresponding target prompt templates, differentiated and customized inspections are achieved for different types of code submission events. This unifies the inspection standards, eliminates quality fluctuations caused by differences in the technical skills of reviewers, and improves the overall efficiency and quality of code review. It can be widely applied in fields such as digital cultural product creation software in next-generation information technology.

[0067] However, existing code inspection methods are independent of development task requirements, resulting in the inability to verify whether the code accurately implements the original requirements, creating a blind spot in functional consistency verification. An optional implementation of this specification provides a method to solve the above problem by associating task requirements with the code to be inspected. This method includes the following steps performed before step 102:

[0068] Receive code development tasks sent by the requester, wherein the code development tasks include task information;

[0069] The code development task is sent to the code development end so that the code development end can execute the code development task based on the task information.

[0070] The demand side refers to the party or system that requests code development tasks. For example, the demand side can be a project management tool, a product requirement management platform, a module in a customer service ticket system that generates technical requirements, or even another AI system that automatically generates development requirements.

[0071] A code development task refers to a specific work unit initiated by the requester and required to be completed by the code developer. For example, a code development task can be a specific defect fix order in a defect management system, a user story card in an agile development Kanban board, or a security upgrade task automatically triggered in a continuous integration pipeline due to the detection of dependency library updates.

[0072] Task information refers to a structured or unstructured data set that identifies a code development task and describes its goals, requirements, background, and constraints in detail. Task information defines the final state the code development needs to achieve and the rules it should follow, and includes the task's identifier, providing verification basis and context for subsequent code inspection. For example, task information may include functional requirements documents, interface design documents, user interface prototypes, test case lists, performance metrics (such as response time <100ms), and non-functional requirements (such as compatibility requirements and security level requirements), and includes the task number, submission version number, and other identifiers for the code development task.

[0073] The code development end refers to the party or system that actually executes code writing and submission. For example, the code development end can be an integrated development environment used by developers, a development team collaboration platform, a low-code / no-code development platform, or an AI programming assistant that automatically generates code after receiving advanced instructions.

[0074] In one implementation of this specification, the demand side is a task management system, and the code inspection system receives code development tasks sent by the task management system through configured hooks. This task information includes the task title "Payment Interface Optimization," a detailed description "Adjust the payment timeout from 30 seconds to 60 seconds and add a retry mechanism," acceptance criteria "Must pass the payment success rate test case set," and priority "High." After parsing the task, the code inspection system formats the task information and sends it to the designated payment business development team (code development side) through the enterprise's internal communication tool interface, designating developer Zhang San as the task leader.

[0075] In one implementation of this specification, the requesting side is an internal AI task generation system, and the code inspection system receives code development tasks automatically generated by the system. Task information is transmitted in JSON (JavaScript Object Notation) format, including the task type "Security Vulnerability Repair," the vulnerability description "Fix Spring Framework Deserialization Vulnerability CVE-2023-20860," the target version "v2.1.3," a link to a reference remediation solution, and the urgency level "Urgent." Upon receiving the task information, the code inspection system converts it into a standard work order format, creates a corresponding development task work order in the code repository of the specified project through the corresponding interface, and automatically assigns it to the security development team or the corresponding AI programming assistant (code development side).

[0076] When the code development end receives a code development task from the request end and submits a code submission event based on this task, the code content contained in this event is related to the code development task; that is, the implementation result of the code content needs to meet the relevant requirements in the task information of the code development task. An optional implementation of this specification provides a method that can associate task information with the code to be detected, enabling the detection agent to detect the code to be detected based on the task information, thereby achieving the detection of whether the code meets the requirements of the corresponding code development task. Correspondingly, step 102 includes:

[0077] The code management tool is invoked to monitor code submission events of the code development end for the code development task. When a code submission event is detected, the submission information of the code to be detected corresponding to the code submission event is obtained. Based on the submission information and the task information, the code to be detected is associated with the code development task.

[0078] Association refers to establishing a traceable link between the code to be inspected and its corresponding code development task at the data level. For example, association operations can be performed by embedding the task tracking number (such as "Refs#JIRA-123") in the commit message, creating a feature branch with the same name as the task number in the code repository (such as feature / JIRA-123), or by bidirectionally binding the commit hash with the task ID in the task management system (such as the task management system) via API.

[0079] In one implementation of this specification, when developer Zhang San develops code based on this task, a feature branch for that code development task is created. After development is completed, Zhang San creates a merge request and explicitly marks the GEP task number of the code development task in the commit message. The code inspection system detects the merge request event through hooks, obtains the commit information, and automatically associates this code commit with the original development task in the task management system by parsing the task number in the commit information.

[0080] In one implementation of this specification, the security development team creates a remediation branch based on this work order. When the team completes the remediation and pushes the code to the GitLab repository, the code inspection system monitors the code push event and obtains the commit information. The system automatically establishes an association between the code and the security task using the work order number in the branch name, and performs targeted security checks in subsequent inspections by combining the vulnerability description and reference solution in the task information to ensure the correctness and completeness of the remediation solution.

[0081] The method provided in this manual improves the quality of detection by associating code submissions with code development tasks, enabling targeted analysis based on original requirements.

[0082] However, existing code inspection methods typically only output code-level quality issues (such as syntax errors and security vulnerabilities). For changes involving databases, configurations, or interfaces, they lack automated identification and guidance for necessary subsequent operations (such as executing scripts or updating configurations). This forces developers to manually extract relevant operation items from code changes, easily overlooking critical steps and leading to inconsistencies or functional abnormalities after deployment. An optional implementation process in this specification provides a method to address these issues, specifically including the following steps:

[0083] Identify the detection results, and if the detection results involve a specified type, generate a detection list. The specified type includes at least one of database script execution, configuration file update, and interface change. Accordingly, the detection list includes at least one of the script files to be executed, configuration parameter modification points, and interface adjustment items.

[0084] The specified type refers to the specific change category that needs to be specially identified and handled in the code inspection results. These changes not only involve the code logic itself, but may also have a direct impact on the application's runtime environment, dependent services, or data persistence layer. Therefore, it is necessary to generate clear guidelines for subsequent operations. For example, specified types include database script execution, configuration file updates, and interface changes.

[0085] Database script execution refers to script changes that need to be executed on the application database. Examples include Data Definition Language operations such as CREATE TABLE (create a table) and ALTER TABLE (modify the table structure); Data Manipulation Language operations; or the creation and updating of stored procedures and functions. These changes require ensuring that the scripts are executed in the correct order in the target environment.

[0086] Configuration file updates refer to modifications to the contents of configuration files that the application depends on at runtime. Examples include changing the server port number (server.port) in application.yml, updating third-party API endpoint addresses in config.properties, and adjusting the output level in the logging framework's logback.xml. Such changes must be correctly synchronized across different environments (development, testing, and production).

[0087] Interface changes refer to modifications to the application programming interfaces (APIs) that an application provides or depends on. Examples include changes to the API path (e.g., from / api / v1 / user to / api / v2 / user), additions, deletions, or modifications to request parameters or response body structures (e.g., adding new fields), API deprecation flags, or version updates to API contracts. Such changes require coordination with service callers and updates to documentation.

[0088] A checklist is a structured task list automatically generated by the system based on identified changes of a specified type. It includes specific operation items, execution order, and precautions. Its purpose is to seamlessly integrate code changes with operational deployments, providing clear operational guidelines and avoiding omissions from manual review. For example, a checklist may include executable script files, configuration parameter modifications, and interface adjustments.

[0089] The script files to be executed list the paths to the SQL (Structured Query Language) script files that need to be executed on the target database in a specific order (e.g., sql / migrations / 20240520_001_add_index.sql), and may include execution prerequisite checks (e.g., requiring the database version number) and post-execution verification statements (e.g., checking whether the index was created successfully).

[0090] The configuration parameter modification points clearly list the key-value pairs that need to be modified in different environment configuration files (e.g., in application-test.yml, change the value of cache.enabled from false to true), and may prompt whether the modification requires restarting the service or if there are any dependent configurations.

[0091] The interface adjustment details list the operations required due to the interface change, such as updating the routing configuration of the interface gateway; notifying all caller teams about the interface path change and the documentation link for the corresponding toolset for the new version; adding annotations to the old interface in the code and planning the decommissioning time.

[0092] In one implementation of this specification, the detection agent, while analyzing the code, identifies that the submission contains a database migration script (db / migrations / V002__add_user_table.sql), which is used to create a new user table. The detection results mark this change as "database script execution". The system then generates a checklist, which explicitly states that "the following scripts must be executed sequentially on the test environment database: 1. V001__init.sql 2. V002__add_user_table.sql", and includes the complete path and verification code of the scripts.

[0093] In one implementation of this specification, the detection agent discovers that the code has modified the configuration file (application-prod.yml) of the corresponding application development framework (such as the Spring Boot framework), updating the data source connection address from the old address to the new address. The detection result identifies this as a "configuration file update" type. The system automatically generates a detection checklist, listing the configuration parameters that need to be modified.

[0094] The `spring.datasource.url` in the production environment configuration file `application-prod.yml`.

[0095] The parameters need to be changed, specifically as follows:

[0096] The command "jdbc:mysql: / / old-db:3306 / app" has been updated to "jdbc:mysql: / / new-db:3306 / app", and a message has been displayed stating "The application service needs to be restarted after modification".

[0097] The method provided in this manual automatically generates a checklist containing specific operational items by identifying specific change types in the detection results. This organically combines code changes with operation and maintenance operations, effectively reducing the risk of environment configuration errors caused by human oversights, improving the completeness and reliability of change implementation, and realizing closed-loop management from code detection to deployment guidance.

[0098] In existing code inspection methods, for code submitted for the first time (such as new features or services), only routine code quality or security scans are typically performed. However, initial submissions often involve the initial linkage between front-end and back-end modules, and existing methods lack the ability to automatically analyze the relationships between them. This prevents the system from establishing a call mapping between front-end pages and back-end interfaces, making subsequent detection of interface changes or feature integration tests lack accurate contextual basis and hindering the effective identification of architectural issues such as mismatched front-end and back-end calls and missing interfaces. This specification provides an optional implementation method to address the above problems, specifically including the following steps:

[0099] When the event type of the code submission event is the first submission, a full scan of the front-end and back-end code is performed to obtain the association between the front-end module and the back-end interface, as well as the interface information of the back-end interface.

[0100] The first commit refers to the first commit operation that brings code into the version control system for a specific code development task. The first commit could be the first version of an application. For example, the first commit could be the first commit of a new feature branch, the initial commit of a completely new microservice module, or the initial commit of a major refactoring task. A key characteristic of the first commit is that it does not modify existing code files.

[0101] A full scan refers to a complete, non-incremental analysis of all code files included in the current commit. Unlike simply analyzing code differences, a full scan aims to establish a complete code structure graph. For example, a full scan parses all front-end routing files and back-end controller classes to construct complete call relationships; in one implementation of this specification, a full scan may involve traversing the front-end and back-end code files and outputting their abstract syntax structure trees.

[0102] A relationship refers to the call and being called relationship between a front-end user interface module and a back-end application programming interface. For example, a relationship can be specifically described as "the front-end user management page (e.g., UserManagement.vue) calls the back-end user query interface (e.g., GET / api / v1 / users)" and "the user creation form calls the user addition interface (e.g., POST / api / v1 / user)". For example, relationships can be recorded in the form of a mapping table or a JSON file (JavaScript Object Notation).

[0103] Interface information refers to a collection of detailed information used to precisely define the backend interface. For example, interface information includes the interface's request method (e.g., GET / POST / PUT / DELETE), the complete URL path (e.g., / api / v1 / orders / {id}), the list of request parameters (including name, type, and whether they are required), the data structure of the response body, and a functional description of the interface.

[0104] In one implementation of this specification, a new development task corresponds to the first code commit. After identifying the event type as "first commit," a full scan is initiated. The scanner analyzes all front-end view components and simultaneously analyzes the back-end controller, discovering the target interface defined by the back-end control layer. The system then establishes a relationship: "front-end components depend on back-end target interfaces," and records detailed information about the interface (such as string-type path parameters). This relationship and interface information are persistently stored as a benchmark for detecting the impact of interface changes during subsequent iterations of this feature.

[0105] In one implementation of this specification, the front-end and back-end code are scanned to generate abstract syntax tree structures for each, representing their syntactic structures. The code structure is represented as a tree, with each node representing a component (such as a class, method, annotation, etc.). By traversing the abstract syntax tree structures of the front-end and back-end code, a JSON-formatted interface file is obtained to record the relationships between the front-end modules and back-end interfaces, as well as the interface information of the back-end interfaces.

[0106] The method described in this manual automatically constructs a complete relationship graph between front-end modules and back-end interfaces by initiating a full scan upon initial submission, and extracts precise interface contract information. This provides authoritative benchmark data for subsequent iterative development, analysis of the impact of interface changes, and front-end / back-end integration testing.

[0107] Existing methods for parsing front-end code typically stop at syntax checking or dependency scanning, lacking the ability to accurately identify and extract specific back-end service call points within the front-end code. This specification provides an optional implementation method for scanning front-end code to lay the foundation for subsequently establishing a mapping relationship between front-end page elements and back-end application programming interfaces, specifically including the following steps:

[0108] For the front-end code in the front-end and back-end code, the front-end code is parsed to obtain the parsing results;

[0109] Based on the parsing results, identify the front-end modules that use function calls in the front-end code;

[0110] Based on the calling function, the calling information of the front-end module calling the back-end interface is obtained, and based on the calling information, the association between the front-end module and the back-end interface is constructed.

[0111] Parsing refers to the process of performing lexical and syntactic analysis on front-end code to understand its structural semantics. For example, parsing can involve using code parsing tools to convert code into a tree-like data structure, such as an abstract syntax tree, for programmatic analysis.

[0112] A function call refers to a specific function or method in the front-end code used to initiate a network request to invoke a back-end service. For example, a function call can be a built-in application programming interface (API) for initiating a network request or a related method provided by a third-party request library.

[0113] A front-end module refers to a relatively independent functional unit in front-end code that has a specific user interface and interaction logic. For example, a front-end module can be a single-file component, a functional component, or a component defined by a specific framework.

[0114] Invocation information refers to the specific parameter information extracted from the calling function of the front-end code, which describes how to invoke the back-end interface. For example, invocation information includes, but is not limited to, the request method of the called interface, the interface path, the request header information, and the parameter variables passed to the calling function.

[0115] Parsing the front-end code and obtaining the parsing results means using appropriate scripts or tools to traverse and analyze the specific resource files involved in the front-end code, and generate structured data that can represent the relationships and syntactic structure of each statement in the front-end code. For example, the parsing result is the aforementioned structured data. By analyzing the relationships and syntactic structure of each code statement in the parsing result, the position and relationship of the calling function related to the API call can be determined within the entire front-end code set. This allows us to identify the front-end module that uses the calling function and its API call information.

[0116] In one implementation of this specification, the Babel Parser (a JavaScript code parser) is used to perform a full scan and parsing of all source code files in the front-end project (including but not limited to .js, .ts, .vue, .jsx, .tsx, etc.). First, the project directory structure is traversed to locate all target files. Then, each file is parsed, and the script portion is extracted to generate a JavaScript AST (Abstract Syntax Tree). This AST structure is then traversed to identify Call Expression nodes. When a function is detected as an axios function (a Promise-based HTTP library), the system sequentially extracts the interface method type (e.g., GET, POST, etc.), URL (Uniform Resource Locator, i.e., interface address), request parameters (including query parameters and request body data), and code location information (file path, line number, and column number). Finally, the extracted complete call information is stored in a structured mapping table, establishing a precise association between the front-end module and the back-end interface. The method provided in this manual achieves accurate extraction and structured storage of interface call relationships by automatically parsing network request calls in the front-end code, providing a reliable data foundation for subsequent code inspection.

[0117] In one implementation of this specification, a combination of regular expression matching and static text analysis is used to extract interface call information from the front-end code. First, all source code files in the front-end project are traversed, and preset regular expressions are used, such as:

[0118] / axios\.(get|post|put|delete)\(['"]([^'"]+)['"] / g)

[0119] The system scans the file content and directly matches the call statements of the network request library. When a match is detected, the system extracts the interface method type (such as get, post), URL string (such as / api / v1 / users), and its code location (file path, line number) from the matching result. Finally, the extracted information is structured and stored in a mapping table.

[0120] The method provided in this manual, through in-depth analysis of the front-end code, locates the calling functions and extracts the calling information, thereby realizing the automated and accurate construction of the association between the front-end module and the back-end interface. This provides a reliable data foundation for subsequent analysis of the impact of interface changes and improves the detection accuracy.

[0121] This specification provides an optional implementation method for scanning backend code to lay the foundation for establishing a complete relationship between the frontend and backend code, specifically including the following steps:

[0122] For the backend code in the frontend and backend code, the control layer of the backend code is parsed to obtain the interface information of the backend interface, and the call relationship of each code layer of the backend code is parsed to obtain the call relationship of each code layer, and the call relationship is recorded.

[0123] The controller layer refers to the code component layer in the backend code architecture responsible for receiving external requests, coordinating business processing, and returning responses. For example, the controller layer can be a class marked with a specific annotation (such as a class annotated with `@RestController` in the Spring framework) or its methods (such as methods annotated with `@GetMapping`).

[0124] Interface information refers to a collection of detailed information used to precisely define the backend interface contract. For example, interface information includes the interface's request method (such as HTTP methods like GET and POST), the complete URL path pattern (such as / api / v1 / users / {id}), request parameter constraints (such as parameter types and whether they are required), and a description of the response data structure.

[0125] Each code layer refers to a different logical layer in the backend code, divided according to the principle of separation of responsibilities. For example, each code layer may include a control layer, a business logic layer (service layer), a data persistence layer (data access layer), etc.

[0126] The call relationship refers to the method call dependency chain between modules at different levels or within the same level in the backend code. For example, the call relationship can be specifically described as "the getUser method of UserController in the controller layer calls the queryUser method of UserService in the service layer".

[0127] Parsing the control layer of backend code refers to using appropriate parsing tools or scripts to systematically traverse and analyze various source code files involved in the backend project, generating structured data that can represent the code hierarchy, module dependencies, and syntactic features. For example, the code hierarchy includes the interface layer, business logic layer, and data layer. This process yields parsable data in a format that displays the call chain and architectural hierarchy between code elements. With this structured data, the position and relationships of methods related to data persistence operations within the overall code architecture can be clearly identified, determining the service modules using these methods and their complete call chain information for accessing underlying resources such as the database.

[0128] In one implementation of this specification, a Java Parser tool is used to scan and parse the backend code. First, the system scans the project's source code directory, identifying all Java files named "Controller" (such as UserController.java, OrderController.java, etc.) as controller layer analysis objects. Next, a parsing library is used to parse the source code of each Controller file into an AST (Abstract Syntax Tree). This tree structure transforms elements such as class declarations, method definitions, and annotation information in the code into node-based data structures. Then, by traversing the AST nodes, key interface information is extracted, including: class-level mapping annotations, method-level request mapping annotations, request method types (GET / POST, etc.), method parameter structures, and their constraint annotations. Furthermore, the system analyzes the method call statements in the method body to establish the call relationship between the controller layer and the business layer, such as identifying the Service components and their methods called in the Controller methods. Simultaneously, the calls to DAO (Data Access Object) layer methods within the Service methods are traced to fully record the three-layer call chain from Controller to Service to DAO. Finally, all parsed results (including interface metadata and hierarchical call relationships) are integrated to generate a structured JSON (JavaScriptObject Notation, a lightweight data exchange format) interface archive file (such as backend_ast.json). This archive fully records the definition of each Controller interface, the corresponding Service layer method dependencies, and the final DAO layer data operation associations.

[0129] The method provided in this manual achieves automated modeling of the backend code architecture by extracting backend code control layer interface information and systematically analyzing the call relationships between various code layers, providing complete architectural foundation data for subsequent code quality analysis, change impact assessment, and system maintenance.

[0130] When performing automated code inspection, existing code inspection methods typically employ a uniform inspection strategy to handle code change events, failing to deeply analyze the specific attributes of the changes (such as whether they involve modifications to backend interfaces or adjustments to frontend call logic). This coarse-grained inspection approach cannot dynamically adjust the inspection focus based on the actual situation of the changes, resulting in a lack of targeting in the inspection process. This may lead to a large number of irrelevant alerts or the omission of key issues, reducing the practical value of the inspection results.

[0131] This specification provides an optional embodiment of a method to solve the above problems, specifically including the following steps:

[0132] If the event type of the code submission event is code change, retrieve the front-end and back-end code change information from the submission information;

[0133] The front-end and back-end code change information is parsed to obtain the interface change information of the back-end code and the module call change information of the front-end code.

[0134] Accordingly, step 106 may include the following steps:

[0135] The target prompt words are constructed based on the interface change information, the module call change information, and the target prompt template.

[0136] Code changes refer to modifications, additions, or deletions made to existing code in the repository during a code commit event. For example, code changes could include adjusting parameters of an existing backend interface, optimizing the calling logic of a frontend component, or fixing defects in existing functionality.

[0137] Front-end and back-end code change information refers to structured information describing specific modifications to the front-end and back-end code, obtained by comparing code version differences. For example, it can be code difference content generated by the `git diff` command, which includes modified file paths and specific line changes (additions, deletions, modifications).

[0138] Interface change information refers to the modification details of the application programming interface (API) parsed from changes in the backend code. For example, interface change information includes: changes to the interface path, changes to the HTTP method, additions, deletions, and modifications to request parameters or response body structures, and updates to interface annotations.

[0139] Module call change information refers to the modification details about how the front-end module calls the back-end interface, which are parsed from the changes in the front-end code. For example, module call change information includes: changes to the URL of the called interface, changes to the request method, adjustments to the input parameter structure, and updates to the callback processing logic.

[0140] The process involves retrieving front-end and back-end code change information from submission messages; parsing this information to obtain interface change information for the back-end code and module call change information for the front-end code. Essentially, it uses version control and analysis tools to systematically extract and parse the changes involved in code submission events, generating structured data that characterizes the details of back-end interface modifications and adjustments to front-end call logic. For example, interface change information refers to the modifications to interface definitions (e.g., paths, methods, parameters) in the back-end code within the aforementioned structured data; similarly, module call change information refers to the adjustments made to front-end code calls to back-end interfaces (e.g., request parameters, processing logic) within the aforementioned structured data. By parsing this structured data, the specific impact and relationships of code changes in the front-end and back-end components can be determined. This data, combined with target prompt templates, allows for the generation of corresponding detection instructions to guide the detection agent in targeted analysis.

[0141] In one implementation of this specification, after the system identifies a code commit event as "code change," it uses the Git version control system's diff function to obtain the code differences between the current commit and the previous version. Parsing these differences reveals a change in a method annotation in the backend code's controller file, indicating a change in the interface path; the system records this as interface change information. Simultaneously, parsing reveals that the corresponding component in the frontend code calls this interface for updates; the system records this as module call change information. When constructing the target prompt, the system integrates the aforementioned interface path change details and frontend call adjustment information with a preset prompt template for the "interface change" type (this template includes instructions for checking interface compatibility, version transition schemes, etc.) to generate the final target prompt, for example: "It has been detected that the user query interface path has changed from ' / user / {id}' to ' / v2 / user / {user Id}', and the frontend call has been adjusted accordingly. Please focus on analyzing whether this interface change maintains backward compatibility, whether all relevant callers have been notified, and whether the version transition scheme is reasonable."

[0142] In one implementation of this specification, the system determines front-end and back-end code change information based on the parsing results using a detection agent. After the system identifies the code commit event type as "code change," it obtains the code change content through a version control system, thereby obtaining the updated back-end code. For the back-end code, the system uses a code parser to construct an abstract syntax tree (AST). Simultaneously, the updated front-end code can be obtained using the same method. For the front-end code, the system uses a scripting language parser to construct an AST. The resulting AST of both front-end and back-end code is the parsing result. For example, the prompt words constructed for the commit information could be:

[0143] "As an API architecture expert, conduct a detailed analysis of the impact of API changes by combining the front-end AST.json, back-end AST.json, and commit message, and output the results according to the following requirements:"

[0144] a. Output Change Type

[0145] b. Output influence range

[0146] c. Are there any potential risks in the output?

[0147] d. Output Repair Suggestions

[0148] e. Output the relevant responsible person.

[0149] The method provided in this manual, through refined analysis of front-end and back-end relationship changes in code modifications and dynamic integration of these specific change information into detection instructions, enables the detection agent to perform highly targeted analysis, significantly improving the accuracy and effectiveness of code change detection and providing strong assurance for the quality of software iteration.

[0150] In existing code change analysis processes, a full analysis of the entire codebase is typically performed, failing to effectively filter out changes relevant to the current commit. This results in an overly broad analysis scope, redundant parsing, and difficulty in accurately identifying the relationship between the current change and historical code, impacting the accuracy and efficiency of change information extraction. This specification provides an optional implementation method for accurately extracting code change information, specifically including the following steps:

[0151] The front-end and back-end code change information is filtered to obtain the code change content of the back-end code and the code change content of the front-end code.

[0152] The code changes to the backend code and the code changes to the frontend code are analyzed separately to obtain the analysis results.

[0153] The parsing result is then merged with the original parsing result for the front-end and back-end code.

[0154] Based on the merging results, the interface change information of the backend code and the module call change information of the frontend code are determined.

[0155] Filtering: The process of selecting modifications related to specific code types from complete code change information. This involves filtering front-end and back-end code change information to obtain the changes made to the front-end and back-end. For example, filtering can be performed using file path characteristics (such as back-end code file paths containing keywords like "controller" or "service") to distinguish between back-end and front-end code changes. For example, filtering can be done using predefined regular expressions.

[0156] Code change details: This refers to the specific modifications made to a particular type of code (backend or frontend) after filtering. For example, code change details may include a list of modified files and specific changes to lines of code (additions, deletions, or modifications).

[0157] Original parsing results: These refer to the historical parsing results stored by the system for the same codebase prior to this code change. For example, original parsing results may include previously established backend interface lists, frontend module call relationships, and other code structure information. For example, original parsing results may be the abstract syntax tree of the frontend codebase and the abstract syntax tree of the backend codebase in the previous codebase.

[0158] Merging refers to the process of integrating and comparing the parsing results of the current code change with the historical parsing results. For example, the merging operation can be carried out by using a version comparison algorithm to identify newly added, modified, or deleted interface definitions and module call relationships.

[0159] In one implementation of this specification, after the system obtains code change information, it first filters based on file path characteristics: file changes containing the path "controller" are categorized as backend code changes, and file changes containing the ".vue" extension are categorized as frontend code changes. The filtered frontend and backend Diff content is then parsed using pattern-matching text parsing. For the frontend code, regular expressions are used to directly match network request call patterns (e.g., identifying key functions like fetch and axios and their parameters). For the backend code, regular expressions are used to match annotation patterns (e.g., identifying annotations like @RequestMapping and @GetMapping and their attributes), thereby extracting interface definitions and call information. Then, the system merges the parsing results with the original interface mapping table obtained from a full scan. The merging rules include removing corresponding mapping entries from deleted rows, adding new entries to newly added rows, and updating entry attributes in modified rows. Finally, the system obtains an updated structured interface mapping table, providing an accurate data foundation for subsequent code change analysis.

[0160] In one embodiment of this specification, a specific process for filtering and hierarchically parsing Diff information is provided. Figure 3 This specification illustrates a flowchart of a specific process for filtering and hierarchically parsing Diff information according to an embodiment of the present specification. Specifically:

[0161] Step 302: Code repository commit: The development team commits the Diff file from the code repository.

[0162] Step 304: Change Diff Capture: Use the diff function of the Git version control system to obtain the code differences between the current commit and the previous version.

[0163] Step 306: Layered Parsing: After obtaining the GitHub Diff file, the Diff information of the code submissions is first filtered using regular expressions. The filtering rules for the front-end code are based on specific paths (such as paths containing "webapp") and file extensions (such as JavaScript, TypeScript, and related framework file extensions). The filtering rules for the back-end code are based on specific paths (such as paths containing "java") and file extensions (such as Java, Kotlin, Scala, etc.), thereby filtering out the changes in the front-end and back-end code. Next, the system uses dedicated parsing tools to parse the filtered front-end and back-end Diff content. The front-end code uses a Babel parser to generate a front-end abstract syntax tree file, and the back-end code uses a Java parser to parse the controller layer, service layer, and data layer (DAO layer) to generate a back-end abstract syntax tree file.

[0164] Step 308: Building the front-end and back-end call relationship: The system merges the newly generated abstract syntax tree file with the original abstract syntax tree file obtained from the full scan. The merging rules include removing the corresponding node for deleted lines, creating new nodes for added lines, and updating node attributes for modified lines. Finally, the system obtains the updated front-end and back-end abstract syntax tree file, providing an accurate structured data foundation for subsequent code change analysis.

[0165] To more clearly describe the layered parsing and the process of building the front-end and back-end call relationship in this implementation process, Figure 4 This document illustrates a schematic diagram of the specific process for hierarchical parsing and obtaining an updated front-end and back-end abstract syntax tree, as provided in one embodiment of this specification.

[0166] like Figure 4As shown, after obtaining the GitHub Diff file, the front-end and back-end code in the Diff file are first filtered out using regular expression classification. The Babel Parser tool is then used to parse the front-end code, and the parsed front-end AST is used to update the original front-end AST. Correspondingly, the Java Parser tool is used to parse the back-end code layer by layer, including interface layer (Controller) analysis, business logic layer (Service) analysis, and data layer (DAO) analysis, to obtain a back-end AST that can represent the call relationship between the back-end code layers in the changed Diff file. This back-end AST is then used to update the original back-end AST. Finally, the updated front-end AST and back-end AST are combined to obtain the change analysis and save it.

[0167] The method provided in this manual achieves accurate extraction of code change information through a progressive processing flow of filtering, separate parsing, and result merging. By comparing and analyzing with historical code states, it accurately identifies change points and their impact scope, improving the accuracy of extracting interface change information and module call change information.

[0168] However, existing code detection methods typically only consider current interface and call change information when constructing detection prompts, failing to fully utilize existing front-end and back-end relationship data. This specification provides an optional implementation process to address these issues, specifically including the following steps:

[0169] Based on the interface change information, the module call change information, the association between the front-end module and the back-end interface, and the target prompt template, a target prompt word is constructed.

[0170] The relationship refers to the call mapping relationship between front-end modules and back-end interfaces established in historical code analysis. For example, the relationship can be specifically described as a complete mapping table of "the user management front-end page calling the user query interface and the user editing front-end component calling the user update interface".

[0171] Target prompt word construction refers to the process of fusing multiple information sources to generate the final detection instruction. For example, the construction process includes intelligently splicing and semantically fusing interface change details, module call change information, relationship graphs, and preset detection templates.

[0172] In one implementation of this specification, the system obtains complete information about a code commit, including the front-end AST.json file, the back-end AST.json file, and the commit information. Based on this information, the system generates the following prompts and calls the detection agent for deep analysis. The specific prompts may be:

[0173] As an API architecture expert, please conduct an impact analysis of the interface change based on the following input information:

[0174] a. Fragment of changes to the backend AST.json:

[0175] -Before the change:

[0176] "@GetMapping(" / api / user / {id}")"public UserDTO getUser(@PathVariableLong id){...}

[0177] -After the change:

[0178] "@GetMapping(" / api / users / {id}")"public UserDTO getUser(@PathVariableLong id){...}

[0179] b. Relevant parts of the front-end AST.json (in the user details page component):

[0180] {"type":"CallExpression","callee":{"type":"Identifier","name":"axios.get"},"arguments":

[0181] [{"type":"Literal","value":" / api / user / 123"},...]}

[0182] c. Submit message: "refactor: unify user-related interface paths, change / user / to / users / "

[0183] Please produce a detailed analysis report according to the following requirements:

[0184] a. Change type: Identify the specific type and nature of this change.

[0185] b. Scope of impact: Analyze the direct and indirect audiences affected by the change.

[0186] c. Potential Risks: Assess potential technological and business risks.

[0187] d. Repair suggestions: Provide specific and feasible solutions and improvement suggestions.

[0188] e. Relevant responsible persons: Identify the teams and personnel who need to participate in the repair.

[0189] The method provided in this specification, by incorporating relational information into the construction of prompt words, enables the detection agent to perform analysis based on the complete architectural context, significantly improving the systematicness and comprehensiveness of code change detection.

[0190] In existing code inspection processes, inspection results are typically output in raw data form, lacking a structured report presentation. Furthermore, the transmission process between the inspection results and the code to be inspected is relatively independent, requiring the inspection end to manually associate the results with the corresponding code, increasing processing complexity and time costs. This specification provides a method to address these issues in one optional implementation, specifically including the following steps:

[0191] A code detection report is generated based on the detection results, and the code detection report and the code to be detected are sent to the detection terminal.

[0192] Code inspection report: A structured document generated based on inspection results, containing information such as inspection findings, issue classification, and remediation suggestions. For example, a code inspection report may contain structured fields such as issue level (e.g., critical, warning, alert), issue location (file path, line number), issue description, and remediation suggestions.

[0193] Detection terminal: refers to the terminal or system that receives and processes code inspection results. For example, the detection terminal could be the integrated development environment of a code reviewer, the issue tracking system of a project management platform, or the report display interface of a continuous integration platform. Figure 5 This diagram illustrates an embodiment of a detection report display interface for a task management system, as provided in this specification. Figure 5 As shown, the interface includes the specific time of the information push, relevant information about the code inspection task to be executed, including the task number corresponding to the code submission, the task type, the person in charge of the code development task, and the submission time; after the inspection is completed, a code review report will also be pushed, which includes the task number corresponding to the code review report, a summary of serious issues, controls for viewing details, and controls for generating a corresponding list of issues.

[0194] In one implementation of this manual, after obtaining the code detection results, a code detection report is automatically generated, containing the following information: detection time, version hash value of the code to be detected, and a list of detected issues (including issue type, severity level, location information, and suggested remediation). Subsequently, the system packages the code detection report and the corresponding code to be detected into a single package and sends it via email to the project team's code review email address (the detection end). Reviewers can directly view the structured report and access the specific code location within the email.

[0195] In one implementation of this specification, after code inspection is completed, a standardized JSON-formatted inspection report is generated. The report includes a detailed description of each detected issue, the associated code snippet, the issue category, and a priority assessment for remediation. Subsequently, the system pushes the inspection report along with the corresponding code version information to a designated task (inspection end) on the project management platform via an API interface. Developers can directly view the report and associate it with specific code changes on the platform.

[0196] In one implementation of this specification, after code detection is completed, the generated code detection report may include the following content, and an early warning notification may be issued based on the code detection report. Figure 6 This specification illustrates a flowchart of an embodiment of an artificial intelligence intelligent analysis that generates a code detection report and issues an early warning notification. Specifically:

[0197] Step 602: AI Intelligent Analysis: Call the AI ​​module in the detection agent to perform intelligent analysis;

[0198] Step 604: Generate impact prediction results. For example, the detection report includes specific impact prediction results. The detection report can be:

[0199] a. Change type: Interface path change (belongs to P0 level change, which may cause front-end requests to return a 404 error).

[0200] b. Scope of impact: All front-end modules using this interface. Through front-end AST scanning, we identified the following front-end modules using the old paths:

[0201] - User details page: UserDetail.vue (using path: / api / user / ${id}).

[0202] - User management list: UserList.vue (This API is called to navigate to a user's details when a user is clicked).

[0203] c. Potential risk: Extremely high. The front-end is still requesting the old path, while the back-end has changed the path, causing all user details interface requests to fail, and users will not be able to view user details.

[0204] d. Repair suggestions:

[0205] 1. The front-end needs to change the request path from / api / user / ${id} to / api / users / ${id}.

[0206] 2. It is also recommended that the backend retain the compatibility of the old interface (such as supporting two paths at the same time) for a period of time when modifying the path, or use redirection to give the frontend a buffer period.

[0207] e. Relevant responsible persons:

[0208] - Backend Owner: The backend developer who submitted the change (e.g., Zhang xx).

[0209] - Frontend lead: The most recent modifier of UserDetail.vue and UserList.vue (from git blame):

[0210] -UserDetail.vue: Li xx.

[0211] -UserList.vue: Wang xx.

[0212] Step 606: Warning Notification: After obtaining the analysis results, the account information of project team members can be obtained from the project management system (e.g., task management system) according to the severity level. One or more people can be notified at the same time through collaborative communication tools, email, SMS, etc. For example, the frequency of notifications can be limited. For example, only one notification for the same interface and the same change reason can be pushed per hour to avoid multiple frequent message notifications at the same time.

[0213] For example, a project manager is notified in a collaborative communication tool.

[0214] For example, a collaborative communication tool can be used to notify the project leader and relevant personnel.

[0215] For example, collaborative communication tools are used in conjunction with SMS notifications to project leaders.

[0216] For example, collaborative communication tools are used to notify the project leader and relevant personnel via SMS.

[0217] Figure 7 This diagram illustrates a visual interface example of a notification scenario on a collaborative communication tool, specifically illustrating the code detection method provided in one embodiment of this specification. For example... Figure 7 As shown, the interface includes the identifier of the communication tool, the information push time, the warning reminder of the interface change notification, and an overview, including the submission time, change type, a brief description of the reason for the impact, the scope of the impact, and the relevant responsible persons; it also includes controls for jumping to details and controls for notifying the relevant responsible persons.

[0218] Accordingly, the submission information related to this notification case was recorded in the corresponding task management system. Figure 8 This specification illustrates a visual interface diagram of a submission record in a task management system provided in an embodiment, such as... Figure 8As shown, the interface includes controls for viewing details, viewing related plans, viewing release records, viewing associated work items, viewing attachments, and viewing commit records. It also includes commit version number, branch attribute information, repository information, committer, commit date, and other commit information summaries and possible modification details.

[0219] The method provided in this manual achieves efficient delivery and processing of detection results by automatically generating structured detection reports and sending them along with the code to be detected to the processing end, thereby improving the efficiency and accuracy of code quality management.

[0220] Corresponding to the above method embodiments, this specification also provides embodiments of a code detection system. Figure 9 A schematic diagram of the structure of a code detection system provided in one embodiment of this specification is shown. Figure 9 As shown, the system includes:

[0221] The code management tool 902 is configured to monitor code commit events, and upon detecting a code commit event, obtain the commit information of the code to be monitored corresponding to the code commit event;

[0222] The detection agent 904 is configured to identify the event type of the code submission event and determine a target prompt template based on the event type; construct target prompt words based on the submission information and the target prompt template; and perform a code detection task based on the target prompt words to obtain a detection result for the code to be detected.

[0223] Optionally, the code management tool 902 is further configured to: receive a code development task sent by the requesting end, wherein the code development task includes task information; send the code development task to the code development end so that the code development end executes the code development task based on the task information; invoke the code management tool to monitor the code submission event of the code development end for the code development task, and if a code submission event is detected, obtain the submission information of the code to be detected corresponding to the code submission event; and associate the code to be detected with the code development task based on the submission information and the task information.

[0224] Optionally, the detection agent 904 is further configured to: identify the detection result, and generate a detection list if the detection result involves a specified type, wherein the specified type includes at least one of database script execution, configuration file update and interface change, and correspondingly, the detection list includes at least one of script files to be executed, configuration parameter modification points and interface adjustment items.

[0225] Optionally, the code management tool 902 is further configured to: perform a full scan of the front-end and back-end code when the event type of the code submission event is the first submission, to obtain the association between the front-end module and the back-end interface, as well as the interface information of the back-end interface.

[0226] Optionally, the code management tool 902 is further configured to: parse the front-end code in the front-end and back-end code to obtain a parsing result; based on the parsing result, identify the front-end module that uses a function call in the front-end code; based on the function call, obtain the call information of the front-end module calling the back-end interface, and based on the call information, construct the association between the front-end module and the back-end interface.

[0227] Optionally, the code management tool 902 is further configured to: parse the control layer of the backend code in the frontend and backend code to obtain the interface information of the backend interface, parse the call relationship of each code layer of the backend code to obtain the call relationship of each code layer, and record the call relationship.

[0228] Optionally, the code management tool 902 is further configured to: when the event type of the code submission event is code change, obtain the front-end and back-end code change information in the submission information; parse the front-end and back-end code change information to obtain the interface change information of the back-end code and the module call change information of the front-end code;

[0229] The detection agent 904 is further configured to: construct target prompt words based on the interface change information, the module call change information, and the target prompt template.

[0230] Optionally, the code management tool 902 is further configured to: filter the front-end and back-end code change information to obtain the code change content of the back-end code and the code change content of the front-end code; parse the code change content of the back-end code and the code change content of the front-end code respectively to obtain the parsing results; merge the parsing results with the original parsing results for the front-end and back-end code; and based on the merging results, determine the interface change information of the back-end code and the module call change information of the front-end code.

[0231] Optionally, the detection agent 904 is further configured to: construct target prompt words based on the interface change information, the module call change information, the association between the front-end module and the back-end interface, and the target prompt template.

[0232] Optionally, the detection agent 904 is further configured to: generate a code detection report based on the detection results, and send the code detection report and the code to be detected to the detection terminal.

[0233] The above is an illustrative scheme of a code detection system according to this embodiment. It should be noted that the technical solution of this code detection system and the technical solution of the code detection method described above belong to the same concept. Details not described in detail in the technical solution of the code detection system can be found in the description of the technical solution of the code detection method described above. Furthermore, the components in the system embodiment should be understood as functional modules necessary to implement each step of the program flow or each step of the method; these functional modules are not actual functional divisions or separations. The system claims defined by such a set of functional modules should be understood as a functional module architecture that primarily implements the solution through the computer program described in the specification, and not as a physical system that primarily implements the solution through hardware.

[0234] Figure 10 A structural block diagram of a computing device according to an embodiment of this specification is shown. The components of the computing device 1000 include, but are not limited to, a memory 1010 and a processor 1020. The processor 1020 is connected to the memory 1010 via a bus 1030, and a database 1050 is used to store data.

[0235] The computing device 1000 also includes an access device 1040, which enables the computing device 1000 to communicate via one or more networks 1060. Examples of these networks include PSTN (Public Switched Telephone Network), LAN (Local Area Network), WAN (Wide Area Network), PAN (Personal Area Network), or combinations of communication networks such as the Internet. The access device 1040 may include one or more of any type of wired or wireless network interface (e.g., NIC (Network Interface Controller)), such as an IEEE 802.11 WLAN (Wireless Local Area Network) wireless interface, Wi-MAX (Worldwide Interoperability for Microwave Access) interface, Ethernet interface, USB (Universal Serial Bus) interface, cellular network interface, Bluetooth interface, and NFC (Near Field Communication).

[0236] In one embodiment of this specification, the above-described components of the computing device 1000 and Figure 10 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 10 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this specification. Those skilled in the art can add or replace other components as needed.

[0237] The computing device 1000 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs (Personal Computers). The computing device 1000 can also be a mobile or stationary server.

[0238] The processor 1020 is used to execute computer-executable instructions of the code detection method.

[0239] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the code detection method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the code detection method described above.

[0240] An embodiment of this specification also provides a computer-readable storage medium storing a computer program / instructions which, when executed by a processor, are used for a code detection method.

[0241] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the code detection method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the code detection method described above.

[0242] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, are used for a code detection method.

[0243] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the code detection method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the code detection method described above.

[0244] The computer program / instructions include computer program code, which may be in the form of source code, object code, executable file, or some intermediate form. The computer-readable medium may include any entity or system capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, ROM (Read-Only Memory), RAM (Random Access Memory), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.

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

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

[0247] The preferred embodiments disclosed above are merely illustrative of this specification. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the content of this specification. These embodiments have been selected and specifically described in this specification to better explain the principles and practical applications of this specification, thereby enabling those skilled in the art to better understand and utilize this specification. This specification is limited only by the claims and their full scope and equivalents.

Claims

1. A code detection method, characterized in that, Applied to a code inspection system, the code inspection system including a code management tool and an inspection agent, the method includes: The code management tool is invoked to monitor code commit events. If a code commit event is detected, the commit information of the code to be monitored corresponding to the code commit event is obtained. Identify the event type of the code submission event and determine the target prompt template based on the event type; Based on the submitted information and the target prompt template, a target prompt word is constructed, and the detection agent is invoked to perform a code detection task based on the target prompt word, thereby obtaining the detection result for the code to be detected.

2. The method according to claim 1, characterized in that, Before invoking the code management tool to monitor code commit events, the process also includes: Receive code development tasks sent by the requester, wherein the code development tasks include task information; Send the code development task to the code development end so that the code development end can execute the code development task based on the task information; The process involves calling the code management tool to monitor code commit events. Upon detecting a code commit event, the tool retrieves the commit information of the code to be monitored corresponding to that event, including: The code management tool is invoked to monitor code submission events of the code development end for the code development task. When a code submission event is detected, the submission information of the code to be detected corresponding to the code submission event is obtained. Based on the submission information and the task information, the code to be detected is associated with the code development task.

3. The method according to claim 1, characterized in that, After obtaining the detection result for the code to be detected, the method further includes: Identify the detection results, and if the detection results involve a specified type, generate a detection list, wherein the specified type includes at least one of database script execution, configuration file update and interface change, and correspondingly, the detection list includes at least one of the script files to be executed, configuration parameter modification points and interface adjustment items.

4. The method according to claim 1, characterized in that, The code to be detected includes front-end and back-end code; After identifying the event type of the code submission event, the method further includes: When the event type of the code submission event is the first submission, a full scan of the front-end and back-end code is performed to obtain the association between the front-end module and the back-end interface, as well as the interface information of the back-end interface.

5. The method according to claim 4, characterized in that, The full scan of the front-end and back-end code includes: For the front-end code in the front-end and back-end code, the front-end code is parsed to obtain the parsing results; Based on the parsing results, identify the front-end modules that use function calls in the front-end code; Based on the calling function, the calling information of the front-end module calling the back-end interface is obtained, and based on the calling information, the association between the front-end module and the back-end interface is constructed.

6. The method according to claim 4, characterized in that, The full scan of the front-end and back-end code includes: For the backend code in the frontend and backend code, the control layer of the backend code is parsed to obtain the interface information of the backend interface, and the call relationship of each code layer of the backend code is parsed to obtain the call relationship of each code layer, and the call relationship is recorded.

7. The method according to claim 1, characterized in that, After identifying the event type of the code submission event, the method further includes: If the event type of the code submission event is code change, retrieve the front-end and back-end code change information from the submission information; The front-end and back-end code change information is parsed to obtain the interface change information of the back-end code and the module call change information of the front-end code. The step of constructing target prompt words based on the submission information and the target prompt template includes: The target prompt words are constructed based on the interface change information, the module call change information, and the target prompt template.

8. The method according to claim 7, characterized in that, The step of parsing the front-end and back-end code change information to obtain interface change information of the back-end code and module call change information of the front-end code includes: The front-end and back-end code change information is filtered to obtain the code change content of the back-end code and the code change content of the front-end code. The code changes to the backend code and the code changes to the frontend code are analyzed separately to obtain the analysis results. The parsing result is then merged with the original parsing result for the front-end and back-end code. Based on the merging results, the interface change information of the backend code and the module call change information of the frontend code are determined.

9. The method according to claim 8, characterized in that, The construction of target prompt words based on the interface change information, the module call change information, and the target prompt template includes: Based on the interface change information, the module call change information, the association between the front-end module and the back-end interface, and the target prompt template, a target prompt word is constructed.

10. The method according to any one of claims 1-9, characterized in that, After obtaining the detection result for the code to be detected, the method further includes: A code detection report is generated based on the detection results, and the code detection report and the code to be detected are sent to the detection terminal.

11. A code detection system, characterized in that, This includes code management tools and detection agents; The code management tool is configured to monitor code commit events, and upon detecting a code commit event, obtain the commit information of the code to be monitored corresponding to the code commit event; The detection agent is configured to identify the event type of the code submission event and determine the target prompt template based on the event type; Based on the submitted information and the target prompt template, a target prompt word is constructed, and a code detection task is performed based on the target prompt word to obtain the detection result for the code to be detected.

12. A computing device, characterized in that, This includes memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, wherein when the computer programs / instructions are executed by the processor, they implement the method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program / instructions that, when executed by a processor, implement the method described in any one of claims 1 to 10.

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

Images