用户与场景分析

研究状态：尚未开展真实用户研究。 本文的用户画像和场景都是待验证的假设，来自对公开评论区的观察和个人经验。文末给出了验证每条假设的方法，访谈提纲与记录模板在用户研究工具包。拿到真实访谈记录后，应当用结论替换这里的假设，并保留被推翻的条目。

目标用户（假设）

角色	典型处境	他们现在怎么处理反馈	最在意什么
小团队产品经理（主要用户）	3–20 人团队，一个人负责一到两条产品线，没有专职用研或数据分析	每周抽时间翻应用商店评论和客服群，手动把重要的抄进表格或工单	别漏掉严重问题；周会上能拿出“这周用户在抱怨什么”的数字
用户运营 / 客服主管	每天直接面对用户留言，需要决定哪些升级给研发	凭经验判断，口头或截图转给产品和研发	升级得准不准、快不快；重复问题能不能合并
独立开发者	一个人做一个应用，没有任何流程	有空才看评论，常常隔几周	花最少的时间知道“最该先修哪个”

非目标用户：有成熟客户之声平台的大公司团队（他们已有专门系统和标注团队）；需要对单条反馈做深度定性分析的用户研究员（他们要读原文，不要摘要）。

周一上午，产品经理把上周导出的 80 条应用商店评论贴进来，想在十分钟内知道：最多的三类问题是什么？有没有必须今天就拉研发处理的？

对应功能：批量分诊页。

客服在群里看到一条抱怨，不确定该不该升级。贴进来看一眼类别和紧急度，把摘要复制成工单标题。

对应功能：单条分析页。

技术负责人想知道这个模型准不准、多快、能不能本地跑，再决定要不要接进自己的工单系统。

对应功能：评测结果页、模型说明卡、命令行与 HTTP 接口。

阶段	用户动作	痛点（假设）	FeedLens 提供的
收集	从应用商店后台、客服系统导出或复制评论	来源分散、格式不一	不解决（v0.1 只接受粘贴文本）
阅读	逐条读	耗时；读到后面注意力下降	先给摘要和类别，原文留作核对
判断	决定哪些重要	标准因人而异；严重问题被淹没	统一的紧急度规范，高紧急度置顶
记录	抄进表格或工单	重复劳动	导出 CSV，摘要可直接作标题
汇报	周会上讲本周问题	没有数字	类别分布统计

编号	假设	如果不成立会怎样	验证方法
H1	小团队没有专门工具，反馈靠人工阅读整理	需求不存在，或已被现有工具满足	访谈 5–8 位目标用户，问“上一次整理反馈是怎么做的”
H2	最大的痛点是“严重问题被淹没”和“没有统计数字”，而不是“读得慢”	应当优先做聚类和趋势，而非单条分类	访谈中请对方回忆最近一次漏掉重要反馈的经历
H3	9 个类别能覆盖大多数消费类应用反馈	类别体系要重做	请用户提供 50 条真实反馈，人工按现有规范标注，统计“其他”和“难以归类”的比例
H4	用户愿意接受约九成准确、需人工复核的结果	需要更高准确率或置信度提示才可用	可用性测试：让用户用批量分诊处理自己的反馈，观察是否逐条核对、是否信任排序
H5	“能本地运行、数据不出本机”对这类用户有吸引力	本地部署不是卖点，应当优先做托管服务	访谈中询问反馈数据的敏感程度和对第三方接口的顾虑
H6	一句话摘要能直接当工单标题	摘要需要更长或保留原话	测试任务：请用户把 10 条摘要改成自己会写的标题，统计修改比例

每条假设在访谈提纲里都有对应的问题编号，见用户研究工具包。

本页由 docs/02-users-and-scenarios.md 生成。