一个场景：当AI开始帮你实现论文里的方法
你刚读了一篇论文，里面提出了一个新方法。你把方法描述丢给Claude，让它帮你写代码实现。Claude很配合，刷刷刷写出了完整的PyTorch代码，还能跑通。
但问题来了：这段代码实现的，真的是论文作者想表达的方法吗？
论文里写"我们使用一个稀疏注意力机制"，但没说稀疏度是多少、mask怎么构造、哪些头被保留。Claude替你做了一个合理的选择——但这个选择可能和作者的真实意图完全不同。代码能跑，但跑的不是那个方法。
这就是IdeaAMBIG要解决的问题。这篇来自ACL匿名提交的论文，问了一个被所有人忽略的问题：当研究想法的规格说明不完整时，AI能发现吗？能定位是哪里不完整吗？能问出正确的问题来补全吗？
三个任务：从"能不能跑"到"该不该问"
IdeaAMBIG定义了三个递进的任务：
任务1——就绪性评估（Readiness Assessment）：给定一个研究想法的规格说明，判断它是否"codification-ready"——即一个合格的实现者能否在不做任何未支持假设的前提下构建忠实实现。如果两个合格实现者可能做出实质不同的方法选择，那这个规格就不ready。
任务2——缺陷定位（Defect Localization）：如果规格不ready，定位到底是哪里不ready。是定义模糊？是缺少方法步骤？是缺少模型结构？是缺少数据规格？是缺少配置协议？还是存在内部矛盾？
任务3——澄清动作生成（Clarification Action Generation）：一旦知道了缺陷在哪，生成一个正确的澄清问题来补全这个缺陷。
这三个任务构成了一个完整的"实现前检查"流程。不是在代码生成后检查代码对不对，而是在写代码之前检查规格够不够。
660个实例：从GitHub issues和可复现性报告里挖出来的真实缺陷
数据集的含金量是这篇论文的底气。660个实例，其中163个来自真实世界——GitHub issues和TMLR可复现性报告，都是实现者真实遇到过的规格缺陷。另外497个是受控合成实例，通过人工注入缺陷构造的。
每个实例包含一个NOT_READY规格（有缺陷的）、一个READY规格（补全后的对应版本）、一个标注的缺陷标签、一个gold标准的澄清动作。这种配对设计让评估可以做到非常精细。
缺陷被分为三大类：
- Ambiguity（模糊）：定义模糊、过程模糊
- Incompleteness（不完整）：缺少方法步骤、缺少模型结构、缺少数据规格、缺少配置协议、缺少评估规格
- Inconsistency（不一致）：目标冲突、模型设计冲突、形式定义冲突
13个LLM的惨淡成绩单
论文测了13个LLM，包括GPT-5.6-Sol、Claude、Gemini、Llama等。结果令人震惊：
就绪性评估：最好的GPT-5.6-Sol在真实实例上只有67.5 Macro-F1，接受了31%的不完整规格，拒绝了34%的完整规格。更关键的是，Reason Grounding Score只有0.36——即使标签猜对了，理由也往往是错的。
缺陷定位：这是最难的。GPT-5.6-Sol在真实实例上只有9.6%的Macro Defect Recovery Rate。也就是说，91%的情况下，模型无法准确定位规格中的缺陷。论文做了一个精巧的消融实验：在50个真实实例上去掉分类标签约束，只要求"定位到同一个缺陷"，准确率从10%升到40%。这说明模型不是完全找不到缺陷，而是无法把它归入正确的分类标签。
澄清动作生成：一旦给了缺陷位置，GPT-5.6-Sol在真实实例上达到80.6%的Macro-CAS（Clarification Action Success）。但如果不给缺陷位置，端到端只有13.6%。瓶颈明确在定位，不在生成。
Oracle实验：如果缺陷被完美定位呢？
论文做了一个Oracle实验：直接给模型gold标准的缺陷解决方案，看下游的codification-ready率从14%升到98%。
这个数字的意义是：规格不完整的代价是84个百分点。如果你能在实现前把规格补全，你的方法实现成功率会从14%变成98%。这不是模型能力的差距，是信息完整度的差距。
我的思考：定位瓶颈与合理化外壳
IdeaAMBIG揭示了一个被忽视的瓶颈：AI不是不会问问题，而是不知道什么时候该问、问哪里。模型在澄清生成上表现不错（给了缺陷位置就能问对问题），但在缺陷定位上几乎失败。这和"合理化外壳"概念形成呼应——模型倾向于在不确定时做出合理化假设，而不是承认不确定并寻求澄清。
论文的taxonomy-free消融实验尤其精彩。把"定位+分类"拆成"只定位"，准确率从10%升到40%。这说明模型的定位能力被分类标签的负担掩盖了。这和"标量幻觉"谱系一致：不能问"模型能不能定位缺陷"，要问"在给定分类约束下能否定位"和"不分类能否定位"是两个不同的问题。
对Agentic RL系统的启示：如果你的agent在实现研究想法时经常跑偏，可能不是代码能力的问题，而是规格理解的问题。在实现前加一个"就绪性检查"环节，可能比提升代码生成能力更有效。
代码与数据
论文开源代码在 GitHub: Yiling-Ma/IdeaAMBIG，包含660个benchmark实例、评估代码和构建代码。数据集分为Real_Route（真实世界实例）和Synthetic_Route（合成实例）两个路径。
---
论文: arXiv:2609.10539 代码: github.com/Yiling-Ma/IdeaAMBIG 核心数据: 660实例（163真实+497合成），13个LLM，GPT-5.6-Sol最佳但缺陷定位仅9.6%