用户反馈最容易被误读的地方，是把“用户提出的方案”当成了“用户真正的需求”。用户说想要提醒、导出或更复杂的功能，描述的往往只是他对问题的初步解释，而不是问题本身。真实需求应当指向一个具体场景：用户在什么时刻遇到阻碍，当前如何解决，为什么现有方式不够，以及他是否愿意持续投入时间或成本改变现状。

先还原场景，再判断功能

分析反馈时，第一步不是记录功能名，而是追问行为过程。用户说“需要提醒”，可能是在担心中断记录；说“希望导出”，可能是为了与医生、教练或家人沟通；说“界面复杂”，也可能是产品没有帮助他完成最重要的第一步。相同的表述，背后可能对应完全不同的任务。

因此，一条反馈至少要拆成四个信息：触发场景、当前做法、实际阻碍和期望结果。尤其要关注用户已经采取过的替代方案。愿意手工记录、反复询问、借助其他工具，说明问题已经真实存在；只是口头表达不清，并不能证明需求具有优先级。

观察使用行为通常比收集评价更可靠。用户可能称赞某项功能，却从未持续使用；也可能抱怨产品，却反复回来尝试。前者更像礼貌反馈，后者反而暴露了尚未解决的高价值问题。判断需求时，应把“说了什么”与“做了什么”放在一起比较。

用反馈循环筛选真实需求

反馈不应直接变成功能清单，而要经过验证。可以按这样的顺序推进：

1. 找到一小批具有相似场景的用户，观察他们如何完成任务。
2. 将反馈区分为高频问题、关键阻碍和个体偏好。
3. 先用人工服务或简单原型验证结果，不急于自动化。
4. 观察用户是否持续使用，以及问题是否在不同用户身上重复出现。
5. 明确公布做了什么、暂不做什么，以及背后的判断依据。

真正值得产品化的需求，通常同时具备三个特征：场景清晰、问题反复出现、解决后能改变用户行为。相反，只满足单个用户偏好的请求，即使表达得很具体，也未必代表产品方向。

AI可以加快原型和重复开发，却不能替代需求判断。开发者需要把用户语言、使用路径和反复出现的阻碍沉淀为产品决策。识别真实需求的核心，不是收集更多意见，而是理解用户为何采取某种行为，并验证什么结果值得长期解决。