A specification and software automatic co-construction method and device based on collaborative dialogue driving

Abstract

This invention discloses a method and apparatus for the automatic co-construction of specifications and software based on collaborative dialogue. The method includes: step S1, capturing and semantically processing meeting content; step S2, automatically generating and updating specification documents and intermediate project files; step S3, constructing file summaries and indexes; step S4, generating code; and step S5, iterating project versions. This invention can automatically convert meeting discussions into specification documents and project code, forming a complete pipeline from meeting to software implementation, significantly improving software development efficiency, maintaining consistency between specifications and code, reducing manual maintenance workload, and enhancing the efficiency of project knowledge utilization.

Description

Technical Field

[0001] This invention belongs to the field of automatic specification and software co-construction technology, and relates to a method and apparatus for automatic specification and software co-construction based on collaborative dialogue. Background Technology

[0002] Software development collaborative management, also known as software development collaborative engineering, follows a pipeline principle from meeting discussions to documentation and then to code. It aims to achieve collaborative software development, enabling the conversion of meeting outcomes into documentation at any time, with synchronized updates between documentation and code. Software development collaborative management contrasts with traditional software development methods. Collaboration means that documentation can be generated solely through meeting discussions, eliminating the need for manual coding. With the development and advancement of artificial intelligence, developers no longer need to manually input complex specifications to implement software functions. Instead, business documentation can be completed simply by controlling the requirement flow and configuring document parameters through collaborative meetings. This new development approach is gradually replacing traditional manual coding. However, because documentation generation is a complex task that cannot be accomplished on the first try, it typically requires numerous analyses and adjustments by the system. This process is not only cumbersome but also prone to errors if collaboration is inadequate.

[0003] To address the aforementioned issues, existing technologies include requirements management tools, version control and continuous integration systems, knowledge management systems, and low-code platforms. Requirements management tools such as DOORS and Jira provide requirements tracking and change management capabilities, but their integration with the code implementation phase is weak. Users cannot directly generate code during requirements analysis, which not only reduces development efficiency but also increases the risk of discrepancies between requirements and code, thus lowering software quality. Furthermore, this technical solution lacks an effective mechanism to connect ongoing collaborative dialogue with software specifications and code implementation, and it fails to systematically transform meeting outcomes into project documentation, thus failing to form a complete knowledge system. Summary of the Invention

[0004] To address the aforementioned issues, this invention provides a method and apparatus for the automatic co-construction of specifications and software based on collaborative dialogue.

[0005] The technical solution adopted in this invention is as follows: A method for automatic co-construction of specifications and software based on collaborative dialogue, comprising the following steps: Step S1: Capture the dialogue content in the meeting in real time through the speech recognition model, convert it into a structured meeting minutes file and store it in the project knowledge base. The meeting minutes file includes business entities, functional points, technology choices, and key decisions of the participants. Step S2: Generate intermediate project files based on meeting minutes in the project knowledge base using the large language model. The intermediate project files include specifications, DDD models, and user story models. Store the intermediate project files in the project knowledge base. Step S3: Generate file content summaries for all files in the project knowledge base. The file content summaries include the file topic, file summary, and core file content. For all files in the knowledge base, build an index based on the file content summaries and the file's storage path in the knowledge base. Step S4: Generate project source code based on the files in the project knowledge base using the large language model, and store the project source code in the project knowledge base; Step S5: When a user starts a new meeting, the speech recognition model captures the dialogue content in the new meeting in real time, and extracts business entities, functional points, technology choices, and key decisions of participants from the dialogue content. This is then converted into a structured supplementary meeting minutes file. Based on the supplementary meeting minutes file, the large language model updates the meeting minutes files in the project knowledge base, regenerates text summaries, and builds an index. The construction of the index allows the large language model to become more familiar with the structure and content of the files in the project knowledge base.

[0006] Furthermore, the steps for generating the specification in step S2 include: (1) Extract and analyze business entities, functional points, technology choices, and key decisions of attendees from meeting minutes documents using a large language model, and determine the list of functions that the specification document needs to cover; (2) Generate a specification document framework based on the functional list using the large language model. The specification document framework includes a functional description chapter framework, an input / output chapter framework, a business rules chapter framework, an exception and boundary chapter framework, and an acceptance criteria chapter framework; (3) Based on the key decisions of attendees, obtain the functional points related to the key decisions of attendees in the specification document framework, and complete the input, output, rules, exceptions and boundaries, and acceptance criteria of the functional points as the specification document; (4) Perform a consistency check on the specification document using the large language model and obtain the consistency check results. The consistency check includes whether the functional list is fully implemented, whether the same terminology in the specification document is consistent, and whether the acceptance criteria in the specification document are consistent with the key decisions of attendees. If the consistency check is passed, the specification document is stored in the project knowledge base as part of the project intermediate documents.

[0007] If the consistency check fails, the specification is modified using the large language model based on the consistency check results until the consistency check passes. After that, the specification is stored in the project knowledge base as part of the project intermediate documents.

[0008] Furthermore, the steps for generating the DDD model in step S2 include: (1) Analyze and extract several entities and their attributes, relationships between entities, and several business boundaries from meeting minutes and specifications using a large language model; (2) Generate several first-version domain boundaries based on the business boundaries using the large language model, divide several entities into different first-version domain boundaries, and determine the domain name and terminology set for each first-version domain boundary to obtain several second-version domain boundaries; (3) Determine the core entity, value object, and aggregate root within each second-version domain boundary using the large language model to obtain several final-version domain boundaries; (4) Organize the relationships between the several final-version domain boundaries and entities into a DDD model, and store the DDD model as part of the project intermediate files in the project knowledge base.

[0009] Furthermore, the steps for generating the user story model in step S2 include: (1) Analyze and extract user roles, user needs and business value from meeting minutes, specifications and DDD models using the big language model; (2) Combine the user roles, user needs and business value to generate several user stories using the big language model, and establish a correspondence between the user stories and the functional points in the specifications that are related to the key decisions of the participants. (3) The large language model, combined with the specification, generates the acceptance criteria for each user story; the specification includes the acceptance criteria chapter, the business rules chapter, and the exception and boundary chapter; (4) The large language model determines the priority of the user stories based on the key decisions of the participants, and organizes all user stories, the acceptance criteria corresponding to each user story, and the priority corresponding to each user story into a user story model.

[0010] Furthermore, in step S3, the index is an inverted index, and the specific construction steps include: (1) Generate a file content summary for each file in the project knowledge base using a large language model, and record the file name and storage path of the file; (2) Segment the content summary of each file and remove stop words to obtain a keyword set; (3) Use the keywords in the keyword set as index items to establish the correspondence between keywords and file names and their storage paths; (4) For each keyword in the keyword set, summarize it with its multiple corresponding file names and their storage paths to form a file set corresponding to the keyword, form an inverted index and store it in the project knowledge base.

[0011] Furthermore, the specific steps for code generation in step S4 include: (1) The large language model determines the basic engineering structure of the project based on the function points and technology selection, and determines the interfaces, function entry points and their inputs and outputs to be implemented according to the user story model and specifications; (2) The large language model generates the corresponding logical pseudocode based on the DDD model; (3) The large language model generates interface definition code and input / output data structure code based on the interface to be implemented, function entry and its input / output, and generates implementation code for each function point based on the logical pseudocode. The implementation code of each function point is then linked to the corresponding function entry to form a call relationship, thereby forming the complete project source code and storing it in the project knowledge base.

[0012] A domain-wide model application device based on DSL rules and format validators, comprising at least: The capture module is used to capture the dialogue content in the meeting in real time through a speech recognition model, convert it into a structured meeting minutes file and store it in the project knowledge base. The meeting minutes file includes business entities, functional points, technology choices, and key decisions of the participants. The first generation module is used to generate intermediate project documents based on meeting minutes in the project knowledge base using a large language model. The intermediate project documents include specifications, DDD models, and user story models, and are stored in the project knowledge base. The building module is used to generate file content summaries for all files in the project knowledge base. The file content summaries include the file topic, file summary, and core file content. For all files in the knowledge base, an index is built based on the file content summaries and the file's storage path in the knowledge base. The second generation module is used to generate project source code based on files in the project knowledge base using a large language model, and then store the project source code in the project knowledge base. The iteration module is used to capture the dialogue content of a new meeting in real time through a speech recognition model when a user starts a new meeting. It extracts business entities, functional points, technology choices, and key decisions of participants from the dialogue content and converts them into structured supplementary meeting minutes. Based on the supplementary meeting minutes, the large language model updates the meeting minutes in the project knowledge base, regenerates text summaries, and builds an index. The indexing process allows the large language model to become more familiar with the structure and content of the files in the project knowledge base.

[0013] An electronic device, comprising: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0014] A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method described above.

[0015] The beneficial effects of this invention are as follows: This invention can automatically extract key information from meeting content, generate structured documents, create indexes, and directly generate project source code, forming a complete pipeline from meeting to software implementation. This significantly improves software development efficiency, maintains consistency between specifications and code, reduces manual maintenance workload, and enhances the efficiency of project knowledge utilization. Attached Figure Description

[0016] Figure 1 This invention provides a flowchart of a method for automatic co-construction of specifications and software based on collaborative dialogue. Figure 2 This invention relates to a module diagram of an automatic specification and software co-construction device based on collaborative dialogue. Detailed Implementation

[0017] This invention can automatically extract key information from meeting content, generate structured documents, create indexes, and directly generate project source code, forming a complete pipeline from meeting to software implementation. This significantly improves software development efficiency, maintains consistency between specifications and code, reduces manual maintenance workload, and enhances the efficiency of project knowledge utilization.

[0018] Example 1 This embodiment requires generating and continuously iterating project code based on the progress of the meeting and its content. The specific user requirement is to generate a patient vital signs monitoring system.

[0019] like Figure 1 As shown, a collaborative dialogue-driven method for the automatic co-construction of specifications and software includes the following steps: Step S1: Meeting Content Capture and Semantic Processing The speech recognition model captures the dialogue content in the meeting in real time, converts it into a structured meeting minutes file and stores it in the project knowledge base. The meeting minutes file includes business entities, functional points, technology choices and key decisions of the participants. First, the SenseVoice speech recognition model captures the dialogue content in real time during the meeting. Then, the Deepseek-r1 model extracts the dialogue content using the prompt "Please extract the meeting minutes based on this meeting content. The meeting minutes should include business entities, functional points, technology choices, and key decisions of the participants." This extracts and converts the content into a structured meeting minutes file, which is then stored in the project knowledge base. The meeting minutes file includes business entities, functional points, technology choices, and key decisions of the participants. In this embodiment, the business entity in the meeting minutes file is a doctor, the functional points are blood pressure monitoring and blood glucose monitoring, the technology choices are: Vue technology for the front end and Spring Boot technology for the back end, and the key decisions of the participants are: the primary monitoring tasks for monitoring patient vital signs are blood pressure monitoring and blood glucose monitoring. The normal range for blood pressure is 90-139 mmHg for systolic blood pressure and 60-89 mmHg for diastolic blood pressure, and the normal range for blood glucose is 3.9-6.1 mmol / L. Step S2: Automatic generation and updating of specifications and intermediate project documents The project intermediate files are generated based on meeting minutes in the project knowledge base using a large language model. These intermediate files include specifications, DDD models, and user story models, and are stored in the project knowledge base. The steps for generating the specification in step S2 include: (1) Extract and analyze business entities, functional points, technology choices, and key decisions of attendees from meeting minutes documents using a large language model, and determine the list of functions that the specification document needs to cover; (2) Generate a specification document framework based on the functional list using the large language model. The specification document framework includes a functional description chapter framework, an input / output chapter framework, a business rules chapter framework, an exception and boundary chapter framework, and an acceptance criteria chapter framework; (3) Based on the key decisions of attendees, obtain the functional points related to the key decisions of attendees in the specification document framework, and complete the input, output, rules, exceptions and boundaries, and acceptance criteria of the functional points as the specification document; (4) Perform a consistency check on the specification document using the large language model and obtain the consistency check results. The consistency check includes whether the functional list is fully implemented, whether the same terminology in the specification document is consistent, and whether the acceptance criteria in the specification document are consistent with the key decisions of attendees. If the consistency check is passed, the specification document is stored in the project knowledge base as part of the project intermediate documents.

[0020] If the consistency check fails, the specification is modified using the large language model based on the consistency check results until the consistency check passes. After that, the specification is stored in the project knowledge base as part of the project intermediate documents.

[0021] In this embodiment, the Deepseek-R1 model is used with the prompt "Please extract and analyze the business entities, function points, technology choices, key decisions of the participants from the meeting minutes file, and determine the list of functions that the specification needs to cover" as the prompt. In this embodiment, the list of functions is: "1. Blood glucose monitoring; 2. Blood pressure monitoring;".

[0022] In this embodiment, the DeepSeek-R1 model is used to generate a specification framework based on the following: "Please generate a specification framework based on the function list. The specification framework must include a function description section framework, an input / output section framework, a business rules section framework, an exception and boundary section framework, and an acceptance criteria section framework. The function list is as follows: 1. Blood glucose monitoring; 2. Blood pressure monitoring;". Then, based on the key decisions of the attendees, the functional points in the specification framework related to the attendees' key decisions are obtained. In this embodiment, the functional point related to the attendees' key decisions is "1. Blood glucose monitoring". ;2. Blood Pressure Monitoring”, and complete the input, output, rules, exceptions and boundaries, and acceptance criteria for the function point to obtain the specification manual; In the “1. Blood Glucose Monitoring” function point, the input is the patient's blood glucose, and the output is whether the patient's blood glucose is normal. The rule is “If the patient's blood glucose is in the range of 3.9 to 6.1 mmol / L, it is normal; otherwise, it is abnormal.” The exception in the rule reflects an abnormal physical condition of the patient. The exception and boundary are: “Whether the blood glucose is negative or exceeds 100 mmol / L”; The acceptance criterion is: “Able to accurately and stably judge the patient's blood glucose”. The exception in the exception and boundary reflects an abnormal operation of the device or code; In the "2. Blood Pressure Monitoring" function, the input is the patient's blood pressure, and the output is whether the patient's blood pressure is normal. The rule is "If the patient's systolic blood pressure is 90-139 mmHg and diastolic blood pressure is 60-89 mmHg, it is normal; otherwise, it is abnormal." Abnormalities in the rule indicate abnormalities in the patient's physical condition. The boundary between abnormality and abnormality is: "Is the blood pressure negative?" The acceptance criterion is: "Able to accurately and stably determine the patient's blood pressure." Abnormalities in the boundary indicate abnormalities in the device or code operation. Next, using the prompt "Please perform a consistency check on this specification to determine whether the function list is fully implemented, whether the same terminology in the specification is consistent, and whether the acceptance criteria in the specification are consistent with the key decisions of the participants," the DeepSeek-R1 model is used to perform a consistency check on the specification. If the consistency check passes, the specification is directly stored in the project knowledge base as part of the project intermediate documents. If the consistency check fails, the specification is modified according to the output of the DeepSeek-R1 model until the consistency check passes, and then the specification is stored in the project knowledge base as part of the project intermediate documents.

[0023] The steps in step S2 for generating the DDD model include: (1) Analyze and extract several entities and their attributes, relationships between entities, and several business boundaries from meeting minutes and specifications using a large language model; (2) Generate several first-version domain boundaries based on the business boundaries using the large language model, divide several entities into different first-version domain boundaries, and determine the domain name and terminology set for each first-version domain boundary to obtain several second-version domain boundaries; (3) Determine the core entity, value object, and aggregate root within each second-version domain boundary using the large language model to obtain several final-version domain boundaries; (4) Organize the relationships between the several final-version domain boundaries and entities into a DDD model, and store the DDD model as part of the project intermediate files in the project knowledge base.

[0024] In this embodiment, the Deepseek-R1 model is used, with the prompt "Please analyze and extract several entities and their attributes, relationships between entities, and several business boundaries from the meeting minutes and specifications" to extract and analyze business entities and their attributes, relationships between entities, and business boundaries. In this embodiment, business entities include: "patient", "vital signs", "blood glucose measurement record", "blood pressure measurement record", and "normal range rule". Relationships between entities include: "patient contains several vital signs measurement records"; "vital signs measurement records correspond to one type of indicator"; "normal range rule constrains the determination logic of indicator type". Business boundaries include: "blood glucose monitoring domain boundary" and "blood pressure monitoring domain boundary".

[0025] In this embodiment, the DeepSeek-R1 model is used with the prompt "Please identify business boundaries based on the core domain element set and generate a first initial version of the domain boundary, divide entities into different domain boundaries, and determine the domain name and terminology set for each domain boundary" to generate several first initial version domain boundaries, and divide entities into different first initial version domain boundaries; then, the domain name and terminology set are determined for each first initial version domain boundary to obtain several second initial version domain boundaries; in this embodiment, the names of the first initial version domain boundaries are "blood glucose monitoring context" and "blood pressure monitoring context", where the terminology set of blood glucose monitoring context includes "glycated hemoglobin", "insulin resistance", etc., and the terminology set of blood pressure monitoring context includes "systolic blood pressure", "diastolic blood pressure", etc.

[0026] In this embodiment, using the deepseek-r1 model, with the prompt "Please determine the core entity, value object, and aggregate root within each second initial version domain boundary, and provide consistency rules and invariant constraints within the aggregate," the core entity is determined to be "blood glucose value" in the "blood glucose monitoring context," the aggregate root is "blood glucose measurement record," and the value objects include "blood glucose value," "normal blood glucose range," and "blood glucose judgment result." In the "blood pressure monitoring context," the core entity is determined to be "systolic blood pressure," the aggregate root is "blood pressure measurement record," and the value objects include "systolic blood pressure, diastolic blood pressure, normal blood pressure range, and blood pressure judgment result," thus obtaining several final version domain boundaries.

[0027] The final domain boundaries are organized into a DDD model; and the DDD model is stored in the project knowledge base as part of the project intermediate files.

[0028] The steps in generating the user story model in step S2 include: (1) Analyze and extract user roles, user needs and business value from meeting minutes, specifications and DDD models using the big language model; (2) Combine the user roles, user needs and business value to generate several user stories using the big language model, and establish a correspondence between the user stories and the functional points in the specifications that are related to the key decisions of the participants. (3) The large language model, combined with the specification, generates the acceptance criteria for each user story; the specification includes the acceptance criteria chapter, the business rules chapter, and the exception and boundary chapter; (4) The large language model determines the priority of the user stories based on the key decisions of the participants, and organizes all user stories, the acceptance criteria corresponding to each user story, and the priority corresponding to each user story into a user story model.

[0029] In this embodiment, the DeepSeek-R1 model is used, with the prompt "Please analyze and extract user roles, user needs, and business value from meeting minutes, specifications, and the DDD model" to analyze and extract user roles, user needs, and business value from these documents. In this embodiment, user roles are defined as: "1. Nurse; 2. Doctor;". User needs are defined as: "1. Entering patient blood glucose and determining whether it is normal; 2. Entering patient blood pressure and determining whether it is normal; 3. Providing alerts for abnormal values;". Business value is defined as: "1. Timely monitoring of patient vital signs; 2. Reducing the risk of missed or incorrect diagnoses; 3. Improving ward monitoring efficiency;".

[0030] In this embodiment, the DeepSeek-R1 model is used, with the prompt "Please combine user roles, user needs, and business value to generate several user stories, and establish a correspondence between these user stories and the functional points in the specification that are related to the key decisions of the participants. User roles are as follows: 1. Nurse; 2. Doctor; User needs are as follows: 1. Enter patient blood glucose and determine whether it is normal; 2. Enter patient blood pressure and determine whether it is normal; 3. Provide alerts for abnormal values; Business value is as follows: 1. Timely monitoring of patient vital signs; 2. Reducing the risk of missed and misdiagnosed cases; 3. Improving ward monitoring efficiency; Functional points are as follows: 1. Blood glucose monitoring; 2. Blood pressure monitoring;" as the prompt words to generate several user stories and establish a correspondence. In this embodiment, the correspondence is as follows: User Story 1 (Corresponding Function: Blood Glucose Monitoring): As a nurse / doctor, I want to input patients' blood glucose values ​​and automatically determine whether they are normal, so as to detect abnormalities in a timely manner and take measures. User Story 2 (Corresponding Function: Blood Pressure Monitoring): As a nurse / doctor, I want to input patients' systolic and diastolic blood pressure and automatically determine whether they are normal, so as to detect abnormalities in time and take measures. In this embodiment, the Deepseek-r1 model is used with the prompt "Please generate acceptance criteria for each user story based on the specifications, which include an acceptance criteria section, a business rules section, and an exception and boundary section" to generate acceptance criteria for each user story. Specifically, the acceptance criteria for user story 1 in this embodiment are: "Able to stably receive blood glucose input; output is normal when blood glucose is in the range of 3.9–6.1 mmol / L, otherwise output is abnormal; when blood glucose is negative or exceeds 100 mmol / L, an illegal input or boundary violation message is displayed; the judgment result can be viewed by a nurse / doctor." The acceptance criteria for user story 2 in this embodiment are: "Able to stably receive systolic and diastolic blood pressure input; output is normal when systolic blood pressure is between 90–139 mmHg and diastolic blood pressure is between 60–89 mmHg, otherwise output is abnormal; when systolic or diastolic blood pressure is negative or exceeds the system upper limit, an illegal input or boundary violation message is displayed; the judgment result can be viewed by a nurse / doctor."

[0031] In this embodiment, the DeepSeek-R1 model is used, with the prompt "Please determine the priority of two user stories based on the key decisions of the participants. The key decisions are: the primary monitoring tasks for monitoring patient vital signs are blood pressure and blood glucose. The normal range for blood pressure is 90-139 mmHg systolic and 60-89 mmHg diastolic, and the normal range for blood glucose is 3.9-6.1 mmol / L." The priority of user stories is determined based on the key decisions of the participants. In this embodiment, the priority is: "User story 1 is P0; User story 2 is P0;". This embodiment designs four priority levels, from P0 to P3, from high to low priority.

[0032] Finally, all user stories, along with the acceptance criteria and priority for each user story, are organized into a user story model and stored in the project knowledge base as part of the project intermediate files.

[0033] Step S3: Document Digest and Index Construction Generate document content summaries for all documents in the project knowledge base. Each document content summary includes the document topic, document overview, and core content. For all documents in the knowledge base, build an index based on the document content summaries and the document's storage path in the knowledge base. In step S3, the index is an inverted index, and the specific construction steps include: (1) Generate a file content summary for each file in the project knowledge base using a large language model, and record the file name and storage path of the file; (2)Tokenize the abstracts of each file and remove stop words to obtain a keyword set; (3) Using the keywords in the keyword set as index terms, establish the correspondence between keywords and file names and their storage paths; (4) For each keyword in the keyword set, summarize it with its corresponding multiple file names and their storage paths into a file set corresponding to the keyword, form an inverted index and store it in the project knowledge base.

[0034] In this embodiment, through the deepseek-r1 model, with the prompt "Please generate an abstract for the files in the project knowledge base. The file abstract needs to include the file theme, file summary, and core content of the file, and output the file name and storage path", generate an abstract for each file in the project knowledge base, and record the file name and storage path of the file.

[0035] For example, for the file with the storage path " / project knowledge base / requirements / specification.docx", the file abstract output by the deepseek-r1 model in this embodiment is: " File theme: Specification of the patient vital sign monitoring system; File summary: Describe the input and output, business rules, abnormal boundaries, and acceptance criteria of two core functions, blood glucose monitoring and blood pressure monitoring; Core content of the file: The normal range of blood glucose is 3.9 - 6.1 mmol / L, the normal range of blood pressure is systolic blood pressure 90 - 139 mmHg and diastolic blood pressure 60 - 89 mmHg. Values outside the range are determined as abnormal and a prompt is given; at the same time, record the file name as "specification.docx" and the storage path as " / project knowledge base / requirements / specification.docx".

[0036] In this embodiment, tokenize the abstracts of each file and remove stop words to obtain a keyword set; among them, the tokenization results in this embodiment include keywords such as "patient, vital sign, monitoring, blood glucose, blood pressure, normal range, abnormal, determination, acceptance criteria, DDD, domain model, aggregation, unified language, alarm, event", etc., and after removing stop words such as "of, already, and, among which, for", etc., the keyword set is obtained.

[0037] In this embodiment, using the keywords in the keyword set as index terms, establish the correspondence between keywords and file names and their storage paths; for example, taking "blood glucose" as the index term, the corresponding file name and storage path in this embodiment include: "specification.docx - / project knowledge base / requirements / specification.docx", "DDD model.md - / project knowledge base / model / DDD model.md".

[0038] In this embodiment, for each keyword in the keyword set, each keyword and its corresponding multiple filenames and their storage paths are aggregated into a file set corresponding to that keyword, forming an inverted index; for example, the file set corresponding to "DDD" is {(DDD model.md, / project knowledge base / model / DDD model.md)}, which is finally formed into an inverted index and stored in the project knowledge base.

[0039] Step S4: Code Generation The project source code is generated based on the files in the project knowledge base using a large language model, and then stored in the project knowledge base. The specific steps for code generation in step S4 include: (1) The large language model determines the basic engineering structure of the project based on the function points and technology selection, and determines the interfaces, function entry points and their inputs and outputs to be implemented according to the user story model and specifications; (2) The large language model generates the corresponding logical pseudocode based on the DDD model; (3) The large language model generates interface definition code and input / output data structure code based on the interface to be implemented, function entry and its input / output, and generates implementation code for each function point based on the logical pseudocode. The implementation code of each function point is then linked to the corresponding function entry to form a call relationship, thereby forming the complete project source code and storing it in the project knowledge base.

[0040] In this embodiment, the functionalities are "1. Blood glucose monitoring; 2. Blood pressure monitoring;", and the technology selection is "Vue technology for the front end and Spring Boot technology for the back end". Therefore, the basic engineering structure determined by the deepseek-r1 model in this embodiment is as follows: "Controller layer: exposes a REST interface as the functional entry point; application / service layer: orchestrates test cases and calls the domain layer; domain layer: contains aggregates, value objects, domain services, and domain rules; infrastructure layer: contains repository implementation and persistence adaptation (optional)." Based on the user story model and specifications, the interfaces, function entry points, and their inputs and outputs to be implemented are determined. In this embodiment, the interfaces include a "blood glucose monitoring input interface" and a "blood pressure monitoring input interface," with corresponding inputs and outputs of: "blood glucose monitoring input interface (input: patientId, bloodGlucoseValue, measurementTime; output: normalFlag, judgment description message)" and "blood pressure monitoring input interface (input: patientId, systolic, diastolic, measurementTime; output: normalFlag, judgment description message)." These two interfaces serve as the function entry points for the project. In this embodiment, using the deepseek-r1 model, with the prompt "Please generate the corresponding logical pseudocode based on the DDD model, reflecting the calling relationship between aggregations, value objects, domain rules, domain events, and domain services," logical pseudocode is generated according to the DDD model. The logical pseudocode in this embodiment includes: "Use case: RecordBloodGlucose(patientId, value, time) checks the value boundary (reject if value < 0 or value > 100); constructs the value object BloodGlucose(value); calls VitalSignAssessmentService to determine if it is normal (3.9-6.1 is normal, otherwise abnormal); generates and persists the VitalSignMeasurement aggregation; if abnormal, publishes the domain event AbnormalVitalSignDetected; returns the judgment result; Use case: RecordBloodPressure(patientId,systolic, diastolic, time) checks the systolic / diastolic boundary; constructs the value object BloodPressure(systolic, (diastolic); Call VitalSignAssessmentService to determine if it is normal (systolic blood pressure 90-139 and diastolic blood pressure 60-89 is normal, otherwise abnormal); Generate VitalSignMeasurement aggregate and persist it; If abnormal, publish the domain event AbnormalVitalSignDetected; Return the judgment result; In this embodiment, the Deepseek-r1 model uses the prompt "Please generate interface definition code and input / output data structure code based on the interface to be implemented, the function entry point, and its input / output, and generate the implementation code for each function point based on the logical pseudocode, and establish a call relationship between the implementation code of each function point and the corresponding function entry point" to generate the implementation code for each function point, establish a call relationship between the implementation code of each function point and the corresponding function entry point, thereby forming the complete project source code, and storing the complete project source code as part of the project intermediate files in the project knowledge base.

[0041] Step S5, Project Version Iteration When a user starts a new meeting, the speech recognition model captures the dialogue content in real time and extracts business entities, functional points, technology choices, and key decisions of participants from the dialogue content. This is then converted into a structured supplementary meeting minutes file. Based on the supplementary meeting minutes file, the large language model updates the meeting minutes files in the project knowledge base, regenerates text summaries, and builds an index. The indexing process allows the large language model to become more familiar with the structure and content of the files in the project knowledge base.

[0042] When a user starts a new meeting, the SenseVoice speech recognition model captures the dialogue content in real time. In this example, it is "blood lipid monitoring needs to be added". The system extracts business entities, functional points, technology choices, and key decisions of the participants from the dialogue content and converts them into a structured supplementary meeting minutes file. Based on the supplementary meeting minutes file, the system updates the meeting minutes file in the project knowledge base through a large language model, regenerates the text summary and builds the index, and then updates the project source code.

[0043] Example 2 like Figure 2 A domain-wide model application device based on DSL rules and format validators, comprising at least: Capture module 1 is used to capture the dialogue content in the meeting in real time through a speech recognition model, convert it into a structured meeting minutes file and store it in the project knowledge base. The meeting minutes file includes business entities, functional points, technology choices and key decisions of the participants. The first generation module 2 is used to generate intermediate project files based on meeting minutes in the project knowledge base using a large language model. The intermediate project files include specifications, DDD models and user story models, and the intermediate project files are stored in the project knowledge base. Module 3 is used to generate file content summaries for all files in the project knowledge base. The file content summaries include the file topic, file summary, and core file content. For all files in the knowledge base, an index is built based on the file content summaries and the file's storage path in the knowledge base. The second generation module 4 is used to generate project source code based on files in the project knowledge base using a large language model, and then store the project source code in the project knowledge base.

[0044] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here. Iteration module 5 is used to capture the dialogue content of a new meeting in real time through a speech recognition model when a user starts a new meeting. It extracts business entities, functional points, technology choices, and key decisions of participants from the dialogue content and converts them into structured supplementary meeting minutes. Based on the supplementary meeting minutes, the large language model updates the meeting minutes in the project knowledge base, regenerates text summaries, and builds an index. The construction of the index allows the large language model to become more familiar with the structure and content of the files in the project knowledge base.

[0045] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0046] Accordingly, this application also provides an electronic device, including: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0047] Accordingly, this application also provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0048] In the embodiments provided in this application, it should be understood that the disclosed methods and systems can also be implemented in other ways. The method and system embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0049] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0050] On the other hand, a computer-readable storage medium stores computer instructions thereon, which, when executed by a processor, implement the steps of the above-described method. When the computer program is executed by the processor, it implements the method as described in any of the first aspects above. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0051] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for automatic co-construction of specifications and software based on collaborative dialogue, characterized in that, Includes the following steps: Step S1: Capture the dialogue content in the meeting in real time through the speech recognition model, convert it into a structured meeting minutes file and store it in the project knowledge base. The meeting minutes file includes business entities, functional points, technology choices, and key decisions of the participants. Step S2: Generate intermediate project files based on meeting minutes in the project knowledge base using the large language model. The intermediate project files include specifications, DDD models, and user story models. Store the intermediate project files in the project knowledge base. Step S3: Generate file content summaries for all files in the project knowledge base. The file content summaries include the file topic, file summary, and core file content. For all files in the knowledge base, build an index based on the file content summaries and the file's storage path in the knowledge base. Step S4: Generate project source code based on the files in the project knowledge base using the large language model, and store the project source code in the project knowledge base; Step S5: When a user starts a new meeting, the speech recognition model captures the dialogue content in the new meeting in real time, and extracts business entities, functional points, technology choices, and key decisions of participants from the dialogue content. This is then converted into a structured supplementary meeting minutes file. Based on the supplementary meeting minutes file, the large language model updates the meeting minutes files in the project knowledge base, regenerates text summaries, and builds an index. The construction of the index allows the large language model to become more familiar with the structure and content of the files in the project knowledge base.

2. The method according to claim 1, characterized in that, The steps for generating the specification in step S2 include: (1) Extract and analyze business entities, functional points, technology choices, and key decisions of participants from meeting minutes documents using a large language model, and determine the list of functions that the specification document needs to cover; (2) The large language model generates a specification framework based on the functional list. The specification framework includes a functional description section framework, an input and output section framework, a business rules section framework, an exception and boundary section framework, and an acceptance criteria section framework. (3) Based on the key decisions of the participants, the large language model obtains the functional points related to the key decisions of the participants in the specification framework, and completes the input, output, rules, exceptions and boundaries and acceptance criteria of the functional points as the specification. (4) Perform consistency checks on the specification through a large language model and obtain the consistency check results. The consistency check includes whether the function list is fully implemented, whether the same terminology in the specification is consistent, and whether the acceptance criteria in the specification are consistent with the key decisions of the participants. If the consistency check passes, the specification will be stored in the project knowledge base as part of the project intermediate documents; If the consistency check fails, the specification is modified using the large language model based on the consistency check results until the consistency check passes. After that, the specification is stored in the project knowledge base as part of the project intermediate documents.

3. The method according to claim 1, characterized in that, The steps in step S2 for generating the DDD model include: (1) Analyze and extract several entities and their attributes, relationships between entities, and several business boundaries from meeting minutes and specifications using a large language model; (2) The large language model generates several first-version domain boundaries based on several business boundaries, divides several entities into different first-version domain boundaries, and determines the domain name and term set for each first-version domain boundary to obtain several second-version domain boundaries. (3) By using the large language model, the core entities, value objects and aggregate roots are determined within each second initial version domain boundary to obtain several final version domain boundaries; (4) Organize the relationships between the domain boundaries and entities of the several final versions into a DDD model, and store the DDD model as part of the intermediate files of the project in the project knowledge base.

4. The method according to claim 1, characterized in that, The steps in generating the user story model in step S2 include: (1) Analyze and extract user roles, user needs and business value from meeting minutes, specifications and DDD models using large language models; (2) The user roles, user needs and business value are combined through the big language model to generate several user stories, and the user stories are then matched with the functional points in the specification that are related to the key decisions of the participants. (3) The large language model, combined with the specification, generates acceptance criteria for each user story; the specification includes an acceptance criteria section, a business rules section, and an exception and boundary section; (4) The priority of the user stories is determined by the key decisions of the participants through the large language model, and all user stories, the acceptance criteria and priority of each user story are organized together into a user story model.

5. The method according to claim 1, characterized in that, In step S3, the index is an inverted index, and the specific construction steps include: (1) Generate a file content summary for each file in the project knowledge base using a large language model, and record the file name and storage path of the file; (2) Segment the content summaries of each document and remove stop words to obtain a set of keywords; (3) Using the keywords in the keyword set as index items, establish the correspondence between keywords and file names and their storage paths; (4) For each keyword in the keyword set, it is combined with its multiple corresponding file names and storage paths to form a file set corresponding to the keyword, forming an inverted index and storing it in the project knowledge base.

6. The method according to claim 1, characterized in that, The specific steps for code generation in step S4 include: (1) The large language model determines the basic engineering structure of the project based on function points and technology selection, and determines the interfaces, function entry points and their inputs and outputs to be implemented according to the user story model and specifications. (2) The large language model generates the corresponding logical pseudocode based on the DDD model; (3) The large language model generates interface definition code and input / output data structure code based on the interface to be implemented, function entry and its input / output, and generates implementation code for each function point based on the logical pseudocode. The implementation code of each function point is then linked to the corresponding function entry to form a call relationship, thereby forming the complete project source code and storing it in the project knowledge base.

7. A device for automatic specification and software co-construction based on collaborative dialogue, characterized in that, At least including: The capture module is used to capture the dialogue content in the meeting in real time through the speech recognition model, convert it into a structured meeting minutes file and store it in the project knowledge base. The meeting minutes file includes business entities, function points, technology choices and key decisions of the participants. The first generation module is used to generate intermediate project files based on meeting minutes in the project knowledge base using a large language model. The intermediate project files include specifications, DDD models, and user story models, and are stored in the project knowledge base. The building module is used to generate file content summaries for all files in the project knowledge base. The file content summaries include the file topic, file summary, and core file content. For all files in the knowledge base, an index is built based on the file content summaries and the file's storage path in the knowledge base. The second generation module is used to generate project source code based on files in the project knowledge base using a large language model, and then store the project source code in the project knowledge base. The iteration module is used to capture the dialogue content of a new meeting in real time through a speech recognition model when a user starts a new meeting. It extracts business entities, functional points, technology choices, and key decisions of participants from the dialogue content and converts them into structured supplementary meeting minutes. Based on the supplementary meeting minutes, the large language model updates the meeting minutes in the project knowledge base, regenerates text summaries, and builds an index. The indexing process allows the large language model to become more familiar with the structure and content of the files in the project knowledge base.

8. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-6.

9. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, this instruction implements the steps of the method as described in any one of claims 1-6.

Images