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

地狱级新 benchmark 结果震撼SWE - Bench 创建者放出新 benchmarkClaude 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 等关键词下一阶段竞争可能是谁能持续稳定维护软件系统。