待办事项提取

这项能力到底在做什么

待办事项提取，简单说，就是从会议纪要、聊天记录、项目记录、回访内容等材料里，把“接下来谁要做什么、什么时候做”抽出来。

很多企业并不是没有分工，而是分工说过了，却没有被稳定记录成待办。
常见情况通常是这样：

会上口头定了动作
群里顺手交代了事项
回访里提到需要后续跟进
周报里写了问题，但没拉成具体动作

待办事项提取真正解决的，不是替人安排工作，而是先把已经说过、已经决定过的动作从原始内容里拎出来。

它通常接收什么输入

这项能力接进来的，通常是一段包含任务信息的原始内容。

常见输入包括：

会议纪要
聊天记录
周报内容
客户沟通记录
项目日志
回访摘要

一起带进来的上下文，常见还有这些：

项目或事项名称
参会人或责任人名单
时间信息
优先级规则
任务模板
输出格式要求

这些上下文很关键。因为待办不是只看动词，而是要知道：

这是不是明确动作
谁负责
什么时候做
这件事重不重要

它能输出什么结果

待办事项提取最后交出去的，不应该只是一串句子，而应该是一份可继续流转和提醒的任务结果。

常见输出包括：

输出项	说明
待办内容	要做什么
责任人	谁来做
截止时间	什么时候前完成
优先级	高、中、低
来源位置	这条待办来自哪段内容
待确认标记	哪些责任或时间还不清楚

这样下游拿到的，就不是模糊的“大家去跟一下”，而是一份更能执行的任务列表。

它在内部是怎么跑起来的

待办事项提取真正难的地方，不是把句子挑出来，而是分清哪些是讨论，哪些是已经定下来的动作。
它在内部通常会经过下面这条链。

1. 先读取原始内容

系统先拿到纪要、聊天、周报或回访记录。

2. 再识别动作性表达

系统会重点找：

要做什么
谁来做
什么时候做
需要配合什么

3. 再补责任和时间信息

如果原文里责任人或时间写得不完整，系统会尽量从上下文中补足。

4. 再判断优先级

不是所有待办都同样重要。
系统会结合语气、时限和影响范围做初步分层。

5. 再标记不清楚的地方

比如责任人缺失、截止时间不明、动作描述太模糊，会被单独标出来。

6. 最后输出待办清单

这样后面的提醒、分派和周报流程就能直接接上。

详细内部流程图

flowchart TB
    A[输入纪要、聊天、周报或回访内容] --> B[识别动作句、责任句和时间信息]
    B --> C[补充责任人、截止时间和上下文]
    C --> D[判断优先级和影响范围]
    D --> E[标记模糊或待确认项]
    E --> F[输出结构化待办清单]
    F --> G[交给提醒、分派、周报和项目管理流程]

它最后会把什么交给下游流程

待办事项提取真正交给下游的，不只是任务句子，而是一份能真正推动执行的任务清单。

常见会交出去这些内容：

待办内容
责任人
截止时间
优先级
来源位置
待确认标记

这样后面的流程才能继续做：

任务提醒
工单创建
项目周报
管理看板

它怎么接入业务才真正有价值

待办事项提取最怕的，不是提不出来，而是提出来以后没人接着用。

真正常见、也最有价值的接法，一般有下面几种：

1. 接在会议纪要后面

纪要一出，待办马上跟上，执行会快很多。

2. 接在项目和交付场景里

事项多、角色多时，这项能力特别值钱。

3. 接在客户沟通之后

客户提的明确动作如果能马上进入待办，漏项会少很多。

4. 接在提醒流程前面

只有先有结构化待办，后面的提醒才有目标。

什么情况下必须转人工

待办事项提取虽然很适合自动化，但下面这些情况最好让人工确认：

原文表达很模糊
责任人有争议
截止时间不清晰
事项影响很大
多部门责任交叉
提取结果会直接进入强执行流程

真正稳的企业做法，不是让系统直接决定所有任务，而是让系统先把清楚的待办拉出来，把模糊的交给人确认。

为什么这项能力站得住

待办事项提取之所以在企业里很有价值，是因为很多执行问题不是没人做，而是事情从“说过了”到“真的进入执行清单”这一步掉了。
只要这一步补上，很多流程都会顺很多。

1. 它先解决的是“会里说过，事后没落下”

这在项目和协同场景里非常常见。

2. 它能明显减少漏项

结构化任务清单比口头记忆可靠得多。

3. 它特别适合多事项并行团队

事项越多，这项能力越重要。

4. 它边界清楚，适合人工复核

系统先提取，人再确认。
这种方式很实用。