AnyPS5这个名字是某天晚上我从沙发上爬起来对着那排越堆越高的游戏碟盒随口起的。Any PS5直译过来就是随便一台 PS5 上的任何游戏——因为我当时面临的问题很简单游戏库已经多到让我选择困难而真正想玩的却总是那两三个。如果你也有几十上百款游戏躺在库里却每天打开商店翻来翻去最后默默退出那这个项目的思路或许对你有参考价值。AnyPS5 本质上是一个部署在你自己电脑上的私人游戏库管理工具帮玩家把实体盘、数字版、会员游戏、试玩版归拢到同一套数据库里然后用标签、状态、进度日志和随机推荐解决今天玩什么和上次玩到哪这两个最实际的问题。它最适合两类人一类是库存量大、追求掌控感的收集型玩家另一类是像我这样做不了复杂社交评分、只想要一个安静后台记录自己游戏旅程的单机玩家。整个项目从零搭起来只需要一个能跑 Python 的环境不依赖任何云端服务数据完全归你所有。下面的内容会分成几个部分展开先说为什么会有这个项目再拆解核心功能然后是技术选型逻辑和完整复现过程最后分享开发半年里踩过的坑和一些反思。你可以把它当成一个如果我自己做会怎么做的完整思路。1. 从游戏太多到AnyPS5这个项目的起点1.1 游戏库失控时的真实体验很多人以为库大是富余其实库大带来的是一种低强度的焦虑。我的游戏主要来自四个渠道实体光盘、数字商店、会员赠送和定期更新的试玩版。每个渠道一个入口每个入口一套查找逻辑甚至每个入口的拥有状态都不一样——有的买了没下载有的下好了没打开有的打开过一次然后永远躺在内容库列表里。我一度把想玩的游戏记在手机备忘录里结果备忘录本身也变成了一个新的库里面的条目和实际库存对不上越记越乱。真正的问题不是没有游戏玩而是我没有一个属于自己的、统一的视角来看我的游戏。商店首页的推荐算法是给所有玩家看的它不知道我玩到一半的某个作品、不知道我明确说过这个月不想碰恐怖游戏、更不知道我其实很想回去把某个老游戏重新捡起来。AnyPS5 就是为了补上这个视角而出现的。它不试图替代商店也不试图给游戏打分排名只做一件很朴素的事把我有什么游戏和我玩到哪了变成我自己维护的一组数据。1.2 为什么不做现成的App偏要自己写市面上其实有不少游戏管理类应用移动端和网页端都有功能看起来眼花缭乱。但它们解决的问题和我解决的问题不太一样。一般来说这些应用默认了三个前提玩家有社交需求想和朋友对比收藏玩家有成就收集需求想看奖杯和全成就进度玩家愿意把数据托管到云端服务上。这三个前提我都不太符合。单纯想记录的话开一个 Excel 表格也能做不必写一个项目。自己做的理由不是技术炫技而是想要一个规则完全由我定义的后台我可以随手加一个字段记录这游戏是哪个朋友送的也可以临时把某个游戏打上等 DLC 出了再玩的标签这不需要向任何人申请功能。还有一个很现实的原因是隐私。把整个游戏库、游玩日志、个人评价交给第三方服务等于把生活习惯的一部分托管给了别人。就算服务条款写得很清楚我也总会担心有一天平台改版、数据导出困难或者干脆关停。自己写的工具没有这些风险数据库就是一个文件想备份就复制一份想迁移就拷走任何时候都掌控在自己手里。1.3 AnyPS5 的核心定位本地、私人、无社交压力所以在设计初期我给 AnyPS5 划了几条明确的边界不碰成就、奖杯和任何排行体系游戏库里只有我自己的记录不自动抓取商店库存所有条目以我认为我有为准数据只存在本地 SQLite 文件里没有任何账号和云端依赖游戏状态由我自己手动更新系统只提供辅助不做判断这几条边界看起来好像限制了工具的能力实际上它们保住了 AnyPS5 的核心理念去掉应该玩什么的外部压力。很多管理工具做的好看但用起来像在上班打卡因为你总觉得有指标要完成。AnyPS5 恰恰相反它的目标只有一个——让玩家在选择游戏的瞬间更轻松而不是让管理游戏本身变成新的负担。有了这个定位后面的功能设计和技术选型就有了参照物很多纠结的决策都变得简单了。2. 核心功能拆解陪伴型游戏管理器的边界2.1 入库实体、数字、试玩、会员的归一化游戏库管理的第一步是入库。但如果入库这一步就需要填十几个字段那这个工具大概率会在用了一周后被你遗忘。我的原则是最少字段完成入库额外信息全部可选。AnyPS5 的核心入库字段只有五个游戏名称、平台、来源、发行年份、备注。这里的来源用统一枚举区分来源类型含义示例场景physical实体光盘二手店淘来的碟、首发限定版digital数字商店购买日常打折购入trial试玩版/序章官方 Demo、试玩 Weekendmembership会员赠送/会免订阅服务每月入库other其他朋友借放的碟、媒体送测码归一化处理的重点在于无论这个游戏是怎么到我手里的它在系统里都只是一条库存记录后续的标签、进度、推荐逻辑不会因为来源不同而产生差异。这样做的直接好处是我可以一次性筛选出所有会员来源里还没玩过的动作类游戏而不需要在不同入口之间来回切换。来源字段本质上是一个筛选维度而不是身份证明这一点对后续体验影响很大。2.2 进度追踪记录状态和心情而不只是时长传统游戏统计工具特别喜欢记录游玩小时数对很多人来说这确实有吸引力但它也有副作用——一旦开始记录精确时长你就会不自觉地产生这周玩得不够多的焦虑记录行为本身会从乐趣变成 KPI。AnyPS5 的进度追踪刻意弱化了这个方向。每一条游戏记录只有四类状态unplayed未开始playing进行中paused搁置了但以后可能回来finished / dropped封盘或放弃每次想更新进度只需要追加一条日志包含三个信息本次游玩的大致时长段30分钟以内、1-3小时、一个下午这样的档位、当下的印象分1-5分、一句随便写的备注。备注可以是卡在第三关 boss 心态崩了也可以是结局演出很棒缓一缓。这些内容不会出现在任何排行榜上它们只是给未来的自己看的。日志采用追加模式不覆盖过去所以你可以完整地看到一款游戏从第一天的惊艳到第二周的有点腻是怎么变化的。状态字段反而可以通过最新一条日志自动推导出来不需要手动维护。这套设计让记录动作保持在十几秒以内是我能坚持使用半年的重要原因。2.3 标签、状态、愿望单让系统替你分类标签是游戏库管理的第二层分类。和固定字段不同标签允许你随心情创建不需要任何审批。我自己的常用标签大概是这样题材开放世界、肉鸽、恐怖、节奏短流程、长线、适合碎片时间、情绪治愈、压抑、爽快偶尔还会有和某位朋友联机冲刺白金这样的临时标签。AnyPS5 给标签设计了一个简单规则标签可以多对多可以随时改但不做自动标签推导。市面上很多工具试图通过 AI 识别游戏类型并自动打标看起来很智能但结果经常不准反而要花时间纠正。手动打标签虽然慢但每次打标签本身就是一次思考——你会回忆起这个游戏带给你的感觉这反而加深了对库的掌控感。愿望单是独立于游戏库的一张表。它记录的不是已经拥有的游戏而是未来可能会买的候选者。任何游戏库管理工具都容易让人陷入一个误区只管理已有的东西却不管理自己想要的东西。愿望单补上了这一环配合下面的点名功能形成了一个完整的决策链愿望单里看到感兴趣的 → 有折扣时买下 → 入库 → 玩完后打标签 → 根据体验回头修改愿望单里的偏好。2.4 点名功能随机推荐和一局制今天玩什么是 AnyPS5 里使用频率最高的功能我把这个功能叫作点名。它的逻辑非常简单系统从符合筛选条件的游戏里随机挑选几个显示在首页。第一次实现时我只做了随机挑一个游戏但实际用起来效果并不好——随机挑出来的游戏经常不符合当下的环境比如周末下午挑出一个半小时流程的恐怖游戏或者睡前挑出一个容易上头的长线作品。后来我加入了两个参数一个是时间环境分为睡前、碎片、周末大块三种另一个是不接受标签可以临时排除不想碰的类型。点名时系统先按条件过滤候选集再从里面随机选出三个玩家只需要在这三个里挑一个或者一个都不要再次点名。这其实就是所谓的一局制思路不要给用户一个无限列表那等于把所有选择压力又还给了玩家。三个选项、一个重来按钮是最小可行的推荐交互。我没有引入复杂的推荐算法因为对一个数百条记录的个人库来说随机 简单过滤已经能让选择体验发生质变。3. 技术选型为什么是 FastAPI SQLite 轻前端3.1 为什么不用一套重型后端AnyPS5 的服务对象非常明确单个人、单台机器、低并发、跑在一台可能已经用了七八年的旧笔记本上。这意味着很多在企业级项目里理所当然的选择在这里反而是负担。比如引入 Docker虽然部署更干净但一个本地小工具还要维护镜像和容器明显过度设计。再比如用 PostgreSQL功能强大但 SQLite 对单用户场景绰绰有余而且不需要安装服务。选型的时候我给自己定了一个原则能少一个依赖就少一个依赖新增的任何组件必须能直接回答它减少了维护成本还是增加了维护成本这个问题。最终的技术栈收敛到三层Python 3.10 FastAPI 作为后端SQLite 作为数据库前端只有一个原生 HTML 页面配上少量 JavaScript。整个项目没有构建步骤没有打包流程没有环境编排文件对长期维护来说这是最大的优点。3.2 FastAPI 和其他选择对比做这个项目时我其实比较过几个后端方案结果很直白方案优势不适合的点Flask轻量老牌资料多请求参数验证需要手写写多了容易乱FastAPI类型提示 Pydantic 校验 自动 OpenAPI 文档对资深 Python 开发者来说有些概念要适应Node.js/Express前端同语言性能好还要引入 TS 或维护回调风格心智负担不小纯 Python 脚本 CLI最简单没有可视化界面筛选和日志体验差很多FastAPI 赢在两个关键点。第一是它的请求校验基于类型注解写一个函数签名就像给接口定义了契约参数错误会直接返回清晰提示这帮我省掉了大量手写 if-else。第二是它自带交互式 API 文档开发过程中我经常直接在浏览器里调试接口不需要额外的测试工具。虽然正式使用中没人会打开这个文档页但开发期它真的帮我节省了很多时间。3.3 数据模型设计三张表和一个推荐视图AnyPS5 的数据库结构非常克制核心只有三张表。下面是我最终定下来的表结构。games 表游戏库主表字段类型说明idINTEGER PRIMARY KEY自增主键titleTEXT NOT NULL游戏名称platformTEXT NOT NULLPS5 / PS4 / 其他sourceTEXT NOT NULL来源枚举yearINTEGER发行年份可空noteTEXT备注created_atTEXT入库时间logs 表进度日志表字段类型说明idINTEGER PRIMARY KEY自增主键game_idINTEGER关联 games.idlogged_atTEXT记录时间play_segmentTEXT时长档位short/medium/longmood_scoreINTEGER印象分 1-5noteTEXT自由备注tags 表配合 game_tags 关联表实现多对多标签字段类型说明idINTEGER PRIMARY KEY标签主键nameTEXT UNIQUE标签名不区分大小写game_idINTEGER也可以通过关联表实现多对多设计时我有意没有把游戏状态放进 games 表。因为状态如果放主表每次更新日志都要附带改一次状态字段很容易出现数据不一致。最终方案是状态永远从最新一条日志推导。虽然有轻微计算成本但对单用户几百条数据来说完全可以忽略收益是永远不存在日志说在玩但状态是未开始这种矛盾。推荐不需要单独建表它只是一条带条件过滤的查库逻辑我在代码里用几个筛选函数组合实现后面会展开讲。3.4 SQLite 在个人工具中的适用边界SQLite 是个经常被低估的数据库它甚至不是一个独立服务只是一个 C 语言库。对 AnyPS5 这种规模的项目来说它的表现堪称完美单文件存储备份就是复制 .db 文件不需要导出导入工具支持事务批量导入时能保证要么全成功要么全回滚读并发能力足够个人工具不太可能出现写冲突不需要额外安装Python 标准库自带 sqlite3当然它也有边界。如果未来做成多人协作、每秒钟几十次写入的服务SQLite 就不合适了。但 AnyPS5 的定位就是单用户本地工具我就没在这个问题上纠结。唯一做的一个优化是开启 WALWrite-Ahead Logging模式这样即使某次异常退出数据库也不容易损坏启动时恢复速度也更快。4. 从零复现 AnyPS5 的完整过程4.1 初始化项目结构这个项目的目录结构特别简单五个文件就撑起了整个工具anyps5/ ├── app.py # FastAPI 应用接口都在这 ├── db.py # 数据库连接和初始化逻辑 ├── import_data.py # 从 JSON / CSV 批量导入游戏 ├── static/ │ └── index.html # 前端单页 ├── data/ │ ├── games.json # 原始数据可导出备份 │ └── anyps5.db # SQLite 数据库文件 └── requirements.txt # 依赖清单requirements.txt 内容fastapi uvicorn[standard] pydantic这四个依赖足够了。运行方式一条命令uvicorn app:app --host 127.0.0.1 --port 8000。默认只监听本机地址外部设备访问不到这也是安全上的一个有意设计——本地工具不需要暴露到局域网。4.2 建库语句和初始化逻辑db.py 里的初始化逻辑很直接检查数据目录是否存在不存在则创建一个再执行建表语句用CREATE TABLE IF NOT EXISTS保证多次启动不会报错。下面是核心 SQLCREATE TABLE IF NOT EXISTS games ( id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL, platform TEXT NOT NULL DEFAULT PS5, source TEXT NOT NULL DEFAULT other, year INTEGER, note TEXT, created_at TEXT NOT NULL DEFAULT (datetime(now)) ); CREATE TABLE IF NOT EXISTS logs ( id INTEGER PRIMARY KEY AUTOINCREMENT, game_id INTEGER NOT NULL REFERENCES games(id), logged_at TEXT NOT NULL DEFAULT (datetime(now)), play_segment TEXT CHECK(play_segment IN (short,medium,long)), mood_score INTEGER CHECK(mood_score BETWEEN 1 AND 5), note TEXT ); CREATE TABLE IF NOT EXISTS tags ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL UNIQUE ); CREATE TABLE IF NOT EXISTS game_tags ( game_id INTEGER NOT NULL REFERENCES games(id), tag_id INTEGER NOT NULL REFERENCES tags(id), PRIMARY KEY (game_id, tag_id) );sqlite3 模块的Row访问方式需要设置一下否则查出来的数据是元组操作起来不方便。这个问题很多 Python 新手踩过坑conn.row_factory sqlite3.Row4.3 批量导入从 CSV / JSON 到入库我从旧 Excel 表格迁移数据时第一次尝试写了一个逐条插入的脚本500 条游戏跑了接近三秒体感很慢。后来用了executemany和事务耗时降到 0.2 秒以内。这里把两个方案都放出来你一看就明白差异。慢速版for item in data: cursor.execute( INSERT INTO games (title, platform, source, year, note) VALUES (?, ?, ?, ?, ?), (item[title], item.get(platform, PS5), item[source], item.get(year), item.get(note, )) ) conn.commit()批量版rows [ (item[title], item.get(platform, PS5), item[source], item.get(year), item.get(note, )) for item in data ] cursor.executemany( INSERT INTO games (title, platform, source, year, note) VALUES (?, ?, ?, ?, ?), rows ) conn.commit()导入脚本还需要处理两个事情去重和日期清洗。去重规则我用的是标题小写后去空格 平台作为唯一键同一个游戏既买了数字版又买了实体版不会被误判重复。日期清洗见后面的踩坑部分。4.4 核心接口的实现逻辑FastAPI 接口很简短我抽四个有代表性的说一下设计意图。新增游戏app.post(/api/games) def add_game(body: GameIn): with db.connect() as conn: cur conn.execute( INSERT INTO games (title, platform, source, year, note) VALUES (?, ?, ?, ?, ?), (body.title, body.platform, body.source, body.year, body.note) ) game_id cur.lastrowid return {id: game_id}这里用 Pydantic 的GameIn做请求体校验字段缺失或类型错误会自动返回 422不用自己写解析逻辑。追加日志app.post(/api/games/{game_id}/logs) def add_log(game_id: int, body: LogIn): with db.connect() as conn: conn.execute( INSERT INTO logs (game_id, logged_at, play_segment, mood_score, note) VALUES (?, ?, ?, ?, ?), (game_id, body.logged_at, body.play_segment, body.mood_score, body.note) ) return {ok: True}点名推荐app.get(/api/roll-call) def roll_call(env: str evening, exclude_tag: str None): with db.connect() as conn: sql SELECT g.* FROM games g WHERE NOT EXISTS ( SELECT 1 FROM logs l WHERE l.game_id g.id AND l.logged_at date(now, -3 days) ) rows conn.execute(sql).fetchall() # 再加环境/标签过滤随机取三个 candidates filter_by_env_and_tags(rows, env, exclude_tag) return random.sample(candidates, min(3, len(candidates)))点名逻辑里那个子查询的意思是最近三天内有过游玩记录的游戏不参加点名避免随机出来一个昨天刚玩过的东西。统计接口app.get(/api/stats) def stats(): counts {} for label, sql in [ (total, SELECT COUNT(*) FROM games), (playing, SELECT COUNT(*) FROM games WHERE id IN (SELECT game_id FROM logs GROUP BY game_id HAVING MAX(id) ...)), (wishlist, SELECT COUNT(*) FROM wishlist), ]: counts[label] db.query(sql).fetchone()[0] return counts4.5 前端一个小而美的单页前端我原本打算用 Vue 或者 React后来想到这个项目没有构建步骤引框架反而要维护 node_modules就放弃了。最终用原生 HTML CSS 一小段 fetch 逻辑整个页面压缩到几百行。页面布局就三块顶部是一个搜索框和一个新增游戏按钮中间是大卡片网格每张卡片显示游戏名、标签和最新进度状态右下角悬浮一个点名按钮这就是使用频率最高的那个功能。新增游戏用对话框表单字段和接口对应。保存成功后不刷新页面用location.reload()简单粗暴地重拉数据。这个方案没有任何性能问题因为数据量本来就小。用原生 JS 的好处是零构建、零依赖、零框架升级焦虑任何时候打开编辑器都能直接改。5. 开发过程中踩过的坑与教训5.1 发售日期的脏数据处理游戏发行年份是我最开始没当回事的字段结果它在导入时给了我最大的麻烦。旧表格里的年份五花八门有的写2019年4月有的写2019/04-style还有的直接填TBD未定----甚至出现过 1999 这种明显是 placeholder 的值。最初的代码只做了int(year)强转遇到脏数据直接抛异常整个导入中断在第三行。后来改成先清洗再入库存def clean_year(raw): if not raw: return None digits re.sub(r[^\d], , str(raw)) if len(digits) 4: return None year int(digits[:4]) if 1980 year 2035: return year return None规则很简单只取前四位纯数字范围限制在 1980-2035非法值返回NULL。年份字段允许为空比填一个错误值更好因为排序和筛选时错误值的破坏性比空值大得多。这个经验后来也用在了其他字段上。5.2 进度日志被覆盖从覆盖式到追加式早期版本的日志功能是一个编辑最近一条记录的设计界面上有个下拉框选择状态后直接 UPDATE 当前最新日志。这个设计表面上方便实际上有严重的 bug如果你昨天玩了某款游戏今天打开工具想记录新进度界面上展示的却是昨天的日志你只需要点一下保存就会不小心把昨天的记录改掉丢失真实数据。我实际遇到的情况是某天我想把一款游戏从进行中改成搁置顺手修改了那天的日志结果两天前的通关纪念记录被一起覆盖了。意识到问题后我把所有日志改成了纯追加模式不再支持编辑或删除历史日志每条日志独立保存时间戳游戏状态由最新一条日志推导出来这个改动牺牲了一点灵活性换来了数据一致性。在个人工具里不能改其实也是一种安心你永远不用担心自己的误操作毁掉过去记录。5.3 导入时的 N1 问题与批量优化前面提到批量导入从 3 秒优化到 0.2 秒本质是消除了逐条提交事务的开销。但这还不是最隐蔽的问题。第一次写导入时我还在循环里做了标签匹配每条游戏插入后都要查一次标签表查出关联标签再插入关系统——这就是典型的 N1 查询。对 500 条数据多出来的 500 次 SELECT 其实也能接受但对上千条数据的游戏库就会明显变慢。优化的办法是直接把标签表一次性加载到内存里做成一个name - id的字典导入过程中只查内存不再访问数据库。对于所有类似的本地工具这个思路都通用数据量小到能放内存的时候就不要反复访问磁盘。5.4 自动获取封面看上去很美实际是坑我一度想让 AnyPS5 自动下载游戏封面图这样卡片网格看起来会好看很多。当时试着调用了几个公开的游戏资料接口结果遇到一系列问题接口限速严格频繁请求会被临时封禁封面版权归发行方所有本地引用无所谓但批量抓取存储有合规风险更麻烦的是接口数据经常和本地命名对不上同一个游戏在不同地区的标题不同匹配准确率只有七八成。后来我彻底放弃了自动封面方案改成手动管理在data/covers/目录里放以游戏 ID 命名的图片文件前端检测到对应文件就显示没有就显示一个占位色块。这套方案虽然需要手动放图但绝对不会出错也不会有任何版权和限速问题。这让我意识到在个人项目里能跑且稳定永远比好看且炫酷重要。6. 用了半年后的反思和给后来者的建议6.1 哪些功能高频哪些是摆设AnyPS5 实际使用半年后我拉了一下自己的使用数据结果和起初的设想有些不一样。用得最频繁的是三个功能点名、快速追加日志、按标签筛选。特别是点名几乎每次坐到主机前都会按一次已经变成了一种仪式感。快速追加日志也符合预期十几秒完成记录意愿很高。真正成了摆设的是两个功能复杂统计报表和自动标签规则。先做出来的是一个包含周报、月报、游玩时长分布的仪表盘UI 很漂亮但我一次都没看过因为我根本不需要知道过去三十天我在动作类游戏里花了多少小时。自动标签规则设计得更复杂本想通过标题关键词自动打标签结果误判太多每次都要手动更正后来索性关掉。这两个教训让我深刻理解了高频入口越浅越好低频功能越深越好——统计不是没用而是不该放在首页第一屏。6.2 从AnyPS5到AnyGame的扩展方向半年后有一个朋友问能不能拿去管理他其他平台上的游戏甚至管理书影音。从数据模型看把platform字段放开再改一个名称确实可以变成通用的AnyGame。但我自己实际评估后没有立刻做多平台支持原因很简单多平台意味着每条记录要加更多字段来区分版本、区服、跨平台存档这会让入库表单变长拉低使用频率。如果真要做通用版我建议的分层思路是先把platform从固定值改成自由标签而不是在主表增加一堆平台相关字段。保持游戏的公共属性标题、年份、状态、日志在核心表里把平台差异丢给标签系统去承接。这个扩展方向在代码上几乎无成本但功能边界要守好——不要试图解决所有平台的所有特有问题否则就掉进了功能膨胀的坑。6.3 最后想说的话做 AnyPS5 这半年我最大的体会是工具的目标是服务于玩法而不是让玩法服务于工具。过去我把大量时间花在如何更精确地记录上后来发现真正有价值的是记录之后打开主机不再犹豫这个结果。如果你也想做一个类似的私人管理项目我的建议是先在备忘录或表格里手动维护两周验证自己是不是真的有这个需求再动手写代码。很多项目都是造轮子的冲动超过真实需求存档两周之后发现根本坚持不下来那就不值得投入更大成本。另外尽量克制功能范围你能想到的每个锦上添花的功能将来都会变成需要维护的代码。少做几个功能项目反而能活得更久。AnyPS5 现在依然跑在我的旧笔记本上数据文件只有几百 KB备份就是复制一个文件。它没有云同步没有社区分享没有任何外部依赖但每天打开主机前我会先按一下那个点名按钮——这就是这个项目存在的全部意义。
)
