交付靠不靠谱看它的用例

客户问：应用做好了？交付方答：我们测过了，没问题。客户打开页面点了几下，觉得还行，签了字。上线两周之后，回答开始胡说、引用错文档、多轮对话丢上下文、报告卡在加载。客户找回去，得到的回答是「这是模型的问题，我们也没办法」。

整个过程里没有人说谎，但结论是错的——错在「测过了」这个动作本身。三个原因：交付方自己测自己，报告天然倾向通过，这是结构问题不是态度问题；AI 应用是概率系统，同一个问题采样三次，我们实测污染回答出现了两次；最麻烦的是，AI 应用的典型缺陷根本不报错——库里有数据却答「未找到」、多轮丢上下文，流程照常成功、状态照常显示完成，你在界面上永远点不出来。

那看什么？看它的用例。用例是交付方对「这套系统应该怎么验」的完整物化，而高质量的用例是长出来的，不是设计出来的：开工对齐的「什么算成功」是种子，一套设计方法是土壤，真实环境里遇到过什么问题，用例就长出什么。模板抄来的用例只会写「验证基本功能」，从实践里长出来的会写「供应商报价单第七种格式，字段串位」。

这套验收方法有几个关键动作：AI 应用要分成模型层和模型之外两层来看，大多数真实缺陷在第二层且不报错；用节点级中间态取证，不只看最终回答（我们抓到过推送节点显示「已推送给审批人」、工单节点却是「已驳回待复核」）；概率采样，同一问题至少三次；先冻结用例再执行；跑完先归因三分再动手——有一批七十七条基线用例，五十九条通过、十八条失败，归因后只有四条是应用真实缺陷，另外十四条是用例自己设计错了。结论只有三种：通过、有条件通过、不通过，敢写「不通过」的报告才有价值。