过测不过审的隐形墙
论文讲的是：构建了一个区分功能达标与审查合规的软件智能体评测基准
1问题
想象你指挥一个编程机器人去修老项目的漏洞。它改了三行代码。本地测试全部变绿。你刚准备提交。主管却把申请打了回来。主管只提了三条死规矩。变量名要短。关键逻辑必须记日志。错误处理不能吞异常。机器完美跑通了功能。却在人情世故里挂了科。这其实戳中了现在所有编程大模型的软肋。它们只会被要求让程序不报错。却从不被考核让代码合乎规范。以前的评测榜单只顾着盯测试用例。只要绿灯就宣布通关。结果训练出的模型在实验室风光无限。进了真实开发环境连第一关都迈不出去。直到作者们忽然意识到。如果把跑通和过关拆开来看。答案自然浮出水面。
2翻译
顺着这个思路。作者把原来混在一起的考核劈成了两张独立的卷子。这就好比考驾照。以前只看倒车入库定生死。现在把场地操作和道路实际分开计分。他们干了一件事。从开源社区真实的代码合并申请里。扒出人类审查员常提的具体要求。比如命名要统一。关键逻辑必须打日志。禁止使用全局变量。把这些硬规矩编成自动检测脚本。接着。他们拿着这些剧本去拷问四款不同档次的编程大模型。并配了同一个调度外壳来保证公平。数字很扎眼。在跑了六百多次修复尝试后。有六百四十四次顺利通过了功能测试。可一旦把审查规矩扔进去。其中两百二十一次直接原地翻车。换个角度看。即使剔除那些功能都没跑通的废稿。单纯挑出能通过常规测试的样本再筛一遍。合规率依然跌穿了六成。这篇论文并没有给出那种颠覆认知的反常识结论。它只是老老实实画出了一条分水岭。说明机器判对错的速度很快。但人类定调性的尺度更难摸。
3核心概念
为了把这套玩法落到实处。作者手里攥着三件核心工具。第一件是一套带着全家福的代码包。论文里叫它仓库级修复实例。回到开头的例子。机器人拿到的不是孤立的试卷。而是一整块正在运转的电路板。修这里可能会亮那边。第二件是人类留下的批注清单。论文里叫它审查约束。对应刚才主管打回的那条意见。它不是玄学。而是被作者拆解成一行行可执行的检查规则。第三件是双轨验证机制。这是一个关键的设计选择。作者拒绝把功能检查和规范检查揉进同一个黑盒脚本。而是刻意切成两套并行流水。回到例子。就像机场过检。先过安检门抓违禁品。再过海关看证件。两者互不干扰。这么设计的理由是防止好事者钻空子。有些代码为了凑齐测试用例会故意写得丑陋不堪。如果不分开打分。总分会掩盖真正的协作短板。
4洞见
跑通代码只是及格线。拿到团队点头才算交卷。
5博导审稿
选题眼光很准。现在编程Agent满嘴跑火车。光盯着单元测试确实像在练盲人摸象。这个坑踩得真实。方法成熟度方面有个底子薄的问题没摊开说。他们默认公开平台的评论能代表所有工程场景。可企业内网评审往往看重性能压测或业务对齐。这层隐性假设会让数据集在垂直领域跑偏。实验诚意过关。三百多个带标注的样本撑起的对比盘算得仔细。唯独只用了一套固定脚手架跑模型。没拆开看不同检索策略会不会改写结局。显得稍微保守了点。写作功力扎实。不整虚招。数据摆在那儿自己说话。判决弱接收。理由：底座数据扎实且切中落地痛点。可作为后续研究起点。但泛化边界需补强。
6启发
这意味着你可以把这套拆分考核的逻辑平移过来。迁移上。别再把综合得分当唯一指标。把你的算法模块单独拉出来跑一遍规范校验。看它是不是只会应试。混搭上。拿你自己的业务规则库替换掉公共平台的爬取文本。让约束生成器吐出你们公司特有的红线。跟现有流水线一焊就是新武器。反转上。传统做法是把审查规矩当成事后拦截网。你不妨把它前置。让它在生成代码时就直接当导航仪用。变被动扣分主动引导路径。这三条路都能直接接你现在的活。