Specification driven encoding method and apparatus

Abstract

The embodiment of the specification relates to a specification driven coding method and device, and the method comprises the following steps: in response to a change operation of a user on a specification document, determining change content in the specification document; according to the change content, updating a corresponding specification graph, and determining a plurality of changed change requirement nodes; the specification graph contains a plurality of types of nodes, and corresponds to the semantics of the specification document; according to any first change requirement node, determining a plurality of first recall nodes with a high ranking relevance in the updated specification graph; according to the first change requirement node and the plurality of first recall nodes, determining a first change context; inputting the first change context into a large language model to perform a first update on a current code library.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of artificial intelligence, and more particularly to specification-driven coding methods and apparatus. Background Technology

[0002] With the rapid development of artificial intelligence technology, software development assisted by large language models (LLMs) has become an important means to improve R&D efficiency. Against this backdrop, related technologies have proposed Specification-Driven Coding (Spec Coding), which leverages the large language model to progressively generate technical documents, task descriptions, and ultimately code implementation based on the requirements specification documents written by developers. In this model, developers first write structured requirements specification documents. The system then parses the requirements, scenario descriptions, and constraints in the specification document, converting them into contextual information that the model can understand, thereby guiding the model to generate and deliver the code. This paradigm reduces the interaction cost between developers and the large language model, allowing requirement intent to be mapped more directly to executable code logic, and thus has attracted increasing attention and application from development teams.

[0003] However, several problems remain to be solved in these technologies. Firstly, they are largely limited to the "initial generation" scenario, lacking a mechanism to ensure bidirectional consistency between code and specifications during secondary modifications. As iterations deepen, semantic deviations between the specification documents and the actual code implementation are easily generated, leading to "document decay." Secondly, specification management systems typically employ a full-file parsing strategy, requiring re-parsing and processing of all specification documents with each operation, lacking an incremental processing mechanism for changed content. As project scale expands, the number and size of specification documents increase accordingly; full parsing not only consumes significant computing resources but also leads to a substantial increase in response latency. Furthermore, these technologies lack refined change models, making it difficult to support concurrent collaboration between multiple models. Therefore, a method is needed to perform specification-driven coding more efficiently and accurately. Summary of the Invention

[0004] This specification describes one or more embodiments of a specification-driven coding method and apparatus to maintain consistency between specification documents and code, compress context input, and support concurrent collaboration between multiple models.

[0005] Firstly, a standardized driver coding method is provided, including:

[0006] In response to a user's modification of the specification document, the modified content is determined in the specification document;

[0007] Based on the changes, the corresponding specification graph is updated, and several change requirement nodes are identified. The specification graph contains multiple types of nodes and corresponds to the semantics of the specification document.

[0008] Based on any first change requirement node, identify multiple first recall nodes in the updated specification graph that rank highly in terms of their relevance.

[0009] The first change context is determined based on the first change request node and multiple first recall nodes;

[0010] The first change context is input into the agent, which is then instructed to perform the first update on the current codebase.

[0011] In some possible implementations, determining the changes in the specification document includes:

[0012] Determine the content hash fingerprint of the revised specification document and compare it with the pre-stored historical hash fingerprint;

[0013] Based on the differences in the comparison results, identify the document segments in the specification document that have been changed.

[0014] In some possible implementations, the specification graph includes the following node types: demand nodes, specification nodes, and scenario nodes; each demand node has a corresponding specification node and several scenario nodes.

[0015] In some possible implementations, updating the corresponding canonical map includes:

[0016] Based on the changes, the corresponding nodes in the standard graph are identified, and then the node content of each node is updated.

[0017] In some possible implementations, the updating of the corresponding canonical map further includes:

[0018] For any change request node, its node name, node content, corresponding standard node ID, and the node content of each corresponding scenario node are concatenated to obtain the concatenated text.

[0019] The concatenated text is encoded using a text encoder to determine the representation vector corresponding to the change request node;

[0020] The vector index of the standard graph is updated based on the representation vector corresponding to each change requirement node.

[0021] In some possible implementations, each node in the canonical graph has a corresponding representation vector; the step of determining multiple first recall nodes with high relevance ranking in the updated canonical graph based on any first change requirement node includes:

[0022] For any first node in the specification graph, a first correlation score is determined between it and the first change request node; the first correlation score is determined based on the similarity of the representation vectors between the first node and the first change request node, and the weighted distance values ​​of the first node to each neighboring node in the specification graph.

[0023] The nodes with the highest relevance scores in the specified graph are identified as multiple first recall nodes.

[0024] In some possible implementations, the distance weighted value is determined by a weighted sum of the reciprocals of the distances between the first node and each of its neighboring nodes.

[0025] In some possible implementations, determining the first change context based on the first change request node and multiple first recall nodes includes:

[0026] Extract the summary of the node content of each first recall node to determine multiple first summary texts;

[0027] The first change context is determined by concatenating multiple first summary texts with the first constraint texts corresponding to each first recall node.

[0028] In some possible implementations, the text length of the first change context is less than a preset first threshold; the first threshold is related to the task type in the first change request node.

[0029] In some possible implementations, it also includes:

[0030] In response to a user's second modification to the specification document, the second modification content is determined in the specification document;

[0031] Concurrent conflict detection for the aforementioned change operation and the second change operation;

[0032] In response to a conflict in the detection result, the change operation and the second change operation are executed sequentially.

[0033] When the detection result is non-conflicting, the change operation and the second change operation are executed in parallel.

[0034] In some possible implementations, the concurrent conflict detection of the change operation and the second change operation includes:

[0035] If the object of the change operation and the second change operation are the same, and the types of the change operation and the second change operation are not interchangeable, the detection result is determined to be a conflict.

[0036] In response to the existence of a dependency between the changed object of the first change operation and the second change operation, the detection result is determined to be a conflict.

[0037] In some possible implementations, each requirement node in the specification graph has a corresponding representation vector, and the representation vector of any requirement node is determined based on its node name, node content, corresponding specification node ID, and corresponding scenario nodes; the method further includes:

[0038] Obtain the query vector obtained by encoding the user's query text using a text encoder;

[0039] Based on the similarity between the query vector and the respective representation vectors of each demand node, several recall demand nodes are determined.

[0040] In some possible implementations, it also includes:

[0041] In response to a user's second modification operation on the specification map, several second modification nodes in the specification map are determined;

[0042] The specification document is updated based on the aforementioned second change nodes.

[0043] Secondly, a standard-driven encoding device is provided, comprising:

[0044] The change determination unit is configured to determine the change content in the specification document in response to a user's change operation on the specification document;

[0045] The graph update unit is configured to update the corresponding specification graph according to the changes, and determine several change requirement nodes in the graph; the specification graph contains multiple types of nodes and corresponds to the semantics of the specification document.

[0046] The node recall unit is configured to determine, based on any first change request node, multiple first recall nodes with the highest relevance ranking in the updated specification graph.

[0047] The context determination unit is configured to determine the first change context based on the first change request node and multiple first recall nodes;

[0048] The code update unit is configured to input the first change context into the agent, causing it to perform a first update on the current codebase.

[0049] Thirdly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of the first aspect.

[0050] Fourthly, a computing device is provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method of the first aspect.

[0051] The specification-driven coding method and apparatus proposed in the embodiments of this specification are based on a bidirectional synchronization mechanism between specification documents and specification graphs. Modifications to the specification document are synchronized to the specification graph in real time, and modifications to specification graph nodes are updated back to the specification document, achieving real-time anchoring between the specification document and the logical implementation, thus preventing document corruption. Simultaneously, when modifying the codebase based on the updated specification document, only content highly relevant to the changed requirements is used as the input context for the intelligent agent (large language model), thereby improving the efficiency and accuracy of code generation. Attached Figure Description

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

[0053] Figure 1 A schematic diagram illustrating the process of standard driver coding in related technologies is shown;

[0054] Figure 2 A schematic diagram illustrating a scenario of a specification-driven coding method according to one embodiment is shown;

[0055] Figure 3 A flowchart illustrating a specification-driven coding method according to one embodiment is shown;

[0056] Figure 4 A database architecture diagram illustrating a storage specification diagram according to one embodiment is shown;

[0057] Figure 5 A schematic block diagram of a specification-driven encoding device according to one embodiment is shown. Detailed Implementation

[0058] The solution provided in this specification will now be described with reference to the accompanying drawings.

[0059] Specification-driven coding is an AI-based software development approach where developers no longer write code directly. Instead, they first write detailed specifications in natural language, and then an agent based on a large language model generates corresponding code, test cases, and documentation based on the specifications.

[0060] Typically, a complete process of specification-driven coding can include, for example, Figure 1 The stages shown.

[0061] During the specification phase, developers describe the requirements in natural language, typically in one sentence to a paragraph, such as: "Create a task management application that supports grouping by project, drag-and-drop sorting, and multi-user collaboration." Then, an AI agent asks follow-up questions and clarifies the requirements, followed by human verification that the requirements are understood correctly and have clear boundaries. This process generates a structured specification document (also known as a spec), which includes functional requirements, acceptance criteria, and so on.

[0062] Then, during the planning phase, the developers provide their preferred technology stack (e.g., "using Next.js + PostgreSQL"). The agent generates a technical solution based on the specification document, including: architecture diagram, data model, API (Application Programming Interface) contract, project structure, etc. Then, the technology selection is reviewed by the human team to see if it is reasonable and whether the architecture is in line with the team's habits.

[0063] Next, in the task decomposition phase, the agent breaks down the plan from the previous phase into multiple atomic tasks and labels each task with: involved files, dependencies, whether it can be parallelized, whether it is for testing or implementation, and the task granularity is reviewed by a human to ensure it is appropriate, the order is correct, etc.

[0064] Then, in the implementation phase, the agent executes each task one by one. After completing each task, it checks the box, submits the code, and moves on to the next task. Developers can pause, modify, and revert at any time, ultimately generating deliverables such as runnable code, test cases, and development documentation. Code review and end-to-end testing are then performed manually.

[0065] Finally, in the validation phase, the code artifacts are verified to meet the acceptance criteria in the specification document, and corresponding modifications are made.

[0066] A specification document typically includes at least two sections: Requirements and Scenarios. Requirements describe the behaviors the system must fulfill (e.g., two-step verification, session timeout, etc.). Requirements describe "what to do," not the code implementation details, but rather the externally observable behavior. A requirement usually corresponds to one or more scenarios, which are used to validate the specific use case of the requirement. For example, "When a user has enabled two-step verification, upon submitting valid verification information, a verification code should be sent to the user, and the login process should only be completed if the user enters the correct verification code."

[0067] As mentioned earlier, the specification-driven coding schemes in related technologies have many limitations and are difficult to support the transition of enterprise software from "single generation" to "continuous iteration".

[0068] Specifically, firstly, most existing technical solutions are limited to the initial generation scenario and lack a mechanism to ensure bidirectional consistency between code and specifications during secondary modifications. Existing specification-driven coding schemes cannot effectively detect semantic deviations between code and specifications when modifications are made. As the number of iterations increases, semantic deviations between the specification document and the actual code implementation gradually accumulate, leading to a "document decay" phenomenon—inconsistencies arise between the requirements described in the specification document and the actual functionality implemented in the code, thereby affecting the stability and compliance of the software system.

[0069] Secondly, when handling incremental modifications, existing systems often employ a crude full context injection strategy, leading to a significant waste of computational resources and a decrease in model inference accuracy. Specifically, when a specification document undergoes partial changes, existing solutions tend to indiscriminately input the entire specification document into the AI ​​model's input window, expecting the model to autonomously complete relevance retrieval and localization. This strategy has three drawbacks: First, a large amount of specification content irrelevant to the current task is included in the context, resulting in an exponential waste of token resources and significantly increasing the computational cost of model calls; second, an excessively large context makes it difficult for the AI ​​model to focus on key information during inference, causing the "Lost in the Middle" phenomenon, where the model's attention to key constraints located in the middle of the context is significantly reduced, leading to a decrease in code generation accuracy; third, the full context injection strategy cannot perform differentiated context filtering based on task type, as code generation tasks and dependency analysis tasks receive the same context content, making it impossible to achieve optimized context configuration.

[0070] Furthermore, existing technologies lack sophisticated change conflict detection models, making it difficult to support consistency guarantees in multi-agent concurrent collaboration scenarios. In large-scale software delivery, multiple agents are typically assigned to different modules or functions for parallel development. When multiple agents simultaneously modify the same specification document or specification documents with dependencies, existing solutions can only rely on the underlying file system's overwrite strategy to handle conflicts; that is, later writes overwrite earlier writes, resulting in lost changes. More seriously, existing solutions cannot identify semantic-level logical conflicts. For example, one agent deletes a specification entry for an interface definition, while another agent adds a description of that interface call elsewhere. Text-line-level difference comparison mechanisms cannot understand such semantic deviations, leading to logical errors in the actual content of the specification document and compromising data consistency in multi-agent collaboration.

[0071] Based on this, the embodiments of this specification propose a standard-driven coding method to overcome the above problems and generate code efficiently and accurately during continuous code iteration.

[0072] Figure 2 This diagram illustrates a scenario of a specification-driven coding method according to one embodiment. Figure 2 As shown, a specification document refers to a requirements specification file stored in text format, used to record various requirements, acceptance scenarios, and constraints during the software development process. Specification documents typically use structured formats such as Markdown for ease of reading and editing by developers. In the specification document, requirements refer to specific descriptions of system functions or behaviors, and scenarios refer to acceptance test cases or usage situations of that requirement under specific conditions.

[0073] A specification graph refers to the data representation of a specification document after deconstructing the linear text into a structured knowledge graph. The specification graph maintains data consistency with the specification document through a correspondence. The specification graph contains three types of nodes: specification nodes, corresponding to the relevant specification document; requirement nodes, representing specific requirement items in the specification document; and scenario nodes, representing the acceptance scenarios or usage conditions of the requirement items. In addition, the specification graph maintains a vector index to support semantic vector-based similarity retrieval.

[0074] During an iterative update of the code, when a user modifies the specification document, the first step is to identify the changes within the specification document. The changes refer to the specific text segments in the specification document that have been modified compared to their previous state, such as a change in the description of a requirement item, the addition of a scenario description, or the deletion of a requirement item. The modified document segments can be quickly located by comparing content hash fingerprints.

[0075] Once the changes are determined, they are synchronized to the specification graph, and node updates are performed. Specifically, the corresponding nodes in the specification graph are located based on the changes, and their respective content is updated. For example, if the changes involve modifying a requirement item, the corresponding requirement node can be found in the graph using the requirement item's unique identifier, and its text content field is updated. If the changes involve alterations to a scenario description, the corresponding scenario node is updated. Through node updates, the node data in the specification graph remains synchronized with the changes in the specification document.

[0076] After the node update is completed, the specification graph changes from its previous state to the current specification graph, and the specification document also changes from its previous state to the current specification document. The current specification document and the current specification graph continue to maintain a correspondence; that is, the text content in the current specification document is destructured to form the nodes and edges in the current specification graph.

[0077] Next, based on the current specification map, we will identify the change requirement nodes. Change requirement nodes refer to the requirement nodes in the current specification map that have undergone changes; that is, the various requirement nodes affected by this update operation. Change requirement nodes can be directly obtained from mapping the document fragments corresponding to the changed content, or they can be determined by comparing the differences between the current specification map and the specification map before the update.

[0078] Next, code updates will be performed for each change request node. Using any change request node as a baseline, a search will be conducted within the current specification graph to identify several recall nodes with high relevance. Recall nodes refer to other nodes in the current specification graph that have a high correlation with the change request node. These recall nodes are typically nodes that have dependencies on the change request node, semantically similar nodes, or nodes that are adjacent in the specification graph structure.

[0079] After identifying the change request node and multiple recall nodes, these are integrated to determine the change context corresponding to the change request. The change context refers to the contextual information input into the agent, guiding it to understand the background, constraints, and associated requirements of the current change. After determining the change context, it is input into the agent. Based on the core description of the change request node and the associated information of the recall nodes contained in the change context, the agent understands the intent and scope of the current change, and then updates the codebase accordingly, such as adding code, modifying existing code, or deleting obsolete code.

[0080] Through the aforementioned update process, changes to the specification document can be accurately propagated to the specification graph. A semantic indexing mechanism retrieves relevant nodes from the graph, constructs a minimal necessary context, and guides the agent to complete the code update. The entire process only incrementally processes the content affected by the changes, avoiding repeated parsing of the entire document and injection of the full context. This reduces resource consumption while improving the agent's understanding of the change intent and the accuracy of code generation.

[0081] The following describes the specific implementation steps of the above-described specification-driven coding method with reference to specific embodiments.

[0082] Figure 3 A flowchart illustrating a specification-driven coding method according to one embodiment is provided. The execution entity of the method can be any platform, server, or device cluster with computing and processing capabilities. Figure 3 As shown, the method includes at least the following steps: Step S302, in response to a user's change operation on the specification document, determining the changed content in the specification document; Step S304, updating the corresponding specification graph according to the changed content, and determining several change request nodes therein; the specification graph contains multiple types of nodes and corresponds to the semantics of the specification document; Step S306, determining multiple first recall nodes with high relevance ranking in the updated specification graph based on any first change request node; Step S308, determining a first change context based on the first change request node and the multiple first recall nodes; Step S310, inputting the first change context into the agent, causing it to perform a first update on the current codebase.

[0083] This specification employs a hybrid storage architecture combining a physical layer and a logical layer. The physical layer uses highly readable text files (e.g., Markdown files) as raw storage, preserving developers' reading and editing habits and serving as the single source of truth. The logical layer uses a graph database to deconstruct unstructured specification documents into structured knowledge graphs (specification graphs) to support fine-grained change tracking, semantic indexing, and impact analysis. Data consistency between the physical and logical layers is maintained through a bidirectional synchronization mechanism.

[0084] Specifically, the canonical graph contains various types of nodes, as well as relational edges that define the semantic connections between nodes. Figure 4 A database architecture diagram illustrating a storage specification graph according to one embodiment is shown. Figure 4 As shown, the specification graph includes at least the following types of nodes: specification nodes (SPEC), requirement nodes (REQUIREMENT), and scenario nodes (SCENARIO).

[0085] In this system, a specification node is the top-level node in the specification graph, representing a complete specification document. Each specification node has a unique primary key identifier (id) to uniquely identify the node in the graph; a name field to record the title or name of the specification; an overview field to record the overall description information of the specification, facilitating a quick understanding of the specification's purpose and scope; a version field to record the current version of the specification node, supporting the tracking of the specification document's change history; and an updated time field to record the timestamp of the last modification of the specification node, facilitating the identification of recently modified specification documents.

[0086] Requirement nodes represent specific requirement entries in a specification document. Each requirement node has a unique primary key identifier (id). The specification identifier (spec_id) in a requirement node is a foreign key field used to associate the requirement node with the specification node it belongs to, indicating which specification document the requirement entry belongs to; the name field records the title of the requirement entry; the text content field records the detailed description text of the requirement entry; the order index field records the sorting order of the requirement node under its parent specification node, facilitating the maintenance of the correct hierarchical order when backsynchronizing the specification graph to the specification document; the hash value field stores the hash fingerprint of the text content of the requirement node, allowing for quick identification of whether the requirement node has undergone substantial content changes by comparing changes in the hash value.

[0087] Scene nodes represent the acceptance scenarios or usage contexts of requirement entries. Each scene node has a unique primary key identifier (id). The requirement identifier (requirement_id) is a foreign key field used to associate the scene node with the requirement node to which it belongs, indicating which requirement entry the scene description belongs to; the raw text field records the complete description text of the scene; and the order index field records the sorting order of the scene node under its parent requirement node.

[0088] In addition, the specification graph can also include change nodes (CHANGE) and increment nodes (DELTA). Change nodes represent a complete change operation event. When a user or AI agent modifies the specification document, a change node can be created to record the metadata information of that change operation.

[0089] Incremental nodes represent specific changes within a change operation. Each incremental node has a unique primary key identifier (id). The change identifier (change_id) is a foreign key field used to associate the incremental node with the corresponding change node, indicating which change operation the incremental item belongs to. The operation type field records the operation type corresponding to the incremental node, such as add (ADD), modify (MOD), delete (DEL), or rename (REN). The target requirement identifier (target_req_id) is a foreign key field used to associate the incremental node with the target requirement node it affects, indicating which requirement node the change operation impacted. The payload field stores the specific changed content of the incremental node in JSON format, such as the text value before and after the change.

[0090] Meanwhile, relation edges in the canonical graph are used to define semantic associations between different types of nodes. Specifically,

[0091] The `contains` relation connects specification nodes and requirement nodes, indicating that a specification node contains several requirement nodes. This relation reflects the hierarchical structure of the specification document, meaning that a specification document consists of multiple requirement items. The `has` relation connects requirement nodes and scenario nodes, indicating that a requirement node has several scenario nodes. This relation reflects the dependency relationship between a requirement item and its acceptance scenarios; that is, a requirement item can correspond to multiple acceptance scenarios. The `proposes` relation connects change nodes and incremental nodes, indicating that a change node proposes several incremental change items. This relation reflects that a single change operation can include multiple specific change items. The `targets` relation connects incremental nodes and requirement nodes, indicating that an incremental change item acts on a specific target requirement node. This relation enables the system to accurately track the specific requirement items affected by each change operation, providing graph-level data structure support for subsequent concurrent conflict detection and change impact analysis.

[0092] In addition, the canonical graph also has a corresponding vector index, which is used to quickly find nodes in the canonical graph, or to find several nodes in the canonical graph that are highly similar to a certain query item.

[0093] The construction of the vector index first requires textual representation of each node in the canonical graph. This embodiment employs a context-enhanced strategy, where the input text for vectorization encoding of any given node is composed of multidimensional metadata.

[0094] Specifically, for a demand node Its vectorized input text The node name of the demand node The canonical node identifier to which it belongs Node content text And the node content of each scenario node associated with this requirement node. It is assembled together. As shown in formula (1):

[0095]

[0096] Among them, text splicing The operation sequentially connects the aforementioned text parts using predefined delimiters to form a complete concatenated text. The purpose of this context enhancement strategy is to ensure that the generated concatenated text not only contains the semantic information of the requirement node itself, but also integrates the business domain context of its respective specification document and the specific acceptance scenario description. By representing the requirement node within its specification and scenario contexts, the semantic ambiguity of short texts can be effectively resolved, resulting in subsequent generated representation vectors with richer semantic connotations.

[0097] After obtaining the concatenated text, this embodiment uses a pre-trained text encoder to encode the concatenated text and determine the representation vector corresponding to the requirement node. The text encoder can employ a pre-trained language model based on the Transformer architecture to map the variable-length concatenated text into a dense vector of fixed dimensions. This representation vector carries the deep semantic information of the requirement node after fusing the canonical context and the scene context, and can be used for subsequent similarity retrieval and relevance calculation.

[0098] For each requirement node in the standard graph, the system generates a corresponding representation vector in the manner described above, and stores it together with the metadata information of that requirement node in the vector database.

[0099] Building upon vector encoding, vector indexes such as the Hierarchical Navigable Small World (HNSW) algorithm can be constructed. These vector indexes support efficient approximate nearest neighbor retrieval, enabling semantic similarity retrieval with logarithmic complexity even in canonical graphs containing thousands of nodes.

[0100] It is understandable that nodes of other types in the standard graph, besides the requirement nodes, can be indexed in the usual way, with their titles and / or body text indexed. This will not be elaborated on here.

[0101] Through the aforementioned context-enhanced text representation strategy, the vector indexes in the canonical graph can efficiently carry the semantic information of each required node, providing a reliable data foundation for subsequent semantic retrieval and relevance scoring.

[0102] The specific execution process of each of the above steps is described below.

[0103] First, in step S302, in response to the user's change operation on the specification document, the changed content is determined in the specification document.

[0104] In this step, the specification document is stored at the physical layer, typically in a text format such as Markdown, for easy reading and editing by developers. The specification document can be organized hierarchically, for example, with the specification document as the root node, containing multiple requirement chapters, each containing several requirement items, and each requirement item may contain sub-content such as scenario descriptions and acceptance criteria. When a user (e.g., a developer) modifies, adds to, or deletes a specification document, it is necessary to first identify the specific content that has changed in the document for targeted processing, rather than re-parseing the entire document.

[0105] In one specific embodiment, determining the changed content in step S302 can be based on a content hash fingerprint. Specifically, a content hash value can be calculated for each document fragment in the specification document, and these hash values ​​can be pre-stored. Document fragments can be divided according to the hierarchical structure of the document, such as by heading level, paragraph, or requirement item. Taking requirement items as the unit of division, when initially loading the specification document, a SHA-256 hash value can be calculated for the text content of each requirement item as the content hash fingerprint, and it can be associated with and stored with the unique identifier of the requirement item.

[0106] When a document is modified, the content hash fingerprint of the modified specification document can be determined and compared with pre-stored historical hash fingerprints. Based on the differences in the comparison results, the modified document segment within the specification document can be identified. For example, suppose a specification document contains ten requirement items, and at initial loading, the content hash fingerprints of each item are H1 to H10. When a user modifies the description of the third requirement item, the method recalculates the content hash fingerprints of the ten items and finds that the hash fingerprint of the third item changes from H3 to H3', while the hash fingerprints of the remaining items remain unchanged. Thus, the third requirement item can be quickly identified as the modified document segment without requiring a line-by-line comparison of the entire document. This content hash fingerprint can be a fixed-length hash value calculated using hash algorithms such as MD5 or SHA-256; the specific algorithm chosen can be set according to performance requirements and collision probability.

[0107] It's important to note that content hash fingerprinting is primarily used for quickly identifying physical text changes. In some scenarios, document modifications may only involve formatting adjustments or punctuation changes, without affecting the semantic content. Therefore, after identifying changed document segments based on content hash fingerprints, these segments can be further compared semantically to confirm whether there are any substantial content changes. Specifically, the system can use lightweight text similarity algorithms (such as cosine similarity based on term frequency-inverse document frequency (TF-IDF)) to quickly compare document segments before and after the change, obtaining a semantic similarity score. If the semantic similarity score is higher than a preset threshold (e.g., 0.95), it can be determined that the change does not involve substantial content modification, but only minor adjustments to format or expression, and does not require triggering subsequent graph updates and index reconstruction processes. If the semantic similarity score is lower than the preset threshold, it is determined that a substantial change has occurred, and subsequent graph update steps are required. By combining hash verification and semantic comparison, unnecessary computational overhead caused by non-substantial changes can be avoided.

[0108] In another embodiment, changes to the specification document can also be detected through a file change detection mechanism. For example, file change notification mechanisms such as inotify (Linux), FSEvents (macOS), or ReadDirectoryChangesW (Windows) can be used to detect file change events in the directory where the specification document is located in real time. When a file write, modification, or deletion event is detected, the incremental parsing process is triggered, and the process proceeds to the change content determination stage in step S302.

[0109] Then, in step S304, the corresponding specification map is updated according to the changes, and several change requirement nodes are determined; the specification map contains multiple types of nodes and corresponds to the semantics of the specification document.

[0110] The node types in a specification graph can include requirement nodes, scenario nodes, and specification nodes. Requirement nodes represent specific requirement entries in a specification document, and each requirement node has a unique identifier (e.g., a Universally Unique Identifier, UUID) to uniquely identify the node in the graph. Scenario nodes describe the acceptance scenarios or usage conditions of a requirement; typically, one requirement node can be associated with several scenario nodes. Specification nodes represent the specification document or business domain to which a requirement belongs; a specification node can contain multiple requirement nodes.

[0111] Taking the user authentication module's specification document as an example, this specification document can correspond to a specification node, which contains several requirement nodes such as login requirement node, password reset requirement node, and two-factor authentication requirement node. The login requirement node can further be associated with several scenario nodes such as normal login scenario node, incorrect password scenario node, and account lockout scenario node. Through this hierarchical node organization, the system can structurally represent the linear document's structural information in the form of a graph.

[0112] Edges in the specification graph define the relationships between nodes. Besides the aforementioned types of relationships, relationship types can also include dependencies (depends_on) and conflicts (conflicts_with). For example, a specification node is connected to several subordinate requirement nodes through containment relationships, and requirement nodes are connected to several corresponding scenario nodes through containment relationships. Requirement nodes can express sequential or logical dependencies through dependency relationships. For instance, a password reset requirement node might depend on a user authentication requirement node because resetting a password requires verifying the user's identity first. These relationships constitute the semantic structure of the specification document, enabling the system to perform fine-grained reference tracking and change impact analysis at the graph level.

[0113] In one embodiment, step S304, updating the specification map based on the changes, may include the following process: First, based on the changes in the specification document, determine the corresponding nodes in the specification map, which include several change requirement nodes. For example, if the changes involve modifying the description of a requirement item, the corresponding requirement node can be found in the map using the unique identifier of that requirement item, and the text content field of that node can be updated.

[0114] If the change involves adding a new requirement item, a new requirement node can be created in the graph, and its inclusion relationship with the corresponding specification node can be established according to the document's hierarchical structure. If the change involves deleting a requirement item, the corresponding requirement node in the graph can be marked as pending deletion, and physical deletion can be performed after confirming that no other nodes depend on that node. Then, the content of each node can be updated, completing the incremental update of the graph.

[0115] It's important to note that when updating node content, the edge relationships between nodes also need to be updated synchronously. For example, when a user adds a reference to other requirement items in the specification document, a dependency edge can be added between the corresponding requirement nodes in the graph. When a user deletes a scenario description, the containment edge between the corresponding requirement node and the scenario node can be deleted from the graph. By synchronously updating nodes and edges, it can be ensured that the semantic structure of the specification graph and the specification document remains consistent.

[0116] After updating the node content of each node, the system also needs to vectorize the nodes involved in the change in order to update the semantic index of the graph. Specifically, for any node requiring change, the system can concatenate its node name, node content, corresponding canonical node identifier, and the node content of each corresponding scenario node to obtain a concatenated text, as shown in the aforementioned formula (1).

[0117] After obtaining the concatenated text, a pre-trained text encoder is used to encode the concatenated text to determine the representation vector corresponding to the change request node. Then, based on the representation vectors corresponding to each change request node, the vector index of the canonical graph is updated.

[0118] The vector index is updated incrementally. For a changed demand node, the old index entry corresponding to its representation vector is deleted, and the new index entry corresponding to its representation vector is inserted. For a newly added demand node, the index entry corresponding to its representation vector is directly inserted. For a deleted demand node, the index entry corresponding to its representation vector is deleted. When the representation vector of a demand node changes, the old index entry corresponding to that demand node's representation vector is deleted, and the new index entry corresponding to its representation vector is inserted.

[0119] In a more specific embodiment, the incremental update operation is triggered only when the incremental parsing determines that the semantics of the demand node have undergone a substantial change, thus avoiding the computational overhead of rebuilding the entire index. For newly added demand nodes, the index entry corresponding to its representation vector is directly inserted into the vector index; for deleted demand nodes, the index entry corresponding to its representation vector is deleted from the vector index.

[0120] Next, in step S306, based on any first change requirement node, determine multiple first recall nodes that rank highly in relevance to it in the updated specification graph.

[0121] In step S306, the first change requirement node refers to any one of the several change requirement nodes determined in step S304. Since there are usually semantic relationships and logical dependencies between the nodes in the specification document, when a requirement node changes, a set of nodes that are highly relevant to that change requirement node can be recalled from the specification graph to provide sufficient contextual information for subsequent code updates.

[0122] In one specific embodiment, the determination of the first recall node can be based on a relevance score. Specifically, for any first node in the canonical graph, a first relevance score can be determined between it and the first change request node. This first relevance score is determined jointly based on the similarity of the representation vectors between the first node and the first change request node, and the weighted distance values ​​of the first node with each of its neighboring nodes in the canonical graph.

[0123] Vector similarity can be calculated using, for example, cosine similarity, representing the semantic similarity between the first change request node and a node in the canonical graph. The distance-weighted value reflects the degree of association between the first node and the first change request node within the topological structure of the canonical graph.

[0124] In one specific implementation, the distance weighting value is determined by a weighted sum of the reciprocals of the distances between the first node and each of its neighboring nodes. With the first change request node First correlation score between It can be shown in formula (2):

[0125]

[0126] in, Indicates the first node With the first change request node The similarity of the representation vectors between them, for example, could be cosine similarity. Indicates the first node The set of neighbor nodes in the canonical graph Indicates the first node with neighboring nodes The weight of the edges between them. Indicates the first node Neighboring nodes Distances in the graph, such as shortest path distances. Edge weights can be set according to the relationship type; for example, the weight of an inclusion relationship can be set to a higher value (e.g., 1.0), the weight of a dependency relationship can be set to a medium value (e.g., 0.8), and the weight of a reference relationship can be set to a lower value (e.g., 0.5).

[0127] and This is a weighting coefficient used to balance the contributions of semantic similarity and topological distance to the relevance score, and can be set according to the specific application scenario. For example, in scenarios where semantic association is more important, it can be appropriately increased. The value of makes semantic similarity dominate the scoring; in scenarios where dependency is more critical, the value can be appropriately increased. The value of makes the topological structure of the graph have a greater impact on the score.

[0128] After calculating the first correlation score between each node in the specification graph and the first change requirement node, the nodes with the highest correlation scores in each node in the specification graph are identified as multiple first recall nodes.

[0129] In other embodiments, other methods for determining relevance scores may be used, such as using only vector similarity as the relevance score, which is not limited here.

[0130] After obtaining multiple recall nodes, in step S308, a first change context is determined based on the first change request node and the multiple first recall nodes.

[0131] In this step, the first change context refers to the context information input to the agent, used to guide the agent to understand the background, constraints, and related requirements of the current change, thereby enabling accurate code updates. Since the length of the agent's input context is limited by the token budget, directly inputting the complete content of all recalled nodes into the agent would not only waste computing resources but also potentially affect the agent's inference accuracy due to excessive irrelevant information in the context. Therefore, the system needs to filter and compress the content of the recalled nodes to construct a minimum necessary context.

[0132] In one specific embodiment, step S308, determining the first change context, may include the following processing steps. First, the node content of each first recalled node is extracted into a summary to determine its corresponding first summary text. The summary extraction can employ a text summarization algorithm to compress the complete description of each recalled node into a short, structured summary, preserving the node's core semantics and key constraints while significantly reducing the text length. For example, the TextRank algorithm or a sentence importance scoring method based on attention weights can be used to rank the importance of each sentence in the node content, selecting the sentences with the highest scores to form the summary text. In another implementation, the summary extraction can also employ a generative summarization method, using a pre-trained text generation model to generate summaries of the node content, resulting in a more semantically concise summary text.

[0133] Next, the multiple first summary texts are concatenated with the first constraint texts corresponding to each first recall node to determine the first change context. The first constraint text refers to information related to the recall node, such as constraints, acceptance criteria, and dependency descriptions, which can typically be extracted from the scene nodes or dependencies associated with that node. For example, for a login requirement node, its first constraint text may include constraints such as password complexity requirements, login failure limit, and account lockout time; these constraints can be extracted from the scene nodes associated with that node.

[0134] In a more specific embodiment, the text length of the first change context can be limited to be less than a preset first threshold. When the text length of the first change context exceeds the first threshold, the length of each first summary text obtained in the summary extraction process in the aforementioned steps can be further compressed, so that the text length of the updated first change context is less than the first threshold.

[0135] The first threshold is related to the task type in the first change request node. For example, for code generation tasks, the first threshold can be set to a larger value to provide sufficient contextual information, ensuring that the agent can understand the complete business logic and constraints involved in the change; for dependency analysis tasks, the first threshold can be set to a smaller value, because such tasks mainly focus on the dependencies between nodes, and the required contextual information is relatively concise. By dynamically setting the first threshold according to the task type, the system can maximize information density within a limited token budget and avoid the decrease in inference accuracy caused by context overload.

[0136] Alternatively, context construction can be performed iteratively. First-recall nodes are selected sequentially based on their relevance scores, from highest to lowest. Their summary text and constraint text are concatenated into the context, and the cumulative text length is calculated in real-time. Adding new node content stops when the cumulative text length approaches a first threshold. This ensures that the context prioritizes information most relevant to the change request node while also satisfying token budget constraints. In addition to the complete content of the first change request node itself, its core description can also be added to the context as baseline information for the agent to understand the change intent.

[0137] Finally, in step S310, the first change context is input into the agent, causing it to perform the first update on the current codebase.

[0138] The first agent is an AI agent configured to perform code writing and updating tasks. It can be built based on a large language model and possesses the ability to understand natural language specifications and generate or modify code. The first agent can utilize a pre-trained large language model and, through methods such as instruction tuning or prompt engineering, enable it to understand the mapping relationship between specification documents and code generation. The first update refers to the corresponding modifications made by the agent to the current codebase based on the first change context, including but not limited to adding code, modifying existing code, and deleting obsolete code.

[0139] Specifically, the system can input the first change context constructed in step S308 as part of the prompt to the first agent. The prompt may also include task instructions, relevant file path information in the codebase, and the specific type of change operation. For example, the prompt may have the following structure: "The following is a change to a requirement specification and its associated requirement description. Please modify the corresponding implementation in the codebase according to this change. The associated requirement is as follows: [First Change Context]." Here, [First Change Context] is a placeholder used to fill in the specific content of the first change context.

[0140] After receiving the prompt, the first agent can locate the code file or code snippet that needs to be modified in the codebase based on its understanding of the requirement changes in the specification context, and generate the corresponding code change content.

[0141] The following technical results can be obtained through steps S302 to S310 above. By combining rapid localization using content hash fingerprinting with semantic comparison, the system can identify only the affected document fragments when the specification document changes, avoiding repeated parsing of the entire document. Through incremental updates of the specification graph and local reconstruction of the vector index, the system can keep the computational overhead of change processing at a low level. Through a comprehensive relevance score based on representation vector similarity and graph topological distance, the system can accurately recall the set of nodes related to the change requirements from a large-scale specification knowledge base. Through a context construction strategy combining summary extraction and token budget constraints, the system can provide a minimum necessary context with higher information density within a limited input window, thereby improving the agent's understanding of the change intent and the accuracy of code generation. Overall, the specification-driven coding method described in this specification optimizes the specification-driven coding process from a full-processing mode to an incremental processing mode, enabling the system to maintain low resource consumption and high response efficiency even when dealing with large-scale, long-cycle iterative development scenarios.

[0142] In scenarios supporting concurrent collaboration among multiple AI agents for specification-driven coding, different agents may simultaneously modify the same or related specification documents. Without an effective conflict detection and coordination mechanism, concurrent changes can lead to inconsistencies or logical conflicts in the specification documents. Therefore, based on the above-described method embodiments, this specification further provides a method embodiment involving concurrent conflict detection and handling.

[0143] In some possible implementations, the method further includes steps 11-14.

[0144] In step 11, in response to the user's second change operation on the specification document, the second change content is determined in the specification document.

[0145] In this step, the second change operation is another change operation executed concurrently with the change operation in step S302. The second change operation can be initiated directly by the user or triggered by another AI agent. For example, while the first agent is changing the user authentication module, the second agent may be changing the order processing module that depends on the user authentication module. In this case, the two change operations overlap in time, constituting concurrent changes.

[0146] It should be noted that the execution order of steps S302 and S11 is not fixed; they can occur in parallel or sequentially. After detecting concurrent change operations, the system needs to perform conflict detection to determine whether the two operations can be safely executed in parallel. In a specific implementation, the system can maintain a queue of change operations, adding arriving change operations to the queue sequentially. When there are two or more change operations in the queue, and the arrival time interval of these change operations is less than a preset concurrency threshold (e.g., 100 milliseconds), the system can determine that these change operations are concurrent changes and proceed to the conflict detection process in step 12.

[0147] Step 12: Detect concurrent conflicts between the change operation and the second change operation.

[0148] In this step, conflict detection is performed on the concurrent change operation and the second change operation to determine whether they can be safely executed in parallel.

[0149] In a specific implementation, concurrent conflict detection can be based on the object being changed and the operation type of the change operation. Specifically, it can first be determined whether the object being changed by the change operation and the second change operation are the same. The object being changed refers to the specific target in the specification document targeted by the change operation, such as a requirement node, scenario node, or document fragment. The object being changed by the change operation and the second change operation can be uniquely identified by the document fragment identifier located by the difference in the content hash fingerprint determined before the change. At the specification graph level, the object being changed can correspond to the identifier (e.g., UUID) of a specific node in the graph.

[0150] If the object being changed by the change operation and the second change operation are the same, and the types of the two change operations are not interchangeable, then the detection result is determined to be a conflict. Change operation types can include operations such as Add (ADD), Modify (MOD), Delete (DEL), and Rename (REN). Operation commutativity refers to whether two operations produce the same result when executed in different orders. For example, two modification operations targeting the same requirement node might be commutative if they modify different attribute fields (e.g., one modifies the node name, the other modifies the node description) because they produce the same result when executed in different orders. However, if the two modification operations target the same attribute field, they are not commutative because different execution orders will result in different values ​​for that attribute field. The system can maintain an operation commutativity matrix to quickly determine whether two operation types are commutative when targeting the same target. This matrix can be stored in tabular form, with rows and columns representing operation types and matrix elements indicating whether the two operations are commutative.

[0151] Furthermore, if there is a dependency relationship between the change operation and the object being changed by the second change operation, the detection result will also be identified as a conflict. Specifically, the system can query the canonical graph to see if there is a dependency edge (e.g., a depends_on relationship) between the object being changed by the change operation and the object being changed by the second change operation. If a dependency relationship exists, even if the two change operations have different goals, their concurrent execution may lead to semantic inconsistencies.

[0152] Taking a specific scenario as an example, suppose the first agent modifies the password policy requirement node in the user authentication module, changing the password complexity requirement from at least eight characters to at least twelve characters. Simultaneously, the second agent modifies the user registration requirement node in the order processing module, adding a password setting step to the registration process. Since the password setting step in the user registration requirement node depends on the password policy requirement node in the user authentication module, the two have a dependency edge in the specification graph. If the two changes are executed in parallel, the second agent might generate code based on the old password policy (at least eight characters) when adding the password setting step, while the first agent has already modified the password policy to at least twelve characters. This would lead to a semantic deviation between the code implementation and the specification document. Therefore, the system needs to classify such dependency-based changes as conflicts.

[0153] Formalistically, the above judgment condition can be written as formula (3):

[0154]

[0155] in, and These represent two change operations. for The changed goal for The goal of the change. represent and They are not interchangeable. For operation Change the dependencies of the object.

[0156] Then, in step 13: in response to a conflict in the detection result, the change operation and the second change operation are executed sequentially.

[0157] In this step, when the system determines that there is a conflict between the change operation and the second change operation, the system can switch from concurrent execution mode to serial execution mode. Specifically, the system can execute the change operation and the second change operation sequentially according to the arrival time of the change operation.

[0158] Meanwhile, in step 14: in response to the detection result being non-conflicting, the change operation and the second change operation are executed in parallel.

[0159] In this step, when the system determines that there is no conflict between the first change operation and the second change operation, the system can allow the two change operations to be executed in parallel. Parallel execution can make full use of the system's computing resources and improve the efficiency of change processing. Specifically, the first and second change operations can trigger their respective canonical graph update processes, semantic index update processes, and agent code update processes, and these processes can be scheduled concurrently without causing data races or semantic conflicts.

[0160] By formalizing change operations into structured data containing the change object and operation type, and performing conflict detection based on operation commutativity and dependencies in the graph, the system can accurately identify semantic-level logical conflicts in multi-agent concurrent collaboration scenarios, rather than relying solely on text line-level difference comparisons. By introducing an operation commutativity matrix, the system can efficiently determine the concurrency safety of different operation types on the same change object, avoiding unnecessary serialization overhead. For change objects with dependencies, even if the operation types are different, the system can identify and intercept potential semantic conflicts. For conflicting change operations, a serial execution mechanism ensures data consistency; for non-conflicting change operations, a parallel execution mechanism improves processing efficiency. Overall, this method provides reliable consistency guarantees for standardized document management in large-scale concurrent collaboration scenarios.

[0161] Beyond the aforementioned change-driven coding process, users can also retrieve relevant requirement information from the specification knowledge base through natural language queries. Traditional specification document retrieval methods are typically based on keyword matching, which cannot understand the deep semantics of user queries, potentially leading to omitting relevant requirements or including a large amount of irrelevant information in the search results. Therefore, this specification further provides an embodiment of a method involving semantic retrieval of user queries.

[0162] In some possible implementations, the method further includes steps 21 to 22.

[0163] Step 21: Obtain the query vector obtained by encoding the user's query text using a text encoder.

[0164] In this step, the user enters a query text in natural language form, such as how to change their login password or which payment methods the system supports. After the user enters the query text in the system's search interface, the system can receive the query text and vectorize it.

[0165] Specifically, the system can use a pre-trained text encoder to encode the query text, obtaining a query vector. This text encoder is the same as the one used to encode the canonical document, ensuring that the query vector and the representation vectors of nodes in the canonical graph reside in the same vector space. This guarantees that meaningful similarity calculations can be performed between the query vector and the node representation vectors.

[0166] Then, in step 22, several recall demand nodes are determined based on the similarity between the query vector and the respective representation vectors of each demand node.

[0167] In this step, each requirement node in the specification graph has a corresponding representation vector. The representation vector of any requirement node is determined based on its node name, node content, corresponding specification node identifier, and corresponding scenario nodes. Specifically, as described above, the representation vector of each requirement node is obtained by concatenating its node name, node content, specification node identifier, and the node content of each scenario node, and then encoding it using a text encoder.

[0168] After obtaining the query vector, the similarity between the query vector and the representation vectors of each demand node in the canonical graph can be calculated. Then, based on the similarity calculation results, several demand nodes with the highest similarity ranking can be selected as recall demand nodes. The number of recall demand nodes can be set according to actual needs; for example, a fixed number of nodes with high similarity ranking can be selected, or nodes with similarity higher than a preset threshold can be selected.

[0169] The embodiments comprising the above steps yield the following technical results. Through a vector space-based semantic indexing mechanism, the system can understand the natural language intent of user queries, rather than relying solely on keyword matching for retrieval. Through a context-enhanced text representation strategy, the representation vectors of demand nodes integrate business domain and scenario information, reducing semantic ambiguity in short texts and making retrieval results more accurate. Compared to traditional keyword search methods, this semantic retrieval method can identify the association between synonyms and implicit intent, improving the precision and recall of standardized document retrieval.

[0170] In some possible embodiments, the method may further include steps 31 to 32.

[0171] In step 31, in response to the user's second change operation on the specification map, several second change nodes in the specification map are determined.

[0172] In this step, the second change operation refers to the change operation on the standard map, which is the opposite of the change operation on the standard document described above. Specifically, the change operation described above synchronizes changes to the standard document to updates on the standard map, while in this step, the change operation synchronizes changes to the standard map in reverse to updates on the standard document.

[0173] Changes to the canonical graph can originate from various scenarios. For example, an agent might directly add a new requirement node to the canonical graph or modify an existing requirement node. Alternatively, after executing a code update, the system might automatically deduce the necessary adjustments to the canonical graph based on the changes. Regardless of the source of the change, the system needs to identify the changed node in the canonical graph as the secondary change node.

[0174] In one specific implementation, the system can identify the second changed node by monitoring the operation logs of the canonical graph. The canonical graph management module can record all change operations on the graph, including the addition, modification, and deletion of nodes, as well as the addition, deletion, and modification of edges. The operation logs can record information such as the timestamp, operation type, target node identifier, and the content before and after the change for each change operation. By querying the operation logs, the system can identify each node that has changed within a recent period (e.g., since the last synchronization time).

[0175] In another implementation, the system can maintain a version number or timestamp field for each node in the canonical graph. When a node changes, its version number is incremented or its timestamp is updated to the current time. The system can quickly identify the changed node by querying the version number or timestamp. For example, the system can record the global version number at the time of the last reverse synchronization, and then identify the node in the current graph whose version number is higher than that global version number as the second changed node.

[0176] Then, in step 32, the specification document is updated based on several second change nodes.

[0177] In this step, the specification document is updated accordingly based on the information from the second change node to ensure that the physical layer specification document and the logical layer specification map remain consistent.

[0178] In a specific implementation, for a newly added second change node, its hierarchical position and relationships within the specification graph can be determined, and a corresponding document fragment can be generated at the corresponding location in the specification document. For example, if the newly added node is a requirement node, a new requirement entry is added under the corresponding section of the specification document based on the specification node to which the requirement node belongs. If the newly added requirement node is associated with several scenario nodes, a scenario description paragraph can be added under the requirement entry, formatting the content of each scenario node into a scenario list.

[0179] For the modified second change node, the corresponding document segment in the specification document can be identified, and that segment can be updated. Specifically, the unique identifier of the requirement node can be mapped to the corresponding location in the specification document. By querying this mapping relationship, the location in the specification document that needs to be modified can be quickly located, and the updated content of the node can replace the original document content.

[0180] For the deleted second change node, the system can locate the corresponding document fragment in the specification document and delete it or mark it as obsolete.

[0181] By reverse-synchronizing changes to the specification graph to the specification document, the system achieves bidirectional data consistency assurance between the physical and logical layers. This mechanism ensures that changes initiated from the specification document, the specification graph, or agent collaboration are ultimately reflected in the specification document, maintaining the integrity of the data as a unique source of truth. For long-term iterative software development projects, this bidirectional synchronization mechanism effectively avoids the disconnect between the specification document and actual requirements, reducing document maintenance costs. Through change difference reporting and user review confirmation mechanisms, the system strikes a balance between automated synchronization and manual review, ensuring the quality of specification document changes.

[0182] According to another embodiment, a specification-driven encoding device is also provided. Figure 5 A schematic block diagram of a specification-driven encoding apparatus according to one embodiment is shown. This apparatus can be deployed in any device, platform, or cluster of devices with computing and processing capabilities. Figure 5 As shown, the device 500 includes:

[0183] The change determination unit 502 is configured to determine the change content in the specification document in response to a user's change operation on the specification document;

[0184] The graph update unit 504 is configured to update the corresponding specification graph according to the changes, and determine several change requirement nodes therein; the specification graph contains multiple types of nodes and corresponds to the semantics of the specification document;

[0185] The node recall unit 506 is configured to determine, based on any first change request node, multiple first recall nodes with the highest relevance ranking in the updated specification graph.

[0186] The context determination unit 508 is configured to determine the first change context based on the first change request node and multiple first recall nodes;

[0187] The code update unit 510 is configured to input the first change context into the agent, causing it to perform a first update on the current codebase.

[0188] In some possible implementations, the device 500 further includes:

[0189] The second change determination unit is configured to determine the second change content in the specification document in response to a user's second change operation on the specification document.

[0190] The conflict detection unit is configured to perform concurrent conflict detection on the change operation and the second change operation.

[0191] A serial execution unit is configured to serially execute the change operation and the second change operation in response to a conflict detection result;

[0192] The parallel execution unit is configured to execute the change operation and the second change operation in parallel in response to a detection result that indicates no conflict.

[0193] In some possible implementations, each requirement node in the specification graph has a corresponding representation vector, and the representation vector of any requirement node is determined based on its node name, node content, corresponding specification node ID, and corresponding scenario nodes; the device 500 further includes:

[0194] The query retrieval unit is configured to retrieve the query vector obtained by encoding the user's query text using a text encoder;

[0195] The similarity determination unit is configured to determine a number of recall demand nodes based on the similarity between the query vector and the respective representation vectors of each demand node.

[0196] In some possible implementations, the device 500 further includes:

[0197] The determining unit is configured to, in response to a user's second change operation on the specification map, determine a plurality of second change nodes in the specification map;

[0198] The document update unit is configured to update the specification document based on the plurality of second change nodes.

[0199] According to another embodiment, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed in a computer, causes the computer to perform the methods described in any of the above embodiments.

[0200] According to another embodiment, a computing device is also provided, including a memory and a processor, wherein the memory stores executable code, and when the processor executes the executable code, it implements the method described in any of the above embodiments.

[0201] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the apparatus embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0202] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0203] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0204] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware or by a program instructing related hardware. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0205] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above description is only a specific embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A specification-driven coding method, comprising: In response to a user's modification of the specification document, the modified content is determined in the specification document; Based on the changes, the corresponding specification graph is updated, and several change requirement nodes are identified. The specification graph contains multiple types of nodes and corresponds to the semantics of the specification document. Based on any first change requirement node, identify multiple first recall nodes in the updated specification graph that rank highly in terms of their relevance. The first change context is determined based on the first change request node and multiple first recall nodes; The first change context is input into the agent, which is then instructed to perform the first update on the current codebase.

2. The method as described in claim 1, wherein, The determination of changes in the specification document includes: Determine the content hash fingerprint of the revised specification document and compare it with the pre-stored historical hash fingerprint; Based on the differences in the comparison results, identify the document segments in the specification document that have been changed.

3. The method as described in claim 1, wherein, The specification graph includes the following node types: requirement nodes, specification nodes, and scenario nodes; each requirement node has a corresponding specification node and several scenario nodes.

4. The method of claim 3, wherein, The updated corresponding canonical graph includes: Based on the changes, the corresponding nodes in the standard graph are identified, and then the node content of each node is updated.

5. The method of claim 4, wherein, The updated corresponding canonical graph also includes: For any change request node, its node name, node content, corresponding standard node ID, and the node content of each corresponding scenario node are concatenated to obtain the concatenated text. The concatenated text is encoded using a text encoder to determine the representation vector corresponding to the change request node; The vector index of the standard graph is updated based on the representation vector corresponding to each change requirement node.

6. The method of claim 1, wherein, Each node in the canonical graph has a corresponding representation vector; the step of determining multiple first recall nodes with high relevance ranking in the updated canonical graph based on any first change requirement node includes: For any first node in the specification graph, a first correlation score is determined between it and the first change request node; the first correlation score is determined based on the similarity of the representation vectors between the first node and the first change request node, and the weighted distance values ​​of the first node to each neighboring node in the specification graph. The nodes with the highest relevance scores in the specified graph are identified as multiple first recall nodes.

7. The method of claim 6, wherein, The distance weighted value is determined by the weighted sum of the reciprocals of the distances between the first node and each of its neighboring nodes.

8. The method of claim 1, wherein, The step of determining the first change context based on the first change request node and multiple first recall nodes includes: Extract the summary of the node content of each first recall node to determine multiple first summary texts; The first change context is determined by concatenating multiple first summary texts with the first constraint texts corresponding to each first recall node.

9. The method of claim 8, wherein, The text length of the first change context is less than a preset first threshold; the first threshold is related to the task type in the first change request node.

10. The method of claim 1, further comprising: In response to a user's second modification to the specification document, the second modification content is determined in the specification document; Concurrent conflict detection for the aforementioned change operation and the second change operation; In response to a conflict in the detection result, the change operation and the second change operation are executed sequentially. When the detection result is non-conflicting, the change operation and the second change operation are executed in parallel.

11. The method of claim 10, wherein, The concurrent conflict detection of the change operation and the second change operation includes: If the object of the change operation and the second change operation are the same, and the types of the change operation and the second change operation are not interchangeable, the detection result is determined to be a conflict. In response to the existence of a dependency between the changed object of the first change operation and the second change operation, the detection result is determined to be a conflict.

12. The method of claim 1, wherein, Each requirement node in the specification graph has a corresponding representation vector. The representation vector of any requirement node is determined based on its node name, node content, corresponding specification node ID, and corresponding scenario nodes. The method further includes: Obtain the query vector obtained by encoding the user's query text using a text encoder; Based on the similarity between the query vector and the respective representation vectors of each demand node, several recall demand nodes are determined.

13. The method of claim 1, further comprising: In response to a user's second modification operation on the specification map, several second modification nodes in the specification map are determined; The specification document is updated based on the aforementioned second change nodes.

14. A specification-driven encoding device, comprising: The change determination unit is configured to determine the change content in the specification document in response to a user's change operation on the specification document; The graph update unit is configured to update the corresponding specification graph according to the changes, and determine several change requirement nodes in the graph; the specification graph contains multiple types of nodes and corresponds to the semantics of the specification document. The node recall unit is configured to determine, based on any first change request node, multiple first recall nodes with the highest relevance ranking in the updated specification graph. The context determination unit is configured to determine the first change context based on the first change request node and multiple first recall nodes; The code update unit is configured to input the first change context into the agent, causing it to perform a first update on the current codebase.

15. A computer-readable storage medium having a computer program stored thereon, which, when executed in a computer, causes the computer to perform the method of any one of claims 1-13.

16. A computing device comprising a memory and a processor, wherein, The memory stores executable code, and when the processor executes the executable code, it implements the method of any one of claims 1-13.

Images