先看这一条合成反馈：“切换分类回来，刚输入的搜索词消失。”
它可以直接拆成一个可检查的任务。先记设备、版本和进入路径，在 A 分类准备一条已保存、标题含“会议”的测试便签：
- 在 A 输入“会议”，记下输入框和结果。
- 不刷新，切到 B，再回 A。
- 检查输入是否还在，结果是否与输入一致。
如果确实要保留搜索上下文，改动后的检查再加三种情况：A 主动清空后切走再回来，词仍为空；B 输入另一个词，不覆盖 A 的词；快速切换时，当前分类、输入与结果一直对应。
另外五条反馈也要保留各自的问题，不能统统压成“优化体验”：
| 原反馈 | 下一步具体查什么 |
|---|---|
| 标题有“会议”，却搜不到 | 原便签是否仍在、搜索范围、保存与同步状态 |
| 收藏后没提示，不知道成没成功 | 首次点击后的等待、完成状态和请求结果 |
| 收藏点两次又取消 | 两次点击间隔；第二次发生在等待中还是完成后 |
| 手机删除和收藏太近，误点 | 实际视口、点击区域、误点录屏、删除后能否恢复 |
| 结果里看不出关键词在哪 | 实际命中的字段和片段是否显示 |
“收藏点两次”还不能直接判成后端故障。它可能就是切换状态，也可能是第一次反馈太迟，要先补操作证据。
如果反馈只剩“后来没找到”，可以借用另一段合成访谈练习里的中性追问：“回想最近一次想找那篇内容的时候，你从哪里开始，接着做了什么？”记不清时，先允许细节留空，再问当时想用内容做什么。
上面用的是六条合成反馈和一段合成访谈；任务步骤已经写出，真实 App 的复现和根因还需要按步骤查。
复用这份示例的完整提示词：
请把六条反馈变成产品团队能讨论的小任务，先保留用户遇到的具体情况，别直接归结为“体验差”。变量示例：【产品】便签App；【反馈】R1搜索会议却找不到昨天标题含会议的便签；R2切分类回来搜索词消失；R3收藏后没提示，不知成功否；R4收藏点两次又取消；R5手机删除与收藏太近误点；R6搜索结果看不出关键词在哪；【缺失信息】无日志、版本、设备与总体用户数据。先逐条抽取症状，再按有证据的关联分组；分组不能丢失R编号，也不要把收藏重复点击直接判为后端故障。每组输出用户情境、原因假设、需要补的证据、一个最小改动候选，以及可以实际操作验证的通过条件。可以暂按误操作后果、任务是否受阻排序，但必须说明排序依据来自这六条样本，不代表真实发生频率；不要编转化率、用户数或提升百分比。最后选出一个可先验证的任务，写出重现步骤与改动后检查步骤。把事实、假设和建议清楚分开，不自动发布工单。
本次输入（确切变量取值；以上要求保持不变）：
合成便签App反馈：R1搜索输入会议却没找到昨天标题含会议的便签；R2切换分类回来刚输入的搜索词消失；R3收藏后没有提示，不知道成功没有；R4收藏按钮点两次又取消了；R5手机上删除与收藏挨得太近误点；R6搜索结果里看不出关键词出现在哪。无日志、设备版本和用户规模数据。