每天早上的站會日報，說實話是我最懶得寫的東西。不是因為難，是因為無聊——打開日曆看昨天做了什麼，打開任務清單看今天要幹嘛，然後用條列式整理一遍。這種事不就該自動化嗎？
站會日報的結構
我們公司的站會日報格式很標準：
- 昨天做了什麼
- 遇到什麼問題
- 今天要做什麼
其中「遇到什麼問題」通常是空的（不是沒問題，是寫日報的時候想不起來），真正要花時間的是第一點和第三點。
第一版：太天真了
最初的想法很簡單：讓 AI Agent 去讀 Google Calendar 昨天的事件 + 任務管理系統的完成項目，組裝成「昨天做了什麼」。
結果第一版跑出來的日報有 18 項。
為什麼？因為我把所有資料來源都倒進去了：日曆事件、個人待辦、公司任務清單。很多東西重複了——日曆上寫了「處理客戶 A 需求」，任務清單也有一條「客戶 A 功能開發」，結果日報裡出現兩次。
第二版：砍掉重複來源
教訓很明確：資料來源要正交，不要重疊。
分析一下各個來源的特性：
- Google Calendar：記錄「我在哪裡、跟誰開會」，是時間軸上的事實
- 個人待辦：記錄「我打算做什麼」，是計劃
- 公司任務清單：記錄「公司指派了什麼」，跟個人待辦高度重疊
重疊的部分主要是「公司任務清單」和「個人待辦」。因為我的習慣是把公司任務也拉到個人待辦裡管理（加上自己的排程和優先級），所以兩邊一定有重複。
解法：「昨天做了什麼」只用日曆 + 工作筆記，不查公司任務清單。
日曆提供事件骨架（幾點到幾點做了什麼），工作筆記補充細節（具體做了哪些技術決策、解了什麼問題）。公司任務清單留給「今天要做什麼」用。
砍完後，18 項變成 5 項。清爽多了。
「昨天」不只是昨天
另一個踩到的坑：週一的站會，「昨天」是指上週五。
更精確地說，「昨天做了什麼」應該是「上次寫日報到昨天之間做的事」。如果中間有假日、請假、或者某天忘了寫，範圍要自動拉長。
實作方式是去查日報資料庫裡最近一筆我寫的紀錄，用那個日期作為起點。這樣不管跨幾天，都能正確涵蓋。
「今天要做什麼」的資料來源
這部分相對單純：
- 今天的日曆事件：已經排好的會議和行程
- 個人待辦中到期的項目：預計今天做的 + 今天截止的
排序邏輯是行程在前（有明確時間的）、待辦在後（彈性安排的）。
有一個小細節：有些待辦既沒有排程日期也沒有截止日期，這種就不放進日報。沒有時間壓力的事情不該出現在「今天要做什麼」裡，否則日報又會膨脹。
過濾非工作事項
日曆上不全是工作。早餐約會、讀書會、公司尾牙——這些出現在站會日報裡就很奇怪。
做法是維護一個排除清單，遇到這些關鍵字就跳過。不需要做得很精密，幾個常見的非工作事項過濾掉就好。偶爾有漏網之魚，AI Agent 通常也能從語意上判斷要不要放進去。
最終架構
整理一下最終的資料流：
「昨天做了什麼」
- 來源 1：Google Calendar 事件（上次日報日 ~ 昨天）
- 來源 2：每日工作筆記中的專案相關紀錄
- 過濾：排除非工作事項
- 排序：按時間順序
「今天要做什麼」
- 來源 1：Google Calendar 今天的事件
- 來源 2：個人待辦（排程日 ≤ 今天 或 截止日 ≤ 今天，且未完成）
- 排序：行程在前、待辦在後
不使用的來源
- ❌ 公司任務清單（跟個人待辦重複）
- ❌ 工作筆記用於「今天要做什麼」（那是記錄不是計劃）
每天凌晨五點自動跑
整個流程設成排程任務，每個工作日凌晨五點自動執行。Agent 起來後：
- 算出「上次日報日」
- 抓日曆事件和工作筆記
- 組裝成站會格式
- 寫入日報資料庫
早上開站會的時候，日報已經在那裡了。有時候會微調幾個字，但 90% 的情況下直接用。
省下的不只是時間
老實說，寫站會日報本身花不了多少時間，大概五到十分鐘。但它有一個隱性成本：每天早上要切換到「回想模式」。
昨天做了什麼？嗯⋯⋯先打開日曆⋯⋯再看看 commit log⋯⋯好像還處理了一個客戶問題⋯⋯。這個回想過程打斷了早上的心流。
自動化之後，早上打開電腦直接進入工作狀態，站會的時候掃一眼日報確認沒遺漏就好。
反思
這個專案讓我學到的最重要的事，不是技術上的，而是：資料來源的選擇比演算法重要。
第一版什麼都丟進去，結果是垃圾。不是 AI 不夠聰明，是我餵了重複的資料。砍掉重疊的來源之後，幾乎不需要什麼複雜的邏輯，日報品質就到位了。
這跟很多 AI 應用的經驗一致——與其調 prompt、換模型、加後處理，不如先把輸入端整理乾淨。Garbage in, garbage out 永遠是真理。
如果你也在做類似的自動化，建議先畫一張資料來源的 Venn 圖，看看哪些重疊了。砍掉重疊的部分，比寫去重邏輯省事多了。