核心问题：把专家设计提供给 Agent，能否把“想不到好设计”与“实现不了好设计”这两种困难分开？
论文卡片
- 原题： D2K-Bench: Can LLM Agents Turn Expert Designs into Efficient GPU Kernels?
- 作者： Daifeng Li、Huiqiang Jiang、Chengruidong Zhang、Wei Wu、Xudong Guo、Jianhong Tu、Jianwei Zhang、Binhang Yuan、Dayiheng Liu。
- 版本： 2026-10-02 提交的 arXiv v1，30 页；分类 cs.LG、cs.AI、cs.DC。
- 定位： GPU kernel 生成的诊断型评测，关注专家知识与 Agent 能力边界。
- 入口： arXiv · HTML 全文（v1） · PDF（v1） · alphaXiv
简短导读
作者在 26 项任务、85 个工作负载上，对五个模型进行有无指导的配对实验：同样使用 B200、Triton 和 350 轮预算；指导包含算法、数据流、底层执行及其依赖，但不给专家源码。
总体性能分数从 1.46 升至 1.95。这里的基线是 Fable-5 无指导时的首个正确实现，不是专家实现；通过任务按延迟比取几何平均，失败任务记 0.5，再逐层聚合。因此分数同时反映速度与成功情况，不能全部解释为加速收益。
另一项评估让 LLM 在看不到运行时间时判断代码实现了哪些设计属性。它与性能的吻合主要展示在模型级汇总上，不是逐项诊断准确性的证明。以上为作者实验，导读未独立重跑。
重点读哪里
读 §2.3 理解指导的内容；读 §3.2–3.3 区分实测性能与模型评分；对照 §4.1–4.3、附录 A.4，注意固定轮数不等于固定 token 成本，累积添加指导也不等于各层作用彼此独立。
思想启发：帮助有效，不等于困难已被完全分解
以下是导读者的推论。
配对比较让“有没有这份帮助”变成可观察的差别，但并不自动把人的能力概念分解成两个互不影响的变量。设计提示可能同时减少搜索、改变注意力分配、提供判断候选的标准。结果改善可以说明这份信息有用，却未必能唯一确定原来的失败原因。
同样，“设计已给出”也不表示所有设计选择已结束。将抽象叙述变成代码时，仍可能需要补足表示、资源和数值行为之间的关系。把剩余困难统称为实现，有助于划定实验对象，却可能掩盖其中仍有设计活动。
这个区分使评测更有解释力，也提醒我们：一种有用的诊断分类，不必被当作智能内部已经得到证明的结构。
三个思考问题
1. 提供专家设计后仍然失败，足以说明缺的是实现能力吗？
如果指导本身存在隐含前提，或模型没有正确理解它，失败应归于设计、理解还是实现？这三个概念的边界应如何界定？
展开思考线索
“信息可见”与“信息已被理解”之间有距离。一个模型可能复述正确术语，却没有形成可执行的约束；也可能理解了目标，却无法协调相互依赖的选择。因此，指导后的差距更适合被看成待解释的剩余量，而不是纯粹实现能力的直接读数。
2. 如果一种更快的合法实现没有遵循专家路线，诊断分数应如何评价它？
评测究竟是在衡量“完成特定设计”，还是“解决原始问题”？两者发生冲突时，哪个应有优先权？
展开思考线索
前者适合检验知识传递，后者适合检验开放式创造。它们可以同时重要，却不必共享一把尺子。即使评分原则允许替代方案，判断“相同设计意图”仍可能受既有路线限制。反过来，快也不能单独说明采用了更好的设计：它可能只在某组输入上占优。
3. 相同轮数预算，是否足以让“指导带来的收益”具有公平的含义？
如果指导改变每轮处理的信息量和搜索路径，这个对照回答的是信息价值、计算效率，还是给定交互次数内的产物质量？
展开思考线索
公平并没有脱离研究问题的唯一答案。固定轮数适合比较相同交互机会下的结果；固定总计算量回答另一类问题。更深一层看，专家整理知识的成本位于实验边界之外。承认边界不会否定实验价值，但能阻止我们把局部收益扩展成总成本或普遍能力的结论。