Alb：从 Web 项目经验迁移到 Android 相册

Alb 是我目前正在做的 Android 原生相册整理项目。

它不是为了再做一个普通看图应用。它真正想解决的是长期整理问题：照片和视频已经散在系统相册里，但系统相册通常不适合做多层分类，也不适合长期维护一个个人化的整理结构。

产品方向

Alb 的核心是分类整理层。

它通过 MediaStore 读取系统可见的照片和视频，用 Room 保存分类、标签、封面、排除目录和设置这些元数据。全部照片、待整理、整理库、标签和查重结果，都是围绕同一批媒体文件展开的不同视图。

对我来说，最重要的一点是不重复存储照片。整理动作优先表现为本地元数据里的分类映射，而不是复制一份媒体文件。这个方向也和隐私空间场景有关。在类似 OriginOS 隐私空间这类环境里，文件移动和跨空间访问会受到系统限制，所以 Alb 更适合先把“分类关系”做好。

当前功能

项目已经打通了几条主链路。

时间流和相册视图接入真实媒体库。整理库支持多层分类。待整理用于查看还没有进入 Alb 分类体系的媒体。查看器支持图片、视频、分类、标签、收藏、删除和信息查看。工具页包含查重、备份恢复、权限检查等入口。

查重是这个项目的重要能力。精确查重通过文件特征找完全重复内容，相似查重则面向画面接近的图片。它和分类整理结合在一起，能在长期整理前先清掉重复项。

参考项目与工作流

Alb 不是闭门从零写出来的。

开发过程中，我要求搜索工具查找成熟相册项目和相关资料，再决定哪些地方应该借鉴。Aves 更适合参考系统集成、元数据和 MediaStore 边界。Fossify Gallery、Simple Gallery 更适合参考查看器、文件夹卡片、底部操作和视频播放。LeafPic 年代较旧，只适合少量兜底思路。

这件事对我很重要。它让我不再把 vibecoding 理解成“让 AI 独立脑补一切”。更合理的方式，是先做资料检索和参考分析，再让 AI 在已有成熟方案的约束下实现。

Alb 也是我把 Codex、Gemini CLI、Trellis、Aegis 和轻量澄清流程组合起来的项目。它证明这套方法不只适用于 Web，也可以迁移到 Android 原生应用。

参考材料：

• 项目 README
• docs/PRODUCT_DIRECTION.md
• docs/REFERENCE_BORROWING_ANALYSIS.md
• docs/REFERENCE_ADOPTION_PLAN.md
• docs/GEMINI_CLI_WORKFLOW.md