Steam 最近评测和全部评测不一致，该信哪个？

全部评测不错，最近评测却差了不少，到了购买按钮前难免会犹豫：这游戏是以前好玩，现在出问题了吗？反过来，如果全部评测不怎么样，最近的反应却变好了，是不是就可以放心买了？

在我看来，买之前先看最近评测更有用。毕竟，对准备现在开始玩的人来说，现在会遇到什么不便才更要紧。

不过，不能把评测的差异全归到更新头上。两边的语言可能不同，你正在读的评测列表和页面上方的评分，统计的也可能不是同一批评测。这次我们查看了三个商店页面公开 HTML 中的最近评测和韩语评测。下面会结合可以自己验算的假设例子，看看这两类汇总能不能放在相同条件下比较。

同一个页面上的数字，统计范围未必相同#

这是帮助比较的示意图。实际数字和查看时间另列在正文表格中。

2026 年 9 月 12 日，我们在不携带登录信息的情况下，向三个 Steam 商店页面发送 HTTP 请求，并保存了返回的 HTML。下表记录的是每个响应接收完毕时的韩国时间（KST，UTC+09:00），并不代表同一瞬间的统计，也不是服务器内部计算这些数字的时间。

来源：Stardew Valley、No Man’s Sky、Balatro。比例取自已保存 HTML 中的工具提示说明属性，并非在浏览器中调出工具提示后留下的画面记录。单看这些汇总，还无法确认最近评测涵盖哪些语言、韩语评测从哪一天开始统计，以及所有语言的全部评测数量、比例和等级。

No Man’s Sky 的两个比例相差 17 个百分点，但没有依据说韩语评测改善了这么多。要了解变化，需要两个时段的资料，并让语言和纳入标准保持一致。这张表并不满足这样的比较条件。

此时要做的不是选出哪个数字才对，而是先确定自己想知道什么：长期积累下来的反应，最近的反应，还是用自己打算使用的语言玩游戏时的体验？这些问题听起来相近，回答它们所需的资料却不同。资料里没写明的条件，不能凭一个熟悉的栏目名称自行补上。

Steamworks 将商店评测的时间范围说明为过去 30 天和产品的整个生命周期。Steamworks 用户评测文档

我们选择这三款游戏，是为了说明怎么看评测，不是调查有多少游戏近期反响好、有多少反响差。三个页面的最近评测都属于好评类别，也不能据此断定 Steam 上大多数游戏都反响不错。这些资料也不包含实际运行游戏或测量性能的结果。

“韩语评测”这个名称也需要留意。Steam 的评测数据文档中，语言指作者写评测时指定的语言，不是对居住国家的调查。因此，把韩语评测的比例说成全体韩国人的满意度，就超出了资料能说明的范围。Steam 评测数据说明

Valve 在推出按语言区分的评测分数时解释过，翻译、文化背景、网络等因素可能带来不同的体验。所以，筛选语言是有理由的。但用韩语写的评测并不全是在谈翻译质量。觉得战斗难，和指出对白不自然，即使用同一种语言写出来，说的也是不同问题。按语言区分评测分数的推出公告

如果你是担心翻译才打开韩语评测，就还需要从中找出真正谈到对白或说明文字的内容。反过来，如果你犹豫是因为不喜欢高难度战斗，那么看到很多翻译方面的抱怨，并不等于找到了想要的答案。选好了分类，评测也还得继续读。

90% 这个数字里，究竟算了什么#

这是基于假设的算术例子，不是 Steam 的实际评测数据。

Steam 客服将评分解释为按好评比例划分的类别。对于需要购买的游戏，在 Steam 购买的玩家所写的评测会计入评分；不需要购买的游戏另有例外。页面上的百分比，不能理解成玩家按百分制打分后得出的平均分。Steam 用户评测帮助

点了推荐，不代表完全没有不满。一个人可能因为喜欢的地方很多而推荐，同时又花很长篇幅描述某个严重的不便。也可能玩得很开心，却因为一个对自己重要的条件不满足而点了不推荐。把这两种选择汇总成比例，无法还原每个人做出选择的原因。

过去有研究考察过这一点。Lin 等人的 Steam 评测研究以 2016 年 3 月的商店目录为基础，排除评测不足 25 篇的游戏后，收集了 6,224 款游戏的 10,954,956 篇评测。研究者并没有逐篇读完全部评测。做内容分析时，两位研究者人工分类了 472 篇英语评测；其中的好评里，29% 提到了缺点，7% 提到了 bug。这是当时样本的结果，不能把这些比例套到今天的韩语评测上。对我来说，这给了一个很具体的理由：看到推荐标记，也别跳过正文。Lin 等人的 Steam 评测研究，表 10

从这里开始，计算所用的数字都是为方便说明而设定的，并非实际游戏评测或调查结果。我们会同时写出分母和好评数量，方便你自己算一遍。

假设 A、B 两组互不重叠。A 组有 1,000 篇评测，其中 900 篇是好评；B 组有 10 篇，其中 8 篇是好评。两组的好评率分别是 90% 和 80%，把这两个百分比相加再除以 2，就得到 85%。

但如果把所有评测合在一起，好评共有 908 篇，评测总数为 1,010 篇。908 除以 1,010，约等于 89.9%。之所以和 85% 不同，是因为前一种算法把有 1,000 篇评测的组和只有 10 篇的组，都当作一个同样大小的单位。两种算法想求平均的对象不同：一个按单篇评测算，一个按组算。

想把不同语言的百分比取平均，算出全部评测的分数时，也会遇到这个问题。你需要知道各组的好评数量和总数。在此之前，还得确认各组是否重叠、有没有遗漏的组，以及统计条件是否一致。如果只合并了页面上看得到的一部分，结果也只能说明那一部分。

正确体现大群体的权重，和忽略小群体的不便，是两回事。某个问题在合并后的分数里不显眼，但如果你恰好打算按那种条件游玩，它就可能很重要。评测数量更多的群体，也不能替你决定个人喜好。

比例看起来稳不稳，也和分母有关。5 篇评测里有 4 篇好评，好评率是 80%；多一篇差评，就成了 6 篇里有 4 篇好评，降到约 66.7%。1,000 篇里有 800 篇好评，起初同样是 80%，但多一篇差评后约为 79.9%。都是增加一篇，变动幅度却很不一样。

这不代表评测数量少就没必要读。要看看一篇“卡在启动画面”的具体描述，并不需要先凑够一千篇评测。只是，这一篇让比例变动了多少，与问题本身有多严重，要分开看。不能仅凭百分比大幅下跌，就推断有多少人受到了影响。

评测很多的游戏，也可能让人产生相反的错觉：新问题出现了，却被长期积累的数字掩盖。全部评测的比例和昨天差不多，不代表新发评测里提到的运行问题就不存在。还是得另外看看，评测描述的是在什么条件下发生的问题。

记录比例变化时，写清单位也有帮助。同样条件下的假设统计从 60% 变成 90%，是增加了 30 个百分点；相对于最初的 60%，则增长了 50%。只写“好了 30%”，别人很难知道你是怎么算的。仅凭这两个比例，也看不出好评增加了多少篇，因为还缺少两个时间点各自的评测总数。

也别把显示出来的数字当成同样精确的原始数据。假设一张表四舍五入到小数点后一位，79.96% 和 80.04% 都会显示为 80.0%。不是原来的值相同，而是显示时把差别抹掉了。这并不是在说 Steam 使用这种舍入方式，而是用例子说明：单凭页面显示的比例，推不出背后准确的整数数量。

把最近评测再加进全部评测，会发生什么#

这里假设已知准确数量和包含关系，并非根据 Steam 显示的比例反推出来的数字。

先假设统计条件、查看时间相同，而且最近评测全部包含在全部评测中。全部 1,000 篇评测里有 900 篇好评，其中最近的 50 篇里只有 30 篇好评。那么全部是 90%，最近是 60%，并不需要有一个数字是错的。

这是因为最近评测只占全部评测的一小部分。长期积累的反应很多时，新出现的差异在整体数字里就不那么显眼。这种情况下，全部与最近之间的差距，更适合作为去读新评测的理由，而不是删掉其中一个数字的理由。

要小心的是把这两组相加。好评数用 900 加 30，总数用 1,000 加 50，就把最近评测算了两遍。不能把全部评测和最近评测当成两次互相独立的投票。想把两个百分比混合成一个更可信的分数之前，也得先弄清它们的包含关系。

在同样的假设下，可以算出扣除最近评测后的早期部分。好评为 900 减 30，得到 870 篇；总数为 1,000 减 50，得到 950 篇，好评率约为 91.6%。能做这个减法，是因为已经知道准确的整数和包含关系。如果一边的语言不同，或排除条件不同，就不能照搬。同样，也不能拿前面 HTML 汇总中的整数百分比乘以评测数，得到一个估算值，就宣称准确还原了过去的评分。

随时间变化的，究竟是游戏本身，还是留下评测的人群构成，也要分开考虑。再用两组假设数据说明一下。这里的 A、B 不代表真实国家，也不代表实际的玩家类型。

第一个时间点，A 组 100 篇里有 90 篇好评，B 组 10 篇里有 5 篇好评，合起来是 110 篇里有 95 篇好评，约为 86.4%。第二个时间点，假设 A 组变成 10 篇里有 9 篇好评，B 组变成 100 篇里有 50 篇好评。合计 110 篇里有 59 篇好评，约为 53.6%。

总好评率明显下降了，但 A 组两个时间点都是 90%，B 组都是 50%。各组的比例没变，只是两组所占的权重对调了。甚至评测总数都一样，都是 110 篇。这就是为什么总数相同，也不能说明内部构成相同。

这个例子并不是在解释某次真实的 Steam 评分下跌。要找到实际原因，还需要相应的资料。这里只是说，比例下降了，并不能单凭数字就得出游戏的每个部分都变差了的结论。中间还缺了一步：到底什么变了？

普通玩家能做的，不一定是把所有原因都查清。读一读与你在意的条件有关的近期评测，看看有没有描述具体变化，就能为购买决定补充信息。需要区分群体，不意味着要收集作者的个人资料或账号名单。这里也没有收集实际的个人数据，或做这样的分析。

为什么读完评测列表，感觉和评分不一样#

这张图对照的是当时公告的内容，不是实际评测列表的截图。

往下滚动一点，看到的都是抱怨，就可能觉得页面上方的高分很奇怪。但首先得想想：最先出现的几篇，是随机抽出来的吗？按特定标准选出的文章，给人的印象未必和全部统计一致。

Valve 在 2024 年的有用性系统公告中说明，排序会调整为优先显示有助于购买决策的内容；被归类为信息量较低的、只写一个词的评测或玩梗内容等，可能会被排到后面。公告明确区分了排序和评分计算：这次调整不改变评测分数的计算方式。先被读到的评测，和计入评分的评测，不是一个概念。评测有用性系统公告

一句有趣的感想，读起来可以很开心，却未必能回答你买之前的问题。不必判定这种表达是对是错，看看有没有自己需要的信息，没有就接着往下读。反过来，一篇文章再长、语气再认真，如果和你的问题无关，也未必值得优先看。

通过外部激活码、免费周末、家庭共享等方式玩过游戏的玩家，也可以写评测。能读到的评测，并不都会计入付费游戏的评分。

单篇评测被归类为与游戏无关，和把发生无关评测活动的整个时段排除在评分之外，也要区分。当前 Steamworks 文档说明，前一种情况即使降低了可见度，评测仍会计入评分。Valve 重新审视用户评测的公告则说明，后一种情况在默认设置下，会将判定时段内的所有评测排除出评分，但不会因此删除评测。Valve 重新审视用户评测的公告

我不愿意只看图表突然下跌，就把所有批评都叫作评测轰炸。也可能是真的有更多人遇到了问题。批评是否有道理，和评分如何处理这些评测，是两件需要分别考察的事。这次收集没有确认排除时段或账号设置。

读评测的顺序也可以跟着问题走。想知道某次变化后的问题，就先读那之后写的；想知道长时间游玩后才显现的不便，就先看具体描述这种经历的内容。不管是哪种情况，都不宜把自己挑着读的几篇，换算成全体玩家中的比例。

几篇不同的文章看似都在说同一个问题，也可能只是在转引同一篇内容。需要分清，这是另一个人在不同条件下的亲历，还是把最初的说法又传了一遍。找到五篇引用文章，并不能算作五次独立确认。

不妨把注意力从评测的情绪和语气，移到可以核实的内容上：做了什么之后发生了什么，作者原本期待什么，哪些部分只是猜测。语气越愤怒，不一定意味着问题越严重；写得平静，也不代表内容已经得到验证。

出了补丁，不等于问题已经解决#

这份资料说明有过这则公告，不是对补丁效果的测量结果。

Hello Games 在 2026 年 9 月 9 日的 COSMOS 公告中介绍了 7.0 更新。COSMOS 官方公告

新公告发布后，评分就算发生了变化，也不代表原因已经找到了。这次资料里没有收集更新前后的单篇评测，再按内容分类的结果；也没有实际运行测试，或在相同条件下比较性能。

如果某个抱怨让你犹豫要不要买，可以把它的日期和相关公告放在一起看。关键是公告到底说了什么：新增内容、承认问题、声称已修复，能回答的是不同问题。不能因为标题都叫更新，就把这三种情况当作一回事。

名字相近的故障，出现的场景也可能不同。战斗后卡住，和打开存档列表时卡住，如果都笼统归为“卡住”，就很难对照究竟修好了哪一个。要读清开发商说已修复时，具体附带了哪些条件。而读过那段说明，和通过测试确认自己的环境里已经解决，仍是两回事。

Steam 评测数据分别记录首次撰写时间、最后修改时间、累计游玩时长和撰写评测时的游玩时长。很早以前写的评测，可能最近才改过；作者写完之后，也可能又玩了一段时间。因此，累计时长很长，不代表这些时间都在经历文章现在描述的那个问题。

也不能因为游玩时间短，就忽略无法启动之类的问题。“一开始就进不去”和“后期内容不尽如人意”，所需的体验范围本来就不同。反过来，玩得很久的人，也可能没接触过你想了解的模式或场景。时长可以帮助理解评测的背景，却不是判定所有说法真假的资格证。

找不到后续评测时，更难下判断。很容易以为没人再说就是修好了，但在这次搜索范围里没找到新内容，和问题已经消失，并不是一回事。作者也可能因为别的原因不再发文。找不到确认已解决的资料，就可以先不下结论。

说游戏变好了的评测，也可以这样读。具体说明哪种不便减少了，和只说一句“现在可以了”，提供的信息不同。如果好评一律放过，只对批评挑剔地审视，很容易只是通过阅读来确认自己原本就想买的念头。

从抱怨里找出真正影响自己的问题#

这是用来说明阅读方法的假设例子，没有转述任何真实评测、作者或游戏。

下面设想一种买游戏前的困惑，不对应真实游戏或玩家的故事。有个人想找一款能独自体验剧情的游戏，不喜欢长时间重复战斗，而且需要经常停下来。整体反响不错这件事已经确认了，但他还想知道游戏适不适合自己。

他看到了三篇假设评测。第一篇夸赞和朋友一起反复战斗很有趣；第二篇说剧情不错，但同样的战斗要打很多遍，因此不推荐；第三篇说画面很合心意，还想再听里面的音乐。这些句子都不是对真实帖子的引用。

只数推荐与否，整体印象可能更偏正面。但对这个人的购买决定来说，第二篇关于重复战斗的描述更值得先看。不是说和朋友一起玩的乐趣或音乐不好，而是它更贴近一开始定下的条件。挑出有用的评测，和判定游戏好不好，不是同一件事。

不过，看到一篇不推荐，也不必马上放弃。那些重复战斗究竟是推进剧情必不可少的，还是为了收齐可选内容才碰上的，目前还不清楚。文章没有回答，下一份资料要找的就是这个区别。对于这次购买，弄清抱怨适用于什么范围，比再找一篇同样的抱怨更有帮助。

到了这里，能接受和不能接受这种不便的人，可能会作出不同选择。如果只是可选内容，可以考虑跳过；如果主线里也频繁出现，也可以改选别的游戏。还不知道是哪一种，那就保留等等再买的选项。不必因为好评率高就放弃追问，也不必因为看到不推荐，就把所有优点一并否定。

即使已经找到“重复战斗属于可选内容”这个答案，最初记下的条件也还剩一个：这个人需要经常中断游玩。能跳过战斗，并不等于想结束时就能退出。接下来，我会找找有没有人写过短时间游玩后停下来的经历，或查阅相关官方说明。如果找不到，就记下：对重复战斗的顾虑减轻了，但怎样中断仍不清楚。找到一个答案，不该被当成所有购买条件都满足了。反过来，已经查清的重复战斗问题，也没必要一直从头再读。分清已经知道的事和剩下的问题，就能离开反复翻看同类评测的循环，去找还会影响决定的资料。

读评测时，也值得区分问题出现的频率，和出现一次会造成的后果。很少发生，不代表问题就轻。短暂的显示错误和丢失进度，即使发生次数相同，接受起来的负担也可能不同。本文没有测量这类发生率，只是在说明：把别人报告的问题放到自己的购买条件里时，还需要知道什么。

反过来，经常被抱怨的内容，是不是你讨厌的东西，也要另外想一想。有人批评对白太长，对想赶快跳过剧情的读者来说是提醒，对原本就想慢慢读对白的人来说却可能不太碍事。没必要硬说别人嫌弃的地方恰好是自己的优点，但喜好的差别，确实不能靠数字解决。

建议寻找具体说明，不是要求其他玩家交出所有证据。评测也是写个人感受的地方。别人有只写一句“不好玩”的自由，而准备购买的你也有必要另找更详细的资料，这两件事并不冲突。描述不够，就别把它当成自己问题的答案。没必要质问作者，更不必调查账号。

遇到截然相反的评测，可以先找双方都认同的事实。一方说战斗重复、很无聊，另一方说反复练熟同样的战斗很有意思，他们可能都承认战斗具有重复性。推荐与否相反，反而也能帮助你看清游戏的特点。

这种读法和投票决定谁对谁错有些不同。我们是在分辨：分歧来自喜好、不同时间的体验，还是不同的游玩条件？相同条件下，每个人的判断也可能不同，所以不必给每一种分歧都安上唯一原因。

我觉得，读评测前简单记下购买条件，有助于减少这种混乱。不需要一张复杂的评分表，只要留下眼下的问题：想知道独自推进时有多少重复内容，或能不能玩一小会儿就停下。读着读着改变想法时，也能回头看看，最初究竟想确认什么。

继续读，却没有更多答案时#

这是根据条件作出判断的例子，不保证购买结果，也不是在展示 Steam 的提醒功能。

类似的评测读久了，有时会分不清：是在获取更多信息，还是在等别人允许自己按下购买按钮？如果只是在找符合心意的结论，再看十篇，也未必能让判断更可靠。不妨问问自己：看到什么样的描述，我会改变选择？

比如，你已经决定，如果能确认担心的不便只存在于可选内容里，就考虑购买，那么下一步该读的就是能确认这件事的资料。反过来，如果无论怎么解释，只要还有一点买了不合适的可能，就让你放不下心，那多收集一些好评也未必有用。我认为，这时暂缓购买更合适。

记录阅读结果时，留下条件，比只抄一个数字更有用。简单记下查看日期、统计项名称、确认了什么问题，还有什么不清楚。以后找到新资料时，如果保留原来的记录，而不是直接覆盖，就能回头看出自己为什么改变了判断。

为了比较而调整了条件，也把改过的项目一起记下来。时段、语言和购买方式同时变化，结果即使不同，也很难分清是哪项变化造成的。实际条件没有确认，就不要说自己做了同条件比较。

这次的商店资料来自没有发送登录信息的 HTML 请求，我们只记录了其中明确写出的最近评测和韩语评测汇总。没有把偏好语言、购买筛选和排除设置统一后进行比较，也没有取得公开评测汇总 API 的响应。因此，这不是一份计算了准确好评、差评原始数量，或不同购买途径差异的资料。

没有“必须读完所有评测才能买”的标准。看看最初关心的条件是否已经有了答案就好。理解了喜好的差别，也觉得可以接受，就可以考虑购买；如果影响游玩的关键问题还不清楚，也可以再等等。无须在高分和低分之间删掉一个，照样能作决定。

确认评测里有没有现在开始玩的你所需要的信息后，比起只盯着页面上方的评价标记犹豫，你会更清楚自己到底在担心什么。