AI 做桌面应用实操：Tauri 还是 Electron（2026）

用 AI 做网页、做小程序的教程已经满地都是，但「做一个能双击打开、带图标、能读本地文件的桌面软件」这件事，仍然让很多人卡在第一步。这篇讲的就是用 AI 做桌面应用的完整路线：先讲清 Tauri 2 和 Electron 在 2026 年的真实差距该怎么选，再回答那个最关键的问题——AI 写 Rust 到底靠不靠谱，最后把创建项目、接本地大模型、打包签名这些实际会卡住你的环节一个个走一遍。

什么需求值得做成桌面应用

先泼一盆冷水：大部分想法做成网页就够了，做成桌面应用只是给自己多加一道分发和签名的坎。真正非桌面端不可的需求其实很集中——要批量读写本地文件（批量改名、整理照片、扫描目录）、要长期驻留后台（剪贴板管家、定时任务、状态栏小工具）、要调用系统能力（全局快捷键、截图、监听键鼠）、要离线可用且数据不出本机（跑本地大模型、处理敏感资料）。

如果你的需求命中了上面任意一条，桌面应用就是对的选择；如果只是「做个工具给自己和同事用」，先做成网页，跑通再说。这个判断做错了，后面所有工作量都是白加的。

Tauri 2 还是 Electron：2026 年的真实差距

两者的技术路线区别只有一句话：Electron 把整个 Chromium 浏览器打包进你的应用，Tauri 直接用操作系统自带的 WebView（Windows 上是 WebView2，macOS 上是 WKWebView，Linux 上是 WebKitGTK）。这一个决定，导致了下面所有差异。

体积差距不是虚荣指标。同样一个工具，让用户下载 8 MB 还是 165 MB，转化率完全不是一个量级——尤其是国内很多人还在用移动网络下载。所以 2026 年的默认建议是：新项目先试 Tauri，除非你有明确必须用 Electron 的理由。

关键问题：AI 写 Rust 靠谱吗

这是选 Tauri 时最真实的顾虑。答案要分开看：在 Tauri 项目里，Rust 的用量比你想象的少得多。界面全是 HTML/CSS/JS（React、Vue、Svelte 随便选），Rust 只负责那些必须落到系统层的事——读写文件、调用系统 API、起后台进程。一个典型的中小型 Tauri 应用，Rust 代码可能只有两三百行，而且高度模板化。

更重要的是，Rust 恰好是 AI 最容易「自纠」的语言之一。Rust 编译器的报错信息在所有主流语言里数一数二地详细，经常直接告诉你该怎么改。AI 编程工具跑一次 cargo build，把编译器的建议吃进去，改，再跑——这个闭环通常两三轮就收敛。真正难倒 AI 的是复杂的生命周期和并发所有权设计，而这些在一个 Tauri 命令函数里基本不会出现。

从零到第一个窗口

Tauri 2 的环境准备比纯前端项目多一步：要装 Rust 工具链（1.77 以上），还要装各平台的系统依赖。Windows 10/11 自带 WebView2 一般不用管，macOS 要装 Xcode 命令行工具，Linux 要装 WebKitGTK 开发包。

# 1. 装 Rust（三平台通用，Windows 建议用官网 rustup-init.exe）
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
rustc --version   # 确认 >= 1.77

# 2. 系统依赖
# macOS:
xcode-select --install
# Ubuntu/Debian:
sudo apt install libwebkit2gtk-4.1-dev libgtk-3-dev
# Windows: Win10+ 自带 WebView2，通常无需额外操作

# 3. 创建项目（会交互式问你选前端框架和包管理器）
npm create tauri-app@latest

# 4. 跑起来
cd 你的项目名
npm install
npm run tauri dev

第一次 npm run tauri dev 会编译整个 Rust 依赖树，慢是正常的，通常要几分钟；之后的增量编译就快了。跑通之后你会看到一个真正的原生窗口——到这一步，环境就没问题了，剩下的可以全部交给 AI。

让 AI 接手：怎么描述需求

桌面应用最容易让 AI 跑偏的地方是前后端边界：哪些逻辑放前端 JS、哪些必须落到 Rust 侧。在提示词里把这条界线画清楚，返工会少一大半。下面这段模板可以直接改用：

这是一个 Tauri 2 项目，前端用 [React + TypeScript]。
我要做的功能：[选一个文件夹，扫描里面所有图片，
按拍摄日期批量重命名，界面上显示进度和结果]

请遵守这个分工：
- 所有涉及文件系统、系统 API、长耗时处理的逻辑写在 Rust 侧，
  做成 #[tauri::command]，前端用 invoke 调用。
- 界面、状态、交互全部在前端，不要在 Rust 里拼 HTML。
- 需要用到的 Tauri 插件（dialog、fs 等）请一并配好权限，
  Tauri 2 的能力需要在 capabilities 里显式声明，别漏。

工作方式：
1. 先只做「选文件夹 + 列出文件名」这一条最小链路，跑通给我看。
2. 我确认后再加重命名逻辑，最后加进度条和错误处理。
3. 每改完一轮自己跑 npm run tauri dev 确认能编译、能启动，
   编译报错自己改，不要把报错抛给我。

特别提醒 Tauri 2 的权限模型：它不像 Tauri 1 那样一个 allowlist 配到底，而是改成了 capabilities（能力）声明，插件的每个 API 都要显式授权。这是 AI 最容易出错的地方——它可能沿用 Tauri 1 的写法，代码看着对但运行时报权限错误。提示词里点名「Tauri 2 的 capabilities」能显著减少这类问题。

把大模型塞进桌面应用

桌面应用相对网页最大的独占优势，就是能跑本地大模型——数据完全不出本机，没有 API 费用，断网也能用。两条常见做法：

1. 1接本机 Ollama：让用户自己装 Ollama，你的应用去调它的本地接口（默认 http://localhost:11434）。最省事，你不用打包模型，但用户要多装一个软件。
2. 2打成 sidecar：Tauri 支持把外部可执行文件作为 sidecar 一起打包，由 Rust 侧管理它的启动、通信和退出。推理引擎、Python 脚本都可以这么塞进去。体验一体化，代价是安装包会大很多，而且每个平台都要准备对应的二进制。

做个人工具或团队内部工具，走第一条；做要分发给普通用户的产品，才值得为第二条付出复杂度。还有第三种最省事的：应用只做界面和本地数据处理，模型调用走云端 API（DeepSeek、GLM 这类国产模型很便宜），涉及隐私的部分留在本地处理——大多数产品其实是这个形态。

打包与签名：这一步最花钱

代码写完只是一半。桌面应用要给别人用，就绕不开代码签名——没签名的应用在 Windows 上会弹「SmartScreen 已阻止启动」，在 macOS 上直接提示「已损坏，无法打开」，普通用户看到这个 99% 会直接删掉。

打包命令本身很简单——npm run tauri build 会在 src-tauri/target/release/bundle 下生成对应平台的安装包（Windows 的 .msi/.exe、macOS 的 .dmg、Linux 的 .deb/.AppImage）。但注意：交叉编译在桌面端很不好用，想出三个平台的包，基本得在三个平台上各打一次，或者用 GitHub Actions 的多平台 runner 自动打。

桌面应用是检验「AI 编程能力」的一块好试金石：它同时要求你处理前端、系统层、打包分发三条线，任何一条断了产品就交付不出去。而这恰恰是大多数人用 AI 做东西时的真实卡点——不是写不出代码，是走不完从想法到能给别人用的最后一公里。IMAI 的实战课程就是围绕这条完整链路设计的，从选型、实现到上线交付，每一步都给你可复制的方法。