本文是《超越Benchmark》系列下篇。上篇介绍了 benchmark 的局限、专家在环的交互式评估方法，以及公平、专家、标准三大支柱——详见 超越Benchmark：面向中国场景的Coding 专家交互式评估（上）。本篇从质检体系讲起，展示真实评测的多维画像，并说明 Expert Evals as a Service 的服务形态。

四、质检：让专家判断的结果更可信

前面几章我们反复说，专家的主观判断可以做到可信。靠什么？靠一套贯穿数据全生命周期的质检。它有两个不寻常之处：第一，它不是等专家全部做完再来一次终检，而是每完成一步就校验一步；第二，它由一套工具托底，让"苛刻"得以规模化，而不是靠堆人。

4.1 不是终检，而是每一步提交即校验

一条数据，从出题到打分要经过许多步骤。我们不让专家一口气全做完、再统一挑错，而是每完成一步就提交一步，由模型与脚本立即对这一阶段的产物做校验——不通过就当场打回，专家自行返修后重新提交，通过了才能进入下一步。

这样做的价值在于：问题在它产生的那一步就被拦下，不会顺流而下污染后续工作；返修的成本最小；专家也能拿到即时反馈。本质上，这是一条"数据生产的 CI 流水线" —— 把质量内建进生产过程，而不是事后补救。

4.2 一条数据要穿过的关卡

人：专家资质。 源头先卡人。不同 Level 的专家有不同的命题配额；同时校验专家资质与题目领域是否匹配——不让一个后端专家去出前端可访问性的题。并且经验告诉我们，专家质量是动态的，专家可能随着项目的进行会出现"江郎才尽"的情况，所以我们同时会关注专家近期表现，只有持续表现优异的专家才可以继续参与项目。让对的人做对的题，是质量的第一道保险，也呼应了第三章讲的专家分布。

题：领域、难度与仓库。 先看这道题是否符合本期评测的领域、难度与技术栈配比；再结合 repo 对 query 做难度定级，并对 repo 做深度校验——技术栈是否达标、项目复杂度是否够、能不能正常构建与运行。还有两类"防注水"校验：query 与题库的语义相似检测（防止重复出题）和模板化检测（防止换汤不换药）。最后是一道承接第三章公平性的关——环境泄漏扫描：repo 里绝不能残留答案、修复 commit 或参考实现。

标准：rubric。 这一关查的是"评判的标尺本身合不合格"：七个维度是否都被覆盖、判零依赖是否合法（无环、方向正确）、权重分配是否合理、每条子任务是否可溯源且可客观判定（不能是"质量不错"这类模糊措辞）。其中最要紧的一条，我们单独拎出来查——核心约束是否被拆成了硬性的子任务：query 里那条最要紧的约束，比如限流题的"绝不能误伤正常用户"，必须在 rubric 里有一个对应、可验证的子任务接住它。接不住，这道题就等于没考到点子上。

过程：轨迹。 评测跑完，校验它的轨迹：轮次数是否匹配题目难度、评测的目标模型与配置是否用对、专家的引导是否合理。这里有一条是整套方法的命门——专家纠偏绝不能越界泄题。我们的差异化正是交互式纠偏，可一旦纠偏变成把答案直接喂给模型，测的就成了专家而非模型。所以质检会专门盯：提示是否按分档给出、是否如实留痕、有没有把解法直接塞过去。

结果：打分。 最后校验分数本身：打分有没有逻辑冲突（典型的，比如子任务大量低分、维度分却给得很高，或者 rationale 已指出严重问题、分却虚高）；每一处扣分能否溯源到轨迹里的具体证据；以及 rationale 是否含足够细节、能指导后续的模型优化方向——评分不只是判一个高下，更要产出可用于改进的信号。

图6　单条评估数据全生命周期展示流程

图7　某次评估项目各质检环节通过率

4.3 用工具把苛刻撑成规模

苛刻的质检若全靠人力，必然又慢又贵、跑不起规模。支撑上面这整条流水线的，是一套工具。

逐步校验的脚本与模型，是 4.1 那条"提交即校验"流水线的执行者：语义相似、模板化、环境泄漏、打分逻辑冲突这些检查，都由它们在每一步自动完成。

Rubrics 合成工具。 写出一份结构规范、维度齐全的 rubric，是一项和工程能力不同的专门技能。我们不要求一位资深工程师同时还是 rubric 专家——他只需提供自己最擅长的那部分：这道题该拆成哪些子任务、每个子任务的关键校验点是什么；由合成工具把它扩写成符合 schema、维度齐全、依赖与权重完备的完整 rubric。判断来自专家，结构由工具保证。这既降低了专家的门槛，也让每一份产出天然满足 rubric 校验那一关。

评估专用 Docker。 我们给专家一个标准化的评估环境，里面预置了待评测的 Coding Agent 与对应模型配置、git，以及两套自动化脚本：一套是项目初始化脚本，自动移除 git remote 等信息，落地一个干净、无泄漏的起点，在这里被机械地强制执行，而不完全依赖人的执行；另一套是结果上传脚本，自动收集 git diff、agent 的完整 trace 以及完成后的代码包并统一上传。这一个 Docker 同时解决了三件事：公平（每个模型面对同一个干净起点）、可复现（环境标准化、随时回到初态）、以及轨迹可校验（trace、diff、代码被自动而完整地采集，轨迹质检才有可靠的对象）。它还顺手消除了"目标模型用错配置"这类人为错误。

这些工具——逐步质检的脚本、rubric 合成、评估 Docker——本质都是平台能力的沉淀：把苛刻的质检沉淀成可复用的底座，我们才能把这套标准做厚，还跑得起规模。

小结

一条数据，从出题到打分，每一步提交即被校验，再由一套工具把这份苛刻撑成可规模化的产线。这条可审计、可复现的生产线，就是我们敢谈"专家判断可信"的底气。

五、评测结果：一张多维画像

Results: A Multi-Dimensional Profile

前面讲的是怎么评、凭什么可信。这一章用一期真实评测的数据，看我们评出来的结果长什么样。和公开榜单只给一个总分不同，我们交付的是一块多维画像——它不仅回答"谁更强"，更回答"强在哪、弱在哪、差距在哪个维度上拉开"。本期共评测 126 道真实题目、四个主流 coding 模型，下文模型一律匿名为 A / B / C / D。

图8　本期评测项目关键指标概览

5.1 本期评测构成

题目来自专家的真实工程场景，覆盖从"从零生成"到"理解、重构、修 Bug"的完整开发活动，而非单点玩具题。

图9　本期评测的任务类型与业务领域分布（真实数据，n=126）

两个细节能说明题目的工程真实度：

一是九成题目涉及多文件改动（模块内多文件 51、跨模块 43、跨系统 20，单文件仅 12），近一半需要跨模块甚至跨系统协同；

二是任务类型分布均衡，0-1 生成、Feature 迭代、Bug 修复三类合计占七成，覆盖了真实研发里最高频的活动。

5.2 多维能力画像

我们对每个模型，在七个固定维度上给出画像。下图是四个模型的真实七维画像。

图10　四个模型的七维能力画像（真实均分，1–5 分）

画像把"综合更强"拆成了"强在哪一维"。综合来看排序为 A > B > C > D，但更有价值的是结构差异：所有模型的最强项都集中在"架构边界"（边界感，4.05–4.33，几乎不出格、不做高危操作），而差距最大的维度是"用户体验"——从 A 的 3.88 一路掉到 D 的 3.13，分差达 0.75，是七个维度里区分度最高的。换句话说，模型们在"守规矩"上已经趋同，真正拉开差距的是"好不好用"和"想得清不清楚"。

5.3 谁在哪一维更强

把七个维度的均分铺成一张热力图，强弱一眼可辨。

图11　分维度均分热力图（真实数据，颜色越深分越高）

热力图比总分更有诊断价值：模型 A 在每个维度上都领先，且在指令遵从（4.10）与任务规划（4.03）上优势最明显；模型 D 的短板高度集中——用户体验只有 3.13、语义理解 3.47，这意味着它"能做出来，但不好用、也容易想偏"。这种"同样的综合分、完全不同的强弱结构"，正是单一榜单分数会抹平、而多维画像能保留的信息。

5.4 两两对战：胜率与画像互相印证

除了打分，我们还让模型在同一道题上两两对战，由专家判定谁更好（GSB，即 Good / Same / Bad）。下图以模型 B 为基准，给出它和另外三个模型的真实对战胜率。

图12　GSB 战胜率：以模型 B 为基准（真实 GSB 结果，每组 126 场）

对战结论与多维画像互相印证：模型 B 不敌综合更强的 A（48% : 52%），却明显胜过 C（62%）和 D（68%）。两套互相独立的评测方式——逐维打分与整体对战——给出了一致的排序，这种交叉一致本身就是评测可信度的一个旁证。

5.5 一张对照：人评测到了什么

回到最根本的问题：这套评估，比公开 benchmark 多测到了什么？

本期数据给出了一个有力的注脚：四个模型在"架构边界"上的分差只有 0.28，却在"用户体验"上拉开了 0.75 的差距。一个只看综合分或通过率的榜单，会把这种结构性差异完全抹平；而正是这种"强在哪、弱在哪"的诊断力，构成了专家交互式评估最不可替代的价值。

六、价值与展望

What This Enables

把以上拼起来，这套评估为模型团队带来的，不止是一张更细的成绩单。

6.1 一个本土的、判断层的能力信号

对模型 lab 来说，自动化评测和可验证 RL 环境已经把"能不能跑通"测得很好。我们补上的是它们够不到的那一层：本土场景（中文语境、国产技术栈、合规约束）、判断层质量（资深工程师会不会合这版产出）、以及可引导性（被纠偏后能不能改对）。这三类信号，恰恰是模型走向真实生产协作时最该被衡量、也最难被自动化的。

这一层信号的价值，业界已有先例：2026 年，微软发布 MAI-Thinking-1 时，专门委托第三方评估机构进行了专家盲测偏好评估，并将"评审者更偏好该模型"的结论写进了发布公告与技术报告（参见 Surge AI 的案例）——当 benchmark 分数趋同，来自人类专家的判断，正在成为模型对外证明能力的公信力来源。而在中国场景下，这样的信号还需要多一层：懂本土工程的专家。这正是我们要补上的位置。

6.2 评测资产可复用：出题与评测解耦

一道题通过整条质检流水线、连同它的 rubric 与 Docker 环境一起入库后，就成了一个固化的、可复现的评测资产。这意味着出题与评测可以解耦：同一道题，能在模型迭代出新版本后被反复施测——把新模型放进同一个环境、用同一套 rubric 跑一遍，得到的差异就干净地归因于模型本身，而不掺入"这次的题更难或更简单"的噪声。

这带来两层价值。其一是纵向可比：跨版本的进步可以被干净地度量，这是题目频繁更换的公开 benchmark 难以提供的。其二是成本摊薄：出一道好题、配一套好 rubric、清一个干净环境是最贵的投入，正因为它可复用、可反复施测，这笔投入才从一次性成本变成了持续产生价值的资产。

当然，可复用有两个前提要守住：施测过的题要严格保密、不进入任何训练流程，否则会被污染；题目的难度也会随模型进步而漂移，题库需要持续的难度再校准与新陈代谢。

6.3 评测即训练信号

更进一步，结构化的专家 rubric 不只是"考卷"，也可以是"教材"。带权重、带依赖、带 Critical Negatives 的评分，本身就是一种高质量、可转化为训练或奖励信号的监督——它和可验证的 RL 数据互补：后者擅长"能自动判定对错"的部分，前者覆盖"只有资深工程师才判得了"的主观质量与协作层。这条路，让一套评估服务既能度量能力，也能反哺能力。

我们提供的，是一套标准化的 Coding 专家评估服务（Expert Evals as a Service）——把资深工程师的判断，做成可交付、可复现、可规模化的产品，而不是一次性的评估项目。

6.4 服务形态：标准配置 + 可选套件

前面五章讲的是这套评估"怎么做、凭什么可信"。这一章回答一个更实际的问题：你能从我们这里买到什么。

我们把它设计成一套像选配一辆车的服务：有一套开箱即用的标准配置，覆盖一次严肃评测所需的全部环节；在此之上，再提供若干可选套件，让你按自己的模型、场景与目标按需加装。标准配置保证"拿到的就是一份专业、可复现的评测"，可选套件则让这份评测精确贴合你的需求——而这一切，都跑在同一套已经沉淀好的平台能力上，所以既标准、又能定制。

图13　评估服务标准配置与可选套件

标准配置：一次严肃评测的全部必需件

以下能力，是每一个评测项目默认就包含的——它们正是前五章详细论证过的那套方法，作为标准交付物打包在一起

换句话说，标准配置本身就是一份完整、可直接采购的产品——你不需要从零定义评估方法，拿到的就是一套经过验证、可复现的评测体系。

可选套件：按需加装

在标准配置之上，下面这些套件可以按你的目标自由组合——无论你是想聚焦某个技术领域、引入行业专属标准，还是把评测数据进一步用于训练：

为什么我们能做到"既标准又可定制"

标准与定制看似矛盾，能同时做到，靠的是前几章反复提到的一件事——这一切都跑在同一套沉淀好的平台能力上。逐步质检的脚本、rubric 合成工具、评估专用 Docker，都是可复用的底座：正因为底座是标准的，标准配置才能稳定、可规模化地交付；也正因为底座是模块化的，可选套件才能像积木一样按需拼装，而不必每次从零搭建。对别人是"每个项目都重做一遍"的成本，对我们是平台能力的复用——这既是我们敢承诺标准化的底气，也是我们能灵活定制的前提。

结语：把专家判断，做成一项服务

Closing — Expert Evals as a Service

回到最初的那个问题：在真实的中国工程现场、在一位资深工程师的协作与引导下，一个模型的工程能力到底如何？这不是一道更难的题能回答的——它需要把懂中国工程的资深专家重新放回评测的回路：让他们出题、观察、纠偏、判断，再用结构化的标准、苛刻的质检与可复现的资产，把这份判断变成可信、可比、可审计的信号。这，就是我们所说的"超越 Benchmark"。

而我们真正想交到你手里的，不只是一套方法，更是一项产品：一套标准化、可定制的 Coding 专家评估服务——Expert Evals as a Service。标准配置让你开箱即得一份专业、可复现的评测；可选套件让这份评测精确贴合你的模型、场景与目标。它既经得起研究层面的推敲，也经得起规模化交付的考验。

如果你正在训练或迭代一个 coding 模型，并且想知道它在真实的中国工程场景下、面对一位资深工程师时究竟表现如何——欢迎与千识研究院聊聊。我们已经把"资深专家的判断"，做成了一件可以交付的事。