你要找的決策紀錄範本就在下面：八個欄位，貼到 Notion、Google 文件或 markdown 都能用。 不過先說實話：範本是一種「填空格式」，填完的那一刻就是它最準確的一刻——之後每一次上游決策變動， 它都在悄悄失真。這一頁先給你能直接抄走的範本，再告訴你怎麼讓它活著。 概念層面的「決策紀錄是什麼」，見 決策紀錄指南。
決定了什麼，一句話講清楚。日後被搜尋的就是這一句。
為什麼此刻需要這個決定——當時的限制、壓力、已知條件。
認真考慮過哪些方案。只有一個選項的決策，多半還沒想完。
為什麼選這個、捨棄其他。這是幾個月後最值錢的欄位。
這個決策建立在哪些前提或其他決策之上。前提變了，這裡就該亮燈。
生效中／已被取代／已撤銷。沒有狀態欄的紀錄，讀的人不知道還能不能信。
誰拍板。不是為了咎責，是為了日後有問題知道找誰補脈絡。
什麼時候定的。搭配狀態欄，讀者能判斷這個決定的「保鮮期」。
這個格式和 ADR（架構決策紀錄）相通——ADR 是工程決策的特化版。 一個決策一筆紀錄，別把三個決定塞進同一格。
八個欄位能保證你「寫下來的當下」是完整的，但它不知道世界後來變了。定價策略改了、平台規則變了——紀錄裡引用舊前提的那幾行，不會自己舉手。
你寫下這個決策依賴哪些前提。之後某個前提變了，要靠某個人「記得回來翻」這份文件——沒有人記得。於是最該保鮮的欄位，最先腐爛。
紀錄在寫完那一刻最準，之後只會越來越不準——而且你不知道哪一筆已經不準。團隊開始不信文件、改問當事人，決策紀錄就名存實亡了。
在 Draftlize 裡，決策、脈絡、選項各自是有 ID 的結構化卡片，能被引用、被連結——而不是埋在表格第三欄裡的一段字。
「依賴」在這裡是真實的連結。上游決策改了，所有依賴它的卡片自動標記過時——像建置系統把下游全部標為需要重編，而不是等人想起來回頭翻。
Claude Code 或 Cursor 透過 MCP 讀到每一筆決策的脈絡再動手，新的決定也寫回同一套結構。紀錄不再是沒人回看的檔案，而是每一輪都被讀取的上下文。
範本告訴你要寫哪些欄位。它沒辦法告訴你，哪個欄位已經跟事實對不上了。欄位照抄。讓底層結構替你保鮮。
至少八個：決策本身、當時脈絡、考慮過的選項、選擇理由、依賴的前提、目前狀態、負責人、日期。其中「理由」和「依賴」最常被省略，也最值錢——理由讓翻案有據可查，依賴讓過時可被發現。
ADR 是決策紀錄在軟體架構領域的特化版，格式幾乎相同（脈絡、決策、後果）。產品、營運、商務的決策一樣適用這套欄位——差別只在記錄的對象，不在方法。
可以起步，多數團隊也是這樣開始的。問題出在維護：文件裡的「依賴」只是文字，上游變動不會通知下游，紀錄悄悄過時、沒人發現。工具能不能自動標記過時，是紀錄能不能撐過三個月的分水嶺。
同樣八個欄位，但每個欄位是一張可定位的結構化卡片：依賴是真實連結，上游決策一改、依賴它的卡片自動標記 stale；AI agent 透過 MCP 讀寫同一套結構。一鍵就能把這個範本開成專案，欄位預先建好。
一鍵建立專案：這些章節會預先建成結構化、彼此連結的卡片。和 agent 一起回答它們——之後任何決策變了，依賴它的章節會自動標記過時，而不是悄悄失真。註冊送 $5 額度，無需綁卡。