评审会开到第三遍产品经理把同一句话又念了一次「这个『基本可用』具体要看到什么才算过了」桌上六个人——算法、产品、运维、测试都在——没人接话。不是不想答是这句话在每个人语境里的意思都不一样算法觉得指标不崩就算过产品觉得用户别骂就算过运维觉得别在半夜告警就算过。三套标准单独看都没错可它们没有一条能被判成真或假。这种沉默在传统项目里很少出现。「什么算通过」这个问题基本不用问需求文档里写着字段、范围、异常码测试把它们翻成用例和断言就行判据是现成的测试是判据的执行者与守护者。到了智能体这一层这条链条断了——断在三个具体的地方。判据不再从需求文档里来「能正确回答用户问题」这句话怎么判它不是不严谨是不可判定没有真值、没有边界、没有可观测的失败形式。需求侧写不出对应的判据这不是某个岗位的失职是这类系统的固有性质行为面太宽语义判断太软任何一句自然语言的验收标准都会在评审会上被问三遍然后不了了之。于是判据的生产位置被顶到了测试这一侧分场景的判据得由测试补出来——哪类问题必须走知识库、哪类必须转人工、哪类宁可拒答也不能猜每条给出一句可以判真假的判定式。测试第一次站到了需求的上游。这件事对个人的要求也很具体写得出判定式的人得同时懂业务流程、懂模型的不确定性出在哪、懂失败长什么样子——缺一样写出来的句子都会在第三次追问里露馅。举个具体的转化。「退款咨询要答得准」这种话落不了地但把它摊成三档句子立刻能判顺利路径——用户问退款几天到账回答必须给出时效口径且不得超出政策文档边界路径——用户问「能不能今天就到」回答不得承诺具体到账时间必须给出条件化说法或转人工失败路径——用户没给订单号时必须先追问订单号不得先下结论。三句话都能被判真或假也都能被写进评估集当断言——这就是判据该有的样子不描述愿望只描述可观测的通过形态。被测对象多了一个评估自己第二个变化更隐蔽除了测产品你还得测「评估」。样例集的分布是不是偏——是不是全是顺利路径、边界样本都漏在外面判据有没有判别力——一条永远不会失败的判据等于没有判据评分器会不会误判——打分规则本身有没有漏洞模型会不会顺着它写答案而不是把事做对。这些量的是「评估本身好不好用」。质量人第一次有了元评估职责过去你只对产品负责现在你还得替评估负责。一份没有被量过的评估集会以「我们已经全量跑过了」的面目出现在上线评审上而它证明的可能只是这套判据没有杀伤力。这是新的位置也是新的风险敞口——你引用的那份报告本身就是你的被测对象。最起码的两件自查可以做起来拿一批已知好答案和已知坏答案去过一遍判据如果两类都被放行这条判据就该修再拿边界样本过一遍看它们落在哪一档落不进去的说明分档还缺一档。三张表同一个作者第三个变化是跨职能接口的位移。算法团队需要指标定义——线上到底盯哪几个数、每个数的口径是什么产品需要放行线——涨到哪、跌到哪算可以上什么情况下必须拦运维需要回滚判据——出事之后凭什么认定这次变更该回滚。这三张表往前追溯作者都是同一个人都在回答同一个问题什么算通过什么算不通过。谁写清了判据谁就在决策桌上——不是因为头衔而是因为决策需要的那句话只有他写得出。反过来说缺席这张桌子的人往往也不是被排除的是拿不出那句能被判真假的话。三件事过去谁负责现在该谁写产出物长什么样判据来源需求文档写测试翻译成用例测试补出分场景判定式每类场景一句可判真假的验收条件被测对象只测产品产品 评估本身样例分布、判别力、评分器评估集的分布说明与自检结论跨职能接口各职能各看各的数同一个人出三张表指标定义、放行线、回滚判据这个位置其实不陌生。当年做接口契约评审测试就坐在那个位置上契约从字段格式换成判定条件位置没变。当年你追问的是「这个字段为空返回什么」现在追问的是「这个场景下模型答成什么样算过」。手艺是同一门手艺——把模糊的要求拍成可判定的条件再把它钉进流程里。判据空着不会报错判据空着系统不会报错也不会有任何告警。它会安静地穿过需求评审、开发、提测最后在上线之后变成一场关于「到底算不算问题」的会议。会上大家争的不是技术是定义而这场会议本质上就是判据缺失的补交作业补交的成本比当场写高一档当场写只需要一句判定式事后补要搭上复盘、回滚和信任。还有一种更慢的代价几个月后有人问「这套东西到底有没有变好」没人答得上来。没有基线判据就没有基线数字没有基线数字每一次变更都只能靠感觉争论谁嗓门大听谁的。判据不只是上线时的闸门它也是日后所有技术讨论的共同语言——先有判据才有可比的数。有一点分寸要说清判据不是越严越好。判定式写得太死智能体会被逼成一板一眼的规则机用户体感先掉下去更务实的做法是按场景分档——官方工程实践谈智能体评估时也是这么做的把任务成功率按场景分档来看据 NVIDIA 官方技术博客 2026-05-19。分档的意思不是放松而是承认不同场景该有不同门槛而不是拿一个总数替所有场景背账。本周就能做的最小动作不用等治理框架不用等平台支持。挑一条最含糊的上线条件——大概率就是评审会上被追问三遍的那句「基本可用」——把它拆成三档场景顺利路径、边界路径、失败路径每档写一句判定式句子必须可以被判成真或假。顺利路径的判定式往往一眼能写难的是边界路径写不下去的地方恰好就是模型最可能出错的地方也是这次动作真正的收获。写完拿去给算法和产品看一遍听他们说不同意的地方在哪。他们不同意的每一处都是你下一版判据要补的口子而这张桌子第一次承认你写的那句话是算数的。这三句判定式别留在会议纪要里让它跟着评估集一起进版本库场景标签、判定式、通过形态写在一起下一次改动来了谁都能看到「这一条是被哪句话守着的」。判据能被 diff位置才算真的立住了。判据写得清不清决定你在项目里是「测完了」的那个人还是「说清楚什么算测完了」的那个人——前者被验收后者定义验收。