當 AI 等不到你回答，會自己做決定：拆解 Claude Code 的 60 秒「misfeature」

📍 真實場景

陳工程師，新創公司的後端工程師

深夜加班用 Claude CodeAnthropic 出的一款能自己讀程式碼、寫程式、執行指令的 AI 助理工具，你可以想成一個會寫程式的智慧型工讀生重構一份資料庫遷移腳本，中途起身去泡咖啡

😖 卡住的地方：回到座位才發現 AI 已經自己決定改了三個檔案、還開始跑遷移指令，他完全不知道 AI 是「一直乖乖在等他」還是早就自作主張做了選擇，只能整個回頭翻 log 確認有沒有出包

💡 這堂課會拆解 Claude Code 這個「60 秒沒回應就自動接管」的機制是怎麼運作的、為什麼被說成是 misfeature，並帶你設計自己專案裡「AI 該乖乖等、還是該自己衝」的安全開關

🧭 這到底是什麼（白話版）

2026 年 7 月 1 日，Anthropic 在 Claude CodeAnthropic 出的一款能自己讀程式碼、寫程式、執行指令的 AI 助理工具，你可以想成一個會寫程式的智慧型工讀生 2.1.198 版偷偷加了一個機制：當這個 agent（代理）能夠自己觀察狀況、做決定、採取行動的 AI 程式，不是每一步都要人類點頭才會動執行任務執行到一半，需要你點頭決定某件事時，它會跳出問題等你回答——但如果你 60 秒內沒有回應，它不會繼續乾等，而是自己猜一個「最合理」的答案，然後真的照那個猜測往下做。

文章裡貼出一段作者自己遇到的真實紀錄：AI 問了一個問題，畫面顯示「No response after 60s — continued without an answer」，接著 AI 自己寫下「The user stepped away. I'll proceed with best judgment.」（使用者大概離開了，我要照自己覺得最好的方式做），然後真的開始執行它自己想出來的計畫，全程沒有任何人類點頭同意。

問題不只是「AI 會自己做決定」這件事本身，而是這個機制是預設打開的，而且完全沒有寫進這次更新的 changelog（更新日誌）軟體公司每次更新產品時，用來記錄「這次改了什麼」的清單裡。使用者是自己在使用時撞見這個行為，才發現原來工具悄悄改了規則，這也是文章把它稱為「misfeature（帶壞處的功能）」而不只是一個普通新功能的原因。

後續發展算是「還好」：這件事在 Hacker News 上被大量討論後，Anthropic 在幾天內就出了修正。但作者也點出一個更長期的問題——一個靠 auto-update（自動更新）軟體自己在背景下載並套用新版本，使用者不用手動點安裝天天推新版的工具，如果連改變 AI 自主權邊界這麼大的事都能悄悄上線、不寫文件，使用者以後還能百分之百信任它的每一次更新嗎？

🎯 為什麼值得你花時間

預設值其實是幫所有人做決定多數使用者根本不會去改 default（預設值）軟體出廠時「沒有特別設定就會用的選項」，多數使用者根本不會去改它，所以預設值等於幫使用者做了決定，所以「預設是超時就自動繼續」等於 Anthropic 幫全部使用者選好了「風險由你自己承擔」這個答案，而使用者連自己被選了都不知道。

沒寫進 changelog，等於偷偷改規則changelog 是使用者評估「這次更新安不安全」的唯一依據；一個會改變 AI 自主權邊界的功能沒被記錄，代表使用者連「我該不該謹慎一點」的判斷機會都被拿走了。

agent 的自主程度必須是可控的旋鈕，不是暗藏的開關AI agent 會不會「自己做決定」，影響範圍從「浪費一點時間」到「誤操作正式環境」都有可能，這種等級的風險應該讓使用者自己轉動旋鈕決定，而不是被工具商用一個沒人看得到的預設值鎖死。

⚙️ 它是怎麼運作的

1

使用者發問卡關，AI 跳出提示當 Claude Code 執行任務遇到需要人類決定的分岔點（例如要不要用某個方案），它會停下來，在畫面上打出問題，等待你回覆。

▼

2

背景默默開始 60 秒倒數從問題跳出來的那一刻，系統就悄悄啟動一個 60 秒的計時器，畫面上完全看不到這個倒數在跑，你根本不知道自己正在被計時。

▼

3

在時限內回覆：照你的意思做如果你在 60 秒內打字回答，AI 就照你給的方向繼續往下執行，這是大家原本以為的正常流程。

▼

4

超過 60 秒沒回覆：AI 自己接管一旦時間到了還沒等到你的回答，系統就會判定「使用者可能離開了」，然後自己選一個它覺得最合理的做法，直接往下執行，不會停下來等你。這種「不確定時先做了再說」的設計就是 fail-open（失效開放）系統遇到不確定的狀況時，選擇「先做了再說」，優先讓任務繼續跑。

▼

5

社群發現、討論爆開，Anthropic 緊急修正這個機制被使用者撞見又沒寫在更新日誌裡後，在 Hacker News 上引發大量討論，Anthropic 在幾天內就出了修正，但也讓不少人重新評估要不要信任這個產品的自動更新機制。

兩種「AI 等不到你回應時」的系統設計哲學

設計方式	超時後的行為	最大風險	適合場景
fail-open（Claude Code 這次的做法）	AI 自己判斷後繼續執行	做錯決定、多燒 token（代幣／字符額度）AI 每次「想」跟「做」都要消耗的計費單位，可以想成 AI 的燃料，燒越多次代表花越多錢跟時間、甚至誤觸正式環境操作	低風險、可逆的任務，例如寫文件草稿
fail-closed（多數人以為的預設）	AI 停在原地等待，不會自己往下走	任務卡住、浪費使用者時間	高風險、不可逆的任務，例如資料庫遷移、正式環境部署

🔍 程式碼漫遊（點有 ● 的行看白話講解）

這是文章作者自己用 Claude Code 時截下來的真實紀錄，一行一行看，就能看懂「60 秒沒人理」到底會發生什麼事。

●● Claude asked:

💬 AI 遇到需要人類決定的地方，跳出提問，例如「要不要用這個方案？」。

● ⎿ …

💬 省略號代表這裡原本有一串完整的問題內容，作者把它裁掉沒貼出來。

● ● No response after 60s — continued without an answer

💬 重點在這行：60 秒沒人理它，系統自己記下「沒有回答」這件事，然後就往下走，不會卡住等你。

●● The user stepped away. I'll proceed with best judgment. My plan:

💬 AI 自己腦補了一個理由（「你大概是離開了」），接著說「我要照我自己覺得最好的方式做」，然後開始列出它自己想出來的計畫——這一步完全沒有人類點頭。

🛠️ 動手做：60 秒讀秒模擬器：你會選 fail-open 還是 fail-closed？

先選一種「超時策略」：fail-open（超時就自動繼續）或 fail-closed（超時就停住等待）。
按下「開始模擬（新一輪）」，會出現一個假設情境（AI 問你一個問題），倒數計時器開始跑——demo 用 8 秒代表原本的 60 秒。
在時間內按下「即時回應：照我說的做」做出決定，或是什麼都不做，讓它超時看看會發生什麼事。
重複跑幾輪、中途也可以切換策略，觀察下方「風險累積」跟「卡住累積」兩個計數器怎麼變化，感受兩種策略各自要付出的代價。

👇 下面是活的，直接操作

🧠 工程思維透鏡（資深工程師看到的是什麼）

🔭 為什麼 Anthropic 會選擇 fail-open（超時自動繼續），而不是比較安全的 fail-closed？

從產品指標的角度看，agent 產品最怕的就是「卡住不動」——如果每次沒人回應就整個停死，使用者會覺得這個工具很笨重、很難用，留存率會掉。fail-open 讓體驗看起來更順、任務完成率更高，代價是把風險轉嫁給使用者自己沒發現的那一刻。這是典型的「把安全成本外部化」設計取捨：短期讓數字好看，長期風險卻是使用者要自己承擔。

🔭 這個功能沒寫進 changelog，技術上該算誰的責任？

這比較像是「發布流程（release process）」有漏洞，不是單一工程師手滑忘記寫文件。一個健康的發布流程應該規定：任何會改變 agent 自主行為邊界的功能，必須強制在 changelog 標注，甚至要額外走一次產品審查，因為這種改動動到的是「使用者掌控權」這種信任層級的東西，不是普通 bug fix。這件事更可能暴露出，內部把這次改動歸類成「效能優化」而不是「行為改變」，分類錯誤就跳過了該有的審查關卡。

🔭 如果要自己在專案裡做一個會「自主決策」的 AI agent，這篇文章給了什麼具體的設計啟示？

至少三個做法可以直接抄：第一，超時後的預設行為要讓使用者自己選，不要用寫死的預設值幫所有人決定風險偏好；第二，針對「不可逆」的操作（部署、刪除、動正式環境）應該強制 fail-closed，只有「可逆」的操作才考慮 fail-open；第三，任何自主決策都要留下清楚可查的 log，就像文章裡那段 transcript 一樣，讓使用者事後能重建「AI 到底做了什麼決定、為什麼這樣做」。

🔭 「60 秒沒人理」這種超時機制，跟後端系統設計裡常見的哪些機制是同一家族？

這其實是分散式系統裡常見的「timeout + fallback」模式，跟資料庫連線逾時、API 重試、熔斷器（circuit breaker）是同一個問題家族：系統要在「等待完美資訊」跟「不能無限期卡住」之間找一個妥協點。差別在於，一般後端系統的 fallback 通常是「重試」或「回傳錯誤」，風險相對可控；但 Claude Code 的 fallback 是「AI 自己編一個決定、而且真的去執行它」，這個 fallback 本身就帶有高度不確定性，風險等級完全不同，所以才會被說是 misfeature，而不只是一個普通的工程權衡。

📝 隨堂考（點選答案，立即回饋）

Q1. 根據文章，Claude Code 這個「60 秒機制」實際上做了什麼事？

✅ 文章原文寫的是「No response after 60s — continued without an answer」，代表超過 60 秒沒人回答問題，AI 就自己判斷後繼續往下做，不是存檔或離線功能。

Q2. 這篇文章把這個功能稱為「misfeature」，最主要的理由是什麼？

✅ 文章強調的重點不是效能或收費，而是這個會改變 AI 自主權邊界的機制，在使用者不知情、也沒有文件記錄的狀況下就被預設打開了。

Q3. 文中所說的 fail-open 設計，最大的潛在風險是什麼？

✅ fail-open 代表「超時就自己往下衝」，如果剛好問到的是「要不要動正式環境資料庫」這種不可逆操作，AI 判斷錯了就沒有回頭路。

Q4. 根據文章結尾提到的後續發展，Anthropic 對這次事件的處理方式是？

✅ 原文說「Within a couple of days a fix was shipped, but where does that leave user trust in this product?」——問題被修了，但作者也點出這對使用者信任造成的影響沒那麼容易補回來。

Q5. 如果你要幫自己的 AI agent 專案設計「超時處理機制」，根據這堂課的分析，比較合理的做法是？

✅ 這堂課的 lens 分析指出，關鍵不是選邊站，而是依照操作的可逆性跟風險程度做分流，並且把選擇權交還給使用者，而不是用一個寫死的預設值決定所有人的風險承受度。

🃏 翻牌記憶卡（先想答案，再點開對答）

fail-open（失效開放）點我翻面

系統不確定時選擇「先做了再說」，優先讓任務往下跑，代價是可能做錯決定。

fail-closed（失效關閉）點我翻面

系統不確定時選擇「先停下來」，優先確保安全，代價是任務可能卡住等人。

Claude Code 的 60 秒機制是什麼？點我翻面

使用者超過 60 秒沒回應提問時，AI 會自己判斷後繼續執行任務，不會一直卡著等人。

這個機制為什麼被稱為 misfeature？點我翻面

因為它預設開啟、又沒寫進 changelog，在使用者不知情下改變了 AI 的自主權邊界。

changelog（更新日誌）的作用是什麼？點我翻面

讓使用者知道「這次更新到底改了什麼」，是使用者建立信任、評估風險的重要依據。

設計自主 AI agent 時，超時策略該怎麼分流？點我翻面

依操作是否可逆決定：可逆操作可以 fail-open，不可逆、高風險操作要 fail-closed，且讓使用者能自己設定。

✅ 離開前自測（全勾＝這課真的學會了）

0%

我能夠用自己的話解釋 Claude Code 的 60 秒自動接管機制是怎麼運作的。我能夠說出 fail-open 跟 fail-closed 這兩種設計哲學的差別跟各自的風險。我能夠解釋為什麼這個功能沒寫進 changelog 會是個問題，而不只是「工程師忘記寫」。我能夠判斷：在什麼樣的操作情境下 AI 應該 fail-open，什麼情境下應該 fail-closed。我能夠說出至少一個把這篇文章的教訓，套用到自己專案設計裡的具體做法。