WeDrive 改名转存小云后，这个项目反而更清楚了
WeDrive 后来改名成了 转存小云。
这个改名一开始有点被动。微信小程序的名称有规则，很多名字不能直接用，英文名也不一定适合普通用户理解。可改完以后我反而觉得，这个项目被名字重新解释了一遍。
WeDrive 听起来像一个网盘品牌，甚至像要和 OneDrive、Google Drive 站在同一层。转存小云 就轻很多，也准确很多：它不是云盘，它只是把微信里的文件更顺手地转存到用户自己的 OneDrive。
这个差别很重要。
名字会影响产品边界
我一开始做 WeDrive 的时候，脑子里有很多文件管理功能。
浏览、上传、下载、移动、复制、重命名、搜索、分享链接、多账号切换、容量查看、上传任务队列。功能越列越多，最后它看起来确实像一个“小型 OneDrive 客户端”。
但如果把它叫成一个“Drive”，就很容易把产品边界拉大：
- 要不要支持更多云盘？
- 要不要做自己的账号体系？
- 要不要做文件预览？
- 要不要做更完整的分享、协作和权限？
- 要不要变成一个真正的网盘工具？
这些问题不是不能想，但它们会把一个小工具拖进完整产品的包袱里。
转存小云这个名字把问题收了回来。
它提醒我：这个工具最核心的价值，不是“管理所有文件”，而是解决一个更具体的动作：微信文件进 OneDrive 这一步太绕了。
真正的用户动作只有一个
我后来重新看这个项目，发现它的核心动作其实很简单：
1 | |
只要这条链路顺，其他功能都是辅助。
目录浏览是为了选位置。
多账号是为了区分个人盘和工作盘。
上传任务是为了知道有没有传完。
搜索和最近文件是为了补充文件管理体验。
分享链接、移动、复制这些能力有用，但不是第一优先级。
这也是小工具开发里很容易忽略的地方：功能越多，越容易忘记最初那个动作。
一个产品刚开始不需要证明自己能覆盖多少场景。它先要证明自己在一个场景里确实减少了麻烦。
微信小程序不是普通 Web 应用
转存小云踩过的很多坑，和微信小程序这个平台有关。
普通 Web 里，一个 OAuth 登录跳转、一个动态上传地址、一个文件流传输，都是常规问题。但到了微信小程序，就会多出很多平台约束：
- 个人主体小程序不能像普通 Web 一样顺滑使用
web-view授权； - 请求域名必须提前配置，OneDrive 上传会话的动态域名很难直接白名单；
- 文件选择依赖
wx.chooseMessageFile，后台网络和大文件稳定性要单独考虑； - 文件类产品涉及隐私和授权，说明必须更谨慎。
所以最后的方案并不是最优雅的方案，而是能在微信规则里跑通的方案。
前端只访问固定域名 wedrive.nmdft.cn，后端用 EdgeOne Pages Functions 处理授权、目录、上传和下载，再去访问 Microsoft Graph 和 OneDrive 临时地址。
这条链路有成本，尤其是上传和下载经过中转，会消耗 EdgeOne 流量。但它换来了一个好处：小程序端不用直接请求一堆动态域名。
很多工程决策就是这样。不是选“最漂亮”的方案，而是选“能过平台限制、能解释清楚、能继续迭代”的方案。
文件工具最怕状态不可信
做转存小云时，我越来越明显地感觉到：文件工具的信任门槛比普通小工具高。
用户可以容忍界面简单，可以容忍第一次授权麻烦一点，但很难容忍状态不可信。
比如多账号切换，如果界面显示的是 A 账号，后端实际操作的是 B 账号，这就是严重问题。
比如上传任务，如果显示成功但文件找不到，用户会马上失去信任。
比如 token 刷新失败，如果没有清楚提示，用户会以为自己的文件出了问题。
所以我后来不太敢把文件类工具写得太轻。
它的功能可以少，但账号状态、目录路径、上传结果、授权边界必须讲清楚。
这个项目证明了什么
转存小云不是一个大产品。
它没有大规模用户，也没有商业化。它更像一个 AI 协作开发出来的个人工具：从一个真实烦恼出发，拆需求、查限制、写代码、调接口、改结构，最后让核心链路跑起来。
但对我来说，它证明了几件事。
第一，AI coding 不是只能写 demo。只要需求足够具体，它可以陪我把小程序、云函数、第三方 API、测试和文档串起来。
第二，非技术出身的人也可以用 AI 进入软件开发，但前提是要能判断真实流程。模型可以写代码，但它不会天然知道用户为什么烦、平台限制为什么重要、哪个体验是核心。
第三，一个小工具最重要的不是一开始就做大，而是把一个具体动作做顺。
转存小云改名以后，我反而更愿意把它当成一个清楚的案例：一个小工具可以很窄，但只要它真的减少了一段重复动作，就值得被认真做完。