Data processing method and electronic equipment

Abstract

The invention provides a data processing method and electronic equipment. The method comprises the following steps: in response to target input data for a current initial object, generating target variable data based on the target input data; generating target update data based on the target variable data and the target knowledge base, wherein the target update data can be used for updating the target object; wherein the target object comprises a current initial object and / or a target associated object thereof, and the target object can be used for providing a target function service; the target knowledge base is used for describing core elements required for realizing the target function service.

Description

Technical Field

[0001] This application relates to, but is not limited to, the field of electronic technology, and in particular to a data processing method and an electronic device. Background Technology

[0002] In related technologies, the business development process for updating functional services may suffer from problems such as untimely, incomplete, or out-of-synchronization data updates, resulting in low development efficiency and high maintenance costs for functional services. Summary of the Invention

[0003] In view of this, embodiments of this application provide at least one data processing method and one electronic device.

[0004] The technical solution of this application embodiment is implemented as follows: This application provides a data processing method, including: in response to obtaining target input data for a current initial object, generating target variable data based on the target input data; generating target update data based on the target variable data and a target knowledge base, wherein the target update data can be used to update the target object; wherein the target object includes the current initial object and / or its target associated objects, and the target object can be used to provide target functional services; the target knowledge base is used to describe the core elements required to implement the target functional services.

[0005] This application provides an electronic device, including at least one processor and at least one processing model capable of running on the at least one processor. The processing model can be invoked to perform the following operations: in response to obtaining target input data for a current initial object, generating target variable data based on the target input data; generating target update data based on the target variable data and a target knowledge base, wherein the target update data can be used to update the target object; wherein the target object includes the current initial object and / or its target associated objects, and the target object can be used to provide target functional services; the target knowledge base is used to describe the core elements required to implement the target functional services.

[0006] It should be understood that the above general description and the following detailed description are merely exemplary and explanatory, and are not intended to limit the technical solutions of this application. Attached Figure Description

[0007] Figure 1 This is a schematic diagram illustrating the implementation flow of a data processing method provided in an embodiment of this application; Figure 2 This is a schematic diagram of a forward flow from a user's perspective, provided in an embodiment of this application. Figure 3 This is a schematic diagram of a forward process from a device perspective provided in an embodiment of this application; Figure 4This is a reverse process diagram from a user's perspective provided in an embodiment of this application; Figure 5 This is a schematic diagram of a reverse process from a device perspective provided in an embodiment of this application; Figure 6 This is a schematic diagram illustrating the implementation process of a synchronization consistency guarantee method based on API graphs provided in an embodiment of this application; Figure 7 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0008] It should be noted that the terms "first" and "second" mentioned above are only used to distinguish between different options and do not represent the degree of superiority or inferiority of the options or their priority in the implementation process. Detailed Implementation

[0009] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0010] In the following description, the terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of the objects. It is understood that "first / second / third" can be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein. Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application. It should also be noted that, for ease of description, only the parts relevant to the application are shown in the accompanying drawings.

[0011] This application provides a data processing method that can be executed by an electronic device. The electronic device refers to a server, laptop computer, tablet computer, desktop computer, smart TV, set-top box, mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or any other device with data processing capabilities. Figure 1 As shown, the method includes the following steps S101 to S102: Step S101: In response to obtaining target input data for the current initial object, generate target variable data based on the target input data.

[0012] Here, the current initial object is an object related to the application business. For example, the current initial object may include, but is not limited to, at least one of the following: technical development documents, software code, software applications, firmware, functional services, etc.

[0013] Target input data refers to the input information provided by the user or system for the current initial object. It represents the need to add or modify the current initial object and serves as the basis for generating target variable data and performing subsequent update operations. In implementation, the data type of target input data can include, but is not limited to, at least one of document types, natural language, and code files. For example, users can input target input data through a front-end interface, voice input, or other methods.

[0014] Target variable data is intermediate data generated after parsing, validating, and / or comparing the target input data. It is used to reflect semantic changes or business logic changes corresponding to the target input data.

[0015] For example, if the initial object is a software application, the corresponding target input data may include the updated configuration file of the software application's Application Programming Interface (API), where the configuration file represents the update of the configuration variables of the software application's API. Furthermore, the corresponding API contract increment, i.e., the target variable data, can be generated based on the updated configuration file.

[0016] For example, when the initial object is software code and / or technical development documentation, the corresponding target input data may include commands and / or content for modifying the software code and / or technical development documentation. For instance, the target input data may be the modified software code; further, corresponding code variables may be generated based on the modified software code as target variable data. As another example, the target input data may be an instruction to update the technical development documentation; further, corresponding document variables may be generated in response to this instruction as target variable data.

[0017] For example, if the initial object is an intelligent agent (such as an automated system, robot, virtual assistant, and game character), the target input data may include a requirements document or workflow creation data instructing the creation of the intelligent agent. Furthermore, based on the corresponding requirements document, the API contract and / or code framework corresponding to the intelligent agent can be added as target variable data.

[0018] For example, when the initial object is a functional service provided by the application, the corresponding target input data may include natural language requirements representing additions or adjustments to that functional service. Furthermore, based on semantic information extracted from the natural language requirements, the functional service modules corresponding to that functional service can be added or adjusted as target variable data.

[0019] Step S102: Generate target update data based on target variable data and target knowledge base. The target update data can be used to update target objects. The target objects include the current initial object and / or its target associated objects. The target objects can be used to provide target functional services. The target knowledge base is used to describe the core elements required to implement the target functional services.

[0020] Here, the target knowledge base is a set of rules associated with the target object, used to describe the core elements required to provide target functional services for the target object. This enables different types of changes (such as requirement changes, code modifications, and document updates) to be coordinated and mapped under the same knowledge system, thereby improving the consistency and integrity of updated data.

[0021] In some implementations, the target knowledge base may include the API graph of the current initial object, or other types of knowledge graphs. For example, if the current initial object is an application or an artificial intelligence (AI) assistant, the target knowledge base may include a functional configuration graph corresponding to the application or AI assistant, or a device configuration graph of the electronic device running the application or AI assistant.

[0022] In some implementations, the target knowledge base may further include semi-structured data and / or unstructured data (documents, manuals, rule texts) used to describe standard configuration parameters and / or standard variables required to describe preset or specific functional services (including target functional services). For example, the target knowledge base may include semi-structured data of Extensible Markup Language (XML) type and / or JavaScript Object Notation (JSON) type. Furthermore, the target knowledge base may include documents (such as code documents, technical development documents, etc.), manuals (such as API reference manuals), and rule texts (such as code and / or requirement annotation texts).

[0023] When the target object includes program files, such as at least one of an application, agent, firmware, or driver, the corresponding target function service can be provided by directly running the target object.

[0024] If the target object includes non-program files, such as technical documents, code files, model files, etc., then corresponding conversion or provision of corresponding target functional services in the target runtime environment is required. For example, technical documents can be converted into code files and run in a specific runtime environment to provide corresponding functional services.

[0025] Core elements can be understood as the software or hardware resources required to implement functional services. For example, core elements may include at least one of the following: API interfaces or business endpoints required to implement functional services, parameter values ​​of API interfaces or business endpoints, and relationships between business endpoints. Alternatively, core elements may include, but are not limited to, at least one of the following: hardware resources required for functional services, driver resources, architectural relationships between hardware drivers, calling relationships, and interface relationships.

[0026] The target update data is generated by combining the target variable data and the target knowledge base, and is used to update the current initial object and / or its target-related objects. Target-related objects are other objects that have dependencies on the current initial object.

[0027] In some implementations, the target update data may be a patch file used to update the target object. In practice, depending on the type of target object to be updated, the target update data may include, but is not limited to, at least one of API contract patches, code skeleton patches, test cases, initial documentation patches, etc. For example, when updating the target object to represent a code change, the target update data may include a code incremental patch. Similarly, when updating the target object to represent a document change, the target update data may include a document incremental patch.

[0028] In some implementations, updating the target object may include updating only the current initial object or the target associated object; it may also include updating the current initial object and the target associated object simultaneously, that is, updating the current initial object itself while also updating the corresponding associated object.

[0029] For example, if the current initial object includes a technical document, the technical document can be updated using target update data of the corresponding type, or the code file corresponding to the technical document can be updated; alternatively, the corresponding code file can be updated synchronously when updating the technical document.

[0030] For example, if the current initial object includes a code file, the code file can be updated using target update data of the corresponding type, or the technical documentation, application, and / or test cases corresponding to the code file can be updated; the corresponding technical documentation, application, and / or test cases can also be updated synchronously when updating the code file.

[0031] For example, if the current initial object includes an agent, the agent can be updated using target update data of the corresponding type, or the code file corresponding to the agent can be updated; the corresponding code file can also be updated synchronously when updating the agent.

[0032] For example, if the current initial object includes an application, the application can be updated using target update data of the corresponding type, or the code file corresponding to the application can be updated; the corresponding code file can also be updated synchronously when updating the application.

[0033] In some implementations, target update data can be generated based on the relationship between target variable data and the target knowledge base. For example, corresponding target update data can be generated based on the correspondence or transformation relationship between API contract variables and code files and / or technical documents. Alternatively, target variable data can be updated in the API graph first, and the correspondence between the API graph and code files or technical documents can be used to generate update patches.

[0034] In this embodiment, in response to obtaining target input data for the current initial object, target variable data is generated based on the target input data. Furthermore, target update data is generated by combining the target knowledge base, and the target object used to provide target functional services is updated using the target update data. In this way, on the one hand, the target object can be automatically updated in response to the target input data, thereby improving the timeliness and accuracy of updating (modifying or adding) the target functional services; on the other hand, based on the target knowledge base that can describe the core elements required to implement the target functional services, the adaptability of the target update data to the target object can be improved, thereby improving the accuracy of updating the target object.

[0035] Understandably, by introducing a target knowledge base as a semantic hub, it is possible to achieve multi-directional closed-loop management of requirements, code, and / or documents during the business development process, thereby improving development efficiency while reducing subsequent maintenance costs.

[0036] In some embodiments, step S101 may include step S111 or step S112: Step S111: In response to obtaining target input data for the current initial object, obtain attribute information of the current initial object or target input data.

[0037] Here, attribute information can be information used to characterize the object type of the current initial object or the data type of the target input data. It is understandable that by extracting attribute information from the current initial object or target input data, subsequent processing strategies can more accurately match the needs of the current business scenario.

[0038] For example, by analyzing the data format or content of the acquired target input data, it can be determined whether the target input data is at least one of the following: natural language, code data, other unstructured data (such as graphic data, workflow data, voice data, etc.).

[0039] For example, semantic analysis or entity recognition can be performed on the target input data to determine whether the current initial object corresponds to at least one of the following: technical document, code file, intelligent agent, application, etc.

[0040] Step S112: Process the target input data based on the attribute information using different processing strategies to obtain target variable data. The processing strategy is used to call different functional processing modules of the electronic device.

[0041] Here, after determining the attribute information of the current initial object or target input data, the corresponding functional processing module of the electronic device is called for different business scenarios to process the target input data. This can obtain target variable data that is more suitable for the current business scenario, thereby further improving the accuracy of the target update data generated based on the target variable data.

[0042] Different functional processing modules may include functional modules deployed locally on electronic devices, as well as functional modules of edge devices or cloud devices connected to electronic devices. These functional processing modules may include, but are not limited to, at least one of the following: differential engine, demand parser, API graph, etc.

[0043] For example, in scenarios where attribute information represents the current business scenario as processing non-code data such as technical documents, applications, and intelligent agents, a requirement parser and a large language model (LLM) can be used for intent parsing and entity recognition, as well as for API graph pre-playing and compatibility verification.

[0044] For example, in scenarios where attribute information represents the current business scenario as processing code files, at least one of the following can be used: text comparison, abstract syntax tree (AST) analysis of code, and / or structured difference comparison of contract documents, to identify semantic-level changes.

[0045] In this embodiment, attribute information of the current initial object or target input data is obtained, and different processing strategies are adopted to process the target input data based on the attribute information, thereby generating target variable data. This allows for flexible selection of data processing methods more suited to the current business scenario based on different object types or the attribute characteristics of the input data, thereby improving the adaptability and accuracy of the target variable data.

[0046] In some embodiments, step S112 may include at least one of steps S121 to S123: Step S121: Given that the initial object is a technical document and the target input data is natural language requirement data for the technical document, the natural language requirement data is identified and verified using the large language model in the electronic device and the pre-built corresponding graph library to obtain the target variable data.

[0047] Here, natural language requirement data represents the data type of the target input data as natural language. Given that the initial object is a technical document and the target input data is natural language requirement data for that technical document, this means the target input data can be functional requirements or changes to the technical document proposed by the product manager or user using natural language. Furthermore, LLM can be used to recognize the natural language, and the recognition results can be verified using a pre-built corresponding knowledge graph library to obtain the target variable data. The pre-built knowledge graph library can correspond to the aforementioned API graph or other corresponding knowledge graphs.

[0048] Step S122: When the current initial object is a code file and the target input data is code change data for the code file, the differential engine in the electronic device is used to perform differential comparison on the code change data to obtain the target variable data.

[0049] Here, code change data can include modified or added code data. When the initial object is a code file and the target input data is code change data specific to that code file, it means the target input data can be improvements or modifications to the code file itself. Furthermore, a difference engine can be used to perform a differential comparison between the code change data and the corresponding original code file to obtain the target variable data. This differential comparison can include, but is not limited to, at least one of text comparison, structured difference comparison, and syntax comparison.

[0050] Step S123: Given that the current initial object is an intelligent agent and the target input data is the requirement data of the sub-intelligent agents that build the intelligent agent, the workflow is created using the target knowledge base according to the requirement data to obtain the target variable data. The target knowledge base is a pre-built knowledge base for the intelligent agent. The knowledge base includes the application programming interface graph library and the associated knowledge database required for the functional services that the intelligent agent can implement.

[0051] Here, an intelligent agent can be, but is not limited to, at least one of the following: AI assistants applied in different scenarios, such as game assistants, web assistants, and application assistants. A sub-agent can correspond to a functional service module created within an intelligent agent to provide functional services. When the target input data is determined to be requirement data, workflow creation utilizes the requirement data to create a workflow in which the sub-agent executes a specific functional service (corresponding to the target functional service). For example, a sub-agent (i.e., a functional service module of the parent intelligent agent) can be created within the parent intelligent agent for document review (which may include, but is not limited to, patent documents, annotation documents, office documents, etc.).

[0052] For example, a workflow may include an automated development pipeline, such as a continuous integration, continuous delivery, or deployment pipeline (CI / CD pipeline), which includes a continuous integration (CI) process, a continuous delivery (CD) process, and a continuous deployment (CD) process.

[0053] Understandably, the functional services that each intelligent agent can provide can be achieved through a relevant API graph library and associated knowledge database. The API graph library provides parameters related to the hardware, software, and framework required for the agent's operation, while the associated knowledge database includes general knowledge and / or specialized knowledge required by the agent.

[0054] In this embodiment, corresponding processing strategies are adopted for different types of current initial objects and target input data. For example, large language models and graph libraries are used to process natural language requirement data, differential engines are used to process code change data, and target knowledge bases are used to create workflows. This allows for more adaptable processing methods for different types of business scenarios, thereby further improving the accuracy and applicability of the target variable data.

[0055] It is understandable that when the current initial object and / or target input data include multiple of the above situations, the processing steps corresponding to each situation can be combined to obtain the corresponding multiple target variable data, thereby realizing the updating of multiple business scenarios or multiple types of data.

[0056] In some embodiments, step S101 may include steps S131 to S132: Step S131: In response to obtaining the first input data for the first object, parse the target user needs corresponding to the first input data.

[0057] Here, the first object is one or more of the target objects mentioned above. For example, the first object may include, but is not limited to, at least one of technical development documents, software applications, firmware, functional services, etc.

[0058] The first input data is the target input data corresponding to the first object. For example, the first input data may include, but is not limited to, at least one of the following: configuration variable update data, commands or content for modifying technical documents, agent creation requirements, and functional service adjustment requirements.

[0059] The target user requirement refers to the user requirement represented by the first input data, that is, an abstract representation of the user's intent. It may include, but is not limited to, at least one of the following: a requirement to add new features to the first object, a requirement to change existing features, or a requirement to create new functional services. For example, if the first object corresponding to the first input data is an intelligent agent, the target user requirement may include creating a new intelligent agent. Similarly, if the first object corresponding to the first input data is an application, the target user requirement may include creating or modifying an application to provide the target functional service.

[0060] In some implementations, the target user requirements can be converted into structured requirements after parsing; alternatively, tabular requirements, semantic text requirements, etc., can be created in a specific encoding format or field format after parsing the first input data, and used as target user requirements.

[0061] Step S132: Verify the target user requirements using the target map library, and generate target incremental data after passing the verification.

[0062] Here, the target incremental data can correspond to the target variable data in step S101 above. For example, the target incremental data can include, but is not limited to, at least one of the following: contract increments, document variables, code variables, newly added functional service modules, etc., used to implement user requirements. As validated variable data, the target incremental data ensures that the updates to the target object maintain overall consistency with the target knowledge base.

[0063] The target graph library can correspond to the API graph of the first object or other types of knowledge graphs, such as the function configuration graph of an application or AI assistant, or the graph related to device configuration.

[0064] During implementation, structured or unstructured target user requirements can be pre-tested and compatibility verified in the corresponding target graph library to determine whether the addition or modification operations corresponding to the target user requirements conflict with existing business processes. If the addition or modification operations corresponding to the target user requirements do not conflict with existing business processes, then target incremental data can be generated. This reduces the possibility of conflicts between update operations and existing functional services corresponding to the target objects caused by directly generating target update data based on target incremental data and updating the target objects.

[0065] In some implementations, different knowledge graphs can be selected for verification based on the type of the first object. For example, if the first object includes a technical document, a knowledge graph library containing the technical document and / or its code file can be selected for verification to determine whether the content of the technical document and / or code file conflicts. As another example, if the first object includes a functional service module, the API graph corresponding to that functional service module can be selected for verification to determine whether the API contract conflicts.

[0066] In this embodiment, the target user needs corresponding to the first input data are parsed and verified using a target graph library. Target incremental data is then generated after the verification is successful. This enables automated verification of the rationality of the target user needs before generating target variable data, reducing the possibility of conflicts between the updated content and existing functional services caused by directly updating the target object in response to the first input data, thus improving the overall stability and accuracy of the update process.

[0067] In some embodiments, the parsing of the target user needs corresponding to the first input data in step S131 above may include the following steps S141 to S142: Step S141: Use a large language model to perform intent parsing and entity recognition on the first input data to obtain the target user needs corresponding to the first input data.

[0068] Here, after obtaining the first input data from the product manager or user, such as the natural language requirements submitted by the product manager or architect through the human-computer interaction interface, the requirement parser can use a large language model to perform intent parsing and entity recognition on the first input data, thereby obtaining the target user's requirements.

[0069] For example, the first input data may include natural language requirement data: "We need to add an order cancellation function and release inventory after the order is cancelled." LLM can identify business entities (such as "order," "inventory," etc.), business operations (such as "cancel"), and business rules (such as "after cancellation") in the natural language requirement data. Further, the business entities, business operations, and business rules are identified as corresponding target user requirements.

[0070] Step S142: Convert the target user's requirements into a structured requirement map. The requirement map should at least represent the change information of the core elements in the target user's requirements.

[0071] In some implementations, the target user requirements may be transformed into any structured data capable of representing entities, relationships, and attributes, rather than being limited to a subgraph structure. For example, the target user requirements may be transformed into one of the following: tuples, tree structures, graph structures, etc.

[0072] The demand graph includes demand substructures corresponding to the target user's needs, representing a structured knowledge representation. In this embodiment, unstructured target user needs are transformed into structured "demand subgraphs," i.e., the demand graph. This enables the ingestion and standardization of user needs from the first input data, thereby improving the efficiency and data consistency of subsequent processing based on user needs.

[0073] Nodes in a requirement graph can represent business objects, i.e., business entities; edges in a requirement graph can represent the relationships between business objects, such as operations or constraints.

[0074] The change information for core elements refers to changes related to business entities. For example, it may include the change principles for business entities, i.e., the business rules mentioned above; it may also include the direction of change for business entities, such as the type of operation performed on the business entity (corresponding to "cancellation" of the "order" mentioned above), or adding or reducing the operation performed on the business entity, etc.

[0075] Correspondingly, step S132 may include steps S143 to S144: Step S143: Use the pre-built nodes and relationships in the target graph library to perform compatibility verification on the entities and relationships in the requirement graph. The target graph library is the application programming interface (API) graph library corresponding to the first object.

[0076] Here, the pre-built nodes and relationships in the target graph library can be understood as the currently existing nodes and relationships, i.e., the current state of the existing API model. For example, an existing API model can correspond to a generated API contract file, such as a specification fragment of an Open Application Programming Interface (Open API). Nodes in the target graph library can represent the API endpoints corresponding to the business, and edges in the target graph library can represent the relationships between nodes, such as dependencies, calls, and inheritance. It is understood that for an ongoing business (one or more), the relevant business logic and interface definitions have already been established, i.e., the corresponding API model (API endpoint) has been built. When the target graph library is empty, compatibility checks can pass by default. In this case, the generation operation can be directly executed, transforming the input requirement graph into initial target graph library nodes, thereby completing the establishment of the target graph library and realizing asset initialization. It is understood that the API graph libraries built based on different first objects can be different.

[0077] The entities and relationships in the demand graph refer to the newly constructed or modified business entities and their related relationships.

[0078] In some implementations, compatibility checks on entities and relationships in the demand graph are performed using pre-built nodes and relationships in the target graph library. This may include adding the demand graph to the target graph library for pre-analysis reasoning to determine whether there are any conflicts with the pre-built nodes and relationships in the target graph library.

[0079] Step S144: In response to the requirement map passing the compatibility check, generate target incremental data, which is the map incremental data of the target map library.

[0080] Here, if the demand graph passes the compatibility check, it can be assumed that the demand graph can be added to the target graph library, or the existing corresponding node relationships in the target graph library can be replaced or changed based on the demand graph.

[0081] Incremental graph data refers to the variable data corresponding to nodes and relationships pre-built in the target graph library.

[0082] For example, API contracts conforming to industry standards can be generated or updated based on the validated demand graph. For instance, for the demand "We need to add an order cancellation function and release inventory after order cancellation," a corresponding API endpoint can be added, i.e., incremental graph data, and persisted to the API graph. The API endpoint may consist of, but is not limited to: 1. Endpoint identifier, i.e., the specific interface definition, such as POST / orders / {id} / cancel, where POST is used to submit data to create the corresponding resource, orders corresponds to "orders," {id} corresponds to the specific identifier of the "order," and cancel corresponds to the "cancel" operation; 2. Parameters, i.e., the fields required to input the interface; 3. Return value, i.e., the output structure after the interface execution; 4. Relationship with other entities, i.e., the association between this endpoint and other business entities.

[0083] In this embodiment, the first input data is analyzed for intent and entity recognition using a large language model, transforming it into a structured demand graph. Furthermore, a target graph library is used for compatibility verification, thereby generating incremental graph data. This approach improves data consistency during processing by structuring user demands, thus enhancing overall processing efficiency and accuracy. Furthermore, compatibility verification reduces the likelihood of conflicts between newly added entities and relationships and existing nodes and relationships in the target graph library, improving the overall stability of the processing.

[0084] In some embodiments, step S101 may include steps S151 to S153: Step S151: In response to obtaining second input data for the second object, perform text comparison between the second input data and the second object using the differential engine in the electronic device to obtain a first comparison result.

[0085] Here, the second object is one or more of the target objects mentioned above. For example, the second object may include, but is not limited to, code documentation, API contract files, etc.

[0086] The second input data is the target input data corresponding to the second object. For example, the second input data may include, but is not limited to, new code files submitted by the developer, modified API contracts, etc.

[0087] In some implementations, a differential engine in an electronic device can detect relevant changes to the second object, and after detecting the changes, perform a text comparison between the second input data and the second object to obtain a first comparison result.

[0088] In practice, the first comparison result may include the second input data being the same as the second object text, the second input data being different from part of the second object text and the second input data including newly added text, the second input data being different from part of the second object and the second input data including modified text, or the second input data being completely different from the second object text.

[0089] Step S152: Identify the structured differences between the second input data and the second object to obtain the first identification result.

[0090] Here, structural differences include syntactic differences, which can characterize semantic-level changes. The first identification result can characterize whether the second input data has undergone semantic-level changes compared to the second object, that is, whether it involves semantically relevant key elements, such as method names, parameter lists, or return values. For example, if a comment in the code changes, the corresponding first identification result can indicate that no update to the second object needs to be triggered.

[0091] Understandably, by identifying the structured differences between the second input data and the second object, changes affecting business logic can be identified more accurately, thereby reducing invalid updates and improving both data synchronization efficiency and the accuracy of data updates.

[0092] For example, when modifying the function signature in the code, the difference between the new code file (second input data) and the original code file (second object) can be obtained by analyzing the abstract syntax tree of the code, which is the first identification result.

[0093] For example, different methods of renaming an interface will result in different identification methods.

[0094] For example, if a developer modifies the interface name through code comments, the first identification result representing the interface renaming can be obtained by analyzing the abstract syntax tree of the code.

[0095] For example, if a developer changes the interface name by directly modifying the Open API configuration file, such as the format used to express data serialization (YAML), the first identification result representing the interface renaming can be obtained by analyzing and comparing the structure of the contract file.

[0096] In practice, a differential engine can be used to identify the structured differences between the second input data and the second object to obtain the first identification result.

[0097] Step S153: Generate target variable data based on the first comparison result and / or the first identification result.

[0098] Here, corresponding target variable data can be generated based on either the first comparison result or the first identification result. Furthermore, combining the first comparison result and the first identification result can more accurately identify semantic-level changes, such as identifying newly added parameters in method signatures, structural changes in interface return values, and deprecated interfaces, thereby generating corresponding target variable data.

[0099] In this embodiment, a difference engine is used to compare the second input data and the second object, and to identify structured differences, thereby generating target variable data. This makes the changes not only identifiable in form but also logically understandable, more accurately capturing the differences between the second input data and the second object, obtaining more accurate target variable data, and thus providing a reliable basis for subsequent updates.

[0100] In some embodiments, the step S102 described above, which generates target update data based on target variable data and target knowledge base, may include the following steps S161 to S163: Step S161: Update the target knowledge base corresponding to the current initial object based on the target variable data to obtain the updated knowledge base.

[0101] Here, after updating the target knowledge base based on the target variable data, the resulting updated knowledge base can be either a newly added knowledge base or a target knowledge base where elements have been updated.

[0102] For example, target variable data can be synchronized to the API graph. If the initial knowledge base corresponding to the current initial object is empty, the API graph is generated based on the target variable data. If the initial knowledge base corresponding to the current initial object is not empty, the nodes and relationships in the API graph corresponding to the current initial object are updated.

[0103] Step S162: Determine the data of the object to be updated based on the mapping relationship between the updated knowledge base and the target associated object.

[0104] Here, by traversing the mapping relationship, the scope of the updated knowledge base affected by the update can be determined more accurately, thereby reducing the possibility of a global rewrite of all files or data.

[0105] The data to be updated can include nodes and relationships in the API graph, or it can be document content or code content to be transformed.

[0106] For example, if the initial object is a code file, the target associated object can be the API contract corresponding to the code file. Furthermore, the API contract to be updated, i.e. the data to be updated, can be determined based on the nodes and relationships related to the code file in the updated API graph.

[0107] For example, if the initial object is a technical document, the target associated object can be the code file corresponding to that technical document. Furthermore, the code content that needs to be updated or changed, i.e., the data to be updated, can be determined based on the mapping relationship between the API graph and the code file.

[0108] For example, if the initial object is a code file, the target associated object can be the technical document corresponding to that code file. Furthermore, the content in the technical document that needs to be updated or changed can be determined based on the mapping relationship between the API graph and the technical document, i.e., the data to be updated.

[0109] Step S163: Generate target update data based on the data of the object to be updated.

[0110] During implementation, the target update data may include the data of the object to be updated itself; it may also include the data obtained after code conversion or natural language conversion of the data to be updated; it may also include the document data or code data to be updated obtained after corresponding conversion of the nodes and relationships in the API graph based on the mapping relationship between the API graph and technical documents or code files.

[0111] For example, after a developer submits the code file corresponding to a new feature service, that code file can be used as the object data to be updated and directly identified as the target update data.

[0112] For example, based on the changed nodes and relationships in the updated API graph, corresponding API contract files, code patches, and / or documentation patches can be generated. Code patches require code conversion based on the changed nodes and relationships, while documentation patches require natural language conversion based on the changed nodes and relationships.

[0113] For example, based on the mapping relationship between technical documents and code files in the API graph, if one of them (as the object data to be updated) changes, both can be updated synchronously, and target update data corresponding to each can be generated based on the changed object data to be updated.

[0114] In some implementations, the electronic device may be equipped with a patch synthesizer to respond to update operations when an update is triggered in the target knowledge base. Based on the analysis results of the data to be updated, it automatically creates a data request in the corresponding data warehouse, such as a pull request (PR) for a distributed version control system (Git) repository. The content of the request may include, but is not limited to, at least one of API contract patches, code skeleton patches, and initial documentation patches. The data warehouse can be understood as the developer's work object; developers can access the data warehouse to obtain tasks and submit code and other files.

[0115] In this embodiment, the target knowledge base is first updated based on the target variable data. Then, the data of the object to be updated is determined according to the mapping relationship between the updated knowledge base and the target associated objects. Finally, the target update data is generated based on the data of the object to be updated. In this way, the dynamic updating of the target knowledge base can achieve accurate synchronization of associated objects, reduce unnecessary rewriting, lower update costs, and improve processing efficiency, thereby improving the overall consistency and accuracy of the update process.

[0116] In some embodiments, step S162 may include steps S171 to S172: Step S171: Determine the object data to be updated based on the nodes and relationships in the updated knowledge base and the entities and relationships in the target associated object. The object data to be updated includes the entities and relationships to be updated. The updated knowledge base is the updated application programming interface (API) graph.

[0117] Here, the nodes and relationships in the API graph record the business relationships between various business entities. The updated API graph also records the dependencies between the updated API contracts (API endpoints) and various business entities at the business logic level. Therefore, based on the nodes and relationships in the updated API graph and the entities and relationships in the target associated object, the data to be updated, i.e., the entities and relationships that need to be updated, can be determined from a business logic perspective.

[0118] Understandably, because the edges in an API graph represent the relationships between nodes (API endpoints), the API graph not only contains API metadata (such as paths, methods, parameters, return values, etc.) but also carries business logic and the impact chain of changes. By modeling the updated knowledge base as an API graph, it's possible to more intuitively identify which APIs have changed and further deduce the impact of these changes on other APIs. For example, if an API is deprecated, it's necessary to determine whether other APIs that depend on it also need corresponding adjustments.

[0119] For example, the nodes and relationships to be updated can be determined based on the nodes and relationships in the updated API graph and the current entities and relationships in the current technical documentation or current code file.

[0120] Step S172, or, determine the object data to be updated based on the dependencies in the updated Application Programming Interface (API) graph and the entities and relationships in the target associated object. The object data to be updated includes at least one of the affected document nodes, code references, and test cases.

[0121] Here, the dependencies in the updated API graph can include the correspondence between each API node and each document, code, and / or test case. By traversing the dependencies in the updated API graph, the document nodes, code references, and / or test cases affected by the update can be quickly and accurately located. Document nodes can correspond to technical documents, code documents, etc.; code references can include the reference relationships between APIs in the code, or the reference relationships between different code snippets; test cases can include the test cases corresponding to quality gating tests of code or contract changes.

[0122] In some implementations, an impact analyzer can be set up in the electronic device to automatically calculate the impact domain corresponding to each update based on the dependencies of the API graph, and determine the datasets (such as API reference manuals, developer guides, sample code, etc.) that need to be created or updated. The impact analyzer can perform calculations based on a preset algorithm model, such as an impact domain analysis model.

[0123] For example, the impact domain analysis model can quantify the degree to which each node in the API graph is affected by a change based on a change propagation score function. For nodes in the API graph affected by changes... Changes triggered , For any node in the API graph Impact Score It can be calculated using a linear weighted model. The calculation process can be found in the following formula (1): (1); in, It can represent a node To the node The path weights are used to evaluate nodes. Node The strength of the impact of changes is usually inversely proportional to the path length; the shorter the path, the more nodes... Node The more direct the impact of changes, the more pronounced they will be from the node. To the node The higher the path weight; It can represent the type weight of edges (i.e., relations) in a path. For example, the weight representing a "directly documented" relation can be higher than the weight representing a "merely mentioned" relation. It can represent a node The meta-attribute score of the document itself, for example, a document node marked as "unstable" or "pending review" may have a high sensitivity to change, and the corresponding meta-attribute score can be high. In implementation, the meta-attribute score can be normalized or set to a score value of 1 to 100. , as well as These correspond to preset weight coefficients for path weight, type weight, and meta-attribute score, respectively, used to adjust the importance of different factors in the change propagation score. It can be understood that the calculation is performed differently depending on the use case or business requirements. corresponding , as well as They can be different.

[0124] In some implementations, a preset score threshold can be determined, which is the minimum score that represents the corresponding node that needs to be updated.

[0125] For example, experts in the relevant field can set a preset threshold representing "needs to be updated" based on business risks and / or data importance. Alternatively, by analyzing the statistical results of historical update data, a preset threshold can be set. Dynamic adjustments are made to achieve more accurate update coverage and update precision.

[0126] In some implementations, a preset threshold is set by analyzing the statistical results of historical update data. Dynamic adjustments can be implemented in the following ways: Review and analyze API graph update records for target number of times (e.g., 50 times, 100 times, etc.) in historical business operations; compare the impact score calculated by the impact domain analysis model at each update with the historical record of whether the corresponding node data was ultimately modified; statistical results show that when the impact score is higher than the first threshold (e.g., impact score normalization, the first threshold can be 0.75, 0.8, 0.83, etc.; impact score ranges from 0 to 100, the first threshold can be 75, 80, 83, etc.), the first proportion (e.g., four-fifths, ...) of the corresponding node data If node data (e.g., 95%, etc.) is ultimately modified, it indicates that the prediction result based on the corresponding preset threshold is relatively accurate. If, when the influence score is lower than the second threshold (e.g., influence score normalization, the second threshold could be 0.6, 0.55, 0.5, etc.; influence score ranges from 0 to 100, the first threshold could be 60, 55, 50, etc.), and the node data of the second proportion (e.g., four-fifths, three-fifths, 90%, 95%, etc.) in the corresponding node data is ultimately not modified, it indicates that the prediction result based on the corresponding preset threshold is relatively accurate. Through this statistical analysis, we can find the preset threshold for relatively accurate prediction results, thereby reducing the generation of unnecessary data patches while minimizing the omission of data that needs updating.

[0127] Furthermore, it can be based on a preset threshold. Determine the "minimum update set" at which the representation needs to be updated at least. That is, the corresponding impact score Not less than the preset threshold A set of nodes. For example, the "minimum update set". Please refer to the following formula (2): (2).

[0128] In this way, the smallest unit of data to be updated can be determined more accurately based on quantifiable impact scores and preset score thresholds.

[0129] In this embodiment, the corresponding types of object data to be updated are determined by analyzing the nodes and relationships in the updated API graph and the entities and relationships in the target associated object, or by analyzing the dependencies in the updated API graph and the entities and relationships in the target associated object. This approach allows for more accurate identification of the types of object data to be updated, further reducing unnecessary global updates and improving update efficiency and accuracy. Furthermore, it enhances the comprehensiveness and consistency of data updates and synchronization based on the business logic recorded in the API graph or its associations with different types of data.

[0130] In some embodiments, the above data processing method may further include the following step S181: Step S181: Perform compliance verification on the target update data, and after passing the compliance verification, update the target associated object of the current initial object using the target update data, or update the current initial object using the updated target associated object.

[0131] Here, compliance verification means that before applying the target update data to update the target object, its content is checked to ensure that it conforms to preset quality standards, format requirements, and / or business rules. The target update data will only be used to update the target object if it passes compliance verification. This maintains the stability and consistency of the original data.

[0132] In some implementations, compliance verification may include pre-established automated quality gate testing to perform quality verification checks such as contract specification checks, interface testing, and example verification. The judgment criteria for quality gate testing may include, but are not limited to, at least one of the following: whether the data structure is consistent with existing contracts, whether it meets preset business rules (such as whether state transition conditions are met, whether time limits are met, etc.), whether it conflicts or contradicts other existing nodes or relationships, and whether it violates quality gate policies (such as whether test coverage meets standards, whether examples are runnable, etc.).

[0133] For example, access control checks are performed on the code skeleton and API contract generated based on natural language requirement changes, and if the checks pass, the updated code files and API contracts are used to update the current code files and API contracts, or the updated code files and API contracts are used to further update relevant technical documents and / or test cases.

[0134] For example, access control verification can be performed on code changes or contract changes submitted directly by developers, and if the verification passes, the changes can be used to update the corresponding code files or API contracts, or the updated code files and API contracts can be used to further update relevant technical documents and / or test cases.

[0135] After passing compliance verification, the verification results can determine how to apply the target update data to update the target associated object or the current initial object. For example, there are two possible update paths after verification: The first approach involves updating the target associated object of the current initial object using the target update data. This update method means that the target update data can be directly used to update a defined existing object (i.e., the target associated object), such as an API endpoint, business entity, or endpoint parameters.

[0136] The second path involves using the updated target associated object to further update the current initial object. This update method indicates that the target associated object itself has changed, and this change in the target associated object affects the state or attributes of the current initial object. For example, if the target associated object is a general model that is depended on by multiple other objects, then an update to the target associated object may trigger a re-evaluation or synchronous update of the other associated objects.

[0137] In this embodiment, compliance verification is performed before applying target update data to the target object. After passing compliance verification, the target associated object of the current initial object is updated using the target update data, or the current initial object is updated using the updated target associated object. This ensures that the updated content conforms to specifications, reduces the possibility of erroneous data propagation, and improves the stability of the original data. Furthermore, updating the target associated object, or synchronously updating the current initial object corresponding to the target associated object in both directions, improves overall data consistency.

[0138] In some embodiments, the current initial object includes technical documentation, the target update data includes patch data, and the target associated object includes the code file corresponding to the technical documentation; the step S181 above, which involves updating the target associated object of the current initial object using the target update data, or updating the current initial object using the updated target associated object, may include the following step S191: Step S191: Update the code file using the patch data corresponding to the technical document, or update the technical document using the updated code file.

[0139] Here, technical documents can represent new requirements or changes to requirements proposed by the demand side.

[0140] During implementation, after adding or modifying the relevant code using the corresponding code patches (i.e., patch data), the final code file can be obtained. Alternatively, after updating the code, the corresponding technical documentation, such as code comment documentation, operation process documentation, developer guides, and API reference manuals, can be updated synchronously based on the updated code.

[0141] Patch data can include incremental modifications to existing code or documentation.

[0142] Understandably, updating code files with patch data corresponding to technical documentation represents a forward update process from documentation to code; while updating technical documentation with updated code files represents a reverse update process from code to documentation. This two-way update mechanism can better reduce the problem of documentation and code being out of sync in the business development process, achieving a two-way driven automated closed loop.

[0143] For example, consider the process from natural language requirements to building framework data (code frameworks and / or API contracts) for fulfilling those requirements. Figure 2 As shown, from the user's interaction perspective, product managers or architects can submit natural language requirements, which are then updated synchronously by a processing model within the electronic device, including a large language model and a logic processing model. Figure 2 The system (corresponding to the synchronous update system) parses and processes the data, generating deliverables, namely the code framework and API contract, for the developers, and finally completes verification and release through the CI / CD pipeline. The synchronous update system can be a specific device or functional entity used to execute the above data processing methods. The synchronous update system and the CI / CD pipeline are two independent structures, but they work together through an interface. Specifically, this may include the following steps S201 to S213: Step S201: Submit a natural language request.

[0144] Step S202: Parse intent and normalize.

[0145] This corresponds to the steps in the data processing method described above: parsing the target user's intent from natural language demand data and performing structured processing on the target user's intent.

[0146] Step S203: Check for change conflicts.

[0147] This corresponds to the compatibility check in the data processing method described above.

[0148] Step S204: Return the verification result.

[0149] If the verification result is successful, proceed to step S205.

[0150] During implementation, a manual approval step can be added after step S204 to further confirm the validity of the verification results.

[0151] Step S205: Update the map status.

[0152] This corresponds to the process of updating the target knowledge base in the data processing method described above.

[0153] Step S206: Create the code framework and tasks.

[0154] Here, the task can correspond to the task (pull request) that the developer can obtain from the data warehouse in the above data processing method, and then implement the corresponding business logic based on the obtained task.

[0155] Step S207: Implement business logic.

[0156] Step S208: Submit the code.

[0157] Here, the submitted code can be the final code file after being modified or supplemented by the developer, or it can be a code skeleton that has passed the developer's review.

[0158] Step S209: Implement quality gating.

[0159] Here, execution quality gating can correspond to the execution quality gating test in the data processing method described above.

[0160] Step S210: Return the test results.

[0161] If the test result is successful, proceed to step S211.

[0162] Step S211: Notification Issuance.

[0163] Here, the notification of data release from the CI / CD pipeline indicates that the validated data is allowed to be merged into the API knowledge graph (i.e., the API graph mentioned above).

[0164] Step S212: Check the latest status.

[0165] Here, by querying the latest status of the API knowledge graph, we can further analyze the impact domain of this update and further realize the synchronous update of relevant data.

[0166] Step S213: Generate the initial version document.

[0167] Here, the initial version document refers to the initial version of the technical document. Considering that there may be subsequent updates to the technical document, the technical document generated at this time is the initial version.

[0168] For example, from the perspective of electronic devices, for Figure 2 The internal logic implementation of the process can be as follows Figure 3 As shown, in response to the natural language request submitted by the participants, the synchronous update system in the electronic device parses and processes the request, generates a deliverable, and triggers access control verification. Specifically, this may include the following steps S301 to S308: Step S301: Submit a natural language request.

[0169] Here, after responding to the natural language requirements submitted by the participants, we enter Phase 1: Requirements Ingestion and Standardization, which yields the requirements subgraph, namely the aforementioned target user requirements.

[0170] Step S302: Structured requirements sub-graph.

[0171] Here, the structured demand subgraph is the demand graph in the data processing method described above. After obtaining the demand graph, the process proceeds to stage two: graph preview and contract generation.

[0172] Step S303: Perform pre-run and verification based on API map.

[0173] Step S304: Generate contract increment.

[0174] Here, the contract increment can correspond to the target variable data in the data processing method described above. During implementation, the contract engine in the synchronous update system can receive the validated demand graph and automatically generate or update the standard API contract file accordingly, and then persist the new nodes and relationships to the API graph.

[0175] After generating the contract increment, we proceed to Phase 3: Impact Analysis and Asset Initialization.

[0176] Step S305: Calculate the influence domain based on the spectral map.

[0177] Step S306: Create a PR.

[0178] Here, PR can correspond to the target update data in the above data processing method. PR can include, but is not limited to, at least one of contract files, code frameworks, documentation patches, etc.

[0179] Understandable Figure 3 The process of automatically creating PRs (Private Repositories) from the synchronous update system to the data warehouse (including code repositories, document repositories, and / or contract repositories) can correspond to... Figure 2The process of synchronously updating the system to generate deliverables and delivering them to developers.

[0180] Step S307: Trigger access control verification.

[0181] Here, triggering access control verification corresponds to the execution quality access control test in the data processing method described above.

[0182] During implementation, it can be performed by the C1 pipeline or the access control verification module in the system.

[0183] Step S308: Return the verification result.

[0184] Here, the verification result can include pass (i.e., pass the verification) or fail (i.e., fail the verification).

[0185] For example, taking changes from code or contracts to document synchronization as an example, such as Figure 4 As shown, from the user's interactive perspective, developers can submit code changes, which are then captured by the CI / CD pipeline and used to drive a synchronous update system for analysis and documentation patching, ultimately merging the code and documentation synchronously. Specifically, this can include the following steps S401 to S411: Step S401: Modify the code.

[0186] During implementation, after developers obtain the code framework from the data warehouse, they may modify the code, such as adding parameters, adjusting interfaces, or modifying return values.

[0187] Step S402: Submit code changes.

[0188] Here, the code change can correspond to the target input data or the second input data in the data processing method described above.

[0189] Step S403: Capture changes.

[0190] Step S404: Semantic incremental difference.

[0191] Here, semantic incremental difference can correspond to text comparison and structured difference comparison in the data processing methods mentioned above.

[0192] During implementation, after a developer submits code or directly modifies the API contract, the differential engine used to detect changes in the synchronous update system is triggered. This engine can not only perform text comparison, but also more accurately identify semantic-level changes by analyzing the abstract syntax tree of the code and comparing the structured differences in the contract file.

[0193] Step S405: Update the graph nodes.

[0194] During implementation, the identified changes can be synchronized to the API knowledge graph to update the corresponding nodes and attributes (including relationships).

[0195] Step S406: Query dependencies and perform influence domain analysis.

[0196] Here, querying dependencies and performing impact domain analysis corresponds to traversing the API graph dependencies in the data processing method described above, thereby identifying the affected objects to be updated.

[0197] During implementation, the impact analyzer in the synchronous update system can initiate impact domain analysis based on the graph. By traversing dependencies, it can quickly locate all document nodes, code references, and test cases affected by this change.

[0198] Step S407: Return the set of affected document nodes.

[0199] Step S408: Generate incremental patch for the document.

[0200] Here, the patch synthesizer in the synchronous update system, which generates patch data, can generate corresponding incremental documentation patches based on the minimum update set output by the impact domain analysis. These patches are used to automatically update relevant documentation, such as updating parameter tables in the API reference manual, demonstrating the usage of new parameters in calling examples, and updating outdated flowcharts or explanatory text. Furthermore, the synchronous update system can automatically submit this documentation patch as a pull request (PR) to the corresponding documentation repository in the data warehouse, thus completing reverse synchronization from code to documentation.

[0201] Step S409: Automatically submit document patches to the data warehouse.

[0202] Step S410: Perform quality gating on the latest code and documentation.

[0203] Here, quality gating can include, but is not limited to, at least one of the following: performing contract testing, checking for compliance with standards and specifications, and determining the executability of examples.

[0204] Step S411: Return the final verification result.

[0205] After returning the final verification results to the developers, a manual review and data merging process can be added to ensure the accuracy of the final verification results.

[0206] For example, from the perspective of electronic devices, for Figure 4 The internal logic implementation of the process can be as follows Figure 5 As shown, in response to code changes submitted by developers, document synchronization is achieved through semantic difference-aware changes, graph updates, and influence domain calculations. Specifically, this may include the following steps S501 to S506: Step S501: Submit code and / or contract changes.

[0207] Here, after developers submit code and / or contract changes to the data warehouse, we enter Phase Four: Change Awareness and Semantic Differentiation.

[0208] Step S502: Capture changes and parse the AST to generate a semantic change set.

[0209] Here, after executing step S502, we proceed to stage five: map update and influence domain analysis.

[0210] In implementation, for example, the semantic change set can be represented as .

[0211] Step S503: Update the API graph and calculate the minimum document influence set.

[0212] Here, the minimum document impact set corresponds to the minimum update set in the data processing method described above. After executing step S503, the process proceeds to stage six: automatic document repair and verification.

[0213] Step S504: Create a document incremental patch (PR).

[0214] Here, the created incremental document patch is added to the corresponding data warehouse.

[0215] Step S505: Trigger access control verification.

[0216] Step S506: Return the verification result.

[0217] Here, the verification result can include pass or fail.

[0218] In this embodiment, patch data is used to achieve bidirectional updates between technical documentation and code files. This improves development efficiency while maintaining dynamic consistency between the two.

[0219] In related technologies, business requirements during system development are often initially presented as unstructured textual descriptions. The final deliverables, however, must be transformed into precise API interface specifications, robust and maintainable code, and technical documentation (such as developer guides and API reference manuals) that strictly match these requirements (e.g., including at least the corresponding APIs).

[0220] Currently, several independent solutions are typically used to address some of the challenges, but each has its limitations: 1. Contract-First Approach: Define the API contract first, then generate the code framework. An API contract is the technical expression of business requirements; it's a structured specification document (such as an Open API) that precisely defines the interface, detailing the API's parameters and return values. The API contract is used to automatically generate the initial code framework and as a benchmark to help identify semantic changes. However, this approach is one-way. If the code is modified directly later, the corresponding contract and documentation will not be automatically updated, potentially leading to data inconsistencies (mismatches).

[0221] 2. Code-to-Documentation Solution: This method automatically generates documentation through code comments. However, it is also unidirectional, and the document quality heavily relies on the completeness of the comments, making it difficult to reflect high-level business logic and design intent. In the data processing methods described above, high-level business logic and design intent are embodied in the API knowledge graph. This logic and intent often originate from the initial natural language requirements, such as business rules and constraints, which are parsed to generate structured requirement subgraphs that are stored within the graph. The API graph, acting as a "semantic hub," preserves the semantic link from requirement intent to technical implementation, thus compensating for the shortcomings of relying solely on code comments in related technologies, which often fail to reflect high-level design.

[0222] 3. Documentation as Code Solution: This approach treats documentation as code for version control. However, it cannot automatically detect logical changes in the code itself, requiring manual verification of the documentation's up-to-date content. In other words, the documentation needs to be manually updated in response to code updates.

[0223] In summary, the development process in related technologies suffers from the following main problems: the traceability link from requirements to code is broken, and technical documentation is often lagging due to the lack of an automatic synchronization closed-loop mechanism. Therefore, an API knowledge graph capable of unified management of requirements, contracts, code, and documentation is needed as the core to build a bidirectional, incrementally updated, and verifiable automated closed-loop update mechanism for key nodes.

[0224] To address the above issues, based on the aforementioned data processing methods, this application provides a synchronization consistency guarantee method based on API graphs, applicable to electronic devices and executed by the synchronization update system within the electronic device. This method uses a unified API graph as its semantic center, and its core lies in being driven by four collaborative mechanisms that synchronize modifications to documents with modifications to code, forming an end-to-end automated closed loop. These four mechanisms include: 1. Requirements Standardization and Contract Generation: Natural language requirements are automatically parsed into a structured representation, compatibility is verified through an API graph, and the generation and evolution of API contracts are driven. The evolution of API contracts means that the API specification document is no longer a one-time generated document, but a dynamic object that can automatically expand its definition based on new natural language requirements and automatically correct details based on actual code changes, thus maintaining its up-to-date status as a single source of fact.

[0225] 2. Semantic Incremental Differentiation: By comparing changes in the code abstract syntax tree and API contract, it accurately identifies semantic modifications such as function signatures and interface renaming, providing precise input for subsequent synchronization.

[0226] 3. API Graph Impact Domain Analysis: Based on the dependencies of the API graph, the system automatically calculates the minimum set of documents affected by changes, enabling accurate updates of document increments and reducing the possibility of global rewriting.

[0227] 4. Executable Quality Gating: Automated gating is established for each change to perform quality checks such as contract specification checks, interface testing, and example verification. This ensures that compliant changes are merged into the final data. Changes that are non-compliant will not be merged, thereby improving the overall consistency of the source code and contracts.

[0228] like Figure 6 As shown, the method includes the following steps S601 to S610: Step S601: Change of Natural Language Requirements.

[0229] Here, we will use a specific business scenario, such as adding a time-limited cancellation function to an order system, to illustrate the workflow of this application's embodiment. For example, a product manager proposes a natural language requirement: "We need to add a function to cancel orders for users. Only orders in the 'pending payment' status can be cancelled, and the operation must be completed within 15 minutes of placing the order." This corresponds to the forward flow in the data processing method described above. After the product manager inputs the above requirement into the system interface (the system mentioned below can all correspond to the aforementioned synchronous update system), the system's built-in LLM can identify the following after parsing the requirement: main entity (e.g., "orders", which can correspond to "orders"), operation (e.g., "cancel", which can correspond to "cancel"), Hypertext Transfer Protocol (HTTP) method suggestion (e.g., POST or PUT method for submitting data to the server), resource path suggestion (e.g., " / orders / {id} / cancel"), and business rules / constraints (e.g., "the operation must be completed within 15 minutes of placing the order").

[0230] Step S602: Requirements standardization and contract generation.

[0231] Here, the system can form a demand subgraph from the structured information extracted in step S601, which can then be used to update the API knowledge graph.

[0232] Step S603: Generate or update the API map.

[0233] Here, the system can verify the demand subgraph against the existing API graph to confirm whether there are any contradictions or conflicts. Furthermore, the system's contract engine can automatically generate corresponding incremental contracts, such as "contract.diff," in the Open API specification file based on the demand subgraph, serving as new API endpoints. Additionally, the new API endpoints and their rules can be persisted to the API knowledge graph.

[0234] The core of this method lies in the construction and dynamic updating mechanism of the API knowledge graph. Each node (representing API, parameters, entities, etc.) and edge (representing relationships such as dependency, inheritance, and invocation) in the graph can carry its version and state information. The dynamic update process can be found in formula (3): (3); in, It can represent a point in time. Corresponding API graph status; It can represent incremental changes parsed from the demand side (natural language); It can represent incremental changes identified from the code and / or contract side through semantic differential; Functions can represent deterministic operations with transactional and conflict resolution capabilities, used to enable change sets. and The application of this parameter is atomic. That is, when conflicts exist within a change set, such as a document requirement to deprecate a parameter while a code-side change necessitates its use, then... The function can reject the current update and generate a conflict report based on preset priority rules (such as code change priority, document change priority, etc.) or rollback mechanism, thereby improving the overall consistency of the graph state.

[0235] Step S604: Analysis of the influence domain of the spectral map.

[0236] Step S605: Incremental document update.

[0237] Here, the system can use the impact analyzer to determine that this change is for a new feature service, thus requiring the creation of new code and documentation. Furthermore, the system can automatically create a PR in the code repository of the data warehouse, which may contain the updated configuration file, such as "openai.yaml", and the new code framework, and create initial documentation for the API endpoint (such as "docs / api / orders / cancel.md") in the documentation repository of the data warehouse.

[0238] Step S606, Quality Gating.

[0239] During implementation, step S607 is executed if the quality gate is passed; step S609 is executed if the quality gate is not passed.

[0240] Step S607, Merge and Publish.

[0241] Step S608: Achieve data consistency.

[0242] Here, you can update the corresponding code files and / or technical documents using incremental document data.

[0243] Step S609, code and / or contract change.

[0244] During implementation, for the above business scenario, when developers took over the PR and completed the business logic, they discovered that it was necessary to return the ID of the canceled order to the caller. Therefore, developers can modify the method signature and implementation before submitting the code changes.

[0245] Step S610: Semantic incremental difference.

[0246] Here, in response to the code change commit, the CI pipeline in the CI / CD pipeline is triggered, and the differential engine in the system starts working. By analyzing the AST of the code, the engine can identify that the return value of the order cancellation method has changed from the initial value to the latest value, which corresponds to the semantic change in the aforementioned data processing method. Furthermore, this change can be synchronized to the API knowledge graph, thereby updating the return value information of nodes (such as the / orders / {id} / cancel endpoint), i.e., returning to step S603.

[0247] In step S604, the influence domain of the graph is calculated based on the updated nodes. For example, the definition of this endpoint in the configuration file openai.yaml is outdated; the API reference and sample code in the API endpoint docs / api / orders / cancel.md are inaccurate. Furthermore, the system can automatically generate an incremental patch for the documentation through the patch synthesizer, and automatically modify the response section of openapi.yaml and the sample response in the documentation cancel.md by submitting this patch to the developer's current PR.

[0248] After submitting the PR, step S606, a quality gate, is triggered to verify whether the code implementation matches the updated API contract and whether the example code snippets in the documentation run correctly. Once all checks pass, the PR is allowed to be merged, and step S607 is executed. At this point, the requirements, code, and documentation are once again in agreement.

[0249] In this embodiment, an integrated system and method are used to automatically maintain consistency throughout the entire lifecycle, from natural language requirements to API code and documentation. The core is the construction of an API knowledge graph as a single source of fact, achieving a bidirectional, incremental, synchronous closed loop through two core workflows: a forward process (document to code) and a reverse process (code to documentation). This achieves several advantages: firstly, it enables the rapid transformation of natural language requirements into usable interfaces, significantly shortening the development cycle and improving product delivery efficiency; secondly, the automated closed loop reduces inconsistencies between contracts, code, and documentation, improving overall data quality and consistency; thirdly, automating document synchronization allows developers to focus more on core business logic, further improving product quality and processing efficiency while reducing maintenance costs; and fourthly, it provides real-time, accurate, and highly reliable documentation and examples, thereby reducing collaboration costs between developers and development systems and improving the developer experience.

[0250] This application provides an electronic device, such as... Figure 7 As shown, the electronic device 700 includes at least one processor 710 and at least one processing model 711 capable of running on the at least one processor. The electronic device can refer to a server, laptop, tablet, desktop computer, smart TV, set-top box, mobile device (e.g., mobile phone, portable video player, personal digital assistant, dedicated messaging device, portable gaming device), or other device with data processing capabilities; the processing model can correspond to the aforementioned synchronous update system or other processing models capable of performing the same operations as the synchronous update system.

[0251] The aforementioned processing model 711 can be invoked to perform the following operations: In response to obtaining target input data for the current initial object, target variable data is generated based on the target input data; Target update data is generated based on target variable data and target knowledge base, and the target update data can be used to update target objects; The target object includes the current initial object and / or its target associated objects, and the target object can be used to provide the target functional service; the target knowledge base is used to describe the core elements required to implement the target functional service.

[0252] In some embodiments, the at least one processor 710 may also invoke at least one processing model 711 to execute any step in the data processing method described above.

[0253] This application also proposes a computer program including computer-readable code. When the computer-readable code is run in an electronic device, the processor in the electronic device executes a data processing method provided in this application.

[0254] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the data processing method provided in this application.

[0255] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the data processing method provided in this application when executed by a processor.

[0256] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A data processing method, comprising: In response to obtaining target input data for the current initial object, target variable data is generated based on the target input data; Target update data is generated based on the target variable data and the target knowledge base, and the target update data can be used to update the target object; The target object includes the current initial object and / or its target associated object, and the target object can be used to provide target functional services; the target knowledge base is used to describe the core elements required to implement the target functional services.

2. The method according to claim 1, wherein generating target variable data based on the target input data in response to obtaining target input data for the current initial object comprises: In response to obtaining target input data for the current initial object, obtain attribute information of the current initial object or the target input data; Based on the attribute information, the target input data is processed using different processing strategies to obtain the target variable data, wherein the processing strategy is used to call different functional processing modules of the electronic device.

3. The method according to claim 2, wherein processing the target input data based on the attribute information using different processing strategies to obtain the target variable data includes at least one of the following: When the current initial object is a technical document and the target input data is natural language requirement data for the technical document, the natural language requirement data is identified and verified using a large language model in the electronic device and a pre-built corresponding graph library to obtain the target variable data. When the current initial object is a code file and the target input data is code change data for the code file, the differential engine in the electronic device is used to perform differential comparison on the code change data to obtain the target variable data; When the current initial object is an agent and the target input data is the requirement data for constructing the sub-agent of the agent, a workflow is created using the target knowledge base according to the requirement data to obtain the target variable data. The target knowledge base is a pre-built knowledge base for the agent, which includes an application programming interface graph library and an associated knowledge database required for the functional services that the agent can implement.

4. The method according to claim 1 or 2, wherein generating target variable data based on the target input data in response to obtaining target input data for the current initial object comprises: In response to obtaining first input data for the first object, the target user needs corresponding to the first input data are parsed. The target user needs are verified using a target map library, and target incremental data is generated after the verification is passed.

5. The method according to claim 4, wherein, Parsing the target user needs corresponding to the first input data includes: The first input data is analyzed using a large language model to perform intent parsing and entity recognition in order to obtain the target user needs corresponding to the first input data. The target user needs are transformed into a structured demand map, which at least represents the change information of the core elements in the target user needs; Correspondingly, the step of verifying the target user needs using the target map library and generating target incremental data after passing the verification includes: The entities and relationships in the requirement graph are verified for compatibility using the pre-built nodes and relationships in the target graph library, where the target graph library is the application programming interface (API) graph library corresponding to the first object. In response to the requirement map passing the compatibility check, the target incremental data is generated, and the target incremental data is the map incremental data of the target map library.

6. The method according to claim 1 or 2, wherein generating target variable data based on the target input data in response to obtaining target input data for the current initial object comprises: In response to obtaining second input data for the second object, a text comparison is performed between the second input data and the second object using a differential engine in the electronic device to obtain a first comparison result; Identify the structured differences between the second input data and the second object to obtain a first identification result; The target variable data is generated based on the first comparison result and / or the first identification result.

7. The method according to claim 1, wherein generating target update data based on the target variable data and the target knowledge base includes: The target knowledge base corresponding to the current initial object is updated based on the target variable data to obtain the updated knowledge base; The data of the object to be updated is determined based on the mapping relationship between the updated knowledge base and the target associated object; The target update data is generated based on the data of the object to be updated.

8. The method according to claim 7, wherein determining the object data to be updated based on the mapping relationship between the updated knowledge base and the target associated object includes: The data of the object to be updated is determined based on the nodes and relationships in the updated knowledge base and the entities and relationships in the target associated object. The data of the object to be updated includes the entities and relationships to be updated. The updated knowledge base is an updated application programming interface (API) graph; or, The object data to be updated is determined based on the dependencies in the updated Application Programming Interface (API) graph and the entities and relationships in the target associated object. The object data to be updated includes at least one of the affected document nodes, code references, and test cases.

9. The method according to claim 1 or 7, further comprising: The target update data is subjected to compliance verification, and after passing the compliance verification, the target associated object of the current initial object is updated using the target update data, or the current initial object is updated using the updated target associated object.

10. An electronic device comprising at least one processor and at least one processing model capable of running on said at least one processor, said processing model being invoked to perform the following operations: In response to obtaining target input data for the current initial object, target variable data is generated based on the target input data; Target update data is generated based on the target variable data and the target knowledge base, and the target update data can be used to update the target object; in, The target object includes the current initial object and / or its target associated object, and the target object can be used to provide target functional services; the target knowledge base is used to describe the core elements required to implement the target functional services.

Images