每天請 Bot 把信件、行程與待辦整理成日報，已經能省下不少翻找資訊的時間。不過，看完日報之後，事情還沒有結束：有些待辦已經完成，有些安排臨時改了，也有一些項目想再請 Bot 幫忙。如果這些進度都得回到聊天裡重新交代，閱讀日報之後，往往還有一輪整理回覆的工作。

Daily Brief Service 是一個讓你閱讀 Bot 日報、直接針對事項留下回饋的工作台。Bot 負責整理資訊，你在網頁上註解、補充或標記完成，讓它下一次製作日報時，有清楚的上下文可以接續。

聊完一件事，不必再往上翻找下一件

假設早上的日報列出「週五前確認報價」。當你處理完，回到 Bot 對話說「報價已經回覆了」，常常還得補上一句，說明指的是哪份日報、哪個客戶或哪個事項。接著討論了幾輪，日報已被推到上面；要處理下一項，又得捲回去找。

Daily Brief 把報告和回覆的位置留在一起。待辦完成時，可以直接勾選；有新的進度，就在該項旁留下註解。處理完這件事，繼續往下看下一項，不必在整份日報和不斷延伸的聊天之間反覆找位置。

這也讓閱讀時的回饋更容易留下來。你不需要先組織一段完整的聊天訊息，只要在對應位置寫下「已回覆，接下來等對方提供合約」，Bot 就有辦法把這段補充和原本的報價事項一起理解。

flowchart LR
    accTitle: 使用 Daily Brief 前後的回覆流程
    accDescr: 原本要回到聊天交代進度，再往上翻找日報；使用 Daily Brief 後，在事項旁回覆即可繼續下一項。
    subgraph Before["原本：回聊天重新交代"]
        direction TB
        B1["收到 Bot 日報"] --> B2["指出正在討論哪件事"]
        B2 --> B3["聊天補充進度與後續"]
        B3 --> B4["捲回上方找日報，再找下一項"]
    end
    subgraph After["使用 Daily Brief：留在日報處理"]
        direction TB
        A1["在網頁閱讀同一份日報"] --> A2["在事項旁勾選完成、留下註解"]
        A2 --> A3["回饋保留在對應的事項旁"]
        A3 --> A4["繼續看下一項，不必重找位置"]
    end
    Before ~~~ After

圖一：差別不只是少打一段文字，也少了每討論完一件事，就得捲回日報重新找位置的來回。

今天的回覆，成為明天日報的起點

沿用同一個例子：今天的日報提醒你確認報價，你勾選完成並留下等待合約的註解。隔天製作日報前，Daily Brief 提供給 Bot 的操作指示會要求它重新讀取昨日報告的註解、完成狀態與補充，再依最新進度整理內容。原本的「確認報價」，就能接著變成「等待對方提供合約」，而不是重複提醒已經處理過的事。

這裡的重點是重新讀取，而不是期待 Bot 記得前一天聊過的所有內容。報告中的完成狀態和註解有明確的對應位置；如果你後來取消勾選，或清空了留言，下一次讀取時也應以目前狀態為準。

上面的報價與合約是示意情境。實際日報如何調整，仍由 Bot 依來源、回饋與你的要求判斷；勾選完成也不代表服務已代你寄出信件或完成外部工作。

flowchart TB
    accTitle: 今天的回饋如何帶進明天的日報
    accDescr: Bot 發布確認報價的日報，使用者標記完成並註解等待合約；隔天 Bot 先讀昨日最新回饋，再整理新日報。
    S["你已授權 Bot 讀取的信件、行程與待辦"] --> T["今天的日報：週五前確認報價"]
    T --> F["你勾選完成，並註解：已回覆，等待合約"]
    F --> R["Daily Brief 保存對應事項的最新回饋"]
    R --> Q["隔天 Bot 製作日報前，先讀昨日回饋"]
    Q --> N["接續整理：等待對方提供合約"]
    N --> C["你閱讀新日報，繼續留下進度"]

圖二：以「確認報價」到「等待合約」為例，回饋不只留在今天的畫面上，也能成為下一次整理的依據。這是示意流程，實際內容由 Bot 判斷。

原本就有的日報，也可以接上來

Daily Brief 不要求你重新設計一套報告。如果你已經讓 Grok Bot 每天整理信件、行程或待辦，可以沿用原本的內容與時間安排，再指定其中一份日報發布到 Daily Brief。

完成 Skill 與連線設定後，可以這樣告訴 Bot。把報告名稱換成你實際使用的名稱即可：

請把你每天早上幫我整理的「信件與今日待辦日報」發布到 Daily Brief，之後這份例行日報也都照這樣做。每次製作新日報前，先重新讀取昨日報告的註解與完成狀態，再接續更新內容。

如果只想先體驗一次，也可以直接說：

請把今天這份日報發布到 Daily Brief，先不要更動之後的例行安排。

要交代的是「哪份報告」與「發布範圍」，不是把所有 Bot 輸出都搬進來。安裝 Skill 或建立連線，只是讓 Bot 能使用這個服務，不會自動授權它發布所有報告。

想讓 Bot 現在就知道，也能開啟即時通知

有些回饋等到明天再整理就夠了，也有些變動希望 Bot 早一點看到。Daily Brief 提供選用的 Bot 通知設定：啟用後，你在日報上儲存的註解或完成狀態變更，會觸發服務向 Grok Routine 發送通知，讓 Bot 讀取最新回饋並在原本的對話中回應。

不必自己研究 Webhook 格式才能開始。登入後按「怎麼通知 Bot？」，再按「怎麼告訴你的 Grok Bot 設立 Routine」，就能取得附有複製按鈕的指示。把它貼進 Grok Bot 對話，請 Bot 建立 Routine；接著按照 Bot 的說明打開 Routine，取得 Endpoint 與 API Key，再回到 Daily Brief 填入。金鑰直接填在設定欄位，不要貼到聊天中。

儲存設定不會自動發送測試；只有按下「發送測試通知」才會實際呼叫已儲存的端點。正常使用時，短時間內的改動可能合併成一次通知，Routine 指示也會要求 Bot 稍等後再讀最新狀態。因此，這裡的「即時」是不用等到隔天才通知，不是保證 Bot 在你點下按鈕的同一刻就完成處理。你也可以參考 Grok Bot 的 Routine 官方說明。

這項功能不是使用 Daily Brief 的必要條件。沒有設定即時通知，也能閱讀、註解和標記完成，並讓 Bot 在下一次製作日報前讀取回饋。

sequenceDiagram
    accTitle: 選用即時通知的運作方式
    accDescr: 回饋先儲存，啟用通知後再透過 Webhook 觸發 Grok Routine；Bot 等至少五秒再經 MCP 讀最新狀態並回應。
    actor U as 你
    participant D as Daily Brief
    participant B as Grok Bot 與 Routine
    U->>D: 儲存註解或變更完成狀態
    D->>D: 保存最新回饋
    opt 已啟用 Bot 通知
        D->>B: 嘗試發送 Webhook 通知
        Note over D,B: 三秒內的變更可能合併；接受通知不等於已讀取
    end
    D-->>U: 回饋已儲存，並顯示通知結果
    opt Webhook 已觸發 Routine
        Note over B: Routine 指示：至少等五秒再讀取
        B->>D: 經 MCP 讀取最新回饋與原報告
        D-->>B: 回傳目前狀態與對應內容
        B-->>U: 在原本的 Bot 對話中回應
    end

圖三：通知讓 Bot 不必等到隔天才知道有改動，但不是把註解直接當成外部操作授權。圖中是投遞與 Routine 正常執行時的流程；實際回應仍取決於 Bot 的執行結果。

Bot 整理資訊，Daily Brief 承接閱讀與回饋

Daily Brief 不會另外要求你把信箱、行事曆或其他來源全部交給它。資訊從哪裡來、Bot 能讀取什麼、什麼時候製作日報，仍由 Bot 原本的能力與你的授權決定。這個服務負責保存報告與對應的回饋，提供一個更適合閱讀和逐項回覆的介面。

Web 與 Bot 之間透過 MCP 連線。MCP 是讓 AI client 使用外部工具與資料的通訊協定；在這裡，它讓 Bot 發布報告，也讓 Bot 讀回你留下的註解與完成狀態。一般使用者不需要手寫資料格式，依網頁提供的設定說明完成連線，再說清楚要使用哪份日報即可。

Grok 網站的 Connector 與 Grok Bot 自己的 Plugins／MCP 設定是不同入口，請在你實際使用的 client 完成授權，並使用與 Daily Brief 網頁相同的帳號。若之後想重新查看設定方式，登入後也能透過「使用說明」打開完整介紹，再回到原本的日報繼續處理。

從下一份日報開始

如果你已經習慣讓 Bot 整理每日資訊，Daily Brief 不需要取代原本的工作方式。先挑一份固定會看的日報，把它接到網頁上，試著在一個項目旁留下進度，再看 Bot 如何在下一次整理中接續。想縮短回饋等待的時間，再加上即時通知就好。

前往 Daily Brief Service 查看介紹與開始使用。想了解實作或部署方式，也可以到 GitHub repository 查看程式碼與文件。