---
author: OOMOL
author_url: https://oomol.com/zh-tw/about/
datePublished: 2026-10-15
title: 會議紀要寫完了，下一步該交給誰？
description: 讓助手整理會後任務時，保留建議、決定與承諾的區別，明確交付物、負責人和期限，再把確認過的事項交到團隊實際使用的系統裡。
lang: zh-TW
canonical_url: https://oomol.com/zh-tw/blog/ai-meeting-handoff/
markdown_url: https://oomol.com/zh-tw/blog/ai-meeting-handoff.md
---

![會議筆記中的週五初稿請求，旁邊任務單的負責人和期限仍待確認](/blog/ai-meeting-handoff/zh-tw-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-tw/docs/connector-client/)提供呼叫已連接應用帳號的路徑，先在 [Connections](https://console.oomol.com/connections) 把存放會議記錄的應用和團隊的任務工具連上。連接前核對每個應用是否提供需要的讀取、查詢、建立與更新操作。會議轉錄仍由原有會議工具提供，連接應用不等於 OOMOL 會錄製會議或識別發言人。

建議把兩側分開上線：先只接通讀取，讓助手整理交接草稿；確認它區分的建議與承諾符合預期後，再按[權限控制指南](https://oomol.com/zh-tw/docs/access-control/)開啟建立任務、發送訊息等寫入操作，並確認目標帳號、專案、收件人和最終內容。

應用連接提供讀寫能力，建議與承諾的區分、負責人匹配、確認記錄和任務關聯仍要由助手指令或業務流程落實，具體規則按團隊實際做法配置。

## 從一場會議的交接草稿開始

選一場已經結束、能夠核對原始記錄的會議，把範圍限定在這次討論及對應專案。讓已經接入所需應用的助手處理下面的請求：

> 根據這份會議記錄，整理已確認的決定、明確接下的任務和待確認事項。每條任務寫清交付物、負責人、期限或前置條件，並附來源；沒有依據的欄位保持待定。查找指定專案中已有的相關任務，分別提出新增或更新建議。先把交接草稿交給我，不建立任務、不發訊息。需要確認的地方，請寫出具體問題和適合回答的人。

審閱時，重點檢查三處：客戶的願望有沒有被寫成團隊承諾，詢問問題的人有沒有被分配成負責人，條件尚未滿足的事項有沒有被提前排期。

確認後，再讓助手將對應事項寫入目標系統，返回實際任務連結和仍待決定的內容。下一位接手的人打開任務，就能知道自己答應了什麼、需要交付什麼，以及還有哪些條件沒有落實。