Area 1 · Claude Code 配置實務

真考高頻失分區：配置機制選擇／review 配置／測試生成／iterative refinement／CI 旗標／MCP 整合｜讀完 → Drill 1（快檢 10 + 情境 30）

1.1 配置機制選擇 — 先問「強制還是建議」

五個機制解五種不同問題。第一個判斷永遠是：這條規則能不能容忍被違反？

這條 guidance…
│
├─ 絕不能被違反（compliance / 金流 / 破壞性操作）？
│    ├─ 是「擋某個工具呼叫」 → settings permissions（deny/ask 規則）
│    └─ 要「檢查內容再決定/轉換」 → hooks（PreToolUse 擋、PostToolUse 轉換）
│
└─ 是建議/慣例（違反了頂多品質差）？
     ├─ 全專案、每個 session 都該知道 → CLAUDE.md
     ├─ 只有某類檔案適用          → .claude/rules/ + paths glob（省 context）
     └─ 多步驟流程、偶爾才用       → Skill（被呼叫才載入）

機制	給什麼	何時載入	強制力
CLAUDE.md	事實性/持續性規則（build 指令、慣例、架構）	每 session 開始全載入（沿目錄樹往上）	❌ context，「盡量遵守」
.claude/rules/ + paths	只適用部分檔案的規則	有 `paths` → 碰到 match 檔案才載入	❌ 同上
Skills	多步驟程序/工作流	被呼叫才載入 body	部分（`allowed-tools` 預核工具）
Hooks	「不論 Claude 怎麼決定」都要執行/擋下	事件觸發跑 callback	✅ 真強制
settings permissions	工具/檔案/網域存取控制	每次工具呼叫前評估	✅ 真強制，deny 最大

最大陷阱：把「寫進 CLAUDE.md（用大寫、放最前面）」當成能擋住行為的選項。官方原文："To block an action regardless of what Claude decides, use a PreToolUse hook instead."　CLAUDE.md 和 rules 是塑造行為的 context，不是 enforcement 層。

補充規格：CLAUDE.md 支援 @path import——相對路徑以「含 import 的那個檔」為基準、最大遞迴 4 層、code span 內的 @ 不解析。官方建議 CLAUDE.md 保持精簡（巨檔 → 拆進 .claude/rules/ 主題檔）。

例題走一遍：測試檔慣例散落 12 個 service

題：migration SQL 檔散落各 service 的 migrations/，要統一慣例、編輯到就自動套用、context 成本最低。

推理：①「自動套用」→ 刪掉 Skill（要人叫）；②「慣例」不是 compliance → 不用 hook；③「只有某類檔案」→ root CLAUDE.md 常駐太貴、per-dir CLAUDE.md 要同步 12 份；→ .claude/rules/ + paths: ["**/migrations/*.sql"]，match 才載入。

但若題目改一個字：「migration 檔絕不允許出現 DROP TABLE」→ 這是 must-never → PreToolUse hook 檢查 Edit/Write 內容，rules 檔擋不住。

1.2 Permission modes — 六個，背行為差異

Mode	不問就能做	典型場景
`default`（別名 manual）	只有讀	一般互動
`acceptEdits`	讀 + 檔案編輯 + 常見檔案系統指令（mkdir/touch/rm/mv/cp/sed），限 working dir / additionalDirectories 內	信任的編輯流程
`plan`	只有讀（唯讀探索）	改動前探索、出計畫等核准
`auto`	全部，但有背景 classifier 安全檢查	需 admin 開啟 + 新模型
`dontAsk`	只有 allow 清單內 + 內建唯讀指令；其餘直接 deny、不會問	CI / 腳本（沒有人能回 prompt）
`bypassPermissions`	全部（含 protected paths）	只限隔離容器 / VM

三個必背事實：① 除 bypass 外，所有 mode 對 protected paths（.git、.claude、.bashrc、.npmrc…）都強制 prompt，allow 規則也蓋不掉；② rm -rf /、rm -rf ~ 在所有 mode 含 bypass 都有 circuit-breaker prompt；③ --dangerously-skip-permissions = bypassPermissions 的旗標形式。

CI 題陷阱：「pipeline 沒有人回 prompt」的正解是 dontAsk（不在 allow 清單 → 自動拒絕、流程繼續可控），不是 bypassPermissions（全放行 = 把 CI runner 的一切交給 agent，官方限定隔離環境）。兩者都「不會卡住」，差在預設方向：一個 deny、一個 allow。

1.3 Settings 層級與規則評估

優先序（高 → 低）                     permission rules 例外
Managed（企業，誰都蓋不掉）           ├ 不是覆蓋，是 merge
  ↓ CLI 參數                          ├ 任一層的 deny 永遠贏
  ↓ .claude/settings.local.json（個人）├ 高層 allow 蓋不掉低層 deny
  ↓ .claude/settings.json（team 共用） └ 評估順序固定：
  ↓ ~/.claude/settings.json（user）        deny → ask → allow（先中先贏）

先中先贏、與具體程度無關：deny Bash(git push *) + allow Bash(git push origin dev) → 照樣 deny（deny 先評估）。
deny 裡放裸工具名（Bash）= 整個工具從 context 移除；Bash(rm *) = 保留工具、擋特定呼叫。
Hook 與規則的位階：hook 的 block 優先於 allow 規則；但 settings 的 deny 連 hook 的 allow 都蓋掉。一句話：deny > hook > allow。
MCP 整合：project .mcp.json 進 repo team 共用｜~/.claude.json 個人；secrets 走 ${ENV_VAR} 展開絕不進 commit；server 連線時 tools 一次全部 discover。

1.4 CI / Headless CLI 旗標

旗標	作用	考點鑰匙
`-p` / `--print`	非互動，印完就退	「CI 卡住等輸入」
`--output-format`	text / json / stream-json（只有這三個值）	選項出現 markdown/xml = 假值
`--json-schema`	最終輸出強制符合 schema	「下游機器讀」和 json 搭配
`--max-turns`	回合上限，預設無上限，到頂 exit error	「防 runaway / 爆預算」成對出現
`--max-budget-usd`	美金成本上限，到頂即停	「防 runaway / 爆預算」成對出現
`--permission-mode`	六 mode 擇一	CI 用 `dontAsk`
`--allowedTools` / `--disallowedTools`	工具 pattern 清單	review agent 限唯讀
`--setting-sources`	載入哪幾層 settings（user,project,local）	「不信任 fork 的 project settings」
`--mcp-config` + `--strict-mcp-config`	指定且只用該 MCP 設定	CI 環境鎖定 server 來源

例題走一遍：nightly review job 的完整命令長相

claude -p "Review yesterday's merged changes" \
  --output-format json --json-schema ./findings-schema.json \
  --permission-mode dontAsk \
  --allowedTools "Read" "Grep" "Glob" "Bash(git log *)" "Bash(git diff *)" \
  --max-turns 30 --max-budget-usd 5.00

每個旗標對一個考點：非互動（-p）、機器可讀（json+schema）、無人回 prompt（dontAsk）、least privilege（唯讀工具）、防 runaway（兩個上限）。考題常抽掉其中一個問「還缺什麼」。

1.5 Hooks — 位置決定能力

user prompt ──▶ [UserPromptSubmit]* ──▶ Claude 決定呼叫工具
                                            │
                              [PreToolUse]* ─┤ exit 2 = 擋下（工具不執行）
                                            ▼
                                        工具執行
                                            │
                              [PostToolUse] ─┤ 只能轉換結果/補 context
                                            ▼   （動作已發生，擋不了）
                                     結果進 agent context
Claude 想結束 ──▶ [Stop / SubagentStop]* ── exit 2 = 不准停、繼續做
context 快滿 ──▶ [PreCompact]*            （* = 可 block 的事件）

Exit code：0 成功｜2 blocking（只對 pre-action 事件有效）｜其他非零 = non-blocking error。
設定位置：settings.json 的 hooks 欄位（各層級皆可）；Skill/Agent frontmatter 也能掛 scoped hooks。

機制陳述為假的固定款：「用 PostToolUse hook 阻止危險指令執行」——PostToolUse 跑的時候動作已經發生，不可能 block。要擋 → PreToolUse。反過來「格式正規化」放 PreToolUse 也錯位：結果還不存在，要 PostToolUse。

1.6 CI Review 配置與測試生成

Review 配置三件套（objective 原文就是這三件）

載入 project 標準：CI instance 是全新 context，要餵 CLAUDE.md（慣例/fixture/review 準則），否則它拿通用標準審你的刻意設計。
限制工具：review 只需要讀 → --allowedTools 只給 Read/Grep/Glob（+ 唯讀 git）。不給 Edit/Write = review agent 不可能改壞東西。
結構化輸出：--output-format json + --json-schema，讓 bot 能 parse 成 PR comments / gate 條件。

測試生成品質三件套

給既有測試檔當 context —— 學專案的測試風格與結構，而不是憑通用習慣生成。
定義 fixture 慣例 —— 測試資料怎麼建、放哪、怎麼共用。
給區分準則：behavioral test（測邊界行為、錯誤路徑）vs trivial assertion（assert getter 回傳值）。沒有準則，模型會大量生成後者衝覆蓋率。

辨識訊號：「生成的測試都很淺/瑣碎」→ 給 criteria + 既有測試當範例；不是「要求更多測試」（更多垃圾）、不是換模型（無關升級）。

1.7 Iterative refinement 三機制

Concrete input/output examples：具體「輸入 → 期望輸出」範例 > prose 描述（prose 被不一致解讀 → 格式漂移）。
Targeted feedback on specific failures：指著具體失敗點回饋（「第 3 段表格欄位順序錯」），不是「再改好一點」。
Batched issue descriptions：相關問題打包一次給（consolidated evaluation）——一條一條擠牙膏會來回震盪、每輪重新理解 context。

辨識訊號：「格式一直漂」→ examples；「回饋很模糊沒收斂」→ targeted feedback；「改了東壞了西」→ batch 相關 issues。選項出現 fine-tune / 「MUST」大寫措辭 / 換模型 = 陷阱。

討論題（讀書會 session 用 — 先自己想，再和夥伴或你的 Claude 互相挑戰）

deny Bash(git push *)（user 層）+ allow Bash(git push origin main)（project 層）+ 一個 PreToolUse hook 回 allow——最後 git push origin main 會怎樣？為什麼？
「CLAUDE.md 寫了不准刪檔，agent 還是刪了」——列出三種真正能擋住的做法，各自的適用差異？
CI 上想跑 review 又怕 fork 的 PR 挾帶惡意 project settings——哪兩個旗標組合起來處理？
dontAsk 和 bypassPermissions 都「不會卡 prompt」，什麼情境下選錯會出大事？
為什麼 --max-turns 預設無上限這個事實在考題裡重要？