Claude Opus 4、GPT-5 等 AI 编程助手在 RubberDuckBench 上表现如何？
RubberDuckBench 上，Grok 4、Claude Opus 4 和 GPT-5 的平均得分分别为 69.29%、68.53% 和 67.80%，位于 20 款模型前列，但前三名之间不能据此判定稳定胜负。更重要的结果是：模型主要依靠部分得分，跨三次运行都完全答对的问题最多只有 2 道，平均 58.3% 的回复出现论文定义的虚假断言。
RubberDuckBench 测试什么
RubberDuckBench 不是让模型从描述生成独立函数，而是测试 AI 编程助手能否结合具体项目、文件和代码位置回答问题。数据来自高质量开源项目的 GitHub Pull Request 评论，经模型辅助筛选、三位作者确认并改写为清晰问题。
基准包含 15 个问题，Java、Python 和 C++ 各 5 个，覆盖 13 个开源项目。问题类型包括项目行为、库与 API 行为、程序变量值传播和性能判断，平均每个评分规则投入约 12 人时整理。
主要模型表现
| 模型 | 平均得分 | 解读 |
|---|---|---|
| Grok 4 | 69.29% | 总体最高，但未稳定显著领先多数高分模型 |
| Claude Opus 4 | 68.53% | 与第一名接近，严格跨三次完全正确 2 题 |
| GPT-5 | 67.80% | 位于前三，问题间表现仍有明显波动 |
| 20 款模型平均 | 60.17% | 中位数为 61.30% |
论文指出，Grok 4 对后续 12 款高分模型的两两差异没有达到显著水平。小样本中不到两个百分点的总分差不能当成稳定能力等级，模型在不同语言和问题类型上的排序也会变化。
为什么总分会掩盖风险
回答可通过提到部分正确事实获得分数，因此约 68% 的平均分不等于多数问题完全正确。以严格标准要求三次运行都获得满分时，Grok 4 与 Claude Opus 4 各完全答对 2 道，其他模型最多 1 道，多数为 0。
模型在库行为问题上相对更好，在依赖项目整体语义的 Project Behavior 问题上最弱。这说明熟悉通用 API 不等于理解某个仓库中状态、约束和调用链的真实含义。
58.3% 的虚假断言意味着什么
论文的评分规则对错误或编造信息比遗漏施加更重扣分，并把这类断言统计为 lies。这里不是判断模型主观意图，而是标记回答中与代码证据冲突、却被肯定表达的内容。20 款模型平均有 58.3% 的回复包含此类问题。
开发者因此不能只看回答语气和解释长度。涉及变量值、性能原因或项目行为时，应要求模型指向具体文件、符号和控制流，再通过最小脚本、测试或调试器验证。
价格更高是否更可靠
研究没有发现 API 价格或参数规模与得分相关。低成本 Gemini 2.5 Flash 在该基准上高于 Gemini 2.5 Pro，gpt-oss-20B 也高于规模更大的 gpt-oss-120B。这个结果只适用于该基准，不能推广为“小模型总是更好”。
选型时应计算得到可验证答案的总成本，包括模型调用、人工核查、错误修正和重复运行，而不是只比较每百万 Token 的标价。
团队如何使用这类助手
- 给出准确提交、文件和行号，避免让模型猜测代码版本。
- 要求回答区分代码事实、推断和未知信息。
- 对关键结论附上符号与调用路径，方便人工复查。
- 用最小测试验证变量值、异常路径和性能假设。
- 同一高风险问题运行多次，检查结论是否稳定。
- 记录错误断言和遗漏，按团队真实问题建立内部评分集。
RubberDuckBench 的核心结论不是 Claude Opus 4 或 GPT-5 谁以微小分差获胜，而是当前 AI 编程助手对上下文化代码问题仍缺乏稳定、完全正确的回答能力。它们适合加速定位与提出假设，最终结论仍应由代码证据和可执行验证决定。
