← 交付方法总览
质量体系可泛化原则
Eval 用例设计
质量
用例集决定了你能看见什么。设计得好，它会在发布前暴露真实失败；设计得差，它只会证明你已经知道的东西。这份文档讲用例从哪来、怎么分层、覆盖什么、以及如何避免用例集自我安慰。
什么时候需要它
- 要从零建立一个 Eval 用例集
- 现有用例几乎全绿，但生产仍在出问题
核心内容
它决定什么
公开的是判断与判据。客户口径、私有阈值和内部示例不在其中。
用例来自真实语料，不是想象
工程师凭想象编的问题，措辞比真实用户规整得多。用例的主体应当来自真实提问、工单、访谈记录，而不是自己写的示范句。
分层组织
冒烟层保证基本可用、核心层覆盖主要业务场景、边界层覆盖歧义与超范围提问、回归层固定住已修复的缺陷。不同层跑的频率和阈值可以不同。
必须包含应当拒答的用例
只测该答的问题，会把系统推向什么都答。超出数据范围、超出权限、信息不足的提问都要有用例，且期望是明确拒答。
一条用例只测一件事
把多个判断塞进一条用例，失败时无法定位。宁可用例数量多一点，也要保证每条失败都能直接指向一个原因。
期望要写成判据而不是标准答案
开放式回答不存在唯一正确字符串。期望应当写成「必须包含哪些要点、不得出现哪些内容、必须引用哪类来源」。
用例集本身会退化
长期不更新的用例集会与真实流量分布脱节。生产上的新失败要定期回流，过时的用例要显式退役而不是留着凑数。
怎么判断它真的到位
- 用例的主体来自真实语料，且能说明采样方式
- 存在拒答类用例，且它们是被判为正确的
- 最近一次生产失败已经变成用例集里的一条
常见误区
- 用例全部由实现者自己编写，措辞与真实用户差距很大
- 把标准答案写死，导致合理的另一种表达被判失败
- 只测该答的问题，模型被训练成永远给答案
这套方法怎么落到你的项目
这是我们交付生产级 AI Agent 的公开、脱敏方法骨架。真正落地时，从 AI Agent 生产就绪审查与路线图 入手，或先用 生产上线前深检 定位薄弱环节。