<owner>/<name>。
结构
array
必填
每一条是
{"name": string, "weight": number, "description": string}。description 要写成给一位细心读者的指令，而不是一个标签。
「产品相关的每一条陈述都真实且是当前的」告诉裁判该看什么；「准确性」不告诉。number
每个维度的打分区间。
0–5 是常见选择；0–1 会让加权总分读起来就是一个比例。private | public
默认值:"private"
private：主人和管理员可读。public：所有人可读，写仍然只归主人。string
这份 rubric 是干什么的。列表里会显示，值得认真写——
一份名字含糊又没有描述的 rubric，就是半年后被别人复制一份的那一份。
一份 rubric 用在哪
同一份 rubric 服务三个地方，这也正是它是一个对象、而不是复制粘贴进两份配置的提示词的原因：
因为它是同一个对象，模型据以训练的标准和据以打分的标准不会悄悄分家。
版本
每次编辑版本号加一，旧版本的全文会被保留。rubrics 表只存当前版本，每次编辑都覆盖它的 criteria——
那会让「版本化」这个词对版本号成立、对内容不成立。
一次按 v2 打过分的 run，在 rubric 走到 v5 之后就再也说不出 v2 当时到底写了什么。
保留修订全文，是「版本计数器」和「可审计资产」之间的差别。
编辑 rubric 会让裁判对它的分数缓存失效——缓存键带着 owner 和版本。
磨细一个维度不会让旧分数悄悄留在原地。
为什么 rubric 要有主人
全局唯一的名字会把每份 rubric 冻结在第一版
全局唯一的名字会把每份 rubric 冻结在第一版
什么算正确答案，是每个团队的判断，不是平台的判断。如果 rubric 名字是全局的、
写入还需要管理员，那么一个想把某条维度改精确一点的研究员就得走流程——
于是他不会走，rubric 停在第一版。一份停在第一版的 rubric，会被训练和评测双双绕开，各自写一份自己的打分逻辑——
而这恰恰是这个对象存在要防的那种分家。所以所有权沿用数据集那一套：
主人持有写权限，可见性决定还有谁能读。
怎么写出一份管用的 rubric
- 维度少而边界清楚。 三条描述清晰的维度胜过八条互相重叠的。 让裁判分别给「清晰度」和「可读性」打分，你会得到同一个数的两份拷贝。
- 按你真正愿意做的取舍来定权重。 如果一个事实错误但文笔优美的回答一文不值， 事实那一条的权重就要能说明这一点。
- 描述失败，而不只是描述成功。 「不编造不存在的产品功能」比「准确」更容易被稳定地执行。
- 有意识地升版本。 一次只磨一条维度，这样使用记录才能告诉你是哪次改动挪动了分数。