1.1 什么是模型编程能力排名：从代码生成到工程任务
我第一次认真关注“模型编程能力排名”这件事，是因为团队里一个刚入行的同事问我：既然都说某某模型写代码最强，为什么我让它改个线上 bug 却总翻车？这个问题其实问到了点子上。所谓模型编程能力排名，本质上是一套用统一任务集和评分标准，去横向比较不同大语言模型在编程相关任务上表现的系统性结果。它看起来像一张榜单，背后却是一整套评测方法论的较量。
早期大家理解的编程能力，基本停留在“给个函数签名，模型能不能把函数体补全”。HumanEval 刚出来那会儿，Pass@1 能上 70% 就已经是新闻了。可真实开发远不止函数生成，你得读懂别人写的几百行上下文，得在仓库里定位问题，得跑测试、看日志、反复迭代。于是排名评测的任务形态也在变，从单轮补全走向多轮对话、从独立函数走向真实仓库、从写代码走向改代码和交付代码。我们今天说的“模型编程能力排名”，覆盖范围已经比三年前宽太多了。
我习惯把这件事拆成两层看。一层是模型的基础编码能力，体现在语法正确率、算法实现和跨语言迁移上；另一层是工程化编程能力，体现在它能不能理解项目结构、遵守约束、配合工具链完成任务。榜单排的是分数，但分数背后是这两层能力的综合投影。只看一层，很容易被带偏。
1.2 排名对开发者、企业与研究者的实际价值
站在开发者角度，排名的价值特别直接：帮你缩小试错范围。我平时选模型写脚本、做重构或者搭小工具，不可能每个都装一遍慢慢试。榜单能让我先圈出三五个候选，再去实测。它更像我逛超市时的货架标签，不能替我做决定，但能让我少走很多弯路。
企业视角就不一样了。我们给客户做技术选型时，排名往往是内部评审材料的一部分。团队会看模型在 SWE-bench 这类真实仓库任务上的表现，也会看它在我们自己业务代码上的微调成本、推理成本和数据安全合规情况。对一家金融客户来说，模型能不能私有化部署，比它榜单上高两分重要得多。排名这时候是决策的起点，不是终点。
研究者关注的点又不同。他们更在意评测本身是否公平、任务集是否干净、指标定义是否合理。一个基准如果训练数据泄漏严重，或者任务分布过于偏科，那排名结论的可信度就打折扣。我认识的一些做代码大模型的朋友，会同时盯着好几个榜单的细分项，比如失败案例分析、语言覆盖度、长上下文表现，从中找下一个优化方向。同一张榜，三类人读出三种信息，这也是它的有趣之处。
1.3 核心评估维度：正确率、效率、鲁棒性、可维护性与协作能力
聊到评估维度，很多人第一反应就是正确率。这个当然重要，Pass@1、Pass@10 这些指标直观好懂。但我自己踩过坑：一个模型在 HumanEval 上刷得很高，结果在稍微复杂一点的边界条件上就崩。正确率往往只在特定任务集上成立，换个分布就可能失真。
效率是另一个容易被低估的维度。这里的效率不只是生成速度，还包括它需要几轮才能把问题解决、每次消耗多少 token、是否需要反复人工纠正。我做过一个对比，同样一个接口改造任务，A 模型一次给对但解释啰嗦，B 模型第一次错但有清晰的推理过程，改一轮就过。算总账 B 更省时间。正确率之外，交互成本是真实存在的。
鲁棒性和可维护性是我近两年越来越看重的。鲁棒性指模型面对模糊需求、错误上下文、异常输入时能不能稳住；可维护性指它写出来的代码别人能不能看懂、能不能改。有些模型喜欢炫技，一行塞三个嵌套推导式，测试能过，但同事接手时想骂人。协作能力则是更前沿的一层，涉及模型能不能配合 Agent 框架调用工具、能不能在多人多轮的工程流程里持续贡献。这五个维度叠在一起，才接近“模型编程能力”的完整画像。不同的排名会侧重不同维度，读榜的时候先看它到底在测什么，比看名次更有意义。
2.1 HumanEval 的评测机制、任务类型与 Pass@k 指标
HumanEval 是我接触代码大模型评测时遇到的第一个基准，它由 OpenAI 在 2021 年提出，整个数据集包含 164 道手写的 Python 编程题。每道题的结构很统一，给出一段函数签名、一段 docstring 描述、几个示例输入输出，模型需要把函数体补全。题目覆盖的领域挺广，有基础算法、字符串处理、数据结构操作、数学计算，难度大概相当于 LeetCode 简单到中等偏上的水平。这个设计的好处是任务干净、评分自动化程度高，跑一遍测试用例就能判断对错，不需要人工介入。
真正让 HumanEval 被广泛引用的是 Pass@k 这个指标。简单说就是让模型对同一道题生成 k 个答案，只要其中一个能通过全部单元测试，就算这道题通过。Pass@1 关注的是第一次就写对的概率，Pass@10、Pass@100 则反映模型在多次采样下的潜力上限。我个人的理解是，Pass@1 更接近实际使用体验，因为你日常让模型写代码，基本不会让它生成一百个版本慢慢挑。Pass@k 高但 Pass@1 低的模型，就像一个思路很发散但不够稳定的搭档，适合头脑风暴，不太适合直接交付。
HumanEval 的评测流程还有一个细节值得说，它用的是代码补全模式，模型只看到函数签名和注释，不需要处理多文件依赖或者外部库调用。这种设定让评测变得可控，也让它和真实工程场景之间拉开了距离。我有时候会把 HumanEval 比作编程能力的“体检基础项”，能看出一些东西，但远远不够全面。
2.2 MBPP、SWE-bench、LiveCodeBench、Codeforces 等基准差异
MBPP 是我觉得和 HumanEval 最容易放在一起比较的一个基准。它全称叫 Mostly Basic Programming Problems，包含大约一千道题，同样以 Python 为主，但题目描述更偏向自然语言叙述，不像 HumanEval 那样给出结构化的函数签名。MBPP 的题目难度整体偏低，更接近日常脚本任务，比如“写一个函数把列表里的偶数挑出来”这种。它和 HumanEval 的差异主要在于任务形式，HumanEval 考的是补全能力，MBPP 考的是从描述到代码的转化能力。
SWE-bench 则是另一个维度的东西。它不再考函数级生成，而是把模型扔进真实的 GitHub 仓库里，让它去解决实际的 issue。每道题都来自开源项目的真实提交，模型需要理解仓库结构、定位相关文件、修改代码、跑通测试。这个跨度非常大，从“写一个函数”变成了“在几万行代码里找到该改的那一行”。我第一次看到 SWE-bench 的题目时，感觉它更像在考一个初级工程师的日常工作任务，而不是在考一个代码生成器。
LiveCodeBench 和 Codeforces 又是另一条路线。LiveCodeBench 强调用最新的竞赛题目做评测，避免模型在训练阶段见过原题，主要考察模型在算法竞赛场景下的推理能力。Codeforces 则是直接拿线上编程比赛的成绩来排名，模型需要在限定时间内解决难题，评分规则和人类选手一样。这两个基准的共同点是题目难度高、时间压力大，适合衡量模型的复杂推理上限。MBPP 看基础、SWE-bench 看工程、LiveCodeBench 和 Codeforces 看竞赛推理，这四个基准放在一起，基本覆盖了编程能力的几个不同切面。
2.3 大模型编程能力排行榜 HumanEval 的参考意义与局限性
HumanEval 到今天仍然被大量榜单引用，我觉得它最大的价值在于提供了一个统一的、低成本的比较基准。164 道题跑一遍很快，评分完全自动化，结果可复现。对于刚接触代码大模型的人来说，HumanEval 分数是一个不错的起点，能快速判断一个模型在基础 Python 编程上大概处于什么水平。很多模型发布时也会把 HumanEval Pass@1 作为一个标配指标放出来，方便横向对比。
它的局限性也很明显。任务集只有 164 道题，覆盖面有限，题目风格偏算法练习，和真实开发中的代码差异很大。数据污染是个绕不开的问题，因为 HumanEval 太出名了，很多模型的训练数据里可能已经包含了这些题目和答案，导致分数虚高。我见过一些模型在 HumanEval 上刷到 90% 以上，但换个稍微复杂点的实际任务就表现平平。这种落差说明榜单分数和真实能力之间不能画等号。
还有一个容易被忽略的点是，HumanEval 只测 Python，而且只测函数级生成。多语言能力、代码调试、重构、性能优化、依赖管理这些维度它都覆盖不到。我现在的习惯是把 HumanEval 分数当成一个入门门槛来看，分数高的模型不一定好用，但分数太低的模型基本可以排除。它是一个筛选工具，不是一个决策工具。
2.4 主流基准的演进：从函数生成到真实仓库级任务
回顾这几年基准的演进路线，我感受到一条很清晰的主线，就是从孤立走向真实。早期的 HumanEval 和 MBPP 都是函数级任务，模型只需要在一个封闭的小环境里输出一段代码。后来的 SWE-bench 把评测场景搬到了真实仓库里，模型要面对的是多文件、多依赖、有历史包袱的代码库。这个变化背后是整个行业对模型能力期待的升级，大家不再满足于“能写代码”，而是希望模型“能干活”。
LiveCodeBench 代表的是另一条演进方向，也就是动态评测。传统的基准一旦发布，题目就固定了，时间一长就会被训练数据覆盖。LiveCodeBench 的做法是持续收集新的竞赛题目，保持评测集的新鲜度，让模型没法靠背题拿高分。这个思路我觉得很聪明，它把评测变成了一个持续更新的过程，而不是一次性的静态考试。类似的做法还有 SWE-bench 的更新版本，会不断加入新的仓库和 issue。
再往前看，我注意到评测正在往 Agent 化方向走。现在的模型不只是生成代码，还要会调用工具、跑测试、读报错、自己迭代。评测基准也开始模拟这种多轮交互的场景，比如让模型在一个沙箱环境里自主完成一个完整的开发任务。从函数生成到仓库级任务，再到端到端的 Agent 评测，这条演进线反映的是模型编程能力评价标准的不断升维。我现在看一个新基准，会先判断它处于这条线的哪个位置，再决定它适合回答什么问题。
3.1 2025 年 AI编程模型排名 2025最新 的主要榜单来源
2025年想搞清楚编程模型到底谁强谁弱，光看官方博客已经不够用了。我这一年盯下来的榜单大概分三类，一类是学术味重的研究基准，比如 LiveCodeBench 和 SWE-bench Verified，题目定期更新，专门防着模型背题。另一类是实战派平台，像 Aider Polyglot 排行榜，直接让模型改真实代码仓库，跑单元测试，看谁改得又快又准。还有一类是 LMArena 的 WebDev 榜单，靠人投票，程序员自己选哪个模型写的代码更靠谱。这三类榜单的视角差异特别大，我一般会交叉着看，不会只信一家。
Artificial Analysis 和 Vals AI 这类独立评测机构我也常逛。它们的价值在于会把多个基准整合成综合分，同时给出价格、速度、上下文长度这些工程维度的数据。Vals AI 还有个法律、金融、编程的行业细分榜，对判断模型在特定领域的真实水平帮助不小。我注意到一个问题，很多榜单的测试集和模型训练数据有重叠风险，尤其 HumanEval 这种老基准，分数通胀得厉害，2025年还在拿 HumanEval 80分说事的宣传基本可以忽略。
各家模型厂商自己发布的 benchmark 我也会看，心态是当参考不当证据。厂商选出来的题目、采样次数、评测环境往往对自家模型有利，同一道 SWE-bench 题，有的报 Verified 版，有的报 Full 版，分数差出去十几个点。我现在养成一个习惯，看到一个新榜单先翻它的方法论说明，搞清楚任务类型、评分规则、数据来源，再决定这个分数值不值得记在脑子里。
3.2 国际主流模型编程能力表现：GPT、Claude、Gemini 等
2025年国际市场基本是三家在编程赛道上贴身肉搏。Claude 系列在 SWE-bench Verified 上的表现一直很抢眼，Claude 4 系列（Sonnet 和 Opus）在仓库级任务里展现出很强的任务拆解和长上下文理解能力。我用 Claude 写代码的时候，最明显的感受是它改代码比较克制，不会动不动就重写整个文件，而是精准地定位到该动的那几行。这个特质在维护老项目时特别值钱。Aider Polyglot 榜上 Claude 也常驻头部，多语言代码编辑的稳定性不错。
GPT 系列在 2025 年的编程能力进步幅度让人印象深刻。GPT-5 和 o 系列推理模型在竞赛类题目上的表现很强，Codeforces 那种带时间压力的算法题，推理模型能靠着思维链一步步推出来。我实测下来感觉 GPT 的风格偏全面，从函数生成到复杂重构都能接，但具体任务上的稳定性偶尔会波动。它在 LiveCodeBench 这种动态基准上的分数一直紧跟第一梯队，说明底子扎实，不是靠背题撑起来的。
Gemini 2.5 Pro 是这半年我越来越常用的一个。它在多模态代码理解上有独到之处，比如给它一张 UI 截图让它写出对应前端代码，或者给个架构图让它生成服务骨架，完成度比其他家高。Gemini 的上下文窗口撑得很大，整个中型仓库丢进去做分析不太费劲。SWE-bench 上的成绩它跟 Claude、GPT 咬得很紧，差距经常在几个百分点以内，Aider Polyglot 的性价比排名里它也常出现。一家之言是，这三家现在没有绝对的王者，选谁更多看你的技术栈和任务类型。
3.3 国产大模型编程能力表现：DeepSeek、Qwen、GLM、Kimi 等
国产模型这两年的追赶速度超出了我最初的预期。DeepSeek 系列是我身边开发者讨论最多的，DeepSeek-V3 和 R1 在开源阵营里长期占据编程榜前列，SWE-bench 上的成绩已经能跟国际一线模型掰手腕。我用 DeepSeek 跑过几轮代码重构任务，它的代码风格偏简洁，注释少但逻辑紧凑，适合有一定经验的开发者。开源权重这一点对国内企业吸引力极大，私有化部署不用再走申请审批那一套。
Qwen 系列的编程能力在 2025 年也站稳了第一阵营。Qwen3 系列在多个开源榜单上分数很高，尤其是代码补全和函数级生成任务，响应速度快，成本低。我做一些脚本类的小工具时经常用 Qwen，基本是秒回，正确率也够用。Qwen 的多语言能力相对均衡，Python、JavaScript、Go、Java 都有不错的支持，这点对做全栈的团队比较友好。GLM 系列在 Agent 化编程任务的适配上有自己的思路，工具调用和结构化输出做得比较规整。Kimi 的长上下文能力放在代码库分析场景里挺实用，丢进去几千行代码让它梳理调用关系，基本能跟得住。
国产模型的共同优势是价格和本地化。API 调用成本通常只有国际模型的几分之一，中文注释和中文技术文档的理解上也更顺。我看到的差距主要在超复杂任务上，比如涉及跨模块重构、微服务架构调整这类需要深度工程判断的场景，国产头部模型和国际顶尖还有一段路要追。日常业务开发、数据处理、脚本自动化这些占大头的场景，国产模型已经完全够打。
3.4 排名变化趋势：从单轮生成到 Agent 化编程
这一年榜单最大的变化，我觉得是评测对象本身变了。2024年大家还在比谁的函数写得好，2025年的榜单越来越关注模型能不能像 Agent 一样干活。SWE-bench 的权重一路走高就是信号，这个基准考的是模型在一个真实仓库里自主定位问题、修改代码、跑测试、迭代修复的完整流程。能在这个榜上拿高分的模型，通常也能在 Cursor、Cline、Claude Code 这类工具里表现出色。
Agent 化编程对模型的要求跟单轮生成完全不是一个量级。模型得会规划任务步骤，会调用工具，会读报错信息，还得知道什么时候该停下来问人。我观察到头部模型都在往这个方向加能力，Claude 的 computer use、GPT 的 reasoning 模式、Gemini 的长上下文加工具链，都是在为 Agent 场景铺路。榜单的评测方式也跟着变，从单轮输出比对变成了多轮交互轨迹评估，指标从 Pass@1 慢慢转向任务完成率、修复成功率、人类干预次数这类更工程化的数据。
这个趋势对选型的影响很直接。你如果是给 IDE 加个代码补全，看 HumanEval 和 MBPP 的分数就够了。你要做的是自动化修 bug、自动生成 PR 这类事，就必须盯着 SWE-bench 一类的 Agent 榜单看。我自己现在评估一个新模型，会先问一句，它是为单轮生成优化的，还是为 Agent 流程优化的。这个问题的答案，往往比榜单上高出来的那两三分更能决定它适不适合你的场景。
4.1 代码补全与函数级生成：适合参考哪些排名
日常写代码的时候，补全和函数级生成是我用得最多的功能。这种场景下，HumanEval 和 MBPP 的分数还是有参考价值的，它们考的就是给函数签名和注释，模型能不能把函数体写对。我平时打开一个新模型，会先跑几道 HumanEval 题目感受一下，看看它写的代码风格顺不顺眼，边界条件处理得细不细。这两个基准的题目不算难，但能把基本功看得比较清楚，如果一个模型连 HumanEval 都写得磕磕巴巴，指望它在复杂场景里表现好就不太现实。
MBPP 我也常看，它比 HumanEval 更贴近日常的短代码片段生成，题目描述用的是自然语言，模型需要自己理解要写什么。这个基准对补全工具选型比较有用，因为补全场景下用户给的上下文本来就少，模型得靠有限信息推断意图。LiveCodeBench 的函数级子集我也留意，它的题目每月更新，不容易被训练数据污染，分数更干净一些。LMArena 的代码聊天榜偶尔翻翻，看看程序员群体对各家补全体验的主观评价，有时候榜单分数差不多，用起来的手感差异反而挺明显。
我选补全模型的时候，看的不只是正确率。响应速度、延迟稳定性、对上下文的利用效率都很关键，一个 Pass@1 高但每次要等三秒的模型，放进 IDE 里用起来是折磨。Qwen 系列在这方面给我的体验一直不错，小任务秒回，正确率也够用。Copilot 背后的模型切换我感知不强，但我自己配过 DeepSeek 和 Claude 做补全，延迟和质量的平衡点各有取舍。补全这个场景，性价比和速度的权重其实比榜单上的名次更重要。
4.2 Bug 修复、重构与代码审查：SWE-bench 类指标更关键
一旦任务从写新代码变成改旧代码，评估逻辑就完全不同了。修 bug、重构、代码审查这三件事，考的是模型对现有代码库的理解能力、定位问题的准确性、以及改动的最小化程度。SWE-bench 和 SWE-bench Verified 就是为这个场景设计的，它给模型一个真实的 GitHub 仓库和对应的 Issue 描述，让模型自己找到问题文件、写出补丁、跑通测试。我在实际项目里用下来，SWE-bench 分数高的模型，改代码确实更靠谱，不会动不动把整个文件重写一遍。
SWE-bench 的评测方式有个我喜欢的地方，它看的是补丁能否让测试通过，而不是代码写得漂不漂亮。这个标准和工程实践很接近，能跑通、不引入回归、补丁尽量小，就是好活。Claude 系列在这类任务上的表现我一直比较认可，它改代码很克制，定位精准，知道哪些地方不该动。GPT 在复杂 bug 上推理链条更长，有时候能找到更根本的原因，但偶尔也会改得太多，需要人再往回拉一拉。
代码审查这个场景更微妙一些，它不只是找 bug，还包括风格一致性、命名建议、潜在的性能问题、安全隐患。这个能力目前没有特别权威的单一榜单，SWE-bench 只能部分反映。我看过一些模型在 CodeReviewer 类数据集上的表现，差异挺大，有的模型能把安全漏洞指出来，有的只会说些“这里可以加个注释”的废话。Aider Polyglot 的多语言编辑榜对重构场景有参考价值，它会让模型在多种语言的项目里做修改并跑测试，能看出模型跨语言重构的稳定性。选重构类工具的时候，我会优先看 SWE-bench Verified 和 Aider 的成绩，HumanEval 在这种场景下基本没什么说服力。
4.3 算法竞赛、复杂推理与多语言开发：如何交叉看榜
算法竞赛类的任务我平时接触得不多，但团队里做算法岗的同事会经常参考 Codeforces 和 LiveCodeBench 的榜单。Codeforces 的评分体系比较硬核，模型需要在限时条件下解出难度递增的题目，拿到接近人类选手的 Elo 分数才算真本事。o 系列和 GPT-5 在这类带推理链的竞赛题上表现突出，能一步步推演，把复杂问题拆成子问题。我试过用推理模型做 LeetCode 困难题，确实比普通模型稳，但代价是推理时间长，tokens 消耗高，不适合高频调用。
LiveCodeBench 我更喜欢用来交叉验证，它的题目每月更新，防污染做得比较认真，而且覆盖竞赛题、面试题、代码修复多种类型。一个模型如果只在 HumanEval 上分数高，在 LiveCodeBench 上掉下来，那基本可以判断它的成绩有水分。多语言开发场景下，Aider Polyglot 和 MultiPL-E 这类多语言基准更值得看，它们会测试模型在 Python、JavaScript、Rust、Go、C++ 等多种语言上的生成和编辑能力。我做过几个跨语言的项目，发现有的模型 Python 很强，换到 Rust 就露怯，所有权和生命周期一塌糊涂。
交叉看榜是我现在比较常用的方法。把 HumanEval、LiveCodeBench、Codeforces、Aider Polyglot 的分数拉一张表，看模型在不同维度上的分布，比盯单一榜单的数字有意义得多。一个模型如果各项都稳定在前列，用起来一般不会太差。某个模型只在特定基准上突出，其他榜单平平，我通常会先打个问号，找机会自己实测几轮再决定要不要接进工作流。
4.4 企业私有化、成本安全与生态集成：排名之外的决策因素
给企业做技术选型的时候，榜单分数只是起点，真正的决策因素往往在排名之外。私有化部署是很多国内企业的硬需求，数据不能出内网，开源权重就成了关键门槛。DeepSeek 和 Qwen 的开源版本在这方面优势明显，可以直接拿权重在自有服务器上部署，不用走 API。闭源模型即使能力再强，如果无法本地化部署，在很多合规场景下直接就被排除掉了。我参与过几次企业侧的模型选型，参数规模、显存要求、推理框架兼容性这些工程细节，讨论时间比看榜单分数长得多。
成本这件事我单独拎出来说。API 调用价格在大规模使用时差距会被放大，国产模型的价格通常是国际头部模型的几分之一甚至更低。一个日调用量大的代码助手，换成性价比更高的模型，一年省下来的钱可能够养一个工程师。安全方面还要考虑输出内容的合规、代码泄露风险、日志留存策略，这些都不是榜单能回答的问题。生态集成也重要，模型能不能接进企业现有的 CI/CD 流程、能不能跟 GitLab、Jenkins、内部知识库打通，直接影响落地速度。
我现在的做法是把决策拆成两层，先看榜单筛出能力达标的候选池，再用工程维度的清单去过滤。清单上大概包括部署方式、成本结构、响应延迟、上下文长度、工具调用能力、微调支持、社区活跃度这些项。走完这两层，剩下的选项通常就不多了。排名帮你缩小范围，真正拍板靠的还是跟具体业务场景的匹配度。我见过一些团队被榜单名次牵着走，选了能力最强但集成成本极高的方案，最后落地的效果反而不如选个分数中等但贴合现有技术栈的模型。
5.1 如何正确阅读模型编程能力排名：看指标、版本与任务集
榜单我看了快两年，踩过的坑不算少。打开一个排行榜，很多人第一眼找的是名次，我第一眼找的是它到底在测什么。Pass@1 和 Pass@10 听起来差不多，含义差得很远。Pass@1 是模型一次写对的概率，Pass@10 是允许生成十次只要有一次对就算过。有的榜单只标一个总分，不告诉你是哪种采样方式，这种数字拿来做决策很容易翻车。我现在的习惯是先拉到评测说明那一栏，看清楚指标定义、采样参数、温度设置，这些细节决定了分数能不能横向比较。
版本这件事也容易被忽略。同一个模型，今天刷到的分数和三个月前看到的可能完全不是一回事。厂商会更新权重，评测方会修订题目，提示词模板也会调整。我遇到过某模型在 HumanEval 上从 80 出头跳到 90 多，查了半天才发现是评测脚本的 few-shot 示例变了。看榜的时候我会顺手记一下日期和评测配置，尤其是准备写选型报告的时候，不注明版本的分数基本没法用。榜单之间的分数更不要直接混着比，SWE-bench 的解决率和 Codeforces 的 Elo 分，量纲都不一样，放一起排名没有意义。
任务集的构成也得看一眼。HumanEval 只有 164 道题，MBPP 大概 400 多道，样本量小的时候，一两道题的差异就能让名次上下浮动好几名。我见过两个模型差了 0.5 个百分点就被写进标题说“反超”，实际上在统计误差范围之内。LiveCodeBench 这种按月更新题目的基准，样本量和时效性平衡得相对好一些。看榜的时候我会优先信任那些公开题目集、公开评测脚本、有第三方复现记录的榜单，厂商自己发的新闻稿数据，参考价值要打个折扣。
5.2 避免唯排名论：数据污染、评测偏差与真实项目验证
数据污染是现在看榜绕不开的问题。HumanEval 的题目早就进了各种训练语料，模型见过原题和没见过原题，分数差距可能很大。我做过一个小实验，把 HumanEval 里的函数名改掉、变量名换一遍，再让几个模型写，有几个模型的表现明显下滑，这就说明它记住的是题目本身而不是解题能力。LiveCodeBench 按时间切分题目，就是为了缓解这个问题，模型训练数据截止到某个时间点，题目从之后开始出，分数更接近真实泛化能力。看到某个模型在旧基准上高得离谱、在新基准上平平无奇，我会先怀疑它的成绩里有背诵成分。
评测偏差还有另一层。基准题目的风格偏学术，很多是算法题、函数题，跟企业里真实的代码库差别很大。真实项目里代码是成百上千个文件，有历史包袱，有奇怪的依赖关系，有写了一半的注释和 TODO。我让模型在真实仓库里改 bug，表现和 HumanEval 排名往往对不上号。有的模型解算法题很溜，进了真实项目就找不到北，因为它不习惯在噪音里定位问题。这种偏差不是榜单的错，是榜单的边界，用的人得心里有数。
我现在的做法是榜单当筛子，不当裁判。先用榜单把明显不行的模型排除掉，剩下的候选者全部拉进真实项目里跑几轮。验证的方式也很朴素，拿团队里积压的真实 Issue 让模型试着修，看补丁能不能过 CI，看改动范围合不合理，看它会不会把无关的代码也顺手改了。这个过程花时间，但比事后返工划算。我印象很深的一次，某个榜单排名前十的模型在补全场景表现很好，一进代码审查场景就开始胡说，把正常的写法标成问题，把真正的隐患漏掉。榜单上没有这个维度的分数，只有自己试了才知道。
5.3 动态评测趋势：多轮协作、真实仓库与端到端交付
评测方式这两年变化挺大。早期的基准都是单轮生成，给一个函数签名，模型写出来，跑测试，完了。现在的趋势是往多轮、往真实环境走。SWE-bench 已经算是往这个方向迈了一大步，它给的是真实仓库和真实 Issue，模型要自己探索代码结构、定位文件、写补丁、跑测试、根据报错再调整。这个过程里模型不只是写代码，还要会用工具、会读报错、会做决策。我观察下来，能在 SWE-bench 上拿高分的模型，通常也更能适应 Agent 化的编程工作流。
Agent 化编程是我最近比较关注的方向。模型不再只负责生成片段，而是接管一整个任务链，自己拆解需求、调用终端、读写文件、运行测试、提交 PR。这种模式下，评测的维度就变了。单次生成的正确率没那么重要了，重要的是模型能不能在多次尝试中收敛，能不能从失败里恢复，能不能控制改动范围。有些新出的基准开始测“任务完成率”“平均修复轮数”“回归引入率”这些指标，比 Pass@k 更贴近工程实际。我看好这个方向，虽然现在的评测标准还很粗糙，但至少往真实场景靠了。
端到端交付是更远一点的目标。让模型从一句需求描述开始，自己完成设计、编码、测试、部署，中间不需要人插手。现在离这个目标还有距离，但一些演示已经能跑通简单的全流程。这个趋势对排名的影响是，未来榜单可能不再比单点能力，而是比整条链路的完成质量。我在团队里试过让模型独立完成一个内部小工具的开发，从建仓库到写测试到打包，全程只给需求文档。结果不算完美，中间卡了几次，但它自己查文档、自己改配置、自己重试，最后还是跑起来了。那一刻我意识到，评测的范式确实在变。
5.4 未来展望：编程能力排名将走向综合工程能力评价
我对排名的未来有一个判断，纯代码生成的榜单会慢慢退到二线，综合工程能力的评价会走到台前。原因不复杂，模型写代码这件事本身已经做得不错了，瓶颈转移到了别的地方。怎么理解模糊的需求，怎么在大型代码库里做权衡，怎么跟人协作，怎么在约束条件下做取舍，这些能力目前还没有被很好地量化。未来的排名大概率会把这些维度拆出来，分别打分，再合成一个工程能力画像。单看一个总分就能选型的好日子可能快结束了。
综合工程能力评价会带来几个变化。评测环境会更接近真实，可能是模拟的代码库、模拟的团队协作、模拟的 CI/CD 流水线。评测周期会拉长，不再是跑几百道题出个分，而是让模型在环境里工作几天甚至几周，看它的长期表现。评测指标也会更多元，正确率之外会加入可维护性、安全性、成本效率、协作友好度这些项。我甚至觉得可能会出现针对特定行业的垂直榜单，比如金融、医疗、嵌入式，因为不同领域的工程约束差别太大，通用榜单给出的信号会越来越弱。
这些变化对用榜单的人来说，意味着得换一套阅读方法。以前是找名次，以后可能是找画像，看模型在哪些维度强、哪些维度弱，跟自己的场景匹不匹配。我自己的选型清单已经在往这个方向调整了，除了能力分数，还会记录模型在长任务里的稳定性、工具调用的可靠性、以及跟现有技术栈的磨合成本。榜单会继续有用，但它提供的是参考，不是答案。真正的问题始终是那句老话，这个模型放到我的项目里，到底能不能把活干好。
