AI programming assistant session data incremental synchronization method and system based on local state library

Abstract

The application relates to the technical field of data incremental synchronization, in particular to an AI programming assistant session data incremental synchronization method and system based on a local state library, which comprises the following steps: collecting developer interactive behavior data and code state data and writing the data into a local state library; determining an AI assistant wake-up probability and a question intention category through a hidden Markov model based on the developer interactive behavior data and the code state data; and obtaining an intention context set by clipping an AST subgraph associated with an editing position in a code knowledge graph according to the question intention category. In the application, the prediction law corresponding to different developer behaviors is continuously corrected through federated aggregation parameters, so that a closed loop is formed by pre-fetch triggering, context selection, incremental transmission, cache control and prediction updating, and the real-time performance of synchronization, transmission efficiency, Token resource utilization, context effectiveness and personalized prediction accuracy are considered.

Description

Technical Field

[0001] This invention relates to the field of incremental data synchronization technology, and in particular to a method and system for incremental synchronization of AI programming assistant session data based on a local state library. Background Technology

[0002] Incremental data synchronization technology involves identifying, extracting, transmitting, verifying, and updating changed data content across multiple storage nodes, terminal devices, servers, or distributed environments, so that different data copies remain consistent while reducing redundant transmissions.

[0003] Existing incremental data synchronization typically focuses on identifying data differences between multiple storage nodes, terminal devices, or servers. It performs incremental extraction, transmission, verification, and updating only after detecting added, deleted, or modified content. Its core objective is primarily to reduce redundant data transmission and maintain consistency across different data copies. However, in AI programming assistant scenarios, code content, cursor positions, compilation diagnostics, file switching, and session context in the development environment exhibit continuous changes. If synchronization is still initiated only after a fixed period, data change event, or user request, state detection, difference extraction, and network transmission tend to occur near the interaction request. This means that even after the user submits a prompt, they still need to wait for the latest context to be synchronized, directly adding network latency and state processing time to the AI ​​response time. Furthermore, traditional incremental synchronization often determines the transmission range based on whether data has changed, paying insufficient attention to the semantic relationship between changed data and the current query's purpose. For example, when multiple files in a project are modified simultaneously, code changes unrelated to the current error location may also enter the incremental set, causing the synchronized data scale to continuously expand and the cloud-based AI model to receive a large amount of irrelevant context. As development sessions continue, continuous incremental updates accumulate over time in the cloud. If the data is primarily overwritten chronologically, older data is directly deleted, or all historical data is continuously retained, the first two approaches risk losing historical relationships that still have inference value, while the latter may rapidly deplete the model context token budget. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing an incremental synchronization method and system for AI programming assistant session data based on a local state library.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: an incremental synchronization method for AI programming assistant session data based on a local state library, comprising the following steps:

[0006] Collect developer interaction data and code status data, and write them to the local status database;

[0007] Based on the developer interaction behavior data and the code state data, the AI ​​assistant wake-up probability and question intent category are determined by a hidden Markov model.

[0008] Based on the question intent category, trim the AST subgraph associated with the edit position in the code knowledge graph to obtain the intent context set;

[0009] The intent context set is compared with the cloud state to generate incremental data;

[0010] When the AI ​​assistant wake-up probability reaches the prefetch threshold, the incremental data is prefetched to the cloud cache during the idle period of the bidirectional WebSocket connection.

[0011] Budget-aware cache control is performed based on the token occupancy in the cloud cache and the correlation between the micro-incremental data and the edit position to obtain a controlled prefetch context;

[0012] Upon receiving the prompt word submission, the controlled prefetch context and the prompt word are combined and sent to the AI ​​model to obtain a response; the Hidden Markov Model is updated based on the prompt word submission result, model parameter increments are generated, and federated aggregation parameters are synchronized.

[0013] Preferably, the steps for collecting developer interaction behavior data and code state data and writing them into the local state database are as follows:

[0014] Within a preset sliding time window, keystroke timestamps, cursor positions, cursor dwell time, file switching events, compilation events, and AI assistant call events are collected, and the developer interaction behavior data is formed according to the event time.

[0015] Monitor the contents of project files, abstract syntax tree, symbol table, function call relationships, terminal diagnostic information, and version control differences, and form the code status data according to the change time;

[0016] An index is established using code entity identifiers, event times, and state versions. The developer interaction behavior data and the code state data are written into the local state database, and a consecutive version number is recorded for each code state change.

[0017] Preferably, the steps for determining the AI ​​assistant's wake-up probability and question intent category using a Hidden Markov Model based on the developer interaction behavior data and the code state data are as follows:

[0018] Keystroke frequency, cursor dwell time, file switching frequency, and number of consecutive compilation failures are extracted from the developer interaction behavior data. Diagnostic types, code entity types corresponding to the editing positions, and changes in call relationships are extracted from the code status data to form an observation feature sequence.

[0019] Set the state of not being ready to ask for help as the non-ask-for-help hidden state, and set the states of preparing to explain code, preparing to fix defects, and preparing to generate unit tests as the three ready-to-ask-for-help hidden states. Input the observed feature sequence into the hidden Markov model and calculate the posterior probability of each hidden state.

[0020] The posterior probabilities of the three ready-to-help hidden states are summed to obtain the AI ​​assistant wake-up probability. The category corresponding to the hidden state with the largest posterior probability value among the three ready-to-help hidden states is determined as the questioning intent category.

[0021] Preferably, the step of obtaining the intent context set by trimming the AST subgraph associated with the edit position in the code knowledge graph according to the question intent category is as follows:

[0022] The code knowledge graph is constructed based on the abstract syntax tree, symbol table, and function call relationships in the code state data. The nodes of the code knowledge graph include files, functions, parameters, return values, diagnostic locations, and test cases. The graph edges include inclusion relationships, function call relationships, definition reference relationships, and test relationships.

[0023] When the question intent category is to prepare to fix defects, the target diagnostic function is determined with the diagnostic position corresponding to the editing position as the center, and the function call relationship is traced back two levels to the caller to extract the signature, diagnostic information and data dependency statement of the target diagnostic function and the traced function;

[0024] When the question intent category is to prepare to generate unit tests, the parameter structure, return value structure, and associated test cases within the same file of the target function are extracted, with the target function corresponding to the editing position as the center.

[0025] When the question intent category is to prepare to explain code, the definition, direct call relationship, and direct called relationship of the target code entity are extracted with the target code entity corresponding to the editing position as the center. The intent context set is composed of the nodes, graph edges and code fragments that are trimmed and retained in the code knowledge graph.

[0026] Preferably, the step of comparing the intent context set with the cloud state to generate incremental data specifically includes:

[0027] Read the local state version of each code entity in the intent context set and the cached version of the corresponding code entity in the cloud state, and compare the local state version and the cached version;

[0028] For code entities with inconsistent versions, new code snippets, deleted code snippets, modified code snippets, and graph edge changes are extracted according to the state version order in the local state library to form a state difference set;

[0029] The state difference set is encapsulated according to the code entity identifier, state version, change type, change content, question intent category, and edit position to obtain the micro-incremental data.

[0030] Preferably, when the AI ​​assistant wake-up probability reaches the prefetch threshold, the step of prefetching the incremental data to the cloud cache during the idle period of the bidirectional WebSocket connection specifically involves:

[0031] Based on the historical AI assistant call records in the local state database, the AI ​​assistant wake-up probability sample before the actual call is statistically analyzed, and the preset quantile value of the AI ​​assistant wake-up probability sample is determined as the pre-fetch threshold.

[0032] The send queue and uplink bandwidth utilization of the bidirectional WebSocket connection are detected, and the idle period of the bidirectional WebSocket connection is determined when the send queue is empty and the uplink bandwidth utilization does not exceed a preset idle threshold.

[0033] When the AI ​​assistant wake-up probability reaches the prefetch threshold, a continuous incremental sequence number is generated for the micro-incremental data, and the micro-incremental data is sent to the cloud cache according to the continuous incremental sequence number. The unconfirmed micro-incremental data is determined according to the confirmed incremental sequence number returned by the cloud, and only the unconfirmed micro-incremental data is retransmitted.

[0034] Preferably, the step of performing budget-aware cache control based on the token occupancy in the cloud cache and the correlation between the incremental data and the edit position to obtain the controlled prefetch context specifically includes:

[0035] The number of tokens for each micro-incremental data in the cloud cache is counted to obtain the token usage. When the token usage reaches 80% of the AI ​​model context token budget, the budget-aware cache control is triggered.

[0036] The character distance and the number of shortest path layers in the AST between each incremental data point and the edit position are normalized respectively. The correlation between each incremental data point and the edit position is calculated using the following formula: ,in This represents the correlation between the j-th incremental data and the edit position. Indicates the sequence number of the incremental data. Indicates the normalized character distance. This represents the number of layers in the normalized AST shortest path;

[0037] The incremental data are selected in ascending order of the correlation value. Natural language summaries are generated through a semantic compression model and the corresponding incremental data are replaced until the token usage drops below 70% of the AI ​​model context token budget. The controlled prefetch context is composed of the incremental data that has not been replaced and the natural language summaries.

[0038] Preferably, the specific steps for responding to the prompt word submission, combining the controlled prefetch context with the prompt word, and sending it to the AI ​​model to obtain a response are as follows:

[0039] Receive the prompt word submitted by the developer, read the latest status version of the prompt word at the time of submission from the local status database, and read the latest cached version from the cloud cache.

[0040] When the latest state version is consistent with the latest cache version, the controlled prefetch context and the prompt word are combined to form a model request;

[0041] When the latest state version is inconsistent with the latest cached version, the latest state version and the latest cached version are compared, the unsynchronized state differences are extracted, supplementary micro-incremental data is generated, and the supplementary micro-incremental data is appended to the controlled prefetch context and combined with the prompt word to form the model request;

[0042] The model request is sent to the AI ​​model, the response is received, and the prompt word and the response are written to the local state database.

[0043] Preferably, the steps of updating the Hidden Markov Model based on the prompt word submission results, generating model parameter increments, and synchronizing the federated aggregation parameters are as follows:

[0044] After the AI ​​assistant wake-up probability reaches the pre-fetching threshold, a training feature sequence is formed based on the developer interaction behavior data and the code status data in the preset observation window. The actual questioning intent category is determined based on the submitted prompt words. The corresponding training feature sequence is marked as the actual questioning intent category. The training feature sequence that has not submitted prompt words is marked as not ready to ask for help, thus forming a local label.

[0045] The initial state probability, state transition probability, and observation probability of the Hidden Markov Model are updated based on the local labels. The model parameters before and after the update are compared to obtain the model parameter increment.

[0046] The model parameter increments are subjected to norm pruning and differential privacy noise is added. The model parameter increments are uploaded during the idle period of the bidirectional WebSocket connection. The cloud federated learning server aggregates the model parameter increments from at least two local devices to obtain the federated aggregated parameters.

[0047] The federated aggregation parameters are received, written into the local state database, and the hidden Markov model is updated. The uploaded data of the model parameter increment does not include the developer interaction behavior data and the code state data.

[0048] The present invention also provides a system comprising:

[0049] The data acquisition module collects developer interaction data and code status data, and writes them to the local status database;

[0050] The intent prediction module, based on the developer interaction behavior data and the code state data, determines the AI ​​assistant wake-up probability and question intent category through a hidden Markov model;

[0051] The context trimming module trims the AST subgraph associated with the edit position in the code knowledge graph according to the question intent category to obtain the intent context set;

[0052] The incremental generation module compares the intent context set with the cloud status to generate incremental data.

[0053] When the AI ​​assistant wake-up probability reaches the prefetch threshold, the background prefetch module uses the idle period of the bidirectional WebSocket connection to prefetch the incremental data to the cloud cache.

[0054] The cache control module performs budget-aware cache control based on the token occupancy in the cloud cache area and the correlation between the micro-incremental data and the editing position to obtain a controlled prefetch context;

[0055] The request-response module submits a response prompt by combining the controlled prefetch context with the prompt and sending it to the AI ​​model to obtain a response.

[0056] The parameter update module updates the Hidden Markov Model based on the prompt word submission results, generates model parameter increments, and synchronizes the federated aggregation parameters.

[0057] Compared with the prior art, the advantages and positive effects of the present invention are as follows:

[0058] This invention continuously collects developer interaction data and code state data and writes them into a local state database. This creates a continuously traceable data foundation for operational behaviors, code changes, and context states in the development environment. Based on developer interaction data and code state data, it determines the AI ​​assistant's wake-up probability and question intent category. This shifts the data synchronization trigger condition from a fixed period or a passive response after prompt word submission to a pre-judgment based on development behavior state. Furthermore, it prunes the code knowledge graph and AST subgraph associated with the editing location according to the question intent category. This shrinks the synchronized data from complete project data or broadly dependent data to an intent context set directly related to the current editing location and expected question type. This reduces the probability of irrelevant code entering the synchronization link while improving the matching degree between context and subsequent AI inference needs. By comparing the intent context set with the cloud state, it generates incremental data. Transmission is only performed on valid contexts that have changed between local and cloud environments. When the AI ​​assistant wake-up probability reaches a pre-fetch threshold, the incremental data is pre-fetched during the idle period of a bidirectional WebSocket connection. This allows idle network resources to bear the state synchronization pressure originally concentrated after prompt word submission, shortening the waiting time between prompt word submission and the AI ​​model obtaining valid context. By combining the token usage in the cloud cache with the correlation between incremental data and the editing position, budget-aware cache control is implemented. During the continuous accumulation of context, data closely related to the current programming task is prioritized, while data with weaker correlation is compressed, creating a dynamic balance between historical context continuity and AI model context capacity constraints. After the prompt word is submitted, the controlled prefetch context is directly combined for inference, and the intent prediction parameters are updated in reverse based on the actual prompt word submission results. Federated aggregation parameters continuously correct the prediction patterns corresponding to different developer behaviors, forming a closed loop of prefetch triggering, context selection, incremental transmission, cache control, and prediction updates. This balances real-time synchronization, transmission efficiency, token resource utilization, context effectiveness, and personalized prediction accuracy. Attached Figure Description

[0059] Figure 1 This is a schematic diagram of the steps of the present invention. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0061] The following detailed implementation of the incremental synchronization method for AI programming assistant session data based on a local state database further illustrates this approach. This implementation uses a local integrated development environment (IDE) that integrates the AI ​​programming assistant as the implementation environment. A continuous communication connection is established between the local IDE and the cloud-based AI service. The local side stores developer actions, code state, context version, and model parameters, while the cloud side stores the pre-fetched code context and corresponding state version. By identifying the request for help intent before the developer actually submits the prompt and performing micro-incremental synchronization on the code context associated with the predicted intent, the cloud can pre-form the context state for model inference. Simultaneously, token budget control and federated parameter updates maintain synchronization efficiency and intent recognition accuracy over long-term use.

[0062] Please see Figure 1 This invention provides a technical solution for incremental synchronization of AI programming assistant session data based on a local state library, comprising the following steps:

[0063] In this embodiment, a local state database is established after the local integrated development environment starts. This database uses a data structure that supports key-value indexing and version lookup to store developer operation events, the current state of project code entities, dependencies between code entities, AI assistant call records, cloud-confirmed status versions, and Hidden Markov Model parameters. Different types of data in the local state database are appended with event timestamps or version numbers, allowing changes to the same code entity at different points in time to be restored chronologically, thus providing a foundation for subsequent micro-increment extraction.

[0064] Collect developer interaction data and code status data, and write them to the local status database;

[0065] In practice, after a developer opens a project file and begins editing, the local integrated development environment continuously monitors keyboard input, cursor movement, cursor position, file switching, compilation and execution, terminal errors, and AI assistant calls. Simultaneously, it monitors source code files, abstract syntax trees, symbol resolution results, and version control differences. The collected data is not immediately and completely uploaded to the cloud; instead, it is written to a local state database according to the event occurrence time and code state version. This ensures that subsequent intent judgments and incremental generation can be completed locally first, reducing the frequent entry of raw development behavior data and complete code content into the network link.

[0066] Based on developer interaction behavior data and code status data, the probability of AI assistant activation and the category of questioning intent are determined by a hidden Markov model.

[0067] In practice, the continuously collected behaviors and code states are aggregated within a time window. The developer's keystroke frequency, cursor dwell time, file switching frequency, number of consecutive compilation failures, current diagnostic type, and the code entity they are in within the current time period are converted into an observation feature sequence that can be processed by a Hidden Markov Model. The model outputs the posterior probability of the developer being in different hidden states: not ready to ask for help, ready to explain code, ready to fix defects, and ready to generate unit tests. The AI ​​assistant activation probability is determined based on the sum of the probabilities corresponding to multiple ready-to-ask-help states, and the current question intent category is determined based on the highest probability among the ready-to-ask-help states. For example, when there are two consecutive compilation failures and the cursor remains inside the error-reporting function, the probability of being ready to fix defects is usually higher than in other ready-to-ask-help states.

[0068] Based on the question intent category, trim the AST subgraph associated with the edited location in the code knowledge graph to obtain the intent context set;

[0069] In practice, the pruning scope is determined based on the predicted question intent category. The local state library maintains a code knowledge graph using an abstract syntax tree, symbol table, and function call relationships. The developer's current editing position serves as the pruning starting point, and different question intents employ different graph traversal conditions. When the prediction leans towards defect fixing, the focus is on retaining the error location, the function it belongs to, the parent function that calls it, and code content with data dependencies on the error statement. When the prediction leans towards generating unit tests, the focus is on retaining the target function's parameters, return value, and existing test cases in the project. When the prediction leans towards interpreting the code, the focus is on retaining the definition of the target code entity and its direct call relationships. This forms a set of intent contexts that match the current predicted intent.

[0070] Compare the intent context set with the cloud state to generate incremental data;

[0071] In practice, the local state database stores the current local state version for each code entity in the intent context set, while also storing the most recently confirmed cached version in the cloud. By comparing the two versions, the database determines the data already existing in the cloud and the newly generated data. Only for code entities whose versions have changed, the database extracts newly added, deleted, and modified content, as well as changes in knowledge graph relationships, forming micro-incremental data. For example, if the current local target function version is V108, and the cloud-confirmed version is V106, then the local state database reads the state changes between V106 and V108, without resending the complete function content that was synchronized before V106.

[0072] When the AI ​​assistant wake-up probability reaches the prefetch threshold, the incremental data is prefetched to the cloud cache during the idle period of the bidirectional WebSocket connection.

[0073] In practice, the local state database determines the prefetch threshold based on historical AI assistant call records. When the AI ​​assistant wake-up probability reaches the prefetch threshold, it indicates that the current operation sequence has obvious characteristics of an impending request for help. At this point, it checks whether the bidirectional WebSocket connection is idle. If there are no higher-priority business messages and the uplink bandwidth utilization is within the allowable prefetch range, incremental data is sent in advance before the developer actually submits the prompt words. After receiving the data, the cloud temporarily stores it in the cloud cache corresponding to the current development session, rather than directly triggering AI model inference.

[0074] Budget-aware cache control is performed based on the token usage in the cloud cache and the correlation between incremental data and the editing position to obtain a controlled prefetch context;

[0075] In practice, the cloud cache continuously counts the number of tokens generated from each batch of incremental data after conversion into model context. When the cache size approaches the acceptable context token budget for the AI ​​model, the correlation between different incremental data and the current editing position is further calculated. Incremental data that are close to the current editing position and have a strong relationship in the AST structure are given priority in retaining the original code content, while incremental data that are far away and have a weaker structural relationship are semantically compressed to form a natural language summary, thereby reducing token consumption while preserving historical semantic clues.

[0076] Upon receiving the prompt, the controlled prefetch context and the prompt are combined and sent to the AI ​​model to obtain a response. The Hidden Markov Model is updated based on the prompt submission result, and the model parameter increments are generated and the federated aggregation parameters are synchronized.

[0077] In practice, once the developer actually inputs and submits the prompt, the cloud cache typically already stores the controlled prefetch context corresponding to the current development state, eliminating the need to wait for the complete project context to be uploaded again. The system only checks whether there is a difference between the local version and the cloud cached version in the last segment of the state before submission. If there is no difference, the controlled prefetch context and the prompt are directly combined into a model request; if there is a difference, the corresponding micro-incremental data is added to form the model request. After the AI ​​model returns a response, the local side determines whether the previous intent prediction was hit based on the actual submission result and uses the relevant training samples to update the local Hidden Markov Model. The difference in parameters before and after the update is used as the model parameter increment, which, after privacy protection processing, enters the federated aggregation process, enabling different devices to exchange only the changes in model parameters without exchanging the original code content.

[0078] The specific steps for collecting developer interaction behavior data and code state data and writing them to the local state database are as follows:

[0079] In this embodiment, developer interaction data and code status data use different data recording structures. Developer interaction data focuses on describing development operations that occur continuously over time, while code status data focuses on describing changes to project files and code entities. The two types of data are correlated through a unified event timeline, enabling the model to determine the code status corresponding to a given operation.

[0080] Collect keystroke timestamps, cursor position, cursor dwell time, file switching events, compilation events, and AI assistant call events within a preset sliding time window, and form developer interaction behavior data according to the event time;

[0081] In practice, the preset sliding time window can be set to 30 seconds, with the window sliding forward once every 5 seconds. Each time the window updates, events occurring within the window are statistically analyzed. Keystroke timestamps are used to calculate keystroke frequency and pause distribution; cursor position is used to identify the current code entity; cursor dwell time is used to determine if the developer is continuously analyzing a specific code location; file switching events reflect whether the developer is frequently searching for dependent files; compilation events identify compilation success or failure; and AI assistant invocation events generate the actual help labels needed for model training. These events are then sorted by millisecond-level timestamps to form developer interaction behavior data.

[0082] Monitor project file content, abstract syntax tree, symbol table, function call relationships, terminal diagnostic information, and version control differences, and generate code status data according to the change time;

[0083] In practice, whenever a developer saves a file, edits statements, or compiles a project, the current file content is parsed and the abstract syntax tree is refreshed. The symbol table and function call relationships provided by the language service are read, and terminal diagnostic information is associated with the corresponding file path, line of code, and code entity. Version control differences are used to assist in determining newly added, deleted, and modified code sections in the file. For the same code entity, a new code state record is only generated when the parsing result changes; unchanged code entities continue to reference the existing state version.

[0084] An index is created based on code entity identifier, event time, and state version. Developer interaction data and code state data are written to the local state database, and a consecutive version number is recorded for each code state change.

[0085] In practice, code entity identifiers are generated by combining project identifiers, file paths, and internal entity identifiers. Event timestamps are used to associate behavioral data with state data, and state versions use monotonically increasing consecutive serial numbers. For example, the target function `calculateTotal` corresponds to version V100 when it is first loaded, is written to V101 after a modification to the function body, and is written to V102 after a modification to the function parameters. Consecutive version numbers allow subsequent queries to directly look up the state changes that have occurred based on the interval between two version numbers, without needing to rescan the entire file.

[0086] Based on developer interaction behavior data and code state data, the specific steps for determining the AI ​​assistant's wake-up probability and question intent category using a Hidden Markov Model are as follows:

[0087] In this embodiment, a Hidden Markov Model (HMM) is used to describe the continuous temporal transition of a developer from normal coding to a state of preparing for help. Adjacent sliding time windows correspond to adjacent observation times, and the state transition probability limits the abrupt changes of the hidden state over continuous time, ensuring that a single accidental compilation failure or short pause will not directly trigger prefetching.

[0088] Keystroke frequency, cursor dwell time, file switching frequency, and number of consecutive compilation failures are extracted from developer interaction behavior data. Diagnostic types, code entity types corresponding to editing positions, and changes in call relationships are extracted from code status data to form an observation feature sequence.

[0089] In practice, a set of observation features is generated for each sliding time window. For example, keystroke frequency is calculated by dividing the number of effective keystrokes within the window by the window duration; cursor dwell time is the duration during which the current editing position remains relatively stable without significant movement; file switching frequency is the number of times file focus is switched within the window; and the number of consecutive compilation failures is accumulated from the most recent successful compilation. Diagnostic types can be mapped to discrete features such as empty diagnostics, syntax diagnostics, type diagnostics, and runtime diagnostics; code entity types can be mapped to categories such as functions, classes, parameters, and expressions; and the change in call relationships represents the number of function call edges added or deleted within the current window.

[0090] Set the unprepared to ask for help hidden state as the non-ask-for-help hidden state, and set the prepared to explain code, prepare to fix defects, and prepare to generate unit tests as the three prepared to ask for help hidden states. Input the observed feature sequence into the hidden Markov model and calculate the posterior probability of each hidden state.

[0091] In practice, the Hidden Markov Model's state set is fixed at four hidden states. Forward probability calculation is performed on the currently observed feature sequence, and the posterior probability of each hidden state is obtained by combining the existing state transition probabilities and observation probabilities. When compilation fails repeatedly, diagnostic information persists, and the cursor is near the diagnostic location, the probability of preparing to repair the defect increases; when lingering for a long time in a complex function without errors and frequently checking the caller, the probability of preparing to interpret the code increases; when creating a new test file and continuously checking the target function parameters, the probability of preparing to generate unit tests increases.

[0092] The posterior probabilities of the three ready-to-help hidden states are summed to obtain the AI ​​assistant wake-up probability. The category corresponding to the hidden state with the largest posterior probability value among the three ready-to-help hidden states is determined as the question intent category.

[0093] In practice, for example, if the posterior probabilities of not being ready to ask for help, being ready to explain code, being ready to fix defects, and being ready to generate unit tests are calculated to be 0.16, 0.12, 0.61, and 0.11 respectively at a certain moment, then the AI ​​assistant's wake-up probability is 0.84, and the intention to fix defects is determined as the question intent category. If the prefetch threshold obtained from historical statistics is 0.78, then the micro-incremental prefetching process begins at that moment.

[0094] Table 1. Example results of Hidden Markov Model intent recognition

[0095] Normal continuous encoding 0.83 0.07 0.06 0.04 0.17 Long-running read function 0.21 0.58 0.12 0.09 0.79 Continuous compilation failures 0.16 0.12 0.61 0.11 0.84 Create a new test file 0.18 0.09 0.13 0.60 0.82

[0096] As shown in Table 1, in normal continuous coding scenarios, the probability of not being ready to ask for help is dominant, and the probability of AI assistant wake-up remains low, without triggering prefetching. In scenarios such as reading functions for a long time, continuous compilation failures, and creating new test files, the probability of being ready to ask for help increases, and the probability of AI assistant wake-up is close to or exceeds the example prefetching threshold, thus enabling the developer to judge potential help needs in advance based on continuous behavior.

[0097] The specific steps for obtaining the intent context set by trimming the AST subgraph associated with the edited location in the code knowledge graph according to the question intent category are as follows:

[0098] In this embodiment, the code knowledge graph is not used to store complete copies of the code, but rather to establish structural relationships between code entities that can be traversed quickly. The abstract syntax tree provides the internal syntax hierarchy of the file, the symbol table provides definition and reference mappings, and the function call relationship provides cross-function dependency directions. Together, these three determine the range of subgraphs that need to be prefetched.

[0099] A code knowledge graph is constructed based on the abstract syntax tree, symbol table, and function call relationships in the code state data. The nodes of the code knowledge graph include files, functions, parameters, return values, diagnostic locations, and test cases. The graph edges include inclusion relationships, function call relationships, definition reference relationships, and test relationships.

[0100] In practice, the project file serves as the upper-level node, connecting function, function parameter, and return value nodes within the file through inclusion relationships. Function call relationships are established based on the call results generated by static analysis; definition reference relationships between variables and function symbols are established based on the symbol table; and test relationships are established based on the target function calls in the test file. When terminal diagnostic information appears, a diagnostic location node is created, and the diagnostic location is connected to the corresponding code entity. Each graph node stores the corresponding code entity identifier and status version, enabling direct association between the graph structure and the code content in the local state library through identifiers.

[0101] When the question intent category is to prepare to fix defects, the target diagnostic function is determined with the diagnostic position corresponding to the editing position as the center, and the function call relationship is traced back two levels to the caller to extract the signature, diagnostic information and data dependency statements of the target diagnostic function and the traced function;

[0102] In practice, for example, if the diagnostic location is inside the `parseOrder` function, then `parseOrder` is identified as the target diagnostic function. The first-level calling function of `parseOrder`, `processOrder`, is queried, followed by the second-level calling function of `processOrder`, `handleRequest`. Synchronized content prioritizes retaining the function signatures of these three functions and analyzes the data dependency statements corresponding to variables referenced by error statements and their return values. Local variable definitions without data dependencies and located in other branches are not included in the intent context set, thereby limiting the prefetching scope of defect repair scenarios.

[0103] When the question's intent category is to prepare for generating unit tests, extract the parameter structure, return value structure, and associated test cases within the same file of the target function, centered on the target function corresponding to the editing location.

[0104] In practice, for example, if the target function is `calculateDiscount`, the function's parameter names, parameter types, default values, return type, and exception conditions are extracted. Then, test cases that already reference `calculateDiscount` in the current test file are queried. Existing test cases can serve as context examples when generating new test code from the model, allowing the model to maintain the project's existing assertion formats, test naming conventions, and data construction style, while avoiding loading irrelevant business functions.

[0105] When the question intent category is to prepare to explain the code, the definition, direct call relationship, and direct called relationship of the target code entity corresponding to the editing position are extracted as the center. The intent context set is composed of the nodes, graph edges and code fragments that are trimmed and retained in the code knowledge graph.

[0106] In practice, only nodes with a one-hop direct relationship to the target code entity are expanded, without recursively expanding the entire call graph without boundaries. For example, if the target code entity is the function `buildCacheKey`, then the function definition, the hash function and serialization function directly called by the function, the upper-level function that directly calls `buildCacheKey`, and the corresponding graph edges are retained. The resulting nodes, graph edges, and code fragments are organized according to the code entity identifier to form an intent context set.

[0107] The specific steps for generating incremental data by comparing the intent context set with the cloud state are as follows:

[0108] In this embodiment, the cloud status is not read again from the cloud code repository, but rather indicates the version of the code entity that has been confirmed and received in the cloud cache corresponding to the current development session. Each time the cloud successfully receives incremental data, the latest version number is returned to the local machine, enabling the local state database to save the cloud confirmation status of each code entity.

[0109] Read the local state version of each code entity in the intent context set and the cached version of the corresponding code entity in the cloud state, and compare the local state version and the cached version;

[0110] In practice, the code entity identifier is used as the query key to read the local state version and the cached version confirmed by the cloud. If the two are the same, it is considered that the code entity does not need to be synchronized again; if the local state version is greater than the cached version, it is considered that there are data changes that have not yet been sent or confirmed after the cached version, and the state difference extraction process is initiated.

[0111] For code entities with inconsistent versions, extract newly added code snippets, deleted code snippets, modified code snippets, and graph edge changes based on the state version order in the local state library to form a set of state differences.

[0112] In practice, for the same code entity, intermediate change records are read according to consecutive version numbers. For example, if the cached version is V205 and the local state version is V208, then the state changes from V205 to V206, V206 to V207, and V207 to V208 are merged sequentially. Repeatedly modified segments are merged into the final modification result, and temporary codes that were added and then deleted are offset. Finally, a set of state differences that can be directly updated from V205 to V208 is generated to further reduce the amount of data transmitted.

[0113] Encapsulate the set of state differences according to code entity identifier, status version, change type, change content, question intent category, and edit location to obtain micro-incremental data.

[0114] In practice, each micro-increment record includes at least a code entity identifier, target state version, change type, change content, corresponding question intent category, and current editing position. Upon receiving the record, the cloud can locate the cached content based on the code entity identifier, apply add, delete, or modify operations according to the change type, and update the corresponding cached version based on the target state version.

[0115] When the AI ​​assistant wake-up probability reaches the prefetch threshold, the specific steps for prefetching incremental data to the cloud cache during the idle period of the bidirectional WebSocket connection are as follows:

[0116] In this embodiment, the prefetch threshold is not fixed and uses a uniform empirical value, but is based on local historical AI assistant call samples for statistical analysis, so that both the developer's frequent and infrequent use habits can form corresponding trigger boundaries.

[0117] Based on the historical AI assistant call records in the local state database, the AI ​​assistant wake-up probability sample before the actual call is statistically analyzed, and the preset quantile value of the AI ​​assistant wake-up probability sample is determined as the pre-fetch threshold.

[0118] In practice, the peak AI assistant wake-up probability within 30 seconds prior to the last 200 actual AI assistant calls is read to obtain a probability sample set. The 25th percentile of this probability sample set is then used as the prefetch threshold. This method covers the predicted probabilities that occur before most actual requests for help, while avoiding a threshold that is too low, causing a large number of ordinary coded states to trigger prefetching. In one example, the statistically obtained 25th percentile value is 0.78, therefore 0.78 is determined as the current prefetch threshold.

[0119] The send queue and uplink bandwidth utilization of the bidirectional WebSocket connection are detected. The idle period of the bidirectional WebSocket connection is determined when the send queue is empty and the uplink bandwidth utilization does not exceed the preset idle threshold.

[0120] In practice, the ratio of the actual uplink data volume in the last 2 seconds to the available uplink bandwidth is used as the uplink bandwidth utilization rate, and the preset idle threshold can be set to 20%. An empty sending queue indicates that there are currently no priority service messages such as prompt word requests and reply confirmations. An uplink bandwidth utilization rate of no more than 20% indicates that there is remaining transmission capacity in the current network link that can be pre-fetched by the backend.

[0121] When the AI ​​assistant wake-up probability reaches the prefetch threshold, a continuous incremental sequence number is generated for the micro-incremental data. The micro-incremental data is sent to the cloud cache according to the continuous incremental sequence number. The unconfirmed micro-incremental data is determined according to the confirmed incremental sequence number returned by the cloud, and only the unconfirmed micro-incremental data is retransmitted.

[0122] In practice, each development session maintains an independent consecutive incremental sequence number. For example, if increments 312, 313, and 314 are generated locally, and the cloud returns an acknowledged increment sequence number 313, then only 314 is retained locally as an increment awaiting acknowledgment. If the connection is briefly interrupted and then re-established, the unacknowledged increment 314 continues to be sent, without needing to resend the already acknowledged 312 and 313, thereby reducing the amount of redundant synchronization under network fluctuation conditions.

[0123] The specific steps for obtaining a controlled prefetch context by performing budget-aware cache control based on the token occupancy in the cloud cache and the correlation between incremental data and the edit position are as follows:

[0124] In this embodiment, the cloud cache maintains an independent token budget count for each development session. The token count is based on the word segmenter actually used by the AI ​​model, ensuring that the cache budget remains consistent with the actual context length of subsequent model requests.

[0125] The number of tokens for each micro-incremental data in the cloud cache is counted to obtain the token usage. Budget-aware cache control is triggered when the token usage reaches 80% of the AI ​​model context token budget.

[0126] In practical implementation, for example, if the AI ​​model allows a token budget of 32,768 tokens to be allocated to the code context, then budget-aware cache control will be triggered when the current prefetched context in the cloud cache reaches 26,214 tokens. Approximately 20% of the remaining capacity is reserved at 80% of the trigger locations to accommodate the final state changes and actual prompt content before the developer actually submits the prompt, thereby reducing the probability of exceeding the model window limit due to a sudden increase in context during submission.

[0127] Normalize the character distance and the number of shortest path layers in the AST for each incremental data point and the edit position, and calculate the correlation between each incremental data point and the edit position using the following formula: ,in This represents the correlation between the j-th incremental data and the edit position. Indicates the sequence number of the incremental data. Indicates the normalized character distance. This represents the number of layers in the normalized AST shortest path;

[0128] In practice, character distance is represented by the number of characters between the current editing position and the starting position of the micro-increment code fragment, and normalized to the range of 0 to 1 according to the maximum character distance in the current intent context set; the shortest path layer of the AST represents the minimum number of levels between the current editing code entity node and the micro-increment code entity node, and is also normalized to the range of 0 to 1 according to the maximum number of levels in the current set. For example, if the normalized character distance of a certain micro-increment data is 0.2 and the normalized AST shortest path layer is 0.3, then the correlation is 1 divided by 1.5, which is approximately 0.667; another micro-increment data has corresponding values ​​of 0.8 and 0.9, and the correlation is approximately 0.370. Therefore, the latter enters the compression candidate range earlier.

[0129] Micro-incremental data are selected in ascending order of relevance value. Natural language summaries are generated through a semantic compression model and the corresponding micro-incremental data are replaced until the token occupancy drops below 70% of the AI ​​model context token budget. The controlled prefetch context is composed of the micro-incremental data that has not been replaced and the natural language summaries.

[0130] In practice, semantic compression is performed starting with the data with the lowest relevance. The compression process preserves function names, key inputs and outputs, call results, and indirect relationships with the current task, while removing low-relevance code details from the complete function implementation. For a budget of 32,768 tokens, 70% corresponds to 22,937 tokens; therefore, compression continues until the token usage falls below 22,937 tokens. Recent and highly relevant code snippets retain their original form, while earlier and less relevant content is converted into natural language summaries. Both together form a controlled prefetching context.

[0131] Table 2. Token Budget-Aware Caching Control Example Results

[0132] No control triggered 24120 73.6% 24120 24120 0 Triggering conditions met 26430 80.7% 22860 21140 1720 Triggered again after continuous prefetching 26780 81.7% 22640 20580 2060

[0133] As can be seen from Table 2, compression is not performed when the token usage is below 80%. When the token usage reaches around 80%, the total token usage can be reduced to below 70% by prioritizing the compression of micro-incremental data with low relevance. At the same time, most of the original code content with high relevance to the current editing position is retained, and key semantic information in the early context is maintained through the summary.

[0134] The steps to respond to the prompt word submission, which involve sending the controlled prefetch context and the prompt word combination to the AI ​​model and obtaining a response, are as follows:

[0135] In this embodiment, the developer submits a prompt word, which corresponds to the transition from the prefetch phase to the formal inference phase. At this point, a state version verification needs to be performed to address any short-term code changes that may occur between the completion of the prefetch and the submission of the prompt word.

[0136] Receive the prompt words submitted by the developer, read the latest status version of the prompt words at the time of submission from the local status database, and read the latest cached version from the cloud cache.

[0137] In practice, after detecting the AI ​​assistant's submission event, the event time is used as the version verification time point. The local state library reads the latest state version of each code entity in the current intent context, the cloud cache reads the cached version of the confirmed application, and compares each code entity involved in the current intent context one by one.

[0138] When the latest state version and the latest cached version are consistent, the controlled prefetch context and prompt words are combined to form a model request;

[0139] In practice, the version consistency means that the local code state at the time of submission of the prompt is already fully included in the prefetch context. Therefore, no additional code upload is triggered. The controlled prefetch context is placed in the code context area according to the preset prompt template, and the developer prompt is placed in the user request area, forming a model request that can be directly sent into the AI ​​model.

[0140] When the latest state version is inconsistent with the latest cached version, compare the latest state version with the latest cached version, extract the unsynchronized state differences, generate supplementary micro-incremental data, and then append the supplementary micro-incremental data to the controlled prefetch context and combine it with the prompt words to form a model request.

[0141] In practice, for example, if the target function version is V410 when prefetching is complete, and the developer modifies a line of code before submitting the prompt to update the latest state version to V411, then the modifications between V410 and V411 are read, supplementary micro-incremental data is generated, and synchronized first. Since the supplementary data only covers short-term changes after prefetching, the data volume is usually significantly smaller than re-uploading the complete context.

[0142] Send the model request to the AI ​​model, receive the response, and write the prompt and response to the local state database.

[0143] In practice, after the AI ​​model completes inference, it returns code explanations, defect repair suggestions, or unit test code. The local integrated development environment associates the prompt words, reply text, submission time, and corresponding status version and writes them into the local status library, so that subsequent model training can determine whether an AI assistant call actually occurs after a certain prediction window and what the real question is about.

[0144] In a set of simulation tests, 100 development processes involving AI assistant calls were selected. When using the method of synchronizing context only after the request arrives, an average of 430 milliseconds were required to complete the context upload after the prompt was submitted. After adopting the prefetching process described above, the main context synchronization was completed in 82 of the calls before the prompt was submitted. After the prompt was submitted, only version verification or a small amount of supplementary incremental synchronization was required, resulting in an average additional synchronization time of 96 milliseconds. The above data illustrates that the prefetching mechanism can move some network transmission processes forward to the time interval before the developer formally asks a question, and does not limit the fixed response time in the actual product.

[0145] The specific steps for updating the Hidden Markov Model based on the prompt word submission results, generating model parameter increments, and synchronizing federated aggregation parameters are as follows:

[0146] In this embodiment, the prompt word submission result is used both to determine whether a genuine request for help has occurred and to ascertain the genuine intent to request help. The developer's specific keystroke logs and code content on different devices are not directly uploaded to the federated learning server; training sample construction and model parameter updates are only completed locally.

[0147] After the AI ​​assistant wake-up probability reaches the pre-fetch threshold, a training feature sequence is formed based on the developer interaction behavior data and code status data in the preset observation window. The actual questioning intent category is determined based on the submitted prompt words. The corresponding training feature sequence is marked as the actual questioning intent category, and the training feature sequence that has not submitted prompt words is marked as not ready to ask for help, thus forming a local label.

[0148] In practice, the preset observation window can be set to 60 seconds after the AI ​​assistant's wake-up probability reaches the pre-fetch threshold. If a developer submits a prompt within the observation window, the actual questioning intent category is determined based on the prompt's semantics and the AI ​​assistant's invocation entry point. For example, a prompt requesting an explanation of the current function's execution process is marked as "preparing to explain code," a prompt requesting a solution to a current terminal error is marked as "preparing to fix a defect," and a prompt requesting the creation of test cases for the target function is marked as "preparing to generate unit tests." If no prompt is submitted within 60 seconds, the trained feature sequence is marked as "not preparing to seek help." This establishes a supervised correspondence between prediction results and actual behavior.

[0149] The initial state probability, state transition probability, and observation probability of the Hidden Markov Model are updated based on the local labels. The model parameters before and after the update are compared to obtain the model parameter increment.

[0150] In practice, a parameter update is performed after a preset number of new training samples are accumulated locally. For example, local training is performed every 50 labeled observation sequences. After training, the differences between the initial state probability matrix, the state transition probability matrix, and the observation probability parameters before and after the update are calculated. These differences are then organized into model parameter increments according to the parameter positions. The training feature sequences themselves are not uploaded.

[0151] Norm pruning and differential privacy noise are added to the model parameter increments. The model parameter increments are uploaded during the idle period of the bidirectional WebSocket connection. The cloud federated learning server aggregates the model parameter increments from at least two local devices to obtain the federated aggregated parameters.

[0152] In practice, norm pruning is performed on the model parameter increments to limit the overall magnitude of parameter updates on a single device to a preset range. Random noise that meets a preset privacy budget is added to the pruning result to form the parameter increments to be uploaded. The upload process continues to reuse the idle period of the bidirectional WebSocket connection to avoid competing for transmission resources with prompt word requests. The cloud-based federated learning server only performs aggregation after receiving model parameter increments from at least two local devices in the same round, for example, by weighting the average based on the number of effective training samples from each device to obtain the federated aggregate parameters.

[0153] Receive federated aggregation parameters, write the federated aggregation parameters to the local state library and update the Hidden Markov Model. The uploaded data for incremental model parameters does not include developer interaction behavior data and code state data.

[0154] In practice, after receiving the federated aggregation parameters, the local device first associates the federated aggregation parameters with the currently effective model version and writes them into the local state database. In the next model update cycle, it switches to the new Hidden Markov Model parameters. Since the uploaded content consists only of the differences in the updated probability parameters, the server cannot directly obtain the source code, complete keystroke time series, cursor movement trajectory, or original terminal log text, thus keeping the model collaborative update and code state data synchronization separate.

[0155] Through the above implementation methods, the local state library serves as a continuous state storage and version index, the Hidden Markov Model (HMM) pre-determines the likelihood of AI assistant calls and question types based on continuous development behavior, code knowledge graph and AST subgraph pruning further limit the range of prefetched data, version comparison between local and cloud states ensures that the network link only carries micro-incremental data that has changed, WebSocket idle period prefetching moves part of the context synchronization process forward to before prompt word submission, token budget-aware cache control keeps the context size in long-term development sessions within the model's allowable range, and the actual prompt word submission results are used in turn for local model training and federated parameter aggregation. This forms a continuous closed-loop process from state acquisition, intent prediction, semantic pruning, incremental generation, background prefetching, cache control, model inference to prediction parameter updates, enabling the AI ​​programming assistant to maintain relatively timely context state synchronization even in continuous editing, frequent state changes, and long-context development scenarios.

[0156] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention in any other way. Any person skilled in the art may make changes or modifications to the above-disclosed technical content to create equivalent embodiments that can be applied to other fields. However, any simple modifications, equivalent changes, and modifications made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the protection scope of the present invention.

Claims

1. A method for incremental synchronization of AI programming assistant session data based on a local state library, characterized in that: Includes the following steps: Collect developer interaction data and code status data, and write them to the local status database; Based on the developer interaction behavior data and the code state data, the AI ​​assistant wake-up probability and question intent category are determined by a hidden Markov model. Based on the question intent category, trim the AST subgraph associated with the edit position in the code knowledge graph to obtain the intent context set; The intent context set is compared with the cloud state to generate incremental data; When the AI ​​assistant wake-up probability reaches the prefetch threshold, the incremental data is prefetched to the cloud cache during the idle period of the bidirectional WebSocket connection. Budget-aware cache control is performed based on the token occupancy in the cloud cache and the correlation between the micro-incremental data and the edit position to obtain a controlled prefetch context; Upon receiving the prompt word, the controlled prefetch context and the prompt word are combined and sent to the AI ​​model to obtain a response. The Hidden Markov Model is updated based on the submission results of the prompt words, and the incremental model parameters are generated and the federated aggregation parameters are synchronized.

2. The method for incremental synchronization of AI programming assistant session data based on a local state library according to claim 1, characterized in that, The specific steps for collecting developer interaction behavior data and code state data and writing them to the local state database are as follows: Within a preset sliding time window, keystroke timestamps, cursor positions, cursor dwell time, file switching events, compilation events, and AI assistant call events are collected, and the developer interaction behavior data is formed according to the event time. Monitor the contents of project files, abstract syntax tree, symbol table, function call relationships, terminal diagnostic information, and version control differences, and form the code status data according to the change time; An index is established using code entity identifiers, event times, and state versions. The developer interaction behavior data and the code state data are written into the local state database, and a consecutive version number is recorded for each code state change.

3. The method for incremental synchronization of AI programming assistant session data based on a local state library according to claim 1, characterized in that, Based on the developer interaction behavior data and the code state data, the specific steps for determining the AI ​​assistant wake-up probability and question intent category using a Hidden Markov Model are as follows: Keystroke frequency, cursor dwell time, file switching frequency, and number of consecutive compilation failures are extracted from the developer interaction behavior data. Diagnostic types, code entity types corresponding to the editing positions, and changes in call relationships are extracted from the code status data to form an observation feature sequence. Set the state of not being ready to ask for help as the non-ask-for-help hidden state, and set the states of preparing to explain code, preparing to fix defects, and preparing to generate unit tests as the three ready-to-ask-for-help hidden states. Input the observed feature sequence into the hidden Markov model and calculate the posterior probability of each hidden state. The posterior probabilities of the three ready-to-help hidden states are summed to obtain the AI ​​assistant wake-up probability. The category corresponding to the hidden state with the largest posterior probability value among the three ready-to-help hidden states is determined as the questioning intent category.

4. The method for incremental synchronization of AI programming assistant session data based on a local state library according to claim 1, characterized in that, The specific steps for obtaining the intent context set by trimming the AST subgraph associated with the edit position in the code knowledge graph according to the question intent category are as follows: The code knowledge graph is constructed based on the abstract syntax tree, symbol table, and function call relationships in the code state data. The nodes of the code knowledge graph include files, functions, parameters, return values, diagnostic locations, and test cases. The graph edges include inclusion relationships, function call relationships, definition reference relationships, and test relationships. When the question intent category is to prepare to fix defects, the target diagnostic function is determined with the diagnostic position corresponding to the editing position as the center, and the function call relationship is traced back two levels to the caller to extract the signature, diagnostic information and data dependency statement of the target diagnostic function and the traced function; When the question intent category is to prepare to generate unit tests, the parameter structure, return value structure, and associated test cases within the same file of the target function are extracted, with the target function corresponding to the editing position as the center. When the question intent category is to prepare to explain code, the definition, direct call relationship, and direct called relationship of the target code entity are extracted with the target code entity corresponding to the editing position as the center. The intent context set is composed of the nodes, graph edges and code fragments that are trimmed and retained in the code knowledge graph.

5. The method for incremental synchronization of AI programming assistant session data based on a local state library according to claim 1, characterized in that, The specific steps for generating incremental data by comparing the intent context set with the cloud state are as follows: Read the local state version of each code entity in the intent context set and the cached version of the corresponding code entity in the cloud state, and compare the local state version and the cached version; For code entities with inconsistent versions, new code snippets, deleted code snippets, modified code snippets, and graph edge changes are extracted according to the state version order in the local state library to form a state difference set; The state difference set is encapsulated according to the code entity identifier, state version, change type, change content, question intent category, and edit position to obtain the micro-incremental data.

6. The method for incremental synchronization of AI programming assistant session data based on a local state library according to claim 1, characterized in that, When the AI ​​assistant wake-up probability reaches the prefetch threshold, the specific step of prefetching the incremental data to the cloud cache during the idle period of the bidirectional WebSocket connection is as follows: Based on the historical AI assistant call records in the local state database, the AI ​​assistant wake-up probability sample before the actual call is statistically analyzed, and the preset quantile value of the AI ​​assistant wake-up probability sample is determined as the pre-fetch threshold. The send queue and uplink bandwidth utilization of the bidirectional WebSocket connection are detected, and the idle period of the bidirectional WebSocket connection is determined when the send queue is empty and the uplink bandwidth utilization does not exceed a preset idle threshold. When the AI ​​assistant wake-up probability reaches the prefetch threshold, a continuous incremental sequence number is generated for the micro-incremental data, and the micro-incremental data is sent to the cloud cache according to the continuous incremental sequence number. The unconfirmed micro-incremental data is determined according to the confirmed incremental sequence number returned by the cloud, and only the unconfirmed micro-incremental data is retransmitted.

7. The method for incremental synchronization of AI programming assistant session data based on a local state library according to claim 1, characterized in that, The specific steps for performing budget-aware cache control to obtain the controlled prefetch context based on the token occupancy in the cloud cache and the correlation between the micro-incremental data and the edit position are as follows: The number of tokens for each micro-incremental data in the cloud cache is counted to obtain the token usage. When the token usage reaches 80% of the AI ​​model context token budget, the budget-aware cache control is triggered. The character distance and the number of shortest path layers in the AST between each incremental data point and the edit position are normalized respectively. The correlation between each incremental data point and the edit position is calculated using the following formula: ,in This represents the correlation between the j-th incremental data and the edit position. Indicates the sequence number of the incremental data. Indicates the normalized character distance. This represents the number of layers in the normalized AST shortest path; The incremental data are selected in ascending order of the correlation value. Natural language summaries are generated through a semantic compression model and the corresponding incremental data are replaced until the token usage drops below 70% of the AI ​​model context token budget. The controlled prefetch context is composed of the incremental data that has not been replaced and the natural language summaries.

8. The method for incremental synchronization of AI programming assistant session data based on a local state library according to claim 1, characterized in that, The specific steps for responding to prompt word submission, combining the controlled prefetch context with the prompt word, and sending it to the AI ​​model to obtain a response are as follows: Receive the prompt word submitted by the developer, read the latest status version of the prompt word at the time of submission from the local status database, and read the latest cached version from the cloud cache. When the latest state version is consistent with the latest cache version, the controlled prefetch context and the prompt word are combined to form a model request; When the latest state version is inconsistent with the latest cached version, the latest state version and the latest cached version are compared, the unsynchronized state differences are extracted, supplementary micro-incremental data is generated, and the supplementary micro-incremental data is appended to the controlled prefetch context and combined with the prompt word to form the model request; The model request is sent to the AI ​​model, the response is received, and the prompt word and the response are written to the local state database.

9. The method for incremental synchronization of AI programming assistant session data based on a local state library according to claim 1, characterized in that, The specific steps for updating the Hidden Markov Model based on the prompt word submission results, generating model parameter increments, and synchronizing federated aggregation parameters are as follows: After the AI ​​assistant wake-up probability reaches the pre-fetching threshold, a training feature sequence is formed based on the developer interaction behavior data and the code status data in the preset observation window. The actual questioning intent category is determined based on the submitted prompt words. The corresponding training feature sequence is marked as the actual questioning intent category. The training feature sequence that has not submitted prompt words is marked as not ready to ask for help, thus forming a local label. The initial state probability, state transition probability, and observation probability of the Hidden Markov Model are updated based on the local labels. The model parameters before and after the update are compared to obtain the model parameter increment. The model parameter increments are subjected to norm pruning and differential privacy noise is added. The model parameter increments are uploaded during the idle period of the bidirectional WebSocket connection. The cloud federated learning server aggregates the model parameter increments from at least two local devices to obtain the federated aggregated parameters. The federated aggregation parameters are received, written into the local state database, and the hidden Markov model is updated. The uploaded data of the model parameter increment does not include the developer interaction behavior data and the code state data.

10. The system for incremental synchronization of AI programming assistant session data based on a local state library according to any one of claims 1-9, characterized in that, include: The data acquisition module collects developer interaction behavior data and code status data, and writes them to the local status database; The intent prediction module, based on the developer interaction behavior data and the code state data, determines the AI ​​assistant wake-up probability and question intent category through a hidden Markov model. The context trimming module trims the AST subgraph associated with the edit position in the code knowledge graph according to the question intent category to obtain the intent context set; The incremental generation module compares the intent context set with the cloud status to generate incremental data. When the AI ​​assistant wake-up probability reaches the prefetch threshold, the background prefetch module uses the idle period of the bidirectional WebSocket connection to prefetch the micro-incremental data to the cloud cache. The cache control module performs budget-aware cache control based on the token occupancy in the cloud cache area and the correlation between the micro-incremental data and the editing position to obtain a controlled prefetch context; The request-response module submits a response prompt by combining the controlled prefetch context with the prompt and sending it to the AI ​​model to obtain a response. The parameter update module updates the Hidden Markov Model based on the prompt word submission results, generates model parameter increments, and synchronizes the federated aggregation parameters.

Images