Knowledge base-based assisted programming method and apparatus

Abstract

One or more embodiments of the specification provide a knowledge base-based assisted programming method and device. In the method, in response to a received assisted programming request, a target service field and a development request type corresponding to the assisted programming request can be determined; then, a multi-layer knowledge base including a first knowledge layer and a second knowledge layer can be acquired, wherein the first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store field definition information; then, based on the target service field and / or the development request type, corresponding configuration information is determined from the multi-layer knowledge base, wherein the configuration information includes at least one of a code template, a programming specification, and a file storage path, the code template and the programming specification are obtained based on the development architecture specification information, and the file storage path is obtained based on the development architecture specification information and the field definition information; finally, based on the configuration information, program code corresponding to the assisted programming request is generated.

Description

Technical Field

[0001] This specification relates to one or more embodiments in the field of computer technology, and more particularly to a knowledge base-based assisted programming method and apparatus. Background Technology

[0002] With the rapid development of artificial intelligence technology, AI-assisted programming has become an important technical direction in the field of computer technology to improve software development efficiency and ensure code quality. It is widely used in development processes such as code generation, standard verification, and test case writing.

[0003] Currently, software projects are developed at a fast pace, with complex application scenarios and frequent code iterations, which places higher demands on AI-assisted programming. To address the needs of project development in complex scenarios, ensure the standardization and accuracy of code generated by AI-assisted programming, and adapt to the rapid iterative evolution of software projects, a programming assistance solution is needed. Summary of the Invention

[0004] To address the needs of project development in complex scenarios, ensure the standardization and accuracy of AI-assisted programming generated code, and adapt to the rapid iterative evolution of software projects, this specification provides a knowledge-based assisted programming method and apparatus through one or more embodiments.

[0005] In a first aspect, one or more embodiments of this specification provide a knowledge-based assisted programming method, the method comprising: responding to a received assisted programming request, determining a target service domain and a development request type corresponding to the assisted programming request; acquiring a multi-layer knowledge base, the multi-layer knowledge base including a first knowledge layer and a second knowledge layer, the first knowledge layer being used to store development architecture specification information, and the second knowledge layer being used to store domain definition information; determining corresponding configuration information from the multi-layer knowledge base based on the target service domain and / or the development request type, the configuration information including at least one of a code template, a programming specification, and a file storage path, the code template and the programming specification being obtained based on the development architecture specification information, and the file storage path being obtained based on the development architecture specification information and the domain definition information; and generating program code corresponding to the assisted programming request based on the configuration information.

[0006] In one possible implementation, determining the corresponding configuration information from the multi-layered knowledge base based on the target service domain and / or the development request type includes: obtaining the code template and the programming specification from the development architecture specification information based on the development request type; and determining the file storage path based on the target service domain, the development request type, the development architecture specification information, and the domain definition information.

[0007] In one possible implementation, obtaining the code template from the development architecture specification information based on the development request type includes: if the development request type is a code generation type, determining the development framework type corresponding to the assisted programming request; and obtaining the code template corresponding to the development framework type from the first knowledge layer.

[0008] In one possible implementation, determining the file storage path based on the target service domain, the development request type, the development architecture specification information, and the domain definition information includes: determining the hierarchical affiliation information corresponding to the assisted programming request based on the development request type and the domain definition information; determining candidate storage locations based on the target service domain and the hierarchical affiliation information; selecting target storage locations that meet preset conditions from the candidate storage locations, the preset conditions including preset constraints and / or preset adaptation conditions; and determining the file storage path based on the target storage location and the development architecture specification information.

[0009] In one possible implementation, before acquiring the multi-layer knowledge base, the method further includes: constructing a multi-layer knowledge base corresponding to the target code repository; parsing the target code repository to obtain code information; extracting multi-dimensional information from the code information to obtain the development architecture specification information and domain information; storing the development architecture specification information in the first knowledge layer; obtaining the domain definition information based on the domain information, and storing the domain definition information in the second knowledge layer.

[0010] In one possible implementation, the multi-dimensional information extraction of the code information includes: extracting information from at least two dimensions of the code information, such as annotations, structure, naming information, framework type, and code features.

[0011] In one possible implementation, the code information includes code modules; obtaining the domain definition information based on the domain information includes: determining the association between the code modules and a preset domain based on the domain information; receiving a user's confirmation instruction on the association; obtaining structured domain knowledge based on the confirmed association through a large language model; and using the structured domain knowledge as the domain definition information.

[0012] In one possible implementation, determining the association between the code module and a preset domain includes: obtaining an association score based on association factors between the code module and the preset domain and preset weight parameters of the association factors; wherein the association factors include at least one of name similarity, entity association, complexity factor, and keyword matching degree; and determining the preset domains whose association scores meet preset score conditions as domains associated with the code module, so as to obtain the association between the code module and the preset domain.

[0013] In one possible implementation, obtaining structured domain knowledge based on confirmed associations through a large language model includes: calling the large language model to perform semantic integration and structuring processing on the code module based on the confirmed associations to obtain the structured domain knowledge.

[0014] In one possible implementation, the multi-layered knowledge base further includes a third knowledge layer and a fourth knowledge layer; after constructing the multi-layered knowledge base corresponding to the target code repository, the method further includes: obtaining the initial configuration information of the target code repository and storing the initial configuration information in the third knowledge layer; and / or, obtaining the preset maintenance information of the multi-layered knowledge base and storing the preset maintenance information in the fourth knowledge layer.

[0015] In one possible implementation, the method further includes: in response to a change in the code of the target code repository, obtaining a change file; determining the code change information in the change file; and updating the multi-layer knowledge base based on the code change information using a large language model.

[0016] In one possible implementation, the method further includes: The development architecture specification information in the multi-layer knowledge base is compared with the code information in the target code repository to detect deviations, thereby obtaining the deviation detection result of the multi-layer knowledge base; wherein, the deviation detection includes at least one of naming detection, hierarchical structure detection, framework consistency detection, entity definition detection, and constraint rule detection, and the deviation detection result includes deviation type and deviation level.

[0017] In one possible implementation, the deviation detection result further includes an automatic repair identifier; the method further includes: obtaining preset evaluation indicators of the multi-layer knowledge base; weighting the preset evaluation indicators to obtain a health evaluation result; wherein the preset evaluation indicators include at least one of structural integrity indicators, semantic richness indicators, consistency indicators represented by the deviation detection result, freshness indicators represented by update time, update traceability indicators, and repairability indicators represented by the automatic repair identifier.

[0018] In one possible implementation, the method further includes: performing semantic recognition on the multi-layer knowledge base using the large language model to obtain semantic-level question recognition results; and performing entropy reduction management on the multi-layer knowledge base based on the deviation detection results and / or the health assessment results, as well as the semantic-level question recognition results.

[0019] In one possible implementation, the entropy reduction governance of the multi-layer knowledge base includes at least one of the following: (1) semantically merging different named entities representing the same concept; (2) cleaning up expired knowledge information; (3) unifying different term definitions representing the same concept into the same term definition; (4) deleting knowledge information whose corresponding code does not exist; and (5) converging and unifying the development architecture specification information according to the code usage frequency in the target code repository.

[0020] In one possible implementation, the method further includes: obtaining the design document corresponding to the target code repository; performing multimodal analysis on the design document to obtain document definition information; cross-integrating the document definition information with the knowledge information in the multi-layer knowledge base, and updating the multi-layer knowledge base based on the information obtained from the cross-integration.

[0021] Secondly, one or more embodiments of this specification also provide a knowledge-based auxiliary programming device, the device comprising: The first determining module is used to determine the target service domain and development request type corresponding to the received auxiliary programming request in response to the auxiliary programming request. The acquisition module is used to acquire a multi-layer knowledge base, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. The second determining module is used to determine corresponding configuration information from the multi-layer knowledge base based on the target service domain and / or the development request type. The configuration information includes at least one of code template, programming specifications, and file storage path. The code template and the programming specifications are obtained based on the development architecture specification information, and the file storage path is obtained based on the development architecture specification information and the domain definition information. The execution module is used to generate program code corresponding to the auxiliary programming request based on the configuration information.

[0022] In one possible implementation, the second determining module is used to: obtain code templates and programming specifications from development architecture specification information based on the development request type; and determine the file storage path based on the target service domain, the development request type, and the development architecture specification information and domain definition information.

[0023] In one possible implementation, the second determining module is used to: determine the development framework type corresponding to the auxiliary programming request when the development request type is code generation type; and obtain the code template corresponding to the development framework type from the development architecture specification information.

[0024] In one possible implementation, the second determining module is used to: determine the hierarchical affiliation information corresponding to the auxiliary programming request based on the development request type and domain definition information; determine candidate storage locations based on the target service domain and hierarchical affiliation information; select target storage locations that meet preset conditions from the candidate storage locations, the preset conditions including preset constraints and / or preset adaptation conditions; and determine the file storage path based on the target storage location and development architecture specification information.

[0025] In one possible implementation, the knowledge base-based assisted programming device further includes a construction module, which is used to: construct a multi-layered knowledge base corresponding to the target code repository; parse the target code repository to obtain code information; extract multi-dimensional information from the code information to obtain development architecture specification information and domain information; store the development architecture specification information in the first knowledge layer; obtain domain definition information based on the domain information, and store the domain definition information in the second knowledge layer.

[0026] In one possible implementation, the building module is used to extract information from at least two dimensions of code information: annotations, structure, naming information, framework type, and code characteristics.

[0027] In one possible implementation, the code information includes code modules; the building module is used to: determine the association between the code modules and the preset domain based on domain information; receive the user's confirmation instruction on the association; obtain structured domain knowledge based on the confirmed association through a large language model; and use the structured domain knowledge as domain definition information.

[0028] In one possible implementation, the construction module is used to: obtain a correlation score based on the correlation factors between the code module and the preset domain and the preset weight parameters of the correlation factors; wherein the correlation factors include at least one of name similarity, entity correlation, complexity factor, and keyword matching degree; and determine the preset domains whose correlation scores meet the preset score conditions as the domains associated with the code module, so as to obtain the correlation relationship between the code module and the preset domains.

[0029] In one possible implementation, the building module is used to: invoke a large language model, and perform semantic integration and structuring processing on the code modules based on the confirmed relationships, to obtain structured domain knowledge.

[0030] In one possible implementation, the multi-layer knowledge base further includes a third knowledge layer and a fourth knowledge layer; the building module is also used to: obtain the initial configuration information of the target code repository and store the initial configuration information in the third knowledge layer; and / or, obtain the preset maintenance information of the multi-layer knowledge base and store the preset maintenance information in the fourth knowledge layer.

[0031] In one possible implementation, the knowledge base-based assisted programming device further includes a maintenance module, which is used to: obtain change files in response to code changes in the target code repository; determine the code change information in the change files; and update the multi-layer knowledge base based on the code change information through a large language model.

[0032] In one possible implementation, the maintenance module is further used to: perform deviation detection between the development architecture specification information in the multi-layer knowledge base and the code information in the target code repository to obtain the deviation detection result of the multi-layer knowledge base; wherein, the deviation detection includes at least one of naming detection, hierarchical structure detection, framework consistency detection, entity definition detection and constraint rule detection, and the deviation detection result includes deviation type and deviation level.

[0033] In one possible implementation, the deviation detection result also includes an automatic repair identifier; the maintenance module is further used to: obtain preset evaluation indicators of the multi-layer knowledge base; perform weighted processing on the preset evaluation indicators to obtain a health evaluation result; wherein, the preset evaluation indicators include at least one of the following: structural integrity indicator, semantic richness indicator, consistency indicator of deviation detection result representation, freshness indicator of update time representation, update traceability indicator, and repairability indicator of automatic repair identifier representation.

[0034] In one possible implementation, the maintenance module is also used to: perform semantic recognition on the multi-layer knowledge base using a large language model to obtain semantic-level question recognition results; and perform entropy reduction governance on the multi-layer knowledge base based on the deviation detection results and / or health assessment results, as well as the semantic-level question recognition results.

[0035] In one possible implementation, the maintenance module is used for at least one of the following: (1) semantically merging different named entities representing the same concept; (2) cleaning up expired knowledge information; (3) unifying different term definitions representing the same concept into the same term definition; (4) deleting knowledge information whose corresponding code does not exist; and (5) converging and unifying development architecture specification information according to the code usage frequency in the target code repository.

[0036] In one possible implementation, the maintenance module is also used to: obtain the design document corresponding to the target code repository; perform multimodal analysis on the design document to obtain document definition information; cross-integrate the document definition information with the knowledge information in the multi-layer knowledge base, and update the multi-layer knowledge base based on the information obtained from the cross-integration.

[0037] Thirdly, one or more embodiments of this specification also provide an intelligent agent, which includes: The first determining module is used to determine the target service domain and development request type corresponding to the received auxiliary programming request in response to the auxiliary programming request. The acquisition module is used to acquire a multi-layer knowledge base, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. The second determining module is used to determine corresponding configuration information from the multi-layer knowledge base based on the target service domain and / or the development request type. The configuration information includes at least one of code template, programming specifications, and file storage path. The code template and the programming specifications are obtained based on the development architecture specification information, and the file storage path is obtained based on the development architecture specification information and the domain definition information. The execution module is used to generate program code corresponding to the auxiliary programming request based on the configuration information.

[0038] Fourthly, one or more embodiments of this specification also provide an electronic device, which includes a memory and a processor; the memory is used to store a computer program product; the processor is used to execute the computer program product stored in the memory, and when the computer program product is executed, it implements the knowledge base-based assisted programming method of the first aspect described above.

[0039] Fifthly, one or more embodiments of this specification also provide a computer-readable storage medium storing computer program instructions that, when executed, implement the knowledge-based assisted programming method of the first aspect described above.

[0040] In summary, to address the complex development needs of projects, ensure the standardization and accuracy of AI-assisted programming code generation, and adapt to the rapid iterative evolution of software projects, this specification provides one or more embodiments of a knowledge-based assisted programming method and apparatus. In this method, in response to a received assisted programming request, the target service domain and development request type corresponding to the assisted programming request are determined, and a multi-layered knowledge base is obtained. This multi-layered knowledge base includes a first knowledge layer and a second knowledge layer, wherein the first knowledge layer stores development architecture specification information, and the second knowledge layer stores domain definition information. Then, based on the target service domain and / or development request type, corresponding configuration information is determined from the multi-layered knowledge base, including at least one of code templates, programming specifications, and file storage paths. The code templates and programming specifications are obtained based on the development architecture specification information, and the file storage paths are obtained based on the development architecture specification information and the domain definition information. Finally, based on the configuration information, program code corresponding to the assisted programming request is generated.

[0041] In this way, by determining the corresponding configuration information from a multi-layered knowledge base based on the target service domain and development request type of the assisted programming request, the configuration information can be domain-specific and task-specific. Since the configuration information originates from a knowledge base that stores layered development architecture and domain knowledge, and is dynamically determined based on the development request type and target service domain, even in situations with fast project development pace, complex application scenarios, and frequent code iterations, it can provide the programming agent with structured engineering common sense matching the current task, such as code templates, programming standards, and file storage paths. This effectively ensures the standardization and accuracy of the generated program code, adapts to the rapid iterative evolution of software projects, improves the efficiency, code quality, and maintainability of AI-assisted programming, and reduces the cost of manual review and repair. Attached Figure Description

[0042] To more clearly illustrate the technical solutions of one or more embodiments of 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 some embodiments of one or more embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 A structural block diagram of a multi-layer knowledge base provided for one or more embodiments of this specification; Figure 2 A flowchart illustrating a method for constructing a multi-layered knowledge base provided in one or more embodiments of this specification; Figure 3A flowchart illustrating a knowledge-based assisted programming method provided for one or more embodiments of this specification; Figure 4 A structural block diagram of a knowledge-based auxiliary programming device provided for one or more embodiments of this specification; Figure 5 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Detailed Implementation

[0044] The present specification describes one or more embodiments in further detail below with reference to the accompanying drawings and examples. Through these descriptions, the features and advantages of one or more embodiments of the present specification will become clearer and more apparent.

[0045] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments. Although various aspects of embodiments are shown in the accompanying drawings, the drawings are not necessarily drawn to scale unless specifically indicated otherwise.

[0046] Furthermore, the technical features described below in one or more embodiments of this specification may be combined with each other as long as they do not conflict with each other.

[0047] To facilitate understanding, the application scenarios of the technical solutions provided in one or more embodiments of this specification will be described below.

[0048] With the rapid development of artificial intelligence technology, AI-assisted programming has become an important technological direction in the field of computer technology to improve software development efficiency and ensure code quality. It is widely used in development processes such as code generation, specification verification, and test case writing. Among them, AI-assisted programming (AI Coding) refers to the AI-assisted programming paradigm represented by programming tools such as Cursor, GitHub Copilot, and Claude Code.

[0049] Currently, AI-assisted programming tools are undergoing a critical transformation from "code completion" to "autonomous coding agents," which can directly generate and modify code within code repositories. GitHub's 2025 Developer Ecosystem Report shows that 92% of developers are already using AI coding tools. However, the fast pace of software project development, complex application scenarios, and frequent code iterations place higher demands on AI-assisted programming. Developers commonly face a dilemma: the code generated by the agent may appear logically correct in its local context, but often contains errors within the overall project context, including inconsistent naming, disorganized file locations, and incorrect framework usage. This is not due to a lack of agent capability, but rather a lack of understanding of the overall project context; in other words, the agent does not understand the developer's project.

[0050] Specifically, the agent lacks persistent memory. The context window of a large model is scrolling; even a window with 200K tokens (the basic unit of text processing) only covers about 3000 lines of code. During cross-day development, the agent forgets the previous day's architectural decisions, naming conventions, compilation errors, and other information. Directly writing project specifications into the prompt window is essentially replacing a "manual" with "verbal instructions," which is unreliable and wastes valuable context computing resources.

[0051] Furthermore, the agent lacks basic engineering knowledge. For example, it may not know whether the project uses the data access framework CrudKill or the persistence layer framework MyBatis, whether the service layer (Service) should have the suffix "Service" or "Manager", whether new files should be placed in the app / biz / order directory or the app / common / dal directory, or whether component (Bean) registration should use the @Service annotation or the SOFA framework's XML configuration file. Due to this lack of engineering knowledge, the quality of the generated code is highly random. The same agent in the same project might generate an OrderService class one time and an OrderManager class another time, making it difficult to guarantee consistency in code style and standards.

[0052] In response to the above problems, some auxiliary programming solutions have been proposed in related technologies, but there are still obvious shortcomings.

[0053] In some application scenarios, Retrieval-Augmented Generation (RAG) is used. This involves chunking the codebase, embedding it, and storing it in a vector database. When an agent queries, it retrieves relevant code fragments based on semantic similarity and injects context. However, this approach suffers from knowledge fragmentation; the retrieval results are fixed-length text blocks (typically 500-2000 tokens) lacking structured domain semantics. What the agent sees is "a code snippet containing OrderService," rather than complete domain knowledge such as "the Order entity has 12 attributes, 3 state transitions, and 5 rule constraints." Furthermore, the knowledge is linearly accumulated without convergence. After each code change, it is re-segmented and stored in the database, causing the vector database size to grow linearly over time. Different versions of the same entity may coexist in the vector database, and the agent may retrieve outdated information. There is no semantic deduplication or density improvement mechanism. At the same time, there is a lack of lifecycle management. As the code evolves, the vector database automatically decays without being noticed, repaired, or measured. In addition, RAG only provides "reference information" and has no binding force. The agent can freely ignore the naming style retrieved.

[0054] In some application scenarios, static configuration files are used, such as placing project-level configuration files (e.g., CLAUDE.md or .cursorrules files) in the project root directory, with manually written project specifications provided for Agent reference. This approach relies on manual maintenance; developers need to manually update the configuration files after code changes, and in practice, almost no team can maintain them continuously. Furthermore, the configuration file information is flat, with all specifications piled up in a single file without hierarchical references. This forces Agents to load the controller's specifications when writing Data Access Object (DAO) code, wasting context window resources. Additionally, there is no deviation detection mechanism; the specification claims "Service classes use the Service suffix," but when the OrderManager suffix appears in the code, there is no mechanism to detect this deviation. Moreover, there is no quantitative measurement capability; it is impossible to know how many entities the specification covers, how many interfaces are kept in sync, or the overall health of the knowledge base.

[0055] In some application scenarios, code indexing is used, such as building a structured index of files, classes, and functions by parsing the Abstract Syntax Tree (AST) of the codebase. This approach only includes the code structure and lacks specific semantics. That is, the index knows that "OrderService has a createOrder method," but it does not know the rules and constraints such as "creating an order must check the inventory and initialize the status to CREATED." Furthermore, it cannot distinguish between "what the current code is" and "what the code should be." The current state of the code reflected by the index may contain bad code, and the agent may imitate incorrect naming. In addition, it does not support the integration of external documents. External knowledge such as Product Requirement Documents (PRDs) and design documents cannot be cross-integrated with the code index.

[0056] In some application scenarios, general AI memory methods such as mem0, Zep, and MemGPT are used. Although these methods can provide agents with persistent memory capabilities across sessions, they are designed for conversational memory rather than code domain knowledge. They only record preference information such as "the user last asked me to use a statically typed language (TypeScript)," and do not have code repository analysis capabilities. Furthermore, they lack quality assurance in the engineering domain, and do not have mechanisms such as terminology consistency checks, naming pattern conflict detection, and interface synchronization rate evaluation. In addition, the memory granularity is at the single fact level, while AI-assisted programming requires a complete domain model, making the memory granularity incompatible.

[0057] Furthermore, the aforementioned methods such as RAG, static configuration files, code indexes, and general AI memory all remain at the "static snapshot" stage, failing to address issues like knowledge decay, semantic fragmentation, and a lack of unified quality assurance. They have significant limitations in terms of knowledge structuring, automated maintenance, and quality assurance, making it difficult to continuously provide agents with accurate, complete, and binding engineering common sense throughout project iterations. Static snapshots refer to a one-time collection and solidification of code, documentation, and configuration at a specific point in time, forming a fixed knowledge copy—essentially capturing only the project's current state at a single point in time. This approach lacks the ability to automatically and incrementally synchronize with project iterations, specification updates, and service changes, as well as the capabilities for deviation detection and self-healing. Knowledge remains stuck in an old, fixed version, unable to dynamically evolve, converge, refine, or continuously maintain quality.

[0058] To address the aforementioned technical issues, one or more embodiments of this specification provide a knowledge-based assisted programming method and apparatus. This method automatically extracts domain knowledge from a code repository through a multi-pass scanning pipeline, constructs a multi-layered structured knowledge base, and utilizes a Large Language Model (LLM) as an intelligent editor for continuously maintaining the knowledge system. This enables knowledge to achieve compound growth through semantic merging and density enhancement. Furthermore, continuous maintenance is achieved through incremental synchronization, eight types of deviation detection, six-dimensional compliance assessment, and entropy reduction governance, ensuring that each code generation by the Agent occurs within the real engineering context of the project.

[0059] During the application phase, the Agent can respond to received assisted programming requests, determine the target service domain and development request type corresponding to the assisted programming request, and obtain a multi-layered knowledge base. This multi-layered knowledge base includes a first knowledge layer and a second knowledge layer, wherein the first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. Subsequently, based on the target service domain and / or development request type, the Agent can determine the corresponding configuration information from the multi-layered knowledge base, including at least one of code templates, programming specifications, and file storage paths. The code templates and programming specifications are obtained based on the development architecture specification information, and the file storage paths are obtained based on the development architecture specification information and domain definition information. Finally, based on the configuration information, the Agent can generate the program code corresponding to the assisted programming request.

[0060] In this way, by determining the corresponding configuration information from a multi-layered knowledge base based on the target service domain and development request type of the assisted programming request, the configuration information can be domain-specific and task-specific. Since the configuration information originates from a knowledge base that stores hierarchical development architecture and domain knowledge, and is dynamically determined based on the development request type and target service domain, even in situations with fast project development pace, complex application scenarios, and frequent code iterations, it can provide the programming agent with structured engineering common sense that matches the current task, such as code templates, programming standards, and file storage paths. This effectively ensures the standardization and accuracy of the generated program code, adapts to the rapid iterative evolution of software projects, improves the efficiency, code quality, and maintainability of AI-assisted programming, and reduces the cost of manual review and repair.

[0061] The following description, in conjunction with the accompanying drawings, will first provide an exemplary description of one or more embodiments of the multi-layered knowledge base provided in this specification.

[0062] In one possible implementation, the aforementioned multi-layered knowledge base may include four knowledge layers. (See also...) Figure 1 , Figure 1 This is a structural block diagram of a multi-layered knowledge base provided for one or more embodiments of this specification. Figure 1As shown, a multi-layered knowledge base may include a scheme layer (i.e., the third knowledge layer) 11, a specification implementation layer (i.e., the first knowledge layer) 12, a domain layer (i.e., the second knowledge layer) 13, and an automation assurance layer (i.e., the fourth knowledge layer) 14.

[0063] The solution layer 11 stores the initial configuration information of the project, including top-level rules and direction information, and can be considered the semantic anchor of the entire knowledge base. This layer mainly stores requirements specifications (Spec), architecture overview, glossary, and knowledge maintenance rules, providing upstream constraints for subsequent layers, clarifying the project's basic conventions and top-level consensus, and avoiding naming and conceptual confusion. In one possible implementation, the initial information of solution layer 11 can be automatically generated from basic project information or extracted from existing project requirements documents.

[0064] The specification implementation layer 12 stores development architecture specification information, essentially serving as an engineering implementation manual. This layer includes AI code templates, coding standards, project structure, historical technical decisions, and Data Access Layer (DAL) templates. The DAL templates can be selectively loaded based on the actual data access framework used in the project (such as CrudKill, MyBatis, JPA, etc.) to guide the AI ​​Agent to use only the framework templates matching the project when writing DAL code. Through specification implementation layer 12, the probabilistic guesses of large models can be transformed into deterministic behaviors executed according to specifications, thereby ensuring consistency in code style and project structure.

[0065] Domain Layer 13 stores domain definition information, including conceptual entities (attributes, relationships, constraints), domain processes and state machines, interface specifications, domain constraints and validation rules, code patterns (such as naming conventions, layering patterns, etc.), domain terminology, and validation checklists. It can be organized according to structured files storing different dimensions of domain knowledge. Domain Layer 13 provides the AI ​​Agent with complete domain common sense, enabling it to understand the complete semantics of domain entities, state transitions, and domain constraints, thereby generating code that conforms to domain logic.

[0066] The automated assurance layer 14 stores pre-defined maintenance information, acting as a knowledge immune system. This layer stores incremental synchronization rules, deviation detection strategies (covering eight types of deviations including naming, hierarchical structure, framework consistency, entity definition, and constraint rules), entropy reduction governance schemes (such as entity redundancy merging, interface obsolescence cleanup, terminology drift unification, orphan document deletion, and schema conflict convergence), and a six-dimensional (including structural integrity, semantic richness, consistency, freshness, traceability, and repairability) health assessment model. The automated assurance layer 14 can automatically detect code changes and synchronize knowledge updates, detect and repair knowledge decay, drift, and conflicts, and monitor the quality status of the knowledge base through quantitative health assessments, ensuring that the knowledge base remains effective, accurate, and of high quality as the code evolves.

[0067] For example, the four knowledge layers mentioned above have upstream and downstream referencing relationships. Specifically, the initial configuration information of the solution layer 11 can guide the implementation of the architectural specifications of the specification implementation layer 12; the development architecture specifications of the specification implementation layer 12 can provide engineering constraints for the domain knowledge of the domain layer 13; and the domain definition of the domain layer 13 determines which deviations the automation assurance layer 14 should detect and how to govern them.

[0068] Furthermore, multiple collaborative mechanisms can be introduced into the operation of each knowledge layer. For example, the solution layer 11 has a hard-gate pre-assertion as a rigid access control for the requirements phase; the specification implementation layer 12 can output a uniquely determined engineering decision path for the Agent through deterministic pipelines and static analysis routing; the domain layer 13 can adopt an LLM editor mode to complete the semantic refinement and structured accumulation of knowledge, achieving compound growth of knowledge; and the automation assurance layer 14 can build a knowledge immune system and form a three-layer self-healing closed loop, relying on incremental synchronization, deviation detection, and entropy reduction governance mechanisms to continuously maintain the overall healthy operation of the multi-layer knowledge base.

[0069] In one possible implementation, the aforementioned multi-layered knowledge base can be stored as a structured set of files under the project directory. In this way, through the combination of hierarchical referencing and supporting mechanisms, the multi-layered knowledge base forms a living, self-evolving engineering knowledge system.

[0070] It should be noted that this example only uses a four-layer knowledge base. In practical applications, the number and type of knowledge layers included in a multi-layer knowledge base can be flexibly configured. For example, a multi-layer knowledge base may only include a specification implementation layer and a domain layer to meet basic assisted programming needs, or it may selectively add a solution layer, an automation assurance layer, or other custom knowledge layers. There are no restrictions here.

[0071] The following is combined with Figure 1 The multi-layered knowledge base shown illustrates an embodiment of a knowledge base-based assisted programming method.

[0072] In the knowledge-based assisted programming method provided in one or more embodiments of this specification, a corresponding multi-layered knowledge base can be first constructed based on the code repository corresponding to the project to be processed. Then, the constructed multi-layered knowledge base is applied to perform assisted programming operations, and the knowledge base is continuously maintained during the code evolution process. This method can be executed by AI CodingAgent (hereinafter referred to as Agent), which can be integrated into AI programming tools such as Claude Code, Cursor, and GitHub Copilot.

[0073] The construction process of a multi-layered knowledge base will be explained below.

[0074] See Figure 2 , Figure 2 This is a flowchart illustrating a method for constructing a multi-layered knowledge base, provided for one or more embodiments of this specification. Figure 2 As shown, the method may include steps S202 to S210.

[0075] Step 202: Construct a multi-layered knowledge base corresponding to the target code repository.

[0076] For example, the source code of each project is stored in an independent code repository. Therefore, a multi-layered knowledge base can be built for the target code repository corresponding to the project, providing a structured storage carrier for the engineering specifications and domain knowledge extracted from the code repository later.

[0077] For example, a structured directory (e.g., .codewiki / ) can be created in the root directory of the target code repository to store multi-layered knowledge bases, and a storage framework can be pre-defined for the first knowledge layer (specification implementation layer), the second knowledge layer (domain layer), the third knowledge layer (solution layer), and the fourth knowledge layer (automation assurance layer).

[0078] In this way, by establishing a multi-layered knowledge base for the code repository corresponding to each engineering project, the physical association and isolation between project-level engineering knowledge and application code are realized, providing a standardized carrier for subsequent automatic extraction and storage of knowledge, enabling knowledge to establish a clear ownership relationship with the code repository, which facilitates unified management and version control.

[0079] Step 204: Parse the target code repository to obtain code information.

[0080] One possible implementation involves performing a full static analysis on all source files in the target code repository, transforming unstructured code text into structured data (i.e., code information). The code information is a collection of structured data corresponding to each code unit (including classes, interfaces, enums, etc.) in the code repository.

[0081] For example, a fast-scanner can be invoked to traverse all Java source files under the target code repository path, perform lexical analysis and syntax parsing on each file, and output a collection of structured information for multiple code units, named ClassInfo[]. Each ClassInfo object corresponds to the structured information of a code unit, and all ClassInfo objects together constitute the code information.

[0082] Furthermore, each ClassInfo[] can contain fields such as className, fullName, package, filePath, type, extends, implements[], annotations[], imports[], and patterns[{type, layer, subtype}]. Among these: className is the basic name of the code unit and is the core identifier for domain knowledge extraction.

[0083] fullName is a fully qualified name consisting of the package path and the code unit name, used for knowledge tracing and uniqueness verification.

[0084] The package path is where the code unit is located, reflecting the project's architectural layers and module affiliation.

[0085] filePath is the physical location of the code unit file in the target code repository, used for file location and mapping association.

[0086] `type` is a structure type, and its values ​​include `class`, `interface`, `enum`, etc., used to distinguish code roles and purposes.

[0087] `extends` specifies the name of the parent class that the current code unit inherits from, and is used to extract inheritance relationships and architectural patterns.

[0088] `implements[]` is a collection of all interfaces implemented by the current code unit, used to analyze interface constraints and service specifications.

[0089] annotations[] is a collection of framework annotations placed on code units, used to identify code layering and technology framework types.

[0090] imports[] is a list of external packages and classes that a code unit depends on, used to analyze dependencies and module associations.

[0091] patterns[{type, layer, subtype}] is a set of code patterns identified from the current code unit. Each pattern contains three attributes: type, layer, and subtype, which are used to mark the engineering specifications, architectural layers, and coding styles that the class conforms to.

[0092] In this way, by transforming source code, which is difficult for agents to understand directly, into standardized code information that can be processed efficiently, a complete and accurate basic data source is provided for subsequent engineering specification extraction and domain knowledge identification. At the same time, this code information can be reused in multiple subsequent stages of the build process (such as multi-dimensional information extraction and module dependency analysis in class placement decisions), avoiding repeated code parsing and improving build efficiency.

[0093] Step 206: Extract multi-dimensional information from the code information to obtain development architecture specification information and domain information.

[0094] In one possible implementation, information can be extracted from at least two dimensions of code information, including annotations, structure, naming information, framework type, and code characteristics, to obtain development architecture specification information and domain information.

[0095] For example, after obtaining the structured ClassInfo[] data, two types of key knowledge materials can be extracted from it: engineering specification knowledge and domain knowledge. The extraction process can include processing in multiple dimensions.

[0096] Annotation detection: Traverse the annotation array of each code unit to identify framework markers such as @Entity, @Table, @Service, @Controller, and @SOFAService, thereby determining the layered role (such as controller layer, service layer, data access layer, etc.) and component type (such as entity class, service class, controller, etc.) of the code unit.

[0097] Structural analysis: Analyze the field and method information of code units, such as detecting primary key fields like private Long id to identify entity information, and extract the method signature of each method (including method name, parameter list, return type, etc.) to provide a structural basis for subsequent domain layer entity modeling.

[0098] Naming heuristics: Match the suffixes of code unit names and count the frequency of occurrence of suffixes such as Entity, DO, Service, ServiceImpl, and Controller to extract the naming conventions actually used in the project and form a solidified naming pattern.

[0099] Framework detection: Identify the type of Remote Procedure Call (RPC) framework from annotations and configuration information, such as SOFA, HSF, Dubbo, gRPC, etc., determine the service communication technology stack of the project, and extract the corresponding RPC service specifications, such as interface definitions, timeout configurations, serialization methods, etc.

[0100] Type feature extraction: Extracting common technical paradigms from global features of the code, including response wrapper patterns (e.g., uniform return format Result). <t>Error code formats, pagination methods, validation strategies, and idempotency mechanisms are used to refine the overall technical specifications of the project.

[0101] Through the above multi-dimensional information extraction, two types of outputs can be obtained: engineering specification knowledge (including naming rules, hierarchical structure, DAL framework, code template, technical paradigm, etc.) and domain knowledge (including domain entities, interfaces, domain features, domain constraints, etc.).

[0102] Furthermore, engineering specification knowledge can be written into the first knowledge layer, and domain knowledge can be output to subsequent steps to generate domain definition information.

[0103] In this way, by using multiple scans and overlays, implicit engineering specifications and domain clues can be efficiently and comprehensively extracted from structured code information, making the "project rules" that are difficult to summarize manually explicit and data-driven. Multi-dimensional cross-validation can significantly reduce the false positive rate. The extracted engineering specification knowledge provides factual basis for subsequent deterministic routing, while the domain knowledge provides rich raw materials for domain modeling.

[0104] Step 208: Store the development architecture specification information in the first knowledge layer.

[0105] For example, the engineering specification knowledge (i.e. development architecture specification information) obtained in step S206 above can be written into the first knowledge layer (specification implementation layer).

[0106] The content stored in the specification implementation layer can include AI code templates (covering the five layers of the entire stack, including front-end, back-end, and data access), coding standards (such as naming conventions and code styles), project structure (such as module division and package path rules), historical technical decisions, and DAL templates.

[0107] It should be noted that DAL templates can be categorized and marked according to the data access framework actually used in the target code repository (such as CrudKill, MyBatis, JPA, etc.) so as to achieve physical isolation and deterministic loading in the subsequent application stage. When the Agent writes the data access layer code, it can only see the framework template that matches the project; other templates are not visible or selectable.

[0108] In this way, by persisting engineering specification information to the specification implementation layer, project-level architectural constraints, coding styles, framework selection, and other "engineering common sense" no longer rely on verbal instruction from developers or scattered configuration files, but are solidified in a structured, machine-readable form in a knowledge base. This provides a deterministic execution basis for subsequent code generation by the Agent. The Agent can directly obtain code templates, naming conventions, and layering rules that match the project from the specification implementation layer, thereby avoiding problems such as naming conflicts, mixed frameworks, and arbitrary file locations caused by inconsistent understandings among different developers or at different times. This significantly improves the consistency and standardization of the generated program code, while reducing the cost of code review and repair.

[0109] Step 210: Obtain domain definition information based on domain information, and store the domain definition information in the second knowledge layer.

[0110] In one possible implementation, the association between the code module and the preset domain can be determined based on domain information. Then, the user's confirmation instruction on the association is received, and structured domain knowledge is obtained based on the confirmed association through a large language model. The structured domain knowledge is then stored as domain definition information in the second knowledge layer.

[0111] For example, when determining the association between a code module and a preset domain based on domain information, an association score can be obtained based on the association factors between the code module and the preset domain and the preset weight parameters of the association factors. The preset domains whose association scores meet the preset score conditions are determined as the domains associated with the code module, so as to obtain the association between the code module and the preset domain.

[0112] Among them, the correlation factors may include at least one of name similarity, entity correlation, complexity factor, and keyword matching degree.

[0113] For example, the code module structure can be obtained first. The code modules can be automatically aggregated based on the package paths of the code units (i.e., ClassInfo) obtained in step S204 above. For example, code units with the same package name prefix can be grouped into the same module, or they can be directly obtained based on the existing module division of the project (such as Maven submodules). Each code module can contain multiple related code units.

[0114] Afterwards, the domain class knowledge (i.e., domain information) and code module structure output by the aforementioned step S206 can be used to calculate the correlation score between each code module and the preset domain (e.g., order domain, user domain, payment domain) using the four-factor correlation scoring algorithm, i.e. the following formula (1).

[0115] relevance_score(module,domain)=name_similarity×0.3+entity_relevance×0.4+complexity_factor×0.2+doc_keyword_match×0.1 (1) Here, `relevance_score(module,domain)` represents the relevance score between the code module and the domain; `name_similarity` represents the name similarity between the code module and the domain; `entity_relevance` represents the entity relevance between the code module and the domain, i.e., the degree to which the code units contained in the code module reference the core entity class of the preset domain; `complexity_factor` is a complexity factor used to represent the code complexity of the code module (such as the number of lines of code, the number of dependencies, etc.); `doc_keyword_match` represents the keyword matching degree between the code module and the domain, i.e., the matching degree of domain-related keywords appearing in the comments or documents within the code module; the corresponding coefficients of 0.3, 0.4, 0.2, and 0.1 are the preset weight coefficients for the four factors (name similarity, entity relevance, complexity factor, and keyword matching degree), used to adjust the importance of each factor in the relevance calculation.

[0116] For example, the preset weight coefficient for name similarity can be 30%, the preset weight coefficient for entity relevance can be 40%, the preset weight coefficient for complexity factor can be 20%, and the preset weight coefficient for keyword matching degree can be 10%.

[0117] It should be noted that the above-mentioned preset weight coefficients can be set according to the domain characteristics of the actual project, actual needs, or human experience in order to optimize the accuracy of association recommendations.

[0118] Furthermore, based on the calculation results, for each code module, preset fields that meet the preset score conditions, such as a correlation score ≥ 0.8, can be selected. Then, these preset fields are sorted from high to low scores, and the top three fields are selected as the recommendation results, thereby establishing a preliminary correlation between the code module and these preset fields. If there are fewer than three preset fields that meet the score criteria, all of them can be recommended.

[0119] It is understood that the above-mentioned preset score conditions and recommended number can be adjusted according to actual needs, and this application embodiment does not limit this.

[0120] After establishing the aforementioned relationships, the Agent can present the recommendation results to the user through the interactive interface of the programming tool. At this point, the user can determine the scope and boundaries of each domain entity and confirm, correct, add, or delete the recommendations. This effectively prevents the illusionary or erroneous recommendations that LLM might produce.

[0121] Furthermore, LLM can be invoked to perform semantic integration and structuring of code modules based on the confirmed relationships, resulting in structured domain knowledge.

[0122] For example, LLM can work in editor mode, performing cross-file reorganization (extracting and integrating relevant information scattered across multiple files), semantic judgment (determining whether to create, update, merge, or discard existing knowledge), and external document enhancement (reading descriptions from engineering project-related design documents and cross-validating them with code implementation), thereby refining the original domain information into structured, semantically clear domain knowledge units.

[0123] Furthermore, to reduce the false positive rate of LLM judgments and improve the compactness of the knowledge base, an auxiliary vector similarity deduplication step can be introduced before calling LLM. For example, an embedding model can be used to convert the description of code units, entity definitions, interface signatures, etc., into vector representations, and a similarity threshold (e.g., 0.85) can be set. When the vector cosine similarity of two knowledge items exceeds the threshold, they are marked as candidate duplicates, and then LLM performs secondary confirmation and merging. This semantic deduplication optimization can reduce the invalid processing of LLM and improve the accuracy and density of the knowledge base.

[0124] Furthermore, after obtaining structured domain knowledge, it can be written into the domain layer.

[0125] One possible implementation involves creating domain-specific directories, such as `domains / order / `, and generating seven structured domain knowledge files (referred to as a Domain 7-Artifact Set) within these directories. Each file stores domain knowledge across different dimensions. For example, these seven dimensions could include: concepts.md: Used to store core entities and their attributes, relationships, and constraints.

[0126] business-flow.md: Used for storing process and state machine information in the storage domain, including flow steps, state transition rules, etc.

[0127] api-spec.md: Used to store interface specifications, including method signatures, parameters, return values, routes, request and response formats, etc.

[0128] constraints.md: Used for constraints and validation rules, prohibited modes, etc. in the storage domain.

[0129] code-patterns.md: Used to store code pattern specifications, such as naming conventions, hierarchical patterns, DAL patterns, etc.

[0130] glossary.yml: Used for a glossary of storage domain terms, providing a unified semantic definition.

[0131] validation-checklist.md: This file stores a validation checklist for code review.

[0132] Simultaneously, a hidden metadata directory `.meta / ` can be generated under the domain directory, containing `version.yml` and `CHANGELOG.md`. `version.yml` records the domain knowledge's ownership information, version number, and the most recent associated code commit number; `CHANGELOG.md` records incremental change logs for each addition, modification, or obsolescence of knowledge. This metadata ensures knowledge traceability and version management capabilities. Together, the seven domain components and the metadata directory constitute a complete modeling unit for this domain.

[0133] In this way, the collaborative working mode of machine recommendation, user confirmation, and LLM refinement not only leverages the powerful semantic understanding capabilities of LLM, but also ensures the accuracy of knowledge boundaries through human access control, effectively preventing the injection of erroneous knowledge caused by model illusion.

[0134] It should be noted that the user confirmation step described above is only an optional implementation method and is not a necessary technical feature of this solution. In practical applications, the user confirmation step can also be omitted according to the needs of the scenario. For example, the large language model can automatically complete the confirmation of associations and knowledge editing based on preset rules and confidence thresholds. This is not limited here.

[0135] Ultimately, domain knowledge is distilled into a structured set of seven files and traceable metadata, ensuring that domain definition information is complete, consistent, version-controllable, and automatically synchronized. This allows agents to directly load this structured domain knowledge from the domain layer during subsequent programming, understand the complete semantics of domain entities, state transitions, and domain constraints, thereby generating code that conforms to domain logic, no longer relying on fragmented code snippets or general knowledge within the model. Simultaneously, the metadata provides a data benchmark for subsequent incremental synchronization, deviation detection, and entropy reduction governance.

[0136] In one possible implementation, building a multi-layered knowledge base may also include: obtaining the initial configuration information of the target code repository and storing the initial configuration information in the third knowledge layer.

[0137] For example, configuration files (such as spec-config, project description in pom.xml, and initial parameters input by the user) in the root directory of the target code repository corresponding to the project can be read to obtain initial configuration information such as specifications, architecture overview, glossary, and knowledge maintenance rules. This initial configuration information is then written into the third knowledge layer (solution layer) in a structured form (such as spec.yaml). This information will serve as the semantic anchor of the entire knowledge base, providing upstream constraints for subsequent layers and ensuring that the domain definition and engineering specifications are consistent with the top-level design of the project.

[0138] In one possible implementation, constructing a multi-layered knowledge base may further include: obtaining preset maintenance information of the multi-layered knowledge base and storing the preset maintenance information in the fourth knowledge layer.

[0139] The fourth knowledge layer (automation assurance layer) is the carrier of the knowledge immune system. This knowledge immune system consists of a self-healing closed loop composed of three mechanisms: incremental synchronization, entropy reduction governance, and six-dimensional health assessment, ensuring that the knowledge base remains fresh as the code evolves.

[0140] For example, predefined maintenance information such as incremental synchronization strategies, deviation detection thresholds, entropy reduction governance trigger rules, and various weight parameters for the six-dimensional health assessment can be predefined. This predefined maintenance information can then be written into the automated assurance layer using structured configuration files, such as YAML or JSON. This allows the knowledge base to automatically perform synchronization, detection, governance, and assessment according to these rules during subsequent operation, without manual intervention. The specific maintenance mechanisms for incremental synchronization, deviation detection, health assessment, and entropy reduction governance stored in the automated assurance layer will be described in detail in subsequent maintenance phases and will not be elaborated here.

[0141] The above construction method can automatically build a complete multi-layered knowledge base that includes development architecture specifications, domain knowledge, project top-level configuration, and automated maintenance strategies. This multi-layered knowledge base corresponds one-to-one with the code repository and has the characteristics of being structured, version-controllable, and incrementally evolving, providing a persistent, deterministic, and measurable engineering common sense foundation for AI-assisted programming.

[0142] Furthermore, the scope of the knowledge base can be extended to the team level, enabling knowledge reuse across projects. For example, for multiple related projects (such as multiple microservices in the payment domain), a shared domain knowledge base can be built, storing common domain definitions, rule constraints, code patterns, etc. When the agent generates code for any project, it can simultaneously reference both the project-specific knowledge base and the team-shared knowledge base, thereby avoiding the repeated extraction of the same domain knowledge and improving knowledge reuse rates. The maintenance of the team-level knowledge base can be uniformly handled by dedicated personnel or automated processes, and the practices of each project can be synchronized regularly.

[0143] After constructing a multi-layered knowledge base, the Agent can apply this knowledge base to perform assisted programming. The following describes the Agent's knowledge base-based assisted programming method.

[0144] See Figure 3 , Figure 3 This is a flowchart illustrating a knowledge-based assisted programming method provided for one or more embodiments of this specification. Figure 3 As shown, the method may include steps S302 to S308.

[0145] Step S302: In response to the received auxiliary programming request, determine the target service area and development request type corresponding to the auxiliary programming request.

[0146] For example, after receiving a user's request for assisted programming, such as "create a Service class for creating orders in the order domain", the Agent can perform semantic parsing on the request and extract two key dimensions: the target service domain is "order domain" and the development request type is "code generation".

[0147] The target service domain can be used to load the corresponding domain definition information from the domain layer later; the development request type is used to determine which type of configuration information needs to be obtained from the specification implementation layer, such as code templates, programming standards, file storage paths, etc., and can also be used to determine the current development stage, such as code generation, solution design, code review, etc.

[0148] This step allows the Agent to clarify the scope and nature of the current task, preparing it for subsequent on-demand loading of the knowledge base.

[0149] Step S304: Obtain a multi-layered knowledge base, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information.

[0150] For example, the Agent can load a multi-layered knowledge base pre-built for the current code repository. This knowledge base contains project-level engineering specifications and domain knowledge. Specifically, the specification implementation layer stores development architecture specification information such as code templates, coding standards, project structure, and DAL templates; the domain layer stores domain definition information such as entity definitions, operation procedures, interface specifications, and constraint rules.

[0151] In practice, the Agent can load only the knowledge layer that is relevant to the current development request type, avoiding loading irrelevant information, thereby saving the model's context window budget. That is, each Agent only loads the minimum required knowledge fragments at a specific stage.

[0152] Step S306: Based on the target service domain and / or development request type, determine the corresponding configuration information from the multi-layer knowledge base; wherein, the configuration information includes at least one of code template, programming specification and file storage path, the code template and programming specification are obtained based on development architecture specification information, and the file storage path is obtained based on development architecture specification information and domain definition information.

[0153] One possible implementation is to obtain code templates and programming standards from the development architecture specification information of the first knowledge layer based on the development request type.

[0154] For example, if the development request type is code generation type, the development framework type corresponding to the auxiliary programming request can be determined, and the code template corresponding to the development framework type can be obtained from the development architecture specification information.

[0155] Specifically, when the development request type is code generation, the Agent first needs to determine the data access framework actually used by the current project. The Agent can read the build configuration file in the project root directory (such as pom.xml in a Maven project) and extract a list of all dependency packages from it.

[0156] Then, the project's development framework type is matched according to the preset framework detection rules. For example, if the project introduces the crudkill-starter dependency, the CrudKill data access framework is used; if it introduces the dalgen-core dependency, the DalGen data access framework is used; if it introduces the spring-data-jpa dependency, the JPA persistence framework is used; if it introduces the mybatis dependency, the MyBatis data access framework is used, and so on.

[0157] After determining the development framework type, the Agent only loads the DAO code template corresponding to that framework type from the code template library of the specification implementation layer. Templates for other frameworks are physically isolated and are not visible or selectable by the Agent.

[0158] Simultaneously, the agent can also obtain programming specification information from the specification implementation layer. These specifications include naming conventions, layered structure specifications, and DAL framework usage specifications. These programming specifications are not manually written, but are automatically generated and solidified into the specification implementation layer during the knowledge base construction phase by extracting patterns from the actual code in the code repository multiple times.

[0159] The naming convention for suffixes was determined by scanning the suffixes of all classes and counting their frequency. For example, in the Service class, the suffix "Service" appears 23 times, and "ServiceImpl" appears 18 times; in the Controller class, the suffix "Controller" appears 15 times; and in the Entity class, the suffix "Entity" appears 8 times, and "DO" appears 12 times. Based on this, the actual naming conventions used in the project can be extracted, such as consistently using the "Service" suffix instead of "Manager" for Service classes.

[0160] The layered structure specification is determined by statistically analyzing the distribution of the number of classes in each layer (including the web layer, business layer, and DAL layer). For example, the web layer has 18 classes, the business layer has 35 classes, and the DAL layer has 22 classes. This allows us to determine the layering ratio of the project and ensure that the Agent generates code according to the actual layering.

[0161] The DAL framework usage guidelines are determined by the usage of statistical data access frameworks. For example, out of 22 data access classes, 20 use the CrudKill framework, and 2 use the MyBatis framework. Therefore, it can be determined that the mainstream framework for the project is CrudKill, and the Agent should use CrudKill as the standard when generating DAL code.

[0162] In this way, the Agent can use a framework template that perfectly matches the project when generating code, avoiding compilation errors caused by mixing different frameworks. At the same time, it strictly adheres to the project's actual naming conventions, layering, and framework usage habits, eliminating unreasonable phenomena such as mixing "OrderService" and "OrderManager" within the same project, or having a significantly larger number of web layer classes than the business layer. Through physical isolation and standardized solidification, the probabilistic choices of the large model are transformed into deterministic engineering decisions, significantly improving the consistency and standardization of the generated code.

[0163] In one possible implementation, the file storage path can be determined based on the target service domain, the development request type, the development architecture specification information in the first knowledge layer, and the domain definition information in the second knowledge layer.

[0164] For example, the hierarchical affiliation information corresponding to the auxiliary programming request can be determined based on the development request type and domain definition information, and candidate storage locations can be determined based on the target service domain and hierarchical affiliation information. Then, target storage locations that meet preset conditions can be selected from the candidate storage locations. The preset conditions include preset constraints and / or preset adaptation conditions. Finally, the file storage path can be determined based on the target storage location and development architecture specification information.

[0165] Specifically, the process can be divided into the following five steps.

[0166] The first step is dependency analysis: The agent first analyzes the other modules (such as OrderDAO, UserService, etc.) that the code unit to be created (such as a new OrderService class) depends on. By parsing the imported classes, method calls, and annotations in the code unit, a dependency graph of the code unit is constructed, thus obtaining the set of modules that it must depend on, denoted as requiredModules (such as {order-dal, user-api}). This step can clearly define the dependency information required when selecting the target storage location, laying the foundation for subsequent dependency reachability verification (i.e., pre-setting constraints).

[0167] The second step is to determine the layer affiliation and candidate storage location: Based on the development request type (e.g., "code generation") and the domain definition information obtained from the domain layer, the Agent determines the layer to which the code unit should belong. For example, different types of code units correspond to different default layers. If the class to be created is a Controller, it should belong to the web or API layer; if it is a Service class, it should belong to the biz or service layer; if it is a Repository class, it should belong to the dal or data layer; if it is an Entity class, it should belong to the dal or domain layer, etc. For example, creating a Service class would place it at the biz layer. Then, by combining the target service domain (e.g., "order domain") and the layer affiliation information, all possible candidate modules for storing the code unit can be filtered from the project structure description of the specification implementation layer, such as order-biz, order-service, etc., resulting in a candidate storage location list, candidateModules.

[0168] The third step is to verify dependency reachability through preset constraints: For each candidate module obtained in the second step, the Agent can check whether the module meets the preset constraints, that is, whether the module can access the requiredModules set of modules that must depend on it, as determined in the first step. For example, if requiredModules includes order-dal (located in the data access layer), and a candidate module is order-web (located in the web layer), according to common layered architecture constraints (the web layer cannot directly depend on the dal layer), the order-web module will be deemed invalid and excluded. Through this verification, the set of validModules, which meets all preset constraints and passes the dependency reachability check, can be obtained.

[0169] The fourth step is to calculate the affinity score and select the module with the highest score: For each valid module obtained in the third step, the Agent can calculate the placement affinity score, placement_score, by using the preset adaptation conditions, i.e., the following formula (2): Placement_score(m)=50 × is_primary_domain(m) + 20 × is_related_domain(m) + 10 × name_keyword_match(m) + 5 × package_structure_match(m) + 3×has_source_roots(m) (2) Among them, is_primary_domain(m) is used to indicate whether the module belongs to the primary domain of the target service domain (such as the primary module order-biz in the order domain), with a value of 1 or 0 and the highest weight; is_related_domain(m) is used to indicate whether the module is associated with the target service domain (such as the payment module associated with the order domain), with a value of 1 or 0; name_keyword_match(m) is used to indicate the degree of keyword matching between the module name and the target service domain name and the code unit name (such as order-biz having a high degree of matching with "order" and "OrderService"), with a value range of 0 to 1; package_structure_match(m) is used to indicate whether the module's package structure is consistent with the package path specification defined in the first knowledge layer (such as com.company.order.biz conforming to the specification), with a value range of 0 to 1; has_source_roots(m) is used to indicate whether the module has a real source code directory (such as excluding test or resource directories), with a value of 1 or 0.

[0170] It should be noted that the coefficients (50, 20, 10, 5, 3) are used to highlight the differences in importance of different factors, rather than to calculate precise percentages. Therefore, the value of each coefficient only needs to reflect the relative importance.

[0171] After calculating the score of each legitimate module according to the above formula (2), the module with the highest score can be selected as the target storage location selectedModule. Through this scoring mechanism of preset adaptation conditions, the most suitable storage location can be selected from multiple legitimate candidate modules.

[0172] Step 5: Construct the complete package path: After determining the target storage module, the Agent can generate a complete file storage path by concatenating the package path rules in the specification implementation layer (such as base package com.company, layer package biz, type package service, class name OrderService) according to the format of base package + layer package + type package + class name, such as com.company.order.biz.service.OrderService. This path is unique and cannot be changed. The Agent directly writes the generated code into the file corresponding to this path.

[0173] Through the above embodiments, the Agent can no longer rely on random guesses from a large model. Instead, it uniquely determines the storage location of new files through static code analysis and pre-defined layering, domain, and constraint rules. Each Agent loads only the minimum necessary knowledge fragments at a specific stage, such as using only the layering rules, package path rules, and domain affiliation information implemented in the specification. This avoids interference from irrelevant knowledge and solves the problem of chaotic file locations. In other words, deterministic routing, through static analysis, provides the Agent with a uniquely determined engineering decision path, replacing probabilistic inference and ensuring the consistency and maintainability of the code structure.

[0174] Step S308: Based on the configuration information, generate the program code corresponding to the auxiliary programming request.

[0175] For example, the Agent can use the code templates (such as the DAO template of the CrudKill framework), programming standards (such as naming conventions and layering conventions) and file storage paths (such as com.company.order.biz.service.OrderService) obtained above to generate program code that conforms to common sense in project engineering, and automatically write the generated program code to the determined file storage path to complete the assisted programming task.

[0176] In this way, the entire assisted programming process is driven by deterministic routing rules, avoiding random errors, ensuring the consistency and standardization of generated code, adapting to the characteristics of rapid iteration and evolution of software projects, improving the efficiency, code quality and maintainability of assisted programming, and reducing the cost of manual review and repair.

[0177] It's important to note that in the actual software development lifecycle, the types of assisted programming requests are not limited to code generation, but also include multiple stages such as requirements analysis, solution design, code review, test design, and refactoring. To fully leverage the multi-layered knowledge base, the Agent can reference the appropriate knowledge layer as needed based on the current stage of the task, thereby achieving end-to-end engineering common sense support.

[0178] For example, when the development request type is requirements analysis, the Agent primarily references information from the solution layer, including requirements specifications, architecture overviews, and glossaries. Hard-gate mechanisms in the solution layer can be implemented through pre-assertions. For instance, if a requirements specification fails to pass approval, the Agent will refuse to proceed to the subsequent coding phase, thus ensuring that all development activities are grounded in evidence.

[0179] When the request type is "Solution Design," the Agent can reference both the solution layer and the domain layer. The solution layer provides the project's top-level structure and terminology consensus, while the domain layer provides domain constraints and interface specifications. When generating a technical solution, the Agent references project structure files (e.g., project-structure.md) to determine file placement and constraint files (e.g., constraints.md) to determine actual constraints, thus ensuring that the solution design conforms to both the project's top-level planning and meets domain-specific requirements.

[0180] When the development request type is code generation (i.e., the scenario described in steps S302 to S308 above), the Agent can reference the specification implementation layer and the domain layer. The specification implementation layer provides DAL templates, coding standards, project structure, and package path rules, while the domain layer provides entity definitions, specific processes, constraint rules, etc. When generating program code, the Agent can simultaneously follow engineering specifications and domain logic, generating code that meets both architectural requirements and service semantics.

[0181] When the development request type is code review, the Agent can reference all knowledge layers. Specifically, the solution layer provides requirement specifications as acceptance criteria, the specification implementation layer provides coding standards and project structure as review benchmarks, the domain layer provides service constraints and validation checklists as the basis for logical checks, and the automation assurance layer provides deviation detection results and historical change records as quality references. The Agent reviews the code item by item against the validation checklist.md in the domain layer to ensure that the code conforms to the specification requirements of all layers.

[0182] When the development request type is test design, the Agent primarily references the domain layer. Specifically, the Agent can refer to the service rules and prohibited modes in the constraint file constraints.md to design boundary and exception test cases; refer to the state machine in the process file business-flow.md to design test cases for normal processes; and through the service semantics of the domain layer, the generated test cases can comprehensively cover the service scenarios.

[0183] When the development request type is refactoring, the Agent can reference the specification implementation layer. Specifically, the Agent can refer to the coding-standards.md and code-patterns.md files, and adjust the internal structure to conform to the project's unified engineering standards while keeping the external behavior of the code unchanged. In addition, the historical technical decisions in the specification implementation layer also provide a basis for framework selection and dependency adjustment during refactoring.

[0184] The aforementioned end-to-end behavior exhibits an invariant: regardless of the stage the Agent is in, its internal context window may forget earlier information due to scrolling, but the external multi-layered knowledge base always exists and remains persistently accessible. In other words, the knowledge base is decoupled from the Agent's session state and will not be lost when the session ends or the context is cleared. The Agent can reload the required knowledge from the knowledge base at any stage, ensuring consistency and reliability of engineering common sense across stages and sessions.

[0185] Through this end-to-end knowledge-driven approach, the Agent receives stable and accurate engineering common sense support throughout the entire software development process, thereby significantly improving development efficiency and quality.

[0186] Furthermore, as code repositories continuously undergo evolutionary operations such as additions, modifications, and refactoring, a deviation gradually arises between the actual state of the code and the standardized state recorded in multi-layered knowledge bases.

[0187] To ensure that the multi-layered knowledge base remains synchronized with the code, accurate, and effective, and can be continuously updated and maintained, the following explains the updating and maintenance of the multi-layered knowledge base.

[0188] One possible implementation involves bias detection on a multi-layered knowledge base.

[0189] Deviation detection refers to automatically comparing the actual state of the code with the knowledge base specifications to identify various deviations such as naming drift (code naming deviates from the unified specification), concept drift (actual semantics deviates from the standard definition), and pattern conflict (development architecture and implementation paradigm contradict each other), and reporting them in a graded manner according to their severity level.

[0190] One possible implementation involves performing deviation detection between the development architecture specification information in the multi-layered knowledge base and the code information in the target code repository to obtain the deviation detection results of the multi-layered knowledge base.

[0191] Deviation detection can include at least one of the following: naming detection, hierarchical structure detection, framework consistency detection, entity definition detection, and constraint rule detection.

[0192] Deviation detection results can include deviation type, deviation level, and automatic repair flag. Deviation type can include missing specification documents, missing code files, unsynchronized class renaming, name drift, pattern drift, concept drift, interface drift, constraint violation, etc. Deviation level is divided into critical error, warning, and informational message. Automatic repair flag indicates whether the deviation can be automatically repaired by the agent, including whether it can be automatically repaired or not.

[0193] The severity level can be determined using rule-based heuristics or LLM inference. Alternatively, a machine learning classification model (such as LambdaMART) can be introduced to learn from historical labeled data and automatically assign severity levels to new deviations. Specifically, deviation detection results and manually labeled severity levels can be collected as training samples to extract deviation features (such as deviation type, code change frequency, and scope of impact) and train the LambdaMART classifier. This model reduces reliance on fixed rules and adapts to deviation patterns across different projects, improving classification accuracy and consistency. Similarly, the determination of automatic repair labels can also be predicted using the same model.

[0194] Furthermore, the Agent can perform a full deviation check periodically or automatically after each update (i.e., incremental synchronization). The check process can use five sequential detectors, including a naming detector, a layered detector, a framework consistency detector, an entity definition detector, and a constraint rule detector, which respectively cover code specification comparison, entity definition detection, and constraint rule detection in different dimensions.

[0195] The naming detector extracts a whitelist of allowed naming suffixes (e.g., Service, Controller suffixes) from the code pattern specification document (code-patterns.md file) used in the specification implementation layer to store information such as naming conventions and layering patterns. It then uses regular expressions to match the actual class name suffixes, identifying non-compliant naming, such as the use of `OrderManager` in the code when the specification requires `Service`. The detector outputs a deviation type of `NAMING_DRIFT` with a severity level of `Warning`, which can be automatically corrected.

[0196] Furthermore, to further improve the accuracy of knowledge extraction and support multiple languages, syntax parsing tools (such as Tree-sitter) can be used to generate an Abstract Syntax Tree (AST) to replace regular expression matching for code structure analysis. Tree-sitter supports accurate incremental parsing for multiple languages ​​such as TypeScript, Go, and Python, and can more reliably identify information such as annotations, class structures, and method signatures, reducing false matches. It is also easily extendable to projects using non-Java languages. Through this enhancement, this solution can be adapted to more technology stacks, improving the versatility and accuracy of knowledge extraction.

[0197] The layered detector can statistically analyze the actual distribution of class counts in the web, business, and digital level (DAL) layers, compare it with the layered structure specification recorded in the implementation layer, and detect any imbalances in the layer ratios, such as too few classes in the business level and too many in the web level. The detector outputs a bias type of pattern drift (PATTERN_DRIFT) with a severity level of Warning, which can be automatically corrected.

[0198] The framework consistency detector can detect whether multiple data access frameworks exist simultaneously in the code, such as both CrudKill implementations and MyBatis Mapper. It compares the results with the DAL framework specifications recorded in the specification implementation layer. If coexistence or deviation from the specification is found, the output deviation type is Constraint Violation (CONSTRAINT_VIOLATION), with a severity level of Critical, which cannot be automatically corrected.

[0199] The entity definition detector can extract a list of entities (such as Order and User) from the core entity definition document (concepts.md file) in the domain layer. It then uses fuzzy substring matching in the code to find corresponding class or field definitions, detecting inconsistencies in entity definitions, such as Order becoming OrderDO in the code and missing attributes. The detector outputs a bias type of Concept Drift (CONCEPT_DRIFT) with a severity level of Warning, which can be automatically corrected.

[0200] The constraint rule detector can parse prohibited patterns from the domain constraint and validation rule document (constraints.md file) at the domain layer, such as prohibiting the direct creation of objects using the `new` keyword or prohibiting the use of certain deprecated APIs. It searches for these patterns in the code to detect behaviors that violate the constraints. The detector can also output a deviation type as constraint violation (CONSTRAINT_VIOLATION), with a severity level of Critical, which cannot be automatically corrected.

[0201] In addition to the deviations output by the five detectors mentioned above, other deviations can be detected through file system scanning and Git change comparison, such as missing specification files (FILE_MISSING_IN_SPEC, Critical, can be automatically repaired), missing code files (FILE_MISSING_IN_CODE, Warning, cannot be automatically repaired), unsynchronized class renaming (CLASS_RENAMED, Warning, can be automatically repaired), and API drift (API_DRIFT, Warning, can be automatically repaired), etc.

[0202] In summary, deviation detection can cover eight types of deviations, each with a corresponding severity level and automatic repair indicator.

[0203] For example, the types, meanings, severity levels, and automatic correction indicators of various deviations can be shown in Table 1 below.

[0204] Table 1

[0205] Deviation detection can comprehensively identify differences between the knowledge base and the code, and output detection results including deviation type, deviation level and fixability flags, providing accurate data basis for subsequent compliance assessment and entropy reduction governance.

[0206] One possible implementation approach is to conduct compliance assessments on multi-layered knowledge bases.

[0207] Compliance assessment refers to calculating a comprehensive health score based on deviation detection results and dimensions such as the knowledge base's structure and freshness, which is used to quantitatively measure the overall quality of the knowledge base.

[0208] One possible implementation involves obtaining preset evaluation indicators from a multi-layered knowledge base and weighting these indicators to obtain a health assessment result.

[0209] The preset evaluation indicators can include six dimensions: structural integrity indicator, semantic richness indicator, consistency indicator of deviation detection result representation, freshness indicator of update time representation, update traceability indicator, and repairability indicator of automatic repair identifier representation.

[0210] For example, the Agent can perform compliance assessments periodically. The preset weights and calculation formulas for each dimension are shown in Table 2 below.

[0211] Table 2

[0212] The meanings of each calculation formula are as follows: Structural Integrity: missing_count represents the number of missing files in the seven-piece domain set. The score is calculated using the formula max(20, 100 - missing_count×15), meaning 15 points are deducted for each missing file, with a minimum of 20 points.

[0213] Semantic richness: Σdeductions represents the total deductions based on insufficient or redundant entities, APIs, constraints, and terms. The score is not lower than 0.

[0214] Consistency: critical, warning, and info represent the number of critical errors, warnings, and informational errors in the deviation detection results, respectively. The score calculation formula is max(0, 100 - (critical×20 + warning×8 + info×2)), meaning that different levels of deviations are penalized with different weights, with a minimum score of 0.

[0215] Freshness: The score is determined based on the time interval (in days) since the last incremental synchronization: ≤7 days is 100 points, ≤14 days is 90 points, ≤30 days is 80 points, and >30 days is 60 points.

[0216] Traceability: commit_bonus and changelog_bonus represent the completeness and timeliness scores of the most recent code commit and changelog, respectively (0-25 points each). The base score is 50 points, and with these two bonuses, the maximum score is 100 points.

[0217] Repairability: `fixable_count` represents the number of automatically repairable deviations in the deviation detection results, and `total_deviations` represents the total number of deviations. The score is the repairability percentage, rounded to the nearest integer.

[0218] Ultimately, the overall score is the sum of the scores of each dimension multiplied by their respective weights.

[0219] For example, the score can be mapped to a level such as: S (≥95), A (≥80), B (≥60), C (≥40), D (<40). Furthermore, when the health level is lower than a preset threshold (e.g., 70 points), subsequent entropy reduction governance can be automatically triggered.

[0220] Through compliance assessments, the quality of the knowledge base can be quantified, allowing the development team to intuitively understand the health trends of the knowledge base and intervene in a timely manner when the score declines.

[0221] One possible implementation is to use a knowledge immune system to perform incremental synchronization, entropy reduction governance, and health assessment of the knowledge base, ensuring that the knowledge base remains fresh as the code evolves.

[0222] Incremental synchronization is used to respond to real-time changes in the target code repository, updating the knowledge base with the changes in a timely manner to prevent the knowledge base from falling behind the code.

[0223] In one possible implementation, in response to changes in the code of the target code repository, the change file can be obtained; the code change information in the change file can be determined; and the multi-layer knowledge base can be updated based on the code change information through a large language model.

[0224] For example, the Agent can perform synchronization periodically (e.g., every 5 minutes), or it can automatically trigger the synchronization process when events such as commits occur in the code repository, using hook mechanisms provided by the version control system (such as Git Hook, i.e., scripts that are automatically triggered when specific Git events occur), thereby obtaining all changed files since the last synchronization. These changed files can be obtained through version control system diff commands (such as git diff), including the paths of newly added, modified, and deleted files.

[0225] In addition, incremental synchronization can be integrated into the continuous integration pipeline, for example, by automatically triggering a synchronization step before code merging or building, ensuring that the knowledge base is consistent with the latest code. This automated triggering method can further reduce the latency between the knowledge base and the code, achieving near real-time uptime.

[0226] Furthermore, for each change file, the Agent needs to parse the code change information, such as newly added classes, modified method signatures, and deleted fields. Then, it calls the LLM to determine the processing method for the corresponding knowledge fragments in the multi-layered knowledge base based on this change information. For example, for newly added classes or interfaces, a corresponding domain knowledge entry is created in the corresponding knowledge layer of the multi-layered knowledge base; for modified classes, the existing knowledge definitions in the corresponding knowledge layer are updated; for deleted classes, the corresponding knowledge in the corresponding knowledge layer is marked as obsolete or directly deleted. After the update is complete, a change log (such as CHANGELOG.md) is recorded, and the version number and timestamp in the metadata are updated.

[0227] Through incremental synchronization, the knowledge base can reflect the latest state of the code in real time, avoiding the problem of knowledge becoming outdated due to code iteration.

[0228] Entropy reduction governance is an automated mechanism that draws on the concept of information entropy to perform a global scan and repair of redundant, drifting, and outdated content in the knowledge base, so that the knowledge density continues to increase rather than decays over time.

[0229] Entropy reduction governance can be triggered by compliance assessment results (such as when the health score is below a threshold), or it can be executed on a fixed schedule, or it can be manually executed by developers.

[0230] In one possible implementation, semantic recognition of a multi-layered knowledge base can be performed using a large language model to obtain semantic-level question recognition results. Based on the deviation detection results and / or health assessment results, as well as the semantic-level question recognition results, entropy reduction governance can be carried out on the multi-layered knowledge base.

[0231] For example, when entropy reduction governance is triggered, the static engine can first perform a full scan of the knowledge base, and combine the deviation detection results to identify structural problems, format problems, and file-related problems (such as missing files, non-standard naming, etc.).

[0232] Then, the semantic layer of LLM can be invoked to further identify hidden problems that static inspection cannot detect, including semantic-level issues such as different named entities of the same concept (e.g., Order, OrderDO, OrderEntity), terminology confusion, inconsistent process descriptions, and entity definition disagreements. Based on these issues, LLM can generate governance solutions and merge them with the static inspection results to form the final remediation plan.

[0233] One possible implementation approach for entropy reduction governance can include the following five scenarios: (1) Semantically merge different named entities representing the same concept. For example, if there are three descriptions of the "order" entity (Order, OrderDO, OrderEntity) in the knowledge base, by analyzing the actual usage frequency and semantic similarity in the code, the three can be merged into a unified entity definition (such as keeping Order), and all related reference files can be updated. This can eliminate duplication and ambiguity, and improve knowledge density.

[0234] (2) Clean up outdated knowledge information. For example, if an interface has been marked as deprecated (@Deprecated) in the code for more than 90 days and there is no obvious caller, its definition can be moved from the interface specification file api-spec.md, which stores the specifications of interface signatures, parameters, return values, etc., to the archive directory, thereby reducing noise in the knowledge base and keeping the knowledge base clean.

[0235] (3) Unify different term definitions representing the same concept into the same term definition. For example, if the glossary file glossary.yml and the core entity definition file concepts.md use different expressions for the same term (such as one writing "order number" and the other writing "orderId"), then a standard can be selected through semantic judgment, and all variants can be unified to that standard, thereby improving the consistency within the knowledge base.

[0236] (4) Delete knowledge information that does not exist in the corresponding code. For example, if the specification file records an entity OrderDetail, but no trace of the entity class can be found in the code repository, then the definition of the entity is deleted from concepts.md, and the reason for deletion and the associated code commit number are recorded in the change log file CHANGELOG.md, thereby reducing information entropy and avoiding misleading.

[0237] (5) The development architecture specification information should be converged and unified according to the frequency of code usage in the target code repository. For example, the code pattern specification file code-patterns.md records both Service and Manager naming suffixes, but the code statistics show that the Service suffix appears 23 times and the Manager suffix appears 0 times. In this case, the specification should be unified to the Service suffix and the Manager suffix option should be deleted to enhance the certainty of engineering decisions.

[0238] Furthermore, when performing entropy reduction governance for the above scenarios, multiple operating modes can be supported, including dry-run, interactive, agent, apply, and pr modes, to adapt to different operation and maintenance needs and risk control strategies.

[0239] Among them, dry-run is a trial run mode that only reports deviations. In this mode, the knowledge base is not actually modified, and only a governance report is output for human review; interactive is an interactive mode that requires confirmation item by item. In this mode, user confirmation is requested before each governance operation; agent is an intelligent mode that is driven by LLM to make automatic decisions. In this mode, governance is completed automatically; apply is an automatic mode that automatically repairs remediable deviations. In this mode, only deviations marked as automatically remediable are automatically processed; pr is a collaborative mode that submits the repair content as a code change request (Pu Request). In this mode, governance changes are submitted via PR and merged after human review.

[0240] Furthermore, after entropy reduction governance is completed, the metadata version and change log of the knowledge base can be updated, and the compliance assessment can be rerun to verify the improvement effect.

[0241] Through entropy reduction governance, the knowledge base can be continuously refined, deduplicated, and converged, and the knowledge density can be continuously improved, solving the fundamental problems of knowledge decay, drift, and infinite accumulation in static snapshot schemes.

[0242] Health assessment refers to the automatic execution of a six-dimensional health assessment after each incremental synchronization and entropy reduction governance, forming a health time series of the knowledge base. By monitoring the changing trend of the health score, signs of knowledge base quality decline can be detected in a timely manner, and alarms can be triggered when the score continues to decrease, prompting maintenance personnel to intervene and check or manually trigger entropy reduction governance. In this way, the entire maintenance process forms a self-healing closed loop of deviation detection → entropy reduction governance → health assessment, ensuring that the knowledge base always remains in a healthy state.

[0243] To further enhance the semantic richness and accuracy of the knowledge base, one or more embodiments of this specification provide a knowledge base-based assisted programming method that also supports cross-integration of external design documents with the knowledge base, achieving complementarity between code semantics and document semantics, resulting in higher and more complete knowledge density.

[0244] In one possible implementation, the design document corresponding to the target code repository can be obtained, and multimodal analysis can be performed on the design document to obtain document definition information. Then, the document definition information can be cross-fused with the knowledge information in the multi-layer knowledge base, and the multi-layer knowledge base can be updated based on the cross-fused information.

[0245] For example, the agent can read Markdown-formatted design documents from a project, such as PRDs and system architecture documents. It extracts embedded images from these documents and processes them using a multimodal analysis model. Specifically, it can convert flowcharts into domain process descriptions, architecture diagrams into module dependencies, and state diagrams into state machine definitions. Simultaneously, it can extract semantic information such as domain terminology, constraint descriptions, and interface definitions from the document text. The extracted document definition information is then cross-validated and fused with the domain definition information in the domain layer.

[0246] Furthermore, if the definitions in the documentation are consistent with the implementation in the code, this information is added to the knowledge base. For example, if the documentation describes order statuses as "created, paid, shipped," and the code also has the same enumeration, this knowledge is confirmed and marked as verified, and a more detailed domain description is added to the documentation. If there is a conflict between the documentation and the code, the actual implementation in the code prevails, and a conflict warning is recorded in the knowledge base for manual review. For example, if the documentation states that order statuses include "cancelled," but the code does not have this enumeration, an inconsistency is indicated, and the status list in the code is retained.

[0247] The knowledge obtained after fusion contains both code semantics and document semantics, has a higher density, provides the Agent with a more complete domain background, and realizes the compound growth of knowledge.

[0248] In this way, by cross-integrating external documents, the knowledge base can absorb domain knowledge from sources other than code, further improving the accuracy and comprehensiveness of AI-assisted programming.

[0249] The above describes one or more embodiments of the knowledge base-based assisted programming method provided in this specification.

[0250] To quantify the actual effectiveness of the knowledge base-based assisted programming method described above, multiple sets of experiments were conducted to verify the key technical points of the above technical solution. Some representative experiments are described below.

[0251] Experiment 1: A Comparative A / B Experiment of a Four-Layer Knowledge Base Architecture Experimental objective: To quantitatively verify the effectiveness of a four-layer domain knowledge base in improving AI-assisted programming in complex service scenarios, while distinguishing the independent contributions of architectural specification knowledge and domain knowledge.

[0252] Experimental Task Selection: Select a representative complex service problem as the standardized task, such as the missing binding problem of a specific service model in the Bailing penalty rollback scenario. This task should have the following characteristics: involving cross-module interaction, relying on specific service domain knowledge, and having clear correctness judgment criteria.

[0253] Experimental model: Any fixed version of AI programming agent.

[0254] Experimental Environment and Grouping: Three completely isolated experimental environments were created. Group A served as the control group, with the knowledge base directory (e.g., .sdd-spec) completely removed from the working directory to simulate traditional AI programming without a knowledge base. Group B was the architecture knowledge experimental group, retaining only the solution layer and specification implementation layer, removing all domain knowledge under the domain layer, to measure the contribution of development architecture specification information. Group C was the complete knowledge base experimental group, retaining the complete four-layer knowledge base structure (solution layer, specification implementation layer, domain layer, and automation assurance layer). The three environments were physically isolated using Git Worktree technology to ensure the reproducibility of the experiments.

[0255] Experiment Execution Procedure: Each experiment follows the same standardized procedure. First, execute the context clearing command to ensure no historical information interference. Then, record the experiment start time and provide the Agent with a standardized problem description (identical for all three groups). The Agent enters the autonomous reasoning and coding phase, recording the interaction content and tool calls in each round. If the number of interaction rounds exceeds the threshold of ten, the Agent is forced to generate the current feasible solution. At the end of the experiment, record the termination time and generate a solution file and a complete process log.

[0256] Evaluation Dimensions and Weights: A four-dimensional evaluation system is established. Accuracy of Root Cause Locating (25 points): This assesses whether the Agent can accurately deduce the technical root cause from service phenomena. Completeness of Technical Solution (20 points): This evaluates whether the solution includes elements such as problem analysis, repair logic, and boundary case handling. Correctness of Code Repair (25 points): This verifies the actual runnability and correctness of the generated code. Efficiency Indicators (25 points): This is comprehensively evaluated from three sub-dimensions: total time consumption, number of interaction rounds, and number of code iterations. In addition, information acquisition and localization capability indicators (10 points) and domain understanding indicators (5 points) are set as supplementary evaluation items.

[0257] Experimental conclusions: Group A performed weakest in root cause localization and domain understanding, requiring more interaction rounds and code iterations; Group B showed significant improvement in architectural decisions (file location, naming conventions, framework selection), but still had obvious shortcomings in domain logic understanding; Group C performed outstandingly in all dimensions, able to locate problems and generate correct solutions the fastest. This experiment quantitatively demonstrates the effectiveness of the four-layer knowledge base architecture, and the contributions of architectural knowledge and domain knowledge are distinguishable and quantifiable.

[0258] Experiment 2: Evaluation of Knowledge Extraction Accuracy in Multi-Pass Scan Pipeline Experimental objective: To verify the advantages of multi-pass scanning pipeline in terms of knowledge extraction accuracy, recall, and efficiency compared to single-pass scanning and pure RAG schemes.

[0259] Experimental Task Design: Three historical projects of different sizes were selected for backtesting. Project A is a small monolithic application, Project B is a medium-sized multi-module application, and Project C is a large-scale microservice architecture application. The scan pipeline was run multiple times for each of the three projects, and the ground truth was manually annotated.

[0260] Evaluation dimensions: Recall measures the proportion of actual domain knowledge that is successfully extracted; Precision measures the proportion of correct knowledge extracted; F1 score combines the two; in addition, extraction speed is evaluated by comparing the performance difference between multiple scans and full AST parsing.

[0261] Experimental conclusions: In terms of recall, multi-pass scanning (five-dimensional overlay) significantly outperforms single-pass scanning, especially in the RPC framework detection and naming heuristics dimensions, which supplement a large amount of missing information; in terms of accuracy, the four-factor association scoring algorithm achieves a Top-1 recommendation accuracy of over 85%; in terms of efficiency, the scanning pipeline completes the first round of extraction for large projects within three minutes, meeting the requirements for immediate response.

[0262] Experiment 3: Blind Test of Class Placement Accuracy for Deterministic Routing Mechanism Experimental objective: To verify the accuracy improvement of the deterministic routing mechanism in class placement decisions and compare it with simple LLM inference.

[0263] Experimental Task Design: Extract 100 real-world class creation scenarios from historical submission records as a test set. Each scenario includes: class type (Service, Controller, DAO, etc.), class dependency information, and project module structure. The actual placement locations are hidden, and prediction results are given using both deterministic routing algorithms and pure LLM inference.

[0264] Evaluation dimensions: Top-1 accuracy measures the proportion of prediction results that perfectly match the actual location; Top-3 accuracy measures the proportion of the actual location that appears in the top three candidates; the human evaluation score is given by senior engineers who score the reasonableness of the output results.

[0265] Variable control: Ensure that the LLM inference group receives only the same basic information as the deterministic routing group (without additional information about the project's historical decisions), thus guaranteeing the fairness of the comparison.

[0266] Experimental conclusions: The Top-1 accuracy of the deterministic routing group exceeded 90%, while the accuracy of the simple LLM inference group was approximately 60%–70%. This experiment demonstrates the crucial value of explicit engineering common sense for consistency in AI-assisted programming.

[0267] Experiment 4: Tracking the Evolution of Knowledge Base Health in the Entropy Reduction Governance System Experimental objective: To verify that the entropy reduction governance system can effectively detect and repair knowledge base biases, maintaining the health of the knowledge base at a high and stable level, rather than decaying over time.

[0268] Experimental task design: Select an actively maintained project for continuous tracking for eight weeks, perform a six-dimensional compliance assessment (gc dry-run mode) weekly, and record the scores for each item. In the fourth week, perform a full entropy reduction governance (gcapply mode) and compare the changes in health before and after the governance.

[0269] Assessment dimensions: Time series health score is plotted as a six-dimensional score trend chart over eight weeks; governance effect is quantified by calculating the improvement of each dimension after governance actions; deviation detection rate is calculated by statistics on the number of deviations detected and the repair ratio of each type over eight weeks.

[0270] Experimental Conclusions: In the first four weeks without governance implementation, scores for freshness and consistency showed a downward trend, reflecting knowledge drift caused by code evolution. After implementing governance in the fourth week, scores for all dimensions rebounded significantly. For the following four weeks, maintaining lightweight weekly synchronization resulted in a stable health score above 80 points, indicating a healthy level. This experiment demonstrates that entropy reduction governance is not an optional enhancement, but a necessary mechanism for maintaining the effectiveness of the knowledge base.

[0271] Experiment 5: Verification of the Reproducibility of the Auxiliary Programming Method in the Control Group Experiment Experiment Objectives: Verify the reproducibility and transferability of the auxiliary programming method based on the knowledge base in the control group experiment, and ensure that other teams can also independently evaluate the effectiveness of the knowledge base using this paradigm.

[0272] Experimental Task Design: Invite three independent development teams to each select different application scenarios and independently execute the AB control experiment. Among them, for Scenario 1, select the repair of exception handling logic; for Scenario 2, select the adaptation of interface contract changes; for Scenario 3, select the troubleshooting of distributed transaction problems.

[0273] Evaluation Dimensions: For result consistency, compare whether the score distributions of the three teams on the same evaluation dimensions show similar patterns (i.e., whether they all show a gradient of A < B < C); for execution cost, record the time and manpower input required for each team to complete the experiment, and evaluate the actual operability of this auxiliary programming method based on the knowledge base; for subjective feedback, collect the team's evaluations of the experimental process and improvement suggestions.

[0274] Experimental Conclusions: The experimental results of the three teams all show consistent patterns. The complete knowledge base group is superior to the control group in all dimensions, and the architecture knowledge group is between the two. It proves that the auxiliary programming method based on the knowledge base is not a special case dependent on a specific scenario, but a reusable general evaluation paradigm.

[0275] Experiments 1 to 5 above can confirm that through methods such as four-layer structured modeling, LLM editor mode, incremental synchronization, entropy reduction governance, deterministic routing, and external document integration, effectively overcome the defects of RAG knowledge fragmentation, static configuration obsolescence flattening, lack of semantic code indexing, and lack of engineering awareness in general memory, and achieve technical effects such as increased knowledge density, real-time synchronization, on-demand loading, deterministic output, and automatic self-healing.

[0276] It should be noted that Experiments 1 to 5 above are only part of all verification links and have all achieved positive results consistent with expectations.

[0277] Through the above solutions and experimental verifications, the auxiliary programming method based on the knowledge base provided by one or more embodiments of this specification has achieved the following technical effects: Naming consistency is improved from probabilistic output to deterministic output: The Agent strictly follows the naming suffix specification automatically extracted and solidified from the code, and there is no longer inconsistent phenomenon such as mixing Service suffix and Manager suffix in the same project.

[0278] The accuracy of file placement is improved from random guessing to deterministic routing: Through a five-step deterministic class placement algorithm, newly created classes are uniquely and accurately placed under the module and package paths that conform to the architecture layer and domain attribution.

[0279] Framework selection has been upgraded from suggestion to physical isolation: the agent can only see the unique code template that matches the actual data access framework of the project, and other framework templates are not visible, which prevents framework abuse from the root.

[0280] Knowledge base health can be quantified: Through a six-dimensional compliance assessment model (structural integrity, semantic richness, consistency, freshness, traceability, and repairability), the quality of the knowledge base is quantified into a score of 0-100 and an S / A / B / C / D rating, making knowledge asset management measurable.

[0281] Knowledge decay is perceptible and repairable: The self-healing closed loop formed by incremental synchronization, deviation detection and entropy reduction governance can promptly detect knowledge decay, drift and obsolescence, and automatically perform repair operations such as semantic merging, cleaning and unification to ensure that the knowledge base remains fresh as the code evolves.

[0282] Furthermore, through a multi-layered reference architecture and a knowledge editor mode, knowledge can grow exponentially rather than linearly, and the complete entropy reduction governance system fills the gap in self-maintenance of knowledge bases in other solutions; the six-dimensional compliance assessment model realizes the quantitative measurement of knowledge base health, providing a theoretical basis for knowledge asset management; and by introducing a control group experimental method, the evaluation of knowledge base effectiveness is upgraded from subjective feelings to objective data.

[0283] By using the knowledge base-based assisted programming methods described above, large R&D teams can reduce the time it takes for new members to become familiar with the project architecture and domain from weeks or months to hours, and increase the first pass rate of AI-assisted programming by more than 30% and reduce architecture consistency violations by more than 80%, demonstrating significant technological progress and practicality.

[0284] It is understood that the above embodiments are merely examples, and modifications can be made to the above embodiments in actual implementation. Those skilled in the art will understand that any modifications to the above embodiments that do not require creative effort fall within the protection scope of one or more embodiments of this specification, and will not be described again in the embodiments.

[0285] Based on the same inventive concept, one or more embodiments of this specification also provide a knowledge-based auxiliary programming device. Since the principle of the problem solved by the knowledge-based auxiliary programming device is similar to that of the aforementioned knowledge-based auxiliary programming method, the implementation of the knowledge-based auxiliary programming device can refer to the implementation of the aforementioned knowledge-based auxiliary programming method, and the repeated parts will not be described again.

[0286] See Figure 4 , Figure 4 This is a structural block diagram of a knowledge-based auxiliary programming device provided for one or more embodiments of this specification. (See diagram for example.) Figure 4 As shown, the knowledge-based assisted programming device 400 may include: a first determining module 401, an acquiring module 402, a second determining module 403, and an execution module 404. Among them, The first determining module 401 is used to determine the target service area and development request type corresponding to the received auxiliary programming request in response to the auxiliary programming request.

[0287] The acquisition module 402 is used to acquire a multi-layer knowledge base, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information.

[0288] The second determining module 403 is used to determine the corresponding configuration information from a multi-layer knowledge base based on the target service domain and / or development request type. The configuration information includes at least one of code templates, programming specifications, and file storage paths. The code templates and programming specifications are obtained based on development architecture specification information, and the file storage paths are obtained based on development architecture specification information and domain definition information.

[0289] Execution module 404 is used to generate program code corresponding to the auxiliary programming request based on configuration information.

[0290] Based on the same inventive concept, one or more embodiments of this specification also provide an intelligent agent. Since the principle by which the intelligent agent solves the problem is similar to the aforementioned knowledge-based assisted programming method, the implementation of the intelligent agent can refer to the implementation of the aforementioned knowledge-based assisted programming method, and the repeated parts will not be described again.

[0291] The intelligent agent may include: The first determining module is used to determine the target service area and development request type corresponding to the received auxiliary programming request in response to the auxiliary programming request. The acquisition module is used to acquire a multi-layered knowledge base, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. The second determining module is used to determine the corresponding configuration information from a multi-layered knowledge base based on the target service domain and / or development request type. The configuration information includes at least one of the code template and programming specifications in the first knowledge layer and the file storage path in the second knowledge layer. The code template and programming specifications are obtained based on the development architecture specification information, and the file storage path is obtained based on the development architecture specification information and the domain definition information. The execution module is used to generate program code corresponding to the auxiliary programming request based on the configuration information.

[0292] Based on the same inventive concept, one or more embodiments of this specification also provide an electronic device.

[0293] See Figure 5 , Figure 5 This is a structural block diagram of an electronic device provided for one or more embodiments of this specification. Figure 5 As shown, the electronic device 500 may include a processor 501 and a memory 502; the memory 502 may be coupled to the processor 501. It is worth noting that... Figure 5 This is an example; other types of structures can also be used to supplement or replace this structure to achieve telecommunications functions or other functions.

[0294] In one possible implementation, the functionality of the knowledge-based auxiliary programming device 400 can be integrated into the processor 501. The processor 501 can be configured to perform the following operations: In response to a received assisted programming request, determine the target service domain and development request type corresponding to the assisted programming request; A multi-layered knowledge base is acquired, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. Based on the target service domain and / or development request type, the corresponding configuration information is determined from a multi-layered knowledge base. The configuration information includes at least one of code templates, programming standards, and file storage paths. The code templates and programming standards are obtained based on the development architecture specification information, and the file storage paths are obtained based on the development architecture specification information and domain definition information. Based on the configuration information, generate the program code corresponding to the assisted programming request.

[0295] In another possible implementation, the knowledge-based auxiliary programming device 400 can be configured separately from the processor 501. For example, the knowledge-based auxiliary programming device 400 can be configured as a chip connected to the processor 501, and the knowledge-based auxiliary programming operation can be implemented through the control of the processor 501.

[0296] In one possible implementation, the plurality of processors 501 may be processors deployed on the same device. For example, the electronic device may be a high-performance device composed of multiple processors, and the plurality of processors 501 may be processors configured on the high-performance device.

[0297] In another possible implementation, the aforementioned multiple processors 501 may also be processors deployed on different devices. For example, the aforementioned electronic device may be a server cluster, and the aforementioned multiple processors 501 may be processors on different servers in the server cluster.

[0298] Furthermore, in some alternative implementations, the electronic device 500 may also include: a communication module, an input unit, an audio processor, a display, a power supply, etc. It is worth noting that the electronic device 500 is not necessarily required to include these components. Figure 5 All components shown; in addition, the electronic device 500 may also include Figure 5 For components not shown, please refer to existing technologies.

[0299] In some alternative implementations, the processor 501, sometimes also referred to as a controller or operating control, may include a microprocessor or other processor device and / or logic device, which receives input and controls the operation of various components of the electronic device 500.

[0300] The memory 502 may be, for example, one or more of a cache, flash memory, hard drive, removable media, volatile memory, non-volatile memory, or other suitable devices. It may store the aforementioned information related to the knowledge-based auxiliary programming device 400, and may also store programs for executing that information. The processor 501 may execute the program stored in the memory 502 to perform information storage or processing, etc.

[0301] An input unit can provide input to the processor 501. This input unit may be, for example, a button or touch input device. A power supply can be used to provide power to the electronic device 500. A display can be used to display images and text, etc. This display may be, for example, an LCD display, but is not limited to this.

[0302] Memory 502 can be a solid-state memory, such as read-only memory (ROM), random access memory (RAM), SIM card, etc. It can also be a memory that retains information even when power is off, can be selectively erased, and contains more data; examples of this type of memory are sometimes referred to as EPROM, etc. Memory 502 can also be some other type of device. Memory 502 includes buffer memory (sometimes referred to as a buffer). Memory 502 may include an application / function storage unit for storing application programs and function programs or processes for executing the operation of electronic device 500 via processor 501.

[0303] The memory 502 may also include a data storage unit for storing data, such as contacts, digital data, pictures, sounds, and / or any other data used by the electronic device. The driver storage unit of the memory 502 may include various drivers for the computer device for communication functions and / or for performing other functions of the computer device (such as messaging applications, address book applications, etc.).

[0304] The communication module is a transmitter / receiver that sends and receives signals via an antenna. The communication module (transmitter / receiver) is coupled to the processor 501 to provide input signals and receive output signals, which is the same as in a conventional mobile communication terminal.

[0305] Based on different communication technologies, multiple communication modules can be configured in the same computer device, such as cellular network modules, Bluetooth modules, and / or wireless LAN modules. The communication modules (transmitters / receivers) are also coupled to speakers and microphones via an audio processor to provide audio output through the speakers and receive audio input from the microphones, thereby enabling typical telecommunications functions. The audio processor may include any suitable buffer, decoder, amplifier, etc. Additionally, the audio processor is coupled to processor 501, enabling on-device recording via the microphone and on-device playback of stored sound via the speakers.

[0306] One or more embodiments of this specification also provide a computer-readable storage medium capable of implementing all steps of the knowledge-based assisted programming method in the above embodiments. The computer-readable storage medium stores a computer program that, when executed by a processor, implements all steps of the knowledge-based assisted programming method in the above embodiments. For example, when the processor executes the computer program, it implements the following steps: In response to a received assisted programming request, determine the target service domain and development request type corresponding to the assisted programming request; A multi-layered knowledge base is acquired, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. Based on the target service domain and / or development request type, the corresponding configuration information is determined from a multi-layered knowledge base. The configuration information includes at least one of code templates, programming standards, and file storage paths. The code templates and programming standards are obtained based on the development architecture specification information, and the file storage paths are obtained based on the development architecture specification information and domain definition information. Based on the configuration information, generate the program code corresponding to the assisted programming request.

[0307] While one or more embodiments of this specification provide the operational steps of the methods described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive labor. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only possible execution order. In actual device or client product execution, the methods shown in the embodiments or drawings can be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment).

[0308] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, apparatus (systems), or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, one or more embodiments of this specification can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0309] This specification describes one or more embodiments of a method, apparatus (system), and computer program product according to one or more embodiments of this specification with reference to flowchart illustrations and / or block diagrams. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0310] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0311] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0312] 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 device and system embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0313] In this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, without necessarily requiring or implying 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. Those skilled in the art will understand the specific meaning of the above terms in one or more embodiments of this specification, depending on the specific circumstances.

[0314] It should be noted that, unless otherwise specified, one or more embodiments and features thereof in this specification can be combined with each other. This specification is not limited to any single aspect, nor to any single embodiment, nor to any combination and / or substitution of such aspects and / or embodiments. Furthermore, each aspect and / or embodiment of one or more embodiments of this specification can be used alone or in combination with one or more other aspects and / or embodiments thereof.

[0315] The above embodiments are only used to illustrate the technical solutions of one or more embodiments of this specification, and are not intended to limit them. Although one or more embodiments of this specification have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of one or more embodiments of this specification, and they should all be covered within the scope of the claims and the specification of one or more embodiments of this specification.

[0316] The foregoing description of one or more embodiments of this specification has been provided in conjunction with optional implementation methods. However, these embodiments are merely exemplary and serve only an illustrative purpose. Based on this, various substitutions and modifications can be made to one or more embodiments of this specification, all of which fall within the protection scope of one or more embodiments of this specification.

[0317] Finally, it should be noted that the user information and data involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties.

[0318] The data acquisition and collection actions involved in one or more embodiments of this specification are all performed after authorization by the user, the object, or after full authorization by all parties.< / t>

Claims

1. A knowledge-based assisted programming method, characterized in that, Applied to intelligent agents, the method includes: In response to a received assisted programming request, the target service domain and development request type corresponding to the assisted programming request are determined; A multi-layer knowledge base is obtained, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. Based on the target service domain and / or the development request type, corresponding configuration information is determined from the multi-layer knowledge base. The configuration information includes at least one of code templates, programming standards, and file storage paths. The code templates and programming standards are obtained based on the development architecture specification information, and the file storage paths are obtained based on the development architecture specification information and the domain definition information. Based on the configuration information, the program code corresponding to the assisted programming request is generated.

2. The method according to claim 1, characterized in that, The step of determining the corresponding configuration information from the multi-layered knowledge base based on the target service domain and / or the development request type includes: Based on the development request type, the code template and the programming specifications are obtained from the development architecture specification information; The file storage path is determined based on the target service domain, the development request type, the development architecture specification information, and the domain definition information.

3. The method according to claim 2, characterized in that, Based on the development request type, the code template is obtained from the development architecture specification information, including: If the development request type is code generation type, determine the development framework type corresponding to the assisted programming request; Obtain the code template corresponding to the development framework type from the development architecture specification information.

4. The method according to claim 2, characterized in that, The step of determining the file storage path based on the target service domain, the development request type, the development architecture specification information, and the domain definition information includes: Based on the development request type and the domain definition information, determine the hierarchical affiliation information corresponding to the assisted programming request; Based on the target service domain and the hierarchical affiliation information, candidate storage locations are determined; From the candidate storage locations, target storage locations that meet preset conditions are selected, including preset constraints and / or preset adaptation conditions. The file storage path is determined based on the target storage location and the development architecture specification information.

5. The method according to claim 1, characterized in that, Before acquiring the multi-layered knowledge base, the method further includes: Construct a multi-layered knowledge base corresponding to the target code repository; The target code repository is parsed to obtain code information; Multi-dimensional information extraction is performed on the code information to obtain the development architecture specification information and domain information; The development architecture specification information is stored in the first knowledge layer; The domain definition information is obtained based on the domain information, and the domain definition information is stored in the second knowledge layer.

6. The method according to claim 5, characterized in that, The multi-dimensional information extraction of the code information includes: Information is extracted from at least two dimensions of the code information, including annotations, structure, naming information, framework type, and code features.

7. The method according to claim 5, characterized in that, The code information includes code modules; obtaining the domain definition information based on the domain information includes: Based on the domain information, the association between the code module and the preset domain is determined; Receive confirmation from the user regarding the association; Structured domain knowledge is obtained based on the confirmed relationships through a large language model; The structured domain knowledge is used as the domain definition information.

8. The method according to claim 7, characterized in that, Determining the association between the code module and the preset domain includes: A relevance score is obtained based on the association factors between the code module and the preset domain and the preset weight parameters of the association factors; wherein, the association factors include at least one of name similarity, entity relevance, complexity factor, and keyword matching degree; The preset domains whose correlation scores meet the preset score conditions are identified as the domains associated with the code module, so as to obtain the correlation relationship between the code module and the preset domains.

9. The method according to claim 7, characterized in that, The structured domain knowledge obtained through a large language model based on confirmed relationships includes: The large language model is invoked, and the code module is semantically integrated and structured based on the confirmed association to obtain the structured domain knowledge.

10. The method according to claim 5, characterized in that, The multi-layered knowledge base further includes a third knowledge layer and a fourth knowledge layer; after constructing the multi-layered knowledge base corresponding to the target code repository, the method further includes: Obtain the initial configuration information of the target code repository and store the initial configuration information in the third knowledge layer; and / or, Obtain the preset maintenance information of the multi-layer knowledge base and store the preset maintenance information in the fourth knowledge layer.

11. The method according to claim 5, characterized in that, The method further includes: In response to changes in the code of the target code repository, obtain the change file; Determine the code change information in the modified file; The multi-layered knowledge base is updated based on the code change information using a large language model.

12. The method according to claim 5, characterized in that, The method further includes: The deviation detection results of the multi-layer knowledge base are obtained by comparing the development architecture specification information in the multi-layer knowledge base with the code information in the target code repository. The deviation detection includes at least one of naming detection, hierarchical structure detection, framework consistency detection, entity definition detection, and constraint rule detection, and the deviation detection result includes deviation type and deviation level.

13. The method according to claim 12, characterized in that, The deviation detection result also includes an automatic repair indicator; the method further includes: Obtain the preset evaluation indicators of the multi-layered knowledge base; The preset evaluation indicators are weighted to obtain the health assessment results; The preset evaluation indicators include at least one of the following: structural integrity indicator, semantic richness indicator, consistency indicator represented by the deviation detection result, freshness indicator represented by the update time, update traceability indicator, and repairability indicator represented by the automatic repair identifier.

14. The method according to claim 13, characterized in that, The method further includes: The semantic recognition results of the multi-layer knowledge base are obtained by performing semantic-level question recognition using the large language model. Based on the deviation detection results and / or the health assessment results, as well as the semantic-level question identification results, entropy reduction is performed on the multi-layer knowledge base.

15. The method according to claim 14, characterized in that, The entropy reduction management of the multi-layered knowledge base includes at least one of the following: (1) Semantically merge different named entities that represent the same concept; (2) Clean up outdated knowledge and information; (3) Unify the different terminology definitions that represent the same concept into the same terminology definition; (4) Delete the knowledge information whose corresponding code does not exist; (5) The development architecture specification information is converged and unified according to the code usage frequency in the target code repository.

16. The method according to claim 5, characterized in that, The method further includes: Obtain the design document corresponding to the target code repository; Perform multimodal analysis on the design document to obtain document definition information; The document definition information is cross-integrated with the knowledge information in the multi-layer knowledge base, and the multi-layer knowledge base is updated based on the information obtained from the cross-integration.

17. A knowledge-based auxiliary programming device, characterized in that, The device includes: The first determining module is used to determine the target service domain and development request type corresponding to the received auxiliary programming request in response to the auxiliary programming request. The acquisition module is used to acquire a multi-layer knowledge base, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. The second determining module is used to determine corresponding configuration information from the multi-layer knowledge base based on the target service domain and / or the development request type. The configuration information includes at least one of code templates, programming specifications, and file storage paths in the first knowledge layer and the second knowledge layer. The code templates and programming specifications are obtained based on the development architecture specification information, and the file storage paths are obtained based on the development architecture specification information and the domain definition information. The execution module is used to generate program code corresponding to the auxiliary programming request based on the configuration information.

18. An intelligent agent, characterized in that, The intelligent agent includes: The first determining module is used to determine the target service domain and development request type corresponding to the received auxiliary programming request in response to the auxiliary programming request. The acquisition module is used to acquire a multi-layer knowledge base, which includes a first knowledge layer and a second knowledge layer. The first knowledge layer is used to store development architecture specification information, and the second knowledge layer is used to store domain definition information. The second determining module is used to determine corresponding configuration information from the multi-layer knowledge base based on the target service domain and / or the development request type. The configuration information includes at least one of code templates, programming specifications, and file storage paths in the first knowledge layer and the second knowledge layer. The code templates and programming specifications are obtained based on the development architecture specification information, and the file storage paths are obtained based on the development architecture specification information and the domain definition information. The execution module is used to generate program code corresponding to the auxiliary programming request based on the configuration information.

19. An electronic device, characterized in that, The electronic device includes: Memory, used to store computer program products; A processor is configured to execute a computer program product stored in the memory, wherein, when the computer program product is executed, it implements the method described in any one of claims 1 to 16.

20. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed, implement the method described in any one of claims 1 to 16.

Images