Method, system and equipment for salvaging and displaying handwriting track data of user

Abstract

The invention belongs to the field of computers, and relates to a method, a system and equipment for salvaging and displaying handwriting track data of a user, and the method comprises the following steps: carrying out query processing on a log service according to a user identifier and an operation time range; generating track log data comprising a track coordinate point list, a request unique identifier, an interface path, an actual return result and an expected result; performing analysis and line drawing processing on a track coordinate point list in the track log data to generate a track diagram file; performing assembly processing on a track coordinate point list, a request unique identifier, an interface path, an actual return result, an expected result and a storage address of a track diagram file in the track log data to generate a data packet containing troubleshooting information; and carrying out integration and display processing on the data packet, and generating a rendering page used for displaying the track diagram file and the track log information. According to the invention, when the handwriting track abnormity is checked, the operation complexity is reduced, and the problem positioning efficiency is improved as much as possible.

Description

A method, system, and device for retrieving and displaying user handwritten trajectory data. Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system and device for retrieving and displaying user handwritten trajectory data. Background Technology

[0002] In online education platforms, user interaction with learning content through handwriting has become a common practice. When users report malfunctions in handwriting-related functions, technical staff typically need to conduct a comprehensive analysis combining various information, such as user operation logs, server-side interface responses, and the actual handwriting patterns of the user's input, to pinpoint the root cause of the problem.

[0003] In one existing technical solution, the aforementioned data types are managed and provided separately by independent backend systems. Technical personnel first need to retrieve relevant operation records and API call results from the log management system based on user identifiers and time ranges. Subsequently, they may need to use independent trajectory playback tools or code scripts to import the trajectory coordinate data extracted from the logs to reconstruct the trajectory graph. Finally, they manually compare and correlate the reconstructed trajectory graph with the server-side judgment results recorded in the logs to complete the problem investigation.

[0004] However, in existing solutions, the operation logs, trajectory coordinate data, and trajectory visualization results relied upon for problem investigation are stored in different systems or presented in different interfaces, resulting in a disconnect between the data flow and operation flow in the entire problem investigation chain. Operators need to frequently switch between multiple independent tools or interfaces, match information, and manually associate data. This process not only increases the complexity and cognitive burden of operations but also restricts the overall efficiency of problem localization. Summary of the Invention

[0005] This application provides a method, system, and device for retrieving and displaying user handwritten trajectory data, aiming to reduce the complexity of operations and improve the efficiency of problem localization when investigating abnormal handwritten trajectories.

[0006] To address the aforementioned technical problems, this application provides the following technical solution: a method for retrieving and displaying user handwritten trajectory data, comprising: querying a log service based on a user identifier and operation time range to generate trajectory log data containing a list of trajectory coordinate points, a unique request identifier, an interface path, actual return results, and expected results; parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory graph file; assembling the list of trajectory coordinate points, the unique request identifier, the interface path, the actual return results, the expected results, and the storage address of the trajectory graph file in the trajectory log data to generate a data packet containing troubleshooting information; and integrating and displaying the data packet to generate a rendering page for displaying the trajectory graph file and the trajectory log information.

[0007] On the other hand, embodiments of this application also provide the following technical solution: a system for retrieving and displaying user handwritten trajectory data, comprising: a log data acquisition module, used to query and process log services according to user identifier and operation time range to generate trajectory log data containing a list of trajectory coordinate points, a unique request identifier, an interface path, actual return results, and expected results; a trajectory map acquisition module, used to parse and draw lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory map file; a data packet acquisition module, used to assemble the list of trajectory coordinate points, the unique request identifier, the interface path, the actual return results, the expected results, and the storage address of the trajectory map file in the trajectory log data to generate a data packet containing troubleshooting information; and a page rendering module, used to integrate and display the data packet to generate a rendered page for displaying the trajectory map file and the trajectory log information.

[0008] On the other hand, a computer device is provided, the device including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to realize the method for retrieving and displaying user handwritten trajectory data as described above.

[0009] The beneficial effects of this application are as follows: 1. This application directly generates trajectory log data containing a list of trajectory coordinate points, a unique request identifier, an interface path, actual return results, and expected results by querying and processing the log service based on user identifiers and operation time ranges. This step centrally obtains information that traditionally needs to be retrieved and extracted separately from multiple independent data sources such as log management systems and interface monitoring systems in a single query, avoiding frequent switching between multiple systems for initial data collection, and providing a unified data carrier with complete content for subsequent processing.

[0010] 2. This application parses and draws lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory graph file. This step directly utilizes the structured coordinate data obtained in the previous step to automatically generate a visualized trajectory graphic, replacing the traditional method of manually converting coordinate data to reproduce the trajectory using independent tools or additional scripts. The data-to-image conversion process is embedded within the workflow, reducing external dependencies and manual operation steps.

[0011] 3. This application assembles the trajectory coordinate point list, request unique identifier, interface path, actual return result, expected result, and storage address of the trajectory map file from the trajectory log data to generate a data packet containing troubleshooting information. This step encapsulates the original trajectory coordinates, key identifiers, server response conclusions, and access addresses of visualization results into a structured data set. This fundamentally changes the isolated state of various information in traditional troubleshooting, establishing an inherent relationship between all troubleshooting elements through the formation of the data packet, allowing subsequent display to be directly based on a holistic information containing complete context.

[0012] 4. This application integrates and displays the data package to generate a rendered page for displaying the trajectory map file and the trajectory log information. This step, based on the aforementioned highly integrated data package, simultaneously presents the trajectory visualization image and its strictly corresponding log details on a unified interface. This solves the pain point of operators constantly switching interfaces, visually comparing, and manually associating information due to its fragmented presentation. It allows technicians to obtain coherent, context-dependent investigation information in a single view, thereby reducing cognitive burden and making the analysis process more focused and efficient. Attached Figure Description

[0013] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 is a schematic diagram of the overall process of a method for retrieving and displaying user handwritten trajectory data provided in an embodiment of this application; Figure 2 is a structural block diagram of a system for retrieving and displaying user handwritten trajectory data provided in an embodiment of this application; Figure 3 is a hardware structural block diagram of an electronic device for a method for retrieving and displaying user handwritten trajectory data provided in an embodiment of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] Referring to Figure 1, this application embodiment provides a method for retrieving and displaying user handwritten trajectory data, including: Step 1, querying a log service based on the user identifier and operation time range to generate trajectory log data containing a list of trajectory coordinate points, a unique request identifier, an interface path, actual return results, and expected results; Step 2, parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory graph file; Step 3, assembling the list of trajectory coordinate points, the unique request identifier, the interface path, the actual return results, the expected results, and the storage address of the trajectory graph file in the trajectory log data to generate a data package containing troubleshooting information; Step 4, integrating and displaying the data package to generate a rendering page for displaying the trajectory graph file and the trajectory log information.

[0017] This application constructs a complete chain through the above steps, from centralized data querying to automatic visualization conversion, then to integrated information encapsulation, and finally to unified interface display. This chain transforms the traditionally scattered, manual, multi-step operation into a relatively automated, highly aggregated, and coherent process, effectively alleviating the efficiency constraints caused by the separation of data and operations, and is particularly suitable for scenarios involving the rapid location and analysis of handwritten trajectories.

[0018] Specifically, preferably, step 1 is implemented as follows: First, based on the user-provided unique device number (SN), the time period of the problem, and the specific application programming interface (API) path corresponding to the handwritten trajectory data, a structured query request is constructed. This query request includes three dimensions of constraints for precise log filtering. Then, the constructed query request is sent to a cloud log service system, such as Alibaba Cloud Log Service. After receiving the query request, the cloud log service system matches records that simultaneously meet the three conditions of the unique device number, time period, and application programming interface path from its massive stored log entries. Next, the system extracts several predefined key fields from the successfully matched log records. These fields include: the original trajectory coordinate point sequence generated by the user's handwritten operation (stored in list form), the unique trace identifier (TraceID) assigned by the server for this request, the complete path of the called application programming interface, the actual processing result returned by the server, and the server's preset expected correct answer. Finally, these extracted key fields are combined into a structured data set, which is the trajectory log data. This process completes the traditional method of searching in multiple systems or interfaces with a single combined condition query, and gathers all the contextual information required for subsequent analysis.

[0019] Preferably, in the specific technical implementation of step 2: the trajectory log data generated in step 1 is obtained, and the trajectory coordinate point list is located from it. The trajectory coordinate point list is usually a sequence containing multiple numerical elements, where each pair of consecutive numbers represents the x-coordinate (X) and y-coordinate (Y) of a trajectory point on a two-dimensional canvas. First, the trajectory coordinate point list is parsed and converted into a sequence of multiple coordinate pairs, each representing a specific trajectory point position. Then, based on the maximum and minimum values ​​of all coordinate pairs in the x and y directions, the size of the rectangular canvas that can accommodate the entire trajectory is dynamically calculated. Next, a digital image object with the calculated size and a white background is created in memory. Then, according to the order of the coordinate pairs in the sequence, adjacent coordinate points are connected sequentially on the image using lines of a preset color (such as black) and a preset width, thereby drawing continuous handwritten trajectory lines. This drawing process converts the abstract coordinate data sequence into an intuitive graphical representation. After drawing is completed, the digital image object is saved to the local file system or temporary storage area in a common image format (such as PNG) to generate the final trajectory image file. This method differs from traditional manual screenshotting or drawing, and achieves automated conversion from raw log data to visual graphics.

[0020] Preferably, in one scenario, step 3 is specifically implemented as follows: Simultaneously acquire the trajectory log data generated in step 1 and the trajectory image file generated in step 2. First, upload the trajectory image file to the cloud object storage service (OSS) and obtain a unique resource address (URL) that can be directly accessed via the internet. Then, create a structured data container, such as a JSON (JavaScript Object Notation) object. Within this JSON object, establish multiple independent fields, and fill in the corresponding fields with the list of trajectory coordinate points from the trajectory log data, the unique request identifier, the interface path, the actual return result, the expected result, and the unique resource address of the newly obtained trajectory image file. This operation encapsulates the scattered raw logs, the processed image, and the image access point into a self-describing structured whole, i.e., a data package containing problem investigation information. This data package integrates all the core elements required for problem reproduction and analysis, providing a unified data exchange format for multi-role collaborative investigation and avoiding information fragmentation and loss during transmission.

[0021] Preferably, the specific implementation process of step 4 is as follows: The system receives the data packet containing troubleshooting information generated in step 3 and parses the data packet to extract the content of each field. The front-end display system loads the trajectory map file via a network request based on the unique resource address of the trajectory map file in the data packet and renders it in a specific area of ​​the webpage. Simultaneously, the system displays the unique request identifier, interface path, actual return result, expected result, and trajectory coordinate point list from the data packet in a structured layout in adjacent areas of the same page. Furthermore, through front-end programming technology, an interactive association is established between the display area of ​​the trajectory image and the corresponding text information (especially the TraceID). For example, the TraceID can be displayed as a clickable hyperlink, which, when clicked, directly jumps to a more detailed distributed link tracing system interface; or, when the user hovers the mouse over a stroke in the trajectory image, the corresponding coordinate point data can be highlighted in the sidebar. Finally, the system generates a rendered page that integrates a visualized trajectory image, associated log text, and interactive functions. This page integrates information and tools that are traditionally scattered in multiple places into a single view, allowing customer service or technical personnel to complete initial problem assessment and in-depth analysis without switching contexts, thus improving the continuity and efficiency of the troubleshooting process.

[0022] Optionally, the step of parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory map file includes: step 2a, performing coordinate pair transformation on the sequence of coordinate points in the list of trajectory coordinate points to obtain a sequence of coordinate pairs, and performing line drawing on the sequence of coordinate pairs to generate a trajectory map file.

[0023] Optionally, after generating the trajectory map file, the method further includes: step 2b, uploading the trajectory map file to an object storage server to generate the storage address of the trajectory map file.

[0024] Optionally, before parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory map file, the method further includes: step 2c, comparing the actual return result with the expected result in the trajectory log data to generate a comparison result identifier.

[0025] Optionally, generating the trajectory map file includes: step 2d, coloring the lines drawn according to the coordinate sequence based on the comparison result identifier to generate the trajectory map file.

[0026] Preferably, the specific implementation process of step 2a is as follows: First, extract the list of trajectory coordinate points from the trajectory log data. This list of trajectory coordinate points is a one-dimensional array, where elements are grouped in pairs according to order, representing the horizontal coordinate (X-axis coordinate) and vertical coordinate (Y-axis coordinate) of each trajectory point. The one-dimensional array is traversed, sequentially reading every two adjacent elements and combining them into a coordinate pair representing a two-dimensional plane point. After traversal, a sequence of coordinate pairs is obtained, consisting of multiple coordinate pairs arranged in their original order. Next, the sequence of coordinate pairs is traversed to find the maximum and minimum values ​​of the horizontal coordinate and the vertical coordinate in all coordinate pairs. Based on these four extreme values, the theoretical width and height of the rectangular canvas that can completely accommodate all trajectory points are calculated. Based on this, a boundary margin can be added (e.g., increasing the width and height by a fixed pixel value or proportionally) to ensure that the trajectory lines do not hug the edges of the canvas. Then, based on the calculated canvas width and height, a digital image object of a specified size with a pure white background (RGB value 255, 255, 255) is created in memory. Finally, following the sequence of coordinate pairs, using a preset line color (e.g., black, RGB value 0,0,0) and a preset line width (e.g., 2 pixels), adjacent coordinate pairs are connected by straight line segments on the digital image object. For line drawing, an anti-aliasing algorithm can be used to smooth the edges, generating visually smoother trajectory lines. After all lines are drawn, a preliminary trajectory image file is generated. This method differs from simple static canvas drawing; by dynamically calculating the canvas size based on coordinate data, it ensures that the trajectory image is fully displayed without unnecessary blank spaces, adapting to the varying sizes of different input trajectories.

[0027] Preferably, in one scenario, step 2b is specifically implemented as follows: The trajectory map file generated in step 2a is obtained. Then, the file upload interface in the Software Development Kit (SDK) provided by the Object Storage Service (OSS) is called. The trajectory map file, as a binary data stream, along with a unique key within the storage bucket assigned to that file, is submitted to the OSS. Upon receiving the upload request, the OSS persistently stores the trajectory map file in the cloud and returns a Uniform Resource Locator (URL) uniquely corresponding to the file, accessible via Hypertext Transfer Protocol (HTTP) or its secure version (HTTPS). This URL becomes the storage address of the trajectory map file. This design transforms the trajectory map file from a local temporary asset into a persistent resource that can be directly referenced over the network, providing a technical foundation for subsequent direct embedding and display in web pages and sharing links between different teams, thus solving the collaboration bottleneck where local files cannot be directly accessed across systems.

[0028] Preferably, in the specific technical implementation of step 2c: the actual returned result field and the expected result field are read from the trajectory log data. The actual returned result is the text content returned by the server after processing the handwritten trajectory recognition request, and the expected result is the correct answer text corresponding to the request preset by the server. These two text strings are compared. The comparison process can be designed as a strict string matching judgment, or it can be designed as a more complex similarity calculation (for example, in character recognition scenarios, tolerating a certain character error). In a specific implementation, a string matching judgment is performed: if the actual returned result string is exactly the same as the expected result string, a comparison result identifier indicating "meets expectations" is generated (e.g., a boolean value of true or a status code "SUCCESS"); if they are different, a comparison result identifier indicating "does not meet expectations" is generated (e.g., a boolean value of false or a status code "FAIL"). This comparison result identifier serves as the decision basis for subsequent steps. This step automates the judgment process that originally required manual visual comparison, introducing rule-based conditional branching capabilities into the process.

[0029] Preferably, the specific implementation process of step 2d is as follows: This step integrates the comparison result identifier generated in step 2c into the line drawing stage of step 2a. First, the operations described in step 2a, such as calculating the canvas size and creating a white background image object, are performed. When preparing to draw lines, the line color to be used is determined according to the value of the comparison result identifier. Specifically, a set of color mapping rules is defined: when the comparison result identifier is a value indicating "meets expectations", a first preset color (such as green, RGB value 0,128,0) is selected as the line color; when the comparison result identifier is a value indicating "does not meet expectations", a second preset color (such as red, RGB value 255,0,0) is selected as the line color. Then, using this dynamically determined line color (and preset line width and anti-aliasing settings), trajectory lines are drawn on the image object according to the coordinate pair sequence. After drawing, the final trajectory map file is generated. This technical design makes the visualization result not only present the trajectory shape, but also intuitively encode the result status (success or failure) of this handwriting recognition request through color semantics. This differs from traditional post-event manual correlation judgment. Business logic judgment results are integrated into the image generation stage, which enables the problem trajectory (red) to be quickly visually highlighted from a large number of trajectories, greatly assisting the efficiency of manual screening.

[0030] Optionally, obtaining the trajectory log data further includes: Step 11, querying the log service based on the user identifier, operation time range, and target application interface to generate an initial log dataset; Step 12, comparing and analyzing the actual return results and expected results in the initial log dataset based on preset filtering rules to generate preliminary suspicious log identifiers; Step 13, based on the preliminary suspicious log identifiers, performing trajectory coordinate anomaly feature determination processing on the log data in the initial log dataset that have the preliminary suspicious log identifiers to generate final suspicious log identifiers; Step 14, filtering the corresponding log data from the initial log dataset based on the final suspicious log identifiers to generate the trajectory log data.

[0031] Optionally, the "based on preset filtering rules" in step 12 specifically refers to the matching degree rules between the interface return status code rules and the actual return results and the expected results.

[0032] Optionally, the "trajectory coordinate anomaly feature determination processing" in step 13 includes: step 131, performing spatial distribution analysis processing on the list of trajectory coordinate points contained in the log data with the preliminary suspicious log identifier in the initial log dataset to generate coordinate point distribution density features; step 132, performing temporal continuity analysis processing on the list of trajectory coordinate points contained in the log data with the preliminary suspicious log identifier in the initial log dataset to generate stroke continuity features; step 133, performing anomaly feature logic determination processing based on the coordinate point distribution density features and the stroke continuity features to generate the final suspicious log identifier.

[0033] Optionally, the "spatial distribution analysis and processing of coordinate points" in step 131 specifically involves calculating the dispersion or clustering of the trajectory coordinate point list within a preset canvas area to generate the coordinate point distribution density features.

[0034] Optionally, the "coordinate point temporal continuity analysis and processing" in step 132 specifically involves: calculating the instantaneous distance sequence between consecutive coordinate points in the trajectory coordinate point list, and analyzing the number of jump points exceeding a preset threshold in the instantaneous distance sequence to generate the stroke continuity feature.

[0035] Optionally, the "abnormal feature logic judgment processing" in step 133 specifically means: when the coordinate point distribution density feature indicates that the coordinate points are abnormally clustered in the canvas edge area, or when the stroke continuity feature indicates that the stroke continuity is lower than the preset standard, a final suspicious log identifier indicating abnormal operation behavior is generated.

[0036] Preferably, the specific implementation process of step 11 is as follows: First, input information from user problem feedback is received. This input information includes at least the user device number (SN), the time period in which the problem occurred, and the specific application programming interface (API) path involving the handwriting trajectory function. Based on these three types of information, a structured composite query condition is constructed. This composite query condition differs from traditional single-condition or fuzzy queries, explicitly requiring that log records must simultaneously meet the precise matching of the three dimensions of device, time, and interface path. Next, by calling the query application programming interface (API) provided by cloud log services (such as Alibaba Cloud Log Service SLS), the constructed composite query condition is submitted to the log service backend. The log service backend performs a fast index-based retrieval in its stored massive log stream data, locates and returns the set of all original log records that simultaneously meet the three conditions, and this set is the initial log dataset. This step, by constructing and executing a highly specific composite query, directly and significantly narrows the data range from the source, laying an efficient data foundation for subsequent accurate analysis, replacing the inefficient practice of manually browsing a large number of irrelevant logs.

[0037] Preferably, in the specific technical implementation of step 12: the initial log dataset generated in step 11 is obtained, and each log record in it is traversed. For each log record, a two-layer judgment is performed using preset filtering rules. The first layer of judgment is based on the interface return status code rule: the HTTP status code recorded in the log is checked, and if the status code does not belong to the category indicating success (e.g., non-2xx series status codes), the log record is immediately marked with a preliminary suspicious status. The second layer of judgment is based on the matching degree rule between the actual returned result and the expected result: if the status code belongs to the success category, the actual returned result text and the expected result text in the log are further extracted, and the similarity between these two text strings is calculated. In a specific implementation, the matching degree rule adopts a string similarity algorithm based on edit distance, which is an internationally common algorithm and will not be elaborated here. The minimum number of single-character editing operations required to modify the actual returned result text to the expected result text is calculated, and this number is divided by the length of the expected result text to obtain an error rate. If the error rate exceeds a preset threshold (e.g., the error rate is greater than 5%), the log record is also marked with a preliminary suspicious status. After the traversal is complete, a unified preliminary suspicious log identifier is generated for all log records marked as initially suspicious (for example, adding a boolean field `is_suspicious` to the record and setting it to `true`). This step introduces a two-level progressive automated judgment logic, which not only captures explicit service errors (through status codes) but also implicit logical errors (through result matching), thus achieving preliminary automated filtering of "suspicious" logs.

[0038] Preferably, in one scenario, step 13 is specifically implemented as follows: Obtain the initial log dataset processed in step 12 and carrying preliminary suspicious log identifiers. First, filter out all log data subsets with preliminary suspicious log identifiers. Then, perform trajectory coordinate anomaly feature determination processing on each log data in this subset. This processing is specifically divided into two parallel and complementary analysis dimensions: The first dimension is coordinate point spatial distribution analysis processing (corresponding to step 131): For a list of trajectory coordinate points in a log, it is assumed that it should be drawn within a standard canvas (e.g., a rectangular area with a resolution of 1024x768 pixels). Calculate the standard deviation of the x-coordinate and the standard deviation of the y-coordinate of all coordinate points in the list. If both the standard deviation of the x-axis and the standard deviation of the y-axis are less than a very low threshold (e.g., less than 2% of the canvas width / height), then the coordinate points are determined to be abnormally clustered, and a coordinate point distribution density feature indicating "highly concentrated distribution" is generated. Furthermore, if the average position of these clustered coordinate points is close to the edge of the canvas (e.g., the average x-axis is less than 5% or greater than 95% of the canvas width, or the average y-axis is less than 5% or greater than 95% of the canvas height), then the coordinate point distribution density feature is marked as "abnormally clustered at the edge".

[0039] The second dimension is the temporal continuity analysis of coordinate points (corresponding to step 132): For the list of trajectory coordinate points in the same log, traverse every two adjacent coordinate points (x_i, y_i) and (x_{i+1}, y_{i+1}) in the collection order. Calculate the Euclidean distance between them to form an instantaneous distance sequence. Analyze this instantaneous distance sequence and count the number of jump points that exceed a preset physical distance threshold (e.g., more than 50 pixels). If the ratio of the number of jump points to the total number of points exceeds a continuity threshold (e.g., more than 10%), it is considered that there is an abnormal interruption or jump in the stroke, generating a stroke continuity feature indicating "low continuity". In one embodiment, the default value of the preset physical distance threshold is 50 pixels, based on the sampling accuracy of mainstream handwriting devices (100dpi) and the standard canvas resolution (1024×768 pixels); if the device sampling accuracy is 200dpi, the threshold can be proportionally reduced to 25 pixels, and the threshold is reduced by 50% for every doubling of the sampling accuracy. The continuity threshold of 10% is derived from statistics of 1000 normal handwritten trajectory samples. The proportion of jump points in normal samples is less than 5%. The 10% threshold can cover slight device jitter errors and accurately identify abnormal jump trajectories.

[0040] Finally, based on the coordinate point distribution density characteristics and stroke continuity characteristics, anomaly feature logic judgment processing is performed (corresponding to step 133). The judgment logic is set as follows: if the coordinate point distribution density characteristic is "abnormally clustered at the edge", or the stroke continuity characteristic is "low continuity", then a final suspicious log identifier indicating abnormal operation behavior is generated. This step shifts the analysis of trajectory data from simply judging the correctness of service results to analyzing the user's original input behavior patterns. By quantitatively evaluating the spatial distribution rationality and temporal continuity of the trajectory, it is possible to effectively identify "hidden" problem logs caused by abnormal user operations (such as clicking only in the corner) or abnormal input device signals (such as coordinate point jumps). The service return result of these problem logs may be successful, but they actually represent potential product experience or hardware problems, thus achieving deeper problem discovery.

[0041] Preferably, step 14 is implemented as follows: Receive the initial log dataset processed in step 13 and updated with the final suspicious log identifier. Traverse the dataset and filter out all log records with the final suspicious log identifier. Extract these filtered log records from the initial log dataset and reorganize them into a new, streamlined log set. This new log set is the trajectory log data defined in step 1, containing user handwritten trajectory operation records that are considered most valuable for investigation and reflect potential anomalies after being filtered by multiple automated rules. This step completes the automated focusing process from massive amounts of raw logs to high-value target logs, ensuring that subsequent visualization and analysis steps can efficiently target the truly problematic data, thus improving the overall targeting and efficiency of the investigation process.

[0042] Optionally, the step of parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory map file includes: Step 21, parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate an original trajectory map; Step 22, obtaining a standard trajectory coordinate point list associated with the trajectory log data; Step 23, comparing and visualizing the coordinate point differences between the list of trajectory coordinate points in the trajectory log data and the standard trajectory coordinate point list to generate a trajectory difference comparison map; Step 24, combining the original trajectory map and the trajectory difference comparison map to generate the trajectory map file.

[0043] Optionally, step 23, "coordinate point difference comparison and visualization rendering processing", includes: step 231, performing point-by-point position difference calculation processing on the list of trajectory coordinate points in the trajectory log data and the list of standard trajectory coordinate points to generate a coordinate point difference dataset; step 232, based on the coordinate point difference dataset, performing visualization rendering processing on the difference areas using rendering colors different from the original trajectory map to generate the trajectory difference comparison map.

[0044] Preferably, the specific implementation process of step 21 is as follows: The processing object of this step is the list of trajectory coordinate points in the trajectory log data. First, coordinate pair transformation processing is performed on the list of trajectory coordinate points, converting it from a one-dimensional array into a sequence of coordinate pairs consisting of multiple (x, y) coordinate pairs. Next, based on this coordinate pair sequence, the minimum rectangular canvas size that can completely accommodate all trajectory points is dynamically calculated. Subsequently, according to the calculated canvas size, a new image with a pure white background is created in memory. Finally, using a first preset color (e.g., dark gray, RGB value 64, 64, 64) and a preset width of lines, adjacent coordinate pairs are connected on the new image according to the order of the coordinate pair sequence, thereby drawing the handwritten trajectory lines actually input by the user. The image file obtained after drawing is the original trajectory diagram. The original trajectory diagram generated in this step faithfully reflects the user's original input data.

[0045] Preferably, in one scenario, step 22 is specifically implemented as follows: This step aims to obtain a benchmark for comparative analysis. The processing is based on trajectory log data, particularly the question or character identifiers implicit in the "Expected Result" or "Interface Path" fields. First, the trajectory log data is parsed to extract information that uniquely identifies the current handwriting task. For example, the target character "A" is extracted from the "Expected Result" field, or the question ID "123" is parsed from the "Interface Path" parameter. Then, this identifier information is used as a query key to access a pre-set trajectory template database. This trajectory template database stores lists of standardized writing trajectory coordinate points for various standard characters or graphics. These lists are generated by averaging a large number of standardized writing samples or by calibration by educational experts. Through querying, a list of standard trajectory coordinate points corresponding to the current task is obtained. This list of standard trajectory coordinate points defines the "correct" or "expected" handwriting space path in the context of the current problem.

[0046] Preferably, in the specific technical implementation of step 23: the core of this step is to quantitatively compare and visually present the user trajectory with the standard trajectory. The processing objects are the trajectory coordinate point list (user trajectory) used in step 21 and the standard trajectory coordinate point list obtained in step 22. First, the point-by-point position difference calculation processing of step 231 is performed: since the two coordinate point lists contain different numbers of points, or the sampling positions of the points do not completely correspond, sequence alignment is required first. One implementation is to resample the two lists, normalize them into a sequence with the same number of points, or treat the standard trajectory coordinate point list as a continuous path and calculate the shortest Euclidean distance from each user coordinate point to this standard path. After completing the alignment or distance calculation, for each user trajectory coordinate point or each aligned position, the difference value (e.g., Euclidean distance) between it and the corresponding standard position is calculated, thereby generating a coordinate point difference dataset consisting of a series of difference values. Next, the visualization rendering processing of step 232 is performed: a new image with a transparent background of the same size as the original trajectory map is created. Based on a coordinate point difference dataset, for regions where the difference value exceeds the visual perception threshold (e.g., a difference distance greater than 5 pixels), a second preset color (e.g., semi-transparent red, RGBA value 255, 0, 0, 128) is used to draw at the corresponding position on the new image. This drawing can be done by drawing highlighted circles, filling the difference region with color blocks, or thickening the difference line segments. Ultimately, this new image, highlighting the difference regions with different colors, is the trajectory difference comparison map. This technology differs from traditional simple side-by-side comparisons; by calculating and rendering spatial differences, it intuitively encodes information such as "where is different" and "how big is the difference," making problem points (such as stroke misalignment or structural errors) immediately apparent.

[0047] Preferably, the specific implementation process of step 24 is as follows: The purpose of this step is to synthesize a final, information-rich analysis view. The processing object is the original trajectory map generated in step 21 and the trajectory difference comparison map generated in step 23. First, the trajectory difference comparison map is used as the upper layer and overlaid on the original trajectory map as the lower layer with a specific transparency (alpha channel blending). This overlay operation allows the red highlight areas of the difference to be semi-transparently covered over the gray original trajectory, so that the user can see the original handwriting while also clearly seeing the highlighted difference parts. Then, the overlaid and synthesized image is processed together with the original trajectory map and the trajectory difference comparison map for layout. For example, a three-grid layout can be used: the left image contains the original trajectory map labeled "User Input," the middle image contains the trajectory difference comparison map labeled "Difference Highlight," and the right image contains the overlaid and synthesized image labeled "Comprehensive View." Finally, this layout image containing multi-view information is saved as a single image file, i.e., the trajectory map file described in this application is generated. The trajectory map file generated by this combined processing not only provides a view of the raw data, but also integrates a difference insight view obtained through intelligent analysis. This allows technical or teaching and research personnel to complete the preliminary analysis from phenomenon observation to problem location in a single map, improving the technical interpretability of trajectory data and the efficiency of problem investigation.

[0048] Optionally, the process of integrating and displaying the data packet to generate a rendered page for displaying the trajectory map file and the trajectory log information includes: Step 41, parsing the data packet to extract the storage address of the trajectory map file, the list of trajectory coordinate points, and the unique request identifier; Step 42, loading the trajectory map file according to its storage address, and generating an interactive trajectory heatmap layer according to the list of trajectory coordinate points; Step 43, associating and binding the loaded trajectory map file, the interactive trajectory heatmap layer, and the unique request identifier to generate interactive page elements; Step 44, integrating and displaying the interactive page elements and other information in the data packet to generate the rendered page.

[0049] Optionally, step 42, "generating an interactive trajectory heatmap layer based on the trajectory coordinate point list," specifically involves: statistically processing the trajectory coordinate point list for the duration of point dwell or the number of redraws, and generating an interactive trajectory heatmap layer using color intensity to represent the operation heatmap based on the statistical results. Specifically: First, the canvas area is rasterized into an M×N grid. The trajectory coordinate point list is traversed, each coordinate point is mapped to its corresponding grid cell, and the count of that cell is accumulated to simulate the "number of redraws." If the log data contains a timestamp sequence, the time difference between adjacent points is calculated. Consecutive point groups with a time difference that is too small (e.g., less than 100 milliseconds) are considered "dwellings," and the cumulative weight of the corresponding area is increased. Then, the cumulative value of each grid cell is normalized. Finally, a predefined color mapping function is applied (e.g., using linear interpolation to map normalized values ​​to an RGBA color sequence from light yellow [low heat] to dark red [high heat]), and rectangles with corresponding color and transparency are drawn for each grid cell on another transparent Canvas layer, overlaid on the original trajectory map to form an interactive heatmap layer.

[0050] Optionally, the "association binding process" in step 43 specifically involves: constructing the unique identifier of the request into a hyperlink pointing to the end-to-end tracking system, and binding the hyperlink to a specific display area of ​​the trajectory map file.

[0051] Preferably, the specific implementation process of step 41 is as follows: The processing object of this step is a data packet containing problem investigation information, which is usually in the format of a JSON (JavaScript Object Notation, a lightweight data interchange format) object. First, the JSON data packet is parsed and converted into a structured object in memory so that its internal fields can be accessed programmatically. Next, from this structured object, the values ​​of three key fields are extracted by accessing them by key name: the first is a field named imageUrl or similar, whose value is the storage address of the trajectory map file, which is a string-formatted Uniform Resource Locator; the second is a field named tracePoints or similar, whose value is a list of trajectory coordinate points, which is an array containing several numeric elements; the third is a field named traceId, whose value is a unique request identifier, which is a string. After extraction, these three pieces of information are temporarily stored in memory variables, waiting to be used in subsequent steps. This step achieves the precise separation of the core data units required for visualization and interaction from the encapsulated data set.

[0052] Preferably, in the specific technical implementation of step 42: this step executes two subtasks in parallel, which respectively process the storage address of the trajectory map file extracted in step 41 and the list of trajectory coordinate points.

[0053] The first subtask, targeting the storage address of the trajectory map file: Using the image loading mechanism in a front-end web environment, initiate an asynchronous HTTP network request based on this storage address (a URL) to download the binary data of the trajectory map file from the object storage service. Once downloaded, decode the binary data into an image object that the browser can recognize and render, and wait for the image object to be fully loaded into memory.

[0054] The second subtask focuses on the list of trajectory coordinate points: generating an interactive trajectory heatmap layer based on this list. Specifically, the implementation involves: First, performing spatiotemporal statistical processing on the trajectory coordinate point list. One approach is to analyze the timestamp differences between adjacent points in the list (if timestamps are recorded in the logs), considering consecutive points with very small differences as instances where the user lingered or repeatedly drew within a local area, and accumulating the "lingering heat" of these areas. Another approach is to directly count the number of coordinate points in the entire list that fall within the same pixel or tiny area of ​​the canvas, using this as the "repeated drawing heat." After the statistics are complete, a two-dimensional heatmap matrix corresponding to the original canvas area is obtained, where each element represents the heat intensity of the corresponding pixel area. Then, based on the heat intensity, a preset color mapping function is applied to map the heat values ​​to color intensity values ​​with an alpha channel, generating a semi-transparent color layer with the same size as the original trajectory map. This layer is the interactive trajectory heatmap layer. Unlike static images, this layer is a vector-based or Canvas-drawn graphic element that responds to user mouse events.

[0055] This step not only loads the static result image, but also mines and generates a dynamic thermal information layer from the original coordinate data that reflects the density of user operations or the degree of hesitation, providing an additional, visualized data dimension for analyzing user writing habits and locating pause points.

[0056] Preferably, in one scenario, step 43 is specifically implemented as follows: the processing objects of this step are the trajectory map file (as an image object) loaded in step 42, the generated interactive trajectory heatmap layer, and the unique request identifier extracted in step 41. The core of the association binding process is to establish the logical and interactive connections between these three. The specific implementation consists of two steps: First, the unique request identifier is constructed into a hyperlink pointing to the end-to-end tracing system. For example, the identifier string "abc123" is concatenated with the base address of the end-to-end system "https: / / trace.example.com / detail / " to generate the complete URL: "https: / / trace.example.com / detail / abc123". Second, the hyperlink is bound to a specific display area of ​​the trajectory map file. One implementation method is to utilize HTML's image mapping function to define one or more clickable areas on the trajectory image and set the click event handler for that area to open the aforementioned hyperlink. A better approach is to programmatically listen for user clicks or hover events on the Canvas or SVG (Scalable Vector Graphics) element that carries the heatmap. When an event occurs in a high-heat area, a tooltip containing a unique identifier for the request is dynamically displayed, allowing the user to click and navigate to the full-link tracing page. Once these bindings are complete, the image, heatmap, and tracing links together form an interactive page element. Users can not only see the trajectory and heatmap but also directly delve into the detailed backend call chain of the request through clicks, seamlessly integrating the frontend display with backend deep diagnostic tools.

[0057] In this embodiment, the interactive function includes two triggering methods: mouse hover: when hovering over any area of ​​the heatmap layer, a tooltip pops up, displaying the heat value of that area (e.g., "Heat: 35") and its coordinate range (e.g., "(100-120, 200-220)"); mouse click: clicking on a high-heat area with a heat value ≥ 30 automatically redirects to the full-link tracing page. The interactive area is divided into rectangular partitions of 10×10 pixels, with the same interactive logic shared within the same partition to ensure smooth response.

[0058] Preferably, the specific implementation process of step 44 is as follows: The purpose of this step is to integrate all information and generate the final user interface. Its processing objects are the interactive page elements generated in step 43, and other information extracted during data packet parsing in step 41 that has not yet been used, such as the interface path, actual return result, and expected result. First, plan an overall layout structure in the front-end page, for example, using a two-column layout. In the main content area on the right, embed the interactive page elements generated in step 43, i.e., the trajectory image already bound with heatmap layers and tracking links. In the left sidebar area, create several information display panels, clearly listing text information such as the interface path, actual return result, and expected result in a structured manner (e.g., a list of tag-value pairs). Simultaneously, the unique request identifier is not only bound to the image as a clickable link but also displayed as text in the sidebar. Then, through data binding or state management of the front-end framework, ensure that the page elements and sidebar information logically correspond to the same request. Finally, all the above layouts, elements, and data are integrated and rendered into a complete, dynamic web page document object model, generating a rendered page for display. This page integrates raw trajectory, behavior heatmap, detailed log parameters, and interactive capabilities for one-click access to in-depth diagnostics, providing a multi-layered, interactive problem-solving context in a unified view. This reduces the time required for technicians to switch between multiple independent tools and pages to correlate information.

[0059] Optionally, the step of parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory image file further includes: step 2e, performing stroke segmentation and type recognition processing on the list of trajectory coordinate points in the trajectory log data to generate a stroke sequence with semantic labels; step 2f, performing writing quality quantification evaluation processing on each stroke in the stroke sequence with semantic labels to generate a stroke quality evaluation vector; and step 2g, performing fusion rendering processing of annotation information and trajectory image based on the stroke sequence with semantic labels and the stroke quality evaluation vector to generate the trajectory image file.

[0060] Preferably, the specific implementation process of step 2e is as follows: The processing object of this step is the list of trajectory coordinate points in the trajectory log data. First, feature point detection processing based on curvature and speed is performed on the list of trajectory coordinate points. Specifically, the list of trajectory coordinate points is traversed, and for each internal point, the direction change angle (curvature) of the vector formed by its preceding and following adjacent points is calculated, along with the instantaneous writing speed estimated based on the timestamp (if included in the log) or the point sequence interval. A dynamic threshold is set to mark points where the curvature suddenly increases (e.g., the angle exceeds 60 degrees) or the speed suddenly decreases (e.g., below 30% of the average speed) as potential feature points. Next, these potential feature points are denoised and merged, merging feature points that are too close together into one, ultimately generating an ordered sequence of stroke segmentation points, where each point represents a possible boundary position between strokes. Then, based on the stroke segmentation point sequence, the original list of trajectory coordinate points is divided into multiple continuous sub-coordinate point lists, each sub-coordinate point list corresponding to an independent physical stroke (such as horizontal, vertical, left-falling, right-falling strokes, etc.). Finally, orientation and morphological features are extracted from each sub-coordinate point list. Extracted features include, but are not limited to: the direction vectors of the stroke's start and end points, the aspect ratio of the bounding box of the stroke point set, and the convex hull features of the stroke points. These feature vectors are input into a pre-trained multi-class stroke classification model (e.g., a convolutional neural network with fully connected layers). This model outputs the probability distribution of the stroke belonging to a predefined stroke type (such as "horizontal," "vertical," "left-falling," "right-falling," "dot," "turning," etc.), and the type with the highest probability is taken as the semantic type label for that stroke. After traversing all sub-coordinate point lists, a semantically labeled stroke sequence is obtained, consisting of multiple strokes and their semantic type labels arranged in writing order.

[0061] In one embodiment, the stroke classification model is a three-layer fully connected neural network. The input layer has 7 nodes, corresponding to a 7-dimensional feature vector composed of the following features: the sine and cosine of the direction angle of the line connecting the start and end points of the stroke; the aspect ratio of the rectangle enclosing the stroke point set; the ratio of the area of ​​the convex hull of the stroke point set to the area of ​​the rectangle enclosing the stroke; the average curvature of the stroke point set; and the average and variance of the stroke writing speed. The hidden layer contains 15 nodes, using the ReLU activation function. The output layer has 6 nodes, corresponding to the six stroke types: horizontal, vertical, left-falling, right-falling, dot, and fold, and uses the Softmax function to output the probability distribution. This model uses a handwritten trajectory sample library containing 100,000 labeled stroke types and is trained under supervision using the cross-entropy loss function and the Adam optimizer.

[0062] Preferably, in one scenario, step 2f is specifically implemented as follows: The processing object of this step is the stroke sequence with semantic labels generated in step 2e. For each stroke segment in the sequence (corresponding to a sub-coordinate point list and its semantic type label), two quantitative evaluations are performed in parallel. The first is smoothness analysis: the local curvature (or direction angle change) formed by every three consecutive points in the sub-coordinate point list is calculated, and the variance of these local curvature values ​​is obtained. The larger the variance value, the more severe the local jitter of the stroke, and the less smooth the writing. After normalizing this variance value, it is mapped to a stroke jitter level score between 0 and 1, with a higher score indicating more severe jitter. The second is speed uniformity analysis: if the log contains timestamps, the time difference between adjacent points is directly calculated as the instantaneous speed; if there are no timestamps, the inverse of the point sequence interval can be used as an approximation. The coefficient of variation (standard deviation divided by the mean) of these instantaneous speeds is calculated. The larger the coefficient of variation, the greater the fluctuation in writing speed and the worse the smoothness. After normalizing this coefficient of variation, it is mapped to a stroke fluency score between 0 and 1, with a higher score indicating poorer fluency. For each stroke segment, the calculated stroke jitter score is combined with the stroke fluency score to form a two-dimensional vector, which generates the stroke quality evaluation vector for that segment. This vector quantitatively describes the writing quality of a single stroke from two dimensions: "stability" and "fluency."

[0063] In some embodiments, the stroke jitter score S_jitter is calculated using the following formula: S_jitter = min(1.0, curvature variance / threshold T1), where T1 is a preset empirical threshold, such as 0.05. The stroke fluency score S_fluency is calculated using the following formula: S_fluency = min(1.0, coefficient of variation / threshold T2), where T2 is another preset empirical threshold, such as 0.3. The local curvature can be calculated as follows: for three points P arranged sequentially in the sub-coordinate point list... i 1(x i 1,y i 1), P i (x i ,y i ), P i+1 (x i+1 ,y i+1 First, calculate the vector. =(x i x i 1, y i y i 1) With the vector =(x i+1 x i , y i+1 y i ). Then, calculate the included angle θ i between these two vectors. The calculation formula for the included angle θ i is: . This included angle θ i is used as the metric value of the local curvature at point P i . Traverse all positions in the sub-coordinate point list that can form three consecutive points to obtain a series of local curvature values {θ i}.

[0064] Preferably, in the specific technical implementation of step 2g: The purpose of this step is to visually superimpose semantic and quality information onto the trajectory image to generate an information-enhanced trajectory map file. Its processing objects are the stroke sequence with semantic labels generated in step 2e and the stroke quality evaluation vector corresponding to each stroke generated in step 2f. First, based on each sub-coordinate point list in the stroke sequence with semantic labels, draw the original trajectory line on a blank canvas using a base color (such as black) to generate a trajectory line drawing. Then, perform quality and semantic fusion rendering processing: Traverse each stroke. According to the semantic type label of this stroke, obtain a base color tone from a preset semantic-tone mapping table (for example, "horizontal" is mapped to a blue tone, "vertical" is mapped to a green tone). At the same time, according to the stroke quality evaluation vector of this stroke, calculate a comprehensive quality score (for example, take the weighted average of the stroke jitter degree score and the stroke smoothness score), and map this score to a transparency value (the better the quality, the higher the transparency, and the lighter the covering color) and a brightness adjustment coefficient. Then, use the mapped base color tone, transparency, and adjusted brightness to generate a semi-transparent color mask, and precisely cover this mask onto the trajectory line area corresponding to this stroke. Finally, perform intelligent annotation rendering processing: On the canvas, for strokes with a comprehensive quality score lower than a predetermined threshold (i.e., strokes with poor quality), select a position near them that does not block the trajectory, and render the semantic type label and its quality score of this stroke in the form of a text box (for example, display "slash: 0.35"). After all the rendering is completed, save the final composite image as a trajectory map file. This technique is different from simple line drawing. By encoding semantics with colors, encoding quality with transparency, and annotating key problem points with text, the generated trajectory map file not only shows "what is written", but more intuitively reveals "how it is written" and "where it is written poorly", providing pixel-level and quantifiable visual evidence for teaching feedback or in-depth problem diagnosis.

[0065] In one embodiment, the semantic-tone mapping table is defined as follows: horizontal lines are mapped to blue (0,0,255), vertical lines to green (0,255,0), left-falling strokes to red (255,0,0), right-falling strokes to yellow (255,255,0), dots to purple (128,0,128), and folds to cyan (0,255,255). The overall quality score Q is calculated using the formula Q = 0.6 * S_jitter + 0.4 * S_fluency, where * represents a product.

[0066] Optionally, after generating the rendered page, the process further includes: Step 5: Based on the rendered page and the data packet containing the problem investigation information, perform multi-role collaborative problem confirmation and status transition processing to generate a closed-loop problem file with a time-series confirmation chain; wherein, the multi-role collaborative problem confirmation and status transition processing includes: Step 5a: Providing role-based interactive confirmation interfaces on the rendered page, wherein the roles include at least the problem reporting user, front-line customer service personnel, test reproduction personnel, and R&D analysts, and configuring different operation permissions and data views for each role; Step 5b: Responding to the submission operation of the problem reporting user, creating an initial problem ticket, and triggering the first-level parallel processing branch: Branch 1: Push the rendered page and the data package to the frontline customer service personnel; Branch 2: Match the key features in the trajectory log data with the historical problem database in real time to generate prompts for suspected known problems and solutions; Step 5c: In response to the operation of the frontline customer service personnel, perform the second-level judgment and triage process: If the frontline customer service personnel accept the prompts, they will directly feed the prompts as solutions back to the user who reported the problem and request the user's confirmation; if the user confirms the solution, the work order will be closed directly; if the frontline customer service personnel judge it to be a new problem requiring technical intervention, they will mark the initial technical suspicions on the rendered page and select the problem type and urgency; System Based on this selection and project load, the task is simultaneously assigned to the test reproduction personnel and the relevant R&D analysts, entering a parallel collaborative diagnostic mode; Step 5d, in the parallel collaborative diagnostic mode: the test reproduction personnel are responsible for performing reproduction verification, and their verification conclusions (reproducible / difficult to reproduce / unreproducible) and additional test environment information will be synchronized to the views of all relevant roles in real time; the R&D analysts can simultaneously view the rendered page, the data package, the suspicious points marked by customer service, and the real-time conclusions of the testers, and initiate targeted log queries or code reviews; if the test reproduction personnel and the R&D analysts disagree on the root cause of the problem, or if the problem involves multiple modules, the system will Automatically initiate an online joint diagnostic session, lock the rendered page as the core shared context, record statements and evidence from all parties, and support arbitration decisions by senior R&D personnel or technical leaders; Step 5e: In response to the final determination of the root cause, the responsible R&D analyst submits a solution including code modifications, triggering a third-level verification loop: the system automatically associates the modifications with the test reproduction personnel, requiring them to perform regression verification in a specified environment; only after successful verification is the solution marked as ready; Step 5f: Push the solution and verification results to the frontline customer service personnel, who then organize feedback and confirmation from the user who reported the issue; if the user accepts, the work order is closed;If user feedback remains unresolved or triggers new issues, the work order will redirect to step 5c or step 5d based on the new feedback, forming a feedback loop. In step 5g, throughout the entire process, the system will automatically record the actions, conclusions, timestamps, and data evidence used by each role at key status nodes (such as screenshots annotated by customer service, test environment snapshots, and log fragments queried by R&D). These records will be structured and stored according to timeline and logical relationships, ultimately encapsulated to generate the closed-loop issue file with the time-series confirmation chain.

[0067] Preferably, the specific implementation process of step 5a is as follows: The system receives the rendered page generated in step 4 and the data packet containing the problem investigation information as the initial technical context for multi-role collaboration. First, based on the predefined role permission matrix, the system generates dynamic, data-filtered interactive views for the four core roles: problem reporting users, front-line customer service personnel, test reproduction personnel, and R&D analysts. This role permission matrix is ​​a two-dimensional table, where rows represent roles, columns represent data fields or operation permissions (such as "can view the complete list of trajectory coordinate points", "can annotate on the rendered page", "can view historical matching results", "can operate the status flow button"), and the Boolean value at the intersection of rows and columns indicates whether the role has this permission or data visibility. Then, based on the rendered page, the system dynamically injects a set of interactive controls matching the currently logged-in role through the front-end framework. For example, it injects a "mark suspicious points" drawing tool and a "problem classification" drop-down box for customer service personnel, "reproduction environment selection" and "verification conclusion submission" panels for test personnel, and "related code library query" and "log depth query" interfaces for R&D personnel. This dynamically generated, role-customized interface serves as the role-specific interaction confirmation interface. This embodiment ensures that each role can only access and operate information and functions related to their responsibilities, achieving secure information isolation and operational guidance.

[0068] Preferably, in one scenario, step 5b is specifically implemented as follows: When the user reporting the problem clicks the submit button on the interactive confirmation interface, the system first creates an initial problem ticket record. This record includes the problem ID, creation time, reporting user identifier, and is associated with the storage address of the data packet and the rendered page. Immediately afterwards, the system triggers an asynchronous event processing engine, which executes the first-level parallel processing branch. The processing action of branch one is: according to preset customer service routing rules (such as by product line or user level), the access links of the problem ticket, rendered page, and data packet are pushed to the ticket queue of the selected front-line customer service personnel in the form of instant messages or to-do tasks. The processing action of branch two is: simultaneously, the system calls a real-time feature matching service. This service extracts a set of predefined key feature vectors from the data packet. The key feature vectors include: interface path, combined hash value of expected result and actual return result, and statistical features of the trajectory coordinate point list (such as the number of points and distribution range). Then, this feature vector is compared with the feature vectors of closed-loop problems in the historical problem database for approximation calculation (e.g., using cosine similarity). If the similarity exceeds a preset threshold (e.g., 0.85), the solutions to the top-matching records are retrieved from the historical question database and combined to generate a prompt message indicating a suspected known question and its solution. This prompt message will be added as a note and linked in real time to the customer service view generated in step 5a. This parallel triggering mechanism ensures that customer service receives intelligent decision-making assistance before intervention, creating conditions for rapid closure.

[0069] Preferably, in the specific technical implementation of step 5c: the system monitors the operation events of frontline customer service personnel on the interactive confirmation interface provided in step 5a. When the customer service personnel perform an operation, the system performs a second-level judgment and triage based on the operation content. If the customer service personnel adopt the prompt information generated in step 5b, the system will directly feed back the solution text in the prompt information to the user who reported the problem through an in-site message or in-application notification, and generate an interactive task for user confirmation. If the user confirms that the problem has been resolved within the specified time, the system will directly update the status of the problem ticket to "closed loop" and record the reason for closure as "knowledge base matching solution". If the customer service personnel do not adopt the prompt information, or the prompt information does not exist, the customer service personnel need to perform a labeling operation on the rendering page: using the drawing tools provided by the system, circle the suspicious stroke areas or abnormal points on the trajectory image. This labeling operation will generate a set of geometric data bound to the canvas coordinates. At the same time, the customer service personnel need to select the problem type (such as "identification error", "trajectory loss", "performance delay") and urgency (such as "high", "medium", "low") from the drop-down menu. After customer service personnel complete the labeling and selection, they click the "Submit Technical Diagnosis" button. Upon receiving this submission event, the system immediately launches an intelligent task allocator. This allocator calculates the optimal combination of testers and R&D analysts based on the problem type and urgency selected by the customer service representative, combined with a pre-set R&D-tester load dashboard (displaying the number of tasks pending for each person), and a personnel skill tag matrix. Then, the system simultaneously pushes the problem ticket, the rendered page with customer service labeling, the complete data package, and the allocation instructions to the to-do task lists of the selected testers and R&D personnel, updating the ticket status to "Parallel Collaborative Diagnosis in Progress." This embodiment structures the customer service representative's judgment actions (labeling and classification) and uses them as key inputs to drive an automated, parallel task allocation process based on rules and load balancing, replacing the traditional manual, serial assignment.

[0070] Preferably, the specific implementation process of step 5d is as follows: When the problem work order enters the "parallel collaborative diagnosis in progress" state, the system opens a shared, real-time synchronized collaborative workspace for test reproduction personnel and R&D analysts. The interactive view of the test reproduction personnel will provide a standardized verification template, which includes reproduction environment configuration items (such as device model, system version, network environment), a reproduction step record box, and a conclusion radio button group (options: "Reproducible", "Difficult to reproduce (requires specific conditions)", "Unable to reproduce"). When the test personnel fill in the template and submit the conclusion, the system will generate a structured test verification report and display its key contents (conclusion, environment snapshot) in real time in the sidebar of the R&D personnel's view. At the same time, the interactive view of the R&D analysts focuses on in-depth diagnosis: its interface integrates the code repository search entry, a more powerful log query terminal (which can directly use the traceID in the data packet for querying), and displays customer service annotations and real-time test conclusions. Every key query operation performed by the R&D personnel (such as searching for a certain piece of code or querying logs for a certain time period) will be automatically captured and recorded by the system as "diagnostic evidence". The system is configured with a dispute detection rule: when testers submit a conclusion of "cannot be reproduced" while developers insist on the existence of the problem based on analysis, or when developers mark the problem as involving multiple code modules requiring collaboration from other developers, the system will automatically trigger an online joint diagnostic session. The system will create a temporary video conference room, locking the problem rendering page, all submitted structured reports (customer service judgments, test reports), and a list of "diagnostic evidence" captured by both parties as core shared materials in the center of the room. During the meeting, any new argument raised by either party requiring data support can request the system to perform a real-time log query or code location, and share the results immediately. The meeting moderator (usually a senior developer or technical lead) can make an "arbitration decision" within the system based on the discussion, which will serve as the authoritative basis for subsequent steps. This model transforms traditional offline, unstructured technical disputes into an online, evidence-driven, and recorded arbitration process.

[0071] Preferably, in the specific technical implementation of step 5e: regardless of whether it is through conventional diagnosis or arbitration, once the root cause of the problem (e.g., a logical defect in a piece of code or a configuration error in a service) is finally identified, the responsible R&D analyst needs to fill in the root cause description, the involved code files and line numbers (which can be associated with specific commits in the version control system) in the solution submission form provided by the system, and submit the fix code (such as a patch file or merge request link). After receiving the solution submission event, the system will not immediately allow the loop to close, but will automatically trigger the third-level verification loop. The system will automatically generate a regression verification task based on the code modules associated with the solution and the reproduction environment submitted by the testers, and forcibly assign it to the testers who were initially responsible for the reproduction verification (or other testers in the same group). This task explicitly requires the testers to verify in the specified environment whether the fix code solves the original problem and does not introduce new regression defects. Only when the testers submit a conclusion of "verification passed" in the verification task will the system mark the solution status as "ready". If the verification fails, the task and the solution will be returned to the R&D personnel and re-enter the modification state. This mandatory verification cycle forms a key closed loop for quality assurance.

[0072] Preferably, in the specific technical implementation of step 5f: when the solution is marked as "ready," the system automatically transfers the issue status back to frontline customer service personnel and pushes a notification. The customer service personnel's view will then clearly display the complete timeline of the issue, the final solution description, and the conclusion that testing and verification have passed. The customer service personnel organize feedback to the user who reported the issue, for example, by informing the user via phone or in-app message that the issue has been fixed, and may guide the user through simple verification. The system will generate a task awaiting final confirmation from the user. If the user confirms the issue has been resolved, the customer service personnel click the "User Confirmation Loop Closure" button, and the system updates the issue ticket status to "Closed Loop (User Confirmation)." If the user reports that the issue is not resolved, or that the fix has caused new related issues, the customer service personnel can record the new user feedback in the system. Based on the nature of the new feedback, the system automatically executes the status transition logic: if the new feedback indicates that the original issue has not been completely resolved, the ticket may jump back to step 5d (parallel collaborative diagnosis), requiring re-analysis; if the feedback is a completely different new phenomenon, it may jump back to step 5c (customer service judgment and triage), or even be created as a new related ticket. This dynamic redirection mechanism, driven by user feedback, creates an external feedback loop, ensuring that problems are truly resolved rather than merely shut down at the technical level.

[0073] Preferably, in the specific technical implementation of step 5g: In each step (5a to 5f) of the entire process, the system establishes preset "key status nodes" (such as "work order creation," "customer service submission," "test conclusion submission," "R&D solution submission," "arbitration judgment," "verification passed," and "user confirmation"). Whenever the process flows to these nodes, or any role performs a key operation (such as customer service annotation, R&D query, or test environment recording), the system's event listener automatically captures the operation. The captured content includes: the operator's role, the operation timestamp, the operation type, and a snapshot of the specific data evidence associated with the operation. For example, when customer service performs annotation, the system saves the coordinate data of the annotated area and a screenshot of the rendered page after annotation; when R&D performs a log query, the system saves the query conditions used and the key log fragments returned. All these records are encapsulated into immutable audit logs. Finally, when the problem work order is closed, the system initiates an archiving process. The program arranges all audit logs, data packets generated in step 5b, rendered pages, and structured reports submitted by various roles (customer service judgments, test reports, solutions, etc.) in chronological order and establishes internal logical connections (for example, associating R&D query logs with customer service annotations through the issue context). All this information is packaged, compressed, and generates a self-contained, offline-viewable structured document, namely the closed-loop issue file with a chronological confirmation chain. This file not only records "who made what decision when," but more importantly, it records "what data was used to make the decision," forming a complete, reliable, and reproducible record of technical decisions.

[0074] Through the above, this embodiment transforms loose, human-dependent cross-departmental collaboration into a data- and rule-driven, measurable, and traceable engineering process, thereby systematically improving the efficiency of organizational collaboration and the quality of knowledge accumulation while solving complex technical problems.

[0075] Furthermore, in one embodiment, referring to FIG2, this application also provides a system for retrieving and displaying user handwritten trajectory data, including: a log data acquisition module, used to query and process log services according to user identifier and operation time range to generate trajectory log data containing a list of trajectory coordinate points, a unique request identifier, an interface path, actual return results, and expected results; a trajectory map acquisition module, used to parse and draw lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory map file; a data packet acquisition module, used to assemble the list of trajectory coordinate points, the unique request identifier, the interface path, the actual return results, the expected results, and the storage address of the trajectory map file in the trajectory log data to generate a data packet containing troubleshooting information; and a page rendering module, used to integrate and display the data packet to generate a rendered page for displaying the trajectory map file and the trajectory log information.

[0076] Specifically, the log data acquisition module queries the log service based on the user identifier and operation time range to generate trajectory log data containing a list of trajectory coordinate points, a unique request identifier, an interface path, the actual return result, and the expected result. Then, the trajectory graph acquisition module parses and draws lines from the trajectory coordinate point list in the trajectory log data to generate a trajectory graph file. Next, the data packet acquisition module assembles the trajectory coordinate point list, unique request identifier, interface path, actual return result, expected result, and the storage address of the trajectory graph file from the trajectory log data to generate a data packet containing troubleshooting information. Finally, the page rendering module integrates and displays the data packet to generate a rendered page for displaying the trajectory graph file and trajectory log information.

[0077] This application provides a device for retrieving and displaying user handwritten trajectory data. The generating device can be a terminal or a server, including a processor and a memory. The memory stores at least one instruction or at least one program. The at least one instruction or at least one program is loaded and executed by the processor to implement the method for retrieving and displaying user handwritten trajectory data as provided in the above method embodiments.

[0078] The memory can be used to store software programs and modules. The processor executes these stored software programs and modules to perform various functional applications and retrieve and display user handwritten trajectory data. The memory mainly includes a program storage area and a data storage area. The program storage area stores the operating system, application programs required for the functions, etc.; the data storage area stores data created based on device usage, etc. Furthermore, the memory may include high-speed random access memory and non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor with access to the memory.

[0079] The method embodiments provided in this application can be executed in electronic devices such as mobile terminals, computer terminals, servers, or similar computing devices. Figure 3 is a hardware structure block diagram of an electronic device for a method of retrieving and displaying user handwritten trajectory data provided in this application embodiment. As shown in Figure 3, the electronic device 900 can vary considerably due to different configurations or performance, and may include one or more central processing units (CPUs) 910 (processor 910 may include, but is not limited to, microprocessors MCUs or programmable logic devices FPGAs), a memory 930 for storing data, and one or more storage media 920 (e.g., one or more mass storage devices) for storing application programs 923 or data 922. The memory 930 and storage media 920 may be temporary or persistent storage. The program stored in the storage media 920 may include one or more modules, each module may include a series of instruction operations on the electronic device. Furthermore, the central processing unit 910 may be configured to communicate with the storage media 920 and execute a series of instruction operations in the storage media 920 on the electronic device 900. Electronic device 900 may also include one or more power supplies 960, one or more wired or wireless network interfaces 950, one or more input / output interfaces 940, and / or one or more operating systems 921, such as Windows Server™, Mac OSX™, Unix™, Linux™, FreeBSD™, etc.

[0080] The input / output interface 940 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 900. In one example, the input / output interface 940 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 940 may be a radio frequency (RF) module for wireless communication with the Internet.

[0081] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method for retrieving and displaying user handwritten trajectory data in the method embodiment. The at least one instruction or the at least one program is loaded and executed by the processor to implement the method for retrieving and displaying user handwritten trajectory data provided in the above method embodiment.

[0082] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0083] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various alternative implementations described above.

[0084] It should be noted that the "log service," "object storage service," and "end-to-end tracing system" mentioned in the embodiments of this application are all backend services with industry-standard or publicly available API interfaces. For example, a log service can refer to a centralized log management system (such as ELK Stack, Alibaba Cloud SLS, etc.) that supports SQL-like query syntax, and the log data fields returned by it (such as a list of trajectory coordinate points, TraceID, etc.) are pre-defined and stored structured fields. An object storage service refers to a cloud storage service that provides standard HTTP PUT / GET interfaces. The core of this application lies in the automatic processing, integration, and visualization logic of data obtained from these standardized service interfaces, rather than the specific implementation of these external services themselves.

[0085] It should be understood that this application is not limited to the processes and structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for retrieving and displaying user handwritten trajectory data, characterized in that, include: Based on the user identifier and operation time range, the log service is queried to generate trajectory log data containing a list of trajectory coordinate points, a unique request identifier, an interface path, the actual return result, and the expected result; the list of trajectory coordinate points in the trajectory log data is parsed and processed with lines to generate a trajectory graph file; The trajectory coordinate point list, request unique identifier, interface path, actual return result, expected result, and storage address of the trajectory map file in the trajectory log data are assembled to generate a data package containing troubleshooting information; the data package is then integrated and displayed to generate a rendering page for displaying the trajectory map file and the trajectory log information.

2. The method for retrieving and displaying according to claim 1, characterized in that, The step of parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory graph file includes: performing coordinate pair transformation on the sequence of coordinate points in the list of trajectory coordinate points to obtain a sequence of coordinate pairs, and performing line drawing on the sequence of coordinate pairs to generate a trajectory graph file.

3. The method for retrieving and displaying according to claim 1 or 2, characterized in that, After generating the trajectory map file, the method further includes: uploading the trajectory map file to an object storage server to generate the storage address of the trajectory map file.

4. The method for retrieving and displaying according to claim 1, characterized in that, Before parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory map file, the method further includes: comparing the actual return result with the expected result in the trajectory log data to generate a comparison result identifier.

5. The method for retrieving and displaying according to claim 4, characterized in that, The process of generating the trajectory map file includes: coloring the lines drawn according to the coordinate sequence based on the comparison result identifier to generate the trajectory map file.

6. The method for retrieving and displaying according to claim 1, characterized in that, Obtaining the trajectory log data further includes: querying the log service based on the user identifier, operation time range, and target application interface to generate an initial log dataset; comparing and analyzing the actual return results and expected results in the initial log dataset based on preset filtering rules to generate preliminary suspicious log identifiers; performing trajectory coordinate anomaly feature determination processing on the log data in the initial log dataset that have the preliminary suspicious log identifiers based on the preliminary suspicious log identifiers to generate final suspicious log identifiers; and filtering the corresponding log data from the initial log dataset based on the final suspicious log identifiers to generate the trajectory log data.

7. The method for retrieving and displaying according to claim 1, characterized in that, The step of parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate a trajectory map file includes: parsing and drawing lines on the list of trajectory coordinate points in the trajectory log data to generate an original trajectory map; obtaining a standard trajectory coordinate point list associated with the trajectory log data; comparing and visualizing the coordinate point differences between the list of trajectory coordinate points in the trajectory log data and the standard trajectory coordinate point list to generate a trajectory difference comparison map; and combining the original trajectory map and the trajectory difference comparison map to generate the trajectory map file.

8. The method for retrieving and displaying according to claim 1, characterized in that, The process of integrating and displaying the data packet to generate a rendered page for displaying the trajectory map file and the trajectory log information includes: parsing the data packet to extract the storage address of the trajectory map file, the list of trajectory coordinate points, and the unique request identifier; loading the trajectory map file according to its storage address and generating an interactive trajectory heatmap layer according to the list of trajectory coordinate points; associating and binding the loaded trajectory map file, the interactive trajectory heatmap layer, and the unique request identifier to generate interactive page elements; and integrating and displaying the interactive page elements and other information in the data packet to generate the rendered page.

9. A system for retrieving and displaying user handwritten trajectory data, characterized in that, include: The log data acquisition module is used to query and process the log service according to the user identifier and operation time range to generate trajectory log data containing a list of trajectory coordinate points, a unique request identifier, an interface path, actual return results, and expected results; the trajectory graph acquisition module is used to parse and draw lines from the list of trajectory coordinate points in the trajectory log data to generate a trajectory graph file. The data packet acquisition module is used to assemble the list of trajectory coordinate points, unique request identifier, interface path, actual return result, expected result, and storage address of the trajectory map file in the trajectory log data to generate a data packet containing troubleshooting information; the page rendering module is used to integrate and display the data packet to generate a rendered page for displaying the trajectory map file and the trajectory log information.

10. A computer device, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the method for retrieving and displaying user handwritten trajectory data as described in any one of claims 1 to 8.

Images