想研究同类应用的用户评价，容易先看星级，再把几条差评汇总成「竞品的弱点」。但评分高的评论也可能提出功能请求；一句抱怨，也未必是能复现的产品故障。
更实用的输出是一张场景—用户描述—主题—证据—待验证动作清单。本文用 Todoist、TickTick 和 Microsoft To Do 的一批公开评论，演示从小样本到产品问题的整理过程；不是应用推荐，也不是满意度调查。
先固定采样条件，不把上限当数量
本次于 2026-10-04 通过 Apify 的 Google Play 评论工具取得结果。输入为三个应用标识，国家参数 US、语言参数 en、排序 NEWEST，每款设置最多 30 条，未设置日期下限。工具提示当前账户每次最多返回 10 条，最终每款取得 10 条，共 30 条有效文字评论、30 个不同的「应用标识 + 评论 ID」组合。
这是工具在上述条件下返回的小样本。排序参数为最新，不等于已独立验证「截至采集日全球最新的 10 条」；国家、语言字段也只是采样条件，不证明评论者的国籍、居住地或母语。未验证完整覆盖，不能称为美国用户的代表性调查。
| 应用与公开入口 | 有效评论 | 返回的评论日期范围（UTC） | 版本字段非空 |
|---|---|---|---|
| Todoist | 10 | 2026-10-01—2026-10-02 | 9 / 10 |
| TickTick | 10 | 2026-10-01—2026-10-03 | 7 / 10 |
| Microsoft To Do | 10 | 2026-09-29—2026-10-03 | 10 / 10 |
三款返回的日期覆盖不同，因此不比较「这几天谁的问题更多」。这批数据有 4 条版本为空，正文、评分、日期和评论标识均非空；字段非空不代表内容真实、版本已核实或问题已复现。未另行核实每条评论的设备、使用环境与完整展示状态。
最初测试的 App Store 工具只返回了无结果标记，已排除，不据此判断这些应用没有 iOS 评论。也不把两家商店的结果混在一起。采集运行显示成功，只能作为技术状态；验收还要看结果是否真的有正文。更多可取得范围见应用商店数据来源说明。
商店评分、评论星级和文字内容是三回事
商店显示的汇总评分、某一条评论的星级，以及正文表达的问题，不能相互替代。Google 的评分与评论说明指出，展示评分侧重较近期评分，用户也可更新评价。因此，样本星级的简单平均不能当作 Google Play 的商店评分。
App Store 应单独记录。Apple 的说明介绍了按国家或地区的汇总评分，以及新版本可重置汇总评分的机制。两家商店的评分口径不同，不能合成一个「全平台平均分」。
自有应用还可以在有权限的开发者后台分析反馈，但后台能力不等于竞争对手公开页也提供同样字段。本案例只分析工具返回的公开评论，不涉及下载量、收入、留存或后台用户数据。
从正文提取问题：三条真实样本的改写示例
下面是对返回正文的简短改写，不是原文引用，也不是我们验证过的故障结论。每条线索都要接一个验证动作。
| 样本 | 正文表达的线索 | 建议主题 | 下一步核查 |
|---|---|---|---|
| Todoist，3 星，10 月 2 日 | 肯定设计与速度，但反映循环子任务再次出现时顺序可能改变 | 循环任务、顺序保持；混合反馈 | 在相应版本下测试不同完成顺序，并查现行行为 |
| TickTick，3 星，10 月 2 日 | 希望保留七日视图选择，并对日历入口及付费边界有期待 | 视图偏好、付费边界 | 分别核查设置记忆和当前套餐，不将两者统称为故障 |
| Microsoft To Do，5 星，10 月 2 日 | 总体认可应用，同时希望查看全部待办，而非只按当天组织 | 任务视图、功能请求；混合反馈 | 检查现有全部任务入口，区分功能缺失与入口难找 |
第三条特别重要：如果只筛一、二星评论，它会被排除。五颗星不等于没有改进需求。 反过来，只有简短称赞、没有具体场景的评论，可以标为「泛评价／信息不足」，不能为了凑主题而猜测功能。
同一条评论可以有多个标签。本批另一条 Microsoft To Do 评论同时描述备注编辑时键盘遮挡，并提出为任务步骤设置日期的请求；应拆成「交互问题」和「功能请求」，不将一个人说的两件事计为两名用户。
留下证据表，而不是只留情绪结论
原始字段与人工判断分开保存。建议保留 store、app_id、采样国家和语言参数、排序方式、采集时间、review_id、评论时间、星级、正文、可用版本及来源链接；另设场景、主题、反馈性质、信息充分度和待验证事项。字段设计可参考采集字段设计。
去重以「商店 + 应用标识 + 评论 ID」为起点。跨期监测时还要保留快照日期与文本变化：同一评论更新后是变化记录，不一定是新增用户。找不到版本号就留空，不用当前版本补齐；缺少设备信息就不宣称某个机型普遍受影响。
主题口径应能复查。例如，「视图与导航」包括默认视图、入口和筛选；「任务逻辑」包括重复、排序和步骤；「付费与价值」包括订阅形式和付费边界。以上是建议标签，不是本批已经完成的全量分类统计。先标注一小批、核对歧义，再扩大，不让自动分类把推测当事实。
如果统计主题，分母写成「本批有正文且纳入分析的 N 条评论」，同时公布剔除理由。一条可以多标签，主题比例相加可能超过 100%。这种比例只描述采到的评论，不是用户总体投诉率；本案例不发布主题占比、应用排名或问题发生率。
如何把线索变成下一步产品工作
先按可验证程度处理：有明确操作步骤的问题，尝试复现；涉及付费或功能边界的反馈，核查当前说明；只是表达偏好的请求，补用户访谈或可用性测试。评论的次数只能是一个参考，还要看影响程度、场景与自有业务证据。
这 30 条足以演示「星级与正文分开、缺失如实保留、问题接验证动作」，不足以确定开发优先级。若要比较同类产品，应另定统一时间窗与补样规则；不足的应用标注覆盖缺口，不用旧评论凑相同数量后假装可比。
本次在输出映射阶段就未保留评论者姓名、头像和个人主页；文章只展示聚合数量与简短改写，不公开整份评论正文。公开可见不等于适合原样再发布，研究范围应只包含回答产品问题所需的内容。
需要把同类应用反馈整理成可交付的研究表，可以通过产品调研方案提供应用清单、商店、目标市场、语言与要回答的问题。先验证少量样本能否取得、字段是否够用，再确认扩大范围；不以评论采集代替产品实测。