常年在主机上折腾游戏的人多少都有过这种状态库里攒了一百多个游戏真正通关的没几个明明记得某个存档还在真到要找的时候却翻遍外接硬盘也找不到想清理空间又怕把不该删的删了。我最近一直在做一个小工具名字就叫 AnyPS5专门用来收拾这些零碎的本地数据。它不做任何超纲的事不碰主机系统限制功能更不碰账号安全设置就是一个老老实实的本地数据管家把游戏库、存档状态、截图录像、游玩时长汇总成一份能看得懂的报告顺便告诉我哪些游戏早该被清理了。如果你也喜欢给游戏数据做整理或者想用代码管好自己的主机资料这篇内容应该对你有用。1. AnyPS5 到底解决什么问题从游戏库失控说起1.1 三个让我想动手写工具的场景说起来有点丢人真正让我下决心写 AnyPS5 的不是某个宏大的技术目标而是三个特别琐碎的场景。第一幕发生在一次大扫除式的换硬盘之前。当时主机内置空间只剩下不到一百G外接固态也快满了我打算删一批游戏腾位置但打开游戏库一看几百个条目密密麻麻根本分不清哪个是玩过不想再碰哪个是下次还想继续更分不清哪个存档文件对应哪个游戏。我一度以为某个经典RPG的存档丢了结果后来发现是当初把存档文件复制到U盘时因为同名冲突被系统自动改名了真正的内容还在。第二幕是关于游玩记录。我特别想知道自己一年到底在哪些游戏上花了多少时间但主机的统计界面只给个概览想按月份、按类型、按通关状态拉一张明细表基本没法做。每次想回顾一下只能靠记忆而记忆在这种事上非常不可靠。第三幕是截图和录像。我的外接盘里躺着几千张截图和几百段录像文件命名千奇百怪有的按关卡有的按日期有的干脆是一串乱码。想做一期个人年度回顾视频光整理素材就花了整个周末。这三个场景凑到一起结论就出来了我需要一个能把这些数据统一纳管、清洗、汇总、展示的小工具。市面上的方案要么只覆盖其中一小块要么要把数据上传到云端我实在不想为了看个统计就把自己的游戏轨迹交给别人。1.2 为什么现成的方案都不够顺手我也不是没试过现成方案大概可以分成三类。第一类是主机自带的统计功能。它的问题在于颗粒度太粗只能看个总数而且一旦游戏被删除历史时长记录可能跟着丢失无法回溯。第二类是各种第三方统计网页和App它们大多依赖公开的个人资料页面数据有限不说有些功能还需要把账号信息授权出去安全性我一直不放心。第三类是纯手工的Excel表格我坚持用过一阵子但人总有犯懒的时候一个月后表格就停更了最后还是扔在一边。AnyPS5 的思路和它们都不一样所有数据只存本地界面是一个本地生成、本地打开的HTML报告任何需要账号权限的信息都不碰只使用那些本来就公开可见的基础资料以及我自己导出的文件信息。它本质上是一个离线数据库加自动化整理器不追求实时同步只追求在需要的时候能拿得出可靠结果。1.3 AnyPS5 的定位本地优先、不越界的数据管家这里我想把边界说清楚。AnyPS5 完全不涉及主机系统的任何受限功能不引导用户做任何可能影响账号安全或设备保修的操作。它做的事情说白了就是三件把游戏库里每个游戏的基础信息汇总成一张清单把外接存储里的截图、录像、存档文件按规则归档成可检索的目录根据游玩时长、上次启动时间、通关状态和安装体积生成一份哪些游戏可以腾地方的清理建议。这个定位决定了它的实现方式很朴素。不需要多高深的技术但恰恰因为数据源五花八门、格式不统一真正难的是数据清洗和对应关系的建立。这一点我们在下一节详细展开。2. 数据从哪来又怎么洗AnyPS5 的数据链路2.1 三路数据来源与各自的脾气AnyPS5 的数据来源主要有三路每一路的格式和可靠性都不一样这也是整个项目里最需要打磨的部分。第一路是公开的个人游戏列表。通过主机账号的个人资料页可以获取到公开可见的游戏记录、奖杯进度这类基础信息。但这一路数据有明显的滞后性玩过的游戏有时候不会立刻反映出来需要手动触发同步。我当时为了做月度统计给这一路设计了一个采样抓取加本地合并的机制每次抓取都是增量更新抓到后先落盘再和本地已有的记录做并集绝不覆盖本地存量数据。第二路是外接存储里的文件信息。截图、录像、存档导出后文件本身带时间戳和部分命名信息。这一路最可靠毕竟是真实的文件但问题在于命名格式混乱尤其是不同批次导出时系统会沿用同样的前缀加递增编号导致重名非常容易出现归档错误。我在项目里专门写了一套重命名规则后面第四节会细说。第三路是人工补充信息。物理版游戏的购买日期、通关状态、个人评分这类数据接口里拿不到必须手工录入。为了让录入不要太痛苦我给 AnyPS5 做了一个简单的命令行交互每次只需要回答三个问题这游戏你现在还想接着玩吗通关了没有如果给个1到5的分数你会打几分每次添加游戏时顺手答一下几乎不花时间但积累下来就是一份非常有价值的个人数据库。2.2 游戏记录的归一化合并三路数据汇合之后第一件事就是归一化。所谓归一化就是把同一个游戏在不同来源里的不同写法合并成唯一一条记录。举个例子某个游戏在商店页面叫某开放世界冒险,在个人资料页叫某开放世界冒险(完整版)在存档文件夹里又是另一个内部代号。如果不做归一化同一个游戏会被统计成三条记录时长被拆散通关状态还会互相打架。我在 AnyPS5 里处理这个问题的方式是三层匹配第一层是精确ID匹配。每个游戏都有平台内部编号这个是唯一且稳定的能匹配上就直接认定是同一款游戏。第二层是标题清理匹配把豪华版完全版终极版这类后缀去掉之后再比对。第三层是人工确认池前两层都匹配不上的进一个待确认列表由我手动标记一次之后所有来源的记录都挂到同一个ID下面。匹配完成之后每条记录会带上一份标准化字段游戏ID、标题、区域、类型、安装体积、游玩时长、上次启动日期、通关状态、个人评分、关联存档路径。有了这张主表后面所有统计模块都只需要读这一张表不用再去翻原始数据。这一步是我在整个项目里收益最大的一笔投资后面每天打开报告都觉得干净。2.3 时区、语言与重复记录的三个暗坑有人说数据清洗有什么难的不就是改改格式吗。实际做起来光时区这一个问题就够折腾的。文件导出的时间戳用的可能是本地时间游戏资料的更新记录用的又是另一个时区如果直接把字符串塞进报告统计出来的本月游玩趋势可能偏差好几个小时。我的做法是在入库那一刻统一转成标准时间戳存储所有展示层再做本地时区转换。代码里绝不拿字符串比大小一律先转成时间对象。语言问题则是多语言合并。游戏在港服、日服、欧美服标题可能是繁体中文、日文、英文。我在标题清理之外额外维护了一个多语言别名表每次抓取资料时把不同区域看到的标题都登记进别名表里之后无论哪个来源出现都能命中同一条记录。这个表是我自己全手工维护的量不大但效果极好。重复记录则来源于增量更新。如果某次抓取任务中断重跑时就可能把同样的数据再插一遍。为了避免重复我在数据库层对关键字段建了唯一约束插入使用存在即忽略、不存在才新增的逻辑而不是先查一遍再插。这样即使脚本因为网络波动重试几十次也不会产生脏数据。def upsert_record(conn, record): cur conn.cursor() cur.execute( INSERT OR IGNORE INTO games (game_id, title, region, last_play_ts, play_minutes) VALUES (?, ?, ?, ?, ?), (record[game_id], record[title], record[region], record[last_play_ts], record[play_minutes]) ) conn.commit()这段代码是整个数据管线的核心习惯宁可让同一批数据被重复执行也绝对不允许入库时产生重复。3. 核心模块设计与实现细节3.1 游玩时长与进度统计模块时长统计是 AnyPS5 最早完成的功能也是我使用频率最高的功能。它读取主表中的游玩时长字段按照三种维度做聚合按游戏聚合、按月份聚合、按通关状态聚合。按游戏聚合很简单SUM 一下就是总时长。按月份聚合稍微需要点技巧因为一条游戏记录里只有累计时长和上次启动时间缺少逐次游玩明细没法精确还原某个月的时长。我的处理是做一个近似估算把累计时长的变化量分摊到两次采样之间的时间线上再按月加权。这个方法不精确但胜在稳定足够回答这个月我到底玩没玩、大概玩了多久这类问题。通关状态聚合则依赖人工录入的通关标记。我给每个游戏维护了四个状态未开始、进行中、已通关、已放弃。已通关的游戏单独拉出来会生成一份个人通关清单按通关日期排序。这个清单看起来简单但每次打开都有种莫名的成就感是我坚持录入的最大动力。3.2 空间清理建议模块这个模块解决的是开头说的那个痛点站在客厅里对着存储空间页面发呆不知道到底该删什么。AnyPS5 给每个游戏生成一条清理建议判断逻辑并不复杂如果上次启动时间超过 180 天、通关状态不是进行中且安装体积大于某个体积阈值就建议删除安装文件同时明确提示存档已安全备份不会被删除。下面是我在报告里实际使用的一张建议表字段和判断规则都来自真实验证游戏安装体积上次启动通关状态建议某赛车竞速类约 96G14 个月前已通关可删除安装文件某战略经营类约 60G3 天前进行中保留某老牌动作类约 85G都快三年了已放弃可删除安装文件某双人合作类约 120G5 个月前进行中保留但提示跟进这个模块的核心在于删除前先给承诺。每次生成建议脚本都会先执行一次存档备份检查确认该游戏的关键存档已存在于备份目录才允许这条建议出现。宁可漏掉一些可删项也不能给出任何可能让用户误删存档的糟糕建议。3.3 本地 HTML 仪表盘所有统计结果最终都会汇入一个本地生成的 HTML 报告。报告是一个单文件页面不依赖外部网络不加载任何远程资源所有图表数据都以 JSON 形式内嵌在文件里。这样做的好处是隐私性极强整个报告就是一份可以双击打开的文件断网也能看发给朋友也不会泄露任何账号信息。报告里包含几个区块顶部是总量卡片显示游戏总数、总时长、本月游玩时长、可释放空间估算中间是游玩趋势图按月展示时长变化下面是游戏清单表支持按状态筛选和排序。图表我用的是纯前端图表库没有引入重型框架生成时直接渲染成静态图形所以文件体积很小打开速度极快。生成流程是典型的数据到模板模式先用脚本从数据库里聚合所有统计数据再把结果填充到一套 HTML 模板里最后输出成一个带时间戳的报告文件。为了避免无限堆积我只保留最近十份报告旧报告自动清理每次生成完都会顺手把当前这份重命名为最新报告。3.4 数据库结构与更新流程AnyPS5 的存储用的是一个本地轻量数据库结构非常克制。主表只有四张games游戏基础信息和统计数据game_aliases多语言标题别名表media_files截图、录像、存档文件的归档目录update_log抓取任务的执行日志。四张表之间的关系也很简单核心就是一个游戏ID贯穿所有表。更新流程则是先拉数据、再入库、最后出报告三步走第一步拉取公开资料和扫描外接盘文件第二步做归一化和增量入库第三步重新生成报告。整个流程我用一个脚本串联平时想更新一行命令跑完三分钟之内就能拿到新鲜报告。数据库文件的备份是我一直很看重的事。它记录了我所有游戏的轨迹属于不可再生数据所以我设置了每次报告生成后自动复制一份当日备份保留最近三十天的滚动存档。这个习惯初期觉得多余但有一次我在改脚本时不小心清了库靠备份十分钟就满血复活了。4. 实做中被我改了又改的五件事AnyPS5 从第一版跑通到现在中间踩了不少坑。这里挑五个印象最深的每一个都是改了至少两版才稳定的。4.1 请求太勤被限制限速策略的调整第一个坑来自抓取逻辑。最早的版本为了追求数据完整抓取任务全速跑结果跑不到一半个人资料的访问就被平台暂时限制了连续几个小时恢复不了。那一次让我意识到任何公开数据抓取都必须把频率当成一等公民来设计。修复方案是彻底限速每两个请求之间强制等待至少 1.5 秒单批次最多抓取两百条记录批次之间休息五分钟。这样一次完整抓取虽然会慢一些但胜在稳定再也没出过访问被限制的情况。我也把时间段选在清晨避开高峰进一步降低风险。这也是一个重要的原则问题对公开来源做低频率、小批量的更新既符合常规使用规范也不会给平台带来负担。4.2 多语言标题导致的合并错乱第二个坑发生在归一化匹配上。早期版本只做后缀清理结果某游戏在繁体区域和英文区域被识别成两条记录时长数据被拆得七零八落。我当时花了整整一个晚上人工核对才把一堆错乱记录掰回来。修复手段就是前面提到的多语言别名表。从那以后所有来源标题在入库前都会先查别名表命中就挂到正确游戏ID下。这个表刚建时只有十几条记录后面的任何一个新增游戏只要发现疑似未匹配就会自动进入待确认池我定期批量处理一次。整个过程不需要写死任何规则靠积累跑赢规则这也是我在项目里学到的最实在的一条经验。4.3 截图录像导出重名文件归档命名方案第三个坑来自外接盘的截图和录像。系统导出时的文件名通常都是同一个前缀加数字编号跨批次导出就会重名。我一度在整理年度回顾素材时发现某段视频被另一段同名文件悄悄覆盖了难受程度不亚于丢存档。后来我写了一套归档命名规则文件入库时按照游戏ID_日期_原始编号的格式重命名日期取文件的标准时间戳游戏ID来自人工关联标记。整理过的文件统一移入按游戏分层的目录结构。这套规则虽然简单但彻底解决了重名问题而且让文件检索变得非常快。以后想找某年某月的截图直接按目录和文件名过滤就行。4.4 存档恢复时的版本兼容判断第四个坑和存档备份恢复有关。我的习惯是定期把关键存档复制到外接盘但有时候游戏更新了大版本旧存档直接恢复进去系统会提示不兼容。最早我根本不区分这些直到有一次恢复经典游戏的存档才发现光看文件名和修改时间根本判断不了版本。现在 AnyPS5 会给存档记录额外维护三个字段版本号、存档时间、通关百分比。恢复前先做一次三字段比对版本号不同就明确提示可能不兼容建议先升级到新版本再恢复版本相同但通关百分比差异很大的情况也会弹出一句确认提示防止误覆盖新进度。这套逻辑不复杂但非常救命。4.5 磁盘占用估算偏差下载体积不等于安装体积第五个坑是空间清理建议里的体积估算。早期的报告直接用商店页面标注的体积来做清理测算结果某游戏标注的下载体积才 90G装完实际占了 120G多出来的部分是后续补丁和扩展内容。按标注体积算出来的可释放空间出现过十万级的误差差得离谱。修复方案是改用实际安装目录扫描出来的体积累积计算每次扫描外接盘时记录每个游戏目录的真实大小定期刷新。这样报告里的清理建议才真正和主机存储空间对上号。这个改动也让整个项目的数据可信度上了一个台阶因为用户最关心的就是删了之后到底能腾出多少哪怕差 10G体验都会变得不靠谱。5. 从 AnyPS5 延伸出去整理数据能带来的玩法工具做出来之后我发现它带来的不只是能查表这么简单。数据一旦沉淀下来很多玩法会自然而然长出来。5.1 周报与游玩习惯分析我后来给 AnyPS5 加了一个周报功能每周一早上自动生成一份上周游玩摘要玩了多少小时、集中在哪些游戏、哪个时间段上线最多。你可能会问主机已经有类似统计了这有什么特别。区别在于 AnyPS5 的周报会和年度数据放在一起能看到这周相比去年同期是多了还是少了最近一个月是不是对某类游戏明显偏心这类趋势性问题。虽然只是近似估算但足够用来做个人时间管理的复盘。5.2 加硬盘前的数据预演另一个很实用的场景是加硬盘前的预演。很多人纠结要不要扩容犹豫的根源是不知道自己现有数据到底占多大空间。我把 AnyPS5 的数据导出一份体积分布报告一眼就能看出来哪些游戏撑死了也不会再玩、哪些是绝对舍不得删的、哪些删了又得重新下载反而更麻烦。根据这个报告决定硬盘容量比凭感觉猜准确得多。有一次我就是靠着这份分布表挑了一个刚好够用的容量省下了一笔不必要的开支。5.3 多账号数据合并对比如果你家里有不止一个账号在玩同一台主机AnyPS5 也支持把多个账号的公开资料合并进同一份报告按账号维度做对比。我和朋友某开发者在模拟项目里做过一次验证用两台不同主机的数据合并之后报告能清楚展示两台机器的游玩场景差异——一台偏单机剧情一台全是联机合作类。这种对比在规划要不要再买一台主机的时候是非常直观的数据支撑。5.4 我刻意不做的事最后想说说我刻意不去做的事。AnyPS5 从一开始就明确不碰任何涉及系统修改、固件降级、绕过验证的方向。原因很简单这类操作风险极高一旦出问题轻则丢数据重则影响设备正常使用完全不值得。我见过一些方案为了炫技引导用户把系统改得乱七八糟最后游戏都进不去还得花钱修复。AnyPS5 的定位是在合法、常规的范围内管好自己的数据这个边界我建议你也守住。6. 如果你也想做一个自己的版本我的几点建议如果你也想给自己做一套类似 AnyPS5 的整理工具我有几个实操层面的建议都是被坑换来的。第一先做导出和扫描再想统计和界面。很多人一上来就想做酷炫仪表盘结果数据源还没理清楚统计出来的全是垃圾。先把几路数据摸透哪怕最初只在命令行里打表也比一张错得离谱的大屏强得多。第二所有入库存量都走增量且可重放的逻辑。宁可每次更新多跑几遍也绝不允许重复记录。这个习惯能省掉你后面无数的清洗时间。第三把备份当成功能而不是习惯。脚本能自动备份就自动备份人肉备份早晚会有一天忘掉而那一天往往是数据最需要恢复的一天。第四给每一个建议类功能都加上保护性判断。比如清理建议必须验证存档备份存在后才允许出现宁可少给建议也不能给出一个让人后悔的建议。工具的价值不在于功能多而在于每一次输出都靠得住。AnyPS5 到目前为止仍然是我自己在用的小项目代码谈不上优雅但它确确实实解决了我最痛的那些问题存档不再莫名其妙消失年度回顾素材可以几分钟整理完存储空间心里有数每一份报告都是我自己游戏轨迹的真实档案。如果你也想做类似的东西我的建议是从最小的场景开始先盯住一个你最痛的点比如只整理截图或者只做时长统计跑通之后再逐步加模块。这样的工具做出来的过程本身就是一种乐趣你会比我更懂怎么把它改造成适合自己习惯的样子。