一個純文字檔案,徹底改變了開發者使用 AI 編碼的方式。
不是新模型。
不是昂貴的 IDE。
不是另一個「AI Agent」新創公司。
只是一個檔案:
CLAUDE.md
而它悄然成為 GitHub 上成長最快的開發者配置之一。
超過 82,000 顆星。
數千個分支。
從新創公司到企業團隊的工程師,一夜之間將它複製到自己的專案中。
因為開發者終於意識到一件事:
Claude Code 失敗,不是因為模型不夠強。
而是因為每次對話開始時,它都像得了失憶症。
每次你打開 Claude Code,它都會忘記:
• 你的技術棧
• 你的架構決策
• 你的命名慣例
• 你的編碼標準
• 上週已經失敗過什麼
• 哪些東西絕對不能改
• 為什麼你選擇某個框架而非另一個
• 哪些檔案風險太高,不能碰
所以模型只能做每個缺乏上下文的 AI 都會做的事:
它開始猜測。
而這些猜測,代價極其高昂。
你請它修一個函式。
它重寫了三個檔案。
重新命名了你刻意選擇的變數。
重構了正常運作的程式碼。
建議了與你架構不相容的工具。
刪除了「順便清理」的東西。
改了沒人叫它碰的格式。
然後你花下一小時,在撤銷這些「幫助」。
這就是 AI 編碼中,沒人談論的隱藏成本。
一位工程經理估計,他們的團隊每週幾乎要浪費 8 小時,只為了:
→ 重新解釋專案背景
→ 還原未經授權的變更
→ 修正錯誤的假設
→ 重新教導架構決策
→ 阻止範圍蔓延
這不是 AI 的問題。
這是記憶的問題。
而 CLAUDE.md 用最簡單的方式解決了它。
它只是一個放在你專案根目錄的純文字檔案。
但 Claude 會在每次對話開始時自動讀取它。
意思是,你的 AI 終於從「背景脈絡」開始,而不是從「混亂」開始。
差異非常巨大。
沒有 CLAUDE.md:
「AI 助手」
有了 CLAUDE.md:
「已經了解你專案的工程師。」
這個檔案通常包含三個層級。
━━━━━━━━━━━━━━━
- 預設規則 ━━━━━━━━━━━━━━━
這個部分教導 Claude 你的工作方式。
回應應該多詳細。
你的技術棧是什麼。
你如何溝通。
你已經知道多少背景。
該用什麼寫作風格。
哪些事不能做。
像是:
→ 不要用填充詞
→ 回答的篇幅要與任務複雜度成比例
→ 在做出假設前先提問
→ 不要過度解釋基本概念
→ 完全比照我的編碼風格
→ 自動遵循專案限制
聽起來很小。
但累積數百次提示之後呢?
這消除了大量的重複。
大多數開發者不知不覺中,每天花 20 到 40 分鐘在重新教導 AI 背景。
每一次。每一場對話。
現在把這個數字乘以一個工程團隊。
那就是每個月浪費數千美元,只為了重複說同樣的話。

━━━━━━━━━━━━━━━
- 行為控制
━━━━━━━━━━━━━━━
這是開發者幾個月前就希望擁有的部分。
因為在這裡,你可以阻止 Claude 變得「有創意地破壞」。
你定義了明確的界線,像是:
→ 只碰與任務直接相關的檔案
→ 絕不重構無關的程式碼
→ 刪除任何東西前先詢問
→ 執行破壞性動作前先確認
→ 未經核准,不得改寫現有結構
→ 永遠清楚顯示改了什麼
→ 絕不自動部署或執行遷移
這單一部分,就能防止大多數 AI 編碼的恐怖故事。
不再有驚喜重寫。
不再有架構偏移。
不再有「我幫你清理了一下」的災難。
AI 變得可預測。
而這正是工程師真正想要的。

━━━━━━━━━━━━━━━
- 記憶 + 專案大腦
━━━━━━━━━━━━━━━
這裡才是真正強大的地方。
開發者開始將 CLAUDE.md 與以下檔案搭配使用:
MEMORY.md
ERRORS.md
現在 Claude 可以記住:
• 你的團隊已經做出的決策
• 失敗過的方法
• 被否決的工具
• 生產環境事故
• 技術限制
• 架構取捨
• 客戶特定的規則
意思是,AI 不再推薦你幾個月前就已經排除的東西。
它不再忘記。
這改變了一切。
因為 AI 編碼真正的瓶頸,不再是程式碼生成。
而是持續的上下文。
而大多數人還沒有意識到這一點。

━━━━━━━━━━━━━━━
讓它爆紅的 4 條規則
━━━━━━━━━━━━━━━
這個配置之所以爆紅,是因為開發者開始分享 4 條簡單的規則,靈感來自 Andrej Karpathy 與 AI 系統合作的方法。
它們看起來簡單得令人難以置信:
- 先問,再假設。
- 先用最簡單的解法。
- 不要碰無關的程式碼。
- 立即標示不確定的地方。
就這樣。
但這 4 條規則解決了大多數 AI 編碼的失敗。
因為最大的傷害,通常來自 AI 在缺乏足夠背景時,卻表現得過於自信。
獲得最佳結果的開發者,並不是使用「更多 AI」。
他們是在減少模糊性。
而一旦你看到這一點,就再也無法忽視。
━━━━━━━━━━━━━━━
AI 編碼的真正分野
━━━━━━━━━━━━━━━
現在,使用 Claude Code 的開發者基本上分成兩類。
第一組:
每次對話都從零開始。
每天重複背景。
清理不必要的變更。
不斷對抗範圍蔓延。
把 AI 當成臨時的自動完成。
第二組:
使用持續性的指令。
鎖定行為規則。
維護專案記憶。
嚴格控制範圍。
把 AI 當成長期的工程協作者。
同樣的模型。
完全不同的結果。
這就是為什麼這個檔案傳播得這麼快。
因為一旦 Claude 擁有:
• 規則
• 記憶
• 技術棧意識
• 行為限制
• 專案背景
……它就不再像個聊天機器人。
而開始感覺像基礎設施。
━━━━━━━━━━━━━━━
從這裡開始
━━━━━━━━━━━━━━━
打開你的專案。
建立一個名為:
CLAUDE.md
的檔案。
然後先貼上這 4 條規則:
• 先問,再假設
• 先用最簡單的解法
• 不要碰無關的程式碼
• 明確標示不確定性
光是這樣,就能立即改善 Claude 的行為。
然後隨著時間慢慢擴充:
→ 你的技術棧
→ 編碼標準
→ 架構規則
→ 禁止事項
→ 決策記錄
→ 專案記憶
大多數開發者還沒有這麼做。
這意味著,一般 AI 輔助編碼與頂尖 AI 輔助編碼之間的差距,越來越不在於模型本身……
……而在於誰知道如何正確地組織背景。
把這篇存起來。
因為六個月後,持續性的 AI 專案記憶,很可能會變得跟今天的 GitHub 儲存庫一樣普遍。





