Flow Files：我用 AI 做了一款自己的 Windows 文件管理器
最开始，我只是想验证一个问题：如果要做一款内存占用不高、界面又足够自由的 Windows 文件管理器，Tauri、Avalonia 和纯 Rust GUI 到底应该怎么选？
后来这个用于比较技术路线的小 Demo，一点点变成了现在的 Flow Files。
项目已经公开在 GitHub：
当前版本是 0.1.0。它已经能完成日常文件浏览与管理，但仍处于早期阶段，我暂时不建议用它完全替代 Windows 资源管理器。
为什么最后选择 Tauri
我最在意的不是“理论上最低能占多少内存”，而是三件事能不能同时成立：
- 空闲和多标签使用时，内存占用保持在可以接受的范围；
- 界面可以自由调整，能做出简洁、紧凑的浏览体验；
- 我不会亲自写大量底层代码时，AI 仍然能稳定开发、调试和维护。
Avalonia 的原生渲染和 C# 工程体验很有吸引力，Slint 也有更轻量的潜力。但对这个项目来说，React 的组件生态、界面调整效率和 AI 可维护性更重要。最终我保留了 Avalonia 对照原型，把主线放在 Tauri 2 + React + TypeScript + Rust 上。
这里的 Rust 并不是为了“所有代码都用 Rust 重写”。界面与交互仍然由 React 负责，Rust 主要承担文件系统、Windows 集成和需要原生能力的部分。两套代码的边界清楚之后，维护成本没有想象中那么高。
它现在能做什么
Flow Files 已经不只是一个会列出文件名的壳。目前主要能力包括：
- 多标签目录浏览、标签拖动排序、前进后退和地址栏导航；
- 详细信息、紧凑列表和大图标视图，以及排序、列宽调整和虚拟滚动；
- 图片缩略图和高清预览，文本、代码、音频、视频与常见元数据预览；
- 新建、重命名、复制、剪切、粘贴、拖放、压缩、解压、回收站和永久删除；
- 与 Windows 文件剪贴板互通，目录变化后自动刷新；
- 收藏夹分组、文件夹树、最近位置、搜索历史和会话恢复；
- 文件任务进度、暂停、取消、失败重试，以及有界的撤销与最近操作记录；
- 磁盘空间体检、安全清理预览、重复文件扫描和清理前复核；
- 在当前目录打开 Windows Terminal 或 Claude Code。
这些能力不是一次设计完成的。很多细节来自真实使用时暴露的问题：小窗口里菜单被截断、预览区遮挡、列表穿过底栏、跨文件夹拖放失败、标签无法排序、外部变化不能及时同步……每发现一个问题，就把它变成一个可以复现和验证的改动。
最难的不是“把功能写出来”
文件管理器看起来只是“展示一堆文件”，实际却非常考验边界处理。
一个复制操作会遇到重名、权限不足、文件占用、磁盘空间不足和网络中断；一个右键菜单要考虑空白区域、单选、多选、文件和文件夹；一个预览面板还要在不同窗口高度下保持可用，不能让播放器控件或按钮被裁掉。
我越来越明确地感受到：成熟软件与原型的差别，不在于首页看起来多漂亮，而在于这些不显眼的边界是否都被认真处理。
所以后期的主要工作已经从“继续加按钮”变成：
- 让危险操作先预览、再选择、最后确认；
- 让长任务有进度、可暂停、可取消，失败后能定位到具体项目；
- 让界面在小窗口和大量文件场景下仍然可操作；
- 让设置、历史和缓存有边界，不会无限积累；
- 让每一轮优化进入 README、CHANGELOG、ROADMAP 和 Git 历史，而不是反复做同一件事。
关于内存占用
Tauri 依赖 Windows WebView2，因此它不会像最小化的原生 GUI 那样把基础内存压到极限。任务管理器里还需要把宿主进程和 WebView2 子进程合起来看，不能只盯着单个进程。
但实际比较后，我接受了这部分成本。它换来的不是“更快写出一个页面”这么简单，而是更成熟的界面生态、更高的 AI 开发成功率，以及之后持续改交互时更低的沟通和维护成本。
对我而言，几十 MB 的差异值得重视，但不能脱离可维护性单独决定技术路线。
为什么现在公开
这个项目的大部分演进，都是我描述问题、AI 实现和验证、我再根据实际使用反馈继续调整。把仓库公开，一方面是为了让版本与开发过程真正可追踪，另一方面也希望它能成为一个参考：不会编程的人，如何通过持续提出具体问题，把一个原型慢慢推向可用软件。
仓库中保留了早期 Avalonia 对照原型、Tauri 主应用、内存测量记录、版本日志和路线图。现在最需要继续完善的是正式安装与覆盖升级、自动更新，以及网络位置和断开设备的恢复体验。
Flow Files 还没有完成，但它已经从“试一试”走到了“我真的会拿来管理文件”。这也是我决定给它建立正式版本、发布 v0.1.0 并公开源码的原因。