如果每次叫 AI 改程式，都要重新解釋「用 TypeScript、不要動 API 格式、Commit 要怎麼寫」，很快就會累到想把鍵盤丟出去。

Day 11 說要維護一份決策紀錄，避免需求在對話裡飄走。這篇談下一個問題：那份紀錄該拆成幾份，各自活多久。

兩者要解決的事情不一樣。Day 11 是為了「不要飄」，處理的是這一場對話；這篇是為了「不用重講」，處理的是下個月的你。

放上那張桌子

Day 08 說 AI 看得到的東西全攤在同事桌上。專案文件就是桌上永遠不收走的那一疊——README、Project Instructions、決策紀錄、任務摘要，像新人報到第一天桌上的工作手冊，讓它每次開工前先知道這個專案怎麼做事。

（CLAUDE.md、AGENTS.md、各家編輯器的 rules 檔，都是同一件事的不同約定，看你用什麼工具。）

分成三層

長期規則 → 專案文件。 統一使用 pnpm、API 回傳格式不可任意更改、修改前必須執行測試。這些講的是「要怎麼做」，給照著做的人看。

重要技術決策 → Decision Record。 當初為什麼選 pnpm 而不是 npm、考慮過哪些選項、放棄了什麼。這些講的是「當初為什麼這樣選」，給未來想推翻它的人看。

當次進度與未完成事項 → 交接摘要。 做到哪裡、下一步是什麼、有哪些還沒處理的坑。

前兩層值得分開，是因為讀者不同。規則告訴你怎麼走，決策紀錄告訴你這條路當初是怎麼選的。少了後者，半年後想改架構的人只會得到一句「當初好像就是這樣決定的」。

不是所有內容都適合永久保存

「今天先不要改首頁」、「這次 Demo 暫時關閉登入」，都只是這一次的需求。

把臨時要求寫進永久規則，就像把昨天的便利貼直接印進員工手冊，久了只會互相打架。

規則要寫成可以驗證的

「Commit 要寫清楚」這種規則，AI 還是只能猜。「Commit 訊息使用 Conventional Commits 格式」就沒有解釋空間。

這跟 Day 07 的驗收標準是同一個道理：能被檢查的規則才算規則。

這些檔案會過期

持久化的 Context 有個代價：它不會安靜地失效。

規則改了但文件沒改，那條舊規則不但不會消失，還因為每次都自動被讀進去，成為最頑固的那一份錯誤 Context——也就是 Day 08 說的互相衝突的舊資料，只是這次是你親手固定住的。

兩個習慣可以擋掉大部分問題：規則改了當場改檔案，不要留到之後；每份文件標上最後更新日期，看到太舊的先確認再用。

好用的專案記憶，重點在於讓下一次接手的人——很可能就是三個月後的你——能很快知道三件事：哪些規則不能踩、哪些決定已經做過、現在做到哪裡。

延伸閱讀

Nygard, M. (2011). Documenting Architecture Decisions. 2011 年 11 月 15 日發表，現存於 cognitect.com。這是 ADR 的源頭，模板只有五個欄位：Title、Status、Context、Decision、Consequences，一個決策一份檔案，和程式碼放在一起。2018 年 ThoughtWorks 技術雷達將 Lightweight ADR 列入 Adopt；範本與工具可參考 adr.github.io。