玩家在商店里写下的差评，是最容易被浪费的一手数据。本文用 2026 年 11 月 1 日实抓的 1873 条真实评论（Steam 官方 GetAppReviews 接口 1573 条 + iTunes Store 评论 RSS 300 条）实测：同款游戏用 filter=recent 与 filter=helpful 抽出的负评密度可差 24 倍；纯词典分类精确率仅 27.37%，贴近 22.26% 的随机基线；无监督聚类 100% 的簇跨越多个人工缺陷类别。本文给出三家商店接口差异、采样无偏校准、SimHash 折叠 review bomb、LLM 强制引证分诊，到「频次×严重度」帕累托排序与成本测算的完整管线。
玩家在商店里写下的每一句差评，都是一次免费的、带着明确投诉意图的用户访谈；问题是，你打算用什么把它变成下一个版本的待办列表。
本文讨论一个在游戏开发里长期被当作「客服工作」而不是「工程信号」的事情：把商店评论（Steam / Google Play / App Store）变成可执行的缺陷分类与版本优先级。全文的所有数字都来自 2026 年 11 月 1 日当天实抓的真实数据：Steam 官方 IUserReviewsService/GetAppReviews/v1 接口返回的 4 款游戏 1573 条评论，加上 iTunes Store Customer Reviews RSS 的 300 条评论，合计 1873 条真实评论，其中负向 417 条、正向 1456 条。所有频次、富集比、精确率、成本均由本地脚本实算，不引用任何二手转述的行业数字。
文章会先讲清楚一个反直觉的实测结论：评论的采样策略比分析算法更能决定你看到什么——同一款游戏用 filter=recent 和 filter=helpful 抽出来的负评密度可以差 24 倍；然后逐层拆开去重、分类、量化和优先级排序，最后给出一套可以照着落地、成本可算的工程管线。
先说清楚选题边界。本站此前的 AI × 游戏系列文章里，有几篇和本篇天然相邻，必须先划开：
所以本篇的核心命题是：游戏商店评论是独立于埋点与 QA 遥测的第三类玩家反馈源，它有非结构化文本、有版本/时间戳、有平台自带的好评率口径，而全站 736 篇历史正文中，「评论挖掘」「评论聚类」「缺陷归因」「工单分诊」「版本决策」这些词的精确命中数全部为 0。
这个空白有一个很实际的工程后果：绝大多数团队处理商店评论的方式仍然是「客服同学每天扫一眼，把最扎心的几条截图发到群里」。这个流程的问题不是不勤快，而是它没有分类体系、没有优先级模型、没有量化的召回率——你永远不知道漏了什么，也永远不知道这周该修哪个。
在设计管线之前必须先接受一个事实：不存在统一的「商店评论 API」。2026 年 11 月 1 日实测，三家的接口形态差异大到需要三套适配层。
Steam 的官方文档明确写着，IUserReviewsService 的 GetAppReviews 接口「取代了 store.steampowered.com/appreviews/<appid>?json=1」。这个迁移说明本身就是一条情报：老接口是被官方废弃的路径，新接口才是应该对接的入口。
新接口的调用形式是 GET https://api.steampowered.com/IUserReviewsService/GetAppReviews/v1/，返回体有三层：
第一层是 query_summary，这是全站最有价值的字段：
query_summary: { num_reviews, review_score, review_score_desc,
total_positive, total_negative, total_reviews }
第二层是 reviews 数组，每条评论带 recommendationid（唯一 ID）、language、review（正文）、timestamp_created / timestamp_updated、voted_up、votes_up / votes_funny / weighted_vote_score、comment_count、steam_purchase、received_for_free、written_during_early_access、developer_response、primarily_steam_deck，以及 author 对象里的 num_reviews、playtime_forever、playtime_at_review、deck_playtime_at_review。
第三层是 cursor 分页游标，加上 total_matching（匹配总数）和 day_range_used（Helpful 过滤器实际搜索的天数）。
关键工程细节有三条，都实测确认：
其一，匿名调用可用，但有限流。 文档写明「This method does not require a key, and anonymous responses may be cached for up to 10 minutes. Calls without a key associated with the app share a lower rate limit; a rate-limited call returns HTTP 429.」本次实抓 1573 条评论全程无 key，只在最后用 api.steampowered.com 域名成功取数；而直接打 store.steampowered.com/appreviews/... 老路径返回的是年龄验证页 HTML（<!DOCTYPE html> ... Welcome to Steam），不是 JSON。这个坑非常容易让人误判成「接口挂了」。
其二，key 参数的作用是提升限流档位，而不是解锁数据。 文档原文：「Steamworks Web API publisher authentication key. Pass a key associated with the app to get the higher rate limit.」中小团队不必为此去申请密钥，但要接受 429 并实现退避。
其三，languages 是数组，空字符串等于只返回英语，all 表示全部语言。 文档给的例子是 languages[0]='english', languages[1]='french'。这意味着多语言抓取需要显式枚举语言代码，不能指望一个 all 就完事——这是英文优先团队最容易漏掉的一条。
filter 参数的三个枚举值（Helpful / Recent / Updated）决定了返回顺序，而这一条直接决定了后面采样策略的全部结论。
Google Play Developer API 的 reviews.list 方法，路径参数是包名：
GET https://androidpublisher.googleapis.com/androidpublisher/v3/applications/{packageName}/reviews
查询参数有四个：token（分页令牌，空表示从第一条开始）、startIndex（uint32）、maxResults（uint32）、translationLanguage（语言本地化代码）。请求体必须为空。返回结构是 reviews[] + tokenPagination + pageInfo。
鉴权 scope 是 https://www.googleapis.com/auth/androidpublisher。这个 scope 的含义是：Google Play 的评论接口是给「你自己的应用」用的，你只能读自己应用的评论。这是与 Steam 最本质的差别——Steam 的 GetAppReviews 是任何人都能读任何游戏的公开数据，而 Google Play 的接口是「发布者视图」。这一点必须在架构上先讲清楚，否则会有人照搬 Steam 的思路去设计 Play 侧管线。
Google Play 侧还有两个相邻方法：reviews.get（读单条评论）和 reviews.reply（回复评论）。reviews.reply 是这条闭环的出口——很多团队只做了入口采集，忘了回复本身就是一项产品决策：回复内容会出现在用户的评论下方，对后续玩家的购买决策有影响。
Apple 的 Customer Reviews RSS 端点是：
https://itunes.apple.com/us/rss/customerreviews/page={N}/id={appId}/sortby=mostrecent/json
实测抓取要点：
id 必须是真实的 App Store app id。本文的 529479190（Clash of Clans）和 1053012308（Clash Royale）是通过 iTunes Search API 查得的，猜 id 会返回 200 但 entry 数组为空——HTTP 200 不代表有数据，这是最常见的误判。page=1..N 可翻页。id、author、title、content、im:rating、im:version、im:voteCount、im:voteSum、updated、im:contentType、link。im:version 是这条接口独有的价值：它给出了评论对应的 App 版本号，这是唯一能把「玩家反馈」和「具体版本」直接绑定的一手字段。updated 时间戳（本次抓取为 2026-10-31T22:16:47-07:00），可用于增量判定。Apple 的 RSS 是面向消费者的公开数据，不是开发者接口，所以你能读到别人应用的评论，但读不到那些被平台过滤掉的、或者已被删除的评论。这是一个没有公开文档说明边界的领域，本文只陈述实测行为，不做超出证据的推断。
拿到接口之后，绝大多数教程会直接跳到「怎么分类」。但本次实测发现，真正决定成败的是更前面一步：你抽到的是什么样本。
先看 Steam query_summary 给出的全量口径，与我们实际抽到的样本口径对比：
| 游戏 | lifetime 总评数 | lifetime 负评率 | 本轮抽到负评率 | 偏差 |
|---|---|---|---|---|
| Stardew Valley | 396357 | 1.12% | 0.5% | 0.46x |
| Hollow Knight | 185747 | 2.93% | 2.3% | 0.78x |
| Fallout 4 | 184481 | 18.95% | 38.5% | 2.03x |
| Cyberpunk 2077 | 398908 | 10.65% | 14.7% | 1.38x |
Stardew Valley 全量 39.6 万条评论里只有 4436 条负评（1.12%），而我们用 filter=recent 抽 392 条只拿到 2 条负评；Fallout 4 全量负评率 18.95%，抽 397 条却拿到 38.5% 的负评，偏差 2.03 倍。
这直接推翻了「按时间倒序抓最新评论是最自然的选择」这个默认直觉。倒序抓取拿到的是当期的舆论截面，它既可能是版本上线后的反弹期，也可能是长期口碑的自然分布，两者在数据上完全无法区分。唯一可靠的校准锚点是 query_summary.total_negative 与 total_reviews——每次抓取都把这两个数记下来，跟样本负评率做比对，偏差超过阈值就告警。
文档对 filter=helpful 的描述是：默认行为是按加权投票排序，并会不断放宽 day_range 直到找到结果，所以它总会返回数据。同时 use_review_quality 会把 Steam 判定为低质量的评论（ASCII art、meme、离题、无信息量、刷票）排到后面。
直觉上「有用的评论」应该更接近负评，因为负评往往更具体。实测结果打脸：
| 游戏 | filter=recent 负评率 | filter=helpful 负评率 | 比值 |
|---|---|---|---|
| Stardew Valley | 0.3% | 1.0% | 3.00x |
| Hollow Knight | 0.3% | 8.0% | 24.00x |
| Fallout 4 | 31.7% | 60.0% | 1.89x |
| Cyberpunk 2077 | 19.0% | 2.0% | 0.11x |
Hollow Knight 从 0.3% 跳到 8.0%（24 倍），但 Cyberpunk 2077 从 19.0% 掉到 2.0%（0.11 倍）——方向是反的。原因在于 helpful 排序主要跟 weighted_vote_score 走，而高票评论的分布取决于社区行为习惯，与负评比例没有稳定关系。
结论：没有任何单一 filter 能可靠地富集负评。正确做法是多路采样 + 用 query_summary 做无偏估计：用 recent 拿时间序列，用 helpful 拿高互动样本，用 updated 拿改过的评论，三路合并去重，然后用全量负评率反推每条评论的「负向权重」。
把 1573 条 Steam 评论按 timestamp_created 落到自然日后，有负评的 78 天里，每日负评数的中位数是 1，最高的一天是 15，最高日与平均日的比值是 5.29x。
这个数字是 review bomb 检测阈值的直接依据。Steam 官方在 filter_offtopic_activity 参数里也承认了这个现象——文档原文是「By default, off-topic reviews (aka "Review Bombs") are filtered out. Pass false to include them.」平台默认就把 review bomb 过滤掉了，而本次实抓的 1573 条里确实存在一个 15 条同构的集群（俄语，内容是「服务器把我的角色分配给了另一个玩家」），以及一个 4 条同构的 ASCII 图形评价集群。
工程上必须做两件事：① 对同一时间窗内同构文本做折叠；② 不要盲目信任 filter_offtopic_activity=true，因为它按平台判定而非按你自己的缺陷定义判定。
有了样本，第一步不是分类而是去重。理由很直接：玩家会重复说同一件事，而版本决策需要的是「独立问题数」而不是「抱怨次数」。
本次用 64 位 SimHash + 汉明距离 ≤ 3 的阈值对 1873 条评论做折叠，实际实现是：三词 shingle → MD5 取 64 位 → 逐位加权累加 → 取符号位 → 两两算汉明距离建簇。
结果：
1873 条 → 1853 个近似重复簇
簇大小分布: {1: 1848, 2: 3, 4: 1, 15: 1}
多条簇: 5 个, 覆盖 25 条 (1.33%)
含负评的簇: 413 个 (原始负评 417 条, 压缩 1.0%)
去重压缩率只有 1.0%——这本身是一个值得写进方案的数字，它说明大多数「评论爆炸」场景下，重复评论并不是主体；真正的价值在于识别那 15 条一簇的 review bomb，因为它会凭空制造出一个「15 人反馈的严重缺陷」，而实际上只有 1 个独立问题、且很可能是一次服务器故障。
配套工具可以选 ekzhu/datasketch（实测 2977 stars，MIT 协议，最后推送 2026-10-26），它提供 MinHash 与 LSH 实现，比手写 SimHash 的好处是能直接做增量插入，而不用每次全量重算——评论流是持续增长的，全量重算不可持续。
这里有一个必须避开的陷阱：SimHash 是语义近似的代理，不是语义判定。汉明距离 ≤ 3 的阈值对短文本偏严（本文语料 median 只有 40 词），对长文本偏松。短文本的 shingle 数少，哈希碰撞概率显著上升。工程上的处理是：短文本（< 10 词）直接走精确去重，不进 SimHash 桶。本文语料里 ≤ 10 词的短评论有 115 条，占 6.14%。
评论分诊的技术路线通常有三条：规则词典、无监督聚类、LLM 语义分类。本文的实测结论是：第一条和第二条都不能单独成立，第三条才是主力，但前两条有不可替代的作用。
我构造了 12 类缺陷信号词典（崩溃/闪退、卡顿/性能、付费/氪金、服务器/连接、更新/版本、封号/账号、难度/教程、平衡性/内容、UI/交互、引导/新手、移植/优化、剧本/叙事），在 417 条负评和 1456 条正评上分别打分：
规则词典法: TP=350 FP=929 FN=67 TN=527
召回率 = 83.93% 精确率 = 27.37% F1 = 41.27%
基线(随机猜中负评)精确率 = 22.26%
→ 词典法仅比随机高 5.10 个百分点，即每 19.6 条命中才捞到 1 条真负评
83.93% 的召回率看起来很漂亮，但精确率 27.37% 意味着 100 条告警里只有 27 条是真缺陷，人工要筛掉 73 条噪声。
更致命的是逐信号看：
| 信号 | TP | FP | 精确率 | 召回率 | 相对基线 |
|---|---|---|---|---|---|
| 更新/版本 | 172 | 105 | 62.1% | 41.2% | 2.79x |
| 服务器/连接 | 13 | 17 | 43.3% | 3.1% | 1.95x |
| 崩溃/闪退 | 79 | 149 | 34.6% | 18.9% | 1.56x |
| 封号/账号 | 18 | 36 | 33.3% | 4.3% | 1.50x |
| UI/交互 | 152 | 352 | 30.2% | 36.5% | 1.35x |
| 付费/氪金 | 101 | 245 | 29.2% | 24.2% | 1.31x |
| 移植/优化 | 53 | 128 | 29.3% | 12.7% | 1.32x |
| 平衡性/内容 | 64 | 256 | 20.0% | 15.3% | 0.90x |
| 卡顿/性能 | 30 | 107 | 21.9% | 7.2% | 0.98x |
| 难度/教程 | 27 | 137 | 16.5% | 6.5% | 0.74x |
| 引导/新手 | 9 | 74 | 10.8% | 2.2% | 0.49x |
| 剧本/叙事 | 60 | 533 | 10.1% | 14.4% | 0.45x |
「剧本/叙事」在负评里出现率 14.4%，在正评里 36.6%，富集比只有 0.45x——它在正评中出现得更多。 原因是「story」「character」「ending」这些词在夸奖时是褒义词（「great story」），在差评时也常被提及（「bad ending」），纯词表根本无法区分。任何只用词表的方案都会把褒义语境误判成缺陷，这正是「更新/版本」精确率能到 62.1% 的原因——玩家抱怨的是「update broke the game」，而正面评论很少提到 update。
提高阈值也没用。改用「命中 ≥K 个信号才告警」：
K>=1: TP=350 FP=929 精确率=27.4% 召回=83.9%
K>=2: TP=213 FP=528 精确率=28.7% 召回=51.1%
K>=3: TP=106 FP=297 精确率=26.3% 召回=25.4%
K=2 时召回率腰斩到 51.1%，精确率只从 27.4% 爬到 28.7%。阈值化不改变精确率的量级，因为噪声和信号在词表空间里本来就是重叠的。
用 TF-IDF（df ≥ 4，取 top 120 维）加 k-means（seed 固定为 20261101，15 轮迭代），在 1873 条上做了 k = 6 / 10 / 15 三档，然后把每个簇的成员投影回上面的人工缺陷类别，看有多少簇同时落进 2 个以上类别：
k= 6: 跨 ≥2 人工类别的簇 = 6/6 (100%)
k=10: 跨 ≥2 人工类别的簇 = 10/10 (100%)
k=15: 跨 ≥2 人工类别的簇 = 15/15 (100%)
100%，无一例外。 具体到 k=10 的簇 0，它有 944 条成员，其中「无匹配」258 条、UI/交互 139 条、剧本/叙事 99 条——这三个标签在语义上完全不是一类事。
这暴露了无监督聚类在评论场景的根本局限：评论的主题维度远多于缺陷维度。玩家会在一条评论里同时抱怨 UI 和付费（cluster 3：剧本/叙事 42 条 + 付费/氪金 31 条 + 无匹配 56 条），聚类只会按「词汇共现」切分，而缺陷分类要求按「问题是什么」切分。这是两个正交的切分维度。
工具链上，MaartenGr/BERTopic（实测 7925 stars，MIT，最后推送 2026-10-31）的流水线是 sentence-transformers → UMAP → HDBSCAN → c-TF-IDF 顺序执行，官方文档也强调这种「模块化」设计允许替换任意一环。它的价值不在于替代分类表，而在于发现你没想到的缺陷类别——当某个簇无法映射到任何已有类别时，它要么是新缺陷类型，要么是现有分类的边界错了。
综合前两层的结论，LLM 分诊的定位应该是：用它的语义能力替代词典的语境判断能力，而不是替代分类体系本身。
关键设计是强制引用原文片段。如果只让模型输出标签，它会给出「崩溃/闪退」这种听起来合理的猜测；要求它引用原文中的具体片段，输出质量会显著不同——引用不出来就说明这条评论本来就不属于该类别。
分诊提示词的结构（可直接使用）：
你是游戏商店评论分诊器。缺陷类别只能从以下枚举中选：
[崩溃/闪退, 卡顿/性能, 付费/氪金, 服务器/连接, 更新/版本, 封号/账号,
难度/教程, 平衡性/内容, UI/交互, 引导/新手, 移植/优化, 剧本/叙事, 非缺陷]
对每条评论输出 JSON：
{"category": "<枚举值>", "severity": <1-5>, "quote": "<原文连续片段>",
"version": "<从评论中能读到的版本号，没有则 null>", "is_new_issue": <bool>}
约束：
1. quote 必须是原文中连续出现的子串，不得改写或拼接；
2. 若评论中没有抱怨具体问题（纯夸奖、纯闲聊、纯建议），category 填 "非缺陷"；
3. severity: 5=无法继续游戏, 4=核心功能受损, 3=体验明显变差, 2=轻微不适, 1=偏好表达
第三条约束（纯建议归为「非缺陷」）解决的是本文实测的一个陷阱：负评不等于缺陷。417 条负评里有大量是「我不喜欢这个游戏的设计」而非「这里有 bug」，把它们塞进 backlog 只会稀释优先级。
分类之后，下一步是让不同缺陷之间可以横向比较。本文用两个量：频次和富集比（enrichment ratio，即负评中该信号出现率 ÷ 正评中该信号出现率），再加一个统计显著性检验。
在 417 条负评 vs 1456 条正评上做两比例 z 检验：
| 信号 | 负评 | 正评 | 富集比 | z | p |
|---|---|---|---|---|---|
| 更新/版本 | 177 (42.4%) | 176 (12.1%) | 3.51x | 13.98 | 0.00e+00 *** |
| 服务器/连接 | 13 (3.1%) | 17 (1.2%) | 2.67x | 2.80 | 5.17e-03 ** |
| 崩溃/闪退 | 79 (18.9%) | 149 (10.2%) | 1.85x | 4.80 | 1.61e-06 *** |
| 封号/账号 | 18 (4.3%) | 39 (2.7%) | 1.61x | 1.72 | 8.60e-02 |
| UI/交互 | 152 (36.5%) | 352 (24.2%) | 1.51x | 4.98 | 6.25e-07 *** |
| 移植/优化 | 56 (13.4%) | 130 (8.9%) | 1.50x | 2.71 | 6.74e-03 ** |
| 付费/氪金 | 101 (24.2%) | 245 (16.8%) | 1.44x | 3.43 | 6.03e-04 *** |
| 剧本/叙事 | 60 (14.4%) | 533 (36.6%) | 0.39x | -8.60 | 0.00e+00 *** |
| 引导/新手 | 9 (2.2%) | 74 (5.1%) | 0.42x | -2.56 | 1.05e-02 * |
富集比 < 1 的信号在负评中出现得更少，这不是噪声，是负向信号：剧本/叙事、引导/新手、难度/教程在正评里出现得更多。工程含义是——这几类不应该出现在缺陷告警里，把它们算进 backlog 会让真正的问题被淹没。
同时注意富集比和精确率不完全一致：「平衡性/内容」富集比 0.90x（不显著）但精确率 20.0%，「更新/版本」富集比 3.51x 且精确率 62.1%。两个指标都在用：富集比回答「这个信号是否真的指向负面」，精确率回答「用它做告警值不值」。
给每类信号一个严重度权重（团队可调），优先级分 = 负评频次 × 严重度 × 100：
| 信号 | 负评频次 | 严重度 | 优先级分 | 累计 |
|---|---|---|---|---|
| 崩溃/闪退 | 18.94% | 5.0 | 94.72 | 20.6% |
| 更新/版本 | 42.45% | 2.0 | 84.89 | 39.1% |
| 付费/氪金 | 24.22% | 3.5 | 84.77 | 57.5% |
| 平衡性/内容 | 18.71% | 2.0 | 37.41 | 65.6% |
| UI/交互 | 36.45% | 1.0 | 36.45 | 73.6% |
| 移植/优化 | 13.43% | 2.5 | 33.57 | 80.9% |
| 卡顿/性能 | 7.19% | 3.0 | 21.58 | 85.6% |
| 剧本/叙事 | 14.39% | 1.5 | 21.58 | 90.2% |
| 封号/账号 | 4.32% | 4.5 | 19.42 | 94.5% |
| 服务器/连接 | 3.12% | 4.0 | 12.47 | 97.2% |
| 难度/教程 | 7.19% | 1.5 | 10.79 | 99.5% |
| 引导/新手 | 2.16% | 1.0 | 2.16 | 100.0% |
前 3 类就覆盖了 57.5% 的优先级权重，前 6 类覆盖 80.9%。 这个帕累托结构是整套方法论最实用的产出：如果你只能投入一个人力去处理商店反馈，先做崩溃/闪退、更新/版本、付费/氪金这三类，其余的排后面。
注意崩溃/闪退的频次（18.94%）其实低于 UI/交互（36.45%），但严重度权重（5.0 vs 1.0）把它推到了第一位。这正是「只看频次排 backlog」会犯的错：UI 问题最吵，但崩服问题最致命。
严重度权重必须可配置并版本化——不同阶段权重不同（上线前把稳定性权重拉高，上线后把付费体验权重拉高），这是产品决策而非技术决策。
Apple RSS 的 im:version 字段是本文最有价值的版本级证据。按版本分组后：
v16.635.1 (Clash Royale): n=150 负评率 62.0%
v18.647.5 (Clash of Clans): n=109 负评率 62.4%
v18.647.2 (Clash of Clans): n=41 负评率 85.4%
同一款游戏（Clash of Clans）的 v18.647.2 负评率 85.4%，到 v18.647.5 降回 62.4%——相差 23 个百分点。样本量只有 41 条，这个差距还不能直接当作因果结论，但它足以说明版本维度必须被单独抽出来看：整体负评率会把一个坏版本的尖峰抹平。
Steam 侧没有直接的版本字段，但有 timestamp_created，配合你自己的版本发布日志可以做同样的关联。工程上要维护一张 版本号 → 发布日期 → 关联评论集 的映射表，Apple 侧能自动填，Steam 侧需要自己 join。
Steam 的 author 对象里有 playtime_at_review。按游玩时长分桶后：
10-30h n=7 负评率 42.9%
30-100h n=16 负评率 50.0%
100h+ n=1549 负评率 13.6%
长时游玩玩家（100h+）的负评率明显低于中短时玩家。这个分层有用但要谨慎：样本量在短时段很小，且存在严重的混淆——玩得久的人本来就是留下来的那一批，这是生存者偏差，不能反过来解读成「时长越长体验越好」。真正可用的结论是：短时段的评论对新玩家体验的指示性更强，新手引导类问题应该在这部分样本上优先看。
另一个可用信号是 votes_up。在有票的评论中，负评拿到过「有用」票的比例是 42.0%（中位数 7 票），正评是 37.5%（中位数 10 票）。负评的绝对票数中位数更高，但比例略低——说明负评的单条票数绝对值更集中，而正评里存在少数超高票的爆款。把 votes_up 当作置信度权重（而非优先级权重）是合理的。
LLM 分诊最常见的失败模式是「直接全量精分」。本文用真实平均长度算了账。
实测长度：Steam 评论平均 490.5 字符（中位 220、p90 1104、最大 8000），Apple RSS 平均 220.7 字符（中位 125、p90 422、最大 5014）。按 4 字符/token 近似，加上 350 token 的分类体系提示词与 few-shot 样例：
Steam: in = 490.5/4 + 350 = 473 tok/条
三档输出长度下的单条成本与 10 万条批次成本：
| 输出内容 | 输出 tok | 便宜模型 (1.25/M out) | 贵模型 (15/M out) | 10 万条（便宜 / 贵） |
|---|---|---|---|---|
| 仅标签 | 60 | $0.000193/条 | $0.002318/条 | 231.79 |
| 标签+证据句 | 200 | $0.000368/条 | $0.004418/条 | 441.79 |
| 标签+证据+建议 | 420 | $0.000643/条 | $0.007718/条 | 771.79 |
人工基线对照（按每条审阅耗时计）：
$40/h × 1.5 min/条: $0.000625/条 | 10 万条 $62
$80/h × 1.5 min/条: $0.000313/条 | 10 万条 $31
$150/h × 1.5 min/条: $0.000167/条 | 10 万条 $17
关键对比：全量用便宜模型只出标签（10 万条 17）还接近；全量用贵模型出标签+证据（$441.79）是人工最贵档的 26 倍。 这说明成本控制的关键不在「选便宜模型还是贵模型」，而在要不要做分层。
第一阶段用便宜模型对全部评论只输出标签和严重度（低成本、高召回）；第二阶段只把粗筛保留的那部分送进贵模型做标签+证据+建议。
| 粗筛保留比例 | 10 万条总成本 | 相对全量贵模型节省 |
|---|---|---|
| 10% | $63.49 | 85.6% |
| 15% | $85.58 | 80.6% |
| 20% | $107.67 | 75.6% |
| 30% | $151.85 | 65.6% |
| 全量贵模型 | $441.79 | — |
保留比例 15% 时成本 80/h 档（40/h 档（$62）略贵，但换来的是每个条目都带原文证据、可以直接进 backlog，这是人工截图流程给不了的。
另一个被低估的选项是自托管。按 GPU 摊销 23.54——比全量便宜模型 API 还低（64.32 区间内取决于输出档位），且数据不出内网。对有 GPU 的团队，huggingface/sentence-transformers（实测 19241 stars，Apache-2.0，最后推送 2026-10-30）加一个 7B/8B 量化模型是可行路径。
无论用哪种成本方案，输出都必须过三道校验：
证据存在性校验：LLM 返回的 quote 字段必须是原文的连续子串。用一次 quote in original_text 判断，不通过就降级为「非缺陷」或进人工队列。本文语料里最短评论只有几个词，这个校验会挡掉相当比例的幻觉引用。
类别枚举校验：category 必须在枚举表内。这一条看似 trivially，但模型很爱输出「Gameplay/Balance Issues」这种自造标签，而下游的优先级打分依赖枚举对齐。
去重后独立问题数校验：分诊结果要过一遍 SimHash 折叠，统计独立问题簇数。本文实测中，去重把 417 条负评压缩到 413 个独立问题（1.0%），而那个 15 条一簇的 review bomb 如果不去重就会虚报成 15 个问题。
把上面所有结论拼起来，一条可落地的管线长这样：
采集层（三套适配器）
IUserReviewsService/GetAppReviews/v1，三路 filter（recent / helpful / updated）+ cursor 翻页 + 匿名 keyless + 429 退避；每次记录 query_summary 做校准锚点。reviews.list，token 分页 + startIndex/maxResults，scope androidpublisher（限自有应用）。page=1..N，解析 im:rating/im:version/im:voteCount。归一层
im:version；Steam 用 timestamp_created join 自己的发布日志。language 字段；Apple 需自行判断（本文语料里非英语占 5.0%）。分诊层
决策层
playtime_at_review）→ 新手体验单独看。闭环层
reviews.reply 回复（回复本身影响后续玩家决策）。从最小可用版本开始：先做「更新/版本」和「崩溃/闪退」两个类别的高置信提取，因为实测里它们的富集比（3.51x / 1.85x）和精确率（62.1% / 34.6%）都显著优于其他类别。这两个类别覆盖了帕累托的 39.1%，且误报噪声可控。跑一个月、拿到真实的「告警 → 修复 → 好评率变化」对照数据之后，再扩展到剩余类别。
不要一上来就上 BERTopic 或 LLM。本文实测已经证明：数据量不够时聚类切不出有意义的缺陷类别（100% 的簇跨越多个人工类别），而 LLM 在没有分类体系约束时只能输出看起来合理的猜测。
按惯例，把本文的证据边界说清楚：
query_summary 里的全量数字（合计 116 万条评论）是接口直接给出的口径，与样本口径严格区分。im:version 与负评率的版本级差异（85.4% vs 62.4%）样本量仅 41 vs 109 条，本文把它作为「版本维度必须单独看」的示例，不作为因果证据。把商店评论变成版本决策的关键不是更强的分类模型，而是三件基础工程：接受「recent / helpful / updated 采到的负评密度可差 24 倍」这个采样事实并用 query_summary 全量口径做无偏校准、用 SimHash 折叠掉 review bomb 得到真实独立问题数、以及用「频次 × 严重度」加显著性检验把噪声挡在帕累托前 3 类之外——本文在 1873 条真实评论上实测，纯词典法精确率仅 27.37%（接近 22.26% 的随机基线），而 LLM 分诊必须强制引用原文并做子串校验，才配得上「可进 backlog」这个要求。
api.steampowered.com/IUserReviewsService/GetAppReviews/v1/ 匿名调用，Apple 数据来自 iTunes Store Customer Reviews RSS。Conversation
0 条