企业官网建设流程全解析

Qwen3-Coder 评测档案解读：DevQualityEval v0.5.0 中 stripedhyena-nous-7b 的测试生成评测报告

【免费下载链接】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

本篇围绕 Qwen3-Coder 仓库中收录的一份具体评测报告展开——DevQualityEval基准 v0.5.0 对openrouter/togethercomputer/stripedhyena-nous-7b模型的评估结果。读完本文，你将了解这份报告的文件组织方式与字段含义、七个结果分类的判定逻辑（含源码级依据）、该模型在 Go/Java 测试生成任务上的逐项得分构成，以及如何在本仓库内复现同类评测。

1. 报告来源与定位

该报告位于 qwencoder-eval/instruct/eval-dev-quality/docs/reports/v0.5.0/stripedhyena-nous-7b/README.md，记录时间为2024-06-19 10:52:48，由 DevQualityEval 基准工具的version 0.5.0生成。

DevQualityEval 是 Qwen3-Coder 评测体系中内置的一个代码生成质量基准框架（见 qwencoder-eval/instruct/eval-dev-quality/README.md），用于回答两个问题：哪些 LLM 能完成软件开发任务？其结果质量如何？本次快照中，stripedhyena-nous-7b（通过 OpenRouter 提供的 StripedHyena 系列 7B 模型）被要求在Go 和 Java 两种语言上完成write-tests（测试生成）任务：给定源文件，生成能编译通过并达到 100% 语句覆盖率的单元测试。

该目录是 v0.5.0 批量评测的一部分：docs/reports/v0.5.0/ 下为 70 余个模型各建了一个结果目录（gpt-4o、claude-3.5-sonnet、deepseek-coder 等），并带有跨模型汇总文件models-summed.csv、golang-summed.csv、java-summed.csv，便于横向对比。

原文档特别强调了一点，本文的解读同样以此为前提：

LLM 是非确定性的，以下结果只反映一次评测的快照（snapshot），不代表模型的稳定能力。

每个模型目录内的文件结构如下：

需要说明：原文档中链接的逐请求完整日志（evaluation.log）与模型子目录在当前仓库中并未保留，本仓库内可供核查的是上述 CSV 文件。

2. 七个结果分类及其判定逻辑

报告定义了七个结果分类，按“门槛”从低到高排列（原文逐条定义）：

1. category unknown：无法被归类的模型。
2. response error：请求过程中遇到错误。
3. no code：响应中没有产出任何代码。
4. invalid code：产出的代码无法执行。
5. executable code：产出的代码可以执行。
6. statement coverage reached：代码执行且达到 100% 语句覆盖。
7. no excess response：响应中没有超出要求的内容（如要求“只给测试代码”却附带了说明文字）。

这些分类并非手工标注，而是由基准工具按评估项自动推断的。从源码 qwencoder-eval/instruct/eval-dev-quality/evaluate/metrics/category.go 看，判定规则是**“一致性达标”：一个模型的整体分类，对应它能够在所有任务中稳定拿满满分**的最高层级——源码注释举例说明，若共有 3 个任务、模型在 3 个任务上都产出了可执行代码、但只有 1 个任务达到覆盖目标，则分类只记为 “executable code” 而非 “statement coverage reached”，因为覆盖目标没有“一致性地”达成。

判定链条按顺序短路返回：

• 若response-no-error未拿满 →response error；
• 若response-with-code与files-executed均未拿满 →no code（源码中带有一个 TODO 说明：目前并非总能准确检测响应里是否含源码，因此只要代码确实全部跑通就避免误判为 “no code”，见 category.go#L87）；
• 若files-executed未拿满 →invalid code；
• 若coverage未拿满 →executable code；
• 若no-excess未拿满 →statement coverage reached；
• 全部拿满 →no excess response。

此外，分类注册表AllAssessmentCategories在 category.go#L31-L74 中通过registerAssessmentCategory集中登记并做重复 ID 检查，报告中的分类名称（如 "invalid code"、"statement coverage reached"）即取自该注册表的Name字段，与 README 文案逐字对应。

一个值得注意的边界：本次快照中，stripedhyena-nous-7b被列在 "category unknown" 桶下。源码中Category()在评测任务数为 0 时会直接返回 unknown（category.go#L80-L82）；而从下面的原始 CSV 可见该模型实际完成了 4 项任务并有得分，因此该 “unknown” 的具体归因需以当时完整评测日志为准（未随仓库保留），这也是“结果只反映快照”这一告诫的一个具体体现。

3. 原始逐项得分（evaluation.csv）

evaluation.csv 共 4 行数据，对应该模型在 4 个“语言 × 仓库”组合上的表现（任务均为write-tests）：

各列含义（结合主 README 的 Tasks 一节与 CSV 表头）：

• coverage：达成的语句覆盖点数。write-tests 任务要求“测试必须编译且达到 100% 覆盖”，每覆盖一个覆盖对象计 1 点，是分值权重最高的维度；
• files-executed：成功执行（编译并通过）的测试文件数；
• generate-tests-for-file-character-count：要求模型为其生成测试的源文件总字符数，可视为该任务“体量”的度量——plain仓库是约 1.5K~3K 字符的单文件最小仓库，light仓库则是约 9 万~10 万字符的多文件仓库；
• processing-time / response-character-count：处理耗时与响应长度（从数值量级看，golang/light 的 449905 若按毫秒计约 7.5 分钟，响应约 10.5 万字符）；
• no-error / no-excess / with-code：三个响应质量维度的得分——请求未出错、响应未超出“只给测试代码”的约束、响应中确实包含源码。

score 的构成可以逐行验证：每一行的score恰好等于coverage + files-executed + no-error + no-excess + with-code五项之和，例如：

• golang/light：710 + 22 + 115 + 75 + 113 =1035
• java/plain：0 + 1 + 5 + 3 + 5 =14

这说明score不是独立指标，而是各维度按文件/点数加权累加后的总分。主 README 的 Reward Points 一节定义了这些维度的语义：response-no-error、response-with-code、no-excess属于“响应质量”维度，compiled（体现为 files-executed）与statement-coverage-reached属于“代码质量”维度，其中覆盖率与通过的测试文件数是拉开模型差距的主要权重项。

4. 汇总维度与得分结构分析

三个汇总 CSV 是对逐项数据沿不同轴的求和，可互相印证：

校验关系：Go 两行相加（1035+24=1059、710+10=720）即 golang 汇总；Java 两行相加（5096+14=5110、4750+0=4750）即 java 汇总；两者相加即 models 汇总（1059+5110=6169）。这份数据内部是自洽的。

从结构上可以读出几个特征：

1. Java 明显强于 Go。总分 6169 中 Java 贡献 5110（约 83%），主要来自 java/light：52 个文件成功执行、覆盖 4750 个点；而 golang/light 仅执行 22 个文件、覆盖 710 点。该模型在 v0.5.0 快照中的测试生成能力显著偏向 Java。
2. plain（最小仓库）任务表现极弱。golang/plain 仅得 24 分（coverage 10），java/plain 仅 14 分（coverage 0）。这与主 README 的观点一致——“给一个几乎空的函数写测试并非平凡任务”，它要求模型掌握语言与测试框架的约定（如 Go 的testing包、Java 的 JUnit 5），该 7B 通用模型在这两个最小案例上几乎未能达到覆盖目标。
3. 响应质量维度存在明显短板。no-error 维度拿到 240 分（四个任务请求均未出错），而 no-excess 仅 148 分——即相当多响应附带了超出“只输出测试代码”要求的多余内容。这会影响自动化流水线中“响应即测试文件”的落盘方式，也是分类体系把 “no excess response” 单独列为最高一档的原因。
4. 覆盖集中度。models 汇总的 5470 个覆盖点中，4750 来自 java/light 一个仓库，说明得分高度集中于单一大型任务。

5. 如何在仓库内复现与验证

本报告属于“查看型”档案，复现评测只需按 qwencoder-eval/instruct/eval-dev-quality/README.md 安装基准工具并指定同一模型即可（评测在隔离环境中进行，工具默认不沙箱化执行模型生成代码，建议使用--runtime docker）：

git clone 本仓库后进入 eval-dev-quality 目录 go install -v github.com/symflower/eval-dev-quality/cmd/eval-dev-quality export PROVIDER_TOKEN=openrouter:${your-key} # 只评测 stripedhyena-nous-7b eval-dev-quality evaluate --model=openrouter/togethercomputer/stripedhyena-nous-7b

运行后产物与本档案同构：终端输出逐请求/逐命令的详细日志，结果写入evaluation.csv，并生成带分类图的REPORT.md。若要复现本快照的完整结果，还需与 v0.5.0 版本一致的测试数据——本报告中涉及的golang/plain、golang/light、java/plain、java/light四个仓库对应仓库内的testdata/golang/plain、testdata/golang/light、testdata/java/plain、testdata/java/light目录，write-tests 任务的提示词形如：“给定文件 X 与包 Y，请提供测试文件；测试须达到 100% 覆盖并编译通过；响应必须只包含测试代码”。测试数据的增删与扩展方式（repository.json任务过滤、新语言/新任务接入）同样在该 README 的 “How to extend the benchmark?” 一节有说明。

若想核对本报告涉及的源码实现，建议按以下顺序阅读：

• 分类判定：evaluate/metrics/category.go、evaluate/metrics/assessment.go；
• write-tests 任务实现：evaluate/task/task-write-test.go、evaluate/task/repository.go；
• 报告与 CSV 生成：evaluate/report/markdown.go、evaluate/report/csv.go。

6. 小结

这份报告是 DevQualityEval v0.5.0 对openrouter/togethercomputer/stripedhyena-nous-7b的一次快照：模型在 Go/Java 的 4 个测试生成任务上合计 6169 分，其中 Java 大仓库任务（5096 分、52 个文件执行、4750 个覆盖点）是绝对主力，而最小仓库任务（24 分 / 14 分）与“无多余响应”维度（148/240）暴露了短板；最终该模型在本次快照中被归入 “category unknown”。由于 LLM 输出非确定性，任何单点分数都应结合跨模型汇总表（v0.5.0 根目录的models-summed.csv等）与多次运行来解读；本档案的价值正在于它以 CSV 形式保留了每个维度可加、可校验的原始得分，使读者可以像本文第 3、4 节那样独立复核其构成。

【免费下载链接】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