一个外行用AI写了个照片整理工具

一个外行用AI写了个照片整理工具，还想把它搬上安卓

照片越攒越多，找一张图的时间，有时比拍它还长。

手机相册里几万张照片混在一起，导出到电脑后更是一场灾难——微信缓存、相机原图、截图、短视频全挤在一个文件夹里，文件名从 IMG_2024 到 Screenshot_2025 毫无规律。想按时间整理？手动拖文件夹拖到怀疑人生。

有人选择忍受，有人选择写个工具。

今天要推荐的 MediaOrganizer，就是一个"自己动手解决照片混乱"的产物。它的作者不是专业开发者，而是一个去年才从零开始学编程的外行——用 AI 辅助写代码，从 Python 写到 C#，从工作小工具写到第一个公开项目。

这个项目刚在 GitHub 发布初版，桌面端已经可以日常使用，安卓端还在调试的坑里挣扎。但正是这种"半成品"的真实感，让它比那些完美的商业软件更值得一聊。

01 从"工作工具"到第一个公开项目

作者的编程之路，起点非常务实。

去年开始，他从纯零基础外行学用 AI 辅助编程——也就是现在常说的"vibe coding"。最早写的东西都和工作相关：自动填写数据表的脚本、给实验用信号源做的上位机。这些工具解决的是自己的问题，没什么公开价值，写完就用，用完就放着。

语言选择上也经历了一次转向。一开始学的是 Python，毕竟入门门槛低、教程多。但写着写着，他换到了编译型语言 C#。原因很实际：个人开发者用得多、轮子（第三方库）丰富、生态成熟。对一个要做桌面应用的人来说，编译型语言的速度确实比解释型语言更好。

这个转变很关键。Python 适合快速验证想法，但如果目标是一个有界面、要分发、要跨平台的桌面工具，C# + .NET 是更稳的选择。

02 一个 Python 脚本，启发了一个 C# 重构

项目的直接起因，是别人群里分享的一个 Python 版照片整理器。

那个脚本的逻辑不复杂：扫描文件夹里的照片，从 EXIF 信息或文件名里提取拍摄日期，然后按年月日建文件夹，把照片归类放进去。但它有两个局限：只支持本地目录，而且是 Python 工具，启动速度、扫描遍历速度有些差。

作者决定用 C# 重做一个，并且加了一个很多人需要的能力——网络位置作为目标文件夹。具体支持两种协议：SMB（Windows 共享文件夹，常见于 NAS）和 WebDAV（很多网盘和 NAS 都支持）。

这意味着整理后的照片可以直接归档到 NAS 或网盘，不用先整理到本地再手动上传。对照片量大的人来说，这一步省了不少事。

核心功能一句话就能说清：从照片信息或命名规则读取时间，按年月日分文件夹归类迁移。

但真正做起来，细节比想象中多。

从杂乱到有序，中间是一条多级日期提取链。

03 MediaOrganizer 到底能做什么

打开软件，流程很清晰：选源目录、选输出目录、扫描分析、确认计划、执行归档。但每一步背后都有设计考量。

多级日期提取链。不是所有照片都有完整的 EXIF 信息。微信发过来的图被压缩过，截图没有拍摄时间，有些老照片的元数据早就丢了。MediaOrganizer 用了一条加权提取链：先读 EXIF，再匹配文件名规则，最后用文件系统时间兜底。每一级都可以调节权重和开关，尽量减少"识别不出日期"的失败率。

分析和执行分离。扫描完不会立刻动你的文件，而是先生成一份归档计划：哪些文件要移到哪里、哪些识别失败、哪些会重名冲突。你确认后才执行。这一点对整理珍贵照片来说很重要——谁也不想看到软件一顿操作后发现分类错了。

同名文件处理。不同设备拍的照片可能撞文件名。可以选跳过、覆盖，或者自动重命名。

本地和网络双目标。输出目录可以是本地文件夹，也可以是 SMB 共享或 WebDAV 地址。账号密码加密存储在配置里。

失败文件和"待处理文件夹"。识别不出日期的文件不会被静默忽略，而是列出来让你手动处理。还有一个"魔术工具"，用来生成和测试文件名的正则规则——对付那些命名奇葩的照片集特别有用。

技术栈方面，项目用的是 .NET 10 + Avalonia 12，MVVM 架构。核心逻辑（Core）和 UI 完全解耦，桌面端和未来的安卓端共享同一套业务代码。图片 EXIF 用 Magick.NET 读取，视频元数据用 TagLib#。

整个项目结构分层干净：Core 管扫描、分析、归档逻辑；Shared 放共享的 ViewModel；Desktop 是桌面界面；Android 是安卓端骨架。对一个个人项目来说，这个架构意识相当不错。

04 安卓的坑，还没踩完

作者选 Avalonia 12 的原因很明确：为了跨平台。

Avalonia 是 .NET 生态里的跨平台 UI 框架，一套代码可以跑 Windows、macOS、Linux，也能打包安卓和 iOS。对想做安卓版又不想重写一套界面的人来说，这是最自然的选择。

安卓部分的代码已经写好了——工程骨架搭起来了，Core 和 Shared 层复用，应用冷启动、清单合并、主题这些基础链路也打通了。但调试不成功。

这是个人开发跨平台应用时最常见的卡点：桌面端跑得好好的，一到移动端就冒出各种平台特有的问题——权限、文件访问路径、生命周期、AOT 编译限制。README 里很诚实地把安卓端标注为"长远任务"，明确说"当前阶段以桌面端为重心，安卓端仅处于早期探索与架构验证阶段，不纳入近期发布目标"。

这种坦诚比画饼靠谱得多。

很多个人项目的 README 喜欢把"即将支持"写得像马上就来，但实际可能永远停留在 TODO。MediaOrganizer 没有回避安卓还没跑通这件事，而是把它定位成长期演进方向，先把桌面端做稳。

写在最后

MediaOrganizer 不是什么革命性的软件。照片整理工具市面上有不少，付费的、免费的、开源的都有。

但它的价值不在于"又一个照片整理器"，而在于它代表了一种越来越常见的创作模式：一个普通人，用 AI 辅助编程，把自己遇到的问题变成一个公开可用的工具。

从填写数据表的脚本，到信号源上位机，再到这个有界面、有架构、有网络协议支持的桌面应用，作者的成长路径清晰可见。他没有等"学完再做"，而是遇到问题就动手，做不好就换语言，做不完就诚实标注。

如果你也有一堆乱成麻的照片需要整理，或者对 C# + Avalonia 跨平台开发感兴趣，可以去 GitHub 看看这个项目。初版刚发布，桌面端已经能用，安卓端还在路上——也许你的一个 issue 或 PR，能帮它把最后那段路走完。

项目地址：https://github.com/self-exiler/MediaOrganizer

封面图

一个外行的 AI 编程实践，从混乱到有序。

内容验真

项目信息：MediaOrganizer 项目地址为 https://github.com/self-exiler/MediaOrganizer ，README 显示初版发布于 2026 年 8 月 16 日，代码 100% 为 C#。功能描述、技术栈、项目结构、平台定位均基于该仓库 README 原文。

开发者背景：学习编程时间、语言选择（Python 转 C#）、前期项目（数据表填写、信号源上位机）、项目起因（群内分享的 Python 版照片整理器）、安卓调试状态等信息来源于用户提供的开发背景描述，未做额外虚构。

功能事实：多级日期提取链（EXIF / 文件名 / 文件系统时间）、SMB 与 WebDAV 网络目标、分析与执行分离、同名文件处理、失败文件列表、魔术工具、配置管理等功能均来自 README"功能概览"与"主要组件说明"章节。

技术栈：.NET 10、Avalonia 12、CommunityToolkit.Mvvm、Magick.NET、TagLib#、WebDAVClient 均来自 README"技术栈"章节。

安卓状态：README 明确将安卓端定位为"长远任务"，说明"已搭建工程骨架并打通基础启动链路，但距离可用产品仍远"，与用户描述的"安卓部分代码写好了，调试不成功"一致。

图片来源：头图、文中功能示意图、封面图均为 AI 生成图片，非真实软件截图或现场照片。

边界说明：本文未实际运行该软件，功能体验描述基于 README 文档，不构成对软件实际表现的承诺。

|(Note: May contain AI-generated content.)