用户点了差评之后，怎么让这些反馈真正变成产品改进？

收集端的设计

差评时机点上加一层轻量归因选项：「答案不对 / 没理解问题 / 太啰嗦 / 不安全」四选一加可选的一句话补充，参与率比开放问卷高数倍。同时自动快照当时的完整上下文（问题、检索片段、模型版本、配置版本）与差评绑定——没有上下文的差评无法归因，这是最常见的收集设计失误。

自动归因管道

• 技术归因自动化：把差评样本跑一遍诊断管线——检索命中了吗（没命中 → 检索问题）、命中了但答案没用（生成问题）、格式或截断问题（工程问题）、样本本身是超纲问题（范围问题）

• 聚类优先：每周把差评按失败模式聚类，Top 三类的修复价值远超零散个例

• 优先级 = 频次 × 严重度：涉及安全与事实错误的差评无条件最高优先级

改进与验证闭环

每类高频失败模式对应明确的改进出口：检索问题进检索优化 backlog、提示词问题进提示词变更流程、能力缺口进评测集。关键的最后一步是验证——改进上线后，用同类历史差评样本回归验证是否解决，并把「差评率按失败模式的趋势」作为改动的验收指标。闭环的标志是：任何一个差评样本要么在某个改进 backlog 里，要么已被某个改进覆盖验证。