歡迎來到 Claude Code Deep Dive。

這一集我們要講的是 settings 和 scopes。這題看起來很基礎，但實際上是整個團隊配置能不能穩定運作的分水嶺。很多人一開始學 Claude Code，會先注意到功能有沒有打開，卻沒有先問一個更重要的問題：這個設定，應該放在哪一層？誰來負責？誰可以改？誰不該碰？

如果這三個問題沒有先想清楚，團隊很快就會出現兩種狀況。第一種，是大家把所有東西都寫進同一份設定檔，最後 shared config、個人偏好、臨時實驗全部混在一起。第二種，是大家各自改各自的 scope，結果同一個 repo 裡面有好幾份彼此打架的決策。表面上看起來很有彈性，實際上是 policy drift。

所以這一集的目標很單純：把 settings 講成一個「位置決策」問題，而不是一個「數值調整」問題。Settings define where configuration lives and who owns it。你只要記住這一句，後面很多混亂都可以拆開。

先講最核心的模型。Claude Code 的設定，最少可以想成四個 scope：user、project、local、managed。

User scope，是跨專案的個人預設。這一層適合放個人習慣，而且這些習慣通常不應該綁死某一個 repo。比如你自己想用什麼預設工具、什麼閱讀節奏、什麼偏好，這些通常屬於 user scope。

Project scope，是 repo 共用的預設。這一層的責任是讓整個團隊進到同一個專案時，看到的是同一套起點。像是 `.claude/settings.json` 這類可以簽入版本控制的設定，就屬於這種思路。它不是個人偏好，它是專案共識。

Local scope，是機器或暫時性的設定。這一層的關鍵詞不是「方便」，而是「不要污染共享狀態」。你今天在這台機器上做測試，或是暫時要調一個不想簽入的參數，就應該放 local。這樣你可以快，但不會把暫時狀態誤當成團隊決策。

Managed scope，是 org policy。這一層的意思很直接：這不是 repo 自己說了算。當你看到 managed，你就要知道這是組織級別的控制。它存在的目的，就是避免每個專案各自亂長，最後整個團隊沒有共同底線。

這四層裡面，最容易出問題的，是把 local 當成 shared，或把 project 當成 personal。這兩種錯誤都很常見。前者會讓臨時實驗變成正式規則，後者會讓 repo 共識被個人偏好覆蓋。等到新成員進來，根本不知道到底哪一份才是真正應該遵守的設定。

所以 settings 的第一個實務原則，不是「怎麼寫」，而是「先判斷 owner」。你要先知道這個值是誰擁有的，再決定寫進哪個 scope。這個順序不能反。因為一旦你先寫，再回頭猜 scope，通常就已經寫錯了。

再來講邊界。Settings 很重要，但 settings 不能取代 policy writing。它也不能把 local hack 變成安全做法，更不能消除 code review 的必要。也就是說，settings 是配置工具，不是治理的全部。

這裡有一個很值得團隊反覆提醒自己的點：不要把「可以改」誤認成「應該改」。user scope 可以改，不代表應該拿來放 repo policy。local scope 可以改，不代表應該把它帶進 production。managed scope 可以控制，不代表你在 repo 裡就可以忽略它。

如果你想把這件事講給團隊聽，最簡單的方法就是用一條判斷線。第一問，這是不是跨 repo 的個人習慣？如果是，考慮 user。第二問，這是不是 repo 共享預設？如果是，考慮 project。第三問，這是不是只對這台機器或這次測試有效？如果是，考慮 local。第四問，這是不是 org policy？如果是，讓 managed 來管。

這條線看起來很簡單，但它能避免很多低級錯誤。因為大部分設定漂移，不是來自技術太難，而是來自責任沒有分清楚。

講兩個常見反模式。

第一個反模式，是把 local override 提交進 shared config。這種做法最常見的理由是「先跑起來再說」。問題是，一旦你把臨時值簽進 repo，下一個人就會以為那是標準答案。久了之後，整個團隊都在維護例外。

第二個反模式，是同一個決策在多個 scope 重複出現。比如說你在 user、project、local 都設了類似的值，最後任何人都不知道是哪一個真的生效。這種狀況不是彈性，是難以驗收。當你無法快速說出誰在生效，系統就已經失去可治理性。

那正確做法是什麼？還是回到團隊設計。

Research 負責驗證 scope 的官方語意，確認哪個 scope 的行為到底怎麼生效。Architecture 負責把 file taxonomy 定下來，讓團隊知道 `.claude/settings.json`、`.claude/settings.local.json`、`CLAUDE.md`、rules、permissions 各自的位置。Content 負責把這些規則寫成能教人的內容。Instructor 負責把口條穩住，讓每一次講解都能回到同一個判斷邏輯。Distribution 負責把這些設定和教學資料維持一致，避免網站、講義、音檔彼此打架。

你會發現，這裡真正重要的，不是某個單一檔案，而是整套分層後的責任感。當 team 真的知道誰管 user，誰管 project，誰管 local，誰管 managed，settings 才會變成可持續的東西。

如果要把這一集收束成三個 takeaway，我會這樣說。

第一，先知道 owner，再改設定。不要先改完再回頭猜。

第二，keep local local。臨時實驗就是臨時實驗，不要把它升級成共識。

第三，shared config 要明確。只要是團隊共用的東西，就要讓大家一眼看得懂它屬於哪個 scope。

如果你能把這四個 scope 分清楚，你就不只是會改設定，你是在建立團隊的配置秩序。這就是這一集真正要帶走的東西。

下一集，我們會進到 permissions，看看當設定之外還需要安全邊界時，該怎麼把 allow、ask、deny 和 permission modes 一起設計起來。