CVPR 2026｜LLM会写3D视觉代码吗？清华联合智源用GeoCodeBench给出答案

如果把一篇最新的 3D 几何视觉论文、一个挖空关键函数的代码模板，一起交给大模型，它能否像真正的研究者一样，把论文里的几何推导和算法逻辑准确写成可执行代码，并通过一套严格的单元测试？

GeoCodeBench 给出的答案，说实话，不太乐观。

图 1: 主流 LLM 在 GeoCodeBench 上的通过率

最近，来自

等机构的研究团队，联合搞了一个新基准：。简单来说，这是一个专门针对 3D 几何计算机视觉的、PhD 级别的代码评测集。团队从 2025 年的 CV 顶会论文和官方代码仓库中，精心挑选了 47 个仓库，构建出 100 个问题实例，目的就是测一测大模型到底能不能「读懂论文、理解几何、写出正确代码」。

在论文最初的测试里，研究团队评测了 8 款主流的开源和闭源模型。结果相当出乎意料——

。

随着模型能力的快速迭代，GeoCodeBench 也在持续更新。根据最新的排行榜，团队又测试了 Claude Opus 4.7、Gemini 3.1 Pro 和 GPT-5.5 等新一代前沿模型。结果很有意思：

。

图 2: GeoCodeBench 主页最新 Leaderboard

为什么要做这样一个 benchmark？

这些年，AI coding 在通用软件工程领域确实是突飞猛进，但 3D 几何视觉完全不是一回事。这不是普通的软件开发，它要求模型同时吃透几何变换、投影关系、法线计算，还得理解光学和力学公式，搞懂多视图与多模态流程，以及论文里那些特定模块的逻辑。

具体来说，模型不仅要

，更棘手的是，它必须把论文里那些。

如果模型真能稳定完成这类任务，那它就不再只是个「写代码助手」，而可能成为真正意义上的 3D 视觉研究助手：帮研究者自动原型化模型、加速研究迭代，甚至降低 3D 算法开发的门槛。这，才是这项工作背后真正的野心。

这项工作最值得强调的三点贡献

1. 首个面向 3D 几何视觉 PhD 级 coding 的执行式 benchmark

这不是一个泛泛的代码题库，而是专门针对 3D geometric computer vision，强调 paper-to-code 和科研级实现能力的评测。

表 1: 代表性基准测试与 GeoCodeBench 的能力覆盖范围对比

2. 自动化构建 + 专家在环 + 高覆盖单元测试

构建过程中，团队没有简单依赖自动抽取工具，而是请来了 3D 视觉领域的研究专家进行人工筛选，确保留下的都是最能体现核心几何和算法逻辑的函数。同时，每道题都配备了高覆盖率的单元测试，连边缘情况都考虑在内，保证了评测的可执行性和判分的可靠性。

3. 首次揭示大模型的关键短板：会做 3D 几何题，不等于会写 3D 论文代码

GeoCodeBench 最有价值的地方，不只是又提供了一个新 benchmark，而是清楚揭示了当前大模型在 3D 视觉研究编程中的核心短板——它们可能懂几何，但还没法稳定地把论文方法写成能通过测试的正确代码。实验显示，模型在通用 3D 几何知识题上表现还不错，但一旦要严格遵循论文设定去实现研究级模块，成功率就会明显下滑。

Benchmark 构建方法

和常见的代码 benchmark 不同，GeoCodeBench 不是手工编几道 3D 编程题，而是直接从

。研究团队先选了 2025 年顶会的 3D 视觉论文及其对应的开源仓库，最终构建出 47 个仓库、100 个问题实例。这些题目不是泛泛的任务，而是真实研究 pipeline 中的关键函数。

为了让模型能理解论文内容，团队先用 OCR 工具把 PDF 中的文本、公式和图像抽取出来，整理成结构化输入；同时，从代码仓库里自动挖掘候选函数。然后，研究者们对这些候选函数进行人工筛选，只保留最能代表核心几何和算法逻辑的实现，并把函数体挖空，构造成 fill-in-the-function 任务。

图 3: GeoCodeBench 的基准测试构建与评估流程概览

除了构建 benchmark，

还有一个很有辨识度的设计：它把任务拆成了两类。

• General 3D Capability
  ：主要考察几何变换、基础光学与力学公式；

• Research Capability
  ：更关注模型能否按照论文逻辑实现新模块、处理 paper-specific 的几何耦合与系统逻辑。

这套设计的好处在于，它不只告诉我们模型「分高不高」，还进一步回答了一个更关键的问题：模型到底是 3D 几何知识不够，还是虽然懂几何，但不会按照论文把方法真正写成代码。

图 4: GeoCodeBench 的题目分类

图 5: GeoCodeBench 的类别分布与函数示例

有了题目之后，下一个关键问题是：怎么评分？

GeoCodeBench 采用执行式评测。研究团队为每道题自动生成一组高覆盖的单元测试，既覆盖默认输入，也覆盖了各种边界情况。这些单元测试经过专家手工核对，确保没问题。

评测时，模型拿到的是三部分内容：

，以及。模型补全函数后，系统会直接运行单元测试，以通过率作为最终得分。换句话说，这里比的不是「代码看起来像不像」，而是能不能真正跑通。

图 6: 给 LLM 的输入与详细提示词

整体结果：GPT-5 也只有 36.6%

表 2: 论文原始评测中展示的主流 LLM 在 GeoCodeBench 的得分

在论文最初的测试中，作者对 8 款开源与闭源大模型做了全面评估。结果让人意外：即便是当时最好的模型 GPT-5，在 GeoCodeBench 上也只拿到了

的通过率。

随着模型迭代，团队又测试了 Claude Opus 4.7、Gemini 3.1 Pro 和 GPT-5.5 等新一代模型。其中，

的整体通过率排在首位。

表 3: 最新 LLM 在 GeoCodeBench 的得分对比

这组数据直观地说明，当前的 AI 能力与生成「可靠、严谨的 3D 科学代码」之间，还存在一条巨大的鸿沟。复杂的 3D 几何视觉任务，依然是目前大模型很难轻易跨越的壁垒。

与此同时，在分析 LLM 回答正确的例子时，作者观察到一个有意思的现象：

。以极线距离计算为例，不同模型给出了截然不同的实现路径。有的模型直接在像素坐标系中基于 Fundamental Matrix 求解，也有的先把点变到归一化坐标系，再通过 Essential Matrix 计算。两种写法不同，但在数学上等价，最终都通过了测试。

图 7: Creative Correctness 的例子，不同模型为同一问题实现了互异但数学等价的代码路径

会做几何题，不等于会写论文代码

实验结果表明，General 3D Capability 和 Research Capability 两类能力虽然存在正相关，但差距非常明显：

换句话说，很多模型「懂几何」，但一旦任务变成按照论文设定去补全一个 paper-specific 模块，性能就会明显掉下来。3D 几何知识，和按照论文写出正确代码、并通过测试的能力之间，还隔着一条很深的鸿沟。

图 8: 模型的通用 3D 能力和研究能力的关系

图 9: Case Study: 通用 3D 理解与研究级实现能力之间的差异

如图 7 所示，左图中 DeepSeek-R1 可以正确完成一个基础 3D 几何任务：利用三角函数将二维图像坐标映射到三维球面坐标，说明它已经具备较强的通用几何知识。但右图中，面对论文中的特定函数，模型却没有正确实现所需逻辑——它把原本要求的 Yin 与 Yang 之间的双向互投影，误写成了彼此分离的单向投影。这个案例清楚说明，

给模型更多论文内容，不一定更有帮助

图 10: 不同上下文长度对性能影响的消融实验结果

作者比较了三种输入设置：

。按常理，更多上下文应该更有利于模型补全代码，但实验结果恰恰相反。多数模型在「」时表现最好，而整篇论文往往会带来更多噪声——冗长的引言、实验描述和无关细节，反而拖累了效果。换句话说，当前大模型并不是「论文喂得越多越好」，它们对长上下文 scientific content 的利用能力仍然非常有限。

最大的问题不是语法错误，而是功能逻辑错误

为了更细致地分析失败原因，作者把错误分成了 Shape Error、Syntax Error、Import Error、Type Error 和 Functional Error 五类。结果发现，

。这意味着，很多模型写出来的代码表面上看没什么问题，语法对、接口也对，甚至能运行，但它实现的功能根本不是论文要求的几何逻辑。相比之下，单纯的语法错误和 import 错误反而不是主要矛盾。这也解释了为什么 GeoCodeBench 比很多通用 coding benchmark 更难——它难的不是「写代码」，而是

图 11: 不同模型在 GeoCodeBench 上的错误分布

为什么这项工作值得长期关注？

GeoCodeBench 的价值，不只是又做了一个 leaderboard。更重要的是，它第一次把一个过去常被模糊讨论的问题测清楚了：

论文也明确指出，GeoCodeBench 是一个可以持续扩展的基准。随着新的 3D vision 论文不断出现，新任务可以通过相同流程持续并入。这意味着，