Method, device and electronic equipment for generating a rule file based on a dialogue content

Abstract

The application relates to a method and device for generating a rule file based on conversation content and electronic equipment. The method comprises the following steps: listening to the interaction event of a user in a Cursor conversation interface to capture an incremental conversation segment when the user submits a natural language interaction request or the conversation ends; calling a target large language model to perform rule extraction processing on the incremental conversation segment to identify rule information therein and format a rule file conforming to a preset rule control format; writing the rule file into a corresponding rule storage path under a local engineering directory according to the semantic type of the rule information and performing incremental merging, repeated rule deduplication and index maintenance processing; and long-term storing and sharing the rule file through a version management system. The application solves the technical problem that Cursor conversation rules are difficult to be long-term saved and structured managed.

Description

Technical Field

[0001] This application relates to the field of artificial intelligence technology, and in particular to a method, apparatus, storage medium, and electronic device for generating rule files based on dialogue content. Background Technology

[0002] With the application of artificial intelligence technology in software development, intelligent coding assistants such as Cursor, Codeium, and GitHub Copilot have become tools used daily by developers. Cursor, in particular, can accumulate a wealth of development context information through natural language dialogue, including code style guidelines, naming conventions, module division principles, business logic rules, and project-specific tacit knowledge. However, existing technologies still have several technical problems. First, Cursor's dialogue context window is limited; as the dialogue length increases, historical dialogue content is automatically discarded, preventing the long-term preservation of key rules accumulated during development, thus affecting the controllability and consistency of AI output. Second, rules formed based on dialogue lack structured management and cross-team sharing capabilities. Rule information usually exists only in individual interaction records and cannot be reused across different projects or teams, requiring new members to repeatedly create dialogues to gain experience, while also leading to inconsistent team standards. Finally, although developers can manually summarize valuable dialogues, this process is time-consuming, laborious, and prone to overlooking key rules, lacking unified management and version control. Summary of the Invention

[0003] This application provides a method, apparatus, and electronic device for generating rule files based on dialogue content, in order to solve the technical problem that Cursor dialogue rules are difficult to store and manage in a structured manner over a long period of time.

[0004] Firstly, this application provides a method for generating rule files based on dialogue content, comprising: listening to user interaction events in a Cursor dialogue interface to capture incremental dialogue fragments when the user submits a natural language interaction request or when the dialogue ends; invoking a target large language model to perform rule extraction processing on the incremental dialogue fragments to identify the rule information therein and formatting a rule file that conforms to a preset rule control format; writing the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information, and performing incremental merging, duplicate rule deduplication, and index maintenance processing; and storing and sharing the rule file long-term through a version management system.

[0005] Secondly, this application provides an apparatus for generating rule files based on dialogue content, comprising: a capture module for listening to user interaction events in a Cursor dialogue interface to capture incremental dialogue fragments when the user submits a natural language interaction request or when the dialogue ends; an identification module for calling a target large language model to perform rule extraction processing on the incremental dialogue fragments to identify the rule information therein and format a rule file conforming to a preset rule control format; a writing module for writing the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information, and performing incremental merging, duplicate rule deduplication, and index maintenance processing; and a storage module for long-term storage and sharing of the rule file through a version management system.

[0006] As an optional example, the above-mentioned capture module includes: a listening unit, used to register a dialogue event listener through the development tool plugin interface to listen for the user's interaction events in the above-mentioned Cursor dialogue interface; and an extraction unit, used to extract the dialogue text that is newly added compared to the previous round of dialogue from the current dialogue content when the user submits a natural language interaction request in the above-mentioned Cursor dialogue interface, until the dialogue ends, to obtain the above-mentioned incremental dialogue fragment.

[0007] As an optional example, the above-mentioned identification module includes: a preprocessing unit, used to call the above-mentioned target large language model, extract prompt templates according to preset rules, preprocess the above-mentioned incremental dialogue fragments, filter out idle text, invalid descriptions and code snippet noise, and generate preprocessed target dialogue content; an analysis unit, used to perform semantic analysis and rule extraction processing on the above-mentioned target dialogue content, and identify rule information related to coding standards, naming conventions, architectural principles or business constraints; and a sorting unit, used to sort the identified rule information in a structured manner, generate rule entries according to the above-mentioned preset rule control format, and classify and output the above-mentioned rule entries to the corresponding rule files according to the semantic type of the above-mentioned rule information.

[0008] As an optional example, the above writing module includes: a determining unit, used to classify each rule entry in the rule file into code style rules, naming rules, architectural constraint rules or business rules according to the semantic type of the rule information, and determine the rule storage path corresponding to each rule category; and a writing unit, used to write each rule entry in the rule file into the corresponding rule storage path under the local project directory.

[0009] As an optional example, the above-mentioned writing module includes: a processing unit, configured to determine the unprocessed rule entries in the rule file as the current rule entries, and perform the following processing on the current rule entries: compare the current rule entries with the existing rule entries in its corresponding rule storage path one by one, and merge the current rule entries into the existing rule entries if the current rule entries do not exist in the existing rule entries; perform duplicate detection processing on the current rule entries and the existing rule entries, and delete the current rule entries or update the corresponding rule entries with the same semantics in the existing rule entries if the current rule entries are found to be semantically identical to any rule entries in the existing rule entries, wherein the duplicate detection processing includes keyword matching, text similarity calculation or semantic vector comparison; update the rule index of the local project directory to maintain the mapping relationship between rule categories and rule entries, and record the version information, update time and archive status of each rule entry.

[0010] As an optional example, the processing unit is further configured to perform logical conflict detection on the current rule entry and the existing rule entry after performing duplicate detection processing on the current rule entry and the existing rule entry, and generate conflict identification information when a logical conflict is detected between any rule entry in the current rule entry and the existing rule entry, so as to prompt manual confirmation or trigger an automatic adjustment strategy.

[0011] As an optional example, the above apparatus further includes: a detection module, configured to detect the update time of each rule entry in each rule storage path under the local project directory after writing the rule file to the corresponding rule storage path under the local project directory according to the semantic type of the rule information; an archiving module, configured to remove the target rule entry from the corresponding rule storage path and write it to the archive path under the local project directory when the update time of the target rule entry exceeds a preset validity period, wherein the target rule entry is any rule entry in any rule storage path; and an update module, configured to update the rule index of the local project directory.

[0012] Thirdly, this application provides a storage medium storing a computer program, wherein the computer program is executed by a processor to perform the above-described method for generating rule files based on dialogue content.

[0013] Fourthly, this application also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to execute the above-described method for generating rule files based on dialogue content through the computer program.

[0014] The technical solutions provided in this application have the following advantages compared with the prior art: This application employs a method of monitoring user interaction events in the Cursor dialog interface to capture incremental dialogue fragments when the user submits a natural language interaction request or the dialogue ends; it calls a target large language model to perform rule extraction processing on the incremental dialogue fragments to identify the rule information within them and format them into a rule file conforming to a preset rule control format; based on the semantic type of the rule information, the rule file is written to the corresponding rule storage path in the local project directory, and incremental merging, duplicate rule deduplication, and index maintenance are performed; the rule file is then stored and shared long-term through a version management system. Because in the above method, by monitoring... The system captures incremental dialogue fragments from user interactions in the Cursor dialog interface, and uses a large language model to extract and structure the incremental content according to rules. It generates rule files that conform to a preset rule control format, and then writes them to the local project directory according to the rule category. It performs incremental merging, deduplication, and index maintenance, and stores and shares them long-term through a version control system. This achieves automatic rule accumulation, unified management, cross-team reuse, and historical traceability, avoids the loss of key specifications, improves development efficiency, and reduces manual organization costs. In this way, it solves the technical problem of Cursor dialog rules being difficult to preserve and manage in a structured manner for a long time. Attached Figure Description

[0015] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0016] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] One or more embodiments are illustrated by way of example with reference numerals in the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements with the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0018] Figure 1 This is a flowchart of an optional method for generating rule files based on dialogue content according to an embodiment of this application; Figure 2 This is a flowchart illustrating a specific implementation of an optional method for generating rule files based on dialogue content, according to an embodiment of this application. Figure 3 This is a schematic diagram of an optional apparatus for generating rule files based on dialogue content according to an embodiment of this application; Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0019] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. 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.

[0020] The following disclosure provides numerous different embodiments or examples for implementing various structures of this application. To simplify the disclosure, specific examples of components and arrangements are described below. These are merely examples and are not intended to limit the scope of this application. Furthermore, reference numerals and / or letters may be repeated in different examples. Such repetition is for simplification and clarity and does not in itself indicate a relationship between the various embodiments and / or arrangements discussed.

[0021] According to a first aspect of the embodiments of this application, a method for generating a rule file based on dialogue content is provided, optionally, as follows: Figure 1 As shown, the above method includes: S102, listen for user interaction events in the Cursor dialogue interface to capture incremental dialogue fragments when the user submits a natural language interaction request or when the dialogue ends. S104, Invoke the target large language model to perform rule extraction processing on the incremental dialogue fragments in order to identify the rule information in them and generate a rule file that conforms to the preset rule control format; S106. Based on the semantic type of the rule information, write the rule file to the corresponding rule storage path in the local project directory, and perform incremental merging, duplicate rule deduplication, and index maintenance processing. S108 uses a version control system to store and share rule files long-term.

[0022] Optionally, this embodiment provides a method for generating rule files based on dialogue content. The aim is to address the technical bottlenecks in the long-term development of existing intelligent coding assistants regarding the accumulation and sharing of key rules. By listening to, refining, and structuring the incremental content of the user's dialogue with the Cursor, and effectively managing and storing the generated rule files long-term, the method achieves automatic rule accumulation, unified standardization, and cross-team reuse.

[0023] Specifically, such as Figure 2 The flowchart shown first listens for user interaction events in the Cursor dialogue interface. Using APIs provided by the developer tool plugin or the Cursor plugin, event listeners are triggered each time the user submits a natural language interaction request or the dialogue ends, thereby capturing the latest incremental dialogue fragments. These incremental dialogue fragments only include content added compared to the previous dialogue round and are temporarily stored in a local cache queue to avoid duplicate capture and redundant analysis. This overcomes the limitations of the Cursor context window, allowing key dialogue information accumulated during development to be fully acquired, thus providing reliable input data for subsequent rule extraction.

[0024] After acquiring incremental dialogue fragments, the target Large Language Model (LLM) is further invoked to perform rule extraction processing. Semantic analysis of the incremental dialogue content identifies information such as coding standards, naming conventions, architectural principles, business logic rules, and project-specific constraints, structuring these into rule entries. Simultaneously, during rule extraction, preprocessing and noise reduction mechanisms filter out idle chatter, invalid descriptions, and code snippets to ensure the accuracy and executability of the generated rules. Rule entries are further formatted according to a preset rule control format, such as generating ".mdc" file content, ensuring they can be automatically recognized and executed by the tool. This process also identifies duplicates and conflicts between newly generated rules and existing rules. Duplicate rules are deduplicated, and conflicting rules generate prompts for manual confirmation or automatic adjustment, thus ensuring the consistency and completeness of the rule base.

[0025] After rule extraction, the rule files are written to the corresponding rule storage path in the local project directory based on the semantic type of the rule information. Rule entries are categorized, such as naming rules, code style rules, architectural constraint rules, or business rules, and written to the respective naming rule file, style rule file, architectural rule file, and business rule file. During the writing process, incremental merging is performed, comparing the newly generated rules with the existing file content and appending or merging only non-existent entries to achieve dynamic updates to the rule base. Simultaneously, a rule index file is maintained, recording the structure of each rule category and its contained rule entries. The index is updated synchronously when rules are updated or expired rules are deleted to support fast retrieval, loading, and management of the rule base. For expired rules, the update time or effective period is periodically checked, and expired rules are moved to the archive path for storage and marked as archived in the index, ensuring that the main rule file contains only currently valid rules while allowing for the tracking of historical versions.

[0026] Finally, a version control system is used for long-term storage and sharing of rule files. The generated rule files are managed as plain text files within version control systems such as Git. The system automatically records the differences (diff) of each newly added rule, the modification history, and commit information, achieving long-term rule persistence and version traceability. Team members can share rule files through repositories, enabling rule reuse across projects and teams. New members can quickly access unified standards, ensuring consistency in coding and architectural rules within the team. Collaborative rule updates and conflict resolution are also supported, forming a complete closed-loop rule management system.

[0027] Optionally, this embodiment can automatically extract the natural language dialogue between developers and the Cursor into structured, executable, and categorized rule files. Through incremental merging, deduplication, index maintenance, archiving, and version management, the rules can be long-term stored and shared within the team. This improves rule accumulation efficiency, prevents the loss of key specifications, reduces manual compilation costs and the risk of omissions, enables cross-project and cross-team standardization and reuse, and ensures the maintainability, traceability, and automated management capabilities of the rule base, significantly enhancing the controllability and efficiency of intelligent coding-assisted development.

[0028] As an optional example, listening for user interaction events in the Cursor dialog interface to capture incremental dialogue fragments when the user submits a natural language interaction request or when the dialogue ends includes: Register a dialogue event listener through the developer tool plugin interface to listen for user interaction events in the Cursor dialogue interface; When a user submits a natural language interaction request in the Cursor dialog interface, the system begins to extract additional dialogue text from the current dialogue content compared to the previous round of dialogue, until the dialogue ends, thus obtaining an incremental dialogue fragment.

[0029] Optionally, in this embodiment, a dialogue event listener is registered through the development tool plugin interface or the Cursor plugin API to monitor user actions in the Cursor dialogue interface in real time, including user input prompts and AI model response generation events. The listener can capture each event when a user submits a natural language interaction request, thereby triggering the extraction of incremental dialogue content. Secondly, upon detecting a user submitting a natural language interaction request, the text content added compared to the previous round of dialogue is extracted from the current dialogue content; this added content constitutes an incremental dialogue fragment. Subsequent dialogues can be continuously monitored until the user completes the dialogue or a preset dialogue end condition is met, thus fully acquiring all incremental information during a round of interaction. During the extraction process, incremental fragments are saved in a local cache queue to avoid duplicate analysis and data loss, and to ensure the order and integrity of the dialogue increments. This embodiment can overcome the limitations of the Cursor dialogue context window, achieving complete capture of key dialogue content during the interaction between the developer and the AI, providing a reliable data foundation for automatically generating rule files and long-term development specifications.

[0030] As an optional example, the target large language model is invoked to perform rule extraction processing on the incremental dialogue fragments to identify the rule information within them, and to generate a rule file that conforms to a preset rule control format, including: The target large language model is invoked, prompt templates are extracted according to preset rules, incremental dialogue fragments are preprocessed, and idle text, invalid descriptions and code snippet noise are filtered out to generate preprocessed target dialogue content. Perform semantic analysis and rule extraction on the target dialogue content to identify rule information related to coding standards, naming conventions, architectural principles, or business constraints; The identified rule information is structured and organized, and rule entries are generated according to the preset rule control format. At the same time, the rule entries are classified and output to the corresponding rule files according to the semantic type of the rule information.

[0031] Optionally, in this embodiment, firstly, the target large language model (such as GPT, Llama, or Claude) is invoked, and combined with a preset rule extraction prompt template, to preprocess the captured incremental dialogue fragments. During the preprocessing stage, by filtering out idle chatter, invalid descriptions, and noise from specific code snippets, only valid target dialogue content related to rule extraction is generated, thereby ensuring the accuracy and efficiency of subsequent analysis and processing. Subsequently, semantic analysis and rule extraction processing are performed on the target dialogue content. This processing uses the large language model to understand the text semantics, identify information involving coding standards, naming conventions, architectural principles, and business constraints, and extract this information into rule entries that can be structured. Next, the extracted rule entries are structured, including a unified naming format, standardized rule descriptions, and classification labeling, and the final rule entries are generated according to a preset rule control format, making them directly recognizable and executable by the rule management tool. Based on the semantic type of the rule entries, they are further classified and output to corresponding rule files, such as naming rule files, style rule files, architectural rule files, or business rule files, thereby achieving orderly management and classified storage of rules. This embodiment can automatically convert unstructured incremental dialogue content into structured, executable, and categorizable rule files, ensuring the accuracy and standardization of rule extraction.

[0032] As an optional example, depending on the semantic type of the rule information, writing the rule file to the corresponding rule storage path in the local project directory includes: Based on the semantic type of the rule information, each rule entry in the rule file is divided into code style rules, naming rules, architectural constraint rules, or business rules, and the rule storage path corresponding to each rule category is determined. Write each rule entry in the rule file to the corresponding rule storage path in the local project directory.

[0033] Optionally, in this embodiment, after extracting and structuring the rules for the incremental dialogue fragments, it is necessary to perform semantic type determination and classification management on the identified rule entries. Specifically, based on the semantic features of the rule information, the rule entries are divided into different rule categories, such as code style rules, naming rules, architectural constraint rules, and business rules. Among them, code style rules are used to constrain indentation format, comment specifications, and code structure organization; naming rules are used to unify the naming conventions of variables, functions, modules, and interfaces; architectural constraint rules are used to limit module dependencies, layer boundaries, and component calling methods; and business rules are used to describe the project-specific business logic constraints, data validation principles, or domain specifications.

[0034] After classifying the rules, the corresponding rule storage paths for each category are further determined. These storage paths can be pre-configured within the project directory structure. For example, a unified rule management directory can be created in the project root directory, with subdirectories or independent files set up according to the category, ensuring the standardization and maintainability of rule file storage. Furthermore, based on the project's language type, framework characteristics, or team conventions, different rule categories can be mapped to specific configuration file formats or control files, allowing subsequent development tools or intelligent coding assistants to directly load and activate them.

[0035] Subsequently, each rule entry in the rule file is written to the corresponding rule storage path in the local project directory according to its category. During the writing process, appending or overwriting can be used, and the format of the rule entries is uniformly validated to ensure that the output content conforms to the preset rule control format requirements.

[0036] As an optional example, performing incremental merging, deduplication of duplicate rules, and index maintenance includes: Identify any unprocessed rule entries in the rule file as the current rule entries, and perform the following processing on the current rule entries: The current rule entry is compared with the existing rule entries in its corresponding rule storage path one by one. If the current rule entry does not exist in the existing rule entries, the current rule entry is merged into the existing rule entries. Perform duplicate detection processing on the current rule entry and existing rule entries, and if the current rule entry is found to be semantically identical to any rule entry in the existing rule entries, delete the current rule entry or update the corresponding rule entry in the existing rule entries that is semantically identical to it based on the current rule entry. The duplicate detection processing includes keyword matching, text similarity calculation or semantic vector comparison. Update the rule index of the local project directory to maintain the mapping relationship between rule categories and rule entries, and record the version information, update time and archive status of each rule entry.

[0037] Optionally, in this embodiment, after the rule entries are written to the corresponding rule storage path in the local project directory according to their semantic types, the system needs to perform incremental updates and duplicate control on the newly added rule entries to ensure the continuous scalability and consistency of the rule files. Specifically, merging and deduplication are performed on each rule entry. In the incremental merging phase, the current rule entry is compared with the existing rule entries in its corresponding rule storage path. When the comparison result shows that there is no rule content in the existing rule set that is completely consistent with the current rule entry, the current rule entry is merged and appended to the existing rule entry set, thereby realizing the incremental expansion of the rule base, avoiding the full overwrite of historical rules every time a rule file is generated, and improving the efficiency of rule accumulation.

[0038] In the deduplication stage, further deduplication processing is performed on the current rule entry and existing rule entries to identify potential semantic repetitions or rule content with different expressions but the same meaning. When a current rule entry is found to be semantically identical to any existing rule entry, the current rule entry can be deleted to avoid redundancy, or existing rule entries can be updated and supplemented based on the current rule entry to maintain the up-to-dateness and accuracy of the rule expression. Deduplication detection can be implemented in various ways, including fast filtering based on keyword matching, content comparison based on text similarity calculation, or deep semantic consistency judgment based on semantic vector representation, thereby improving the accuracy and robustness of deduplication.

[0039] After incremental merging and deduplication, the rule index in the local project directory is updated and maintained to preserve the mapping between rule categories and rule entries, and to record the version information, update time, and archive status of each rule entry. This index maintenance mechanism supports rapid rule retrieval, historical tracking, and cross-version management, providing stable support for subsequent rule sharing, team collaboration, and intelligent assistant loading.

[0040] As an optional example, after performing duplicate detection processing on the current rule entry and existing rule entries, the above method further includes: Perform logical conflict detection processing on the current rule entry and existing rule entries, and generate conflict identification information when a logical conflict is detected between the current rule entry and any existing rule entry to prompt manual confirmation or trigger automatic adjustment strategy.

[0041] Optionally, in this embodiment, since the rule entries are derived from incremental extraction of dialogues in different rounds and may be proposed by different developers in different scenarios, even if the rule entries are not semantically repetitive, there may be potential contradictions in their constraint content, scope of application, or execution strategy. Without control, conflicting rules will cause the intelligent coding assistant to exhibit inconsistent behavior or uncontrollable output when generating subsequent code.

[0042] Specifically, after determining the current rule entry and performing semantic deduplication with existing rule entries, a logical consistency analysis is further performed on the current rule entry and the existing rule entries in its corresponding rule storage path. Logical conflict detection is used to identify whether there are mutually exclusive relationships, priority contradictions, or opposite constraint directions between rules. For example, one rule requires "all interfaces must return a uniform wrapper structure," while another rule requires "internal modules are prohibited from additional wrapping to reduce overhead." If the scope of application is not clearly distinguished, these two rules may constitute a logical conflict.

[0043] During the detection process, the structured representation of rule entries can be used to parse the constraint objects, constraint actions, applicable conditions, and exception scope of the rules. The degree of conflict can then be determined by combining keyword oppositions, rule condition coverage relationships, or semantic reasoning models. When a logical conflict is detected between the current rule entry and any existing rule entry, conflict identification information is generated. This information may include the conflicting rule pair, conflict type, conflict severity level, and suggested handling methods, prompting developers to conduct manual verification.

[0044] Furthermore, conflict resolution can be triggered based on preset automatic adjustment strategies. For example, this could involve introducing a rule priority mechanism, automatically supplementing the scope of application, or temporarily marking conflicting rules as pending archiving, thus preventing them from directly entering the effective rule base. Through these logical conflict detection and identification mechanisms, the uniformity and reliability of rule files can be further ensured, rule governance capabilities improved, and the stable output of the intelligent coding assistant enhanced during long-term iterations.

[0045] As an optional example, after writing the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information, the above method also includes: Detect the update time of each rule entry in each rule storage path under the local project directory; If the update time of the target rule entry exceeds the preset validity period, the target rule entry will be removed from the corresponding rule storage path and written to the archive path under the local project directory. The target rule entry is any rule entry in any rule storage path. Update the rule index of the local project directory.

[0046] Optionally, in this embodiment, after writing the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information, to ensure the long-term validity of the rule base and the continuous applicability of the rule content, expiration detection and archiving cleanup are performed on the rule entries. Since rule entries originate from long-term dialogue and interaction between developers and the intelligent coding assistant, rules generated at different stages may gradually become invalid as the project architecture evolves, business needs change, or team specifications are updated. If all historical rules are retained for a long time, it can easily lead to rule base expansion, specification conflicts, or AI behavior deviating from current project requirements. Therefore, a rule lifecycle management mechanism is further introduced to automatically clean up and archive expired rules.

[0047] Specifically, the update time of each rule entry in the rule storage paths under the local project directory is detected first. The update time can be the last modification time, the most recent reference time, or the most recent incremental update time of the rule entry, and the corresponding information can be obtained through the timestamp field in the file metadata record or the rule index. By periodically scanning or performing detection when a rule update event is triggered, the activity status of the rule entries can be monitored in real time.

[0048] If the update time of any rule entry in any rule storage path exceeds the preset validity period, the target rule entry is determined to be an expired rule. The preset validity period can be configured according to project type, team management strategy, or rule category. For example, naming convention rules have a longer validity period, while business logic rules may need to be updated more frequently. For target rule entries determined to be expired, they are removed from the corresponding rule storage path and written to the archive path under the local project directory to achieve historical preservation of rules and purification of the current rule base. The archive path is set to, for example, the ".cursor / archive / " directory, to centrally store invalid or long-unupdated rule content.

[0049] After completing the rule removal and archiving, the rule index in the local project directory is further updated to maintain the mapping relationship between rule entries and rule categories, and the archiving status, archiving time, and version information of the target rule entries are recorded synchronously, thereby ensuring that the rule index is consistent with the actual rule files. Through the above-mentioned expiration detection and archiving cleanup mechanism, continuous optimization and dynamic governance of the rule base can be achieved, preventing invalid rules from interfering with the output behavior of the intelligent coding assistant for a long time, and improving the maintainability and project adaptability of the rule system.

[0050] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

[0051] According to another aspect of the embodiments of this application, an apparatus for generating rule files based on dialogue content is also provided, such as... Figure 3 As shown, it includes: The capture module 302 is used to listen to user interaction events in the Cursor dialogue interface in order to capture incremental dialogue fragments when the user submits a natural language interaction request or when the dialogue ends. The recognition module 304 is used to call the target large language model to perform rule extraction processing on the incremental dialogue fragments in order to identify the rule information therein and generate a rule file that conforms to the preset rule control format. The writing module 306 is used to write the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information, and to perform incremental merging, duplicate rule deduplication and index maintenance processing. Storage module 308 is used for long-term storage and sharing of rule files through a version management system.

[0052] It should be noted that the capture module 302 in this embodiment can be used to execute step S102 in this application embodiment, the identification module 304 in this embodiment can be used to execute step S104 in this application embodiment, the writing module 306 in this embodiment can be used to execute step S106 in this application embodiment, and the storage module 308 in this embodiment can be used to execute step S108 in this application embodiment.

[0053] As an optional example, the capture module includes: The listening unit is used to register dialogue event listeners through the development tool plugin interface to listen for user interaction events in the Cursor dialogue interface; The extraction unit is used to extract the dialogue text that is newer than the previous round of dialogue from the current dialogue content when the user submits a natural language interaction request in the Cursor dialogue interface, until the dialogue ends, and obtain the incremental dialogue fragment.

[0054] As an optional example, the recognition module includes: The preprocessing unit is used to call the target large language model, extract prompt templates according to preset rules, preprocess incremental dialogue fragments, filter out idle text, invalid descriptions and code snippet noise, and generate preprocessed target dialogue content. The analysis unit is used to perform semantic analysis and rule extraction processing on the target dialogue content, and identify rule information related to coding standards, naming conventions, architectural principles or business constraints. The sorting unit is used to structure the identified rule information, generate rule entries according to the preset rule control format, and classify and output the rule entries to the corresponding rule files according to the semantic type of the rule information.

[0055] As an optional example, the write module includes: The determination unit is used to classify each rule entry in the rule file into code style rules, naming rules, architectural constraint rules, or business rules according to the semantic type of the rule information, and to determine the rule storage path corresponding to each rule category; The write unit is used to write each rule entry in the rule file to the corresponding rule storage path under the local project directory.

[0056] As an optional example, the write module includes: The processing unit is used to identify unprocessed rule entries in the rule file as the current rule entries, and to perform the following processing on the current rule entries: The current rule entry is compared with the existing rule entries in its corresponding rule storage path one by one. If the current rule entry does not exist in the existing rule entries, the current rule entry is merged into the existing rule entries. Perform duplicate detection processing on the current rule entry and existing rule entries, and if the current rule entry is found to be semantically identical to any rule entry in the existing rule entries, delete the current rule entry or update the corresponding rule entry in the existing rule entries that is semantically identical to it based on the current rule entry. The duplicate detection processing includes keyword matching, text similarity calculation or semantic vector comparison. Update the rule index of the local project directory to maintain the mapping relationship between rule categories and rule entries, and record the version information, update time and archive status of each rule entry.

[0057] As an optional example, the processing unit is also used to perform logical conflict detection on the current rule entry and the existing rule entry after performing duplicate detection processing on the current rule entry and the existing rule entry, and generate conflict identification information when a logical conflict is detected between the current rule entry and any of the existing rule entries to prompt manual confirmation or trigger an automatic adjustment strategy.

[0058] As an optional example, the above-described apparatus further includes: The detection module is used to detect the update time of each rule entry in each rule storage path in the local project directory after writing the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information. The archiving module is used to remove the target rule entry from the corresponding rule storage path and write it to the archive path under the local project directory when the update time of the target rule entry exceeds the preset validity period. The target rule entry is any rule entry in any rule storage path. The update module is used to update the rule index of the local project directory.

[0059] For other examples of this embodiment, please refer to the examples above, which will not be repeated here.

[0060] Figure 4 This is a schematic diagram of an optional electronic device according to an embodiment of this application, such as... Figure 4 As shown, it includes a processor 402, a communication interface 404, a memory 406, and a communication bus 408. The processor 402, communication interface 404, and memory 406 communicate with each other via the communication bus 408. Memory 406 is used to store computer programs; When processor 402 executes a computer program stored in memory 406, it performs the following steps: Listen for user interaction events in the Cursor dialog interface to capture incremental dialogue fragments when the user submits a natural language interaction request or when the dialogue ends. The target large language model is invoked to perform rule extraction processing on incremental dialogue fragments in order to identify the rule information therein and generate a rule file that conforms to the preset rule control format. Based on the semantic type of the rule information, the rule file is written to the corresponding rule storage path in the local project directory, and incremental merging, duplicate rule deduplication, and index maintenance are performed. Rule files are stored and shared long-term through a version control system.

[0061] Optionally, in this embodiment, the communication bus can be a PCI (Peripheral Component Interconnect) bus or an EISA (Extended Industry Standard Architecture) bus, etc. This communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 4 The symbol is represented by a single thick line, but this does not indicate that there is only one bus or one type of bus. The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0062] The memory may include RAM, or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0063] As an example, the memory 406 described above may include, but is not limited to, the capture module 302, the recognition module 304, the writing module 306, and the storage module 308 in the apparatus for generating rule files based on dialogue content. Furthermore, it may include, but is not limited to, other module units in the apparatus for generating rule files based on dialogue content, which will not be elaborated upon in this example.

[0064] The processor mentioned above can be a general-purpose processor, including but not limited to: CPU (Central Processing Unit), NP (Network Processor), etc.; it can also be DSP (Digital Signal Processor), ASIC (Application Specific Integrated Circuit), FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0065] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0066] Those skilled in the art will understand that Figure 4 The structure shown is for illustrative purposes only. The device that implements the above method for generating rule files based on dialogue content can be a terminal device, such as a smartphone (e.g., Android phone, iOS phone), tablet computer, PDA, mobile Internet Devices (MID), PAD, etc. Figure 4 This does not limit the structure of the aforementioned electronic devices. For example, the electronic device may also include components that are more... Figure 4 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 4 The different configurations shown.

[0067] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, ROM, RAM, disk or optical disk, etc.

[0068] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored in the computer program, which, when executed by a processor, performs the steps in the method for generating a rule file based on dialogue content described above.

[0069] Optionally, in this embodiment, those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0070] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0071] If the integrated units in the above embodiments are implemented as software functional units and sold or used as independent products, they can be stored in the aforementioned 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 all or 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 one or more computer devices (which may be personal computers, servers, or network devices, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application.

[0072] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0073] In the several embodiments provided in this application, it should be understood that the disclosed client can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, indirect coupling or communication connection between units or modules, and may be electrical or other forms.

[0074] The units described as separate components may or may not be physically separate. 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 units can be selected to achieve the purpose of this embodiment according to actual needs.

[0075] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0076] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for generating rule files based on dialogue content, characterized in that, include: Listen for user interaction events in the Cursor dialog interface to capture incremental dialogue fragments when the user submits a natural language interaction request or the dialogue ends. The target large language model is invoked to perform rule extraction processing on the incremental dialogue fragments in order to identify the rule information therein and generate a rule file that conforms to the preset rule control format. Based on the semantic type of the rule information, the rule file is written to the corresponding rule storage path in the local project directory, and incremental merging, duplicate rule deduplication, and index maintenance are performed. The rule files are stored and shared long-term through a version management system.

2. The method according to claim 1, characterized in that, The monitoring of user interaction events in the Cursor dialog interface to capture incremental dialogue fragments when the user submits a natural language interaction request or the dialogue ends includes: Register a dialogue event listener through the development tool plugin interface to listen for the user's interaction events in the Cursor dialogue interface; When the user submits a natural language interaction request in the Cursor dialog interface, the system begins to extract additional dialogue text from the current dialogue content compared to the previous dialogue, until the dialogue ends, thus obtaining the incremental dialogue fragment.

3. The method according to claim 1, characterized in that, The process of calling the target large language model, performing rule extraction processing on the incremental dialogue fragments to identify rule information, and formatting and generating a rule file conforming to a preset rule control format includes: The target large language model is invoked, and prompt templates are extracted according to preset rules. The incremental dialogue fragments are preprocessed to filter out idle text, invalid descriptions and code snippet noise, and generate preprocessed target dialogue content. Perform semantic analysis and rule extraction processing on the target dialogue content to identify rule information related to coding standards, naming conventions, architectural principles, or business constraints. The identified rule information is structured and organized, and rule entries are generated according to the preset rule control format. At the same time, the rule entries are classified and output to the corresponding rule files according to the semantic type of the rule information.

4. The method according to claim 1, characterized in that, The step of writing the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information includes: Based on the semantic type of the rule information, each rule entry in the rule file is divided into code style rules, naming rules, architectural constraint rules, or business rules, and the rule storage path corresponding to each rule category is determined. Write each rule entry in the rule file into the corresponding rule storage path under the local project directory.

5. The method according to claim 4, characterized in that, The incremental merging, duplicate rule deduplication, and index maintenance processes include: The unprocessed rule entries in the rule file are identified as the current rule entries, and the following processing is performed on the current rule entries: The current rule entry is compared with the existing rule entries in its corresponding rule storage path one by one. If the current rule entry does not exist in the existing rule entries, the current rule entry is merged into the existing rule entries. The current rule entry and existing rule entries are subjected to duplicate detection processing. If the current rule entry and any existing rule entry are found to be semantically identical, the current rule entry is deleted or the corresponding existing rule entry with the same semantics is updated based on the current rule entry. The duplicate detection processing includes keyword matching, text similarity calculation or semantic vector comparison. Update the rule index of the local project directory to maintain the mapping relationship between rule categories and rule entries, and record the version information, update time and archive status of each rule entry.

6. The method according to claim 5, characterized in that, After performing duplicate detection processing on the current rule entry and existing rule entries, the method further includes: Logical conflict detection is performed on the current rule entry and the existing rule entries. If a logical conflict is detected between the current rule entry and any of the existing rule entries, conflict identification information is generated to prompt manual confirmation or trigger an automatic adjustment strategy.

7. The method according to claim 1, characterized in that, After writing the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information, the method further includes: Detect the update time of each rule entry in each rule storage path under the local project directory; If the update time of a target rule entry exceeds the preset validity period, the target rule entry will be removed from the corresponding rule storage path and written to the archive path under the local project directory. The target rule entry is any rule entry in any rule storage path. Update the rule index of the local project directory.

8. An apparatus for generating rule files based on dialogue content, characterized in that, include: The capture module is used to listen for user interaction events in the Cursor dialogue interface in order to capture incremental dialogue fragments when the user submits a natural language interaction request or the dialogue ends. The recognition module is used to call the target large language model, perform rule extraction processing on the incremental dialogue fragments, identify the rule information therein, and format and generate a rule file that conforms to the preset rule control format. The writing module is used to write the rule file to the corresponding rule storage path in the local project directory according to the semantic type of the rule information, and to perform incremental merging, duplicate rule deduplication and index maintenance processing. The storage module is used for long-term storage and sharing of the rule files through a version management system.

9. A computer-readable storage medium storing a computer program, characterized in that, The computer program is executed by the processor to perform the method described in any one of claims 1 to 7.

10. An electronic device comprising a memory and a processor, characterized in that, The memory stores a computer program, and the processor is configured to execute the method described in any one of claims 1 to 7 through the computer program.

Images