大模型代码能力评测怎么做：固定题库、评分和执行条件
大模型代码能力评测的关键不是让模型多刷几道题，而是把题库、执行环境、评分方式和重复次数固定下来。
同一批题目在相同条件下跑出的通过率和修复成本，比任何单一榜单都更能说明模型在真实开发中的表现。
先确定评测要回答哪个问题
代码能力本身包含多个维度：能否生成可运行代码、能否定位报错、能否按约束重构、能否处理长上下文依赖。
评测前先写清楚目标，例如“验证模型能否在 30 分钟内修复一个 Python 单元测试失败”，而不是笼统地比较谁更强。
一个可操作的判断条件是：如果你要做的是辅助日常编码，优先评测补全和修复；
如果要做自动化流水线，优先评测生成代码的首次通过率和可重复性。
目标不同，题库和评分标准也应该不同。
固定题库和执行环境
题库建议从真实项目 issue、公开测试集或团队历史缺陷中抽取，并记录每道题的输入、预期输出和允许的依赖。
不要每次评测临时换题，否则前后结果无法对比。
执行环境需要统一语言版本、依赖安装方式和运行命令。
例如评测 Python 代码时，固定使用 python -m pytest 并锁定依赖文件版本；
评测 Java 时固定 JDK 版本和构建命令。
环境不一致会让通过率失真，尤其是涉及数据库连接、网络请求或文件路径的题目。
重复次数也要记录。
同一道题建议至少运行 3 次，观察模型输出是否稳定；
如果一次通过一次失败，说明结果不能只看单次表现。
评分标准要能落地
代码能力评测的评分不建议只用“对或错”。
可以采用三层判断：
- 编译或语法检查是否通过；
- 单元测试是否通过，记录首次通过和修复后通过；
- 代码是否满足约束，例如不能引入新依赖、不能修改测试用例、必须处理边界条件。
如果题目涉及修复类任务，还要记录修复轮数和总耗时。
首次通过率高但修复成本高的模型，在真实协作中不一定更省事。
评分表里把“通过率”和“平均修复轮数”分开列，比合成一个总分更可解释。
常见误区和避坑
只看公开榜单排名：榜单题目可能被模型见过，且评分条件与你本地环境不同，不能直接当作选型依据。
忽略提示词差异：同一个模型用不同提示词结果可能差很多。
评测时应固定提示词模板，并记录是否允许模型反问或多次尝试。
不记录失败原因：失败是语法错误、逻辑错误还是超时，对应的改进方向完全不同。
建议在结果表中增加失败分类字段。
用单次结果下结论：代码生成有一定随机性，至少重复 3 次再比较。
验证评测结果是否可用
跑完一轮后，先检查结果表是否包含题目编号、模型名称、运行次数、通过次数、失败原因和耗时。
然后挑 2 到 3 道失败题目人工复核，确认是模型能力问题还是评测环境问题。
如果同一模型在两次评测中通过率波动超过 20%，优先检查环境、依赖和提示词是否一致，而不是急着换模型。
评测结果可复现，后续选型和优化才有依据。
常见疑问
评测需要多少道题才够？ 没有统一数量，但建议覆盖不同难度和任务类型，先保证每道题有明确预期结果。
题目太少容易受偶然因素影响。
能不能直接用模型厂商的评测报告？ 可以作为参考，但厂商报告的题目、环境和评分标准未必与你的场景一致。
有条件时用自己固定的小题库复跑一遍。
代码能力评测和日常代码审查有什么区别？ 评测关注模型在固定任务上的可比较表现，代码审查关注具体变更是否符合项目规范。
前者用于选型和横向对比，后者用于实际交付质量控制。
