AI写的代码，你敢直接用吗？全球顶级程序员出手，给AI出了套“地狱考题”

一个残酷的现实正在浮出水面：AI不仅能写代码，还可能很快成为代码进入生产环境的主流路径。但问题是，它写的代码，是“能跑”还是“好用”？

今天，所有编程基准测试的共识是：AI能写出正确的代码。但当正确性成为及格线，下一个关键问题来了：它能写出高质量、可维护、能直接合并进你项目的代码吗？

最新发布的 FrontierCode 基准测试，给出的答案可能会让AI支持者冷静一下。

不止对不对，更看“值不值”：AI编程的“高考”来了

FrontierCode 自称是首个衡量AI代码“可合并性”的基准。它的核心理念是：代码不仅要功能正确，还要在风格、设计、范围控制等维度，通过真实世界开源项目维护者的严格审查。

这听起来有点抽象？想象一下，你提交了一个修复bug的代码，CI测试全绿，但你的团队Leader看了一眼说：“虽然能用，但这样写不规范，以后难维护，打回去重写。”——FrontierCode测试的就是AI能否避免这种“打回”。

它的诞生背景是，现有如SWE-Bench这类基准测试，被发现存在大量“误判”：高分模型生成的代码，人类维护者其实根本不会接受。而FrontierCode声称，通过一套复杂的新方法，将误报率降低了81%。

最强AI也翻车：及格线下的残酷数据

我们直接看结果。FrontierCode设置了从易到难的三个子集，测试了包括Claude、GPT、Gemini在内的所有主流顶尖模型。

结果令人惊讶：在最难的“钻石”集上，表现最好的Claude Opus 4.8，得分也仅仅只有13.4%。

这意味着，即使是当前最顶尖的AI模型，在模拟真实代码审查的严苛标准下，超过85%的时候都交出了“不达标”的作业。其他模型的得分更是惨不忍睹：GPT-5.5得6.3%，Gemini 3.1 Pro得4.7%。

一个有意思的细节是：虽然Claude得分最高，但GPT-5.5完成任务所消耗的token数量，最多只有Claude的四分之一，展现了更好的“成本-智能”平衡。在AI应用落地时，这或许是一个比单纯跑分更重要的维度。

为什么AI的“高分作业”不被认可？

问题出在哪里？以一个具体的评测任务为例。任务要求在一个C++项目中，将所有打印“警告”的代码统一到一个新的LOG_WARNING()函数里。

从功能上看，AI模型（如Claude Opus 4.8）生成的代码完全正确，能输出同样的错误信息到标准错误流。但评分标准之一是代码的“地道性”和“未来可维护性”。

维护者的正确做法是：

LOG_WARNING() << "You are opting in to remove schema identifiers... \n"
              << "The only legit use case...\n"
              << "non-compliant...\n" << ... ;

而AI的做法是：

LOG_WARNING() << "You are opting in to remove schema identifiers...\n";
    std::cerr << "The only legit use case...\n";
    std::cerr << "non-compliant...\n";

两者行为一样，但AI的写法埋下了隐患：它硬编码假设了LOG_WARNING()和std::cerr是同一个输出流。如果未来LOG_WARNING()的实现发生变化，这部分代码就会悄无声息地出错。这种对代码“未来”的考量，正是人类资深开发者与当前AI的核心差距之一。

顶级维护者出手：40小时雕琢一个“考题”

FrontierCode的“硬核”之处，在于其构建过程。它联合了20多位世界级开源项目维护者，来自像Celery、Mattermost这样拥有数万Star的明星项目。

每位维护者需要为单个任务投入超过40小时，基于自己维护的真实代码库，设计出贴近现实、有挑战性的题目，并定义何为“可合并”的代码。他们把多年积累的“品味”和“判断”，转化成了3000多条具体的评分标准。

这些维护者对FrontierCode的评价很高：

“别人像CI（持续集成）一样打分，FrontierCode则像一个技术负责人一样打分。” —— Celery CEO Tomer Nosrati

“每个任务的校准深度，在LLM基准测试中前所未有。” —— Budibase CTO Martin McKeaveney

为了确保评分的公正性，整个流程包括对抗性测试、校准、多阶段审查，每一份任务都由Cognition的研究员手动复核。这种近乎偏执的质量控制，正是为了确保基准本身不会被“应试技巧”攻破。

尾声：AI编程的下一步，是“协作”还是“替代”？

FrontierCode像一面镜子，照出了当前AI编程能力的真实边界：在理解代码库规范、把握设计权衡、预判未来修改等“软技能”上，AI距离资深工程师仍有巨大鸿沟。

当一条看似理性的科技新闻，把“AI能写代码”的狂热，拉回到“AI写的代码好不好用”的冷酷现实时，我们或许该问：未来，是不断逼近人类标准的AI最终取代程序员，还是成为人类开发者手中更强大的、需要被严格监督的“高级工具”？

有趣的是，在社交媒体的讨论中，一条评论获得了很多共鸣：“由于没人知道或能同意‘代码质量’是什么，我们甚至无法为人类输出衡量它，我对于为LLM衡量它持怀疑态度。”

这或许是比AI得分本身更值得思考的终极问题。

【锐评】：当评测标准从“对不对”升级到“香不香”，AI编程的泡沫，或许正在遇到第一根坚硬的针。

参考链接：
https://cognition.ai/blog/frontier-code