做评测的人，最容易产生一种错觉：我交了一份漂亮的报告，工作就结束了。用户不会看报告，用户只在更新后发现豆包答得不如上次、某个高频场景突然抽风时，用卸载键投票。把评测证据变成「发还是不发」的决策，才是评测真正护住用户价值的地方。这篇讲怎么把证据拧成一道发布闸门。

一、为什么评测人要坐到发布决策桌前

试用员替用户用、替用户说、替用户试，这是评测人的底色。用户关心的事很朴素：这次更新之后，豆包还靠不靠谱，我常用的那个功能是不是还行。至于模型在 MMLU 上涨了零点几分，用户一个字也不会在意。

所以评测人的第一责任不是产出分数，而是把用户那种模糊的体感，翻译成一个明确的动作建议：这个版本可以发、先灰度、还是直接拦下。分数只是中间产物，决策才是交付物。这正好回扣系列一直说的那句话：产品造价值，测试证价值，评测是两者之间的桥。坐到决策桌前，评测才真的把价值证到了位。

传统测试里，测试工程师在发布前交一张 pass/fail 清单，开发看着清单点「可以发」。到了豆包这类非确定性系统，清单变成了分数加分布加趋势，决策依据变了，但「评测要参与发布决策」这件事没变，反而更重了。因为分数看错一点，发出来的就是真会坑用户的版本。

二、一个反例：只交「综合分 4.2」为什么害了产品

先看一个会真实发生的场景。某个版本评完，综合分 4.2，比上版 4.1 还高，团队很高兴，准备全量发。但拆开看，安全维度的对抗样本漏过率从 0.05% 跳到了 0.13%，一个核心办公场景的准确率掉了 5 分被平均分稀释掉了。综合分看着漂亮，用户体感却是：豆包变危险了，而且我天天用的那个功能变差了。

传统测试的 pass/fail 是二值的，过了就是过了，不存在「整体过了但某一块悄悄挂了」。算法评测如果只交一个综合分，就退化成了比传统测试还不如的东西：它用一个平均数，把 P0 场景的退化盖在了底下。01 篇讲能力分治、04 篇讲拆维度看基准分，都是在防这件事。综合分的陷阱在于，它假设所有维度同等重要，而现实中用户只在乎那几个高频场景。

正确的交付物不是「综合分 4.2」，而是一张带维度、带区间、带趋势的表，旁边明确写着：这个版本在哪些维度达到放行条件，哪些维度亮了红灯，建议动作是什么。决策人拿到的应该是一个可判断的结论，不是一个需要他自己再算一遍的平均数。

三、发布决策的三道闸门：总框架

把前面各篇散落的纪律收拢，发布决策可以抽象成三道闸门。一个版本要全量发给用户，必须依次过这三道，任何一道拦住，就不能进下一道。

第一道是准入闸。它回答「这个版本有没有资格进入候选」。判据是硬门槛：基准分是否达到行业基线，以及是否触了产品质量红线。准入闸只有过和不过，没有商量余地，它是否决权不是放行权。

第二道是质量闸。它回答「过了门槛之后，质量稳不稳、有没有退化」。判据是多维加权分数加上 95% 置信区间，以及相对上版的退化信号。质量闸看的是分布和趋势，不是单点。

第三道是业务闸。它回答「技术和质量都过了，用户价值层面能不能发」。判据是核心场景的用户价值影响评估，以及灰度验证中的线上监控表现。业务闸把评测从技术指标拉回用户体感。

这三道闸和 04 篇说的「安全红线、退化评审、线上灰度」三道关是一脉相承的，04 是从基准分视角看下游，本文把它整合升级：把基准分和红线一起明确收进准入闸，把用户价值单列成独立的业务闸，让三道关变成一张能直接用来拍板的决策单。

三道闸的决策流是这样的：版本提交 → 准入闸（不过即拦）→ 质量闸（黄灯人工复核、红灯拦截）→ 业务闸（灰度验证通过才全量）→ 发布。每道闸的输出都是下一道路的输入，任何一道亮红灯，版本就停在那一关，不往前走。

三道闸是有优先级的，不是平等并联。准入闸最硬，它不过，后面两道连跑的资格都没有；质量闸次之，它拦住的是技术稳了但能力退化的版本；业务闸最后，它拦的是技术质量都行但用户体感不行的版本。优先级的意义是让团队一眼看清卡点在哪：拦在准入闸，是硬伤；拦在质量闸，是退化；拦在业务闸，是价值判断分歧。三道闸也和角色对应：准入闸和质量闸的结论由评测人负责跑准，业务闸的判断由产品人负责拍板，这点第八节再展开。

四、闸门一·准入闸：基准分与红线的硬门槛

准入闸是三道闸里最硬的一道，它不跟你谈权重、不跟你谈趋势，只谈两条死线。

第一条死线来自 04 篇的「基准分是准入证不是通行证」。基准分的作用是粗筛：把明显低于行业基线的维度直接卡在门外。比如某个通用能力在公开基准上低于主流水平一个明显档次，这个版本就没有资格进入下一轮评估。注意这是否决权，不是放行权。基准分全部达标甚至领先，也只是拿到了「可以进入下一轮」的资格，不等于能发。04 篇把它放在决策链路最上游做入口筛子，本文把它收进准入闸，位置没变，表述更明确。

第二条死线来自 01 篇的产品质量红线。红线不进综合评分，它们是闸门，触线即否。01 篇列了四条贯穿全系列的硬红线：安全漏过率大于 0.1% 一票否决；Agent 任务破坏性误操作一票否决；生成内容违规或侵权一票否决；后台崩溃或权限越界一票否决。任何一条触线，其他维度再漂亮也不能发，不存在「这块差点但别的好所以能发」。

准入闸的判定要稳，不能让评测噪声误拦团队。01 篇特别点过：安全漏过率那条要在对抗样本集上跑够量，建议至少一万条再下结论，偶尔一条误报不算触线；Agent 破坏性那条要在隔离 sandbox 里验证真实世界状态，不能只看模型说「已删除」。闸门严，但判定要稳，不然团队被误拦搞烦了，反而会绕过闸门。

落地动作很具体。把每个能力的行业基线写成一张准入证清单，每次评测机械逐条核对，过了打勾，没过标红阻断。把 01 篇的红线写成断言函数，评测流水线末尾加一步，失败即阻断发布。这样准入闸就自动化了，不靠人肉盯分数。基线怎么定才不是拍脑袋。公开基准如 SuperCLUE 的榜单分位可以作为行业基线的参考锚（单一来源思路，具体阈值以贵团队业务校准为准，本篇不列硬数字）。自建防污染基准上的表现则是更贴近真实场景的基线。基线要随模型代际更新，不能一年不调。准入闸最容易失效的反例是：团队为了赶进度，把没过基线的维度标称达标混过去，结果下游质量闸也跟着松，最后发出去的版本用户一用就骂。准入闸的硬，硬在没人能绕过它改结论。

准入闸的放行条件只有一句话：全部维度过基线，且零红线触线。

五、闸门二·质量闸：多维加权与趋势判定

准入闸过了，版本进入候选，但能不能发，还要过质量闸。质量闸是三道闸里判法最密的一道，它处理的是「稳不稳、退没退化」这个问题。

先说加权。质量闸不能把各维度算术平均成一个分，那是综合分的老陷阱。正确的做法是按用户价值权重加权：高频核心场景权重大，长尾场景权重小。01 篇的能力分治、04 篇的拆维度，内核都是「不同维度重要性不同」。权重怎么定，参考用户使用频次和客诉分布，不是拍脑袋。加权之后得到一个总分，但这个总分只是入口，真正起作用的是下面两样东西。

第一样是置信区间。每次评测给出每个维度的均值、标准差，以及 95% Bootstrap 置信区间。Bootstrap 由 Efron 于 1979 年提出，用重采样估计区间，不依赖正态假设，适合评测常见的小样本。一个维度「本次 4.2 分，95% CI [4.0, 4.4]」比孤零零一个 4.2 分信息量高出一个量级，因为它告诉你这个数字稳不稳。

第二样是退化信号。本版某维度均值较上版下降，且两个版本的置信区间不重叠，才算一个真实退化信号。05 篇给过具体阈值：维度均值下降达到 0.15 分亮黄灯，达到 0.3 分红灯，前提是 Bootstrap 95% 置信区间不重叠。作为辅助判断，相对下降幅度达到 3% 也值得关注。区间重叠的时候，不管下降多少，都先当作正常波动，不拉告警，这是为了防止把噪声当退化、团队被狼来了搞疲。

对于通过率型的指标，比如某类任务的成功率，退化判法换成样本级：本版失败样本数较上版新增达到 2 个亮黄灯，达到 5 个亮红灯。这个双阈值是本篇给出的经验判法，不同团队可按自己的样本量校准，关键是 Threshold 要和区间判法配套用，单看通过率高低一样会误判。

权重怎么定才不拍脑袋。一个可落地的办法是拿用户使用频次和客诉分布反推：每天被调用上万次的核心场景权重设高，偶发长尾场景权重设低，权重表随业务更新，不写死。权重的意义是让质量闸聚焦用户真正在乎的地方，而不是被长尾 case 稀释。

质量闸还依赖评分稳不稳。05 篇提过 Kappa 一致性，评分 Agent 之间一致性一般要达到 0.6 以上才算可接受。如果这一版评分 Kappa 掉到 0.6 以下，先修评分器再谈退化，否则区间本身不可信，闸门等于没闸。

黄灯出现时的人工复核动作要写清楚：拉出本版掉分维度的具体 case，看是某类输入系统性变差还是零星异常；对照上版同批 case 比差异；能定位到一类就归并成根因线索交算法侧。黄灯不是放过，是要求人在 loop 里确认一次。

豆包版本迭代很密（据火山引擎开发者社区豆包版本动态，截至 2026 年 7 月仍保持高频更新节奏），退化信号隔版就可能冒头，质量闸必须每版都跑，不能只在发版前跑一次。

质量闸的三档结论用一张表收清：

档位	触发条件	动作
绿灯	权重内达标，无退化信号	进入业务闸
黄灯	下降未达红灯，或区间边缘重叠	人工复核定位根因
红灯	区间不重叠且下降达 0.3 分，或危险退化	拦截退回算法侧

质量闸的核心纪律就一句：只看分布和区间，不对单点下定论。

六、闸门三·业务闸：用户价值与灰度验证

技术和质量两道闸都过了，版本拿到了全量发布的候选资格，但还差最后一道业务闸。业务闸不重复查技术指标，它查的是用户价值层面：这个版本发出去，用户高频场景的体感会不会变差，有没有意料之外的负面体验。

业务闸的第一关是核心场景用户价值评估。评测分过了，不代表用户感知到的价值就过了。05 篇讲的无声退化，说的就是版本更新后某些维度悄悄掉一点，单次发布评测未必抓得住，等用户投诉上来才发现。所以业务闸要求评测人站在用户角度再过一遍：那几个每天被用几十次的功能，这次更新后是不是还顺手，有没有引入新的别扭。

业务闸的第二关是灰度验证。即便前面都过，也不能直接全量，要走灰度。行业通行的金丝雀发布节奏是先放 5%，观察稳定再放 20%、50%，最后 100% 全量。这个节奏是渐进式发布（progressive delivery）的通用工程实践，不是豆包的硬性标准，不同业务可按风险调整比例，但「先小流量验证再放大」的原则是稳的。

灰度期间要开着线上监控。05 篇讲的 golden set 持续跑、影子评测、CI 告警，在灰度阶段继续生效：小流量先把无声退化暴露出来，指标异常就回滚，影响面被控制在 5% 用户以内。业务闸的放行条件：核心场景用户价值评估无负面结论，且灰度各阶段线上监控平稳。任一阶段监控报警，停在当前比例或回滚，不继续放大。

七、决策会怎么开：一份评测驱动的交付决策单

三道闸分散在各篇，真到决策会上，评测人拿出来的应该是一张单子，而不是三份报告。这张发布决策单，是 06 篇项目验收单的出口升级：验收单回答「这个版本评测过没过」，决策单回答「基于评测，建议发还是拦」。

决策单的字段这样设计。版本号与评测时间，定位到具体快照。三闸结论栏，准入闸、质量闸、业务闸各填过或拦，任一拦就整体拦。区间证据栏，列关键维度的本版均值、上版均值、95% 置信区间、是否告警，让决策人能看到数字而不是只看到结论。建议动作栏，从「全量发」「灰度到 X%」「人工复核」「拦截退回」里选一个。风险备注栏，写清楚拦的理由或灰度的关注点。

下面是一张可抄的模板，占位用「不适用」表示该项本次无需填写：

字段	内容
版本号 / 评测时间	填写具体快照标识与时间
准入闸结论	过 / 拦
准入闸证据	各维度基线达成情况；红线触线情况（无则填不适用）
质量闸结论	过 / 黄灯 / 拦
质量闸证据	关键维度均值、95% CI、相对上版下降幅度与告警档位
业务闸结论	过 / 拦
业务闸证据	核心场景用户价值评估结论；灰度阶段监控情况
建议动作	全量发 / 灰度到 X% / 人工复核 / 拦截退回
风险备注	拦截理由或灰度关注点，无则填不适用

一张填好的决策单大概长这样（示例数据，非真实版本）：版本号 V2.3.1、评测时间 2026-07-15；准入闸过，证据各维度过基线、红线零触线；质量闸黄灯，证据核心办公场景均值 4.1、上版 4.3、95% 置信区间 [4.0, 4.2] 与上版 [4.2, 4.4] 不重叠、下降 0.2 亮黄灯；业务闸过；建议动作灰度到 20% 观察核心场景；风险备注黄灯已复核为该类 case 偶发，灰度重点盯办公场景。

决策单的价值在于它把三道闸的结论汇到一个动作上。决策会上，评测人念的不再是「综合分 4.2」，而是「准入过、质量黄灯已复核通过、业务过，建议灰度到 20% 观察核心场景」。产品人和算法人拿同一张单子讨论，谁拍板、基于什么拍板，清清楚楚。单子留档，下次回归有迹可循，这也是 06 篇说的账本变成团队资产的那一步。

八、谁来拍板：评测、产品、算法的角色边界

三道闸搭好了，还要说清一件事：谁来决定发不发。边界模糊，闸门会被绕开或者越界。

评测人的角色是给证据，不是下商业决策。评测人负责把三道闸跑准、把决策单填实，给出建议动作，但不替产品拍板「用户价值上能不能发」。这一点 06 篇讲沟通升级时强调过：评测是提供判断依据的一方，不是拥有最终决定权的一方。越了位，要么决策失真，要么团队关系拧巴。

产品人的角色是对用户价值拍板。准入闸和质量闸的结论是客观的，但业务闸里「用户价值影响能不能接受」常常没有标准答案，这个判断归产品。产品人基于决策单上的证据，结合商业节奏和用户感知，决定全量还是灰度、灰度放到多大。

算法人的角色是对退化根因负责。质量闸亮红灯、业务闸发现无声退化，算法人要去定位是模型变了、检索文档变了还是评测集偏了，给出修复方案。闸门拦住版本，算法人不是被指责的一方，而是被要求拿出根因和修复的一方。

三者的关系用一句话收：评测给证据，产品对用户价值拍板，算法对根因负责。闸门是共同的纪律，不是某一方的武器。

九、灰度与回滚：决策不是终点

业务闸过了、版本进了灰度，决策流程并没有结束，而是进入闭环的最后一段。05 篇说的「发布等于监控开始，不是测试结束」，在灰度阶段体现得最明显。

灰度期间，golden set 持续跑，影子评测并行比对，CI 告警链路开着。无声退化往往就在小流量里先露头：某个维度在 5% 流量上掉了，全量评测时因为样本分散没显出来。监控发现后，触发回滚或停在当前比例，影响面被锁在最小范围。这就是决策闭环：评测证据推动发布闸门，闸门放行后监控继续提供证据，证据反过来修正或回滚决策。

回滚不是失败，是闸门在线上阶段的延伸。团队要习惯把回滚当正常操作，而不是当成事故。灰度监控的数据回流，又成为下个版本评测集的养分，这部分留到 08 篇专门讲。

十、三个典型误用

三道闸讲完，列三个最常踩的误用，都是前面内容的反面。

第一，综合分盖短板就发。质量闸还没过，拿一个平均数说「整体还行」就推全量。正确做法：任何 P0 维度亮红灯，整体再好看也拦，这是 01 篇能力分治的纪律。

第二，区间重叠当退化拦截。看到某维度分数掉了，不管两个版本的置信区间重不重叠，直接判退化拦版本。正确做法：区间重叠先当正常波动，只有区间不重叠且达阈值才算真退化，否则团队被误拦搞疲，闸门就失效了。

第三，分高就放松灰度。准入和质量都漂亮，业务闸直接跳过小流量验证全量发。正确做法：灰度这关不看出身，分再高也要先放 5% 看线上监控，无声退化只在真实流量里现形。

这三个误用，本质都是把某一道闸当摆设。三道闸每道都有它拦得住的东西，缺一道，用户价值就有缝隙。

下篇预告

这篇把评测证据变成了产品真能用的一张发布闸门：准入闸卡硬门槛、质量闸看分布和趋势、业务闸拉回用户价值，三道闸汇成一张决策单，评测给证据、产品拍板、算法查根因，灰度回滚把决策闭成环。但你可能会接着问：灰度和线上监控发现的那些 bad case、那些无声退化的样本，除了触发回滚，能不能反过来让评测集自己长大？下篇讲评测数据飞轮，从线上 bad case 反哺评测集，让每一次发布都让下一次评测更准。

作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。

参考与延伸

• 01 篇（产品质量红线：安全漏过率大于 0.1% 等四条一票否决、能力分治不靠综合分盖短板、红线断言函数挂 CI）｜ 2026-07
• 04 篇（基准分是准入证不是通行证、最上游粗筛、下游安全红线/退化评审/线上灰度三关、准入证清单）｜2026-07
• 05 篇（非确定性统计基础、95% Bootstrap 置信区间、退化告警阈值 mean_drop 大于等于 0.15 黄灯/0.3 红灯且区间不重叠、golden set 与灰度监控、发布等于监控开始）｜2026-07
• 06 篇（能力账本与项目验收单、沟通升级中评测给证据不下商业决策）｜2026-07
• Efron B. Bootstrap Methods, 1979（置信区间重采样估计；经典方法论文，不受保鲜期约束）
• Cohen J. A. Kappa 系数（评分者一致性，一般大于等于 0.6 可接受），1960（经典方法论文，不受保鲜期约束）
• 渐进式发布（progressive delivery / canary release）行业通用工程实践，灰度节奏 5 到 20 到 50 到 100 为常见非硬性标准，建议按业务风险调整（通用工程范式，不受保鲜期约束）
• SuperCLUE 榜单（第三方横评，行业基线参考锚）｜榜单数据截至 2026-07