Qwen3-Coder 仓库内 DevQualityEval v0.5.0 评测报告详解：以 nous-capybara-7b 为例读懂 LLM 代码生成质量报告
【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder
本篇技术文章基于仓库中qwencoder-eval/instruct/eval-dev-quality模块自动生成的一份真实评测报告（nous-capybara-7b 报告）展开，系统讲解 DevQualityEval 基准的七类模型分类体系、三份 CSV 结果文件的字段含义与交叉校验方法，以及如何结合 benchmark 主 README 和源码完整复现一份报告。读完本文，你将掌握解读该基准任意一份模型评测报告的方法，并能独立运行eval-dev-quality对 LLM 的代码生成质量（可执行性、语句覆盖率、响应规范性）进行量化评估。
报告的来源与定位：这是一份自动生成的评测快照
该报告文件 README.md 并非手写文档，而是由 DevQualityEval 基准（Symflower 开源的 LLM 代码生成质量评测框架，本仓库收录于 eval-dev-quality 目录）自动生成的结果文档。报告头部给出了两个关键元信息：
- 评测时间戳：
Evaluation from 2024-06-19 10:47:13，即该快照的产生时刻； - 生成器与版本：
This report was generated by DevQualityEval benchmark in version 0.5.0。该版本号与源码中 evaluate/version.go 里的Version = "0.5.0"常量完全一致，可据此确认报告对应的基准版本。
报告同时附有一句重要的免责说明（原文）：
Keep in mind that LLMs are nondeterministic. The following results just reflect a current snapshot.
即 LLM 输出具有非确定性，报告只反映某一次运行的结果快照，不能视为该模型的固定能力值。本次评测的对象是通过 OpenRouter 接入的openrouter/nousresearch/nous-capybara-7b模型（模型标识前缀openrouter/即主 README 中说明的最便捷接入方式），评测任务为write-tests（为既有代码仓库生成单元测试）。
七类模型分类体系：从结果到类别的完整映射
报告的核心是"分类"（category）机制：每个参评模型会被归入且仅归入以下七个类别之一，原文档对这七类给出了完整定义：
- category unknown：无法归类的模型；
- response error：模型在产生响应时遇到错误；
- no code：模型响应中不含任何代码；
- invalid code：模型生成的代码执行时产生错误（即无效代码）；
- executable code：模型生成了可执行（无错误运行）的代码；
- statement coverage reached：模型生成的代码达到了 100% 语句覆盖率；
- no excess response：模型没有输出超出要求的内容（响应简洁规范）。
这七类并非仅存在于文档措辞中，它们在源码中有精确的一一对应。evaluate/metrics/category.go 定义了全部AssessmentCategory结构，例如：
// ID 分别为：category-unknown / response-error / response-no-code / // code-invalid / code-executed / code-coverage-statement / code-no-excess AssessmentCategoryCodeCoverageStatementReached = registerAssessmentCategory(AssessmentCategory{ ID: "code-coverage-statement", Name: "statement coverage reached", Description: "Models in this category produced code that reached full statement coverage.", })分类的判定逻辑实现在同文件的Category()方法中（category.go#L79-L98），其规则值得特别注意——"一致性原则"，源码注释解释为：
模型的总类别对应于"在所有任务上都稳定拿到满分"的那一条标准。例如共 3 个任务，模型在全部任务上都产出了可执行代码，但只有 1 个任务达到覆盖率目标，则其类别只能是
CodeExecuted，因为覆盖率目标并未被一致地达成。
具体判定顺序是一个switch级联：
- 响应无错误分 ≠ 满分 →
response error； - 响应含代码分与"文件可执行"分均未满分 →
no code（源码中保留了 issue #43 的 TODO：因不能总是检测响应是否含代码，若代码实际全部成功执行则不判入 no code）； - 文件可执行分未满 →
invalid code； - 覆盖率分未满 →
executable code； - 无多余响应分未满 →
statement coverage reached； - 全部满分 →
no excess response。
而category unknown在源码中对应"任务总数为 0"的兜底分支（category.go#L80-L82）。
三份 CSV 的字段详解与本模型的完整数据
报告正文声明："完整评测日志见 evaluation.log，详细打分明细见 evaluation.csv"。需要说明：当前仓库该目录下实际只包含README.md、categories.svg和三份 CSV（evaluation.csv、models-summed.csv、golang-summed.csv、java-summed.csv），全量日志evaluation.log并未随仓库分发，因此文章以下面的 CSV 数据为准。
evaluation.csv 是逐任务（per-task）明细，表头字段为：
model, language, repository, task, score, coverage, files-executed, generate-tests-for-file-character-count, processing-time, response-character-count, response-no-error, response-no-excess, response-with-code
本模型的三条任务记录（原样摘录）：
| 仓库 | 任务 | score | coverage | files-executed | 待生成测试文件字符数 | 处理时长(ms) | 响应字符数 | no-error | no-excess | with-code |
|---|---|---|---|---|---|---|---|---|---|---|
| golang/plain | write-tests | 10 | 0 | 0 | 732 | 12871 | 986 | 5 | 2 | 3 |
| java/light | write-tests | 6549 | 6210 | 57 | 104103 | 961295 | 113468 | 115 | 76 | 91 |
| java/plain | write-tests | 22 | 10 | 1 | 7048 | 45837 | 7102 | 5 | 3 | 3 |
字段含义可结合报告分类体系与源码理解：
- score / coverage：任务总分与语句覆盖率得分（write-tests 任务的核心目标是让生成的测试代码覆盖被测代码的语句）；
- files-executed：成功执行（生成并通过运行）的测试文件数；
- generate-tests-for-file-character-count：被测目标源码的字符数，体现任务规模（java/light 的 10.4 万字符远大于 golang/plain 的 732 字符）；
- processing-time / response-character-count：单次请求的处理耗时（毫秒）与响应长度；
- response-no-error / response-no-excess / response-with-code：三类"评估项"（assessment）的累计得分，正是上一节
Category()判定所读取的AssessmentKey*键值来源。
另外两份 CSV 是按语言/整体维度的汇总，用于快速核对：
- models-summed.csv（跨语言合计）：score=6581、coverage=6220、files-executed=58、处理时长合计 1020003ms、响应字符 121556、no-error=125、no-excess=81、with-code=97；
- golang-summed.csv：10 / 0 / 0 / 732 / 12871 / 986 / 5 / 2 / 3；
- java-summed.csv：6571 / 6220 / 58 / 111151 / 1007132 / 120570 / 120 / 79 / 94。
数据自洽性校验（读者可用此方法核对任意一份报告）：java 汇总 + golang 汇总应等于 models 汇总。逐项验证：6571+10=6581 ✓；6220+0=6220 ✓；58+0=58 ✓；1007132+12871=1020003 ✓；120570+986=121556 ✓；120+5=125 ✓；79+2=81 ✓；94+3=97 ✓。汇总数据与逐任务明细完全吻合。从明细还可看出该模型的明显偏科：java/light（大仓库）拿到 6210 覆盖率分、57 个文件执行通过，而 golang/plain 与 java/plain 两个小仓库的覆盖率均为 0/接近 0，且 java 大任务的单次耗时（约 961 秒）占总耗时的 94%。
报告头部的 categories.svg 是与上述七类对应的"每个类别中模型数量"柱状图，本目录只有 1 个模型，图中该模型落在category unknown一档。
为什么该模型被列在 "category unknown" 分类下
报告 Results 小节最后的逐模型清单，将openrouter/nousresearch/nous-capybara-7b列于Result category "category unknown"（"Models in this category could not be categorized"）之下。这一点与evaluation.csv中存在三条完整任务打分明细并存，值得留意。
从源码结构看，AssessmentCategoryUnknown是Category()方法在totalTasks == 0时返回的兜底类别（category.go#L79-L82），报告 Markdown 的生成逻辑位于 evaluate/report/markdown.go。可以推断：该模型在报告生成时刻用于判定类别的评估项聚合为空（任务数为 0），因此落入 unknown 桶；而同一评测进程产生的逐任务 CSV 明细仍然落盘。这提醒使用者：报告首页的分类结论必须与 CSV 明细一起阅读，单看分类可能低估或误判模型实际产出；反过来，CSV 中有分不代表分类桶里一定"好看"。这正是报告强调"结果只是当前快照"的深层原因。
被评测的对象：write-tests 任务与其仓库集合
本次报告评测的任务标识符是write-tests，它在源码中注册于 evaluate/task/task.go（IdentifierWriteTests = registerIdentifier("write-tests")），具体实现与"仓库形态校验"在 evaluate/task/task-write-test.go（如validateWriteTestsRepository检查 write-tests 任务所用仓库是否结构完整）。该基准还支持code-repair、transpile、write-tests-symflower-fix等任务（同目录task-*.go文件），write-tests 是其中与"代码质量"直接相关的一类：要求模型为给定仓库编写测试，并以测试能否执行、能覆盖多少语句作为客观打分依据，而非依赖人工或 LLM 判分。
报告 CSV 中的三个取值golang/plain、java/light、java/plain即本次评测所用的目标仓库（语言/规模档位），与 CSV 的language列和两份分语言汇总 CSV 一一对应。
如何复现这份报告：安装与运行步骤
依据 eval-dev-quality 主 README，复现路径如下（适用前提：本机已安装 Git 与 Go）：
# 1. 安装 git clone https://github.com/symflower/eval-dev-quality.git cd eval-dev-quality go install -v github.com/symflower/eval-dev-quality/cmd/eval-dev-quality # 2. 配置 OpenRouter 接入密钥（最便捷的 provider） export PROVIDER_TOKEN=openrouter:${your-key} # 3. 在全部模型与仓库上运行基准任务 eval-dev-quality evaluate运行结束后，输出为一份包含所有请求/响应与所执行命令的详细日志，最终结果保存到evaluation.csv，并生成类似本文剖析的按模型目录组织的 Markdown 报告（即docs/reports/<version>/<model>/README.md结构）。
README 中有一条安全警示必须遵守：
This project does not execute the LLM generated code in a sandbox by default. Make sure that you are running benchmarks only inside of an isolated environment, e.g. by using
--runtime docker.
基准默认不在沙箱中执行 LLM 生成的代码，务必使用--runtime docker等隔离环境运行。
v0.5.0 报告族：单个模型报告在整个基准中的位置
本报告并非孤立文件，而是 docs/reports/v0.5.0/ 目录下数十个模型报告之一（同目录下还有deepseek-coder、gemini-pro-1.5、claude-3.5-sonnet、codeqwen等模型子目录，以及跨模型汇总的顶层evaluation.csv）。v0.5.0 版本的结果还配套了一篇深度分析文章（见主 README 的 "latest results" 链接说明），结论是"DeepSeek v2 Coder 与 Claude 3.5 Sonnet 在代码生成上比 GPT-4o 更具成本效益"。
因此，使用本仓库这份 nous-capybara-7b 报告的正确姿势是：单模型报告用于查看某模型在"响应规范性 → 可执行性 → 覆盖率"梯度上的落点，跨模型对比则应基于 v0.5.0 顶层evaluation.csv汇总。结合本文的字段解读与交叉校验方法，你完全可以对目录中任意一份模型报告做同等深度的解读，或运行基准生成新的快照来做模型迭代前后的质量回归对比。
【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder
创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
