我用 TraeCode 给桌宠加了整套开发工具箱，从截图小工具变成开发者日常必备
我是谁，遇到了什么问题
我是做 Web 开发的，平时也自己设计放置修仙游戏， 桌面端开发其实没怎么碰过。但前阵子我搞了个桌宠项目——就是那个叫"尼可"的桌面宠物，本来是从截图工具改过来的，WPF 写的，插件化架构。
尼可能逛论坛、收卡牌、换皮肤、还有记忆系统，功能倒是不少。但有一次我在写代码的时候想格式化一段 JSON，又要切到浏览器去找在线工具，来来回回特别烦。我就想，既然桌宠已经是插件架构了，为啥不直接加个 JSON 工具？然后又想，既然要加，不如把常用的开发小工具全塞进去——正则测试、Base64、时间戳转换、哈希计算、颜色取色……全整一套，以后不用再来回切窗口了。
问题是：这些工具我大部分都没从头写过，WPF 也不是我最熟的栈。一个个去啃文档写，估计得搞一两周。
我是怎么用 TraeCode 解决的
我主要用的是 SOLO 模式，因为整个任务链条比较长，需要它自己规划、拆分、并行执行。
第一步：先加一个 JSON 格式化插件，试试水。
我先让它看了一下项目已有的插件接口（IPetModule），跟它说"照着现有的模块架构，加一个 JSON 格式化插件，要有格式化、压缩、校验、Unicode 转义功能"。它读完项目结构就直接开写了，创建了窗口、模块文件，注册到托盘菜单，一次编译通过。这个过程大概几分钟，我心想这效率还行。
第二步：摊牌了，我要加全部工具，合成一个工具箱。
我跟它说：“之前建议的那些开发工具——正则、Base64、时间戳、UUID、哈希、取色、二维码、文本对比、Markdown 预览、编码转换、HTTP 测试、IP 查询——全部加上，和 JSON 格式化合并成一个’工具箱’入口。”
这一步是整个任务里最大的一坨。它自己拆成了并行任务，同时创建多个工具页面：一批搞文本类工具，一批搞生成类工具，一批搞网络类工具。13 个 UserControl 加一个主窗口，加起来快 20 个文件，最后并行写完统一编译，0 错误。
我就在旁边看着它一个一个文件蹦出来，哪个子任务先完成就先看哪个，感觉还行就让它继续。这个节奏我挺喜欢的，跟我以前做小程序时用子代理并行开发的模式一样。
第三步：修 bug + 加功能，边用边调。
工具上线之后我开始实际用，然后就开始踩坑了：
- 颜色取色器全屏变黑：点击取色按钮，整个屏幕黑了，啥也看不见。原因是取色覆盖窗口没设
AllowsTransparency=True，WPF 直接给渲染成不透明黑色了。跟它说了之后，它不光修了透明度，还顺手加了个跟随鼠标的放大镜，取色体验一下子就好了。 - MD5 没有加盐和解密：原始哈希工具只能算哈希，我说加上盐值功能和 MD5 在线反查。它加了三种加盐方式（前缀、后缀、双重），还对接了两个在线彩虹表 API 做反查。
- 编码转换工具长文本撑爆布局：输入一长串 URL 编码的数据，标签被截断（“输入文本"变成"入文本”），布局全乱了。根因是文本框水平滚动条设成了 Auto，长文本往右撑开了整个面板。改成自动换行就好了。
- 工具箱窗口不能最小化：标题栏只有关闭按钮，没有最小化。加了个最小化按钮搞定。
这些 bug 拿到一个个修，每个基本一轮对话就解决。关键是它能自己定位根因，不用我帮它翻代码。
第四步：加快捷键和全局开关。
最后我跟它说，给工具箱加个快捷键 Ctrl+Shift+T，再做个全局开关，能一键启用/禁用所有快捷键（包括截图那些）。它创建了一个 HotkeyManager 统一管理所有热键，托盘菜单里加了个带勾选状态的开关项，首选项里也能自定义快捷键。这一步改动涉及 5 个文件，也是一次编译通过。
最终交付的东西：
一个集成了 13 个开发工具的桌宠工具箱，右键桌宠 →「
工具箱」或按 快捷键打开：
这些是我自己每天开发都在用的，现在不用切浏览器了，桌宠右键一开就行。项目本身已经跑起来了，日常使用中
效率对比
以前：要加一个工具，我得先查 WPF 文档（不熟嘛），再写 UI 布局，再写逻辑代码，一个工具可能半天到一天。13 个工具串行写，加上调试，我估计得两周往上。
这次：用 TraeCode 的 SOLO 模式，它自己并行拆分任务，13 个工具页面 + 主窗口框架，差不多一个下午就全写完了。后续修 bug 加功能，每个问题基本都是一轮对话搞定，总共也就花了一两天。效率大概是以前的 5-6 倍。
更重要的是，它不只是在写代码，它还在帮我定位问题根因。比如取色器黑屏那个，如果不是它直接找到 AllowsTransparency 的问题，我可能要在 WPF 透明窗口的坑里转好一阵。
几点经验
-
SOLO 模式适合任务量大、可拆分的场景。13 个工具页面天然适合并行，让它自己拆比我一个个指挥效率高得多。但如果只是改一个 bug，直接对话反而更快。
-
先给上下文，再提需求。每次加功能前，我都会让它先读项目现有的插件架构和代码风格。这样写出来的东西能直接融入项目，不用我再手动调整格式和命名。
-
用起来再发现问题，比纸上谈兵靠谱。工具箱写完我马上实际用，用的时候才发现取色黑屏、长文本撑布局这些问题。如果是写完不测直接交付，这些 bug 全得留给用户发现。所以"写完 → 自己用 → 发现问题 → 让它修"这个循环特别重要。
