Code tracing methods, systems, electronic devices, storage media, and computer program products

Abstract

This application discloses a code tracing method, system, electronic device, storage medium, and computer program product, relating to the fields of artificial intelligence and computer technology. The method includes: in response to a write event of target type code in an integrated development environment, acquiring code change data corresponding to the write event; in response to a version commit operation performed on the code to be committed corresponding to the target type code, verifying the code change data based on the code to be committed and a baseline version code corresponding to the target type code to obtain commit statistics, wherein the commit statistics are used to characterize the valid code change lines provided by the target type code relative to the baseline version code; associating and storing the commit statistics with the code version identifier corresponding to the version commit operation to obtain a code tracing record. This application solves the technical problems of low efficiency, poor real-time performance, and poor accuracy in code tracing of related technologies.

Description

Technical Field

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

[0002] In software development, accurately measuring and tracing code from specific sources (such as specific contributors or tools) is a common requirement for improving project management and quality assessment efficiency. This necessitates a system that can automatically and accurately associate changed code with specific sources. However, existing solutions typically rely on manual post-event analysis or external tools independent of version control processes for code tracing. These solutions suffer from several drawbacks: file-level comparisons result in low tracing accuracy; low automation leads to low efficiency; and poor synchronization between tracing results and code commits results in poor real-time performance.

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

[0004] This application provides a code tracing method, system, electronic device, storage medium, and computer program product to at least solve the technical problems of low efficiency, poor real-time performance, and poor accuracy in code tracing in related technologies.

[0005] According to one aspect of the embodiments of this application, a code tracing method is provided, comprising: in response to a write event of target type code in an integrated development environment, acquiring code change data corresponding to the write event; in response to a version commit operation performed on code to be committed corresponding to the target type code, verifying the code change data based on the code to be committed and a base version code corresponding to the target type code to obtain commit statistics, wherein the commit statistics are used to characterize the effective code change lines provided by the target type code relative to the base version code; and associating and storing the commit statistics with a code version identifier corresponding to the version commit operation to obtain a code tracing record. According to one aspect of the embodiments of this application, a method for tracing artificial intelligence code is provided, comprising: in response to a write event of artificial intelligence code in an integrated development environment, acquiring code change data corresponding to the write event; in response to a version commit operation performed on code to be committed corresponding to the artificial intelligence code, verifying the code change data based on the code to be committed and a base version code corresponding to the artificial intelligence code to obtain commit statistics, wherein the commit statistics are used to record the effective code change lines provided by the artificial intelligence code relative to the base version code; and associating and storing the commit statistics with a code version identifier corresponding to the version commit operation to obtain a code tracing record.

[0006] According to another aspect of the embodiments of this application, an electronic device is provided, including: a memory storing an executable program; and a processor connected to the memory for running the program, wherein the program executes the code tracing method of any one of the above-mentioned methods during runtime.

[0007] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, the device where the computer-readable storage medium is located executes the code tracing method of any of the above.

[0008] According to another aspect of the embodiments of this application, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the above-described code tracing methods.

[0009] In this embodiment, in response to a write event of target type code in the integrated development environment, code change data corresponding to the write event is obtained; in response to a version commit operation performed on the code to be committed corresponding to the target type code, the code change data is verified based on the code to be committed and the base version code corresponding to the target type code to obtain commit statistics, wherein the commit statistics are used to characterize the valid code change lines provided by the target type code relative to the base version code; the commit statistics are associated and stored with the code version identifier corresponding to the version commit operation to obtain code tracing records. It is easy to note that this embodiment ensures the real-time nature of the tracing response by obtaining code change data in response to a write event; it integrates the tracing process into the development commit workflow by automatically triggering subsequent processing in response to a version commit operation, thus achieving automation; by verifying the change data based on the code to be committed and the base version code at the time of commit, invalid or conflicting change lines are eliminated, thereby ensuring the row-level accuracy of the statistics; in addition, by directly associating and storing the refined commit statistics with the version identifier of the current commit, it ensures that the tracing results correspond precisely to a specific code version, and achieves a relatively strict synchronization between the tracing data and the version history. Therefore, the embodiments of this application achieve the goal of automating and line-level tracing of target type code through the linkage between code tracing, code writing, and code submission, thereby improving the technical effects of code tracing efficiency, real-time performance, and accuracy, and solving the technical problems of low code tracing efficiency, poor real-time performance, and poor accuracy in related technologies.

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

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

[0012] Figure 1 This is a hardware structure block diagram of a computing device used to implement code tracing methods;

[0013] Figure 2 This is a schematic diagram of the system structure in an application scenario;

[0014] Figure 3 This is a flowchart of a code tracing method according to an embodiment of this application;

[0015] Figure 4 This is a schematic diagram of an optional AI code tracing system architecture according to an embodiment of this application;

[0016] Figure 5 This is a schematic diagram of an optional real-time recording process after AI code is written, according to an embodiment of this application;

[0017] Figure 6 This is a schematic diagram of an optional submission verification process for AI code submission according to an embodiment of this application;

[0018] Figure 7 This is a schematic diagram of an optional code tracing process after history rewriting according to an embodiment of this application;

[0019] Figure 8 This is a schematic diagram of a specific process following an optional submission merge operation according to an embodiment of this application;

[0020] Figure 9 This is a structural block diagram of a code tracing device according to an embodiment of this application;

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

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

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

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

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

[0026] An Integrated Development Environment (IDE) is a software application that provides software developers with comprehensive functions such as code editing, compilation, and debugging.

[0027] Git is a distributed version control system used to efficiently track and manage the code change history of software projects.

[0028] Git hooks are callback mechanisms provided by the Git version control system that automatically execute pre-defined scripts when specific events occur.

[0029] The prepare-commit-msg hook is a type of Git hook that is triggered before the commit message editor starts and can be used to modify or generate commit messages.

[0030] The post-commit hook is a type of Git hook that is triggered after a commit operation is completed and is often used to perform subsequent processing tasks.

[0031] The post-rewrite hook is a type of Git hook that is triggered after a history rewrite operation is completed and is used to handle related follow-up operations.

[0032] A Git reference (or Git Ref) is a pointer in Git that points to a specific commit or other object. It is often used to store metadata information.

[0033] JSON Lines (JSONL) is a data storage format in which each line is an independent JSON object, making it easy to process line by line.

[0034] Rebase: A history rewriting operation in Git used to move a series of commits onto a new base commit.

[0035] Amend: A Git operation used to modify the content or message of the most recent commit.

[0036] Squash: In Git, this operation combines multiple commits into a single commit.

[0037] AI Code Contribution Rate: A metric used to measure the proportion of code generated by artificial intelligence (AI) assistants in total code changes.

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

[0039] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 This is a hardware structure block diagram of a computing device used to implement code tracing methods. For example... Figure 1As shown, the computing device 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processors 102 may include, but are not limited to, microprocessors (MCUs) or field-programmable gate arrays (FPGAs), etc.), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the computing device 10 may also include: a display, an input / output interface (I / O interface), a Universal Serial Bus (USB) port (which may be included as one of the ports of a computer bus), a network interface, a cursor control device (such as a mouse, touchpad, etc.), a keyboard, a power supply, and / or a camera.

[0040] Those skilled in the art will understand that Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, the arithmetic unit 10 may also include a ratio Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0041] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element of the computing device 10. As involved in the embodiments of this application, the data processing circuits serve as processor control (e.g., selection of a variable resistor termination path connected to an interface).

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

[0043] The transmission device 106 is used to connect to a network via a network interface to receive or send data. Specific examples of the network described above may include wired and / or wireless networks provided by the communication provider of the computing device 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module for wireless communication with the Internet.

[0044] like Figure 1 The display shown can be, for example, a touchscreen liquid crystal display (LCD), which allows the user to interact with the user interface of the computing device 10.

[0045] Figure 1 The hardware structure block diagram shown can serve not only as an exemplary block diagram of the aforementioned computing device 10, but also as an exemplary block diagram of the aforementioned server. In one optional embodiment, Figure 2 It is a kind of use Figure 1 The diagram shows a system architecture for an application scenario where the computing device acts as a transmitter or receiver. Figure 2 As shown, the computing device 10 can be connected to one or more servers (e.g., security servers, resource servers, game servers, etc.) via a data network connection or electronically. In an alternative embodiment, the computing device 10 can be any mobile computing device, etc. The data network connection can be a local area network (LAN) connection, a wide area network (WAN) connection, an Internet connection, or other types of data network connection. The computing device 10 can execute network services that connect to a server (e.g., a security server) or a group of servers 20. The network server is a network-based user service, such as social networks, cloud resources, email, online payments, or other online applications.

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

[0047] Step S301: In response to a write event of target type code in the integrated development environment, obtain the code change data corresponding to the write event.

[0048] The aforementioned integrated development environment (IDE) is an application used for writing, modifying, debugging, and testing software code. It provides an integrated interface for functions such as a code editor, project management tools, compiler, and debugger. In application scenarios, this IDE can be locally installed software, a cloud-based IDE running in a browser or on a remote server, or a lightweight code editor existing as a plugin for other applications. This IDE can also serve as a platform for code tracing, method execution, and event triggering.

[0049] The aforementioned target type code refers to code snippets or blocks that possess specific attributes or whose contributions need to be tracked. The target type code is the specific object of code tracing operations. The attributes of the target type code can be defined according to actual tracing needs. For example, target type code may include, but is not limited to: code automatically generated or suggested by artificial intelligence models, code associated with a specific developer identifier (such as email address or username), code imported from a specific code repository, branch, or template, and code marked with specific comments or tags. This application does not limit the specific type definition criteria for target type code; it can cover code types distinguished and marked based on code source, author, generation method, or other attributes.

[0050] The aforementioned write events refer to the actions of creating, inserting, modifying, or replacing target type code within the code editor of an integrated development environment (IDE). These write events can serve as the initial trigger signal to initiate the code tracing process. Write events can be triggered directly by user input or automatically by auxiliary tools within the IDE (such as code completion and refactoring). In application scenarios, for example, a write event is generated when an AI coding assistant inserts a generated code snippet at the cursor position in the editor; another example is when a developer pastes a code block from a specific source.

[0051] The code change data described above is a collection of information describing the changes to the code content introduced by this write event. The code change data can contain various fields, the specific set of which can be determined according to the application scenario requirements. For example, code change data may include, but is not limited to: the path of the modified file, the location information of the change (e.g., start line number, end line number, range of changed characters, etc.), the specific code content fragments before and after the change, a timestamp, and the tool identifier or author information that triggered the write event. The code change data can be stored in various structured formats, such as JSON objects, text lines with specific delimiters, or binary format.

[0052] In application scenarios, the system can continuously monitor write events. When a write event is detected, it retrieves the corresponding code change data. Code change data can be obtained in various ways. For example, it can be obtained by installing plugins or extensions in the integrated development environment (IDE), through an external monitoring process independent of the IDE, or through the integration interface between the IDE and the version control system client. It should be noted that this application embodiment can employ appropriate technical means to obtain code change data for different types of IDEs and different target code definition methods.

[0053] Through the aforementioned step S301, this embodiment of the application enables the system to instantly detect and record code change information when target type code is written. This code change data provides a raw, event-driven data foundation for subsequent accurate verification and statistics during version submission.

[0054] Step S302: In response to the version commit operation performed on the code to be committed corresponding to the target type code, the code change data is verified based on the code to be committed and the base version code corresponding to the target type code to obtain commit statistics. The commit statistics are used to characterize the effective code change lines provided by the target type code relative to the base version code.

[0055] The code to be committed mentioned above refers to the modified code content in the current development directory that is ready to be saved to the version history. The code to be committed is the object processed by the version commit operation. The version commit operation refers to issuing an instruction to the version control system, requesting that the code to be committed be created as a new, permanent version snapshot. For example, in the Git version control system, the version commit operation is usually completed by executing the `Git commit` command. The version commit operation can serve as a trigger event for subsequent verification processes.

[0056] The baseline version code refers to the code content of a specific version that already exists in the version history and is selected as the comparison benchmark. The baseline version code can be the latest state of the file in the version control system before writing begins for the target type of code. For example, the baseline version code could be the code content of the file in the most recent commit of the current branch. The baseline version code can serve as a reference basis for measuring the contribution of the target type of code.

[0057] In application scenarios, during the time interval between the target type code being written and the triggering of a version commit operation, the code to be committed may be actively modified by the developer or other tools. In this case, the code change data recorded in step S301 may not fully reflect the actual situation of the committed version code. Based on this, when the system detects a version commit operation, it verifies the code change data based on the code to be committed and the baseline version code, accurately identifies and records the valid code change lines provided by the target type code relative to the baseline version code, thereby obtaining commit statistics information.

[0058] Specifically, the aforementioned verification process refers to the process of checking, analyzing, and correcting code change data. The submission statistics are concise and accurate results obtained after verification. The submission statistics include line numbers and statistical information for valid code change lines. This statistical information may include: number of changed lines, change percentage, contribution, etc. A valid code change line refers to a line change that has been verified and confirmed to be introduced by the target type of code and actually exists in the code to be submitted. Line changes include added lines and deleted lines. For example, the submission statistics may include: file path, new line number, number of new lines, deleted line number, and number of deleted lines.

[0059] Specifically, the aforementioned statistical information may also include various categories of statistical data corresponding to different types of change lines in the valid code change lines. For example, the statistical information may include statistics on newly added lines and statistics on deleted lines. The statistics on newly added lines include: the number of newly added lines, the percentage of newly added lines, and the contribution of newly added lines, etc. The statistics on deleted lines include: the number of deleted lines, the percentage of deleted lines, and the contribution of deleted lines, etc.

[0060] The aforementioned contribution includes, but is not limited to: the contribution of the target type code contained in the code to be committed to the base version code; and the contribution of the target type code to the full code corresponding to the base version code after the code to be committed is successfully committed. In particular, when calculating the contribution, different types of change lines can correspond to different contribution weights. For example, each newly added line has a contribution weight of +1, and each deleted line has a contribution weight of -0.8.

[0061] In application scenarios, the verification process involves reviewing code change data using the code to be committed and the baseline version. This verification process can be implemented in several ways. For example, in one implementation, verification can be automated using the hook mechanism provided by the version control system. In Git, a first hook script (of type pre-commit or prepare-commit-msg) can be configured. This first hook script is automatically triggered when the user executes the Git commit command. When the first hook script is executed, the system first retrieves the code content in the current staging area as the code to be committed. Next, it retrieves the baseline version code using Git commands. Then, the hook script reads the code change data. Finally, by calling file difference comparison tools or libraries, it cross-compares the information in the code to be committed, the baseline version code, and the code change data to identify valid change lines still existing in the code to be committed, thereby generating commit statistics.

[0062] For example, in another implementation, validation can be accomplished through deep integration of the integrated development environment (IDE) and the version control system. When a user clicks the "Commit" button in the IDE's graphical interface, the IDE triggers a validation callback before internally building the commit package. This callback function retrieves the code to be committed from the workspace, obtains the base version code from the version control plugin, and reads code change data from memory or temporary files. The IDE then uses its built-in code comparison engine to execute the validation logic and displays the upcoming commit statistics in a pop-up window or updated interface.

[0063] Through step S302 above, this embodiment of the application automatically introduces a verification step at the version commit node of the code lifecycle. This verification step uses the code to be committed and the baseline version code to review the original change records, ensuring that the commit statistics accurately reflect the actual contribution of the target type code in this commit version. This effectively prevents statistical errors caused by secondary modifications before commit.

[0064] Step S303: Associate and store the submission statistics information with the code version identifier corresponding to the version submission operation to obtain the code tracing record.

[0065] The code version identifier mentioned above is a string or numeric sequence automatically generated by the version control system for each successfully executed commit, used to uniquely identify the code version created by that commit. For example, in the distributed version control system Git, the code version identifier can be a hash value generated based on a specific algorithm. The code version identifier serves as an index for anchoring statistical information to specific code history nodes.

[0066] The aforementioned associated storage refers to the process of establishing and persistently saving the correspondence between commit statistics and code version identifiers. Associated storage aims to ensure that the contribution statistics of each commit can be reliably stored long-term and precisely bound to the corresponding code version for future querying, auditing, or analysis. The code tracing record described above is the data recorded after associated storage is completed. For example, a code tracing record can be a structured data record that contains or implicitly associates with code version identifiers.

[0067] In application scenarios, the process of associating and storing commit statistics with code version identifiers can be implemented in various ways. For example, it can be accomplished through the version control system's own object storage mechanism, through an external database or file system independent of the version control system, or by utilizing the version control system's extended attributes or metadata mechanisms. In other words, for different version control systems, different team infrastructures, and different data persistence requirements, the embodiments of this application can adopt corresponding storage strategies and technical means to achieve associated storage.

[0068] Through step S303 above, this embodiment of the application completes the storage phase of the tracking process. This storage phase binds the verified and accurate code change statistics to a unique code version identifier in the version control system. The resulting code tracking records ensure that for any historical code version, the specific contribution of the target type of code can be accurately and quickly queried. This provides a data foundation for subsequent performance analysis, cost accounting, audit tracing, or compliance checks.

[0069] The code tracing method provided in this application can be applied to software development and collaboration scenarios that require precise measurement of specific types of code contributions. In particular, in scenarios such as evaluating the performance of AI coding assistants, tracking contributions from specific teams or developers, and analyzing the impact of third-party code repository introductions, the aforementioned code tracing method can effectively solve the problems of fuzzy contribution statistics and disconnect from version information. For example, in development teams using AI programming assistants, the aforementioned code tracing method can automatically count the number of lines of code generated by AI in each commit; in open-source project governance, it can accurately distinguish code modifications by different contributors; and in software compliance reviews, it can clearly track the change history of code under specific licenses. By introducing real-time recording based on write events, automatic verification based on commit operations, and strong association storage with version identifiers, this application embodiment can achieve the technical effects of statistical automation, result accuracy, and data versioning in different development management scenarios.

[0070] Through steps S301 to S305, this embodiment of the application ensures the real-time nature of the tracking response by instantly acquiring code change data in response to write events; it integrates the tracking process into the development submission workflow by automatically triggering subsequent processing in response to version commit operations, thus achieving automation; it verifies the change data based on the code to be committed and the base version code during submission, eliminating invalid or conflicting change lines, thereby ensuring the line-level accuracy of the statistics; furthermore, by directly associating and storing the refined submission statistics with the version identifier of the current submission, it ensures that the tracking results correspond precisely to specific code versions, achieving a relatively strict synchronization between tracking data and version history. Therefore, this embodiment of the application achieves the goal of automating and line-level tracking of target type code through the linkage between code tracking, code writing, and code submission, thereby improving the technical effects of code tracking efficiency, real-time tracking, and accuracy, and solving the technical problems of low code tracking efficiency, poor real-time performance, and poor accuracy in related technologies.

[0071] The following provides further explanation of other optional embodiments of the code tracing method in this application.

[0072] As an optional embodiment, in the code tracing method, the target type code is code generated by an artificial intelligence model.

[0073] In the optional embodiments described above, the artificial intelligence model refers to a trained machine learning model. This AI model is capable of automatically generating or suggesting programming code based on natural language descriptions, code context, or other inputs. The AI ​​model used for code generation can be an application example of a large language model in the field of code generation.

[0074] In this embodiment, the target type code is specifically set to the code generated by the artificial intelligence model (which can be called AI-generated code), which clarifies a typical application scenario of the above code tracing method. In this application scenario, the system can automatically and accurately track and count the contribution of the artificial intelligence model in the software development project according to the above code tracing method.

[0075] In application scenarios, code generated by AI models is typically integrated into an integrated development environment (IDE) through specific interfaces or plugins. When developers use the functionality of these interfaces or plugins, the AI ​​model provides code snippet suggestions, which developers can choose to accept. When a suggestion is accepted, a write event for the target type of code is triggered.

[0076] Based on this, when a write event is identified as originating from an AI model, the system initiates a code tracing process to obtain code change data. In subsequent processing, the system performs line-level verification and statistics on these AI-generated lines of code. Furthermore, the system associates detailed contribution statistics of the AI-generated code with the corresponding code version identifier to obtain code tracing records.

[0077] By concretizing target type code into code generated by an artificial intelligence model, the embodiments of this application enable the code tracing scheme to be directly applied to AI-assisted programming scenarios. Thus, the above-mentioned optional embodiments meet the needs of quantifying the contribution of AI tools, evaluating the quality of AI code, or conducting related audits; that is, without human intervention, the system automatically obtains AI code output data accurate to the line level and strictly synchronized with the code version history.

[0078] As an optional embodiment, in step S301, obtaining code change data includes the following steps: Step S311, obtaining the changed file path, the file code before writing, and the file code after writing corresponding to the write event; Step S312, comparing the file code before writing and the file code after writing to obtain a first line number mapping relationship; Step S313, determining the current set of newly added line numbers and the current set of deleted line numbers based on the first line number mapping relationship; Step S314, generating code change data using the changed file path, the current set of newly added line numbers, the current set of deleted line numbers, and the current file snapshot of the file code after writing.

[0079] In the optional embodiments described above, the modified file path refers to the location information of the file containing the target type code in the project working directory or version control system after the target type code has been written. The modified file path is used to identify the file modified by the target type code. For example, the modified file path can be a relative path or an absolute path.

[0080] The "pre-write file code" refers to the complete code content of the file pointed to by the changed file path before this write event occurred. The "post-write file code" refers to the complete code content of the same file after this write event was completed. The pre-write file code and post-write file code together define the complete content difference caused by this write event.

[0081] In application scenarios, obtaining the modified file path, the file code before the write, and the file code after the write are prerequisites for performing detailed difference analysis. Specifically, this information can be obtained through the application programming interface (API) provided by the integrated development environment (IDE). For example, when a plugin detects a write event for the target type, it can directly obtain the path of the modified file, the text content of the editor before the event (as the file code before the write), and the new text content after the event (as the file code after the write) from the event callback parameters. Alternatively, by monitoring file system save operations, the current content of the file and the previous version's content retrieved from the cache can be read simultaneously at the moment the file is saved, thus obtaining the file code before and after the write.

[0082] The aforementioned first line number mapping relationship is obtained by comparing the file code before and after the write operation line by line. This first line number mapping relationship describes the corresponding changes from the "before the write" line number to the "after the write" line number. Specifically, the comparison process identifies lines that remain unchanged before and after the write operation, lines that exist only in the file code after the write operation (i.e., newly added lines), and lines that exist only in the file code before the write operation (i.e., deleted lines).

[0083] In application scenarios, comparing the file code before and after writing can be achieved by calling a difference calculation library or tool. For example, the first line number mapping relationship can be obtained using the string difference library built into the programming language, the diff command provided by the operating system, or a preset difference algorithm library. This first line number mapping relationship can be represented in a list format, where each record indicates the type of line change (such as "added", "deleted", "modified") and the range of line numbers involved in the change.

[0084] The aforementioned set of currently added line numbers is a selection of line numbers belonging to the "added" type from all changes, based on the first line number mapping relationship. This set records the position of newly generated lines of code in this write event within the "file code after write". Similarly, the aforementioned set of currently deleted line numbers is a selection of line numbers belonging to the "deleted" type from all changes, based on the first line number mapping relationship. This set records the position of lines of code removed in this write event within the "file code before write".

[0085] In practical implementation, the set of row numbers can be represented using various data structures. For example, a continuous range of row numbers can be represented by an interval consisting of a starting row and an ending row (such as [10, 15]) to simplify the data. For discrete single rows, a single number can be used. Therefore, the currently added row number set and the currently deleted row number set can be represented as a list consisting of numbers or intervals.

[0086] The aforementioned current file snapshot refers to a complete copy of the file code after the write operation. The purpose of saving the current file snapshot is to provide an accurate baseline of the file state corresponding to the completion of this write event for subsequent verification steps.

[0087] In application scenarios, generating code change data is a data encapsulation process. The changed file paths, the set of currently added line numbers, the set of currently deleted line numbers, and the current file snapshot are organized according to a predefined structure to obtain the code change data.

[0088] For example, this information can be encapsulated into a JSON object to obtain code change data. This JSON object includes the following fields: the changed file path (filePath), the current set of newly added line numbers (aiAddedLines), the current set of deleted line numbers (aiDeletedLines), and the current file snapshot (aiModifiedContent).

[0089] Based on steps S311 to S314 described above, this application provides a specific and implementable method for obtaining code change data. This method accurately captures the file state before and after writing and performs line-level difference analysis, enabling it to accurately identify line-level changes directly caused by the target type of code, and encapsulates the change content, location information, and complete snapshot into structured data. This provides high-quality, fine-grained foundational data for the code tracing process.

[0090] As an optional embodiment, the code tracing method further includes the following steps: Step S341, obtaining the change history corresponding to the target type code, wherein the change history includes: a set of historically added line numbers, a set of historically deleted line numbers, and historical file snapshots recorded after the previous version commit operation; Step S342, comparing the historical file snapshots with the current file snapshot to obtain a second line number mapping relationship; Step S343, based on the second line number mapping relationship, merging the historically added line number set with the current added line number set to obtain a merged added line number set, and merging the historically deleted line number set with the current deleted line number set to obtain a merged deleted line number set; Step S344, updating the code change data using the merged added line number set, the merged deleted line number set, and the current file snapshot.

[0091] In the optional embodiments described above, the change history refers to change information for target type code within the same file (i.e., the file pointed to by the changed file path), which was recorded but not yet committed before the current write event occurred. The change history is used to maintain and accumulate change states across multiple consecutive write events. The change history is typically stored in a temporary area, such as a memory cache maintained by an IDE plugin, a temporary JSON file in the project directory, or a specific local database.

[0092] The aforementioned set of historical newly added line numbers records the line numbers of target type code that were added to the same file but not yet committed before this write event. The aforementioned set of historical deleted line numbers records the line numbers of target type code that were deleted to the same file but not yet committed before this write event. The aforementioned historical file snapshots are the complete file content corresponding to the time the historical newly added line number sets and historical deleted line number sets were generated. These historical file snapshots serve as a comparison benchmark to track changes in the position of line numbers during subsequent file modifications.

[0093] In application scenarios, retrieving the change history occurs after or in parallel with step S311. When a write event for a file is detected, the system attempts to check if the file already has an uncommitted change history. For example, the system can search for and load the change history from a cached dictionary with the file path as the key or a temporary file named after the file path, based on the changed file path.

[0094] The aforementioned second line number mapping is a data relationship obtained by comparing historical file snapshots with the current file snapshot line by line. This second line number mapping describes the mapping from the line numbers of the "historical file snapshot" to the line numbers of the "current file snapshot". Because the file may be changed by other modifications (including modifications to non-target type code) between two write events, causing the overall line numbers to shift or the content to be reorganized, the second line number mapping is needed to correct the valid position of the historical line number set in the current file.

[0095] The historical file snapshot is compared with the current file snapshot, which can be done using a difference algorithm similar to step S312. The second line number mapping relationship obtained from the comparison will indicate whether each line (or line interval) in the historical file snapshot exists in the current file snapshot, and if so, its corresponding new line number.

[0096] In the application scenario, for the set of historically added line numbers, the second line number mapping relationship is used to attempt to map each added line number to the coordinate system of the current file snapshot. If a historically added line can be successfully mapped, it means that the line still exists in the current file content, and its mapped new line number should be retained. Then, the successfully mapped new line numbers are merged with the set of currently added line numbers generated by the current write event to form a merged set of added line numbers. For the set of historically deleted line numbers, the second line number mapping relationship is also used for conversion and verification. If the content corresponding to a historically deleted line number is deleted in a historical snapshot but does not appear in the current snapshot, the deletion record is still valid and should be retained. Then, the retained historically deleted line numbers are merged with the set of currently deleted line numbers generated by the current write event to form a merged set of deleted line numbers.

[0097] Specifically, the above merging process may need to handle cases where mapping failures occur. For example, if a historically added line number cannot be mapped to the current file snapshot, it means that the line was deleted by other modifications between the two write events, and therefore the line should no longer be counted as a valid addition to the target type code and should be removed from the history. If a historically deleted line number can be mapped to the current file snapshot, it means that the line has been restored, and the corresponding deletion record should be removed.

[0098] Updating code change data by merging the sets of newly added line numbers, the sets of deleted line numbers, and the current file snapshot means replacing the sets of currently added and deleted line numbers generated based on a single write event with the merged set of line numbers reflecting all uncommitted cumulative changes. The current file snapshot is used as the base snapshot for the update, and together they constitute the updated code change data. This updated code change data will be used for subsequent commit verification.

[0099] Based on steps S341 to S344 above, this application provides a solution for handling multiple target type code write events within the same file before a single version submission. This solution, by maintaining and iteratively updating the change history, can accurately accumulate and coordinate multiple modifications, ensuring the integrity of submission statistics and avoiding the loss or duplicate counting of some changes due to multiple edits. This improves the robustness and accuracy of the tracking system in active development scenarios.

[0100] As an optional embodiment, in step S302, based on the code to be submitted and the baseline version code, the code change data is verified to obtain submission statistics, including the following steps: Step S321, comparing the current file snapshot in the code change data with the code to be submitted to obtain the third line number mapping relationship; Step S322, verifying the set of newly added line numbers in the code change data according to the third line number mapping relationship to obtain the updated set of newly added line numbers; Step S323, comparing the baseline version code with the code to be submitted to determine the fourth line number mapping relationship; Step S324, verifying the set of deleted line numbers in the code change data according to the fourth line number mapping relationship to obtain the updated set of deleted line numbers; Step S325, generating submission statistics based on the updated set of newly added line numbers and the updated set of deleted line numbers, wherein the submission statistics include statistics on newly added line numbers and statistics on deleted line numbers.

[0101] In the optional embodiments described above, the current file snapshot is the complete content of the file recorded in the code change data after the target type code write event has occurred. The code to be committed is the current file content to be stored in the version history. Comparing the current file snapshot with the code to be committed aims to identify subsequent changes to the file content that have occurred between the time the target type code was written and the time before the commit. These subsequent changes may have been introduced by manual editing by the developer or automatic modifications by other tools.

[0102] The aforementioned third line number mapping is a data relationship obtained by comparing the current file snapshot with the code to be committed line by line. This third line number mapping describes the correspondence between line numbers in the current file snapshot and line numbers in the code to be committed. The comparison process will identify unchanged lines that remain consistent between the two versions, as well as changed lines that have been added, deleted, or modified in the code to be committed.

[0103] In application scenarios, obtaining the third line number mapping relationship can be achieved by calling the diff calculation function. For example, the system can pass the current file snapshot and the content of the code to be committed to a diff algorithm library, which returns a change list showing every line-level change from the current file snapshot to the code to be committed and its mapping.

[0104] The newly added line number set in the aforementioned code change data records the position of the lines added by the target type code in the current file snapshot. This newly added line number set is verified based on the third line number mapping to determine whether these lines added by the target type code still exist in the code to be committed.

[0105] The aforementioned fourth line number mapping relationship is a data relationship obtained by comparing the base version code and the code to be committed line by line. This fourth line number mapping relationship describes the correspondence between line numbers in the base version code and line numbers in the code to be committed. The purpose of this comparison is to determine the status of each line of content in the base version code in the code to be committed.

[0106] The set of deleted line numbers in the aforementioned code change data records the position of the lines deleted by the target type code in the coordinate system of the base version code. This set of deleted line numbers is verified according to the fourth line number mapping relationship to determine whether these lines marked as deleted by the target type code are indeed still in a deleted state in the code to be committed.

[0107] Commit statistics are generated based on the updated sets of newly added and deleted line numbers. Commit statistics clearly and structurally represent the valid changes made to the target type code relative to the base version. For example, commit statistics can also be a JSON object containing fields such as filePath, finalAddedLines (a list of valid newly added line numbers), and finalDeletedLines (a list of valid deleted line numbers). Furthermore, the total number of newly added and deleted lines can be calculated as a statistical summary within the commit statistics.

[0108] Specifically, the aforementioned commit statistics can be structured to include new line statistics and deleted line statistics. New line statistics record valid lines of code added by the target type code that have been verified and retained. This typically includes at least a list of line numbers for valid new lines and can further calculate statistical metrics such as the total number of new lines. Deletion line statistics record valid lines of code deleted by the target type code that have been verified and confirmed. This typically includes at least a list of line numbers for valid deleted lines and can further calculate statistical metrics such as the total number of deleted lines. Based on this, the aforementioned commit statistics can provide a complete and fine-grained quantitative description of the target type code's contribution to the current commit version.

[0109] Through steps S321 to S325 described above, this application provides a specific and operable verification processing scheme. This scheme performs cross-validation and filtering of record changes from two dimensions: the post-write state and the original baseline state. This accurately eliminates invalid changes that are overwritten or restored between code writing and commit, ensuring that commit statistics accurately reflect the true contribution of the target type code in this commit version, thus improving the accuracy and reliability of the statistical results.

[0110] As an optional embodiment, in step S322, the newly added line number set is verified according to the third line number mapping relationship to obtain the updated newly added line number set, including the following method steps: Step S3221, based on the third line number mapping relationship, at least some of the newly added line numbers that failed to be mapped to the code to be submitted are filtered from the multiple newly added line numbers in the newly added line number set to obtain the updated newly added line number set.

[0111] In the optional embodiments described above, the specific circumstances of the mapping failure are as follows: for a specific newly added line number in the set of newly added line numbers, when attempting to find its corresponding line number in the code to be committed through the third line number mapping relationship, a valid, corresponding line number cannot be found. Mapping failure usually means that the line was removed during the change process from the current file snapshot to the code to be committed.

[0112] In the application scenario, the system iterates through each newly added line number (or line number range) in the newly added line number set. For each newly added line number encountered, the system uses it as input to query the previously calculated third line number mapping relationship. The query result can be: the line number in the code to be submitted that corresponds to the newly added line number encountered (if no corresponding line number exists in the code to be submitted, "-1" is returned). Based on this, the system makes a judgment based on the query result: if a valid line number is found, it indicates that the line still exists in the code to be submitted, the mapping is successful, and the line number (or the new line number adjusted according to the mapping relationship) should be retained; if the query returns "-1", it indicates that the line no longer exists in the code to be submitted, and the mapping fails.

[0113] After the mapping is completed, the system removes all newly added row numbers that failed to be mapped from the set of newly added row numbers. Then, the remaining newly added row numbers that were successfully mapped constitute the updated set of newly added row numbers.

[0114] Through step S3221 described above, this application embodiment provides a specific and automated filtering mechanism. During the pre-commit verification phase, this mechanism can accurately identify and remove invalid new lines that have been overwritten or deleted by subsequent modifications. This ensures that the new line statistics in the commit information strictly include lines included in the code repository, thereby eliminating statistical errors caused by manual editing before commit and further consolidating the line-level accuracy of code tracing results.

[0115] As an optional embodiment, in step S324, the set of deleted line numbers is verified according to the fourth line number mapping relationship to obtain an updated set of deleted line numbers, including the following method steps: Step S3241, based on the fourth line number mapping relationship, at least some of the deleted line numbers that are successfully mapped to the code to be submitted are filtered from the multiple deleted line numbers in the set of deleted line numbers to obtain an updated set of deleted line numbers.

[0116] In the optional embodiments described above, a successful mapping refers to a specific situation where, for a particular deleted line number in the set of deleted line numbers, when attempting to find its corresponding line number in the code to be committed through the fourth line number mapping relationship, a valid and corresponding line number can be found. A successful mapping typically means that the line was not actually removed during the change from the base version of the code to the code to be committed, or that it was removed and then restored.

[0117] In the application scenario, the system iterates through each deleted line number (or line number range) in the deleted line number set. For each deleted line number encountered, the system uses it as input to query the previously calculated fourth line number mapping relationship. The query result can be: the line number in the code to be submitted that corresponds to the deleted line number in the iterated sequence (if no corresponding line number exists in the code to be submitted, it returns "-1"). Based on this, the system makes a judgment based on the query result: if a valid line number is found, it indicates that the line still exists in the code to be submitted, and the mapping is successful; if the query returns "-1", it indicates that the line no longer exists in the code to be submitted, and the mapping fails.

[0118] After the mapping is completed, the system removes all successfully mapped deletion row numbers from the deletion row number set. Then, the remaining deletion row numbers that failed to be mapped constitute the updated deletion row number set.

[0119] Through step S3241 described above, this application embodiment provides a specific and automated reverse filtering mechanism. During the pre-commit verification phase, this mechanism can accurately identify and remove invalid deleted lines that have been subsequently restored or were not actually deleted. This ensures that the deleted line statistics in the commit statistics strictly include lines removed from the code repository, thereby eliminating statistical errors caused by manual editing before commit and further solidifying the accuracy of code tracing results in determining code deletion behavior.

[0120] As an optional embodiment, in step S303, the commit statistics information and code version identifier are associated and stored to obtain a code tracing record, including the following method steps: Step S331, based on the commit statistics information, a first file content object of the version control system is created; Step S332, the first file content object is associated and stored with the code version identifier to generate a code tracing record, wherein the code version identifier is used to indicate the commit version code determined after the version commit operation is completed.

[0121] In the optional embodiments described above, the version control system refers to a software tool used to manage the version history of source code. This version control system can be Git, Mercurial, Subversion, etc. Internally, version control systems typically use object databases to store data.

[0122] The aforementioned commit statistics are structured data representing valid changes to target type codes, obtained after verification processing. Creating a first file content object based on the commit statistics means encapsulating the structured data in the commit statistics into data units that can be recognized and stored by the version control system, according to the internal format specified by the version control system, thereby obtaining the first file content object. Internally, the data unit used to store file content can be a Blob object.

[0123] In this application scenario, the creation of the first file content object is automated by the system. Specifically, the system serializes commit statistics into a string of a specific format. For example, the system can convert commit statistics into a JSON or XML string. Then, the system calls the underlying commands or application programming interfaces (APIs) provided by the version control system to create the first file content object. For instance, in Git, a preset command can be invoked, taking the aforementioned string as input to obtain its corresponding hash value. This string and hash value are then saved as a new Blob object in Git's object database. This newly created Blob object serves as the first file content object.

[0124] Furthermore, when storing the first file content object in association with the code version identifier, a direct or indirect reference relationship from the code version identifier to the first file content object is established, and this reference relationship is persisted to obtain the code tracing record.

[0125] The code tracing records described above provide a robust and queryable correspondence between code version identifiers and commit statistics. When it is necessary to query the target type of code contribution for a particular commit, the system can locate the associated first file content object through the code version identifier, read the object content and deserialize it to reconstruct the commit statistics.

[0126] In application scenarios, the aforementioned associated storage can be implemented in several ways. One exemplary approach is to leverage the referencing mechanism of a version control system. For instance, in Git, a new referencing can be created using the `Git update-ref` command within a second hook script (e.g., a post-commit hook). The name of this new referencing can include a code version identifier, such as "refs / ai-stats / ". <commit-hash>The value of this new reference can be set to the hash value of the first file's content object. Based on this, in subsequent processes, the corresponding reference can be found through the code version identifier, and then the Blob object storing commit statistics (i.e., the first file's content object) can be found through the reference. In addition, if the version control system supports custom commit metadata, the hash value of the first file's content object can be directly recorded in the metadata of this commit object, achieving a tighter binding.

[0127] Through steps S331 and S332 described above, this application embodiment provides a reliable code tracing record persistence scheme that is deeply integrated with a version control system. This scheme utilizes the version control system's own object storage and reference mechanisms to persistently store commit statistics associated with code version identifiers, thereby enhancing the data persistence and traceability of the code tracing system.

[0128] As an optional embodiment, the code tracing method further includes the following steps: Step S351, in response to a target rewrite operation in the version control system, obtaining the rewritten version code that was triggered to be committed after the target rewrite operation was completed; Step S352, based on the target rewrite operation, determining the historical code tracing record corresponding to the historical version code identifier, wherein the historical version code identifier includes: at least one version code identifier of at least one historical commit version code associated with the target rewrite operation; Step S353, using the rewritten version code, verifying the historical commit statistics in the historical code tracing record, and generating rewrite statistics; Step S354, associating and storing the rewrite statistics with the rewrite version identifier corresponding to the rewritten version code, and updating the code tracing record in the version control system.

[0129] In the optional embodiments described above, the target rewrite operation refers to a command operation in the version control system that modifies the commit history. When these target rewrite operations are executed, they change the code content, commit metadata, or commit history order of one or more existing commits and generate a new commit version code. For example, target rewrite operations include, but are not limited to: commit amend, rebase, cherry-pick, and commit squash. The rewritten version code refers to the file content of the new version created and committed to the version history after the target rewrite operation is executed.

[0130] In application scenarios, when a user or automated process performs the aforementioned target rewrite operation, the system automatically detects the rewrite event through a third hook script in the version control system (such as a post-rewrite hook). Subsequently, the system extracts the file content corresponding to the newly generated commit of this target rewrite operation from the code repository, i.e., the rewritten version code.

[0131] The aforementioned historical version code identifiers are unique identifiers of one or more original commits affected by the target rewrite operation. The aforementioned historical code trace records are pre-stored code trace records associated with these historical version code identifiers, containing historical commit statistics. The process of determining historical code trace records can be as follows: the system analyzes the target rewrite operation, parses out the version identifiers of all original commits affected by the target rewrite operation, and then, based on these version identifiers, searches for and reads the corresponding historical code trace records from the version control system's storage space.

[0132] When using the rewritten version code to verify historical commit statistics, the verification process is similar to that in step S302. Specifically, the system uses the rewritten version code, historical file snapshots, and historical baseline version code to perform verification processes on the historical commit statistics, including line number mapping, new line verification, and deleted line verification, in order to generate rewritten statistics that accurately reflect the effective contribution of the target type code in the rewritten code.

[0133] During the process of associating rewrite statistics with rewrite version identifiers, the newly generated rewrite statistics are bound to the unique identifier (i.e., the rewrite version identifier) ​​of the new commit created by the target rewrite operation and stored in persistent storage. This association storage operation will generate a new code tracing record.

[0134] Through steps S351 to S354 described above, this application provides an extended solution for handling version history rewriting operations. This solution can automatically respond to target rewrite operations in a version control system. By obtaining the rewritten version code and identifying the associated historical code tracing records, the rewritten version code can be used to re-verify historical commit statistics, generating rewrite statistics that accurately reflect the code's state after the rewrite. Furthermore, by associating the rewrite statistics with the new rewrite version identifier, automatic migration and updating of code tracing records after version history rewriting is achieved. This effectively solves the problem of tracing data immediately becoming invalid or broken after the code history is rewritten in traditional solutions, ensuring the persistence, consistency, and strong correlation between code tracing records and the dynamically evolving code history, thus improving the practicality of the code tracing system in complex development workflows.

[0135] As an optional embodiment, in step S353, the rewritten version code is used to verify the historical commit statistics in the historical code tracing record to generate rewrite statistics, including the following steps: Step S3531, compare the rewritten version code with the historical file snapshots corresponding to the historical code tracing record to obtain the fifth line number mapping relationship; Step S3532, according to the fifth line number mapping relationship, verify the historical newly added line number set in the historical commit statistics to obtain the rewritten newly added line number set; Step S3533, compare the rewritten version code with the historical base version code corresponding to the historical code tracing record to obtain the sixth line number mapping relationship; Step S3534, according to the sixth line number mapping relationship, verify the historical deleted line number set in the historical commit statistics to obtain the rewritten deleted line number set; Step S3535, generate rewrite statistics based on the rewritten newly added line number set and the rewritten deleted line number set.

[0136] In the optional embodiments described above, the aforementioned historical file snapshot is a snapshot of the complete file content corresponding to historical commit statistics stored in the historical code tracing record. The aforementioned historical baseline version code is the original file version recorded in the historical code tracing record, serving as the basis for calculating historical commit statistics. The aforementioned rewrite version code is the file content in the new commit version generated after the target rewrite operation is completed.

[0137] The rewritten code is compared with historical file snapshots to identify code changes that occurred between the historical commit state and the current rewritten state. By comparing the rewritten code with historical file snapshots line by line, a fifth line number mapping is obtained. This fifth line number mapping describes whether each line (or line range) in the historical file snapshot exists in the rewritten code, and its corresponding new line number.

[0138] Furthermore, the historical newly added line numbers are verified based on the fifth line number mapping relationship to obtain the rewritten newly added line numbers set. Specifically, the system iterates through each line number in the historical newly added line number set and queries the fifth line number mapping relationship. If a historically added line number can be successfully mapped to a valid line number in the rewritten version code, it means that the line still exists in the rewritten version and should be added to the rewritten newly added line number set (or the mapped new line number). If the mapping fails, it means that the line has been removed during the rewriting process and should be filtered out.

[0139] The rewritten version code is compared with the historical baseline version code to determine the true differences between the rewritten version and the original baseline code. By comparing the rewritten version code line by line with the historical baseline version code, a sixth line number mapping is obtained. This sixth line number mapping describes whether each line (or line interval) in the historical baseline version code exists in the rewritten version code, and its corresponding new line number.

[0140] Furthermore, the historical deleted line number set is verified based on the sixth line number mapping relationship to obtain the rewrite deleted line number set. Specifically, the system iterates through each line number in the historical deleted line number set and queries the sixth line number mapping relationship. If a historical deleted line number can be successfully mapped to a valid line number in the rewrite version code, it means that the line has been restored in the rewrite version and should be filtered out; if the mapping fails, it means that the line is still in a deleted state in the rewrite version and should be retained in the rewrite deleted line number set.

[0141] Furthermore, based on the verified sets of newly added and deleted line numbers obtained after rewriting, rewrite statistics are generated. The format and meaning of these rewrite statistics are consistent with those of the submission statistics, and the rewrite statistics accurately reflect the updated status of the target type code's contribution after historical rewrite operations.

[0142] Through steps S3531 to S3535 described above, this application embodiment provides a verification process for historical rewrite scenarios. This process reuses line number mapping and verification logic, automatically correcting and migrating existing statistical data by comparing the rewritten version code with historical snapshots and historical benchmarks. This ensures that even after complex version history changes, code tracing records maintain strict synchronization and precise correspondence with the rewritten and updated code versions.

[0143] As an optional implementation, the target rewrite operation in the code tracing method includes one of the following: commit correction operation, rebase operation, pick operation, and commit merge operation.

[0144] In the above optional embodiments, the target rewrite operation is a specific command in a version control system (such as Git) used to modify the existing commit history. The target rewrite operation may change the code content, commit order, or commit structure, potentially leading to a discrepancy between recorded code contribution statistics and the new code version. Therefore, embodiments of this application can provide corresponding processing for the target rewrite operation.

[0145] The commit modification operations described above (such as the `amend` operation in Git) are used to modify the content or metadata of the most recent commit. During these operations, the user may have modified previously committed content containing code of the target type. Therefore, after the commit modification operation is executed, the historical commit statistics associated with that operation are re-verified and recalculated to ensure that the tracking information is consistent with the modified code version.

[0146] The rebase operation described above (e.g., the rebase operation in Git) is used to reapply a sequence of commits from one branch to another base point. During this rebase operation, code modifications may occur while resolving conflicts, resulting in changes to lines of code in the target type. Therefore, after the rebase operation is executed, the historical commit statistics involved need to be re-verified and recalculated.

[0147] The picking operation described above (e.g., the cherry-pick operation in Git) is used to apply the changes of a specific commit to the current branch individually. During this picking operation, conflicts and subsequent modifications may occur when applying the changes to different code contexts, potentially altering the contribution of the target type of code. Therefore, after the picking operation is performed, the historical commit statistics of the picked commit need to be re-verified and recalculated.

[0148] The commit merge operation described above (e.g., the squash operation used during interactive Git rebasing) is used to merge multiple consecutive commits into a single commit. During this merge operation, changes to target type code in multiple commits may affect or cancel each other out (e.g., code added in one commit may be deleted in a subsequent commit). Therefore, after the commit merge operation is executed, it is necessary to first merge the statistics of the multiple historical commits involved, and then re-verify and calculate the merged information.

[0149] Through the above optional embodiments, this application can perform code tracking and updates for various rewrite operations in version rewrite scenarios. The combination of the constraints, rebase operations, selection operations, and commit merge operations with the above-mentioned re-verification and migration mechanisms can ensure that the code tracking method can actively and accurately update statistical information after various rewrite operations are executed, thereby improving the robustness and practicality of the code tracking solution in complex development scenarios.

[0150] As an optional embodiment, in the code tracing method, when the target rewrite operation is a commit merge operation, the target rewrite operation is associated with multiple historical commit versions of code; the historical commit statistics are the merged information of multiple sets of commit statistics corresponding to multiple historical commit versions of code; the historical new line number set is obtained by merging multiple sets of new line numbers contained in multiple sets of commit statistics; the historical deleted line number set is obtained by merging multiple sets of deleted line numbers contained in multiple sets of commit statistics; the historical file snapshots include multiple code file snapshots from multiple sets of code change data corresponding to multiple historical commit versions of code; the historical baseline version code includes multiple baseline version codes corresponding to multiple sets of code change data.

[0151] In the optional embodiments described above, when the target rewrite operation is a commit merge operation, the system merges multiple consecutive, independent historical commits into a new single commit. Therefore, this commit merge operation is associated with multiple historical commit version codes. These historical commit version codes refer to the file content versions corresponding to the original commits to be merged.

[0152] To generate accurate rewrite statistics for the merged new commits, the system first needs to integrate the tracking data of multiple historical commits involved. The aforementioned historical commit statistics are not directly taken from the record of a single commit, but rather are a comprehensive information set obtained by merging multiple sets of commit statistics corresponding to the code of the multiple historical commit versions to be merged. The merging process mainly involves summarizing relevant fields from multiple sets of statistics.

[0153] Specifically, the above-mentioned set of newly added line numbers is generated by reading the set of valid newly added line numbers for each commit recorded in the commit statistics, and then merging these multiple sets of newly added line numbers from different commits. This merging process can be achieved using the union operation of sets, but the newly added line numbers need to be converted to a unified baseline before the merging operation.

[0154] Similarly, the above-mentioned historical deleted line number set is generated by reading the set of valid deleted line numbers for each commit recorded in the commit statistics, and then merging these multiple sets of deleted line numbers from different commits. Likewise, the deleted line numbers also need to be converted to a unified benchmark.

[0155] The aforementioned historical file snapshots are not the content of a single file, but rather include multiple code file snapshots saved in multiple sets of code change data corresponding to each historical commit version. These snapshots record the file state at the moment the corresponding historical commit was completed.

[0156] The aforementioned historical base version codes are not single versions, but rather include the base version codes on which each set of code change data was recorded. Since different historical commits may be based on different commit bases, these historical commit base version codes may vary.

[0157] With the above limitations, the embodiments of this application clarify the data sources and data structures that the system needs to integrate when handling the specific scenario of commit merge operation. This ensures that the system can correctly aggregate the original tracking data of multiple related commits, providing complete and accurate input for subsequent re-verification of the new content after the merge. This ensures that the migration and recalculation of code contribution statistics can still maintain correctness in complex commit merge scenarios.

[0158] As an optional embodiment, in step S354, the rewrite statistics information and the rewrite version identifier are associated and stored, and the code tracing record in the version control system is updated, including the following method steps: Step S3541, based on the rewrite statistics information, a second file content object of the version control system is created; Step S3542, the second file content object is associated and stored with the rewrite version identifier to generate a current code tracing record corresponding to the rewrite version identifier in the version control system; Step S3543, after the current code tracing record is generated, the historical code tracing record corresponding to the historical version code identifier is deleted from the version control system.

[0159] In the optional embodiments described above, the object is an internal data object created and managed by the version control system. This second file content object is used to persistently store structured rewrite statistics in the version control system's database. The process of creating the second file content object is as follows: rewrite statistics (e.g., a JSON-formatted string) are submitted as input to the underlying object storage interface of the version control system. The version control system calculates the hash value of the input content and saves this hash value as a new data object to the database. This newly created data object then serves as the second file content object.

[0160] The aforementioned rewrite version identifier is a unique identifier generated after the target rewrite operation is completed, representing a newly committed commit. Associating the second file content object with the rewrite version identifier means establishing a direct or indirect reference relationship between the rewrite version identifier and the second file content object, allowing the corresponding rewrite statistics to be located and accessed through the rewrite version identifier. In application scenarios, a typical associated storage method is to create a new reference in the version control system. For example, in a Git system, a new reference file named after the rewrite version identifier (or its abbreviation) can be created in the reference directory. The content of this reference file is the hash value of the second file content object. This newly created file reference and the second file content object it points to together constitute the current code tracing record corresponding to the rewrite version identifier.

[0161] After the current code trace is successfully generated, the system needs to perform a cleanup operation. This cleanup operation deletes the historical code traces corresponding to the historical version code identifiers (i.e., the identifiers of the old commits being rewritten) associated with this target rewrite operation from the version control system. Specifically, the system will locate and remove related references to old data objects. For example, in a Git system, this deletes reference files named after the old commit hash in the reference directory.

[0162] Through steps S3541 to S3543 described above, this application provides an atomic and secure storage update strategy. This strategy, by first creating a new object and establishing a new reference, and then deleting the old reference, ensures that code tracing data is not lost or left in an inconsistent intermediate state during the rewriting of version history. This mechanism enables code tracing records to automatically and reliably update synchronously with the historical evolution of code versions, effectively solving the problem of data breakage caused by version rewriting operations and ensuring the integrity and traceability of data throughout its entire lifecycle.

[0163] In the aforementioned operating environment, this application also provides a method for tracing artificial intelligence code, comprising: responding to a write event of artificial intelligence code in an integrated development environment, obtaining code change data corresponding to the write event; responding to a version commit operation performed on the code to be committed corresponding to the artificial intelligence code, verifying the code change data based on the code to be committed and the baseline version code corresponding to the artificial intelligence code to obtain commit statistics, wherein the commit statistics are used to record the valid code change lines provided by the artificial intelligence code relative to the baseline version code; associating and storing the commit statistics with the code version identifier corresponding to the version commit operation to obtain a code tracing record.

[0164] In software development environments employing AI-assisted programming, accurately tracking and measuring AI-generated code contributions is crucial for improving R&D efficiency, evaluating tools, and optimizing team collaboration. For example, when development teams use AI programming assistants, managers need to objectively assess their actual impact on project progress and code quality. In open-source or enterprise projects, it's essential to distinguish between contributions from human developers and AI tools for accurate tracing and auditing. Furthermore, precise data is needed to compare the performance of different AI coding tools when evaluating and purchasing them. However, existing code statistics methods struggle to automatically and accurately separate AI-generated lines of code from mixed modifications, and the statistical results are easily out of sync with code versions. In contrast, the AI ​​code tracking method provided in this application, by integrating into the developer's coding events and version submission workflow, automates the entire process from AI code generation and accurate verification upon submission to data persistence. This provides a real-time, reliable line-level contribution data foundation for the aforementioned application scenarios, enabling teams to evaluate the effectiveness of AI-assisted programming, optimize tool usage strategies, and clarify the source of code assets based on accurate data rather than subjective impressions.

[0165] This application embodiment ensures the real-time nature of AI code tracing by instantly acquiring code change data in response to AI code write events; it integrates the AI ​​code tracing process into the development submission workflow by automatically triggering verification processing in response to version submission operations, thus automating the tracing process; by verifying AI code change data based on the code to be submitted and the baseline version code during submission, it effectively eliminates invalid change lines that have been manually modified, overwritten, or restored between AI generation and submission, thereby ensuring the row-level accuracy of AI contribution statistics; furthermore, by directly associating and storing the refined submission statistics with the version identifier of the current submission, it ensures that the AI ​​code tracing results are precisely bound to specific code versions, achieving strict synchronization between tracing data and version history. Therefore, this application embodiment achieves the goal of automating and accurately embedding AI code tracing into the version control process, thereby improving the efficiency, real-time nature, and accuracy of AI code contribution measurement, and solving the technical problems of cumbersome AI code tracing processes, insufficient result accuracy, and easy disconnection from versions in related technologies.

[0166] The following section provides a detailed explanation of the code tracing method provided in the embodiments of this application, in conjunction with application scenarios.

[0167] In an exemplary application scenario, embodiments of this application provide, as follows: Figure 4 This illustrates one possible AI code tracing system architecture. (Example:) Figure 4 As shown, the AI ​​code tracing process implemented by this system architecture begins at the Integrated Development Environment (IDE). Within the IDE, the AI ​​code assistant acts as the source of code generation. When the AI ​​code assistant performs a code writing operation, a recording event is triggered. This recording event is responded to by the AI ​​code line mapping tracing module, which is essentially an integration of the functions of the AI ​​code recording submodule (not shown in the diagram) and the line number mapping submodule (not shown in the diagram): the AI ​​code recording submodule captures and records the specific line numbers of the code modified by the AI ​​in real time, while saving the complete modified file content as a snapshot and storing it in a JSONL temporary file on the IDE side; while the line number mapping submodule, after each AI modification, uses a Diff algorithm to track and verify the line number changes in the historical records, ensuring the accuracy of the records.

[0168] When the developer finishes editing and executes the Git commit command, the AI ​​code tracing process enters the version control system. At this time, the Git hook module in the version control system is activated, specifically executed by the prepare-commit-msg hook. This prepare-commit-msg hook reads the records in the aforementioned JSONL temporary file, verifies them based on the code content to be committed, and writes them into the statistics. The verified AI contribution statistics are automatically filled into the commit message for this commit. After the commit is successfully completed, the post-commit hook is triggered. At the same time, the system ensures that the post-rewrite hook is created and enabled. This post-rewrite hook is used to handle historical rewrite operations (such as rebase, amend, etc.) to maintain the continuity of statistical data.

[0169] The storage phase of the AI ​​code tracing process is handled by a persistent storage module (such as Git Ref). After a post-commit, this persistent storage module permanently stores the verified statistics as independent Git objects. For example, it saves the statistics as Git references (Ref), allowing the tracing data to be distributed and persisted along with the code repository.

[0170] Through such Figure 4 The AI ​​code tracing system architecture shown in this application, when applied to specific application scenarios, can achieve a fully automated closed loop from code generation, real-time recording, automatic verification upon submission to data persistence. This architecture deeply embeds tracing functionality into the developer's standard workflow, utilizing the version control system's own hook mechanism to trigger processing at critical moments. This not only ensures the real-time nature and line-level accuracy of tracing but also guarantees strict synchronization and permanent association between tracing results and code version history.

[0171] In an exemplary application scenario, the code tracing scheme in this embodiment relies on a line number mapping and verification algorithm based on difference comparison (Diff). This algorithm defines the basic concepts of file content in different states to achieve accurate line number tracing. The baseline version code, or baselineContent, refers to the original content of the file in the most recent commit of the version control system, serving as a fixed reference throughout the tracing process. The file code before the change, or oldContent, refers to the file content before the change occurred. The file code after the change, or newContent, refers to the file content after the change was completed. By comparing the file content in these different states, the system can calculate the precise line number correspondence.

[0172] The key to the algorithm described above lies in performing a Diff comparison of the content of two versions of the file and generating a detailed line number mapping relationship. The Diff comparison produces three basic results, each corresponding to a specific mapping processing rule. The first result is identical lines, also known as "equal". For lines with completely identical content, the system establishes a bidirectional mapping between the line numbers of the two versions, allowing the corresponding line number in the other version to be found from the line number in one version. The second result is newly added lines, also known as "insert". For lines that only exist in `newContent`, the system records their line numbers in `newContent`, but these line numbers cannot be back-mapped to `oldContent`; a return value of -1 is typically used to indicate that this mapping failure has occurred. The third result is deleted lines, also known as "delete". For lines that only exist in `oldContent`, the system records the line numbers of these lines that were deleted from `oldContent`, but these line numbers cannot be forward-mapped to `newContent`.

[0173] Based on the aforementioned Diff line number mapping relationship, the system performs two key verification operations to ensure the accuracy of the statistical information. The first operation verifies whether the newly added line still exists. This operation compares the file content at the time of the record change (as oldContent) with the current file content to be verified (as newContent) using a Diff comparison. The system checks each recorded newly added line number and attempts to forward map it to the current newContent. If the mapping is successful, it means that the line of code still exists in the current updated version, and the system updates its line number to the new mapped line number; if the mapping fails, it determines that the line of code has been deleted by subsequent modifications.

[0174] The second type of operation verifies whether a deleted line is still deleted. This operation involves performing a diff comparison between the unchanged baseline content and the current file content to be verified (as newContent). The system checks each recorded deleted line based on the baseline content's line number and attempts to map it to the current newContent. If the mapping is successful, it means the line has been restored and is no longer deleted; if the mapping fails, it confirms that the line is still deleted.

[0175] To ensure data integrity when initially recording changes to the target type code, the system also introduces a filtering logic to exclude false changes. This filtering logic mainly includes two aspects.

[0176] The first aspect is filtering newly added lines, which aims to exclude lines of code that appear to have been added by the target type code but actually already exist in the baseline version of the code (baselineContent). This typically happens when previously deleted lines of code are restored. The specific implementation for filtering newly added lines involves performing a Diff comparison between the modified file content (newContent) of the target type code and the baseline version of the code (baselineContent), and then checking whether the newly added line number of each record can be mapped back to baselineContent. If a mapping exists, it means that this line is not truly newly added and is excluded.

[0177] The second aspect is filtering deleted lines, designed to exclude lines of code that the target type code attempted to delete but which were not originally present in the baseline version of the code. This typically occurs when lines were added by the target type code itself before deletion. The specific implementation of filtering deleted lines involves performing a diff comparison between the original content of the target type code (oldContent) and the baseline version of the code (baselineContent), checking whether the deleted line number of each record can be mapped to the baselineContent. If a mapping is not possible, it indicates that the line was not a deletion of the baseline code and is excluded. Furthermore, to facilitate continuous tracking in a unified coordinate system, the system also performs a coordinate transformation of the deleted lines, converting the deleted line numbers from the coordinate system of the original content (oldContent) to the coordinate system of the baseline version of the code (baselineContent).

[0178] The aforementioned line number mapping and verification algorithm can be reused multiple times during AI code tracing, forming a common technical foundation for different processing stages. For example, when recording changes to target type code in real time, the algorithm is used to execute filtering logic and coordinate transformation to generate accurate initial change data. In the pre-commit verification stage, the algorithm is used to perform validity verification of added and deleted lines to generate commit statistics. In the history rewrite processing stage, the algorithm is again used to re-verify historical statistics to generate new statistics consistent with the rewritten version. By reusing the same set of line number mapping and verification rules in different stages, the embodiments of this application not only ensure the consistency of the entire tracing process logic but also improve the maintainability of the system and the reliability of the processing results.

[0179] In one exemplary application scenario, such as Figure 5 This illustrates a real-time recording process after AI code is written. For example... Figure 5 As shown, Figure 5 As shown, the process begins with an AI code write event, triggered by the AI ​​code assistant in the integrated development environment. Upon this event, the system responds immediately and proceeds to the "Calculate this change" step. In this step, the system invokes a difference comparison (Diff) algorithm to compare the original file content before the write with the AI-modified file content, calculating the set of line-level changes directly caused by this AI write.

[0180] The process then proceeds to two parallel filtering stages to eliminate false change records. The first stage is "filtering deleted lines," which aims to exclude lines of code marked as deleted by AI but which never actually existed in the baseline version. The system uses the aforementioned line number mapping and verification algorithm to perform a diff comparison between the original content and the baseline version, checking if each deleted line number can be mapped to the baseline. If not, the deleted line is excluded according to the filtering logic in the algorithm. The second stage is "filtering added lines," which aims to exclude lines of code marked as added by AI but which already exist in the baseline version. The system again uses the line number mapping and verification algorithm to perform a diff comparison between the AI-modified content and the baseline version, checking if each added line number can be mapped back to the baseline. If a mapping is possible, the added line is excluded according to the filtering logic in the algorithm.

[0181] After filtering is complete, the process executes the "coordinate transformation" step. This step applies the principle of coordinate system unification defined in the algorithm to transform the valid deleted line numbers from the coordinate system of the original content to the coordinate system of the baseline version code.

[0182] Next, the system determines whether an "old JSONL record" generated by the previous AI writes already exists in the current file. If no old record exists, the process switches to the "use directly" branch. If an old record exists, the process enters the verification phase. This verification phase includes two parallel verification operations: "verifying whether the old newly added lines still exist" and "verifying whether the old deleted lines have been recovered." Both verifications reuse the principles of line number mapping and verification algorithms. Specifically, the system performs a diff comparison between the historical file snapshot saved in the old record and the current aiModified content as two versions to generate a line number mapping relationship. For historically added lines, it checks whether they can be forward mapped to the current content to verify whether they still exist; for historically deleted lines, it checks whether historically deleted lines based on historical benchmarks can be mapped to the current content to verify whether the historically deleted lines have been recovered.

[0183] After completing the above verification and updates, the process proceeds to the "Merge New and Old Records" step. The system merges the valid new change data with the updated historical change records. Subsequently, the process executes the "Save aiModifiedContent Snapshot" step, saving the complete content of the file after AI has been written. Finally, in the "Write to JSONL File" step, the system serializes and writes the merged complete change records and the file snapshot together into a temporary JSONL file.

[0184] Through such Figure 5 The real-time recording process shown in this embodiment enables tracking to begin immediately after AI code is written. Through reused line number mapping and verification algorithms, the accuracy and consistency of filtering, coordinate transformation, and historical verification are ensured. This process guarantees the construction of accurate and reliable initial change data, which is a crucial prerequisite for successful verification during subsequent submissions.

[0185] In one exemplary application scenario, such as Figure 6 This illustrates a process for verifying AI code submissions. For example... Figure 6 As shown, this process is triggered by the developer executing the "git commit" command. After this command is executed, the system first performs the "read JSONL record" step, loading a JSONL file containing code change data for the target type, generated by the real-time recording process, from the temporary storage. Next, the system performs the "get stagedContent" step, retrieving the complete content of the currently pending code from the version control system's staging area.

[0186] After obtaining the above data, the process executes two core verification branches in parallel, both of which reuse the aforementioned line number mapping and verification algorithm. The first branch is "verifying newly added lines." In this branch, the system performs the "Diff(aiModifiedContent, staged)" operation, that is, it compares the difference between the AI ​​modified file snapshot (aiModifiedContent) saved in the JSONL record and the staging area content (staged). Based on the line number mapping relationship generated by this Diff calculation, the system performs the "filtering AI code that has been deleted by the user" operation. This operation specifically applies the logic of "verifying whether newly added lines still exist" in the algorithm: checking whether each newly added line number in the JSONL record can be positively mapped to the staging area content (staged). Line numbers that cannot be mapped mean that the AI ​​code in that line was manually deleted by the user before submission, and therefore are filtered out from the statistics.

[0187] The second parallel branch is "verifying deleted rows". In this branch, the system performs a "Diff(baseline, staged)" operation, which compares the differences between the baseline version code and the staged content. Based on the row number mapping relationship generated by this Diff calculation, the system performs a "filtering code that the user has recovered" operation. This operation specifically applies the logic of "verifying whether deleted rows are still deleted" in the algorithm: it checks whether each deleted row in the JSONL record, based on the baseline version code row number, can be mapped to the staged content. Row numbers that can be successfully mapped mean that the row has been manually recovered by the user, and therefore are filtered out from the deletion statistics.

[0188] After both verification branches are completed, the process proceeds to the "Generate Final Statistics" step. The system summarizes the valid new and deleted lines retained after double verification and filtering, generating final statistics that accurately reflect the contribution of the target type of code in this commit. Subsequently, the system executes the "Write to CommitMessage" step, automatically writing this final statistics into the commit message of this commit, permanently associating it with the commit. Finally, the process executes the "Create GitRef" step, permanently storing the final statistics as an independent object in the version control system and creating a reference pointing to this final statistics, ensuring that tracking data is distributed along with the code repository.

[0189] Through such Figure 6 The submission verification process shown in this application embodiment uses line number mapping and verification algorithms to accurately verify the temporary content at the code submission node. This effectively eliminates statistical errors caused by human intervention between the writing of AI code and the formal submission, thereby ensuring the accuracy of the statistical information in the database and realizing the automated and structured binding of statistical results with version submission.

[0190] In one exemplary application scenario, such as Figure 7 This illustrates a code tracing process after a history rewrite. For example... Figure 7 As shown, the process begins when a user or system performs a "history rewrite operation". This history rewrite operation triggers the version control system's "Post-rewriteHook", which automatically starts the code tracing process after the history rewrite to maintain the continuity of tracing data.

[0191] The process first determines the operation type. For "squash" (commit merge operation) types, the system first performs the "merge JSONL records of multiple commits" step. This step integrates the historical JSONL records corresponding to multiple commits to be merged, preparing a unified set of changed data for subsequent verification. For "rebase" (rebase operation) types, the system directly proceeds to the "get new commit content" step, extracting the file content from the new commit generated after the rewrite operation.

[0192] Regardless of the type of rewrite operation, the subsequent processing in the code tracing flow reuses the line number mapping and verification algorithm of this application embodiment. The system executes two verification branches in parallel. The first branch is "verifying newly added lines". The system compares the file snapshot in the history with the content of the rewritten file by executing the "Diff(aiModifiedContent, newContent)" operation (or "Diff(aiModifiedContent, rebasedContent)" operation for rebase operations). Based on the generated line number mapping relationship, the logic of "verifying whether newly added lines still exist" in the algorithm is applied to determine whether the historically added lines are still valid in the rewritten version. The second branch is "verifying deleted lines". The system compares the base version code with the content of the rewritten file by executing the "Diff(baseline, newContent)" operation (or "Diff(baseline, rebasedContent)" operation for rebase). Based on the generated row number mapping relationship, the algorithm is used to "verify whether the deleted row is still deleted" to determine whether the historically deleted row is still in the deleted state in the rewritten version.

[0193] After completing the above verification, the code tracing process proceeds to the "Generate New Statistics, Create New Ref" step. Based on the valid change lines retained after verification, the system generates rewrite statistics that accurately correspond to the newly committed version. Subsequently, the system creates a new Git object for this statistics and establishes a reference (Ref), permanently storing it and associating it with the version identifier of the new commit.

[0194] Furthermore, after ensuring that the new code tracing record is successfully created and stored, the system will perform a "delete old Ref" operation, which deletes historical references associated with the old commit version that has been rewritten and cleans up invalid tracing records, thereby completing the migration of the entire tracing data from the old version to the new version.

[0195] Through such Figure 7 The historical rewrite process shown in this application embodiment can automatically respond to and adapt to version history rewrite operations. By reusing a unified verification algorithm, this process ensures that even after the code history is modified, contribution statistics can be accurately recalculated and synchronized with the new code version, thereby solving the problem of data breakage and failure due to historical rewriting in traditional solutions.

[0196] In one exemplary application scenario, such as Figure 8 This illustrates a special workflow following a commit merge operation. For example... Figure 8 As shown, this process simulates the transfer of three historical commits (such as...). Figure 8 The example demonstrates how Commit1, Commit2, and Commit3 are merged (squash) into a new commit, and showcases the logic for merging and re-verifying AI code contribution data during this process.

[0197] Specifically, such as Figure 8 As shown, at the start of the above process, the system retrieves the AI ​​change records for each of the three historical commits: "Commit1" records AI newly added rows "[10-12]", "Commit2" records AI deleted rows "[10-12]", and "Commit3" records AI newly added rows "[20-25]". When performing the commit merge operation, the system first performs a "merge JSONL records" step, integrating the JSONL change records of the three commits. After merging, a temporary change set is obtained: the set of newly added rows is "[10-12, 20-25]", and the set of deleted rows is "[10-12]".

[0198] Subsequently, the process executes two verifications in parallel. The first verification is "Verification: Does the newly added row exist in the final content?" The system judges each row in the set of newly added rows in the merge based on the content of the final file generated after the commit merge. For example, for row "10-12", since it has been marked as deleted in "Commit2", it no longer exists in the final merge content, the conclusion is "10-12 does not exist (deleted by commit2) so it is filtered", and this row is removed from the valid addition statistics. For row "20-25", it still exists in the final content, the conclusion is "20-25 exists so it is retained".

[0199] The second verification is "Verification: Whether the deleted lines are still deleted in the final content." The system also makes a judgment based on the final file content. For the line "10-12" in the deleted line set, since it was deleted by "Commit2", it may no longer exist in the final merged content. The conclusion is "If 10-12 exists (it disappeared after being deleted by commit2), then it needs to be judged." Here, further analysis is needed to determine whether it has been restored by other modifications.

[0200] After completing the above verification and filtering, the system combines the results of the two verifications. In this example, after verification, "10-12" is neither counted as a valid addition, and its deletion status needs to be determined separately, while "20-25" is confirmed as a valid AI addition. Therefore, the process yields "Final statistics: AI additions [20-25]". The above process demonstrates how the system intelligently handles the complex situation where AI changes between multiple submissions may cancel each other out (such as being added and then deleted) through re-verification, ensuring the accuracy of the merged statistical results.

[0201] Through such Figure 8 The specific process illustrated in this application demonstrates the ability to handle the complex rewrite operation of commit merging (squash). This process eliminates statistical ambiguity caused by the intertwining of historical commit changes by summarizing each commit record before merging and re-analyzing the final content after merging, ensuring that the measurement results of AI contribution remain clear and accurate even after the code history has been significantly reorganized.

[0202] In summary, the code tracing method provided in this application can achieve several beneficial effects in AI code tracing scenarios. In terms of system architecture, the integrated design based on Git hook chains achieves a natural connection between the tracing process and version control operations, solving the problem of AI code tracing being disconnected from developer workflows. Regarding data persistence, by storing statistical data as Git objects and associating them with specific references, tracing data can be synchronized and distributed with the code repository, facilitating team collaboration and long-term maintenance. In terms of historical compatibility, the mechanism for handling historical rewrite operations ensures that relevant statistical data can be automatically migrated and remain valid after the code commit history is modified, avoiding breaks in the tracing chain. Regarding statistical accuracy, the processing logic based on line number mapping and verification algorithms achieves precise line-level tracing of code changes and can identify and filter manual modifications before commits, improving the accuracy of statistical results. Regarding support for complex operations, special handling for scenarios such as multi-commit merging allows for the correct aggregation and re-verification of change data from multiple historical commits, adapting to diverse version management practices. Based on the above technical effects, this application implements an automated, high-precision code tracing solution that is deeply integrated with version control systems.

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

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

[0205] According to an embodiment of this application, an apparatus embodiment for implementing the above-described code tracing method is also provided. Figure 9 This is a schematic diagram of the structure of a code tracing device according to an embodiment of this application, as shown below. Figure 9 As shown, the device includes: an acquisition module 901, used to acquire code change data corresponding to the write event in response to a write event of target type code in the integrated development environment; a verification module 902, used to verify the code change data based on the code to be committed and the base version code corresponding to the target type code in response to a version commit operation performed on the code to be committed corresponding to the target type code, and obtain commit statistics, wherein the commit statistics are used to characterize the valid code change lines provided by the target type code relative to the base version code; and an association module 903, used to associate and store the commit statistics with the code version identifier corresponding to the version commit operation, and obtain code tracking records.

[0206] Optionally, the acquisition module 901 is further configured to: acquire the changed file path, the file code before writing, and the file code after writing corresponding to the write event; compare the file code before writing and the file code after writing to obtain a first line number mapping relationship; determine the current set of newly added line numbers and the current set of deleted line numbers based on the first line number mapping relationship; and generate code change data using the changed file path, the current set of newly added line numbers, the current set of deleted line numbers, and the current file snapshot of the file code after writing.

[0207] Optionally, in addition to all the modules mentioned above, the code tracing device also includes a merging module (not shown in the figure), used to: obtain the change history corresponding to the target type code, wherein the change history includes: a set of historically added line numbers, a set of historically deleted line numbers, and historical file snapshots recorded after the last version commit operation; compare the historical file snapshots with the current file snapshot to obtain a second line number mapping relationship; based on the second line number mapping relationship, merge the set of historically added line numbers with the set of currently added line numbers to obtain a merged set of added line numbers, and merge the set of historically deleted line numbers with the set of currently deleted line numbers to obtain a merged set of deleted line numbers; and update the code change data using the merged set of added line numbers, the merged set of deleted line numbers, and the current file snapshot.

[0208] Optionally, the verification module 902 is further configured to: compare the current file snapshot in the code change data with the code to be committed to obtain a third line number mapping relationship; verify the set of newly added line numbers in the code change data according to the third line number mapping relationship to obtain an updated set of newly added line numbers; compare the base version code with the code to be committed to determine a fourth line number mapping relationship; verify the set of deleted line numbers in the code change data according to the fourth line number mapping relationship to obtain an updated set of deleted line numbers; and generate submission statistics based on the updated set of newly added line numbers and the updated set of deleted line numbers, wherein the submission statistics include statistics on newly added line numbers and statistics on deleted line numbers.

[0209] Optionally, the verification module 902 is further configured to: based on the third line number mapping relationship, filter out at least some of the new line numbers that failed to be mapped to the code to be submitted from the multiple new line numbers in the new line number set, and obtain an updated new line number set.

[0210] Optionally, the verification module 902 is further configured to: based on the fourth line number mapping relationship, filter at least a portion of the deleted line numbers that have been successfully mapped to the code to be submitted from multiple deleted line numbers in the deleted line number set, and obtain an updated deleted line number set.

[0211] Optionally, the aforementioned association module 903 is further configured to: create a first file content object of the version control system based on the submission statistics information; associate and store the first file content object with the code version identifier to generate a code tracking record, wherein the code version identifier is used to indicate the code version of this submission determined after the version submission operation is completed.

[0212] Optionally, in addition to all the modules mentioned above, the code tracing device also includes a rewriting module (not shown in the figure), used to: in response to a target rewrite operation in the version control system, obtain the rewritten version code that is committed after the target rewrite operation is completed; based on the target rewrite operation, determine the historical code tracing record corresponding to the historical version code identifier, wherein the historical version code identifier includes: at least one version code identifier of at least one historical commit version code associated with the target rewrite operation; use the rewritten version code to verify the historical commit statistics in the historical code tracing record, and generate rewrite statistics; associate and store the rewrite statistics with the rewrite version identifier corresponding to the rewritten version code, and update the code tracing record in the version control system.

[0213] Optionally, the rewrite module is further configured to: compare the rewritten version code with the historical file snapshots corresponding to the historical code tracing records to obtain the fifth line number mapping relationship; verify the set of historically added line numbers in the historical commit statistics based on the fifth line number mapping relationship to obtain the set of rewritten newly added line numbers; compare the rewritten version code with the historical baseline version code corresponding to the historical code tracing records to obtain the sixth line number mapping relationship; verify the set of historically deleted line numbers in the historical commit statistics based on the sixth line number mapping relationship to obtain the set of rewritten deleted line numbers; and generate rewrite statistics based on the set of rewritten newly added line numbers and the set of rewritten deleted line numbers.

[0214] Optionally, in the above rewrite module, the target rewrite operation includes one of the following: commit correction operation, rebase operation, pick operation, and commit merge operation.

[0215] Optionally, in the above rewrite module, when the target rewrite operation is a commit merge operation, the target rewrite operation is associated with multiple historical commit versions of code; the historical commit statistics are the merged information of multiple sets of commit statistics corresponding to multiple historical commit versions of code; the historical new line number set is obtained by merging multiple sets of new line numbers contained in multiple sets of commit statistics; the historical deleted line number set is obtained by merging multiple sets of deleted line numbers contained in multiple sets of commit statistics; the historical file snapshots include multiple code file snapshots in multiple sets of code change data corresponding to multiple historical commit versions of code; the historical base version code includes multiple base version codes corresponding to multiple sets of code change data.

[0216] Optionally, the rewrite module is further configured to: create a second file content object for the version control system based on rewrite statistics; associate the second file content object with the rewrite version identifier for storage, so as to generate a current code tracing record corresponding to the rewrite version identifier in the version control system; and delete the historical code tracing record corresponding to the historical version code identifier from the version control system after the current code tracing record is generated.

[0217] It should be noted that the above-mentioned acquisition module 901, verification module 902 and association module 903 correspond to steps S301 to S303 in the embodiment. The three modules and the corresponding steps implement the same instances and application scenarios, but are not limited to the content disclosed in the foregoing embodiment.

[0218] It should be noted that the above-mentioned modules or units may be hardware or software components stored in memory and processed by one or more processors. The above-mentioned modules may also be part of a device and run in a computer terminal.

[0219] It should be noted that the preferred implementation methods of this embodiment can be found in the relevant descriptions of the foregoing embodiments, and will not be repeated here. The preferred implementation methods involved in the above embodiments of this application are the same as the solutions, application scenarios, and implementation processes provided in the above embodiments, but are not limited to the solutions provided in the above embodiments.

[0220] Embodiments of this application may provide an electronic device, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the code tracing method of any of the foregoing items during runtime.

[0221] Figure 10 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 10 As shown, the electronic device 100 may include: one or more (only one is shown in the figure) processors 1002, memory 1004, memory controller, and peripheral interfaces.

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

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

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

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

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

[0227] Those skilled in the art will understand that, Figure 10 The structure shown is for illustrative purposes only. Electronic devices can also be smart mobile devices (such as smartphones), tablets, PDAs, and mobile internet devices (MIDs) and other terminal devices. Figure 10 This does not limit the structure of the aforementioned electronic device. For example, electronic device 100 may also include components that are more... Figure 10 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 10 The different configurations shown.

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

[0229] Embodiments of this application also provide a computer-readable storage medium. Optionally, in this embodiment, the computer-readable storage medium includes a stored executable program, wherein, when the executable program runs, it controls the device where the computer-readable storage medium is located to execute the code tracing method described above.

[0230] Optionally, in this embodiment, the storage medium may be located in an electronic device.

[0231] Optionally, in this embodiment, the computer-readable storage medium is configured to store an executable program, and when the executable program runs, it controls the device where the computer-readable storage medium is located to execute any of the code tracing methods described in the above embodiments.

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

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

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

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

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

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

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

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

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

Claims

1. A code tracing method, characterized in that, include: In response to a write event of target type code in the integrated development environment, obtain the code change data corresponding to the write event; In response to a version commit operation performed on the code to be committed corresponding to the target type code, the current file snapshot in the code change data is compared with the code to be committed to obtain a third line number mapping relationship. Based on the third line number mapping relationship, the set of newly added line numbers in the code change data is verified to obtain an updated set of newly added line numbers. The base version code is compared with the code to be committed to determine a fourth line number mapping relationship. Based on the fourth line number mapping relationship, the set of deleted line numbers in the code change data is verified to obtain an updated set of deleted line numbers. Based on the updated set of newly added line numbers and the updated set of deleted line numbers, commit statistics are generated. The commit statistics are used to characterize the effective code change lines provided by the target type code relative to the base version code. The commit statistics include statistics on newly added lines and statistics on deleted lines. The submission statistics are associated with the code version identifier corresponding to the version submission operation and stored to obtain code tracing records.

2. The code tracing method according to claim 1, characterized in that, Obtaining the code change data includes: Obtain the changed file path, the file code before writing, and the file code after writing corresponding to the write event; The file code before writing and the file code after writing are compared to obtain the first line number mapping relationship; Based on the first row number mapping relationship, determine the current set of newly added row numbers and the current set of deleted row numbers; The code change data is generated using the changed file path, the set of currently added line numbers, the set of currently deleted line numbers, and the current file snapshot of the written file code.

3. The code tracing method according to claim 2, characterized in that, The method further includes: Obtain the change history corresponding to the target type code, wherein the change history includes: a set of historically added line numbers, a set of historically deleted line numbers, and historical file snapshots recorded after the previous version commit operation; The historical file snapshot is compared with the current file snapshot to obtain the second line number mapping relationship; Based on the second row number mapping relationship, the historical newly added row number set and the current newly added row number set are merged to obtain a merged newly added row number set, and the historical deleted row number set and the current deleted row number set are merged to obtain a merged deleted row number set; The code change data is updated using the merged new line number set, the merged deleted line number set, and the current file snapshot.

4. The code tracing method according to claim 1, characterized in that, Based on the third row number mapping relationship, the newly added row number set is verified, and the updated newly added row number set includes: Based on the third line number mapping relationship, at least some of the newly added line numbers that failed to be mapped to the code to be submitted are filtered from the multiple newly added line numbers in the newly added line number set to obtain the updated set of newly added line numbers.

5. The code tracing method according to claim 1, characterized in that, Based on the fourth row number mapping relationship, the deleted row number set is verified, and the updated deleted row number set includes: Based on the fourth line number mapping relationship, at least a portion of the deleted line numbers that were successfully mapped to the code to be submitted are filtered from the multiple deleted line numbers in the deleted line number set to obtain the updated deleted line number set.

6. The code tracing method according to claim 1, characterized in that, The code tracking record is obtained by associating and storing the submission statistics with the code version identifier, including: Based on the submission statistics, create the first file content object of the version control system; The first file content object is associated with the code version identifier and stored to generate the code tracing record, wherein the code version identifier is used to indicate the code version of this submission determined after the version submission operation is completed.

7. The code tracing method according to claim 1, characterized in that, The method further includes: In response to a target rewrite operation in the version control system, obtain the rewrite version code that is committed after the target rewrite operation is completed; Based on the target rewrite operation, determine the historical code tracking record corresponding to the historical version code identifier, wherein the historical version code identifier includes: at least one version code identifier of at least one historical commit version code associated with the target rewrite operation; Using the rewritten version code, the historical commit statistics in the historical code tracking record are verified and processed to generate rewrite statistics. The rewrite statistics are associated with the rewrite version identifier corresponding to the rewrite version code and stored, and the code tracking record in the version control system is updated.

8. The code tracing method according to claim 7, characterized in that, Using the rewritten version code, the historical commit statistics in the historical code tracing record are verified and processed to generate the rewrite statistics, including: The rewritten version of the code is compared with the historical file snapshots corresponding to the historical code tracing records to obtain the mapping relationship of the fifth line number; Based on the fifth line number mapping relationship, the set of historically newly added line numbers in the historical submission statistics is verified to obtain the set of rewritten newly added line numbers; The rewritten version code is compared with the historical baseline version code corresponding to the historical code tracing record to obtain the mapping relationship of the sixth line number; Based on the sixth line number mapping relationship, the set of historical deleted line numbers in the historical submission statistics is verified to obtain the set of rewritten deleted line numbers; The rewrite statistics are generated based on the set of newly added rewrite line numbers and the set of deleted rewrite line numbers.

9. The code tracing method according to claim 8, characterized in that, The target rewrite operation includes one of the following: commit correction operation, rebase operation, pick operation, and commit merge operation.

10. The code tracing method according to claim 8, characterized in that, When the target rewrite operation is a commit merge operation, the target rewrite operation is associated with multiple historical commit versions of code; The historical commit statistics are the combined information of multiple sets of commit statistics corresponding to the multiple historical commit version codes; The set of historically newly added line numbers is obtained by merging multiple sets of newly added line numbers contained in the multiple sets of submitted statistical information; The set of historical deleted row numbers is obtained by merging multiple sets of deleted row numbers contained in the multiple sets of submitted statistical information; The historical file snapshots include multiple code file snapshots from multiple sets of code change data corresponding to the multiple historical commit versions of code; The historical baseline version code includes multiple baseline version codes corresponding to the multiple sets of code change data.

11. The code tracing method according to claim 7, characterized in that, Associating and storing the rewrite statistics with the rewrite version identifier, and updating the code tracing records in the version control system includes: Based on the rewrite statistics, a second file content object of the version control system is created; The second file content object is associated with the rewritten version identifier and stored to generate a current code tracing record corresponding to the rewritten version identifier in the version control system; After the current code tracing record is generated, the historical code tracing record corresponding to the historical version code identifier is deleted from the version control system.

12. A method for tracing artificial intelligence code, characterized in that, include: In response to a write event of AI code in the integrated development environment, obtain the code change data corresponding to the write event; In response to a version commit operation performed on the code to be committed corresponding to the artificial intelligence code, the code change data is verified based on the code to be committed and the baseline version code corresponding to the artificial intelligence code to obtain commit statistics, wherein the commit statistics are used to record the valid code change lines provided by the artificial intelligence code relative to the baseline version code; The submission statistics are associated with the code version identifier corresponding to the version submission operation and stored to obtain code tracing records; The process of verifying and processing the code change data based on the code to be submitted and the baseline version code corresponding to the artificial intelligence code to obtain submission statistics includes: comparing the current file snapshot in the code change data with the code to be submitted to obtain a third line number mapping relationship; verifying the set of newly added line numbers in the code change data according to the third line number mapping relationship to obtain an updated set of newly added line numbers; comparing the baseline version code with the code to be submitted to determine a fourth line number mapping relationship; verifying the set of deleted line numbers in the code change data according to the fourth line number mapping relationship to obtain an updated set of deleted line numbers; and generating the submission statistics based on the updated set of newly added line numbers and the updated set of deleted line numbers, wherein the submission statistics include statistics on newly added line numbers and statistics on deleted line numbers.

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

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

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

Images