当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任务上训练的模型，在软件工程任务上的表现也有提升，反之亦然。这说明模型学到的不是某个领域的特定经验，而是识别和处理不可解决的不确定性这种通用能力，证明判断力是可训练的通用技能。