非Rust开发者用AI造出Windows文件管理器，上架微软商店

一个产品经理，不会Rust，却用AI编程智能体做出了一款上架微软商店的Windows文件管理器。这个故事听起来像营销话术，但Dirwise的GitHub仓库、微软商店页面和作者的详细复盘，让它值得被认真对待。

一个产品人的“越界”实验

作者在项目介绍中直言，自己受够了Windows自带的文件资源管理器。他想要列视图、即时预览、标签页和命令面板，而且希望这一切发生在一个小巧、快速、不偷偷上传数据的应用里。于是Dirwise诞生了——一个免费、开源（MIT协议）、面向Windows 10/11的文件管理器。

技术栈是Tauri 2：Rust做后端，React做界面。安装包只有约2.5MB，没有遥测，唯一的网络行为是可选的每日一次GitHub API更新检查。这个体积和隐私姿态，在Electron应用动辄上百MB的当下，本身就是一种产品宣言。

关键在于，作者的身份是产品人，不是Rust开发者。几乎全部代码由AI编程智能体（Claude Code）完成。他负责的是设计功能、撰写规格、测试每个构建版本，以及决定什么能发布。这条分工线，比“AI写代码”本身更值得讨论。

Tauri 2 是一个用 Rust 构建桌面应用的开源框架，定位与 Electron 类似，但架构有本质区别。Electron 会把整个 Chromium 浏览器和 Node.js 运行时打包进应用，因此安装包轻松上百 MB；Tauri 则复用操作系统自带的 WebView（Windows 上是 WebView2，macOS 上是 WKWebView），只打包业务代码和 Rust 后端，所以能做到几 MB 的体积。代价是前端渲染依赖系统 WebView，不同平台之间可能出现细微差异，这也是后文 WebView2 拖放问题特别棘手的原因之一。Tauri 2 相比 1.x 最大的变化是正式支持移动端（iOS/Android）并重构了插件与权限系统，使后端能力可以按需授权，而非一股脑暴露给前端。

把AI当工程师，而不是许愿池

作者明确反对“给我建个文件管理器”这种一句话提示。他的原话是：那样得到的是演示，不是产品。真正有效的方法可以拆成五条。

按阶段拆分，而非一个巨型提示。 每个版本被切分成目标明确的小阶段：“带键盘导航的列视图”“标签页”“回收站”“商店发布”。每个阶段有独立的提示词和验收标准，也就是“完成”到底意味着什么。

用第二个对话做规划。 他保留一个专门用于思考的对话：写提示词、审阅智能体的报告、决定优先级。编码智能体拿到的是干净、具体的指令，而不是他意识流的碎碎念。这个做法把“想”和“做”在工具层面就隔离开了。

先看计划，再动代码。 几乎每条提示词都以“先给我看计划，我说OK之前不要提交”结尾。这些计划经常在代码写出来之前就拦下问题：一个隐私漏洞、一次构建失败、一个会误删文件的特性。

把规则写进文件。 仓库里有一份CLAUDE.md，列出智能体必须始终遵守的规则。有些规则是踩坑换来的，比如：永远不要碰真实回收站里不是本应用放进去的项目。

每个版本自己测试。 他安装、点击、试图弄坏它。AI很快，但AI不用这个应用。这句话点出了当前AI编程的核心短板：智能体缺乏对自己产出的真实使用体验。

CLAUDE.md 是 Claude Code 等 AI 编程智能体约定俗成的项目级指令文件，通常放在仓库根目录，智能体在每次会话开始时自动读取。它的作用类似于给新入职工程师看的团队规范：技术栈约定、代码风格、禁止事项、测试命令、目录结构说明都可以写进去。与每次提示词里重复叮嘱相比，把规则固化到文件里有三个好处：一是跨会话持久生效，二是可以随代码一起进版本控制、被审查和迭代，三是减少了提示词长度带来的上下文浪费。文中“永远不要碰真实回收站里不是本应用放进去的项目”这类规则，正是典型的“踩坑后写进合同”的用法，把一次性的纠正转化为长期约束。

那些AI也搞不定的硬骨头

如果这篇文章只讲成功，可信度会打折。作者列出的困难部分反而更有信息量。

WebView2与Windows其余部分之间的拖放是第一个难关。网页视图天然不讲Windows的拖放语言，这个问题反复了好几轮才解决。视频和PDF的快速缩略图是第二个：在大文件夹里不能卡住界面，这对渲染管线是实打实的考验。

权限处理体现了设计功力。往C:\Program Files里复制需要提权，但让整个应用以管理员身份运行是个坏主意。Dirwise调用Windows文件操作API，只让那一次操作请求权限。这种粒度控制，不是AI随机生成的，而是产品决策。

还有一个颇具讽刺意味的插曲：Windows 11的亚克力透明效果在他自己电脑上失效，查了半天，最后发现是某个桌面美化mod搞的鬼，不是代码问题。这一晚白熬了。

WebView2 是微软基于 Chromium 提供的嵌入式浏览器控件，Windows 11 已预装，也是 Tauri 在 Windows 上的渲染基础。它运行在一个相对隔离的进程里，网页内容与宿主窗口、操作系统之间隔着一层边界。拖放正是受这层边界影响最明显的交互：HTML5 的 drag-and-drop 事件模型与 Windows 的 OLE 拖放（IDropTarget 等 COM 接口）是两套语言，文件从资源管理器拖进 WebView2 时，需要宿主侧拦截系统消息再转译给网页层，方向反过来则更难。这也是为什么一个在浏览器里很普通的功能，在桌面混合应用中反而成为反复调试的硬骨头。

被微软商店拒绝两次，反而教会了产品课

应用最初叫Finder-Win。名字里的问题不难猜。

商店的拒绝理由有两条：名称包含另一家公司的产品名；应用看起来像是Mac上的东西——左上角的彩色窗口按钮。作者承认这很公平。1.6.0版本换了新名字Dirwise，改用带Snap Layouts的正规Windows 11窗口按钮，清理掉一切借用其他平台的视觉元素。第二次拒绝只是因为列表里留了一张旧图。第三次，通过。

他总结的教训很干脆：如果你被另一个平台启发，拿走想法，别拿走外观和名字。这条经验对所有做跨平台产品的团队都成立，与是否用AI无关。

Snap Layouts 是 Windows 11 引入的窗口贴靠增强功能：鼠标悬停在窗口最大化按钮上时，会弹出多种分屏布局供选择，用户可以把窗口快速吸附到屏幕的某个区域。它依赖应用使用标准的系统窗口边框（非客户区）绘制，一旦应用自绘标题栏或使用异形窗口按钮，悬停菜单就可能失效或错位。文中把“改用带 Snap Layouts 的正规 Windows 11 窗口按钮”作为通过商店审核的整改点，本质上不只是视觉风格问题，而是让应用重新接入操作系统级的窗口管理约定——这恰恰是跨平台移植时最容易被忽略、也最容易被平台方判定为“不像本平台应用”的地方。

给AI编程实践者的几条硬建议

作者的收尾建议可以浓缩为四点。做产品负责人，决定建什么、什么算“完成”——AI擅长回答“怎么做”，但“做什么”和“为什么”必须自己扛。让它展示工作过程：计划、测试结果、截图，信任但要验证。每一步保持小范围，小阶段意味着小错误。最后，坦诚公开：代码是公开的，README写明了它是怎么被造出来的，他宁愿接受诚实的代码审查，也不愿假装。

项目仓库里还挂着几个适合Hacktoberfest的入门任务：德语翻译、Rust单元测试和一些界面工作。作者特别欢迎真正的Rust开发者来做代码审查。

这个案例的价值不在于证明“AI能写代码”——那已经不需要证明了。它展示的是一条更现实的路径：一个懂产品但不懂系统编程的人，借助AI把交付能力向前推了一大步，同时把测试、决策和品味牢牢握在自己手里。Dirwise的安装包只有2.5MB，但它背后的协作模式，分量要重得多。