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

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

GeoCodeBench 给出的答案并不乐观。

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

近日，来自清华大学智能产业研究院（AIR）的团队联合北京智源研究院（BAAI）、北京大学、南京大学等机构构建了一个基准：GeoCodeBench。

这是一个面向 3D 几何计算机视觉的 PhD 级 coding benchmark，团队从 2025 年 CV 顶会论文和官方仓库中构建任务，最终形成了 47 个仓库、100 个问题实例，专门评测大语言模型是否真的能「读懂论文、理解几何并写出正确代码」。

在论文原始评测中，研究团队测试了 8 个代表性开源和闭源模型。结果显示，即便是当时表现最强的 GPT-5，整体通过率也只有 36.6%。

随着模型能力快速迭代，GeoCodeBench 也在持续更新。根据最新 leaderboard，团队进一步评测了 Claude Opus 4.7、Gemini 3.1 Pro 和 GPT-5.5 等新一代前沿模型。其中，Claude Opus 4.7 取得 49.4% 的整体通过率，位列第一。

图 2: GeoCodeBench 主页最新 Leaderboard

• 论文标题：Benchmarking PhD-Level Coding in 3D Geometric Computer Vision
• 项目主页： https://geocodebench.github.io/
• 论文链接：https://arxiv.org/abs/2603.30038
• 代码仓库：https://github.com/geocodebench/GeoCodeBench

为什么要做这样一个 benchmark？

过去几年，AI coding 已经在通用软件工程中取得显著进展，但 3D 几何视觉并不是普通的软件开发问题。

它要求模型同时具备对几何变换、光学与力学公式、多视图与多模态流程，以及 paper-specific 模块逻辑的精确理解。

具体来说，它不仅要懂坐标变换、投影、法线、交点、优化等基础几何算子，解析光学、物理约束和渲染公式，更难的是，还要把论文中的新方法、隐含约定和边界条件真正翻译成代码。

如果模型能够稳定完成这些任务，它将不仅仅是一个「写代码助手」，而可能成为真正意义上的 3D 视觉研究助手：帮助研究者自动原型化模型、加速研究迭代，甚至降低 3D 算法开发的门槛。

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

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

它不是泛泛的代码题库，而是明确面向 3D geometric computer vision，强调 paper-to-code 与研究级实现能力。

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

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

在构建过程中，团队并没有简单依赖自动抽取，而是引入了 3D 视觉研究专家进行人工筛选，确保留下的都是最能代表核心几何和算法逻辑的函数。

同时，每道题目都配备了高覆盖、包含 edge cases 的单元测试，用来保证 benchmark 的可执行性和判分可靠性。

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，GeoCodeBench还做了一个很有辨识度的设计：它把任务拆成了两类。

• 一类是 General 3D Capability：主要考察几何变换、基础光学与力学公式；
• 另一类是 Research Capability：更关注模型能否按照论文逻辑实现新模块、处理 paper-specific 的几何耦合与系统逻辑。

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

图 4: GeoCodeBench 的题目分类

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

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

GeoCodeBench 采用的是执行式评测。研究团队为每道题自动生成一组高覆盖单元测试，既覆盖默认输入，也覆盖 edge cases。单元测试经过专家手工核对。

评测时，模型拿到的是三部分内容：结构化论文内容、挖空后的代码骨架，以及统一执行模板。模型补全函数后，系统会直接运行单元测试，并以通过率作为最终得分。也就是说，这里比的不是「代码看起来像不像」，而是能不能真正跑通。

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

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

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

在论文原始评测中，作者对的 8 款开源与闭源大模型进行了全面评估。令人惊讶的是，即使是当时最好的模型 GPT-5 在 GeoCodeBench 上也仅取得了36.6%的通过率。

随着模型的更新，团队进一步评测了 Claude Opus 4.7、Gemini 3.1 Pro 和 GPT-5.5 等新一代前沿模型。其中，Claude Opus 4.7 取得 49.4%的整体通过率，位列第一。

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

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

于此同时，分析 LLM 回答正确的例子，作者观察到一个有意思的现象：Creative Correctness。以极线距离计算为例，不同模型给出了不同实现路径。有的模型直接在像素坐标系中基于 Fundamental Matrix 求解，也有模型先把点变到归一化坐标系，再通过 Essential Matrix 计算。两种写法不同，但在数学上等价，最终都通过了测试。

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

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

实验结果显示，General 3D Capability 和 Research Capability 两类能力虽然存在正相关，但差距非常明显：模型在通用 3D 几何知识上的表现，普遍好于研究级实现能力。

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

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

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

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

这个案例说明，当前大模型即便掌握了一定的 3D 几何知识，在基于论文内容完成细粒度、过程化的研究代码实现时，仍然存在明显短板。

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

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

作者比较了三种输入设置：不给论文、只给到 Method 章节、给整篇论文。按直觉，更多上下文似乎应该更有利于模型补全代码；但实验结果恰恰不是这样。

多数模型在「只给到 Method」时表现最好，而整篇论文往往会带来更多噪声，比如冗长的引言、实验描述和无关细节，反而拖累效果。换句话说，当前大模型并不是「论文喂得越多越好」，它们对长上下文 scientific content 的利用能力仍然有限。

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

为了更细致地分析失败原因，作者把错误分成了 Shape Error、Syntax Error、Import Error、Type Error 和 Functional Error 五类。结果显示，Functional Error 是最主要的失败来源。

这意味着，很多模型写出来的代码表面上看没什么问题，语法对、接口也对，甚至能够运行，但它实现出来的并不是论文真正要求的几何逻辑。相比之下，单纯的语法错误和 import 错误反而不是主要矛盾。

这也解释了为什么 GeoCodeBench 会比很多通用 coding benchmark 更难：它难的不是「写代码」，而是把论文里的隐含几何语义、实现约定和边界条件真正写对。

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

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

GeoCodeBench 的价值，不只是又做了一个 leaderboard。

更重要的是，它第一次把一个过去常被模糊讨论的问题测清楚了：

从通用 coding 走向可信赖的 scientific coding，尤其是在 3D 几何视觉这样的高门槛领域，中间还有一条很长的路。

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

这意味着，GeoCodeBench 不只是一个静态评测集，它更有潜力成为未来 automated research agents，甚至「auto 3D vision scientist」的基础设施。