pytest 断言管得了代码，管不了「基本可用」：质量人手里的第三张表，为什么决定你在不在决策桌上

评审会开到第三遍，产品经理把同一句话又念了一次：「这个『基本可用』，具体要看到什么才算过了？」桌上六个人——算法、产品、运维、测试都在——没人接话。不是不想答，是这句话在每个人语境里的意思都不一样：算法觉得指标不崩就算过，产品觉得用户别骂就算过，运维觉得别在半夜告警就算过。三套标准单独看都没错，可它们没有一条能被判成真或假。

这种沉默在传统项目里很少出现。「什么算通过」这个问题基本不用问：需求文档里写着字段、范围、异常码，测试把它们翻成用例和断言就行，判据是现成的，测试是判据的执行者与守护者。到了智能体这一层，这条链条断了——断在三个具体的地方。

判据不再从需求文档里来

「能正确回答用户问题」这句话怎么判？它不是不严谨，是不可判定：没有真值、没有边界、没有可观测的失败形式。需求侧写不出对应的判据，这不是某个岗位的失职，是这类系统的固有性质：行为面太宽，语义判断太软，任何一句自然语言的验收标准都会在评审会上被问三遍，然后不了了之。

于是判据的生产位置被顶到了测试这一侧：分场景的判据得由测试补出来——哪类问题必须走知识库、哪类必须转人工、哪类宁可拒答也不能猜，每条给出一句可以判真假的判定式。测试第一次站到了需求的上游。这件事对个人的要求也很具体：写得出判定式的人，得同时懂业务流程、懂模型的不确定性出在哪、懂失败长什么样子——缺一样，写出来的句子都会在第三次追问里露馅。

举个具体的转化。「退款咨询要答得准」这种话落不了地，但把它摊成三档，句子立刻能判：顺利路径——用户问退款几天到账，回答必须给出时效口径，且不得超出政策文档；边界路径——用户问「能不能今天就到」，回答不得承诺具体到账时间，必须给出条件化说法或转人工；失败路径——用户没给订单号时，必须先追问订单号，不得先下结论。三句话都能被判真或假，也都能被写进评估集当断言——这就是判据该有的样子：不描述愿望，只描述可观测的通过形态。

被测对象多了一个：评估自己

第二个变化更隐蔽：除了测产品，你还得测「评估」。样例集的分布是不是偏——是不是全是顺利路径、边界样本都漏在外面；判据有没有判别力——一条永远不会失败的判据，等于没有判据；评分器会不会误判——打分规则本身有没有漏洞，模型会不会顺着它写答案，而不是把事做对。这些量的是「评估本身好不好用」。

质量人第一次有了元评估职责：过去你只对产品负责，现在你还得替评估负责。一份没有被量过的评估集，会以「我们已经全量跑过了」的面目出现在上线评审上，而它证明的可能只是这套判据没有杀伤力。这是新的位置，也是新的风险敞口——你引用的那份报告，本身就是你的被测对象。最起码的两件自查可以做起来：拿一批已知好答案和已知坏答案去过一遍判据，如果两类都被放行，这条判据就该修；再拿边界样本过一遍，看它们落在哪一档，落不进去的，说明分档还缺一档。

三张表，同一个作者

第三个变化是跨职能接口的位移。算法团队需要指标定义——线上到底盯哪几个数、每个数的口径是什么；产品需要放行线——涨到哪、跌到哪算可以上，什么情况下必须拦；运维需要回滚判据——出事之后，凭什么认定这次变更该回滚。这三张表往前追溯，作者都是同一个人，都在回答同一个问题：什么算通过，什么算不通过。

谁写清了判据，谁就在决策桌上——不是因为头衔，而是因为决策需要的那句话只有他写得出。反过来说，缺席这张桌子的人，往往也不是被排除的，是拿不出那句能被判真假的话。

这个位置其实不陌生。当年做接口契约评审，测试就坐在那个位置上：契约从字段格式换成判定条件，位置没变。当年你追问的是「这个字段为空返回什么」，现在追问的是「这个场景下模型答成什么样算过」。手艺是同一门手艺——把模糊的要求拍成可判定的条件，再把它钉进流程里。

判据空着不会报错

判据空着，系统不会报错，也不会有任何告警。它会安静地穿过需求评审、开发、提测，最后在上线之后，变成一场关于「到底算不算问题」的会议。会上大家争的不是技术，是定义；而这场会议本质上就是判据缺失的补交作业，补交的成本比当场写高一档：当场写只需要一句判定式，事后补要搭上复盘、回滚和信任。

还有一种更慢的代价：几个月后有人问「这套东西到底有没有变好」，没人答得上来。没有基线判据，就没有基线数字；没有基线数字，每一次变更都只能靠感觉争论，谁嗓门大听谁的。判据不只是上线时的闸门，它也是日后所有技术讨论的共同语言——先有判据，才有可比的数。

有一点分寸要说清：判据不是越严越好。判定式写得太死，智能体会被逼成一板一眼的规则机，用户体感先掉下去；更务实的做法是按场景分档——官方工程实践谈智能体评估时也是这么做的，把任务成功率按场景分档来看（据 NVIDIA 官方技术博客 2026-05-19）。分档的意思不是放松，而是承认不同场景该有不同门槛，而不是拿一个总数替所有场景背账。

本周就能做的最小动作

不用等治理框架，不用等平台支持。挑一条最含糊的上线条件——大概率就是评审会上被追问三遍的那句「基本可用」——把它拆成三档场景：顺利路径、边界路径、失败路径，每档写一句判定式，句子必须可以被判成真或假。顺利路径的判定式往往一眼能写，难的是边界路径：写不下去的地方，恰好就是模型最可能出错的地方，也是这次动作真正的收获。

写完拿去给算法和产品看一遍，听他们说不同意的地方在哪。他们不同意的每一处，都是你下一版判据要补的口子；而这张桌子第一次承认，你写的那句话是算数的。这三句判定式别留在会议纪要里，让它跟着评估集一起进版本库：场景标签、判定式、通过形态写在一起，下一次改动来了，谁都能看到「这一条是被哪句话守着的」。判据能被 diff，位置才算真的立住了。

判据写得清不清，决定你在项目里是「测完了」的那个人，还是「说清楚什么算测完了」的那个人——前者被验收，后者定义验收。