用户点了踩，Agent 就该学习吗？
一份基金比较报告交到用户手里，用户点了"缺少依据"。系统记下了这个反馈。接下来，它应该做什么？
如果立刻把"回答没有依据"写入长期记忆，甚至据此调整之后的研究或风险策略，问题就来了：用户的一次评价，真的足以证明这些结论吗？
反馈首先是用户的一次评价，是值得调查的线索；它本身还不是对答案质量的最终判决。
一个"踩"可能代表很多事情
同样是"缺少依据"，有人可能觉得文章没有列出来源，有人发现引用的材料不支持结论，也有人只是没找到自己想看的数据。用户指出了体验中的问题，但系统仍需要回到原问题、回答和资料中确认原因。
比如一份基金比较被评价为"错误"，原因可能是日期不对、基金认错、计算有误，也可能是用户对结论有不同看法。要把这次反馈用于改进，先弄清发生了什么，比直接把它变成一个"模型答错"的标签更重要。
先记清楚：谁评价了哪份回答
这听起来很基础，却是一个容易被忽略的产品问题。同一段对话可能有多次研究、多个回答；用户点的是其中一条，不是整个会话的永久评价。
我们在 ETF Agent 中整理反馈能力时，首先关注的是让评价能对应到具体回答、属于正确的用户，并在刷新之后仍能读回。网络请求失败时，还要区分两种情况：确实没有反馈，和反馈暂时无法读取。后者不能悄悄显示成"未评价"。
重试也需要小心：假如第一次已经保存，但成功消息在路上丢了，用户再次提交同一评价，不应该因此多算一次。相反，同一份回答收到相互冲突的评价时，也不应悄悄把原记录覆盖掉。是否支持撤回或修改，应该作为清楚的产品能力另行设计。
从一次差评走向真正的改进
一个有用的处理过程可以很朴素：
- 保存用户对具体回答的评价，让本人之后能查到。
- 在获得相应资料访问授权的前提下，检查原问题、回答和依据。
- 分清是数据、计算、资料引用、表达方式，还是需求理解出了问题。
- 把可以复现的问题整理成样本，再验证修改是否改善了同类情况。
每一步都在回答不同的问题。"用户点了踩"是发生过的动作；"发现计算错误"需要核对；"修改后同类问题减少"还需要进一步验证。把它们写成一条自动发生的学习链，很容易让一个真实信号变成错误的确定结论。
一个尚未走完的实践
我们曾发现：反馈已经保存，控件重新打开时却没有显示"已记录"。这暴露出页面上的临时状态与持久记录不是一回事。后续做了针对读回、切换回答和权限的局部修复与测试，但这些测试并不证明完整的真实用户反馈闭环或模型自动学习已经得到验收。
另外，已检查的界面当时聚焦最近完成的回答；不能据此说用户已经能在历史中任选一条回答评价。这些边界应该和进展一起说清楚。
点赞和点踩很容易做成按钮；让反馈成为可信的改进线索，需要知道评价属于谁、针对哪份回答、是否真的保存，以及后续判断有什么依据。
你觉得 AI 产品收到差评后，最应该先做的是追问原因、重新检查答案，还是让用户直接修改反馈？
本文根据 ETF Agent 技术站原文整理；更多工程实践在 GitHub 文章仓库，欢迎交流和 Star。