回归集怎么长起来
每次修一个 badcase 就往回归集里加一条，合并前全量回放，防止修 A 破 B。用例要带来源（真实工单或评审记录）与修复版本备注，这样能追溯到问题的真实场景，而不是堆积一堆凭空构造的用例。过时用例标注下架原因，而不是静默删除——静默删除会让同类问题重新出现而无人察觉。
基本信息
| 纪律 | 合并前回放全量；出现红项先定位再合并 |
|---|---|
| 来源 | 每条用例可追溯到真实问题 |
| 维护 | 过时用例标注下架原因，而非静默删除 |
| 边界 | 回归通过不代表新场景可用，探索仍靠开发集 |
典型使用场景
- 提示改版：合并前跑全量回归，确认没有旧问题复活
- 模型升级：切模型前先跑回归，比较两版在历史问题上的差异
- 字段口径调整：确认改动没有破坏此前修好的抽取样例
- 线上问题回灌：把用户反馈的失败样本转成用例
- 评审验收：把回归结果附在变更说明里，作为合并依据
回归用例字段示例
回归用例字段示例
id: reg-0127
来源: 线上工单 #4821（2026-10-03）
输入: <对话片段或摘要>
期望: 输出类别 = 退款进度查询
加入版本: v11 修复；防回归项
状态: 活跃（下架需记录原因）
# 用例要带真实来源，避免构造用例堆积后无从判断价值
# 下架要写原因（口径已变更/场景已下线），不静默删除
# 分类统计用例来源：线上问题、评测发现、主动构造用例字段与作用
| 字段 | 内容 | 作用 |
|---|---|---|
| id | 唯一编号 | 引用与统计 |
| 来源 | 工单号或评审记录 | 追溯真实场景，判断优先级 |
| 输入/期望 | 样本与期望输出 | 回放的判据 |
| 加入版本 | 该用例对应的修复版本 | 定位是哪次改动引入的 |
| 状态 | 活跃或已下架（附原因） | 控制回归集规模 |
回归集只加不减会无限膨胀；定期评估每条用例的价值并归档过时项，但要记录下架原因而不是直接删除。
回归通过不代表新场景可用：回归集只覆盖历史问题，探索新场景仍然依赖开发集和线上采样。