用 MCP 将应用商店评论变成产品分析输入

Claude 能回答「用户最近最讨厌 Todoist Android 版的什么」，但如果没有新数据，答案可能只是根据旧训练资料推测。作者做了一个 MCP server，把 App Store 和 Google Play 的实时评论接给模型，并先统计、再交给模型解读。

这篇值得看的地方，是一个具体的 AI 工程选择：评论抓取和计数由工具完成，模型负责比较、解释和追问。不过，拿到新数据不代表结论就可靠，样本范围和关键词统计仍然需要核对。

为什么先统计，比直接塞评论更实用

作者的判断是，原始评论对 Agent 来说太贵。300 条评论很容易占用数万 tokens，模型读完之后，还要自己数评分、归纳话题。

他们提供的 analyze_app_reviews 先完成统计，返回约 4–5 KB 的 JSON。作者给出了 Todoist 在美国 Google Play 最新 100 条评论的一次真实调用结果，下面是节选：

{
  "averageRating": 3.93,
  "ratingDistribution": { "1": 14, "2": 7, "3": 9, "4": 12, "5": 58 },
  "negativeShare": 0.21,
  "developerReplyRate": 0.85,
  "topComplaints": [
    { "term": "task", "mentions": 5, "shareOfReviews": 0.238 },
    { "term": "add", "mentions": 4, "shareOfReviews": 0.19 }
  ]
}

重点看 negativeShare：14 条一星加上 7 条二星，占这批评论的 21%。topComplaints 的比例则不能直接按全部 100 条理解，原文没有明确说明它的分母和筛选口径。

先让工具算清楚，再让模型解释，能减少上下文负担，也让统计结果更容易复核。

但这还不是性能对照实验。作者没有提供直接输入原始评论与使用摘要时的 token 消耗、耗时或准确率比较。

总评分 4.6，最近评论为什么只有 3.93

原文中，Todoist 的商店总评分是 4.6 星，这批最新 100 条评论的均分却是 3.93，且 21% 为一星或二星。

两个数字回答的是不同问题：总评分反映长期积累，最近评论更接近当前反馈。产品经理如果只看总分，可能错过近期出现的问题。

不过，这个差距只能作为调查入口。它不能单独证明产品正在变差，更不能直接归因于某次更新。要判断原因，还需要检查评论时间、版本以及具体内容；原文没有提供这些对照。

作者还返回了 developerReplyRate: 0.85，也就是这批样本的开发者回复率为 85%。回复率能说明回应情况，却不能说明问题已经解决。

怎么接进日常 AI 工具，成本怎么算

这个服务运行在 Apify 的 Standby actor 上，使用者不需要自行托管。作者称它包含五个工具，但原文没有完整列出名称，只明确展示了 analyze_app_reviews。

应用可以通过商店 URL、Apple id、Android package name 或名称指定。Claude Desktop、Cursor 和 VS Code 可以通过 mcpServers 配置连接，服务项名为 app-reviews，使用 url 指定地址，并在 headers 中设置 Authorization。

Claude 的命令行接入方式如下：

claude mcp add --transport http app-reviews https://rasareka--app-reviews-mcp.apify.actor/mcp --header "Authorization: Bearer YOUR_APIFY_TOKEN"

注意 --transport http 和 --header：前者指定连接方式，后者传入 Bearer token，YOUR_APIFY_TOKEN 需要替换成自己的凭证。

作者建议的提问包括：比较 Todoist、TickTick 和 Things 3 的近期弱点；查看英国 App Store 中 Notion 自上次更新以来的一星评论；寻找美国排名前 10 的习惯追踪应用，比较同步相关投诉。它们是提问示例，原文没有展示每种任务的完整执行结果。

计费方面，搜索或详情调用每次 $0.005，每 50 条评论 $0.005，每份洞察报告 $0.03，失败调用免费。作者估算，一次比较 3 个竞品的会话约 $0.10。实际费用仍取决于调用次数和抓取量。

我的判断

我认可这个分工：确定性的计数交给工具，模型处理解释和比较。相较于直接把评论全部塞进上下文，结构化摘要更适合做第一轮筛查；需要判断具体问题时，再回看评论原文。

局限也很明确。Apple 的公开 feed 每个应用、每个国家最多提供 500 条评论，不能据此假设拿到了完整历史。话题提取采用关键词方法，task、add 这样的词也未必能说明用户到底在抱怨什么，更无法仅凭词频判断语气和原因。

这套工具适合发现调查线索，结论还需要评论原文支撑。

作者展示了一次真实统计结果，但没有给出与人工分析或其他方法的对照数据。关于效率和洞察质量，目前应按作者的实践经验理解。

能拿来做什么

• 做竞品调查时，先固定国家、商店和样本数量，再让 Claude 比较近期评分与投诉，避免把不同范围的数据直接排在一起。
• 排查应用更新后的反馈时，可以沿用作者的 Notion 提问方式筛选低分评论，同时核对评论时间和版本，确认反馈是否属于目标更新。
• 在 Cursor 或 VS Code 中接入后，先读取统计摘要，再要求模型引用具体评论解释投诉，避免把关键词直接当成需求结论。
• 自己设计 AI 数据工具时，可以参考这种输出方式：返回评分分布、比例和话题计数，同时明确分母与采样范围，让后续分析有据可查。