讓 AI 持續跟進專案，怎樣少發重複提醒，又不漏掉變化？

AI 生成的概念插圖，內容為假設範例。

假設你讓 AI 幫忙盯著一個週五交付的專案。週一，它提醒客戶還沒確認材料；週二，它又送來幾乎相同的摘要。到了週三，客戶已經在郵件裡提出延期，專案看板卻仍然寫著週五交付。助手把兩個日期都放進了報告，最後建議你「持續關注」。

你還是得打開郵件，查看看板，再問一次負責人。

持續跟進需要保留上一次的判斷，並說明這一次有什麼變化。如果每次執行都重新概括全部材料，助手很容易把舊訊息寫成新進展，也可能把尚未確定的提議當作已經生效的安排。

一次摘要之後，還需要留下什麼

跨應用整理資訊的嘗試已經不少。Composio 的家庭日報案例把行事曆、天氣和趣味內容組成一份當天的小報；Lindy 的 AI teammate 介紹討論了持續上下文與主動跟進。這些內容說明當天的資訊可以整理成什麼，但沒有回答一個更具體的問題：連續兩次檢查之間，應該保留哪些已經確認的判斷。

一份當天摘要幫助你了解眼前的安排；一項持續跟進的任務，還需要解釋事情相對上一次發生了什麼。

以專案交付為例，第一次整理完材料後，值得留下的內容很少：目前確認的交付日期、仍在等待的材料、負責跟進的人，以及支持這些判斷的來源。還要記下這次檢查涵蓋到什麼時間，哪些來源沒有讀到。

這份記錄就是下一次檢查的起點。它可以保存在應用資料庫、任務記錄或一份受控文件中，具體形式由助手系統決定。重要的是後續執行確實能讀到它，並且知道其中哪些內容已經確認，哪些只是推測。

如果上一次只有一句「專案進展正常」，下一次就很難解釋到底哪裡變了。

新訊息不一定意味著事情有了進展

同一份材料被轉發到群組裡，信箱裡多了一封「收到，謝謝」，看板上有人修改了任務描述。這些都是新記錄，但對交付的影響不同。

可以圍繞任務關心的事實做比較。對於這個專案，你真正需要知道的是：材料是否齊備，交付日期是否改變，誰接下了待辦，以及是否出現新的阻塞。

下面是一組假設情況：

本次讀到的內容	應怎樣理解	適合怎樣提醒
同事轉發了週一的材料請求	同一事項，尚無新的交付資訊	不重複推送同一條提醒，到期仍提醒
客戶送來了此前缺少的附件	材料已收到，是否滿足要求仍需檢查	說明收到什麼、還缺什麼
客戶詢問能否改到下週一	出現了改期請求	標為待決定，保留目前確認日期
負責人明確同意改期	出現新的確認記錄	說明原日期、新日期和確認來源

識別同一條記錄，可以使用來源系統提供的識別碼；判斷不同記錄是否描述同一件事，還需要結合專案、參與人和內容。僅憑標題相同，無法可靠地把兩封郵件合併。僅憑文字不同，也不應認為專案又向前推進了一步。

已經明確的欄位適合直接比較，需要理解語意的地方再交給模型。比如先找出日期欄位發生變化的任務，再讓 AI 閱讀相關討論，解釋這次變化是否已經得到確認。

郵件和看板不一致時，把分歧留下來

週三的郵件提出下週一交付，看板仍然寫著週五。哪一個才算數？

「更新得更晚」只能說明記錄時間，不能說明發言人有權改變安排。郵件可能是一項請求，看板可能尚未更新，也可能只是引用了另一項任務的日期。

團隊可以提前約定依據。例如，交付日期以指定負責人的確認為準，看板用於記錄確認後的安排。這樣，助手看到改期郵件時，就能把它歸入待確認事項；看到負責人同意後，再指出看板還需要同步。

沒有約定時，助手應當把兩條記錄放在一起，說明分歧，交給負責人決定。下面是一個虛構的提醒範例：

客戶在今天的郵件中請求將交付改到下週一；專案看板仍為本週五。目前可讀取的記錄中，尚未找到負責人的改期確認。請確認是否接受請求。

引用來源時，應當給出真實、可打開的連結；只寫「客戶郵件」或「看板」，負責人仍然無法核對。

這裡需要人做決定，而且要求很明確。相比「請持續關注專案風險」，負責人知道自己該回答什麼，也能直接打開依據。

沒有變化、檢查失敗和到期，要分開處理

持續執行的助手需要允許安靜的結果。如果指定來源檢查正常，事情也沒有變化，就可以記錄檢查結果，按約定不再推送一份重複摘要。

但信箱讀取失敗時，不能得出相同結論。助手只知道自己沒能完成檢查，應該保留最近一次成功讀取的位置，並說明本次遺漏的來源。恢復存取後，需要補查遺漏期間的記錄；如果介面提供增量游標，可以按其約定續讀，否則應設計涵蓋遺漏時間的查詢。不能只查恢復當天，就假定中間沒有變化。

Viktor 的自動化悄然失效描述了長期執行的任務失效後很難被察覺。跟進任務也是一樣：沒有送來提醒時，你應該能查到它上次是否執行過、檢查了哪些來源。

還有一種情況，即使沒有新訊息也需要提醒：約定的期限到了。客戶一直沒有回覆，到了雙方約定的跟進時間，這件事就值得再次出現。

因此，提醒可以來自實際變化，也可以來自事先約定的時間條件。任務結束、取消或被負責人接管後，還需要停止相應提醒。否則，一項已經完成的工作仍會每天要求你關注。

OOMOL 為跟進任務提供應用連接

要比較兩次檢查之間的變化，助手需要讀取真實系統裡的記錄。在 OOMOL 中，Connector SDK 說明了如何選擇已授權的連接帳號、呼叫相應的應用操作；閘道負責持有憑證並發起實際請求。

例如，為專案跟進連接工作信箱和專案管理工具，再核對它們是否提供所需的搜尋、詳情讀取和更新時間欄位。不同服務的查詢範圍、歷史記錄和增量能力各不相同，需要按具體介面確認。

上一次確認的狀態、不同來源之間的關聯、提醒條件和停止條件，則由助手或業務流程保存和執行。連接成功之後，這些任務規則仍然需要落實。

第一版可以只開放必要的讀取操作，把變化報告交給負責人。需要同步看板或回覆客戶時，再按權限控制指南配置相應操作，並明確執行目標與確認方式。

團隊如果需要自己管理連接服務，可以使用 OOMOL 的開源專案 OpenConnector，按自部署指南管理憑證、操作策略和執行記錄。

用同一個專案，連續檢查兩次

可以從 OOMOL Connections 連接任務所需的應用，讓支援呼叫連接能力、能夠保存任務狀態的助手處理一個範圍明確的請求：

幫我跟進這個專案的交付日期和待交材料。先讀取指定郵件會話與專案任務，整理目前已確認狀態、待確認事項和來源，保存為後續比較的依據。本次只把結果交給我，不修改來源系統。下次檢查時，說明相對這次發生了什麼變化；沒有變化時不重複摘要，讀取失敗時說明缺失。提醒時間與停止條件由我確認後再設定。

第一次檢查，核對它是否選對了專案、郵件和負責人。第二次可以用測試材料加入一條重複轉發、一項改期請求和一條正式確認，觀察助手能否區分三者。再讓一個來源暫時無法使用，檢查它會不會把讀取失敗說成「沒有進展」。

等這些判斷符合預期，再安排定時執行。你收到的下一次提醒，就應該能回答一個具體問題：相對上次確認的狀態，現在有什麼需要你處理？