乐山铝皮保温施工 AI编程真面容：竣工样子通过率仅27

AI 编程是项十分有实用价值的才略乐山铝皮保温施工，但汇聚上时常也能看到步履员怀恨 AI "听不懂东说念主话"、"难以找到根柢问题"，有平直建议"每次生成代码不要过 5 行"的教化共享。

而近期又有好多 AI 器用宣称不错从快速构建竣工代码样子。

是以 AI 编程智能体真的能从构建竣工软件样子吗？近日多校联辩论团队针对这问题进行了探索。

上海交通大学、上海创智学院、加州大学默塞德分校、北京理工大学（按论文作家端正）联发布ProjDevBench——个通过 OJ 细粒度反应评估 AI 编程智能体端到端样子拓荒才略的基准测试，条目智能体仅凭当然谈话需求文档，从脱手构建竣工、可运行的软件仓库。

当任务从"补全现存代码"变为"从构建"时，能出现断崖式下落。

效果令东说念主想：整个智能体总体提交 AC 率仅 27.38。

该辩论得出的论断摘抄：

六种主流编程智能体（Cursor、GitHub Copilot、Claude Code 等）的总体提交 AC 率仅为 27.38，在从构建任务中能大幅下滑。

OJ 提供的细粒度会诊反应（编译弱点（CE）、运行时弱点（RE）、时（TLE）、内存限（MLE）、谜底弱点（WA）等）是评估端到端拓荒才略的关节构成部分，远于传统的 pass/fail 二元判定。

交互轮次与能呈强负有关（-0.734），智能体在遭受穷苦时堕入低试错轮回，而非通过反想终了打破。

为什么需要端到端样子拓荒基准

现存基准测试如 HumanEval、MBPP 聚焦于函数代码生成，SWE-bench 暖热 issue 竖立，但果真软件工程需要的远不啻这些。当拓荒者使用 Cursor 或 GitHub Copilot 进行" vibe coding "时，他们盼望智能体大要：从策画系统架构、创建和组织多个源文献、确立依赖和构建系统（如 CMakeLists.txt）、终寄托个可编译运行的竣工样子。

这种端到端的样子构建才略此前从未被系统评估过。ProjDevBench 填补了这空缺。

与传统基准的骨子永诀在于：HumanEval 等条目智能体补全代码片断，SWE-bench 条目竖立现存代码库中的 bug，而 ProjDevBench 条目智能体像信得过的软件工程师样，在莫得任何开动代码模板的情况下，自主完成从架构策画到多文献编码的全经由。

双重评估机制：OJ 测试 + 代码审查

与以往仅复返 pass/fail 的测试不同，ProjDevBench 遴荐双制度评估：

OJ 实施评分（80）：通过在线判题系统进行严格的黑盒测试，提供细粒度会诊信号——编译弱点（CE）、运行时弱点（RE）、时（TLE）、内存限（MLE）、谜底弱点（WA）等。这些信号复旧智能体进行迭代调试，模拟果真拓荒中"编写代码 - 遭受报错 - 修改代码"的轮回。

代码审查评分（20）：结端正剧本和 LLM 模拟的代码审查，检测 OJ 测试法捕捉的问题：是否违背显式端正（如使用谢绝的库）、是否存在舞弊解法、是否行使测试套件粗疏而非遵命推行经管。

这种策画的中枢洞悉是：仅靠测试用例法评估代码质地。个能通过整个测试的解法，可能遴荐了看风使舵的式，而非信得过领路并遵命问题法式。如下图所示：

任务策画与数据开头乐山铝皮保温施工

辩论团队从上海交通大学 ACM 班（https://acm.sjtu.edu.cn/home）的在线判题平台精选 20 说念难度编程样子，涵盖算法、数据结构、解说器、解决系统、存储组件等 8 大类别。

这些题目经过三阶段筛选：

开动采集：从约 2,800 说念候选题目中筛选

范围过滤：保留需要多文献终了、模块组织、构建确立的样子任务，摈斥纯算法单文献题目，剩余约 100 说念

质地过滤：及法式闪现、测试套件完善、难度非等闲的题目，终保留 20 说念

两种任务方式：

Easy 方式（有代码库）：提供部分代码，条目补全样子

Hard 方式（代码库）：仅提供当然谈话法式，条目从构建

东说念主类参考解法平均包含约 10 个源文献，智能体平均需要 138 轮器用调用、破钞 4.81M tokens 材干完成说念题目，复杂的任务需要过两小时。

实验效果解读

辩论团队评估了六种主流编程智能体：Cursor、GitHub Copilot、Claude Code、Augment、Codex CLI、Gemini CLI，搭配 GPT-5、Claude Sonnet 4.5、Gemini 3 Pro 等前沿模子。

举座剖释：Codex + GPT-5 得到综得分 77.85，但整个智能体的总体提交 AC 率仅为 27.38。

从构建时能断崖式下落：这是关节的发现。当任务从 Easy（有代码库）变为 Hard（代码库）时，大多数确立出现显贵能下降。举例：

GitHub Copilot + Sonnet-4.5：71.10 → 36.63

Gemini CLI + Gemini-3-Pro：74.57 → 35.53

Codex + Sonnet-4.5：66.07 → 31.88

这标明现时智能体擅长在现存代码基础上进行修补，管道保温施工但衰败从脱手进行宏不雅架构策画的才略。

失败方式度分析

辩论团队对整个提交进行了系统分析乐山铝皮保温施工，揭示了智能体的中枢短板：

提交景况分散：

Accepted：27.38

Wrong Answer：41.86

Time Limit Exceeded：13.91

Runtime Error：7.01

Compile Error：4.52

Memory Leak：3.51

表带领路偏差：智能体时常生谚语法正确但遗漏关节业务逻辑的框架代码。在火车票解决系统任务中，整个智能体都终闪现用户解决和列车查询，却遗漏了座位解决系统。在扫雷任务中，智能体探望了 3,789 个安全格子中的 3,825 个，标明终了不竣工而非逻辑弱点。

规模情况处理薄弱：精深运行时弱点源于空指针解援用、数组越界等问题。在 map 终了中，红黑树的旋转函数衰败空指针查验；在 Bookstore 任务中，整个智能体都未能通过覆盖测试点，通晓了对空字符串、文献 I/O 非常、嵌套场景的处理不及。

工夫复杂度分析缺失：在 ICPC 解决系统任务中，智能体在每次解冻操作后再行排序整个队列，得到 O ( K × N log N ) 的解法，而正确作念法是行使排行变化的局部终了 O ( K log N ) 。智能体倾向于使用闇练但次的方式，而非分析问题特进行针对化。

资源解决局限：在 BASIC 解说器任务中，当 std::stoi ( ) 抛出非常时，已分派的抒发式对象未被开释，致内存露馅。智能体处理显式弱点旅途，却忽略闲居操作中可能出现的非常。

交互长度与能的负有关

辩论团队发现了个反直观的局面：智能体的交互轮次越多、破钞的 token 越多，终得分同样越低。

Tokens 与得分的有干总计：-0.734

交互轮次与得分的有干总计：-0.668

交互轮次与 token 破钞的有干总计：0.898

这意味着当智能体遭受穷苦时，它们同样堕入低的"尝试 - 报错 - 再尝试"死轮回，法像东说念主类那样通过度想考找到解。增多的 token 主要来自类似的交互轮次，而非极少但入的长理样子。

静态代码复杂度（文献数目、修转业数）与能的有关较弱，标明任务难度主要体当今延伸的交互和缩短的能上，而非平直由代码领域决定。

代码审查的特价值

除实施效果外，代码审查揭示了智能体在软件拓荒使命流领路上的盲点：

版块摈弃误会：智能体时常在土产货修改代码并创建 commit，却未 push 到而已仓库，致提交不竣工。这表理智能体隐式假定"写代码 = 完成任务"，忽略了进程须通过版块摈弃显式记载和提交的条目。

法式遵命失败：构建系统确立弱点、生成弱点称号的可实施文献、使用谢绝的圭臬库头文献、遗漏需文献、修改受保护的模板。这些问题揭示了智能体将法式条目视为次要于正确的倾向。

这些发现标明，智能体尚未将软件拓荒领路为个结构化的使命经由，而只是是代码生成任务。

转头与道理

ProjDevBench 次阐述了现时 AI 编程智能体在处理果真、复杂的端到端软件拓荒任务时仍处于初阶段。它们擅长局部代码修补，但在全局架构策画、工夫复杂度化、资源解决及复杂逻辑理上尚未达到可用圭臬。

学术孝顺：

提议个端到端提供细粒度反应的样子拓荒基准，条目智能体从构建竣工可运行的软件仓库

建立结 OJ 细粒度反应与 LLM 代码审查的双重评估条约

系统揭示智能体在法式对皆、规模处理、复杂度化、资源解决等面的失败方式

推行道理：

为评估和调动下代自主软件拓荒智能体提供了逼近果真工程场景的圭臬

明确了从"代码补全器用"到"软件工程师"的才略鸿沟

指出了改日辩论向：怎样让智能体在交互中有地行使反应信号，从单纯的"试错"转向信得过的"理"

局限：面前基准仅包含 20 说念任务，主要聚于 C++ 谈话，尚未涵盖其他编程谈话或东说念主机交互式拓荒场景。改日将扩张任务领域、引入多谈话和任务类型。

论文勾搭：

https://arxiv.org/abs/2602.01655

样子勾搭：

https://github.com/zsworld6/projdevbench

键三连「点赞」「转发」「注意心」

宽容在褒贬区留住你的方针！

—  完  —

咱们正在招聘名眼疾手快、暖热 AI 的学术剪辑实习生  � �

感兴致的小伙伴宽容暖热 � �  了解细则

� � 点亮星标 � �

科技前沿进展逐日见乐山铝皮保温施工