一段科研构想可以写得流畅、合理，甚至足以让 AI 生成一份能运行的代码，却仍然没有说清它真正要实现的方法。比如，一个系统要把论文 PDF 转成文本块，但没有交代输入来自原始 PDF、LaTeX、OCR 还是 Markdown，也没有说明公式、图片和参考文献怎样处理。Agent 如果直接挑一种常见方案继续做，程序可能跑通，实现的却不是作者想要的方法。
9 月 9 日，耶鲁大学与 TCS Research 的研究者提交了 IdeaAMBIG。这个包含 660 个案例的新基准没有再问模型能否提出科研点子或写出代码，而是把检查点提前到执行之前：一份研究方法说明是否已经足够明确，模型能否找出阻碍实现的那一处缺口，以及它知道缺口后能否提出有效的澄清动作。
结果形成了一个鲜明落差。13 个受测模型中，表现最好的 GPT-5.6-Sol 在真实案例上的严格缺陷恢复率只有 9.6%；把缺陷位置直接告诉同一个模型后，澄清动作成功率达到 80.6%。科研 Agent 的薄弱环节不只是回答问题，而是先知道该问什么。
真实问题不是一句话有歧义，而是代码可以悄悄走向另一种方法
IdeaAMBIG 把“可编码”定义得很窄：有能力的实现者或代码 Agent 应当能据此搭出忠实的初始实现，而不必替核心方法做没有证据的选择。随机种子、文件路径或常规 batch size 不必全部写死；只有当两位实现者可能据此做出足以改变方法的不同选择，遗漏才算实施关键缺陷。
660 个案例都只保留一个目标缺陷，并为欠缺信息的 NotReady 版本配上补全后的 Ready 版本、缺陷标签和标准澄清动作。其中 163 个真实案例来自已经关闭或得到回答的 GitHub issue 与复现报告：研究者先检查了 1000 个论文关联仓库中的 4106 条 issue，以及机器学习复现挑战、ECIR 和 TMLR 的复现材料，最后人工保留 121 条 issue 案例和 42 条复现案例。其余 497 个案例是受控合成缺陷，研究者从已经成功复现或执行的材料中删除、模糊或改写一处关键细节。
这种设计换来清晰的因果对照，也限定了文章可以怎样解读数据。真实案例是根据事后已经出现的实现争议重新整理出的、自包含的规格说明，不是研究者最初交接工作的原始记录；合成案例又占了总体的四分之三。它适合诊断“单个、已知可解决的缺口”，不能代表开放科研任务的总体成功率。
9.6% 是一项严格联合指标，去掉分类要求后仍只有 40%
基准依次测试三件事。第一步让模型判断一份规格是否已经可以实现；第二步不给提示，要求它找出缺陷，同时匹配“歧义、信息不全、前后矛盾”中的一级类别和更细的二级类别；第三步则把标准缺陷描述交给模型，要求它决定是向作者提问，还是去论文、代码、配置、数据文档和实验日志中找证据。
9.6% 的 Macro Defect Recovery Rate 要求模型同时找对阻塞实现的具体问题，并给出两级分类，因此比“有没有提出一个合理疑问”严格。论文用 50 个真实案例另做了一次不要求分类的人工评估：GPT-5.6-Sol 的同一阻塞点识别率从联合标准下的 10% 升到 40%。分类确实压低了主指标，但去掉分类后仍有六成案例没找对关键缺口。
更值得警惕的是，模型并不缺少批评意见。在真实案例的错误分析中，GPT-5.6-Sol 有 17.8% 找到了相邻问题，66.3% 指向了另一个具体问题，几乎没有空白或含糊回答。它会生成听起来像审稿意见的担忧，只是大部分没有击中那项会改变实现的方法选择。
第一步的“是否可实现”也没有提供可靠闸门。该模型在平衡样本上的 Macro-F1 为 67.5：31% 的欠完整规格被放行，34% 的完整规格又被拒绝。模型给对标签不等于理由可靠；论文的细分评估中，只有 1.5% 的真实案例同时满足标签正确、理由支持标签、找对阻塞点且没有脱离原规格。
缺陷提示把澄清成功率从 13.6% 推到 80.6%
研究者用同一模型、同一批真实案例做了更直接的对照。端到端设置只给欠完整规格，模型要自己找问题并提出澄清，Macro-CAS 为 13.6%；加入标准缺陷描述后，成绩升到 80.6%，其中“取得足够信息”的分项从 8.6% 升到 80.4%，而“不擅自假设”的得分基本不变。按来源聚类重采样后，这个 67 个百分点的差距仍然成立。
这组实验把两个能力拆开了：模型通常能把已知阻塞点改写成一个有用问题，难的是从一份看似完整的技术方案中发现哪项决定仍未被定义。此前的 SciConvBench 已在流体、固体、材料和偏微分方程任务中测试多轮澄清；SpecBench 检查软件 RFC 的规格缺陷；ClarifyCodeBench 则让模型对含糊的编程需求反复提问并最终写代码。IdeaAMBIG 的增量，是把“发现缺口”和“拿到缺口后怎样行动”分开，并把答案锚定到论文、代码、issue 与复现材料。
给出缺失信息能让代码更忠实，却还不是完整论文复现
在 50 个真实案例的 oracle 实验里，研究者不只告诉模型缺陷，还把标准澄清动作和已有证据支持的解决方案一起给出。由此生成的规格被判为可编码的比例从 14% 升到 98%，缺失细节恢复率也从 14% 升到 98%。这说明模型并非普遍缺少把方法写清楚的能力；信息一旦被找齐，它大多能完成后续表达。
20 个带参考实现的受控案例进一步检验了代码结果。未补缺口时，70% 的代码可以运行，只有 30% 忠实实现了目标方法细节；加入 oracle 解决方案后，两项比例分别升到 95% 和 90%，通过全部预设测试的比例从 45% 升到 85%。能运行与实现正确方法之间的 40 个百分点差距，正是“流畅补全”最容易掩盖的代价。
这些数字来自有限的组件级任务，不是端到端复现论文；50 个 oracle 案例和 20 个可执行案例也不足以说明部署收益。基准目前集中在 AI、NLP 和机器学习，只评估单个缺陷、单次澄清动作，尚未让 Agent 在多轮对话中处理多个相互影响的缺口。公开仓库已经提供 660 个案例、构建代码和评测流程，但没有缓存模型输出，也未在仓库顶层声明数据与代码许可证。
对科研 Agent 的下一道产品门槛因此很具体：在调用代码 Agent 或实验工具前，先放一道“规格是否足以忠实实现”的检查，并允许系统暂停、向人提问或查阅证据。接下来真正需要验证的，不是这道闸门能否再提高一个离线分数，而是它能否在完整科研流程中减少方法偏离、无依据默认值和研究者返工。
