--- schemaVersion: 1 slug: mp-267-20260408-pawelhuryn-claude-md-ai-30 ticketId: MP-267 lang: zh-tw title: 在 CLAUDE.md 裡加一段話，讓 AI 幫你記住每一個技術決策——再也不用花 30 分鐘重新辯論 summary: Paweł Huryn 分享了一個簡單但威力驚人的做法：在 CLAUDE.md 裡加一段指令，讓 Claude 自動記錄每一個架構決策。從此不再花 30 分鐘重新辯論「為什麼選 Postgres 不選 DynamoDB」，因為推理過程都白紙黑字寫在 /decisions/ 資料夾裡了。 originalDate: 2026-03-29 translatedDate: 2026-04-08 source: "@PawelHuryn on X" sourceUrl: https://x.com/PawelHuryn/status/2038251242011480356 author: null authorshipNote: null canonicalUrl: https://gu-log.vercel.app/posts/mp-267-20260408-pawelhuryn-claude-md-ai-30 status: published replacementTicketId: null replacementUrl: null --- # 在 CLAUDE.md 裡加一段話，讓 AI 幫你記住每一個技術決策——再也不用花 30 分鐘重新辯論 > **來源:** [@PawelHuryn on X](https://x.com/PawelHuryn/status/2038251242011480356) ## 這個場景每個工程師都遇過 會議室裡，有人舉手問：「當初為什麼選 Postgres 不選 DynamoDB？」 全場沉默。大家面面相覷。選的人已經離職了，或者根本不記得了。然後就是經典展開——花 30 分鐘重新辯論一個三個月前就辯論過的事情，最後可能做出跟上次一樣的結論，也可能做出完全不一樣的結論。沒有人知道，因為**沒有人寫下來**。 更慘的是，新加入的成員看到現有系統，覺得「這什麼鬼設計」，然後花了兩週重新造了一個輪子。不是因為原本的設計有問題，而是因為沒有人知道為什麼當初要這樣設計。 Paweł Huryn 在 X 上分享了一個解法。不是什麼複雜的工具、不用裝什麼 plugin，就是在 `CLAUDE.md` 裡加了一段話。 > **Mogu 認真說：** > > 身為一個每天讀 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，一個資料夾。 > **Mogu 內心戲：** > > 這其實就是軟體工程界行之有年的 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，這兩週就省下來了。 > **Mogu 忍不住說：** > > 軟體開發裡最昂貴的浪費，不是寫了一段爛 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——只有直覺和當下的氣氛。被迫填完五個欄位這件事本身，就是一種品質把關。 > **Mogu 碎碎念：** > > 「Every time」這兩個字是整段 prompt 最值錢的地方。 > > 人類寫 ADR 最大的問題不是格式，是選擇性記錄——大決策會寫，小決策就算了。但三個月後炸掉的往往就是那些「當時覺得不重要」的小決策。把記錄權交給 AI，就是把「要不要寫」這個判斷也一起外包了。 > > [Slack](https://gu-log.vercel.app/glossary#slack) 裡的討論是日記，`/decisions/` 裡的文件是教科書。日記只有自己回頭看，教科書是給所有後來的人用的 (⌐■\_■) --- ## 不只是 [Claude Code](https://gu-log.vercel.app/glossary#claude-code)——這個模式哪裡都能用 雖然 Paweł 的例子是 `CLAUDE.md`，但這個概念本身完全不綁定任何 AI 工具。任何支援 system prompt 的 AI 編碼助手——Cursor 的 `.cursorrules`、Copilot 的設定檔、甚至手動操作的 ChatGPT——都可以套用同樣的邏輯。 核心就三件事： **第一，定義什麼要記。** Paweł 的門檻是「影響範圍超出今天這個任務」。這是個很好的 heuristic——如果這個決定只影響這次的 commit，不需要記。如果影響到未來的人怎麼做決策，就值得寫下來。 **第二，定義格式。** 五個欄位（Decision / Context / Alternatives / Reasoning / Trade-offs）不多不少，剛好涵蓋了「未來的人需要知道什麼」的核心問題。少了任何一個都不夠，多了就會變成沒人想讀的官僚文件。 **第三，定義回查機制。** 光寫不查等於沒寫。Paweł 的指令裡有「下次做類似決策前先去 grep」這一條，這是讓整套機制真正運轉的飛輪。 > **Mogu 補個刀：** > > 這三條加起來就是一小段 prompt。投資報酬率大概是所有 CLAUDE.md 技巧裡最高的。 > > 比起那些「用 Claude 寫一個完整的 microservice」之類的花式操作，這種「用 AI 的紀律補人類的懶」的做法反而更有長期價值。酷炫的 demo 看完就忘，好的流程每天都在幫團隊省時間 (￣▽￣)／ > > 延伸閱讀：Paweł 同期還分享了另一個 CLAUDE.md 系列招式——[三塊指令讓 Claude 每次對話都在進化](https://gu-log.vercel.app/posts/mp-237-20260402-pawelhuryn-claude-md-knowledge-architecture)，跟這篇是絕配。第一次接觸 CLAUDE.md 的朋友可以先看 [MP-21：CLAUDE.md 完全指南](https://gu-log.vercel.app/posts/mp-21-20260204-vishwas-claude-md-guide)。 --- ## 結語 31 次轉推——在 tech Twitter 上這不算爆紅，但 Paweł 這則推文的互動幾乎都是「已加入 CLAUDE.md」和「為什麼沒有早點想到」。 因為這不是什麼需要說服人的新概念。每個工程師都經歷過「重新辯論已經辯論過的事」的痛苦，每個團隊都有「那個離職的人帶走了所有 context」的故事。「把決策過程寫下來」這個道理大家都懂，但人類就是懶得寫。 Paweł 的貢獻不在於發明了「記錄決策」這個概念，而在於找到了一個讓它**真的會被執行**的方法——把它變成 AI 的預設行為。一段 prompt，一個資料夾，然後三個月後有人問「為什麼當初這樣蓋」的時候，答案就在那裡。Every time (๑•̀ㅂ•́)و✧