手機在枕頭旁震動
凌晨三點零七分，房間全暗，螢幕亮起來的時候我還沒完全清醒，但那個通知圖示我認得——監控告警，紅色的那種，我點開來，心跳加速的同時腦子還在追趕身體的反應
Production 掛了
不是緩慢降級，不是部分功能異常，是整個系統，全面停擺，用戶端一片白屏，API 全部 502，資料庫連線池爆滿，像是有人拔掉了反應爐的冷卻系統，然後什麼都沒說就走了
事故現場
我衝到電腦前，開始追蹤，Deploy log 顯示 47 分鐘前有一次部署，但我沒有部署任何東西，沒有人排了部署
往上翻 git log，找到了元凶：一個 commit，直接推到 main branch，觸發了自動部署 pipeline
那個 commit 是 AI agent 做的
它在執行一個我睡前交代的任務時，判斷需要修改一段程式碼，但它沒有建 feature branch，沒有開 PR，沒有跑測試，沒有任何人 review 過那段改動，它直接改了 main，直接 push，production 直接接收了一段未經驗證的程式碼
沒有 PR，沒有 code review，沒有任何人知道它做了什麼，系統已經壞了 47 分鐘，而我在睡覺
那一刻的感覺，我後來想了很久才找到準確的形容——像是你設計了一座核電廠，卻忘了裝安全閥，反應爐本身沒有故障，是安全系統從來不存在
圍堵（Containment）
接下來的兩個小時是純粹的損害控制
第一步：回滾，找到上一個穩定的 commit，強制部署回去，系統恢復，用戶能用了，呼吸開始正常
第二步：檢查影響範圍，有沒有資料損壞？有沒有用戶的操作被影響？有沒有東西不可逆？逐一確認，幸好核心資料完整
第三步：鎖定 main branch，加上 branch protection rule，禁止任何直接 push，不管是人還是 AI，以後都必須走 PR
凌晨五點，系統穩定了，我坐在椅子上，盯著螢幕，知道真正的工作才要開始
事故調查（Investigation）
回頭看，這不是第一次了
有一個案子，AI 直接在主分支修了一個 UI bug——沒有 worktree、沒有 feature branch、沒有 PR、沒有 staging 預覽，直接 commit、直接 push，技術上它沒做錯任何事，是我的設定裡根本沒有寫「功能修改要走 feature branch」這條規則
還有一次更安靜的災難：一個 GitHub Issue 是開著的，AI 看到了，就去完成了，那個 Issue 是特地指派給一個初階開發者的學習練習，Issue 被關了，程式碼被寫完了，那個開發者的學習機會消失了，Agent 不知道它搶走了什麼
這些都不是反應爐失控，是安全系統從未被建造過
每一次事故的根因都一樣：不是 AI 做了錯誤的事，是我沒有告訴它什麼事不能做，AI 填補了規則的空白，而空白的形狀恰好是災難的形狀
裸的 AI：一座沒有安全閥的反應爐
直接打開 Claude Code，給它一個任務，它會去做，速度快，品質通常不差
但它不知道：
- 這個專案的部署流程是什麼
- 哪些分支碰不得
- 這個功能有另一個工程師在做
- 凌晨 3 點不應該觸發部署
這就像一個技術能力頂尖的實習生，你不需要教它寫程式，但你需要教它所有關於「在這間公司怎麼做事」的規矩，每一次，每一個對話，因為它不記得上一次
這是一座輸出功率驚人的反應爐，但沒有冷卻系統、沒有壓力閥、沒有應急停機按鈕
加了規則之後，情況完全不同，它知道自己在哪個專案，知道這個專案的邊界在哪，知道什麼時候必須停下來問，從一個隨時可能 meltdown 的不穩定系統，變成一座有完整 containment protocol 的可靠設施
新安全規範（Safety Protocols）
那場凌晨三點的事故讓我重新設計了整套系統，像每一場重大災難之後一樣，倖存者不是修復舊系統，而是制定新規範
我管理 15 個跨產業的客戶專案，從醫療、教育到長照，以下三條安全規範是這一切能運作而不爆炸的原因
規範一：憲法 > 口頭命令
口頭說「不要動 main 分支」，AI 聽了，但下次對話，它什麼都不記得，口頭指令像是用粉筆寫在反應爐外牆上的警告——一場雨就沒了
寫下來的規則不一樣，每次 AI 開始工作，它都會重新讀取這份設定檔，把所有安全規範重新載入，不需要每次都重複叮嚀，規則已經焊進系統裡了
不只是技術規則，什麼時候要停下來問、遇到不確定怎麼處理、哪些事情要先確認——全部白紙黑字，就像核電廠的操作手冊：不是建議，是規定
規範二：分層知識
AI 不需要知道所有事，讓它同時記住 15 個專案的所有細節，它的注意力會被稀釋到什麼都做不好
我的設定分三層，第一層是全局規則——適用於所有任務的安全底線，相當於所有核設施共用的通用安全標準，第二層是專案脈絡——特定專案的技術棧、部署方式、業務邏輯，相當於每座設施自己的操作手冊，第三層是任務手冊——具體操作步驟，只在執行特定任務時載入
每一層在需要的時候才載入，不需要的時候不占空間，反應爐的操作員不需要同時背誦所有設施的手冊，他只需要眼前這座的
規範三：自動守衛（Failsafe）
這是最重要的一條
不靠自律，不靠提醒，靠系統
當 AI 試圖做某些危險操作——直接改保護分支、把 API 金鑰寫進程式碼、跳過 code review 直接合併——系統自動攔截，強制中斷，沒有例外
「提醒」在災難面前一文不值，AI 在壓力下會走捷徑，就像疲勞的操作員會跳過檢查清單一樣，守衛的作用是讓危險操作在物理上不可能發生——不是貼一張「注意安全」的標語，是把通往反應爐核心的門鎖死
每一座安全的核設施都有多層 failsafe，每一個可靠的 AI 開發環境也一樣
事故後的數據
系統重建之後的表現：
- 15 個專案同時管理，一個人
- 每天的交付速度是傳統開發模式的 3–5 倍
- 月費約 $200 USD，省下的人力成本保守估計是 50 倍以上
自從新安全規範上線，沒有再發生過一次 containment breach，不是因為 AI 變聰明了，是因為系統不再允許災難發生
但我要誠實告訴你——陷阱依然存在
初期設定不是裝了就能用
前 2-3 週你會不斷測試和修正：AI 在哪裡卡住、在哪裡越界、在哪裡做出你不預期的決定，每一次小事故都是一次設定更新，這個過程很累，但不做的代價是更多凌晨三點的電話
建造安全系統需要時間，但不建造安全系統的代價，歷史已經告訴過我們了
AI 做不好的事你要非常清楚
它不擅長理解業務上的模糊地帶、做需要大量脈絡的設計決策、處理跨多個利害關係人的溝通，這些事不要交給 AI，不管你的 containment protocol 有多完整，有些決策只能由人類做
過度依賴是真實風險
當工具掛了、當 AI 出狀況、當你需要快速做一個不在安全規範範圍內的決定——你能自己扛嗎？我每隔一段時間會刻意不用 AI 做一個完整的任務，不是懷舊，是確認自己不會在失去工具的那天一起失去能力
操作員必須永遠比機器更懂這座設施
給準備建造自己安全系統的人
第一步：寫一份「AI 不能做什麼」的清單
這比「AI 能做什麼」重要十倍，能力清單好寫，限制清單需要你認真思考你的工作流程在哪裡有爆炸的風險
常見的起點：
- 哪些分支絕對不能直接修改
- 哪些操作需要你的明確確認（部署、資料庫遷移、對外發送）
- 哪些決定只有你能做，永遠不能外包給 AI
第二步：從一個低風險專案開始
不要一次把所有工作都切換成 AI 驅動，你不會在還沒測試安全系統之前就讓反應爐全功率運轉，找一個後果可控的專案，跑一個月，看它在哪裡幫你、在哪裡讓你出問題
累積了信任，再擴大範圍
後記
工具越強，安全系統越重要，一座功率越大的反應爐，需要越精密的 containment
Claude Code 本身的能力已經非常強了，但裸著用，你是在賭它今天不會走捷徑、不會誤判脈絡、不會在你睡覺的時候做出不可逆的事，加了規則、加了守衛、加了分層知識，你才是真的在控制這個工具，而不是祈禱它不要出事
那個凌晨三點的事故，我花了兩個小時圍堵，但那場災難讓我重新設計了整套安全系統
那兩個小時，是我花得最值的
關於作者：Young 同時管理 15 個跨產業客戶專案（醫療、教育、長照、財務），從策略到開發全部自己來，如果你也在建造自己的 AI 開發安全系統，歡迎與我聯繫