评测工程线上评测集如何回流

有团队把三个月客诉全导进评测集，整整一万两千条。本以为真实场景全覆盖了，跑起来才发现不对。

八成是登录失效——这问题两个月前就修好了，线上一次都复现不出来。剩下两成里还有大半是"用不了""还是不对"，没人知道当时到底发生了什么。真正的新问题被埋在垃圾里，跑一遍出一堆红，分不清哪个是真退化。

入口决定上限。工单被客服转述过，用户原话丢了；客服对话最真实但太散；应用内反馈虽然短，却能自动带上版本号、设备、当前页面。只给一个空白输入框，收上来的注定是半句话。后来他们让系统自动补上版本号、页面、最近一轮对话、账号租户、发生时间这五个字段，单条处理时间直接从 40 分钟降到 8 分钟。算法没改一行，只是把上下文补齐了。

一万两千条过五道筛，最后只剩约一千五百条，占 13%。去重、过滤已修复、判能不能定对错、分模型还是产品问题、人工补上下文——筛完能进黄金集的，还得同时满足影响面大、稳定复现、答案唯一、长期不变。每条都得写清来源链接、原始反馈、复现条件、期望答案、判定方式，少一个，半年后接手的人根本看不懂这条用例在测什么。

反馈集天生有偏。出大事的人才会投诉，小瑕疵没人愿意花时间说，用得顺的人不说话。所以它只能做缺陷发现，不能用来估发生率——拿它算满意度得出 8%，真实情况可能是九成用户用得好，只是不说话。发生率得靠线上随机抽样，混在一起会得出反向结论。

回流系统还得盯三个指标：回执率长期低于五成，供给就会衰减；时效中位数超过两周，说明筛不过来了；积压量连续三周涨，人力已经不够。最伤的是回流污染——一条标错的样本进了黄金集，之后每次回归都会拦一次正确输出，还会传染一批新用例跟着错。唯一的防线是抽检一成，不合格整批退回重判。

落地第一步很简单：抽五十条最近的客诉，按五道筛手工走一遍，记下每道剩多少。半天就能做完，你会立刻看出哪道筛最堵。