Conference data processing method and device, equipment and storage medium

Abstract

The present disclosure provides a conference data processing method and device, equipment and storage medium, relates to the technical field of computers, especially to the technical field of large models, artificial intelligence, office automation and intelligent agents. The specific implementation scheme is: obtaining a discussion context of a conference; collecting audio of the conference in real time, and converting the audio into transcribed text; generating a task item according to the transcribed text, the task item recording a task target and a completion standard; generating a handover package with a multi-layer structure according to the discussion context, the task item and decision information determined from the transcribed text; and providing the handover package to an external coded intelligent agent to analyze the content of each layer of the handover package by the external coded intelligent agent, and to continue to execute the task item. According to the technical scheme of the present disclosure, the structured handover of conference discussion results to an external coded intelligent agent is realized, and the efficiency and continuity of the flow of conference results to research and development tasks are improved.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to the fields of large models, artificial intelligence, office automation, and intelligent agents. Background Technology

[0002] Meeting assistant tools typically end with recording, providing real-time speech-to-text transcription of meeting discussions and outputting transcribed text or summary documents. AI programming aids, on the other hand, only respond to human-inputted prompts like "Prompt," generating code snippets or performing file operations. Inspirations, decisions, and tasks generated during meeting discussions require users to manually organize, copy, and paste them before providing them as input to programming AI tools, resulting in a lack of a native pathway between discussion outcomes and the R&D stage. Summary of the Invention

[0003] This disclosure provides a method, apparatus, device, and storage medium for processing conference data.

[0004] According to one aspect of this disclosure, a method for processing conference data is provided, comprising: Obtain the discussion context of the meeting; Real-time acquisition of meeting audio, and transcription of the audio into transcribed text; Task items are generated from the transcribed text, and each task item contains the task objectives and completion criteria. Based on the discussion context, task items, and decision information determined from the transcribed text, a multi-layered serialized handover packet is generated; The handover packet is provided to an external coding agent, which then parses the contents of each layer of the handover packet and continues to execute the tasks.

[0005] According to another aspect of this disclosure, a conference data processing apparatus is provided, comprising: The acquisition module is used to acquire the discussion context of the meeting; The audio acquisition and transcription module is used to acquire the audio of the meeting in real time and transcribe the audio into transcribed text. The task extraction module is used to generate task items based on the transcribed text. Each task item has a task objective and a completion standard. The handover packet generation module is used to generate multi-layered serialized handover packets based on the discussion context, task items, and decision information determined from the transcribed text. A module is provided to deliver the handover packet to an external coding agent, which then parses the contents of each layer of the handover packet and continues to execute the task.

[0006] According to another aspect of this disclosure, an electronic device is provided, comprising: At least one processor; and The memory is communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform any of the methods described in the present disclosure.

[0007] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause the computer to perform any of the methods according to embodiments of this disclosure.

[0008] According to another aspect of this disclosure, a computer program product is provided, including a computer program that, when executed by a processor, implements any of the methods according to embodiments of this disclosure.

[0009] According to the technical solution disclosed herein, a structured transfer of meeting discussion results to external coded intelligent agents is realized, which improves the efficiency and continuity of the flow of meeting results to R&D tasks.

[0010] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0011] The accompanying drawings are provided to better understand this solution and do not constitute a limitation of this disclosure. Wherein: Figure 1 This is a flowchart illustrating a meeting data processing method provided according to an embodiment of the present disclosure; Figure 2 This is a schematic diagram of the system architecture of the meeting data processing method provided according to the embodiments of this disclosure; Figure 3 This is a schematic diagram of the structure of the handover package provided according to an embodiment of the present disclosure; Figure 4 This is a schematic diagram of the interface of the conference workbench provided according to an embodiment of the present disclosure; Figure 5 This is a flowchart illustrating a meeting data processing method according to another embodiment of the present disclosure; Figure 6 This is a schematic diagram of the structure of a conference data processing apparatus provided according to an embodiment of the present disclosure; Figure 7 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present disclosure. Detailed Implementation

[0012] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0013] Traditional meeting processing solutions often rely on post-meeting summaries or manual transcription to bridge meeting discussions with programming tools. While this approach performs adequately for recording typical single-meeting scenarios, it falls short in complex scenarios involving multi-person brainstorming discussions that require direct access to code development. This is because meeting outputs are human-readable documents rather than machine-executable structured instructions, and there's a lack of a native pathway from the meeting context to the local command-line interface (CLI) programming agent. This leads to several problems, including the need for manual transcription of discussion results, attenuation of ideas during relaying, lack of signed documentation of consensus, and fragmentation across meeting contexts. Furthermore, programming tools only respond to manually entered prompts, failing to perceive the complete context of multi-person discussions; and the lack of formal signing of consensus makes it impossible to trace who agreed with what. Traditional solutions easily result in a broken flow between meeting outcomes and the development phase, leading to rework and deviations.

[0014] To at least partially address one or more of the aforementioned problems and other potential issues, this disclosure proposes a meeting data processing method. This method involves real-time acquisition and streaming transcription of meeting audio, extracting task items containing objectives and completion standards from the transcribed text, merging the discussion context, task items, and decision information into a multi-layered sequential structure to generate a handover packet, and providing it to an external coding agent for parsing and continuation. This establishes a native handover pathway between the meeting discussion and the coding agent. This method significantly improves the efficiency and contextual continuity of the flow from meeting outcomes to R&D tasks, and enhances the executability of output instructions through the multi-layered structured handover packet, achieving a complete closed loop from meeting discussion directly to code development.

[0015] This disclosure provides a method for processing conference data, which can be applied to a conference data processing device. The conference data processing device is located in an electronic device. The electronic device includes, but is not limited to, fixed devices and / or mobile devices. For example, fixed devices include, but are not limited to, servers, which may be cloud servers, general-purpose servers, or distributed nodes. Mobile devices include, but are not limited to, laptops, tablets, and smartphones. In some possible implementations, the conference data processing method can also be implemented by a processor calling computer-readable instructions stored in memory.

[0016] The following describes in detail the implementation methods of this disclosure in conjunction with application scenarios and examples.

[0017] like Figure 2 As shown, the conference data processing method provided in this embodiment can be applied to a system architecture consisting of a first end and a second end that cooperate with each other. The first end is a conference workbench used to perform processing such as audio acquisition, streaming transcription, task extraction, and handover packet generation; the second end is an external coding agent used to receive handover packets and continue executing tasks. A one-way data channel is established between the first end and the second end via handover packets, forming a closed loop from conference discussion to code development. The first end can run as a web-based conference workbench in a browser environment, and the second end is a coding agent with a command-line interface; both can run on the same electronic device or different electronic devices. When collecting data involving personal voice information, such as conference audio, personal authorization may be required if necessary, and the scope of authorization should be indicated to the user before collection.

[0018] Figure 1 This is a flowchart illustrating a meeting data processing method provided according to an embodiment of this disclosure. Figure 1 As shown, the method includes, but is not limited to, steps S101 to S105.

[0019] Step S101: Obtain the discussion context of the meeting.

[0020] In this embodiment, the discussion context can be understood as relevant information describing the topic, background, and boundaries of the meeting discussion, providing a semantic framework for subsequent processing. The discussion context may include information such as the meeting topic, the main idea of ​​the document to be reviewed, known constraints, links to reference code, and a list of participants. It may also include transcribed content accumulated during the meeting, extracted core points, and decision-making information. The discussion context can be used to determine the topic boundaries of the meeting, which can be understood as the scope of topics covered in this meeting's discussion. This limits the processing scope of subsequent transcription analysis and task extraction, ensuring that processing focuses on the discussion topic without excessive digression.

[0021] Specifically, methods for obtaining discussion context include, but are not limited to: receiving information entered before the meeting starts, reading archived data of related meetings from historical records, and reading the context state accumulated in real time during the meeting. In one implementation, before the meeting starts, the workbench provides a context entry interface where users fill in information such as the meeting topic, the main idea of ​​the document to be reviewed, and known constraints in natural language, and can upload local reference attachments; the workbench loads the entered information and attachment content into the session state, forming the discussion context. In another implementation, if the current meeting is associated with a target meeting in the historical archive, the workbench retrieves the archived data of the target meeting and loads it into the session state as at least part of the discussion context.

[0022] Taking a specific application scenario as an example, before an architecture brainstorming session begins, the facilitator enters "Assess the feasibility of transforming the existing single-machine search service into a distributed architecture," uploads the current system architecture documentation and interface definition documentation, and checks the archive option for the previous "Search Service Performance Bottleneck Analysis" session. Based on this, the workbench determines the topic boundary of this meeting as "Feasibility of Distributed Transformation," and subsequent transcription and task extraction are all carried out around this boundary.

[0023] As a concrete implementation example, discussion context can be stored in the session state as structured fields, such as the session identifier as the key, recording fields like topic, constraint, attachment identifier list, and associated archive identifier, for reference in subsequent steps. Furthermore, discussion context can be dynamically updated; new key points and decisions generated during the meeting can be appended to the session state, allowing the topic boundaries to evolve with the discussion.

[0024] Step S102: Collect the audio of the meeting in real time and transcribe the audio into transcribed text.

[0025] In this embodiment, specifically, the acquired audio input streaming speech recognition pipeline processes the audio in frames, and outputs the corresponding text segment for each stable speech segment recognized, forming a transcribed text stream. The transcribed text stream accumulates chronologically to form a complete transcribed text. Streaming transcription can use a general cloud-based speech recognition service or a locally deployed speech recognition model; this disclosure does not limit its specific implementation.

[0026] Taking a specific application scenario as an example, in a multi-person requirements review meeting, the workbench simultaneously collects microphone audio from the speakers and system audio output from the meeting platform. The two audio streams are then mixed and fed into the streaming recognition engine. When someone says, "The authentication logic of the login module needs to be split," the recognition engine outputs the corresponding text "The authentication logic of the login module needs to be split" in real time and appends it to the transcribed text stream.

[0027] Step S103: Generate task items based on the transcribed text. The task items record the task objectives and completion standards.

[0028] In this embodiment of the disclosure, a task item can be understood as a record of task items with clear execution attributes extracted from the discussion content. A task item records the task objective and completion criteria: the task objective describes the result to be achieved, and the completion criteria describe the acceptance conditions for task completion. Task items may also include information such as task description, attribution of responsibility, and suggestions for next steps, providing a basis for subsequent handover and execution.

[0029] Specifically, task descriptions, objectives, and completion criteria are identified from transcribed text to form structured task items, thereby transforming ambiguous conclusions in discussions into executable and acceptable task assets. In one implementation, the transcribed text is input into a semantic analysis model, which identifies statements containing task semantics and extracts task objectives and completion criteria elements, filling them into a task item template. Task item determination can be based on semantics by the model or by combining rules (such as statements containing task indicator words like "need," "should," or "responsible").

[0030] Taking a specific application scenario as an example, when the transcribed text contains statements such as "We need to add a rate limiting module to ensure that no requests are dropped when the QPS reaches 5000" and "This task is the responsibility of Xiao Wang and must be completed by next week", the workbench extracts and generates a task item: the task description is "add a rate limiting module", the task goal is "no requests are dropped when the QPS reaches 5000", the completion standard is "completed by next week", and the responsibility is assigned to "Xiao Wang".

[0031] As a concrete implementation example, tasks can be stored in structured data format, including fields such as task identifier, task description, task objective, completion criteria, responsibility attribution, creation time, and status. The status of a task can include pending execution, in execution, or completed, and is updated during the handover and execution process.

[0032] In some embodiments, generated tasks can be displayed as task cards in the web-based meeting workbench. For example, the in-meeting collaboration page can render each task as a task card, displaying fields such as task description, task objectives, completion criteria, and responsibility attribution. Participants can directly view and perform subsequent operations on the task cards, thus presenting the tasks under discussion in an intuitive card format, facilitating real-time verification and confirmation by participants.

[0033] Step S104: Generate a multi-layered serialized handover packet based on the discussion context, task items, and decision information determined from the transcribed text.

[0034] The handover package can be understood as structured data that packages the results of meeting discussions into a unified package, which can be executed by external coded intelligent agents. Decision information can be understood as the decision records determined during the meeting, including the discussed and determined solutions, trade-off conclusions, and timelines. The multi-layered structure can be understood as a serialized structure that organizes different types of information hierarchically according to responsibilities, facilitating the identification and parsing of each layer's content by external coded intelligent agents.

[0035] Specifically, the discussion context, task items, and decision information generated in the meeting are merged and serialized into a handover package in a multi-layered structure. In one implementation, the handover package is organized into a target layer, a basis layer, an execution method layer, a completion standard layer, and a delivery method layer, with each layer carrying corresponding information. The serialization format may include structured formats (such as JSON), text formats (such as Markdown), or configuration formats (such as YAML), and this disclosure does not impose any restrictions on them.

[0036] Taking the aforementioned architecture brainstorming meeting as an example, at the end of the meeting, the workbench will merge the discussion context, tasks, and decision information such as "adopting a distributed architecture and introducing message queues to smooth out peaks" and generate a handover package according to a five-layer structure. The target layer records "complete the design of the distributed transformation plan for the search service", the basis layer records the architecture documents and discussion decisions before the meeting, the execution method layer records "refer to best practices for distributed transformation and output the transformation plan document", the completion standard layer records "the plan document has passed the review", and the delivery method layer records "deliver as the first draft of the specification document".

[0037] Step S105: The handover packet is provided to the external coding agent, which then parses the contents of each layer of the handover packet and continues to execute the task.

[0038] The external coding agent can be understood as a programming agent with code generation and file manipulation capabilities, running in a command-line interface or other interactive environment, and capable of calling the development toolchain to execute tasks. The external coding agent can be a general-purpose programming assistant or a coding agent deeply integrated with the development environment; this disclosure does not limit its specific form.

[0039] Specifically, the methods for providing the handover package to the external coding agent include, but are not limited to: writing the handover package to the system clipboard for pasting, writing it to a specified storage path for reading, and sending it via a communication interface. After parsing the contents of each layer of the handover package, the external coding agent reuses existing toolchains and continues to execute tasks based on the task objectives and completion standards recorded in the task items, directly producing deliverables such as technical solutions, draft specifications, or patch fixes. This step eliminates the manual transfer link between the end of the meeting discussion and the start of development, allowing the results of the meeting discussion to directly reach the coding agent through structured handover.

[0040] For example, after the aforementioned architecture brainstorming session, the user launches an external coding agent in the command-line interface and pastes the handover package into the agent's input box. After parsing the content of the target layer and the basis layer, the agent combines the requirements of the completion standard layer and the delivery method layer, calls the code repository retrieval and document generation capabilities, and directly outputs a draft of a distributed transformation plan document for team review.

[0041] In addition, the meeting discussion content can be exported as a readable document, such as exporting the complete discussion record in Markdown format, as a traceable record of the discussion process, making it easy for users to view and share.

[0042] According to the scheme of this disclosure embodiment, by real-time data acquisition and transcription, task item generation, multi-layer structure handover package generation and providing it to external coding intelligence for parsing and continuation, the discussion content in the meeting is structured into executable task assets, realizing the native flow of meeting discussion results to coding intelligence. This allows the meeting discussion results to directly reach the coding intelligence without going through intermediate links such as manual sorting, transporting, and pasting, eliminating the gap between the end of the discussion and the start of development, and improving the efficiency and continuity of the flow of meeting results to R&D tasks.

[0043] In one possible implementation, step S103 generates task items based on the transcribed text, specifically including the following steps: S131, Identify the task description, task objectives and completion criteria from the transcribed text, and generate task items; S132, if the task objectives and completion standards of the task items meet the preset quality threshold, the corresponding task items will be grouped into qualified task items. Among them, the tasks merged into the handover package are the target-achieving tasks.

[0044] In this embodiment, the preset quality threshold can be understood as the standard used to determine whether a task is feasible, such as whether the task objective is clear, whether the completion standard is explicit, and whether the task elements are complete. The quality threshold can be preset by the system or customized by the user for a meeting or project; this disclosure does not limit its specific value.

[0045] Specifically, in step S131, the task description, task objective, and completion criteria can be identified from the transcribed text through semantic analysis. The task description explains the content and scope of the task, the task objective describes the result to be achieved, and the completion criteria record the acceptance conditions. After identifying the above elements, a structured task item is generated. In one implementation, the transcribed text is input into a semantic analysis model, which outputs statements containing task semantics and their task elements, which are then filled into the task item template.

[0046] Taking a specific application scenario as an example, after semantic analysis of the transcribed text fragment "We need to add a rate limiting module so that no requests are lost when the QPS reaches 5000", the task description "add a rate limiting module" and the task objective "no requests are lost when the QPS reaches 5000" are identified, and an initial task item is generated. If the completion standard has not yet been clearly defined in the discussion, the task item does not yet meet the quality threshold.

[0047] In step S132, the generated task items are judged to meet quality standards. When the task objectives and completion standards recorded in the task item meet the preset quality threshold, the corresponding task item is grouped into qualified task items. In one implementation, the task objective field and completion standard field of each task item are checked one by one to see if they are not empty and are clearly described. If both are met, it is judged as a qualified task item.

[0048] Taking a specific application scenario as an example, after the discussion clarifies that "the completion standard of the rate limiting module is to pass the load test and not lose requests when the QPS reaches 5000", the task objective and completion standard of this task item are clear, and it is collected as a qualified task item and merged into the handover package; while the task item that only contains "optimize the homepage loading speed" without clear objectives and acceptance standards is not merged into the handover package because it does not meet the quality threshold.

[0049] According to the scheme of this disclosure embodiment, the generated task items are first judged to meet the quality standards. The task items whose task objectives and completion standards meet the preset quality thresholds are grouped into qualified task items. This ensures that the task items entering the handover package all have clear objectives and verifiable acceptance conditions, thus guaranteeing the quality of the task items in the handover package. This also ensures that the external coding agent only accepts task items that meet the acceptance conditions, preventing invalid tasks from flowing into subsequent processing.

[0050] In one possible implementation, such as Figure 3 As shown, the multi-layered structure of the handover package includes at least one of the following: target layer, basis layer, execution method layer, completion standard layer, and delivery method layer.

[0051] The target layer records the results to be achieved for each task; the basis layer records the discussion context and decision information on which the handover package is generated; the execution method layer records the toolchain used to execute the task; the completion standard layer records the acceptance conditions for the task; and the delivery method layer records the delivery form of the task.

[0052] In this embodiment, the target layer, basis layer, execution method layer, completion standard layer, and delivery method layer can be understood as a five-layer structure of the handover package divided according to information responsibilities. The target layer describes the desired outcome of the task, providing direction for the execution process; the basis layer records the discussion context and decision-making information, providing background and basis for execution; the execution method layer records the toolpaths, technical routes, and constraints used; the completion standard layer records the acceptance conditions for the execution process to determine whether the task is completed; and the delivery method layer records the delivery form of the task, such as a draft specification document, a patch, or code snippets. This five-layer structure separates the target, basis, execution, completion standard, and delivery method, avoiding information mixing and improving the recognition and processing efficiency of the external coded intelligent agent.

[0053] Specifically, the five-layer structure can be serialized into hierarchical structured data, such as organized as nested objects or segmented text. In one implementation, the handover package uses a JSON structured format, with the target, basis, execution method, completion standard, and delivery method as the top-level fields, and each field containing corresponding specific content. In another implementation, the handover package uses a Markdown text format, with each layer serving as a section heading to organize the content.

[0054] Taking a specific application scenario as an example, the handover package of a "login authentication splitting" task has the following layers: the target layer records "split the authentication logic of the login module into an independent service", the basis layer records "the distributed transformation plan determined at the meeting and the pre-meeting architecture document", the execution method layer records "refer to the best practice of message queue peak shaving and adopt service-oriented splitting", the completion standard layer records "the login interface passed the stress test after splitting and there was no functional regression", and the delivery method layer records "deliver the transformation plan document and code change list".

[0055] According to the scheme of this disclosure embodiment, through the hierarchical structure of responsibility layer, including target layer, basis layer, execution method layer, completion standard layer and delivery method layer, different types of information in the handover package are separated and organized. Since the information carried by each layer has a single and clear semantic meaning, the external coding agent can first read the target layer and completion standard layer to clarify the task requirements, then select the tool link according to the execution method layer, and finally determine the output form according to the delivery method layer. This avoids the parsing ambiguity caused by the interweaving of multiple layers of information and improves the parsability of the handover package and the accuracy of task continuation execution.

[0056] In one possible implementation, step S101 obtains the discussion context of the meeting, specifically including the following steps: S141, Before the meeting begins, receive the pre-context filled in natural language and / or receive the uploaded reference attachments; S142, bind the meeting to the project directory, which is the directory that stores the code files and documents of the project corresponding to the task; S143, Load the preceding context and / or reference attachments into the session state as the discussion context.

[0057] In this embodiment, the pre-context can be filled in by the user in natural language, used to describe information such as the meeting topic, the main idea of ​​the document to be reviewed, known constraints, and reference code links; reference attachments can be understood as documents or related reference content that need to be discussed and reviewed in the meeting, which can be local files uploaded by the user, such as product requirement documents, technical solution documents, and interface specification documents, or reference materials such as documents to be reviewed, PPT documents to be presented in the meeting, known constraints, and reference code links. The project directory can be understood as a directory that stores the code files and documents of the projects corresponding to the task items, used to establish an association between the meeting discussion results and specific projects.

[0058] Specifically, in step S141, the workbench provides a pre-context entry interface, where the user fills in the pre-context and / or uploads reference attachments; either the pre-context or the reference attachments can exist, or both can exist simultaneously, and the meeting is received if either one exists. In step S142, the meeting is bound to the project directory, for example, by selecting or entering the project directory path. In step S143, the received pre-context and / or reference attachments are loaded into the session state as the discussion context.

[0059] In one example, before the requirements alignment meeting begins, the product manager fills in the pre-context "Review the PRD for the new points mall requirement", uploads the PRD document, and binds it to the code directory of the current R&D project; the workbench loads the main idea and document content of the PRD into the session state, and subsequent task extraction is based on this discussion context, so that the extracted tasks match the actual code structure of the project.

[0060] According to the solution of this disclosure embodiment, by entering the pre-meeting context, uploading reference attachments and binding the project directory, the topic boundaries and semantic framework of the meeting discussion are preset. Since the subsequent transcription analysis and task extraction are based on the discussion context, the processing is constrained within the semantic range that is actually related to the project, avoiding generalized extraction that is out of context, making the generated task items match the actual structure of the project, and improving the accuracy of the processing results.

[0061] In one possible implementation, the method further includes the following steps: S151, Before the audio capture of the meeting begins, index each data unit in the loaded discussion context; S152, During the process of generating the transcribed text stream, a corresponding index is added to each transcribed segment; An index is used to record the mapping relationship between data units and storage locations.

[0062] In this embodiment of the disclosure, a data unit can be understood as an information unit that can be independently referenced within the discussion context, such as a piece of preceding context text, an attachment, a transcribed fragment, a decision record, etc. An index can be understood as a data structure that records the mapping relationship between data units and storage locations, similar to a dictionary directory, used for subsequent rapid data location.

[0063] Specifically, in step S151, before the conference audio acquisition begins, an index is created for each data unit in the loaded discussion context, forming a location mapping similar to a dictionary directory. In step S152, during the streaming generation of the transcribed text, a corresponding index is incrementally added to each transcribed segment. The index records the mapping relationship between data units and storage locations, used for subsequent rapid data location. Through the index, the data unit pointed to by the index can be located and read only during the handover phase, without traversing all the data, thereby speeding up the location process and saving processing overhead.

[0064] Taking a specific application scenario as an example, before the meeting begins, the workbench creates index entries for the "PRD for reviewing the new points mall requirement" text filled out before the meeting and the uploaded PRD document, recording their storage locations. During the meeting, each time a piece of transcribed text is generated, an index entry is added to that piece, marking its position in the transcribed text stream. In the subsequent handover phase, any data unit can be quickly located based on the index.

[0065] In one example, the index can be stored as key-value pairs, with the data unit identifier as the key and the storage location as the value; alternatively, it can be an inverted index, facilitating retrieval by content keywords. The indexing method can be incrementally maintained as the discussion context updates, avoiding duplicate indexing.

[0066] According to the scheme of this disclosure embodiment, by creating an index before the meeting and incrementally appending the index during the meeting, a location mapping is established for the data unit. Since the index records the mapping relationship between the data unit and the storage location, the target data can be located directly by the index during subsequent reading without traversing all the data, thus avoiding the time overhead caused by full scanning and improving the data reading efficiency.

[0067] In one possible implementation, step S104, which generates a handover packet by serializing it according to a multi-layer structure, further includes the following steps: S161, the indexes corresponding to the discussion context and task items are written as association pointers into the handover packet; wherein, the association pointers are used by the external coding agent to locate the corresponding data units according to the association pointers after parsing the handover packet, and only load the data units that are pointed to.

[0068] In this embodiment of the disclosure, the associated pointer can be understood as a reference information pointing to the storage location of the data unit, used to enable the external coded intelligent agent to locate the data as needed. The associated pointer can be carried in the handover packet, existing as a background index, and the association relationship is not displayed to the front end.

[0069] Specifically, in step S161, the indexes corresponding to the discussion context and task items are written as associated pointers into the handover packet. These associated pointers exist as background indexes, used by the external coding agent to locate the corresponding data units after parsing the handover packet. Since the data entered before the meeting started has been pre-indexed, and the data generated during the meeting is also indexed segment by segment, the external coding agent only needs to load the pointed-to data unit, without loading the entire context, thus quickly locating the corresponding data, saving processing time and reducing processing overhead.

[0070] Taking a specific application scenario as an example, when the target layer in the handover packet references "Points Mall PRD", its associated pointer points to the storage location of the PRD document; after the external encoding agent parses the pointer, it only reads the content of the PRD document as a basis, without having to load the entire transcribed text of the entire meeting, thereby quickly locating the corresponding data, saving processing time and reducing processing overhead.

[0071] In one example, associated pointers can be implemented in the form of Uniform Resource Identifiers, relative paths, or data block identifiers; external coded agents can read on demand based on pointers, avoiding full data loading.

[0072] According to the scheme of this disclosure embodiment, by writing the index as an associated pointer into the handover packet, the handover packet carries reference information but does not carry all the data itself. The external coding agent locates according to the pointer and only loads the data unit that is pointed to. There is no need to load the entire transcribed text and context of the entire meeting, which significantly reduces the amount of data entering the coding agent's context, reduces the data scale and overhead of subsequent processing, and improves the efficiency of continuation execution.

[0073] In one possible implementation, step S102 involves real-time acquisition of the conference audio, specifically including the following steps: S171, acquire the audio from the microphone input source and the audio from the system sound source to obtain two audio channels; S172, Time-align the two audio streams and remove duplicate speech segments from the two audio streams to obtain the target audio; S173, stream the target audio; the system sound source includes the tab audio output from the conferencing platform.

[0074] The system audio sources include tab audio output from the conferencing platform.

[0075] In this embodiment of the disclosure, the microphone input source can be understood as an audio input source that captures the sound of on-site speech, such as a built-in or external microphone of the device. The system sound source can be understood as an audio input source that captures the audio output from an electronic device, such as the tab audio output from a conference platform. Dual-source hybrid acquisition can be understood as simultaneously acquiring audio from two sources and merging them to ensure that no speech source is missed.

[0076] In step S171, the microphone input source and the system sound source are simultaneously accessed for dual-source acquisition, resulting in two audio streams. The microphone input source acquires the on-site speaking sound, and the system sound source acquires the sound output from the conference platform, including the tab audio output from the conference platform. In step S172, the two audio streams are time-aligned to align corresponding sounds at the same time on the timeline. Based on this, duplicate speaking segments are detected and removed from the two audio streams to obtain the target audio, preventing the same speaking content from being recorded repeatedly during transcription. In step S173, the target audio is streamed and transcribed.

[0077] In one implementation, system sound sources are acquired through the system audio interface, and microphone input sources are acquired through the browser media interface. The two audio streams are synchronized and then merged into one stream, which is then sent to the streaming recognition engine.

[0078] For example, in a remote video conference, the host speaks live using a microphone, while the voices of remote participants are output through the conference platform. The workstation simultaneously captures the microphone audio and the system audio output from the conference platform, mixes the two streams, and transcribes them to ensure that both live and remote speeches are recorded.

[0079] If only one audio stream can be acquired (e.g., only microphone audio or only system sound audio), streaming transcription can still be performed based on the acquired audio stream, which can still cover the speech content from the corresponding source.

[0080] According to the solution of this disclosure embodiment, by using dual-source mixed acquisition of microphone and system sound, multiple audio sources such as on-site speech and remote output are covered. Since the two audio streams are mixed and sent to streaming transcription in a unified manner, speech from either source will not be missed due to a single acquisition source, thus avoiding the omission of speech due to a single acquisition source and improving the completeness of the transcribed content.

[0081] In one possible implementation, the method further includes the following steps: S181, retrieve the list of attendees entered before the meeting; S182, perform speaker separation on the audio and annotate the speaker for the transcribed text; S183, in response to the operation of mapping the speaker to a participant in the participant list, associates the participant identity with the corresponding transcribed text.

[0082] In this embodiment, the list of attendees can be understood as a list of attendee information entered before the meeting begins, used for subsequent identity mapping. Speaker separation can be understood as the process of distinguishing the voices of different speakers in the audio and labeling each transcribed text segment with a speaker identifier. Attendee identity can be understood as the correspondence between the transcribed text and the specific attendee.

[0083] In step S181, the participant list is entered before the meeting begins for subsequent identity mapping. In step S182, speaker separation is performed on the collected audio to distinguish the voices of different speakers, and speaker identifiers are added to the transcribed text. Speaker separation can distinguish different speakers, but the specific speaker can be manually assigned. In step S183, the operator maps the speaker identifiers to the corresponding participants in the participant list, associating the transcribed text with the participant's identity and giving the transcribed text information about the speaker's attribution.

[0084] For example, before the meeting starts, the list of participants, "Wang, Li, Zhang", is entered; during the meeting, the speaker separation engine divides the transcribed text into several segments and marks them with identifiers such as "Speaker A" and "Speaker B"; the host maps "Speaker A" to "Wang", and then the transcribed text of that segment is associated with Wang's identity, making it easy to trace "who proposed which task and who is responsible for it".

[0085] As a concrete implementation example, speaker separation can be achieved through methods such as voiceprint clustering or online incremental differentiation; identity mapping can be completed once (e.g., binding the speaker of the current segment to a participant in the list) or adjusted multiple times during the meeting.

[0086] According to the solution of this disclosure embodiment, by separating the speaker and manually mapping the pre-meeting list, the transcribed text is associated with the identity of the participants, so that the discussion content has a speaker attribution. Subsequently, when tasks are extracted and signed, it is possible to trace "who proposed which task, who is responsible for it, and who confirmed it" according to the speaker, which provides a verifiable basis for task responsibility attribution and decision-making traceability, and facilitates the subsequent tracing of task attribution and decision-making responsibility according to the speaker.

[0087] In one possible implementation, before step S103 generates the task item based on the transcribed text, the method further includes the following steps: S191, identifies the final identification node in the transcription process; S192, determine whether the transcribed content before the final identification node contains task semantic elements, including task objective description and / or completion standard description; S193, when the task semantic elements are included, the transcribed content before the final identification node is merged with the semantically related candidate tasks in the accumulated candidate tasks to generate a candidate task list. S194, Generate task items based on the transcribed text, based on the candidate task list.

[0088] In this embodiment of the disclosure, the final recognition node can be understood as the final confirmation node of a speech recognition result in streaming speech recognition, and the transcribed content before it is the stable text of that node. Task semantic elements can be understood as feature elements used to determine whether the transcribed content possesses task semantics, including at least one of task objective description and completion standard description. The task objective description describes the result to be achieved by the task, and the completion standard description describes the acceptance conditions for task completion.

[0089] In step S191, the final recognition node is identified during the streaming transcription process. The final recognition node represents the final confirmation result of a speech recognition segment, and the transcribed content preceding it is the stable text of that node. In step S192, it is determined whether the transcribed content preceding the final recognition node contains task semantic elements, i.e., whether it contains a description of the task objective and / or a description of the completion criteria. In step S193, if the task semantic elements are included, the transcribed content preceding the final recognition node is merged with semantically related candidate tasks from the accumulated candidate tasks until the task semantics of the candidate task are complete, generating a candidate task list; if the task semantic elements are not included, the process continues listening to subsequent content.

[0090] Taking the aforementioned application scenario of the rate limiting module as an example, during the streaming transcription process, the recognition engine outputs a text that says "We need to add a rate limiting module so that requests are not dropped when the QPS reaches 5000" and marks it as the final recognition node. This text constitutes a complete task, and the workbench generates a candidate task list based on it. However, content such as "And then, I think it can be optimized a bit more" does not constitute a complete task and is not included in the candidate task list.

[0091] As a concrete implementation example, the determination of a complete task can be made by the model based on semantics, or it can be made in combination with rules (such as detecting a sentence that contains task indicator words and is semantically complete); the candidate task list can be gradually accumulated and updated as the final identification node appears.

[0092] According to the scheme of this disclosure embodiment, the final identification node is identified during the streaming transcription process. By identifying the final identification node and determining whether the transcribed content contains task semantic elements, the transcribed content with task semantics and semantic relevance is merged across nodes into a semantically complete candidate task. This makes the generation of executable tasks based on clear semantic boundaries, which avoids misjudging fragmented content without task semantics as tasks and ensures that the same task across multiple segments is completely collected, thus improving the accuracy of task extraction.

[0093] In one possible implementation, the method further includes the following steps: S1101, At the end of the meeting, list the tasks that were drawn up; S1102, in response to the participant's check-in operation for the task item, records the signer, the checked task item and the signing timestamp, and generates a signing record; Among them, the tasks merged into the handover package are the signed tasks.

[0094] In this embodiment of the disclosure, the signature trace can be understood as data that records signature confirmation information, used to ensure that the consensus reached in the discussion has a traceable confirmation attribution. The signer can be understood as the participant who performs the checkmark operation to confirm the task. The signature timestamp can be understood as the time information that records the moment the signature occurred.

[0095] In step S1101, at the end of the meeting, the task list is automatically compiled and displayed for participants to check. In step S1102, participants check each item on the webpage and manually check and sign it. The system records the signatory, the checked task, and the signing timestamp, generating a signature record that indicates "who approves what" along with the timestamp. When merging to generate a handover package, the merged task items are the signed task items, ensuring that the task items in the handover package have confirmed ownership.

[0096] For example, the meeting end page lists all tasks. Wang selects and signs the "Add Traffic Limiting Module" task. The workbench records that the signer is Wang, the signed task identifier, and the signing timestamp. When merging tasks in the handover package, only signed tasks are merged. Unsigned tasks or tasks marked with objections are not included in the handover package.

[0097] In one implementation, the signature record can be stored in the form of a record table, which includes fields such as task identifier, signer, signing timestamp, and signing status; the signing operation can be performed one by one or in batches; unsigned tasks can be reconfirmed in subsequent meetings.

[0098] According to the solution of this disclosure embodiment, by checking the signature and timestamp recording, the task item is given a confirmation attribution attribute, and the confirmation attribution of each task item is verifiable, avoiding the misunderstanding caused by relying solely on verbal consensus afterward, and making the discussion consensus traceable.

[0099] In one possible implementation, the method further includes the following steps: S1111, in response to the wake-up operation during the meeting, inputs the accumulated transcribed text into the model, and identifies unresolved issues from the transcribed text that have not yet reached a consensus as discussion checkpoints; S1112, Generate candidate solution comparison information and suggestion information for the discussion bottleneck; S1113, based on the accumulated transcribed text, completes the missing task elements of the unresolved issues and outputs action suggestions.

[0100] In this embodiment, the wake-up operation can be understood as an operation triggered by the user to intervene in the AI ​​during a meeting, such as clicking a wake-up button. Unresolved issues can be understood as points in the accumulated transcribed text where consensus has not yet been reached, where disagreements exist, or where information is missing, such as disagreements on the selection of candidate solutions. Candidate solution comparison information can be understood as information comparing multiple candidate solutions, such as a comparison of the advantages and disadvantages of different technical solutions. Discussion deadlocks can be understood as points in the discussion where it cannot continue, where disagreements exist, or where information is missing. Action suggestions can be understood as next steps and action items suggested by the AI ​​based on the discussion content.

[0101] Specifically, in step S1111, when a discussion stalls during the meeting, the user clicks to wake up the AI ​​member, inputting all previously accumulated transcribed text into the model. The model then identifies unresolved issues from the transcribed text that have not yet reached a consensus, designating them as discussion stalls. In step S1112, candidate solution comparison information and suggestions are generated for this discussion stall, such as providing a comparison of the technical selection of different candidate solutions and recommendations. In step S1113, the missing task elements for this unresolved issue are supplemented based on the accumulated transcribed text, and suggestions for the next action are output. The wake-up operation can be paused or triggered at any time, with the pace controlled by the user.

[0102] In some embodiments, in response to a wake-up operation, technical ideas, solution comparison results, or directly reusable code snippets, fixes, and their accompanying prompts can be output in real time, so that code drafts can be obtained on the spot during the discussion, and the post-event summary can be moved to the meeting, and the product can be upgraded from human-read documents to machine-executable prototypes.

[0103] According to the solution of this disclosure embodiment, when a discussion reaches a bottleneck during the meeting, the user triggers a wake-up operation, inputting all previously accumulated transcribed text into the model to identify the bottleneck and generate suggestions. At the same time, missing elements are filled in based on existing content. Since the AI ​​intervenes in real time during the discussion rather than afterward, the team can obtain targeted suggestions on the spot when encountering obstacles, without having to interrupt the discussion to look them up separately. This shortens the discussion stagnation time, transforms the AI ​​from an observer into a collaborator, and improves discussion efficiency.

[0104] In one possible implementation, step S105 provides the handover packet to the external coded agent, including at least one of the following methods: S1121, Write the handover packet to the system clipboard so that it can be pasted to the external coded agent in the command line interface; S1122, Write the handover packet to the specified storage path for external coded intelligent agents to read; S1123, via the interface for communicating with the external coded agent, sends a handover packet to the external coded agent.

[0105] In this embodiment, the system clipboard can be understood as a temporary data cache area provided by the electronic device, supporting copy and paste operations. The specified storage path can be understood as a pre-determined file storage location, such as the handover package file path under the project directory. The communication interface can be understood as an interface for establishing data transmission with external coded intelligent agents, such as an inter-process communication interface, a network interface, or a command-line pipe.

[0106] In step S1121, the handover packet is written to the system clipboard in the form of a continuation context or a Prompt, which the user can then paste into the command-line interface to complete the provision. In step S1122, the handover packet is written to a specified storage path, from which the external coding agent reads it. In step S1123, the handover packet is sent directly via the interface for communicating with the external coding agent. All three methods can provide the handover packet to the external coding agent; any method can be chosen depending on the usage environment.

[0107] In one example, when a user uses a coding agent via a command-line interface, the workbench writes the handover package content to the system clipboard, and the user pastes it into the agent's input box to complete the handover. If the user prefers file handover, the workbench writes the handoff package to the handoff file in the project directory, and the agent reads the file. If the workbench and the agent are integrated in the same environment, the workbench can also send the handover package directly to the agent via the communication interface.

[0108] According to the scheme of the embodiments of this disclosure, the handover packet can be flexibly delivered to the external coding agent through various delivery methods such as clipboard pasting, storage path reading or communication interface sending, adapting to different usage environments, and ensuring that the handover packet can reliably reach the coding agent in different deployment environments, thereby improving the adaptability and availability of the handover link.

[0109] In one possible implementation, step S105 continues the execution of the task, specifically including the following steps: S1131, assign independent coding execution agents to the multiple tasks in the handover package, and let each coding execution agent handle the assigned tasks. S1132, after all the coding execution agents have completed their processing, the integration agent integrates the processing results and outputs the integrated task result.

[0110] In this embodiment of the disclosure, the coding execution agent can be understood as a coding-type agent used to perform specific task processing, and may have capabilities such as code generation and file operation. The integrating agent can be understood as an agent that uniformly integrates the processing results of multiple coding execution agents.

[0111] For multiple tasks within a handover package, independent coding execution agents are assigned to each. Each coding execution agent performs its own task, avoiding context pollution caused by multiple tasks being fully input into the same agent and speeding up task execution. After all coding execution agents have completed their processing, an integration agent unifies and combines the results to determine the output, resulting in the integrated task outcome.

[0112] Taking the aforementioned rate limiting module scenario as an example, the handover package includes three tasks: "designing the rate limiting module interface", "writing the load testing script", and "updating the architecture document". The workbench assigns three independent coding execution agents to process the three tasks in parallel. After processing, the integration agent integrates the three results into a complete transformation delivery result.

[0113] According to the scheme of this disclosure embodiment, by independently encoding and executing the intelligent agent for each task, the divide-and-conquer processing and the unified integration of the intelligent agent are combined to avoid the full information of multiple tasks entering the context of a single intelligent agent at the same time. Since the processing contexts of each task are isolated from each other, the information between tasks will not interfere with each other, reducing context pollution. At the same time, multiple tasks can be processed in parallel, shortening the total processing time of all tasks. Then, the integrated intelligent agent integrates the processing results, improving the overall efficiency of multi-task processing and the consistency of output.

[0114] In one possible implementation, the method further includes the following steps: S1141, after the meeting ends, archives the meeting discussion records, tasks, and handover packages to local storage, using each meeting as an isolated unit; The archived data from different meetings are isolated from each other.

[0115] In this embodiment of the disclosure, in step S1141, after the meeting ends, the discussion records and tasks are automatically archived in the historical archive, with each meeting as an isolated unit, and stored locally to retain the complete context chain. Archived data from different meetings are isolated from each other, avoiding cross-contamination of contexts between multiple meetings. Archived data can be retrieved as needed in subsequent new meetings.

[0116] In one specific example, archived data can be organized by meeting identifier in the form of a directory or data set, including meeting metadata, discussion records, task items, handover packages, and other files; archived data can be retained locally or synchronized to the cloud with user authorization.

[0117] According to the solution of this disclosure embodiment, by isolating and archiving a single meeting locally, the subsequent processing of data from a certain meeting will not be affected by the content of other meetings, avoiding cross-meeting context pollution, while retaining a complete discussion chain, providing a foundation for the accumulation of organizational discussion assets.

[0118] In one possible implementation, step S101 obtains the discussion context of the meeting, specifically including the following steps: S1151, in response to the selection of the target meeting in the historical archive when creating a new meeting, retrieve the archived data of the target meeting; S1152, associate archived data with the session state of the new meeting as at least part of the discussion context of the new meeting.

[0119] In this embodiment of the disclosure, the target meeting can be understood as a meeting that the user has selected to associate in the historical archive. Cross-meeting association can be understood as establishing an association between the new meeting and the archived data of the historical meeting in order to recall the historical discussion context.

[0120] Specifically, when creating a new meeting, users can select a target meeting from the historical archive to associate with, for example, a second discussion on the same topic, by selecting the previous archive beforehand. In response to this selection, the archived data of the target meeting is retrieved. This retrieved archived data is then associated with the session state of the new meeting, serving as at least part of the new meeting's discussion context, enabling the new meeting to recall historical discussions. Cross-session associations are manually selected by the user, rather than automatically aggregated, balancing lightweight design with continuity.

[0121] For example, when a user creates a "Second Review of Points Mall Requirements" meeting, they can check the box to associate it with the "Points Mall Requirements Review" meeting in the historical archive. The workbench will retrieve the archived data from the previous meeting and load the new meeting session state, so that when the new meeting discusses the "Points Mall" topic, it can directly refer to the solutions and legacy tasks that have been determined in the previous meeting.

[0122] According to the solution of this disclosure embodiment, by manually selecting the cross-site association of historical archives before the meeting, the new meeting can recall the historical discussion context, realize the tracking and evolution of multiple rounds of discussion on the same topic, and avoid the context confusion caused by automatic aggregation.

[0123] In one possible implementation, the conference data processing method is executed by a web-based conference workbench, responding to a session creation operation initiated by any participant on the web page, creating a session and loading the discussion context without account registration or login.

[0124] In this embodiment, the web-based conference workbench can be understood as a conference processing client running in a browser environment, undertaking functions such as audio acquisition, real-time transcription and presentation, AI triggering, and handover packet generation. A session can be understood as a running instance of a conference processing procedure, including the conference status and discussion context.

[0125] Specifically, the meeting data processing method runs on a web-based meeting workbench, accessible to any participant simply by opening the webpage; no account system is required. Any participant can initiate a session creation operation on the webpage, creating a session and loading the discussion context without account registration or login. The web-based meeting workbench serves as the primary client, handling audio capture, real-time transcription, AI triggering, and handover packet generation.

[0126] For example, when a team is brainstorming offline, any member can open the meeting workbench website in a browser, create a session, enter the pre-context, and start listening without registering or logging in. Other members can also directly access the same session to participate in the discussion.

[0127] According to the solution of this disclosure embodiment, the web-based meeting workbench and the account-free, ready-to-use usage mode eliminate the need for pre-registration or login to start the service. Any participant can join by opening the workbench in a browser, eliminating the preconditions for use brought by the account system. This allows participants who join temporarily to also join the same session immediately, lowering the threshold for use and improving ease of use.

[0128] In one possible implementation, such as Figure 4As shown, the web-based meeting workbench interface is divided into four pages according to the meeting lifecycle: pre-meeting preparation, in-meeting collaboration, post-meeting delivery, and historical archive. Discussion context is entered on the pre-meeting preparation page; transcribed text and tasks are presented on the in-meeting collaboration page; handover packages are generated on the post-meeting delivery page; and discussion records and tasks for each meeting are managed on the historical archive page. These four pages are connected by a unified session state to ensure data continuity throughout the page flow.

[0129] In this embodiment, the pre-meeting preparation page is used for pre-meeting context input and project directory binding; the in-meeting collaboration page presents the listening and wake-up process in real time with audio recordings, AI output, task cards, and other content; the post-meeting delivery page handles deliverable verification and signing, and allows for one-click handover and export of packaged deliverables; the history archive page centrally stores all discussion records and task items and supports cross-session tracing. The four pages are connected via a unified session state transition, ensuring that the discussion flow is not interrupted or lost during page transitions.

[0130] According to the solution of this disclosure embodiment, by dividing the meeting into four functional pages according to the meeting lifecycle and connecting them with a unified session state, the meeting data remains continuous during the page transition, thereby improving the continuity of interaction.

[0131] Figure 5 This is a flowchart illustrating a meeting data processing method according to another embodiment of this disclosure. Figure 5 As shown, the method includes, but is not limited to, steps S501 to S523. Figure 5 The illustrated embodiment combines the complete steps of the foregoing embodiments, and each step is described in detail below.

[0132] Step S501: Receive the prior context filled in natural language and / or the uploaded reference attachments.

[0133] Step S502: Bind the meeting to the project directory, which is a directory that stores the code files and documents of the project corresponding to the task.

[0134] Step S503: Load the prior context and / or reference attachments into the session state as the discussion context, and obtain the list of participants entered before the meeting.

[0135] Step S504: Before the audio acquisition of the meeting begins, index each data unit in the loaded discussion context is created.

[0136] Step S505: Real-time acquisition of conference audio, acquisition of audio from microphone input source and audio from system sound source, to obtain two audio streams.

[0137] Step S506: Mix the two audio streams and then perform streaming transcription to obtain the transcribed text.

[0138] Step S507: During the process of generating the transcribed text stream, add corresponding indexes to each transcribed segment.

[0139] Step S508: Speaker separation is performed on the audio, the speaker is labeled for the transcribed text, and in response to the operation of mapping the speaker to the participants in the participant list, the participant identity is associated with the corresponding transcribed text.

[0140] Step S509: Identify the final identification node in the streaming transcription.

[0141] Step S510: If the transcribed content before the final identification node constitutes a complete task, a candidate task list is generated based on the transcribed content of the complete task.

[0142] Step S511: Extract task items from the transcribed text based on the candidate task list, identify task descriptions, task objectives and completion criteria, and generate task items.

[0143] Step S512: If the task objectives and completion standards of the task items meet the preset quality threshold, the corresponding task items are grouped into qualified task items.

[0144] Step S513: At the end of the meeting, list the extracted tasks, respond to the participants' selection of tasks, record the signer, the selected task and the signing timestamp, and generate a signing record.

[0145] Step S514: Merge the discussion context, task items, and decision information generated in the meeting; write the indexes corresponding to the discussion context and task items as associated pointers into the handover package; and serialize the handover package according to the multi-layer structure of target layer, basis layer, execution method layer, completion standard layer, and delivery method layer.

[0146] Step S515: The handover packet is provided to the external coding agent, which then parses the contents of each layer of the handover packet and continues to execute the task.

[0147] Step S516: Assign independent code execution agents to the multiple tasks in the handover package, and have each code execution agent handle the assigned tasks.

[0148] Step S517: After all the coding execution agents have completed their processing, the integration agent integrates the processing results and outputs the integrated task result.

[0149] Step S518: After the meeting ends, archive the meeting discussion records, tasks, and handover packages to local storage, using each meeting as an isolated unit.

[0150] In addition to the above steps, the method also includes an optional step S519: in response to a wake-up operation during a meeting, inputting the accumulated transcribed text into the model, identifying discussion bottlenecks and generating suggested information for the bottlenecks, and supplementing task elements based on the accumulated transcribed text to output action suggestions.

[0151] When the newly created meeting includes historical meetings, the method also includes the following steps: Step S520: In response to the selection of the target meeting in the historical archive when creating a new meeting, retrieve the archived data of the target meeting.

[0152] Step S521: Associate the archived data with the session state of the new meeting as at least part of the discussion context of the new meeting.

[0153] Step S522: In response to a session creation operation initiated by any participant on the web page, create a session and load the discussion context without registering or logging in to an account.

[0154] Step S523: By connecting the unified session states of the four pages, the data of the meeting is kept continuous during the page transition.

[0155] According to the solution of this disclosure embodiment, by executing the above complete steps in sequence, a complete closed loop is realized from pre-meeting preparation, in-meeting listening and wake-up, post-meeting verification and signing, one-click handover to archiving, so that the meeting discussion results can be directly delivered to the coded intelligent agent through structured handover, without the need for manual handling throughout the process, effectively avoiding creative decay and improving circulation efficiency.

[0156] Figure 6 This is a structural schematic diagram of a conference data processing apparatus 600 provided according to an embodiment of this disclosure. (See attached diagram.) Figure 6 As shown, the device includes: Module 601 is used to obtain the discussion context of the meeting; The acquisition and transcription module 602 is used to acquire the audio of the meeting in real time and transcribe the audio into transcribed text; The task extraction module 603 is used to generate task items based on the transcribed text. The task items record the task objectives and completion standards. The handover packet generation module 604 is used to generate a multi-layered serialized handover packet based on the discussion context, task items, and decision information determined from the transcribed text. Module 605 is provided to provide the handover packet to an external coding agent, which then parses the contents of each layer of the handover packet and continues to execute the task.

[0157] In one possible implementation, the task extraction module 603 is used for: Identify task descriptions, objectives, and completion criteria from transcribed text to generate task items; If the task objectives and completion standards of a task item meet the preset quality threshold, the corresponding task items will be grouped into qualified task items.

[0158] Among them, the tasks merged into the handover package are the target-achieving tasks.

[0159] In one possible implementation, the multi-layered structure of the handover package includes a target layer, a basis layer, an execution method layer, a completion standard layer, and a delivery method layer. The target layer records the results to be achieved by the task corresponding to the task item. The basis layer records the discussion context and decision information on which the handover package is based. The execution method layer records the tool chain used to execute the task. The completion standard layer records the acceptance conditions of the task. The delivery method layer records the delivery form of the task.

[0160] In one possible implementation, the acquisition module 601 is used for: Before the meeting begins, receive the pre-conference context filled in natural language, and / or receive the uploaded reference attachments; Bind the meeting to the project directory, which is the directory that stores the code files and documents of the project corresponding to the task; Load the preceding context and / or reference attachments into the session state as the discussion context.

[0161] In one possible implementation, the device further includes: The index building module is used to build an index for each data unit in the loaded discussion context before the audio acquisition of the meeting begins; and to add a corresponding index to each transcribed segment during the transcribed text streaming generation process; the index is used to record the mapping relationship between data units and storage locations.

[0162] In one possible implementation, the handover packet generation module 604 is used for: The indexes corresponding to the discussion context and task items are written as association pointers into the handover packet. The association pointers are used by the external coding agent to locate the corresponding data units after parsing the handover packet, and only the data units that are pointed to are loaded.

[0163] In one possible implementation, the acquisition and transcription module 602 is used for: The system acquires audio from both the microphone input source and the system sound source, resulting in two audio streams. It then performs time alignment on the two audio streams to ensure that corresponding sounds at the same moment are aligned on the timeline. Finally, it performs streaming transcription on the target audio. The system sound source includes the tab audio output from the conferencing platform.

[0164] In one possible implementation, the device further includes: The identity association module is used to obtain the list of participants entered before the meeting; perform speaker separation on the audio and label the speakers for the transcribed text; respond to the operation of mapping the speakers to the participants in the participant list and associate the participant identity with the corresponding transcribed text.

[0165] In one possible implementation, the task extraction module 603 is also used for: Identify the final identification node in the streaming transcription; determine whether the transcribed content before the final identification node contains task semantic elements, including task objective descriptions and / or completion standard descriptions; if task semantic elements are included, merge the transcribed content before the final identification node with semantically related candidate tasks from the accumulated candidate tasks until the task semantics of the candidate tasks are complete, and generate a candidate task list; generate task items based on the transcribed text and perform the task based on the candidate task list.

[0166] In one possible implementation, the device further includes: The signing module is used to list the extracted tasks at the end of the meeting; in response to the participants' selection of tasks, it records the signer, the selected tasks, and the signing timestamp, generating a signing record; among them, the tasks merged in the handover package are the signed tasks.

[0167] In one possible implementation, the device further includes: The wake-up module is used to respond to wake-up operations during the meeting. It inputs the accumulated transcribed text into the model, identifies unresolved issues that have not yet reached a consensus from the transcribed text as discussion checkpoints, generates candidate solution comparison information and suggestion information for discussion checkpoints, fills in the missing task elements of unresolved issues based on the accumulated transcribed text, and outputs action suggestions.

[0168] In one possible implementation, module 605 is provided for: Write the handover packet to the system clipboard for pasting into the external coding agent in the command-line interface; write the handover packet to the specified storage path for the external coding agent to read; send the handover packet to the external coding agent via the interface for communication with the external coding agent.

[0169] In one possible implementation, module 605 is also used for: Each task in the handover package is assigned an independent coding execution agent, which handles its assigned task. After all coding execution agents have completed their processing, the integration agent integrates the processing results and outputs the integrated task result.

[0170] In one possible implementation, the device further includes: The archiving module is used to archive meeting discussion records, task items, and handover packages to local storage after the meeting ends, with each meeting as an isolated unit; the archived data from different meetings are isolated from each other.

[0171] In one possible implementation, the acquisition module 601 is also used for: In response to the selection of a target meeting in the historical archive when creating a new meeting, retrieve the archived data of the target meeting; associate the archived data with the session state of the new meeting as at least part of the discussion context of the new meeting.

[0172] In one possible implementation, the device further includes: The session creation module is used to respond to any session creation operation initiated by a participant on the web page, creating a session and loading the discussion context without requiring account registration and login.

[0173] In one possible implementation, the device further includes: The page management module is used to divide the web-based meeting workbench interface into four pages according to the meeting lifecycle: pre-meeting preparation page, in-meeting collaboration page, post-meeting delivery page, and historical archive page. Discussion context is entered on the pre-meeting preparation page; transcribed text and tasks are presented on the in-meeting collaboration page; handover packages are generated on the post-meeting delivery page; discussion records and tasks for each meeting are managed on the historical archive page; the four pages are connected through a unified session state to ensure that meeting data remains continuous during page transitions.

[0174] The specific implementation of the conference data processing device is basically the same as the specific embodiment of the conference data processing method described above, and will not be repeated here.

[0175] According to the scheme of this disclosure embodiment, the device, through the collaboration of the acquisition module, the acquisition and transcription module, the task extraction module, the handover package generation module and the providing module and their extension modules, realizes the structured handover of meeting discussion results to external coding intelligent agents, thereby improving the efficiency and continuity of the flow of meeting results to R&D tasks.

[0176] The specific functions and examples of each module and submodule of the apparatus in this disclosure can be found in the relevant descriptions of the corresponding steps in the above method embodiments, and will not be repeated here.

[0177] The acquisition, storage, and application of any type of information, such as user personal information, involved in the technical solutions disclosed herein comply with relevant laws and regulations and do not violate public order and good morals.

[0178] According to embodiments of this disclosure, this disclosure also provides an electronic device, a readable storage medium, and a computer program product.

[0179] Figure 7 A schematic block diagram of an example electronic device 700 that can be used to implement embodiments of the present disclosure is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0180] like Figure 7 As shown, device 700 includes a computing unit 701, which can perform various appropriate actions and processes based on a computer program stored in read-only memory (ROM) 702 or a computer program loaded into random access memory (RAM) 703 from storage unit 708. The RAM 703 may also store various programs and data required for the operation of device 700. The computing unit 701, ROM 702, and RAM 703 are interconnected via bus 704. Input / output (I / O) interface 705 is also connected to bus 704.

[0181] Multiple components in device 700 are connected to I / O interface 705, including: input unit 706, such as keyboard, mouse, etc.; output unit 707, such as various types of monitors, speakers, etc.; storage unit 708, such as disk, optical disk, etc.; and communication unit 709, such as network card, modem, wireless transceiver, etc. Communication unit 709 allows device 700 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0182] The computing unit 701 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 701 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 701 performs the various methods and processes described above, such as conference data processing methods. For example, in some embodiments, the conference data processing method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 708. In some embodiments, part or all of the computer program may be loaded and / or installed on device 700 via ROM 702 and / or communication unit 709. When the computer program is loaded into RAM 703 and executed by the computing unit 701, one or more steps of the conference data processing method described above may be performed. Alternatively, in other embodiments, the computing unit 701 may be configured to perform conference data processing methods by any other suitable means (e.g., by means of firmware).

[0183] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0184] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0185] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0186] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0187] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as a data server), or computing systems that include middleware components (e.g., an application server), or computing systems that include frontend components (e.g., a user computer with a graphical user interface or web browser through which a user can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., a communication network). Examples of communication networks include local area networks (LANs), wide area networks (WANs), and the Internet.

[0188] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0189] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0190] The specific embodiments described above do not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A method for processing conference data, comprising: Obtain the discussion context of the meeting; The audio of the meeting is collected in real time and transcribed into text. Task items are generated based on the transcribed text, and the task items have task objectives and completion criteria; Based on the discussion context, the task items, and the decision information determined from the transcribed text, a multi-layered serialized handover packet is generated; The handover packet is provided to an external coding agent, which then parses the contents of each layer of the handover packet and continues to execute the task.

2. The method according to claim 1, characterized in that, The step of generating task items based on the transcribed text includes: The task description, task objectives, and completion criteria are identified from the transcribed text, and the task items are generated. If the task objectives and completion standards of the task items meet the preset quality threshold, the corresponding task items will be grouped into qualified task items. The task items included in the handover package are the target achievement task items.

3. The method according to claim 1, characterized in that, The multi-layered structure includes a target layer, a basis layer, an execution method layer, a completion standard layer, and a delivery method layer. The target layer records the results to be achieved for the task. The basis layer records the discussion context and decision information on which the handover packet is generated; The execution method layer records the toolchain used to execute the task. The completion standard layer records the acceptance criteria for the task items; The delivery method layer records the delivery format of the task.

4. The method according to claim 1, characterized in that, The process of obtaining the discussion context of the meeting includes: Before the meeting begins, receive a pre-context filled in natural language and / or receive uploaded reference attachments; The meeting is bound to a project directory, which is a directory that stores the code files and documents of the project corresponding to the task. The preceding context and / or the reference attachment are loaded into the session state as the discussion context.

5. The method according to claim 4, characterized in that, Also includes: Before the audio capture of the meeting begins, an index is created for each data unit in the loaded discussion context; During the process of generating the transcribed text stream, a corresponding index is appended to each transcribed segment; The index is used to record the mapping relationship between data units and storage locations.

6. The method according to claim 5, characterized in that, The step of generating a handover packet by serializing it according to a multi-layer structure also includes: The indexes corresponding to the discussion context and the task items are written as associated pointers into the handover packet; The associated pointer is used by the external coding agent to locate the corresponding data unit after parsing the handover packet, and only load the data unit that is pointed to.

7. The method according to claim 1, characterized in that, The real-time acquisition of the conference audio includes: The system collects audio from both the microphone input source and the system sound source, resulting in two audio streams. The two audio streams are time-aligned, and duplicate speech segments are removed to obtain the target audio. The target audio is transcribed into a streaming format. The system's audio source includes tab audio output from the conferencing platform.

8. The method according to claim 1 or 7, characterized in that, Also includes: Obtain the list of attendees that was entered before the meeting; Speaker segmentation is performed on the audio, and the speakers are labeled for the transcribed text; In response to the operation of mapping the speaker to a participant in the participant list, the participant identity is associated with the corresponding transcribed text.

9. The method according to claim 1, characterized in that, Before generating the task item based on the transcribed text, the method further includes: Identify the final identification node in the transcribed text generation process; Determine whether the transcribed content before the final identification node contains task semantic elements, wherein the task semantic elements include a description of the task objective and / or a description of the completion criteria. In the case of including the semantic elements of the task, the transcribed content before the final identification node is merged with the semantically related candidate tasks in the accumulated candidate tasks to generate a candidate task list. The process of generating task items based on the transcribed text is performed based on the candidate task list.

10. The method according to claim 1 or 2, characterized in that, Also includes: At the conclusion of the meeting, the tasks listed below shall be presented. In response to the participants' selection of tasks, the system records the signer, the selected task, and the signing timestamp, generating a signature record. The tasks included in the handover package are signed tasks.

11. The method according to claim 1, characterized in that, Also includes: In response to the wake-up operation during the meeting, the accumulated transcribed text is input into the model, and unresolved issues that have not yet reached a consensus are identified from the transcribed text as discussion checkpoints; Generate candidate solution comparison information and suggestion information for the discussed bottlenecks; Based on the accumulated transcribed text, complete the task elements of the unresolved issues and output action suggestions.

12. The method according to claim 1, characterized in that, The provision of the handover packet to the external coded agent includes at least one of the following methods: The handover packet is written to the system clipboard for pasting into the external coded agent in the command-line interface; The handover packet is written to a specified storage path for the external coded agent to read; The handover packet is sent to the external coded agent via the interface that communicates with the external coded agent.

13. The method according to claim 1, characterized in that, The continuation of the task includes: Each of the multiple tasks in the handover package is assigned an independent code execution agent, and each code execution agent processes the assigned task. After all the code execution agents have completed their processing, the integration agent integrates the processing results and outputs the integrated task result.

14. The method according to claim 1, characterized in that, Also includes: After the meeting concludes, the discussion records, tasks, and handover packages of the meeting are archived to local storage, with each meeting serving as an isolated unit. The archived data from different meetings are isolated from each other.

15. The method according to claim 4 or 14, characterized in that, The process of obtaining the discussion context of the meeting includes: In response to the selection of a target meeting in the historical archive when creating a new meeting, the archived data of the target meeting is retrieved; The archived data is associated with the session state of the new meeting as at least part of the discussion context of the new meeting.

16. The method according to claim 1, characterized in that, The method is executed by a web-based conference workbench; In response to a session creation action initiated by any participant on the webpage, a session is created and the discussion context is loaded without account registration or login.

17. The method according to claim 16, characterized in that, The web-based meeting workbench interface is divided into a pre-meeting preparation page, a meeting collaboration page, a post-meeting delivery page, and a historical archive page according to the meeting lifecycle. The discussion context is entered on the pre-meeting preparation page; The transcribed text and the task details are presented on the meeting collaboration page. The handover package is generated on the post-meeting delivery page; Discussion minutes and task assignments for each meeting are managed in the history archive page. The four pages are connected through a unified session state to ensure that the data of the meeting remains continuous during page transitions.

18. A conference data processing apparatus, comprising: The acquisition module is used to acquire the discussion context of the meeting; The acquisition and transcription module is used to acquire the audio of the meeting in real time and transcribe the audio into transcribed text; The task extraction module is used to generate task items based on the transcribed text, and the task items record the task objectives and completion standards. The handover packet generation module is used to generate a multi-layered serialized handover packet based on the discussion context, the task items, and decision information determined from the transcribed text. A providing module is used to provide the handover packet to an external coding agent, so that the external coding agent can parse the contents of each layer of the handover packet and continue to execute the task.

19. An electronic device comprising: At least one processor; as well as A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-17.

20. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-17.

21. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1-17.

Images