Information processing method and device, electronic equipment and computer readable storage medium

Abstract

One embodiment of the present disclosure provides an information processing method, comprising: in response to detecting an input operation containing a task creation indicator and a target object in a communication interface; extracting task-related information from the input operation and / or the context of the communication interface; generating task data based on the extracted task-related information; and synchronizing the task data to a task management system.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and in particular to information processing methods, apparatus, electronic devices, and computer-readable storage media. Background Technology

[0002] In team collaboration and project management, instant messaging software and enterprise task management systems are two commonly used tools. Instant messaging software facilitates real-time communication and information exchange among team members, while task management systems are used to plan, assign, and track the progress of tasks. In real-world work scenarios, communication and task assignment are often closely intertwined.

[0003] However, when users need to mention and assign tasks in instant messaging, they usually have to exit the current chat interface, manually switch to a separate task management application, and re-enter information such as the task name, executor, and deadline. This operation is cumbersome, leading to longer user operation time and the occupation of terminal resources due to frequent application switching; at the same time, relying entirely on manual information entry is also prone to errors, increasing the burden of subsequent data verification and correction. Summary of the Invention

[0004] This disclosure provides an information processing method, apparatus, electronic device, and computer-readable storage medium to at least partially solve the aforementioned problems existing in the related art.

[0005] According to one aspect of this disclosure, an information processing method is provided, the method comprising: responding to detecting an input operation in a communication interface that includes a task creation indicator and a target object; extracting task-related information from the context of the input operation and / or the communication interface; generating task data based on the extracted task-related information; and synchronizing the task data to a task management system.

[0006] According to one aspect of this disclosure, an information processing apparatus is provided, comprising: a detection unit for responding to detecting an input operation in a communication interface that includes a task creation indicator and a target object; an extraction unit for extracting task-related information from the context of the input operation and the communication interface; a generation unit for generating task data based on the extracted task-related information; and a synchronization unit for synchronizing the task data to a task management system.

[0007] According to one aspect of this disclosure, an electronic device is provided, comprising: a processor, a memory, and computer program instructions stored in the memory and executable on the processor; the processor executes the computer program instructions to implement any of the above information processing methods.

[0008] According to one aspect of this disclosure, a computer-readable storage medium is provided, which stores computer program instructions that, when executed by a processor, are used to implement any of the above information processing methods.

[0009] One embodiment of this disclosure provides an information processing method, including: responding to detecting an input operation containing a task creation indicator and a target object in a communication interface; extracting task-related information from the context of the input operation and / or the communication interface; generating task data based on the extracted task-related information; and synchronizing the task data to a task management system. In this way, by directly responding to specific input operations in the communication interface and automatically extracting relevant information to generate tasks, the steps of manual operation by the user and switching between applications are reduced, improving the efficiency and accuracy of task creation and allocation. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 This diagram illustrates a system architecture in one exemplary embodiment of the present disclosure.

[0012] Figure 2 A flowchart illustrating a method in one exemplary embodiment of this disclosure is shown; Figure 3 This diagram illustrates task creation in one exemplary embodiment of the present disclosure; Figure 4 A schematic diagram of the structure of an electronic device is shown in one exemplary embodiment of the present disclosure. Detailed Implementation

[0013] Exemplary embodiments of this disclosure will be described more fully below with reference to the accompanying drawings.

[0014] The accompanying drawings are schematic illustrations of this disclosure and are not necessarily drawn to scale. Some block diagrams shown in the drawings may be functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in hardware modules or integrated circuits, or in networks, processors, or microcontrollers. Implementations can be carried out in various forms and should not be construed as limited to the examples set forth herein. The features, structures, or characteristics described in this disclosure can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough description of embodiments of this disclosure. However, those skilled in the art will recognize that one or more specific details may be omitted when implementing the technical solutions of this disclosure, or other methods, components, apparatuses, steps, etc., may be used to replace one or more specific details.

[0015] To make the objectives, technical solutions, and advantages of this disclosure clearer, the embodiments of this disclosure will be described in further detail below with reference to the accompanying drawings.

[0016] Figure 1 A system architecture diagram of the operating environment of this embodiment is shown. This system architecture may include a first client 110, a second client 120, and a server 130. The first client 110 and the second client 120 are terminal devices that have installed and run IM application client programs, such as mobile phones, tablets, personal computers, smart wearable devices, etc. They have display functions and can display a graphical user interface, which may include the operating system interface or the application interface. The first client 110 is the client used by a first account, and the second client 120 is the client used by a second account. That is, the IM application client program running on the first client 110 is logged into the first account, and the IM application client program running on the second client 120 is logged into the second account. The server 130 generally refers to the backend system providing communication services in this exemplary embodiment; it can be a single server or a cluster of multiple servers. A communication server program is deployed on the server 130 to perform server-side communication data processing. The first client 110, the second client 120, and the server 130 can be connected via wired or wireless communication links for data transmission. For example, the first client 110 can send information to the second client 120 through the server 130, and the second client 120 can send information to the first client 110 through the server 130. Furthermore, the first client 110 and the second client 120 can also communicate directly via wired or wireless means.

[0017] To make the above-mentioned objectives, features and advantages of this disclosure more apparent and understandable, the disclosure will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0018] According to one embodiment of the information processing method of this disclosure, such as Figure 2 As shown, the method may include: Step S210, in response to detecting an input operation containing a task creation indicator and a target object in the communication interface; Step S230: Extract task-related information from the context of the input operation and / or communication interface; Step S250: Generate task data based on the extracted task-related information; Step S270: Synchronize the task data to the task management system.

[0019] According to one embodiment of this disclosure, tasks are generated by directly responding to specific input operations and automatically extracting relevant information in the communication interface, which reduces the steps of manual operation by the user and switching between applications, and improves the efficiency and accuracy of task creation and allocation.

[0020] The embodiments of this disclosure will now be further described.

[0021] In step S210, the system responds to the detection of an input operation containing a task creation indicator and a target object in the communication interface. By directly detecting an input operation containing a specific indicator and target object in the communication interface, the task creation process can be quickly triggered, integrating previously fragmented multi-step operations into a single step. This effectively improves the efficiency of task allocation, avoids the burden of frequent switching and repetitive information input between different applications, and provides a clear start signal and execution framework for subsequent context-based intelligent information extraction and task data generation.

[0022] For example, in a specific team collaboration chat, when the project leader enters "@task@Zhang San, complete the user research report by next Friday, refer to the requirements document in the attachment" in the group chat, the system detects that the input contains both the "@task" indicator and the "@Zhang San" target object, and immediately triggers the lightweight task creation entry without the user having to manually exit the current chat window or launch a separate task management application, thus achieving a seamless task creation experience in the communication context.

[0023] The task creation indicator is used to identify that the user's input intent is to create a task, thereby triggering the subsequent information extraction and task generation process.

[0024] Optionally, the task creation indicator can be presented as a specific combination of text symbols. In an optional embodiment, the indicator can be a string with a clear semantic prefix, such as "@task", "#task", or " / task". When a user types such a specific character combination into the input box of the communication interface, the input monitoring module on the client or server will recognize it as a trigger signal for task creation intent. This design makes the task creation trigger action naturally integrated into daily text communication habits, eliminating the need for users to remember complex menu paths or click deeply hidden buttons. Further optionally, to enhance flexibility and fault tolerance, the system can support custom configuration of the indicator, for example, allowing team administrators to set the indicator to "@TODO" or "[task]" according to internal collaboration habits. Furthermore, the recognition of indicators can go beyond exact matching. It can also be combined with simple natural language processing (NLP) for fuzzy intent recognition. For example, when a user enters "Assign Zhang San a task: complete the report next week", the system recognizes that the colloquial expression "assign a task" is highly related to the intent of task creation. Even without a standard prefix, it may trigger a lightweight task creation confirmation prompt, thereby covering a wider range of user expression habits.

[0025] Optionally, the task creation indicator can be triggered by specific interactive controls or gestures within the communication interface. For example, on touchscreen devices, users can long-press a contact's chat bubble and select "Create Task" from the pop-up shortcut menu. The system will then automatically identify the contact as the target and use the message content as context. Alternatively, on desktop, users can drag and drop a contact's avatar from the chat window to a specific "task creation area" (which may float at the edge of the interface or be accessed via a shortcut key) to create an "input operation containing the target object." These two methods provide a direct interactive path different from text input, making them particularly suitable for quickly converting existing conversations or contacts into task scenarios. Together with text indicators, they form a multi-dimensional trigger entry point to adapt to different user preferences and operational efficiency needs in different situations.

[0026] Optionally, upon detecting a task creation indicator, the system can provide immediate visual feedback in the communication interface and launch a lightweight task panel. For example, after a user types "@task", a compact task information card may slide out near the input box or at the bottom of the interface, pre-filled with information initially extracted from the current context (such as recent chat history). This immediate feedback clarifies that the operation has been accepted by the system and guides the user to the next step. Meanwhile, to handle potential accidental triggers (such as when the user intends to discuss the word "task" rather than create one), the lightweight panel can be designed with a prominent close button, or the system can set a short delay, only fully expanding and locking the trigger state after the user subsequently types the target object (such as "@Zhang San") or pauses briefly without canceling the operation. This foolproof mechanism ensures the accuracy of the trigger and avoids interference with the normal chat flow due to input ambiguity.

[0027] The target object refers to the entity to which the task is directed, and its type determines the specific logic for the subsequent generation and allocation of task data.

[0028] Optionally, target objects can be categorized into two basic types: individual target objects and group target objects. In an optional embodiment, individual target objects are typically specified using the "@" symbol followed by a personal identifier (such as name, nickname, or employee ID), for example, "@Zhang San" or "@Alex". The system can uniquely identify the corresponding individual account by matching the company's address book or the current session member list. Group target objects are specified using the "@" symbol followed by a group identifier (such as department name, project group name, or specific tag), for example, "@Test Group" or "@Product Team". After identifying group target objects, the system needs to further obtain the member list and related attributes of the group. This distinction forms the basis for subsequent differentiated task processing (such as direct assignment or intelligent splitting), enabling the task allocation mechanism to flexibly adapt to both one-to-one assignment and one-to-many dispatch scenarios.

[0029] Optionally, target object identification can be based on auxiliary information or interaction context beyond the input content. For example, in a private chat session, the system can default to identifying the chat partner (i.e., the private chat object) as the target object for this task creation, even if the user does not explicitly input "@the other party". In this case, the task creation indicator (such as "@task") alone can trigger the process. Alternatively, after the user selects (e.g., long-presses) a specific historical message in a group chat and then clicks the "Create Task" button, the system can automatically identify the sender of that historical message as the target object. Furthermore, the target object can also be determined by parsing the subject-verb-object structure of the input statement, without relying on the "@" mention. For example, when inputting "Zhang San needs to process the report," even without the "@" symbol, the system can use NLP to identify "Zhang San" as the agent of the action "process," thus identifying him as a potential target object for confirmation. These alternative identification methods enhance support for natural language expressions and indirect operation scenarios.

[0030] Optionally, when a target object is identified as a group target object, the system will initiate targeted group task processing logic. The core of this logic lies in intelligently breaking down a total task and assigning it to appropriate members within the group. The system first needs to obtain a list of members under the group target object and further query or calculate each member's attribute information, such as skill tags (marking the member's areas of expertise, such as "Java development" or "UI design") and current workload (which can be determined by counting the number or complexity of unfinished pending tasks under their name). Based on these attributes, the system can employ various strategies for task splitting and assignment: for example, if the task content keywords are related to "testing," subtasks are preferentially assigned to members whose skill tags include "test engineer"; simultaneously, among members with matching skills, members with lower workloads are prioritized to achieve load balancing. The split subtasks can be subdivided modules of the total task or parallel tasks with different focuses generated based on task templates. This process automates the complex allocation work that originally required manual coordination by managers, significantly improving the scientific nature and efficiency of group task assignment.

[0031] Optionally, the attribute information associated with the target object (such as personal occupation, skill tags, and workload) can be dynamically acquired and continuously updated. This information may be stored in a unified enterprise knowledge base, human resources (HR) system, or project management platform. When identifying a target object, the system queries its latest attributes in real time through an interface. For example, an employee's skill tags may be updated due to participation in new training. When the system creates a task for that employee the next time, it can perform more accurate task template matching or sub-task allocation based on the updated skills. Workload is also dynamically changing, adjusting in real time as tasks are completed and created. This dynamism ensures the timeliness and rationality of task allocation suggestions. In addition, for situations where accurate attributes cannot be obtained in real time (such as network latency or access restrictions), the system can degrade to using recently cached attribute data locally, or allow users to manually adjust the system-suggested executor on the task confirmation interface, thus ensuring the robustness of the mechanism and the user's ultimate control while being intelligent.

[0032] In an optional implementation, the task creation indicator includes "@task". By explicitly using the specific symbol combination "@task" as the task creation indicator, a direct and efficient trigger entry point is provided to the user within the communication interface. Users do not need to memorize complex commands or search for hidden functions; they only need to input this combination to clearly express their intention to create a task. The system can then quickly respond and initiate the subsequent information extraction and task generation process. This not only greatly simplifies the initial steps of task creation, avoiding the tediousness of frequent switching between different applications, but also standardizes and predicts the triggering action of task creation, laying a clear and reliable foundation for subsequent automated and intelligent information processing, thereby improving the overall efficiency and smoothness of task allocation and management.

[0033] For example, when a team is using instant messaging software for project discussions, if a project manager needs to assign a debugging task to developer "Zhang San," they can directly type "@task@Zhang San, complete the interface performance debugging this week. See the attached test_params.xlsx for specific parameters" in the chat input box. Here, "@task" serves as an explicit instruction, monitored and recognized by the system, thus triggering a lightweight task creation entry. The system then parses the message, extracting "@Zhang San" as the target object, "this week" as the time keyword, "complete the interface performance debugging" as the requirement description, and "test_params.xlsx" as the attachment file, automatically filling these into the task card to be generated. The entire process requires the project manager to leave the chat window, simplifying the operation from traditional multiple clicks and manual input to a single, continuous input trigger.

[0034] Optionally, the task creation indicator is used to trigger the system to initialize the task creation process when the text input area of ​​the communication interface is entered.

[0035] Optionally, in the specific implementation process, the symbol combination "@task" serves as a typical manifestation of a task creation indicator. Its core function is to provide users with a standardized, low-learning-cost trigger signal. When a user types the "@" symbol in the input box of an instant messaging application (such as a team chat window) followed by the word "task" (or the input method suggests the complete phrase), the text monitoring module on the client or server will capture this specific character sequence in real-time or near real-time. The system does not treat it as ordinary chat text, but rather parses it into an instruction with a clear functional intent. The recognition of this instruction can be based on simple string matching rules, such as detecting whether the input text contains the complete substring "@task"; it can also be combined with more intelligent semantic analysis, such as triggering the instruction even if there are a few character gaps or variations (such as "@task"), as long as the intent to create a task is expressed within the preset context window. Upon triggering, the system typically launches a lightweight overlay, pop-up, or sidebar interface immediately or after the user completes and sends the current message. This interface serves as a quick entry point for task creation, pre-filled with information initially extracted from the current message context, awaiting user confirmation or supplementation. This design seamlessly embeds the starting point of task creation into the most natural communication scenario, realizing the "what you say is what you get" interaction concept.

[0036] Optionally, besides the specific form "@task", task creation indicators can also be presented as other character combinations or controls with similar triggering functions to adapt to the usage habits of different user groups or the design specifications of different platforms. For example, the indicator can be "#task", "task:", or a specific emoji / icon. When using "#task", it utilizes the classification and marking functions commonly used in social and collaborative scenarios, making it easier for users to understand the meaning of "marked as a to-do item". The "task:" form is closer to natural language instructions, lowering the cognitive threshold. These different forms can maintain consistency in triggering logic: the system pre-configures one or more keyword or pattern libraries to scan and match user input in real time. Each form has its own application scenarios and advantages: "@task" emphasizes the association with a specific person (@object), suitable for scenarios that require a clear executor; "#task" focuses more on marking the attributes of the task itself, which may be more suitable for task posting in public channels; and icon triggering may save more screen space, suitable for mobile rich text editors. This disclosure does not limit the specific character representation of the indicator; its core purpose is to be reliably recognized by the system and used as a clear signal to initiate the task creation process.

[0037] Optionally, to further ensure the accuracy and robustness of the triggering mechanism and avoid confusion with the regular use of "@" mentions or the word "task" in ordinary chat text, the system can introduce more refined triggering logic. For example, it can be set that "@task" must appear as a continuous whole, unseparated by other characters (except spaces), at the beginning of a message or at a specific position (such as on a new line) to be recognized as an indicator. Alternatively, the system can combine user's historical behavior data; if a user frequently discusses tasks after mentioning someone but does not use an indicator, it can provide intelligent suggestions on the interface, asking "Do you want to create a task for @Zhang San?". In addition, the triggering action itself can also be integrated with operating system or input method shortcuts. For example, a user can long-press the "@" key to bring up a function menu and select "Create Task," which the system internally still maps to the logical instruction "@task". In complex communication environments, such as rapidly scrolling messages in group chats, the system can also provide visual highlighting or badge prompts for messages containing "@task" but not yet processed, ensuring that the triggering intent is not missed. In this way, through multi-layered identification and fault tolerance mechanisms, the "@task" triggering method is both direct and efficient, and can remain stable and reliable in various practical use scenarios.

[0038] In optional implementations, the target objects include at least one of the following: individual target objects and group target objects. By clearly distinguishing target objects into individual and group types, a clear input classification is provided for subsequent task generation logic, enabling the system to adopt differentiated processing strategies based on different types of objects. For individual target objects, the individual task executor can be directly and efficiently identified, simplifying the assignment process; for group target objects, it lays the foundation for triggering complex task splitting and member matching mechanisms, allowing task allocation to expand from individuals to teams. This significantly enhances the adaptability and practicality of the solution in diverse collaborative scenarios and improves the overall conversion efficiency from communication dialogue to task implementation.

[0039] For example, in a scenario where a team discusses project progress using instant messaging software, when the project manager needs to assign tasks, if they type "Please @Zhang San complete the user research report by next Friday," the system identifies "Zhang San" as the individual target; if they type "Please @the product team to jointly complete the requirements analysis for the new version," the system identifies "the product team" as the group target. These two different types of identification results will directly lead to drastically different subsequent task data generation paths. The former may directly create a task with "Zhang San" as the executor, while the latter may trigger a complex task allocation process that requires splitting tasks based on the skills and workload of team members.

[0040] Optionally, the personal target object is used to refer to a single user entity mentioned by @ in the communication interface. As a direct candidate for task executor, the system associates specific task templates or determines task content by recognizing its identity attributes.

[0041] Optionally, the identification of an individual target can be based on a user's unique identifier in the communication system (such as a user ID, username, or nickname). In a specific business environment, the system will match this identifier with the enterprise knowledge base or organizational structure data in real time to obtain the user's detailed attribute information, such as their department, job responsibilities (personal occupation), and professional skill tags (such as "Java development," "UI design," or "test engineer"). This attribute information is not only static profile data, but in some embodiments it can also be dynamically updated, for example, automatically adjusting the weight of the user's skill tags based on the types of projects the user has recently completed. In this way, when the task creation indicator and the individual target are detected simultaneously, the system can quickly anchor a specific individual with rich background information, providing accurate data support for subsequent intelligent matching (such as automatically selecting a "test case writing template").

[0042] Optionally, besides specifying the target user by directly mentioning their username (@username), the designation of a personal target can also be achieved through other associated methods. For example, in a communication context, a user might mention a role title (e.g., "Please have the colleague in charge of testing follow up") or a skill keyword (e.g., "We need a colleague who knows Python") instead of a specific personal account. In such scenarios, the system can use natural language processing technology to parse the descriptive requirements for the personal target from the statement, and then intelligently recommend candidates based on the attribute information of members in the enterprise knowledge base, listing one or more candidates that match the description for the user to choose from. This approach expands the triggering boundaries of "personal target," allowing task assignment to be initiated even without explicitly specifying a specific person, and final confirmation can be completed through human-computer interaction, balancing flexibility and accuracy.

[0043] Optionally, the group target object is used to refer to the group or team entity mentioned by @ in the communication interface, which triggers the system to intelligently break down a general task and assign it to multiple members within the group for processing.

[0044] Optionally, the target group typically corresponds to a group chat in a communication software or a predefined organizational unit (such as "Front-end Development Team" or "Marketing Department"). After identifying the group, the system queries its member list and further obtains the attribute information of each member, including at least their occupation, skill tags, and current workload. Based on this multi-dimensional data, the system executes a task decomposition algorithm: First, it performs semantic analysis on the overall task content, decomposing it into multiple logically independent sub-task modules with clearly defined skill requirements; then, it calculates the matching degree between the skill requirements of each sub-task module and the skill tags of the group members, while considering the balance of each member's current workload, ultimately assigning a suitable executor to each sub-task. For example, assigning the task "Make a Poster" to the "Design Team" might be broken down into "Copywriting Ideation - Member A," "Visual Design - Member B," and "Layout Proofreading - Member C," achieving a transformation from a broad group @ assignment to a refined individual task distribution.

[0045] Optionally, the composition of the target group is not fixed, and the corresponding task splitting strategy can be adapted according to the group type. For example, for a "project group" temporarily formed based on a project, the skills of its members may overlap. When splitting sub-tasks, the system can adopt a competitive allocation strategy, prioritizing tasks to members with the highest matching degree and lighter workload. For a fixed "department group," the responsibilities of its members are relatively fixed, and the system may adopt a rule-based allocation strategy based on roles (individual occupations), directly assigning a certain type of sub-task to members in the corresponding positions. In addition, there may be dependencies between the split sub-tasks (such as "testing" can only be carried out after "development" is completed). When allocating tasks, the system can generate a task flowchart and set dependency conditions, thereby planning the order of task execution while assigning executors, improving the automation level of complex project management.

[0046] Optionally, when splitting tasks based on group target objects, the system also needs to incorporate multiple fault tolerance and optimization mechanisms to cope with the complexity of real-world scenarios. For example, if the algorithm detects that a core skill member's workload is already full, it can initiate secondary matching or issue a warning to the user, suggesting adjustments to task deadlines or additional manpower. Furthermore, to prevent overly fragmented splitting, the system can set a minimum granularity threshold for subtasks, avoiding splitting overly simple task modules and directly assigning them to the member with the highest overall matching degree. Simultaneously, the system can provide a visual preview interface for the splitting results, displaying the executor, estimated time, and dependencies for each subtask, allowing users to manually adjust before final confirmation. In this way, the entire splitting process leverages the efficiency of automated algorithms while retaining necessary human intervention entry points, ensuring the rationality and feasibility of the task allocation scheme.

[0047] In step S230, task-related information is extracted from the context of the input operation and / or communication interface. By automatically extracting structured task-related information from the context of the input operation and communication interface, the system can intelligently understand the user's assignment intentions and task requirements, transforming informal chat content into processable task elements. This not only provides accurate and reliable data input for subsequent steps such as task template matching, automatic information completion, and executor determination, effectively transforming ambiguous intentions in the communication context into clear and executable task instructions, but also fundamentally avoids information omissions, misunderstandings, and operational interruptions caused by manual switching between different applications and repeated data entry. This transforms the task creation process from "manually filling out forms" to "naturally conveying information in conversation," significantly improving the automation level, information fidelity, and overall process coherence of the transformation from communication to collaboration.

[0048] In a specific team collaboration chat scenario, when the project manager sends a message like "@Test Engineer Xiao Wang, complete the test case writing for the core module based on 'V2.0 Requirements Document.pdf' by next Friday," the system's extraction process doesn't simply copy the entire sentence. It first identifies the "input operation" part, namely "@Test Engineer Xiao Wang," and parses out the target object "Xiao Wang" and its accompanying skill tag "Test Engineer" as object attribute information. Simultaneously, the system scans the message and its surrounding chat window's "context," extracting valid text information: identifying "by next Friday" as a time keyword, "complete the test case writing for the core module" as a core requirement description, and recognizing the mentioned attachment "V2.0 Requirements Document.pdf" as a related file. All these extracted "task-related information" form a solid foundation for the subsequent automatic creation of a test task.

[0049] Optionally, task-related information is intended to cover a set of data extracted from the interaction scenario that substantially contributes to the formation of a complete task. It includes at least target object attribute information used to identify the task's ownership, and valid text information used to define the task's content and requirements.

[0050] Optionally, the object attribute information in the task-related information is used to accurately characterize the features and status of the task executor. For individual target objects, the attribute information can be specifically reflected in the member's registered job position in the organizational structure (such as "software engineer" or "product manager") or personal skill tags maintained by the system (such as "Java proficient" or "UI design"). For group target objects, the attribute information is more complex and may include the group's overall tag (such as "front-end development team"), the set of job and skill tags for each member in the group, and workload data reflecting the current task busyness of each member. This attribute information is the core decision-making basis for subsequent intelligent matching of task templates and automatic assignment or splitting of tasks to suitable members.

[0051] Optionally, the effective text information within the task-related information is responsible for capturing the specific requirements of the task from the natural language and multimedia content of the conversation. Typical forms include: "time keywords" implying time constraints, such as "within this week," "before 3 PM tomorrow," or "end of Q3," which the system needs to parse into specific deadlines; "requirement descriptions" describing the task objectives, such as "revise the user agreement," "investigate the cause of server downtime," or "prepare quarterly report materials," which often directly constitute the core part of the task name; and "attached files" serving as task references or deliverables, such as documents, forms, design drafts, and links sent or shared in the chat, which need to be automatically associated with the generated task items. The depth and accuracy of the extraction of effective text information directly determine whether the automatically generated task content aligns with the user's original intent.

[0052] Optionally, the composition of task-related information is not fixed but can be dynamically combined and prioritized based on the type of the target object and the identified context. For example, when tagging a skill (such as "@UI designer") rather than a specific individual, the object's attribute information may primarily rely on that skill tag, while the requirement description in the effective text becomes key to finding a matching candidate. Furthermore, when the contextual information is very rich, the system may employ a confidence model to prioritize extracting semantically clear information that highly matches common task fields. Ambiguous or polysemous content can be treated as notes or left for user confirmation. This flexible and intelligent information extraction and organization method ensures that the solution can adapt to diverse real-world communication habits, rather than requiring users to adhere to a rigid input format.

[0053] Optionally, the context mainly refers to the session environment information associated with the current input operation in the instant messaging interface that triggers the task creation operation, which provides the main source of content for extracting task-related information.

[0054] Optionally, the specific scope of the context can be flexibly defined, typically including historical message records within a certain timeframe or number of messages in the current chat session before and after detecting an input operation containing the task creation indicator. These message records contain the background of the task requirements, the discussion process, detailed requirements, and related file-sharing links or directly uploaded attachments. For example, before a user @someone and says "Please handle this issue," there may have been several messages discussing a specific bug phenomenon. These historical messages collectively constitute the context for understanding what "this issue" specifically refers to. The system uses natural language processing technology to scan and analyze this context to locate and extract valid task-related information.

[0055] Optionally, there must be a close semantic relationship between the context and the aforementioned "input operation," requiring the system to perform correlation analysis when extracting information. For example, the extracted time keyword "tomorrow" needs to be combined with the time of the input operation to calculate the specific deadline; the extracted requirement description may need to be combined with the role of the target object in the input operation (such as "designer") to determine its relevance ("provide design drafts" is a relevant requirement, while "modify backend code" may be less relevant). This correlation analysis helps filter out irrelevant noise in the context, improves the accuracy of information extraction, and ensures that the automatically completed task content is highly consistent with the user's assignment intent.

[0056] In an optional implementation, task-related information includes: object attribute information of the target object and valid text information; the object attribute information of the target object includes: attribute information of individual target objects and attribute information of group target objects; the attribute information of individual target objects includes: individual occupation and individual skill tags; the attribute information of group target objects includes: group tags, group members' occupations, group members' skill tags, and group members' workload. By clearly dividing task-related information into two dimensions—object attribute information and valid text information—not only does it provide a clear and structured data input foundation for subsequent intelligent task generation, but it also enables the system to accurately locate the executor's identity and capabilities based on object attributes and automatically complete task details based on valid text. This effectively avoids the problems of information omission, role mismatch, and context fragmentation commonly found in traditional manual data entry, significantly improving the automation level and reliability of the task allocation process.

[0057] In specific instant messaging collaboration scenarios, such as when a project leader sends a message in a group chat, "@task@test team, complete the test case writing for all modules by this Friday, refer to the design document in the attachment," when the system extracts task-related information, the object attribute information will cover the skill tags of group members corresponding to the test team as the target object of the group (such as "automation testing" and "performance testing") and the current workload. The effective text information will identify the time keyword "by this Friday," the requirement description "complete the test case writing for all modules," and the attachment file "design document" from the context. This structured information together provides a complete basis for the subsequent generation of specific and assignable sub-task data.

[0058] Optionally, object attribute information is used to characterize the identity, capabilities, or status characteristics of the target object (individual or group), aiming to provide a basis for decision-making in identifying task executors and matching task templates.

[0059] Optionally, object attribute information can be derived from a unified enterprise directory, a personal / group database of instant messaging software, or a historical behavior data analysis system. For example, the attribute information of an individual target object may be obtained by retrieving employee files from a human resources system via an interface. Personal occupation fields such as "software engineer" or "UI designer" define their general job responsibilities, while personal skill tags such as "Python programming" or "user experience design" more precisely depict their professional skills and strengths. This information collectively forms the quantitative basis for determining whether an individual is suitable for a particular task. In another implementation, object attribute information can also be dynamically updated. For example, temporary skill tags can be automatically assigned based on the type of projects an employee has recently participated in, or their ability score can be dynamically calculated and updated based on their task completion efficiency. This makes the attribute information more timely and accurate, adapting to rapidly changing team collaboration needs.

[0060] Optionally, in addition to retrieving information from pre-defined data sources, object attribute information can also be inferred or supplemented by analyzing the target object's historical interaction records in the communication interface. For example, the system can analyze whether an employee frequently discusses or shares content related to "data analysis" in past chats, thereby automatically adding or strengthening the "data analysis" skill tag for them; or it can enrich the experience dimension in their attribute information by statistically analyzing the types of tasks they have recently been @mentioned and successfully completed. This context-based dynamic attribute mining can compensate for the shortcomings of static databases being outdated, making attribute information more comprehensive and closer to actual work scenarios, and providing support for more refined task matching.

[0061] Optionally, the application logic of object attribute information is not fixed and can be flexibly configured according to different task types or enterprise management systems. For example, for urgent and professional tasks, the system can prioritize high-precision matching based on "personal skill tags"; while for routine and collaborative tasks, it may focus more on generalized allocation based on "personal occupation" or "group tags". In addition, certain fields in the attribute information (such as "workload") can be set with threshold alarms. When a member's workload is detected to be full, the system can automatically exclude that member in the task allocation suggestions or issue a warning, thus incorporating humanized resource management considerations and avoiding over-allocation.

[0062] Optionally, valid text information is used to capture semantic content, time elements, and associated resources directly related to task creation from the communication context, with the aim of automatically populating the specific requirements of the task.

[0063] Optionally, the identification of effective text information relies on Natural Language Processing (NLP) technology to parse specific text fragments in the communication interface. For example, the identification of time keywords not only includes explicit date expressions such as "tomorrow" and "next Monday," but also understands relative time phrases such as "within this week" and "before the end of the month," and converts them into specific deadline field values ​​by calculating with the current system date. The extraction of requirement descriptions may be achieved by locating core verbs and objects through semantic analysis, such as extracting "stress test login function" as a candidate task name from "We need to stress test the login function." For attachment files, the system not only records their file names but can also further parse their file types (such as .pdf and .docx) and extract key content summaries, which are then associated with the task fields as supplementary information to the task description.

[0064] Optionally, the scope of valid text information extraction can be expanded to include richer contextual elements. For example, in addition to the single message that triggers the @ operation, the system can scan multiple related messages within a certain time window before and after that message to obtain a more complete task background. For instance, the preceding message might be "There's an important matter regarding the release of the new version," and the following message might be "It's necessary to ensure that all compatibility tests pass." Combining the triggering message "@task@Xiao Li," the system can synthesize this information to generate a more accurate task description: "Compatibility testing before the release of the new version." Furthermore, valid text information can also include specific formatted content in the message, such as project numbers (e.g., "PRJ-2023-001"), and the addresses of online documents pointed to by hyperlinks, all of which can be identified and associated as part of the task.

[0065] Optionally, to ensure the accuracy and robustness of extracted effective text information, the system can introduce multi-round verification and user intervention mechanisms. For example, when the identified time keywords are ambiguous (e.g., "next week" may refer to different start points), the system can highlight the field on the task confirmation interface and prompt the user to confirm the specific date. For the requirement description, if the extracted text is too brief or vague, the system can generate supplementary prompts based on a preset question template, such as "Please clarify what the specific deliverables of the task are?". This design balances automation and controllability, leveraging the efficiency advantage of automatic filling of effective text information while ensuring the quality of the final task data through user confirmation at key points, avoiding misunderstandings that may result from complete automation.

[0066] Optionally, the attribute information of the individual target is intended to portray the professional background and ability profile of the individual task performer, providing a basis for personalized task assignment.

[0067] Optionally, the attribute information of an individual target is typically a structured dataset containing at least two dimensions: personal occupation and personal skill tags. Personal occupation usually reflects the member's formal job role within the organization, such as "backend development engineer" or "product operations specialist," providing a macro-level role matching basis for task allocation. Personal skill tags refine and supplement the occupation, potentially including specific programming languages ​​(such as "Java" or "Go"), proficiency in software tools (such as "Figma" or "Jira"), or business domain knowledge (such as "financial risk control" or "cross-border e-commerce"). These tags enable the system to perform more refined skill-based matching. In practice, this attribute information can be stored in a user profile database and retrieved in real-time when an individual target is detected.

[0068] Optionally, the attribute information of individual target individuals is not static, and its update mechanism can be designed in multiple modes. Besides manual maintenance by administrators, it can also be integrated with internal learning platforms, code repository contribution records, or project management systems to achieve automated skill tag growth. For example, when an employee presents on "containerized deployment" at an internal technical sharing session, the system can automatically add or enhance relevant skill tags such as "Docker" and "Kubernetes." This dynamically updated attribute information allows task allocation to keep pace with the actual skill development of team members, avoiding task-skill mismatches caused by information lag, thereby continuously optimizing the efficiency of human resource utilization.

[0069] Optionally, personal occupation is used to identify the target person's formal job title or job category within the organizational structure.

[0070] Optionally, an individual's occupation, as a fundamental field of object attribute information, typically corresponds to the company's job title system, such as "Project Manager," "Visual Designer," and "Test Engineer." In task allocation scenarios, the primary function of an individual's occupation is to perform initial role screening and matching. For example, when the task content clearly falls under the "design" category, the system will prioritize members with the occupation of "Designer." To achieve more intelligent matching, the individual's occupation field can be associated with predefined task template mapping rules. For instance, the occupation "Test Engineer" is associated by default with task templates such as "Test Case Writing" and "Defect Regression Testing." Furthermore, individual occupation information can also be used for permission verification. For example, certain high-privilege or sensitive tasks may only be allowed to be assigned to members with specific occupations (such as "Department Head"), thus embedding necessary control logic while facilitating allocation.

[0071] Optionally, personal skills tags are used to describe the specific professional skills, tool usage abilities, or knowledge areas possessed by the target individual.

[0072] Optionally, personal skill tags provide fine-grained supplementation to an individual's profession, typically existing as a list of keywords, such as "Python data analysis," "React front-end development," and "MySQL database optimization." During task generation, personal skill tags can be used for precise skill matching. For example, if a task description mentions "requiring the use of TensorFlow for model training," the system can compare the skill tags of members within a group, prioritizing members with tags containing "TensorFlow" or "machine learning" as candidates for executor. Skill tags can come from various sources, including those maintained by the employee themselves and automatically extracted from data sources such as project experience, certificate repositories, and technical blogs. To improve matching effectiveness, skill tags can also be assigned weights or proficiency levels, such as "proficient," "familiar," and "understanding." The system can use proficiency as a ranking factor during matching, thereby assigning tasks to the most suitable experts and improving task completion quality and efficiency.

[0073] Optionally, the attribute information of the group target object is used to describe the overall characteristics of a collaborative team and the composition and status of its members, providing a decision-making basis for the intelligent splitting and allocation of group tasks.

[0074] Optionally, the attribute information of the target object in a group is a composite data structure. It includes both a "group tag" describing the group as a whole (such as "front-end development team" or "marketing planning team") and a detailed set of attributes describing each member, such as their occupation, skill tags, and workload. When a target object is detected as a group, the system uses this attribute information to execute task splitting logic. For example, a group with the tag "product development department" might have members whose occupations include product managers, UI designers, front-end and back-end developers, etc., each with different skill tags. The system first matches potentially applicable task types based on the group tag, and then, based on the detailed attributes of the members, decomposes the total task into sub-tasks that match the occupations and skills of each member, thereby achieving a reasonable division of tasks within the group.

[0075] Optionally, the application strategy for the attributes of internal members of the target group can be flexibly configured during task splitting. A common strategy is clustering and allocation based on skill tags. The system analyzes the key requirements of the overall task, matches them with the skill tags of group members, splits the requirements into different skill modules, and assigns them to members with the corresponding tags. Another strategy is balanced allocation based on workload. During splitting, the system considers the number of unfinished tasks or workload saturation of each member, prioritizing the allocation of sub-tasks to members with lighter workloads to achieve a relatively balanced workload for the team and avoid overloading individual members. In practice, these two strategies can be combined. The system can set a comprehensive scoring algorithm that considers both skill matching and workload, calculating a score for each possible sub-task-member pairing to arrive at the optimal or near-optimal splitting and allocation scheme.

[0076] Optionally, group tags are used to functionally or organizationally categorize target groups to quickly associate them with the scope of tasks they may be responsible for.

[0077] Optionally, group tags are typically one or more short descriptive terms, such as "Customer Support Group," "Architecture Review Committee," or "Project A Task Force." Their purpose is to provide a quick index for task template matching and initial task targeting. For example, when a user mentions a group tagged "Operations," the system can prioritize recommending templates related to operations work (such as "Server Inspection" or "Troubleshooting") from the task template library. Group tags can be automatically generated or manually labeled based on the group's creation purpose, main member composition, or historical task types. In some complex organizations, a group may have multiple tags to reflect its multiple roles. The system can combine all tags for matching, or allow users to specify which tag to use when triggering a task, thereby increasing the flexibility and accuracy of task allocation.

[0078] Optionally, group member occupations are used to identify the formal job roles of individual members within the group.

[0079] Optionally, in the attribute information of the target group, the set of group members' occupations describes the professional roles within the group. When splitting tasks within a group, the occupations of group members are one of the important bases for dividing task modules. For example, if a "marketing promotion" task is assigned to the "marketing department" group, the system may automatically split the task into sub-tasks such as "writing promotional copy," "contacting distribution channels," and "designing promotional posters" based on the occupations of group members (e.g., "copywriting," "channel operations," "graphic design"), and initially associate the sub-tasks with the corresponding members based on their occupations. The occupational information of group members is usually synchronized from the company's organizational structure, ensuring authority and consistency. In the splitting logic, the system can preset a mapping relationship library between different occupations and task types, making the splitting process systematic, reducing randomness, and ensuring the rationality of the professional division of labor in the decomposed sub-tasks.

[0080] Optionally, group member skill tags are used to provide detailed descriptions of the specific professional skills possessed by each member within the group.

[0081] Optionally, group member skill tags provide a more refined profile of abilities than group member occupations. They play a crucial role in task decomposition within the group, especially when handling complex tasks requiring specific expertise. After breaking down the overall task into subtasks, the system needs to find the most suitable person to perform each subtask. At this point, occupation alone may not be sufficient for accurate matching. For example, members with the same occupation of "development engineer" might have skill tags for "Java microservices" and "Python data processing," respectively. By comparing the subtask's requirement keywords with each member's skill tags, the system can achieve precise "person-job matching." Furthermore, when multiple members possess similar skills, the proficiency level of the skill tags or historical success data can serve as further decision-making criteria, helping the system select the most competent member, thereby improving the success rate and quality of task execution.

[0082] Optionally, the workload of group members is used to quantitatively reflect the current task responsibilities of each member in the group, aiming to achieve a balanced and humane task allocation.

[0083] Optionally, the workload of a group member can be a dynamically changing numerical or hierarchical indicator. The data can be sourced from the task management system and calculated by counting the number of tasks under that member's name that are in progress or pending start, the total estimated working hours, or the recent task completion density. Introducing the workload attribute during the group task splitting and allocation process can effectively avoid individual member overwork or team efficiency bottlenecks caused by uneven task distribution. For example, when selecting an executor for a subtask, if the system finds that member A, with the highest skill matching, has a workload approaching the saturation threshold, while member B has a slightly lower skill matching but a lighter workload, the system may prioritize member B or provide a prompt on the task confirmation interface, suggesting the user weigh the options. This mechanism not only optimizes resource scheduling but also reflects care for employee work status, helping to maintain the stability and enthusiasm of long-term team collaboration.

[0084] In optional implementations, valid text information includes at least one of the following: time keywords, requirement description, and attachments. By explicitly defining that valid text information must include at least these three key types of information—time keywords, requirement description, and attachments—a clear and efficient focus is defined for the system to intelligently extract information from the communication context. This not only ensures that the subsequent task data generation process receives structured, high-value information input, thus accurately and automatically filling in core fields such as task deadlines, task names, and associated files, but also significantly reduces the steps and time costs required for users to manually organize and enter this information. Furthermore, it effectively improves the overall efficiency and accuracy of the conversion from chat dialogue to standardized tasks, avoiding information omissions or misunderstandings that may occur due to manual transcription, and ensuring the integrity and reliability of the generated task data.

[0085] For example, in a specific team collaboration chat scenario, when user A sends the message "@Zhang San, complete this user research report by next Friday. Detailed requirements can be found in the 'Research Outline.docx' I just uploaded," the system, after triggering the task creation process, will extract valid text information from this message and its context: "By next Friday" will be identified as a time keyword and parsed into a specific deadline; "Complete this user research report" will be identified as the core requirement description, and "User Research Report" will be extracted as a candidate task name; simultaneously, the "Research Outline.docx" file, which is present in the message context or nearby, will be identified as an attachment to be associated. This extracted structured information will be directly used to populate the corresponding fields of the task to be created.

[0086] Optionally, time keywords are used to identify and parse statements related to task time requirements from the context text content to automatically determine the task's deadline or time point.

[0087] Optionally, the identification of time keywords can rely on a pre-defined time expression pattern library or a natural language processing model. For example, the system can pre-configure a series of regular expressions or keyword patterns to match common Chinese time expressions such as "before XX", "until XX", "next week X", and "X month X day". When such patterns are detected in messages related to the input operation that triggers task creation, or in several messages before and after them, they are captured as time keywords. Furthermore, the system needs to standardize these unstructured time expressions, for example, by combining "before next Friday" with the current date and converting it into a specific "YYYY-MM-DD" format date and timestamp, which serves as the value of the deadline field in the task data. This process avoids the tedious operation of users having to exit the chat interface and manually search and select dates in the calendar.

[0088] Optionally, in addition to the fixed-pattern matching mentioned above, the identification of time keywords can also employ more flexible semantic understanding methods. For example, the system can infer time requirements by combining contextual information. For vague expressions like "handle as soon as possible," a suggested deadline can be automatically calculated by combining the task type, the executor's historical processing speed, or the company's default emergency task response time limit (such as "within 24 hours"). Alternatively, for event-dependent expressions like "wait for Mr. Wang to return before deciding," the system can try to link Mr. Wang's schedule information in the company's knowledge base. When his schedule status is updated to "returned," a reminder or subsequent task creation steps can be automatically generated. This deep inference and extension makes the extraction of time information more intelligent and aligned with actual business scenarios, enhancing the system's practicality in complex or vague contexts.

[0089] Optionally, the requirements description is used to extract the core content or objectives of the task from the context text, serving as the main basis for automatically generating task content data such as task name and task details.

[0090] Optionally, the extraction of the requirement description can be based on keyword extraction and semantic analysis techniques. In a typical embodiment, the system can focus on the message containing the task creation indicator (such as "@task"), as well as several adjacent messages, as a candidate text pool. By removing stop words, identifying nouns and verb phrases, and combining them with a predefined domain dictionary related to the work task (such as "writing," "reviewing," "testing," "researching," "reporting," etc.), the system extracts the core phrases or short sentences that best summarize the work intent. For example, from the message "@Li Si, please take some time to test the newly launched payment function, focusing on compatibility," the phrase "test the compatibility of the newly launched payment function" can be extracted as the requirement description, which can then be directly used or simplified (such as "payment function compatibility test") as the task name. To improve accuracy, the system can also combine syntactic analysis to identify the recipient of the action (such as "payment function") and the specific aspects of the action (such as "compatibility").

[0091] Optionally, the method for determining the requirement description is not unique. In another optional implementation, the system can adopt an extraction strategy strongly correlated with the task template. For example, when the target object's skill tag is identified as "test engineer" and matched with a "functional test template," the system can proactively search for descriptions related to the template's preset fields within the context. This template may preset fields such as "test object" and "test focus," in which case the system will guide the information extraction module to specifically search for and fill in this specific information within the context, thereby forming a structured requirement description. This approach makes the extraction process more targeted, resulting in a higher degree of consistency between the generated task content and the template format. Furthermore, if the requirement description in the context is vague or brief (e.g., simply stating "handle this bug"), the system can also supplement the analysis by combining the content of identified attachments (such as bug report documents) or trigger interactive prompts to allow the user to provide further explanation.

[0092] Optionally, considering the casualness and diversity of chat language, the extraction of requirement descriptions also needs to have a certain degree of fault tolerance and generalization ability. For example, when multiple possible requirement expressions exist in the same context, the system can prioritize them based on word frequency, relevance to the target object (such as mentioning the executor's area of ​​expertise), or completeness of expression, selecting the most likely one as the main requirement description, while using other relevant expressions as supplementary content for task details. Another strategy is that the system can forgo final simplification of the requirement description, instead directly filling in the original sentence or sentence group containing the core information as the task details, while the task name is automatically generated from the matched task template or modified by the user upon later confirmation. This flexible processing logic adapts to the expression habits in different scenarios, ensuring that no core information is omitted.

[0093] Optionally, attachment files refer to electronic files that exist in the task creation context and are related to the task content. By identifying and associating these files, the system enables task data to be accompanied by necessary references or work objects.

[0094] Optionally, the scope of attachment file identification can include files directly attached to the message that triggered the task creation input operation, as well as files sent by the same user or related users within a specific time window or conversation round before and after that message. The system obtains the identification information of these files by scanning the message records of the communication interface, such as filename, file type icon, unique link stored on the server, or hash value. For example, when a user sends the message "@task@Wang Wu, write code based on this plan" and simultaneously uploads a "Architecture Design V2.pdf" file, the system will recognize this PDF file as a valid attachment file in the current task creation context. Subsequently, when generating task data, the system can use the access link or storage path of this file as the value of the associated file field, thereby automatically binding the task to the file and eliminating the need for the user to upload it again in the task management system.

[0095] Optionally, the association strategy for attachment files can be further refined based on file type and contextual semantics. For example, the system can have a built-in mapping relationship between file types and task types. When an attachment is identified as ".xlsx" or ".csv", if the extracted requirement description contains keywords such as "data analysis" or "statistical report", it can be prioritized as the data source file for the task; if the attachment is a requirement document in ".prd" or ".md" format, it will be automatically associated as the requirement basis file for the task. In addition, for "attachments" in the form of cloud storage links, the system can parse the link and obtain the file's metadata (such as title, size, and last modified time) and associate it accordingly. On the user's final task confirmation interface, these automatically associated attachments can be clearly displayed in a list, allowing users to remove incorrectly associated files or manually add other files not automatically captured by the system. This retains necessary space for manual review and correction on top of automation, ensuring the accuracy and completeness of the associated files.

[0096] In an optional implementation, the method further includes: if task-related information meeting preset conditions cannot be extracted from the context, a prompt message for supplementing task information is displayed on the communication interface. Thus, when the information intelligently extracted by the system based on the context fails to meet the minimum standards required to construct a complete task, the automated process can be proactively interrupted and switched to manual guidance mode, requesting the user to supplement the missing content through clear and direct prompts. This mechanism effectively avoids "silent failure" caused by limitations in natural language understanding or ambiguity in context, i.e., the system generates an incomplete or incorrect draft task without informing the user. It ensures the ultimate reliability of this crucial collaborative action of task creation, creating an organic complement between intelligent assistance and final human confirmation. It leverages the efficiency advantages of automatic extraction while ensuring the accuracy and completeness of task data through controllable human intervention, thereby enhancing the practicality and user trust of the entire solution in complex real-world scenarios.

[0097] In the specific task creation interaction process, suppose a user enters in an instant messaging group chat, "@Task@Xiao Li, please review this report and provide analysis opinions before next Monday," but the current chat context does not contain an attachment file named "report." At this point, the system's information extraction module may successfully identify the executor "Xiao Li," the time keyword "before next Monday," and the requirement description "review and provide analysis opinions," but the extraction result for the key task-related file "report" is empty. Since "related file" is a high-priority task field preset by the system (especially when a specific file is explicitly mentioned in the requirement description), its missing state triggers the judgment of "failed to meet preset conditions." Therefore, the system will not directly generate a task draft lacking an attachment, but will display a prompt message on the current communication interface (e.g., above the input box or in a non-modal pop-up): "The task may require the associated file 'report,' but it is not found in the context. Please upload or confirm." Based on this prompt, the user can immediately upload the file in the chat window or click the "Confirm No Attachment" button in the prompt message to continue the task creation process.

[0098] Optionally, preset conditions are used to determine whether the task-related information extracted from the context is sufficient to generate an executable or pending initial task data.

[0099] Optionally, preset conditions can be reflected in the completeness requirements of key task fields. For example, the system may pre-set at least two of the following as required fields: task name, executor, and deadline. If, after matching and transformation, the valid text information and object attribute information extracted from the context still cannot fill any required field, it is determined that the preset conditions are not met. Another judgment logic is based on the confidence level of the extracted information. The system scores the confidence level of identified time keywords, requirement descriptions, etc. If the average confidence level of all key information is lower than a certain threshold, or if the requirement description with the highest confidence level is still lower than the individual threshold, the extraction result is considered unreliable, and a prompt mechanism is triggered. In addition, preset conditions can also be combined, such as requiring "executor field has been determined" and "(task name has been determined or attachment has been associated)". Only when this logical combination is met simultaneously is it considered to have passed the condition check; otherwise, the user will be guided to supplement the most likely missing information.

[0100] Optionally, in addition to hard checks based on field completeness, preset conditions can also include soft checks for information consistency or conflict. For example, the system might identify two potentially contradictory time keywords from the context (such as "tomorrow" and "this Friday," while today is Thursday), or the identified executor's skill tags might be significantly inconsistent with the skills recommended by the task template matched based on the requirements description. In such cases, even if the fields are formally complete, the system might still determine that the preset conditions are "not met" because the generated task data has questionable internal logic. The displayed prompts might then focus on asking the user to clarify the conflict, such as "Two possible time requirements were detected: 'tomorrow' and 'this Friday,' please confirm the final deadline." or "A 'code development' template was matched for 'Zhang San,' but his skill tag is mainly 'UI design,' do you confirm the assignment?" This kind of preset condition incorporates simple logical reasoning, which can further improve the quality of the initial task data and reduce the number of subsequent modifications.

[0101] Optionally, a prompt message for supplementing task information is provided, which aims to guide the user to supplement the necessary information within the current communication interface in a non-intrusive or minimally intrusive manner.

[0102] Optionally, the prompt can be presented as a toolbar or bubble floating above the communication input box. For example, when preset conditions are not met, a bubble containing an icon and brief text, such as "Task Information Incomplete," may appear on the interface, accompanied by a "Add Details" button. Clicking this button may expand a lightweight form overlay, clearly listing the fields identified by the system as missing or with low confidence (such as "Task Name: ?", "Due Date: ?"), and providing quick input controls (such as text input boxes, date pickers, file upload buttons) or suggested options (completion suggestions generated based on context history) next to each field. This design allows users to quickly and precisely add information without leaving the chat context, maintaining the continuity of the interaction flow. The visual representation of the prompt (such as color and animation) can also be differentiated according to the urgency or type of missing information; for example, a red warning for missing executor and a blue warning for missing attachments.

[0103] Optionally, the interaction logic of this prompt can be designed to be more intelligent and foolproof. For example, after the prompt is displayed, the system can simultaneously highlight or quote the most relevant contextual sentences in the chat history to help users quickly locate the source of the missing information. For the prompt "supplement executor," the system can directly list all members of the current chat group in a pop-up for the user to select, instead of manual input. In addition, the prompt can be set to automatically disappear: if the user does not interact with the prompt within a preset time (e.g., 30 seconds), the prompt will automatically disappear, and a task draft containing the extracted information and a clear missing marker will be generated and saved to the "tasks to be improved" list, while leaving a permanent, clickable to-do mark on the chat interface. This avoids the prompt obscuring the interface for a long time and ensures that task clues are not lost. Users can click the mark at any time to bring up the supplementation interface, realizing an asynchronous, non-interrupted task information improvement process.

[0104] In step S250, task data is generated based on the extracted task-related information. This process, by transforming the extracted unstructured contextual information and object attribute information into structured task data through preset or intelligent matching processing logic, achieves a high degree of automation and intelligence in the task creation process. This step acts as a crucial bridge from "information perception" to "executable instruction generation." It is not simply data packaging, but rather deep processing based on enterprise knowledge bases, task templates, and intelligent splitting algorithms. For example, it can transform conversational requests (such as "Check this BUG as soon as possible") into standardized task names (such as "BUG troubleshooting"), and vague time indications (such as "next week") into specific deadlines. It also automatically matches the most suitable task template or executor based on the identity or skill tags of the @object. This not only completely liberates users from tedious and error-prone manual filling, significantly shortening the task creation path, but more importantly, it ensures that the generated task data possesses a high degree of business standardization and execution feasibility. This lays a solid and reliable data foundation for subsequent seamless synchronization and efficient collaboration, fundamentally improving the overall quality and response speed of team task management.

[0105] For example, Figure 3 A schematic diagram illustrating task creation is shown in one exemplary embodiment of this disclosure. For example... Figure 3 As shown, for example, in an instant messaging group for a product development team, the product manager sent three messages: Message 1: "@Zhang San (my name), the key to modifying the document is: navigation list, details, and other critical areas." Message 2: A document named "Report"; Message 3: "Please help me finish the revisions before I leave work tomorrow. This is a very high priority."

[0106] Upon detecting the action "@Zhang San," which includes the target object (Zhang San) and an implicit identity tag, the system triggers the task creation process. The intelligent recognition module extracts task-related information from the context. For example, it extracts "modify document" as the requirement description and "before the end of get off work tomorrow" as the time keyword, and identifies the most recently uploaded "report.docx" file in the group as the associated attachment. Subsequently, task data is generated based on the extracted task-related information: the system automatically matches a task template from the task template library, which includes the task name, task description, task deadline, and task attachments; it fills in "modify document" as the task name based on the context; it fills in "modify navigation list, details, etc." as the task description; it parses "before the end of get off work tomorrow" into a specific date and time based on the current date and fills it into the deadline field; it associates "requirement document V1.2.pdf" as the task attachment; it fills in "very high priority" as "priority-urgent"; and it identifies Zhang San as the task executor. Finally, a structured task data object is generated, containing complete fields such as task name, task description, executor, deadline, associated files, and task priority, awaiting user confirmation or direct synchronization.

[0107] In an optional implementation, the task data includes task executor data. Based on the extracted task-related information, task data is generated, including: determining the task executor according to the object attribute information of the target object. This intelligently determines the task executor based on the object attribute information of the target object, automatically matching the individual or group of executors best suited to the task requirements. This avoids problems such as mismatched selections and skill mismatches that may occur due to information asymmetry or subjective judgment in traditional manual allocation, effectively improving the accuracy and rationality of task allocation. Furthermore, when the target object is a group, this mechanism can intelligently split and assign the total task based on multi-dimensional attributes such as the group members' skill tags and workload, allowing the task load to be distributed and optimized within the team, reducing the manual coordination costs for managers and improving the overall efficiency of team collaboration.

[0108] For example, in a specific team collaboration communication scenario, when a project manager enters in an instant messaging group chat, "Please @testing team complete the test case writing for the new version by next Friday; the relevant requirements document has been uploaded," the system detects the "@testing team" operation, which includes the group target object. It then extracts the group attribute information of the "testing team" (e.g., it includes members Zhang San and Li Si, whose skill tags are "functional testing" and "performance testing," respectively, and whose current workload is "medium" and "idle," respectively). Based on this attribute information, the system can break down the overall task of "test case writing" into two sub-tasks: "functional test case writing" and "performance test case writing," and assign Zhang San and Li Si as the executors of the corresponding sub-tasks, thus automatically completing the precise mapping from the general @ group to specific individual task allocation.

[0109] Optionally, the task executor data, as a key component of the generated task data, may include the unique identifier (such as user ID, account), name, department or team information of the identified executor, and the specific job description or subtask identifier assigned to the task item.

[0110] Optionally, the task executor data is not a static field; its generation and population are highly dependent on the aforementioned object attribute information matching process. For example, when the target object is an individual, the data can be directly associated with that individual's identity identifier; when the target object is a group and the task is split, the data may correspond to a list structure, with each item in the list recording the information of a sub-task executor and its corresponding sub-task details. Furthermore, the data format can be adapted and encapsulated according to the interface requirements of the downstream task management system, such as encapsulating it into a specific JSON object or XML data package, to ensure data compatibility and integrity during cross-platform synchronization.

[0111] Optionally, the core logic for determining the task executor lies in making decisions based on the type of the target object and its associated attribute information. For individual target objects, the determination process is relatively straightforward, usually directly mapping the @mentioned individual as the sole executor of the task. However, to enhance robustness, the system can perform a verification before determination, such as checking whether the individual user's current status (e.g., whether they are online or on vacation) or their skill tags have a minimum degree of match with the task requirement keywords extracted from the context. If the match is too low or the status is abnormal, a prompt can be given on the task confirmation interface, rather than mechanically specifying directly.

[0112] Optionally, for group target objects, determining the task executor involves a dynamic task splitting and intelligent assignment process. Besides the splitting based on members' "skill tags" and "workload" mentioned in the handover document, in practice, more dimensions of attributes or different matching strategies can be introduced. For example, one possible implementation is to prioritize matching based on the semantic similarity between the keywords of the task content and the members' skill tags, assigning the corresponding sub-task to the member with the highest similarity; another parallel implementation primarily considers the balancing of members' workload, prioritizing the assignment of sub-tasks to members who are currently idle or have a lower workload to ensure overall team efficiency. These two approaches have different focuses: the former pursues the quality and professionalism of task completion, while the latter emphasizes the fairness and timeliness of resource utilization. The system can preset a strategy or allow administrators to configure options.

[0113] Optionally, further after the initial intelligent determination, a layer of error prevention and confirmation mechanism can be introduced to improve user experience and system reliability. For example, after the system automatically determines the executor based on attribute information, the recommended executor and its reasons for recommendation (such as "Matching Skill: JAVA Development") can be highlighted on the task confirmation interface, allowing users to manually adjust or reselect. In addition, for the split subtasks, the system can set rules to avoid assigning too many closely related subtasks to different members, leading to collaborative chaos. For example, when keywords such as "close collaboration" or "sequential dependency" are identified in the task description, the splitting strategy can be adjusted, merging related steps and assigning them to the same member or a small team. This retains the efficiency advantages of intelligent determination while reducing the risks associated with automated decision-making through manual review and context-aware rules.

[0114] In an optional implementation, the task executor is determined based on the target object's attribute information, including: if the target object is an individual, the individual is designated as the task executor. Thus, when the system recognizes that the target object of the input operation is a specific individual, it directly establishes that individual as the final executor of the task. This logic maps to the user's most direct intention in instant messaging scenarios to assign tasks by mentioning (@) a specific colleague. It effectively simplifies subsequent task generation logic, eliminating the need for additional filtering, matching, or confirmation steps, thereby significantly reducing the overall operation path from intention generation to task creation completion. Compared to solutions requiring an additional interface for executor selection, this direct determination mechanism based on raw input not only improves the processing efficiency of task allocation and reduces the user's cognitive load, but also fundamentally avoids potential executor assignment errors caused by manually selecting from multiple candidate objects, ensuring the accurate communication and recording of task assignment intentions.

[0115] For example, in a group chat of an instant messaging application used by the team, project manager Zhang San needs to assign the analysis of a user research report to his colleague Li Si. Zhang San types "@Li Si, please analyze this user research report and provide a summary by next Friday" in the chat input box. The "@Li Si" triggers the task creation process. The system uses an intelligent recognition module to determine that "Li Si" is an individual target (not a group or department) and obtains its corresponding object attribute information (such as the job title "data analyst"). In the subsequent steps of generating task data, based on the logic defined by this feature, since the target object is clearly identified as the individual target object "Li Si", the system will not need to pop up an executor selection list or perform complex rule matching, but will directly and automatically determine "Li Si" as the task executor. Subsequently, the system will combine the "by next Friday" (time keyword), "analyze the user research report and provide a summary" (requirement description) extracted from the context, and the possibly associated "research report" attachment file to automatically fill in the corresponding fields of the task template, forming a complete task draft to be confirmed. In this way, Zhang San completed almost all the key information for task allocation with just one natural @ operation and a description of the requirements, greatly improving collaboration efficiency.

[0116] In an optional implementation, the object attribute information includes the attribute information of group members within the target group. Based on the target object's object attribute information, the task executor is determined, including: if the target object is a group target object, the task content is broken down into multiple sub-tasks associated with group members within the target group; based on the attribute information of the group members, a corresponding group member is assigned as the task executor for each sub-task. Thus, when the target object is a group, by breaking down the total task content into multiple sub-tasks associated with group members and accurately assigning executors to each sub-task based on the group members' attribute information, automated and rational task decomposition and allocation can be achieved. This not only avoids the tediousness of manual coordination and splitting but also enables a fairer and more efficient task allocation based on members' actual abilities and current workload, thereby significantly improving the overall efficiency of team collaboration and the quality of task completion, and reducing communication costs and execution delays caused by uneven task allocation or mismatched executors.

[0117] For example, in a specific team collaboration scenario, when the project leader enters in an instant messaging group chat, "@Product Team, complete the user research and requirements document writing for the new version by next Friday. See the attached 'Market Analysis.pdf' for relevant background information," the system identifies the target group as the "Product Team." Subsequently, the system intelligently breaks down the overall task of "completing the user research and requirements document writing for the new version" into two logical subtasks: "User Research" and "Requirements Document Writing." Next, the system queries group members Zhang San (skill tag: User Research, current workload: Medium) and Li Si (skill tag: Product Documentation, current workload: Low). Based on their skill matching and workload, the system automatically assigns the "User Research" subtask to Zhang San and the "Requirements Document Writing" subtask to Li Si, attaching the relevant attachments and setting the deadline to next Friday, thus completing a one-click group task assignment.

[0118] Optionally, the task content refers to the specific work items that need to be performed, which is determined based on valid text information (such as requirement description) identified from the communication context, and serves as the object for subsequent splitting or direct allocation.

[0119] Optionally, the task content can be a core requirement description extracted from the communication interface context using natural language processing technology, such as phrases like "complete the quarterly report," "fix system bugs," or "organize a team meeting." This content typically contains key actions and target objects from the user's intent. The system uses semantic analysis to extract and structure this from the dialogue flow, forming clear and actionable task topics. When determining task content, the system not only identifies explicit instructions but may also consider implicit information in the context, such as previously discussed focus points, repeatedly mentioned keywords, or topics associated with attachment names, to ensure that the extracted task content accurately reflects the user's true intent. Furthermore, the task content determination process may involve ambiguity resolution. For example, when multiple potential task directions exist in the context, the system can comprehensively judge based on the user's identity initiating the @ operation, the dialogue history, or preset enterprise knowledge base preferences, thereby selecting one or more of the most likely task topics as the final task content, providing a clear and unambiguous input basis for subsequent splitting and allocation.

[0120] Optionally, a subtask refers to an independent work unit associated with a specific group member, obtained by logically or functionally dividing the total task content for the group.

[0121] Optionally, subtasks can be generated by semantic parsing and functional mapping of the overall task content. For example, for the overall task of "completing user research and outputting a report," the system can break it down into multiple subtasks such as "designing a survey questionnaire," "conducting user interviews," "data analysis," and "writing a survey report" based on a pre-defined task knowledge graph or common collaboration patterns. Each subtask is associated with specific skill tags required to complete that step (such as "questionnaire design," "data analysis," and "document writing"). The system then matches these skill requirements with the skill tags of each member within the target group. The matching process can comprehensively consider exact matching, partial matching, and skill proficiency levels, prioritizing the assignment of corresponding subtasks to members with high skill compatibility. Furthermore, the decomposition logic is not fixed; it can be dynamically adjusted based on the complexity of the task content, the preset decomposition granularity (such as by stage or by module), or historical decomposition records to ensure that the generated subtasks are both executable and logically constitute a complete closed loop of the overall task.

[0122] Optionally, besides splitting and matching based on skill tags, the generation and allocation of subtasks can also incorporate more dimensions of group member attribute information as a decision-making basis, forming parallel or complementary implementation schemes. For example, the system can prioritize allocation based on members' historical task completion efficiency, quality scores, or professional expertise, automatically assigning more relevant subtasks to members skilled in a certain type of work. Another optional implementation can dynamically schedule tasks based on their urgency and members' current workload: for high-priority subtasks, even if a member's skills match but their workload is full, the system may still allocate them to members with lower workloads and slightly less superior skills to ensure a smooth overall task flow. Furthermore, the allocation of subtasks is not entirely automated; the system can provide a "suggestion-confirmation" mechanism. After automatic splitting and initial matching, the system presents a list of subtasks and suggested executors to the task initiator or group administrator, allowing for manual adjustments or confirmation. This leverages the efficiency advantages of intelligent allocation while retaining necessary human intervention flexibility to adapt to various complex real-world team collaboration scenarios.

[0123] In an optional implementation, the attribute information of group members includes at least one of the following: individual skill tags and workload. By explicitly including skill tags and workload in the attribute information of group members, precise data support is provided for subsequent intelligent task splitting and allocation. In group target object scenarios, the system can match task requirements based on members' skill expertise while considering their current workload to avoid task overload, thereby achieving reasonable and balanced task allocation, effectively improving team collaboration efficiency and reducing management costs.

[0124] For example, in a team project management scenario, when the person in charge mentions in a communication group, "Please have the testing team complete all functional tests of the new version by next Friday and attach a test report template," and specifies the "testing team" as the target group via the @ operation, the system may extract group member attribute information such as skill tags like "automated testing" and "performance testing," as well as the workload reflected by the number of unfinished tasks currently undertaken by each member. Based on this information, when generating sub-tasks subsequently, the system can prioritize assigning the "automated test case writing" sub-task to member Zhang San, whose skill tags match and whose workload is relatively light, while assigning the "performance load testing execution" sub-task to member Li Si, who has the corresponding skills and whose workload is moderate.

[0125] In an optional implementation, the task data includes task content data. Based on extracted task-related information, task data is generated, including determining the task content based on valid text information identified from the context. Thus, by automatically generating task content based on valid text information already existing in the communication context, the system frees users from the repetitive work of manually summarizing, paraphrasing, and filling in task details. This not only significantly compresses the operational path from communication to task creation but also ensures, through programmatic information extraction and structuring, that the final generated task content data maintains a high degree of consistency with the original dialogue intent. This effectively avoids information errors or misunderstandings that may occur due to manual re-entry, improving the automation level and reliability of the entire task allocation process.

[0126] For example, in a specific team collaboration communication scenario, when a user mentions in the instant messaging interface, "Please complete the user research report by next Friday and refer to the draft questionnaire in the attachment," the system can automatically convert "by next Friday" into a specific deadline field value, use "complete the user research report" as the task name field value, and associate "draft questionnaire in the attachment" as the task's file field by recognizing the context. This allows for the quick and accurate generation of a task to be assigned containing complete content data, without requiring the user to leave the chat window or manually fill in any task description.

[0127] Optionally, the task content data is used to carry the core descriptive information of the task, which is generated at least in part based on valid text information identified from the communication context, and is provided in a structured form for subsequent allocation and synchronization.

[0128] Optionally, the specific composition of the task content data may include, but is not limited to, fields such as task name, task description, deadline, and associated files. For example, in an implementation based on a handover document, the system uses natural language processing technology to parse the context, filling the task name field with identified "requirement description" text (such as "conduct user research"), filling the deadline field with "time keywords" (such as "before Friday") after date conversion, and automatically associating the mentioned "attached files" as the task attachment field, thereby forming a complete and information-rich task content data entity. The data generated in this way not only directly serves the current task creation but can also be used as historical data for subsequent queries or statistical analysis.

[0129] Optionally, the presentation of task content data is not fixed; its field set can be dynamically adjusted based on different task templates or enterprise knowledge bases. For example, in a software development scenario, task content data may additionally include specialized fields such as "code repository branch" and "related requirement ID"; while in a marketing activity scenario, it may include fields such as "activity budget" and "target audience." The system can automatically match and apply corresponding field templates to construct task content data based on identified contextual keywords or target object attributes (such as the skill tag "development"), making the generated data more scenario-adaptable and practical.

[0130] Optionally, determining the task content aims to generate or complete the core description of the task through a series of processing logics based on valid text information identified from the communication interface context.

[0131] Optionally, one specific implementation of determining task content involves real-time scanning and semantic analysis of the context text. After detecting a task creation trigger, the system acquires all text content within a certain time window or message range before and after the trigger point. Using natural language processing techniques such as named entity recognition, keyword extraction, and dependency parsing, it filters out valid information fragments related to task attributes. For example, it identifies time entities (such as "tomorrow," "end of Q3"), action-object structures (such as "write test cases," "review contracts"), and file references (such as "see document V1.2"). Subsequently, the system maps these information fragments to predefined task content fields to determine the final task content. This process automates the conversion from unstructured chat text to a structured task description.

[0132] Optionally, the logic for determining task content can also include an intelligent population mechanism based on task templates. The system maintains a task template library containing various task types (such as "Approval," "Development," "Design," and "Research"). Each template defines the fields required for the task content and their default formats. When determining task content, the system first automatically matches the most suitable task template based on keywords identified in the context or skill tags of the target object (e.g., @"Legal Affairs" may be associated with the "Contract Review" template). Then, the identified valid text information (such as the specific contract name and urgency description) is populated into the corresponding fields of the template. This approach not only speeds up content generation but also ensures the standardization and professionalism of the task content.

[0133] Optionally, the process of determining task content can further incorporate fault tolerance and optimization strategies to enhance user experience. For example, when the system identifies multiple possible time information or vague requirement descriptions from the context, after generating preliminary task content, these fields to be confirmed can be highlighted on the task confirmation interface, and alternative explanations can be provided for the user to choose from. Alternatively, the system can set a confidence threshold, automatically filling in fields only when the confidence level of the identified information exceeds the threshold; otherwise, the fields are left empty, prompting the user to manually enter the information. Furthermore, for attachment association, in addition to directly associating files attached to the message, the system can intelligently recommend relevant documents from historical tasks as supplementary associations based on file names or content keywords, thereby making the determined task content more comprehensive and accurate.

[0134] In an optional implementation, the task content is determined based on valid text information identified from the context, including: filling in task fields in the task template according to the valid text information to determine the task content. This automatically fills in the corresponding fields in the task template based on valid text information intelligently identified from the communication context, avoiding the operational fragmentation and time loss caused by users manually switching between different applications and repeatedly entering information, and significantly improving the accuracy and completeness of task information filling. Thus, users do not need to manually extract and translate key information from lengthy chat logs; the system can automatically convert unstructured dialogue content into structured task data, making the task creation process smoother and more efficient, and reducing field omissions or errors caused by human negligence.

[0135] In specific team collaboration scenarios, such as a project manager sending a message in a group chat, "@Zhang San, please complete the user research report by next Friday, referring to the attached requirements document," the system will trigger the task generation process when it detects that the message meets the task creation conditions. The system first identifies valid text information from the message context, including the time keyword "by next Friday," the requirement description "complete the user research report," and the attached file "requirements document." Then, based on this information, the system automatically fills in the corresponding fields in a preset "Research Report Writing" task template: parsing "by next Friday" and converting it into a specific deadline (e.g., "2023-10-27 18:00:00") and filling it in the deadline field; simplifying or directly using "complete the user research report" as the task name and filling it in the task name field; and automatically associating the "requirements document" attachment mentioned in the chat to the task's associated file field. The user can then view this automatically filled information in the pop-up task confirmation interface and make minor adjustments or directly confirm and submit.

[0136] Optionally, populating the task fields in the task template means mapping the identified context information and filling it into the various data items predefined in the task template.

[0137] Optionally, the core of the population operation lies in establishing a mapping relationship between "valid text information types" and "task template field types." For example, "time keywords" identified from the context (such as "tomorrow," "before the first day of work next Monday," or "before the end of Q3") are parsed into specific, formatted date and timestamps by a specific Natural Language Processing (NLP) module or rule engine and populated into the "deadline" or "start time" fields of the task template. Identified "requirement descriptions" (usually phrases or sentences containing actions and goals, such as "revise product PRD" or "troubleshoot server overload") are processed through keyword extraction or summary generation and can be used as content in the "task name" or "task description" fields. For identified "attached files," the system obtains their unique identifier or storage path in the instant messaging session and associates this reference with the "associated files" or "references" fields of the task template, enabling cross-platform synchronous access to file content. This filling is not a simple text copying process, but an intelligent process that includes information transformation (such as time analysis), content extraction (such as extracting the core task from long sentences), and resource linking (such as attachment association), aiming to maximize the use of existing dialogue information and reduce the user's burden of secondary input.

[0138] Optionally, the filling strategy can be dynamically adjusted based on the complexity of the task template and the richness of the contextual information. In one implementation, the system adopts a "full fill" mode, which attempts to find matching contextual information to fill in all non-mandatory fields in the template, generating a task draft with as much detail as possible. In another implementation, the system can adopt a "key field priority fill" mode, automatically filling only core fields such as task name, executor, and deadline, leaving other fields blank or providing recommended values ​​for users to choose from on the confirmation screen, thus balancing automation and user control. Furthermore, the interface feedback for filling is also crucial. For example, on the task confirmation screen, automatically filled fields can be visually distinguished by highlighting, using specific border colors, or adding an "autofill" label, reminding users to focus on these system-generated contents for quick review and correction. If the automatically filled content is ambiguous (e.g., identifying multiple possible time points), the system can provide alternative options next to the corresponding field or present them directly as an interactive control (such as a date picker) for users to make a final confirmation or selection.

[0139] In an optional implementation, task fields in the task template are populated based on valid text information, including at least one of the following: converting identified time keywords into a due date field; using identified requirement descriptions as a task name field; and associating identified attachment files as a file field. By specifically defining several core methods for automatically populating task fields from valid text information, fragmented and unstructured information extracted from the instant messaging context can be accurately and efficiently transformed into structured data required by the task management system. This not only avoids transcription errors, field omissions, or attachment association failures that may occur when users manually switch between multiple applications and repeatedly enter information, but also makes the task creation process smooth and highly automated. This significantly improves the accuracy and completeness of the generated task data while reducing operational steps, ultimately achieving a rapid task creation experience based on context-based intelligent completion.

[0140] For example, in a specific team collaboration chat, when the project leader sends the message "@Zhang San, please complete the market analysis report based on 'Q3 Planning Draft.pdf' before work next Monday," the system recognizes "before work next Monday" as a time keyword and automatically converts it into a specific date and time format to fill in the deadline field. The requirement description "complete the market analysis report" is directly extracted as the task name field. At the same time, the system automatically associates the link or copy of the "Q3 Planning Draft.pdf" file attached to the chat history with the file field of the task. Thus, after user confirmation, a complete and directly assignable task can be generated.

[0141] Optionally, it is used to convert natural language time expressions such as "tomorrow afternoon", "before this Friday", and "early next month" recognized in chat text into a standard date and time format that the task management system can recognize through the built-in date and time parsing algorithm, and fill them into time-related fields such as the task's deadline or planned start time.

[0142] Optionally, in optional embodiments, the identification and conversion process of time keywords can be implemented based on a preset natural language processing model or rule base. For example, the system can pre-build a rule base containing common time expression patterns (such as "Month X Day", "Week X", "Before XX") and their corresponding date calculation logic. After extracting text fragments from the chat context, the system first determines whether they belong to a time expression through keyword matching or regular expressions, and then calculates the time based on the logic defined in the rule base. For example, when "next Monday" is identified, the system calculates the calendar date of next Monday based on the current date; when "two weeks later" is identified, 14 days are added to the current date. To handle more complex or ambiguous expressions (such as "as soon as possible" or "end of the month"), the system can also combine contextual information (such as message sending time, project urgency tags) or provide users with selectable date ranges to choose from, thereby ensuring the accuracy and practicality of the conversion.

[0143] Optionally, and even more optionally, the conversion of time keywords is not limited to a single deadline; it can also generate richer time information based on the needs of the task template. For example, some complex task templates may contain multiple time fields such as "planned start time," "milestone time," and "final deadline." The system can identify multiple related time keywords from a continuous chat text and fill them into different fields based on the task type template or simple logical relationships (such as sequential relationships). For example, in the description "Do research first, give me the first draft next Wednesday, and the final draft next Friday," the system can identify the two time points "next Wednesday" and "next Friday" and fill them into the different stage fields of the task as "first draft submission deadline" and "final draft deadline," respectively. This multi-dimensional automatic filling further reduces the burden of manually sorting out timelines and improves the granularity of task planning.

[0144] Optionally, it can be used to extract the phrases or sentences that best summarize the task objective or core action directly from the contextual semantics of the chat text, and automatically set them as the task name for generating the task, without requiring the user to manually summarize and input them.

[0145] Optionally, in optional embodiments, implementing the requirement description as the task name field can rely on semantic analysis and key information extraction of effective text information from the chat context. The system does not simply extract the entire sentence containing the @ symbol, but rather extracts the core task description by analyzing sentence structure, identifying the subject and object of the action, and filtering out interjections and redundant information. For example, in the message “@Li Si, could you please take a look at the minutes of the last meeting and organize the to-do list? Thank you!”, the system can identify the core verb phrase “organize the to-do list” as the task name, while filtering out non-core social phrases such as “please,” “take a look,” “take a look,” and “thank you.” To achieve more accurate extraction, the system can combine a pre-trained language model to understand the sentence's intent, or utilize common task verb libraries in the enterprise knowledge base (such as “write,” “review,” “test,” and “research”) for matching and weighting, thereby ensuring that the automatically generated task name is both concise and accurately reflects the user's true intent.

[0146] Optionally, it can be used to automatically detect and capture file attachments appearing in the communication interface context, and associate and bind the reference link, storage path or file copy of the attachment with the generated task data, so that the task executor can directly access the relevant files in the task management system.

[0147] Optionally, in optional embodiments, the attachment file identification and association mechanism can cover various file presentation formats. The system can monitor the payload of chat messages, identify various documents, images, compressed files, etc. sent through the file transfer function, and record their unique file identifiers (such as file IDs, cloud storage links). When generating task data, this identifier is written into the task's file association field. In addition, for files appearing in the form of hyperlinks (such as links pointing to internal document libraries, cloud drives, or version control systems), the system can also identify them as associatable "file" resources by parsing the link text or preview information. The association method can be to store a reference to the original chat attachment, or, according to enterprise policies, automatically copy the attachment to the file storage area specified by the task management system and establish a link for the new task, thereby ensuring that even if the original chat history is deleted, the task-related files remain accessible.

[0148] Optionally, to further enhance the intelligence and accuracy of association, the system can also perform content analysis and classification on the identified attachments. For example, when multiple attachments exist in a chat, the system can determine which attachment is most relevant to the core requirements of the task based on the attachment type, name keywords, or through lightweight content analysis, and set it as the primary associated file. For instance, in the message "@Wang Wu, these are the requirements document and design drafts, please start development based on them," if "PRD_v1.2.docx" and "UI_Design.png" are also attached, the system can prioritize associating the requirements document "PRD_v1.2.docx" as the primary reference file for the task based on the task type "development." Simultaneously, the system also supports associating multiple attachments with the same task and adding simple tags (such as "reference document," "design draft," "data source") to them, so that the task executor can more clearly understand the purpose of each attachment. This further strengthens the lossless transmission of information from communication to task execution.

[0149] In an optional implementation, the method further includes: automatically matching a corresponding task template from a task template library based on the object attribute information of the target object. This automatic matching of task templates based on the target object's attribute information not only eliminates the tedious process of manually browsing, recalling, and selecting suitable templates when creating a task, further simplifying the task configuration steps and significantly improving the efficiency of the overall process, but also ensures that the generated task is highly compatible with the executor's professional field in terms of structure, fields, and requirements because the matching process is closely linked to the executor's responsibilities, skills, or identity tags. This improves the standardization of task descriptions and the relevance of task execution, reducing subsequent misunderstandings, repeated communication, and rework costs caused by improper template selection or inconsistent task formats.

[0150] For example, in a team collaboration scenario, when a project manager enters in a group chat, "@UI designer, refer to this product document and output the visual draft of the new interface by next Friday," the system recognizes the professional attribute of the target object, "UI designer," and automatically matches a preset "interface design task template" from the task template library. This template usually contains professional fields such as "design requirement link," "design software version," "output format specifications," and "review nodes." Then, combined with contextual information, it automatically fills in some content, quickly constructing a to-do task that is both professional and fits the role's workflow.

[0151] Optionally, the task template library is used to centrally store multiple predefined task template structures to support automated matching and invocation based on object attributes.

[0152] Optionally, the task template library can be deployed on an enterprise intranet server or cloud storage service. The task templates stored within are typically predefined and configured by team administrators based on the organization's workflow, project type, or role responsibilities. Each template is essentially a structured data model, containing at least basic fields such as task name, task description, deadline, priority, and associated resources. It often extends to specific function-related fields; for example, a template for a "test engineer" might include "test environment," "test case coverage," and "defect tracking links," while a template for a "financial specialist" might include "reimbursement form number," "approval process," and "invoice list." These templates typically exist in the library as database records or configuration files, accompanied by metadata tags such as the applicable set of job titles, a list of skill keywords, and project type identifiers. This metadata serves as a key index for the subsequent intelligent matching process. The template library's maintenance interface allows administrators to perform CRUD operations, ensuring that template content is updated synchronously with the team's evolving practices, thereby guaranteeing that tasks created through the system always maintain a consistent professional format and process standardization.

[0153] Optionally, the composition and sources of the task template library can be diversified and not limited to a single centralized static library. One possible implementation is that the system supports automatically learning and generating commonly used templates from users' historical task data through cluster analysis. For example, continuously analyzing all past "feature development" tasks completed by a "development engineer" user, extracting common fields (such as "Git branches," "unit test requirements," and "integration testing time"), forming their frequently used task templates, and incorporating them into their personal template library. Another alternative is to establish a hierarchical template library system, such as setting up a company-level global template library, a department-level template library, and a project-level template library. Matching follows the principle of proximity, prioritizing searching from the project or department library to which the target object belongs. If no match is found, it then backtracks upwards level by level. This satisfies the personalized needs of different levels while utilizing the global library as a fallback. Furthermore, the physical storage format of the template library can be flexibly selected according to performance requirements. For example, frequently accessed templates can be cached in memory to improve matching speed, while all templates are persistently stored in a relational database or document database.

[0154] Optionally, matching refers to the intelligent process of automatically selecting suitable task templates from the task template library based on the object attribute information of the target object and by calculating the correlation with the task template metadata.

[0155] Optionally, the core logic of the matching process lies in constructing a mapping and scoring system between the object attribute dimension and the template applicability dimension. After obtaining the target object's attribute information (such as the individual's occupation "backend development" and skill tags "Java, Spring Cloud"), the system traverses the metadata tags of all templates in the task template library (each template predefines its applicable roles, skill sets, or project scenarios) and performs similarity calculations. The calculation method can be diverse, such as precise matching based on keywords, fuzzy matching based on semantic vectors, or prediction using a pre-trained classification model. In a specific embodiment, the system assigns weights to the applicability tags of each template. When the target object's attribute keywords overlap with the template tags, the corresponding weights are accumulated to obtain a matching score, and the template with the highest score is finally selected. For example, a "service module development template" tagged with "Java development" and "microservices" will have a significantly higher matching score than a template tagged only with "Python script" when encountering a target object with the attribute "Java engineer". The entire matching process is completed silently in the background, without requiring users to actively query or select, thus completely handing over the burden of user cognitive decision-making to the system for automated processing, achieving seamless task template recommendation.

[0156] Optionally, the matching decision conditions can be further enriched and refined, introducing multi-factor weighting and context-aware mechanisms to improve matching accuracy and scenario adaptability. Besides directly using the target object's static attributes (such as job title and skill tags), the matching algorithm can dynamically incorporate information from other dimensions, such as the object's recent task type preferences, activity level in the current project, and even historical task completion quality evaluation data. For example, for an engineer with both "front-end development" and "user experience design" skill tags, if most of their recent tasks are related to "interaction optimization," the system can assign higher weight to the "UI optimization task template" during matching. Another extension is supporting composite matching of group target objects. When the target object is a group, the system can analyze the commonalities in the attributes of group members (such as most members possessing the "Agile Coach" skill) or identify group tags (such as "sprint iteration team") to match team collaboration templates, such as the "Sprint task splitting template." Furthermore, the matching rules themselves can be configurable, allowing administrators to define complex matching logic through the rule engine. For example, "when the target object's skills include 'data analysis' and the job title is 'senior specialist,' prioritize matching 'in-depth analysis report template'; if the project stage is 'final,' then match 'project review template.'"

[0157] Optionally, considering boundary conditions in practical applications, the matching module also needs to integrate robust fault tolerance and interactive confirmation mechanisms to ensure the robustness of the process and user controllability. A common error prevention design is to set a matching confidence threshold. When the calculated highest matching score is lower than this threshold (e.g., 60%), the system determines it as a "low-confidence match" or "no match". At this time, the system can execute a preset degradation strategy: first, automatically select a preset, simplified general task template as the default output to ensure that the task creation process is not interrupted; second, while generating the task draft, prominently prompt the user on the task confirmation interface that "the system could not find a highly matching dedicated template, a general template has been used, and it is recommended that you check or select manually". Furthermore, the system can record such low-confidence matching events and periodically generate reports for administrators to optimize template library tags or add new templates. At the interaction level, even if the match is successful, the system can provide a brief description of the matching result on the interface (e.g., "Matching basis: Your 'Test Engineer' role") and allow users to easily view other candidate template lists and manually switch before one-click confirmation. This approach ensures the smooth operation of the automated process while also empowering users with the right to final review and adjustments through flexible design, thus preventing a decline in user experience due to errors in automated decision-making.

[0158] In step S270, the task data is synchronized to the task management system. By automatically transmitting the intelligently generated structured task data from the preceding steps to a dedicated task management platform, seamless and automated flow of task information is achieved. This completely avoids the operational fragmentation and inefficiency caused by users manually switching applications and repeatedly entering information in traditional solutions. Furthermore, it creates an efficient, reliable, and user-unobtrusive digital closed loop from communication context triggering to final task traceability, significantly improving the overall efficiency and reliability of task distribution and follow-up in team collaboration.

[0159] For example, in a team collaboration instant messaging scenario, when a project manager enters "@task@test team, complete the stress test of the new version by next Friday, see attached test_plan.docx for specific parameters" in a group chat and confirms the task generation, the system immediately executes this step in the background. This step does not require the project manager to perform any additional operations such as "jumping to task management software" or "clicking the sync button." Instead, the client or server automatically calls the predefined data interface with the task management system to push the generated task data package, which contains complete fields such as "executor: test team (specific members split according to skill tags)," "task name: new version stress test," "deadline: next Friday," and "associated file: test_plan.docx," to the enterprise's task management system in a secure and reliable manner. The system then automatically creates a corresponding to-do task item, thus completing the instant transformation from a chat command to a formally assignable and trackable task.

[0160] Optionally, the synchronization operation is used to automatically transmit the generated task data to the task management system to achieve cross-platform task information updates and status consistency.

[0161] Optionally, the specific implementation of the synchronization operation can be based on a pre-configured Application Programming Interface (API) or middleware technologies such as message queues. In one optional embodiment, when the user clicks "Confirm Creation" on the aforementioned task confirmation interface or when the system automatically triggers synchronization, the client or backend service encapsulates the generated task data and, according to the API protocol specifications (such as RESTful API or GraphQL) publicly disclosed by the task management system, initiates one or more network requests, sending the task data as the request body (Payload) to the designated endpoint of the task management system. To ensure a seamless and smooth user experience, this synchronization process is usually executed asynchronously in the background. That is, after the user submits confirmation, the communication interface can immediately resume normal chat interaction, while the synchronization process runs in the background without requiring the user to wait. Further optionally, to cope with abnormal situations such as network fluctuations or temporary unavailability of the target system, the synchronization mechanism can also include retry logic and local caching strategies. For example, when the initial synchronization fails, the system can temporarily store the task data in a local database or cache and initiate a retry mechanism using an Exponential Backoff algorithm. During the subsequent network recovery period, the system can automatically retry synchronization, thereby ensuring that the task data can eventually be successfully delivered and improving the robustness and reliability of the entire solution.

[0162] Optionally, the success or failure of the synchronization operation and its final status can be fed back to the user in various ways to enhance the certainty and transparency of the interaction. For example, after a synchronization request is successfully sent and a confirmation response is received from the task management system, a non-modal, short-lived prompt message, such as "Task has been synchronized to [Task Management System Name]," can be displayed near the original message on the communication interface or in the notification area at the top / bottom of the interface. Conversely, if synchronization continues to fail due to network or system reasons, a more prominent prompt can be triggered, such as informing the user in the original position of the task confirmation interface or through a pop-up window, "Task synchronization failed. It has been saved to a local draft. Please try again later or check the network," and may also provide a "Manual Retry" button control. This status feedback mechanism allows users to clearly know the result of their operation even in the context of seamless synchronization, avoiding user doubts about whether the task has been successfully created due to the system's silent processing, thereby optimizing the overall human-computer interaction experience.

[0163] Optionally, the task management system is used to receive, store, manage, and display synchronized task data, and provide users with task tracking, status updates, and collaboration functions.

[0164] Optionally, in the context of this disclosure, the task management system refers to any third-party or self-built platform capable of receiving and managing structured task data. Its specific form can be diverse; for example, it can be independently deployed enterprise-level project management software (such as Jira, Asana, Trello, and similar products), a task management module integrated into an office suite, or an internal task tracking tool developed by the team itself. The core function of this system is to provide a centralized management view for synchronized tasks, enabling task performers to clearly see their assigned work, deadlines, and related resources, while managers can easily track overall progress. This solution interfaces with these systems through standardized data interfaces, achieving a smooth transition from lightweight, instant communication scenarios to heavy-duty, structured task management scenarios. It should be noted that the focus of this disclosure is on how to intelligently generate task data from the communication context and automatically trigger synchronization. How the task management system displays, sorts, or further processes this task data is not limited; this is entirely determined by the existing logic of the receiving system, thus demonstrating the good openness and compatibility of this solution.

[0165] In an optional implementation, before synchronizing task data to the task management system, the method further includes providing a task confirmation interface for users to confirm or modify task data. This embedding the task confirmation interface into the automated task generation process provides a crucial human-computer interaction verification point for the system's automatic extraction, matching, and generation of task data. Users can conduct a final review and necessary correction of key fields such as task executor, task content, and deadline before final data synchronization, effectively improving the accuracy and reliability of data synchronized to the task management system and avoiding erroneous task assignments due to natural language comprehension biases, missing contextual information, or ambiguous user intent. Simultaneously, this design respects and preserves the user's final decision-making and control rights in the automated process, enhancing user trust and satisfaction with the intelligent assistance function, thus achieving a balance between "rapid triggering" and "data accuracy."

[0166] In a specific team collaboration chat scenario, when a project manager types "@task@testing team, complete the user experience testing of the new version by next Friday. See the attached test_cases.docx for specific test cases" in a group chat, the system triggers the task creation process and automatically identifies the target group "testing team," the time keyword "by next Friday," the requirement description "complete the user experience testing of the new version," and the attached file. Subsequently, based on the skill tags and workload of the "testing team" members, the system breaks down the total task into several sub-tasks and automatically fills in the fields according to the "software testing task template." After this, the system does not directly synchronize; instead, it provides a task confirmation interface in a non-modal pop-up window on top of the current chat interface. This interface clearly lists the sub-tasks to be assigned, the suggested executor for each sub-task, the automatically converted deadline, the task name generated from the requirement description, and the associated attachments. The project manager can quickly browse all the information on this interface. If a member's workload is already full, they can directly replace them on the interface; if there are any objections to the automatically generated deadline, the date can be manually adjusted. Only after the user clicks the "Confirm and Assign" button on the interface will this set of final verified task data be seamlessly synchronized to the task management system in the background.

[0167] Optionally, the task confirmation interface is used to display an overview of the task data automatically generated by the system to the user before the task data is synchronized, and to receive the user's final confirmation or modification instructions for the data.

[0168] Optionally, the task confirmation interface can be presented as a floating card or pop-up window overlaying the communication interface. Its layout should at least include a task data display area and an operation button area. In the data display area, the system will display automatically extracted and generated key task fields in a structured manner. For example, it may display the task executor and their corresponding sub-tasks in a list format, highlight the task name and deadline, and provide a preview or download link for attachments. The operation button area should at least include two types of trigger controls: "Confirm" and "Modify." The "Confirm" control instructs the system to perform synchronization based on the currently displayed data, while the "Modify" control may further trigger a field-level editing panel, allowing users to fine-tune specific fields. This design ensures that users can efficiently verify and correct automated results without leaving the current communication context.

[0169] Optionally, the task confirmation interface can also be designed as a dynamic panel that slides in from the side or pops up from the bottom of the communication interface, and its data organization can adaptively change according to the complexity of the task. For simple individual task assignments, the interface may only display core information such as the task name, executor, and deadline; while for complex group task splitting, the interface may use a collapsible group list, allowing users to expand and view the details of each subtask one by one. In addition, to further improve operational efficiency, the interface can also integrate intelligent auxiliary modification functions. For example, when the user clicks to modify the "executor" field, the interface not only provides a list of members to select, but also displays the current workload or skill matching degree of each member as a reference, thereby assisting the user in making more reasonable adjustment decisions. This combination of flexible interface form and intelligent assistance allows the confirmation process to adapt to the user experience needs of different scenarios.

[0170] Optionally, considering the prevention of accidental touches and operational continuity, the task confirmation interface can also incorporate a series of interactive logic. For example, the interface may be accompanied by slight visual emphasis (such as a background overlay) to focus the user's attention. If the user does not perform any operation for a period of time, the interface can automatically collapse or fade, and retain a thumbnail prompt that can be expanded again at the original trigger location. In modification scenarios, the system can perform real-time compliance checks on the user's modified data, such as checking whether the deadline is earlier than the current time, whether the executor is still in the project team, etc., and provide immediate prompts for non-compliant modifications. Furthermore, the interface can also provide two modes: "One-click Accept All" and "Item-by-Item Confirmation." The former is suitable for scenarios where users highly trust the system's generated results to pursue ultimate efficiency, while the latter provides a more cautious verification path. This design takes into account the different user habits and the requirements of the task's criticality regarding the strictness of confirmation.

[0171] In an optional implementation, after synchronizing the task data to the task management system, the method further includes displaying a notification message indicating successful task synchronization on the communication interface. By providing clear notification messages on the communication interface immediately after successful task data synchronization, the uncertainty of the user's operation results can be effectively eliminated, avoiding redundant steps such as repeated submissions or forced redirection to external systems for manual confirmation due to lack of feedback. This further solidifies the core advantage of this solution in reducing operational processes. Furthermore, this closed-loop feedback within the original operational context greatly enhances the integrated and seamless interactive experience of the "trigger-assignment-synchronization" process, allowing users to obtain reliable confirmation of operation results without interrupting the current communication scenario, thus increasing user trust in the system's automated and intelligent processing capabilities and their willingness to use it.

[0172] For example, when a product manager enters "@Test Engineer Xiao Wang, complete the test cases for the login module by next Friday; see the attached requirements document" in an instant messaging group and triggers task creation, the system automatically extracts information, matches templates, generates task data, and attempts to synchronize it to the enterprise task management platform. Once the backend confirms that the synchronization interface call was successful and the data has been received by the task management system, without any additional user operation or interface jump, a prompt will immediately appear near the chat message or in a specific area of ​​the screen (such as the top notification bar or floating bubble). For example, a green checkmark icon combined with the brief text "Task has been successfully synchronized to the task system" clearly conveys the completion status of "task has been assigned and archived" to the product manager and group members who may be interested in this matter.

[0173] Optionally, the prompt message is used to convey the result status of the task synchronization operation to the user in the communication interface, and its triggering depends on the background confirmation of the synchronization success status.

[0174] Optionally, the presentation of the notification message in the communication interface can be diverse, at least partially including visual or auditory content to clearly indicate to the user that the task data has been successfully delivered to the external task management system—a crucial event. For example, an intuitive implementation could be to dynamically pop up a semi-transparent floating notification box (Toast) or banner next to the original chat message bubble that triggered the task creation or in a fixed notification area on the screen. This notification box could contain a success icon (such as a green checkmark or a circular exclamation mark), concise status text (such as "Task synchronization successful," "Assigned to task list"), and possibly a timestamp. This design provides clear, timely, and non-intrusive operational feedback without significantly interfering with the user's continued browsing of chat history. To accommodate different user preferences and interface styles, the visual style parameters of the notification message, such as background color, transparency, display duration, and appearance / disappearance animation effects (such as fade-in / fade-out, slide-in from the side), can be personalized according to the client theme or user settings.

[0175] Alternatively, besides the floating notification box format mentioned above, notification information can also be carried by various other UI elements to adapt to different interaction scenarios and interface layouts. For example, in a chat list interface, a small red dot with the number "1" or a specific icon can be temporarily displayed on the right side or in the corner of the corresponding conversation item to indicate to the user that a task has just been successfully synchronized in that conversation; or, a persistent or temporarily active task status indicator can be set in the bottom navigation bar or function bar area of ​​the communication interface, which will briefly highlight or change color when synchronization is successful. Another lighter alternative is to use sound notifications, that is, to play a short, pleasant success sound effect after detecting successful synchronization, which is especially user-friendly for users whose visual attention is not on the screen. These different notification formats each have their advantages: floating notification boxes display the most direct and comprehensive information; corner notifications occupy the least amount of interface space; status indicator lights provide continuous, non-intrusive global status awareness; and sound notifications achieve feedback across visual channels.

[0176] Optionally, considering that the display of prompts should not hinder normal user communication interactions, its triggering and display logic can also include deeper error prevention and adaptive mechanisms. For example, the system can monitor the current active area of ​​the communication interface and the user's possible touch focus in real time: if it detects that the user's finger or cursor is performing a fine operation (such as text selection, long-press to bring up the menu) at the location where the prompt is about to appear, it can intelligently delay the display of the prompt, or present it in a relatively empty area on the other side of the screen, to avoid obscuring key operation areas and causing accidental touches. In addition, the display duration of the prompt can also be dynamically adjusted according to its content priority and the current interface activity: for simple success prompts, a strategy of automatically disappearing after a short time (such as 2 seconds) can be adopted; if the successfully synchronized task contains particularly important attributes (such as high priority, involving multiple people), the prompt can be displayed for a longer period of time, or an interactive "view details" button can be provided. After the user clicks, a card can be expanded to preview the core fields of the synchronized task (such as executor, deadline), thus providing immediate feedback while also giving the user a quick entry point for verification, further enhancing the reliability and transparency of the operation.

[0177] Optionally, successful task synchronization indicates that the task data has been received and processed by the task management system, which serves as the core condition for triggering the display of prompt information.

[0178] Optionally, the determination of a successful task synchronization status is based on the return result after data interaction between the client or server and the external task management system. In the specific implementation, after generating task data, the system initiates a synchronization request to the task management system through a predefined application programming interface (API). This request encapsulates the task data packet. Upon receiving the request, the task management system verifies and stores the data, then returns a response containing a status code (e.g., HTTP status code 200 indicating success) and a possible message body (e.g., the unique ID of the newly created task). After parsing this response, the client or the background service responsible for synchronization determines "task synchronization successful" if both the status code and message body meet the preset "success" conditions (e.g., status code 200 and a valid task ID in the message body), and then triggers the process of displaying the corresponding prompt information on the communication interface. This determination logic ensures the accuracy of the prompt information and avoids false success reports due to network latency or brief system anomalies.

[0179] Optionally, the successful task synchronization status can be further subdivided and corresponding to different prompting strategies to provide more precise feedback. For example, successful synchronization might include "complete success" (all fields of the task have been received) and "partial success" (the main task was created successfully, but some attachments failed to upload due to formatting issues). For "complete success," a standardized success message can be displayed (such as a green checkmark icon and the text "Task synchronization successful"). For "partial success," more detailed explanations or warnings can be added to the success message, such as a yellow exclamation mark icon with the text "Task created, but some attachments failed to synchronize; please check." This fine-grained status feedback allows users to be aware of potential minor anomalies even in automated processes and intervene when necessary, thereby improving efficiency without sacrificing control over key details. In addition, the successful synchronization status information itself can be recorded as a special system message back into the current communication session context, forming a permanently searchable operation log for easy subsequent traceability.

[0180] The following is for reference. Figure 4 The electronic device is illustrated by way of a general-purpose computing device. It should be understood that... Figure 4 The electronic device 400 shown is merely an example and should not be construed as limiting the functionality and scope of use of the embodiments disclosed herein.

[0181] like Figure 4 As shown, the electronic device 400 may include: a processor 410, a memory 420, a bus 430, an I / O (input / output) interface 440, a network adapter 450, and a display 460.

[0182] Memory 420 may include volatile memory, such as RAM 421 and cache unit 422, and may also include non-volatile memory, such as ROM 423. Memory 420 may also include one or more program modules 424, such program modules 424 including, but not limited to: operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. For example, program module 424 may include the modules in the above-described device.

[0183] Processor 410 may include one or more processing units, such as: AP (Application Processor), modem processor, GPU (Graphics Processing Unit), ISP (Image Signal Processor), controller, encoder, decoder, DSP (Digital Signal Processor), baseband processor and / or NPU (Neural-Network Processing Unit).

[0184] The processor 410 can be used to execute executable instructions stored in the memory 420 to perform the methods described above in this disclosure, such as the following method steps: an information processing method in a game, the method comprising: displaying a functional system interface in the game, the functional system interface at least partially obscuring the game scene; in response to detecting a hit event of a controlled virtual object in the game scene, acquiring game information associated with the hit event; and displaying visual cues corresponding to the game information in the functional system interface.

[0185] Bus 430 is used to connect different components of electronic device 400 and may include a data bus, an address bus and a control bus.

[0186] Electronic device 400 can communicate with one or more external devices 500 (such as keyboard, mouse, external controller, etc.) through I / O interface 440.

[0187] Electronic device 400 can communicate with one or more networks via network adapter 450. For example, network adapter 450 can provide mobile communication solutions such as 3G / 4G / 5G, or wireless communication solutions such as wireless LAN, Bluetooth, and near-field communication. Network adapter 450 can communicate with other modules of electronic device 400 via bus 430.

[0188] Electronic device 400 can display a graphical user interface, such as virtual scenes or virtual characters, through display 460.

[0189] although Figure 4 Other hardware and / or software modules may also be configured in the electronic device 400, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID (Redundant Arrays of Independent Disks) systems, tape drives, and data backup storage systems.

[0190] As can be seen from the above, the technical solutions disclosed herein can be implemented as methods, apparatus, systems, computer program products, storage media, electronic devices, etc. Those skilled in the art will understand that various aspects of this disclosure can be specifically implemented in the following forms: a completely hardware implementation, a completely software implementation (including firmware, microcode, etc.), or an implementation combining hardware and software aspects, which may be referred to as "circuit," "module," or "system," respectively.

[0191] It should be understood that this disclosure is not limited to the specific methods, steps, or structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. Those skilled in the art will readily conceive of other embodiments based on the specific implementations provided in this disclosure. Therefore, the specific implementations provided in this disclosure are merely exemplary, and the scope and spirit of this disclosure are indicated by the claims, and should cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary technical means in the art not disclosed in this disclosure.

Claims

1. An information processing method, characterized in that, The method includes: In response to the detection of an input operation containing a task creation indicator and a target object in the communication interface; Extract task-related information from the context of the input operation and / or the communication interface; Based on the extracted task-related information, task data is generated; The task data will be synchronized to the task management system.

2. The method according to claim 1, characterized in that, The target audience includes at least one of the following: individual target audience, group target audience.

3. The method according to claim 1, characterized in that, The task-related information includes: object attribute information of the target object, and valid text information; The target object's attribute information includes: attribute information of individual target objects and attribute information of group target objects; The attribute information of an individual target includes: personal occupation and personal skill tags; The attribute information of the target group includes: group tags, group member occupations, group member skill tags, and group member workload.

4. The method according to claim 3, characterized in that, The task data includes task executor data, and the generation of task data based on the extracted task-related information includes: The task executor is determined based on the object attribute information of the target object.

5. The method according to claim 4, characterized in that, The step of determining the task executor based on the object attribute information of the target object includes: If the target object is an individual target object, then the individual target object is determined as the task executor.

6. The method according to claim 5, characterized in that, The object attribute information includes the attribute information of group members in the target group object. Determining the task executor based on the object attribute information of the target object includes: If the target object is a group target object, the task content is split into multiple sub-tasks associated with the group members within the group target object; Based on the attribute information of the group members, the corresponding group member is determined as the task executor for each subtask.

7. The method according to claim 6, characterized in that, The attribute information of the group members includes at least one of the following: the group member's individual skill tags and workload.

8. The method according to claim 7, characterized in that, The task data includes task content data. Based on the extracted task-related information, task data is generated, including: The task content is determined based on the valid text information identified from the context.

9. The method according to claim 8, characterized in that, Determining the task content based on the valid text information identified from the context includes: Based on the valid text information, fill in the task fields in the task template to determine the task content.

10. The method according to claim 9, characterized in that, The valid text information includes at least one of the following: time keywords, requirement description, and attachments.

11. The method according to claim 10, characterized in that, The step of filling the task fields in the task template based on the valid text information includes at least one of the following: The identified time keywords are converted into a due date field; The identified requirement description will be used as the task name field; The identified attachment files are associated with a file field.

12. The method according to claim 11, characterized in that, The method further includes: Based on the object attribute information of the target object, the corresponding task template is automatically matched from the task template library.

13. The method according to claim 1, characterized in that, Before synchronizing the task data to the task management system, the method further includes: A task confirmation interface is provided, which is used by the user to confirm or modify the task data.

14. The method according to claim 1, characterized in that, After synchronizing the task data to the task management system, the method further includes: The communication interface displays a message indicating that the task synchronization was successful.

15. The method according to claim 1, characterized in that, The method further includes: If no task-related information that meets the preset conditions can be extracted from the context, a prompt message for supplementing task information will be displayed in the communication interface.

16. An electronic device, characterized in that, include: Processor, memory, and computer program instructions stored in said memory and executable on the processor; When the processor executes the computer program instructions, it implements the information processing method as described in any one of claims 1 to 15.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions, which, when executed by a processor, are used to implement the information processing method as described in any one of claims 1 to 15.

Images