---
author: OOMOL
author_url: https://oomol.com/zh-cn/about/
datePublished: 2026-10-15
title: 会议纪要写完了，下一步该交给谁？
description: 让助手整理会后任务时，保留建议、决定与承诺的区别，明确交付物、负责人和期限，再把确认过的事项交到团队实际使用的系统里。
lang: zh-CN
canonical_url: https://oomol.com/zh-cn/blog/ai-meeting-handoff/
markdown_url: https://oomol.com/zh-cn/blog/ai-meeting-handoff.md
---

![会议笔记中的周五初稿请求，旁边任务单的负责人和期限仍待确认](/blog/ai-meeting-handoff/zh-cn-cover.webp)

*AI 生成的概念插图，内容为假设示例。*

假设一次客户会议结束后，助手整理出三条行动项：周五交付新版方案、小林负责报价、下周安排演示。纪要看起来很清楚，每条都像有人、有日期。

但回到会议记录，客户问的是“周五能不能先看一版”；小林说的是“我找销售确认一下价格”；演示则要等客户准备好测试数据。

如果直接把这三条写进任务系统，团队就多出了几个尚未答应的承诺。等到周五，客户等方案，小林收到报价催办，演示邀请也已经发出。会议里留下的不确定性，在整理过程中消失了。

会后交接要保留这些区别。助手可以提取待办、补充上下文、准备写入，但每一条任务都应说明：已经确定了什么，还有什么要由谁来决定。

## 把建议、决定和承诺分开

“我们可以试试另一种报价”是一项建议。“这次采用按月报价”是一项决定。“我周四把报价表发给你”则包含了具体承诺。三句话都与报价有关，后续处理却不同：建议要等人采纳，决定已经生效，承诺则让对方有了一层可以预期的义务。

会后整理把三者都写成“行动项”，这个区别就消失了。Lindy 的[会议记录指南](https://www.lindy.ai/blog/how-to-take-meeting-minutes)和 Viktor 的[当天完成会后跟进](https://viktor.com/blog/same-day-follow-up)分别从纪要写法和跨应用跟进切入会后工作，但一句话到底形成了什么约定，仍要单独判断。

判断的依据是材料里已有的证据：是否有人采纳，是否经过批准，是否由承诺人本人说出，是否指定了时间。找不到这些依据时，就按建议或待确认处理。

对于前面的假设会议，可以这样整理：

| 会议里的表述 | 当前能确定的内容 | 仍需确认的内容 |
| --- | --- | --- |
| 客户问“周五能不能先看一版” | 客户希望周五看到初稿 | 团队是否接受，初稿包括什么 |
| 小林说“我找销售确认一下价格” | 小林接下了询价工作 | 何时反馈，谁最终确定报价 |
| “等测试数据齐了再演示” | 演示有前置条件 | 谁确认数据齐备，之后怎样约时间 |

整理时保留相关原话和来源位置。能定位到转录段落，就附上段落；原始材料提供时间戳，就保留时间戳。说话人识别不清时，标明待核对，不要根据发言内容猜一个名字。

一条缺少负责人的待办，可以暂时留在待确认区。填满表格里的每个字段，并不意味着交接更完整。

## 负责人要对应实际接下的工作

小林答应询价，因此可以把“向销售确认价格”交给小林。由此推断他负责制定报价、审批折扣或向客户发信，就扩大了原来的承诺。

一个人介绍了问题，不代表他接下了解决问题的任务。职位、发言次数和历史分工可以帮助找到该询问的人，却不宜直接当作本次分配的依据。若团队已有明确的派单规则，助手可以按规则提出分配，并说明依据。

交付物要写到接手的人能判断的程度。“跟进报价”留下了太多解释空间；“向销售确认这两种方案的价格，把结果补到报价草稿里”才说明要做什么。发送给客户是否包含在内，要另行明确。

日期同样如此。客户提出的期望时间、团队接受的截止时间、下一次检查进度的时间，各自有不同含义。会议里只说“尽快”，就保留待定；助手可以建议一个日期供确认，但不应把建议写成会议已经通过的安排。

## 请人确认时，只问尚未决定的部分

把整篇纪要发给负责人，再附一句“请确认”，对方仍然要自己找出所有疑点。更有用的交接会把问题落到具体事项上。

例如，助手可以先准备这样的确认请求。下面的内容仍是虚构示例：

> 客户希望周五收到方案初稿，会议中没有找到团队接受该日期的记录。请项目负责人确认是否答应，以及这一版需要包含哪些内容。
>
> 小林已答应向销售询价，反馈时间未定。请小林补充预计反馈时间。
>
> 演示需等待客户提供测试数据，暂不创建日历邀请。请确认由谁检查数据是否齐备。

三条问题分别交给能回答的人。已经确认的事项不必跟着一起等待；仍缺条件的事项则保留原状。这样，一次回复就能解决一个明确的缺口。

确认只对它当时对应的那版内容有效。负责人同意“周五给初稿”之后，如果交付物随后被扩成“完整方案和报价”，这条回复就不能覆盖新增的范围。要重新确认的是发生变化的部分，其余仍然有效。

## 把任务写进接手的人实际使用的地方

会议文档保存讨论依据，任务系统承载分工，对外邮件说明已经确认的安排。三者互相链接，各自保留需要的那部分信息。

一条适合交接的任务，通常包含交付物、负责人、已确认的期限或前置条件，以及相关会议记录。接手的人应能沿着链接找到约定的来由，不必重读整场会议就能开始。

写入前，先查这件事是否已经有任务。本周会议可能只是给上周的事项补了一个日期；再建一条同名待办，会让进度分散在两个地方。助手应核对已有任务及所属项目，提出更新建议；无法判断是否为同一事项时，把候选记录交给负责人确认。

对外邮件要单独整理。内部正在讨论的折扣、尚未批准的交付日期，不应因为出现在同一份纪要里就进入客户回信。邮件草稿只表达已经允许对外传达的内容，内部待办留在相应的工作区。

任务创建后，可以报告它的位置和分配情况。负责人字段只表示分配，不表示对方已经知道或开始；对方是否接手，以团队约定的确认方式为准。

## 用 OOMOL 连接会议材料与任务系统

这一轮交接里，助手要做两类事：从会议记录和已有任务里读，向任务系统和邮件里写。读的部分决定它能不能分清建议与承诺，写的部分决定误判会不会直接落到别人头上。

OOMOL 的 [Connector SDK](https://oomol.com/zh-cn/docs/connector-client/)提供调用已连接应用账号的路径，先在 [Connections](https://console.oomol.com/connections) 把存放会议记录的应用和团队的任务工具连上。连接前核对每个应用是否提供需要的读取、查询、创建与更新操作。会议转录仍由原有会议工具提供，连接应用不等于 OOMOL 会录制会议或识别发言人。

建议把两侧分开上线：先只接通读取，让助手整理交接草稿；确认它区分的建议与承诺符合预期后，再按[权限控制指南](https://oomol.com/zh-cn/docs/access-control/)开启创建任务、发送消息等写入操作，并确认目标账号、项目、收件人和最终内容。

应用连接提供读写能力，建议与承诺的区分、负责人匹配、确认记录和任务关联仍要由助手指令或业务流程落实，具体规则按团队实际做法配置。

## 从一场会议的交接草稿开始

选一场已经结束、能够核对原始记录的会议，把范围限定在这次讨论及对应项目。让已经接入所需应用的助手处理下面的请求：

> 根据这份会议记录，整理已确认的决定、明确接下的任务和待确认事项。每条任务写清交付物、负责人、期限或前置条件，并附来源；没有依据的字段保持待定。查找指定项目中已有的相关任务，分别提出新增或更新建议。先把交接草稿交给我，不创建任务、不发消息。需要确认的地方，请写出具体问题和适合回答的人。

审阅时，重点检查三处：客户的愿望有没有被写成团队承诺，询问问题的人有没有被分配成负责人，条件尚未满足的事项有没有被提前排期。

确认后，再让助手将对应事项写入目标系统，返回实际任务链接和仍待决定的内容。下一位接手的人打开任务，就能知道自己答应了什么、需要交付什么，以及还有哪些条件没有落实。