Steam游戏库数据导出工具：用AI帮你从待玩清单中选游戏

一个由"游戏荒"催生的开源小工具

随着游戏库越堆越大，许多玩家都陷入了同样的困境：面对上百款未通关的游戏，反而不知道该玩哪一个。Reddit 开发者 TohnoCoding 最近开源了一款名为 Steam Library Data Exporter 的小型控制台工具，正是为解决这类"选择困难"痛点而生。

这款Steam游戏库导出工具的核心功能很简单：在你将 Steam 个人资料设为公开后，它会调用 Steamworks Web API 抓取你的用户与游戏数据，并生成一个 JSON 文件，作为游戏库的完整快照。Steamworks Web API 是 Valve 公司面向开发者开放的一套 RESTful HTTP 接口，允许第三方程序通过标准的 GET/POST 请求访问 Steam 平台上的公开数据。RESTful API 是一种基于 HTTP 协议的软件架构风格，由 Roy Fielding 在 2000 年的博士论文中正式提出，核心原则包括无状态性、统一接口和资源导向，开发者无需安装专用 SDK，仅凭浏览器或简单的 HTTP 客户端即可调用。常用接口包括 IPlayerService/GetOwnedGames（获取用户拥有的游戏列表及游玩时长）、ISteamUserStats/GetPlayerAchievements（获取成就数据）等。这些接口只能访问将个人资料设为"公开"的用户数据，这既是功能前提，也是一层隐私保护设计。

JSON（JavaScript Object Notation）是由 Douglas Crockford 在 2001 年提出的轻量级数据交换格式，采用键值对和有序列表两种基本结构，语法简洁且人类可读，同时也易于机器解析和生成。相比 XML，JSON 没有冗余的闭合标签，体积更小、解析速度更快，如今已成为 Web API 数据传输的事实标准。在本工具的场景中，JSON 格式特别适合后续喂给 LLM，因为大语言模型在预训练阶段接触过海量 JSON 数据，能够高效理解其结构和语义。

值得玩味的是它的开发动机。作者提到，自己在玩过独立游戏《1000xRESIST》后深受触动——这是一款由加拿大独立工作室 sunset visitor 于 2024 年发售的叙事冒险游戏，发售后获得了极高的评价，在多个年终评选中名列前茅。游戏以科幻为外壳，讲述了一个关于记忆、身份认同与文化创伤的深层故事，其叙事结构受到口述历史和亚裔移民经验的深刻影响。在操作层面的要求极低，几乎没有传统意义上的"战斗"或"技巧挑战"，核心体验完全建立在探索、对话和情感共鸣之上。作者坦言随着年龄增长，反应速度大不如前，因此希望整理出一份游戏清单，喂给 AI/大语言模型，向其说明自己的口味、局限、偏好与期望的游戏特性，让 AI 从日益庞大的"待玩清单"中推荐合适的作品。

Steam Library Data Exporter 如何工作

使用门槛与操作流程

从技术实现看，这是一款典型的"微工具"（microtool）。微工具是一种软件设计哲学，其核心理念源自 Unix 哲学中的"做好一件事"（Do One Thing and Do It Well）原则。微工具通常代码量极小（几十到几百行），功能单一而专注，没有图形界面或复杂的配置系统。它们的价值不在于技术复杂度，而在于精准解决一个具体痛点，并且足够轻量以至于用户可以完整审计其源代码，确认没有恶意行为。在 AI 时代，这类工具作为"数据管道"的一环变得尤为重要——它们负责将分散在各平台的个人数据提取、清洗并结构化，为下游的 AI 分析做好准备。

整个使用流程被压缩到最简：

• 准备一个 Steamworks API Key（仓库中提供了申请方法）。API Key 可在 Steam 开发者页面免费申请，每个 Steam 账号可获得一个，Valve 对调用频率设有宽松的速率限制（一般为每秒数次请求），但保留对滥用行为进行封禁的权利。API Key 本质上是一个身份认证令牌，服务端通过它来追踪调用来源并实施配额管理，因此用户需妥善保管，避免泄露后被他人盗用配额或关联到不当行为。
• 找到自己的 Steam64 用户 ID（同样有详细说明）。Steam64 ID（也称 SteamID64）是 Steam 平台用来唯一标识每位用户的 64 位整数编号，格式通常为 76561198XXXXXXXXX 这样的 17 位数字。Steam 实际上有多种 ID 格式——早期的 SteamID（如 STEAM_0:1:12345678）、SteamID3（如 [U:1:24691357]）以及 SteamID64——三者可以互相转换，但 Web API 统一使用 SteamID64 作为参数。用户可以通过 Steam 客户端的"账户详情"页面，或使用 steamid.io 等第三方查询工具获取。
• 将上述两项参数输入控制台程序

程序随后会遍历你账户中的所有游戏，最终在桌面生成一个 JSON 文件。整个项目基于 MIT 许可证开源，用户可以自由使用和二次开发，GitHub 地址为 github.com/TohnoCoding/SteamLibraryDataExporter。MIT 许可证是由麻省理工学院最早使用的一种开源软件许可协议，也是目前 GitHub 上最流行的开源许可证之一（据统计约占所有开源项目的 30% 以上）。它允许任何人免费使用、复制、修改、合并、发布、分发、再授权及出售软件副本，唯一要求是保留原始版权声明。相比 GPL 等 Copyleft 许可证，MIT 不要求衍生作品也必须开源，因此对商业使用和二次开发都极为友好。这也意味着有人可以基于此工具开发带有图形界面的增强版，或将其集成到更大的游戏管理套件中，而无需担心许可证兼容性问题。

导出的数据结构详解

从作者提供的真实样例来看，导出的字段设计相当务实，每款游戏都记录了以下信息：

• AppId / Name：游戏的应用 ID 与名称。AppId 是 Steam 为每款应用（游戏、软件、DLC）分配的唯一数字标识，可用于构建 Steam 商店页面链接（如 store.steampowered.com/app/AppId），也是跨系统引用游戏时最可靠的标识符。
• PlaytimeForever：总游玩时长（格式化为时:分:秒）
• PlaytimeLast2Weeks：最近两周游玩时长
• HasAchievements / TotalAchievements / ObtainedAchievements：成就系统相关数据
• AchievementPercentage：成就完成百分比
• LastPlayed：最后游玩时间（ISO 8601 时间戳）

其中 ISO 8601 是国际标准化组织制定的日期与时间表示法国际标准，最常见格式为 YYYY-MM-DDTHH:MM:SSZ，例如 2025-01-15T08:30:00Z。T 是日期与时间的分隔符，末尾的 Z 表示协调世界时（UTC）。这一标准的核心优势在于消除了不同国家和地区日期格式的歧义——比如 01/02/2025 在美国表示 1 月 2 日，在欧洲大部分国家却表示 2 月 1 日。在 API 设计和数据交换中，ISO 8601 已成为事实标准，便于程序解析和跨系统互操作。

以样例中的《1000xRESIST》为例，数据显示玩家总时长 20 小时 16 分，最近两周投入 11 小时 42 分，32 个成就全部解锁，完成度 100%。而对于未游玩的《Amerzone》，大部分字段则为 null，数据结构对"空值"处理得干净利落。在 JSON 规范中，null 是一个特殊的字面值，表示"无值"或"不适用"，这比使用空字符串或零值更具语义准确性——LLM 在解析时能明确区分"玩了 0 小时"与"从未启动过"这两种不同状态。

数据导出 + LLM：个性化游戏推荐的新范式

这个工具本身的技术含量并不高——本质上是对公开 Web API 的一层封装。但它真正有趣的地方，在于揭示了一种正在兴起的使用范式：将个人结构化数据导出，再交由大语言模型进行个性化分析与推荐。

传统的游戏推荐依赖平台算法（如 Steam 的探索队列），这些算法往往基于协同过滤和销量热度，难以捕捉玩家细腻的、语言化的偏好——比如"我想要偏叙事、不吃操作、有解谜元素的作品"。Steam 的探索队列（Discovery Queue）是 Valve 在 2014 年推出的个性化推荐功能，每次向用户展示约 12 款可能感兴趣的游戏。其推荐算法综合考虑用户的游玩历史、愿望单、好友行为、标签偏好以及游戏的全局热度和好评率。2019 年 Valve 引入了基于机器学习的"交互式推荐器"（Interactive Recommender），利用神经网络对用户-游戏交互矩阵进行建模。尽管如此，社区普遍反映该系统仍存在"过滤气泡"问题——一旦你购买了几款某类型游戏，推荐列表会被同质化内容淹没，难以发现跨类型的潜在佳作。

协同过滤（Collaborative Filtering）是推荐系统中最经典的算法范式之一，其核心思想是"和你行为相似的人喜欢的东西，你也可能喜欢"。它分为两大类：基于用户的协同过滤寻找与目标用户行为模式相似的"邻居用户"，再将邻居用户喜欢但目标用户未接触过的物品推荐出来；基于物品的协同过滤则计算物品之间的相似度，推荐与用户已喜欢物品相似的其他物品。这类算法依赖群体行为统计，难以理解个人用自然语言表达的细腻偏好，也容易陷入"热门偏见"——过度推荐已有大量用户数据的热门游戏，而忽略符合用户口味的冷门独立佳作。此外，协同过滤还面临"冷启动"问题：对于新用户或新游戏，由于缺乏足够的交互数据，系统几乎无法给出有意义的推荐。

而当玩家把自己的游玩历史（时长、成就完成度、最近活跃度）转化为结构化 JSON 后，配合自然语言描述的口味说明，LLM 就能进行更贴近人类思维的语义推荐。LLM 进行推荐时实际上利用了 prompt engineering 和 in-context learning 能力。用户将结构化游戏数据和自然语言偏好描述一起放入提示词（prompt），模型基于其训练语料中积累的游戏知识——包括 PCGamer、IGN、Metacritic 等媒体评测，Reddit 和 Steam 社区讨论，游戏 Wiki 等——进行语义匹配和推理。这种方法本质上是将推荐问题转化为文本理解与生成任务，用户还可以通过多轮对话不断细化偏好，实现传统推荐系统难以做到的交互式探索。

大语言模型的推荐能力与传统推荐系统在本质上属于不同范式：传统推荐系统将用户和物品映射为数值向量，通过余弦相似度等数学方法寻找匹配；而 LLM 能够解析"我想要一款节奏舒缓、不需要快速反应、但有深度世界观的游戏"这样的复杂语义需求，并将其与训练语料中积累的海量游戏评测、社区讨论、官方描述信息进行匹配。这意味着 LLM 可以处理传统推荐系统无法编码的"软性偏好"。当然它也有局限：LLM 的推荐基于训练数据的截止时间，对新发售的游戏可能缺乏了解，且无法像协同过滤那样实时捕捉群体行为趋势。不过，随着 RAG（检索增强生成）技术的发展，用户可以将最新的游戏数据库作为外部知识源接入 LLM，在一定程度上缓解知识时效性问题。

换句话说，作者用这个小工具搭建了一座桥梁：把"我玩过什么、玩了多久、完成得如何"的客观数据，与"我喜欢什么、擅长什么、想要什么"的主观表达打通，让 AI 成为一个真正懂你的私人游戏顾问。

各数据字段的推荐价值

仔细看导出的字段，你会发现它们对 AI 推荐颇有讲究：

• 总时长反映了投入深度，长时长游戏往往代表真正的兴趣所在。在游戏行业数据分析中，玩家的中位游玩时长通常远低于通关时长——据 HowLongToBeat 统计，大多数游戏只有不到 30% 的购买者会玩到结局。因此，当某款游戏的总时长显著高于同类平均值时，这是一个极强的正面信号。
• 成就完成度能区分"浅尝辄止"与"深度通关"，100% 完成度是强烈的偏好信号。成就系统（Achievement System）最早由微软在 2005 年随 Xbox 360 引入主流，Steam 于 2007 年跟进。成就设计通常分为"流程成就"（正常通关即可获得）和"挑战成就"（需要额外努力），完成度高的玩家往往对该游戏的机制和世界有更深入的参与。
• 最后游玩时间则揭示了近期的兴趣走向。如果一款标记为"最近两周活跃"的游戏与历史高时长游戏属于不同类型，可能意味着玩家的口味正在发生迁移，LLM 应当在推荐中适当侧重这一新方向。

这些维度组合起来，足以让 AI 勾勒出一份相当立体的玩家画像，从而给出比平台算法更精准的个性化游戏推荐。值得注意的是，这种结构化数据 + 自然语言提示的组合方式，实际上也可以用于向 LLM 说明"反面偏好"——例如指出某些高时长但成就完成度低的游戏可能是"沉没成本式游玩"而非真正喜爱，从而帮助模型更准确地理解数据背后的真实意图。

小工具背后的启示：AI时代的个人数据应用

这款工具虽小，却折射出 AI 时代个人数据应用的一个重要趋势：越来越多用户开始主动导出、整理自己散落在各平台的数据，作为"投喂"给 LLM 的原料。无论是 Steam 游戏库、阅读记录、听歌历史还是运动数据，只要能结构化导出，就能成为个性化 AI 服务的输入。这种趋势实际上与欧盟《通用数据保护条例》（GDPR）中规定的"数据可携带权"（Right to Data Portability）不谋而合——用户有权以结构化、机器可读的格式获取自己的个人数据，并将其传输给其他服务提供者。虽然 Steam 并非因 GDPR 才开放 API，但这种"用户拥有并主动利用自己数据"的理念正在成为主流。类似的趋势还体现在 Spotify 的年度回顾数据导出、Apple Health 的 XML 导出、甚至 ChatGPT 自身提供的对话历史导出功能上。

从更宏观的视角看，这种"个人数据 + LLM"的模式正在催生一个新的应用层——有人将其称为"个人 AI 助理基础设施"。用户不再被动等待平台推送内容，而是主动收集、整合自己的数字足迹，构建专属的上下文知识库，再借助通用 LLM 的推理能力获取高度个性化的服务。这与 Web3 社区倡导的"数据主权"理念异曲同工，但落地路径远比区块链方案来得务实——一个开源脚本加一次 API 调用，就能完成从"平台锁定"到"数据自由"的转变。

当然也需要留意，此类工具依赖账户资料公开与 API Key，涉及一定的隐私考量。将 Steam 资料设为公开意味着任何知道你 Steam64 ID 的人都能查看你的游戏库和游玩数据；而 API Key 一旦泄露，他人可以以你的身份调用 API。好在这类微工具通常在本地运行、开源透明，数据流向可控——本工具的 MIT 协议与桌面本地导出设计，正体现了"数据留在自己手中"的思路。用户在使用完毕后也可以随时将资料改回私密状态，最大限度降低暴露窗口。

对于饱受"选择困难"折磨的玩家而言，与其被平台算法牵着走，不如自己动手把数据导出来，让 AI 按你的真实喜好帮你挑选下一款游戏。这或许正是这个只有几十行代码的小工具，能引发广泛共鸣的原因。它证明了在 AI 时代，解决个人问题未必需要复杂的产品——有时候，一个精准的小脚本加上一次深思熟虑的 prompt，就能带来比任何商业推荐引擎都更贴心的体验。

核心要点

核心要点