當AI"工程師"遇到模糊需求，它會開口問，還是硬著頭皮瞎猜？

這項由Scale.AI研究團隊主導的研究以預印本形式發布于2026年4月，論文編號為arXiv:2604.09408，有興趣深入了解的讀者可以通過該編號查詢完整論文。

假設你剛入職一家公司，第一天主管扔給你一份寫得含糊不清的需求文檔，里面既沒說清楚用戶界面要什么顏色，也沒說清楚數據庫該用哪個字段，更沒說清楚某個功能到底算不算核心需求。這時候，一個靠譜的工程師會做什么？他會先整理一下自己能自行決定的部分，然后把那些真正說不清楚的問題列出來，去找主管確認。他不會假裝自己什么都明白，埋頭寫代碼，最后交出一份漂亮但完全跑偏的作品。

然而，當今最強大的AI智能體，也就是那些被企業寄予厚望、據說能替代程序員完成復雜軟件任務的系統，在面對同樣的模糊需求時，幾乎無一例外地選擇了"硬著頭皮猜"。它們不問、不停、不確認，直接開干，最終交出一份看起來合理但其實錯得離譜的答案。Scale.AI的研究團隊把這種現象稱為"判斷力缺口"，并專門設計了一套名為HIL-BENCH（Human-in-the-Loop Benchmark，人機協作基準測試）的評估體系來測量它。

這項研究揭示的問題，正是當前AI智能體大規模落地失敗率超過90%的核心原因之一——不是因為AI不夠聰明，而是因為AI不知道什么時候該開口求助。

一、為什么AI"不懂問問題"是個大麻煩

在理解這項研究之前，先得明白一個現實：今天的AI智能體其實已經很厲害了。給它們一份寫得清清楚楚、毫無歧義的任務說明，它們能以75%到89%的成功率完成復雜的軟件工程和數據庫查詢任務。這個數字放在幾年前，簡直是科幻小說里才有的場景。

但現實中的工程任務，幾乎沒有哪個是寫得清清楚楚的。需求文檔總是缺東少西，業務邏輯總有沒說清楚的地方，技術規格里總有互相矛盾的條目。人類工程師應對這種情況的方式，是主動識別哪些信息缺口是自己無法靠經驗和推斷解決的，然后去找有相關知識的人確認。這種能力，研究團隊稱之為"選擇性升級"——知道什么時候該自己決定，什么時候該去問人。

現有的AI智能體，包括Claude Code、Codex、Cursor這些市場上最頂尖的產品，其實都內置了"提問"工具。也就是說，從技術機制上看，它們是有能力開口問人的。但正如特斯拉前AI負責人、知名研究者Andrej Karpathy所觀察到的，這些智能體"不去問人類，缺乏正確的背景信息，總是試圖一次性搞定一切"。斯坦福大學教授、AI創業教父吳恩達也指出了同樣的核心障礙：AI無法獲取那些只存在于人腦中的知識。

更麻煩的是，現有的評估基準根本察覺不到這個問題。SWE-Bench（軟件工程基準）、HumanEval（代碼能力評估）、BIRD-SQL（數據庫查詢基準）這些主流測試，給AI提供的都是寫得清清楚楚、毫無歧義的任務。在這種環境下，一個AI就算靠"蒙對了"完成了任務，和一個真正理解了任務、主動確認了所有細節的AI，得到的分數是一模一樣的。這就好比用一道有標準答案的選擇題來測試學生"是否理解了這道題的含義"——即使學生完全不懂題目在說什么，只要運氣好選對了，照樣滿分。這種評估方式，制造了一個危險的假象：高分數等于高質量，可以放心部署。

Scale.AI的研究團隊決定打破這個假象。

二、HIL-BENCH：專門設計來測試"知道不知道什么時候該問"

HIL-BENCH的核心設計思路，用一句話來說就是：把原本寫得清楚的任務故意"弄模糊"，然后看AI有沒有注意到，有沒有去問。

具體的做法是，研究團隊從兩個真實的AI智能體評估數據集中選取任務：一個是針對軟件工程能力的SWE-Bench Pro，涉及在真實代碼庫中修復GitHub問題，覆蓋Python、Go、JavaScript和TypeScript等語言；另一個是針對自然語言轉SQL查詢能力的BIRD數據集，涉及金融、醫療、教育、娛樂等多個領域的數據庫查詢。

選定任務之后，團隊請來經過專門培訓的領域專家注釋員，在每個任務里故意埋入三到五個"障礙"。這里的"障礙"不是隨便加的坑，而是三種在現實工程環境中真實存在的信息缺口類型。

第一種叫"缺失信息"，占所有障礙的42%。這類障礙是任務說明里根本沒提到的必要參數或數值，AI必須得知道這個值才能完成任務，但靠猜是猜不出來的——比如一個解析器在失敗時應該用什么默認值，比如SQL查詢里"快速進站"的時間閾值是多少秒，任務里沒說，數據庫里也沒有。

第二種叫"模糊請求"，占36%。這類障礙是任務說明里存在多種合理解釋，每種解釋都能實現，但最終結果完全不同。比如版本字符串里的"epoch段"應該如何處理，可以有刪除、標準化、委托等多種策略，哪種才是用戶想要的？比如"中東國家"的范圍應該包含哪些國家，不同人有不同理解。

第三種叫"矛盾信息"，占22%。這類障礙是任務說明里兩處要求互相沖突，無法同時滿足。比如一份規格說管理員角色有特殊權限，另一份文件說沒有，到底聽哪個？比如SQL查詢要求統計北加州學校的數據，但具體列出來的卻是南加州的學校名稱。

每一個障礙在被加入數據集之前，都必須通過七項嚴格的質量審查，任何一項不通過都會被直接拒絕。這七項標準分別要求障礙必須在現實中合理存在、必須真正導致任務無法正確完成、必須有唯一明確的答案、答案空間必須足夠大以至于無法靠猜、各障礙之間必須互相獨立、答案只能從人類那里獲得而不能從任何可用信息中推斷出來、以及必須基于現有任務背景而非憑空捏造。此外，每個任務還要經過五到六輪獨立的人工審核，以及若干輪自動化評估流程，反復修改直到所有標準都滿足為止。

三、"邊做邊發現"：模擬真實工程的漸進式探索

HIL-BENCH與其他類似研究的最重要區別，在于它對"漸進式發現"的設計。

研究團隊注意到，在真實的工程工作中，信息缺口通常不是一開始就擺在你面前的。你得先開始工作，寫一部分代碼，查一部分數據庫，然后在某個具體的執行環節才會遇到一個問題：這里需要一個參數，但沒有；這里有兩種可能的實現方式，但不知道哪種才是正確的；這里有兩條規則互相矛盾，不知道該遵從哪一條。只有在這個時刻，信息缺口才真正"浮出水面"。

為了模擬這種真實情況，HIL-BENCH特意把障礙設計成只有通過實際執行和環境探索才能發現，而不是一眼看完任務說明就能察覺到。為了驗證這一點，研究團隊專門做了一個對照實驗：讓Claude Opus 4.6在不使用任何環境工具（不能查看數據庫結構、不能執行SQL、不能檢索業務邏輯）的情況下完成任務。結果，它的障礙發現率從有完整工具時的61%驟降至11%。這個數字有力地證明了，絕大多數障礙確實需要AI先"動手干活"才能被發現，而不是坐在那里看看需求文檔就能識別出來。

在具體的評測場景中，每個AI智能體會收到一個模糊化的任務，同時擁有一個特殊工具：ask_human()，也就是"向人類提問"。這個工具背后連接著一個凍結的開源語言模型（Llama-3.3-70B-Instruct），它充當"知情的人類協作者"的角色。當AI提的問題準確指向了某個已注冊的障礙，這個"人類"就會返回對應的答案；如果問題不相關或者太模糊，它就返回"irrelevant question"（無關問題）。這個機制保證了評測結果的可重復性，不會因為不同人類評估者的主觀判斷而產生差異。

每個任務里的多個障礙，會在AI探索任務環境的不同階段逐一浮現。每次遇到信息缺口，AI都面臨一個判斷：這個問題我能自己解決嗎，還是得去問人？如果它判斷正確，識別出了這是一個自己無法解決的缺口并且提了一個準確的問題，就能獲得答案并繼續推進；如果它假裝沒看見，或者自己憑感覺做了個假設，那這個障礙就永遠無法被真正解決，任務也就必然失敗。

四、ASK-F1：一把專門測量"問問題質量"的尺子

評測AI的判斷力，不能只看它最終有沒有完成任務，還要看它問問題的質量。于是研究團隊設計了一個專用指標，叫做ASK-F1。

這個指標由兩個維度構成。第一個叫"召回率"，衡量的是AI有沒有找出所有需要問的問題——也就是說，任務里埋了五個障礙，AI有沒有都發現了，都問到了？發現得越多，召回率越高。第二個叫"精確率"，衡量的是AI所問的問題有多少是真正有價值的——也就是說，AI問了十個問題，有幾個是真正指向了某個真實障礙的？瞎問一通的問題越少，精確率越高。

ASK-F1是這兩個維度的調和平均數，也就是說，只有當兩個維度都比較高的時候，ASK-F1才會高。這個設計有一個精妙之處：它從根本上堵死了"靠刷題量取勝"的漏洞。假如一個AI任務里有五個障礙，它通過問五十個問題把所有障礙都問到了，召回率是80%，但精確率只有8%（五十個問題里只有四個有效），那它的ASK-F1得分只有可憐的14.5%。靠題海戰術刷高召回率，在這個指標下完全不管用。

這種設計背后有一個現實考量：如果AI每完成一個任務都要向人類提五十個問題，那比起直接讓人類自己做，AI反而更低效，協作根本無法維系。

最終，HIL-BENCH包含300個任務，其中150個來自軟件工程領域，150個來自SQL查詢領域，共埋入1131個障礙，平均每個任務3.8個。障礙類型分布為42%缺失信息、36%模糊請求、22%矛盾信息。數據集被分為200個公開任務和100個私有任務，私有部分作為不公開的測試集，防止模型"刷題"。

五、實驗結果：所有頂級AI都在這里翻車了

研究團隊對四個當前最頂尖的前沿AI模型進行了評測：GPT 5.3 Codex、GPT 5.4、Gemini 3.1 Pro和Claude Opus 4.6。每個模型在三種條件下分別測試：第一種是"無工具基線"，也就是任務被模糊化了，但沒有提問工具；第二種是"完整信息"，也就是所有障礙的答案都直接告訴AI，讓它在已知全部背景的情況下完成任務；第三種是"有提問工具"，也就是任務被模糊化了，同時提供ask_human()工具，讓AI自行決定何時提問。

在完整信息條件下，這些模型的表現非常出色。在SQL領域，四個模型的完成率在86%到91%之間；在軟件工程領域，在64%到88%之間。這說明模型本身的執行能力是完全夠用的。

然而，當切換到"有提問工具"條件時，結果令人震驚。在SQL領域，表現最好的Claude Opus 4.6的任務完成率從91%暴跌到39%；在軟件工程領域，表現最好的Gemini 3.1 Pro完成率從85%跌到了5%。其余模型更是慘不忍睹，GPT 5.3 Codex在軟件工程領域只有2%的完成率，GPT 5.4更只有1.3%。

而在"無工具基線"條件下，所有模型的完成率幾乎趨近于零，這進一步確認了這些任務的設計是有效的：任務確實需要外部信息才能完成，障礙確實無法靠猜或推斷繞過。

用ASK-F1來衡量，SQL領域的平均分是40.5%，軟件工程領域是37.4%。沒有任何一個模型進入了"提問準確且覆蓋全面"的優良區間。

從召回率和精確率的二維分解來看，不同模型呈現出截然不同的失敗畫像。GPT系列兩個模型在兩個領域都展現出低召回率的特點：它們很少主動提問，更傾向于直接開始執行，根本沒有意識到需要確認什么信息。Gemini在軟件工程領域的表現和GPT類似，但在SQL領域，它的召回率相對較高，問了比較多的問題，但精確率很低，問的大多是過于寬泛或指向不明的問題。Claude在SQL領域達到了相對合理的平衡，召回率61.2%，精確率54.3%，但在軟件工程領域，它的召回率降到34.6%，精確率更是只有26.3%，兩個領域之間的落差是所有模型中最大的。

六、為什么它們會這樣失敗？三種截然不同的問題模式

僅僅知道"它們失敗了"還不夠，研究團隊對超過3600條失敗記錄進行了詳細分析，用一個AI評判系統將每條記錄歸類到三個能力維度（工具使用、邏輯推理、目標對齊）和各自的失敗子模式（準確性錯誤、自我評估錯誤、策略錯誤、完成度錯誤）。這套分析框架在多個項目中獨立開發，評判系統的自我一致性指標達到0.928，與人工判斷的比對也經過了持續校準。

GPT 5.4和GPT 5.3 Codex呈現出"錯誤執行、充滿自信"的失敗模式。這兩個模型在工具使用和邏輯推理兩個維度上，都以"準確性錯誤"為主要失敗來源——也就是說，它們不是因為不知道該怎么做而失敗的，而是因為基于錯誤的前提信息在做對的事。在SQL領域，73%到93%的工具使用失敗都是"調用了正確的工具，但用了錯誤的參數"；76%到88%的邏輯推理失敗都是"把錯誤的信念貫穿到了整個推理鏈里"。更關鍵的是，加入提問工具幾乎不改變這個失敗模式，因為這兩個模型從一開始就沒有"發現"需要問什么，自然也不會去問。

Claude Opus 4.6呈現出"能發現問題、但不采取行動"的失敗模式。Claude是所有被測模型中唯一會在推理記錄里明確說出"這個任務我覺得無法完成"的模型，它在目標對齊維度上的自我評估失敗率高達45%——也就是說，幾乎一半的失敗案例里，Claude自己都知道輸出是有問題的，但還是提交了。同時，Claude在工具使用維度上有82%的"完成度失敗"，意味著它頻繁地進行大量探索，消耗了其他模型五倍之多的計算資源，卻始終沒有執行那個關鍵的最終步驟。它能感知到不確定性，但感知到之后，既沒有去問清楚，也沒有在知情的情況下停下來，而是繼續探索、繼續卡住、然后提交一個自己都不滿意的答案。

Gemini 3.1 Pro呈現出"對環境高度敏感、容易被外部信號影響"的失敗模式。它在兩個領域之間的表現差異是所有模型中最大的。在SQL領域，Gemini有很高的邏輯自我評估失敗率，也就是說它經常不確定自己的答案是不是對的；但一旦提供了提問工具，它的行為發生了最戲劇性的轉變：工具使用維度的"完成度失敗"從56%暴降至18%，也就是說它從"卡在探索階段、沒有執行"變成了"更愿意動手執行"。問題是，執行之后"準確性失敗"從38%飆升至82%，也就是說它動手了，但動錯了。提問工具讓Gemini從"不敢出手"變成了"出手但出錯"，失敗的形態變了，但失敗本身并沒有消失。在軟件工程領域，這種"被外部信號糾正"的能力幾乎消失，表現更接近于其他模型。

研究團隊還注意到，"提問工具改變了失敗的形態，而不是減少了失敗的次數"。這是一個重要的洞察：擁有提問能力，并不等于擁有使用提問能力的判斷力。這個工具，是在每個模型原有的失敗模式上額外疊加的一項能力，而不是一個能從根本上解決問題的開關。

七、判斷力可以被訓練出來嗎？強化學習實驗的答案

發現了這么多問題，研究團隊沒有停下來，而是進一步追問：這種"知道什么時候該問"的判斷力，能不能通過訓練來改善？

他們選擇了Qwen3 32B作為基礎模型，使用LoRA（一種參數高效的微調技術，可以理解為在原有模型上貼一層"專項訓練補丁"）和SkyRL框架進行強化學習訓練。訓練數據是120個HIL-BENCH任務，驗證數據是另外30個未見過的任務，SQL和軟件工程兩個領域分別獨立訓練。

訓練的核心是一套精心設計的獎勵機制，因為ASK-F1這個指標本身雖然是個好的目標，但它是一個終局性的整體評分，很難直接用來給訓練過程中的每一步行為提供反饋。研究團隊把它分解成兩個互補的獎勵信號。

第一個是"每步獎勵"，針對每一次ask_human()調用立即給出反饋：如果這個問題準確指向了某個已注冊的障礙，給+0.3分；如果這個問題無關緊要或者重復問了已經解決的障礙，扣-0.1分。這種非對稱的設計——獎勵比懲罰大三倍——是故意的，目的是鼓勵AI探索問題空間，同時對無效問題有所約束。這個組件主要訓練的是"精確率"方向的能力。

第二個是"終局獎勵"，在整個任務完成時給出：已發現的障礙數量除以總障礙數量，但有一個門檻條件——只有當AI至少問出了一個有效問題，這個獎勵才會計算，否則為零。門檻條件的作用是防止模型學會"什么都不問"的退化策略。這個組件主要訓練的是"召回率"方向的能力。

總獎勵是兩者之和，讓AI在探索的每一步都能得到即時反饋，同時也為整體覆蓋率保持激勵。

結果非常值得關注。訓練后的Qwen3 32B，在SQL領域的ASK-F1從18%提升至46%，任務完成率從11%提升至24%；在軟件工程領域，ASK-F1從4%提升至21%，任務完成率從1%提升至7%。

更關鍵的是跨領域遷移實驗。研究團隊測試了一個只在SQL任務上訓練的模型，在軟件工程任務上的表現；以及一個只在軟件工程任務上訓練的模型，在SQL任務上的表現。兩個方向都有正向遷移，也就是說，在一個領域里學到的判斷力，能夠遷移到完全不同的另一個領域。這是整個研究中最有力的一個發現：這個模型學到的不是"在什么SQL場景下該問問題"或者"在什么代碼庫情境下該問問題"，而是一種更通用的能力——識別出自己無法獨立解決的不確定性，并據此采取行動。

這也意味著，"判斷力"不是某個領域的特定知識，而是一種可以跨領域泛化的認知技能，而且這種技能是可以通過正確設計的訓練信號來培養的。

八、一張4格表格，揭示AI真正的能力版圖

研究團隊在論文結尾提出了一個簡潔但深刻的分類框架，把所有AI智能體的行為歸入一個兩維矩陣：橫軸是任務結果（失敗或成功），縱軸是行為策略（不問人或按需提問）。

在"不問、失敗"的格子里，是最危險的一類：充滿自信地產出看起來合理但實際上完全錯誤的答案。這是當前絕大多數前沿AI智能體所在的位置，也是超過90%企業AI試點項目失敗的核心原因。

在"不問、成功"的格子里，是靠運氣碰對了的類型：答案恰好是對的，但這種正確性是脆弱的、不可重現的，換一個略有不同的任務場景就會失敗。

在"亂問、成功"的格子里，是過度依賴人工確認的類型：每個任務問幾十個問題，雖然最終成功了，但比起直接讓人類做，效率更低，人力成本更高，違背了用AI提效的初衷。

只有在"按需提問、成功"的格子里，才是真正實用、可靠、值得大規模部署的AI智能體：它能自主完成自己有把握完成的部分，同時在遇到真正無法獨立解決的信息缺口時，精準地提出正確的問題，獲取答案，繼續推進。研究團隊把這種能力稱為"選擇性升級"。

HIL-BENCH的意義，正在于它讓這四個格子首次變得可以被測量和區分。在此之前，所有主流基準測試都把這四種情況混在一起，只看最終的任務完成率，根本區分不出來。一個靠蒙對了完成任務的AI，和一個真正理解了任務、主動確認了關鍵信息的AI，在舊有的評估體系里得到的是一樣的分數。

研究團隊最后說了一段令人回味的話：無論這些模型變得多么強大，總會有一些背景信息是鎖在某個具體的人腦子里或者某個組織的隱性知識庫里的，是任何模型都無法從環境中自行推斷出來的。對于所有真實世界的應用場景而言，人類永遠都會在這個循環里。真正的問題是：AI是否知道這一點？現在有了HIL-BENCH，我們至少有了一種測量方式來找到答案。

Q&A

Q1：HIL-BENCH是如何防止AI靠大量提問來刷高分數的？

A：HIL-BENCH使用的核心指標ASK-F1是精確率和召回率的調和平均數。精確率衡量AI所提問題中有多少是真正指向實際信息缺口的，召回率衡量AI找到了多少個需要問的關鍵問題。由于調和平均數的特性，只有兩個維度都高才能得到高分。假如一個任務有五個障礙，AI靠問五十個問題把所有障礙都問到了，召回率是80%，但精確率只有8%，ASK-F1得分只有14.5%，完全無法通過題海戰術取得好成績。

Q2：Claude、GPT和Gemini在HIL-BENCH上各自有什么不同的失敗特點？

A：三個模型呈現出截然不同的失敗模式。GPT系列模型的問題是"錯誤執行、充滿自信"，它們從不主動提問，基于錯誤前提直接行動，加入提問工具也不改變這個模式，因為它們根本沒意識到有什么需要問的。Claude的問題是"能感知不確定性、但不轉化為行動"，它是唯一會明確說出"這個任務無法完成"的模型，但說完還是照樣提交了錯誤答案，同時消耗了其他模型五倍的計算資源。Gemini的問題是"對外部信號敏感但容易執行偏差"，擁有提問工具后它變得更愿意動手，但動手之后的準確率反而下降了。

Q3：HIL-BENCH強化學習訓練的結果能說明AI的判斷力可以被提升嗎？

A：可以，而且存在跨領域遷移。研究團隊用強化學習對Qwen3 32B進行訓練后，SQL領域的ASK-F1從18%提升到46%，任務完成率從11%提升到24%；軟件工程領域的ASK-F1從4%提升到21%，任務完成率從1%提升到7%。更重要的是，只在SQL任務上訓練的模型，在軟件工程任務上的表現也有提升，反之亦然。這說明模型學到的不是某個領域的特定經驗，而是識別和處理不可解決的不確定性這種通用能力，證明判斷力是可訓練的通用技能。