Code classification method and device based on context feature map, equipment and medium

Abstract

The application relates to the development auxiliary technology field and discloses a code classification method and device based on a context feature graph, equipment and a medium, which comprises the following steps: obtaining a code change event and extracting engineering environment, directory structure, file attribute and line-level text information, generating classification candidates and matching evidence through a context feature graph, performing classification determination and conflict resolution, obtaining file classification results and data to be reviewed, performing line-level content recognition on the candidate effective files, generating deduction text lines and reserved text lines, summarizing various text lines and performing quantity balance verification, and generating code classification results and balance verification records. The application can be applied to financial technology and medical health business scenarios, a continuous classification process is formed through graph matching, conflict resolution and line-level content recognition, and the text lines after classification are summarized and subjected to quantity verification, so that the classification accuracy and result checkability of complex code changes are improved.

Description

Technical Field

[0001] This invention relates to the field of development assistance technology, and in particular to a code classification method, apparatus, device and medium based on context feature graphs. Background Technology

[0002] Current code metrics typically categorize code changes based on file extensions, directory names, or path keywords. In code repositories with multiple languages ​​and project structures, the same file type may be used in different project phases, and the same path may contain a mix of business code, test content, automatically generated content, and log content. Existing classification methods struggle to comprehensively consider the project environment, directory hierarchy, file attributes, and line-level content to determine code ownership, easily leading to inaccurate classification of valid code and code to be deducted.

[0003] In the fintech sector, platforms for banking, insurance, securities, payment, and lending typically encompass transaction processing, risk control, policy management, claims processing, regulatory reporting, and data analysis. Related code repositories contain a mix of front-end pages, back-end services, database scripts, test data, log content, and automatically generated files. Categorizing files solely based on file extensions or directory keywords makes it difficult to accurately identify the actual categories of different modified files and newly added text lines within files, potentially leading to inaccurate statistical results for valid code in fintech projects.

[0004] In the healthcare business field, medical information platforms, health management platforms, medical data processing platforms, and medical device supporting software typically encompass various engineering components such as diagnostic and treatment procedures, image processing, laboratory data, health records, and device communication. Related code changes may simultaneously involve business programs, configuration files, simulation interfaces, test content, and automatically generated content. Existing classification methods struggle to accurately distinguish between different types of code based on varying levels of project context and line-level content, making it difficult for code classification results in the healthcare software development process to truly reflect code changes. Summary of the Invention

[0005] The main objective of this invention is to provide a code classification method, apparatus, device, and storage medium based on context feature maps, aiming to solve the technical problem that existing technologies are unable to accurately classify complex code changes, resulting in distorted attribution results for valid codes and codes to be deducted.

[0006] To achieve the above objectives, this invention provides a code classification method based on context feature maps, comprising: Obtain code change events, identify each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata, and line-level text increments from the code change events; The global engineering environment information, the directory structure hierarchy information, the file metadata and the line-level text increment are matched with the pre-configured context feature map to generate an initial classification candidate set and matching evidence data corresponding to each changed file; Based on the initial candidate classification set and the matching evidence data, candidate classification determination and classification conflict resolution are performed to generate target file classification results and file data to be reviewed. Based on the target file classification results, candidate valid files are determined, and the changed files in each changed file other than the candidate valid files are determined as the remaining changed files. Based on the context feature map, line-level content recognition is performed on the line-level text increments corresponding to the candidate valid files to generate deducted text lines and retained text lines. Based on the target file classification results and the file data to be reviewed, the deducted text lines, the retained text lines, and the line-level text increments corresponding to the remaining changed files are classified and summarized to generate classified summary data. Based on the categorized summary data, code categorization results are generated, and a row-level quantity balance check is performed based on the row-level text increment corresponding to each change file and the categorized summary data, generating a balance check record.

[0007] Furthermore, to achieve the above objectives, the present invention provides a code classification device based on context feature maps, comprising: The change context extraction module is used to obtain code change events, determine each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata and line-level text increments corresponding to each changed file from the code change events; The graph feature matching module is used to match the global engineering environment information, the directory structure hierarchy information, the file metadata and the line-level text increment with the pre-configured context feature graph to generate an initial classification candidate set and matching evidence data corresponding to each changed file; The classification conflict resolution module is used to determine candidate classification and resolve classification conflicts based on the initial candidate classification set and the matching evidence data, and generate target file classification results and file data to be reviewed. The line-level content recognition module is used to determine candidate valid files based on the target file classification results, and to determine the changed files other than the candidate valid files in each changed file as the remaining changed files. The module performs line-level content recognition on the line-level text increments corresponding to the candidate valid files according to the context feature map, and generates deducted text lines and retained text lines. The classification data summary module is used to classify and summarize the deducted text lines, the retained text lines, and the line-level text increments corresponding to the remaining changed files based on the target file classification results and the file data to be reviewed, and generate classification summary data. The row-level balance verification module is used to generate code classification results based on the classification summary data, and to perform row-level quantity balance verification based on the row-level text increments corresponding to each change file and the classification summary data, and generate balance verification records.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a context-based feature map-based code classification program stored in the memory and executable on the processor, wherein when the context-based feature map-based code classification program is executed by the processor, it implements the steps of the context-based feature map-based code classification method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a code classification program based on context feature maps, wherein the code classification program based on context feature maps, when executed by a processor, implements the steps of the code classification method based on context feature maps as described above.

[0010] Beneficial Effects: This invention relates to the field of development support technology and discloses a code classification method, apparatus, device, and medium based on context feature graphs. The method includes: acquiring code change events and extracting project environment, directory structure, file attributes, and line-level text information; generating classification candidates and matching evidence through context feature graphs; performing classification judgment and conflict resolution to obtain file classification results and data to be reviewed; performing line-level content recognition on candidate valid files to generate deducted and retained text lines; summarizing various types of text lines and performing quantity balance verification to generate code classification results and balance verification records. This invention can be applied to business scenarios such as fintech and healthcare. By forming a continuous classification process through graph matching, conflict resolution, and line-level content recognition, and summarizing and verifying the number of classified text lines, it improves the classification accuracy and verifiability of complex code changes. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a code classification method based on context feature maps according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the code classification method based on context feature maps according to the present invention; Figure 3for Figure 2 A detailed flowchart of step S10; Figure 4 for Figure 2 A detailed flowchart of step S20; Figure 5 for Figure 2 A detailed flowchart of step S30; Figure 6 for Figure 2 A detailed flowchart of step S40; Figure 7 for Figure 2 A detailed flowchart of step S50; Figure 8 for Figure 2 A detailed flowchart of step S60; Figure 9 This is a schematic diagram of the functional modules of a preferred embodiment of the code classification device based on context feature maps of the present invention; Figure 10 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 11 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The code classification method based on context feature maps provided in this invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can obtain code change events from the client and extract project environment, directory structure, file attributes, and line-level text information. It generates classification candidates and matching evidence through context feature graphs, performs classification judgment and conflict resolution, and obtains file classification results and data to be reviewed. For candidate valid files, it performs line-level content recognition, generating deducted and retained text lines. It summarizes all types of text lines and performs quantity balance verification, generating code classification results and balance verification records. This invention can be applied to business scenarios such as fintech and healthcare. It forms a continuous classification process through graph matching, conflict resolution, and line-level content recognition, and summarizes and verifies the number of classified text lines, thereby improving the classification accuracy and verifiability of complex code changes. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention is described in detail below through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the code classification method based on context feature maps provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the code classification method based on context feature maps proposed in this invention includes the following steps: S10, obtain code change events, determine each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata and line-level text increments corresponding to each changed file from the code change events; In this embodiment, the code change event records code changes within a version range, including repository identifier, version identifier, file path, change status, and difference content, which can be generated by code commits, branch merges, or version comparisons. When the event only contains index information, the corresponding data is read based on the repository identifier and version identifier.

[0016] Each changed file is identified based on its file path and the differences in its content, and the difference blocks of the same file are grouped under the same file identifier. When a file is renamed, its original path and the new path are associated with it. Each file identifier is associated with directory structure hierarchy information, file metadata, and line-level text increments, respectively.

[0017] Global project environment information is obtained from project configuration, dependency declarations, build scripts, and module configurations, including project type, dependency ecosystem, framework type, and module organization information. Directory structure hierarchy information is generated by splitting file paths and recording the arrangement of path segments. File metadata is obtained from file paths, file headers, and change status, including filename, file type identifier, encoding type, and binary identifier.

[0018] Line-level text increments are obtained from the differences in each change file. Difference block boundaries, new line markers, and new position are parsed, preserving the new text and its order. When a single change file contains multiple difference blocks, the text lines are arranged according to their new position.

[0019] When a commit event is pushed on a code hosting platform, the repository identifier, version information, and list of changed files are read. Each changed file is determined based on the version differences, and the project configuration, file path, and newly added text content are read from the corresponding version snapshot.

[0020] In the case of statistics based on iteration cycles, the file trees of the baseline version and the target version are compared, and code change events are generated based on file path, content identifier, and change status. File deletion retains file metadata, and line-level text increments are set to empty.

[0021] In the fintech business, when an insurance claims platform undergoes a version merge, the claims page, payment service, database scripts, and log configuration files are determined based on the submitted event, and global project environment information, directory structure hierarchy information, file metadata, and line-level text increments are generated respectively.

[0022] In the healthcare business, when a health management platform performs version comparison, it determines the health record page, device communication service, and data processing script based on the file tree and the differences, and generates corresponding data according to the file path and the newly added content.

[0023] This embodiment reduces data deviations caused by renaming, path differences, and scattered difference blocks by uniformly identifying each changed file and organizing the project environment, directory level, file attributes, and new text content according to file identifiers, thereby improving the integrity and verifiability of code change data.

[0024] S20, the global engineering environment information, the directory structure hierarchy information, the file metadata and the line-level text increment are matched with the pre-configured context feature map to generate an initial classification candidate set and matching evidence data corresponding to each changed file; In this embodiment, the global project environment information includes project type, dependency ecosystem, framework type, and module organization information, which serve as shared matching data for all changed files. Directory structure hierarchy information, file metadata, and line-level text increments reflect the file's location, file attributes, and newly added text content, respectively. By combining the above information according to the changed file identifier, matching data corresponding to each changed file is obtained.

[0025] The context feature graph includes environment feature nodes, directory feature nodes, file feature nodes, content feature nodes, and candidate category nodes. Each feature node records the feature type, feature value, and matching conditions, and is associated with the corresponding candidate category node.

[0026] Before matching, file paths, character case, text encoding, and file type identifiers are standardized. Global project environment information is matched against environment feature nodes, directory structure hierarchy information against directory feature nodes, file metadata against file feature nodes, and line-level text increments against content feature nodes. Matching methods include exact matching, path hierarchy matching, set inclusion matching, and text pattern matching.

[0027] Each match records the changed file identifier, the hit feature node, the candidate category node, the matching location, and the information source, forming matching evidence data. Match results pointing to the same candidate category node are grouped into the same candidate category item, and all candidate category items form the initial candidate category set for the corresponding changed file.

[0028] For graphs with small size and low update frequency, a structured configuration file is used to store nodes and node relationships, and hash indexes and path prefix indexes are established. Project type and file type identifiers use exact matching, directory structure hierarchy information uses path hierarchy matching, and line-level text increments use text pattern matching.

[0029] In scenarios with a large number of graph nodes and a code repository containing multiple modules, a graph database is used to store the context feature graph. For each changed file, environment feature nodes, directory feature nodes, file feature nodes, and content feature nodes are queried separately. Then, candidate category nodes associated with the matched feature nodes are read to generate an initial set of candidate classifications and matching evidence data.

[0030] In the fintech business, code changes to payment platforms include transaction service files, page files, test scripts, and automatically generated interface files. Project configurations, module paths, file attributes, and newly added text are matched with corresponding feature nodes to generate an initial set of candidate classifications and matching evidence data for each changed file.

[0031] In the healthcare business domain, code changes to the health management platform include health record pages, device communication services, data processing scripts, and simulation interface files. Framework information, directory hierarchy, file attributes, and newly added text are used for graph matching, and the matching results are aggregated according to the changed files.

[0032] This embodiment reduces the impact of a single file suffix or directory name on code classification by matching different types of feature nodes to project-level information and file-level information respectively. By retaining the hit feature nodes, candidate category nodes and information sources, the initial classification candidate set has a clear basis, improving the completeness and verifiability of the candidate classification results.

[0033] S30, based on the initial classification candidate set and the matching evidence data, perform candidate classification determination and classification conflict resolution to generate target file classification results and file data to be reviewed; In this embodiment, the initial classification candidate set stores candidate categories obtained from graph matching according to the changed files, with each candidate category associated with a file identifier. The matching evidence data records the information source, hit feature nodes, matching position, and matching method corresponding to the candidate category, which is used to explain the basis for the formation of the candidate category.

[0034] Candidate classification is determined based on the number of candidate categories and the conflict relationships between candidate category nodes. Candidate categories that do not conflict with other candidate categories are directly retained; mutually exclusive candidate categories are divided into the same conflict group to avoid the same change file obtaining incompatible categories simultaneously.

[0035] The classification conflict resolution process reads the priority index, confidence index, and matching evidence data corresponding to each candidate category. The priority index is used to filter out candidate categories with lower priority. If multiple candidate categories still exist after filtering, they are compared based on the confidence index and the quantity and type distribution of evidence from different sources. Change files that can retain a unique candidate category are written into the target file classification results; change files that cannot retain a unique candidate category or whose initial classification candidate set is empty are written into the pending review file data.

[0036] The target document classification results include the document identifier, target category, and corresponding matching evidence. The document data to be reviewed includes the document identifier, remaining candidate categories, conflicting evidence, and reasons for not being able to determine the category, so as to distinguish between the data that has been classified and the data that needs to be reviewed.

[0037] When there are few candidate categories and the conflict relationships are stable, a conflict relationship table and a priority table are used to complete the classification. The initial set of candidate categories is read according to the file identifier, the candidate categories are divided using the conflict relationship table, and then the priority table and confidence index are used to filter them level by level. When the filtering result is unique, the target file classification result is written; when the filtering result is not unique, the data of the file to be reviewed is written.

[0038] When there are many candidate categories and significant differences in the sources of evidence, classification is completed by traversing the graph relationship and comparing the support of evidence. Conflict relationships, priority indicators, and confidence indicators are read along the candidate category nodes, and the number of hits for environmental, directory, file, and content evidence is counted. A candidate category that receives support from multiple types of evidence and whose comparison result is unique is designated as the target category; the remaining conflicting data is retained in the file data to be reviewed.

[0039] In the case of batch code changes, candidate classification is determined in parallel according to file identifiers. Each changed file independently generates target file classification results or data of files to be reviewed, avoiding the mixing of matching evidence between different files.

[0040] In the fintech business, script files in payment and clearing platforms simultaneously match backend service categories, test categories, and automatically generated categories. Based on comparisons of matching evidence corresponding to directories, dependencies, and text content, categories with clearly supported evidence are written into the target file classification results; when multiple categories still cannot be distinguished, the file and conflicting evidence are written into the file data to be reviewed.

[0041] In the healthcare business field, configuration files in health management platforms simultaneously possess characteristics of device communication configuration and test environment configuration. Candidate classification is determined based on matching evidence formed by the engineering environment, directory location, and file content. A unique category is retained, or candidate categories that cannot be distinguished and their corresponding evidence are recorded as file data awaiting review.

[0042] This embodiment associates candidate categories with matching evidence and filters them based on conflict relationships, priority indicators, confidence indicators, and evidence distribution among candidate categories. This reduces classification bias caused by a single matching result. At the same time, it records change files that cannot be uniquely categorized separately, improving the accuracy and verifiability of code classification results.

[0043] S40, based on the target file classification results, candidate valid files are determined, and the changed files in each changed file other than the candidate valid files are determined as the remaining changed files. Based on the context feature map, line-level content recognition is performed on the line-level text increments corresponding to the candidate valid files to generate deducted text lines and retained text lines. In this embodiment, the target file classification results record the file category corresponding to each changed file. Change files that still require text line recognition are filtered based on their file categories and identified as candidate valid files. Candidate valid files include files that show valid code attributes at the file-level classification level, but may still contain comments, logs, test content, or generated content. Files not identified as candidate valid files are included in the remaining change files, ensuring that both categories collectively cover all change files in the code change event.

[0044] The line-level content nodes in the context feature map record the text structure, key content, grammatical form, generation tags, and relationships between adjacent texts. For candidate valid files, text lines are read according to their position in the line-level text increment and matched against the current text line and adjacent text lines. When a single text line matches a node corresponding to a blank space, comment, log, or debugging content, the current text line is identified as independent content to be deducted. When multiple adjacent text lines consecutively match nodes corresponding to test content, simulated content, automatically generated content, or content generated in the auxiliary generation process, the segment boundary is determined based on the consecutive arrangement relationship.

[0045] Text lines that match a line-level content node are identified as deducted text lines. Text lines that do not match a line-level content node and are not located within a consecutive deducted segment are identified as retained text lines. Deducted and retained text lines retain their original file identifiers, text positions, and order, preventing line-level recognition from altering the correspondence between text lines and changed files.

[0046] When new content is primarily composed of independent text lines, a line-by-line matching method is used to identify the text content. For each text line, character composition, statement type, call name, and text prefix are extracted and matched against line-level content nodes in the context feature map. Text lines matching log output, debug output, comments, or blank content are classified as deducted text lines, while other text lines are classified as retained text lines.

[0047] When the newly added content includes consecutive generated fragments or test fragments, a joint matching method of text lines and adjacent content is used to identify the fragment range. The fragment boundaries are determined based on the generation marker, test declaration, indentation relationship, sentence continuity, and node matching of adjacent text lines. Text lines within the fragment are uniformly classified into the deducted text lines to avoid missing subsequent content by only identifying the first line of the fragment.

[0048] When dealing with large increases in line-level text, a block-based reading approach is used to maintain the text line order. Boundary text lines are preserved between adjacent data blocks to ensure that continuous segments across data blocks can still be identified. After all data blocks have been identified, the text lines that were deducted and those that were preserved are merged.

[0049] In the fintech business, credit approval service documents are identified as candidate valid documents. The incremental text at the line level simultaneously contains approval logic, debugging output, and continuous simulation data. Based on the line-level content nodes, debugging output and simulation data fragments are identified, and the corresponding text lines are assigned to the deduction text lines, while the text lines corresponding to the approval logic are assigned to the retention text lines.

[0050] In the healthcare business area, health record service documents were identified as candidate valid documents. The newly added content includes record update logic, log output, and pre-set content for continuous testing. Log output and pre-set test segments are identified based on text lines and adjacent text relationships, and the corresponding text lines are assigned to the deducted text lines, while the remaining record update content is assigned to the retained text lines.

[0051] This embodiment distinguishes between candidate valid files and remaining changed files based on the target file classification results, and identifies independent deduction content and continuous deduction segments in candidate valid files by combining context feature maps. This avoids directly including all newly added text in the entire candidate valid file as valid content, so that the deducted text lines and the retained text lines have clear file ownership and positional relationships, thereby improving the accuracy of line-level content division.

[0052] S50, based on the target file classification results and the file data to be reviewed, classify and summarize the deducted text lines, the retained text lines and the line-level text increments corresponding to the remaining changed files, and generate classification summary data; In this embodiment, the target file classification results record the determined file categories and file identifiers, while the file data to be reviewed records the file identifiers, candidate categories, and review status for files with no unique category. Subtracting and retaining text lines preserves the source file, line position, and content type, while the remaining line-level text increments of the modified files preserve the complete file ownership and arrangement order.

[0053] The categorization and summarization uses document identifiers as the association basis. Deducted text lines are grouped according to the deduction category, while retained text lines are grouped according to the target category of the source document. If the remaining changed documents already have a target category, the corresponding line-level text increments are assigned to the target category; if the remaining changed documents exist in the data of documents awaiting review, the line-level text increments are associated with the candidate category and review status. The categorized and summarized data includes document identifier, category, text line content, line position, content source, and review status, without changing the text line content or the original arrangement.

[0054] When the number of changed files is small, a file identifier index is used to associate the target file classification results, the data of the file to be reviewed, and various text lines. The corresponding classification record is written to each file, and the sorting order is saved according to the position of the text line.

[0055] When dealing with a large number of files undergoing batch changes, file identifier partitioning is used to separately summarize the line-level text increments of deducted text lines, retained text lines, and remaining changed files, and then the results of each partition are merged. A separate review status field is set for files to be reviewed to prevent text lines with undetermined categories from being mixed into those with determined categories.

[0056] In the fintech business area, reserved text lines in payment service files are categorized into business code categories, log text lines are categorized into deduction categories, and configuration file increments with undetermined categories are associated with data in files pending review.

[0057] In the healthcare business, the reserved text lines in the health record service documents are associated with the target category, the test text lines are classified into the deduction category, and the incremental data to be reviewed in the device access scripts are collected separately.

[0058] This embodiment associates target categories, review status, and text lines from different sources with file identifiers, which can reduce text line omissions, duplicate collections, and file attribution errors, while retaining the data status of undetermined categories, thereby improving the integrity and traceability of categorized and summarized data.

[0059] S60, generate code classification results based on the classification summary data, and perform row-level quantity balance verification based on the row-level text increment corresponding to each change file and the classification summary data, and generate balance verification records.

[0060] In this embodiment, the categorized summary data includes the category, categorized text line, line position, and review status corresponding to each changed file. The categorized text lines are grouped according to their categories, retaining the file identifier and line position to generate code categorization results, ensuring that each text line has a clear category affiliation.

[0061] Row-level quantity balance verification is performed on a per-file basis, determining the number of text lines in the row-level text increment and the number of categorized text lines in the categorized summary data, and comparing whether the two quantities are consistent. To identify duplicate or omitted data sets, a row identifier can be composed of a file identifier and a row position, and the corresponding row identifiers on both sides can be verified. The balance verification record saves the file identifier, the two types of quantities, the verification status, and the row positions where discrepancies exist.

[0062] When only the total number of text lines needs to be verified, a file-by-file counting method is used to count the incremental text at the line level and the number of text lines in the categorized summary data. If the numbers match, the verification is recorded as passed; if the numbers do not match, the difference in numbers and the corresponding file identifier are recorded.

[0063] In cases where specific differences need to be located, a line identifier set comparison method is used. Line identifiers are generated based on file identifiers and line positions. Missing and duplicate items in the two sets are compared, and the positions of the differing lines are written to the balance check record.

[0064] When there are a large number of files to be changed, code classification results and verification records are generated by partitioning according to file identifiers. After each partition is completed, the output is merged to avoid text lines from different files from being mixed up.

[0065] In the fintech business, the line-level text increments of payment service documents include business code, log content, and content awaiting review. Code classification results are generated according to the corresponding categories, and the number and position of the categorized text lines are compared with the incremental text lines, recording any missing or duplicate text lines.

[0066] In the healthcare business field, health record service documents include record processing content and testing content. After classification and summarization, corresponding code classification results are generated, and balance verification is performed based on file identifiers and line positions, generating records containing verification status and discrepancy locations.

[0067] This embodiment, by grouping text lines according to classification categories and verifying the quantity and line position of the categorized summary data against the line-level text increments of each changed file, can identify missing text lines, duplicate grouping, and file ownership errors, thereby improving the completeness of code classification results and the traceability of balance verification records.

[0068] In one embodiment, such as Figure 3 As shown, step S10 above includes: S101, Obtain code change events, and read repository context data, file path set, and difference content set from the code change events; S102, parse the set of file paths and the set of differences, determine the corresponding file paths and differences, determine each changed file based on the corresponding file paths and differences, and establish the correspondence between each changed file and the changed file path and the changed difference content. S103, extract project type features, dependency ecosystem features and framework features from the warehouse context data to generate global project environment information; S104, for each changed file, the path of the changed file is divided into multiple path segments, and directory structure hierarchy information is generated according to the arrangement hierarchy of each path segment; S105, extract the file name, file type identifier and binary identifier from the change file path and change difference content corresponding to each change file, and generate file metadata; S106, Identify the new content and new location from the change difference content corresponding to each change file, organize the new content according to the new location, and generate a line-level text increment.

[0069] In this embodiment, code change events are generated by code commits, branch merges, version releases, or version range comparisons, and are associated with the same code change through event identifiers. The event data stores the repository identifier, branch information, the version before the change, the version after the change, and a data retrieval index. When an event does not directly carry complete content, the corresponding repository snapshot and version differences are retrieved based on the repository identifier and version information to prevent data from different versions from being mixed up.

[0070] Repository context data is read from project description files, dependency declaration files, build configurations, and framework configurations in the repository root directory and each module directory. The file path collection stores file paths that have been added, modified, deleted, or renamed. The difference content collection stores the textual differences between each file before and after the change, recording the difference block, change status, and the line position after the change. All three types of data are associated with event identifiers for code change events.

[0071] When parsing a set of file paths, path separators, relative path markers, and duplicate path segments are handled uniformly. When parsing a set of differences, each difference item carries the original path, the new path, file status, and difference block information. The new path is prioritized for establishing the correspondence; deleted files use the original path, and renamed files retain both the original and new paths. When multiple difference blocks point to the same file, related difference blocks are grouped under the same file identifier to determine each changed file, its path, and the content of the changes.

[0072] Project type characteristics reflect the project organization form adopted by the repository, and are identified through project description files, build entry points, and module declarations. Dependency ecosystem characteristics reflect the organization and loading method of dependency packages, and are identified through dependency declaration files, package management configurations, and reference declarations. Framework characteristics are identified through framework dependencies, startup configurations, component declarations, and framework configuration files. The extracted results are organized according to repository-level and module-level scope, retaining the source location, and generating global project environment information that describes the project environment to which the current code change belongs.

[0073] For each modified file, the standardized file path is divided into multiple path segments based on directory separation. Path segments are recorded in order from the repository directory to the filename, and the hierarchical number, parent path segment, and complete path are stored. Files located within a module directory also record their module hierarchy, while files located in the repository root directory generate corresponding records based on their actual path depth, thus forming the directory structure hierarchy information.

[0074] The filename is extracted from the last-level path segment of the modified file path. The file type identifier is determined based on the extension, file header markers, and the text structure of the difference content. When there is no extension or the extension is insufficient to distinguish the type, identification is performed by combining the first-line declaration, content encoding, and statement structure. The binary identifier is determined based on the binary change markers, undecodeable characters, and non-text byte distribution in the difference content. The filename, file type identifier, and binary identifier are associated with the file identifier to form file metadata.

[0075] Changes are parsed according to the change block. The line position of the changed text is determined by the change block header, and new content is identified by new line markers, excluding path markers in the change file header. Each new content record records the text content, the changed line position, and the change block identifier. When the same change file contains multiple change blocks, they are arranged according to the new position; when multiple new content entries are in the same position, their order in the change content is maintained. Deleted content is not written to the line-level text increment; binary files and files without new content generate empty line-level text increments.

[0076] Each changed file is associated with global project environment information, directory structure hierarchy information, file metadata, and line-level text increments through a unified file identifier. Renaming files use the same file identifier, and multiple difference blocks are merged before being written to the corresponding file to avoid misalignment between file paths, file attributes, and newly added content.

[0077] This embodiment reads repository context data, file path set, and difference content set within the same code change event scope, and establishes an accurate correspondence between file paths and difference content. This reduces file duplication and data mismatch in scenarios involving renaming, deletion, and multiple difference blocks. By extracting the project environment, directory level, file attributes, and location of newly added text, the multi-layered information of each changed file is kept consistent, thereby improving the integrity, accuracy, and verifiability of code change data.

[0078] In one embodiment, such as Figure 4 As shown, step S20 above includes: S201, for each changed file, the project type characteristics, dependency ecology characteristics, and framework characteristics in the global project environment information are determined as environment feature items, and directory feature items, file feature items, and content feature items are extracted from the directory structure hierarchy information, file metadata, and line-level text increments corresponding to each changed file, respectively. The environment feature items, directory feature items, file feature items, and content feature items are combined to generate a set of feature items to be matched. S202, determine the feature nodes to be matched from the context feature map that correspond to the types of the environment feature items, the directory feature items, the file feature items and the content feature items respectively, and determine the candidate category nodes corresponding to each feature node to be matched; S203, match each feature item in the set of feature items to be matched with the corresponding feature node to be matched, determine the hit feature node, and generate matching evidence items based on the mutually matched feature items, the hit feature node and the candidate category node corresponding to the hit feature node; S204, for each change file, the corresponding matching evidence items are grouped according to the candidate category nodes, the matching evidence items pointing to the same candidate category node are merged, and candidate classification items are generated based on the merged matching evidence items and the corresponding candidate category nodes. S205. For each changed document, summarize the corresponding candidate classification items, generate an initial classification candidate set for each changed document, and summarize the matching evidence items corresponding to each candidate classification item to generate matching evidence data for each changed document.

[0079] In this embodiment, for each changed file, shared global project environment information, along with the file's independently associated directory structure hierarchy, file metadata, and line-level text increments, are read based on the file identifier. Project type characteristics reflect the project organization form, dependency ecosystem characteristics reflect dependency declarations and referencing systems, and framework characteristics reflect framework configuration and component organization methods. These three types of data retain the characteristic name, characteristic value, and source location, respectively, and are used as environment characteristic items. Environment characteristic items are shared among multiple changed files in the same code change event, but are still written separately into the matching data of each changed file to prevent the mixing of project environments from different events.

[0080] Directory features are extracted from path segments, directory depth, parent-child hierarchy, and module location. After standardizing path separators, character case, and relative path markers, complete paths, last-level directories, consecutive path segments, and module levels are organized into directory features, enabling the context feature map to identify complete and partial directory structures. File features are extracted from filenames, file type identifiers, and binary identifiers, while retaining the filename body, extensions, and file attributes. Content features are extracted from line-level text increments and may include key text fragments, statement structures, declaration types, call identifiers, comment markers, and continuous text relationships. When content formatting differences exist due to spaces, indentation, or encoding variations, formatting differences that do not alter the meaning of the text structure are standardized, while the standardized content and original line positions are preserved.

[0081] Environment features, directory features, file features, and content features are written into the same set of features to be matched, according to their feature types. Each feature record includes the changed file identifier, feature type, feature value, source data type, and source location. When multiple valid pieces of information are extracted from a single source data, multiple feature items are generated separately to avoid compressing multiple meanings into a single, non-matchable combination value.

[0082] The context feature graph is configured with environment feature nodes, directory feature nodes, file feature nodes, and content feature nodes. Each node records the node type, matchable feature values, matching conditions, and node identifier. Candidate category nodes record the file categories that can be pointed to by feature nodes, and feature nodes and candidate category nodes are associated through support relationships. Feature nodes of the same type are selected for matching based on the type of the feature to be matched, avoiding cross-matching of different types of data such as environment information and file attributes. When a feature node to be matched is associated with multiple candidate category nodes, all associated categories are retained.

[0083] Each feature item is compared with other feature nodes of the same type. Environmental features can be matched based on feature value equality or set inclusion; directory features can be matched based on complete paths, path prefixes, or continuous path segments; file features can be matched based on filenames, file type identifiers, or binary attributes; and content features can be matched based on text fragments, sentence structures, or content patterns. Nodes that meet the matching conditions are identified as matching feature nodes. When the same feature item matches multiple nodes, each match is retained, and matching results that may point to different candidate categories are not deleted at the current stage.

[0084] Each hit associates the matching features, the hit feature node, and the candidate category node as a matching evidence item. The matching evidence item records the changed file identifier, feature identifier, feature source, hit feature node, candidate category node, matching method, and matching position. When a content feature item hits, the matching position uses the corresponding text line position; when a directory feature item hits, the matching position uses the corresponding path segment or directory level; when environment and file feature items hit, the corresponding configuration location or file attribute source is recorded.

[0085] For the same changed document, candidate category nodes are used as grouping identifiers, and matching evidence items pointing to the same candidate category node are grouped into the same group. Evidence generated by the same feature item repeatedly hitting the same feature node is merged, while evidence generated from different sources or different feature nodes is retained separately. The merged matching evidence items and candidate category nodes together generate candidate classification items, so that the candidate classification items simultaneously record the candidate category and the environment, directory, file, and content basis that supports the category.

[0086] Candidate classification items for each changed document are aggregated according to document identifier to generate an initial candidate classification set. The initial candidate classification set retains all candidate classification items corresponding to the same document, without further processing the coexistence relationship between candidate categories. Matching evidence items under each candidate classification item are organized according to candidate category and source type to generate matching evidence data, enabling each candidate category to be traced back to specific feature items, hit feature nodes, and information sources.

[0087] This embodiment converts the engineering environment, directory hierarchy, file attributes, and line content into feature items with clear types and sources, and matches them with nodes of the same type in the context feature map. This can reduce the omission of candidate categories caused by a single file suffix or directory name. By merging and matching evidence items according to candidate category nodes, each initial classification candidate has a locatable matching basis, thereby improving the integrity of the initial classification candidate set and the traceability of matching evidence data.

[0088] In one embodiment, such as Figure 5 As shown, step S30 above includes: S301, for each changed file, extract candidate classification items from the corresponding initial classification candidate set, and according to the conflict relationship between the candidate category nodes corresponding to each candidate classification item in the context feature map, determine the candidate classification items that do not form a conflict relationship with other candidate classification items as direct classification items, and determine the candidate classification items that form a conflict relationship with other candidate classification items as conflict classification items; S302, extract the matching evidence items corresponding to each conflict classification item from the matching evidence data, and generate the evidence support degree corresponding to each conflict classification item according to the number of matching evidence items and the type distribution of the corresponding feature items; S303, obtain the priority index and confidence index of the candidate category node corresponding to each conflict classification item from the context feature map, filter the conflict classification items according to the priority index, when only one conflict classification item is retained after filtering, take the only retained conflict classification item as the target classification item, when multiple conflict classification items with the same priority are retained after filtering, compare the multiple conflict classification items with the same priority based on the confidence index and evidence support corresponding to each conflict classification item, when only one conflict classification item is retained after comparison, take the only retained conflict classification item as the target classification item, so as to complete the classification conflict resolution; S304, the change files whose corresponding initial classification candidate set is empty, and the change files that have conflicting classification items but fail to determine a unique target classification item after the classification conflict is resolved, are identified as change files to be reviewed, and the change files to be reviewed, the corresponding initial classification candidate set, and the matching evidence data are used to generate the file data to be reviewed. S305, summarize the direct classification items and target classification items corresponding to the change files other than the change files to be reviewed in each change file, and generate the target file classification result.

[0089] In this embodiment, for each modified file, all candidate classification items are read from the initial candidate classification set based on the file identifier, and the candidate category nodes associated with each candidate classification item are obtained. The conflict relationships between candidate category nodes in the context feature map are queried to determine whether different candidate categories can be simultaneously established. Conflict relationships can be recorded as mutually exclusive associations and indexed by the node identifiers of the two candidate category nodes. When a candidate classification item does not form a mutually exclusive association with other candidate classification items in the same file, it is determined as a direct classification item; when mutually exclusive associations exist, the conflicting candidate classification items are classified into conflict classification items. When a candidate classification item conflicts with multiple candidate classification items simultaneously, conflict groups are formed according to the association relationships between candidate category nodes to avoid missing conflicts within the same group due to only performing pairwise comparisons.

[0090] Matching evidence items are extracted from the matching evidence data according to file identifiers and candidate category nodes, corresponding to each conflicting classification item. The number of matching evidence items reflects the number of times the candidate classification item is matched, and the feature item type distribution reflects whether the evidence originates from the engineering environment, directory structure, file attributes, and text content. Evidence support is generated based on the number and type distribution of evidence, and can be expressed using methods such as item counting, type weighting, or coverage type quantity. Duplicate evidence generated by the same feature item repeatedly matching the same feature node is merged, while evidence from different sources or locations is retained separately to reduce the impact of duplicate matches on evidence support.

[0091] Priority indicators are read from the candidate category nodes corresponding to the conflict classification items and are used to indicate the filtering order among conflict categories. For the same conflict group, conflict classification items that meet the filtering criteria are retained, and conflict classification items with lower priority are removed. If the filtering results contain only one conflict classification item, that conflict classification item is determined as the target classification item. If the filtering results still contain multiple conflict classification items with the same priority, the confidence index of each candidate category node is read and compared with the evidence support.

[0092] The confidence level reflects the credibility of the pre-configured candidate category nodes, while the evidence support level reflects the actual support the current change document provides for the candidate category. The comparison process can be conducted in the order of confidence level and evidence support, or both can be converted to the same evaluation scale to form a comprehensive comparison value. If a unique advantage exists after comparison, the corresponding conflicting classification item is determined as the target classification item; if multiple conflicting classification items still yield the same result, a unique category is not forced to preserve the authenticity of the current classification state.

[0093] An empty initial candidate classification set indicates that no usable candidate classification items have been generated for the corresponding change document. The existence of conflicting classification items but the inability to determine a unique target classification item indicates that the existing priority indicators, confidence indicators, and matching evidence are insufficient to distinguish the categories. Both types of change documents are identified as change documents awaiting review. The data for documents awaiting review is stored according to the document identifier, including the initial candidate classification set, matching evidence data, conflicting classification items, comparison results, and the status of not having a unique category determined. This allows the content awaiting review to be located to a specific candidate category and source of evidence.

[0094] Except for documents awaiting review, change documents without category conflicts retain their direct classification entries, while change documents with resolved conflicts retain their target classification entries. Direct and target classification entries are summarized according to document identifiers to generate target document classification results. Target document classification results record the change document, its determined category, and corresponding evidence, ensuring each classified document has a clear category affiliation.

[0095] This embodiment distinguishes between direct classification items and conflicting classification items by the conflict relationship between candidate category nodes, and sequentially uses priority indicators, confidence indicators and evidence support to filter conflicting categories, which can reduce classification ambiguity caused by the coexistence of multiple candidate categories. By including change documents without candidate categories or whose unique category cannot be determined into the data of documents to be reviewed, it avoids generating distorted classification conclusions when there is insufficient evidence, thereby improving the accuracy of the target document classification results and the traceability of the data to be reviewed.

[0096] In one embodiment, such as Figure 6 As shown, step S40 above includes: S401, extract the file category corresponding to each changed file from the target file classification result, determine the changed files belonging to the valid code category as candidate valid files, and determine the changed files other than the candidate valid files as the remaining changed files; S402, extract line-level content feature nodes from the context feature map that correspond to blank content, annotation content, log content, debugging content, test content, simulation content, automatically generated content, or content generated in the auxiliary process; S403, for each candidate valid file, extract multiple text lines from the corresponding line-level text increment, determine adjacent text lines according to the arrangement position of each text line in the line-level text increment, extract line text features from each text line, and extract adjacent line context features from each text line and its corresponding adjacent text lines. S404, match the line text features and the adjacent line context features with the line-level content feature nodes to determine the line-level content feature nodes hit by each text line, and identify single-line hit content and continuous segment hit content based on the continuous hit relationship of adjacent text lines to the line-level content feature nodes. S405, the text lines corresponding to the single-line hit content and the continuous segment hit content are determined as deducted text lines, and the text lines in the line-level text increment corresponding to the candidate valid file other than the deducted text lines are determined as retained text lines.

[0097] In this embodiment, the file category in the target file classification result is read according to the file identifier, and the file category is compared with the valid code category for consistency. The valid code category is used to mark the changed files in the file-level classification result that may carry business logic, functional logic, data processing logic, or operation control logic. Change files that match the comparison are classified as candidate valid files, while change files that have not yet obtained the target file classification result, belong to other file categories, or are in a pending review state are classified as remaining change files. Candidate valid files and remaining change files are complementaryly divided, so that the same change file is classified into only one category, and the two categories of files cover all change files in the code change event.

[0098] Line-level content feature nodes are read from the context feature map according to node type. Blank content nodes record line structures containing empty characters, indentation characters, or no text content; comment content nodes record the boundary forms of single-line comments, multi-line comments, and documentation descriptions; log content nodes record log calls, log levels, and output parameter structures; debugging content nodes record debug calls, temporary output, and debug flags; test content nodes record test declarations, assertion calls, and test data organization; simulation content nodes record simulation objects, simulation responses, and alternative call structures; automatic generation content nodes record generation flags, templated structures, and batch repetition structures; auxiliary generation process content nodes record prompts, intermediate responses, process comments, and generation auxiliary flags. Each node stores the content type, matching attributes, and applicable text structures. Multiple nodes can be configured for the same content type to cover different languages ​​and file types.

[0099] For candidate valid files, the corresponding line-level text increment is read based on the file identifier, and the increment content is split into multiple text lines according to the insertion position. Each text line retains the text content, file identifier, line position, and difference block identifier. Adjacent text lines are determined based on the continuity of their line positions; text lines located in different difference blocks but with consecutive line positions can be established as adjacent, while those with gaps in line positions are not established as adjacent. Text lines located at the increment boundary are only associated with the actual preceding or following text line.

[0100] Line-by-line text features are extracted from individual text lines, including character composition, key identifiers, statement type, call name, comment boundaries, indentation level, and text structure. Before extraction, character encoding, newline characters, and spaces that do not affect statement structure can be standardized, while preserving the original text and line position. Adjacent line context features are extracted from the current text line and its adjacent text lines, including continuous indentation relationships, statement succession relationships, comment interval relationships, code block boundaries, call parameter continuation relationships, and the continuous distribution of identical content markers. When single-line information is insufficient to determine the content type, adjacent line context features are used to supplement the fragment range and content attribution.

[0101] The text features of a line are compared with the text attributes of the line-level content feature nodes, and the context features of adjacent lines are compared with the context attributes configured for the node. If the line text features satisfy the text matching conditions of the node, and if context constraints are required, the context features of adjacent lines also satisfy the corresponding conditions, the relevant node is determined as the line-level content feature node matched by the current text line. Matching can be performed using character consistency, key identifier inclusion, sentence structure matching, call form matching, or fragment boundary matching. When multiple nodes are matched by the same text line, each match and its content type are retained to avoid missing composite content.

[0102] When a single text line hits a line-level content feature node, and adjacent text lines do not form a continuous hit of the same type, the relevant content is identified as a single-line hit. When multiple adjacent text lines hit the same content type, or hit nodes that can form the same content fragment, the continuous fragment hit content is determined according to line position, indentation level, statement sequence relationship, and fragment boundary. The start position of the continuous fragment is taken as the position of the first text line within the continuous hit range, and the end position is taken as the position of the last text line, avoiding the situation of only deducting the fragment marker line while retaining the content inside the fragment.

[0103] Text lines covered by single-line hits and consecutive segment hits are included in the deducted text lines, while retaining the hit node, content type, file identifier, and line position. Text lines in the line-level text increment of candidate valid files that are not included in the deducted text lines are included in the retained text lines. During the partitioning process, only one final assignment is retained for each text line. When multiple nodes are hit, multiple hit criteria can be saved simultaneously, but the same deducted text lines will not be generated repeatedly.

[0104] This embodiment filters candidate valid files based on the target file classification results, and identifies blank, comment, log, debugging, testing, simulation and generation content within the file-level classification range using line text features and adjacent line context features. It can distinguish between independent hit text lines and continuous hit segments, reducing invalid content mixing caused by including the entire file and deduction omissions caused by only identifying segment markers. It determines the remaining changed files through complementarity, and retains the file ownership, line position and hit basis of the deducted text lines and retained text lines, improving the accuracy and verifiability of line-level content classification.

[0105] In one embodiment, such as Figure 7 As shown, step S50 above includes: S501, determine the deduction category based on the content type of each deduction text line, associate each deduction text line with the corresponding changed file and the deduction category to generate a deduction classification record, determine the file category of the changed file corresponding to the retained text line based on the target file classification result, associate the retained text line with the corresponding changed file and the corresponding file category to generate a retention classification record; S502, the change files in the remaining change files that correspond to the data of the file to be reviewed are identified as change files to be reviewed, and the change files in the remaining change files other than the change files to be reviewed are identified as classified remaining change files; S503, determine the file category corresponding to the classified remaining changed files according to the target file classification result, assign the line-level text increment corresponding to the classified remaining changed files to the corresponding file category, and generate the remaining classification record; S504, associate the line-level text increment corresponding to the change file to be reviewed with the data of the file to be reviewed to generate a classification record to be reviewed; S505: Based on each change document, summarize the corresponding deduction category records, retained category records, remaining category records, and category records pending review to generate category summary data.

[0106] In this embodiment, each deducted text line retains the file identifier, line position, text content, and content type identified by line-level content recognition. The deduction category is determined based on a preset correspondence between content type and deduction category; for example, comment content, log content, debugging content, test content, simulation content, and generated content are respectively categorized into their respective categories. When the same text line has multiple content types, a unique deduction category is determined according to category priority, while other content types are retained as classification criteria to avoid duplicate recording of the same text line.

[0107] The file identifier of the deducted text line is associated with the changed file, and the text content, line position, content type, and deduction category are written into the same data record to generate a deduction classification record. When multiple deducted text lines belong to the same changed file, they are arranged according to line position; when multiple text lines form a continuous segment, the start and end positions of the segment can be recorded simultaneously, so that the deduction classification record can reflect the file ownership of single-line content and continuous content.

[0108] The retained text lines originate from candidate valid files. Based on the file identifier carried by the retained text line, the target file classification result is queried, the file category of the corresponding changed file is read, and the file category is assigned to the retained text line within that file. The retained text lines, corresponding changed files, and file categories are associated to generate a retained classification record. The retained classification record stores the file identifier, file category, text content, and line position, ensuring that each retained text line follows the file-level classification result.

[0109] Remaining change files include those not identified as candidate valid files. The data for files awaiting review is queried by file identifier. Remaining change files with the same file identifier are identified as files awaiting review, while those without the same file identifier are identified as categorized remaining change files. The file identifier can be generated by combining the repository identifier, file path, and change event identifier to distinguish files with the same name in different repositories or different code change events.

[0110] For the remaining changed files that have already been categorized, the file category is retrieved from the target file classification results based on the file identifier. Since this category of files is not divided into deducted and retained text lines, the corresponding line-level text increments are aggregated according to the overall file category. Each line-level text increment retains its text content, line position, and file identifier, and together with the corresponding file category, generates a remaining classification record. When a line-level text increment is empty, the file identifier, file category, and empty increment status are still retained to reflect the classification affiliation of the changed file.

[0111] For documents undergoing review, the corresponding line-level text increments are associated with the document data according to the document identifier. The initial classification candidate set, matching evidence data, and undetermined unique category status in the document data are written to the review classification record along with the line-level text increments. The review classification record does not assign a specific document category to the text lines but retains possible candidate categories to distinguish documents that have not been classified from those that have been classified.

[0112] Using the changed document as the unit of summary, the system reads the corresponding deduction category record, retained category record, remaining category record, and pending review category record for that document. Candidate valid documents are primarily associated with deduction and retained category records; remaining changed documents that have already been classified are associated with remaining category records; and changed documents pending review are associated with pending review category records. During the summary process, file-level data items are created according to the file identifier, and the text lines in each record are organized according to their row positions to generate categorized summary data. The categorized summary data saves the changed document, record type, category, text content, row position, and review status, without changing the arrangement of each text line within the original row-level text increment.

[0113] This embodiment determines the deduction category according to the content type and establishes separate classification records for deducted text lines, retained text lines, the remaining file increments after classification, and the file increments to be reviewed. This ensures that text lines from different sources and in different classification states have clear attribution. By associating the target file classification results and the file data to be reviewed with file identifiers, and summarizing various records by changed file, it can reduce duplicate collection, omission collection, and category mixing of text lines, thereby improving the integrity and traceability of the classified summary data.

[0114] In one embodiment, such as Figure 8 As shown, step S60 above includes: S601, extract the category and category text line corresponding to each change file from the category summary data, summarize the category text line according to the category, and generate code classification results; S602, determine the number of original text lines from the line-level text increments corresponding to each changed file, and determine the number of category text lines corresponding to each changed file from the categorized summary data; S603, For each modified file, compare the original number of text lines with the classified number of text lines to generate a line-level number verification result; S604, Identify the change files with quantity differences based on the row-level quantity verification results, and determine the category text line information corresponding to the change files with quantity differences from the category summary data; S605, summarize the line-level quantity verification results of each change file, as well as the category text line information of change files with quantity differences, and generate a balance verification record.

[0115] In this embodiment, the classification category, classification text line, line position, and record type are read from the categorized summary data according to the change file identifier. The classification category includes deduction categories, identified file categories, and pending review category statuses. Classification text lines with the same classification category are grouped into the same category data item, and the text lines are organized according to the change file identifier and line position. When a single text line contains duplicate classification records, duplicates are identified based on the change file identifier, difference block identifier, and line position, and only one classification text line record is retained to avoid duplicate entries. All category data items together constitute the code classification result, which retains the association between the classification category, source file, classification text line, and line position.

[0116] For each changed file, all newly added text lines are read from the corresponding line-level text increment. The original number of text lines is determined using the actual saved text line records as the counting unit; blank text lines are still counted as independent text lines, and changed files that do not contain newly added content have a corresponding count of zero. When multiple difference blocks belong to the same changed file, the newly added text lines in each difference block are merged to determine the original number of text lines, avoiding file-level dispersion caused by counting separately for each difference block.

[0117] The system reads the deducted category records, retained category records, remaining category records, and pending review category records corresponding to the same changed file from the categorized summary data, and counts the number of category text lines contained in each record to obtain the category text line count. When a continuous segment contains multiple text lines, the count is performed line by line according to the text lines actually covered by the segment, and the entire segment is not counted as a single data item. The statistical range of the category text line count is consistent with the statistical range of the original text line count, so that both counts point to the same changed file and the same code change event.

[0118] The number of original text lines corresponding to each changed file is compared with the number of categorized text lines. When the two numbers are equal, a line-level quantity verification result with consistent numbers is generated; when the number of categorized text lines is less than the number of original text lines, the record may contain uncollected text lines; when the number of categorized text lines is greater than the number of original text lines, the record may contain duplicate collected text lines. The line-level quantity verification result saves the changed file identifier, the number of original text lines, the number of categorized text lines, the quantity difference, and the verification status.

[0119] Based on the verification status, change files with quantity discrepancies are filtered out, and the corresponding category text line information is read from the categorized summary data. The category text line information includes the category, text content, line position, difference block identifier, and record type, used to determine the category range involved in the quantity discrepancy. When multiple records with the same line position exist in the categorized summary data, the relevant records are marked as duplicate aggregation information; when the number of original text lines is greater than the number of category text lines, the potentially missing line position intervals are recorded in conjunction with the existing category text line position ranges.

[0120] The changes are aggregated at the line-level quantity verification results. For changes with the same quantity, the file identifier, the two quantity categories, and the verification status are retained. For changes with quantity discrepancies, the corresponding category text line information is further associated. The aggregated results generate a balanced verification record, ensuring that the quantity comparison results for each change file correspond to the discrepancy location information.

[0121] This embodiment identifies missing and duplicate text lines during the classification and summarization process by separately counting the number of original text lines and the number of classified text lines within the same file range, and comparing the two types of numbers file by file. By associating the differences in numbers with specific classification categories, line positions and record types, it can locate the range of abnormal data, thereby improving the completeness of code classification results and the verifiability of balanced verification records.

[0122] In one embodiment, the code statistics of the monthly version of the claims system of an insurance group's R&D efficiency platform are taken as an example. The claims system adopts a single-repository, multi-module structure. The repository includes a mobile reporting page, a claims review front-end, a claims calculation service, an image data service, database scripts, a test directory, a mock directory, a build artifact directory, automatically generated interface files, and an AI-assisted process directory. After the statistical period ends, the platform generates code change events based on the baseline and target versions, and reads repository identifiers, version information, file path sets, difference content sets, and repository context data such as project configurations, dependency declarations, and build configurations.

[0123] The platform parses the set of file paths and the set of differences, grouping corresponding file paths and difference blocks into the same change file. When a file is renamed, the platform associates the path before and after the change to avoid duplicate counting; deleted files retain their file attributes and do not generate new text lines; images, compressed files, and compilation artifacts are marked with binary identifiers and are not parsed. The platform identifies project type characteristics, dependency ecosystem characteristics, and framework characteristics from repository context data. For example, it identifies front-end frameworks based on dependency declarations, back-end service frameworks based on build configurations, and data processing projects based on script dependencies, generating global project environment information.

[0124] For each changed file, the platform divides the file path into path segments such as repository directory, module directory, function directory, and file name, and generates directory structure hierarchy information according to the arrangement level; it extracts the file name, file type identifier, and binary identifier from the file path and the difference content to generate file metadata; it identifies the new content and new location from the difference block, organizes the new text according to the line position in the file, and generates line-level text increments.

[0125] The pre-configured context feature graph includes feature nodes such as file extensions, filenames, path segments, project configuration files, dependency declarations, build artifacts, tests, mocks, logs, automatic generation, and AI-assisted processes. It records the relationships between each feature node and frontend code, backend code, scripts, configurations, tests, generated content, invalid content, and categories requiring review. Each node is configured with priority, confidence level, applicable conditions, and relationships indicating strong evidence, weak evidence, conflicting evidence, and the need for contextual confirmation.

[0126] The platform extracts environmental, directory, file, and content features from global project environment information, directory structure hierarchy information, file metadata, and line-level text increments, respectively, and matches them with nodes of the same type in the graph. For example, a TypeScript file located in the claims review page directory that uses front-end dependencies and contains page component declarations can generate multiple matching evidences pointing to the front-end code category; a Java file located in the claims calculation test directory that contains assertion calls can simultaneously generate candidate classification items for the back-end code category and the test category; an XML file located in the interface directory that contains generation tags can simultaneously generate candidate classification items for the configuration category and the automatically generated category. The platform records the feature source, hit feature node, candidate category, matching position, and matching method, generating an initial set of candidate classifications and matching evidence data for each changed file.

[0127] For candidate categories that do not form a conflict, the platform identifies them as direct categories. For files that simultaneously match front-end and back-end, valid code and generated content, or business code and test content, the conflict category is determined based on the conflict relationship between candidate category nodes. The platform calculates the amount of evidence for each conflict category and the distribution of evidence in the environment, directory, file, and content, generates evidence support scores, and combines priority and confidence indicators to resolve conflicts. For example, Java files located in the test directory that contain test declarations and assertion calls can be classified into the test category; interface files located in the business directory that simultaneously have a generated directory, generated tags, and a repetitive structure can be classified into the generated category. Files that still cannot be uniquely categorized and files that do not form a candidate category are entered into the pending review file data, and the candidate category, hit details, and conflict reasons are retained.

[0128] The platform identifies candidate valid files, such as front-end code, back-end code, and business scripts, from the target file classification results, and treats the remaining files as residual change files. For the candidate valid files, the platform extracts line-level content feature nodes corresponding to blank content, comment content, log content, debugging content, test content, simulation content, automatically generated content, and content generated in the auxiliary process from the context feature graph, and reads the text line and adjacent text lines according to the newly added position.

[0129] Taking the compensation calculation service file as an example, newly added compensation amount verification logic is retained, log printing statements are identified as single-line deduction content, continuous debugging output is identified as continuous segment deduction content, test assertions and mock compensation data are respectively classified as test content and simulation content, field mapping segments with generation tags and repetitive structures are classified as automatically generated content, and prompts, intermediate responses, or process comments saved during AI-assisted programming are classified as assisted generation process content. Text lines that hit the corresponding node are determined as deducted text lines, and other newly added text lines are determined as retained text lines.

[0130] The platform determines the deduction category (log, test, simulation, generation, or auxiliary generation process, etc.) based on the content type of the deducted text lines and generates a deduction classification record. Retained text lines retain the file category of the source file, generating a retained classification record. For the remaining changed files, those with a clearly defined target category have their corresponding line-level text increments grouped into the appropriate category, forming a remaining classification record. For files corresponding to the data to be reviewed, their line-level text increments are associated with candidate categories, matching evidence, and review status, forming a review-pending classification record.

[0131] Deducted category records, retained category records, remaining category records, and category records pending review are summarized according to the change documents to form category summary data. The category summary data retains the file path, category, text content, line position, hit rule, deduction reason, and review status, so that front-end valid lines, back-end valid lines, test lines, log lines, generated code lines, AI-assisted process generated lines, and lines pending review have clear attribution.

[0132] The platform aggregates categorized text lines according to their classification, generating code classification results, and separately counts the original number of newly added lines and the number of categorized text lines for each modified file. When the two counts are equal, the record is balanced; if the number of categorized text lines is low, the record may contain unaggregated text lines; if the number of categorized text lines is high, the record may contain duplicated text lines. For files with differences, the platform locates missing or duplicate lines based on the file identifier, difference block identifier, and line position, and aggregates the original number of newly added lines, the number of categorized text lines, the difference in count, the verification status, and the difference position to generate a balanced verification record.

[0133] After the statistics are completed, the platform outputs code classification results, detailed matching evidence, reasons for invalid code deductions, a list of files pending review, and balance verification records. Developers can see why a file is classified as front-end, back-end, testing, or generation, and can also pinpoint the basis for retaining or deducting a newly added text. Development efficiency personnel can focus manual review on files with unresolved conflicts, low evidence support, and unidentified files, and verify the sum of the number of lines of code for each category against the original number of newly added lines through the balance verification records.

[0134] In one embodiment, a code classification device based on context feature maps is provided, which corresponds one-to-one with the code classification method based on context feature maps in the above embodiments. (Refer to...) Figure 9 , Figure 9 This is a schematic diagram of the functional modules of a preferred embodiment of the code classification device based on context feature maps of the present invention. The code classification device based on context feature maps includes: a change context extraction module 10, a map feature matching module 20, a classification conflict resolution module 30, a line-level content recognition module 40, a classification data aggregation module 50, and a line-level balance verification module 60. Detailed descriptions of each functional module are as follows: The change context extraction module 10 is used to obtain code change events, determine each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata and line-level text increments corresponding to each changed file from the code change events. The graph feature matching module 20 is used to match the global engineering environment information, the directory structure hierarchy information, the file metadata and the line-level text increment with the pre-configured context feature graph to generate an initial classification candidate set and matching evidence data corresponding to each changed file; The classification conflict resolution module 30 is used to perform candidate classification determination and classification conflict resolution based on the initial classification candidate set and the matching evidence data, and generate target file classification results and file data to be reviewed. The line-level content recognition module 40 is used to determine candidate valid files based on the target file classification results, and to determine the changed files other than the candidate valid files in each changed file as the remaining changed files. The module performs line-level content recognition on the line-level text increments corresponding to the candidate valid files according to the context feature map, and generates deducted text lines and retained text lines. The classification data summary module 50 is used to classify and summarize the deducted text lines, the retained text lines, and the line-level text increments corresponding to the remaining changed files based on the target file classification results and the file data to be reviewed, and generate classification summary data. The row-level balance verification module 60 is used to generate code classification results based on the classification summary data, and to perform row-level quantity balance verification based on the row-level text increment corresponding to each change file and the classification summary data, and generate balance verification records.

[0135] In one embodiment, the change context extraction module 10 is specifically used for: Obtain code change events, and read repository context data, file path set, and diff content set from the code change events; The set of file paths and the set of differences are parsed to determine the corresponding file paths and differences. Each changed file is determined based on the corresponding file paths and differences, and a correspondence is established between each changed file and its path and its difference. Extract project type features, dependency ecosystem features, and framework features from the repository context data to generate global project environment information; For each changed file, the path of the changed file is divided into multiple path segments, and directory structure hierarchy information is generated according to the arrangement hierarchy of each path segment; Extract the file name, file type identifier, and binary identifier from the change file path and change difference content corresponding to each change file to generate file metadata; Identify the new content and new locations from the change differences in each change file, organize the new content according to the new locations, and generate line-level text increments.

[0136] In one embodiment, the map feature matching module 20 is specifically used for: For each changed file, the project type characteristics, dependency ecosystem characteristics, and framework characteristics in the global project environment information are determined as environment feature items. Directory feature items, file feature items, and content feature items are extracted from the directory structure hierarchy information, file metadata, and line-level text increments corresponding to each changed file. The environment feature items, directory feature items, file feature items, and content feature items are combined to generate a set of feature items to be matched. From the context feature map, determine the feature nodes to be matched that correspond to the types of the environment feature, the directory feature, the file feature, and the content feature, and determine the candidate category nodes corresponding to each feature node to be matched; Each feature item in the set of features to be matched is matched with the corresponding feature node to be matched to determine the hit feature node, and a matching evidence item is generated based on the mutually matched feature items, the hit feature node and the candidate category node corresponding to the hit feature node. For each changed document, the corresponding matching evidence items are grouped according to the candidate category nodes, the matching evidence items pointing to the same candidate category node are merged, and candidate category items are generated based on the merged matching evidence items and the corresponding candidate category nodes. For each changed document, the corresponding candidate classification items are summarized to generate an initial candidate classification set for each changed document, and the matching evidence items corresponding to each candidate classification item are summarized to generate matching evidence data for each changed document.

[0137] In one embodiment, the classification conflict resolution module 30 is specifically used for: For each change file, candidate classification items are extracted from the corresponding initial classification candidate set. Based on the conflict relationship between the candidate category nodes corresponding to each candidate classification item in the context feature map, candidate classification items that do not conflict with other candidate classification items are determined as direct classification items, and candidate classification items that conflict with other candidate classification items are determined as conflicting classification items. Extract matching evidence items corresponding to each conflict category from the matching evidence data, and generate evidence support for each conflict category based on the number of matching evidence items and the type distribution of the corresponding feature items. Priority and confidence indices of candidate category nodes corresponding to each conflict classification item are obtained from the context feature map. The conflict classification items are filtered according to the priority indices. When only one conflict classification item is retained after filtering, the uniquely retained conflict classification item is taken as the target classification item. When multiple conflict classification items with the same priority are retained after filtering, the multiple conflict classification items with the same priority are compared based on the confidence index and evidence support corresponding to each conflict classification item. When only one conflict classification item is retained after comparison, the uniquely retained conflict classification item is taken as the target classification item to complete the classification conflict resolution. The change files whose corresponding initial classification candidate set is empty, and the change files that have conflicting classification items but fail to determine a unique target classification item after the classification conflict resolution are identified as change files to be reviewed. The change files to be reviewed, the corresponding initial classification candidate set, and the matching evidence data are used to generate the change file data to be reviewed. Summarize the direct classification items and target classification items corresponding to the change files in each change file, excluding the change files to be reviewed, and generate the target file classification results.

[0138] In one embodiment, the line-level content recognition module 40 is specifically used for: Extract the file category corresponding to each changed file from the target file classification results, determine the changed files belonging to the valid code category as candidate valid files, and determine the changed files other than the candidate valid files as the remaining changed files; Extract line-level content feature nodes from the context feature map that correspond to blank content, annotation content, log content, debugging content, test content, simulation content, automatically generated content, or content generated in the auxiliary process; For each candidate valid file, multiple text lines are extracted from the corresponding line-level text increment, and adjacent text lines are determined according to the arrangement position of each text line in the line-level text increment. Line text features are extracted from each text line, and adjacent line context features are extracted from each text line and its corresponding adjacent text lines. The line text features and the adjacent line context features are matched with the line-level content feature nodes to determine the line-level content feature nodes hit by each text line. Based on the continuous hit relationship of adjacent text lines to the line-level content feature nodes, single-line hit content and continuous segment hit content are identified. The text lines corresponding to the single-line hit content and the consecutive segment hit content are determined as deducted text lines, and the text lines in the line-level text increment corresponding to the candidate valid file, excluding the deducted text lines, are determined as retained text lines.

[0139] In one embodiment, the classification data aggregation module 50 is specifically used for: The deduction category is determined based on the content type of each deduction text line, and each deduction text line is associated with the corresponding changed file and the deduction category to generate a deduction classification record. The file category of the changed file corresponding to the retained text line is determined based on the target file classification result, and the retained text line is associated with the corresponding changed file and the corresponding file category to generate a retention classification record. The change files in the remaining change files that correspond to the data of the file to be reviewed are identified as change files to be reviewed, and the change files in the remaining change files other than the change files to be reviewed are identified as classified remaining change files; Based on the target file classification results, determine the file category corresponding to the remaining classified changed files, assign the line-level text increments corresponding to the remaining classified changed files to the corresponding file category, and generate remaining classification records. Associate the line-level text increment corresponding to the changed file to be reviewed with the data of the file to be reviewed to generate a category record to be reviewed; Based on each change document, summarize the corresponding deduction category records, retained category records, remaining category records, and category records pending review to generate category summary data.

[0140] In one embodiment, the row-level balance check module 60 is specifically used for: Extract the category and category text line corresponding to each change file from the categorized summary data, summarize the category text line according to the category, and generate code categorization results; The number of original text lines is determined from the line-level text increments corresponding to each changed file, and the number of category text lines corresponding to each changed file is determined from the categorized summary data; For each modified document, the number of original text lines is compared with the number of categorized text lines to generate a line-level count verification result; Based on the row-level quantity verification results, identify the change files with quantity discrepancies, and determine the corresponding category text line information of the change files with quantity discrepancies from the category summary data; Summarize the line-level quantity verification results for each changed document, as well as the category text line information for changed documents with quantity discrepancies, and generate a balance verification record.

[0141] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 10As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When executed by the processor, the computer program implements the functions or steps of a code classification method based on context feature maps on the server side.

[0142] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 11 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a code classification method based on context feature maps.

[0143] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain code change events, identify each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata, and line-level text increments from the code change events; The global engineering environment information, the directory structure hierarchy information, the file metadata and the line-level text increment are matched with the pre-configured context feature map to generate an initial classification candidate set and matching evidence data corresponding to each changed file; Based on the initial candidate classification set and the matching evidence data, candidate classification determination and classification conflict resolution are performed to generate target file classification results and file data to be reviewed. Based on the target file classification results, candidate valid files are determined, and the changed files in each changed file other than the candidate valid files are determined as the remaining changed files. Based on the context feature map, line-level content recognition is performed on the line-level text increments corresponding to the candidate valid files to generate deducted text lines and retained text lines. Based on the target file classification results and the file data to be reviewed, the deducted text lines, the retained text lines, and the line-level text increments corresponding to the remaining changed files are classified and summarized to generate classified summary data. Based on the categorized summary data, code categorization results are generated, and a row-level quantity balance check is performed based on the row-level text increment corresponding to each change file and the categorized summary data, generating a balance check record.

[0144] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Obtain code change events, identify each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata, and line-level text increments from the code change events; The global engineering environment information, the directory structure hierarchy information, the file metadata and the line-level text increment are matched with the pre-configured context feature map to generate an initial classification candidate set and matching evidence data corresponding to each changed file; Based on the initial candidate classification set and the matching evidence data, candidate classification determination and classification conflict resolution are performed to generate target file classification results and file data to be reviewed. Based on the target file classification results, candidate valid files are determined, and the changed files in each changed file other than the candidate valid files are determined as the remaining changed files. Based on the context feature map, line-level content recognition is performed on the line-level text increments corresponding to the candidate valid files to generate deducted text lines and retained text lines. Based on the target file classification results and the file data to be reviewed, the deducted text lines, the retained text lines, and the line-level text increments corresponding to the remaining changed files are classified and summarized to generate classified summary data. Based on the categorized summary data, code categorization results are generated, and a row-level quantity balance check is performed based on the row-level text increment corresponding to each change file and the categorized summary data, generating a balance check record.

[0145] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0146] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0147] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0148] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0149] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A code classification method based on context feature maps, characterized in that, Includes the following steps: Obtain code change events, identify each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata, and line-level text increments from the code change events; The global engineering environment information, the directory structure hierarchy information, the file metadata and the line-level text increment are matched with the pre-configured context feature map to generate an initial classification candidate set and matching evidence data corresponding to each changed file; Based on the initial candidate classification set and the matching evidence data, candidate classification determination and classification conflict resolution are performed to generate target file classification results and file data to be reviewed. Based on the target file classification results, candidate valid files are determined, and the changed files in each changed file other than the candidate valid files are determined as the remaining changed files. Based on the context feature map, line-level content recognition is performed on the line-level text increments corresponding to the candidate valid files to generate deducted text lines and retained text lines. Based on the target file classification results and the file data to be reviewed, the deducted text lines, the retained text lines, and the line-level text increments corresponding to the remaining changed files are classified and summarized to generate classified summary data. Based on the categorized summary data, code categorization results are generated, and a row-level quantity balance check is performed based on the row-level text increment corresponding to each change file and the categorized summary data, generating a balance check record.

2. The code classification method based on context feature maps as described in claim 1, characterized in that, Obtain code change events, identify each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata, and line-level text increments corresponding to each changed file from the code change events, including: Obtain code change events, and read repository context data, file path set, and diff content set from the code change events; The set of file paths and the set of differences are parsed to determine the corresponding file paths and differences. Each changed file is determined based on the corresponding file paths and differences, and a correspondence is established between each changed file and its path and its difference. Extract project type features, dependency ecosystem features, and framework features from the repository context data to generate global project environment information; For each changed file, the path of the changed file is divided into multiple path segments, and directory structure hierarchy information is generated according to the arrangement hierarchy of each path segment; Extract the file name, file type identifier, and binary identifier from the change file path and change difference content corresponding to each change file to generate file metadata; Identify the new content and new locations from the change differences in each change file, organize the new content according to the new locations, and generate line-level text increments.

3. The code classification method based on context feature maps as described in claim 1, characterized in that, The global project environment information, the directory structure hierarchy information, the file metadata, and the line-level text increments are matched with a pre-configured context feature map to generate an initial classification candidate set and matching evidence data for each changed file, including: For each changed file, the project type characteristics, dependency ecosystem characteristics, and framework characteristics in the global project environment information are determined as environment feature items. Directory feature items, file feature items, and content feature items are extracted from the directory structure hierarchy information, file metadata, and line-level text increments corresponding to each changed file. The environment feature items, directory feature items, file feature items, and content feature items are combined to generate a set of feature items to be matched. From the context feature map, determine the feature nodes to be matched that correspond to the types of the environment feature, the directory feature, the file feature, and the content feature, and determine the candidate category nodes corresponding to each feature node to be matched; Each feature item in the set of features to be matched is matched with the corresponding feature node to be matched to determine the hit feature node, and a matching evidence item is generated based on the mutually matched feature items, the hit feature node and the candidate category node corresponding to the hit feature node. For each changed document, the corresponding matching evidence items are grouped according to the candidate category nodes, the matching evidence items pointing to the same candidate category node are merged, and candidate category items are generated based on the merged matching evidence items and the corresponding candidate category nodes. For each changed document, the corresponding candidate classification items are summarized to generate an initial candidate classification set for each changed document, and the matching evidence items corresponding to each candidate classification item are summarized to generate matching evidence data for each changed document.

4. The code classification method based on context feature maps as described in claim 1, characterized in that, Based on the initial candidate classification set and the matching evidence data, candidate classification determination and classification conflict resolution are performed to generate target file classification results and file data to be reviewed, including: For each change file, candidate classification items are extracted from the corresponding initial classification candidate set. Based on the conflict relationship between the candidate category nodes corresponding to each candidate classification item in the context feature map, candidate classification items that do not conflict with other candidate classification items are determined as direct classification items, and candidate classification items that conflict with other candidate classification items are determined as conflicting classification items. Extract matching evidence items corresponding to each conflict category from the matching evidence data, and generate evidence support for each conflict category based on the number of matching evidence items and the type distribution of the corresponding feature items. Priority and confidence indices of candidate category nodes corresponding to each conflict classification item are obtained from the context feature map. The conflict classification items are filtered according to the priority indices. When only one conflict classification item is retained after filtering, the uniquely retained conflict classification item is taken as the target classification item. When multiple conflict classification items with the same priority are retained after filtering, the multiple conflict classification items with the same priority are compared based on the confidence index and evidence support corresponding to each conflict classification item. When only one conflict classification item is retained after comparison, the uniquely retained conflict classification item is taken as the target classification item to complete the classification conflict resolution. The change files whose corresponding initial classification candidate set is empty, and the change files that have conflicting classification items but fail to determine a unique target classification item after the classification conflict resolution are identified as change files to be reviewed. The change files to be reviewed, the corresponding initial classification candidate set, and the matching evidence data are used to generate the change file data to be reviewed. Summarize the direct classification items and target classification items corresponding to the change files in each change file, excluding the change files to be reviewed, and generate the target file classification results.

5. The code classification method based on context feature maps as described in claim 1, characterized in that, Based on the target file classification results, candidate valid files are determined, and the changed files in each changed file other than the candidate valid files are determined as the remaining changed files. Line-level content recognition is performed on the line-level text increments corresponding to the candidate valid files according to the context feature map, generating deducted text lines and retained text lines, including: Extract the file category corresponding to each changed file from the target file classification results, determine the changed files belonging to the valid code category as candidate valid files, and determine the changed files other than the candidate valid files as the remaining changed files; Extract line-level content feature nodes from the context feature map that correspond to blank content, annotation content, log content, debugging content, test content, simulation content, automatically generated content, or content generated in the auxiliary process; For each candidate valid file, multiple text lines are extracted from the corresponding line-level text increment, and adjacent text lines are determined according to the arrangement position of each text line in the line-level text increment. Line text features are extracted from each text line, and adjacent line context features are extracted from each text line and its corresponding adjacent text lines. The line text features and the adjacent line context features are matched with the line-level content feature nodes to determine the line-level content feature nodes hit by each text line. Based on the continuous hit relationship of adjacent text lines to the line-level content feature nodes, single-line hit content and continuous segment hit content are identified. The text lines corresponding to the single-line hit content and the consecutive segment hit content are determined as deducted text lines, and the text lines in the line-level text increment corresponding to the candidate valid file, excluding the deducted text lines, are determined as retained text lines.

6. The code classification method based on context feature maps as described in claim 1, characterized in that, Based on the target file classification results and the file data to be reviewed, the deducted text lines, the retained text lines, and the line-level text increments corresponding to the remaining changed files are classified and summarized to generate classified summary data, including: The deduction category is determined based on the content type of each deduction text line, and each deduction text line is associated with the corresponding changed file and the deduction category to generate a deduction classification record. The file category of the changed file corresponding to the retained text line is determined based on the target file classification result, and the retained text line is associated with the corresponding changed file and the corresponding file category to generate a retention classification record. The change files in the remaining change files that correspond to the data of the file to be reviewed are identified as change files to be reviewed, and the change files in the remaining change files other than the change files to be reviewed are identified as classified remaining change files; Based on the target file classification results, determine the file category corresponding to the remaining classified changed files, assign the line-level text increments corresponding to the remaining classified changed files to the corresponding file category, and generate remaining classification records. Associate the line-level text increment corresponding to the changed file to be reviewed with the data of the file to be reviewed to generate a category record to be reviewed; Based on each change document, summarize the corresponding deduction category records, retained category records, remaining category records, and category records pending review to generate category summary data.

7. The code classification method based on context feature maps as described in claim 1, characterized in that, Based on the summarized data, code classification results are generated, and a line-level quantity balance check is performed based on the line-level text increments corresponding to each change file and the summarized data, generating a balance check record, including: Extract the category and category text line corresponding to each change file from the categorized summary data, summarize the category text line according to the category, and generate code categorization results; The number of original text lines is determined from the line-level text increments corresponding to each changed file, and the number of category text lines corresponding to each changed file is determined from the categorized summary data; For each modified document, the number of original text lines is compared with the number of categorized text lines to generate a line-level count verification result; Based on the row-level quantity verification results, identify the change files with quantity discrepancies, and determine the corresponding category text line information of the change files with quantity discrepancies from the category summary data; Summarize the line-level quantity verification results for each changed document, as well as the category text line information for changed documents with quantity discrepancies, and generate a balance verification record.

8. A code classification device based on context feature maps, characterized in that, The code classification device based on context feature maps includes: The change context extraction module is used to obtain code change events, determine each changed file from the code change events, and extract global project environment information, directory structure hierarchy information, file metadata and line-level text increments corresponding to each changed file from the code change events; The graph feature matching module is used to match the global engineering environment information, the directory structure hierarchy information, the file metadata and the line-level text increment with the pre-configured context feature graph to generate an initial classification candidate set and matching evidence data corresponding to each changed file; The classification conflict resolution module is used to determine candidate classification and resolve classification conflicts based on the initial candidate classification set and the matching evidence data, and generate target file classification results and file data to be reviewed. The line-level content recognition module is used to determine candidate valid files based on the target file classification results, and to determine the changed files other than the candidate valid files in each changed file as the remaining changed files. The module performs line-level content recognition on the line-level text increments corresponding to the candidate valid files according to the context feature map, and generates deducted text lines and retained text lines. The classification data summary module is used to classify and summarize the deducted text lines, the retained text lines, and the line-level text increments corresponding to the remaining changed files based on the target file classification results and the file data to be reviewed, and generate classification summary data. The row-level balance verification module is used to generate code classification results based on the classification summary data, and to perform row-level quantity balance verification based on the row-level text increments corresponding to each change file and the classification summary data, and generate balance verification records.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a context-map-based code classification program stored in the memory and executable on the processor, wherein the context-map-based code classification program, when executed by the processor, implements the steps of the context-map-based code classification method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a code classification program based on context feature maps, which, when executed by a processor, implements the steps of the code classification method based on context feature maps as described in any one of claims 1-7.

Images