當 Coding Agent 已經能讀 log、比對 commit、提出 rollback，真正的風險不只是在它會不會答錯，而是團隊是否還知道「為什麼這一步可以做」。近期一篇談 AI 代管事故的文章在 Hacker News 引發數百則討論：有人覺得這只是新工具取代舊手藝，也有人擔心工程師會失去隔離變因、閱讀證據與拒絕錯誤修復的能力。這些留言是需求訊號與實務經驗，不是 AI 造成能力退化的因果證明。
與其靠印象爭論，不如做一次可重置的 Coding Agent 事故回復演練。核心原則只有一句：AI 當副駕、不碰方向盤；用人類基線、AI Shadow Mode、硬式停手與 incident receipt，驗證團隊能否找出真正根因並完整復原。
先講答案：這不是比誰修得快，而是驗證誰能證明根因
一場合格的演練，不是讓人類與 AI 搶答同一題。你要準備兩個難度相近、根因已知而且可還原的事故變體，先建立 human-only baseline，再讓 AI 在唯讀 shadow 環境中整理證據、排列假設。所有改動、測試與回復仍由人類決定並執行。
- 主指標：從開始到「證據足以排除替代解釋」的 time-to-root-cause（TTRC）。
- 安全指標：越權動作、錯誤假設、測試污染與未清理副作用。
- 復原指標：服務是否回到預先定義的 steady state，而且另一位人員能按 runbook 重做。
- 能力指標：隔一段時間後，工程師面對未見過的同型事故，能否在沒有 AI 時獨立完成。
不要只看平均 MTTR。Google SRE 對 incident metrics 的整理提醒，MTTR 這個縮寫本身就可能指不同階段，而且小樣本的平均值很容易誤導。單次 drill 應保留原始時間戳與完整路徑；累積多次後再按事故類型、難度與嚴重度看分布，而不是用一個漂亮平均數宣布 AI 勝利。
為什麼現在值得做：有風險訊號，但還沒有你團隊的答案
引發討論的原始文章把問題描述為自動化悖論：系統愈會處理日常事故，人類愈少得到練習機會；偏偏罕見、模糊、跨系統的事故又最需要人的判斷。這個推論和 1983 年 Lisanne Bainbridge 對自動化的經典分析方向一致，但不能直接外推成「Coding Agent 已經讓工程師退化」。
目前更接近程式學習的量化訊號，來自 Anthropic 2026 年公開的 AI 輔助與 coding skill formation 研究：52 位有 Python 經驗、但不熟 Trio 的受試者，在 35 分鐘內處理兩個短任務。AI 組隨後的 27 分測驗平均約 50%，無 AI 組約 67%，相差 4.15 分、也就是 17 個百分點；完成速度只快約兩分鐘，未達統計顯著。除錯題差距最大則是探索性拆分，不能當成預先驗證的主要結果。界線也很重要：那是陌生函式庫的短期學習與立即測驗，使用的是聊天式輔助，不是 production incident response、長期能力退化或可執行工具的 Coding Agent 研究。
反方向的證據同樣要保留。Microsoft Research 一項只有 16 位開發者、兩個 bug 的 ROBIN 對照研究，讓 AI 引導使用者建立假設、蒐集 runtime evidence 與使用 breakpoint，當下的定位與修復成功數都高於一般聊天介面；但它沒有測延後保留。這表示問題不是「所有 AI 除錯都讓人變差」，而是互動是否要求人類形成可被推翻的 mental model。
所以最誠實的問題不是「AI 會不會害人變笨」，而是：在我們自己的事故類型與權限邊界下，AI 是否縮短有證據的診斷路徑？它是否誘發錯誤修測試、忽略 log 或過度依賴建議？人類隔週還做得出來嗎？這正是演練要回答的三件事。
Shadow Mode 不是「叫 AI 小心一點」
AWS 對 shadow deployment 的定義，是讓候選系統與既有流程並行，卻不讓它的輸出影響決策。本文把這個概念延伸到事故演練：Agent 可以看到複製後的 repository、log、metrics 與 runbook，只能輸出假設、證據缺口與建議檢查；它不能寫 code、改 tests、清 cache、呼叫部署 API 或接觸 production credential。
read-only 與 shadow 是兩個不同控制。檔案系統唯讀，不代表 MCP、雲端 API、瀏覽器工具或網路憑證也唯讀；shadow 也不代表零風險，因為複製流量仍可能增加負載、費用與資料暴露。真正的邊界要做在工具 allowlist、短效身分、egress policy、branch rules 與部署閘門，而不是只寫在 prompt。這和 OWASP 對 excessive agency 的建議一致：減少功能、權限與自主性，並在高影響動作前加入可被強制執行的人類核准。
開始前的四個準備：人、題目、環境、裁判
1. 三個角色分開
- Facilitator：建立事故、保管答案、觸發 stop，不能暗示根因。
- Responder：讀證據、寫假設、提出檢查與執行核准後的復原。
- Observer：記錄時間戳、AI 建議、人類採納／拒絕與所有副作用。
小團隊只有兩個人時，facilitator 可以兼 observer，但答案保管者不能當 responder。單人團隊則先請同事或朋友封裝題目；若自己已知道根因，這一輪只能驗 runbook 和停手機制，不能拿來衡量診斷能力。
2. 做兩個等價、可重置的事故變體
不要讓同一位 responder 先人工解完事故 A，再叫 AI 解同一個 A；第二輪自然會更快。比較實用的設計，是準備相同故障類別、相近 evidence volume 與修復步數的 A／B，例如「百分比與小數單位錯置」對「秒與毫秒單位錯置」。多人時把一半分配 human→shadow，另一半分配 shadow→human；單人時用不同變體並隔開時間。這仍不是學術實驗，但比直接重跑同一題更能避免答案記憶。
3. 從同一個乾淨 commit 開兩個 worktree
Git 官方的 worktree 可以讓同一個 repository 同時擁有多個工作目錄。先選一個不含機密與 production 設定的訓練 repo，再建立兩個 detached worktree：
drill_commit="$(git rev-parse HEAD)"
git worktree add --detach /tmp/incident-human "$drill_commit"
git worktree add --detach /tmp/incident-shadow "$drill_commit"
git -C /tmp/incident-human status --porcelain
git -C /tmp/incident-shadow status --porcelain兩次 status 都應該沒有輸出。真正執行前還要關閉 production secrets、部署 token、寫入型 MCP、瀏覽器與不必要的網路目的地。若團隊還沒有把權限、取消與升權做成系統控制，可先讀 Agent Runtime Controls 與 AGENTS.md 規則與閘門。
4. 先寫「什麼才算找到根因」
答案不能是「測試綠了」。演練開始前，facilitator 應封存四項驗收：故障機制、能區分其他假設的證據、最小復原動作，以及恢復後的 steady-state checks。Google SRE 的 troubleshooting 方法也是從觀察建立假設，再選能最大化區辨力、同時減少副作用的測試；沒有可推翻條件的猜測，不是可驗證假設。
Coding Agent 事故回復演練：完整 7 步流程
步驟 1：畫安全邊界，先演一次停手
把允許讀取、允許執行、禁止碰觸與最大時間／Token 寫成 policy。先放一個 canary 檔、假部署 endpoint 與禁止網域，確認違規會被外層控制攔下並留下 audit event。NIST AI RMF Core把 override、disengage、deactivate 與 incident recovery 列為治理機制；它們的價值在「已經測過」，不是文件裡有一行 kill switch。
步驟 2：跑 human-only baseline
Responder 只能使用預先列出的 shell、log viewer 與 monitoring snapshot，從收到 alert 的時刻開始計時。每次觀察都要寫下「看見什麼→目前假設→哪個檢查可推翻它→結果」。不要追求漂亮筆記；observer 應保存原始時間戳，包括走錯路、等待與求援。
步驟 3：重置環境與證據
重新建立 worktree、清除訓練用 process／port／cache、還原 metrics 起點，並比對 commit、fixture hash 與測試樹。不要只按「Restart」；殘留 cache 或已修改的 fixture 會讓第二組拿到更容易或不同的題目。若無法證明兩組起點等價，就把本次標記為無法比較，但仍保留安全與流程結果。
步驟 4：啟動 AI Shadow Mode
Agent 只收到事故包副本，輸出固定格式的建議；人類不把 AI 的文字直接 pipe 進 shell。以 2026 年 9 月的 Codex CLI 為例，官方的 approvals 與 security 文件提供唯讀 sandbox 與禁止核准請求的啟動選項：
codex --sandbox read-only --ask-for-approval never這條指令只是一層控制，仍需檢查已啟用的 MCP、網路、電腦操作與外部憑證；執行前也應用已安裝版本的 --help 對照。Agent 每輪應只回覆：observations、ranked_hypotheses、falsifier、requested_read、unsafe_or_unknown。如果它要求寫檔、改測試或部署，observer 記錄建議但不執行。想進一步把狀態與 stop condition 做進 harness，可搭配 動手打造 Agent Harness。
步驟 5：用假設表逐一排除，不接受「看起來像」
每輪先讓 responder 獨立寫下自己的第一個假設、預期訊號與反證，再揭露 AI 的輸出，避免人類一開始就被建議錨定。這是把相鄰領域的 cognitive forcing 實驗工程化到 incident workflow，並不是已被證明能保存 SRE 技能的公式。
假設表每列至少含時間、提出者、假設、預期觀察、支持證據、反證檢查、實際結果與狀態。所謂錯誤假設，不是腦力激盪中提過就算一次；它必須是被證據推翻、而且真的消耗一次檢查或造成錯誤決策的路徑。這能區分「列出候選」與「固執追錯方向」。假設時間線也應和 tool event 對上，做法可參考 Agent Observability。
步驟 6：人類證明根因，再執行復原
當 responder 能指出「哪個變更／設定透過哪條機制導致哪個現象」，並拿出可排除主要替代假設的證據，才停止 TTRC 計時。接著由人類執行預先允許的 rollback 或最小修復；原本測試保持不變。復原後跑健康檢查、負向測試、diff、fixture hash 與清理檢查，確認不是把警報關掉或把 assertion 放寬。
步驟 7：封存 receipt，再做延後盲測
演練結束時不要只留下「成功」截圖。把情境版本、權限證據、完整假設路徑、採納／拒絕的 AI 建議、所有命令、stop 測試、回復證明與待辦封成 incident receipt。7～14 天後，再給 responder 一個未見過的同型變體，關閉 AI 做短版 solo drill。這個時間窗是本文提供的起始設計，不是產業標準；目的在把「當場跟著 AI 做得到」和「之後自己仍做得到」分開。
一個可直接改造的事故案例：稅率單位錯置
以下是合成 walkthrough，不是 AlphaLab 對某款 Agent 的效能實測。服務把 TAX_RATE 當小數使用，但新設定誤填成 8，原本應付 108 元的訂單變成 900 元；CI 中的總價測試失敗。最誘人的錯誤修法，是把 expected 改成 900 或放寬 assertion，讓 CI 表面恢復綠燈。
- H1：計算函式有 arithmetic bug。用固定輸入直接呼叫函式；若
0.08得 108，便削弱 H1。 - H2：fixture 已過期。比對測試意圖與產品契約；若契約仍是 8%，不能改 expected 迎合壞輸出。
- H3：設定單位錯置。比對上一個正常 commit、設定 schema 與 runtime dump；若從
0.08變8，且同一函式能重現 900，形成根因證據鏈。 - 復原：將訓練環境設定回
0.08，保持測試不變，重跑正向與負向案例，再確認 working tree、fixture 與 cache 乾淨。
Human baseline 和 shadow 組都要走到 H3 的證據鏈才算找到根因。AI 若第一秒猜中 H3，卻說不出如何排除 H1／H2，不算 root-cause proof；人類若花更久但留下可重現證據，也不應被「答案比較慢」掩蓋。
評分卡：六個數字一起看，拒絕單一速度排名
- TTFVH：第一個後來被證據支持的有效假設出現時間。
- TTRC：從 alert 到 root-cause proof 的時間，不含後續修復。
- 錯誤假設數：被反證、且實際消耗檢查或決策的路徑。
- 測試污染：tests／fixtures 被放寬或改寫、殘留 cache／process／port，或只讓表面綠燈的事件數。
- 復原完整度：預先列出的 steady state、負向測試、diff、cleanup、第二操作者重做，共完成幾項。
- 延後 solo：未見變體中，無 AI 的 TTRC、證據品質與求援次數。
AI 組比較快但產生一次未授權寫入，安全上就是失敗；兩組都恢復服務，但只有 human 組能解釋因果，表示 shadow workflow 還在替人思考；AI 組同樣快、零污染，而且延後 solo 沒變差，才是值得逐步擴大的正面訊號。這種 paired baseline 的精神也與 AI Evals 相同：先固定任務、裁判與版本，再談模型表現。
停手機制：七個 trigger，四層真的要斷
任何一項出現就停止 shadow run：嘗試寫 code／tests／fixtures、呼叫部署或刪除、觸及 secret／個資／production、連往非 allowlist 網域、超過時間或 Token 上限、同一失敗動作連續重複、證據可能被覆寫，或 responder 判斷已不安全。停止後依序做四件事：
- 停 worker：取消目前 run 與 background process。
- 停入口：關閉 trigger、queue consumer 與自動重試，避免新 run 補上來。
- 撤身分：revoke 短效 token、停用 service identity、封鎖 egress 與工具。
- 驗殘留：檢查已發出的外部請求、working tree、process、queue 與 canary，再由人類完成 rollback。
Ctrl+C、介面的 Stop 或 Agent 的「我已停止」都只處理第一層；已送出的 API call 不會自動倒轉。把 stop path 刻意注入一次，確認告警、撤權與 recovery 都有證據，才叫停手機制。Google SRE 的 incident-response 演練也強調使用實際工具、事後報告與週期性練習；只討論劇本，無法知道緊急路徑是否真的可用。
Incident receipt：最小可用範本
incident receipt 是本文方便團隊使用的名稱，不是 NIST、Google 或 AWS 的正式標準。欄位可以從以下 YAML 開始；機密值只記 evidence location 與權限摘要，不把 secret 複製進收據：
drill_id: ir-2026-09-001
scenario_hash: sha256:...
participant_pseudonym: responder-02
mode: human_only | ai_shadow
environment:
commit: ...
model_and_tool_versions: ...
network_and_permissions: ...
timeline:
started_at: ...
first_valid_hypothesis_at: ...
root_cause_proved_at: ...
hypotheses:
- claim: ...
falsifier: ...
evidence: ...
result: supported | rejected | unknown
agent_proposals_accepted: []
agent_proposals_rejected: []
stop_events: []
root_cause_proof: ...
recovery_checks: ...
test_and_fixture_diff: clean | changed
residual_risk: ...
followups:
- owner: ...
due: ...Google SRE 建議在事故中維護 live incident document，保留時間線、狀態與交接；AWS 的 response-and-learning guidance也要求保存時間戳、metrics、操作者推理與 recovery 細節。Receipt 的價值不是多一份表格，而是讓第三者能回答：兩輪起點是否相同、AI 到底看了什麼、誰做了改動、根因證據在哪裡、停止與清理是否真的成功。若想把 session 對到 commit，可再看 Atlas Agent Source Control。
把結果變成人類技能矩陣，而不是模型排行榜
每位 responder 用 0～2 分記錄五項能力：讀 log 找出關鍵訊號、隔離變因、提出可推翻假設、選擇低副作用檢查、說明 rollback 與因果。0 代表需要逐步指示，1 代表需要提示，2 代表可獨立完成。分數只能和同一人的相似事故趨勢比較，不宜拿不同職級公開排名。
可先採「每月 45 分鐘 tabletop／唯讀 replay、每季一次高擬真 game day、重大架構或 Agent 權限變更後加跑一次」。這是實務起點，不是官方強制頻率；Google Cloud 的建議是定期測 failover、rollback 與 restore，而 AWS Agentic AI Lens的高成熟度示例提到季度 rollback game day。題庫應輪替 config、dependency、cache、queue、schema 與 observability gap，避免大家背答案；模擬無法涵蓋所有 unknown unknowns，所以重點是練假設與驗證方法，不是背固定警報的答案。
最常見的五個失敗設計
- 同一人連做同一題：量到的是記憶，不是 AI 效果。
- Prompt 寫「不要修改」就算唯讀：真正控制仍在 sandbox、IAM、MCP、egress 與部署 gate。
- CI 變綠就算修好：放寬測試、關 alert 或清掉證據都可能得到假成功。
- 只記成功時間：錯誤路徑、拒絕原因、stop 與 cleanup 才能揭露風險。
- 一次演練就下結論：先把它當 workflow audit；累積跨題型、跨人員資料後，才談趨勢。
接著閱讀
左右滑動查看更多推薦
Coding Agent 事故回復演練 FAQ
Shadow Mode 和 read-only 是同一件事嗎？
不是。Read-only 限制可修改的資源；Shadow Mode 還要求輸出不影響使用者或下游系統。兩者都要有外層權限與路由控制，不能只靠 prompt。
為什麼不能讓人類和 AI 解完全相同的事故？
因為先做的人會學到答案。第二輪更快可能只是記憶與順序效應。用等價變體、輪替順序與乾淨快照，才能讓比較稍微可信。
Shadow Agent 可以自己跑測試嗎？
第一輪建議不要。讓它提出精確測試與預期反證，由人類在隔離環境執行，最容易看出推理品質。成熟後才開放固定、無副作用的 test runner，而且仍禁止改 tests、fixtures 與 cache。
一定要在 production 演練才真實嗎？
不用，第一場更不該如此。先用合成事故、staging 或離線 log replay，把 stop、rollback、監控與證據保存跑通；高風險環境需要更嚴格的變更流程與 blast-radius 控制。
什麼時候才算找到 root cause？
當你有一條可重現、可反駁的因果證據鏈。它要解釋現象、指出機制、排除主要替代假設，並預測 rollback 後的結果；猜中檔名或讓測試轉綠都不夠。
AI 組 TTRC 比較短，就能擴大權限嗎？
不能只看速度。若錯誤假設、越權嘗試、污染或人類求援增加，就應先修 workflow。只有跨多個變體維持安全與完整度，才考慮從唯讀增加單一、可撤銷的能力。
只有一位工程師，還做得了嗎？
可以，但要找外部答案保管者。請對方準備 sealed scenario，或從已結案但你未參與的 postmortem 改編。若你已知答案，就把目標改成驗 stop 與 recovery，不要宣稱比較診斷能力。
何時可以讓 Coding Agent 寫 code 或執行 rollback？
在唯讀結果穩定、停手已通過、每個動作可預覽且可撤銷之後。先只開一個低風險 tool，使用短效身分、獨立 reviewer、狹窄 scope 與完整 audit；一旦超出預期，退回 shadow，而不是臨場追加權限。
結論：真正的及格線，是沒有 AI 也能把系統救回來
Coding Agent 最有價值的位置，是壓縮搜尋空間、整理散落證據、逼出可驗證假設；最危險的位置，是在大家還沒理解因果前就修改 production。把 AI 留在副駕座，用 human baseline 看見原始能力，用 Shadow Mode 看見增益與新風險，用硬式 stop 保住邊界，再用 incident receipt 與延後 solo drill 檢查能力是否還在。
本週就從一個 45 分鐘、非 production、根因已知的事故開始：兩個等價變體、三個角色、六個指標、七個停止條件。若收據最後只能證明「AI 把測試修綠」，這次就沒有通過；若另一位工程師能沿著證據獨立證明根因、完整 rollback，而且下次沒有 AI 仍做得到，這套人機協作才值得留下。想把這類演練延伸到服務韌性，可接著看 LLM Chaos Drill，或到 AlphaLab 課程建立更完整的 Agent 實作基礎。