Claude Code今天上線了一個新功能，叫auto mode（自動模式）。它的邏輯挺有意思：讓AI替你決定是否授權執(zhí)行操作，而不是像以前那樣每次都要你手動點確認。

聽起來省事，但有個細節(jié)讓人心里打鼓——這個"把關"的AI，和正在幫你寫代碼的AI，是同一個公司造的。

自動模式怎么工作：一個AI干活，另一個AI盯梢

根據(jù)官方文檔，auto mode的核心是一套雙層架構。你的主會話可以用Claude 3.7 Sonnet、Opus 4這些模型，但審查你操作的"分類器"固定用Claude Sonnet 4.6。

這個分類器會在每個動作執(zhí)行前介入，檢查三件事：動作是否超出你交代的任務范圍、目標基礎設施是否被標記為可信、以及是否被文件或網(wǎng)頁里的惡意內(nèi)容誘導。如果判定有風險，操作會被攔下。

用戶可以在終端運行claude auto-mode defaults查看完整的規(guī)則集。JSON輸出很長，我挑幾條有代表性的：

允許列表里包括pip install -r requirements.txt這種常見操作，也允許讀取~/.bashrc、~/.zshrc這些shell配置文件。危險操作如curl | bash管道安裝、直接修改/etc/hosts、向node_modules寫入文件，默認會被攔截。

規(guī)則總數(shù)47條，覆蓋文件系統(tǒng)、網(wǎng)絡請求、命令執(zhí)行、Git操作四大類。用戶可以在此基礎上疊加自己的自定義規(guī)則。

prompt injection的老問題：非確定性防御的軟肋

Simon Willison在博客里寫得很直白：「我對依賴AI做prompt injection防護這件事始終存疑，因為它們本質上是非確定性的?！?/p>

這話指向一個尷尬的現(xiàn)實。分類器也是LLM，它判斷"這個操作是否符合用戶意圖"時，用的是和你主模型類似的概率推理。文檔自己也承認：「如果用戶意圖模糊，或者Claude對你的環(huán)境上下文不足，分類器仍可能放行有風險的操作?！?/p>

更具體的風險已經(jīng)出現(xiàn)過。就在今天早上，LiteLLM遭遇了供應鏈攻擊——攻擊者通過未固定版本的依賴注入惡意代碼。而auto mode的默認規(guī)則允許pip install -r requirements.txt，這意味著如果requirements.txt本身被篡改，分類器不會把它識別為越界操作。

畢竟，從分類器的視角看，"安裝項目依賴"完全在任務范圍內(nèi)。

替代方案：確定性沙箱 vs AI守門員

Willison的偏好很明確：「我還是希望編碼代理默認跑在健壯的沙箱里，用確定性方式限制文件訪問和網(wǎng)絡連接。比起這種基于prompt的防護，我信任前者多得多?！?/p>

這個對比很尖銳。沙箱的權限控制是硬編碼的——能讀哪些目錄、能連哪些域名，規(guī)則寫死，繞過成本極高。而AI分類器的決策是上下文相關的，同一個操作在不同對話里可能得到不同判定。

但Anthropic顯然在押注另一條路。把權限決策也納入AI的能力邊界，讓系統(tǒng)更"懂"你在做什么，而不是機械地按白名單執(zhí)行。代價是引入了新的不確定性層。

一個值得玩味的細節(jié)：分類器固定用Sonnet 4.6，哪怕你主會話用更貴的Opus 4。這可能是成本考量，也可能是4.6在這個特定任務上經(jīng)過了更多對齊訓練。Anthropic沒解釋原因。

auto mode現(xiàn)在作為--dangerously-skip-permissions的替代方案推出。后者是舊版的"全自動駕駛"，幾乎不設防。新方案至少多了道審查，但這道審查本身可靠嗎？

如果你今天就在用Claude Code，會打開auto mode，還是繼續(xù)手動點每一個確認按鈕？