选 AI 编程工具或模型时，最容易被误导的就是那些「编程能力」榜单：某模型 LeetCode 全对、某 benchmark 通过率九十几。数字很漂亮，但你真正在意的问题是——它能不能在我这个又老又乱的真实项目里，改对一个 bug 而不改坏三个地方？ 这两件事的相关性，比想象中低得多。
刷题考的是「从零写一个独立、边界清晰的小函数」，而真实开发是「在一大堆已有代码、隐性约定和依赖关系里做局部修改」。前者强不代表后者行。这篇文章讲清刷题类评测的局限、真实编程能力该怎么测的维度，以及怎么用你自己的代码库搭一套有意义的评估集。方法论和《如何评测一个大模型》一脉相承，这里聚焦编程这个特殊场景。
刷题考「从零写小函数」，真实开发考「在存量代码里做局部修改」——两者能力并不等价。
为什么刷题分数会骗人
刷题类 benchmark（算法题、独立函数题）有几个和真实开发脱节的地方：
- 任务形态不同：刷题是「给一个干净的题目，从零写解法」；真实开发是「在几万行代码里定位、理解、局部修改」，还要不破坏现有功能。后者对「读懂上下文」的要求远高于「写出算法」。
- 数据污染：热门算法题、经典 benchmark 很可能已进入训练数据，模型是「见过答案」而非「真会解」，分数虚高。
- 没有工程约束：刷题不考代码风格一致性、不考向后兼容、不考团队约定、不考「改动别越界」——而这些恰恰是真实项目里 AI 最容易翻车的地方。
- 单点 vs 系统：刷题是孤立的点，真实任务牵一发动全身，需要全局视野——正是 AI 的短板。
所以刷题分数可以用来「排除明显不行的」，但绝不能用来「选出最适合你项目的」。
真实编程能力该测哪些维度
把「编程能力」拆成对真实开发有意义的维度：
| 维度 | 问什么 |
|---|---|
| 定位能力 | 在大代码库里能不能找到该改的地方 |
| 上下文遵循 | 改动符不符合项目已有的风格、约定、架构 |
| 改动精准度 | 是最小必要改动，还是顺手改了一大片 |
| 正确性 | 功能对不对、有没有引入 bug、边界处理了吗 |
| 不破坏性 | 有没有改坏其他功能（回归） |
| 幻觉控制 | 有没有调用不存在的 API、编造依赖 |
| 可验证性 | 写的测试是真测试还是摆设 |
| 效率与体验 | 完成一个任务要来回多少轮、花多少 token |
注意，「能不能写出算法」在这张表里只是「正确性」的一小部分。对真实开发，定位、上下文遵循、不破坏性往往比算法能力更决定体验。
更接近真实的评测方法
业界在往「真实任务」方向走，值得参考的思路：
- 基于真实仓库的任务集：给一个真实项目和一个真实 issue，让模型提交修复，用项目自带的测试判断是否真的修好——这类评测（如 SWE-bench 一类的思路）比刷题接近真实得多，也解释了为什么很多模型「刷题很强、这类分数却不高」。
- 端到端看结果，而非看代码：不只看它写的代码「像不像对的」，而是跑起来看功能是否达成、测试是否通过。Code Agent 的核心优势就是能自我验证，评测也该用同样的硬标准。
- 多轮任务成本：真实使用是多轮交互的，要记录「完成一个任务平均几轮、多少 token、多少次返工」——一个「最终能做对但要来回二十轮」的模型，体验并不好。
最有说服力的评测：给真实 issue、让它提交修复、用项目自带测试判分——端到端看结果。
用你自己的代码库搭评估集
公开评测能缩小范围，但最终选型要用你自己的项目说话——因为工具在你的技术栈、你的代码风格、你的问题类型上的表现，才是你真正关心的。一套可操作的流程：
- 挑 10–20 个真实任务：从你项目的历史 issue、真实 bug、真实小需求里选，覆盖不同类型（修 bug、加功能、写测试、重构、跨文件改动）。太简单的没区分度，选有一定上下文依赖的。
- 定义清楚「做对」的标准：每个任务标注验收条件——哪些测试要通过、哪些行为要正确、哪些地方不能动。没有标准就没法客观比较。
- 同样的任务喂给候选工具/模型：控制变量，同一份任务、同样的项目上下文，跑一遍。
- 按维度打分：不只看「最终对没对」，也记录定位准不准、有没有越界改动、有没有幻觉、花了几轮。可以人工评，也可以对客观项（测试通过率）自动化。
- 叠加工程指标：成本、延迟、稳定性一并记录。质量接近时，快而便宜的胜出。
这套评估集一旦建好就是长期资产：新模型、新工具出来，跑一遍就知道值不值得换，不必被营销数字牵着走。
用自己项目的 10–20 个真实任务建评估集，比任何公开榜单都更能回答「哪个工具适合我」。
适用人群与替代方案
适合要为团队选 AI 编程工具/模型、或想验证「换个模型是否更好」的技术负责人和开发者。如果你是个人轻度使用，不必这么正式——拿你手头几个真实任务，让候选工具各做一遍，凭体验选也够了，关键是一定要用真实任务而非玩具例子。可以参考站内的 AI 编程助手横评和 AI IDE 测评缩小候选，再用自己的任务做最终决定。
常见问题
Q：那些「编程能力第一」的模型榜单完全没用吗？ A：不是没用，它能帮你快速排除明显弱的、圈定第一梯队。但「第一梯队里哪个最适合我的项目」，榜单答不了，只能用你自己的任务测。把榜单当粗筛，别当终判。
Q：评测要不要区分「模型」和「工具」？ A：要。同一个模型，配上不同的编程工具（上下文管理、检索、验证能力不同），实际表现可能差很多。测的时候明确你是在选模型还是选工具，或者干脆按「模型+工具」的组合整体评测——因为你最终用的是组合。
Q：怎么测「会不会改坏项目」？ A：这正是要跑项目完整测试套件的原因。让工具改完后跑全量回归测试，看有没有把别的功能弄坏。没有测试覆盖的项目，就靠人工 review 关键路径，参考 AI 代码 review 清单。
小结
测 AI 编程能力，别被刷题分数骗了：那考的是「从零写小函数」，你要的是「在存量项目里改对而不改坏」。真实能力要看定位、上下文遵循、改动精准度、不破坏性这些维度，用「真实 issue + 跑测试判分」的端到端方法评测。而最终选型，一定要用你自己代码库里的 10–20 个真实任务搭评估集——在你项目上的表现，才是唯一算数的分数。