如果你是工程師或技術主管，每天早上站會前最痛苦的事情大概就是：想不起來昨天到底做了什麼。明明忙了一整天，但要在站會上講出來的時候，腦袋就是一片空白。更慘的是，資料散落在行事曆、任務管理系統、個人待辦清單等各種地方，要手動彙整簡直是一種折磨。
所以我做了一件事：讓 AI 幫我自動產生每日站會報告。
為什麼需要自動化？
其實站會日報的格式非常固定：「昨天做了什麼 / 遇到什麼問題 / 今天要做什麼」。內容也都有跡可循——你的行事曆記錄了參加了哪些會議，任務管理系統記錄了完成了哪些工作，而今天的行事曆和待辦事項就是今天要做的事。
問題不是資訊不存在，而是資訊太分散。每天早上花 15 分鐘去各個系統裡翻資料再手動整理，累積起來的時間成本和心理負擔其實很可觀。而且人的記憶不可靠，常常會漏掉一些瑣碎但重要的事項。
這不就是 AI 最擅長的事嗎？從多個來源抓取結構化 / 半結構化的資料，彙整成人類可讀的報告。
架構設計
整個系統的架構其實不複雜：
資料來源
- 行事曆 API：抓取昨天的會議和事件。會議本身就是工作內容的一部分，而且往往佔了不少時間。
- 任務管理系統 API：這是主要的資料來源。抓取昨天狀態有變化的任務（新建、進行中、完成），以及每個任務的工時記錄。
- 補充性任務清單：有些日常的小任務不一定會登錄到正式的任務管理系統裡，但會記在個人待辦清單上。這個資料來源作為補充。
LLM 彙整
把上面三個來源的資料全部丟給 LLM，讓它：
- 去除冗餘和格式差異
- 分類成「昨天完成」、「昨天進行中」、「遇到的問題」、「今天計畫」
- 產生自然語言的日報，不是乾巴巴的清單，而是有上下文的摘要
最後自動寫入工作日報系統，或者推送到指定的溝通頻道。
實作中踩過的坑
概念很美好，但實作起來有不少魔鬼藏在細節裡：
「一天」到底是什麼時候開始？
這是我遇到的第一個也是最有趣的問題。
一般人直覺會用午夜 00:00 作為日期分界。但工程師的作息……你懂的。加班到凌晨一兩點是家常便飯，如果用午夜切分，那凌晨 00:30 完成的任務到底算昨天還是今天？
我的做法是：把凌晨 4:00 作為日期分界。理由很簡單——正常人（即使是最夜貓子的工程師）通常不會在凌晨 4 點到早上之間工作。所以「昨天」的定義是「前天凌晨 4 點到昨天凌晨 4 點」，這樣不管你加班到多晚，工作內容都會被正確歸類到當天。
這個看似很小的設計決策，實際上影響了整個系統的資料查詢邏輯。API 的查詢時間區間、任務的完成時間判斷，全部都要以凌晨 4 點為基準去計算。
工時自動估算
任務管理系統裡的工時記錄，理想狀態下每個任務都應該填寫。但現實是，很多人（包括我自己）經常忘記填工時。
我的處理方式是設計一個估算邏輯：如果任務有登錄工時，直接使用；如果沒有，就用任務的點數來估算（例如 1 點 ≈ 0.5 小時），再搭配任務的時間區段來推算。這不是什麼精密的演算法，但對日報來說已經夠用了。重點是讓報告裡的工時分配看起來合理，而不是一堆「未填寫」。
非工作事項的過濾
行事曆裡不全是工作事件。讀書會、午餐聚會、私人約會、看牙醫……這些東西如果跑進站會日報裡就尷尬了。
所以需要設定一個排除清單。我的做法是用關鍵字過濾 + 行事曆分類。把非工作的行事曆事件放在不同的日曆（calendar）裡，抓取時只讀取工作相關的日曆。對於混在工作日曆裡的非工作事項，就靠關鍵字排除（像是「午餐」、「聚餐」、「讀書會」等）。
不完美，但實務上 90% 以上的情況都能正確過濾。偶爾漏網的，LLM 通常也能從語境判斷出來。
批量回補的踩坑
系統上線後，我想回補過去 28 天的歷史日報。想說一次跑 28 天，很快就搞定了吧？
結果踩了一個大坑：重複建立。
因為初版的邏輯是「查詢日期 → 產生日報 → 建立到系統」，沒有做冪等性檢查。如果同一天跑了兩次（比如 debug 的時候手動再跑一次），就會在系統裡建立兩筆同一天的日報。28 天回補加上 debug 過程，最後一看，有些天有兩三筆重複的資料。
解法是寫一個去重腳本：
- 用 API 查詢所有日報
- 按日期分組
- 對於重複的，保留最早建立的那筆，刪除其餘
- 刪除前先做 dry run 確認
為什麼保留最早的而不是最新的？因為最早的通常是「正式產生」的那筆，後面的都是 debug 過程中重複跑出來的。這個策略不是所有情況都適用，但在我的場景裡是正確的。
另一個學到的教訓是：永遠先 query 再操作，不要假設資料不存在就直接建立。這是資料工程的基本功，但在快速迭代的過程中很容易忘記。
排程設計
最終的排程是用 Cron job 每天早上 5:00 自動執行。選 5 點是因為：
- 確保在站會之前（通常是 9 點或 10 點）有足夠的時間完成
- 所有昨天的資料都已經確定（配合凌晨 4 點的日期分界）
- 就算有 API 暫時不可用需要 retry，也有充足的緩衝時間
流程是：Cron 觸發 → 抓取多個 API 的資料 → 組合成 prompt → LLM 產生日報 → 寫入任務管理系統的日報區塊。
整個過程通常在 1-2 分鐘內完成。
LLM 在這裡的價值
你可能會問：這種事用一般的腳本不就好了？幹嘛要用 LLM？
確實，如果所有資料來源的格式都是統一的、輸出格式也是固定的，那寫 template-based 的腳本就夠了。但現實是：
- 行事曆的事件標題格式不統一（有的是「[專案] 需求討論」，有的是「跟某某開會」）
- 任務管理系統的任務描述有長有短，有的很正式，有的就一句話
- 補充任務清單的格式更是隨意
LLM 的強項就在於它不挑食，不管輸入的格式多混亂，它都能理解語意，產出格式一致的報告。而且它能做到一般腳本做不到的事：推斷上下文。比如一個任務叫「修 bug #1234」，LLM 可以結合這個任務所屬的專案名稱，在日報裡產生更有意義的描述。
使用心得
這套系統上線一陣子了，最大的好處不是「節省了 15 分鐘」這種量化指標，而是一種心理上的解放。早上起來看到日報已經自動產生好了，站會前快速掃一眼確認沒問題就好，不用再絞盡腦汁回想昨天做了什麼。
偶爾 AI 產生的日報會有一些小問題，比如把某個會議的主題理解錯了、或是工時分配不太對，但這些快速修改一下就好。整體來說，準確率大概在 85-90% 左右，考慮到完全自動化的便利性，這個準確率我可以接受。
結語
這種跨工具的資料整合，是我認為目前 LLM 最有實用價值的應用場景之一。不需要什麼花俏的技術，就是「抓資料 → 丟給 LLM → 格式化輸出」的樸實流程。但它解決的是一個真實存在的痛點，而且用傳統方式很難做好（因為資料格式太不統一）。
如果你也受夠了每天早上手動整理站會報告，不妨試試看。技術門檻不高，最花時間的反而是搞清楚各個 API 的認證和資料結構。一旦串接好，後續的維護成本很低，偶爾調一下 prompt 讓輸出更符合需求就好。
值得投入的自動化，就是那種「做一次，每天受益」的事情。