2026年 Coding 方向 Benchmark 调研报告

调研目标：搜索2026年至今与 coding 方向相关的 benchmark，寻找值得做研究的方向。只列出有公开可用代码仓库的 benchmark，纯论文无代码的不列入。
调研时间：2026年7月3日
数据来源：arxiv（通过 ArxivSearcher 迭代搜索）+ GitHub 仓库可用性验证
覆盖范围：2025年2月 — 2026年7月发布的 coding 相关 benchmark
筛选标准：仅有公开可用代码仓库/数据集的 benchmark 才被列入，纯论文无代码的已排除

一、总览与背景

1.1 为什么要做这份调研？

大语言模型（LLM）在编程领域的应用正在从"写一个函数"进化到"独立完成整个软件开发任务"。2023年 OpenAI 发布 HumanEval 开创了代码生成评测的先河——模型只需写出一个 Python 函数，通过几个测试用例就算成功。

然而真实的软件工程远不止于此：开发者需要在百万行代码的仓库中定位问题、跨多个文件做修改、确保不破坏已有功能、写出安全且可维护的代码。2023年底 SWE-bench 的发布将评测标准提升到"解决真实 GitHub issue"的层面，但随之而来的是大量变体和全新方向的 benchmark 涌现。

这份报告的核心问题是：在2025-2026年的最新工作中，哪些 benchmark 有可用代码仓库？每个 benchmark 重点测试什么问题？哪些方向还值得做？

1.2 搜索与筛选过程

通过 40 轮迭代搜索（覆盖 SWE-bench 变体、代码生成、修复、审查、重构、安全、测试、翻译迁移、前端/UI、形式化验证、硬件/RTL、数据科学、竞技编程、GUI Agent、SQL、长上下文、多智能体、工具调用、自我进化、低资源语言等 20+ 子方向），去重后获得 596 篇 唯一论文，其中标题含 “Bench” 且与 coding 强相关的候选 112 篇。

经逐一核查 arxiv 页面、GitHub API 验证、GitHub 搜索交叉验证，最终确认 33 个 benchmark 拥有公开可用仓库或数据集。

1.3 方向分布总览

方向已验证可用数一句话说明测试什么
仓库级软件工程 / Coding Agent8Agent 能否在真实仓库中解决 issue、开发新功能
代码审查 (Code Review)2AI 能否像人一样审查 Pull Request
代码生成与评估4模型生成的代码质量如何
代码重构0 ⚠️空白方向！ 改善代码结构而不改变行为
形式化验证代码生成2生成的代码能否被数学证明是正确的
代码迁移与翻译2能否把旧代码迁移到新环境/新版本
前端 / Web / 多模态3从设计图/描述生成前端网页代码
安全 / 漏洞2生成的代码是否安全、Agent 是否可被攻击
硬件 / RTL / HDL3能否生成芯片设计代码（Verilog/VHDL）
竞技编程与推理2在高难度算法题中的表现
数据科学与工具调用2能否使用工具完成数据分析任务
GUI / 桌面 Agent3能否操作桌面图形界面

二、详细 Benchmark 清单（按方向分组）

阅读指南：每个 benchmark 条目包含以下字段——

  • 🎯 测试什么问题：这个 benchmark 到底在评估模型的什么能力（这是本报告的重点）
  • 背景与动机：为什么这个问题重要、现有 benchmark 的什么不足催生了它
  • 任务形式：具体怎么测试（输入什么、输出什么、怎么判分）
  • 规模与发现：有多少任务、最强模型表现如何
  • 仓库地址：GitHub/HuggingFace 链接
  • 研究价值：对研究者来说值不值得跟进

A. 仓库级软件工程 / Coding Agent（8个）

这个方向在测什么？ 传统代码 benchmark（如 HumanEval）只让模型写一个独立函数。但真实软件开发中，开发者面对的是包含数千个文件、数百万行代码的仓库。Agent 需要自主探索仓库、定位需要修改的代码、编辑多个文件、运行测试验证。这就是 SWE-bench 开创、这8个 benchmark 深化的方向。

1. SWE-PolyBench — 多语言仓库级 Agent 评测

  • arxiv: 2504.08703 | 仓库: ✅ https://github.com/amazon-science/SWE-PolyBench
  • 🎯 测试什么问题：SWE-bench 只测 Python。但真实世界里 Agent 可能需要修 Java 的 bug、改 TypeScript 的类型、调 C# 的逻辑。模型在不同编程语言上的仓库级 issue 解决能力是否一致？
  • 背景：SWE-bench 是当前最有影响力的仓库级 benchmark，但它 100% 是 Python。亚马逊团队认为这无法反映真实多语言场景。
  • 任务形式：从真实 GitHub 仓库收集已解决的 issue，要求 Agent 提交一个 patch，用对应的单元测试验证是否解决。覆盖 Python/Java/TypeScript/JavaScript/C# 五种语言。
  • 发现：模型在非 Python 语言上的表现显著下降，说明现有 Agent 对 Python 过拟合。
  • 研究价值: ⭐⭐⭐ 如果你的研究涉及多语言代码，这是必跑的 benchmark。

2. SWE-Bench-CL — Agent 的持续学习能力

  • arxiv: 2507.00014 | 仓库: ✅ https://github.com/thomasjoshi/agents-never-forget
  • 🎯 测试什么问题：现有的 SWE-bench 测试每个 issue 都是独立的——Agent 解决完一个就忘掉，下一个从头开始。但真实开发者在同一个项目中会积累经验。Agent 能否跨任务积累知识，越做越好？
  • 背景：想象一个 Agent 连续解决同一个仓库的100个 bug。理想情况下它应该"越做越熟"，但现有 Agent 可能反而被早期任务误导（灾难性遗忘）。
  • 任务形式：给 Agent 一个仓库的连续 issue 序列，测量它解决后续 issue 的成功率是否随经验增加而提升，以及是否出现遗忘。
  • 研究价值: ⭐⭐⭐ 持续学习是 Agent 从"玩具"走向"可部署工具"的关键。

3. SWE-Skills-Bench — Agent 技能消融实验

  • arxiv: 2603.15401 | 仓库: ✅ https://github.com/GeniusHTX/SWE-Skills-Bench
  • 🎯 测试什么问题：现在很多 Agent 系统设计了各种"技能模块"——代码搜索、测试生成、错误修复等。这些模块到底有没有用？去掉某个模块对性能影响多大？
  • 背景：Agent 框架越来越复杂，但很少人做过严格的消融实验。这个 benchmark 就是为消融研究设计的。
  • 任务形式：将 SWE 任务分解为细粒度技能（定位、搜索、编辑、验证等），分别评估每个技能的单独表现和组合效果。
  • 研究价值: ⭐⭐ 对 Agent 架构设计的消融研究有价值。

4. OmniCode — 全生命周期 Agent 评测

  • arxiv: 2602.02262 | 仓库: ✅ https://github.com/seal-research/OmniCode
  • 🎯 测试什么问题：一个 Agent 在软件开发的全生命周期（需求理解→代码搜索→编辑→测试→调试）中各环节表现如何？
  • 背景：大多数 benchmark 只看最终结果（issue 是否被解决），但开发者关心的是 Agent 在哪个环节最容易出错。
  • 任务形式：综合评测涵盖代码理解、生成、编辑、测试、调试等多个维度的能力，提供细粒度的能力画像。
  • 研究价值: ⭐⭐ 提供比"pass/fail"更丰富的诊断信息。

5. FeatureBench — 端到端特性开发（ICLR 2026）

  • arxiv: 2602.10975 | 仓库: ✅ https://github.com/LiberCoders/FeatureBench
  • 🎯 测试什么问题：SWE-bench 测的是"修 bug"，但开发者的日常工作中有大量是"加新功能"。Agent 能否从零开始实现一个完整的新特性，而不只是修一个已有问题？
  • 背景：修 bug 和加功能是两种截然不同的任务。修 bug 只需定位并修复，加功能需要理解架构、设计接口、编写新代码、确保兼容性。后者难度远高于前者。
  • 任务形式：从开源仓库的 commit 历史中，沿着测试依赖图追踪出"特性级"任务——这些任务跨越多个 commit 和 PR，需要多步实现。自动从单元测试派生任务，确保可验证。
  • 规模: 200个高难度任务，3825个可执行环境，24个开源仓库。
  • 亮点: Claude 4.5 Opus 在 SWE-bench 上达 74.4% 解决率，但在 FeatureBench 上仅 11.0%。这个差距清楚地说明：修 bug 和加功能是两个完全不同难度级别的任务。
  • 研究价值: ⭐⭐⭐ 如果你关注"AI 能否真正独立开发软件"，这是最前沿的 benchmark。

6. General AgentBench — Test-Time Scaling 行为

  • arxiv: 2602.18998 | 仓库: ✅ https://github.com/cxcscmu/General-AgentBench
  • 🎯 测试什么问题：当前 AI 领域最火的话题之一是"test-time scaling"——给模型更多推理时间/算力，它能否做得更好？Agent 在搜索、编程、推理、工具调用上的性能随推理算力增加如何变化？
  • 任务形式：综合评测（搜索+编程+推理+工具调用），系统地改变推理预算（采样次数、思考链长度等），观察性能变化。
  • 发现: 序列扩展（让模型想更久）存在"上下文天花板"——想太久反而会跑偏；并行扩展（多采样取优）存在"验证鸿沟"——如何判断哪个答案更好本身就很困难。
  • 研究价值: ⭐⭐ test-time scaling 是当前热点，这个 benchmark 揭示了其根本局限。

7. FEA-Bench — 增量特性开发（ACL 2025 Main）

  • arxiv: 2503.06680 | 仓库: ✅ https://github.com/microsoft/FEA-Bench
  • 🎯 测试什么问题：在已有代码仓库中增加一个新功能，需要同时具备两种能力：(1) 编写新组件的代码补全能力；(2) 修改已有代码以适配新功能的编辑能力。现有 LLM 在这两种能力上是否均衡？
  • 背景：微软团队发现，增量开发是软件工程的日常核心工作，但缺少专门的评测。HumanEval 测纯生成，SWE-bench 测 bug 修复，都不够。
  • 任务形式：从83个 GitHub 仓库收集标记为"新功能"的 PR，每个任务配有单元测试验证实现是否正确。模型需要基于 PR 描述，生成完整的功能代码。
  • 发现：LLM 在 FEA-Bench 上表现显著低于在 SWE-bench 上的表现，说明增量开发比 bug 修复更具挑战性。
  • 研究价值: ⭐⭐⭐ 来自微软，工业级场景，数据质量高。

8. VISTA — 视觉规格→Web 应用

  • arxiv: 2605.26144 | 仓库: ✅ https://github.com/kaboider/VISTA_Bench | 项目页: 🌐 https://kaboider.github.io/VIS_APP/
  • 🎯 测试什么问题：给 Agent 一张网页设计稿或视觉规格，它能否端到端地生成完整的 Web 应用？不只是生成 HTML 片段，而是能运行的完整应用。
  • 任务形式：输入视觉规格（设计图/截图/描述），要求 Agent 输出完整的可运行 Web 应用，通过渲染对比和功能测试评分。
  • 研究价值: ⭐⭐ 视觉→代码的 agentic 评估，跨模态方向。

B. 代码审查 Code Review（2个）

这个方向在测什么？ 代码审查（Code Review）是软件开发中保证质量的关键环节——开发者提交代码后，需要由其他开发者审查（Review）才能合并。这个方向测试 AI 能否自动完成高质量的代码审查：发现问题、给出建议、评估质量。

9. AACR-Bench — 仓库级自动代码审查

  • arxiv: 2601.19494 | 仓库: ✅ https://github.com/alibaba/aacr-bench
  • 🎯 测试什么问题：一个好的代码审查需要理解整个仓库的上下文——不只看改了几行代码，还要理解这段代码在系统中的角色、与哪些模块交互、是否符合项目规范。LLM 能否在完整仓库上下文下给出专业级的代码审查意见？
  • 背景：现有的代码审查评测只看 PR 本身的 diff（代码差异），忽略了仓库上下文。阿里巴巴团队认为这不符合实际——真实审查者一定是在理解项目全貌的基础上审查的。
  • 任务形式：给定一个 PR 和其所属仓库的完整上下文，要求模型生成审查评论。与人类开发者的真实审查评论对比评分。
  • 研究价值: ⭐⭐⭐ 来自阿里巴巴工业界，仓库级上下文是关键创新。

10. Code Review Agent Benchmark (c-CRAB)

  • arxiv: 2603.23448 | 仓库: ✅ https://github.com/c-CRAB-Benchmark
  • 🎯 测试什么问题：Agent 形态的代码审查——不只是静态分析 diff，而是像人一样主动探索仓库、理解上下文、给出全面的审查意见。
  • 研究价值: ⭐⭐ 专注 Agent 形态的 code review。

C. 代码生成与评估（4个）

这个方向在测什么？ 最经典的评测方向：给模型一个编程题目，看它生成的代码质量如何。但这里列出的不是简单的 HumanEval 变体，而是在任务设计上有创新的 benchmark——动态生成、长上下文、数据科学专用等。

11. DynaCode — 动态复杂度感知 Benchmark（ACL 2025 Findings）

  • arxiv: 2503.10452 | 仓库: ✅ https://github.com/HWH-2000/DynaCode
  • 🎯 测试什么问题：静态 benchmark（如 HumanEval 只有164题）面临一个致命问题——数据污染：这些题目可能已经出现在模型的训练数据中了。能否动态生成无限量的编程题，让模型永远无法"背诵"答案？
  • 背景：当你用 HumanEval 测试 GPT-4 时，它可能已经"见过"这些题目了。DynaCode 的解决方案是自动生成嵌套结构的编程题，控制难度层级，使得每次评测的题目都是新鲜的。
  • 任务形式：动态生成不同复杂度的代码生成任务（支持条件嵌套、循环嵌套等结构），理论上可生成 1.89亿 个唯一问题。按复杂度分层评估。
  • 研究价值: ⭐⭐⭐ 动态生成+抗污染是 benchmark 设计的重要趋势。如果你担心你的模型在 HumanEval 上"作弊"了，用 DynaCode。

12. DSCodeBench — 数据科学代码生成

  • arxiv: 2505.15621 | 仓库: ✅ https://github.com/ShuyinOuyang/DSCodeBench
  • 🎯 测试什么问题：数据科学代码（Pandas/NumPy/Matplotlib 等）和通用编程代码很不一样——它通常是探索性的、交互式的、面向数据操作的。LLM 能否写出高质量的数据科学代码？
  • 背景：现有 benchmark 偏重算法和数据结构题，但实际工作中大量代码是数据处理、可视化、统计分析。DSCodeBench 专门评测这类任务。
  • 任务形式：1000道题，来自10个最常用的 Python 数据科学库（Pandas、NumPy、Matplotlib、Scikit-learn 等）。每题配有强测试套件。
  • 发现: GPT-4o 的 pass@1 仅 0.392——即使是最好的模型，在数据科学代码生成上也只有不到40%的成功率。
  • 研究价值: ⭐⭐⭐ 数据科学是 AI 最有价值的应用领域之一，这个 benchmark 填补了重要空白。

13. LoCoBench — 长上下文软件工程

  • arxiv: 2509.09614 | 仓库: ✅ https://github.com/SalesforceAIResearch/LoCoBench
  • 🎯 测试什么问题：真实仓库动辄数十万行代码，远超模型的上下文窗口。即使有 128K 上下文的模型，在百万行代码仓库中也力不从心。LLM 在大规模代码库中的理解、检索、推理能力如何？
  • 背景：来自 Salesforce AI Research，专门针对"长上下文"场景设计。
  • 任务形式：构建需要理解大量代码上下文才能回答的问题，包括代码搜索、跨文件依赖追踪、仓库级问答等。
  • 研究价值: ⭐⭐⭐ 长上下文代码理解是当前模型的关键瓶颈——上下文窗口虽大，但"有效利用"长上下文的能力还很弱。

14. SolEval — Solidity 智能合约生成（EMNLP 2025 Main）

  • arxiv: 2502.18793 | 仓库: ✅ https://github.com/pzy2000/SolEval
  • 🎯 测试什么问题：Solidity 是以太坊智能合约的编程语言。智能合约直接管理资金，代码错误可能导致数百万美元损失。LLM 能否生成正确且安全的仓库级 Solidity 代码？
  • 任务形式：仓库级 Solidity 代码生成任务，评估生成代码的功能正确性和安全性。
  • 研究价值: ⭐⭐ 智能合约/区块链领域专用。

D. 代码重构 — ⚠️ 空白方向！

这个方向在测什么？ 代码重构是指在不改变代码外部行为的前提下，改善其内部结构——让代码更可读、更高效、更易维护。这和修 bug 不同（bug 修复改变行为），和写新代码也不同（重构是改已有的）。

现状: SWE-Refactor（2602.03712）和 SmellBench（2606.05574）是两个重要论文，但截至调研时均未公开仓库。这意味着当前0个有公开可用仓库的代码重构 benchmark。

这是本报告发现的最大研究空白——详见第三节方向预测。

E. 形式化验证代码生成（2个）

这个方向在测什么？ 形式化验证（Formal Verification）是数学上证明代码正确性的方法。普通的测试只能说"这几个输入通过了"，形式化验证可以说"对所有可能的输入，代码的行为都是正确的"。这是代码质量的最高保证，但极难做到。这个方向测试 LLM 能否生成可以被数学证明为正确的代码。

15. CLEVER — Lean 可验证代码生成

  • arxiv: 2505.13938 | 仓库: ✅ https://github.com/trishullab/clever + https://github.com/trishullab/clever-prover
  • 数据集: 📦 https://huggingface.co/datasets/amitayusht/clever
  • 🎯 测试什么问题：可验证代码生成需要同时完成三件事：(1) 生成功能代码；(2) 生成形式化规格（specification，定义代码应该满足什么性质）；(3) 生成数学证明，证明代码确实满足规格。LLM 能否端到端完成这三步？
  • 背景：来自 Trishul Lab（斯坦福）。Lean 是一种交互式定理证明器——用 Lean 写的证明可以被计算机 100% 验证，不存在"看起来对但实际错了"的可能。
  • 任务形式：161道 Lean 编程题。模型需要同时生成代码、规格和证明。使用 Lean 编译器自动验证。
  • 发现：即使是最好的模型，证明生成的成功率也极低。这揭示了当前 LLM 在严格逻辑推理上的根本局限。
  • 研究价值: ⭐⭐⭐ 形式化保证的代码生成是"AI 写出绝对正确代码"的终极目标。

16. VERINA — 可验证代码生成 Arena

  • arxiv: 2505.23135 | 仓库: ✅ https://github.com/sunblaze-ucb/verina
  • 数据集: 📦 https://huggingface.co/datasets/sunblaze-ucb/verina
  • 🎯 测试什么问题：与 CLEVER 类似，但更全面——同时评估代码生成、规格生成、证明生成三个独立维度，以及它们的组合能力。
  • 任务形式：189个手工精选的 Lean 编程任务。支持模块化评测——可以单独测代码（不看规格和证明）、单独测规格、单独测证明，也可以测组合。
  • 发现: OpenAI o3 的代码正确率达 72.6%，规格正确率 52.3%，但证明成功率仅 4.9%。这说明模型"写代码"还行，“证明代码正确"几乎做不到。
  • 研究价值: ⭐⭐⭐ 三位一体的全面评估框架。如果你的研究涉及形式化方法 + LLM，这是必看的 benchmark。

F. 代码迁移与翻译（2个）

这个方向在测什么？ 代码迁移（Migration）是指把代码从一个环境/版本/语言转移到另一个——比如从 Java 8 升级到 Java 21、从 Python 2 迁移到 Python 3、从一个库切换到另一个库。这是企业中极其常见但极其痛苦的工作。

17. MigrationBench — Java 版本迁移

  • arxiv: 2505.09569 | 仓库: ✅ https://github.com/amazon-science/MigrationBench
  • 数据集: 📦 HuggingFace (AmazonScience collection)
  • 🎯 测试什么问题：大量企业代码停留在 Java 8，需要迁移到更高版本（Java 11/17/21）。这不是简单的语法替换，可能涉及废弃 API 的替换、新特性的适配、依赖冲突的解决。LLM 能否自动化完成这种仓库级的版本迁移？
  • 背景：来自亚马逊，直接来自工业界的真实痛点。
  • 任务形式：真实的 Java 8 仓库，要求迁移到高版本，通过编译和测试验证。
  • 研究价值: ⭐⭐⭐ 工业级迁移场景，商业价值极高。

18. CODEMENV — 代码环境/依赖迁移

  • arxiv: 2506.00894 | 仓库: ✅ https://github.com/xdshen-ai/Benchmark-of-Code-Migration
  • 🎯 测试什么问题：有时候不需要换语言版本，而是换一个库或依赖——比如从 requests 换到 httpx、从 pandas 换到 polars。这需要理解两个库的 API 差异并做正确的替换。
  • 研究价值: ⭐⭐ 依赖管理是实际痛点。

G. 前端 / Web / 多模态（3个）

这个方向在测什么？ 前端代码生成是 LLM 编程最直观的应用之一——“给我画个网页”。但生成一个好的前端代码需要同时理解视觉设计（布局、颜色、交互）和工程实现（HTML/CSS/JavaScript/React 框架）。这个方向测试多模态 LLM 能否从设计图/描述生成高质量前端代码。

19. DesignBench — 多模态前端代码生成

  • arxiv: 2506.06251 | 仓库: ✅ https://github.com/WebPAI/DesignBench
  • 🎯 测试什么问题：给定一张网页设计图（UI 截图），多模态 LLM 能否生成在视觉上忠实于设计图的前端代码？ 不只是"差不多像”，而是像素级精确还原。
  • 研究价值: ⭐⭐ 设计稿→前端代码的能力评估。

20. FronTalk — 对话式前端开发

  • arxiv: 2601.04203 | 仓库: ✅ https://github.com/shirley-wu/frontalk
  • 🎯 测试什么问题：真实的前端开发不是"一次生成"，而是多轮对话迭代——开发者说"加个按钮"，AI 加了，开发者说"颜色不对，改成蓝色"，AI 改了……LLM 能否在这种对话式迭代中持续改进前端代码？
  • 背景：将前端开发建模为对话过程，而非单次生成。带多模态反馈——可以看到渲染效果并调整。
  • 研究价值: ⭐⭐⭐ 对话式/迭代式开发场景有创新性，更贴近真实使用方式。

21. WebRSSBench — Web 理解三维评估

  • arxiv: 2509.21782 | 仓库: ✅ https://github.com/annoy-worker/WebRSSBench
  • 🎯 测试什么问题：在生成前端代码之前，模型首先需要理解网页——理解布局结构、推理交互逻辑、抵御对抗性干扰。多模态 LLM 对 Web 页面的理解能力如何？
  • 任务形式：三维度评估：(1) 推理——理解页面逻辑和交互关系；(2) 鲁棒性——面对视觉噪声/干扰时的稳定性；(3) 安全——识别页面中的恶意元素。
  • 研究价值: ⭐⭐ Web 理解是前端生成的前提能力。

H. 安全 / 漏洞（2个）

这个方向在测什么？ AI 生成的代码可能有安全漏洞——SQL 注入、XSS 攻击、缓冲区溢出等。更严重的是，AI Agent 本身也可能被攻击者利用社会工程手段操控。这个方向测试代码安全性和 Agent 安全性。

22. SEVRA-BENCH — 恶意 PR 攻击下的 Review Agent 鲁棒性

  • arxiv: 2606.13757 | 仓库: ✅ https://github.com/rufimelo99/malicious-pr-bench
  • 数据集: 📦 https://huggingface.co/datasets/RedAI4Code/SEVRA
  • 🎯 测试什么问题：如果攻击者提交一个看起来正常但实际包含恶意代码的 PR，AI 审查 Agent 能否识破？随着越来越多项目使用 AI 做 Code Review，攻击者会专门针对 AI 的弱点设计"骗过 AI"的恶意代码。
  • 背景：这是一个全新的安全威胁模型——不只是"代码有没有漏洞"，而是"AI 审查系统本身是否可被攻击"。
  • 任务形式：构造包含隐蔽恶意代码的 PR，测试 Code Review Agent 能否检测出来。
  • 研究价值: ⭐⭐⭐ Agent 安全是一个全新且重要的视角，随着 AI Agent 广泛部署，这个问题会越来越紧迫。

23. DualGauge — 安全+功能联合评估

  • arxiv: 2511.20709 | 仓库: ✅ https://github.com/SRestLabUB/DualGauge
  • 🎯 测试什么问题：一段代码可能"功能正确"（测试通过了）但"不安全"（存在漏洞）。现有 benchmark 只评估功能正确性。如果同时要求"功能正确"和"安全无害"，模型的表现如何？
  • 任务形式：307个编码任务，每个任务同时配有功能测试和安全测试。覆盖 Python/C++/JavaScript 三种语言。评估指标是"联合成功率"——只有同时通过功能和安全测试才算成功。
  • 发现: 即使是最强的模型，在每种语言上的联合安全-功能成功率都低于 15%。这说明模型生成的代码虽然"能用"但大量存在安全漏洞。
  • 进一步发现: 即使是 Codex、OpenHands、Claude Code 等高级 Agent 系统，在纯规格驱动（specification-only）任务上的表现也不比直接生成好——迭代式脚手架并不能改善安全性。
  • 研究价值: ⭐⭐⭐ 安全+功能联合评估是重要创新。如果你的研究关注"AI 生成的代码到底可不可信"，这是核心 benchmark。

I. 硬件 / RTL / HDL（3个）

这个方向在测什么？ 硬件描述语言（HDL）如 Verilog/VHDL 用于设计芯片——你用代码描述电路逻辑，然后综合成实际的芯片。这是和软件编程完全不同的领域：需要理解时序、时钟、并行性、硬件资源约束。这个方向测试 LLM 能否生成芯片设计代码。

24. ProtocolLLM — 通信协议 SystemVerilog 生成

  • arxiv: 2506.07945 | 仓库: ✅ https://github.com/amsheth/ProtocolLLM
  • 🎯 测试什么问题：通信协议（如 AXI、APB、PCIe）是芯片间通信的标准接口。生成符合协议规范的 SystemVerilog 代码需要精确理解时序和握手逻辑。LLM 能否生成正确的通信协议 RTL 代码？
  • 研究价值: ⭐⭐⭐ 协议级硬件生成是细分但高价值场景——一颗芯片上可能有数十个通信接口。

25. RuC — HDL 无关的规则补全

  • arxiv: 2604.27780 | 仓库: ✅ https://github.com/HPAI-BSC/RuC
  • 数据集: 📦 https://huggingface.co/datasets/HPAI-BSC/RuC-datasets
  • 🎯 测试什么问题：硬件设计中有大量"规则"（设计规范中的编码规则、命名规则、接口规则等）。LLM 能否根据已有规则自动补全缺失的部分？ 更重要的是，这个 benchmark 的生成方法本身不依赖于特定 HDL——可以用于 Verilog、VHDL 甚至未来的新 HDL。
  • 研究价值: ⭐⭐ 提供了一种可扩展的 benchmark 自动生成方法。

26. AssertLLM2 — 断言生成

  • arxiv: 2605.27472 | 仓库: ✅ https://github.com/hkust-zhiyao/AssertLLM2
  • 🎯 测试什么问题：硬件验证中，工程师需要编写断言（Assertion）——一种特殊的代码，用于在仿真时自动检测设计中的错误。手动写断言非常耗时。LLM 能否从设计规格自动生成正确的断言？
  • 背景：断言生成是硬件验证流程的瓶颈——一个 SoC 可能需要数千条断言，目前全靠人工编写。来自港科大团队。
  • 任务形式：从设计文档中提取规格，生成 SystemVerilog 断言代码。使用仿真工具验证断言是否正确。
  • 研究价值: ⭐⭐⭐ 断言生成是硬件验证的关键环节，自动化价值极高。

J. 竞技编程与推理（2个）

这个方向在测什么？ 竞技编程（如 ACM-ICPC、Codeforces）代表人类算法能力的极限。这个方向测试 LLM 在高难度算法问题上的表现——不只是写对代码，还要在有限时间内设计出正确的算法。

27. ELABORATION — 人-LLM 协作竞技编程（ACL 2025 Main）

  • arxiv: 2505.16667 | 仓库: ✅ https://github.com/SCUNLP/ELABORATION
  • 🎯 测试什么问题：不是"LLM 独立做题"，也不是"人独立做题"，而是人+LLM 协作做题。在协作过程中，人会给 LLM 什么类型的反馈？LLM 的建议有多少是有用的？人机协作的效果是 1+1>2 还是 1+1<2？
  • 背景：这是首个系统研究人-LLM 协作编程的 benchmark。构建了完整的反馈分类法（taxonomia）来分析协作模式。
  • 研究价值: ⭐⭐⭐ 人机协作是不同于纯自动化的新维度——在真实世界中，AI 是人的助手而非替代者。

28. CPRet — 竞技编程中的检索（NeurIPS 2025 D&B）

  • arxiv: 2505.12925 | 仓库: ✅ https://github.com/coldchair/CPRet
  • 在线Demo: 🌐 https://www.cpret.online/
  • 🎯 测试什么问题：做竞赛题时，很多问题可以通过"参考类似题目的解法“来解决。如果有一个包含大量已解题目的知识库，检索增强生成（RAG）能否帮助 LLM 做竞赛题？
  • 研究价值: ⭐⭐ RAG 在竞技编程中的应用。

K. 数据科学与工具调用（2个）

这个方向在测什么？ AI Agent 的一个重要应用是自动完成数据分析任务——用户说"帮我分析这份销售数据，画出趋势图”，Agent 就能调用工具、处理数据、生成图表。这个方向测试 Agent 的工具调用能力和任务编排能力。

29. GeoAgentBench (GABench) — 空间分析工具增强 Agent

  • arxiv: 2604.13888 | 仓库: ✅ https://github.com/geox-lab/GABench
  • 🎯 测试什么问题：在 GIS（地理信息系统）领域，数据分析需要调用专业工具（如 ArcGIS、QGIS）。Agent 能否根据自然语言指令，正确调用这些工具、组合操作步骤、完成空间分析任务？
  • 特点: 动态执行——任务在真实环境中运行，不是选择题。
  • 研究价值: ⭐⭐ 工具调用+领域特定（GIS）。

30. ADK Arena — 评估 Agent 开发框架本身

  • arxiv: 2606.05548 | 仓库: ✅ https://github.com/jintao-h/ADK-Arena
  • 🎯 测试什么问题：现在有很多 Agent 开发框架（LangGraph、CrewAI、AutoGen、OpenAI Agents SDK 等）。哪个框架做的 Agent 表现最好？ 这个 benchmark 不测模型，而是测框架——用同一个模型，不同的框架，看效果差异。
  • 背景：这是一个"元评估"——评估的是评估/开发工具本身。用"LLM-as-a-Developer"的方式，让不同框架的 Agent 完成同样的开发任务。
  • 研究价值: ⭐⭐⭐ 如果你需要选择一个 Agent 框架来做研究或产品，这个 benchmark 给你答案。

L. GUI / 桌面 Agent / 其他（3个）

这个方向在测什么？ “Computer-Use Agent”——AI 像人一样操作电脑（点击鼠标、输入键盘、切换窗口）。这个方向测试 Agent 在真实桌面环境中的操作能力。

31. WinDeskGround — 多窗口桌面 GUI 定位

  • arxiv: 2605.16402 | 仓库: ✅ https://github.com/ZZZhr-1/WinDeskGround
  • 🎯 测试什么问题：GUI Agent 的第一步是**“看懂"屏幕**——在屏幕上找到正确的按钮、输入框、菜单。这在多窗口、重叠、动态变化的桌面环境中极其困难。Agent 能否在复杂的 Windows 桌面环境中精确定位 UI 元素？
  • 研究价值: ⭐⭐ 桌面 GUI 定位是 computer-use agent 的基础能力。

32. Human-on-the-Bridge — 可扩展 Agent 评估

33. CLARC — C/C++ 鲁棒代码搜索（ICLR 2026）

  • arxiv: 2603.04484 | 数据集: 📦 https://huggingface.co/datasets/ClarcTeam/CLARC
  • 🎯 测试什么问题：代码搜索是编程辅助的基础——开发者输入自然语言描述，系统返回相关代码。但在 C/C++ 中，由于宏、模板、指针等特性，代码搜索特别困难。LLM 能否在 C/C++ 代码库中做鲁棒的语义搜索？
  • 研究价值: ⭐⭐ 代码搜索是编程辅助的基础能力。

三、未来值得做的研究方向预测

基于以上 33 个 benchmark 的分析，以下方向是当前存在明显空白、且预计将成为热点的研究机会：

🔥 第一梯队：高价值蓝海方向

1. 代码重构与可维护性 — 当前最大空白！

  • 现状: SWE-Refactor（2602.03712）和 SmellBench（2606.05574）虽然论文已发表，但截至调研时均未公开仓库。这意味着如果你现在做一个有公开仓库的代码重构 benchmark，你将是这个领域第一个。
  • 核心问题: 现有 benchmark 只评估"能不能跑”（功能正确性），几乎不评估"好不好维护"（可读性、可扩展性、架构质量）。
  • 为什么重要: 在真实软件工程中，开发者花在"维护和重构旧代码"上的时间远多于"写新代码"。但 LLM 在这个方向上的能力几乎完全没有被评测过。
  • 具体机会:
    • 构建一个语义保持性可自动验证的重构 benchmark（用测试套件验证重构前后行为一致）
    • 覆盖跨文件重构（现有 SWE-Refactor 只做 Java，且不可用）
    • 加入代码异味检测+消除的完整评测流程（SmellBench 的思路，但仓库不可用）
    • 评估"可维护性"——不只是代码能跑，而是代码是否更容易理解和修改

2. 代码安全与功能联合评估

  • 现状: DualGauge 揭示最强模型联合成功率<15%。SEVRA-BENCH 展示 agent 可被恶意 PR 攻击。
  • 核心问题: 当前 benchmark 几乎都将"功能正确"和"安全无害"分开评估。但现实中，一段代码必须同时满足两者。
  • 空白: 没有系统评估 Agent 生成代码的安全供应链风险（依赖漏洞、注入等）的 benchmark。
  • 具体机会: 构建"安全感知的 coding agent" benchmark，将安全视为与功能并列的一等指标。

3. 多语言 / 低资源语言代码生成

  • 现状: SWE-PolyBench 开创多语言方向；但 Rust/Go/Swift/Kotlin 等新兴语言、以及仓颉等低资源语言的系统性评测仍然几乎为零。
  • 空白: CangjieBench（2603.14501）仓库已失效（404），说明该方向极不成熟。
  • 具体机会: 跨语言代码迁移+生成 benchmark，关注"语言混淆“现象（模型在生成目标语言代码时混入其他语言语法）。

4. 形式化验证代码生成 — 从0到1的突破点

  • 现状: CLEVER/VERINA 证明 SOTA 模型证明成功率仅~5%。
  • 核心问题: 这是一个几乎"从0到1"的领域——差距巨大，任何改进都是显著贡献。
  • 具体机会: 结合 Lean/Coq/Dafny 的端到端验证代码生成，是理论+工程双突破点。VerifyThisBench 等论文尚未开源，说明这个方向还远未饱和。

⭐ 第二梯队：快速增长方向

5. Agent 中间过程评估

  • 现状: 大多数 benchmark 只看最终结果（resolved/unresolved），忽略过程质量。
  • 核心问题: Agent 在哪个环节最容易出错？是定位错了文件？还是编辑有误？还是测试没通过但 Agent 以为通过了？
  • 具体机会: 构建"过程感知” benchmark，评估 Agent 的规划质量、探索效率、上下文管理。

6. 数据科学 / Notebook 代码

  • 现状: DSCodeBench 覆盖10个库，但仍以独立函数为主。
  • 空白: Jupyter Notebook 级别的端到端数据分析 pipeline 生成、ML 实验代码生成。
  • 具体机会: Notebook 级的 multi-cell 代码生成与执行评估——不只是写一个函数，而是写一整个数据分析流程。

7. 持续学习与记忆

  • 现状: SWE-Bench-CL 首次提出，但仅一个 benchmark。
  • 核心问题: Agent 能否从错误中学习？能否记住上一个任务的经验并在下一个任务中复用？
  • 具体机会: agent 跨 session 记忆、错误经验积累、知识迁移的评估范式。

8. 硬件设计自动化

  • 现状: ProtocolLLM/RuC/AssertLLM2 显示 RTL 方向 benchmark 在爆发。但 CVDP/OpenLLM-RTL 等尚未开源。
  • 具体机会: SystemVerilog 验证、SoC 集成、物理设计等更高层任务的公开 benchmark。

💡 第三梯队：创新交叉方向

9. 性能优化

  • 现状: SWE-Pro（2606.25530）揭示 LLM 在运行时/内存优化上几乎无能为力，专家可达 15.5x 加速，但 benchmark 未开源。
  • 核心问题: “能写出正确的代码"和"能写出高效的代码"是两种完全不同的能力。
  • 具体机会: 构建一个开源的性能优化 benchmark，自动测量 LLM 生成代码的运行时间和内存占用。

10. 对话式 / 迭代式开发

  • 现状: FronTalk 开始探索；Dialogue SWE-Bench 尚未开源。
  • 核心问题: 真实开发是迭代式的——开发者不会一次说清所有需求，而是在看到结果后不断调整。
  • 具体机会: 多轮对话中的需求澄清、增量开发、反馈整合评估。

11. 动态 / 抗污染 Benchmark

  • 现状: DynaCode 的动态生成范式是重要创新；FeatureBench 支持自动扩展。
  • 核心问题: 静态 benchmark 一旦发布，就会被纳入训练数据——“考试漏题”。
  • 具体机会: 持续更新的 benchmark（类似 LiveCodeBench 的策略），自动检测并应对数据泄漏。

12. Benchmark 元研究

  • 现状: “Position: Coding Benchmarks Are Misaligned”（2606.17799）指出现有 benchmark 与真实 agentic SE 脱节。
  • 核心问题: benchmark 本身的质量如何？可复现性如何？社区是否在采用？
  • 具体机会: 研究 benchmark 本身的质量、可复现性、社区采用偏差。

四、数据统计

Benchmark 方向分布

仓库级SWE/Agent    ████████████████ 8  ← 最热门方向
代码生成与评估      ████████ 4
形式化验证          ████ 2             ← 蓝海！成功率仅~5%
代码迁移            ████ 2
前端/多模态         ██████ 3
安全                ████ 2             ← 热门新方向
硬件/RTL            ██████ 3
竞技编程            ████ 2
代码审查            ████ 2
数据科学/工具       ████ 2
GUI Agent           ████ 2
代码重构            0  ⚠️ 空白！       ← 最大研究机会

按时间趋势（月度新增已验证 benchmark 数）

2025.02-04  ███ 3个
2025.05-06  ██████████ 10个 ← 爆发期
2025.07-09  ████ 4个
2025.10-12  ██ 2个
2026.01-03  ████████ 8个 ← 再次加速
2026.04-06  ██████ 6个

趋势明显：benchmark 数量在加速增长，2026年上半年已超过去年全年。

五、方法论说明

搜索策略

  • 使用 ArxivSearcher skill（路径：C:\PreView\ArxivSearcher）的 hybrid 模式（关键词+向量混合检索）
  • 40 轮搜索覆盖 20+ 子方向，每轮 top-20
  • 去重后 596 篇唯一论文

筛选标准

  1. 标题必须含 “Bench” / “benchmark” / “dataset” / “evaluation”
  2. 与 coding 强相关（代码生成、软件工程、编程、调试、重构等）
  3. 必须有公开可用的 GitHub 仓库 / HuggingFace 数据集 / 可执行平台
  4. 排除非 coding 领域（医疗、金融、多语言NLP等）

验证方法

  • 人工核查 arxiv abstract 页面和 HTML 全文中的代码链接
  • GitHub API 验证仓库存在性（HTTP 200）
  • GitHub Search API 按名称搜索交叉验证
  • 排除名称相同但实际为不同论文的仓库（如 seketeam/EvoCodeBench 是另一篇论文）
  • 排除仓库已失效的（如 CangjieBench 的 cjhCoder7/CangjieBench 返回 404）

已排除的重要论文（声明开源但未找到仓库）

以下论文在 abstract 中声明"All code is publicly available"或类似表述，但截至调研时在 arxiv 页面和 GitHub 上均未找到实际可访问的仓库：

arxiv ID名称重点测试什么状态
2602.03712SWE-Refactor仓库级代码重构（语义保持的修改）声明开源，仓库未找到
2606.05574SmellBench代码异味检测与消除声明开源，仓库未找到
2506.14074CVDPRTL设计/验证/调试全流程声明开源，仓库未找到
2503.15112OpenLLM-RTLRTL代码生成+断言评估未找到仓库
2606.19830JAMER (JamBench)游戏引擎项目级代码生成声明开源，URL 未给出
2606.14201TACO开放域 Text-to-SQL未找到仓库
2606.25530SWE-Pro软件性能优化（运行时/内存）未找到仓库
2606.20517Multi-LCB多语言竞技编程未找到仓库
2505.19271VerifyThisBench端到端程序验证（NL→规格→证明）未找到仓库
2602.10171EvoCodeBench自演化编码系统+人类对标未找到仓库
2509.01494SWR-Bench真实世界代码审查评论生成未找到仓库
2509.14856CodeFuse-CR-Bench端到端代码审查评估未找到仓库
2512.24565MCPAgentBenchAgent MCP 工具使用声明开源，仓库未找到

这些论文值得持续关注——其仓库可能在论文正式发表后（如会议 camera-ready）才公开。

已知局限

  • arxiv 索引可能有延迟，最新1-2周的论文可能未被 ArxivSearcher 收录
  • GitHub API 有速率限制，部分搜索可能不完整
  • 部分 benchmark 代码仅在 PDF 全文中提及，abs/HTML 页面无法获取

本报告由 WorkBuddy 基于 ArxivSearcher 迭代搜索 + 多 agent 并行仓库验证 + GitHub API 交叉验证生成。