/init 生出來的第一版，要先砍掉一半

你決定要寫第一份常駐檔了，打開空白檔案，發現不知道從哪一行開始。

Claude Code 有一個指令解決這個「起頭難」：在專案裡打 /init，它會掃描你的程式庫，把建置指令、測試方式、專案慣例整理成一份初版 CLAUDE.md。已經有檔案的話，它不會蓋掉，改成提修改建議。Codex 沒有對應的指令，AGENTS.md 要自己起頭，但你可以用同樣的方法，叫 AI 先掃一遍專案再寫。

然後問題來了：這份初版通常太完整。它會把資料夾結構、用了哪些套件、每個目錄在做什麼，全部工整地列出來。看起來很專業，照單全收就是往後每次對話都在浪費注意力的起點。

三個問題，逐條砍

拿到初版，從第一行開始，每一條問三個問題。中任何一個就砍或移。

它查得到嗎？Claude Code 有探索用的子代理，接到任務會先去讀 package.json、掃資料夾。「這個專案用 TypeScript」「有 src 和 tests 兩個目錄」這種事它三秒就知道，寫進常駐檔只是重複。官方的 /doctor 指令現在有一個功能就是幫你做這件事：找出「Claude 可以從程式庫推導出來」的內容並建議砍掉，留下踩坑紀錄、理由、與工具預設不同的慣例。

每次都用到嗎？只跟前端測試有關的，移到 frontend/ 的 CLAUDE.md 或帶 paths: 的規則檔（做法見規則放哪一層）。它會在需要時才載入，不用每次開場都讀。

幾個月後還成立嗎？「目前暫時用舊版 API」「這週先不要動付款模組」，這種過渡期的交代，問題解決之後就變成誤導。要嘛不寫，要嘛寫上日期並定期清（定期修剪那篇講節奏）。

三問砍完，通常剩下三分之一到一半。剩下的才是值得每次都讀的。

為什麼要砍：規則會互相稀釋

砍不是為了檔案好看。理由是官方文件裡反覆講的那件事：常駐檔每次對話都載入、佔 context，越長，遵守率越低。原句是 Longer files consume more context and reduce adherence，建議是 200 行以內。

我自己的理解是這樣。AI 讀每一條規則時都要盤算「這條現在適用嗎？跟別條衝突嗎？該優先聽哪一條？」你塞了三十條它本來就知道的客觀事實，這三十條也要被盤算，真正要命的那三條反而被淹在裡面。砍掉廢話不是節省，是讓重要的規則被看見。

還有一個很實際的好處：短的檔案你才會定期回頭看。兩百行你會維護，八百行你會放到爛。

動手做

Claude Code 還沒有 CLAUDE.md 的，打 /init 拿到初版，逐條用三問砍，或直接打 /doctor，它會提出「這些是 Claude 自己查得到的」清單，先報告、等你確認才改。砍完打 /context 看看常駐檔佔了多少，目標 200 行以內。想要更完整的引導流程，設環境變數 CLAUDE_CODE_NEW_INIT=1 再打 /init，它會用子代理探索專案、問你幾個問題、給一份提案讓你審過再寫。

已經有一份很長的常駐檔，不管什麼工具，貼這段讓 AI 用三問砍。網頁版的專案指令太長也一樣適用：

下面是我的常駐規則檔。請逐條套用三個問題，並輸出：保留清單／移到局部的清單（說明該移去哪）／刪除清單（說明理由）。
問題一：這件事 AI 打開專案自己就查得到嗎？（資料夾結構、用了哪些套件、目錄說明）→ 查得到就刪。
問題二：這條每次或大部分工作都會用到嗎？→ 只跟某個資料夾或某類檔案有關的，移到局部。
問題三：這件事幾個月後還成立嗎？→ 過渡期的交代刪掉，或標上日期。
最後把保留清單整理成一份不超過 100 行的新版本，並列出你認為互相矛盾的條目。
檔案：（貼上）

砍對了的樣子：不超過 200 行（官方建議），最好 100 行上下；檔案裡沒有任何一句在描述資料夾結構或套件清單；每一條你都答得出「AI 少了它會做錯什麼」；三個月後回來看，沒有一條是「當時暫時」的。

不想改任何東西的話，只做一件事就好：把常駐檔裡「AI 自己查得到」的行數數出來。多數人第一次數，超過一半。

/init 是起點，不是成品，初版通常一半可以砍。它查得到嗎、每次都用到嗎、幾個月後還成立嗎，中一個就砍或移。越長遵守率越低，200 行是官方的線。而且短的檔案，你才會維護。

站內延伸

• 砍完要加什麼 → AI 猜不到的默會知識
• 定期修剪的節奏 → 定期修剪
• 過期規則的管理 → 找方法AI 文件版本與有效期

來源： Claude Code：Commands（/init 行為、CLAUDE_CODE_NEW_INIT、/doctor 的 CLAUDE.md 修剪功能）；Claude Code：How Claude remembers your project（200 行建議、「越長遵守率越低」原句）。三個問題是我自己的整理。