前言：問問題，跟丟回工作，是兩件不同的事

「這幾個分支要不要保留，你來決定」——這句話聽起來像是在尊重使用者的判斷，但如果「該不該保留」這件事其實有客觀依據可以查證（例如分支有沒有被合併、有沒有連結到還開著的協作階段），那麼把這個問題丟回來問，不是尊重，是把本來該做的查證工作省略掉了。

今日目標

• 分辨「真的需要人類判斷」跟「其實可以自己查證」這兩種情況
• 看真實協作紀錄裡這個現象的具體樣子
• 理解為什麼「丟回來問」有時候反而增加了協作成本

真實案例：大規模清理時的兩次「你來選」

一次清理大量本機分支跟工作目錄的作業裡，AI 兩度把驗證工作丟回來問使用者：「這些分支要保留哪些，你決定」。實際上，「這個分支有沒有被合併」「這個分支是不是還連結著開著的協作階段」都是可以直接查證的事——查 git 的合併紀錄、查有沒有對應的進行中工作，不需要使用者用記憶去判斷。丟回來問，等於是把使用者原本期待被完成的工作，又還了一部分回去。

拆解：什麼時候該問，什麼時候該自己查

不是所有「丟回來問」都是問題。真正該分辨的是：這個決策依據存不存在客觀可查證的資訊。如果有（分支的合併狀態、檔案有沒有被其他地方引用、測試覆蓋率的實際數字），這是可以自己查完再回報結論的事；如果沒有客觀依據，純粹是價值判斷或偏好（要不要保留某個實驗性分支，即使它已經沒用但有紀念意義），才是真正該讓人類決定的情境。

為什麼這個現象會增加協作成本

每一次把「其實查得到答案」的問題丟回來問，都是多消耗使用者一次注意力、一次往返的等待時間。如果協作的預期是「授權一整段工作，回來看結果」，這種「你來選」會打斷這個預期，讓使用者必須臨時切回來做原本該由 AI 完成的查證動作——這正是為什麼這類現象常常引來直接、甚至有點不耐煩的回應。

今日思考題

回想你收到過的「你來決定」，事後回頭看，那個決策依據是不是其實可以被查證出來？如果可以，是什麼原因讓查證這一步被跳過了？

今日重點回顧

• 「丟回來問」不等於尊重使用者，如果決策依據其實可查證，這是省略了該做的工作
• 真實案例：分支該不該保留的判斷，其實可以查合併紀錄跟進行中工作直接得到答案
• 判斷準則：有沒有客觀可查證的依據，是「該自己查」跟「真的該問人」的分界線

明日預告

明天分析根因：為什麼 AI 沒有一個「失敗要重試幾次才算數」的預設值。