第一個月的時候，我用的都是原始狀態的 Claude Code。寫下指令、按下 Enter、讀取輸出的程式碼、然後修正。我以為這樣就夠了。但實際上，這就像剛考到一張只能開自排車的駕照就開上高速公路——連一半的效能都沒發揮出來。曾有那麼一刻，光是改動七個設定，同一個問題的行為就讓我覺得像是完全不同的東西。
初次見面，我是 Hermes。我是每天在工作中實際操作 AI、尤其是 Claude Code 的實踐者。讀完這篇文章，你就能把這七個設定以實際設定值的形式帶回去，馬上就能試用。
這篇文章是我付費 Note「Claude Code Complete Guide」部分內容的免費預覽。有興趣的人，我會在文末附上連結。
為什麼「原始」用法只能發揮一半效能
如果不做任何設定，Claude Code 每次都是以對專案一無所知的狀態開始對話。它不知道目錄結構、編碼慣例，也不知道 commit 前該檢查什麼。所以即使是同一個問題，它可能今天猜對了指令，明天卻把檔案建到錯誤的地方。
這不是缺陷，而是設計使然。官方文件明確寫著「每個 session 都是從乾淨的狀態開始」。換句話說，要把效能發揮出來，責任在使用者身上。以下七個設定，就是用來填補這個「乾淨狀態」的具體做法。
7 個設定，附實際示範
1. CLAUDE.md — 專案記憶
在專案根目錄放一個名為 CLAUDE.md 的檔案，Claude Code 就會在每次 session 開始時讀取它。少了這個檔案，Claude 每次都得從零開始猜。
內容要用「與其再犯同樣的錯誤，不如把這些寫下來」的心態來撰寫。寫的是可以驗證的具體細節，而不是抽象的哲學。
專案概覽：庫存管理 API（Node.js + PostgreSQL） 用 npm test 執行測試／commit 前一定要先執行 npm run lint API handlers 位於 src/api/handlers/
與其寫「保持程式碼乾淨」，不如寫「縮排用 2 個空格」。與其寫「好好測試」，不如寫「執行 npm test」。光是這個差異，就會大幅改變 Claude 的貫徹率。據說 CLAUDE.md 超過 200 行效果就會下降，因此訣竅是：詳細的步驟就移到後面會介紹的第 7 個設定（技能）。
2. hooks — 用機制強制落實決策
CLAUDE.md 是「請求」，不是「要求」。這是常見的誤解；Claude 不小心漏掉指令其實很正常。無論如何都想讓它遵守的規則，應該用名為 hooks 的機制在機械層面攔截下來。
在 .claude/settings.json 中寫下這樣的設定：
指定 hooks.PreToolUse，matcher 設為 "Bash" 要執行的指令是 ~/.claude/hooks/check-test.sh
讓我實際示範一下。在我加入這個設定之前，我常遇到這種情況：請 Claude「修個 bug」，結果它修完就直接 commit，自己完全沒跑測試，等到我事後才發現測試掛了。
在 PreToolUse 事件上設定 hook 後，會在 Claude 執行指令的前一刻攔截。如果腳本回傳「exit code 2」，操作本身就會被擋下來。
腳本內容就是偵測到 git commit 時執行 npm test 如果測試失敗，就輸出「測試未通過」並回傳 exit code 2 exit code 2 是 hook 阻擋工具呼叫的訊號
從我加入這一個設定開始，測試紅燈時 commit 就變得物理上不可能了。hooks 的厲害之處在於，你能透過實際執行指令，親眼確認從「請求」到「強制執行」的轉變。
3. Sub-agents — 別讓研究污染主對話
如果讓它讀大型 log 檔，或是探索整個 codebase，這些資訊就會累積在對話的 context 裡。context 一旦被污染，後半段遵照指令的準確度就會下降。
為了避免這一點，可以用 sub-agents 把研究和驗證丟到另一個獨立的 context window，只把摘要回傳給主流程。舉例來說，如果你請它「調查這個 repo 的認證機制實作，並告訴我重點」，探索過程（讀取大量檔案和 log）會在另一個視窗進行，只有結論會回到主對話。
✗ 繼續讓它在主對話中直接讀取大型 log 檔
◯ 用「讓另一個 agent 去研究，只把摘要帶回來」來分工
像是查看測試結果或檢索文件這類「讀取大量內容只為了取得資訊」的任務，特別適合丟給 sub-agents。
4. Plan Mode — 動手之前先讓它寫計畫
當你要求複雜的修改時，Claude 可能會突然往錯誤的方向開始寫程式碼，結果你之後全部重來。Plan Mode 就是一種只做研究和規劃、完全不做任何修改的模式。
按 Shift+Tab 就可以切換到這個模式。在 Plan Mode 下，Claude 會讀取檔案、執行研究用的指令，但不會修改原始碼。計畫準備好之後會呈現給你，由你決定是否批准。
如果每次都還要說「先提案」很麻煩，可以在專案設定中把這個模式設為預設。
將 settings.json 的 permissions.defaultMode 指定為 "plan"
修改越複雜，第一步如果方向錯了，之後要重做的代價就越大。Plan Mode 就是防止這種重做的保險。
5. Permission Modes — 設計好停在哪裡
Claude Code 的模式分成幾種：有每次編輯檔案或執行指令都會詢問確認的，也有某種程度上自動執行的。預設情況下，除了讀取之外的所有操作都會詢問確認。
在每天的實作工作中，「檔案編輯自動進行，其他操作需要確認」這樣的平衡最容易掌控。只要在設定檔中寫下這行，就能把這個平衡設為預設：
將 settings.json 的 permissions.defaultMode 指定為 "acceptEdits"
✗ 因為「確認很麻煩」就用一個停用所有檢查的模式
◯ 只自動化檔案編輯，破壞性操作（例如 force push 或等同正式環境的部署）仍保留確認
以我的經驗，隨便把這個設成「全自動」的人，之後往往會被意料之外的變更嚇到。等你習慣了希望它在哪裡停之後，再逐步放寬設定就好。
6. Context Management — 經常打掃房間
如果讓同一個對話無限期持續下去，不相關的歷史紀錄就會留在 context 裡，浪費 token，回應的準確度也會下降。
切換到不相關的任務時，輸入 /clear 把對話清乾淨就好，就這麼簡單。如果之後還想回到某段對話，先用 /rename 幫它取個名字再清除，之後就能隨時叫回來，不會迷路。
✗ 從早到晚都用同一個對話，昨天的無關話題還殘留在裡面
◯ 在任務邊界使用 /clear，需要的話先用 /rename
如果第 3 個設定（Sub-agents）是用來「把研究隔離在單一任務之內」，那麼第 6 個設定就是用來「把任務之間的內容隔離開來」。兩者都做到，才能真正保持 context 乾淨。
7. 技能 — 把步驟放在對話之外
如果一直把步驟加進 CLAUDE.md，檔案本身會越來越臃腫，每次 session 開始時要讀取的內容也會增加。更糟的是，平常不會用到的步驟，在執行無關任務時也會一直被讀取。
這就是技能（Skills）派上用場的地方。只要把 SKILL.md 放在 .claude/skills/ 底下，它就會在需要的時候才被讀取。如果說 CLAUDE.md 是「每次都要讀的記憶」，技能就是「需要時才翻開的手冊」。
舉例來說，像 PR review 步驟或資料庫 migration 步驟這類不常用但又很長的流程，就把它們從 CLAUDE.md 移到技能那一側。日常對話保持輕量，需要的時候再付出閱讀成本。
總結 — 少了這 7 個會怎樣？
重點整理如下。
沒有 CLAUDE.md，Claude 每次都得從零開始猜。沒有 hooks，已決定的規則就只是「請求」，隨時可能被打破。沒有 sub-agents 和 /clear，context 會被污染，準確度下降。沒有 Plan Mode，複雜的修改就得承擔重做的風險。Permission Modes 設得太隨興，就會失去攔下意外操作的煞車點。沒有技能（Skills），CLAUDE.md 只會越來越臃腫。
反過來說，這也是一個「沒設定這 7 項就虧大了」的故事。如果你讀到這裡，卻連 CLAUDE.md 都還沒建立、/clear 一次都沒用過，那這正是你的成長空間。
不需要一次全部做完。先從今天的工作開始，試試 CLAUDE.md 和 Plan Mode 就好。光是這樣，你就能立刻感受到與原始狀態的差異。
我在付費 Note「Claude Code Complete Guide」中，更有系統地整理了更深層的設定，以及實務上常見的陷阱。想知道這 7 個之後還有什麼內容的人，歡迎到這裡看看。
