一句话总结
把 1-2 星评论导成纯文本，粘进一个长上下文模型（Claude Opus 4.7、Gemini 3.1 Pro、GPT-5.5 Thinking 吃下 500 条评论都毫无压力），然后让它按「对平均评分的影响」排序，而不是按抱怨条数。12 条闪退永远排在 25 条「我想要深色模式」前面。你真正要的产出是一份单 sprint 修复清单，外加一栏「坚决不做」——这份分析有一半价值，就是知道该拒绝什么。
任务场景
过去 90 天攒了 60+ 条 1-2 星评论。一条一条读毁士气、也产不出任何可执行的东西。你想让 AI 把它们聚类成主题、按对评分的影响排序、把高峰关联到最近的版本，再交给你这个 sprint 该修什么——外加一份该拒绝的抱怨清单。
哪些情况适合让 AI 来做
- 至少有 30+ 条评论可分析。再少就只是轶事而非模式，聚类会过拟合。
- 你能把评论文本导出来。截图也行但拖慢节奏；纯文本干净得多。
- 你要的是可修的模式，不是一个情绪打分。如果你只想知道「用户气不气：是/否」，那不用 AI。
怎么导出评论
直接从后台粘评论也可以，但一旦超过 40 条左右，批量导出会快很多。坑在于：两家商店都没给你一个干净的「全部评论」一键按钮，而苹果还卡得很死。
| 平台 | 怎么导 | 限制 / 坑（截至 2026 年 6 月） |
|---|---|---|
| App Store | App Store Connect → 评分与评论；或抓公开 RSS feed | 苹果的 RSS feed 每个国家商店最多返回 500 条评论（10 页 × 50），而且只含带文字的评论——纯星级评分不计入。按国家分别导出再合并。 |
| Google Play | Play Console → 下载报告 → 评论（来自 Google Cloud Storage 的月度 CSV） | 评论按月汇总成 CSV 文件；你能拉到自上线以来的所有文字评论，但只有带评论内容的才出现。 |
| 两家通用 | 第三方工具（Appbot、AppFollow、免费 CSV 导出器） | 部分工具能把上限提到约 1 万条/应用，并把两家商店合并成一份 CSV。超过苹果 500 条上限时很有用。 |
导完之后，只保留 1-2 星的行，把除评论文本外的列都删掉，就得到了你的粘贴块。
需要先给 AI 的信息
- 过去 60-90 天所有 1-2 星评论，纯文本，一行一条。
- 一句话 App 上下文，比如「给 ADHD 成年人的一键习惯追踪器」。
- 当前平均评分、评论总数，以及目标（「4.3 → 4.5」）。
- 最近的版本及日期，让模型能关联「这类抱怨是 v1.4.0 之后才出现的」。
500 条纯文本评论大约 3 万到 6 万 token——远在每个当前旗舰模型的应用内上下文窗口之内（Claude Opus 4.7 在网页对话里能装 50 万 token，Gemini 3.1 Pro 和 GPT-5.5 API 达约 100 万）。你撞不到上下文上限；如果 prompt 没强制要求按影响排序，你会撞到的是质量上限。
可直接复制的 Prompt
你帮我分析负面评论，输出一份修复清单。
App：给 ADHD 成年人的一键习惯追踪器。
当前评分：2400 条评论平均 4.3。目标：4.5。
最近版本：
- v1.4.0（3 周前）：上线 streak freeze
- v1.3.5（8 周前）：上线 widget v1
评论（仅负面，过去 90 天），每行一条：
[在这里粘所有评论]
请输出：
1. 聚类。每一类：名字、条数、两条代表性引文。
2. 按「修了能动多少评分」排序（不是按条数：一小簇「闪退」
要打败一大簇「想要更多 widget」）。
3. 前 3 类：本 sprint 要做的那一个 fix；以及那个「简单/装饰性、
不动评分因此不做」的 fix。
4. 把任何类关联到最近版本（「X 类是 v1.4.0 之后开始的」）。
5. 标出结构上不可修复的类（比如我们明确不打算做的功能）。
这些进回复模板，不进 sprint。
6. 给头号类草拟一段公开 App Store 回复（不是邮件）。这一步建议用 Claude Opus 4.7 或 GPT-5.5 的 Thinking 模式——排序这步很吃推理，而更快的「instant」档位不管你怎么交代都倾向于按原始条数排。挑模型可以看我们这篇 Claude vs ChatGPT 处理长文档 对比。
好的输出长什么样
聚类（按对评分的影响排序）：
- Streak freeze 上线后闪退（12 条，均分 1.0）
- “更新后 App 打不开了。”
- “数据全丢了，求修。”
- v1.4.0 之后出现——这是回归 bug。
- 本 sprint：hotfix 这个闪退。一个工程师，最多 2 天。
- 不做：重设计 streak UI（不动评分）。
- 通知没法一键静音（14 条，均分 1.4）
- “通知让我有羞耻感，想一键关掉而不是翻进设置。”
- “每日那条静不掉。”
- 本 sprint：在通知里直接一键静音。
- 不做：重写通知文案。
- Widget 数据显示错误（8 条，均分 1.6）
- “Widget 显示 0 streak，我明明有 12。”
- v1.3.5 之后出现——widget v1 bug。
- 本 sprint：修 widget 数据同步 bug。
- 不做：上 widget v2。
结构上不可修（只进回复模板）：
- “加一个纯 streak、没有 off-ramp 的模式”（5 条）——明确不在范围内；off-ramp 正是这个产品的楔子。
- “加排行榜”（3 条）——同上。
针对类 1 的 App Store 回复建议：
“感谢反馈。v1.4.0 streak-freeze 更新后的闪退是回归 bug，hotfix 已经在 App Review 里了。你的 streak 历史我们能恢复——在 设置 → 帮助 里联系我们就行。—— 团队”
为什么按评分影响排，而不是按条数
Google Play 和 App Store 都把评分向近期活动加权——截至 2026 年，Google Play 用的是近期加权模型，最近的评分比你 2022 年的历史权重高得多，所以一波由回归 bug 引发的新 1 星会很快把你的显示分拉下来（而修好一个季度也能恢复）。这就让严重度、而非数量，成了该追的东西：本月一簇 12 条 1.0 星的闪退，比两打陈旧的 3 星「希望多点主题」更能动你的数字。让模型按 条数 × 严重度 排，闪退或数据丢失类永远压过功能请求。
怎么改输出
- 只按条数排 → 要求「按可能的评分影响 = 条数 × 严重度 排序，闪退打败功能请求」。
- 聚类太粗 → 「至少给 5 类；只有当两类引文重叠超过 70% 才合并」。
- 不关联版本 → 「每一类都检查是否在我列的某个版本 2 周内开始」。
- 推荐装饰性 fix → 「不许推荐不动评分的 UI 重写；装饰性 fix 一律进
不做那栏」。
回复时别越回越糟
如果分析里冒出值得回复的一类，公开回复要事实、要短。截至 2026 年 6 月，App Store Connect 给开发者回复最多 5970 个字符，而且你的回复最长要 24 小时后才公开显示，所以审核还没过就别承诺「今天已修复」。只有 Account Holder、Admin 或 Customer Support 角色能发回复。等修复真上线了，回头去回那些曾抱怨此事的旧评论——苹果允许你重新触达这些用户，而被编辑过的回复会标注为已编辑。
容易踩的坑
- 把所有负面同等对待。 12 条闪退胜过 25 条装饰性抱怨。
- 忽略结构上不可修的那一类。 它们要的是回复模板，不是一个 sprint 名额。
- 让一个嗓门大的评论主导。 你交代了模型就会给离群值降权；放着不管它会过度盯着那条最愤怒的 400 字长文。
- 跳过「不做」这一栏。 分析的另一半价值就是知道该拒绝什么。
- 只回复不修。 公开回复却不跟进，比沉默更快地侵蚀信任。
FAQ
正面评论也要分析吗？ 单独做。那边的问题是「护城河在哪、要守什么」，不是「要修什么」。混在一起两边都被稀释。
到底要多少条评论才够？ 30+ 才能稳定聚类。再少模型就会从噪声里编主题，一个离群值就把整张图带偏。
AI 能直接 scrape App Store 评论吗？ 不能。从 App Store Connect 导出，或抓 RSS feed（截至 2026 年 6 月每个国家商店上限 500 条文字评论），或用 CSV 工具，再把文本粘进去。模型自己够不到商店。
该用哪个模型？ 任何当前旗舰都扛得住这个量；差别在排序。用推理档位——Claude Opus 4.7 或 GPT-5.5 Thinking——因为影响排序正是更便宜的「instant」模式退化成单纯数数的地方。
每条负面都要回吗？ 不要。公开回前 1-2 类即可；只有当你有办法触达用户时，才私下回那些高信号的单条评论。
相关阅读
外部参考：Apple — 回复评论 · Google Play — 下载与导出报告
标签: #AI 写作 #用户反馈 #评论回复 #App Store #运营