An ai large language model interaction method based on an existing interface of an information system

Abstract

This invention discloses an AI large language model interaction method based on existing interfaces of an information system, comprising: constructing an interface operation feature set based on the information system operation log; identifying the business intent category and functional granularity level corresponding to the interface, and generating an interface functional granularity identification table; constructing an action rule chain based on the interface business intent category and functional granularity level; performing field consistency calibration by combining field timing identifiers, stage identifiers, and trigger point identifiers to form standardized intermediate JSON data; generating prompt words containing field operation instructions, business semantic instructions, and timing background instructions based on the standardized intermediate JSON data; sending model requests, parsing and verifying model output results through existing API interfaces, and recording system status update information. This invention reduces system transformation costs, improves the accuracy of interface semantic expression, and provides an implementable and scalable technical path for the intelligent upgrading of traditional information systems.

Description

Technical Field

[0001] This invention relates to the field of computer software and information processing technology, and in particular to an AI large language model interaction method based on existing interfaces of information systems. Background Technology

[0002] With the rapid development of information technology and artificial intelligence, enterprise information systems have been widely used in business management, production scheduling, customer service, and operation and maintenance support. Traditional information systems typically provide business capabilities through existing API interfaces. These interfaces were designed and deployed in the early stages of system construction, and their functional boundaries, field structures, and calling methods are relatively fixed, serving stable business processes for a long time. However, in practical applications, the integration between traditional information systems and AI large language models faces many technical challenges. To achieve interaction between information systems and AI large language models, existing technologies typically rewrite interfaces, add intermediate services, or manually build business adaptation layers to re-encapsulate existing interfaces, making their output format and semantic structure adapt to the input requirements of AI models. However, such solutions often require large-scale modifications to the original system, increasing development and maintenance costs and potentially introducing new system risks, especially when the number of interfaces is large, the historical system is complex, or there is a lack of complete documentation, further increasing the difficulty and uncertainty of implementation. In addition, existing technologies generally ignore the dynamic behavior differences of interfaces in runtime. The same interface can exhibit drastically different business intents and functional granularities in different transactions due to variations in call location, upstream and downstream interface combinations, and field read / write order. Treating it as a single, fixed-semantic interface can easily lead to misunderstandings. Furthermore, internal interface fields often play different roles and functions during business execution. Current technologies lack systematic analysis of the business structure and execution order at the field level, making it difficult to accurately reflect the logical relationships between multiple business actions within the interface. When introducing AI large-scale language models into business processing, without effective constraints on the interface's business structure, business stages, and temporal relationships, the model is prone to inference based on incomplete or fragmented business information, leading to judgments that do not conform to actual business rules and potentially impacting system operation. Therefore, how to accurately characterize the interface's business intent, functional granularity, and internal business structure based on the actual operational behavior of the information system without modifying the existing interface structure, and how to construct an input mechanism suitable for AI large-scale language model understanding and interaction, has become a pressing technical problem to be solved in the current intelligent transformation of information systems. Summary of the Invention

[0003] To address the problems existing in the prior art, this invention provides an AI large language model interaction method based on existing interfaces of information systems, mainly including:

[0004] Based on the information system operation logs and interface specification documents, obtain the interface call sequence details table, and construct the interface operation feature set by combining field read and write behavior scanning, field operation trajectory analysis and field data dependency relationship.

[0005] Based on the interface operation characteristic data, identify the business intent category and functional granularity level corresponding to the interface, and combine the field dependency stability score and transaction-level action integrity score to filter candidate interfaces and generate an interface functional granularity identification table.

[0006] Based on the interface business intent category and function granularity level recorded in the interface function granularity identification table, the interface fields are divided into field paragraphs, the field semantics are checked, and the business function is marked, and an action rule chain is constructed.

[0007] By obtaining system operation status trajectory fragments from information system operation logs, business stages are marked and time-series context information is generated. Field consistency calibration is performed by combining field time sequence identifiers, stage identifiers and trigger point identifiers to form standardized intermediate JSON data.

[0008] Based on the business meaning of the fields in the standardized intermediate JSON data, the characteristics of interface operations, and the time sequence stage information, generate prompt words that include field operation descriptions, business semantic descriptions, and time sequence background descriptions;

[0009] The system sends model requests, parses and verifies model output results using existing API interfaces, maps results that meet interface constraints and business stage requirements back to the target interface, and records system status update information.

[0010] Furthermore, the step of obtaining an interface call sequence detail table based on the information system operation logs and interface specification documents, and constructing an interface operation feature set by combining field read / write behavior scanning, field operation trajectory analysis, and field data dependency relationships, includes:

[0011] Based on the information system operation logs and interface specification documents, each running interface call path is parsed one by one, recording the timestamp, call order, request parameters, and return field groups. These are then grouped and sorted according to interface identifier and transaction number to obtain an interface call sequence detail table containing action sequences and field mapping relationships. By scanning each field read / write behavior of each group of transactions in the interface call sequence detail table, the read, write, and update operation types of the fields are marked and their frequency of occurrence is counted, generating field operation trajectories. The range of field value changes, value boundaries, and frequency of outliers in the trajectories are analyzed to determine the value range of each field in the target business scenario, thus determining the field operation range and corresponding boundary conditions. Based on the read / write order and mutual reference relationships of fields in the transaction, a data dependency description between fields is formed, resulting in an interface operation feature set containing the number of fields, the proportion of field read / write behaviors, the complexity of field dependency relationships, the position of fields in the transaction, and the transaction call length. This set is then stored in the interface operation monitoring database.

[0012] Furthermore, the step of identifying the business intent category and functional granularity level corresponding to the interface based on the interface operation characteristic data, and combining field dependency stability score and transaction-level action integrity score to filter candidate interfaces and generate an interface functional granularity identification table includes:

[0013] By utilizing an interface operation monitoring database, historical interface operation feature data is obtained, and the interface business intent type and functional granularity are labeled. A random forest algorithm is used for model training to construct a joint identification model for interface business intent and functional granularity. Business intents include business initiation, business verification, business processing, status update, and business confirmation; functional granularity includes coarse-grained, medium-grained, and fine-grained. Based on the real-time acquired interface operation feature data, the joint identification model for interface business intent and functional granularity is used to identify the corresponding business intent category and functional granularity level of the interface. The identified interface business intent is compared with the target business intent for evaluation. Estimate the functional granularity deviation of existing API interfaces under the target business intent; combine field dependency stability score and transaction-level action integrity score to filter out interfaces whose granularity deviation is within the preset range and meets the stability and integrity requirements, and generate a candidate interface list; use identifier mapping to encode the structural parameters of the candidate interfaces into granularity identification tags to obtain the interface functional granularity identification table; based on the call position of the same interface under different transaction numbers, interface combination relationship and field read / write order differences in the interface call sequence details table, perform interface context feature extraction, consistency detection and context sharding processing, and update the interface functional granularity identification table.

[0014] It also includes extracting interface context features, performing consistency checks, and handling context sharding based on the call positions, interface combination relationships, and differences in field read / write order of the same interface under different transaction numbers in the interface call sequence details table, and updating the interface function granularity identification table, specifically including:

[0015] Based on the interface call sequence details table, a comparative analysis is performed on the call positions, interface combination relationships, and field read / write order of the same interface identifier under different transaction numbers. A set of contextual features of the interface in different transaction contexts is extracted. These contextual features include at least the interface's relative call position in the transaction, the number of preceding interfaces, the number of succeeding interfaces, the first appearance position of a field, and the stage distribution of the field's participation in write operations. Based on this set of contextual features, consistency detection is performed between the business intent identification results and functional granularity identification results of the interface in different transactions, and the business intent of the interface under different transaction contexts is calculated. Figure 1 Consistency coefficient and functional granularity stability coefficient; if the interface's business intent Figure 1 If the consistency coefficient or functional granularity stability coefficient is lower than a preset threshold, the interface is determined to have a business semantic drift risk and is marked as a context-sensitive interface. Context-sensitive interfaces are processed by context sharding according to the transaction call path. Call instances of the same interface formed in different transaction contexts are regarded as different context interface units, and their corresponding business intent category, functional granularity level, and field operation range are recorded respectively. The context interface unit replaces the original interface identifier and the interface functional granularity identification table is updated.

[0016] Furthermore, the step of dividing interface fields into paragraphs, verifying field semantics, and marking business functions based on the interface business intent category and function granularity level recorded in the interface function granularity identification table, and constructing an action rule chain, includes:

[0017] Based on the interface business intent category and function granularity level recorded in the interface function granularity identification table, the field names, field function descriptions, and transaction numbers contained in the interface are read line by line. Fields with the same function granularity marker and appearing consecutively in a transaction are grouped into the same field segment. By statistically analyzing the number of fields in each field segment, the order in which fields appear during transaction execution, and the participation of fields in read and write operations, the field segmentation results at the operation level of the interface are obtained. Combined with a pre-set field semantic reference table, the semantic meaning, naming rules, and corresponding business descriptions of the fields in each field segment are checked and analyzed. Under the constraint of the identified business intent category, the field segment in the interface is determined. The functional attribution relationships in the business structure are identified, and field segments are marked with business functions. These business function marks are used to characterize whether a field segment corresponds to a single or multiple business functions. Field segments with the same business function mark are organized, and the necessary, optional, and prerequisite fields required to complete the business function are extracted. Multiple business actions are associated and constructed into an action rule chain according to the business execution order, and the corresponding interface identifiers, field information, and execution order are recorded. Based on the constructed action rule chain, combined with the sequential relationship of field segments in the business execution process and the business function mark, business breakage is determined for adjacent field segments, and high-breakage chains are identified based on the field segment business breakage index.

[0018] It also includes, based on the constructed action rule chain, combined with the sequential relationship of field segments in the business execution process and business function markers, determining business breaks between adjacent field segments, and identifying high-break chains based on the field segment business break index, specifically including:

[0019] Based on the constructed action rule chain, the field segment sequence is extracted according to the business execution order, and the business function tag corresponding to each field segment is read. The business function tags of adjacent field segments are compared one by one. When the business function tags corresponding to adjacent field segments are inconsistent, a business break is determined to have occurred at that position. Based on the number of business breaks in the action rule chain and the total number of adjacent field segment pairs, the field segment business break index formula is used. Calculate the Business Breakdown Index (BFI) for the field paragraph, where... This represents the i-th field segment in the action rule chain, arranged in execution order. This is a sequence formed by arranging the field paragraphs in the actual execution order, with each field paragraph... It has been marked as a certain business function type , This indicates whether adjacent field segments belong to the same business continuum. n is the number of field segments in the action rule chain, and n-1 is the number of adjacent field segment pairs in the action rule chain. The field segment business break index (BFI) is used to represent the continuity of the action rule chain at the business function level. If the field segment business break index is higher than the preset index threshold, it is determined that the current action rule chain has a risk of breakage at the business semantic level, and the action rule chain is marked as a high-break chain.

[0020] Furthermore, by obtaining system operation status trajectory fragments from information system operation logs, marking business stages and generating time-series context information, and combining field time-series identifiers, stage identifiers, and trigger point identifiers to perform field consistency calibration, standardized intermediate JSON data is formed, including:

[0021] By analyzing the information system's operation logs, fragments of the system's operational status trajectory are obtained. These trajectories are divided into multiple time periods based on chronological order. The status trajectories describe the business execution process comprised of multiple business actions. By extracting temporal features within each time period and labeling different business stages, a decision tree algorithm is used for model training to construct a business stage temporal recognition model. This model predicts the current business stage of the system. The temporal features include the order of state changes, trigger event types, and field change patterns. By comparing the changes in field values ​​and states in adjacent time periods, the differences between the current state and subsequent stage states are determined, generating temporal context information reflecting the business stage's location. Based on this temporal context information, corresponding temporal identifiers, stage identifiers, and trigger point identifiers are appended to relevant fields in the script execution environment. Consistency checks are performed on the field information after appending identifiers, and field identifiers under different dimensions are synchronously calibrated. It is determined whether there are value jumps or inconsistencies in order during the business stage transition. For fields with temporal deviations, correction processing is performed based on the field's position in the operation chain to obtain standardized intermediate JSON data.

[0022] Furthermore, the step of generating prompts containing field operation descriptions, business semantic descriptions, and time sequence stage information based on the business meanings of fields in the standardized intermediate JSON data includes:

[0023] Based on standardized intermediate JSON data, the business meaning, interface operation characteristics, and timing information corresponding to the fields are read. The system then determines whether the current field originates from an action rule chain marked as having a high breakage. If the field originates from a high breakage chain, it groups the fields according to their business function tags, semantically merging field segments belonging to the same business function, or continuously rearranging the presentation order of the fields in the prompts without changing the actual execution order. Based on the semantically merged and continuously rearranged field set, combined with the field's operation method in the interface, its semantic meaning in the business, and its stage in the business process, the field name and value are extended to form a field description containing field operation instructions, business semantic descriptions, and timing background information. This description serves as the prompt content for the AI ​​large language model, and the prompt content of the AI ​​large language model, along with the corresponding field values, is encapsulated into JSON format data.

[0024] Furthermore, the process of sending model requests, parsing and verifying model output results through existing API interfaces, mapping results that meet interface constraints and business stage requirements back to the target interface, and recording system status update information includes:

[0025] Based on the prompts from the AI ​​language model, a model request is sent to the AI ​​language model via an existing API interface to obtain the processing results returned by the model. The business intent judgment, operation suggestions, and timing judgment results in the model output are analyzed. The consistency of the model output information returned by the AI ​​language model is verified, and field results that meet the interface constraints and business stage requirements are selected. The verified results are mapped to the field write path of the target interface, and the existing API interface is called to complete the result write-back. By performing the write-back operation and recording the interface return results, the status update record of the information system is obtained and stored for continuous optimization of subsequent interface operation feature updates, business stage identification, and model interaction processes.

[0026] The technical solutions provided by the embodiments of the present invention may include the following beneficial effects:

[0027] This invention provides an AI large language model interaction method based on existing interfaces of information systems. The invention constructs an interface runtime feature set based on the actual runtime behavior of the interface, identifies the interface's business intent and functional granularity in runtime, and further combines interface context differences, field semantic structure, and business stage temporal relationships to refine the internal business structure of the interface, thereby avoiding semantic biases caused by relying solely on static interface definitions. By constructing action rule chains, identifying business breaks, and introducing temporal context constraints, this invention effectively deconstructs and reassembles complex interfaces at the business semantic level, generating structured inputs that more fully reflect complete, continuous, and consistent business stage information, thus improving the stability and consistency of the AI ​​large language model in business processing. This invention eliminates the need to rewrite interfaces or introduce additional adaptation layers, reducing system transformation costs and implementation risks, and improving the reliability, controllability, and scalability of human-machine collaborative processing in complex business scenarios. It is suitable for intelligent upgrades of information systems with complex interfaces and heavy historical system burdens. Attached Figure Description

[0028] Figure 1 This is a flowchart of an AI large language model interaction method based on existing interfaces of an information system, according to the present invention.

[0029] Figure 2 This is a schematic diagram of an AI large language model interaction method based on existing interfaces of information systems according to the present invention. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

[0031] like Figures 1-2 This embodiment of an AI large language model interaction method based on existing interfaces of information systems may specifically include:

[0032] Step S101: Based on the information system operation log and interface specification document, obtain the interface call sequence detail table, and construct the interface operation feature set by combining field read and write behavior scanning, field operation trajectory analysis and field data dependency relationship.

[0033] Based on the information system operation logs and interface specification documents, each running interface call path is parsed one by one, recording the timestamp, call order, request parameters, and return field groups. These are then grouped and sorted by interface identifier and transaction number to obtain an interface call sequence detail table containing action sequences and field mapping relationships. By scanning each field read / write behavior in each group of transactions in the interface call sequence detail table, the read, write, and update operation types of the fields are marked, and their frequency of occurrence is counted, generating field operation trajectories. The range of field value changes, value boundaries, and frequency of outliers in the trajectories are analyzed to determine the value range of each field in the target business scenario, thus defining the field operation range and corresponding boundary conditions. Based on the read / write order and mutual reference relationships of fields in the transaction, a data dependency description between fields is formed, resulting in an interface operation feature set containing the number of fields, the proportion of field read / write behaviors, the complexity of field dependency relationships, the position of fields in the transaction, and the transaction call length. This set is then stored in the interface operation monitoring database.

[0034] For example, in a company's customer management information system, the running interface API_A was analyzed using system operation logs and interface specification documents. Call records for this interface under three different transaction numbers were collected within one day. After analyzing each call path, it was found that in transaction number T101, the call timestamps for API_A were 10:05:12, 10:05:14, and 10:05:18, corresponding to the 1st, 2nd, and 3rd calls. The request parameters included two fields: customer number and operation type. The returned field group included customer status, verification result, and update time. In transaction number T102, the interface was called only once, with a timestamp of 11:32:07. The number of request parameter fields was 3, and the returned field group consisted of 2 fields. After grouping and sorting the above call records based on the interface identifier and transaction number, an interface call sequence detail table was formed, clearly recording the action sequence of the interface under different transactions and the mapping relationship between request fields and returned fields. Based on this, a field-by-field scan of the read and write behavior of each transaction in the interface call sequence details table was performed. It was found that the "Customer Status" field was read 3 times and updated 1 time in transaction T101, and read once without any write operation in transaction T102. The "Update Time" field only had one write operation in T101 and did not appear in T102. The "Validation Result" field only had read operations in both transactions. By statistically analyzing the above field operation behaviors, generating field operation trajectories, and further analyzing the range of field value changes, it was found that the value of the "Customer Status" field only changed between 0 and 2 during transaction execution, and no out-of-bounds or abnormal values ​​appeared. The "Update Time" field always conformed to the timestamp. The format requires that the frequency of outliers be 0, thus determining the value range and legal boundary conditions of the field in the target business scenario. Further, considering the actual read / write order of fields within a transaction and the reference relationships between fields (e.g., the read result of the validation result field directly affects whether the customer status field is updated), a description of the data dependencies between fields is constructed. This results in a set of interface operation characteristics, containing 4 fields, a read ratio of approximately 75% in field read / write behavior, a medium level of field dependency complexity, an average position of the interface in the transaction as the 2nd position, and a transaction call length of 3 calls. This set of interface operation characteristics is then uniformly stored in the interface operation monitoring database.

[0035] Step S102: Based on the interface operation feature data, identify the business intent category and functional granularity level corresponding to the interface, and combine the field dependency stability score and transaction-level action integrity score to filter candidate interfaces and generate an interface functional granularity identification table.

[0036] By utilizing an interface operation monitoring database, historical interface operation feature data is obtained, and the interface business intent type and functional granularity are labeled. A random forest algorithm is used for model training to construct a joint identification model for interface business intent and functional granularity. Business intents include business initiation, business verification, business processing, status update, and business confirmation. Functional granularity includes coarse-grained, medium-grained, and fine-grained granularity. Based on the real-time acquired interface operation feature data, the joint identification model identifies the corresponding business intent category and functional granularity level of the interface. The identified interface business intents are compared with the target business intent to evaluate the deviation of existing API interfaces from the target business intent's functional granularity. Combining field dependency stability scoring and transaction-level action integrity scoring, interfaces with granularity deviations within a preset range and meeting stability and integrity requirements are selected to generate a candidate interface list. An identifier mapping method is used to encode the structural parameters of the candidate interfaces into granularity identification tags, obtaining an interface functional granularity identification table. Based on the call position, interface combination relationship, and field read / write order differences of the same interface under different transaction numbers in the interface call sequence details table, we perform interface context feature extraction, consistency detection, and context sharding processing, and update the interface function granularity identification table.

[0037] For example, the interface operation monitoring database has long recorded historical interface operation characteristic data for the interface identified as API_B. This interface generated 120 valid call records in the past month. Operations personnel first manually or semi-automatically labeled the business scenario corresponding to each call based on this historical interface operation characteristic data. They found that 70 calls were mainly used to create production tasks, labeled as business initiation type; 30 calls were used to check the legality of production parameters, labeled as business verification type; and the remaining 20 calls were used to update the production status, labeled as status update type. Simultaneously, combining the number of interface fields, the field read / write ratio, and the transaction call length, the interface function granularity was labeled. The results showed that this interface exhibited fine-grained functions in business initiation scenarios and coarse-grained functions in status update scenarios. Business intentions included business initiation, business verification, business processing, status update, or business confirmation types, and function granularity included coarse, medium, and fine granularity. Based on the above-labeled historical interface operation characteristic data, a joint recognition model for interface business intention types and function granularity was constructed. During system operation, when a new call record for API_B was collected in real time, the interface's operational characteristics showed that this interface was the 3rd in the call path within the current transaction, with 2 preceding interfaces, 1 succeeding interface, and 9 fields. Write operations accounted for approximately 60% of the fields, and the transaction call length was 4 times. After inputting this real-time interface operational characteristic data into the joint recognition model, the model identified the current business intent category of this interface as business processing, with a medium granularity level. Since the system's current target business intent is set as business processing, further evaluation of the interface's functional granularity deviation under the target business intent revealed that the medium granularity deviates somewhat from the fine granularity commonly used in target business processing, but remains within acceptable limits. Subsequently, the interface was further screened by combining field dependency stability score and transaction-level action integrity score. The field dependency stability score was 0.75, indicating that the data dependencies between interface fields are relatively stable across different transactions. The transaction-level action integrity score was 0.8, indicating that the interface can complete a complete business action chain within a single transaction. Both scores were higher than the preset threshold of 0.6, therefore the interface was included in the candidate interface list. Using an identifier mapping method, the structural parameters of the interface, such as the number of fields, the field read / write ratio, and the transaction call length, were encoded into a granular identification tag and written into the interface function granularity identification table.Analysis of the API call sequence details revealed that API_B is located second in the call path in transaction T201, primarily handling parameter processing, while in transaction T245 it is located fifth, primarily handling status updates. Significant differences were found in the initial appearance position and write phase distribution of the fields between the two transactions. Based on these differences, the API context features were extracted, and consistency checks were performed between the business intent identification results and the functional granularity identification results. This revealed the API's business intent in different transactions. Figure 1 The consistency coefficient is 0.55, and the functional granularity stability coefficient is 0.5, both lower than the preset threshold of 0.6. Therefore, the interface is determined to have a business semantic drift risk and is marked as a context-sensitive interface. Finally, API_B is processed by context sharding according to the call path of different transactions. Its call instances in different transaction contexts such as T201 and T245 are recorded as different context interface units, and the original unified interface identifier is replaced by these context interface units to update the interface functional granularity identification table.

[0038] Specifically, based on the call position, interface combination relationship, and field read / write order differences of the same interface under different transaction numbers in the interface call sequence details table, interface context features are extracted, consistency detection is performed, and context sharding is processed, and the interface function granularity identification table is updated.

[0039] Based on the interface call sequence details table, a comparative analysis is performed on the call positions, interface combination relationships, and field read / write order of the same interface identifier under different transaction numbers. A set of contextual features of the interface in different transaction contexts is extracted. These contextual features include at least the interface's relative call position in the transaction, the number of preceding interfaces, the number of succeeding interfaces, the first appearance position of a field, and the stage distribution of the field's participation in write operations. Based on this set of contextual features, consistency checks are performed on the business intent identification results and functional granularity identification results of the interface in different transactions. The business intent of the interface under different transaction contexts is then calculated. Figure 1 Consistency coefficient and functional granularity stability coefficient. If the interface's business intent... Figure 1 If the consistency coefficient or functional granularity stability coefficient is lower than a preset threshold, the interface is determined to have a business semantic drift risk and is marked as a context-sensitive interface. Context-sensitive interfaces are processed by context sharding based on the transaction call path. Call instances of the same interface formed in different transaction contexts are treated as different context interface units, and their corresponding business intent category, functional granularity level, and field operation scope are recorded separately. The original interface identifier is replaced by the context interface unit, and the interface functional granularity identification table is updated.

[0040] For example, in a certain engineering management information system, there exists an existing interface identified as API_C. This interface is recorded in the system operation log under multiple different transaction numbers. Analysis of the interface call sequence details table reveals that in transaction number T001, API_C is located at the second position in the call path, with one preceding interface and three succeeding interfaces. The interface involves a total of eight fields, with the first appearance of these fields concentrated at the beginning of the transaction, and field write operations primarily occurring during the business processing phase. In transaction number T002, API_C is located at the fifth position in the call path, with four preceding interfaces and zero succeeding interfaces. The interface contains five fields, with the first appearance of these fields concentrated in the later part of the transaction, and field write operations primarily occurring during the status confirmation phase. Based on the context feature sets extracted from different transaction contexts, the business intent identification results of API_C in different transactions were compared. It was found that this interface was identified as a business processing interface in transaction T001, while it was identified as a state update interface in transaction T002, indicating a significant semantic difference between the two types of business intents. Furthermore, statistical analysis of the functional granularity identification results showed that API_C corresponds to a fine-grained function in transaction T001, while it corresponds to a coarse-grained function in transaction T002. For the same interface identifier A, a total of N call instances occurred in different transaction contexts. Among these N call instances, the business intent category with the most frequent occurrences was... Then business intention Figure 1 The consistency coefficient is defined as follows: This means that if an interface is mostly judged as having the same business intent across different transactions, then the consistency is high; if the various intents are scattered, the consistency is low. Further calculations reveal the consistency of the interface's business intent across different transactions. Figure 1 The consistency coefficient is 0.4. The functional granularity level of the same interface in the j-th call instance is denoted as... The frequency of the most frequent granularity level is recorded as follows: The functional granularity stability coefficient is defined as follows: The calculated functional granularity stability coefficient is 0.35, indicating a business intention... Figure 1Both the consistency coefficient and the functional granularity stability coefficient were below the preset threshold of 0.6, therefore API_C was determined to have a business semantic drift risk and was marked as a context-sensitive interface. Based on this, API_C underwent context fragmentation according to the transaction call path. Its call instance in transaction T001 was defined as a context interface unit API_C_C1, with its business intent category recorded as business processing, functional granularity level as fine-grained, and field operation range as 8 fields. Simultaneously, its call instance in transaction T002 was defined as another context interface unit API_C_C2, with its business intent category recorded as state update, functional granularity level as coarse-grained, and field operation range as 5 fields. Subsequently, API_C_C1 and API_C_C2 replaced the original unified interface identifier API_C, updating the interface functional granularity identification table, thus distinguishing and preserving the different business semantics and functional characteristics of the same interface in different transaction contexts.

[0041] Step S103: Based on the interface business intent category and function granularity level recorded in the interface function granularity identification table, divide the interface fields into field paragraphs, verify the field semantics, and mark the business functions, and construct an action rule chain.

[0042] Based on the interface business intent category and function granularity level recorded in the interface function granularity identification table, the field names, field function descriptions, and transaction numbers contained in the interface are read line by line, and fields with the same function granularity mark and appearing consecutively in the transaction are divided into the same field segment. By statistically analyzing the number of fields in each field segment, the order in which fields appear during transaction execution, and the participation of fields in read and write operations, the field segmentation results at the operation level of the interface are obtained. Combined with a preset field semantic reference table, the semantic meaning, naming rules, and corresponding business descriptions of the fields in each field segment are checked and analyzed. Under the constraints of the identified business intent category, the functional affiliation of the field segment in the interface business structure is determined, and the field segment is marked with a business function. The business function mark is used to represent whether the field segment corresponds to a single business function or a compound business function. Field segments with the same business function mark are organized, and the necessary fields, optional fields, and prerequisite fields required to complete the business function are extracted. Multiple business actions are associated to construct an action rule chain according to the business execution order, and the corresponding interface identifier, field information, and execution order are recorded. Based on the established action rule chain, combined with the sequential relationship of field segments in the business execution process and business function markers, business breakage is determined for adjacent field segments, and high breakage chains are identified based on the field segment business breakage index.

[0043] For example, the interface function granularity identification table records the interface with the identifier API_D. Its business intent category is identified as a business processing class, and its function granularity level is medium granularity. Based on this identification table, the complete execution process of this interface in transaction number T305 is analyzed. By reading the field names and field function descriptions contained in the interface line by line, it is found that the interface involves a total of 9 fields in this transaction, arranged in the order in which the fields actually appear in the transaction. Among them, the first 3 fields appear consecutively at the beginning of the transaction and have the same function granularity mark. They are all used for order validity verification and are therefore divided into the same field segment. The next 4 fields mainly participate in order amount calculation and inventory deduction operations. They also appear consecutively in the transaction and have the same function granularity mark and are divided into the second field segment. The last 2 fields appear consecutively at the end of the transaction and are used to update the order status and record the completion time. They are divided into the third field segment. After dividing the fields into segments, the number of fields in each segment and the read / write operations performed on each field were further analyzed. It was found that the first segment contained three fields, all of which underwent only read operations; the second segment contained four fields, three of which underwent write operations; and the third segment contained two fields, both of which underwent state update write operations. Using a pre-defined field semantic mapping table, the semantic meaning and business description of the fields in each segment were verified and analyzed. Under the constraint of business processing intent, the function of the first segment was determined to be a business verification function, the function of the second segment to be a core business processing function, and the function of the third segment to be a state update function. These were then labeled with their corresponding business functions: the second segment was labeled as a single business function, and the other two segments were labeled as auxiliary business functions. Based on this, field segments with the same business function tags are organized. For core business processing function field segments, two required fields, one optional field, and one prerequisite field are extracted to complete the business function. Combining the execution relationship between preceding and following field segments, the business verification function, core business processing function, and status update function are sequentially associated according to the business execution order of order processing, forming a complete action rule chain. The interface identifier, field information, and field execution order corresponding to this action rule chain are recorded. Based on the constructed action rule chain, combined with the sequential relationship of field segments in the transaction execution process and the business function tags, business breakage judgment is performed on adjacent field segments. It is found that the business function tag changes when switching from the business verification function field segment to the core business processing function field segment, and changes again when switching from the core business processing function to the status update function. There are a total of 2 business breaks in this action rule chain. Since there are a total of 2 pairs of adjacent field segments in this action rule chain, the final calculated field segment business breakage index is 1.0.When the system's preset breakage index threshold is 0.6, the action rule chain is identified as a high-breakage chain because the breakage index of the field segment business in this action rule chain is higher than the preset threshold.

[0044] Specifically, based on the established action rule chain, combined with the sequential relationship of field segments in the business execution process and business function markers, business breakage determination is performed on adjacent field segments, and high breakage chains are identified based on the field segment business breakage index.

[0045] Based on the constructed action rule chain, the field segment sequence is extracted according to the business execution order, and the business function tag corresponding to each field segment is read. The business function tags of adjacent field segments are compared one by one; when the business function tags corresponding to adjacent field segments are inconsistent, a business break is determined to have occurred at that position. Based on the number of business breaks occurring in the action rule chain and the total number of adjacent field segment pairs, a field segment business break index formula is used. Calculate the Business Breakdown Index (BFI) for the field paragraph, where... This represents the i-th field segment in the action rule chain, arranged in execution order. This is a sequence formed by arranging the field paragraphs in the actual execution order, with each field paragraph... It has been marked as a certain business function type , This indicates whether adjacent field segments belong to the same business continuum. n is the number of field segments in the action rule chain, and n-1 is the number of adjacent field segment pairs in the action rule chain. The field segment business break index (BFI) is used to represent the continuity of the action rule chain at the business function level. If the field segment business break index is higher than the preset index threshold, it is determined that the current action rule chain has a risk of breakage at the business semantic level, and the action rule chain is marked as a high-break chain.

[0046] For example, for a completed action rule chain, five field segments are obtained sequentially according to the actual execution order of the business, denoted as P1, P2, P3, P4, and P5. Field segments P1 and P2 are marked as business verification (the same business function type), field segment P3 is marked as business processing, and field segments P4 and P5 are marked as state updates. When analyzing this action rule chain, the business function markings of adjacent field segments are compared sequentially. P1 and P2 have the same business function marking, indicating they belong to the same business continuum and there is no business break. P2 and P3 have different business function markings, indicating a business break occurs at the point of switching from business verification to business processing. P3 and P4 have different business function markings, indicating another business break occurs at the point of switching from business processing to state update. P4 and P5 have the same business function marking, belonging to the same business continuum and there is no business break. Therefore, in this action rule chain, there are a total of four pairs of adjacent field segments, with two instances of business breakage. According to the formula for calculating the Business Breakage Index (BFI) of field segments... The Business Breakage Index (BFI) for the field segment of this action rule chain is 0.5. The field segments in the action rule chain, in execution order, are... Each field paragraph It has been marked as a certain business function type , The Business Fragment Index (BFI) indicates whether adjacent field segments belong to the same business continuum. It is used to represent the continuity of the action rule chain at the business function level. If the preset index threshold is 0.4, then since the BFI of this action rule chain is 0.5, which is higher than the preset threshold, it can be determined that this action rule chain has a significant risk of fragmentation at the business semantic level. Therefore, this action rule chain is marked as a high-fragmentation chain and used for business reorganization processing in the subsequent prompt word generation stage.

[0047] Step S104: Obtain system operation status trajectory fragments through information system operation logs, mark business stages and generate time sequence context information, combine field time sequence identifiers, stage identifiers and trigger point identifiers to perform field consistency calibration, and form standardized intermediate JSON data.

[0048] By analyzing the information system's operation logs, fragments of the system's operational status trajectory are obtained. These trajectories are divided into multiple time periods based on chronological order, describing the business execution process comprised of multiple business actions. State temporal features are extracted within each time period, and different business stages are labeled. A decision tree algorithm is used for model training to construct a business stage temporal recognition model, predicting the current business stage of the system. State temporal features include the order of state changes, trigger event types, and field change patterns. By comparing the changes in field values ​​and states in adjacent time periods, the differences between the current state and subsequent stage states are determined, generating temporal context information reflecting the business stage's location. Based on this temporal context information, corresponding temporal identifiers, stage identifiers, and trigger point identifiers are appended to relevant fields in the script execution environment. Consistency checks are performed on the field information after appending identifiers, and field identifiers under different dimensions are synchronously calibrated. It is determined whether there are value jumps or inconsistencies in order during the business stage transition. For fields with temporal deviations, correction processing is performed based on the field's position in the operation chain, resulting in standardized intermediate JSON data.

[0049] For example, the system operation status trajectory corresponding to a complete business execution process is extracted from the information system operation log. This status trajectory covers the time period from 09:00:00 to 09:05:00, lasting 300 seconds. According to the time sequence, this status trajectory is divided into three consecutive time periods: the first time period is from 09:00:00 to 09:01:30, which mainly corresponds to the task initialization process; the second time period is from 09:01:30 to 09:03:30, which mainly corresponds to the core business processing process; and the third time period is from 09:03:30 to 09:05:00, which mainly corresponds to the result confirmation and status write-back process. After extracting the state sequence features for each time period, it was found that in the first time period, the system status changed from idle to task received, triggered by task creation, with the main field change pattern being adding fields. In the second time period, the system status sequentially went through processing and processing completed, triggered by parameter validation passed and processing completed, with multiple business field values ​​being updated. In the third time period, the system status changed from processing completed to confirmed, triggered by result confirmation, with the main field change pattern being status field writing. Based on the above-labeled time periods and their state sequence features, a decision tree algorithm was used to train the model. After training on historical log data, a business stage time sequence recognition model was constructed to predict the current business stage of the system. The state sequence features include the order of state changes, the type of triggered event, and the field change pattern. When the system was running in real time at 09:02:10, the model predicted that the system was in the second business stage, i.e., the core business processing stage, based on the current order of state changes and the type of triggered event. Further comparison of field values ​​and status changes in adjacent time periods revealed that, compared to the first time period, the field processing result code changed from null to 1 in the second time period, and the field processing progress increased from 0% to 80%, indicating that the business had entered the substantive processing stage. However, compared to the subsequent third time period, the field confirmation flag remained at 0 in the current time period, indicating that no status confirmation operation had occurred. Based on these differences, temporal context information reflecting the current business stage position was generated, clarifying that the current stage is located in the middle of the business execution process. In the script execution environment, based on the temporal context information, a temporal flag T2, a stage flag Stage_Process, and a trigger point flag Event_Complete_80% were appended to the field processing progress, and a pending trigger status flag Stage_Confirm was appended to the field confirmation flag. A consistency check of the field information after appending flags revealed that the field confirmation flag unexpectedly jumped from 0 to 1 once in the second business stage. This change occurred earlier in time than the expected confirmation trigger event and was inconsistent with the field's position in the operation chain.To address this timing discrepancy, the field's value order was corrected by considering its position in the last business action within the action rule chain, adjusting the effective write time of this field to the time period corresponding to the third business stage. Finally, the corrected field information, along with its corresponding timing identifier, stage identifier, and trigger point identifier, were unified to generate standardized intermediate JSON data with consistent structure and correct timing, for subsequent interaction with the AI ​​large language model.

[0050] Step S105: Based on the business meaning of the fields, interface operation characteristics, and time sequence information in the standardized intermediate JSON data, generate prompt words that include field operation descriptions, business semantic descriptions, and time sequence background descriptions.

[0051] Based on standardized intermediate JSON data, the business meaning, interface operation characteristics, and timing information corresponding to the fields are read. The system then determines whether the current field originates from an action rule chain marked as having a high breakage. If a field originates from a high breakage chain, it is grouped according to the business function markers of the field segments. Segments belonging to the same business function are semantically merged, or the presentation order of the fields in the prompts is continuously rearranged without changing the actual execution order of the fields. Based on the semantically merged and continuously rearranged field set, combined with the field's operation method in the interface, its semantic meaning in the business, and its stage in the business process, the field name and field value are expanded to form a field description that includes field operation instructions, business semantic descriptions, and timing background information. This description serves as the prompt content for the AI ​​large language model, and the prompt content of the AI ​​large language model, along with the corresponding field values, is encapsulated into JSON format data.

[0052] For example, after preliminary processing, a standardized intermediate JSON data has been generated. This JSON data records the business execution result of interface API_E in transaction number T801, containing six fields: order number, verification identifier, approval result, approval opinion, status code, and update time. When reading this standardized intermediate JSON data, the business meaning, interface operation characteristics, and time sequence information corresponding to each field are first parsed. For example, the order number and verification identifier correspond to the business initiation stage, the approval result and approval opinion correspond to the business processing stage, and the status code and update time correspond to the status update stage. Simultaneously, based on the action rule chain identifier carried in the fields, the action rule chain corresponding to this interface has been marked as a high-fragment chain in the preliminary analysis. This is because fields of the same approval business are split in the rule chain and mixed with status update fields, resulting in a risk of semantic breakage. After confirming that the fields come from a high-fragment chain, the fields are further grouped according to the business function markings of the field segments, and the segment marked as having approval processing business function is semantically merged. Specifically, the previously scattered field approval results and approval opinions are identified as the same business function unit and merged into a continuous approval processing description in the prompt. While the field status code and update time follow closely in the actual transaction execution, because their business function is marked as a status update and they are not essential fields for approval processing, they are continuously rearranged after the approval processing description without changing the actual execution order of the fields. After semantic merging and continuous rearrangement, the field names and values ​​are expanded based on the reorganized field set. For example, for the approval result field, considering its interface operation method (write operation), business semantics (approval conclusion), and business process stage (processing stage), an operation description and semantic description are generated that includes the final judgment result of the order approval, the operation description written by the system during the approval processing stage, and for the status code field, a temporal background description is added to indicate the completion status of the business during the status update stage. Finally, the expanded field descriptions are used as the prompt text and encapsulated together with the corresponding field values, such as approval result "passed" and status code "200," into JSON format data.

[0053] Step S106: Send model requests, parse and verify model output results through existing API interfaces, map results that meet interface constraints and business stage requirements back to the target interface, and record system status update information.

[0054] Based on the prompts from the AI ​​language model, a model request is sent to the AI ​​language model via an existing API interface to obtain the processing results returned by the model. The business intent judgment, operation suggestions, and timing judgment results in the model output are analyzed. The consistency of the model output information returned by the AI ​​language model is verified, and field results that meet the interface constraints and business stage requirements are selected. The verified results are mapped to the field write path of the target interface, and the existing API interface is called to complete the result write-back. By performing the write-back operation and recording the interface return results, the status update record of the information system is obtained and stored for continuous optimization of subsequent interface operation feature updates, business stage identification, and model interaction processes.

[0055] For example, the preceding steps have generated a set of prompt words and corresponding JSON data for interaction with the AI ​​large language model. The JSON data contains four key fields: contract number, approval status, approval opinion, and effective identifier, with corresponding field values ​​of HT2023-015, pending approval, none, and 0, respectively. Based on this prompt word content, a model request is sent to the AI ​​large language model through the existing model call API interface. The preset prompt words explicitly state that the contract number field is used to uniquely identify the business object, the approval status field reflects the current business stage of the contract, the approval opinion field records the approval conclusion, and the effective identifier field indicates whether the contract meets the conditions for effectiveness. Furthermore, the model is required to determine whether the approval status can be updated to "approved" at the current business stage and whether the effective identifier field should be modified simultaneously. After receiving the model request information, the AI ​​large language model analyzes the JSON data based on the business semantic description, field rule description, and processing instructions provided in the prompts, and returns a set of processing results. It explicitly determines that the current contract meets the approval conditions, identifies the business intent as business confirmation, and suggests updating the approval status field from "pending approval" to "approved" and the effectiveness flag field from 0 to 1. The timing analysis indicates that this operation should occur during the approval confirmation stage, not the contract initiation stage. After parsing the model output, a consistency check is performed on the returned field results, confirming that the updated approval status and effectiveness flag both comply with the interface constraints and are consistent with the current business stage requirements, without any unauthorized updates or stage misalignment issues. Subsequently, the validated field results are mapped according to the existing API interface's field write path, and the result is written back by calling the original contract approval interface. The interface returns a successful write result with a 200 status code. Based on this, a new status update record is generated, including the contract number HT2023-015, the approval status changed from "pending approval" to "approved," the effectiveness flag changed from 0 to 1, and the corresponding update timestamp. This status update record is stored in the system database for subsequent incremental updates to the interface's operational characteristics, corrections to the accuracy of business stage identification, and continuous optimization of prompts and processing logic during subsequent interactions with the AI ​​large language model.

[0056] The above description is merely a preferred embodiment of this application and an explanation of the technical principles employed. Those skilled in the art should understand that the scope of the invention involved in this application is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the concept of this application. For example, technical solutions formed by substituting the above features with (but not limited to) technical features with similar functions disclosed in this application.

Claims

1. An AI large language model interaction method based on an existing interface of an information system, characterized in that, The method includes: Based on the information system operation logs and interface specification documents, obtain the interface call sequence details table, and construct the interface operation feature set by combining field read and write behavior scanning, field operation trajectory analysis and field data dependency relationship. Based on the interface operation characteristic data, identify the business intent category and functional granularity level corresponding to the interface, and combine the field dependency stability score and transaction-level action integrity score to filter candidate interfaces and generate an interface functional granularity identification table. Based on the interface business intent category and function granularity level recorded in the interface function granularity identification table, the interface fields are divided into field paragraphs, the field semantics are checked, and the business function is marked, and an action rule chain is constructed. By obtaining system operation status trajectory fragments from information system operation logs, business stages are marked and time-series context information is generated. Field consistency calibration is performed by combining field time sequence identifiers, stage identifiers and trigger point identifiers to form standardized intermediate JSON data. Based on the business meaning of the fields in the standardized intermediate JSON data, the characteristics of interface operations, and the time sequence stage information, generate prompt words that include field operation descriptions, business semantic descriptions, and time sequence background descriptions; The system sends model requests, parses and verifies model output results using existing API interfaces, maps results that meet interface constraints and business stage requirements back to the target interface, and records system status update information.

2. The method according to claim 1, wherein, The step involves obtaining a detailed table of interface call sequences based on the information system's operation logs and interface specification documents. This table is then used to construct an interface operation feature set by combining field read / write behavior scanning, field operation trajectory analysis, and field data dependencies. This includes: Based on the information system operation logs and interface specification documents, each running interface call path is parsed one by one, recording the timestamp, call order, request parameters, and return field groups. These are then grouped and sorted according to interface identifier and transaction number to obtain an interface call sequence detail table containing action sequences and field mapping relationships. By scanning each field read / write behavior of each group of transactions in the interface call sequence detail table, the read, write, and update operation types of the fields are marked and their frequency is counted, generating field operation trajectories. The range of field value changes, value boundaries, and frequency of outliers in the trajectories are analyzed to determine the value range of each field in the target business scenario, thus determining the field operation range and corresponding boundary conditions. Based on the read / write order and mutual reference relationships of fields in the transaction, a data dependency description between fields is formed, resulting in an interface operation feature set containing the number of fields, the proportion of field read / write behaviors, the complexity of field dependency relationships, the position of fields in the transaction, and the transaction call length. This set is then stored in the interface operation monitoring database.

3. The method according to claim 1, wherein, The process involves identifying the business intent category and functional granularity level corresponding to the interface based on the interface's operational characteristic data, and then filtering candidate interfaces by combining field dependency stability scores and transaction-level action integrity scores, and generating an interface functional granularity identification table, including: By utilizing an interface operation monitoring database, historical interface operation feature data is obtained, and the interface business intent type and functional granularity are labeled. A random forest algorithm is used for model training to construct a joint identification model for interface business intent and functional granularity. Business intents include business initiation, business verification, business processing, status update, and business confirmation, while functional granularity includes coarse, medium, and fine granularity. Based on the real-time acquired interface operation feature data, the joint identification model identifies the corresponding business intent category and functional granularity level of the interface. The identified interface business intents are compared with the target business intents for evaluation. Estimate the functional granularity deviation of existing API interfaces under the target business intent; combine field dependency stability score and transaction-level action integrity score to filter out interfaces whose granularity deviation is within the preset range and meets the stability and integrity requirements, and generate a candidate interface list; use identifier mapping to encode the structural parameters of the candidate interfaces into granularity identification tags to obtain the interface functional granularity identification table; based on the call position of the same interface under different transaction numbers, interface combination relationship and field read / write order differences of the interface call sequence details table, perform interface context feature extraction, consistency detection and context sharding processing, and update the interface functional granularity identification table.

4. The method according to claim 3, wherein, The process involves extracting interface context features, performing consistency checks, and handling context sharding based on the call positions, interface combination relationships, and differences in field read / write order of the same interface under different transaction numbers in the interface call sequence details table, and updating the interface function granularity identification table. This includes: Based on the interface call sequence details table, a comparative analysis is performed on the call positions, interface combination relationships, and field read / write order of the same interface identifier under different transaction numbers. A context feature set of the interface in different transaction contexts is extracted. This context feature set includes at least the interface's relative call position in the transaction, the number of preceding interfaces, the number of succeeding interfaces, the first appearance position of the field, and the stage distribution of the field's participation in write operations. Based on the context feature set, consistency detection is performed on the business intent identification results and functional granularity identification results of the interface in different transactions. The business intent consistency coefficient and functional granularity stability coefficient of the interface under different transaction contexts are calculated. If the business intent consistency coefficient or functional granularity stability coefficient of the interface is lower than a preset threshold, the interface is determined to have a business semantic drift risk and is marked as a context-sensitive interface. Context-sensitive interfaces are processed by context sharding according to the transaction call path. Call instances of the same interface formed in different transaction contexts are regarded as different context interface units, and their corresponding business intent categories, functional granularity levels, and field operation ranges are recorded respectively. The context interface units replace the original interface identifiers, and the interface functional granularity identification table is updated.

5. The method according to claim 1, wherein, The process involves dividing interface fields into paragraphs, verifying field semantics, and marking business functions based on the interface business intent category and function granularity level recorded in the interface function granularity identification table, and constructing an action rule chain, including: Based on the interface business intent category and function granularity level recorded in the interface function granularity identification table, the field names, field function descriptions, and transaction numbers contained in the interface are read line by line. Fields with the same function granularity marker and appearing consecutively in a transaction are grouped into the same field segment. By statistically analyzing the number of fields in each field segment, the order in which fields appear during transaction execution, and the participation of fields in read and write operations, the field segmentation results at the operation level of the interface are obtained. Combined with a pre-set field semantic reference table, the semantic meaning, naming rules, and corresponding business descriptions of the fields in each field segment are checked and analyzed. Under the constraint of the identified business intent category, the field segment in the interface is determined. The functional attribution relationships in the business structure are identified, and field segments are marked with business functions. These business function marks are used to characterize whether a field segment corresponds to a single or multiple business functions. Field segments with the same business function mark are organized, and the necessary, optional, and prerequisite fields required to complete the business function are extracted. Multiple business actions are associated and constructed into an action rule chain according to the business execution order, and the corresponding interface identifiers, field information, and execution order are recorded. Based on the constructed action rule chain, combined with the sequential relationship of field segments in the business execution process and the business function mark, business breakage is determined for adjacent field segments, and high-breakage chains are identified based on the field segment business breakage index.

6. The method according to claim 5, wherein, The process involves determining business breakage between adjacent field segments based on the constructed action rule chain, combined with the sequential relationship of field segments during business execution and business function markers. Furthermore, it identifies high-breakage chains based on the field segment business breakage index, including: Based on the constructed action rule chain, the field segment sequence is extracted according to the business execution order, and the business function tag corresponding to each field segment is read. The business function tags of adjacent field segments are compared one by one. When the business function tags corresponding to adjacent field segments are inconsistent, a business break is determined to have occurred at the corresponding position. Based on the number of business breaks in the action rule chain and the total number of adjacent field segment pairs, the field segment business break index formula is used. Calculate the Business Breakdown Index (BFI) for the field paragraph, where... This represents the i-th field segment in the action rule chain, arranged in execution order. This is a sequence formed by arranging the field paragraphs in the actual execution order, with each field paragraph... It has been marked as a certain business function type , This indicates whether adjacent field segments belong to the same business continuum. n is the number of field segments in the action rule chain, and n-1 is the number of adjacent field segment pairs in the action rule chain. The field segment business break index (BFI) is used to represent the continuity of the action rule chain at the business function level. If the field segment business break index is higher than the preset index threshold, it is determined that the current action rule chain has a risk of breakage at the business semantic level, and the action rule chain is marked as a high-break chain.

7. The method according to claim 1, wherein, The process involves obtaining system operation status trajectory fragments from information system operation logs, marking business stages and generating time-series context information, and performing field consistency calibration by combining field time-series identifiers, stage identifiers, and trigger point identifiers to form standardized intermediate JSON data, including: By analyzing the information system's operation logs, system operation status trajectory fragments are obtained. These fragments are then divided into multiple time periods based on chronological order. Each status trajectory fragment describes a business execution process comprised of multiple business actions. By extracting state temporal features within each time period and labeling different business stages, a decision tree algorithm is used for model training to construct a business stage temporal recognition model. This model predicts the current business stage the system is in. State temporal features include the order of state changes, trigger event types, and field change patterns. By comparing the changes in field values ​​and states in adjacent time periods, the differences between the current state and subsequent stage states are determined, generating temporal context information reflecting the business stage's location. Based on this temporal context information, corresponding temporal identifiers, stage identifiers, and trigger point identifiers are appended to relevant fields in the script execution environment. Consistency checks are performed on the field information after appending identifiers, and field identifiers under different dimensions are synchronously calibrated. It is also determined whether there are value jumps or inconsistencies in order during business stage transitions. For fields with temporal deviations, correction processing is performed based on the field's position in the operation chain to obtain standardized intermediate JSON data.

8. The method according to claim 1, wherein, The process of generating prompts containing field operation descriptions, business semantic descriptions, and time sequence background information based on the business meanings of fields in standardized intermediate JSON data includes: Based on standardized intermediate JSON data, the business meaning, interface operation characteristics, and timing information corresponding to the fields are read. The system then determines whether the current field originates from an action rule chain marked as having a high breakage. If the field originates from a high breakage chain, it groups the fields according to their business function tags, semantically merging field segments belonging to the same business function, or continuously rearranging the presentation order of the fields in the prompts without changing the actual execution order. Based on the semantically merged and continuously rearranged field set, combined with the field's operation method in the interface, its semantic meaning in the business, and its stage in the business process, the field name and value are extended to form a field description containing field operation instructions, business semantic descriptions, and timing background information. This description serves as the prompt content for the AI ​​large language model, and the prompt content of the AI ​​large language model, along with the corresponding field values, is encapsulated into JSON format data.

9. The method according to claim 1, wherein, The process of sending model requests, parsing and verifying model output results through existing API interfaces, mapping results that meet interface constraints and business stage requirements back to the target interface, and recording system status update information includes: Based on the prompts from the AI ​​language model, a model request is sent to the AI ​​language model via an existing API interface to obtain the processing results returned by the model. The business intent judgment, operation suggestions, and timing judgment results in the model output are then parsed. Consistency verification is performed on the model output information returned by the AI ​​language model to filter field results that meet the interface constraints and business stage requirements. The verified results are mapped to the field write path of the target interface, and the existing API interface is called to complete the result write-back. By performing the write-back operation and recording the interface return results, the status update record of the information system is obtained and stored for continuous optimization of subsequent interface operation feature updates, business stage identification, and model interaction processes.

Images