AI 产品的反馈为什么不同
同一个输入可能因为模型、Prompt、检索结果、工具状态和随机性产生不同结果。用户说“回答错了”时，团队不仅要知道用户不满意，还要知道是哪一次执行、哪条路径和哪次版本变更。
与此同时，技术上异常并不一定对用户重要。一个 Trace 可以完全正常，结果却无法完成真实工作；另一个工具重试过一次，却没有影响结果。闭环必须连接系统行为和客户结果。
一个完整闭环的六个层次
捕获在 AI 输出或工作流旁保存原始反馈。
澄清追问目标、预期、频率、替代方案和影响。
连接附上客户、产品和 AI 运行上下文。
判断聚类相似证据，评估范围、风险和置信度。
行动明确负责人、决定、状态和下一步。
学习验证结果、回访用户，并把案例加入 Eval。
没有回到用户和质量系统的“闭环”，只是把反馈向内部传递了一次。
保存能够解释结果的最小上下文
- 稳定用户和账户 ID、套餐、角色与客户价值。
- 页面、功能、App 版本、发布版本和实验。
- 模型、Prompt 版本、推理参数和路由。
- 检索来源、工具调用、错误、延迟和 Trace ID。
- 用户输入、AI 输出和必要的会话上下文。
以标识和受控引用为主，避免不必要地复制敏感内容。上下文应该让调查变快，而不是创建新的数据风险。
从单条报告形成可信信号
按用户问题和工作流聚类，再检查模型、Prompt、版本、账户与时间是否集中。评分时同时考虑独立受影响用户、严重程度、账户价值、增长速度和证据完整度。
信号标题应表达问题和影响，例如“版本 4.2 后，专业版账户的上传文件被忽略”，而不是“RAG 问题”。每个结论都应附带代表性原话和执行引用。
从内部行动走到验证和用户回访
- 为认可信号选择调查、修复、计划、观察或拒绝。
- 把工程所需证据带入现有工作流。
- 在修复后重放代表案例和回归 Eval。
- 观察受影响用户群的行为与重复报告。
- 向原始用户说明改变、限制或替代方案。
“已经上线”不是结果。只有当工作流恢复、证据改善并向用户完成沟通，反馈才真正闭环。
衡量闭环是否持续产生价值
- 从反馈到首个认可信号的时间。
- 具有客户与运行上下文的反馈比例。
- 信号认可率和行动率。
- 从信号到负责人、修复和验证的时间。
- 重复报告率、回访率和修复后恢复。
- 每月完成闭环的高价值信号数。