--- author: OOMOL author_url: https://oomol.com/zh-tw/about/ datePublished: 2026-10-15 title: 讓 AI 持續跟進專案，怎樣少發重複提醒，又不漏掉變化？ description: 持續跟進的難點，是相對上次確認的狀態說清發生了什麼。以專案交付為例，說明助手要保留哪些狀態、怎樣區分新訊息與真實變化，以及沒有變化、檢查失敗和到期時該分別報告什麼。 lang: zh-TW canonical_url: https://oomol.com/zh-tw/blog/ai-follow-up-changes/ markdown_url: https://oomol.com/zh-tw/blog/ai-follow-up-changes.md --- ![行事曆保留已確認的週五交付，改到週一的請求仍待決定](/blog/ai-follow-up-changes/zh-tw-cover.webp) *AI 生成的概念插圖，內容為假設範例。* 假設你讓 AI 幫忙盯著一個週五交付的專案。週一，它提醒客戶還沒確認材料；週二，它又送來幾乎相同的摘要。到了週三，客戶已經在郵件裡提出延期，專案看板卻仍然寫著週五交付。助手把兩個日期都放進了報告，最後建議你「持續關注」。 你還是得打開郵件，查看看板，再問一次負責人。 持續跟進需要保留上一次的判斷，並說明這一次有什麼變化。如果每次執行都重新概括全部材料，助手很容易把舊訊息寫成新進展，也可能把尚未確定的提議當作已經生效的安排。 ## 一次摘要之後，還需要留下什麼 跨應用整理資訊的嘗試已經不少。Composio 的[家庭日報案例](https://composio.dev/blog/building-a-daily-family-newspaper)把行事曆、天氣和趣味內容組成一份當天的小報；Lindy 的 [AI teammate 介紹](https://www.lindy.ai/blog/ai-teammate)討論了持續上下文與主動跟進。這些內容說明當天的資訊可以整理成什麼，但沒有回答一個更具體的問題：連續兩次檢查之間，應該保留哪些已經確認的判斷。 一份當天摘要幫助你了解眼前的安排；一項持續跟進的任務，還需要解釋事情相對上一次發生了什麼。 以專案交付為例，第一次整理完材料後，值得留下的內容很少：目前確認的交付日期、仍在等待的材料、負責跟進的人，以及支持這些判斷的來源。還要記下這次檢查涵蓋到什麼時間，哪些來源沒有讀到。 這份記錄就是下一次檢查的起點。它可以保存在應用資料庫、任務記錄或一份受控文件中，具體形式由助手系統決定。重要的是後續執行確實能讀到它，並且知道其中哪些內容已經確認，哪些只是推測。 如果上一次只有一句「專案進展正常」，下一次就很難解釋到底哪裡變了。 ## 新訊息不一定意味著事情有了進展 同一份材料被轉發到群組裡，信箱裡多了一封「收到，謝謝」，看板上有人修改了任務描述。這些都是新記錄，但對交付的影響不同。 可以圍繞任務關心的事實做比較。對於這個專案，你真正需要知道的是：材料是否齊備，交付日期是否改變，誰接下了待辦，以及是否出現新的阻塞。 下面是一組假設情況： | 本次讀到的內容 | 應怎樣理解 | 適合怎樣提醒 | | --- | --- | --- | | 同事轉發了週一的材料請求 | 同一事項，尚無新的交付資訊 | 不重複推送同一條提醒，到期仍提醒 | | 客戶送來了此前缺少的附件 | 材料已收到，是否滿足要求仍需檢查 | 說明收到什麼、還缺什麼 | | 客戶詢問能否改到下週一 | 出現了改期請求 | 標為待決定，保留目前確認日期 | | 負責人明確同意改期 | 出現新的確認記錄 | 說明原日期、新日期和確認來源 | 識別同一條記錄，可以使用來源系統提供的識別碼；判斷不同記錄是否描述同一件事，還需要結合專案、參與人和內容。僅憑標題相同，無法可靠地把兩封郵件合併。僅憑文字不同，也不應認為專案又向前推進了一步。 已經明確的欄位適合直接比較，需要理解語意的地方再交給模型。比如先找出日期欄位發生變化的任務，再讓 AI 閱讀相關討論，解釋這次變化是否已經得到確認。 ## 郵件和看板不一致時，把分歧留下來 週三的郵件提出下週一交付，看板仍然寫著週五。哪一個才算數？ 「更新得更晚」只能說明記錄時間，不能說明發言人有權改變安排。郵件可能是一項請求，看板可能尚未更新，也可能只是引用了另一項任務的日期。 團隊可以提前約定依據。例如，交付日期以指定負責人的確認為準，看板用於記錄確認後的安排。這樣，助手看到改期郵件時，就能把它歸入待確認事項；看到負責人同意後，再指出看板還需要同步。 沒有約定時，助手應當把兩條記錄放在一起，說明分歧，交給負責人決定。下面是一個虛構的提醒範例： > 客戶在今天的郵件中請求將交付改到下週一；專案看板仍為本週五。目前可讀取的記錄中，尚未找到負責人的改期確認。請確認是否接受請求。 引用來源時，應當給出真實、可打開的連結；只寫「客戶郵件」或「看板」，負責人仍然無法核對。 這裡需要人做決定，而且要求很明確。相比「請持續關注專案風險」，負責人知道自己該回答什麼，也能直接打開依據。 ## 沒有變化、檢查失敗和到期，要分開處理 持續執行的助手需要允許安靜的結果。如果指定來源檢查正常，事情也沒有變化，就可以記錄檢查結果，按約定不再推送一份重複摘要。 但信箱讀取失敗時，不能得出相同結論。助手只知道自己沒能完成檢查，應該保留最近一次成功讀取的位置，並說明本次遺漏的來源。恢復存取後，需要補查遺漏期間的記錄；如果介面提供增量游標，可以按其約定續讀，否則應設計涵蓋遺漏時間的查詢。不能只查恢復當天，就假定中間沒有變化。 Viktor 的[自動化悄然失效](https://viktor.com/blog/why-automations-die-quietly)描述了長期執行的任務失效後很難被察覺。跟進任務也是一樣：沒有送來提醒時，你應該能查到它上次是否執行過、檢查了哪些來源。 還有一種情況，即使沒有新訊息也需要提醒：約定的期限到了。客戶一直沒有回覆，到了雙方約定的跟進時間，這件事就值得再次出現。 因此，提醒可以來自實際變化，也可以來自事先約定的時間條件。任務結束、取消或被負責人接管後，還需要停止相應提醒。否則，一項已經完成的工作仍會每天要求你關注。 ## OOMOL 為跟進任務提供應用連接 要比較兩次檢查之間的變化，助手需要讀取真實系統裡的記錄。在 OOMOL 中，[Connector SDK](https://oomol.com/zh-tw/docs/connector-sdk/) 說明了如何選擇已授權的連接帳號、呼叫相應的應用操作；閘道負責持有憑證並發起實際請求。 例如，為專案跟進連接工作信箱和專案管理工具，再核對它們是否提供所需的搜尋、詳情讀取和更新時間欄位。不同服務的查詢範圍、歷史記錄和增量能力各不相同，需要按具體介面確認。 上一次確認的狀態、不同來源之間的關聯、提醒條件和停止條件，則由助手或業務流程保存和執行。連接成功之後，這些任務規則仍然需要落實。 第一版可以只開放必要的讀取操作，把變化報告交給負責人。需要同步看板或回覆客戶時，再按[權限控制指南](https://oomol.com/zh-tw/docs/access-control/)配置相應操作，並明確執行目標與確認方式。 團隊如果需要自己管理連接服務，可以使用 OOMOL 的開源專案 [OpenConnector](https://openconnector.io/)，按[自部署指南](https://oomol.com/zh-tw/docs/openconnector-self-hosting/)管理憑證、操作策略和執行記錄。 ## 用同一個專案，連續檢查兩次 可以從 [OOMOL Connections](https://console.oomol.com/connections) 連接任務所需的應用，讓支援呼叫連接能力、能夠保存任務狀態的助手處理一個範圍明確的請求： > 幫我跟進這個專案的交付日期和待交材料。先讀取指定郵件會話與專案任務，整理目前已確認狀態、待確認事項和來源，保存為後續比較的依據。本次只把結果交給我，不修改來源系統。下次檢查時，說明相對這次發生了什麼變化；沒有變化時不重複摘要，讀取失敗時說明缺失。提醒時間與停止條件由我確認後再設定。 第一次檢查，核對它是否選對了專案、郵件和負責人。第二次可以用測試材料加入一條重複轉發、一項改期請求和一條正式確認，觀察助手能否區分三者。再讓一個來源暫時無法使用，檢查它會不會把讀取失敗說成「沒有進展」。 等這些判斷符合預期，再安排定時執行。你收到的下一次提醒，就應該能回答一個具體問題：相對上次確認的狀態，現在有什麼需要你處理？