我如何以 FastAPI 和 Electron 建構 AI 檔案重新命名工具 RenomeeAI，以及為何不選 Tauri

I had a folder with 2,000 files named things like IMG_8842.jpg, document(3).pdf, and Screenshot 2026-08-02 145321.png. I knew exactly what was in each one — the day I saved them. Two weeks later, I had no idea.

Writing regex felt like overkill. Manual renaming was out of the question. So I built RenomeeAI: an AI-powered desktop app that reads what's inside a file — its text, metadata, even EXIF data — and generates a meaningful filename based on what you tell it you need.

Here's what I chose to build it with, and why.

The Problem I Was Solving

Most file renaming tools work on existing filenames. They let you find-and-replace, add prefixes, or reformat dates — but only from information already in the name.

The real problem is different: the useful information is inside the file.

• A screenshot of a payment failure contains an order number and error code — but the filename is just a timestamp.
• A downloaded PDF report has a title and publisher on page one — but the filename is document.pdf.
• A photo taken on a trip has GPS coordinates and camera settings in its EXIF data — but the filename is IMG_8842.jpg.

Traditional batch renaming tools can't help here. You'd need to open each file, read it, extract the relevant info, and rename it manually. That's exactly the slow, repetitive work AI is good at replacing.

What I needed was a tool that could:

1. Read the content or metadata of a file
2. Understand what the user actually wants from a simple description
3. Generate a clean, searchable filename — not a template, but a real decision

Why a Desktop App (Not a Web App)?

My first instinct was to build a web app. It's faster to ship, easier to share, and works on any device.

But three things pushed me toward a desktop app:

Privacy. Users are renaming real files — invoices, legal documents, personal photos. Uploading them to a server, even temporarily, felt like a non-starter. A local app processes everything on-device.

File system access. The browser's File System Access API has real limitations: no recursive folder traversal, no write access outside user-selected directories, no background processing. Electron gives you full fs access with no restrictions.

Native UX. Drag-and-drop from the file explorer, right-click context menus, system tray, file associations — these make a file utility feel like a real tool, not a workaround.

Architecture Overview

The app is split into two layers:

[ Electron UI (React) ]
        ↕  HTTP (localhost)
[ FastAPI Backend (Python) ]
        ↕
[ LLM API ]   [ OCR Engine ]   [ File System ]

Electron handles the UI, file picker dialogs, and local system integration. It communicates with the backend over a local HTTP connection on a fixed port — simple, debuggable, and decoupled.

FastAPI handles everything AI-related: OCR, EXIF extraction, LLM calls, and the actual file rename operations. Python was the natural choice here — the AI/ML ecosystem lives in Python, and keeping all the smart logic in one place makes it easier to reason about.

The two layers are intentionally independent. You could swap the Electron frontend for a CLI or a web UI without touching the backend.

Why FastAPI for the Backend?

I considered Flask and a Node.js backend. Here's why I landed on FastAPI:

The async support matters more than it might seem. LLM API calls can take 2–10 seconds. If you're processing a batch of 50 files, you want those calls running concurrently, not queued. FastAPI's async/await model handles this cleanly without extra libraries.

Pydantic models also made request validation effortless — when Electron sends a rename request with file paths and user intent, FastAPI validates and parses it automatically.

Why Electron (Not Tauri, Not PyQt)?

This is the question I get most often, so let me be direct.

Electron vs. Tauri

Tauri is excellent for apps where Rust can do the heavy lifting. For an AI tool with a Python backend, the story gets complicated:

• Tauri's backend is Rust. My AI logic is Python. Bridging them means running a Python subprocess and managing IPC between Rust and Python — two layers of complexity instead of one.
• Electron's Node.js layer can spawn a Python process with child_process in a few lines, communicate over localhost HTTP, and shut it down cleanly on exit. It's boring in the best way.
• Yes, Electron bundles Chromium and ships a larger binary (~120MB vs ~10MB for Tauri). For a productivity tool where users install once and use daily, that's an acceptable tradeoff.

Electron vs. PyQt / Tkinter

I considered keeping everything in Python with PyQt, but ruled it out quickly:

• Web component libraries (React, shadcn/ui, Tailwind) give far more UI flexibility than Qt widgets.
• The frontend can be worked on independently by someone who doesn't know Python.
• Hot reload during development is significantly better with Vite + React than with PyQt.

Why Not Pure Electron (No Python)?

Node.js doesn't have mature, production-ready libraries for local OCR and LLM integration that match Python's ecosystem. The moment you need pytesseract, pdf2image, or direct Volcengine SDK calls, Python becomes the obvious choice.

The AI Layer: From Raw Data to Meaningful Names

This is the part that makes the app actually useful — and it's simpler conceptually than it sounds.

When a user selects files to rename, each file arrives at the AI layer with three types of raw data:

• OCR output — text extracted from images or PDFs (what's visually on the page)
• File metadata — original filename, size, modification date, directory path
• EXIF data — for photos: camera model, capture time, GPS coordinates, aperture

On its own, this data is noisy and unstructured. The user's natural language input is the missing piece. When someone says "rename these invoices by supplier name and date" or "keep only the paper title and year", they're providing the selection criteria that transforms raw data into a specific filename.

The AI's job is to bridge these two sides: take heterogeneous file data on one end, take a plain-language intent on the other, and produce a clean, targeted filename. No regex. No template syntax. Just a description of what you want.

The AI doesn't rename files — it converts messy, heterogeneous data into the filename the user already had in mind but couldn't express as a rule.

This is the fundamental shift from traditional renaming tools. Instead of asking "what rule should I apply?", the user asks "what do I want these files to be called?" — and the answer is just a sentence.

Try It / What's Next

RenomeeAI is available for macOS and Windows. If you're dealing with folders full of screenshots, downloaded PDFs, or unorganized photos, it's worth a look.

👉 renomeeai.com (replace with real URL)

The next major feature on the roadmap is Google Drive integration — renaming files directly in the cloud without downloading them first. After that, deeper EXIF-based workflows for photographers.

If you've built something similar — or have strong opinions about Electron vs. Tauri for Python-heavy apps — I'd love to hear your take in the comments.