將會議筆記轉成待辦行動，不編造承諾

用 AI 整理會議上真正決定的事，而不是編出一份看起來完整的計畫。每個行動都應能追溯到筆記。沒有負責人的事項、不確定的日期和建議，在有人確認之前都要清楚地保留下來。

這個方法只使用你貼到 Reunified 的 Mono 對話中的文字，不涉及錄音、逐字稿、行事曆活動或與任務 App 同步。Mono 還沒有正式推出，你可以先加入候補名單，同時用任何文字助手試用這套方法。

1. 準備簡短且日期明確的原始資料

刪掉個人資料和後續追蹤用不到的內容。保留會議日期、專案名稱，以及看懂誰答應了什麼所需的人名。如果筆記裡混著好幾次會議，先分開再請助手提取行動。

用下面這份虛構的筆記當例子：

專案：更新說明頁面。會議日期：2026 年 10 月 9 日。
[1] Lina 會在 10 月 12 日前（含當天）寄出草稿。
[2] Omar 會在 Lina 寄出後審閱。
[3] 週五發布？與團隊確認。
[4] 也許委託製作新螢幕截圖；未約定負責人。

行號是你自己加的標記。有了它們，不用在改寫過的摘要裡翻找也能核對結果。保留問號以及「也許」「之後」這類字詞，不要把筆記「整理」成更確定的承諾。

2. 先要求提取，再考慮規劃

把筆記和一條清楚、有範圍的指令一起貼上：

只提取這份筆記裡明確約定的行動。
每項列出行動、負責人、期限或相依條件，以及來源行號。
缺少資訊請寫「未說明」。
將待確認問題、建議與已約定行動分開。
不要指派人員、編造日期、建立任務或傳送訊息。

最後一行告訴助手你想要什麼，但它不能代替檢查工具權限。如果助手提議在其他服務中執行操作，要另外審查。第一個有用的結果，是一張可以和筆記對照的草稿表。

在核對提取結果之前，不要叫它「把每一項都變成可執行的任務」。這種說法可能讓它猜出負責人或期限，看起來比筆記裡的更確定。

3. 將結果與原始筆記逐項核對

這個例子對應的正確表格如下：

發布日期屬於待確認問題。新截圖屬於建議，沒有負責人。兩者都不應悄悄變成筆記中名字離得最近的那個人的任務。

檢查表格每一列是否都有筆記中的某一行作為依據。再反過來查：有沒有明確的承諾被漏掉？動詞要保持準確。「審閱」「核准」和「發布」是不同的責任，即使摘要把它們混在一起。

4. 補齊資訊，但不要改寫歷史

準備具體的追蹤問題：「發布指的是哪一個週五？」以及「要不要委託製作截圖？如果要，由誰負責？」這些問題要由人來回答，而不是讓模型去填空。

「草稿到了之後」是相依條件，不是日期。在負責人給出時間之前，就維持這樣寫。如果年份是根據會議日期推斷的，要註明；如果筆記跨了年，要再確認。

把原始筆記和每一項已確認的修改放在一起保存。會後做出的決定，要標明是會後決定，並寫上日期。否則，更新後的清單可能會讓人以為會議決定了其實沒決定的事。

5. 準備他人能接手的紀錄

核對完後，整理一份簡短的紀錄：

專案與會議日期：
已確認行動：行動 / 負責人 / 時間 / 來源
待確認問題：問題 / 誰能確認
等待決定的建議：
會後確認的變更：日期 / 決定
下次審查：

使用讀者認得的人名和日期。分享前刪掉對方不需要的細節。如果透過其他服務傳送，要確認送往哪裡、誰會收到；寫好紀錄並不等於已經送出。

你可以把它存成 Markdown 筆記，或用 Markdown 匯出保存整段對話。儲存筆記不會在任何已連線的服務中新增活動或任務。

6. 重複使用前先測試流程

試三種情況：沒有負責人的筆記、後來被否決的提議，以及沒有會議日期的相對期限，例如「下週五」。好的回答會保留不確定或否決，而不是用猜測填滿每一格。

如果回答混淆了會議、編造了承諾或漏掉了相依條件，就少給它一些文字，再核對一次。事實查核指南介紹了證據表的方法。只有當核對後的結果一直有用時，才值得把它做成儲存的提示詞或你向 Mono 描述的任務。自動化能省時間，但每個人仍要自己確認自己的承諾。