SWE-bench 涨了 67 个百分点之后：从基准分数到 Ironclad 合同工作流，‘专业工作能力‘是测出来的还是练出来的？

发布时间：2026/10/29 20:01:40

SWE-bench 涨了 67 个百分点之后：从基准分数到 Ironclad 合同工作流，“专业工作能力”是测出来的还是练出来的？

一个引人注目的数字

如果你关注大模型评测数据，很难忽略这样一张对比表。根据《2025 AI 大模型开发生态白皮书》引用的斯坦福大学《2025 年人工智能指数报告》（AI Index Report 2025），以 GPT-5 为代表的新一代模型在多个关键基准上，一年内实现了大幅跃升：MMMU（大规模多学科多模态理解）提高 18.8 个百分点，GPQA（博士级科学问题）提高 48.9 个百分点，而最夸张的是 SWE-bench（软件工程基准），提高了 67.3 个百分点——从约 7.6% 涨到了 74.9%。

白皮书对此的解读相当乐观：SWE-bench 衡量的是模型解决真实世界 GitHub 代码仓库中 issue 的能力，74.9% 的得分“意味着它已经可以作为一个合格的初级软件工程师，自主理解问题、定位 bug 并编写代码进行修复”。

但另一条新闻值得我们放在一起看：OpenAI 在其研究页面刊发了《携手 Ironclad，提升计算机使用能力》，介绍 OpenAI 与合同管理公司 Ironclad 如何围绕复杂的合同管理工作流，训练和评估 AI 智能体，提升其“使用计算机完成专业工作的能力”。

把这两条信息摆在一起，会出现一个很有意思的问题：既然基准分数已经这么高了，为什么还需要和 Ironclad 这样的企业专门做工作流层面的训练与评估？

基准分数证明的是“能做题”

先说清楚 SWE-bench 这类基准到底测了什么。它测的是：给模型一个真实仓库的 issue，看它能否产出能通过测试的修复。这确实是“真实世界”的——issue 来自真实仓库，代码不是玩具题。这也是它比 HumanEval 这类算法题基准更有含金量的原因。作为对照，白皮书中 GPT-4 在 HumanEval 上已是 90.2%，GPT-5 估算约 95%，提升只有约 4.8 个百分点——标准代码生成这块早就“卷”到天花板了。

但“真实仓库的 issue”和“真实的工作”之间，仍然隔着好几层：

任务边界是清晰的。SWE-bench 的每一题都有一个明确的、可验证的目标（通过测试）。而真实工作中，第一步往往是搞清楚“到底要做什么”——需求本身是模糊的、多方的、会变的。
环境是受控的。基准跑在一个准备好的仓库和运行环境里。真实的软件工程要面对陈旧的依赖、说不清来龙去脉的遗留代码、权限受限的系统、必须遵守的合规流程。
失败成本结构不同。基准里答错扣分；真实工作里，一个错误的合同条款处理可能带来法律后果，一次错误的自动操作可能污染生产数据。

所以 74.9% 更准确的读法是：在“给定清晰任务、可验证目标、受控环境”的前提下，模型能解决约四分之三的问题。这是巨大的进步，但它衡量的是一种被规约化了的工程能力，而不是完整的职业能力。

Ironclad 合作指向的是另一条路

这正是 Ironclad 合作耐人寻味的地方。合同管理工作流和“修一个带测试的 bug”几乎是两个极端：步骤长、判断点分散（这条条款该不该改？这个风险谁承担？）、中间穿插大量对专业软件界面的实际操作。没有一套现成的公开基准能覆盖“在某家公司的合同系统里，按其内部规范走完一个审批流程”这种事。

OpenAI 选择的方式不是“再出一个更难的公开基准”，而是和一个真实业务方合作，围绕其具体工作流做训练和评估的闭环。这透露出一个趋势：当通用基准的分数逼近天花板，剩余的差距越来越多地藏在具体场景里，而具体场景的能力，很难靠刷通用题练出来——需要针对该场景的数据、该场景的成功标准、该场景的评估集。

换句话说，“专业工作能力”既不是纯粹“测出来的”（公开基准只能测到规约化能力），也不纯粹是“练出来的”（没有真实场景的评估闭环，练也练不到点子上）。它更像是“针对具体工作流，训练与评估互相咬合地练出来、再测出来”。

开发者读基准数据时的三个核对问题

作为技术决策者，我们经常要靠基准数字选模型。下次看到一条亮眼的分数，建议先问三个问题：

1. 数据来源是什么？这个数字是官方发布、第三方复现，还是汇总报告里的转述？《2025 AI 大模型开发生态白皮书》自己就很坦诚地在表格里标注了“部分数据为估算”——比如 MMLU 的 ~90%、HumanEval 的 ~95% 带着波浪号。看到带估算标记的数字，引用时就要降低确信度，最好回溯到原始发布。

2. 这个分数是实测还是估算？即便是官方数字，也要看评测条件：是否使用了工具、是否是“专业版/带思考”模式？白皮书提到 GPT-5 在 GPQA 上 88.4% 的成绩是“专业版（with thinking）在无外部工具辅助下”取得的。同一模型在不同设置下分数差异可能非常大，拿标准版分数去预测专业版能力，或者反过来，都会失真。

3. 场景覆盖够不够？分数对应的具体任务形态，和你要做的业务有多接近？SWE-bench 测“修 issue”，不测“从零搭服务”、不测“做代码评审”、更不测“和产品经理对齐需求”。如果你的场景是长链条、多判断点的工作流（比如文档审阅、系统运维），那么公开基准的参考价值有限，值得参考的反而是 Ironclad 这种针对具体工作流的评估思路——甚至你应该为自己的业务构建自己的评估集。

适用范围与局限

最后框一下本文结论的边界。SWE-bench 的 67.3 个百分点提升是真实且重要的信号，它说明模型处理规约化工程任务的能力发生了质变，“AI 能写代码”已经不是营销话术。本文质疑的不是数字本身，而是从数字到“能上岗”的推理链条——白皮书“合格的初级软件工程师”这类解读，是对分数含义的外推，接受它之前需要意识到外推的距离。

同样，Ironclad 合作展示的是一种方法论方向，它说明头部厂商已经意识到场景化训练评估的必要性；但对于大多数团队而言，没有 OpenAI 的资源，“围绕自己工作流建评估闭环”仍是一个需要按自己体量裁剪的工程命题——哪怕只是先写几十条带成功标准的真实任务用例，也比盯着公开基准排行榜更有用。

一句话总结：基准分数告诉我们模型“能做题”的上限在哪，而“能上岗”这件事，得在你自己的工作流里，练一遍、测一遍才知道。