一套标准化、可定制的 Coding 专家评估服务 —— Expert Evals as a Service。

这个领域越来越擅长构造模型能通过的 benchmark，但"通过"不等于"胜任"。我们提出一个更苛刻的问题：一个模型在真实的中国工程场景里、在资深工程师的协作与引导下，能不能交付出一个资深工程师认可的工作？这篇文章介绍我们为回答这个问题而构建的评估方法——它把本土资深专家放回评测的回路，用结构化的七维标准、苛刻的多关质检和可复现的评测资产，把专家的主观判断变成可信、可比、可审计的信号。

图1　评估服务关键指标概览

一、为什么 benchmark 不够

Why Benchmarks Fall Short

公开 benchmark 是过去几年 coding 模型进步的功臣——它把"模型会不会写代码"从一种模糊印象，变成了可量化、可追踪、可复现的进展，没有这套公共标尺，就没有这一代 coding 模型的迭代速度。

但今天，一个奇怪的矛盾摆在面前：很多模型在 benchmark 上几乎没输过，在用户的真实反馈里却几乎没赢过。 榜单分数逼近饱和、你追我赶，可落到真实开发里，工程师的体感并没有跟着一起变好。

为什么榜单上的"强"，没有变成用户手里的"强"？我们认为，根因在于 benchmark 和真实工程之间，有三个根本性的"不同"——题目不同、"赢"的标准不同、工作方式不同。它们共同解释了：为什么榜单能力，没能转化为用户的获得感。

1.1 题目不同：定义清晰 vs 尚待澄清

第一个不同，在题目本身。benchmark 的题，大多是定义清晰、边界明确、自包含的——输入、期望输出、判定标准都替你想好了。而真实工程里的活常常相反：需求是模糊的、需要现场澄清的，答案嵌在一整套特定的工程语境里，得先读懂场景、再决定怎么做。

"水土不服"，就是这种"题目不同"最典型的例证。 主流 benchmark 的任务几乎都取自西方开源工程，国内工程的独特性在其中根本不存在，自然也无从被测量。而这种独特性是技术性的，不是口号：

中文语境下，需求文档、代码注释、commit message 大量是中文，文本处理要面对全角半角混排、GB18030 编码等一系列纯英文项目中从不出现的边界情况；国产技术栈——小程序、快应用、鸿蒙原生、RocketMQ、Dubbo、OceanBase、Seata、火山引擎、飞书开放平台——在国外 benchmark 中几乎是盲区；大量国内大厂的内部框架不在公网上，模型无法靠记忆作答，只能靠真正的工程推理。

图2　国内典型技术栈示意

以微信小程序为例。它的双线程架构、WXML/WXSS，都与标准 Web 貌合神离。一个精通 React、在 benchmark 上拿高分的模型，很容易把 Web 思维直接搬过来——比如长列表滚动时用 setData 全量刷新，"看起来对"，却因每次跨线程通信而卡顿。这份高分，测不出这一层。

所以问题不只是"把题换成中文"，而是：benchmark 在考一类已经定义好的题，真实用户要的却是另一类——嵌在本土工程语境里、还需要现场澄清的任务。 在前者上拿满分，不等于能接住后者。

1.2 "赢"的标准不同：通过判定 vs 真正解决问题

第二个不同，在于什么算"赢"。benchmark 的判定是二元的——测试跑通就算赢。它只回答"对不对"，回答不了"好不好"：只要测试通过，一份结构混乱、埋着隐患、真实场景下并不好用的实现，和一份干净、周全、可维护的实现，在榜单上拿的是同一个满分。

而真实工程里，"赢"从来不是"测试通过"这么低的门槛。能过测试只是及格线；一个资深工程师真正认可的交付，还要在正确性之外看代码质量、边界与异常是否周全、是否安全合规、好不好维护。测试通过是"能用"，资深工程师认可才是"好"——用户的真实体感，恰恰来自"能用"和"好"之间的这段落差。

更麻烦的是，二元判定还可以被刷：模型只要盯着那几个测试用例做文章——过拟合、甚至偷偷改写测试——就能"赢"下这道题，却根本没解决背后的问题。当"赢"被简化成一条测试用例的通过，刷分反而比真正解决问题更划算。

1.3 工作方式不同：一次作答 vs 持续协作与收敛

第三个不同，关乎工程的本质。benchmark 是一次性作答——把题交给模型，它独自冲刺一次，pass@1 就是这一次的静态快照。但真实工程从来不是一次性答题，而是持续的协作与收敛。

一个资深工程师 review 一版实现，指出"这里在并发重试下并不幂等"，好的模型一点就通、改得干净，差的则反复纠偏仍不收敛。这个差异，正是工程能力的核心。但一次性评测测不到它——它回答不了：模型被纠偏之后能不能改对？需要几轮引导才收敛？是真正吸收了反馈，还是只顺着引导、无自主判断地继续滑？这些"可引导性"与"协作收敛"的信号，恰恰是一个模型作为真实开发协作者时最该被衡量的，却在一次冲刺里根本没有容身之处。

而用户的日常，恰恰是"协作"而非"一次冲刺"——他们每天和模型一来一回地把活做成。benchmark 只测了"独自冲刺"的那一下，自然测不出协作里那部分体感的差异。

小结

Benchmark 并非没有价值——它把"模型能不能独自解出一道定义清晰的题"测得相当好。我们要做的不是否定它，而是指出它回答的是另一个问题。

水土不服、可被刷、一次性，这三重局限指向同一个答案：评测的下一站，不是一道更难的题，而是把本土的资深专家重新放回评测的回路里。让懂中国工程的人来出题，在交互中观察、纠偏、判断。这正是我们接下来要介绍的方法。

二、我们的方法：专家在环的交互式评估

Our Method: Expert-in-the-Loop Interactive Evaluation

如果说 benchmark 评的是"一段代码"，那么我们评的是"一次协作"。

一个模型的真实工程价值，往往不在它独自交出的第一版，而在它与一个资深工程师共事时的表现——能不能听懂反馈、改对方向、收敛到一个可交付的结果。所以我们的方法，把一位本土资深专家放进评估的整个回路：由他出题、观察、纠偏，并最终给分。这条流程分为四步。

2.1 专家命题：题目源于真实工程

一道题，由一位本土资深专家构思，并准备好仓库与 query。题目不取自公开来源，而是源于他真实工程经验里的问题，并按公平性规范清理环境——剥离仓库历史、隔离任何参考答案（详见第三章），确保模型无处可"抄"。命题人本身就是这道题的最高标准：他清楚什么是好的解法，也知道资深工程师会在哪里挑剔。

2.2 观察首轮：先不干预

把题目交给模型，专家先不出手，完整记录它独立完成的首轮结果与全过程轨迹。这一轮对应的，正是传统 benchmark 所测的东西——模型独自冲刺一次的能力。它是后续协作的基线，但远不是故事的全部。

2.3 定向纠偏：核心的一步

这是本方法的核心，也是 benchmark 没有的一步。专家像 review 一个 junior 的 PR 那样，给出有针对性的反馈，再观察模型如何回应。

为了让"反馈"本身可比、可审计，我们把提示由轻到重分成几档——只点出问题所在、描述问题的具体表现、给出部分修复方向——每一次干预用了哪一档、在第几轮，都原样记录在案。

我们关心的不只是模型最终改没改对，而是它需要多重的提示、几轮才收敛，是真正吸收了反馈，还是只顺着话头打补丁、在别处又犯下同样的错——这正是定向纠偏能测、而一次性评测测不到的。

2.4 评分：一张多维画像

完成任务、或达到轮次上限后，专家依据 rubric 给出评分。它既包含每道题都打的公用维度——正确性、代码质量、安全、约定遵循，以及这一轮独有的可引导性，也包含针对该题拆出的、带权重与依赖的子任务（详见第三章）。最终产出的不是一个总分，而是一张能看出模型强在哪、弱在哪的多维画像。

为什么是三轮以内

轮次上限是刻意的设计。三轮以内，贴近真实 code review 的往返节奏，把评估成本控制在可规模化的范围内，又足以拉开"一点就通"与"反复纠偏仍不收敛"两类模型的差距。已有研究也发现，单轮表现好的模型，多轮未必更好——而多轮恰恰更接近真实开发（引用自：https://arxiv.org/pdf/2309.10691）。上限可随任务难度调整，但原则不变：既给模型足够的协作机会，也给它暴露能力上限的空间。

下图是一组示意结果：第一梯队模型多在一两轮内收敛，第二梯队模型则更可能反复纠偏甚至不收敛——这一差异，正是一次性评测看不到的。

小结

四步合起来，评估测的就不再是模型独自解出一道题的能力，而是它能不能和一个资深工程师把一件事做成——这正是 benchmark 测不到、而真实工程最看重的能力。

三、三大支柱：公平、专家、标准

Three Pillars: Fairness, Experts, and Rubric

第二章讲的是我们"怎么评"。但一套评估要立得住，还得回答三个更根本的问题：题目公不公平？评判的人够不够格？标准够不够清晰？这正是我们的三大支柱——公平、专家、标准。

3.1 公平性：分数只反映能力，不反映漏题

一个交互式评估，如果题目本身就泄漏了答案，再好的方法也白搭——那时模型不是在解题，而是在"抄"。

模型"抄"的路子有很多：预训练时可能见过这个仓库、翻 git 历史找到修复的 commit、读同级目录里的参考答案、直接读评分用的测试用例，甚至联网搜到原始 issue。

我们用一套纵深防御策略来逐一封死：

1. 题目优先取自非公开来源与模型训练截止后的新问题（不在公开 issue、PR 中）；
2. 交给模型的工作区剥离 git 历史、未来 commit 与分支；
3. 目录里只有待修复的仓库，没有任何参考答案或 gold 解；
4. 评分用的测试不放进模型能看到的环境，只在评分阶段于独立容器注入，且只看最终的结果状态；

每道题都被封装成一个 Docker 环境，任意时刻可以回到完全一致的初始态重新运行。它既保证公平——每个模型面对的是同一个干净起点，也让任何一次评测都可复现、可审计。这一层，我们和 benchmark 一样牢固。

但环境再干净，也挡不住模型"看起来对、其实错"。自动评测的反作弊是固定规则加不断给 verifier 打补丁，永远追在新捷径后面；而一个活的资深专家，能在观察这一轮里实时发现模型钻的空子——它是不是绕过了真正的工作、是不是篡改了测试——并当场扣分。我们的反作弊，靠的不只是规则，更是判断力。

直观地说，一道题交付给模型时，它能看到的源代码，没有 .git/，没有 reference/ 或 answer/，没有评分用的测试。它要么真解，要么解不出，没有第三条路。

3.2 专家分布即护城河

评判的人够不够格——而"够格"从来不是一个人，是一群人。

代码评审的判断高度领域特异：判断一段分布式锁实现是否正确，要的是做过分布式系统的人；判断一个小程序页面的性能，要的是真正写过小程序的人；判断一条数据管道在重试下是否幂等，要的是数据工程师。没有哪一个"全能资深工程师"能在所有领域都给出可信的判断。

所以专家分布本身就是能力。我们的评估质量，取决于能不能为每一类题，都匹配上真正在这个领域里有积累的专家；分布越广、越深，能覆盖、能挑剔出的失败模式就越多。

图4、图5　资深专家按技术领域分布

而本土，是这个分布里别人补不上的一维。懂国产技术栈、懂国内工程规范与合规约束的资深工程师，是国外的评估机构在物理上拿不到的。这既是我们能测出"水土不服"的前提，也是最难被复制的护城河。

3.3 标准：公用维度加题目特异子任务

有了对口的专家，还要把他的判断结构化成可打、可复核的分。我们的 rubric 不是给每道题临时拍几条标准，而是一套"固定维度 + 按题拆解的子任务"的双层体系。

七个固定维度，是我们对"什么叫一次好的工程交付"长期沉淀下来的评审框架，每道题都按这同一套既定标准来打分：

这七个维度让不同的题、不同的模型之间能够横向比较——无论评的是一道小程序性能题还是一道分布式系统题，得到的都是同一套可比的画像。

但只有固定维度还不够。"工程化质量好不好"对每道题的含义是不一样的，笼统地打一个分，既不准确也无法复核。所以我们的做法是反过来的：先从这道题的真实 Query 里，拆分出它特有的、一个资深工程师必然会逐项去验证的子任务，再让每个子任务回去拟合到对应的维度上。 维度提供可比性，子任务提供这道题特有的区分度与诊断力，二者咬合，才得到既能横向比较、又贴合题目的细粒度评分。

举一个直观的例子，下面是评估专家给出的一道题：

给一个线上登录接口加上限流，防止有人用脚本暴力撞密码；
但有一条硬约束——绝不能误伤正常用户，普通人正常登录、偶尔输错一两次密码，都不该被挡在外面

从这道 Query 出发，我们拆出的子任务会分别落到不同维度上：

可以看到，并非每个维度都只对一个子任务——像"工程化质量"和"安全边界"这种内涵更丰富的维度，会挂上多个检查项；而那条"绝不能误伤正常用户"的核心约束，则被单独拆成一个挂在"指令遵从"下的硬子任务。一个把阈值设得过死、导致正常人输错一次就被锁、或者干脆没去验证这条约束的解法，正是在这里被扣住的。这就是子任务的价值：它把题目里最要紧、也最容易被糊弄过去的点，变成了维度之下一个必须被验证的检查项。

子任务之间还带权重与依赖：前置子任务不满足，依赖它的下游自动判零。如果模型连"正常用户不被误伤"这条都没验证，那么它对限流效果的自我声明无论说得多漂亮，相关项都不会得分——避免"功能看着做了、但最要紧的约束根本没守住"刷出虚高分。

最后，每个维度下我们还会埋 Critical Negatives：把"看起来专业、实则致命"的错误编码成扣分项，比如硬编码真实密钥、篡改或删除暴露问题的测试、破坏 API 兼容性、为了让测试通过而过度设计。一个让测试通过、却悄悄删掉关键断言的解法，在这里不会得分，只会扣分。

小结

公平的题、对口的人、清晰的标准——三者缺一不可：题目不公平，测的是漏题而非能力；专家不对口，判断就不可信；标准不清晰，判断就无法复核、无法比较。至于这套判断本身如何被反复校准、保证一致，是下一章质检要回答的问题。

下篇预告： 超越Benchmark：面向中国场景的Coding 专家交互式评估（下） 将继续介绍多关质检、多维评测结果与服务形态。