Method and system for online debugging of API interface based on semantic analysis

Abstract

The application belongs to the technical field of software development and testing, and particularly relates to an API interface online debugging method and system based on semantic analysis, aiming at solving the problems of low efficiency and insufficient intelligence of existing API interface debugging tools. The application comprises: constructing an interface parameter state space model; storing user debugging process records as debugging path trajectories; determining a current state in response to a current user's debugging operation; enumerating all reachable states and obtaining historical trajectories prefixed with the current state; dividing the reachable states into verified success states, verified failure states and unexplored states according to the historical trajectories, and shielding the actions corresponding to the verified failure states on the debugging interface; recording the current debugging process as a new debugging path trajectory and updating the storage. Through state space modeling and historical trajectory learning, the application realizes active shielding of invalid debugging operations and continuous reuse of debugging experience, and significantly improves the debugging efficiency.

Description

Technical Field

[0001] This invention belongs to the field of software development and testing technology, and specifically relates to an online debugging method and system for API interfaces based on semantic parsing. Background Technology

[0002] In the software development process, API interface debugging is a crucial step frequently performed by R&D personnel and is an important component of the software development and testing technology field in the next-generation information technology industry. With the widespread application of artificial intelligence-specific computing architectures such as Neural Processing Units (NPUs), the scale and complexity of intelligent software development have significantly increased. AI application systems based on NPUs generally adopt microservice architectures, leading to a surge in the number of API interfaces, increasingly complex interface parameter structures, and more diverse business dependencies between parameters. This places higher demands on the performance and intelligence level of interface debugging tools.

[0003] Traditional API debugging tools, such as Postman and Swagger, typically require users to manually enter various request parameters. For APIs with a large number of parameters and complex dependencies between them, users need to repeatedly consult the API documentation and fill in test data item by item, which is tedious and inefficient. This problem is particularly prominent in AI application system development scenarios supported by NPU architecture, because API debugging often involves highly complex nested data structures such as a large number of model parameters, feature configurations, and tensor structure definitions. The static configuration mode of traditional tools can no longer meet the urgent needs of developers for debugging efficiency and intelligent assistance.

[0004] While existing technologies offer some auxiliary functions, such as parameter templates and history records, they essentially remain at the "parameter configuration" level, lacking intelligent reasoning capabilities regarding semantic relationships between parameters and deep learning capabilities to analyze user debugging behavior. Specifically, the following technical problems exist:

[0005] Parameter input relies heavily on manual intervention and cannot automatically handle the interrelationships between parameters. When debugging complex AI model interfaces, a change in one parameter (such as the model version) may require corresponding adjustments to several other parameters (such as the input data format). Existing tools cannot automatically handle this interrelationship, forcing users to repeatedly try invalid parameter combinations during debugging, wasting a significant amount of time and causing unnecessary consumption of valuable computing resources such as NPUs.

[0006] Historical debugging data is not being effectively utilized. Tools are unable to learn from past successes or failures to provide intelligent recommendations or avoidance guidance for new debugging. This makes it difficult to continuously improve debugging efficiency and forms an efficient debugging loop that matches the agile development model enabled by NPU.

[0007] Therefore, there is an urgent need for an intelligent online debugging method for API interfaces that can integrate semantic parsing, state space modeling, and historical trajectory learning. This is to meet the urgent need for intelligent and efficient debugging tools in AI application development under dedicated AI computing architectures such as neural network processors, thereby significantly improving debugging efficiency and reducing trial and error and computation costs caused by invalid parameter combinations. Summary of the Invention

[0008] To address the aforementioned problems in existing technologies, namely the low efficiency and insufficient intelligence of existing API interface debugging tools, this invention provides an online API interface debugging method and system based on semantic parsing.

[0009] In a first aspect, this invention proposes an online debugging method for API interfaces based on semantic parsing, the method comprising: Construct an interface parameter state space model, which includes a state space, an action space, and a transition function. The state space is a set of possible combinations of all parameters of the interface. The action space is a set of executable parameter modification operations. The transition function is used to define the next state reached after performing any action in any state. Acquire and store the user's debugging process record for the interface, and record each debugging process as a debugging path trajectory. The debugging path trajectory includes the initial state, at least one action, at least one intermediate state, and the final result. In response to the current user's debugging operation, determine the current state, which is the combination of parameter values ​​corresponding to all parameter modification operations completed by the current user; Starting from the current state, enumerate all reachable states according to the transition function, and obtain the historical trajectory with the current state as a prefix based on the debugging path trajectory; Based on the final results of each action in the historical trajectory, the reachable state is divided into verified successful state, verified failed state and unexplored state, and the actions corresponding to the verified failed state are masked on the debugging interface. Record the current user's debugging process as a new debugging path trajectory and update the stored debugging path trajectory.

[0010] Furthermore, methods for constructing the interface parameter state space model include: Parse the interface definition data, extract all parameters and the data structure and value constraints of each parameter, decompose the composite structure parameter into multiple sub-parameters, map the decomposed sub-parameters and original parameters together into independent state variables, and construct the state space with the Cartesian product of the legal values ​​of each state variable. Each state variable is used as the operation object, and operation units that assign and modify values ​​to each state variable are defined. The action space is constructed by all operation units. The dependencies and mutual exclusions between parameters are analyzed. Based on the obtained dependencies and mutual exclusions, parameter value combinations that do not meet the constraints are filtered out in the state space so that the state space contains only valid states that conform to the business logic. The linkage logic between state variables is constructed based on the dependencies and mutual exclusions, and the transition function is generated based on the linkage logic. The transfer function is used to respond to any assignment modification operation of a state variable and update other state variables affected by that state variable in a coordinated manner to determine the next state to be reached.

[0011] Furthermore, the method for constructing the state space using the Cartesian product of the legal values ​​of each state variable is as follows: Based on the data structure defined in the interface definition data, identify the type attributes of each parameter, and decompose parameters with composite structure types into multiple basic type sub-parameters according to their internal field hierarchy; The sub-parameters obtained from the decomposition, together with the original parameters which are the basic types, are established as independent state variables. Each state variable corresponds to an indivisible basic parameter unit in the interface. Obtain the set of legal values ​​corresponding to each state variable, wherein the set of legal values ​​is determined based on the value constraints in the interface definition data; Perform a Cartesian product operation on the set of all legal values ​​of the state variables, and the resulting set is used as the state space. Each element in the state space uniquely represents a combination of values ​​of all parameters of the interface.

[0012] Furthermore, the method for constructing the action space from all operation units is as follows: The data type of the parameters corresponding to each state variable is analyzed, and the operation type for assigning and modifying each state variable is determined based on the data type. The operation type includes one or more of the following: text input, numerical increment / decrement, enumeration selection, and structured data editing. For each state variable as the operation target, and in combination with the operation type, at least one operation unit is generated for that state variable, and each operation unit corresponds to an independent parameter assignment and modification action. Collect the operation units generated for all state variables, and construct the action space from the set of operation units.

[0013] Furthermore, based on the dependencies and mutual exclusions obtained from the analysis, a linkage logic is constructed between state variables, and the method for generating the transition function based on the linkage logic is as follows: The dependencies and mutual exclusions between parameters are analyzed, and each group of parameters with business relevance is established as an associated parameter group. Within the associated parameter group, the constraint types between state variables are identified. The constraint types include one or more of the following: mandatory conditions, linked value ranges, mutually exclusive selection, and simultaneous increase or decrease. For each constraint type, a corresponding linkage rule is constructed. The linkage rule defines how the value of the affected state variable is adjusted when the value of the triggering state variable changes. All linkage rules are integrated to generate the transition function. The transition function takes the current state and the assignment modification action of the triggered state variable as input, calculates and outputs the updated values ​​of all state variables affected by the linkage according to the linkage rules, and forms the next state.

[0014] Furthermore, the method for determining the current state in response to the current user's debugging actions is as follows: Monitor the parameter modification actions performed by the user in the debugging interface. Each parameter modification action corresponds to an operation unit in the action space. Capture the target state variable targeted by the operation unit and the target value after assignment and modification; Obtain the currently recorded user operation sequence, which includes one or more parameter modification actions completed by the current user since the start of this debugging process; The parameter modification actions in the user operation sequence are applied to the initial state in the order of execution. The initial state is a blank state where all parameters of the interface are not assigned values ​​or a preset default state. The combination of parameter values ​​obtained after sequential action is determined as the current state.

[0015] Furthermore, starting from the current state, enumerating all reachable states according to the transition function, and obtaining the historical trajectory prefixed with the current state based on the debug path trajectory, is as follows: Using the current state as the initial node, the transfer function is applied to the current state, and the next state reached after each operation unit in the action space is enumerated. The new states obtained through enumeration are used as new nodes, and the transition function is repeatedly applied to expand the state until no new states are generated. All the states obtained through enumeration are collected as the reachable states. Each stored debugging path trajectory is represented as a state sequence, which consists of the states arranged in chronological order during the debugging process. Traverse all state sequences and identify the state sequence whose starting part completely matches the current state as the historical trajectory prefixed with the current state.

[0016] Furthermore, the method for dividing the reachable state into verified successful state, verified failed state, and unexplored state is as follows: Obtain historical trajectories prefixed with the current state. Each historical trajectory contains a complete state sequence from the initial state to the final state through a series of actions, and records the final result of the corresponding debugging operation. For each reachable state, traverse all historical trajectories and identify whether there exists a historical trajectory that is prefixed with the current state and passes through that reachable state. If a historical trajectory passes through this reachable state, and the final result corresponding to this historical trajectory represents successful debugging, then the reachable state is marked as a verified successful state. If a historical trajectory passes through this reachable state, and the final result corresponding to this historical trajectory indicates that the debugging failed, then the reachable state is marked as a verified failure state. If no historical trajectory passes through the reachable state, then the reachable state is marked as unexplored.

[0017] Furthermore, the method for disabling actions corresponding to verified failure states on the debugging interface is as follows: Obtain the verified failure status, and each verified failure status corresponds to a combination of parameter values; Establish a mapping relationship between states and actions, and determine the target state variable corresponding to each operation unit and the next state it points to after the assignment and modification; Traverse all operation units in the action space, and for each operation unit, identify the next state reached from the current state after executing the operation unit; If the identified next state belongs to the verified failure state, then the operation unit is determined to be an action to be blocked. On the debugging interface, set the operation control corresponding to the action to be blocked to a disabled state. The disabled state is manifested by the control being grayed out and unable to trigger interaction. When the current state changes due to the user performing other operation units, the traversal recognition step is re-executed to dynamically update the masking state on the debugging interface.

[0018] In a second aspect, the present invention proposes an online debugging system for API interfaces based on semantic parsing, the system comprising: The model building module is used to build an interface parameter state space model. The state space model includes a state space, an action space, and a transition function. The state space is a set of possible combinations of all parameters of the interface. The action space is a set of executable parameter modification operations. The transition function is used to define the next state reached after performing any action in any state. The trajectory storage module is used to acquire and store the user's debugging process record of the interface, and record each debugging process as a debugging path trajectory. The debugging path trajectory includes the initial state, at least one action, at least one intermediate state and the final result. The status determination module is used to respond to the current user's debugging operation and determine the current status, which is the combination of parameter values ​​corresponding to all parameter modification operations completed by the current user. The reachable state enumeration module is used to enumerate all reachable states based on the current state and the transition function. The historical trajectory acquisition module is used to acquire historical trajectories prefixed with the current state based on the debugging path trajectory. The state division module is used to divide the reachable state into verified successful state, verified failed state and unexplored state according to the final result corresponding to each action in the historical trajectory. The action masking module is used to mask actions that have been verified as failed on the debugging interface. The trajectory update module is used to record the current user's current debugging process as a new debugging path trajectory and update the debugging path trajectory stored in the trajectory storage module.

[0019] The beneficial effects of this invention are: Compared to existing technologies, this invention constructs a state-space model of interface parameters and records the user's debugging process as a learnable path trajectory. This transforms traditional API interface debugging from disordered, manual parameter filling into a systematic state-space exploration process based on historical experience. By constructing transition functions by parsing the inherent dependencies and mutual exclusion relationships between parameters, this invention can automatically update other affected parameters when the user modifies any parameter. This ensures the real-time effectiveness of parameter combinations at the business logic level and reduces invalid debugging attempts caused by configurations that do not meet business constraints.

[0020] This invention utilizes stored historical debugging path trajectories to predict and identify subsequent operations that have been proven to lead to failure when a user performs a new debugging operation, based on the currently configured parameter status. By masking the actions corresponding to these invalid operations on the debugging interface, this invention proactively prevents users from entering known error debugging paths, directly avoiding repeated trial and error with invalid parameter combinations, significantly saving user debugging time and backend service computing resources. As debugging trajectories are continuously accumulated, the system's guidance capabilities and masking accuracy will continuously improve, forming a closed loop of debugging knowledge accumulation and reuse, thereby systematically improving the debugging efficiency and success rate of complex API interfaces. Attached Figure Description

[0021] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart of an online debugging method for API interfaces based on semantic parsing according to the present invention; Figure 2 This is a structural diagram of an online API interface debugging system based on semantic parsing according to the present invention; Figure 3 This is a schematic diagram of the structure of a computer system used to implement the methods, systems, and electronic devices of this application. Detailed Implementation

[0022] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the invention. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0023] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0024] The first embodiment of this invention proposes an online debugging method for API interfaces based on semantic parsing, the method comprising: Step S10: Construct an interface parameter state space model. The state space model includes a state space, an action space, and a transition function. The state space is a set of possible combinations of all interface parameters. The action space is a set of executable parameter modification operations. The transition function is used to define the next state reached after performing any action in any state. Step S20: Obtain and store the user's debugging process record for the interface, and record each debugging process as a debugging path trajectory. The debugging path trajectory includes the initial state, at least one action, at least one intermediate state, and the final result. Step S30: In response to the current user's debugging operation, determine the current state, which is the combination of parameter values ​​corresponding to all parameter modification operations completed by the current user; Step S40: Starting from the current state, enumerate all reachable states according to the transition function, and obtain the historical trajectory with the current state as a prefix based on the debug path trajectory; Step S50: Based on the final results of each action in the historical trajectory, the reachable state is divided into verified successful state, verified failed state and unexplored state, and the actions corresponding to the verified failed state are masked on the debugging interface. Step S60: Record the current user's debugging process as a new debugging path trajectory and update the stored debugging path trajectory.

[0025] To more clearly explain the online debugging method for API interfaces based on semantic parsing of this invention, the following will be combined with... Figure 1 The steps in the embodiments of the present invention are described in detail below: Step S10: Construct an interface parameter state space model. The state space model includes a state space, an action space, and a transition function. The state space is a set of possible combinations of all interface parameters. The action space is a set of executable parameter modification operations. The transition function is used to define the next state reached after performing any action in any state. In this embodiment, the method for constructing the interface parameter state space model includes: Step S11: Parse the interface definition data, extract all parameters and the data structure and value constraints of each parameter, decompose the composite structure parameter into multiple sub-parameters, map the decomposed sub-parameters and the original parameters together into independent state variables, and construct the state space with the Cartesian product of the legal values ​​of each state variable. Step S12: Using each state variable as the operation object, define the operation unit to assign and modify the value of each state variable, and construct the action space by all operation units; Step S13: Analyze the dependencies and mutual exclusions between parameters, filter out parameter value combinations that do not meet the constraints in the state space based on the obtained dependencies and mutual exclusions, so that the state space only contains valid states that conform to the business logic, and construct the linkage logic between state variables based on the dependencies and mutual exclusions, and generate the transfer function based on the linkage logic. The transfer function is used to respond to any assignment or modification operation of a state variable, and to update other state variables affected by that state variable in a coordinated manner, so as to determine the next state to be reached.

[0026] In this embodiment, when constructing the interface parameter state space model, all parameter information of the interface is first extracted by parsing the interface definition data. The interface definition data can be a document conforming to the OpenAPI specification, a Swagger definition file, or a structured description directly parsed from the interface source code. The parsing process includes extracting information such as the name, data type, data structure, whether it is required, default value, and value constraints of each parameter. For parameters with composite structure types, such as JSON objects or nested arrays containing multiple fields, the composite structure parameter is recursively decomposed according to its internal field hierarchy, breaking it down into multiple basic type sub-parameters. The decomposed sub-parameters and the original basic type parameters are jointly established as independent state variables, and each state variable corresponds to an indivisible basic parameter unit in the interface.

[0027] Based on this, each state variable is treated as an operation object, and operation units for assigning and modifying values ​​to each state variable are defined. The action space is constructed from all these operation units. Simultaneously, the dependencies and mutual exclusion relationships between parameters are analyzed. Based on these relationships, parameter value combinations that do not meet the constraints are filtered out from the state space, ensuring that the state space contains only valid states that conform to the business logic. Furthermore, linkage logic between state variables is constructed based on the dependencies and mutual exclusion relationships. A transition function is generated based on this linkage logic. This transition function is used to respond to any assignment and modification operation of a state variable, updating other state variables affected by that state variable to determine the next state to be reached. The state space model constructed in this way abstracts the complex interface parameter configuration process into a state transition system with a clear mathematical structure.

[0028] Specifically, the method for constructing the state space using the Cartesian product of the legal values ​​of each state variable is as follows: Step S111: Based on the data structure defined in the interface definition data, identify the type attributes of each parameter, and decompose the parameters with composite structure types into multiple basic type sub-parameters according to their internal field hierarchy; Step S112: The sub-parameters obtained from the decomposition and the original parameters that are the basic types are established as independent state variables. Each state variable corresponds to an indivisible basic parameter unit in the interface. Step S113: Obtain the set of legal values ​​corresponding to each state variable. The set of legal values ​​is determined based on the value constraints in the interface definition data. Step S114: Perform a Cartesian product operation on the set of all legal values ​​of the state variables, and use the resulting set as the state space. Each element in the state space uniquely represents a combination of values ​​of all parameters of the interface.

[0029] When constructing the state space using the Cartesian product of the legal values ​​of each state variable, the type attributes of each parameter are identified based on the data structure defined in the interface definition data. Parameters with composite structure types are decomposed into multiple basic type sub-parameters according to their internal field hierarchy. For example, for an interface providing patent information query functionality, its interface definition data may contain multiple parameters such as "applicant," "application number," "patent type," and "publication date range." The "publication date range" is a composite parameter containing two fields, "startDate" and "endDate," which is decomposed into two basic type sub-parameters. These decomposed sub-parameters, along with the original basic type parameters, are established as independent state variables. Each state variable corresponds to an indivisible basic parameter unit in the interface. Subsequently, the set of legal values ​​corresponding to each state variable is obtained, and this set of legal values ​​is determined based on the value constraints in the interface definition data. For enumeration type parameters, the set of valid values ​​is all the optional values ​​listed in the enumeration definition; for numeric type parameters, the set of valid values ​​can be all numeric values ​​within the defined range; for string type parameters, the set of valid values ​​can be determined based on length limits, regular expression constraints, or preset example values.

[0030] Finally, the Cartesian product of all valid values ​​for the state variables is performed, and the resulting set serves as the state space. Each element in this state space uniquely represents a combination of values ​​for all interface parameters. In actual implementation, to avoid state explosion, a symbolic representation and on-demand generation approach are used. Instead of explicitly enumerating all states, the state space is defined as a mathematical structure—the Cartesian product of the sets of values ​​for each state variable—and dynamically generated and traversed as needed during subsequent processing.

[0031] The method for constructing the action space from all operation units is as follows: Step S121: Analyze the data type of the parameters corresponding to each state variable, and determine the operation type for assigning and modifying each state variable based on the data type. The operation type includes one or more of the following: text input, numerical increment / decrement, enumeration selection, and structured data editing. Step S122: Taking each state variable as the operation target, and combining the operation type, generate at least one operation unit for that state variable. Each operation unit corresponds to an independent parameter assignment and modification action. Step S123: Collect the operation units generated for all state variables, and construct the set of operation units into the action space.

[0032] In the specific implementation where the action space is constructed from all operation units, the data type of the parameters corresponding to each state variable is analyzed, and the operation type for assigning and modifying values ​​to each state variable is determined based on the data type. Operation types include one or more of the following: text input, numerical increment / decrement, enumeration selection, and structured data editing. For example, for string type parameters, the operation type includes text input, allowing users to directly enter any string that meets the constraints through the input box; for numeric type parameters, the operation type includes numerical increment / decrement, allowing users to increase or decrease values ​​through step buttons or by directly entering values; for enumeration type parameters, the operation type includes enumeration selection, allowing users to select an optional value from a drop-down list; for Boolean type parameters, the operation type includes switch toggling; and for array type parameters, the operation type includes structured data editing, allowing users to add, delete array elements, or edit the value of each element. Taking each state variable as the operation target, and combining its data type and operation type, at least one operation unit is generated for that state variable, with each operation unit corresponding to an independent parameter assignment / modification action. For enumeration type parameters, if there are n possible values, n operation units are generated, each corresponding to setting the parameter to one of the possible values. For numeric type parameters, operation units such as increasing by one step, decreasing by one step, and directly setting to a specific value can be generated. The operation units generated for all state variables are collected, and this set of operation units is constructed into an action space. Each action in the action space represents an atomic parameter modification operation that the user can execute on the debugging interface.

[0033] Based on the dependencies and mutual exclusions obtained from the analysis, the linkage logic between state variables is constructed. The method for generating the transition function based on the linkage logic is as follows: Step S131: Analyze the dependencies and mutual exclusions between parameters, establish each group of parameters with business relevance as an associated parameter group, and identify the constraint types between state variables within the associated parameter group. The constraint types include one or more of the following: mandatory conditions, linked value ranges, mutually exclusive selection, and simultaneous increase or decrease. Step S132: For each constraint type, construct a corresponding linkage rule. The linkage rule defines the adjustment method of the value of the affected state variable when the value of the triggering state variable changes. Step S133: Integrate all linkage rules to generate the transition function. The transition function takes the current state and the assignment modification action of the triggered state variable as input, calculates and outputs the updated values ​​of all state variables affected by the linkage according to the linkage rules, and forms the next state.

[0034] When constructing the linkage logic between state variables and generating transfer functions based on dependency and mutual exclusion relationships in the specific implementation, the dependency and mutual exclusion relationships between parameters are first analyzed. These relationships can be obtained from multiple sources: first, explicit constraint rules defined in the interface definition data, such as constraints expressed by keywords like "dependentSchemas," "allOf," and "oneOf" in the OpenAPI specification; second, implicit extraction from the descriptive text of the interface documentation through natural language processing technology, such as identifying dependencies from descriptions like "when the patent type is selected as utility model, the publication date range cannot be empty"; and third, inferring potential associations by analyzing the semantic similarity of parameter names and business domain knowledge. Each group of parameters with business associations is established as an associated parameter group, and the constraint types between state variables are identified within this associated parameter group. Constraint types include one or more of the following: mandatory conditions, value range linkage, mutual exclusion selection, and simultaneous increment / decrement. For each constraint type, a corresponding linkage rule is constructed. The linkage rule is defined in the form of condition-action, clarifying how the value of the affected state variable is adjusted when the value of the triggering state variable changes. For example, for mandatory condition constraints, the linkage rule is defined as follows: when the trigger variable takes a specific value, the mandatory attribute of the affected variable is set to valid; if the affected variable is currently empty, a default value is automatically filled in. For value range linkage constraints, the linkage rule is defined as follows: when the trigger variable takes a specific value, the set of legal values ​​for the affected variable is recalculated, and the current value is checked to see if it is still legal; if not, it is automatically adjusted to the default value within the new range of legal values. For mutually exclusive selection constraints, the linkage rule is defined as follows: when the trigger variable takes a certain value, the affected variable is set to empty or set to the default value allowed by the mutually exclusive rule. For simultaneous increase and decrease constraints, the linkage rule is defined as follows: based on the current value of the trigger variable, the new value of the affected variable is calculated according to a preset mapping function.

[0035] All linkage rules are integrated to generate a complete transition function. This transition function takes the current state and the assignment modification action of the triggered state variable as input. First, it executes the parameter assignment modification corresponding to the action. Then, based on all linkage rules that meet the conditions, it calculates and outputs the updated values ​​of all affected state variables, ultimately forming a new state as the next state. The transition function generated in this way can automatically update other affected parameters when the user modifies any parameter, ensuring the real-time effectiveness of parameter combinations at the business logic level and reducing invalid debugging attempts caused by configurations that do not meet business constraints from the source.

[0036] Step S20: Obtain and store the user's debugging process record for the interface, and record each debugging process as a debugging path trajectory. The debugging path trajectory includes the initial state, at least one action, at least one intermediate state, and the final result. In step S20, the user's debugging process record for the interface is acquired and stored, with each debugging process recorded as a debugging path trajectory. Specifically, when a user starts a new interface debugging session, the initial state of this debugging session is first recorded. This initial state is the current combination of all interface parameters before debugging begins. It can be a blank state where all parameters are unassigned, a preset default state, or a historical state loaded by the user from the history log. Subsequently, all parameter modification operations performed by the user on the debugging interface are monitored in real time. Each time the user modifies any parameter, the modification action is recorded. This action corresponds to an operation unit in the previously constructed action space. Simultaneously, after the user executes this action, the new state formed by all parameter values ​​at this time is calculated and recorded according to the transfer function. This new state is used as an intermediate state for this debugging session. The user's sequential execution of each action and the intermediate state reached after each action are continuously recorded until the user completes the debugging session and triggers the interface call operation.

[0037] When a user triggers an API call, the final result of this call is recorded. This final result includes the status code indicating success or failure, the returned data, error messages, and response time. These records are then integrated into a complete debugging path, which includes the initial state, at least one action performed by the user sequentially, at least one intermediate state reached after each action, and the final result. For example, when a user is debugging a patent information query API, the initial state might be "Applicant = empty, Patent Type = empty, Publication Date Range = empty"; the first action performed by the user might be setting "Patent Type" to "Invention," resulting in the intermediate state "Applicant = empty, Patent Type = Invention, Publication Date Range = empty"; the second action performed by the user might be setting "Applicant" to "XX," resulting in the intermediate state "Applicant = XX, Patent Type = Invention, Publication Date Range = empty"; the user then triggers the API call, records a successful call, returns a patent list, and the final result is success. This complete debugging process is recorded as a debugging path trajectory and stored in the trajectory storage module in the form of structured data. Each trajectory is assigned a unique identifier and associated with an interface identifier during storage, enabling quick retrieval of relevant historical trajectories when debugging the same interface later. This method transforms the user's fragmented debugging operations into a structured state space exploration path, providing a data foundation for subsequent intelligent learning and state partitioning.

[0038] Step S30: In response to the current user's debugging operation, determine the current state, which is the combination of parameter values ​​corresponding to all parameter modification operations completed by the current user; In this embodiment, the method for determining the current state in response to the current user's debugging operation is as follows: Step S31: Monitor the parameter modification actions performed by the user in the debugging interface. Each parameter modification action corresponds to an operation unit in the action space. Step S32: Capture the target state variable targeted by the operation unit and the target value after assignment and modification; Step S33: Obtain the currently recorded user operation sequence, which includes one or more parameter modification actions completed by the current user since the start of this debugging. Step S34: Apply each parameter modification action in the user operation sequence to the initial state in the order of execution. The initial state is a blank state where all parameters of the interface are not assigned values ​​or a preset default state. Step S35: Determine the combination of parameter values ​​obtained after sequential action as the current state.

[0039] In step S30, the current state is determined in response to the current user's debugging operation. Specifically, this involves real-time monitoring of every parameter modification action performed by the user on the debugging interface, with each parameter modification action corresponding to an operation unit in the action space. User interactions on interface controls are captured through an event listener mechanism, such as typing content in a text input box, selecting an option from a drop-down list, clicking a value increment / decrement button, or modifying field values ​​of an array or object through a structured data editor.

[0040] When a user triggers these interactive operations, the operation is identified as an action, and the target state variable targeted by the action and its modified value are captured. For example, when debugging the patent information query interface, if a user selects "Invention" from the "Patent Type" drop-down list, the target state variable for this action is captured as "Patent Type," and the modified target value is "Invention." For example, if a user enters "XX" in the "Applicant" input box, the target state variable is captured as "Applicant," and the target value is "XX." Simultaneously with capturing the current action, the currently recorded user operation sequence is obtained. This sequence contains one or more parameter modification actions completed by the current user since the start of this debugging session, arranged sequentially according to the user's execution time. An operation list is maintained in memory; each time a new action is captured, it is appended to the end of the operation list, and the current state is calculated based on all actions in the list.

[0041] The specific method for calculating the current state is as follows: Each parameter modification action in the user's operation sequence is applied sequentially to the initial state in the order of execution. This initial state can be a blank state where all parameters of the interface are unassigned, or a default state preset in the interface definition data. For example, if the user has executed two actions sequentially since the start of this debugging process: first setting "Patent Type" to "Invention," and then setting "Applicant" to "XX," then starting from the initial state "Patent Type = Empty, Applicant = Empty, Publication Date Range = Empty," the first action is applied to obtain the intermediate state "Patent Type = Invention, Applicant = Empty, Publication Date Range = Empty," and the second action is applied to obtain "Patent Type = Invention, Applicant = XX, Publication Date Range = Empty." The final combination of parameter values ​​is then determined as the current state. This operation sequence replay-based method ensures that the current state accurately reflects the comprehensive result of all the user's historical operations. Regardless of the order in which the user modified the parameters, the current combination of all parameter values ​​can be correctly restored by sequentially applying the actions.

[0042] In practical implementation, an incremental update optimization approach can also be adopted. This involves directly applying the newly captured action based on the current state obtained from the previous calculation, and updating the affected parameters in a coordinated manner through the transfer function, thereby efficiently obtaining the updated current state. Using this method, the current state can be quickly and accurately determined after each user parameter modification, providing a precise starting point for subsequent reachable state enumeration and historical trajectory matching.

[0043] The methods for determining the current state in response to the current user's debugging actions also include: When capturing each parameter modification action performed by the user on the debugging interface, the context information of the action is recorded synchronously. The context information includes the interface focus position at the time the action is triggered, the user identification information, and the timestamp of the action execution. The captured parameter modification actions are associated and encapsulated with the corresponding context environment information to form structured operation events, and the operation events are written into the operation event queue in timestamp order. Before determining the current state, the operation events in the operation event queue are validated for legality. The validation includes verifying whether the operation unit corresponding to the operation event exists in the set of executable actions in the current state according to the definition of the action space. If the validation result is that it does not exist, the operation event is marked as an invalid event and removed from the operation event queue. Based on the queue of operation events after legality verification, the parameter modification actions in each operation event are applied to the initial state in sequence according to the timestamp order, and the combination of parameter values ​​obtained after the sequential application is determined as the current state.

[0044] In step S30, when the system determines the current state in response to the current user's debugging operation, it further employs a precise state determination method based on an operation event queue. Specifically, during the monitoring of user debugging operations, when the system captures each parameter modification action performed by the user on the debugging interface, it synchronously records the context information of that action. The context information includes the interface focus position at the time the action is triggered, user identification information, and the timestamp of the action execution. The interface focus position identifies which input control or area the user triggered the action, facilitating subsequent interactive analysis; the user identification information distinguishes the operations of different users in multi-user collaborative scenarios; and the timestamp precisely records the time the action occurred, ensuring the accuracy of the operation order. The system associates and encapsulates the captured parameter modification action with the corresponding context information to form a structured operation event. This operation event includes the action itself and a complete description of the environment in which the action occurred. Subsequently, the system writes this operation event into the operation event queue according to the order of the timestamps. This queue maintains all pending operation events in a first-in, first-out manner, ensuring that the operation order is not disrupted due to asynchronous processing.

[0045] Before determining the current state, the system performs a validity check on the operation events in the operation event queue. The specific process is as follows: the system retrieves each operation event from the queue, extracts the operation unit corresponding to the parameter modification action, and then verifies whether the operation unit exists in the set of executable actions in the current state, based on the pre-built action space definition. It should be noted that the "set of executable actions in the current state" refers to the set of operation units that, starting from the current state, can actually be executed by the user and produce a valid state transition, according to the transition function and the linkage rules between parameters. Some operation units, although existing in the action space, may not be allowed to be executed in the current state due to mutual exclusion relationships, dependency constraints, or read-only attributes of parameters. If the verification result shows that the operation unit exists in the set of executable actions in the current state, the operation event is marked as a valid event and retained in the operation event queue; if the verification result shows that it does not exist, the operation event is marked as an invalid event and removed from the operation event queue. For example, when the "Patent Type" is set to "Design", the "Publication Date Range" parameter becomes read-only. If the user leaves a modification action for the "Publication Date Range" in the operation event queue, the action is no longer executable in the current state. The system identifies it as an invalid event and removes it, thereby preventing invalid operations from being incorrectly included in the state calculation.

[0046] Based on the queue of operation events that have undergone validity verification, the system applies the parameter modification actions in each operation event to the initial state sequentially according to their timestamps. Specifically, the system retrieves each operation event from the queue in chronological order, parses the encapsulated parameter modification actions, applies each action sequentially to the initial state, and updates all affected parameters through a transition function after each action is applied, resulting in a new intermediate state as the basis for applying the next action. The system continues this process until all valid operation events in the queue have been processed, and the final combination of parameter values ​​is determined as the current state. Through this method, the system can not only accurately reconstruct the parameter value combinations corresponding to all historical user operations, but also automatically filter out invalid operation records generated by parameter linkage or interface state changes through the validity verification mechanism, avoiding interference from invalid operations on the accuracy of the state and ensuring the accuracy and reliability of the current state.

[0047] Step S40: Starting from the current state, enumerate all reachable states according to the transition function, and obtain the historical trajectory with the current state as a prefix based on the debug path trajectory; In this embodiment, step S40 includes the following specific steps: Step S41: Using the current state as the initial node, apply the transfer function to the current state, and enumerate the next state reached after executing each operation unit in the action space; Step S42: Take the new state obtained by enumeration as the new node, and repeatedly apply the transition function to expand the state until no new state is generated. Collect all the states obtained by enumeration as the reachable state. Step S43: Represent each stored debugging path trajectory as a state sequence, wherein the state sequence consists of the states arranged in chronological order during the debugging process; Step S44: Traverse all state sequences and identify the state sequence whose starting part completely matches the current state as the historical trajectory prefixed with the current state.

[0048] In step S40, starting from the current state, all reachable states are enumerated according to the transfer function, and historical trajectories prefixed with the current state are obtained based on the debug path trajectory. Specifically, the current state is first used as the initial node. The transfer function is applied to the current state, and the next state reached after executing each operation unit in the action space is enumerated. For example, assuming that "Patent Type" is set to "Invention" and "Applicant" is set to "XX" in the current state, all operation units in the action space are traversed. For each operation unit, the operation unit is applied to the current state, and the next state reached after executing the operation is calculated using the transfer function. These next states include new states reachable by modifying "Patent Type," new states reachable by modifying "Applicant," and new states reachable by modifying "Publication Date Range," etc. The enumerated new states are used as new nodes, and the transfer function is repeatedly applied to expand the state. That is, starting from each new state, all operation units in the action space are traversed again, and the next state reachable after executing each operation is calculated. This process continues until no new states are generated.

[0049] In practical implementation, a breadth-first or depth-first graph traversal algorithm is used, employing a queue or stack to manage the state nodes to be expanded. Simultaneously, a set of visited states is maintained to avoid redundant expansion. Finally, all enumerated states are collected into a reachable state set. This reachable state set represents all parameter value combinations that can be reached from the current state through any sequence of parameter modification operations. These states cover all directions the user might explore during subsequent debugging.

[0050] Simultaneously, based on the stored debug path trajectories, historical trajectories prefixed with the current state are obtained. First, each stored debug path trajectory is represented as a state sequence. Each state sequence consists of states arranged chronologically during the debug process. For example, a historical trajectory can be represented as a sequence of states S0, S1, S2, up to the final state Sn, where S0 is the initial state, S1 is the state reached after executing the first action, S2 is the state reached after executing the second action, and so on. All stored state sequences are traversed, and the starting part of each state sequence is compared with the current state. If the first few states of a state sequence are identical to the current state, then that state sequence is identified as a historical trajectory prefixed with the current state. For example, if the current state is "Patent Type = Invention, Applicant = XX, Publication Date Range = Empty", traversing the historical trajectory database, we find a trajectory whose state sequence begins with "Patent Type = Invention, Applicant = XX, Publication Date Range = Empty", and subsequently explores states where "Publication Date Range" is set to different values, ultimately achieving successful debugging. Another trajectory also begins with the same state but subsequently explores paths where "Patent Type" is modified to other values, ultimately failing to debug. Both of these trajectories are identified as historical trajectories prefixed with the current state. Through this method, we can extract exploration paths that are the same as or related to the current debugging state from historical debugging experience. These historical trajectories contain the debugging exploration processes and final results previously conducted by other users or the current user starting from the same parameter configuration state, providing crucial historical experience for subsequent state division and intelligent guidance.

[0051] Starting from the current state, the method of enumerating all reachable states according to the transition function further includes: During the process of enumerating all reachable states, a state extension graph is dynamically constructed. The state extension graph uses states as nodes and action execution relationships as edges, recording the state transition paths explored from the current state. During the state expansion process, for each state node to be expanded, the feature hash value of the parameter value combination corresponding to the state node is pre-calculated, and the feature hash value is stored in the visited state set. When the same state node is reached through different action sequences, a quick match is performed in the visited state set based on the feature hash value to identify the duplicate state and terminate further expansion of the duplicate state to avoid state space explosion. Meanwhile, during the state expansion process, the state transition depth from the current state to each reachable state is monitored in real time. The state transition depth is the minimum number of actions required to reach the reachable state from the current state. The state transition depth is associated with the corresponding reachable state and recorded for priority sorting during subsequent state division and action masking.

[0052] In step S40, when the system enumerates all reachable states based on the transition function starting from the current state, it further employs a state space traversal method based on a state expansion graph and feature hashing to improve enumeration efficiency and effectively control the size of the state space. Specifically, the system dynamically constructs a state expansion graph during the enumeration of all reachable states. This graph uses states as nodes and action execution relationships as edges, completely recording all explored state transition paths starting from the current state. Each node represents a state with a combination of parameter values, and each directed edge represents a transition relationship from the source state to the target state after executing a certain operation unit. By maintaining this state expansion graph, the system can clearly trace the source path of each state, providing a structured basis for subsequent state analysis and priority ranking.

[0053] During state expansion, the system pre-calculates a characteristic hash value for the parameter value combination corresponding to each state node to be expanded. The characteristic hash value is calculated as follows: the system arranges all state variables contained in the state node in a preset fixed order, concatenates the name of each state variable with its current value into a string, and then applies a hash algorithm to the entire string to generate a fixed-length hash value. This hash value uniquely identifies the state node. The system stores this characteristic hash value in the visited state set, which records all expanded state nodes. When different action sequences reach the same state node—that is, when two or more different state transition paths converge to the same parameter value combination—the system quickly matches the visited state set based on the characteristic hash value. Because the hash value has unique identification properties, the system can identify the existence of the state node within a constant time, thus determining it to be a duplicate state. Once a duplicate state is identified, the system immediately terminates further expansion of that duplicate state and no longer treats it as a new node for subsequent state expansion operations. This effectively avoids repeated exploration caused by multiple paths converging on the same state, preventing exponential expansion of the state space.

[0054] Meanwhile, the system monitors the state transition depth from the current state to each reachable state in real time during the state expansion process. The state transition depth is defined as the minimum number of actions required to reach the reachable state from the current state. When constructing the state expansion graph, the system employs a breadth-first search strategy, starting with the current state as the starting node. The depth of the state nodes obtained from the first layer of expansion is one, the depth of the state nodes obtained from the second layer is two, and so on. The system associates the calculated state transition depths with the corresponding reachable states, forming a depth-state mapping table.

[0055] This mapping table is used for priority ranking during subsequent state partitioning and action masking. For example, when multiple reachable states are marked as verified successful states, the system can prioritize recommending states with smaller transition depths as debugging targets, guiding users to reach the successful state with the fewest steps. During masking, for actions that lead to verified failed states, the system can provide tiered prompts based on transition depth information, giving more prominent masking or warnings to shallower, more easily accessible failure paths, thereby further improving the intelligence level of debugging guidance. Through the enumeration method combining feature hashing deduplication and depth recording, the system can significantly reduce the computational overhead of state space traversal while ensuring the integrity of reachable states, providing efficient and accurate state set support for subsequent state partitioning and action masking.

[0056] Step S50: Based on the final results of each action in the historical trajectory, the reachable state is divided into verified successful state, verified failed state and unexplored state, and the actions corresponding to the verified failed state are masked on the debugging interface. In this embodiment, the method for dividing the reachable state into a verified successful state, a verified failed state, and an unexplored state is as follows: Obtain historical trajectories prefixed with the current state. Each historical trajectory contains a complete state sequence from the initial state to the final state through a series of actions, and records the final result of the corresponding debugging operation. For each reachable state, traverse all historical trajectories and identify whether there exists a historical trajectory that is prefixed with the current state and passes through that reachable state. If a historical trajectory passes through this reachable state, and the final result corresponding to this historical trajectory represents successful debugging, then the reachable state is marked as a verified successful state. If a historical trajectory passes through this reachable state, and the final result corresponding to this historical trajectory indicates that the debugging failed, then the reachable state is marked as a verified failure state. If no historical trajectory passes through the reachable state, then the reachable state is marked as unexplored.

[0057] The method to disable actions corresponding to verified failure states in the debugging interface is as follows: Obtain the verified failure status, and each verified failure status corresponds to a combination of parameter values; Establish a mapping relationship between states and actions, and determine the target state variable corresponding to each operation unit and the next state it points to after the assignment and modification; Traverse all operation units in the action space, and for each operation unit, identify the next state reached from the current state after executing the operation unit; If the identified next state belongs to the verified failure state, then the operation unit is determined to be a blockable action; On the debugging interface, set the operation control corresponding to the action to be blocked to a disabled state. The disabled state is manifested by the control being grayed out and unable to trigger interaction. When the current state changes due to the user performing other operation units, the traversal recognition step is re-executed to dynamically update the masking state on the debugging interface.

[0058] In step S50, based on the final results of each action in the historical trajectory, the reachable states are divided into verified successful states, verified failed states, and unexplored states. Actions corresponding to verified failed states are then masked on the debugging interface. Specifically, all historical trajectories prefixed with the current state are first obtained. Each historical trajectory contains a complete state sequence transitioning from the initial state to the final state through a series of actions, and records the final result of the corresponding debugging operation, including whether the debugging was successful or failed. For example, during the debugging of the patent information query interface, the current state is "Patent Type = Invention, Applicant = XX, Publication Date Range = Empty". Two historical trajectories prefixed with this state are obtained. In one trajectory, the user subsequently sets the "Publication Date Range" to "2023-01-01 to 2023-12-31" and successfully returns the patent list. In the other trajectory, the user changes the "Patent Type" to "Utility Model" and triggers an interface error, resulting in a debugging failure.

[0059] Subsequently, for each reachable state in the reachable state set, all historical trajectories prefixed with the current state are traversed, and it is identified one by one whether a historical trajectory prefixed with the current state passes through that reachable state in its state sequence. For the reachable state "Patent type = Invention, Applicant = XX, Publication date range = 2023-01-01 to 2023-12-31", it is marked as a verified successful state because a successful trajectory passes through this state; for the reachable state "Patent type = Utility model, Applicant = XX, Publication date range = Empty", it is marked as a verified failed state because a failed trajectory passes through this state; for the reachable state "Patent type = Invention, Applicant = XX, Publication date range = 2024-01-01 to 2024-06-30", it is marked as an unexplored state because no historical trajectory passes through this state.

[0060] After completing the state division, the actions corresponding to the verified failed states are masked on the debugging interface. Specifically, the verified failed states are obtained, each corresponding to a specific combination of parameter values. A mapping relationship between states and actions is established, determining the target state variable corresponding to each operation unit and the next state it points to after the value is modified. All operation units in the action space are traversed, and for each operation unit, the next state reached from the current state after executing the operation unit is identified. For example, under the current state "Patent type = Invention, Applicant = XX, Publication date range = Empty", there is an operation unit "Modify the patent type to utility model". The next state reached after executing this operation unit is exactly the verified failed state "Patent type = Utility model, Applicant = XX, Publication date range = Empty". This operation unit is identified as the action to be masked. On the debugging interface, the operation control corresponding to the action to be masked is set to a disabled state, that is, the "Utility model" option in the "Patent type" drop-down list is grayed out and cannot be selected by the user, thus directly preventing the user from executing the operation at the interface interaction level. When the user performs other operations that cause the current state to change, such as when the user changes the "applicant" to another company name, the above traversal and identification steps are re-executed. Based on the new current state, the system recalculates which actions will lead to the verified failure state and dynamically updates the masking state on the debugging interface to ensure that the masking strategy always matches the current state, thus realizing intelligent debugging guidance based on historical experience.

[0061] Step S60: Record the current user's debugging process as a new debugging path trajectory and update the stored debugging path trajectory.

[0062] In step S60, the current user's debugging process is recorded as a new debugging path trajectory, and the stored debugging path trajectory is updated. Specifically, after the user completes the current debugging operation and triggers the interface call, the complete process data of this debugging is obtained, including the initial state at the start of the debugging, the parameter modification actions performed sequentially by the user during the debugging process, the intermediate states reached after each action, and the final result of this interface call. This data is organized into a complete debugging path trajectory in chronological order. This trajectory starts from the initial state, records each action and its corresponding intermediate state sequentially, and ends with the final result.

[0063] For example, continuing the debugging scenario of the aforementioned patent information query interface, the initial state of this debugging is "Patent type = empty, Applicant = empty, Publication date range = empty". The user sequentially performs three actions: setting "Patent type" to "Invention", setting "Applicant" to "XX", and setting "Publication date range" to "2023-01-01 to 2023-12-31". After each action, the user reaches the corresponding intermediate state. Finally, the interface call is successful and returns the patent list. This information is integrated into a new debugging path trajectory. This trajectory is stored in the trajectory storage module in the form of structured data. When storing, the trajectory is assigned a unique identifier and an association relationship is established with the current debugging interface to ensure that the trajectory can be quickly retrieved when debugging the same interface in the future.

[0064] For the existing historical trajectory library, an incremental update method is used to append newly recorded trajectories to the library without overwriting existing historical trajectories, thereby continuously enriching the historical experience data. As debugging trajectories continue to accumulate, the trajectory library contains more and more successful and failed cases, providing a more comprehensive historical basis for state division and action masking in subsequent debugging processes. This forms a closed loop of debugging knowledge accumulation and reuse, enabling the intelligent guidance capability to continuously improve with the number of uses.

[0065] After recording the current user's debugging process as a new debugging path trajectory and updating the stored debugging path trajectory, it also includes: Regularly perform cluster analysis on the stored debugging path trajectories, and divide the trajectories into multiple trajectory clusters based on the similarity of the state sequences in each trajectory. Each trajectory cluster corresponds to a type of debugging scenario with similar parameter configuration patterns. For each trajectory cluster, common state transition features within the cluster are extracted. These common state transition features include state nodes that the trajectories within the cluster traverse commonly pass through and action sequences that are commonly executed. Based on the common state transition features, a recommended debugging path template is generated for this debugging scenario. The recommended debugging path template includes the shortest state transition path from the initial state to the successful result and optimal parameter configuration suggestions for each state node. When a new user starts debugging, if the new user's initial state or early operation sequence matches the characteristics of a certain trajectory cluster, the recommended debugging path template will be actively displayed on the debugging interface for the user to use with one click or as a debugging reference.

[0066] After recording the current user's debugging process as a new debugging path trajectory and updating the storage in step S60, the system further performs periodic mining and analysis of the stored debugging path trajectories to form reusable debugging knowledge templates. Specifically, the system triggers a trajectory clustering analysis process according to a preset time period or when the number of newly added trajectories in the trajectory storage module reaches a preset threshold. The system first acquires all stored debugging path trajectories. Each trajectory consists of a state sequence and its corresponding final result. The system divides the trajectories into multiple trajectory clusters based on the similarity of the state sequences in each trajectory. The calculation method for state sequence similarity is as follows: the system converts the state sequence of each trajectory into a state variable value vector sequence, and uses a sequence alignment algorithm to calculate the edit distance or the length of the longest common subsequence between two trajectories, using this as a similarity metric. Through the clustering algorithm, the system groups trajectories with high similarity into the same trajectory cluster, and each trajectory cluster corresponds to a type of debugging scenario with similar parameter configuration patterns. For example, during the debugging process of the patent information query interface, a large number of tracks involved selecting between "invention" and "utility model" for the "patent type" parameter and configuring the "publication date range" parameter within different year intervals. The system clustered these tracks into multiple track clusters such as "invention patent query debugging scenario" and "utility model patent query debugging scenario".

[0067] For each trajectory cluster, the system extracts common state transition features within that cluster. Specifically, the system identifies common state nodes traversed by all trajectories within the cluster—state nodes appearing in the majority of trajectories within the cluster—and marks them as common state nodes. Simultaneously, the system identifies common action sequences executed by all trajectories within the cluster—action combinations appearing in the majority of trajectories within the cluster and executed in the same order—and marks them as common action sequences. For example, in the trajectory cluster of the "Invention Patent Search and Debugging Scenario," the system found that most trajectories passed through the state node "Patent Type = Invention, Publication Date Range = 2023-01-01 to 2023-12-31," and all executed the action sequence "First set the patent type to invention, then set the publication date range to the current year." The system extracts these features as common state transition features.

[0068] Based on the extracted common state transition features, the system generates a recommended debugging path template for this debugging scenario. This template includes the shortest state transition path from the initial state to the successful result, as well as optimal parameter configuration suggestions for each state node. When generating the shortest state transition path, the system starts from the initial state and selects the path with the fewest state nodes (i.e., the shortest transition depth) from among the successful trajectories within the trajectory cluster. The system then extracts the state nodes and transition actions along this path to form a standard path template. For optimal parameter configuration suggestions at each state node, the system statistically analyzes the distribution of parameter values ​​at each state node in the successful trajectories within the cluster and determines the most frequently occurring parameter value as the recommended configuration for that state node. For example, in the "Invention Patent Search Debugging Scenario," the system-generated shortest path template might be "Initial State → Set Patent Type to Invention → Set Publication Date Range to the Most Recent Year → Successful Interface Call," and suggests prioritizing the date range of the most recent full year at the "Publication Date Range" node.

[0069] When a new user begins debugging, the system monitors the user's initial state and early operation sequence in real time, matching them with the characteristics of existing trajectory clusters. If the user's initial state or early operation sequence matches the common state transition characteristics of a trajectory cluster—for example, if the user's initial state did not set "Patent Type" but they quickly selected "Invention," matching the initial characteristics of the "Invention Patent Search and Debugging Scenario" trajectory cluster—the system proactively displays a recommended debugging path template for that trajectory cluster on the debugging interface. This can be displayed as a pop-up recommendation card in the sidebar of the debugging interface, visually presenting the optimal path steps from the current state to a successful result, and annotating the recommended parameter configurations at each state node. Users can click the "One-Click Adoption" button, and the system automatically executes each action according to the recommended path template, configuring the parameters to the recommended values. Users can also use the recommended template as a reference and manually debug according to its suggestions. Through this trajectory clustering and template generation mechanism, the system achieves the extraction and reuse of individual debugging experience into group debugging knowledge, enabling new users to quickly complete debugging by drawing on past successful experiences, further improving debugging efficiency and user experience.

[0070] like Figure 2 As shown, a semantic parsing-based online API interface debugging system according to a second embodiment of the present invention is used to execute the above-described semantic parsing-based online API interface debugging method. The system includes: The model building module is used to build an interface parameter state space model. The state space model includes a state space, an action space, and a transition function. The state space is a set of possible combinations of all parameters of the interface. The action space is a set of executable parameter modification operations. The transition function is used to define the next state reached after performing any action in any state. The trajectory storage module is used to acquire and store the user's debugging process record of the interface, and record each debugging process as a debugging path trajectory. The debugging path trajectory includes the initial state, at least one action, at least one intermediate state and the final result. The status determination module is used to respond to the current user's debugging operation and determine the current status, which is the combination of parameter values ​​corresponding to all parameter modification operations completed by the current user. The reachable state enumeration module is used to enumerate all reachable states based on the current state and the transition function. The historical trajectory acquisition module is used to acquire historical trajectories prefixed with the current state based on the debugging path trajectory. The state division module is used to divide the reachable state into verified successful state, verified failed state and unexplored state according to the final result corresponding to each action in the historical trajectory. The action masking module is used to mask actions that have been verified as failed on the debugging interface. The trajectory update module is used to record the current user's current debugging process as a new debugging path trajectory and update the debugging path trajectory stored in the trajectory storage module.

[0071] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related explanations of the methods described above can be found in the corresponding processes in the foregoing system embodiments, and will not be repeated here.

[0072] It should be noted that the above-described embodiment of an online API interface debugging system based on semantic parsing is merely an example of the division of functional modules. In practical applications, the functions described above can be assigned to different functional modules as needed, that is, the modules or steps in the embodiments of the present invention can be further decomposed or combined. For example, the modules in the above embodiments can be merged into one module, or further divided into multiple sub-modules to complete all or part of the functions described above. The names of the modules and steps involved in the embodiments of the present invention are merely for distinguishing the various modules or steps and are not considered as an improper limitation of the present invention.

[0073] A device according to a third embodiment of the present invention includes: At least one processor; and a memory communicatively connected to at least one of the processors; The memory stores instructions that can be executed by the processor to implement the above-described semantic parsing-based online debugging method for API interfaces.

[0074] A fourth embodiment of the present invention provides a computer-readable storage medium storing computer instructions, which are executed by the computer to implement the above-described semantic parsing-based online debugging method for API interfaces.

[0075] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process and related descriptions of the storage device and processing device described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0076] The following is for reference. Figure 3 It shows a schematic diagram of the structure of a computer system for implementing embodiments of the systems, methods, and electronic devices of this application. Figure 3 The server shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0077] like Figure 3 As shown, the computer system includes a Central Processing Unit (CPU) 301, which can perform various appropriate actions and processes based on programs stored in Read Only Memory (ROM) 302 or programs loaded from storage section 308 into Random Access Memory (RAM) 303. The RAM 303 also stores various programs and data required for system operation. The CPU 301, ROM 302, and RAM 303 are interconnected via a bus 304. An Input / Output (I / O) interface 305 is also connected to the bus 304.

[0078] The following components are connected to I / O interface 305: an input section 306 including a keyboard, mouse, etc.; an output section 307 including a cathode ray tube (CRT), liquid crystal display (LCD), and speakers, etc.; a storage section 308 including a hard disk, etc.; and a communication section 309 including a network interface card such as a LAN (Local Area Network) card and a modem, etc. The communication section 309 performs communication processing via a network such as the Internet. A drive 310 is also connected to I / O interface 305 as needed. Removable media 311, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 310 as needed so that computer programs read from them can be installed into storage section 308 as needed.

[0079] Specifically, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 309, and / or installed from removable medium 311. When the computer program is executed by central processing unit (CPU) 301, it performs the functions defined in the methods of this application. It should be noted that the computer-readable medium described above in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on a computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0080] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0081] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0082] The terms “first”, “second”, etc., are used to distinguish similar objects, not to describe or indicate a specific order or sequence.

[0083] The term "comprising" or any other similar term is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus / device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent in such process, method, article, or apparatus / device.

[0084] The technical solution of the present invention has been described above with reference to the preferred embodiments shown in the accompanying drawings. However, it will be readily understood by those skilled in the art that the scope of protection of the present invention is obviously not limited to these specific embodiments. Without departing from the principles of the present invention, those skilled in the art can make equivalent changes or substitutions to the relevant technical features, and the technical solutions after these changes or substitutions will all fall within the scope of protection of the present invention.

Claims

1. A method for online debugging of API interfaces based on semantic parsing, characterized in that, The method includes: Construct an interface parameter state space model, which includes a state space, an action space, and a transition function. The state space is a set of possible combinations of all parameters of the interface. The action space is a set of executable parameter modification operations. The transition function is used to define the next state reached after performing any action in any state. Acquire and store the user's debugging process record for the interface, and record each debugging process as a debugging path trajectory. The debugging path trajectory includes the initial state, at least one action, at least one intermediate state, and the final result. In response to the current user's debugging operation, determine the current state, which is the combination of parameter values ​​corresponding to all parameter modification operations completed by the current user; Starting from the current state, enumerate all reachable states according to the transition function, and obtain the historical trajectory with the current state as a prefix based on the debugging path trajectory; Based on the final results of each action in the historical trajectory, the reachable state is divided into verified successful state, verified failed state and unexplored state, and the actions corresponding to the verified failed state are masked on the debugging interface. Record the current user's debugging process as a new debugging path trajectory and update the stored debugging path trajectory.

2. The method according to claim 1, characterized in that, Methods for constructing interface parameter state-space models include: Parse the interface definition data, extract all parameters and the data structure and value constraints of each parameter, decompose the composite structure parameter into multiple sub-parameters, map the decomposed sub-parameters and original parameters together into independent state variables, and construct the state space with the Cartesian product of the legal values ​​of each state variable. Each state variable is used as the operation object, and operation units that assign and modify values ​​to each state variable are defined. The action space is constructed by all operation units. The dependencies and mutual exclusions between parameters are analyzed. Based on the obtained dependencies and mutual exclusions, parameter value combinations that do not meet the constraints are filtered out in the state space so that the state space contains only valid states that conform to the business logic. The linkage logic between state variables is constructed based on the dependencies and mutual exclusions, and the transition function is generated based on the linkage logic. The transfer function is used to respond to any assignment modification operation of a state variable and update other state variables affected by that state variable in a coordinated manner to determine the next state to be reached.

3. The method according to claim 2, characterized in that, The method for constructing the state space using the Cartesian product of the legal values ​​of each state variable is as follows: Based on the data structure defined in the interface definition data, identify the type attributes of each parameter, and decompose parameters with composite structure types into multiple basic type sub-parameters according to their internal field hierarchy; The sub-parameters obtained from the decomposition, together with the original parameters which are the basic types, are established as independent state variables. Each state variable corresponds to an indivisible basic parameter unit in the interface. Obtain the set of legal values ​​corresponding to each state variable, wherein the set of legal values ​​is determined based on the value constraints in the interface definition data; Perform a Cartesian product operation on the set of all legal values ​​of the state variables, and the resulting set is used as the state space. Each element in the state space uniquely represents a combination of values ​​of all parameters of the interface.

4. The method according to claim 2, characterized in that, The method for constructing the action space from all operation units is as follows: The data type of the parameters corresponding to each state variable is analyzed, and the operation type for assigning and modifying each state variable is determined based on the data type. The operation type includes one or more of the following: text input, numerical increment / decrement, enumeration selection, and structured data editing. For each state variable as the operation target, and in combination with the operation type, at least one operation unit is generated for that state variable, and each operation unit corresponds to an independent parameter assignment and modification action. Collect the operation units generated for all state variables, and construct the action space from the set of operation units.

5. The method according to claim 2, characterized in that, Based on the dependencies and mutual exclusions obtained from the analysis, the linkage logic between state variables is constructed. The method for generating the transition function based on the linkage logic is as follows: The dependencies and mutual exclusions between parameters are analyzed, and each group of parameters with business relevance is established as an associated parameter group. Within the associated parameter group, the constraint types between state variables are identified. The constraint types include one or more of the following: mandatory conditions, linked value ranges, mutually exclusive selection, and simultaneous increase or decrease. For each constraint type, a corresponding linkage rule is constructed. The linkage rule defines how the value of the affected state variable is adjusted when the value of the triggering state variable changes. All linkage rules are integrated to generate the transition function. The transition function takes the current state and the assignment modification action of the triggered state variable as input, calculates and outputs the updated values ​​of all state variables affected by the linkage according to the linkage rules, and forms the next state.

6. The method according to claim 1, characterized in that, The method for determining the current state in response to the current user's debugging actions is as follows: Monitor the parameter modification actions performed by the user in the debugging interface. Each parameter modification action corresponds to an operation unit in the action space. Capture the target state variable targeted by the operation unit and the target value after assignment and modification; Obtain the currently recorded user operation sequence, which includes one or more parameter modification actions completed by the current user since the start of this debugging process; The parameter modification actions in the user operation sequence are applied to the initial state in the order of execution. The initial state is a blank state where all parameters of the interface are not assigned values ​​or a preset default state. The combination of parameter values ​​obtained after sequential action is determined as the current state.

7. The method according to claim 1, characterized in that, Starting from the current state, the method for enumerating all reachable states according to the transition function and obtaining the historical trajectory prefixed with the current state based on the debug path trajectory is as follows: Using the current state as the initial node, the transfer function is applied to the current state, and the next state reached after each operation unit in the action space is enumerated. The new states obtained through enumeration are used as new nodes, and the transition function is repeatedly applied to expand the state until no new states are generated. All the states obtained through enumeration are collected as the reachable states. Each stored debugging path trajectory is represented as a state sequence, which consists of the states arranged in chronological order during the debugging process. Traverse all state sequences and identify the state sequence whose starting part completely matches the current state as the historical trajectory prefixed with the current state.

8. The method according to claim 1, characterized in that, The method for classifying the reachable states into verified successful states, verified failed states, and unexplored states is as follows: Obtain historical trajectories prefixed with the current state. Each historical trajectory contains a complete state sequence from the initial state to the final state through a series of actions, and records the final result of the corresponding debugging operation. For each reachable state, traverse all historical trajectories and identify whether there exists a historical trajectory that is prefixed with the current state and passes through that reachable state. If a historical trajectory passes through this reachable state, and the final result corresponding to this historical trajectory represents successful debugging, then the reachable state is marked as a verified successful state. If a historical trajectory passes through this reachable state, and the final result corresponding to this historical trajectory indicates that the debugging failed, then the reachable state is marked as a verified failure state. If no historical trajectory passes through the reachable state, then the reachable state is marked as unexplored.

9. The method according to claim 1, characterized in that, The method to disable actions corresponding to verified failure states in the debugging interface is as follows: Obtain the verified failure status, and each verified failure status corresponds to a combination of parameter values; Establish a mapping relationship between states and actions, and determine the target state variable corresponding to each operation unit and the next state it points to after the assignment and modification; Traverse all operation units in the action space, and for each operation unit, identify the next state reached from the current state after executing the operation unit; If the identified next state belongs to the verified failure state, then the operation unit is determined to be an action to be blocked. On the debugging interface, set the operation control corresponding to the action to be blocked to a disabled state. The disabled state is manifested by the control being grayed out and unable to trigger interaction. When the current state changes due to the user performing other operation units, the traversal recognition step is re-executed to dynamically update the masking state on the debugging interface.

10. An online debugging system for API interfaces based on semantic parsing, characterized in that, The system includes: The model building module is used to build an interface parameter state space model. The state space model includes a state space, an action space, and a transition function. The state space is a set of possible combinations of all parameters of the interface. The action space is a set of executable parameter modification operations. The transition function is used to define the next state reached after performing any action in any state. The trajectory storage module is used to acquire and store the user's debugging process record of the interface, and record each debugging process as a debugging path trajectory. The debugging path trajectory includes the initial state, at least one action, at least one intermediate state and the final result. The status determination module is used to respond to the current user's debugging operation and determine the current status, which is the combination of parameter values ​​corresponding to all parameter modification operations completed by the current user. The reachable state enumeration module is used to enumerate all reachable states based on the current state and the transition function. The historical trajectory acquisition module is used to acquire historical trajectories prefixed with the current state based on the debugging path trajectory. The state division module is used to divide the reachable state into verified successful state, verified failed state and unexplored state according to the final result corresponding to each action in the historical trajectory. The action masking module is used to mask actions that have been verified as failed on the debugging interface. The trajectory update module is used to record the current user's current debugging process as a new debugging path trajectory and update the debugging path trajectory stored in the trajectory storage module.

Images