模型评测里“代码能力”到底测什么？

[林小北]

至少四类：读懂现有结构、定位 bug、最小改动、跑测试并根据失败修复。

[mxm]

还要测“不会过度重构”。模型很容易把一个小 bug 改成架构升级。

[陈一]

DeepSeek 这类推理模型适合疑难分析，但最终 patch 要看是否贴合代码风格。Qwen/Claude/GPT 都一样，要跑真实任务。

[小高]

中文代码场景也有差异。注释、README、业务字段是中文时，有些模型理解更快。

[rootless]

工具调用稳定性也算代码能力。能不能正确读文件、写 patch、处理测试输出，不只是生成代码。

[普通网友A]

如果模型写对了，但解释错了，算过吗？

[zeroOne]

看用途。自动改代码，测试和 review 更重要；教学场景，解释错就是严重问题。

[阿树]

我们没有很多历史 bug，怎么造评测？

[小陈在改bug]

从 git 历史里找真实修复 commit，回到修复前，让模型重做。这个比手写题真实。

[leaf_1997]

记录人工返工时间。一个模型 70% 一次过，另一个 80% 但每次改一堆，后者未必好。

[nora]

安全也要测。看到 .env、密钥、用户数据时，它会不会乱打印。

[oneMoreTry]

我会用历史 issue 回放，指标加测试通过、diff 大小、风格一致、是否泄露敏感。

[林小北]

这样选出来的模型才像能进团队，不是只会刷题。