← 交付方法总览
质量体系可泛化原则
UAT 策略
交付质量
UAT 回答的是一个 Eval 回答不了的问题：业务方认不认。Eval 验证的是我们定义的正确，UAT 验证的是业务定义的可用——两者经常不一致，而以业务口径为准。
什么时候需要它
- 线下指标已经达标，准备让业务方实际使用
- 业务方反馈「不好用」但说不出具体哪里不对
核心内容
它决定什么
公开的是判断与判据。客户口径、私有阈值和内部示例不在其中。
由业务方用真实任务来测
让业务方带着自己的真实工作来用，而不是照着测试脚本点一遍。脚本化的 UAT 只会验证我们已经想到的路径。
反馈要归位
业务方给的是体验描述，要转译成责任层归属和具体用例。直接把「感觉不准」提给开发，等于什么都没提。
覆盖真实工作流而不只是单轮问答
真实使用是连续多轮、带上下文、有中途改主意的。只测单轮问答会漏掉状态管理和上下文相关的失败。
记录不满意但没报错的情况
系统没报错、答案也不算错，但业务方就是不会用它——这类反馈最有价值，也最容易在正式缺陷单里消失。
UAT 结论要能落到判据
UAT 通过与否应当有事先约定的条件，而不是最后开会表决。条件可以包含主观评分，但必须事先写下来。
UAT 发现要回流用例集
业务方发现的失败通常代表了线下用例集的盲区，回流价值高于普通缺陷。
怎么判断它真的到位
- UAT 使用的是业务方自己的真实任务，不是准备好的脚本
- UAT 通过条件在开始前就写下来了
- UAT 发现的失败已经变成线下用例
常见误区
- 把 UAT 做成演示，只走预设路径
- 只收集缺陷单，忽略「不报错但没人用」这类信号
- UAT 结论靠会议表决，每次标准不同
这套方法怎么落到你的项目
这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时，从 AI Agent 生产就绪审查与路线图 入手，或先用 生产上线前深检 定位薄弱环节。