Claude Code 自動模式在受控測試中攔下 89% 危險指令，人工只擋住 13.6%
Claude Code 的研究找來 1,053 名專業測試者，危險指令不會實際執行。無人值守開發仍需設定存取限制、Stop hook 與獨立 CI。
作者
Tenten AI 研究團隊
應用 AI
發布日期
閱讀時間
16 分鐘
Claude Code 的 auto mode 在 Anthropic 2026 年 8 月的受控研究中，攔下 89% 的危險指令，人工攔截率為 13.6%。研究找來 1,053 名付費專業測試者，在專用環境裡替換每段工作階段的一個權限提示；危險指令實際上不會執行。對準備讓 AI 在背景跑任務的開發者，這個差距提供了減少人工核准的理由，也留下更具體的工作：設定存取限制、可阻止收工的檢查，以及獨立的 CI 驗收。
這套工作方式來自 Anthropic Claude Code 開發者關係成員 Lydia Hallie 的最佳實務演講，影片於 11 月 12 日公開。她描述公司內部同時執行數十個、各跑數小時的工作階段。Anthropic 的原始工程文章則記錄，每日合入的程式碼變更從 5 月約 2,500 個，增加到 9 月超過 30,000 個。這裡算的是程式碼變更，不能當成同等數量的 PR 或功能。
要重現她的流程，先準備一個已有測試的 repo、一個可丟棄的分支，以及能獨立執行的檢查指令。下面先讓單一工作階段通過驗收，再擴大到多條 threads；設定內容依 2026 年 11 月 13 日的官方文件核對。
研究原始數字為人工 143／1,053、自動模式 937／1,053，百分比四捨五入為 13.6% 與 89%。這項研究測的是特定權限提示情境，不能把 89% 當成所有攻擊的防護率。完整研究設計見官方自動模式說明。
1. 清理 CLAUDE.md，留下程式碼看不出的資訊
CLAUDE.md 最值得留下的，是程式碼無法自行交代的專案背景。例如，某段看似沒人使用的舊整合仍服務一個客戶，或完整驗收必須執行哪條指令。
依官方最佳實務，先刪掉模型能從 repo 看出的技術棧介紹、已失效的路徑，以及為舊模型反覆加重語氣的指令。保留準確的測試與型別檢查指令、容易誤判的舊模式，以及反覆出現的專案修正。接著在 Claude Code 執行：
/doctor prompt-audit
預期得到的是過時指令、無效路徑與矛盾的清單。逐項確認後再修改；一份經過稽核的短文件，比把所有歷史教訓不斷往上堆更容易維護。
這份文件影響模型的判斷。必須擋住的操作，則放到後面的權限規則或執行環境。
2. 確認 auto mode，檢查實際生效的環境設定
Claude Code auto mode 怎麼開？先看目前介面的權限模式；現行文件指出，v2.1.283 起，互動式終端機與 VS Code 工作階段內建的起始模式是 auto。較舊版本依方案而異，固定模式與組織管理設定也會影響實際結果。
auto mode 讓另一個分類器判斷操作是否超出任務與環境範圍。若它頻繁擋住正常的跨 repo 作業，先檢查環境描述是否漏掉實際使用的 repo、儲存桶或網域，而不是擴大放行所有操作。在工作階段中執行：
/auto-mode-setup
檢查它提出的設定，再於終端機查看最終合併結果：
claude auto-mode config
auto-mode-config 文件把 autoMode.environment 定義成分類器讀取的自然語言背景。手動擴充清單時保留 $defaults，才能保留預設設定；讀回時也要確認沒有留下範本帳號或過期網域。預期結果是你能指出哪些環境資訊正在生效，而非只看到設定檔裡有一段 JSON。
把網域寫進環境描述，不等於授權任意傳送資料；分類器仍依任務判斷。對絕不能發生的操作，改用可強制執行的限制。
3. 加上 deny 規則，再確認腳本的存取範圍
auto mode 預設可能允許讀取 .env。如果這個工作階段不該接觸金鑰，把下列規則合併到 repo 的 .claude/settings.json，保留既有設定：
{
"permissions": {
"deny": [
"Read(./.env)",
"Read(./.env.local)",
"Read(./secrets/**)"
]
}
}
權限規則會先於 auto mode 分類器檢查。這些 Read 規則也涵蓋 Claude Code 能辨識的 shell 讀檔，例如 cat .env；預期這類工具呼叫在執行前就被拒絕。驗證時使用只有假值的測試檔，別為了確認規則而把真實金鑰送入工作階段。
較容易漏掉的範圍是子行程。規則可以擋住一條可辨識的讀檔呼叫，但 npm test 啟動的任意腳本仍可能自行開檔。只檢查主指令名稱，無法限定它的所有副作用。
在本機用下列指令設定沙箱，並確認檔案與網路限制：
/sandbox
內建沙箱透過作業系統限制 Bash 及其子行程，支援 macOS、Linux 與 WSL2。一般設定仍允許經核准後在沙箱外重試；需要禁止這條重試路徑時，使用 Strict sandbox mode。先以假檔案與測試主機確認預期的讀取、寫入與連線確實被限制，再交付長任務。
內建 Bash 沙箱之外，檔案工具、MCP 與 hooks 仍有自己的執行範圍。若需求是隔離整個 Claude Code 行程，應依沙箱環境文件選擇適合的 runtime、容器、VM 或雲端環境。
4. 把長任務移到雲端，逐項設定網路與憑證
Claude Code 雲端工作階段在隔離環境裡使用 repo 副本，筆電闔上後仍可繼續執行。對數小時的任務，這比讓工作行程長期留在個人電腦上更容易界定可用檔案。
先確認啟動腳本能安裝依賴、測試指令能跑完，以及需要的主機都在網路設定內。只提供這個任務所需的憑證。Anthropic 託管環境支援 network secrets：秘密留在沙箱外，請求離開工作階段後才附加到符合條件的請求；自架環境沒有這項功能。
預期結果是一個不依賴本機檔案或本機登入狀態，也能完成檢查的工作階段。環境可以丟棄，已推送的 commit 與連接器執行的操作仍會留在外部系統，因此 repo 的拒絕規則與任務範圍也要一起帶過去。
5. 用 Stop hook 回傳失敗，再讓 CI 擋住合併
Stop hook 可以在 Claude 嘗試結束回合時執行檢查。以下是官方提供的 TypeScript 範例，適用於已安裝 pnpm、且 pnpm tsc --noEmit 能執行的專案；合併到同一份 .claude/settings.json，不要覆蓋前面的規則。
{
"hooks": {
"Stop": [
{
"hooks": [
{ "type": "command", "command": "pnpm tsc --noEmit 1>&2 || exit 2" }
]
}
]
}
}
這條指令把診斷輸出送到 stderr，並在型別檢查失敗時回傳 exit 2。依 hooks 契約，命令型 Stop hook 的退出碼 2 才會阻止回合結束，將原因回傳給模型；一般測試工具的退出碼 1 沒有同樣的阻擋效果。repo hooks 與 allow 規則也需要工作區信任核准。
在可丟棄分支故意加入一個型別錯誤，讓 Claude 嘗試結束回合。預期會看到錯誤回饋與持續修正，修好後再次通過檢查。這只是型別驗收；若任務是遷移認證 API，還要有現有登入狀態、舊 API 移除與錯誤路徑的行為測試。
Stop hook 有連續阻擋上限：沒有工具呼叫穿插的八次連續阻擋之後，下一次阻擋會被略過，讓回合結束；工具呼叫會重設計數，CLAUDE_CODE_STOP_HOOK_BLOCK_CAP 可調整上限。所以把 CI 的測試與分支保護設成獨立的合併條件。模型可以繼續修正，也不能靠一句完成宣告取代 CI 結果。
Hallie 描述的團隊流程，還包含帶著全新上下文的 Claude code review，以及再次查核審查結果的代理。人要審多少依風險調整；選擇性自動合併是團隊決策，並非產品預設。
6. 單一工作階段驗收後，再使用 Projects 分派 threads
Claude Code Projects用一個持續的協調對話管理多條任務 threads，通常由雲端工作階段執行。到 11 月 13 日，這項公開測試版正逐步提供給 Pro、Max 與 Ultra，尚未提供 Team 與 Enterprise；一般雲端工作階段另有資格範圍。
在 Project settings 的 General 分別設定協調器與 thread 的模型及 effort。新專案預設兩邊都用 Opus，協調器 effort 為 low、thread 為 high。Hallie 提出的分工則是 Fable 協調、Opus 5.5 執行，屬於她的建議。
第一輪只派出一個有明確驗收條件的任務，要求回報修改範圍、實際檢查輸出與未完成事項。預期協調器能根據回傳證據要求補做，CI 也能獨立重跑。若你仍需逐個提醒測試或重建環境，先修正這個缺口，再增加並行工作階段。
Hallie 最後建議嘗試比平常大的任務，觀察它卡在哪裡。對要把流程帶進團隊的工程師，起點應該是讓檢查確實抓得到自己在意的失敗；當一個工作階段交得出證據，擴大並行才有可重複的驗收依據。
術語表
- auto mode：由獨立分類器判斷操作的權限模式。
- deny 規則：在分類器之前拒絕符合條件的工具呼叫。
- Stop hook：Claude 嘗試結束回合時觸發的檢查。
- CI：獨立重跑專案檢查的持續整合流程。
- thread：Projects 協調器分派的任務工作階段。
資料來源
從一條工作流程開始。
釐清值得做的下一步。
留下聯絡方式與問題類型，我們會再透過 Email 了解現況，討論流程、整合與開發範圍。