评分细则是怎么写的？机制细节全梳理

同一个回答，两个人打出不同分数，问题多半不在谁不认真，而在细则没写清楚。评分细则是整个 AI 评测里最容易被低估的环节：它平时不显山露水，一出分歧就是全场焦点。

细则是写给谁看的

名义上的读者是评委，实际的读者还有三个：未来的自己——三个月后回看时仍能看懂当时为什么这样定；裁判模型——如果用模型代打分，细则就是它的系统指令；外部读者——公开评测时，细则就是方法可信度的证据。想清楚这四类读者，写法自然不同：给评委的要具体到例子，给裁判模型的要结构化，给外部的要交代动机。一条细则被反复追问「这句什么意思」，就说明它失败了。

一条细则长什么样

合格的单条细则包含四件套：评分维度、分值、等级描述、示例。以「指令遵循」为例：维度是回答是否覆盖了用户要求的全部要点，满分 3 分；3 分对应全部要点无遗漏，2 分对应遗漏一个非核心要点，1 分对应遗漏核心要点；示例给出一个真实回答片段并标注得分理由。文心一言团队公开的评测规范材料里能见到类似的条目结构，海螺AI的标注文档也采用了等级加示例的写法。四件套齐了，评委之间才有对齐的锚点。分值设计也有讲究，维度越重要权重越高，但单项满分不宜过高，避免个别维度吞掉全部区分度。

四件套各管一段，以「指令遵循」这一维拆开看。

边界情况怎么写

细则的功力全在边界上。常见的边界有三类：回答部分正确给多少分、出现事实错误但格式完美怎么扣、用户指令本身自相矛盾时以谁为准。处理原则是「有例可循」：每类边界至少配一个裁决过的真实案例，写明为什么这样判。新边界冒出来时走裁决流程：评委提出，负责人拍板，结论回写进细则并留修订记录。没有这条回路，细则会越用越失效，各种「私下默契」会悄悄取代成文规则。

细则撰写检查单

• 每个维度都有分值与三档以上等级描述
• 每个等级至少配一个真实示例
• 边界情况有裁决案例，能查到处理依据
• 有修订记录，改动可追溯到日期与原因

定稿前的校对动作

细则写完不等于能用，要过两道校验。第一道是试评：拿一批已知水平的回答让两位评委按细则独立打分，一致性不达标就回炉改写，直到分歧收敛；第二道是压力测试：故意塞进刁钻回答，看细则有没有失灵的角落。校对通过才定稿，并锁版本——细则一改，历史分数的口径就变了，这层关系与可复现的要求一脉相承。细则的雏形往往来自开放题参考答案的评分点拆解，两者是同一件事的不同粒度；细则交给机器执行时要先做裁判模型校准，交给真人执行则依赖人工评测流程里的培训与盲评设计；客观题部分则由选择题判分的脚本独立处理，各管一段。

细则还有一个身份常被忽略：它是团队知识沉淀的容器。每一条边界裁决、每一个示例背后，都是踩过的坑和争论过的案例，新人接手评测工作，读透一份成熟细则抵得上几次培训。所以细则要当成活文档来经营：定期回顾、及时修订、版本留痕，改动频繁的章节往往就是评测中最模糊的地带，值得单独加固。判断一个评测团队的专业程度，看它细则的修订记录比看它的宣传材料准得多。

评分细则快问快答三则

• 细则要写多细？：细到两个陌生人按文执行能打出接近的分数即可，再细会变成没法维护的说明书。
• 细则可以中途改吗？：可以，但要留版本记录，新旧版本的成绩分开统计，不能混在一张榜上。
• 主观题细则和客观题答案冲突时听谁的？：按题型各用各的标尺，同一道题不该既走脚本又走细则，入口就要分流。