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

Abstract

The invention discloses a code tracking method and system, electronic equipment, a storage medium and a computer program product, and relates to the technical field of artificial intelligence and computers. The method comprises the following steps: in response to a writing event of a target type code in an integrated development environment, obtaining code change data corresponding to the writing event; in response to a version submission operation executed for a to-be-submitted code corresponding to the target type code, verifying the code change data based on the to-be-submitted code and a reference version code corresponding to the target type code to obtain submission statistical information, the submission statistical information is used for representing an effective code change line provided by the target type code relative to the reference version code; and performing associative storage on the submission statistical information and a code version identifier corresponding to the version submission operation to obtain a code tracking record. According to the method and the device, the technical problems of low code tracking efficiency and poor real-time performance and accuracy in related technologies are solved.

Description

(19) State Intellectual Property Office (12) Invention Patent Application (10) Application Publication Number (43) Application Publication Date (21) Application Number 202610141373.3 (22) Application Date 2026.01.30 (71) Applicant Hangzhou Aliyun Feitian Information Technology Co., Ltd. Address 311121 Room 553, 5th Floor, Building 3, No. 969, Wenyi West Road, Wuchang Street, Yuhang District, Hangzhou City, Zhejiang Province (72) Inventors Lei Yi Ding Yu (74) Patent Agency Beijing Bohao Bairui Intellectual Property Agency Co., Ltd. 11134 Patent Attorney Zhou Xueyao (51) Int.Cl. G06F 11 / 362 (2025.01) G06F 11 / 3604 (2025.01) (54) Invention Title: Code Tracing Method, System, Electronic Device, Storage Medium, and Computer Program Product (57) Abstract: This application discloses a code tracing method, system, electronic device, storage medium, and computer program product, relating to artificial intelligence technology and computer technology. The method includes: responding to a write event of target type code in an integrated development environment, acquiring code change data corresponding to the write event; responding 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 the baseline version code corresponding to the target type code, obtaining 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, obtaining a code tracing record. This application solves the technical problems of low efficiency, poor real-time performance, and poor accuracy in code tracing in related technologies. Claims 3 pages, Description 28 pages, Drawings 7 pages, CN 121614372 A 2026.03.06 CN 1 21 61 43 72 A 1. A code tracing method, characterized in that it 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 the 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; associating and storing the commit statistics with the code version identifier corresponding to the version commit operation to obtain a code tracing record. 2. The code tracing method according to claim 1, characterized in that acquiring the code change data includes: acquiring the changed file path, the file code before writing, and the file code after writing corresponding to the write event;The code tracing method according to claim 2 is further characterized in that: the method includes: obtaining a change history record corresponding to the target type code, wherein the change history record includes: a historical set of newly added line numbers, a historical set of deleted line numbers, and a historical file snapshot recorded after the previous version commit operation; comparing the historical file snapshot with the current file snapshot to obtain a second line number mapping relationship; merging the historical set of newly added line numbers and the current set of newly added line numbers to obtain a merged set of newly added line numbers, and merging the historical set of deleted line numbers and the current set of deleted line numbers to obtain a merged set of deleted line numbers, based on the second line number mapping relationship; and updating the code change data using the merged set of newly added line numbers, the merged set of deleted line numbers, and the current file snapshot. 4. The code tracing method according to claim 1, characterized in that, based on the code to be submitted and the baseline version code, the verification processing of the code change data to obtain the 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. 5. The code tracing method according to claim 4, characterized in that, verifying the newly added line number set according to the third line number mapping relationship to obtain the updated newly added line number set includes: based on the third line number mapping relationship, filtering at least a portion of the newly added line numbers from the plurality of newly added line numbers in the newly added line number set that failed to map to the code to be submitted, to obtain the updated newly added line number set. Claims 1 / 3 Page 2 CN 121614372 A 6. The code tracing method according to claim 4, characterized in that, verifying the deleted line number set according to the fourth line number mapping relationship to obtain the updated deleted line number set includes:Based on the fourth line number mapping relationship, at least a portion of the deleted line numbers successfully mapped to the code to be committed are filtered from the multiple deleted line numbers in the deleted line number set to obtain an updated deleted line number set. 7. The code tracing method according to claim 1, characterized in that associating the commit statistics with the code version identifier to obtain the code tracing record includes: creating a first file content object of the version control system based on the commit statistics; associating the first file content object with the code version identifier to generate the code tracing record, wherein the code version identifier is used to indicate the commit version code determined after the version commit operation is completed. 8. The code tracing method according to claim 1, characterized in that the method further comprises: responding to a target rewrite operation in a version control system, obtaining the rewritten version code that is triggered to be committed after the target rewrite operation is executed; determining a historical code tracing record corresponding to a historical version code identifier based on the target rewrite operation, 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 to verify the historical commit statistics in the historical code tracing record, generating rewrite statistics; 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. 9. The code tracing method according to claim 8, characterized in that, using the rewritten version code, verifying the historical commit statistics in the historical code tracing record to generate the rewrite statistics includes: comparing the rewritten version code with the historical file snapshots corresponding to the historical code tracing record to obtain a fifth line number mapping relationship; verifying the set of historically added line numbers in the historical commit statistics according to the fifth line number mapping relationship to obtain a set of rewritten newly added line numbers; comparing the rewritten version code with the historical base version code corresponding to the historical code tracing record to obtain a sixth line number mapping relationship; verifying the set of historically deleted line numbers in the historical commit statistics according to the sixth line number mapping relationship to obtain a set of rewritten deleted line numbers; and generating the rewrite statistics based on the set of rewritten newly added line numbers and the set of rewritten deleted line numbers. 10. The code tracing method according to claim 9, characterized in that, the target rewrite operation includes one of the following: a commit correction operation, a rebase operation, a selection operation, or a commit merge operation. 11. The code tracing method according to claim 9, wherein 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 the multiple historical commit version codes; the historical new line number set is obtained by merging multiple sets of new line numbers contained in the multiple sets of commit statistics; the historical deleted line number set is obtained by merging multiple sets of deleted line numbers contained in the multiple sets of commit statistics; the historical file snapshots include multiple code file snapshots in the multiple sets of code change data corresponding to the multiple historical commit version codes; the historical baseline version code includes multiple baseline version codes corresponding to the multiple sets of code change data. 12. The code tracing method according to claim 8, characterized in that, associating and storing the rewrite statistics with the rewrite version identifier and updating the code tracing record in the version control system includes: creating a second file content object of the version control system based on the rewrite statistics; associating and storing the second file content object with the rewrite version identifier to generate a current code tracing record corresponding to the rewrite version identifier in the version control system; and deleting a historical code tracing record corresponding to the historical version code identifier from the version control system after the current code tracing record is generated. 13. A method for tracing artificial intelligence code, characterized in that, it includes: in response to a write event of artificial intelligence code in an integrated development environment, obtaining 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, 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 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. 14. An electronic device, characterized in that it comprises: a memory storing an executable program; and a processor connected to the memory for running the program, wherein the program, when running, performs the method according to any one of claims 1 to 13. 15. A computer-readable storage medium, characterized in that the computer-readable storage medium includes a stored executable program, wherein, when the executable program runs, it controls the device containing the computer-readable storage medium to perform the method according to any one of claims 1 to 13. 16. A computer program product, characterized in that it comprises a computer program, which, when executed by a processor, implements the method according to any one of claims 1 to 13. Claims 3 / 3 Page 4 CN 121614372A Code Tracing Method, System, Electronic Device, Storage Medium, and Computer Program Product Technical Field

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

[0002] In the software development process, accurate measurement and tracing of code from specific sources (such as specific contributors or specific tools) is a common requirement for improving project management and quality assessment efficiency. This requires the system to automatically and accurately associate the changed parts of the code with specific sources. However, existing technical solutions usually rely on manual post-event analysis or external tools independent of the version control process for code tracing, which has the following drawbacks: file-level comparison leads to low tracing accuracy, low automation of the tracing process leads to low tracing efficiency, and poor synchronization between code tracing results and code submission actions leads to poor real-time tracing.

[0003] To address the above problems, no effective solution has been proposed yet. Summary of the Invention

[0004] Embodiments of this application provide 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 of 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; associating and storing the commit statistics with the 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; associating and storing the commit statistics with the 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 of the above-mentioned methods when it runs.

[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 one of the above.

[0008] According to another aspect of the embodiments of this application, a computer program product is provided, including a computer program, which, when executed by a processor, implements the code tracing method of any one of the above. Specification 1 / 28 pages 5 CN 121614372 A

[0009] In the embodiments of this application, in response to a write event of target type code in an 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 effective 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 a code tracing record. It is noteworthy that the embodiments of this application ensure the real-time nature of the tracking response by immediately acquiring code change data in response to write events; by automatically triggering subsequent processing in response to version commit operations, the tracking process is integrated into the development commit workflow, achieving automation; by verifying the change data based on the code to be committed and the base version code during commit, invalid or conflicting change lines are eliminated, thereby ensuring the line-level accuracy of the statistics; in addition, by directly associating and storing the refined commit statistics with the version identifier of the current commit, the tracking results are ensured to correspond precisely with specific code versions, achieving a relatively strict synchronization between tracking data and version history. Thus, the embodiments of this application achieve the goal of automating and line-level tracking of target type code through the linkage between code tracking, code writing, and code commit, thereby achieving the technical effect of improving code tracking efficiency, tracking real-time and accuracy, and thus solving the technical problems of low code tracking efficiency, poor real-time and accuracy of related technologies.

[0010] It is noteworthy that the above general description and the following detailed description are only for illustrative purposes and do not constitute a limitation of this application.

[0011] The accompanying drawings, which are included to provide a further understanding of this application and constitute a part of this application, illustrate exemplary embodiments of this application and, together with their description, serve to explain this application and do not constitute an improper limitation of this application. In the drawings:

[0012] FIG1 is a hardware structure block diagram of a computing device for implementing a code tracing method;

[0013] FIG2 is a schematic diagram of a system structure in an application scenario;

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

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

[0016] Figure 5 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 is a schematic diagram of an optional submission verification process when AI code is submitted according to an embodiment of this application;

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

[0019] Figure 8 is a schematic diagram of a special process after an optional submission merging operation according to an embodiment of this application;

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

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

[0022] To enable those skilled in the art to better understand the solutions of this application, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments in this application, all other embodiments obtained by those skilled in the art without inventive effort should fall within the scope of protection of this 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 device 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 these processes, methods, products, or devices.

[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, stored data, displayed data, 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 related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0025] First, some nouns or terms appearing in the description of the embodiments of this application are subject to the following interpretation.

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

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

[0028] Git Hook: A callback mechanism provided by the Git version control system that automatically executes a preset script when a specific event occurs.

[0029] prepare-commit-msg hook: 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] post-commit hook: A type of Git hook that is triggered after a commit operation is completed and is often used to perform subsequent processing tasks.

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

[0032] Git Reference (Git Ref): A pointer in Git to a specific commit or other object, often used to store metadata.

[0033] JSON Lines (JSONL): A data storage format where each line is an independent JSON object, facilitating line-by-line processing.

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

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

[0036] Squash: An operation in Git that merges 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 presented here. Specification 3 / 28 pages 7 CN 121614372

[0039] The method embodiment provided in Embodiment 1 of this application can be executed in a mobile terminal, computer terminal, or similar computing device. Figure 1 is a hardware structure block diagram of a computing device for implementing a code tracing method. As shown in Figure 1, the computing device 10 may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) (processor 102 may include, but is not limited to, a microprocessor (MCU) or a programmable gate array (FPGA), 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 the structure shown in Figure 1 is only schematic and does not limit the structure of the above-mentioned electronic device. For example, the computing device 10 may also include more or fewer components than those shown in FIG. 1, or have a different configuration than those shown in FIG. 1.

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

[0042] The memory 104 may 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 the embodiments of this application. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, that is, to implement the above-described code tracing method. 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, memory 104 may further include memory remotely located relative to processor 102, which can be connected to computing device 10 via a network. Examples of such networks include, but are not limited to, the Internet, 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 one example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0044] The display shown in FIG1 may 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] The hardware structure block diagram shown in FIG1 can serve not only as an exemplary block diagram of the computing device 10 described above, but also as an exemplary block diagram of the server described above. In an optional embodiment, FIG2 is a schematic diagram of a system structure for an application scenario using the computing device shown in FIG1 as a transmitter or receiver. As shown in FIG2, 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 electronic connection. In one optional embodiment, the computing device 10 can be any mobile computing device, etc. The data network connection can be a local area network connection, a wide area network connection, an Internet connection, or other types of data network connections. The computing device 10 can execute network services to connect to a network service executed by a server (e.g., a security server) or a group of servers 20. The network server is a network-based user service, such as a social network, cloud resources, email, online payment, or other online applications. Specification 4 / 28 pages 8 CN 121614372 A

[0046] In the above operating environment, this application provides a code tracing method as shown in FIG3. FIG3 is a flowchart of a code tracing method according to an embodiment of this application. As shown in FIG3, 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 above integrated development environment is an application for writing, modifying, debugging, and testing software code. The above integrated development environment provides an integrated interface with functions such as a code editor, project management tools, compiler, and debugger. In application scenarios, the aforementioned integrated development environment (IDE) can be locally installed software, a cloud-based IDE running on a browser or remote server, or a lightweight code editor that exists as a plugin for other applications.The development environment can serve as a carrier for the code tracing method to run and for events to be triggered.

[0049] The target type code mentioned above refers to code segments or blocks that have specific attributes or whose contributions need to be tracked. The target type code mentioned above is the specific object of the code tracing operation. The attributes of the target type code can be defined according to actual tracing needs. For example, the 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, a specific branch, or a specific template, and code marked with specific comments or tags. The embodiments of this application do not limit the specific type definition criteria of the target type code, which can cover code types that are distinguished and marked based on code source, author, generation method, or other attributes.

[0050] The write event mentioned above refers to the operation action of creating, inserting, modifying, or replacing the target type code in the code editor of the integrated development environment. The write event mentioned above can serve as the initial trigger signal for starting the code tracing process. The write event can be triggered by direct input from the user or automatically triggered by auxiliary tools (such as code completion and code refactoring) within the integrated development environment. In application scenarios, for example, when an AI coding assistant inserts a generated code snippet into the editor cursor position, a write event is generated; another example is when a developer pastes a code block from a specific source, which also generates a write event.

[0051] The above-mentioned code change data is a collection of information used to describe the changes in code content introduced by this write event. The code change data can contain a variety of fields, and the specific set of fields can be determined according to the application scenario requirements. For example, the code change data may include, but is not limited to: the path of the modified file, the location information of the change (e.g., the starting line number, the ending line number, the range of characters changed, etc.), the specific code content snippets before and after the change, the timestamp, the tool identifier or author information that triggered the write event. The above-mentioned code change data can be stored in a variety of 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, and when it is determined that a write event has been triggered, it obtains the code change data corresponding to the write event. The code change data can be obtained in a variety of ways. For example, code change data 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, for different types of IDEs and different target code definition methods, the embodiments of this application can employ corresponding technical means to obtain code change data.

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

[0054] Step S302, in response to the version submission operation performed on the code to be submitted corresponding to the target type code, the code change data is verified based on the code to be submitted and the base version code corresponding to the target type code, and submission statistics are obtained, wherein the submission statistics are used to characterize the effective code change lines provided by the target type code relative to the base version code.

[0055] The above-mentioned code to be submitted refers to the code content in the current development directory that has been modified and is prepared to be saved to the version history. The code to be submitted is the object to be processed by the version submission operation. The above-mentioned version submission operation refers to the action of issuing an instruction to the version control system, requesting that the code to be submitted be created as a new, permanent version snapshot. For example, in the Git version control system, the version submission operation is usually completed by executing the Git commit command. Version commit operations can serve as trigger events for subsequent verification processes.

[0056] The aforementioned baseline version code refers to the code content of a specific version that has existed in the version history and has been selected as a comparison benchmark. The baseline version code can be the latest state of the file in the version control system before the target type code is written. For example, the baseline version code can 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 made by the target type code.

[0057] In application scenarios, during the time interval between the target type code being written and the version commit operation being triggered, the code to be committed may be actively modified by the developer or other tools. At this time, 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.

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

[0059] In particular, the above statistics may also include: various categories of statistical data corresponding to different types of change lines in the valid code change lines. For example, the statistics may include new line statistics and deleted line statistics. The new line statistics include: number of new lines, percentage of new lines, contribution of new lines, etc., and the deleted line statistics include: number of deleted lines, percentage of deleted lines, contribution of deleted lines, etc.

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

[0061] In application scenarios, during the verification process, the code change data is reviewed using the code to be committed and the baseline version code. The verification process can be implemented in various ways. For example, in one implementation, the verification process can be automatically completed using the hook mechanism provided by the version control system. In the Git system, a first hook script (type can be pre-commit or prepare-commit-msg) can be configured. When the user executes the Git commit command, this first hook script is automatically triggered. When the first hook script is executed, the system first obtains the code content in the current staging area as the code to be committed. Then, it obtains the baseline version code through Git commands. Next, the hook script reads the code change data. Finally, by calling a file difference comparison tool or library, the information in the code to be committed, the baseline version code, and the code change data is cross-referenced to identify valid change lines still existing in the code to be committed, thereby generating commit statistics.

[0062] For example, in another implementation, the verification process can be completed through deep integration of the integrated development environment (IDE) and the version control system (Version Control System Specification, page 6 / 28, 10 CN 121614372 A). When the user clicks the "Commit" button in the graphical interface of the IDE, the IDE triggers a verification callback before building the commit package internally. This callback function retrieves the code to be committed from the workspace, retrieves the base version code from the version control plugin, and reads code change data from memory or temporary files. The IDE uses its built-in code comparison engine to execute the verification logic and displays the commit statistics to be generated in a pop-up window or updated interface.

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

[0064] Step S303, associate the submission statistics with the code version identifier corresponding to the version submission operation to obtain the code tracking record.

[0065] The above-mentioned code version identifier is a string or number sequence automatically generated by the version control system for each successfully executed version submission operation, used to uniquely identify the code version created in this submission. 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 above-mentioned code version identifier serves as an index to anchor the statistics to a specific code history node.

[0066] The above-mentioned association storage refers to the operation process of establishing and persistently saving the correspondence between the submission statistics and the code version identifier. Association storage aims to ensure that the contribution statistics of each submission can be saved reliably for a long time and accurately bound to the corresponding code version for future query, audit or analysis. The code tracing records mentioned above are data recorded after the associated storage is completed. For example, a code tracing record can be a structured data record that contains or implicitly associates a code version identifier.

[0067] In application scenarios, the process of associating and storing submission statistics with code version identifiers can be implemented in various ways. For example, it can be done through the object storage mechanism of the version control system itself, or through an external database or file system independent of the version control system, or by utilizing the extended attributes or metadata mechanism of the version control system. That is to say, 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 the above step S303, the embodiments of this application have completed the storage link of the tracing process. This storage link binds the verified and accurate code change statistics results with the unique code version identifier in the version control system. The resulting code tracing records ensure that for any historical code version, the specific contribution of the target type 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 accurate measurement of contributions of specific types of code. In particular, in scenarios such as evaluating the performance of AI coding assistants, tracking contributions of specific teams or developers, and analyzing the impact of third-party codebase introductions, the above-mentioned code tracing method can effectively solve the contribution statistics model.This addresses the issues of ambiguity and version disconnect. For example, in development teams employing AI programming assistants, the aforementioned code tracing method can automatically count the number of AI-generated lines of code 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 for specific licenses. By introducing real-time recording based on write events, automatic verification based on commit operations, and strong association storage with version identifiers, the embodiments of this application can achieve the technical effects of statistical automation, result accuracy, and data versioning in different development management scenarios.

[0070] Through the above steps S301 to S305, this application embodiment ensures the real-time nature of the tracking response by instantly obtaining code change data in response to the write event; by automatically triggering subsequent processing in response to the version submission operation, the tracking process is integrated into the development submission workflow, achieving automation; by verifying the change data based on the code to be submitted and the base version code during submission, invalid or conflicting change lines are eliminated, thereby ensuring the line-level accuracy of the statistics; in addition, by directly associating and storing the refined submission statistics information with the version identifier of the current submission, the tracking results are ensured to correspond precisely with the specific code version, achieving a relatively strict synchronization between the tracking data and the version history. Thus, this application embodiment achieves the purpose of automating and line-level tracking of target type code through the linkage between code tracking, code writing, and code submission, thereby achieving the technical effect of improving code tracking efficiency, tracking real-time and accuracy, and thus solving the technical problems of low code tracking efficiency, poor real-time and accuracy of 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 above optional embodiments, the artificial intelligence model refers to a trained machine learning model. This artificial intelligence model can automatically generate or suggest programming code based on natural language descriptions, code context, or other inputs. The artificial intelligence model used for code generation can be an application example of a large language model in the field of code generation.

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

[0075] In the application scenario, the code generated by the artificial intelligence model is usually integrated into the system through a specific interface or plugin.In the development environment, when developers use the functions of these specific interfaces or plugins, the artificial intelligence model provides code snippet suggestions, which developers can choose to accept. When a suggestion is accepted, a write event of the target type code is triggered.

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

[0077] By concretizing the target type code into code generated by the 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 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 that is 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 above optional embodiment, the changed 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 is written. The changed file path is used to identify the file modified by the target type code. For example, the changed file path can be a relative path or an absolute path.

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

[0081] In application scenarios, obtaining the changed file path, pre-write file code, and post-write file code is a prerequisite for performing detailed difference analysis. In specific implementation, the aforementioned... can be obtained through the application programming interface provided by the integrated development environment.Information. For example, when the plugin listens to a target type code write event, it can directly obtain the path of the modified file, the text content of the editor before the event is triggered (as the file code before writing), and the new text content after the event is completed (as the file code after writing) from the event callback parameters. For another example, it can also obtain the file code after writing and the file code before writing by listening to the file system's save operation and simultaneously reading the current content of the file and retrieving its previous version from the cache at the moment the file is saved.

[0082] The above-mentioned first line number mapping relationship is a data relationship obtained by comparing the file code before writing and the file code after writing line by line. This first line number mapping relationship describes the corresponding change from the "before writing" line number to the "after writing" line number. Specifically, the comparison process will identify the lines that remain unchanged before and after writing, the lines that only exist in the file code after writing (i.e., newly added lines), and the lines that only exist in the file code before writing (i.e., deleted lines).

[0083] In application scenarios, the comparison between the file code before writing and the file code 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 built-in string diff library of the programming language, the diff command provided by the operating system, or a preset diff 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 above-mentioned current added line number set is a set of line numbers of the "added" type selected from all changes based on the first line number mapping relationship. This current added set records the position of the newly generated code line in the "file code after writing" in this write event. Similarly, the above-mentioned current deleted line number set is a set of line numbers of the "deleted" type selected from all changes based on the first line number mapping relationship. This current deleted line number set records the position of the code line removed in the "file code before writing" in this write event.

[0085] In specific implementations, the line number set can be represented using various data structures. For example, a range of consecutive line numbers can be represented by an interval consisting of the starting and ending lines (e.g., [10, 15]) to simplify the data. For discrete single lines, a single number can be used. Therefore, the current set of newly added line numbers and the current set of deleted line numbers can be represented as a list of numbers or intervals.

[0086] The aforementioned current file snapshot refers to a complete copy of the file code after it has been written. 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. This involves changing the file path, current...The newly added line number set, the currently deleted line number set, and the current file snapshot are organized according to a predefined structure to obtain code change data.

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

[0089] Based on the above steps S311 to S314, this application embodiment 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, which can accurately identify line-level changes directly caused by the target type code, and encapsulates the change content, location information, and complete snapshot into structured data. This provides high-quality, fine-grained basic 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 a historical file snapshot recorded after the previous version commit operation; Step S342, comparing the historical file snapshot 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 above optional embodiment, the change history is for the target type code in the same file (i.e., the file pointed to by the changed file path), which has been recorded but not yet committed before the current write event. The change history is used to maintain and accumulate the change status between multiple consecutive write events. 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 code that the target type code had been added to in the same file but had not yet been committed before this write event. The aforementioned set of historical deleted line numbers records the line numbers of code that the target type code had been deleted to in the same file but had not yet been committed before this write event. The aforementioned historical file snapshot is used to generate historical newly added lines.The complete file content corresponding to the line number set and the historical deleted line number set. The historical file snapshot is used as a comparison benchmark to track the position changes of the line numbers in subsequent file modifications.

[0093] In the application scenario, obtaining the change history occurs after step S311 or in parallel with step S311. When a write event for a file is detected, the system will try to find whether there is an uncommitted change history for the file. For example, the system can search for and load the change history in a cache dictionary with the file path as the key or a temporary file named with the file path, based on the changed file path.

[0094] The above-mentioned second line number mapping relationship is a data relationship obtained by comparing the historical file snapshot with the current file snapshot line by line. The second line number mapping relationship describes the mapping between the line numbers of the "historical file snapshot" and the line numbers of the "current file snapshot". Since the file may be changed by other modifications (including modifications to non-target type code) between two write events, resulting in the overall offset of the line numbers or content reorganization, it is necessary to correct the effective position of the historical line number set in the current file through the second line number mapping relationship.

[0095] The historical file snapshot is compared with the current file snapshot, and a difference algorithm similar to step S312 can be used. 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 historical newly added line numbers, the second line number mapping relationship is used to try to map each newly added line number to the coordinate system of the current file snapshot. If a historical newly 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 current newly added line numbers generated by this write event to form a merged set of newly added line numbers. For the set of historical deleted line numbers, the second line number mapping relationship is also used for conversion and verification. If the content corresponding to a historical deleted line number is deleted in the historical snapshot and does not appear in the current snapshot, the deletion record is still valid and should be retained. Then, the retained historical deleted line numbers are merged with the current deleted line number set generated by the current write event, forming a merged deleted line number set (page 14, CN 121614372 A, specification 10 / 28).

[0097] In particular, the above merging process may need to handle mapping failures. For example, if a historical newly 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, so the line should no longer be counted in the valid additions of the target type code and should be removed from the history. If a historical 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 set of newly added line numbers, the set of deleted line numbers, and the current file snapshot means replacing the set of newly added line numbers and the set of deleted line numbers generated based on a single write event with the merged set of line numbers reflecting all uncommitted cumulative changes, and using the current file snapshot as the base snapshot for the update, together forming the updated code change data. The updated code change data will be used for subsequent commit verification.

[0099] Based on the above steps S341 to S344, this application embodiment provides a scheme for processing multiple target type code write events in the same file before a single version commit. This scheme can accurately accumulate and coordinate multiple modifications by maintaining and iteratively updating the change history, ensuring the integrity of commit statistics, avoiding the loss or duplicate statistics of some changes due to multiple edits, and improving 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 newly added line statistics and deleted line statistics.

[0101] In the above optional embodiment, the above-mentioned current file snapshot is the complete content of the file recorded in the code change data after the target type code writing event is completed. 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 from the time the target type code was written until the commit. These subsequent changes may be introduced by manual editing by the developer or automatic modifications by other tools.

[0102] The third line number mapping relationship 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 relationship 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, the third line number mapping relationship can be obtained by calling the difference calculation function. For example, the system can pass the current file snapshot and the content of the code to be committed to a difference algorithm library, which returns a change list that shows each line-level change from the current file snapshot to the code to be committed and its mapping.

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

[0105] The above 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. The fourth line number mapping relationship describes the correspondence from the line numbers in the base version code to the line numbers in the code to be committed. The above comparison aims to determine the status of each line of content in the base version code in the code to be committed.

[0106] The deleted line number set in the above code change data records the position of the lines deleted by the target type code in the coordinate system of the base version code. The deleted line number set 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 added line number set and the updated deleted line number set. The commit statistics can clearly and structurally represent the valid changes made by the target type code relative to the base version code and which have been committed. For example, the commit statistics can also be a JSON object containing fields such as filePath, finalAddedLines (a list of valid added line numbers), and finalDeletedLines (a list of valid deleted line numbers). Furthermore, the total number of added lines and the total number of deleted lines can be further calculated as statistical summary information in the commit statistics.

[0108] In particular, the above commit statistics can structurally include statistics on added lines and statistics on deleted lines. The new line statistics are used to record valid lines of code added by the target type code that have been verified and retained. They typically include at least a list of line numbers for valid new lines and can be further used to calculate statistical measures such as the total number of new lines. The deleted line statistics are used to record valid lines of code deleted by the target type code that have been verified and confirmed. They typically include at least a list of line numbers for valid deleted lines and can be further used to calculate statistical measures such as the total number of deleted lines. Based on this, the above 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 the above steps S321 to S325, this application embodiment 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, through two independent comparisons and mapping analyses. This can accurately eliminate invalid changes that are overwritten or restored between code writing and submission, thereby ensuring that the submission statistics accurately reflect the true contribution of the target type code in this submission version, and 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 an updated set of newly added line numbers, 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 set of newly added line numbers to obtain an updated set of newly added line numbers.

[0111] In the above optional embodiments, the specific situation of the above mapping failure is as follows: for a specific newly added line number in the set of newly added line numbers, when trying 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 will traverse each newly added line number (or line number range) in the set of newly added line numbers. For each newly added line number traversed, 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 committed that corresponds to the newly added line number traversed (if there is no line number corresponding to the newly added line number in the code to be committed, return "-1"). Based on this, the system makes a judgment based on the query results: 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 traversing the mapping, the system removes all newly added line numbers that failed to be mapped from the set of newly added line numbers. Then, the retained newly added line numbers that were successfully mapped constitute the updated set of newly added line numbers. Specification 12 / 28 pages 16 CN 121614372 A

[0114] Through the above steps S3221, the embodiments of this application provide a specific and automated filtering mechanism. This mechanism can accurately identify and remove invalid newly added lines that have been overwritten or deleted by subsequent modifications during the verification stage before submission. This ensures that the new line statistics in the commit information strictly include those lines that have been incorporated into 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 deleted line number set is verified according to the fourth line number mapping relationship to obtain an updated deleted line number set, including the following method steps: Step S3241, based on the fourth line number mapping relationship, at least some deleted line numbers that are successfully mapped to the code to be submitted are filtered from multiple deleted line numbers in the deleted line number set to obtain an updated deleted line number set.

[0116] In the above optional embodiment, the above-mentioned successful mapping refers to the following specific situation: for a certain deleted line number in the deleted line number set, when trying to find its corresponding line number in the code to be submitted through the fourth line number mapping relationship, a valid and corresponding line number can be found. Successful mapping usually means that the line was not actually removed during the change process from the base version code to the code to be submitted, or it was removed and then restored.

[0117] In the application scenario, the system will traverse each deleted line number (or line number range) in the deleted line number set. For each deleted line number traversed, 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 traversal (if there is no line number in the code to be submitted that corresponds to the deleted line number, return "-1"). Based on this, the system makes a judgment based on the query result: if a valid line number is found, it means that the line still exists in the code to be submitted and the mapping is successful; if the query returns "-1", it means that the line no longer exists in the code to be submitted and the mapping fails.

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

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

[0120] As an optional embodiment, in step S303, the submission statistics and code version identifier are associated and stored to obtain a code tracing record, including the following method steps: Step S331, based on the submission statistics, 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 code version determined after the version submission operation is completed.

[0121] In the above optional embodiments, the above version control system refers to a software tool used to manage the history of source code versions. The above version control system can be Git, Mercurial, Subversion, etc. The version control system usually uses an object database to store data.

[0122] The above commit statistics are structured data that represents valid changes to the target type code 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. Inside the version control system, the data unit used to store the file content can be a Blob object.

[0123] In the application scenario, the process of creating the first file content object is automatically completed by the system. In specific implementation, the commit statistics are serialized into a string of a specific format, as specified in the system specification on page 13 / 28 of CN 121614372 A. For example, the system can convert the commit statistics into a JSON string or an XML string. Then, the system calls the underlying commands or application interfaces provided by the version control system to create the first file content object. For example, in the Git system, a preset command can be invoked, taking the above string as input, to obtain the hash value corresponding to the string, and the string and hash value are saved as a new Blob object in the Git object database. This newly created Blob object serves as the first file content object.

[0124] Further, when the first file content object is associated 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 persistently saved to obtain code tracing records.

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

[0126] In application scenarios, the above-mentioned associated storage can be implemented in various ways. An exemplary way is to utilize the reference mechanism of the version control system. For example, in Git, you can create a new reference using the `Git update-ref` command in a second hook script (such as a post-commit hook). The name of this new reference can include a code version identifier, for example, "refs / ai-stats / ".<commit‑hash> The value of this new reference can be set to the first file content pair.The hash value of the object. Based on this, in the subsequent process, the corresponding reference can be found through the code version identifier, and then the Blob object (i.e., the first file content object) storing the commit statistics information can be found through the reference. In addition, if the version control system supports custom commit metadata, the hash value of the first file content object can be directly recorded in the metadata of this commit object to achieve a tighter binding.

[0127] Through the above steps S331 and S332, the embodiments of this application provide a reliable code tracing record persistence scheme that is deeply integrated with the version control system. This scheme uses the object storage and reference mechanism of the version control system itself to persistently store the commit statistics information and the code version identifier, 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 executed; 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 above optional embodiment, 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 will change the code content, commit metadata, or commit history order of one or more existing commits and generate new commit version code. For example, target rewrite operations include, but are not limited to: amend, rebase, cherry-pick, and squash. The rewritten version code mentioned above refers to the file content of the new version created and committed to the version history after the target rewrite operation is completed.

[0130] In application scenarios, when a user or automated process executes the above target rewrite operation, the system will automatically detect the rewrite event through the third hook script of the version control system (such as the post-rewrite hook). Subsequently, the system extracts the file content corresponding to the newly generated commit of this target rewrite operation from the code version repository, that is, the rewritten version code. Specification 14 / 28 pages 18 CN 121614372 A

[0131] The above historical version code identifier is the unique identifier of one or more original commits affected by the target rewrite operation.The aforementioned historical code tracing records are pre-stored code tracing records associated with these historical version code identifiers, and these historical code tracing records contain historical commit statistics. The process of determining historical code tracing 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 searches for and reads the corresponding historical code tracing records from the storage space of the version control system based on these version identifiers.

[0132] When using the rewritten version code to verify the historical commit statistics, the verification processing method is similar to the verification processing method in step S302. Specifically, the system uses the rewritten version code, historical file snapshots, and historical baseline version code to perform verification processing on the historical commit statistics, including line number mapping, new line verification, and deleted line verification, in order to generate rewrite 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 of the new commit created by the target rewrite operation (i.e., the rewrite version identifier) ​​and stored in persistent storage space. The above association storage operation will generate a new code tracing record.

[0134] Through the above steps S351 to S354, this application embodiment provides an extended scheme for processing version history rewrite operations. This scheme can automatically respond to target rewrite operations in the version control system. By obtaining the rewrite version code and determining the associated historical code tracing record, the historical commit statistics can be re-verified using the rewrite version code to generate rewrite statistics that accurately reflect the code status after rewriting. Furthermore, by associating the rewrite statistics with the new rewrite version identifier, the automatic migration and updating of code tracing records after version history rewrite is realized. This effectively solves the problem that the tracking data immediately becomes invalid or broken after the code history is rewritten in traditional solutions, ensuring the persistence, consistency and strong correlation between the code tracing records and the dynamically evolving code history, and 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 records 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 records 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 records to obtain the sixth line number mapping relationship; Step S3534, according to the sixth 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 records to obtain the sixth line number mapping relationship;The set of historical deleted line numbers in the historical commit statistics is verified to obtain the set of rewritten deleted line numbers; step S3535, based on the set of rewritten new line numbers and the set of rewritten deleted line numbers, rewrite statistics are generated.

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

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

[0138] Further, the set of historically added line numbers is verified according to the fifth line number mapping relationship to obtain the set of rewritten new line numbers. Specifically, the system will traverse each line number in the set of historically added line numbers and query 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 version of CN 121614372 A on page 15 / 28 of the rewritten specification, and it (or the mapped new line number) should be added to the set of rewritten new line numbers; if the mapping fails, it means that the line has been removed during the rewriting process and the line number should be filtered out.

[0139] The rewritten version code is compared with the historical baseline version code to determine the real difference between the rewritten version and the baseline with the original baseline code as a reference. By comparing the rewritten version code and the historical baseline version code line by line, the sixth line number mapping relationship is obtained. The sixth line number mapping relationship 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] Further, the historical deleted line number set is verified according to the sixth line number mapping relationship to obtain the rewritten deleted line number set. Specifically, the system will traverse each line number in the historical deleted line number set and query the sixth line number mapping relationship. If a historical deleted line number can be successfully mapped to a valid line number in the rewritten version code, it means that the line has been restored in the rewritten version and should be filtered out; if the mapping fails, it means that the line is still in the deleted state in the rewritten version and should be retained in the rewritten deleted line number set.

[0141] Further, based on the rewritten new line number set and the rewritten deleted line number set obtained after verification, a rewritten version is generated.Statistical information. The format and meaning of the rewrite statistics are consistent with the submission statistics. The rewrite statistics accurately reflect the update status of the contribution of the target type code after the historical rewrite operation.

[0142] Through the above steps S3531 to S3535, this application embodiment provides a verification process for historical rewrite scenarios. This process reuses line number mapping and verification logic. By comparing the rewritten version code with the historical snapshot and historical benchmark respectively, the automatic correction and migration of the original statistical data are realized. This ensures that even after complex version history changes, the code tracing record can still maintain strict synchronization and accurate correspondence with the rewritten updated code version.

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

[0144] In the above optional embodiment, the above target rewrite operation is a specific command in the version control system (e.g., Git) used to modify the existing commit history. The aforementioned target rewrite operation may change the code content, commit order, or commit structure, potentially leading to a discrepancy between the recorded code contribution statistics and the new code version. Therefore, this application embodiment can address the target rewrite operation accordingly.

[0145] The aforementioned commit correction operation (e.g., the amend operation in Git) is used to modify the content or metadata of the most recent commit. During the aforementioned operation, the user may modify the committed content containing the target type code during the correction. Therefore, after the commit correction operation is executed, the historical commit statistics associated with the operation are re-verified and calculated to ensure that the tracking information remains consistent with the corrected code version.

[0146] The aforementioned rebase operation (e.g., the rebase operation in Git) is used to reapply the commit sequence on one branch to another base point. During the aforementioned rebase operation, code may be modified when resolving code conflicts, causing changes in the lines of the target type code. Therefore, after the rebase operation is executed, the historical commit statistics involved in the operation need to be re-verified and calculated.

[0147] The above-mentioned pick operation (e.g., the cherry-pick operation in Git) is used to apply the changes of a certain commit to the current branch individually. During the above-mentioned pick operation, due to the potential conflicts and subsequent modifications when applied to different code contexts, the contribution of the target type code may change. Therefore, after the pick operation is executed, the historical commit statistics of the selected commit need to be re-verified and calculated.

[0148] The above-mentioned commit merge operation (e.g., the squash operation used when performing interactive rebase in Git) is used to merge multiple consecutive commits into one commit. During the above-mentioned commit merge operation, the contribution of the target type code in multiple commits is... (See page 16 / 28 of the specification, 20 CN)121614372 A Changes may affect or offset each other (for example, code added in one commit may be deleted in a subsequent commit). Therefore, after the commit merge operation is executed, it is necessary to merge the statistics of 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 updates for various rewrite operations in version rewrite scenarios. The combination of the above-mentioned commit correction operation, rebase operation, picking operation, and commit merge operation's limitation, reverification, and migration mechanisms can ensure that after various rewrite operations are executed, the code tracking method can actively and accurately update the statistics, thereby improving the robustness and practicality of the code tracking scheme 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 version codes; the historical commit statistics are the merged information of multiple sets of commit statistics corresponding to multiple historical commit version codes; 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 version codes; the historical base version code includes multiple base version codes corresponding to multiple sets of code change data.

[0151] In the above optional embodiment, when the target rewrite operation is a commit merge operation, the system will merge multiple consecutive, independent historical commits into a new single commit. Therefore, the 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] In order to generate accurate rewrite statistics for the merged new commits, the system 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 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 the relevant fields in the multiple sets of statistics.

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

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

[0155] The above-mentioned historical file snapshots are not the content of a single file, but include multiple code file snapshots saved in multiple sets of code change data corresponding to each historical commit version code. These snapshots record the file state at the time of completion of the corresponding historical commit.

[0156] The above-mentioned historical baseline version code is also not a single version, but includes the respective baseline version code on which each set of code change data is based when it is recorded. Since different historical commits may be based on different commit baselines, the baseline version codes of these historical commits may be different.

[0157] Through the above limitations, the embodiments of this application clarify the data sources and data structures that the system needs to integrate when processing the specific scenario of commit merging operation, thereby ensuring 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 merging, thereby ensuring that the migration and recalculation of code contribution statistics can still maintain correctness in complex commit merging scenarios. Instruction manual, pages 17 / 28, 21 CN 121614372 A

[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 above optional embodiment, the above object is an internal data object created and managed by the version control system. The second file content object is used to persistently store structured rewrite statistics information in the database of the version control system. The process of creating the second file content object is: taking the rewrite statistics information (e.g., a JSON format string) as input, and submitting it 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 the hash value as a new data object in the database. This newly created data object can then be used as the second file content object.

[0160] The aforementioned rewrite version identifier is a unique identifier generated after the target rewrite operation is completed and newly committed. Associating the second file content object with the rewrite version identifier means establishing a way to store the second file content object from the rewrite version identifier.The direct or indirect reference relationship between file content objects enables the location and access of the corresponding rewrite statistics information 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 the 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 trace record corresponding to the rewrite version identifier.

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

[0162] Through the above steps S3541 to S3543, the embodiments of this application provide an atomic and secure storage update strategy. This strategy ensures that code tracing data is not lost or in an inconsistent intermediate state during the rewriting of version history by first creating new objects and establishing new references, and then deleting old references. The above mechanism enables code tracing records to be automatically and reliably updated synchronously with the historical evolution of code versions, thereby 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 above operating environment, this application also provides a method for tracing artificial intelligence code, including: in response to a write event of artificial intelligence code in the integrated development environment, obtaining 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, verifying the code change data based on the code to be committed and the base 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 base version code; associating and storing the commit statistics with the code version identifier corresponding to the version commit operation to obtain code tracing records.

[0164] In software development environments that utilize AI-assisted programming, accurately tracking and measuring the code contributions generated by AI has become a crucial requirement 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-level projects, it is necessary to distinguish between the contributions of human developers and AI tools for accurate tracing and auditing; as stated on pages 18 / 28 of the evaluation and procurement specification.When using different AI coding tools, accurate data is needed to compare their performance. However, the code statistics methods provided by related technologies 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, can automatically complete the entire process from AI code generation and accurate verification at 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; it effectively eliminates invalid change lines that are manually modified, overwritten, or restored between AI generation and submission by verifying AI code change data based on the code to be submitted and the base version code during submission, thereby ensuring the row-level accuracy of AI contribution statistics; in addition, by directly associating and storing the refined submission statistics information 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. Thus, 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 process, insufficient result accuracy, and easy disconnection from versions in related technologies.

[0166] The following will explain the code tracing method provided by this application embodiment in detail with reference to application scenarios.

[0167] In an exemplary application scenario, this application embodiment provides an optional AI code tracing system architecture as shown in FIG4. As shown in FIG4, the AI ​​code tracing process implemented by this system architecture begins at the Integrated Development Environment (IDE). In the IDE environment, 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. The event that triggers the recording is responded to by the AI ​​code line mapping tracing module. This AI code line mapping tracing module can essentially be an integration of the functions of the AI ​​code recording submodule (not shown in the figure) and the line number mapping submodule (not shown in the figure): The AI ​​code recording submodule is used to capture and record the specific line number of the code modified by the AI ​​in real time, and at the same time record the modified complete textThe content of the code is saved as a snapshot and stored in a JSONL temporary file on the IDE side; while the line number mapping submodule tracks and verifies the line number changes in the historical records using a Diff algorithm after each AI modification to ensure the accuracy of the records.

[0168] When the developer finishes editing and executes the Git commit command, the AI ​​code tracking process will enter the version control system side. At this time, the Git hook module in the version control system is activated, specifically executed by the prepare-commit-msg hook. The prepare-commit-msg hook will read the records in the aforementioned JSONL temporary file, verify them based on the code content to be committed, and write them into the statistics. The verified AI contribution statistics will be automatically filled into the commit message of this commit. After the commit action is successfully completed, the post-commit hook is triggered. At the same time, the system will ensure that the post-rewrite hook is created and enabled. The 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 stage of the AI ​​code tracing process is completed by a permanent storage (e.g., Git Ref) module. After post-commit, the permanent storage module will permanently store the verified statistical data as an independent Git object, for example, saving the statistical data as a Git reference (Ref), so that the tracing data can be distributed and persisted along with the code repository.

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

[0171] In an exemplary application scenario, the code tracing scheme in the embodiments of this application relies on a set of line number mapping and verification algorithms based on difference comparison (Diff). This algorithm defines the basic concepts of file content in different states to achieve accurate line number tracking. 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 tracking 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, is...This refers to the file content after the changes are completed. By comparing the file content in these different states, the system can calculate the precise line number correspondence.

[0172] The key to the above algorithm is to perform a Diff comparison on the file content of the two versions and generate a detailed line number mapping relationship. The Diff comparison will produce three basic results, each of which corresponds to a specific mapping processing rule. The first result is the same line, also known as "equal". For lines with completely identical content, the system will establish a bidirectional mapping between the line numbers of the two versions, so that the corresponding line number in the other version can be found from the line number of one version. The second result is a new line, also known as "insert". For lines that only exist in newContent, the system will record the line numbers of these lines in newContent, but these line numbers cannot be mapped back to oldContent. Usually, -1 is returned to indicate that this mapping failure state. The third result is a deleted line, also known as "delete". For lines that only exist in oldContent, the system will record the line numbers of these lines that are deleted in oldContent, but these line numbers cannot be mapped forward to newContent.

[0173] Based on the above Diff line number mapping relationship, the system performs two key verification operations to ensure the accuracy of the statistical information. The first operation is to verify 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 map it forward to the current newContent. If the mapping is successful, it means that the line code still exists in the current updated version, and the system will update its line number to the new line number after mapping; if the mapping fails, it is determined that the line code has been deleted by subsequent modifications.

[0174] The second operation is to verify whether the deleted line is still deleted. This operation compares the unchanged baseline version code (baselineContent) with the current file content to be verified (as newContent) using a Diff comparison. The system checks each recorded deleted line based on the baseline version code line number and attempts to map it to the current newContent. If mapping is successful, it means that the line of code has been restored and is no longer in a deleted state; if mapping fails, it confirms that the line of code is still in a deleted state.

[0175] In order to ensure the purity of data when initially recording changes to the target type code, the system also introduces a set of filtering logic to exclude non-genuine changes. The filtering logic mainly includes two aspects.

[0176] The first aspect is filtering new lines, which aims to exclude those that appear to be added by the target type code but are actually added in the target type code.Lines of code that already exist in the baseline version code (baselineContent). This usually happens when previously deleted lines of code are restored. The specific implementation of filtering newly added lines is to perform a Diff comparison between the modified file content (newContent) of the target type code and the baseline version code (baselineContent), and then check whether the newly added line number of each record can be mapped back to the baselineContent. If it can be mapped, it means that this line is not a real addition and is excluded.

[0177] The second aspect is to filter deleted lines, which aims to exclude those lines of code that the target type code attempts to delete but do not exist in the baseline version code (baselineContent). This usually happens when lines added by the target specification 20 / 28 pages 24 CN 121614372 A type code itself are deleted before deletion. The specific implementation of filtering deleted lines is to perform a Diff comparison between the file content (oldContent) before the target type code is modified and the baseline version code (baselineContent), and check whether the deleted line number of each record can be mapped to the baselineContent. If mapping fails, it indicates that the line is 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 line, converting the deleted line number from the coordinate system of the original content (old Content) to the coordinate system of the baseline version code (baselineContent).

[0178] The above-mentioned 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 in target type code in real time, the algorithm is used to perform filtering logic and coordinate transformation to generate accurate initial change data. In the pre-submission verification stage, the algorithm is used to perform validity verification of newly added and deleted lines to generate submission statistics. In the historical 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, this application embodiment not only ensures the consistency of the entire tracing process processing logic but also improves the maintainability of the system and the reliability of the processing results.

[0179] In an exemplary application scenario, a real-time recording process after AI code is written is provided, as shown in Figure 5. As shown in Figure 5, the process begins with an AI code writing event, which is triggered by the AI ​​code assistant in the integrated development environment. When this event occurs, the system responds immediately and enters the "calculate this change" step. In this step, the system...The difference comparison (Diff) algorithm is invoked to compare the original file content before writing with the file content after AI modification (aiModified), and the set of line-level changes directly caused by this AI writing is calculated.

[0180] Subsequently, the process enters two parallel filtering stages to eliminate non-genuine change records. The first stage is "filtering deleted lines", the purpose of which is to exclude those lines of code that AI marked as deleted but which do not actually exist in the baseline version of the code. The system will use the aforementioned line number mapping and verification algorithm to perform a Diff comparison between the original content before modification and the baseline version of the code, and check whether each deleted line number to be recorded can be mapped to the baseline version of the code. If it cannot be mapped, the deleted line will be excluded according to the filtering logic in the algorithm. The second stage is "filtering added lines", the purpose of which is to exclude those lines of code that AI marked as added but which actually already exist in the baseline version of the code. The system is also based on the line number mapping and verification algorithm. It compares the AI-modified content (aiModified) with the baseline version code (baseline) by performing a diff comparison and checks whether each newly added line number to be recorded can be mapped back to the baseline version code (baseline). If it can be mapped, the newly added line is excluded according to the filtering logic in the algorithm.

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

[0182] Next, the system will determine whether there is an "old JSONL record" generated by the AI ​​in the current file. If there is no old record, the process will switch to the "direct use" branch. If there is an old record, the process will enter the verification stage. The verification stage includes two parallel verification operations: "verify whether the old newly added line still exists" and "verify whether the old deleted line has been restored". Both of these verifications reuse the principle of the line number mapping and verification algorithm. Specifically, the system performs a diff comparison between the historical file snapshots saved in the old records and the current aiModified content as two versions, generating a line number mapping relationship. For historically added lines, it checks whether they can be positively 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 update, the process enters the "merge new and old records" step. The system will merge the valid new records...The changed data is merged with the updated historical change records. Subsequently, the process executes the "save aiModifiedContent snapshot" step, saving the complete content of the file after the AI ​​is written. Finally, in the "write JSONL file" step, the system serializes the merged complete change records and file snapshot together and writes them into a temporary file in JSONL format.

[0184] Through the real-time recording process shown in Figure 5, this application embodiment can start tracking immediately after the AI ​​code is written, and ensures the accuracy and consistency of filtering, coordinate transformation and historical verification through reused line number mapping and verification algorithms. The above process provides a guarantee for building accurate and reliable initial change data, which is a key prerequisite for successful execution of verification during subsequent submissions.

[0185] In an exemplary application scenario, a process for submission verification during AI code submission is provided as shown in Figure 6. As shown in Figure 6, this process is triggered by the developer executing the "git commit" command. After this command is executed, the system first executes the "read JSONL record" step, loading the JSONL file containing the target type code change data generated by the real-time recording process from the temporary storage. Next, the system executes the "get stagedContent" step to extract the complete content of the code to be committed from the staging area of ​​the version control system.

[0186] After obtaining the above data, the process executes two core verification branches in parallel. Both branches reuse the aforementioned line number mapping and verification algorithm. The first branch is "verify new lines". In this branch, the system executes the "Diff f (aiModifiedContent ,staged)" operation, that is, 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 executes the "filter AI code that has been deleted by the user" operation. This operation specifically applies the logic of "verify whether the new line still exists" in the algorithm: check whether each new 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 has been manually deleted by the user before the commit, so they are filtered out from the statistics.

[0187] The second parallel branch is "verify deleted lines". 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 line number mapping relationship generated by this Diff calculation, the system performs a "filtering of user-recovered code" operation. This operation specifically applies the logic of "verifying whether deleted lines are still deleted" in the algorithm: checking each line in the JSONL record based on the baseline version code.Can the deleted line with the (baseline) line number be mapped to the staged content? A line number that can be successfully mapped means that the line has been manually restored by the user, and therefore is filtered out from the deletion statistics.

[0188] After the above two verification branches are completed, the process enters the "Generate Final Statistics" step. The system summarizes the valid new lines and valid deleted lines that have been retained after double verification and filtering, and generates final statistics that accurately reflect the contribution of the target type code in this commit. Subsequently, the system executes the "Write CommitMessage" step, which automatically writes this final statistics into the commit message of this commit, making it permanently associated with the commit. Finally, the process executes the "Create GitRef" step, which permanently stores the final statistics as an independent object in the version control system, and creates a reference pointing to the final statistics, ensuring that the tracking data is distributed along with the code repository.

[0189] Through the submission verification process shown in Figure 6, this embodiment of the application performs precise verification of the temporary content at the code submission node by reusing line number mapping and verification algorithms, effectively eliminating statistical errors caused by manual intervention between AI code writing and 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 an exemplary application scenario, a code tracing process after historical rewrite is provided as shown in Figure 7. As shown in Figure 7, the process begins when the user or system performs a "historical rewrite operation". This historical rewrite operation triggers the "Post-rewriteHook" hook of the version control system, thereby automatically starting the code tracing process after historical rewrite to maintain the continuity of tracing data.

[0191] The process first determines the operation type. For the "squash" (commit merge operation) type, the system will first perform 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 the "rebase" type, the system directly enters 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 of the code tracing process reuses the line number mapping and verification algorithm of the embodiment of this application. The system executes two verification branches in parallel. The first branch is "verify new lines". The system executes the "Diff(aiModifiedContent, newContent)" operation (for the rebase operation, it executes "Diff").The system performs the "(aiModifiedContent, rebasedContent)" operation, comparing the file snapshot in the history with the content of the rewritten new file. Based on the generated line number mapping relationship, the algorithm's logic of "verifying whether newly added lines still exist" is applied to determine whether historically added lines are still valid in the rewritten version. The second branch is "verifying deleted lines". The system performs the "Diff(baseline, newContent)" operation (for rebase, it performs the "Diff(baseline, rebasedContent)" operation) to compare the base version code with the content of the rewritten new file. Based on the generated line number mapping relationship, the algorithm's logic of "verifying whether deleted lines are still deleted" is applied to determine whether historically deleted lines are still in a deleted state in the rewritten version.

[0193] After the above verification is completed, the code tracing process enters the "Generate new statistics and create new Ref" step. Based on the valid change lines retained after verification, the system generates rewrite statistics that accurately correspond to the new commit version after rewriting. Subsequently, the system creates a new Git object for the statistics and establishes a reference (Ref), stores it permanently, and associates it with the version identifier of the new commit.

[0194] Further, after ensuring that the new code tracing record is successfully created and stored, the system will perform the "Delete old Ref" operation, delete the historical reference associated with the old commit version that has been rewritten, clean up the invalid tracing records, and thus complete the migration of the entire tracing data from the old version to the new version.

[0195] Through the historical rewrite processing flow shown in Figure 7, the embodiments of this application can automatically respond to and adapt to the rewrite operation of the version history. This process ensures that even after the code history is modified, the contribution statistics can be accurately recalculated and synchronously bound with the new code version, thereby solving the problem of the tracing data being broken and invalid due to historical rewriting in the traditional solution.

[0196] In an exemplary application scenario, a special process after a commit merge operation is provided as shown in Figure 8. As shown in Figure 8, this process simulates the specific scenario of merging (squash) three historical commits (Commit1, Commit2, and Commit3 in Figure 8) into a new commit, and demonstrates the logic of merging and re-verifying AI code contribution data during this process.

[0197] Specifically, as shown in Figure 8, at the beginning of the above process, the system obtains the AI ​​change records of each of the three historical commits: "Commit1" records the AI ​​newly added line "[10-12]", "Commit2" records the AI ​​deleted line "[10-12]", and "Commit3" records the AI ​​newly added line "[20-25]". When performing the commit merge operation, the system first performs "merging JSONL".The "Record" step integrates the three submitted JSONL change records. After merging, a temporary change set is obtained: the set of newly added lines is "[10-12, 20-25]", and the set of deleted lines is "[10-12]".

[0198] Subsequently, the process executes two verifications in parallel. The first verification is "Verification: Does the newly added line exist in the final content?" The system judges each line in the merged set of newly added lines based on the final file content generated after the submission merge. For example, for line "10-12", since it has been marked as deleted in "Commit2", it no longer exists in the final merged content. The conclusion is "10-12 does not exist (deleted by commit2) so it is filtered", and this line is removed from the valid new addition statistics. For line "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 line is 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 "10-12 exists (it disappeared after being deleted by commit2) and needs to be judged". Here, it is necessary to further analyze 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 not counted as a valid addition, and its deletion status also needs to be judged separately, while "20-25" is confirmed as a valid AI addition. Therefore, the process yields "Final statistics: AI addition [20-25]". The above process shows how the system intelligently handles the complex situation where AI changes between multiple commits may cancel each other out (such as being added and then deleted) by re-verification, ensuring the accuracy of the statistical results after merging.

[0201] Through the special process shown in Figure 8, this application embodiment clarifies the refined processing capability for the complex rewrite operation of commit merging (squash). This process, by summarizing each commit record before merging and re-analyzing the final content after merging, eliminates statistical ambiguity caused by the intertwining of historical commit changes, ensuring that even after significant reorganization of the code history, the measurement results of AI contribution remain clear and accurate.

[0202] Therefore, the code tracing method provided by this application embodiment can achieve several beneficial effects in AI code tracing scenarios. In terms of system architecture, through the integrated design based on Git hook chains, a natural connection between the tracing process and version control operations is achieved, solving the problem of AI code tracing being detached from the developer workflow. Regarding data persistence,By storing statistical data as Git objects and associating them with specific references, tracking data can be synchronized and distributed with the code repository, facilitating team collaboration and long-term maintenance. Regarding historical compatibility, the mechanism for handling historical rewrite operations ensures that relevant statistical data can be automatically migrated and remain valid after code commit history is modified, avoiding breaks in the tracking chain. In terms of statistical accuracy, processing logic based on line number mapping and verification algorithms enables precise line-level tracking 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 merging multiple commits 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 tracking solution that is deeply integrated with version control systems.

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

[0204] Through the above description of the embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platform, and of course, it 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. The computer software product is stored in a storage medium (such as read-only memory (ROM), random access memory (RAM), magnetic disk, optical disk), including 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 the embodiments of this application, an embodiment of an apparatus for implementing the above code tracing method is also provided. Figure 9, page 24 / 28 of the specification, CN 121614372 A, is a schematic diagram of a code tracing device according to an embodiment of this application. As shown in Figure 9, the device includes: an acquisition module 901, configured to acquire code change data corresponding to a write event of target type code in an integrated development environment; and a verification module 902, configured to perform a version commit operation on the code to be committed corresponding to the target type code.The code change data is verified based on the code to be submitted and the base version code corresponding to the target type code to obtain submission statistics. The submission statistics are used to characterize the valid code change lines provided by the target type code relative to the base version code. The association module 903 is used to associate and store the submission statistics with the code version identifier corresponding to the version submission operation to obtain code tracking records.

[0206] Optionally, the above-mentioned acquisition module 901 is also used 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 the 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 a historical file snapshot recorded after the previous version commit operation; compare the historical file snapshot 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 submitted 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 submitted 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 at least a portion of the newly added line numbers from the set of newly added line numbers that failed to map to the code to be submitted to obtain an updated set of newly added line numbers.

[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 newly added line numbers from the set of deleted line numbers that failed to map to the code to be submitted to obtain an updated set of newly added line numbers.Among multiple deleted line numbers, at least a portion of the deleted line numbers that were successfully mapped to the code to be committed are filtered out to obtain an updated set of deleted line numbers.

[0211] Optionally, the above-mentioned association module 903 is further used to: create a first file content object of the version control system based on the commit 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 commit version code determined after the version commit 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), which is used to: in response to a target rewriting operation in the version control system, obtain the rewritten version code that is triggered to be committed after the target rewriting operation is completed; determine the historical code tracing record corresponding to the historical version code identifier based on the target rewriting operation, 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 rewriting operation; use the rewritten version code to perform verification processing on the historical commit statistics in the historical code tracing record, and generate rewriting statistics; associate and store the rewriting statistics with the rewritten version identifier corresponding to the rewritten version code, and update the code tracing record in the version control system.

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

[0214] Optionally, in the above rewrite module, the target rewrite operation includes one of the following: commit correction operation, rebase operation, selection 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 version codes; the historical commit statistics information is the merged information of multiple sets of commit statistics information corresponding to multiple historical commit version codes; the historical new line number set is obtained by merging multiple sets of new line numbers contained in multiple sets of commit statistics information; the historical deleted line number set is obtained by merging multiple sets of deleted line numbers contained in multiple sets of commit statistics information; the historical file snapshots include multiple code file snapshots in multiple sets of code change data corresponding to multiple historical commit version codes; the historical base version code includes multiple base versions corresponding to multiple sets of code change data.This code.

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

[0217] It should be noted here that the above 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 embodiments.

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

[0219] It should be noted that the preferred embodiments of this embodiment can be referred to the relevant descriptions in the foregoing embodiments, and will not be repeated here. The preferred embodiments 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] The embodiments of this application can provide an electronic device, including: a memory storing an executable program; a processor for running the program, wherein the program executes the code tracing method of any of the foregoing items when it runs.

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

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

[0223] Specifically, the electronic device may be pre-installed with various types of models, including but not limited to models in the fields of natural language processing, visual processing, speech processing, code processing, multimodal task processing, etc., thereby providing a variety of model selections. In different product forms, as described on pages 26 / 28 of the instruction manual (30 CN 121614372 A), 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 various types of models such as discriminative and generative models), and model...Model version control (supporting control of different model versions), model evaluation (evaluating the performance and effect of the model based on model evaluation tools), etc. In other product forms, the electronic device can also create applications based on the model, providing application programming interface (API) calling capabilities, which can call the model into the created application through the API interface, and at the same time provide application management tools to realize the management and monitoring of the application.

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

[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, respectively. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, that is, to realize 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, which 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 the 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 the structure shown in FIG10 is merely illustrative, and the electronic device may also be a smart mobile device (such as a smartphone), a tablet computer, a handheld computer, and a mobile Internet device (MID) or other terminal device. FIG10 does not limit the structure of the above electronic device. For example, the electronic device 100 may also include more or fewer components (such as network interfaces, display devices, etc.) than shown in FIG10, or have a different configuration than shown in FIG10.

[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. This program can be stored in a computer-readable storage medium, which may include: a flash drive, a read-only memory (ROM), or a random access memory (RAM).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 any of the code tracing methods 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 above 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, which, when executed by a processor, implements the code tracing method provided in the above embodiments. Specification 27 / 28 pages 31 CN 121614372 A

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

[0234] The 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 their own emphasis. 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. Among them, the device embodiments described above are merely illustrative. For example, the division of the above units is merely a logical functional division. 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. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection of 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 integrated unit is implemented as a software functional unit and sold or used as an independent product, it 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. The 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 method described in the various embodiments of this application. The aforementioned storage medium includes various media that can store program code, such as USB flash drives, ROM, RAM, mobile 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. Instruction manual 28 / 28 pages 32 CN 121614372 A Figure 1 Figure 2 Instruction manual Figure 1 / 7 pages 33 CN 121614372 A Figure 3 Instruction manual Figure 2 / 7 pages 34 CN 121614372 A Figure 4 Instruction manual Figure 3 / 7 pages 35 CN 121614372 A Figure 5 Instruction manual Figure 4 / 7 pages 36 CN 121614372 A Figure 6 Instruction manual Figure 5 / 7 pages 37 CN 121614372 A Figure 7 Figure 8 Instruction manual Figure 6 / 7 pages 38 CN 121614372 A Figure 9 Figure 10 Instruction manual Figure 7 / 7 pages 39 CN 121614372 A 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 methodincludes: 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.

Claims

1. A code trace method, characterized by, The method comprises the following steps: in response to a write event of target type code in an integrated development environment, obtaining code change data corresponding to the write event; in response to a version submission operation performed on to-be-submitted code corresponding to the target type code, performing verification processing on the code change data based on the to-be-submitted code and reference version code corresponding to the target type code, to obtain submission statistical information, wherein the submission statistical information is used to represent effective code change lines provided by the target type code relative to the reference version code; storing the submission statistical information and a code version identifier corresponding to the version submission operation in association to obtain a code tracking record.

2. The code tracing method according to claim 1, wherein, The method further comprises the following steps: obtaining a change file path, pre-write file code and post-write file code corresponding to the write event; comparing the pre-write file code and the post-write file code to obtain a first line number mapping relationship; determining a current added line number set and a current deleted line number set based on the first line number mapping relationship; generating the code change data by using the change file path, the current added line number set, the current deleted line number set and a current file snapshot of the post-write file code.

3. The code tracing method according to claim 2, wherein, The method further comprises the following steps: obtaining a change history record corresponding to the target type code, wherein the change history record comprises a historical added line number set, a historical deleted line number set and a historical file snapshot recorded after a previous version submission operation; comparing the historical file snapshot and the current file snapshot to obtain a second line number mapping relationship; based on the second line number mapping relationship, merging the historical added line number set and the current added line number set to obtain a merged added line number set, and merging the historical deleted line number set and the current deleted line number set to obtain a merged deleted line number set; updating the code change data by using the merged added line number set, the merged deleted line number set and the current file snapshot.

4. The code tracing method according to claim 1, wherein, The method further comprises the following steps: comparing the current file snapshot in the code change data and the to-be-submitted code to obtain a third line number mapping relationship; verifying the added line number set in the code change data according to the third line number mapping relationship to obtain an updated added line number set; comparing the reference version code and the to-be-submitted code to determine a fourth line number mapping relationship; verifying the deleted line number set in the code change data according to the fourth line number mapping relationship to obtain an updated deleted line number set; generating the submission statistical information based on the updated added line number set and the updated deleted line number set, wherein the submission statistical information comprises added line statistical data and deleted line statistical data.

5. The code tracing method according to claim 4, wherein, The method further comprises the following steps: verifying the added line number set according to the third line number mapping relationship to obtain an updated added line number set comprises: Filtering at least part of the new line numbers that fail to be mapped to the to-be-committed code from the plurality of new line numbers in the new line number set based on the third line number mapping relationship, to obtain an updated new line number set.

6. The code tracing method according to claim 4, wherein, According to the fourth line number mapping relationship, the delete line number set is verified to obtain an updated delete line number set, including: Based on the fourth line number mapping relationship, filter at least part of the delete line numbers that are successfully mapped to the to-be-committed code from the plurality of delete line numbers in the delete line number set, to obtain an updated delete line number set.

7. The code tracing method of claim 1, wherein, The submission statistical information is associated with the code version identifier for storage to obtain the code tracking record, including: Based on the submission statistical information, a first file content object of the version control system is created; The first file content object is associated with the code version identifier for storage to generate the code tracking record, wherein the code version identifier is used to indicate the submission version code determined after the version submission operation is completed.

8. The code tracing method of claim 1, wherein, The method further comprises: In response to a target rewrite operation in the version control system, obtaining a rewritten version code triggered by a commit 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 submission version code associated with the target rewrite operation; Using the rewritten version code, the historical submission statistical information in the historical code tracking record is verified and processed to generate rewritten statistical information; The rewritten statistical information is associated with the rewritten version identifier corresponding to the rewritten version code for storage to update the code tracking record in the version control system.

9. The code tracing method according to claim 8, wherein, Using the rewritten version code, the historical submission statistical information in the historical code tracking record is verified and processed to generate the rewritten statistical information, including: Comparing the rewritten version code with the historical file snapshot corresponding to the historical code tracking record to obtain a fifth line number mapping relationship; According to the fifth line number mapping relationship, the historical new line number set in the historical submission statistical information is verified to obtain a rewritten new line number set; Comparing the rewritten version code with the historical base version code corresponding to the historical code tracking record to obtain a sixth line number mapping relationship; According to the sixth line number mapping relationship, the historical delete line number set in the historical submission statistical information is verified to obtain a rewritten delete line number set; Based on the rewritten new line number set and the rewritten delete line number set, the rewritten statistical information is generated.

10. The code tracing method according to claim 9, wherein, The target rewrite operation includes one of the following: a commit correction operation, a base change operation, a pick operation, and a commit merge operation.

11. The code tracing method according to claim 9, wherein, When the target rewrite operation is a commit merge operation, the target rewrite operation is associated with a plurality of historical submission version codes; The historical submission statistical information is the merged information of a plurality of groups of submission statistical information corresponding to the plurality of historical submission version codes; The historical added row number set is obtained by merging a plurality of added row number sets respectively contained by the plurality of groups of commit statistics; The historical deleted row number set is obtained by merging a plurality of deleted row number sets respectively contained by the plurality of groups of commit statistics; The historical file snapshot includes a plurality of code file snapshots in a plurality of groups of code change data respectively corresponding to the plurality of historical commit version codes; The historical reference version code includes a plurality of reference version codes respectively corresponding to the plurality of groups of code change data.

12. The code tracing method of claim 8, wherein, The association storage of the rewrite statistics information and the rewrite version identifier is performed, and the updating of the code tracking record in the version control system includes: Based on the rewrite statistics information, a second file content object of a version control system is created; The second file content object is stored in association with the rewrite version identifier to generate a current code tracking record corresponding to the rewrite version identifier in the version control system; After the generation of the current code tracking record, a historical code tracking record corresponding to the historical version code identifier is deleted from the version control system.

13. A method for tracing artificial intelligence code, characterized in that, It includes: In response to a write-in event of an artificial intelligence code in an integrated development environment, code change data corresponding to the write-in event is obtained; In response to a version commit operation performed on the to-be-committed code corresponding to the artificial intelligence code, the code change data is verified based on the to-be-committed code and the reference version code corresponding to the artificial intelligence code, to obtain commit statistics, wherein the commit statistics are used to record effective code change lines of the artificial intelligence code relative to the reference version code; The association storage of the commit statistics and a code version identifier corresponding to the version commit operation is performed to obtain a code tracking record.

14. An electronic device, comprising: It includes: A memory storing a runnable program; A processor connected with the memory, configured to run the program, wherein the program runs to execute the method in any one of claims 1 to 13.

15. A computer-readable storage medium, characterized in that, The computer readable storage medium includes a stored executable program, wherein the executable program controls the device where the computer readable storage medium is located to execute the method in any one of claims 1 to 13 when the executable program runs.

16. A computer program product, characterised in that, It includes a computer program, which, when executed by a processor, implements the method in any one of claims 1 to 13.

Images