如何把用户反馈变成可验证的改进
用户反馈像一筐刚摘的豆子：有的脆，有的带泥，有的只是“今天不想吃”。它们都值得被听见，但不能直接被当成产品规律或工程结论。把反馈变成改进，需要先保留原始语境，再区分现象、假设和已经验证的原因，否则团队很容易用最响亮的一句话决定最昂贵的一次改动。
收集时记录触发条件
一条反馈至少应带有来源、时间、任务类型、用户预期和可选的上下文标识。来源可以是客服转述、访谈、埋点摘要或主动提交，不同来源的偏差不同，不能混成一个分数。涉及内容和隐私时只保存解决问题所需信息，并给出删除和访问规则。对“答案不对”这类描述，应补问是资料缺失、引用错误、表达难懂，还是操作入口找不到。
归类时先按用户任务和影响范围分组，再记录出现频率和严重程度。频率高不一定优先级高，少量涉及权限、错误操作或误导性建议的反馈可能更需要先处理。不要把用户的措辞直接翻译成技术方案；“搜索不好用”可能来自分段、过滤、排序、界面展示或预期管理，下一步应该是找出可观察的差异。
把猜测写成可被推翻的假设
例如可以提出：特定文档类型的标题未进入检索字段，导致用户找不到答案。这个表述比“换个向量模型就好了”更有用，因为它说明了要检查什么，也允许证据否定它。每个假设写明支持样本、反例、验证方法和可能副作用。对大模型回答，还应区分检索没找到、检索找到了但没被采用、采用后生成表达失真三种情况。
验证优先选影响面小、可回退的方法。可以补充少量代表性查询，检查候选来源和权限过滤；也可以调整展示文案，观察用户是否仍然误解。涉及排序、模型或缓存策略时，要固定语料、版本和评审标准，避免不同时间的数据变化掩盖改动结果。不要只看单一满意度或点击率，它们可能受页面位置、用户群和季节性影响。
把决策过程留给后来的人
每次处理反馈都记录：观察到了什么、做了哪项改变、验证在什么条件下完成、哪些问题仍未解决。这样下次同类反馈出现时，团队不会只能翻聊天记录猜当初为什么这么做。失败尝试也应保留简短说明；知道某个方向在什么前提下无效，往往比一串成功故事更节省时间。
发布后设置复查窗口，重点看新问题是否集中在同一任务、错误类型是否变化、人工介入是否增加。若没有足够证据，不要写成“已经彻底解决”，而是如实说明目前观察到的范围。用户反馈不是给系统盖章，它是帮助我们持续校正假设的输入。把声音变成样本、把样本变成验证，改进才不会只停在热闹的讨论里。
对无法立即验证的反馈，也不必用一句“后续关注”轻轻带过。为它设定再次检查的条件，例如积累到相近场景、补齐关键日志，或等待文档版本稳定；到期后明确关闭、继续观察或进入下一轮实验。这样既不把零散意见遗忘，也不会把未证实的猜测塞进正式结论。
