Ai-assisted software development method based on rule-skill-manual knowledge architecture

Abstract

The application discloses an AI-assisted software development method based on a rule-skill-manual knowledge architecture, and relates to the technical field of AI software development, comprising: setting a constraint priority system according to the execution stage of the AI-assisted software, and constraining each stage of the AI-assisted software; controlling the switching of each stage of the AI-assisted software through a stage state inference mechanism and an artificial confirmation access control mechanism; setting a manual automatic matching and input template generation mechanism and an experience backwriting and knowledge self-growth mechanism; using a statistical quantification and effect evaluation system to statistically analyze the running results of the AI-assisted software; and limiting the execution of the specified stage of the AI-assisted software according to a focus point forced isolation mechanism. The application solves the problems of chaotic specification management, heavy artificial burden, lack of process control, low efficiency of demand specification matching and inability to deposit and iterate engineering knowledge existing in the prior art AI-assisted programming technology.

Description

Technical Field

[0001] This invention relates to the field of AI software development technology, and more specifically, to an AI-assisted software development method based on a rule-skill-manual knowledge architecture. Background Technology

[0002] With the deep integration of artificial intelligence and software engineering, AI-assisted programming has become an important means to improve software development efficiency and reduce R&D costs. It is widely used in scenarios such as code writing, requirements development, and code review. Currently, the industry has formed three mainstream AI-assisted programming technology solutions, but all of them have obvious technical shortcomings and are difficult to adapt to the standardized, high-quality, and iterative development needs of enterprise-level projects. Among them, conversational AI programming assistants, represented by GitHubCopilotChat and Tongyi Lingma, rely solely on model pre-training knowledge and single dialogue context to generate code, and cannot perceive the project-specific architecture and development specifications, resulting in poor code adaptability. Standardized specification file SDD tools, represented by OpenSpec and GitHubSpecKit, require developers to manually and repeatedly enter architecture rules, module specifications, and requirement information, and suffer from complex environment configuration, high instruction learning costs, and high access barriers, making it difficult to scale up. The ManualSDD solution based on global context files is prone to file content expansion and maintenance difficulties with project iterations, and does not differentiate between global rules and module-specific specifications, resulting in unstable AI code generation constraints and unreliable standardization. Overall, existing technologies generally suffer from numerous shortcomings, such as reliance on manual construction for specification building, heavy burden on developers, lack of structured management of functional requirements, inability to effectively link them with code generation, lack of layered isolation of development specifications, chaotic constraint logic, lack of full-process access control from requirements analysis to code review, insufficient code quality and traceability, and inability to systematically accumulate and reuse engineering development experience, making it difficult for team knowledge to iterate and grow. These shortcomings fail to meet the requirements of industrialized and systematic software development. Therefore, there is an urgent need to develop an intelligent AI-assisted programming solution that is layered, controllable, iterative, and fully managed throughout the entire process. Summary of the Invention

[0003] To address the aforementioned issues, the present invention aims to provide an AI-assisted software development method based on a rules-skills-manual knowledge architecture. This method addresses the technical shortcomings of existing AI-assisted programming technologies, such as chaotic standardization management, heavy manual workload, lack of process control, inefficient matching of requirements and specifications, and the inability to accumulate and iterate engineering knowledge.

[0004] To achieve the aforementioned technical objectives, this application provides an AI-assisted software development method based on a rules-skills-manual knowledge architecture, comprising the following steps: Based on the execution stages of the AI-assisted software, a constraint priority system is set up to constrain each stage of the AI-assisted software; The switching of each stage of the AI-assisted software is controlled through an automatic stage state inference mechanism and a manual confirmation access control mechanism. The system includes an automatic manual matching and input template generation mechanism, as well as an experience writing and knowledge self-growth mechanism, to optimize and control the operation of the AI-assisted software. The statistical quantification and effect evaluation system is used to conduct statistical analysis on the operation results of AI-assisted software; Based on the mandatory isolation mechanism based on concerns, the execution of AI-assisted software at designated stages is restricted.

[0005] Preferably, when acquiring the execution phase of the AI-assisted software, the execution phase of the AI-assisted software includes the following stages executed sequentially: requirements analysis phase, solution design phase, code development phase, code review phase, technical solution generation phase, and change archiving phase.

[0006] Preferably, during the code development phase, tasks are executed sequentially. Before each task is executed, the working directory is determined based on the prefix, the corresponding rule file is loaded, and the manual corresponding to the task is obtained. Modify the code according to the manual and perform pre-development checks; Once completed, immediately update the task.md status to DONE, and execute `git add` in the corresponding project directory to precisely stage the changed files. Automatically continue to the next PENDING task.

[0007] Preferably, during the code review phase, a nine-layer hierarchical review is performed: Once the first layer of requirements is met, review and check the completeness of functions and the implementation of business rules against the requirements.md file. The second layer involves design and implementation, with a review and comparison against design.md / implementation.md to check the feasibility of the solution. The third layer of code quality involves reviewing correctness, performance, readability, and security. Fourth-level compliance includes reviewing coding, design, database, and interface specifications. The fifth layer of the architecture is divided into layers, including the Handler layer, Repo layer, Config layer, Enum layer, and general checks. The sixth layer of code quality depth involves reviewing the quality of comments, method complexity, logical clarity, and Sonar preflight check. The seventh layer of impact analysis includes reviewing the classification of changed documents, dependency chain tracing, contextual integrity, and risk assessment of changes in logical behavior. The eighth layer of exception scenarios and API specifications performs checks for 11 common API misuse patterns and 9 boundary scenario checks. The ninth-level experimental governance project involves 12 general inspections and 9 extended inspections.

[0008] Preferably, when constraining each stage of AI-assisted software, during the requirements analysis stage, AI is forced to break down functional points from a business perspective. During the solution design phase, the corresponding development manual is automatically matched based on the function entry identifier of the function point, and the user instruction format in the manual is merged into an input template. During the test design phase, test strategy templates are automatically matched according to functional categories; During the code development phase, an implementation plan is first generated and awaited manual confirmation. Then, it is executed one by one in atomic tasks, with the corresponding manual being read before each task is executed. During the code review phase, a four-tier review model is established, encompassing requirement fulfillment, design implementation, code quality, and compliance with standards, with issues categorized accordingly. During the change archiving phase, automated CHANGELOG generation, experience write-back checks, and SDD effectiveness index calculation are performed.

[0009] Preferably, when setting up the automatic stage status inference mechanism, the AI-assisted software is controlled to automatically determine the current stage by detecting the status of the product files in the changed directory.

[0010] Preferably, when setting up a manual confirmation access control mechanism, the AI-assisted software is controlled to wait for explicit human confirmation after each stage before proceeding to the next stage.

[0011] Preferably, when setting up the automatic matching and input template generation mechanism for manuals, function entry identification is performed to control the AI-assisted software to mark each function point to the corresponding function entry. By matching the manual routes, the corresponding development manual can be located in the manual directory tree according to the function entry identifier of the function point. By synthesizing input templates, the AI-assisted software is controlled to generate code based on the matched development manual and perform intelligent pre-filling.

[0012] Preferably, when setting up the experience writing-back and knowledge self-growth mechanism, the writing-back constraint is set to control the writing-back operation to be performed during the change archiving stage, and the writing-back content must be marked with the source change ID; The control manual, after being written back, is automatically loaded and used by AI-assisted software in the next development of the same type of requirement.

[0013] Preferably, when designing a mandatory isolation mechanism for concerns, the following prohibitions apply: during the requirements analysis phase, reading code files, searching code repositories, and outputting technical details are prohibited; during the solution design phase, generating code directly without reading the manual is prohibited; during the code development phase, generating code structures that are not supported by the Rules or Manual is prohibited; and during the code review phase, subjective judgments are prohibited as the basis for blocking.

[0014] The present invention discloses the following technical effects: This invention significantly reduces the input burden on developers, eliminating the need for manual repetition of filling in large amounts of project context and specification information. Developers only need to provide a requirement description and a few key parameters to drive the entire development process, greatly simplifying the operation chain and improving development efficiency.

[0015] This invention reliably ensures the quality of generated code by strictly limiting the boundaries of AI generation through multi-layered constraints such as global rules, module specifications, and prohibitions, eliminating code quality fluctuations caused by random actions, and ensuring that the output results are standardized, consistent, and of controllable quality.

[0016] This invention enables standardized replication of team AI development capabilities, transforming scattered individual experience into a unified team knowledge system, allowing all members to obtain consistent, high-quality AI-assisted effects, thus breaking away from the traditional development model that relies on individual abilities.

[0017] This invention supports the continuous iterative accumulation of team knowledge. Through an automatic experience write-back mechanism, the engineering experience generated in each development is structured and deposited into the knowledge base, enabling knowledge to be reused and passed on, and promoting the continuous growth of the team's development capabilities.

[0018] This invention enables the entire development process to be traceable, measurable, and optimizable. By automatically generating a complete set of structured development documents and a corresponding quantitative statistical system, it fully retains development process data, providing reliable support for effect evaluation, problem review, and continuous process optimization. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a schematic diagram of the method described in this invention.

[0021] Figure 2 It is the six-stage SDD process state machine described in this invention.

[0022] Figure 3This is a flowchart of the automatic manual matching process described in this invention.

[0023] Figure 4 This is a flowchart of the experience write-back mechanism described in this invention.

[0024] Figure 5 This is the constraint priority system diagram described in this invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0026] like Figure 1 As shown, this invention provides an AI-assisted software development method based on a rules-skills-manual knowledge architecture. It sequentially executes requirements analysis, solution design, code development, code review, technical solution generation, and change archiving. Each stage is configured with independent execution skills, standardized inputs and outputs, detailed execution steps, stage constraints, and manual confirmation access controls. Relying on a layered knowledge system and experience writing-back mechanism, it achieves standardization, controllability, traceability, and data accumulation throughout the entire AI-assisted development process. The overall process strictly follows the principles of stage progression, manual confirmation, and product-driven development. Structured documents connect the entire process, while relying on knowledge base automatic matching, dynamic routing, and experience iteration capabilities to balance development automation efficiency with human controllability.

[0027] In one implementation, the method relies on a user interaction layer, an AI assistant core layer, and a three-layer knowledge architecture.

[0028] For example, the Rules layer, located at the top of the architecture, defines global constraints at the project level, including architectural specifications, coding standards, design specifications, and technology stack constraints. It has the highest priority and must be followed by AI execution at all stages; it cannot be overridden by temporary instructions. Rules, as the global rule source, provide mandatory constraints to the AI ​​assistant. The Skills layer, located between the AI ​​assistant and the manual layer, defines the execution flow of each stage of the SDD (Software Development Document). Each Skill is an independent executable AI program unit. The system includes six core Skills: Requirements Analysis Skill, Solution Design Skill, Test Design Skill, Code Development Skill, Code Review Skill, and Change Archiving Skill. Each Skill acts as a "flow commander," responsible for invoking the Rules layer to obtain constraints and scheduling the corresponding manual execution as needed.

[0029] For example, the Manuals layer is located on the right side of the architecture, defining the development specifications and domain knowledge for each functional module, organized by business module. Each Skill calls the corresponding set of manuals as needed: the Requirements Analysis Skill calls the Requirements Analysis Manual; the Solution Design Skill calls the Task Splitting Manual and the Technical Design Manual; the Test Design Skill calls the Test Solution Manual; the Code Development Skill calls the modular manuals such as Scenario / Grayscale / Data / Recall / Filtering / Reordering / Enhancement / Cache / Unit Test; the Code Review Skill calls the Code Style Check Manual, Logic Check Manual, and Sonar Check Manual; the Change Archiving Skill calls the Change Archiving related manuals. Each manual contains standardized input templates and execution steps, and AI automatically matches and executes the corresponding manual based on the semantics of the functional points.

[0030] For example, the AI ​​assistant core layer is located in the middle column of the architecture, driving the entire development process with a six-stage state machine: requirements analysis → solution design → test design → code implementation → code review → change archiving. Each stage receives different types of user input (requirements, technical lists, prompts, specifications, code), producing structured intermediate artifact files (requirement.md, design.md, task.md, test-plan.md, implementation.md, review.md, CHANGELOG.md). The artifacts of the previous stage automatically drive the start of the next stage, achieving automated process flow.

[0031] For example, the user interaction layer is located on the left side of the architecture, where users interact with the system through natural language. Different stages receive different user inputs—the requirements analysis stage receives the requirements, the solution design stage provides a supplementary technology list, the testing / coding / review / archiving stage is driven by prompts, and the code implementation stage can also accept specification documents and existing code as context. Each stage requires user confirmation before proceeding to the next.

[0032] In one implementation, a six-stage approach is designed to achieve an AI-assisted software development method based on a rules-skills-manual knowledge architecture.

[0033] Phase 1: Execution Requirements Analysis.

[0034] In one implementation, the entity performing the requirements analysis includes a requirements analysis skill (analysis); input: user requirements description (natural language / PRD document / DingTalk document link); output: requirement.md.

[0035] In one implementation, the steps of performing requirements analysis include: Step S100: Initialize the statistical counter and record the start time.

[0036] In step S100 of one implementation, step S101 involves fully reading the requirements description and extracting core business objectives, user roles, triggering scenarios, and key business conditions.

[0037] For example, load the analysis manuals of each system, and break down the requirements into structured function points (FPs) according to the list of function entry points in the manuals. The format is [FP-N]{verb}+{business object}+{behavioral result}—function entry point. Match each FP with the function entry point of each system analysis manual to generate a cross-system mapping table. At the same time, analyze the missing information and logical incomplete items in the requirement description.

[0038] In step S100 of one implementation, step S102 extracts the core functional phrase and DMPT-ID from the requirements, combines them into change-id, and creates a change catalog.

[0039] In step S100 of one implementation, step S103 writes the change summary, function point list, and requirement problem analysis into requirement.md and saves them temporarily.

[0040] In step S100 of one implementation, step S104 writes statistical data to statistics.md, outputs a completion prompt, and waits for user confirmation before proceeding to the next stage. Stage constraints: reading code files is prohibited, searching code repositories is prohibited, and outputting technical details is prohibited; a purely product-centric perspective is maintained.

[0041] In one implementation, the requirements analysis phase is executed by requirements analysis skills. It takes user-generated natural language descriptions of requirements, PRD documents, or document links as input, and outputs a structured requirements document (requirement.md). The overall approach remains purely product-centric, without delving into any technical implementation details. The specific execution steps are as follows: First, initialize the statistics counter and record the phase start time; then, fully parse the user requirements, extracting core business objectives, user roles, triggering scenarios, and key business conditions. Load the corresponding system analysis manual, and based on the manual's function entry list, break down the original requirements into standardized structured functional points, uniformly adopting the format "verb + business object + behavior result - function entry," and establish cross-system mapping relationships between functional points and various systems. Simultaneously, identify and address any missing information or logical flaws in the requirements; next, extract the core functional phrases and unique identifiers to generate change IDs, and create a dedicated change directory; write the change summary, structured functional point list, and requirements problem analysis results into requirements.md and store them temporarily; finally, update the statistical data to statistics.md, await user confirmation, and proceed to the next phase. Strict constraints apply during this phase: reading code files, searching code repositories, and outputting technical details are prohibited; the entire process must maintain a product requirements analysis perspective.

[0042] Phase Two Implementation Plan Design.

[0043] In one implementation, the execution entity for the scheme design includes a scheme design Skill (design); the input is requirement.md plus user-supplemented technical information; the output is design.md plus task.md.

[0044] In one implementation, the execution steps of the scheme design are as follows: Step S200 initializes statistics by reading statistics.md and requirement.md.

[0045] In step S200 of one implementation, step S201 reads the design specifications of each involved system. The catalog of each system manual is scanned, and the description field of the manual is matched semantically with the FP function entry point; the manual content is read according to the main manual → dependent sub-manual link, and the "User Instruction Format" section is extracted; for modification scenarios, code files are read to analyze dependencies; dynamic parameters (grayscale identifier, LionKey, RedisKey, etc.) are intelligently pre-filled based on the existing code pattern of the project, and placeholders are reserved for those that cannot be inferred; all FP input templates are merged by system dimension and written to design.md.

[0046] In step S200 of one implementation, step S202 displays the matching manual and dependencies, and waits for the user to fill in the development input and reply "complete".

[0047] In step S200 of one implementation, step S203 reads the user-filled design.md and design specifications, reads the "Execution Steps" section of each manual, and breaks down the tasks into atomic tasks according to the manual steps. The tasks are arranged in the order of execution dependencies, encoded by system prefix ID (S- / V- / C- / X-), written to task.md, and a review benchmark table is attached.

[0048] In step S200 of one implementation, step S204 performs product integrity and artifact integrity checks (FP coverage, system coverage, manual matching, cross-system interaction, etc.). The experience gained from this dynamic parameter identification is written back to the corresponding manual (grayscale naming → grayscale manual, LionKey naming → configuration manual, etc.). Statistical data is written, and after user confirmation, the code development phase begins. Phase constraints: Searching code repositories is prohibited; outputting code implementation is prohibited; searching manuals independently is prohibited (must be read according to the main manual's dependency links); skipping manuals and directly reading code is prohibited.

[0049] In one implementation, the solution design phase is executed by solution design skills. The inputs are the `requirement.md` file generated during the requirements analysis phase and user-supplemented technical information. The outputs are the design document `design.md` and the task breakdown document `task.md`. The core implementation is the standardized transformation of requirement functional points into executable development tasks. The specific execution steps are as follows: Initialize phase statistics, read historical statistics files and requirement documents; load the design specifications and manual files of the system in question, accurately associate requirement functional points with manual function entry points through semantic matching, read specification content according to the hierarchical link of the main manual and dependent sub-manuals, and extract standardized user instruction formats; for functional iteration and modification scenarios, automatically read code files to analyze dependencies, intelligently pre-fill dynamic parameters such as grayscale identifiers, LionKey, and RedisKey based on the existing code pattern of the project, retain standardized placeholders for parameters that cannot be automatically inferred, and integrate all system functional point input templates to generate a design. The `gn.md` file is generated, displaying associated manuals and dependencies, awaiting user completion and confirmation. After user confirmation, the improved design document and system design specifications are read, and the execution steps within the manual are broken down into ordered atomic development tasks. These tasks are sorted according to business execution dependencies and uniformly coded using system prefixes, generating a `task.md` file containing a review benchmark table. Product integrity verification is performed, covering functional points, system modules, manual matching, and cross-system interactions across multiple dimensions. Simultaneously, best practices such as dynamic parameter identification and configuration naming are automatically written back to the corresponding knowledge base manual, and stage statistics are updated. After user confirmation, the code development phase begins. Strict constraints apply during this phase: searching the code repository, outputting code implementation logic, and unauthorized manual matching are prohibited. Specification content can only be loaded through the main manual's dependency chain; directly reading code without accessing the manual is strictly prohibited.

[0050] Phase 3: Execution code development.

[0051] In one implementation, the entity executing the code development includes a code development skill (development); the inputs are task.md + design.md + corresponding manual; the outputs are implementation.md + actual code changes. In one implementation, the execution steps of code development are as follows: Step S300: Initialize statistics (including code count counter), and read statistics.md and task.md.

[0052] In step S300 of one implementation, if implementation.md does not exist in step S301, then design.md, task.md, and the execution steps of each manual are read, and relevant documents, implementation schemes, core pseudocode, and acceptance criteria are generated for each task and written into implementation.md. The task execution is only initiated after user confirmation is required.

[0053] In step S300 of one implementation, step S302 executes tasks sequentially: Before each task is executed, the working directory is determined based on the prefix (S- / V- / C- / X-), the corresponding system's coding standards / design standards / best practices and other rule files are loaded, and the manual corresponding to the task is read. Code modifications are performed according to the manual, and pre-development checks are performed (constant reuse retrieval, disabling magic values, referencing implementation styles in the same directory, verifying import authenticity, etc.). Upon completion, the task.md status is immediately updated to DONE, and gitadd is executed in the corresponding project directory to precisely stage the changed files. The next PENDING task is then automatically executed.

[0054] In step S300 of one implementation, after all tasks in step S303 are completed, Maven compilation verification is performed on the system with code changes.

[0055] In step S300 of one implementation, step S304 collects code volume statistics (using gitdiff to obtain the number of newly added / deleted lines and modified files for each system), writes the statistical data to statistics.md (including a dedicated section on code volume), and waits for user confirmation before entering the Review stage. Stage constraints: only one task is executed at a time, git commit / push is prohibited, skipping tasks is prohibited, batch git add is prohibited, and business code modification is prohibited before user confirmation.

[0056] In one implementation, the code development phase is performed by code development skills. The inputs are task.md, design.md and the corresponding system development manual produced in the solution design phase. The outputs are the implementation documentation implementation.md and the project code change artifacts, so as to achieve standardized and normalized code iterative development. The specific execution steps are as follows: Initialize the stage counter containing code volume statistics, and read the statistics file and task document; if the implementation document does not exist, integrate the design document, task list, and manual execution specifications, clarify the change files, implementation scheme, core pseudocode, and acceptance criteria for each development task, generate implementation.md, and start the development task after user confirmation; execute atomic development tasks sequentially, match the corresponding working directory according to the task prefix, automatically load system coding specifications, design guidelines, best practices, and other constraints, strictly follow the manual steps to perform code modifications, and synchronously complete pre-development verification, including constant reuse verification, prohibiting magic values, unifying directory code style, and verifying the authenticity of import logic; after a single task is completed, immediately update the task.md status to completed, accurately store the change files, and automatically move to the next pending task; after all tasks are developed, perform Maven compilation verification on the changed system to ensure that the code can be compiled normally; finally, collect code change data for each system, count the number of added and deleted lines of code and the number of change files, update the dedicated code volume statistics section to statistics.md, and enter the code review stage after user confirmation. This phase is subject to strict restrictions: only one task can be executed at a time, submitting push code is prohibited, skipping tasks is prohibited, batch saving of files is prohibited, and business code cannot be modified without user confirmation.

[0057] Phase 4: Code review.

[0058] The execution entity for code review includes: the code review skill (review); the input is gitdiff+task.md+requirement.md+design.md+implementation.md; the output is review-report.md.

[0059] In one implementation, the execution steps for code review are as follows: Step S400 initializes statistics and automatically detects the execution mode (if task.md exists in the directory, it is in SDD mode; otherwise, it is in independent mode).

[0060] In step S400 of one implementation, step S401 collects review input: reads all artifact files, performs gitdiff--cached to collect code changes for each involved system, and loads the corresponding system rule file.

[0061] In step S400 of one embodiment, step S402 performs a nine-layer hierarchical review: The first layer of requirements is met: check the completeness of functionality and the implementation of business rules against requirement.md; Second-level design implementation: Check the implementation of the plan against design.md / implementation.md; The third level of code quality includes: correctness, performance, readability, and security. The fourth layer of specifications adheres to: coding / design / database / interface specifications; The fifth layer of the architecture consists of: Handler layer (naming / annotation / exception / single responsibility), Repo layer (corruption prevention / batch processing / timeout / degradation), Config layer, Enum layer, and general checks. Sixth-level code quality depth: comment quality, method complexity (number of lines ≤ 80 / parameters ≤ 3 / nesting ≤ 3 levels), logical clarity (guard statements / condition extraction), Sonar preflight check; Layer 7 Impact Scope Analysis: Change File Classification, Dependency Chain Tracing (Searching All Reference Points), Contextual Integrity, and Logic Behavior Change Risk Assessment (Diffusion Impact Rating of Condition / Return Value / Anomaly / Data Flow Changes); Layer 8 Exception Scenario and API Specifications: 11 common API misuse patterns and 9 boundary scenario checks; The ninth layer of experimental governance project includes 12 general checks and 9 extended checks (including residual reference search verification). In step S400 of one implementation, step S403 involves checking each item against the task.md review criteria and recording the problems as a three-level classification: blocking / suggestion / hint.

[0062] In step S400 of one implementation, step S404 writes and temporarily saves review-report.md. If there is a blocking issue, the user is notified to fix it and re-review; if there is no blocking issue, the process proceeds to the technical solution stage after user confirmation. Stage constraints: Modifying the code is prohibited, and subjective judgment is prohibited as the basis for blocking.

[0063] In one implementation, the code review phase is executed by code review skills. Inputs include code change cache data, task.md, and all pre-process artifact documents. The output is a standardized review report (review-report.md), which comprehensively ensures code development quality and compliance through a nine-layer hierarchical review mechanism. The specific execution steps are as follows: Initialize phase statistics, automatically identify the operating mode, and distinguish between standardized SDD mode and independent review mode based on the presence of task.md in the change directory; summarize all pre-process artifact files, obtain code change cache data, and load the corresponding system specification rule files; perform a nine-layer hierarchical full-coverage review, sequentially checking the completeness of requirement matching, design implementation, basic code quality, compliance with coding standards, architectural layering compliance, in-depth code quality, scope of change impact, APIs and boundary scenarios, and experimental governance, comprehensively identifying code defects and non-compliance issues; verify each item against the built-in review benchmarks in task.md, classifying all issues into three levels: blocking, suggestion, and prompt; generate and temporarily store review-report.md. If blocking issues exist, prompt the user to fix them and re-review; otherwise, wait for user confirmation before proceeding to the technical solution generation phase. This phase is strictly constrained: direct code modification is prohibited during the review process, all issue judgments are based on standard specifications, and subjective experience is prohibited as a basis for blocking decisions.

[0064] Phase 5 involves generating the technical solution. The execution entity includes: the technical solution Skill (tech-design); the input is all previous artifacts + gitdiff + LionMCP + ABTestMCP; the output is tech-design.md.

[0065] In one embodiment, the execution steps for generating the technical solution are as follows: Step S500: Initialize statistics (including MCP call counter) and read statistics.md.

[0066] In step S500 of one implementation, step S501 reads all preceding artifact files and performs a cross-project gitdiff to collect code changes.

[0067] In step S500 of one implementation, step S502 analyzes code changes to extract key information: external calls (RPC service / forward ranking service / Redis cache), configuration items (LionKey / AB experiment / enumeration), and core process logic (grayscale judgment / cache read / write / degradation processing).

[0068] In step S500 of one implementation, step S503 calls LionMCP to query the actual production value of each Lion configuration key, and calls ABTestMCP to query the experimental layer details (version / variable / bucket range). If the value cannot be obtained, it is marked "to be confirmed".

[0069] In step S500 of one implementation, step S504 generates a technical solution document for testers, including: a business requirement introduction, an interaction flowchart (Mermaid), a core execution flowchart (Mermaid), a gray-scale labeling mechanism, an external call details table, Lion / AB experiment configuration details (including actual production values), caching strategies, degradation and exception handling, risk analysis, online observation indicators, and a gray-scale rollout plan. The document does not contain code snippets.

[0070] In step S500 of one implementation, step S505 involves writing and temporarily storing tech-design.md, writing statistical data, performing a product integrity check (checking all 7 product files), and then proceeding to the archiving stage after user confirmation. Stage constraints: Outputting code implementation is prohibited, modifying business code is prohibited, skipping MCP queries is prohibited, and guessing configuration values ​​is prohibited.

[0071] In one implementation, the technical solution generation stage is performed by technical solution design skills. The inputs are the pre-production products of the entire process, code change data, Lion configuration and A / B test data, and the output is a technical solution document tech-design.md for testers, which focuses on sorting out the technical implementation logic, configuration information and deployment risks. The specific execution steps are as follows: Initialize the counter containing MCP call statistics and read the full-process statistical data; integrate all pre-process structured artifacts and sort out all changes through cross-project code difference comparison; extract core information from code changes, including external RPC calls, cache dependencies, various configuration items, core business processes, canary release strategies, degradation exception logic, etc.; call LionMCP and ABTestMCP tools to accurately query the actual values ​​of online configuration keys, experimental versions, variable parameters, and bucket ranges, and uniformly mark unobtainable information as pending confirmation; generate a complete technical solution document, covering a business requirement overview, interaction and core execution flowcharts, canary release control mechanisms, external call details, configuration parameter details, caching and degradation strategies, online risk assessment, observation indicators, and canary release plans. The document only shows the technical logic and does not contain specific code snippets; temporarily save tech-design.md, update the stage statistical data, complete the full-process artifact integrity verification, and wait for user manual confirmation before entering the archiving stage. Strict constraints apply during this stage: outputting code implementation details, modifying business code, skipping the configuration query process, and subjectively guessing online configuration parameters are prohibited.

[0072] Phase Six: Implement Change Archiving.

[0073] The execution process includes the Change Archive Skill (archive); the input is all preceding artifact files; and the output is the final summary of CHANGELOG.md and statistics.md. In one implementation, the steps for performing change archiving are as follows: Step S600 initializes statistics by reading statistics.md.

[0074] In step S600 of one embodiment, step S601 reads all preceding artifact files (requirement.md, design.md, task.md, tech-design.md, implementation.md, review-report.md).

[0075] In step S600 of one implementation, step S602 extracts the core content from each product and organizes the CHANGELOG structure: change summary, function point list, design scheme summary, technical solution summary, gray scale strategy, review conclusion, change document list, and online checklist.

[0076] In step S600 of one implementation, step S603 checks whether the change introduces a new Handler pattern / tool ​​method / configuration pattern / exception handling pattern. If so, it lists the recommended updated manual and reusable patterns.

[0077] In step S600 of one embodiment, step S604 writes CHANGELOG.md and temporarily saves it.

[0078] In step S600 of one implementation, step S605 writes the statistical data for this stage and generates a final summary of the entire process: workload distribution, time consumption distribution, and code volume summary for each stage. The SDD effectiveness index SEI is calculated as 0.4 × efficiency factor + 0.3 × quality factor + 0.3 × output factor, and the effectiveness level (A~E) is determined. Analysis conclusions are generated from five dimensions: efficiency, quality, output, workload distribution, and improvement suggestions. An output integrity check is performed (checking all 8 output files).

[0079] In step S600 of one implementation, step S606 outputs an archiving completion confirmation, lists the archived items and specification update suggestions, and prompts for subsequent operations (git commit → Merge Request → Release). Stage constraints: Modification of business code is prohibited; the archived artifacts are only CHANGELOG.md and statistics.md.

[0080] In one implementation, the change archiving stage is executed by the change archiving skill. The input is the product documents of all stages of the entire process, and the final output is the change log CHANGELOG.md and the final summary statistics file statistics.md, which realizes the accumulation of development process, knowledge iteration and quantitative evaluation of effect. The specific execution steps are as follows: Initialize archived statistical data, read the full-process statistical files and all preceding artifacts; integrate the core content of each stage, standardize and generate CHANGELOG documents, covering core modules such as change summary, function point list, design and technical solution summary, gray-scale strategy, review conclusion, change file list, and deployment checklist; intelligently identify reusable experiences such as newly added coding patterns, tools and methods, configuration rules, and exception handling mechanisms in this development, match them with the corresponding knowledge base manual, and provide suggestions for standard updates; complete the writing and temporary storage of change logs, and update the statistical data of the archiving stage; summarize the core data such as time consumption, workload, and code change volume of each stage of the entire process, calculate the SDD effect index SEI, divide the effect into five levels from A to E based on the index, and generate quantitative analysis conclusions from five dimensions: development efficiency, code quality, output completeness, workload distribution, and optimization direction; complete the completeness verification of the eight artifacts of the entire process, and finally output the archiving completion prompt, display the archiving list and knowledge base optimization suggestions, and guide users to complete the subsequent code submission, merging, and release processes. Strict constraints apply to this stage: modification of business code is prohibited during the archiving stage; the stage is only responsible for generating change logs and the final quantitative statistical report.

[0081] In one implementation, such as Figure 5 As shown, the present invention also constructs a constraint priority system of a three-layer knowledge architecture.

[0082] For example, the present invention defines a strict constraint priority system, which is as follows from high to low: execution rules of lower priority content must not cover higher priority constraints; when a user's temporary instruction conflicts with Rules, the AI ​​must refuse to execute and explain the reason; when constraints of the same level conflict, the AI ​​must not make a decision on its own, but must pause and prompt the user for processing.

[0083] For example, the present invention designs a six-stage state machine to drive the entire AI-assisted development process.

[0084] For example, for the first phase of requirements analysis, the input includes a natural language requirement description; the output includes requirement.md (a structured list of functional points); the core mechanism is a pure product perspective constraint (prohibiting AI from reading code files or outputting technical details at this stage), forcing AI to decompose functional points from a business perspective; the functional point format is: [FP-N]{verb}+{business object}+{behavioral result}—functional entry point.

[0085] For example, for the Phase 2 solution design, the input includes requirement.md + user-supplemented technical context; the output includes design.md (technical design) + task.md (task list); the core mechanism is to automatically match the corresponding development manual based on the function entry identifier of the function point, and merge the "user instruction format" in the manual into an input template, so that the user only needs to fill in the blanks to supplement key information.

[0086] For example, for Phase 3 test design, the inputs include requirement.md, design.md, and task.md; the outputs include test-plan.md (test plan) and test-cases.md (test cases); the core mechanism is to automatically match test strategy templates according to functional categories (configuration distribution / blocking / parameter construction / filtering / rendering, etc.).

[0087] For example, for Phase 4 code development, the inputs include task.md, design.md, and the corresponding manual; the outputs include implementation.md (implementation plan) and actual code changes; the core mechanism is: first, generate an implementation plan and wait for manual confirmation, then execute it one by one according to atomic tasks, and forcibly read the corresponding manual before executing each task.

[0088] For example, for Phase 5 code review, the inputs are code changes + task.md review benchmark + implementation.md; the output is review-report.md; the core mechanism is a four-layer review model (requirement fulfillment → design implementation → code quality → specification compliance), and the problem classification is (BLOCKER / MAJOR / MINOR).

[0089] For example, for Phase 6 change archiving, the input is all preceding artifact files; the output is CHANGELOG.md + statistics.md; the core mechanism is: automated CHANGELOG generation, experience write-back check, and SDD effect index calculation.

[0090] In one embodiment, the present invention also includes an automatic stage state inference mechanism.

[0091] For example, the current stage can be automatically determined by detecting the status of the product files in the change directory, as shown in Table 1.

[0092] Table 1

[0093] In one embodiment, the present invention also includes a manual confirmation access control mechanism.

[0094] For example, after each stage is completed, it is necessary to wait for explicit human confirmation before proceeding to the next stage, forming a closed loop of "AI output → human review → confirmation and progress". The access control nodes are shown in Table 2.

[0095] Table 2

[0096] In one embodiment, the present invention designs a mechanism for automatic manual matching and input template generation.

[0097] For example, for the manual automatic matching process, such as Figure 3 As shown.

[0098] For example, for function entry point identification, this invention includes the function entry point name and typical keywords for each functional domain. During the requirements analysis phase, AI automatically labels each functional point to its corresponding function entry point.

[0099] For example, for manual route matching, during the solution design phase, the corresponding development manual is automatically located in the manual directory tree based on the function entry identifier of the function point.

[0100] For example, the function entry "Cargo List Card Rendering - Card Click Button Element" → matches the manuals / development / cargolist / cardrender / button-element.md.

[0101] For example, the function entry point is "Cargo List - Handler Registration" → matching manuals / development / cargolist / base / handler.md.

[0102] For example, for input template synthesis, the "user instruction format" (standardized input template) defined in the matched manual is read, and multiple manual input templates are merged into a complete fill-in-the-blank input block. Developers only need to fill in key variable information (such as interface URL, timeout, field name, etc.), and AI can automatically complete code generation based on the manual specifications.

[0103] For example, for intelligent pre-filling, the system intelligently pre-fills some fields in the manual template (such as grayscale identifier naming and configuration key naming) based on the existing patterns of the project, further reducing the amount of manual filling.

[0104] In one embodiment, the present invention designs an experience writing-back and knowledge self-growth mechanism, such as... Figure 4 As shown.

[0105] For example, this invention enables the knowledge base to grow automatically as development practices progress through an experience write-back mechanism: Write-back trigger point: During the change archiving phase, the system automatically analyzes whether any new code patterns have been introduced during the development process.

[0106] Write-back rules: Add a new grayscale identifier naming pattern → automatically append to the grayscale domain manual; add a new configuration key naming pattern → automatically append to the configuration management manual; add a new interface call pattern → automatically append to the RPC client manual; add an enumeration attribution judgment rule → automatically append to the corresponding module manual.

[0107] Write-back constraints: The write-back operation must be performed during the change archiving phase, and the write-back content must be labeled with the source change ID for easy traceability. The written-back manual can be automatically loaded and used by AI in the next development of the same type of requirement.

[0108] In one embodiment, the present invention designs a statistical quantification and effect evaluation system.

[0109] For example, the collected metrics are as follows: Time dimension: total time spent, actual AI working time, and human waiting time for confirmation; Interaction dimension: number of user inputs, number of AI responses, and number of tool calls; Code dimension: number of newly added / deleted lines of code, number of modified files, and net increase in lines.

[0110] Effectiveness Evaluation Model (SDD Effectiveness Index SEI): SEI = 0.4 × Efficiency Factor (E_eff) + 0.3 × Quality Factor (Q_eff) + 0.3 × Output Factor (P_eff), where: Efficiency Factor: measures the amount of work completed per unit of time; Quality Factor: measures the code review pass rate and problem discovery rate; Output Factor: measures the scale of code output and task completion rate.

[0111] In one embodiment, the present invention designs a concern-forced isolation mechanism.

[0112] For example, the present invention sets a strict "prohibited items list" in each Skill to achieve mandatory isolation of concerns: In the requirements analysis stage: reading code files is prohibited, searching code libraries is prohibited, and outputting technical details is prohibited; In the solution design stage: generating code directly without reading the manual is prohibited; In the code development stage: generating code structures that are not based on the Rules or Manual is prohibited; In the code review stage: using subjective judgment as the basis for blocking is prohibited.

[0113] For example, this mechanism ensures that AI focuses only on what it should focus on at each stage, avoiding the problem of local correctness but global conflict.

[0114] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. 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 and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0115] In the description of this invention, it should be understood that the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this invention, "a plurality of" means two or more, unless otherwise explicitly specified.

[0116] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. An AI-assisted software development method based on a rule-skill-manual knowledge architecture, characterized in that, Includes the following steps: Based on the execution stages of the AI-assisted software, a constraint priority system is set up to constrain each stage of the AI-assisted software; The switching of each stage of the AI-assisted software is controlled through an automatic stage state inference mechanism and a manual confirmation access control mechanism. The system includes an automatic manual matching and input template generation mechanism, as well as an experience writing and knowledge self-growth mechanism, to optimize and control the operation of the AI-assisted software. The results of the AI-assisted software operation are statistically analyzed using a statistical quantification and effect evaluation system. Based on the mandatory isolation mechanism based on concerns, the execution of the AI-assisted software at a specified stage is restricted.

2. The AI-assisted software development method based on the rule-skill-manual knowledge architecture according to claim 1, characterized in that: When acquiring the execution phase of AI-assisted software, the execution phase of AI-assisted software includes the following stages executed sequentially: requirements analysis phase, solution design phase, code development phase, code review phase, technical solution generation phase, and change archiving phase.

3. The AI-assisted software development method based on the rule-skill-manual knowledge architecture according to claim 2, characterized in that: During the code development phase, tasks are executed sequentially. Before each task is executed, the working directory is determined based on the prefix, the corresponding rule file is loaded, and the manual corresponding to the task is obtained. Modify the code according to the manual and perform pre-development checks; Once completed, immediately update the task.md status to DONE, and execute `git add` in the corresponding project directory to precisely stage the changed files. Automatically continue to the next PENDING task.

4. The AI-assisted software development method based on the rule-skill-manual knowledge architecture according to claim 3, characterized in that: During the code review phase, a nine-layer hierarchical review process is implemented: Once the first layer of requirements is met, review and check the completeness of functions and the implementation of business rules against the requirements.md file. The second layer involves design and implementation, with a review and comparison against design.md / implementation.md to check the feasibility of the solution. The third layer of code quality involves reviewing correctness, performance, readability, and security. Fourth-level compliance includes reviewing coding, design, database, and interface specifications. The fifth layer of the architecture is divided into layers, including the Handler layer, Repo layer, Config layer, Enum layer, and general checks. The sixth layer of code quality depth involves reviewing the quality of comments, method complexity, logical clarity, and Sonar preflight check. The seventh layer of impact analysis includes reviewing the classification of changed documents, dependency chain tracing, contextual integrity, and risk assessment of changes in logical behavior. The eighth layer includes abnormal scenarios and API specifications, performing checks for 11 common API misuse patterns and 9 boundary scenarios. The ninth-level experimental governance project involves 12 general inspections and 9 extended inspections.

5. The AI-assisted software development method based on the rule-skill-manual knowledge architecture according to claim 1, characterized in that: When constraining each stage of AI-assisted software, during the requirements analysis stage, AI is forced to break down its functional points from a business perspective. During the solution design phase, the corresponding development manual is automatically matched based on the function entry identifier of the function point, and the user instruction format in the manual is merged into an input template. During the test design phase, test strategy templates are automatically matched based on functional categories. During the code development phase, an implementation plan is first generated and awaited manual confirmation. Then, it is executed one by one in atomic tasks, with the corresponding manual being read before each task is executed. During the code review phase, a four-tier review model is established, encompassing requirement fulfillment, design implementation, code quality, and compliance with standards, with issues categorized accordingly. During the change archiving phase, automated CHANGELOG generation, experience write-back checks, and SDD effectiveness index calculation are performed.

6. The AI-assisted software development method based on the rule-skill-manual knowledge architecture according to claim 1, characterized in that: When setting up the automatic stage status inference mechanism, the AI-assisted software is controlled to automatically determine the current stage by detecting the status of the product files in the changed directory.

7. The AI-assisted software development method based on the rule-skill-manual knowledge architecture according to claim 1, characterized in that: When setting up a manual confirmation access control mechanism, the AI-assisted software is controlled to wait for explicit human confirmation after each stage is completed before proceeding to the next stage.

8. The AI-assisted software development method based on the rule-skill-manual knowledge architecture according to claim 1, characterized in that: When setting up the automatic matching and input template generation mechanism for the manual, function entry identification is performed to control the AI-assisted software to mark each function point to the corresponding function entry. By matching the manual routes, the corresponding development manual can be located in the manual directory tree according to the function entry identifier of the function point. By synthesizing input templates, the AI-assisted software is controlled to generate code based on the matched development manual and perform intelligent pre-filling.

9. The AI-assisted software development method based on a rule-skill-manual knowledge architecture according to claim 1, characterized in that: When setting up the experience writing-back and knowledge self-growth mechanism, the writing-back constraint is set to control the writing-back operation to be performed during the change archiving stage, and the writing-back content must be marked with the source change ID; The control manual, after being written back, is automatically loaded and used by the AI-assisted software in the next development of the same type of requirement.

10. The AI-assisted software development method based on the rule-skill-manual knowledge architecture according to claim 1, characterized in that: When designing a mandatory isolation mechanism for concerns, during the requirements analysis phase, reading code files, searching code repositories, and outputting technical details should be prohibited. During the solution design phase, it is prohibited to generate code directly without reading the manual; During the code development phase, it is prohibited to generate code structures that are not supported by the Rules or Manual; during the code review phase, it is prohibited to use subjective judgments as the basis for blocking.

Images