第一个工具：图片打码工具的设计与实现

第一个真实小工具选择做图片打码工具，它把多图选择、缩略图、拖拽打码、撤销和保存状态这些细节完整跑了一遍。

第一个工具：图片打码工具的设计与实现

上图是为文章生成的概念配图，真实工具界面以后可以再补一张截图到 assets/image-redactor-real-ui.png。

第一个真实小工具，我选择做“图片打码工具”。

这个选择比较适合起步。它不是一个特别复杂的工具，但足够真实：用户有明确需求，交互不只是一个输入框和一个按钮，而且涉及图片选择、预览、编辑、撤销、状态标记和导出。

项目名叫：

yuan-image-redactor

中文名叫：

图片打码工具

本地目录是：

D:\dev\yuan-tools\yuan-image-redactor

需求从用户视角开始

我对这个工具的要求不是“能打码就行”，而是要接近真实用户会期待的使用方式。

用户可能一次要处理多张截图，而不是只处理一张。所以工具需要支持一次选择多张图片。

用户选择多张图片后，需要知道当前有哪些图片已经导入，所以需要缩略图列表。

用户可能处理完一张再处理下一张，所以缩略图需要可以点击切换。

用户也可能导错图片，所以缩略图上要有清除按钮。但这个清除动作只应该把图片从工具列表移除，不能删除本地原图。

这些细节看起来不大，但它们决定工具是否像一个真正可用的软件。

核心交互

图片打码的主流程很简单：

flowchart LR
  A["选择多张图片"] --> B["缩略图列表"]
  B --> C["选中图片"]
  C --> D["拖拽区域打码"]
  D --> E["撤销或继续修改"]
  E --> F["保存当前或全部"]

用户在大图上按住鼠标并拖拽，框选需要打码的区域。松开鼠标后，选中区域会被处理成马赛克。

这类操作的关键不是算法多复杂，而是反馈要及时。拖拽时要让用户看见选区，松开后要立刻看到结果。否则工具会显得迟钝。

每张图片独立记录状态

多图工具最容易混乱的地方，是每张图片都有自己的状态。

我给每张图片维护了几类信息：

• 是否还是原图。
• 是否已经打码但未保存。
• 是否已经保存。
• 保存后是否又发生了新修改。
• 当前已经打码了多少次。

这些状态直接影响用户信心。用户需要知道哪张图已经处理过，哪张还没保存，哪张保存后又改了。如果没有这些标记，批量处理时很容易漏掉。

撤销功能为什么重要

打码是一个手势操作，很容易框大、框小或框错位置。

所以第一版就加入了撤销。它不追求复杂的历史面板，只支持撤销当前图片的最后一次打码。这是一个很务实的取舍：实现成本可控，但已经能解决最常见的误操作。

后续如果工具继续增强，可以再加入多步历史、局部历史列表或可视化操作记录。但第一版先把最核心的撤销做稳定。

保存行为

这个工具不会覆盖原始图片，也不会删除本地文件。

保存时会导出一个新的 PNG 副本，文件名类似：

原文件名-redacted.png

保存位置由浏览器或系统下载设置决定。如果没有弹出保存窗口，通常会保存到系统“下载”文件夹。

这个地方第一版还不完美。更理想的桌面体验，是使用 Tauri 的原生保存对话框，让用户明确选择保存位置。这个增强已经记录在后续优化方向里。

技术实现

工具的核心处理基于 Canvas。

前端负责图片读取、显示、拖拽选区、马赛克渲染和导出。桌面版使用 Tauri 打包，窗口标题显示中文工具名，最终生成 Windows EXE。

第一版没有把图片上传到服务器。Web 版使用浏览器本地能力处理，桌面版使用本地 WebView 处理。对图片隐私工具来说，这一点很重要。

第一版的价值

yuan-image-redactor 的意义不只是“做了一个打码工具”。

它验证了我的小工具开发模式：

• 可以用一套 UI 同时生成 Web 和桌面版。
• 可以把用户说明文档和项目 README 标准化。
• 可以打包出隐藏终端窗口的 Windows EXE。
• 可以发布 GitHub Release。
• 可以反过来沉淀成博客文章。

一个工具跑通之后，后面的工具就不再是从零开始。

后续优化

后续我会优先考虑这些方向：

• 增加原生“另存为”窗口。
• 增加批量导出 ZIP。
• 增加模糊强度调节。
• 增加笔刷打码。
• 增加更完整的历史记录面板。
• 补充真实界面截图和打码前后对比图。

第一版不需要完美，但需要真实可用。对我来说，这个工具已经完成了它作为第一个小工具的使命。