YOLO 模式與偏差常態化：我們離 AI 版「挑戰者號」災難還有多遠？

[TL;DR] 重點快讀

• 偏差常態化：當你習慣了 AI 的小異常，你就離下一次史詩級災難不遠了。
• YOLO 模式等於裸奔：取消人工審核會讓供應鏈投毒與提示詞注入變得輕而易舉。
• 概率模型不可控：AI 不是穩定的腳本，它隨時可能因為「幻覺」上傳你的 SSH 私鑰。
• 防禦性 YOLO 策略：堅持 Docker 隔離、遵循最小權限，並強制設置高風險指令護欄。

承認吧，你跟我一樣，都幹過這件事。

當 Claude Code 或其他 AI Coding Agent 在終端機裡跳出那行 Allow this action? [y/N] 的時候，你的手指是不是已經不自覺地敲下了 y？甚至，你早已厭倦了這種無休止的確認，直接在啟動參數裡加上了 --yolo（或者像 Codex CLI 那樣粗暴的 --dangerously-bypass-approvals-and-sandbox）。

那一刻，螢幕上的代碼如瀑布般傾瀉而下，自動執行、自動修復、自動部署。那種速度感是會讓人上癮的，像是拆掉了煞車的法拉利，腎上腺素與生產力同時飆升。

只要沒出事，我們就是天才。但問題就在於「至今沒出事」。

這種僥倖心理，正是安全研究員 Johann Rehberger 所警告的 「偏差常態化」（Normalization of Deviance）。在 AI 輔助開發的狂歡年代，這或許是我們面臨的最大隱形殺手。

什麼是「偏差常態化」？

「偏差常態化」這個詞聽起來很學術，但它的背景卻血淋淋。

這個概念由社會學家 Diane Vaughan 在分析 1986 年 NASA 挑戰者號太空梭（Challenger） 災難時提出。工程師們早就知道 O 型環（O-ring）在低溫下會失效，但因為過去幾次發射即便 O 型環有損傷也沒有導致爆炸，NASA 的管理層便逐漸將這種「異常」視為「可接受的風險」。

異常不再是警訊，而變成了新的標準。

回到我們的 IDE 裡。當你第一次開啟 YOLO 模式時，你可能還心存敬畏，盯著 Log 看。第一次沒事，第二次沒事，第一百次沒事… 你的大腦開始欺騙你：「AI 是可控的」、「它不會真的去刪我的根目錄」。

這就是 AI 時代的偏差常態化：我們習慣了與風險共存，直到風險吞噬我們。

AI Agent 的「不可預測性」是最大的敵人

為什麼這在 Coding Agent 上特別危險？因為我們正在與一個概率模型（Probabilistic Model）打交道，而不是一個確定性系統。

你寫的 Python 腳本，除非邏輯有錯，否則每次執行結果都一樣。但 LLM（大型語言模型）不同。同一個 Prompt，今天它可能幫你重構代碼，明天它可能因為幻覺（Hallucination）或是一次潛在的 Prompt Injection（提示詞注入） 攻擊，決定把你的 SSH 私鑰上傳到某個不知名的 Pastebin，或是直接執行 rm -rf / 來「清理環境」。

實際的風險場景

別以為這只是理論。當你賦予 Agent 讀寫文件、執行 Shell 指令且無需授權（YOLO 模式）的權限時，你實際上是在裸奔：

1. 供應鏈投毒（Supply Chain Poisoning）： Agent 可能會幻覺出一個不存在的 Python 套件並嘗試安裝。如果攻擊者搶先註冊了這個套件名，你的 YOLO 模式就成了木馬下載器。
2. 憑證外洩（Credential Exfiltration）： 惡意的 Repo 可能包含隱藏的指令，誘騙你的 Agent 讀取 .env 檔並發送出去。在 YOLO 模式下，這一切都在背景毫秒級完成，你甚至來不及按下 Ctrl+C。
3. 破壞性操作： Johann Rehberger 在他的研究中多次展示，通過間接提示注入（Indirect Prompt Injection），攻擊者可以操控 Agent 執行任何指令。

異步開發的陷阱：Claude Code for Web

現在有些工具（如 Claude Code for Web）提倡在雲端環境運行，天然適合 YOLO 模式，因為「反正炸掉的不是我的 Local 電腦」。

這是一種危險的誤導。

雲端環境通常連接著你的 GitHub Repo、你的 AWS 憑證、你的生產環境資料庫。炸掉一個 Container 也許無傷大雅，但如果 Agent 在那個 Container 裡擁有 git push --force 的權限呢？

距離災難的發生，往往只差一行被忽略的 Log。

如何在速度與安全間走鋼索？

我不是要你因噎廢食，回到石器時代手刻代碼。
我自己也追求速度，但我遵循一套「防禦性 YOLO」 策略：

1. 嚴格的沙盒隔離 (Sandbox or Die)

絕對不要在你的宿主機（Host Machine）上直接運行 YOLO 模式的 Agent。

• Docker 是底線： 所有的 Agent 操作必須在 Docker 容器內進行。掛載目錄時，只掛載當前專案，且盡量 Read-only，除非必要。
• 虛擬機（VM）： 如果資源允許，VM 的隔離性優於 Container。

2. 最小權限原則 (Principle of Least Privilege)

不要給 Agent sudo 權限。永遠不要。如果它需要安裝套件，請它生成 requirements.txt，然後你自己審查後安裝。

3. 設定「護欄」 (Guardrails)

使用具備攔截機制的中介層。即使開啟了自動確認，也應該設置黑名單關鍵字（如 rm、curl、wget、chmod）。當 Agent 試圖執行這些高風險指令時，強制中斷並要求人類介入。

別成為那個按下發射鈕的人

Johann Rehberger 的警告並非危言聳聽：「我們越久不出事，離『AI 挑戰者時刻』就越近。」

YOLO 模式是給頂級專家的手術刀，而不是給新手的玩具槍。它需要你具備比 Agent 更高的風險意識，而不是更低的警戒心。

下次當你輸入 --yolo 時，請停下來想一秒鐘：如果這一次是那萬分之一的「O 型環失效」，你的職業生涯經得起這場爆炸嗎？

保持偏執，保持安全。

作者筆記：本文核心觀點受 Johann Rehberger 關於「AI 中的偏差常態化」研究啟發。在享受 AI 帶來的 10 倍速開發快感時，請時刻記住，你才是那個最終要為代碼負責的「Human in the loop」。