预测模型反馈闭环：别把所有差评都归因于模型
预测结果由谁使用、会触发什么动作，应该在收集反馈前写清。模型分数不能替代业务判断，高风险动作还要保留人工覆盖入口。
反馈要能回到具体任务
收集时保留发生环节、输入类型、期望结果和实际结果，并允许用户说明为什么不满意。不要把所有负面评价归为“模型不准”或“用户不会用”；界面引导、权限、数据延迟和业务规则都可能是原因。
从反馈追到具体环节
一次负面反馈可能来自数据延迟、字段缺失、阈值、界面解释或权限，不宜统一归为“模型不准”。每条反馈至少关联任务版本、输入摘要和实际结果，再决定修数据、规则还是交互。
可以先用下面这份检查单审阅一个最小任务：
- 反馈是否关联任务版本、输入类型、预测结果和后续业务动作；
- 原因分类能否区分数据延迟、字段缺失、阈值、权限和界面解释；
- 高风险动作是否保留人工覆盖，负面反馈不会自动变成训练标签；
- 规则、数据或交互修改后，如何回看同类反馈而不混入其他版本。
如何验证，而不是靠感觉判断
归因后给出处理状态：已修复、需要更多信息、不在当前范围或暂不处理。每类改动回看同类反馈是否减少，避免只回复一次就宣布闭环。
每条反馈只保留归因需要的脱敏输入摘要、实际结果、期望说明和处理状态。汇总时按任务版本与原因类别拆开，不把一次界面误解算作模型误差；改动上线后回看同类记录，并注明仍无法判断的项。
闭环不等于回复一次
反馈关联到具体任务与处理状态，并能回看同类问题是否减少，才算形成闭环。