假设反馈箱收到一句“最好加个 AI”。直接把它记成需求，排进开发列表，看起来响应很快。但同一句话可能指向完全不同的问题：用户不会写第一段、不知道下一步做什么，或只是希望少点几次按钮。
GOV.UK 的用户研究规划指南建议把未经证实的假设转成研究问题，选择能回答问题的方法，并优先处理团队能够据此采取行动的问题。这份材料是持续维护的研究指南，不是今天发生的行业新闻。
我会把这条反馈拆成一张决策记录。原话保留“最好加个 AI”；待验证问题写“用户在哪个任务上卡住”；候选解释写“不会开始”“操作重复”“缺少判断依据”；可能行动分别是提供示例、合并步骤、解释规则。AI 是候选实现之一，暂时不必成为问题本身。
接下来优先询问最近一次具体经历：当时要完成什么，停在哪一步，最后用了什么替代办法。这里的目的不是诱导对方证明 AI 有价值，而是找到能区分候选解释的证据。例如用户有现成内容，却反复复制到多个字段，生成文本可能不是最直接的修复。
可以复用的记录字段是：原话、相关任务、最近实例、影响、替代做法、尚未排除的解释、下一步观察、改变哪个产品决定。对于“影响”，先记实际描述，不要把一次访谈包装成全体用户的比例。若要估计问题有多普遍，需要适合的样本和统计口径。
优先级可以先看三个条件：问题是否阻断核心任务；是否有足够明确的近期实例；团队是否能做小规模验证。它们是本篇提出的工作判断，不是经过验证的通用打分模型。涉及少数用户但严重阻断的问题，也不能因为反馈数量少就自动放到最后。
完成研究后的产物不一定是新功能。有时是改一个默认值，有时是补说明，有时才是做 AI 原型。一个好的结束条件是：“我们知道哪种证据会让自己改变方案。”如果无论用户说什么都只会推出预定的 AI 功能，那张反馈表只是为既定计划补材料。
资料：GOV.UK 研究规划指南；首发 2016-03-14，页面标注更新 2026-10-15。查阅日期：2026-11-06（Asia/Shanghai）。
来源：https://www.gov.uk/service-manual/user-research/plan-user-research-for-your-service
