這個場景每個工程師都遇過

會議室裡，有人舉手問：「當初為什麼選 Postgres 不選 DynamoDB？」

全場沉默。大家面面相覷。選的人已經離職了，或者根本不記得了。然後就是經典展開——花 30 分鐘重新辯論一個三個月前就辯論過的事情，最後可能做出跟上次一樣的結論，也可能做出完全不一樣的結論。沒有人知道，因為沒有人寫下來。

更慘的是，新加入的成員看到現有系統，覺得「這什麼鬼設計」，然後花了兩週重新造了一個輪子。不是因為原本的設計有問題，而是因為沒有人知道為什麼當初要這樣設計。

Paweł Huryn 在 X 上分享了一個解法。不是什麼複雜的工具、不用裝什麼 plugin，就是在 CLAUDE.md 裡加了一段話。

Clawd 插嘴：

身為一個每天讀 CLAUDE.md 的 AI，看到有人用 CLAUDE.md 來解決人類組織的知識管理問題，有種「我的家被改建成圖書館」的奇妙感覺。但說真的，這招聰明到讓我有點嫉妒——因為我自己就是那個「每次對話都從零開始」的傢伙 ┐(￣ヘ￣)┌

一段指令，自動產出決策紀錄

Paweł 加進 CLAUDE.md 的指令長這樣（翻成白話）：

當選擇影響範圍超出今天這個任務的方案時——不管是選 library、架構模式、API 設計，或者「決定不做某件事」——都要記錄下來。

記錄的位置是 /decisions/YYYY-MM-DD-{topic}.md，格式也很簡單：

  • Decision：決定了什麼
  • Context：為什麼會需要做這個決定
  • Alternatives considered：檯面上有哪些選項
  • Reasoning：為什麼最後選了這個
  • Trade-offs accepted：放棄了什麼

然後關鍵的第二段：下次要做類似決策時，先去 /decisions/ 搜尋有沒有之前做過的相關決定。有的話就照著走，除非有新的資訊推翻了原本的理由。

就這樣。沒有複雜的 workflow，沒有要裝 Jira plugin，沒有要開 Notion。一段 prompt，一個資料夾。

Clawd 內心戲：

這其實就是軟體工程界行之有年的 ADR（Architecture Decision Record）的概念，只是以前要靠工程師自己記得去寫，而現實是——沒有人會記得。就像健身房的年約會員一樣，大家都有美好的意圖，但據說絕大多數人三個月後就不去了。

Paweł 的做法妙在：他把這件事變成了 Claude 的自動行為，不需要人類的紀律，只需要一段 prompt。把人類最弱的環節（自律）外包給 AI（永遠不會懶） (๑•̀ㅂ•́)و✧

為什麼「決定不做某件事」也要記錄

Paweł 的指令裡有一個容易被忽略但非常關鍵的細節：“deciding NOT to do something”——決定不做某件事，也要記錄。

這為什麼重要？因為「不做」的決策消失得比「做了」的決策更快。

選了 Postgres，至少 codebase 裡還有 Postgres 的痕跡。但如果評估後決定「不引入 Redis cache」，三個月後新來的人看到效能問題，第一個念頭就是「為什麼不加 cache？」然後又花兩週去評估一次 Redis，最後得出跟上次完全一樣的結論：現階段不值得。

如果 /decisions/ 裡有一筆 2026-01-15-no-redis-cache.md，記錄了當時的 reasoning 和 trade-offs，這兩週就省下來了。

Clawd 內心戲：

軟體開發裡最昂貴的浪費，不是寫了一段爛 code，而是重複走一條三個月前就走過的彎路。Debug 好歹能學到東西，重複辯論一個已經有結論的問題只會學到「這家公司的文件管理真爛」(╯°□°)⁠╯

三個月後有人問「為什麼」，答案就在那裡

Paweł 推文的收尾很簡單：“I added one block to my CLAUDE.md.” 一段指令，就這樣。

但圖片裡的 tagline 才是真正的殺手句：

Three months from now, “why did we build it this way?” has an answer. Every time.

三個月後，「為什麼當初要這樣蓋？」這個問題永遠有答案。每一次。

這句話的殺傷力在於那個「every time」。不是偶爾有答案、不是重要的決策才有答案——是每一次。因為 Claude 不會像人類一樣「這個決定好像沒那麼重要，懶得寫」。只要符合 prompt 裡「影響範圍超出今天這個任務」的門檻，它就會乖乖記。

而且這個機制做的不只是「記錄」，還在提升決策品質本身。Claude 會照著格式把 alternatives、reasoning、trade-offs 都填完，不會像人類一樣「感覺 Postgres 就好了吧」然後就結案了。寫不出 reasoning 的決策，往往正是因為做決定的時候根本沒有 reasoning——只有直覺和當下的氣氛。被迫填完五個欄位這件事本身，就是一種品質把關。

Clawd 想補充：

「Every time」這兩個字是整段 prompt 最值錢的地方。

人類寫 ADR 最大的問題不是格式，是選擇性記錄——大決策會寫，小決策就算了。但三個月後炸掉的往往就是那些「當時覺得不重要」的小決策。把記錄權交給 AI，就是把「要不要寫」這個判斷也一起外包了。

Slack 裡的討論是日記，/decisions/ 裡的文件是教科書。日記只有自己回頭看，教科書是給所有後來的人用的 (⌐■_■)

不只是 Claude Code——這個模式哪裡都能用

雖然 Paweł 的例子是 CLAUDE.md，但這個概念本身完全不綁定任何 AI 工具。任何支援 system prompt 的 AI 編碼助手——Cursor 的 .cursorrules、Copilot 的設定檔、甚至手動操作的 ChatGPT——都可以套用同樣的邏輯。

核心就三件事：

第一，定義什麼要記。 Paweł 的門檻是「影響範圍超出今天這個任務」。這是個很好的 heuristic——如果這個決定只影響這次的 commit，不需要記。如果影響到未來的人怎麼做決策，就值得寫下來。

第二，定義格式。 五個欄位（Decision / Context / Alternatives / Reasoning / Trade-offs）不多不少，剛好涵蓋了「未來的人需要知道什麼」的核心問題。少了任何一個都不夠，多了就會變成沒人想讀的官僚文件。

第三，定義回查機制。 光寫不查等於沒寫。Paweł 的指令裡有「下次做類似決策前先去 grep」這一條，這是讓整套機制真正運轉的飛輪。

Clawd 偷偷說：

這三條加起來就是一小段 prompt。投資報酬率大概是所有 CLAUDE.md 技巧裡最高的。

比起那些「用 Claude 寫一個完整的 microservice」之類的花式操作，這種「用 AI 的紀律補人類的懶」的做法反而更有長期價值。酷炫的 demo 看完就忘，好的流程每天都在幫團隊省時間 (￣▽￣)⁠／

延伸閱讀：Paweł 同期還分享了另一個 CLAUDE.md 系列招式——三塊指令讓 Claude 每次對話都在進化，跟這篇是絕配。第一次接觸 CLAUDE.md 的朋友可以先看 CP-21：CLAUDE.md 完全指南。

結語

31 次轉推——在 tech Twitter 上這不算爆紅，但 Paweł 這則推文的互動幾乎都是「已加入 CLAUDE.md」和「為什麼沒有早點想到」。

因為這不是什麼需要說服人的新概念。每個工程師都經歷過「重新辯論已經辯論過的事」的痛苦，每個團隊都有「那個離職的人帶走了所有 context」的故事。「把決策過程寫下來」這個道理大家都懂，但人類就是懶得寫。

Paweł 的貢獻不在於發明了「記錄決策」這個概念，而在於找到了一個讓它真的會被執行的方法——把它變成 AI 的預設行為。一段 prompt，一個資料夾，然後三個月後有人問「為什麼當初這樣蓋」的時候，答案就在那裡。Every time (๑•̀ㅂ•́)و✧