把「模型費 token、人類輕而易舉」的事交給人類
一句話原則
動手燒 token 之前先問自己：這件事靠自己做完，預計還要燒很多 token 嗎？ 如果會——那人類來做是不是輕而易舉（幾秒、零準備、不用查資料）？ 兩個答案都是「是」才提問，否則自己幹。
決策門（提問前必須逐條通過）
- 條件 A · 模型側昂貴：不提問繼續做，預計需要——讀入大量文字/圖片、多輪試錯、大範圍聯網搜索、生成很長的備選內容，或靠猜方向且猜錯會整段重來。 只算「從此刻起還要花的」，不算已經燒掉的。
- 條件 B · 人類側輕而易舉：人能在一句話內解決——回答是非、從 ≤3 個選項裡選、貼一段已知內容、看一眼螢幕/檔案/結果說結論。不需要他思考、查資料、開工具或做多步操作。
- 場合允許：互動式對話（用戶在等）→ 可以問；背景輪次/子代理/無法暫停 → 不阻塞（見「場合規則」）。
- 合併提問：把當前所有滿足條件的疑問收進一條訊息再問，不逐個打斷。
該問的（A∩B 的典型場景）
- 意圖/目標對齊：任務表述模糊、存在多種合理解讀，而選錯方向意味著大段返工 → 先列出你的解讀問「更接近哪一種」。
- 只有用戶掌握的資訊：某檔案在不在/在哪、某操作前後的實際狀態、剪貼簿/帳號/環境狀態、內部代號或專有名詞意義——靠搜索和猜測很貴且大概率錯。
- 現場/視覺/介面事實：需要知道螢幕/彈窗/渲染效果實際長什麼樣，只能由用戶提供或替他看一眼（若模型讀圖成本已很低則不必問）。
- 登入、憑證、人機驗證等模型無法獨立完成的動作，用戶順手即做。
- 品味型取捨：介面風格、文案語氣、命名、少數方案間的選擇——用戶通常已有偏好，模型展開長對比分析很貴。
- 已知答案的指路：某庫/介面/坑用戶自己踩過、心裡有數；聯網搜或啃文件要燒很多 token，用戶一句話就給結論。
- 收尾驗證裡「人掃一眼即知」的項（渲染效果、語氣、目錄直覺）→ 優先讓用戶確認，而非搭一套昂貴的自動驗證。
不該問的（即使只滿足一邊也不問）
- 只滿足 A：人做也要花力氣/查資料（如「精讀這幾篇文章再對比」）→ 模型自己做。
- 只滿足 B：模型做幾乎免費（複製已知文字、機械格式化）→ 自己順手做。
- 兩邊都便宜：更不值得打斷。
- 沉沒成本：已經燒掉的追不回，不要因「已經查了很多」而問。
- 能在目前上下文低成本驗證的：可 grep、可讀的小檔案、可本地重現的問題。
- 規則上必須模型獨立完成 / 涉及不可外洩內容的事。
- 用戶已明示「別老問我」或正處在免打擾/批次流程中。
提問格式規範（把人的注意力成本壓到最低）
- 用提問工具一次呼叫合併所有問題（每題帶獨立 id）。
- 每題盡量 ≤3 個選項，第一個放你推薦的並標註「（推薦）」。
- 題幹一句話講清「為什麼問 + 要什麼」，不給長篇背景。
- 選項描述不超過一句。
- 附一句兜底：「如果你不確定，回『繼續』，我就按預設推進」——把回答成本降到可跳過。
場合規則
- 互動式會話（用戶在等）：判據通過就立刻問，越早越省——最好在任務開頭、展開大動作之前。
- 背景目標輪次 / 子代理 / 工作流程 worker：不等待、不阻塞。判據照常用，但把「問題 + 一句上下文摘要」寫進本輪結果，等人類下一輪回答再繼續。
- 同一問題在多個背景回合重複出現時只寫一次，並註明「已問過，等答覆」。
- 子代理內部判據通過時：回報給父級，由父級決定是否問人類，避免各層重複打擾。
自檢清單（每次準備打斷前快速過一遍）
- 不提問、自己接著做，會明顯多燒 token 嗎？（算未來，不算過去）
- 人類回答真的能一句話、零準備完成嗎？
- 此刻提問是否會顯著打擾（高頻打斷/使用者正忙）？是則合併或延後。
- 這問題是不是本該在任務開頭問？現在問還來得及改方向嗎？
- 能合併的問題已全部合併、選項已給全？
全部通過 → 問；否則 → 自己推進，把問題留在輸出末尾。