Code-aware and large language model-based multi-round interactive requirement clarification method, electronic device and storage medium

Abstract

The embodiment of the application relates to the technical field of software development, and particularly relates to a multi-round interactive requirement clarification method based on code perception and a large language model, an electronic device and a storage medium. The embodiment of the application proposes a CARC (Code-Aware Requirement Clarification) mechanism. The CARC mechanism utilizes target information of source code of a target project, visualizes key decisions that are scattered, implicit and untraceable in initial requirement information, and clarifies the key decisions into traceable requirement clarification results. The CARC mechanism has more ability to expose key details that must be confirmed before requirement implementation, accurately understands user requirement intentions through requirement clarification interaction, improves completeness and executability of requirement analysis results, can accurately find contradictions between new requirements and existing logic or architecture, and accurately assesses an influence range of the new requirements.

Description

Technical Field

[0001] This application relates to the field of software development technology, and in particular to a multi-round interactive requirement clarification method, electronic device, and storage medium based on code awareness and a large language model. Background Technology

[0002] In the software development process, requirements gathering and clarification is one of the most critical and challenging stages, with many software defects stemming from problems in the requirements phase. New requirements often suffer from incomplete descriptions, potential conflicts with existing logic or architecture, and unclear scope of impact, thus necessitating requirements clarification.

[0003] In recent years, large language models have significantly improved code generation, code understanding, and question-answering capabilities. However, existing tools primarily focus on "how to implement the function" and pay less attention to "what should be confirmed before implementation." Related technologies, in terms of requirement clarification, do not record key decisions such as the code used to assess the impact of new requirements, existing logic, and critical issues that need clarification. This amplifies information gaps between product managers, developers, testers, and operations personnel, making it difficult to identify conflicts or contradictions between new requirements and existing logic or architecture, and hindering the assessment of the scope of the new requirements' impact. Summary of the Invention

[0004] One objective of this application is to provide a multi-round interactive requirement clarification method, electronic device, and storage medium based on code awareness and a large language model, in order to solve the technical problem in related technologies that the lack of recording of key decisions in the requirement clarification process leads to large information bias and makes it difficult to discover conflicts or contradictions between new requirements and existing logic or architecture.

[0005] In a first aspect, embodiments of this application provide a multi-turn interactive requirement clarification method based on code awareness and a large language model, comprising: Step S1: responding to initial requirement information about a target project input by a user, creating a reference session, wherein the initial requirement information is ambiguous and the reference session includes a dialogue history storing the initial requirement information; Step S2: calling a preset large language model to determine a target tool based on the dialogue history and returning a call instruction for the target tool, wherein the target tool includes any one or more preset query tools; Step S3: based on the call instruction, calling the target tool to obtain target information from the source code of the target project, wherein the target information includes at least one of code information, code call chain information, configuration information, and database information; Step S4: calling the large language model to generate a clarification question based on the target information and the dialogue history, and presenting the clarification question in the reference session; Step S5: responding to the user input of an answer to the clarification question, updating the answer to the dialogue history; Step S6: responding if the requirement clarification completion condition is not met, repeatedly executing steps S2 to S5; Step S7: responding if the requirement clarification completion condition is met, calling the large language model to generate a requirement clarification result based on the target information and the dialogue history; Step S8: presenting the requirement clarification result in the reference session.

[0006] Secondly, embodiments of this application provide an electronic device, including a processor and a memory. The processor is communicatively connected to the memory, and the memory stores computer program instructions executable by the processor. When the computer program instructions are executed by the processor, the electronic device performs the multi-turn interactive requirement clarification method based on code awareness and a large language model provided in the first aspect.

[0007] Thirdly, embodiments of this application provide a computer-readable storage medium storing processor-executable computer program instructions. When executed by the processor, the computer program instructions cause the processor to perform the multi-round interactive requirement clarification method based on code awareness and a large language model provided in the first aspect.

[0008] The embodiments of this application have the following beneficial effects: Unlike related technologies, the embodiments of this application create a reference session based on initial requirement information about the target project. A large language model is invoked to determine the target tool based on the dialogue history containing the initial requirement information. The large language model returns invocation instructions for the target tool. Based on these instructions, the target tool is invoked to obtain target data from the target project's source code. The large language model then generates clarification questions based on the target information, achieving targeted generation of clarification questions. These clarification questions are presented in the reference session, allowing users to input answers to the clarification questions. The answers are then updated in the dialogue history. When the clarification completion conditions are met, the large language model generates a clarification result based on the target information and the dialogue history, and this result is presented in the reference session. The embodiments of this application propose a CARC (Code-Aware Requirement Clarification) mechanism. This mechanism utilizes the target information from the target project's source code to make the scattered, implicit, and untraceable key decisions in the initial requirement information explicit, and clarifies these key decisions into traceable clarification results. Compared to analysis methods that only look at the requirement text, the CARC mechanism is more capable of exposing key details that must be confirmed before the requirement is implemented. Compared to methods that only look at the source code and directly generate clarification results, CARC accurately understands the user's requirement intent through requirement clarification interaction, improves the completeness and executability of requirement analysis results, and can accurately discover contradictions between new requirements and existing logic or architecture, and accurately assess the impact scope of new requirements. Attached Figure Description

[0009] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the accompanying drawings used in the description of the related technologies or embodiments will be briefly introduced below. Obviously, the drawings described below only show some embodiments of this application and should not be considered as limiting the scope of protection. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0010] Figure 1A This is a schematic diagram illustrating application scenarios for clarifying ambiguous needs provided by some embodiments of this application; Figure 1B This is a schematic diagram illustrating application scenarios for clarifying ambiguous needs provided by other embodiments of this application; Figure 2 These are schematic diagrams of the structure of electronic devices provided in some embodiments of this application; Figure 3A This is a flowchart illustrating a multi-round interactive requirement clarification method based on code awareness and a large language model, provided in some embodiments of this application. Figure 3BThis is a schematic diagram illustrating the results of requirement clarification in some embodiments of this application; Figure 4 This is a schematic diagram illustrating examples of the use of the code search tool in some embodiments of this application; Figure 5 This is a schematic diagram illustrating examples of the use of the code parsing tool in some embodiments of this application; Figure 6 This is a schematic diagram illustrating examples of the use of the code parsing tool in other embodiments of this application; Figure 7 This is a schematic diagram illustrating examples of the use of the configured search tool in some embodiments of this application; Figure 8 This is a schematic diagram illustrating examples of the use of the database query tool in some embodiments of this application; Figure 9 This is a schematic diagram illustrating examples of the use of the code submission query tool in some embodiments of this application. Detailed Implementation

[0011] To make the objectives and advantages of the embodiments of this application more readily understood, 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 a part of the embodiments of this application, and not all of them. The detailed description of the embodiments of this application in the accompanying drawings is not intended to limit the scope of protection claimed by this application, but only represents selected embodiments of this application. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0012] It should be noted that, unless there is a conflict, the various technical features involved in the embodiments of this application described below can be combined with each other, and all are within the protection scope of this application. Furthermore, although functional modules are divided in the device or structural schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device or the order in the flowchart. In addition, the terms "first," "second," "third," and other similar expressions used herein do not limit the data or execution order, but are only for illustrative purposes and to distinguish identical or similar items with substantially the same function and effect, and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features.

[0013] Unless otherwise defined, the technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. It should be understood that the term "and / or" as used in this specification includes any and all combinations of one or more of the listed items.

[0014] In the software development process, requirements gathering and clarification are among the most critical and challenging stages, with many software defects stemming from problems in the requirements phase. When developers receive new requirements, these requirements often suffer from the following issues: 1) Incomplete requirement descriptions: The requester only describes the desired functionality but fails to specify details such as business rules, field constraints, and operation permissions; 2) Lack of system context: Users are unfamiliar with the existing system's implementation, leading to conflicts between the requirements and existing logic or architecture; 3) Unclear scope of impact: New requirements may affect multiple modules, but it is difficult for both users and developers to assess; 4) High communication costs: Traditional requirements clarification requires multiple rounds of manual communication, resulting in low efficiency.

[0015] Currently, the following types of requirement clarification solutions are mainly used and their shortcomings: 1) Template-based requirement documents: Predefined requirement templates (such as user stories and use case documents) are used to collect requirement information through fill-in-the-blank questionnaires. However, they lack code library context, the requirement templates are generic and cannot generate targeted questions based on the actual situation of the existing system, the question list is fixed and cannot be dynamically adjusted according to user answers, making them static and rigid; 2) Rule-based requirement verification: Formal and rule-based methods are used to verify the consistency and completeness of requirements. Requirement conflicts are checked through predefined rules. However, the rule definition is complex, requiring a large number of rules to be defined manually, resulting in high maintenance costs and a lack of flexibility. It can only detect known conflict patterns, cannot handle new scenarios, does not understand the code implementation, and can only verify at the requirement level, unable to be associated with the actual code.

[0016] In summary, new requirements often suffer from incomplete descriptions, potential conflicts with existing logic or architecture, and unclear scope of impact, thus necessitating requirement clarification. However, current technologies often fail to document critical decisions regarding requirement clarification, such as the code used to assess the impact of new requirements, existing logic, and key issues requiring clarification. This amplifies information gaps between product managers, developers, testers, and operations personnel, making it difficult to identify conflicts or contradictions between new requirements and existing logic or architecture, and hindering the assessment of the new requirements' impact.

[0017] This application proposes a CARC (Code-Aware Requirement Clarification) mechanism. Utilizing target information from the source code of the target project, it reveals scattered, implicit, and untraceable key decisions in the initial requirement information, clarifying these key decisions into traceable requirement clarification results. Compared to analysis methods that only examine the requirement text, the CARC mechanism is more capable of exposing key details that must be confirmed before requirement implementation. Compared to methods that directly generate clarification results by simply examining the source code, CARC, through requirement clarification interaction, accurately understands the user's requirement intent, improving the completeness and executability of requirement analysis results. It can accurately identify contradictions between new requirements and existing logic or architecture, and precisely assess the impact scope of new requirements.

[0018] Please see Figure 1A , Figure 1A The illustration shows application scenarios for clarifying ambiguous needs provided by some embodiments of this application.

[0019] like Figure 1A As shown, this application scenario includes electronic device 100, which can be any suitable device or apparatus such as a laptop, desktop computer, tablet computer, all-in-one computer, microcontroller, FPGA chip, etc. Figure 1A The electronic device 100 shown is a laptop computer.

[0020] Specifically, the electronic device 100 is equipped with a detection tool for detecting new request submissions. The electronic device 100 uses the detection tool to detect whether the user has submitted or entered a new request, and obtains a detection result. The detection result is used to indicate whether the user has submitted / entered or not submitted / entered a new request. The detection result includes a first result and a second result, wherein the first result indicates that the user has submitted / entered a new request, and the second result indicates that the user has not submitted / entered a new request.

[0021] In some embodiments, the electronic device 100 uses a detection tool to detect when a user submits or inputs a new request, and creates a reference session based on the new request. The reference session includes a dialogue history that stores the initial request information. The electronic device 100 calls a large language model to generate targeted clarification questions and request clarification results based on the reference session, and the user inputs answers to the clarification questions based on the reference session.

[0022] Specifically, when fuzzy initial requirement information about a target project is detected and submitted, the electronic device 100 parses the initial requirement information and creates a reference session. The reference session includes at least the target project's identifier and dialogue history, and the initial requirement information is saved to the reference session. The target project can be any suitable project in the software development process. In this embodiment, the electronic device 100 is configured with a large language model. This embodiment calls the large language model to determine the target tool based on the dialogue history and returns a calling instruction for the target tool. Based on the calling instruction, this embodiment calls the target tool to obtain target information from the target project's source code.

[0023] In this embodiment, the source code of the target project is stored in the local storage of the electronic device 100. The electronic device 100 invokes the target tool to obtain target information (including at least one of code information, code call chain information, configuration information, and database information) from the source code of the target project stored in the local storage. In other embodiments, the source code of the target project is stored in any other suitable system, device, or apparatus, and the electronic device 100 communicates with the system, device, or apparatus via a network. When it detects that a user has submitted or entered initial requirement information about the target project, the electronic device 100 sends a notification instruction to the system, device, or apparatus via the network, causing the system, device, or apparatus to search for the source code of the target project, and the electronic device 100 obtains the source code of the target project from the system, device, or apparatus. For example, see... Figure 1B As shown, server 200 stores the source code of the target project. Electronic device 100 communicates with server 200 via network. After server 200 receives notification instructions and finds the source code of the target project, electronic device 100 obtains the source code of the target project from server 200. Alternatively, server 200 actively sends the source code of the target project to electronic device 100 via network and then calls the target tool to obtain target information from the source code of the target project.

[0024] For example, in this embodiment of the application, a large language model is invoked to generate a clarification question based on the target information and the dialogue history, and the clarification question is presented in a reference session. Of course, the large language model can be configured in any other suitable system, device, or apparatus; see [reference]. Figure 1B As shown, the large language model is configured on server 200. In this embodiment of the application, the large language model configured on server 200 is called to generate a clarification question based on the target information and the dialogue history, and the clarification question is presented in the reference session.

[0025] For example, after generating and presenting a clarification question, the user's response to the clarification question in the reference session (i.e., the answer content) is updated to the dialogue history in this embodiment of the application, and it is determined whether the clarification completion condition is met. Specifically, if the clarification completion condition is not met, the large language model is invoked to generate a clarification question based on the target information and the dialogue history, and the clarification question is presented in the reference session. If the clarification completion condition is met, the large language model is invoked to generate a clarification result based on the target information and the dialogue history, and the clarification result is presented in the reference session. In this way, by utilizing the target information in the source code of the target project, combined with the requirement text, contradictions between new requirements and existing logic or architecture can be accurately identified, and the impact scope of new requirements can be precisely assessed.

[0026] It should be understood that, Figure 1A and Figure 1B The illustrated embodiments are merely illustrative of situations where electronic device 100 clarifies ambiguous requirements in some embodiments of this application, and do not limit the structure, type, or number of electronic devices in other embodiments. In other embodiments, the electronic device may also include... Figure 1A or Figure 1B The laptop shown has more or fewer components, or has the same... Figure 1A or Figure 1B The laptops shown have different configurations.

[0027] To facilitate understanding of the multi-round interactive requirement clarification method based on code awareness and large language model provided in the embodiments of this application, the electronic device provided in the embodiments of this application will first be described in detail.

[0028] Please see Figure 2 , Figure 2 The schematic diagram illustrates the structure of an electronic device provided in some embodiments of this application.

[0029] See Figure 2 As shown, the electronic device 100 includes at least one processor 110 and at least one memory 120 connected in communication. Figure 2 Taking a bus system 130, a processor 110, and a memory 120 as an example, the various components of the electronic device 100 are coupled together through the bus system 130, which is used to realize the connection and communication between the various components. It is easy to understand that the bus system 130 may include, in addition to the data bus, a power bus, a control bus, and a status signal bus, etc. However, for the sake of clarity and brevity, in... Figure 2 The general labels all buses as Bus System 130. This is understandable. Figure 2The structures shown in the embodiments are merely illustrative and do not limit the structure of the electronic device described above. For example, the electronic device may also include components that are more... Figure 2 The structure shown has more or fewer components, or has the same as Figure 2 The diagram shows different configurations of the structure.

[0030] Specifically, processor 110 provides computational and control capabilities to support electronic device 100 in executing corresponding business logic and functions. For example, it supports electronic device 100 in executing the multi-round interactive requirement clarification method based on code awareness and a large language model provided in this application embodiment, or in executing steps in any possible implementation of the multi-round interactive requirement clarification method based on code awareness and a large language model provided in this application embodiment. Those skilled in the art will understand that processor 110 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc., or it can be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0031] The memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, instructions, and modules, such as the programs, instructions, and modules corresponding to the multi-turn interactive requirement clarification method based on code awareness and a large language model in the embodiments of this application. In some embodiments, the memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system, applications required for at least one function, and the data storage area may store data created according to the use of the processor 110. The processor 110 executes various functional applications and data processing of the electronic device 100 by running the non-transitory software programs, instructions, and modules stored in the memory 120, thereby implementing the multi-turn interactive requirement clarification method based on code awareness and a large language model provided in the embodiments of this application, or executing the steps in any possible implementation of the multi-turn interactive requirement clarification method based on code awareness and a large language model provided in the embodiments of this application. In some embodiments, the memory 120 may include high-speed random access memory and may also include non-transitory memory. For example, at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 120 may further include memory remotely configured relative to the processor 110, which can be connected to the processor 110 via a communication network. It is understood that examples of such communication networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0032] As can be understood from the above, the implementing entity of the multi-turn interactive requirement clarification method based on code awareness and a large language model provided in this application embodiment can be any suitable type of electronic device with certain computing and control capabilities, such as the aforementioned electronic device 100. In some feasible implementations, the multi-turn interactive requirement clarification method based on code awareness and a large language model provided in this application embodiment can be implemented by a processor executing computer program instructions stored in memory.

[0033] The following will describe in detail the multi-round interactive requirement clarification method based on code awareness and a large language model provided in the embodiments of this application, with reference to exemplary applications and implementations of the electronic devices provided in the embodiments of this application.

[0034] Understandably, the multi-turn interactive requirement clarification method based on code awareness and a large language model provided in this application embodiment can be applied to the aforementioned electronic device (e.g., electronic device 100). Specifically, the execution entity of the multi-turn interactive requirement clarification method based on code awareness and a large language model is one or at least two processors of the electronic device.

[0035] Please see Figure 3AIn this embodiment of the application, steps S1 to S8 are used to clarify ambiguous requirements.

[0036] Step S1: In response to the user's input of initial requirements information about the target project, create a reference session.

[0037] In this embodiment, the initial requirement information is fuzzy, and the reference session includes at least the dialogue history and the identifier of the target project. The dialogue history stores the initial requirement information. The target project can be any suitable project in the software development process.

[0038] For example, in this application embodiment, the user inputs initial requirement information about the target project through a front-end input component or interface service. Preprocessing operations are performed on the initial requirement information (such as removing invalid characters and noise information, performing word segmentation and semantic parsing, extracting requirement keywords, functional intents and constraint information, etc.). Based on a preset requirement data structure, the initial requirement information is structured and encapsulated to generate a standardized requirement object. The standardized requirement object includes requirement text, keywords, intent tags, etc.

[0039] For example, in this embodiment of the application, a session management component is invoked to create a reference session, generating a unique session identifier (SessionID) for the reference session, and recording the session creation time, user identifier, and source information. The unique session identifier (SessionID) is used to identify the reference session. Based on standardized requirement objects, an initial session context is constructed. The initial session context includes the initial requirement content (i.e., the original text of the initial requirement information), the requirement parsing results (including keywords, intents, etc.), and the current interaction round (initialized to round 1). A session context storage structure (such as a memory object or a persistent storage record) is created to obtain the reference session context.

[0040] In some embodiments, the target project information corresponding to the initial requirement information currently input by the user is obtained, the target project information is associated and bound with the reference session, and the basic index information of the target project (such as code index and module division information) is loaded for subsequent information acquisition.

[0041] Step S2: Invoke the preset large language model to determine the target tool based on the dialogue history, and return the invocation instructions for the target tool.

[0042] In this embodiment, a variety of query tools for source code are provided in advance, and the target tool includes any one or more of the preset query tools.

[0043] In this embodiment, the target tool includes at least one of a code search tool, a code parsing tool, a configuration search tool, and a database query tool.

[0044] For example, in this embodiment of the application, a language model is invoked to parse the initial requirement information in the dialogue history to obtain the requirement parsing result. The requirement parsing result includes a set of requirement keywords, functional intent tags, and business object identifiers (such as module names, table names, interface names, etc.) involved in the initial requirement information. Based on the requirement parsing result, the target information to be queried and obtained (such as data tables, code call information, etc.) is determined, and one or more query tools required to obtain the target information are identified as target tools. A call instruction for the target tool is generated based on the target tool, and the call instruction for the target tool is returned to the electronic device.

[0045] Step S3: Based on the invocation command, invoke the target tool to obtain target information from the source code of the target project.

[0046] In this application's embodiments, the target information includes at least one of code information, code call chain information, configuration information, and database information. For example, in some embodiments, the target information includes database information and code call chain information. In other embodiments, the target information includes code information and configuration information.

[0047] For example, in this embodiment of the application, a call instruction for a target tool is received from a large language model, the call instruction is parsed, the name or type of the target tool is extracted, the target tool is determined from a variety of preset query tools based on the name or type of the target tool, and the target tool is called to query and obtain the target information from the source code of the target project.

[0048] The code information includes class information (such as class name), method information (such as method name and method type), and field information (such as interface and implementation class). The code call chain information includes the call chains of methods, interfaces, and services in the target project's source code; for example, method call chains include forward, reverse, and bidirectional call chains. Configuration information includes runtime environment configurations (such as interface routing and service registration information) and runtime parameter configurations (such as switches, thresholds, and paths). Database information includes information about the tables in the database, including table structure, table fields, and table indexes.

[0049] In this embodiment, reference data is written to the reference session context, and the association between the reference data and the initial requirement information is established for subsequent large language model calls.

[0050] Step S4: Invoke the large language model to generate clarification questions based on the target information and dialogue history, and present the clarification questions in the reference conversation.

[0051] For example, in this embodiment of the application, the dialogue history (including initial requirement information) and the acquired target information are used as model input data. Based on the model input data, a first prompt word is constructed to drive the large language model to generate clarification questions. The first prompt word includes role definition information (used to specify the model role as "requirement analysis and clarification expert"), task description information (used to instruct the model to generate targeted clarification questions for unclear, incomplete, or ambiguous parts of the initial requirement information), constraint rule information (i.e., the clarification questions should be clearly targeted, avoid repeated questioning, and prioritize the coverage of functional logic, parameter constraints, data sources, and boundary conditions), and context information (including initial requirement information, dialogue history, and code submission information (if any)).

[0052] For example, the first prompt word is input into a preset large language model, causing the large language model to perform inference generation operations and output a set of candidate clarification questions. The set of candidate clarification questions includes at least one clarification question. This embodiment of the application obtains the set of candidate clarification questions output by the model, performs format normalization processing on the candidate clarification questions (including standardizing question expressions, removing redundant or duplicate questions, etc.), and filters the normalized clarification questions according to screening conditions (e.g., relevance to initial requirement information, whether it covers key uncertain information points, etc.), selecting the clarification questions that best meet the screening conditions. The selected clarification questions are written to the dialogue history of the reference session, and the reference session state parameters are updated (e.g., the current clarification round is incremented by 1 and the current stage is marked as "awaiting user response"). Finally, the clarification questions are presented in the reference session through a front-end interface or interactive interface to display the clarification questions to the user, and optionally, example answer hints, default options, etc., are provided for each question.

[0053] Step S5: Respond to the user's input regarding the clarification question and update the response to the conversation history.

[0054] For example, after a user enters an answer to a clarification question in a reference session, this embodiment of the application obtains the user's input answer to the clarification question and updates the answer to the dialogue history of the reference session.

[0055] Step S6: If the response does not meet the requirement clarification completion condition, repeat steps S2 to S5.

[0056] The conditions for completing the requirement clarification include that all preset requirement slots have been filled, the user has voluntarily ended the process, and no new key information has been added for several consecutive rounds.

[0057] For example, in this embodiment of the application, it is determined in real time whether the requirement clarification completion condition is met. If the preset requirement slots in the reference session are not all filled, and the user has not actively ended the reference session, and the situation of no new key information being added in multiple consecutive rounds in the reference session has not been met, it means that the requirement clarification completion condition has not been met, and the aforementioned steps S2 to S5 are continuously executed in a loop to continue to perform the requirement clarification operation to clarify the initial requirement information.

[0058] Step S7: In response to the fulfillment of the clarification conditions, the large language model is invoked to generate the clarification result based on the target information and dialogue history.

[0059] If all the preset requirement slots in the reference session are filled, or the user actively ends the reference session, or no new key information is added in multiple consecutive rounds of the reference session, then the requirement clarification completion condition is met. The large language model is then invoked to generate the requirement clarification result based on the target information and the dialogue history.

[0060] For example, the process of generating requirement clarification results is as follows: 1) Extract requirement information (including initial requirement information and complete requirement description after fusion of multiple rounds of responses, etc.) and historical interaction information (such as clarification questions and corresponding answer content), target information, etc. from the dialogue history as multi-source fusion input data, and construct a second prompt word based on the multi-source fusion input data. Among them, the second prompt word includes role definition information (used to specify the model role as "requirement analysis and clarification result generation expert"), task description information (used to instruct the model to perform structured clarification of initial requirement information and answer content, and output clear, complete and unambiguous requirement description), constraint rule information (that is, the requirement clarification result should at least include functional description, input and output definition, business processing logic, parameter constraints, exception handling and boundary conditions, etc.), and context information (including initial requirement information, dialogue history and code submission information (if any), etc.) to obtain the second prompt word for generating requirement clarification results. 2) Input the second prompt word into the large language model so that the large language model performs inference generation operation to obtain the initial requirement clarification result. This application embodiment obtains the initial requirement clarification result, performs consistency verification on the initial requirement clarification result (including consistency with the initial requirement information and the answer content (such as whether it fully covers the user's expressed requirements) and consistency with the target information (such as whether it conforms to the existing code implementation logic and whether it violates configuration or database constraints)), organizes the requirement clarification result that has passed the verification according to a preset structure (including functional module division, interface definition, data structure description and processing flow description, etc.) to obtain the organized requirement clarification result, and performs structured expression processing on the organized requirement clarification result (such as unifying the sentence and paragraph expression form, removing redundant or repeated words, etc.) to obtain the structured requirement clarification result.

[0061] In this embodiment, key information is marked in the structured requirement clarification result based on marking conditions (such as relevance to initial requirement information, followed design logic, etc.), resulting in a marked requirement clarification result. The marked requirement clarification result is written to the dialogue history of the reference session, the reference session state parameters are updated (e.g., the current clarification round is incremented by 1 and the current stage status is marked as "requirement clarification completed"), the final requirement information version is recorded, and the requirement clarification process is terminated or frozen. Finally, the requirement clarification result is presented in the reference session through a front-end interface or interactive interface to display the requirement clarification result to the user.

[0062] Step S8: Present the clarification results of the requirements in the reference session.

[0063] For example, in this application embodiment, the structured requirements clarification results are converted into data structures that can be rendered by the front end (such as modular display structures and segmented text structures). Through the front end interface or interactive interface, the data structures that can be rendered by the front end are rendered into user-visible content, and the user-visible content is presented in the reference session, thereby realizing the display of requirements clarification results to the user.

[0064] For example, please see Figure 3B , Figure 3B A schematic diagram of the results of the requirements clarification is shown. Figure 3B The requirements clarification results clearly and in detail explain the background of the requirements, the functional overview, the functional requirements and the business process diagram. Developers can efficiently and accurately carry out code development work based on the complete and executable requirements clarification results, which are in line with the existing code logic and architecture.

[0065] This application proposes a CARC (Code-Aware Requirement Clarification) mechanism. Utilizing target information from the source code of the target project, it reveals scattered, implicit, and untraceable key decisions in the initial requirement information and clarifies these key decisions into traceable requirement clarification results. Compared to analysis methods that only examine the requirement text, the CARC mechanism is more capable of exposing key details that must be confirmed before requirement implementation. Compared to methods that directly generate clarification results by simply examining the source code, CARC, through requirement clarification interaction, accurately understands the user's requirement intent, significantly improving the completeness and executability of requirement analysis results. It can accurately identify contradictions between new requirements and existing logic or architecture and precisely assess the impact scope of new requirements.

[0066] For example, in this embodiment of the application, steps S31 to S36 are used to realize the purpose of calling the target tool to obtain target information from the source code of the target project based on the calling instruction.

[0067] Step S31: According to the command to call the code search tool, call the code search tool to search for code information in the source code of the target project.

[0068] For example, in this embodiment of the application, after receiving the invocation instruction for the code search tool returned by the large language model, the query tool to be invoked is determined to be the code search tool based on the invocation instruction. The code search tool is then invoked to perform a search operation in the source code of the target project to obtain the code information in the source code of the target project. It can be understood that the code search tool performs the search based on information such as keywords, interface identifiers or method names and / or class names or module identifiers from the initial requirement information.

[0069] For example, the code search tool is SEARCH_FILE, which supports full-text keyword search (directly searching all files in the project for keyword matching), regular expression search (including exact query mode and regular expression query mode), viewing by specified line number (single or multiple lines, using a line number positioning algorithm (retrieving code by line number)), and contextual code display. It is suitable for searching annotation content (such as @PostMapping), searching code snippets, viewing code near specified line numbers, and complex regular expression matching. See also... Figure 4 As shown, Figure 4 The image 'a' shows some usage examples of the SEARCH_FILE tool. Figure 4 b illustrates the use of the keyword search function of the SEARCH_FILE tool to search for, for example... Figure 4 Example of using the keyword "verifySignature" within rectangle 41 shown.

[0070] Step S32: According to the call instructions for the code parsing tool, call the code parsing tool to parse the source code of the target project to obtain code call chain information.

[0071] For example, in this embodiment of the application, after receiving the call instruction for the code parsing tool returned by the large language model, the query tool to be called is determined to be the code parsing tool according to the call instruction for the code parsing tool, and the code parsing tool is called to parse the source code of the target project to obtain the code call chain information in the source code of the target project.

[0072] For example, code analysis tools include the VIEW_METHOD tool and the TRACE_CALL_CHAIN ​​tool. The VIEW_METHOD tool supports viewing the complete implementation code of a method, viewing the Javadoc comments of a method, viewing the method call relationship (based on the parsed data structure implementation), supporting deep call chain tracing (specifying the number of levels for recursive call chain tracing), and viewing the entire class (optional summary or full mode). It supports class-level and method-level viewing; in summary mode, it displays all method names of the class, and in full mode, it displays all the code of the class. It is suitable for scenarios such as quickly viewing method implementations, understanding method call relationships, and deeply analyzing business logic. See also... Figure 5 As shown, Figure 5 The diagram in 'c' illustrates some usage examples of the VIEW_METHOD tool. Figure 5 The diagram in 'd' schematically illustrates the complete implementation code of the viewing method using the VIEW_METHOD tool, showing the functionality of viewing such... Figure 5 Example of using the method "createOrder" within rectangle 51 shown.

[0073] The TRACE_CALL_CHAIN ​​tool supports forward tracing (identifying which methods a given method calls), backward tracing (identifying which methods a given method calls), bidirectional full tracing (containing both which methods a given method calls and which methods call it), and extracting the context code of the call point: extracting the N lines before the call point, the call line, and the M lines after the call point. The TRACE_CALL_CHAIN ​​tool employs code indexing, a bidirectional call relationship graph (calledMethods and calledBy), an interface-implementation mapping table, and code extraction algorithms, making it suitable for scenarios such as analyzing business processes, tracing dependencies, impact analysis, and understanding the context of call points. Please refer to [link to relevant documentation]. Figure 6 , Figure 6 The 'e' in the figure shows some usage examples of the TRACE_CALL_CHAIN ​​tool. Figure 6 The diagram in f schematically illustrates the reverse tracing function of the TRACE_CALL_CHAIN ​​tool for tracing such... Figure 6 Example of the call chain for the method "updateStatus" within rectangle 61 shown.

[0074] Step S33: According to the instruction to call the configuration search tool, call the configuration search tool to search for configuration files in the source code of the target project.

[0075] Step S34: Parse the configuration file and extract the interface configuration and data source configuration from the configuration file as configuration information.

[0076] For example, in this embodiment of the application, after receiving the invocation instruction for the configuration search tool returned by the large language model, the query tool to be invoked is determined to be the configuration search tool based on the invocation instruction. The configuration search tool is then invoked to perform a configuration search operation in the source code of the target project, obtaining the configuration files and file information in the source code of the target project. The file information includes the configuration reference path of the code, configuration file naming matching, and framework convention paths (such as resource directories).

[0077] For example, in this application embodiment, a structured parsing method (such as XML, YAML, JSON parsing) is used to parse the configuration file, extracting interface configuration (such as interface path, request method and parameter definition), data source configuration (such as database connection information, data source identifier), etc. from the configuration file, and performing structured processing on the extracted interface configuration and data source configuration to obtain configuration information.

[0078] For example, the configuration search tool is named SEARCH_CONFIG, which supports searching configuration files such as YML, YAML, Properties, and XML, and also supports searching for configuration item names and values. The SEARCH_CONFIG tool is based on recognizing configuration file extensions (such as .yml, .yaml, .properties, .xml, etc.) and configuration file names (such as application, bootstrap, config, pom), making it suitable for scenarios such as finding database configurations, Redis / MQ configurations, and port, path, and other configuration items. Please refer to [link to relevant documentation]. Figure 7 As shown, Figure 7 The 'g' in the figure shows some usage examples of the SEARCH_CONFIG tool. Figure 7 The 'h' symbol illustrates the use of the SEARCH_CONFIG tool's search function for searching YML configuration files. Figure 7 Example of using the "payment" configuration within rectangle 71 shown.

[0079] Step S35: According to the instruction to call the database query tool, call the database query tool to query the data tables in the database of the target project.

[0080] Step S36: Parse the data table and extract the field comments, data types, and structural indexes from the data table as database information.

[0081] For example, after receiving the call instruction for the database query tool returned by the large language model, this application embodiment determines that the query tool to be called is the database query tool according to the call instruction, calls the database query tool to perform a query operation in the target project, and obtains the data table of the database in the target project.

[0082] For example, in this embodiment of the application, a parsing operation is performed on the data tables of the database in the target project to obtain the table structure information, and the field comments (used to represent business semantics), data types, and structural indexes (including primary keys, unique indexes, and ordinary indexes) in the table structure information are extracted as database information.

[0083] For example, the database query tool is called DATABASE, which supports functions such as querying all tables in a database, querying table structure, and querying table data. DATABASE uses JDBC-based database connections and SQL security checks (disallowing dangerous operations such as DELETE, UPDATE, INSERT, and DROP), making it suitable for scenarios such as viewing data tables, viewing table structure, and querying table data in a database. Please refer to [link to relevant documentation]. Figure 8 , Figure 8 The 'i' in the diagram illustrates some usage examples of the DATABASE tool. Figure 8 The 'j' symbol illustrates how to query table data using the DATABASE tool. Figure 8 The example shown is of the data table "t_order" within rectangle 81.

[0084] For example, in this embodiment of the application, steps S37 to S38 are used to realize the purpose of calling the target tool to obtain target information from the source code of the target project based on the calling instruction.

[0085] Step S37: According to the call instruction for the code submission query tool, call the code submission query tool to query the historical change data, historical submission data and historical defect data of the target project's source code.

[0086] Step S38: Extract the code data, time and modifier of each modification from the historical change data, the code data and author of each submission from the historical submission data, and the defect, time and fixer of each fix from the historical defect data as code submission history information.

[0087] In this embodiment, the target tool also includes a code submission query tool, and the target information also includes code submission history information.

[0088] For example, after receiving the invocation instruction for the code submission query tool returned by the large language model, this application embodiment determines that the query tool to be invoked is the code submission query tool based on the invocation instruction. This application embodiment determines the query scope of the code submission history based on the source code of the target project (such as code repository identifier, target branch or version range, file path or module identifier corresponding to the source code of the target project), thus obtaining the historical data query scope. The code submission query tool is invoked to obtain the code submission history data within the query scope. The code submission history data includes historical change data (used to characterize the differences between different versions of the code), historical submission data (used to characterize the code meta-information of each submission operation), and historical defect data (used to characterize defect records and repair status related to the source code).

[0089] For example, in this embodiment of the application, code differences corresponding to each change (including the modified code data, time, and modifier), files and modules involved in the change, etc., are extracted from historical change data to obtain a subset of change records. Code data, commit summary information, commit time, commit author, and commit instructions (e.g., commit notes) corresponding to each commit are extracted from historical commit data to obtain a subset of commit records. Problem description, defect type (e.g., functional defect and performance defect), fix time, fixer, associated code file, and commit record are extracted from historical defect data to obtain a subset of defect records.

[0090] For example, based on time, file path, or commit identifier, subsets of change records, commit records, and defect records are associated to obtain associated historical data. The associated historical data is then sorted chronologically to construct a code evolution time series, resulting in a code evolution sequence. This code evolution sequence is then structured to generate code commit history information, which includes change dimension information (such as modified code data, modifier, and modification time), commit dimension information (including submitted code data, commit author, and commit description), defect dimension information (such as fixed defects, defect descriptions, fix times, and fixers), and association information (i.e., commit-change-defect mapping relationships). This code commit history information is then fused with at least one of the following: code information, code call chain information, configuration information, and database information, to obtain the target information.

[0091] For example, the code commit query tool is GIT_DIFF, which supports functions such as viewing commit history, commit details, code differences, file modification records, searching commit information, and viewing author commit records. GIT_DIFF is implemented by executing Git commands and parsing Git output through ProcessBuilder, and is suitable for scenarios such as viewing code change history, tracking defect fixes, and analyzing code evolution. See also... Figure 9 , Figure 9 The 'k' in the diagram illustrates some usage examples of the GIT_DIFF tool. Figure 9 The 'm' in the diagram illustrates how to view the commit history using the GIT_DIFF tool, such as... Figure 9 Example of using the "payment" item within rectangle 91 shown.

[0092] In some embodiments, this application implements step S41 to call a large language model to generate a clarification question based on target information and dialogue history, and present the clarification question in a reference session.

[0093] Step S41: Send the target information and dialogue history to the large language model so that the large language model can perform clarification detection operations on the initial demand information or the initial demand information and the answer content based on the target information, obtain the set of items to be clarified, and generate a structured clarification question based on the set of items to be clarified.

[0094] In this embodiment, the dialogue history includes initial request information, or initial request information and response content. It is understood that when a clarification question is first generated, since the user has not responded to the clarification question, the dialogue history only contains the initial request information and does not include the response content. In subsequent clarification questions, since the user has responded to the clarification question and the response content is updated to the dialogue history, the dialogue history includes both the initial request information and the response content.

[0095] The clarification and detection operation includes ambiguity detection, missing constraint identification, and consistency analysis. The set of items to be clarified includes any one or more of the following: missing parameter items, ambiguous object items, undetermined data range items, undetermined execution condition items, and constraint conflict items.

[0096] For example, the target information and dialogue history are sent to the large language model. When a clarification question is generated for the first time, the large language model performs a clarification detection operation on the initial requirement information, analyzes the matching relationship between the initial requirement information and the target information, and identifies the explicit and implicit information (such as missing parameters, undefined business rules, ambiguous data ranges or conditions) in the initial requirement information. Based on the implicit information, a set of items to be clarified is generated. In subsequent clarification question generation processes, the large language model performs a clarification detection operation on the initial requirement information and the response content, analyzes the matching relationship between the initial requirement information, the response content, and the target information, and identifies the explicit and implicit information (such as missing parameters, undefined business rules, ambiguous data ranges or conditions) in the initial requirement information and the response content. Based on the implicit information, a set of items to be clarified is generated.

[0097] For example, the large language model, based on rule generation mechanisms (such as generating completion questions for "missing parameter items," decision questions for "ambiguous object items," and confirmation questions for "constraint conflict items"), analyzes and extracts information from each item in the set of items to be clarified, generating multiple candidate clarification questions in a structured format. The candidate clarification questions are then filtered, such as removing duplicate or semantically similar questions, and removing questions that can be directly deduced from the target information, resulting in filtered candidate clarification questions. Based on their contribution to improving the clarity of the required information and the degree of information loss, the filtered candidate clarification questions are ranked, and the first clarification question among the ranked candidate clarification questions is selected as the final clarification question. The final clarification question is then output to the reference session for display.

[0098] In some embodiments, the structured format includes fields such as a unique identifier for the question, the question content, the question type (e.g., completion, decision, or confirmation), associated information (e.g., associated functional modules or data fields), and the input method (e.g., text input and option selection). For example, embodiments of this application use a JSON array format to represent clarification questions; that is, the structured format is a JSON array format, and the clarification questions in the structured format are presented in JSON array format.

[0099] The JSON array format is specifically designed as follows: question type design, required field definition, mandatory option design, default value strategy, and format markup convention.

[0100] 1. Question type design: Supports three question types to adapt to different scenarios.

[0101] a. Single choice (radio): Used in scenarios where you have to choose one of two or more options, such as "Is this required?" or "Which method should I use?".

[0102] b. Multiple choice (checkbox): Used in scenarios where multiple options can be selected simultaneously, such as "What operations need to be supported?".

[0103] c. Input box: Used in scenarios where users need to input freely, such as "Please describe the specific business rules".

[0104] 2. Required field definitions: Each question must include fields such as identifier, content, description, and options.

[0105] a.id: A unique identifier for the question, used to associate it with a user's answer.

[0106] b. question: The main content of the question, concise and clear.

[0107] c. description: A detailed explanation of the question, explaining why this question was asked.

[0108] d.option: An array of options, required for single-choice and multiple-choice questions.

[0109] e.default: The default option, which provides recommendations based on best practices or existing system designs.

[0110] f.type: Problem type identifier.

[0111] 3. Mandatory Option Design: To avoid omissions, the option array for both single-choice and multiple-choice questions must include two options: "Not involved" and "Other". This way, even if the options listed by the large language model are incomplete, users can provide supplementary information using the "Other" option.

[0112] 4. Default Value Strategy: Based on analysis of existing code, configuration, and database, provide intelligent default options for each problem. For example, if the existing system design uses logical deletion, the default suggestion for new features is also logical deletion to maintain consistency.

[0113] 5. Formatting Conventions: The clarification questions generated by the large language model are wrapped in the special marker "[ASK_QUESTION:…]" to facilitate system identification and extraction. This special marker is similar to the tool call marker "[TOOL_CALL:…]" in the previous embodiment, forming a unified instruction format system.

[0114] The following is a brief description of the clarification questions presented in JSON array format.

[0115] Example of a multiple-choice question: {"id":"q1","question":"Is the nickname field required?","description":"The requirement does not explicitly state whether the nickname field is required","option":["Required","Optional","Not applicable","Other"]","default":"Required","type":"radio"}.

[0116] Example of a multiple-choice question: {"id":"q2","question":"What operations need to be supported?","description":"Please select the operation type you need to support","option":["Add","Modify","Delete","Query","Not involved","Other"]","default":["Add","Query"]","type":"checkbox"}.

[0117] In some implementations, the embodiments of this application achieve the presentation of clarification issues in the reference session through steps S42 to S43.

[0118] Step S42: Parse the structured format clarification question and extract one or more first field contents from the structured format clarification question.

[0119] Step S43: Render and display the contents of one or more first fields in the reference session.

[0120] For example, this application embodiment, based on the structured format of the clarification question, performs localized parsing on the structured format clarification question and extracts one or more first field contents from the structured format clarification question. For example, the parsing extracts the first field contents of the clarification question in the aforementioned embodiment: "Is the nickname field required?", "The requirement does not explicitly state the requirement for the nickname field to be required", etc.

[0121] For example, in this embodiment of the application, based on the relevance of one or more extracted first field contents (such as the relevance between the clarification question and the optional answer item) and the presentation order (such as the requirement content being presented first, the specific question being presented second, and the optional answer item being presented last), one or more extracted first field contents are written into the dialogue history of the reference session, and one or more first field contents are rendered and displayed in the reference session through the user interface rendering engine, thereby realizing the presentation of the clarification question in the reference session.

[0122] In some embodiments, the present application implements step S71 to call a large language model to generate a requirement clarification result based on target information and dialogue history.

[0123] Step S71: Send the target information and dialogue history to the large language model, so that the large language model can perform analysis and extraction operations on the target information and dialogue history to obtain reference information, and generate a structured format requirement clarification result based on the reference information.

[0124] In this embodiment, the dialogue history includes initial request information and response content. It should be understood that, after the aforementioned steps, the user must have entered a response to the clarification question, and the response content has been updated to the dialogue history; therefore, the dialogue history includes initial request information and response content.

[0125] For example, the target information and dialogue history are sent to a large language model. The large language model performs semantic analysis and information extraction on the target information and dialogue history, extracting functional goals, inputs and outputs, and business rules. It matches the requirement information (including initial requirement information and response content) with the target information, identifies reusable design logic, and extracts data structures, field meanings, and constraints related to the requirement information to obtain reference information. Furthermore, the reference information is organized into structured data, including functional element information, interface and parameter information, data structure and constraint information, and processing logic information, resulting in structured reference information.

[0126] For example, after obtaining the reference information, this application embodiment enters the process of generating requirement clarification results as described above, and generates requirement clarification results in a structured format based on the reference information.

[0127] In some embodiments, the structured format includes fields such as a unique identifier for the result, result content (e.g., background information and functional overview), result type, and associated information (e.g., associated functional modules or data fields). For example, embodiments of this application use a JSON array format to represent the requirement clarification result; that is, the structured format is a JSON array format, and the requirement clarification result in the structured format is presented in JSON array format.

[0128] In some implementations, the embodiments of this application achieve the presentation of the requirements clarification results in the reference session through steps S81 to S82.

[0129] Step S81: Parse the structured format requirements clarification results and extract one or more second field contents from the structured format requirements clarification results.

[0130] Step S82: Render and display the content of one or more second fields in the reference session.

[0131] For example, in this embodiment of the application, based on the structured format of the requirements clarification result, the requirements clarification result in a structured format is parsed locally to extract one or more second field contents from the requirements clarification result in the structured format. For example, the parsed and extracted... Figure 3B The second field in the required clarification results shows: "Requirement Background", "The existing system lacks a customer information maintenance entry point, and it is necessary to support adding new customers and ensure the uniqueness of mobile phone numbers to avoid duplicate entry", etc.

[0132] For example, embodiments of this application determine the relevance of one or more extracted second field contents (e.g., the relevance between the requirement background and the corresponding description content) and the presentation order (e.g.) Figure 3B The requirement background is presented first, followed by the functional overview, and finally the business process diagram. One or more extracted second field contents are written into the dialogue history of the reference session. Through the user interface rendering engine, one or more second field contents are rendered and displayed in the reference session, thereby realizing the presentation of the requirement clarification results in the reference session.

[0133] In some embodiments, the multi-round interactive requirement clarification method based on code awareness and a large language model provided in this application further includes step S83.

[0134] Step S83: In response to a reference duration being greater than or equal to a preset duration threshold, delete the reference session to release the memory resources occupied by the reference session.

[0135] In this embodiment, the reference duration is the interval between the current system time and the last access time of the reference session. It can be understood that the current system time refers to the real-time time of the device, apparatus, or system. The duration threshold is a custom setting by engineers based on experimental data and historical experience, such as a duration threshold of 30 minutes, 45 minutes, or other durations.

[0136] Specifically, in this embodiment, when a reference session is created, the creation time of the reference session is recorded. Each time the reference session is accessed, the last access time of the reference session is updated and stored in the session management module. The current system time is obtained, and a reference duration is calculated based on the current system time and the last access time of the reference session. Equal to the current system time With last visit time The difference, that is: Reference duration The reference session is compared with a preset duration threshold. If the reference duration is greater than or equal to the threshold, the reference session is determined to be an expired session. Before deleting the reference session, key session data (including requirement clarification results, historical interaction records, etc.) is persistently stored in a database or log system. A status check is performed on the reference session to determine if there are any ongoing interactions or if it is referenced by other tasks. When the reference session is in a dormant state, it is deleted from memory or the cache system (including session context data, interaction records, and status parameters, etc.), thereby releasing the memory resources occupied by the reference session.

[0137] In summary, this application proposes a CARC (Code-Aware Requirement Clarification) mechanism. This mechanism utilizes target information from the source code of the target project to reveal scattered, implicit, and untraceable key decisions in the initial requirement information, and clarifies these key decisions into traceable requirement clarification results. Compared to analysis methods that only examine the requirement text, the CARC mechanism is more capable of exposing key details that must be confirmed before requirement implementation. Compared to methods that directly generate clarification results by simply examining the source code, CARC, through requirement clarification interaction, accurately understands the user's requirement intent, improves the completeness and executability of requirement analysis results, accurately identifies contradictions between new requirements and existing logic or architecture, and precisely assesses the impact scope of new requirements.

[0138] This application provides a computer-readable storage medium storing processor-executable computer program instructions. When executed by a processor, the computer program instructions cause the processor to perform the multi-round interactive requirement clarification method based on code awareness and a large language model provided in this application, or to perform any step in any possible implementation of the multi-round interactive requirement clarification method based on code awareness and a large language model provided in this application.

[0139] In some embodiments, the storage medium may be a flash memory, a hard disk, an optical disk, a register, a magnetic surface memory, a removable disk, a CD-ROM, a random access memory (RAM), a read-only memory (ROM), an electrically programmable ROM, and an electrically erasable programmable ROM, or any other form of storage medium known in the art, or various devices including one or any combination of the above storage media.

[0140] In some embodiments, computer program instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0141] As an example, computer program instructions may, but do not necessarily, correspond to files in a file system, and may be stored as part of a file that holds other programs or data, for example, in one or more scripts in an HTML (Hypertext Markup Language) document, or in a single file dedicated to the program in question, or in multiple collaborative files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0142] As an example, computer program instructions can be deployed to execute on a single computing device (including devices such as smart terminals and servers), or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network. It is readily understood that all or part of the steps of the methods described in the embodiments provided above can be implemented directly using electronic hardware or processor-executable computer program instructions, or a combination of both.

[0143] Those skilled in the art will understand that the embodiments provided in this application are merely illustrative. The order in which the steps in the methods of the embodiments are written does not imply a strict execution order and does not constitute any limitation on the implementation process. The order can be adjusted, merged, and deleted according to actual needs. Modules or sub-modules, units or sub-units in the apparatus or system of the embodiments can be merged, divided, and deleted according to actual needs. For example, the division of units is only a logical functional division, and there may be other division methods in actual implementation. For another example, multiple units or components can be combined or integrated into another device, or some features can be ignored or not executed.

[0144] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software plus a general-purpose hardware platform, or of course, it can be implemented using hardware. Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods.

[0145] It should be noted that the above embodiments are for illustrating the technical concept and features of this application, and are intended to enable those skilled in the art to understand the content of this application and implement it accordingly. They should not be construed as limiting the scope of protection of this application. Those skilled in the art can understand that all or part of the processes of the above embodiments can be implemented, modified according to the technical solutions described in the embodiments of this application, or equivalent substitutions can be made to some of the technical features. It is understood that these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and should be considered as equivalent changes and modifications made based on the embodiments of this application, all of which should fall within the scope of the claims of this application.

Claims

1. A multi-round interactive requirement clarification method based on code awareness and a large language model, characterized in that, include: Step S1: In response to the user's input of initial requirements information about the target project, create a reference session. The initial requirements information is fuzzy requirements information, and the reference session includes a dialogue history that stores the initial requirements information. Step S2: Invoke the preset large language model to determine the target tool based on the dialogue history, and return the invocation instruction for the target tool, wherein the target tool includes any one or more preset query tools; Step S3: Based on the invocation instruction, invoke the target tool to obtain target information from the source code of the target project. The target information includes at least one of code information, code call chain information, configuration information, and database information. Step S4: Invoke the large language model to generate a clarification question based on the target information and the dialogue history, and present the clarification question in the reference session; Step S5: In response to the user's input of an answer to the clarification question, update the answer to the conversation history. Step S6: If the response does not meet the requirement clarification completion condition, repeat steps S2 to S5. Step S7: In response to the fulfillment of the clarification conditions, the large language model is invoked to generate a clarification result based on the target information and the dialogue history. Step S8: Present the clarification results of the requirements in the reference session.

2. The multi-round interactive requirement clarification method based on code awareness and a large language model according to claim 1, characterized in that, The target tool includes at least one of a code search tool, a code parsing tool, a configuration search tool, and a database query tool. The step of invoking the target tool to obtain target information from the source code of the target project based on the invocation instruction includes: Based on the invocation instructions regarding the code search tool, the code search tool is invoked to search for code information in the source code of the target project; and / or, According to the invocation instructions regarding the code parsing tool, the code parsing tool is invoked to parse the source code of the target project to obtain the code call chain information; and / or, According to the instruction to invoke the configuration search tool, the configuration search tool is invoked to search for configuration files in the source code of the target project; Parse the configuration file and extract the interface configuration and data source configuration from the configuration file as the configuration information; and / or, According to the instruction to invoke the database query tool, invoke the database query tool to query the data tables of the database in the target project; The data table is parsed, and the field comments, data types, and structural indexes in the data table are extracted as the database information.

3. The multi-round interactive requirement clarification method based on code awareness and a large language model according to claim 2, characterized in that, The target tool further includes a code submission query tool, and the target information further includes code submission history information. The step of invoking the target tool based on the invocation instruction to obtain the target information also includes: According to the invocation instruction for the code submission query tool, the code submission query tool is invoked to query the historical change data, historical submission data, and historical defect data of the target project's source code; Extract the code data, time and modifier of each modification from the historical change data, the code data and author of each submission from the historical submission data, and the defect, time and fixer of each repair from the historical defect data as the code submission history information.

4. The multi-round interactive requirement clarification method based on code awareness and a large language model according to claim 1, characterized in that, The dialogue history includes the initial demand information, or the initial demand information and the response content. The step of invoking the large language model to generate a clarification question based on the target information and the dialogue history includes: The target information and the dialogue history are sent to the large language model, so that the large language model performs a clarification detection operation on the initial demand information or the initial demand information and the answer content based on the target information to obtain a set of items to be clarified, and generates a structured clarification question based on the set of items to be clarified. The clarification detection operation includes ambiguity detection, missing constraint identification and consistency analysis. The set of items to be clarified includes any one or more of the following: missing parameter items, ambiguous object items, undetermined data range items, undetermined execution condition items and constraint conflict items.

5. The multi-round interactive requirement clarification method based on code awareness and a large language model according to claim 4, characterized in that, Presenting the clarification question in the reference session includes: Parse the clarification question in the structured format and extract one or more first field contents from the clarification question in the structured format; Render and display the content of one or more of the first fields in the reference session.

6. The multi-round interactive requirement clarification method based on code awareness and a large language model according to claim 1, characterized in that, The dialogue history includes the initial demand information and the response content. The step of invoking the large language model to generate a demand clarification result based on the target information and the dialogue history includes: The target information and the dialogue history are sent to the large language model, which then performs analysis and extraction operations on the target information and the dialogue history to obtain reference information and generate a structured requirement clarification result based on the reference information.

7. The multi-round interactive requirement clarification method based on code awareness and a large language model according to claim 6, characterized in that, Presenting the clarification result of the requirement in the reference session includes: Parse the structured format requirement clarification result and extract one or more second field contents from the structured format requirement clarification result; Render and display the content of one or more of the second field in the reference session.

8. The multi-round interactive requirement clarification method based on code awareness and a large language model according to any one of claims 1-7, characterized in that, The method further includes: In response to a reference duration greater than or equal to a preset duration threshold, the reference session is deleted to release the memory resources occupied by the reference session. The reference duration is the interval between the current system time and the last access time of the reference session.

9. An electronic device, characterized in that, The device includes a processor and a memory, the processor being communicatively connected to the memory, the memory storing computer program instructions executable by the processor, and the computer program instructions, when executed by the processor, causing the electronic device to perform the multi-turn interactive requirement clarification method based on code awareness and a large language model as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores processor-executable computer program instructions, which, when executed by the processor, cause the processor to perform the multi-round interactive requirement clarification method based on code awareness and a large language model as described in any one of claims 1-8.

Images