ProgramBench 重新定义 AI Coding 评估：大模型软件工程能力遭“团灭”，瓶颈在哪？

地狱级新 benchmark 结果震撼

SWE - Bench 创建者放出新 benchmark，Claude Opus 4.7、GPT - 5.4、GPT - 5 mini、Gemini 3.1 Pro、Gemini 3 Flash 等一线模型全部 0% 完成率，意味着今天的大模型会写代码，但不会做软件工程。

ProgramBench 重新定义评估方式

Meta FAIR 联合斯坦福、哈佛等机构发布 ProgramBench，它把问题推进到软件工程层面，让 AI 从零开始构建可执行软件系统，如 ffmpeg、SQLite、ripgrep，且不能联网。它采用行为等价打分，用 agent - driven fuzzing 做测试，结果所有模型 0% 完成率。

模型表现细节

Figure 4 显示模型常能完成一部分，少数任务接近完成，但要求 100% 行为等价就不行。Claude 系列表现相对最好，Claude Opus 4.7 只有 3% 的任务接近完成。模型倾向于生成单体化代码，与人类工程师习惯相反，暴露其擅长局部代码生成，不擅长全局系统规划的问题。

不同语言与任务难度表现

研究团队统计模型在 C/C++、Go、Rust 等语言项目上的表现，C/C++ 项目完成度最高，Rust 最差。不同模型在任务难度排序上一致，简单 CLI 工具通过率高，复杂系统难推进，说明复杂软件系统对当前模型有稳定压制。

围绕 ProgramBench 的争议及回应

有人质疑 ProgramBench 是考模型背过 FFmpeg 吗，知名硅谷投资人 Deedy Das 回应称任何 benchmark 都可能被 overfit，真正重要的是模型完成这类任务的能力可能泛化到其他工程场景。还有人吐槽 benchmark 不合理，Deedy Das 认为 benchmark 目标是推动模型向更高层次智能逼近，人类做不到不意味着没价值。

ProgramBench 的缺陷与改进方向

ProgramBench 存在缺陷，如没测试 Claude Code、Codex 等完整 agent harness，只统计是否完成，限制联网能力等。但这些问题可随 benchmark 演进修正，它第一次把 AI Coding 评估从函数级拉到系统级，暴露出行业断层。

行业研究新方向

当前大模型缺乏维护复杂系统的能力，行业开始研究 memory、agents、repo - level reasoning、long - horizon planning、autonomous software engineering 等关键词，下一阶段竞争可能是谁能持续稳定维护软件系统。