摘要
2019 年我写了一个 PHP 版的 Redis 在线管理工具，跑在 Web 服务器上。用了几年，一直没重构——部署太麻烦，要装 PHP、Nginx，用起来不够顺手。今年借着 TRAE SOLO，两小时内拍板了新的技术架构，一周时间把核心功能基本跑通，从 PHP+Vue2 迁移到了 Tauri 2.0+Vue3+Rust。项目名也换了，叫 Redis小助手。
背景
我做了 20 多年后端，Redis 是日常高频工具。旧版工具（Online Redis Manager）2019 年 11 月 25 日开始做，基于 PHP+Vue2+iView，功能够用，但每次在新机器上用都要配一遍环境，很烦。
一直想重构成桌面应用，但技术选型没定下来，一拖六年。
今年有了 TRAE SOLO，决定让它帮我把这个事真正推动起来。
实践过程
第一步：用 SOLO 做架构选型（约 2 小时）
这是整个过程最值钱的部分。
我把需求喂给 SOLO：旧版是 PHP Web 应用，想改成桌面客户端，双击即用，跨 Windows/macOS，功能对齐旧版。
SOLO 帮我系统梳理了几条路：
-
Go+Gin+React：后端独立，架构太重，桌面应用用不着单独跑一个服务
-
Electron+Vue3：生态成熟，但包体积 100MB+，内存占用高，杀鸡用牛刀
-
Tauri 2.0+Vue3+Rust：包体积约 10MB，用系统原生 WebView，内存低，Rust 后端安全性好
最终选 Tauri 2.0。不是拍脑袋，是把三个方案的优劣对着实际需求逐项比完之后的结论。
中间还讨论了 Electron 时期的一个"双端部署"方案——想一套代码同时跑桌面和浏览器。SOLO 分析之后认为架构复杂度太高，当前阶段不值得，先搁置。这个判断我觉得是对的：功能对齐比架构超前更重要。
整个选型过程，SOLO 帮我生成了完整的 ADR 文档（架构决策记录），把每个决策的背景、候选方案、最终选择、后果都写清楚了，方便后续回溯。
第二步：拆解功能范围（30 分钟）
旧版有哪些功能，新版 v2.0 要覆盖哪些——SOLO 帮我逐一梳理：
-
服务器配置 CRUD、多服务器切换
-
DB 列表查看、新增、删除
-
键的浏览、搜索、查看、增删改
-
数据导入导出（旧版 Excel，新版改为 JSON）
明确划出了"v2.0 范围内"和"后续版本"的边界，避免边做边加功能。
第三步：一周打磨（日常工作之余）
技术栈切换最大的坑：我不会 Rust。
SOLO 在这里帮了很多。Tauri 的 Rust 后端部分，连接 Redis 用的 redis-rs 库，17 个 Tauri Commands 的写法，包括异步处理、类型映射这些细节，基本都靠 SOLO 生成初始代码，再由我理解调整。
前端部分（Vue3+Element Plus+Pinia）相对熟悉，但 iView → Element Plus 的组件迁移也要一一对应，Dialog、Table、Popconfirm……SOLO 给了完整的映射建议。
踩过的坑：
-
Tauri 2.0 的权限系统和 1.x 不一样，fs 访问需要单独在配置里声明，折腾了一段时间
-
redis-rs 的连接池在异步环境下要注意生命周期，第一版直接崩了，SOLO 给出了正确的写法
成果
-
项目地址：https://gitee.com/skygreen2015/RedisManager（Gitee 上的仓库）
-
核心功能已跑通：连接管理、DB 浏览、键 CRUD、模糊搜索、JSON 导入导出
-
包体积：约 10MB（旧版 PHP 方案要装整套 LNMP 环境，不可比）
-
后续计划：命令终端（v2.1）、日志记录（v2.1）、内存分析（v2.1）、慢查询分析（v2.1）、深色主题（v2.2）、监控面板（v3.0）…
总结
这个项目本来能拖很久。六年了，想动没动。
TRAE SOLO 真正帮我做到的事是：在我最容易卡住的那一步——架构选型——给了完整的分析框架，而不是让我自己查文档、比方案、写 PRD。两小时有了方向，后面的事才能推进。
它不替你写代码（或者说，写出来的代码你还是要看懂），但它把"想清楚要做什么、怎么做"这个过程大幅压缩了。
对我来说，More than Coding 的意思是：AI 帮你想，你来决策，然后一起做。