寫於 2026 年 8 月 16 日，9 月才上線（部落格的發佈額度 8 月 10 日就用完了，這批稿子要等到九月才發得出去）。文中對 Devin 與 Claude Code 的描述以 8 月 16 日查到的官方文件為準，你讀到時文件可能已經改版。

補全時代的「不確定」，是在游標旁邊當場解決掉的。灰色建議跳出來，對就 Tab，錯就繼續打字。那時候沒有人在討論「AI 該不該喊停」，因為它從來沒離開過現場，你的眼睛就是那道閘門。

任務從一行變成一個 PR 之後，這道閘門就沒了。agent 拿一句話進去，跑二十分鐘，回來丟給你一包 diff。中間它做了幾十個小判斷，有幾個它自己其實也沒把握。哪幾個？看 diff 是看不出來的。

不確定性沒有消失，只是換人吸收。以前是寫的人當場吸收，現在是 review 的人事後吸收。有意思的地方在於，Devin 跟 Claude Code 對「什麼時候該把人叫回來」給了兩個答案。差別不在誰做得多做得少，在於喊停的判準掛在完全不同的變數上。

Claude Code 的閘門只認動作型別

Claude Code 這邊的規則直白到有點無聊。官方權限文件那張表就三列：唯讀操作（讀檔、Grep）在工作目錄內不需核准；Bash 指令要核准，只有一組內建的唯讀指令例外；改檔案一律要核准。

這是純粹的動作分類。它不管模型有多少把握，只管這個動作會不會留下痕跡。rm -rf 就是要問，grep 就是不問，模型今天狀態好不好完全不影響結果。

好處是可稽核。你可以把規則寫進 .claude/settings.json，check 進版控，全隊共用，而且你事後看得出來為什麼那次它問了、那次它沒問。壞處也很直接：它擋得住「動作危險」，擋不住「方向錯誤」。一個把整份設定檔改對格式、但改錯環境的 Edit，跟一個改對的 Edit，在權限系統眼裡是同一件事。它會問你「要不要改這個檔」，不會問你「我理解對了嗎」。

模式那一欄也是同一套邏輯。plan 是不准動原始碼、只能讀跟跑唯讀指令；acceptEdits 是自動收下檔案編輯；dontAsk 是沒預先允許就直接拒絕。全部是在切「哪一類動作免問」，沒有一個模式的名字跟「模型有多確定」有關。Pro、Max、Team 方案預設進的 auto mode 稍微特別，官方寫的是「由第二個模型，也就是 classifier，代替你檢查動作」，但它檢查的仍然是「這個動作跟你的要求對不對得上」，不是「模型自己覺得如何」。

Devin 把「我沒把握」做成一顆燈

Devin 2.1 走的是另一條軸。Cognition 官方部落格的原文是這樣寫的：At multiple points in each session, Devin will express how confident it is in its approach，用綠、黃、紅三檔的燈號報告自己的把握度。

真正關鍵的是後面兩句。When Devin doesn't have 🟢 confidence, it will ask clarifying questions to improve its understanding：沒拿到綠燈，它會反過來問你問題，把理解補起來、把分數拉上去。以及 Devin will wait for user approval when it is unsure about its plan. Otherwise, it will proceed automatically：對計畫沒把握就等你核准，有把握就自己走。

這是把「我不確定」變成產品層的一級公民。原本只存在模型腦袋裡的內部狀態，被拉出來顯示在畫面上，還會實際改變接下來的行為。

而且他們有拿數字出來背書：綠燈的 session 最後 PR 被 merge 的機率，是紅燈的兩倍。這句話比燈號本身重要，因為它說明這個分數不是裝飾用的進度條，它跟結果真的有相關性。

延伸出來的用法也很聰明。Jira 整合有一個 scoping only 模式，官方文件寫 Devin only analyzes the ticket and posts a scoping comment with a summary, implementation plan, and confidence estimate：它只讀 ticket、貼一則含摘要、實作計畫與信心估計的留言，不開 session，你要做再自己點連結。等於是把「先估把握度、再決定要不要派工」變成一道獨立工序。有一整個 backlog 的時候，先跑一輪批次評分、只挑高信心的來做，這個順序是有道理的。

誠實邊界先講清楚：我沒有 Devin 帳號，也沒跑過任何一個 Devin session。上面每一句對 Devin 行為的描述都出自官方文件與 Cognition 的官方部落格，我只讀了文件。實際跑起來燈號準不準、黃燈的問題問得好不好，我沒有第一手資料可以說。Claude Code 那邊則是日常在用的工具。

計劃這一關，嚴的反而是 Claude Code

直覺上會以為「會喊停的那個比較保守」。實際去對兩邊的計劃階段，結論剛好相反。

Claude Code 的 plan mode 是硬閘門。官方權限模式文件寫得很死：Plan mode tells Claude to research and propose changes without making them. 然後接一句 edits stay blocked until you approve the plan。除非你開了 bypass permissions，否則計畫沒核准，編輯就是被擋著。核准之後才切換模式、才開始動手。

Devin 的 Interactive Planning 是軟閘門。文件原文：By default, Devin will wait thirty seconds for feedback from you before automatically proceeding with its plan. 三十秒，沒回應就自己往下走。這是預設值，可以在 Settings > Customization 調整，複雜任務也可以按「Wait for my approval」把它變成硬閘門。

三十秒這個數字設計得很有意思。它假設你人在螢幕前面。你在的時候，它是一個「我要開始囉，有意見趕快講」的緩衝；你不在的時候，它等於不存在。同一個機制，你在不在旁邊會得到兩種完全不同的產品。

所以在「計劃要不要人點頭」這一題上，Claude Code 反而是比較嚴的那個。差別在於它的嚴格來自模式設定，跟模型的把握度沒有半點關係：你進了 plan mode，它就算對計畫百分之百確定也得等你；你沒進 plan mode，它就算滿頭問號也會直接開始改檔案。

糾正過的事，誰負責記起來

同一個錯誤被糾正第三次，代表這條知識沒有地方可以落地。

Devin 有 Knowledge。官方文件寫 Devin will automatically suggest Knowledge to remember based on your feedback in chat：它會從你在對話裡給的回饋，自己提議「這條要不要記下來」，你可以編輯過再存，也可以直接不理它。存進去的每條都帶一個觸發描述，之後 Devin retrieves Knowledge when relevant, not all at once，用到才撈，不是每次全塞。也可以釘到特定 repo，在那個 codebase 裡自動生效。

寫入的動作是 agent 起頭、人拍板。這個分工其實比「全自動記憶」保守，也比「全手動維護」省事。agent 負責注意到「這件事剛剛被糾正過」，人負責判斷「這值不值得變成長期規則」。糾正發生的當下正是知識最完整的時刻，那時候不記，之後就得靠人回想。

Claude Code 這邊沒有對應的東西。CLAUDE.md 要人自己寫，寫多寫少沒人管，過期了也沒人提醒你。它會不會提醒你「這件事我這週被糾正三次了，要不要寫進去」？不會。這條路上從頭到尾只有你一個人。

Playbook 那邊倒是有一個欄位值得抄。Devin 的 playbook 建議分成 Procedure、Specifications、Advice、Forbidden Actions、Required from User 五節，最後那節的定義是「描述需要使用者提供的任何輸入或資訊」。把「這件事我沒有、要跟人要」寫成工作流的正式欄位，而不是等 agent 跑到一半才發現，這個設計本身就是一種喊停。

真的想問的時候，找得到人嗎

Claude Code 不是不能問。它有 AskUserQuestion，選擇題形式，一次一到四題、每題二到四個選項。

差別在觸發判準。官方文件寫的是 When Claude needs more direction on a task with multiple valid approaches, it calls the AskUserQuestion tool：條件是「有多個都說得通的做法」，不是「我對這件事沒把握」。這兩者聽起來很近，落到行為上差很遠。方向有分歧它會問；方向只有一條但它其實猜錯了，它不會問，因為在它看來沒什麼好選的。

還有一個限制更麻煩：AskUserQuestion 在用 Agent tool 派出去的 subagent 裡不能用。派工鏈愈深，愈沒有人可以問。你派一個 subagent 去改二十個檔案，它中途撞到一個你沒交代的邊界情況，它唯一的選擇是自己選一個然後繼續，把歧義寫在回報最後面，如果它記得寫的話。

官方對 Claude Code 需要人介入的時機給了一句總結：Claude requests user input in two situations: when it needs permission to use a tool ... and when it has clarifying questions。兩種情境，一種看動作型別，一種看模型自己判斷有沒有分歧。沒有第三種。

產品沒做的，只能寫進規則檔

這個空缺，用的人會自己補起來。

我自己的全域規則檔裡就有一段「何時該停下來問使用者」的清單，不是抄來的，是踩夠了才長出來的。該問的那邊列了五項：任何資料庫異動、修改設定檔、刪除大量檔案、對 main 分支 force push、改生產環境配置。不該問的那邊也列了：查得到的事實先去查、可逆的實作細節照既有慣例選一個、以及最重要的那條，不要問「我可以繼續嗎」。

寫的時候我以為自己在調教 agent 的禮貌。回頭看，那份清單的真實身分是一個手寫的權限表，判準跟 Claude Code 內建的完全同一條軸：動作的可逆性。改私有函式的名字可逆，所以不問；INSERT 進正式 DB 不可逆，所以問。

也就是說，我補的是同一條軸的延伸，另一條軸我根本沒補。「不確定就停」這件事，規則檔寫不出來。你可以寫「不確定的時候要問」，但模型憑什麼知道自己不確定？那需要一個能被觀測、能被記錄、能被拿去跟結果做相關性分析的量。Devin 的燈號至少讓這個量離開了模型腦袋，變成一個你看得見、也事後查得到的東西。

兩條軸都要，缺哪條都會漏

回到最前面那個游標旁邊的閘門。它之所以有效，是因為它同時擋住了兩件事：你看到動作，也看到方向。任務一變長，這兩件事就被拆開，然後各自被不同的產品撿走了一半。

動作危險度這條軸，Claude Code 做得紮實：可稽核、可版控、行為可預測，而且完全不依賴模型的自我認知。壞消息是它對「做對了動作、走錯了方向」完全無感。

信心分數這條軸，Devin 做出來了，而且拿得出跟 merge 率的相關性。壞消息是它建立在模型的自我評估上，自我評估這種東西，你沒有辦法像檢查一條權限規則那樣檢查它。它說綠燈，你只能選擇信或不信。

最合理的組合大概是這樣：危險動作看動作型別，該擋就擋，不管模型怎麼想；方向性的疑慮看模型自評，寧可它多問一次。目前沒有哪個工具兩條都給滿。

真正變了的不是「agent 會不會問人」。以前這是一個態度問題，你只能希望它比較謹慎。現在它是一個工程問題：判準掛在哪個變數上、那個變數看不看得見、看得見之後你能不能拿它去對帳。下次評估任何一個 agent 工具，比起問它能自己跑多遠，先問它憑什麼決定要停。

參考來源