我曾經以為，自動產生工作日報的關鍵，是把行事曆、待辦清單、工作筆記和程式紀錄全部接進來。資料愈完整，AI 就愈能還原昨天發生的事。
實際跑了一段時間後，我才發現真正棘手的不是漏資料，而是 AI 太容易把「有活動」寫成「有進度」。行事曆只能證明一段時間被安排了，待辦只能證明某件事曾經被計畫；它們都不必然代表工作已經完成。
日報最危險的錯，不是少寫一項
人工寫日報時，我們多少會做一次心裡的查核：會議有沒有真的開、討論有沒有結論、原本排定的工作是否完成。AI 在沒有明確規則時，則很容易順著資料的表面語意往下寫。
行事曆上有「處理介接問題」，產出的句子就可能變成「完成介接問題處理」；待辦上有「確認驗收流程」，它可能被整理成「已確認驗收流程」。文字只多了幾個字，管理意義卻完全不同。
少寫一項，通常只是資訊不完整；把計畫寫成成果，則會讓團隊在錯誤的現實上做判斷。主管可能以為風險已排除，同事可能以為可以接手下一步，真正的阻塞反而被一份讀起來很順的報告蓋掉。
生成式 AI 最麻煩的地方就在這裡：它不只會犯錯，還會把不確定性整理成很像結論的句子。
先分清楚三種完全不同的資料
我現在會先把日報來源分成三層，而不是直接丟給模型摘要。
第一層是計畫。待辦、排程、行事曆主旨，都在描述「原本打算做什麼」。這些資料適合用來整理今天的重點或預期安排，不能單獨成為昨日完成事項。
第二層是活動。會議出席、聊天討論、檔案開啟、Agent session、工具呼叫，都能證明「曾經投入或發生過」。活動比計畫更接近事實，但仍不代表有可交付成果。一場會議可能延期，也可能談了一小時仍沒有決議；一段除錯工作可能找到了方向，也可能只排除了一個錯誤假設。
第三層是結果。狀態確實變成完成、程式有可對應的提交與測試、文件已寫入並回讀、部署有健康檢查、決策有結論與負責人。這些才是適合用「完成、修正、交付、確認」描述的證據。
這三層不是誰取代誰，而是回答不同問題：計畫告訴我想去哪裡，活動告訴我時間花在哪裡，結果才告訴我到底前進了多少。
讓動詞跟證據強度綁在一起
比起要求 AI「不要亂寫」，我更傾向直接限制它能使用的動詞。
只有計畫資料時，用「預計、排定、待處理」；只有活動證據時，用「討論、釐清、檢視、持續處理」；有結果證據時，才可以用「完成、上線、修正、驗證」。如果來源彼此衝突，就保留較保守的描述，或明確標示「尚待確認」。
這看起來像文案規則，本質上卻是資料契約。因為「完成」不是修辭，而是一個會被下游流程依賴的狀態。只要日報會進入站會、週報、績效回顧或專案判斷，它就不再只是個人筆記，而是一個輕量的管理介面。
我也會要求每一項完成敘述至少能回到一個來源。報告不一定要把所有連結攤在正文裡，但系統應保留來源類型、時間與驗證結果。當有人問「為什麼判定完成」，不能只回答「AI 從昨天的紀錄整理出來」。
沒有證據，不代表什麼都沒做
證據導向很容易走向另一個極端：只承認 commit、單據或狀態異動，於是研究、溝通、排錯與決策準備都像不存在。
這也不對。技術主管的工作有很大一部分，本來就不會每天留下程式提交。真正的做法不是刪掉這些活動，而是誠實描述它們所處的階段。
例如，沒有修改成果但已定位問題，可以寫「完成原因定位，修正待後續處理」；會議有共識但尚未執行，可以寫「確認方案與責任分工，尚未上線」；做了研究卻沒有定案，可以寫「比較可行路徑，仍待風險評估」。
這些句子沒有「全部完成」那麼漂亮，卻更能幫助團隊接續工作。日報的價值不是把每一天寫得很有成就，而是降低下一個人理解現況的成本。
把不確定性留下來，管理才會變清楚
現在我評估自動日報，不再只看它省下多少撰寫時間，而會檢查幾件事：計畫與成果有沒有分開、每個完成事項是否有足夠證據、未完成與阻塞是否被保留、來源衝突時會不會選擇較保守的說法，以及人能不能快速修正判定。
這些規則也適用於更大的 AI 工作流。當 Agent 開始摘要工單、專案進度或營運狀態，最重要的能力往往不是寫得像人，而是知道自己手上的資料能證明到哪一步。
行事曆可以證明我原本把時間留給一件事，系統紀錄可以證明某些活動真的發生，驗證結果才足以支撐完成。把這些邊界分清楚，AI 才不是替忙碌加上漂亮文案，而是在幫團隊維護一份可信的共同現實。