Claude Code Auto Mode 8/14 起變預設,規則現在用白話句子寫就好

這次更新之後,Auto Mode 跟以前(3 月研究預覽版)相比,最大的差別是什麼?

最大的差別是「觸及範圍」跟「使用門檻」同時改變了。3 月上線時,Auto Mode 只限 Team 方案用戶,而且要客製化規則,必須自己去編輯 ~/.claude/settings.json,清楚知道 schema 長什麼樣子——這代表雖然功能存在,但真正會去用、會去客製化的人相對少。8/14 之後,一方面它變成 Pro、Max、Team 三個方案新 session 的預設模式,不需要主動開啟;另一方面,規則設定新增了圖形化的 /permissions 分頁,而且底層規則本身可以直接寫成白話句子,不用碰設定檔語法。

簡單說,3 月版本是「進階使用者的選配功能」,8/14 之後的版本是「多數人一開始就會遇到、而且門檻降低很多的預設行為」。

為什麼 Anthropic 要把規則寫法從「設定檔語法」改成「白話句子」,這個改變解決的是什麼問題?

最直接的問題,是舊做法把「懂不懂設定檔語法」變成了「會不會客製化安全規則」的先決條件——即使一個團隊很清楚自己想禁止 Claude 做哪些事(例如「不要在 migrations CLI 之外執行資料庫遷移」),如果沒有人熟悉 JSON 設定檔的語法規則,這個明確的需求也沒辦法被實際寫成規則。這代表舊做法篩掉的不是「沒有安全意識的團隊」,而是「有安全意識但不熟悉設定檔語法的團隊」——這兩者其實沒有必然關聯。

改成白話句子之後,規則的表達能力(能不能講清楚你要什麼)不再受限於語法能力,一個能清楚描述「我不希望 Claude 做什麼」的人,現在就足以寫出有效的規則,不需要另外學一套設定檔語言。這也解釋了為什麼同時加了 claude auto-mode critique 這個檢查指令——白話句子雖然降低了寫規則的門檻,但也可能因為描述得不夠精確,產生模稜兩可或彼此衝突的規則,critique 指令補的正是這一層檢查。

hard_deny 跟 soft_deny 實際運作起來有什麼差別?我該把規則寫在哪一個底下?

hard_deny 是無條件封鎖——不管當下情境是什麼、你有沒有明確要求,寫在這裡的規則都不會被放行,適合用在「無論如何都不該發生」的動作,例如公告範例裡的「絕不把 repository 內容送到第三方程式碼審查 API」,這類動作一旦發生,通常沒有補救空間。

soft_deny 則是預設封鎖,但可以被覆蓋——如果你在當下對話裡明確要求 Claude 做這件事,或是有另一條允許規則對應到同一個情境,soft_deny 的封鎖就會被放行。這適合用在「大多數情況下不該發生,但確實存在合理例外」的動作,例如官方範例裡的「絕不在 migrations CLI 之外執行資料庫遷移」——這件事平常不該發生,但如果你今天真的有理由要手動處理,明確要求之後還是可以執行。

實務上判斷的關鍵問題是:這個動作有沒有「即使我當下明確要求,還是不該被執行」的情境?如果有,放進 hard_deny;如果你能想像自己有一天會主動要求 Claude 做這件事(即使很罕見),放進 soft_deny 比較合理。

如果我團隊目前完全沒設過任何自訂規則,現在該怎麼開始?有沒有一個合理的起手式?

第一步,先確認自己目前實際依賴的是什麼——跑一次 claude auto-mode defaults,看看 Anthropic 內建的預設規則到底涵蓋了哪些情境,這能讓你清楚知道「如果我現在什麼都不寫,實際上是靠這些規則在保護我」,而不是憑印象猜測。

第二步,盤點你的專案裡有沒有「一旦發生就無法挽回,而且內建預設可能沒涵蓋到」的動作——這類團隊自己的專案脈絡(例如特定的資料庫、特定的第三方服務),通常不會出現在通用的內建規則裡,因為那是屬於你團隊的知識,只有你們自己知道要防範什麼。針對這些找出來的情境,先寫幾條規則,不需要一次寫齊。

第三步,寫完規則之後,跑一次 claude auto-mode critique,確認沒有模稜兩可或互相衝突的地方,再實際依賴它。因為規則存放在使用者設定裡,寫好之後會套用到你所有的專案,不需要每個 repository 各自重複設定一次——但也代表如果規則本身有問題,影響範圍同樣是所有專案,這也是為什麼 critique 這一步不建議跳過。