Work Log：跨 session 的記憶機制
TL;DR： Work Log 是一個很無聊的東西：一份 markdown 檔案，記錄這個任務做到哪裡、做了哪些決定、下個 session 要從哪裡繼續。它沒有解決 AI 的記憶問題，只是繞過它。但在我們找到更好的方法之前，它有效。 在那篇談治理基礎的文章裡，我說過 AI「只活在那一次的對話框裡」。這個說法的代價，在你真正開始用 AI 代理做持續開發的時候才會變得具體。 你跟 AI 花了一個小時討論這個 feature 要走哪個設計模式、為什麼不用另一個方案、資料庫的 schema 要怎麼調整。全部討論清楚了，開始實作。隔天開新對話，繼續做。AI 從頭來：哪個設計模式？資料庫？我不知道你說的是什麼。 這不是 Claude 的問題，也不是任何特定模型的問題。它就是這樣運作的。上一篇說到記憶檔案（CLAUDE.md、AGENTS.md）可以幫助 AI 記住專案的架構規則。但那解決的是「規則要記住」的問題，不是「這個任務做到哪裡」的問題。Work Log 是後者。 兩層記憶，兩個問題 先說清楚兩個東西的差別，因為我發現自己最初混在一起想。 專案記憶：這個專案的架構是什麼、用了哪些 ADR、活躍的任務清單在哪裡、哪些 skill 可以用。這是全域的、靜態的，跟任何一個具體任務無關。你不常去動它，但每次開新 session，AI 需要讀它才知道自己在什麼脈絡裡。 任務記憶（Work Log）：這個任務做到哪個 phase、做了哪些決定、下一個 session 要從哪裡繼續。它是動態的、per-task 的。一個任務一個檔案，在 Agentic OS 裡放在 .agentcortex/context/work/<task-key>.md（完整結構見 repo）。 混在一起的後果是：要麼全域狀態被塞滿具體任務細節（之後沒人看得懂），要麼任務進度沒地方記（每次都從頭）。分開之後，兩個問題各有各的解。 Work Log 長什麼樣子 下面是一個簡化版的實際樣子（來自 github.com/KbWen/agentic-os）： # Work Log: feat/email-verification ## Header - Branch: feat/email-verification - Classification: feature - Current Phase: implement - Checkpoint SHA: a3f9c12 ## Task Description 新增 email OTP 驗證流程。使用者第一次登入後需完成驗證， 未驗證帳號只能讀取，不能寫入。 ## Phase Sequence | Phase | Status | Notes | |-----------|-------------|--------------------------| | bootstrap | completed | 分類為 feature | | plan | completed | 確認走 OTP 不走 magic link | | implement | in-progress | auth module 完成，email 發送待測 | | review | pending | | ## Gate Evidence - Gate: plan | Verdict: pass | At: 2026-05-10T14:00Z - Gate: implement | Verdict: FAIL | Reason: email sending untested, scope not complete | At: 2026-05-11T09:00Z ## Phase Summary - plan: 討論了 OTP vs magic link。決定用 OTP，因為我們的 email provider 有速率限制，magic link 的 retry 設計複雜度更高。 這個決定要記住，下個 session 不要再討論。 關鍵不在格式，在那個 Phase Summary。每個完成的 phase，AI 要用一段話說：做了什麼決定、為什麼這樣決定、有什麼取捨。 ...