用 AI 做第一个小工具，为什么可以从图片压缩开始？

想用 AI 做小工具，又不想一开始就陷入账号、付费和数据库，可以先考虑一个具体任务：把一张太大的图片，变成适合发到网页上的文件。用户能立刻看懂输入是什么，也能用下载结果判断它有没有用。

图片压缩适合练手，原因在于它把产品设计的几个问题放在了很小的范围内：处理是否需要上传、文件变小了多少、画质还能不能接受、失败时怎么解释。AI 可以帮助编写界面和处理逻辑，但这些取舍仍要由需求决定。

一个值得参考的真实产品是 Squoosh。它的开源仓库由 GoogleChromeLabs 托管，项目说明将其定义为支持多种格式的图片压缩网页应用，并明确写明：图片压缩在本地进行，图片不会发送到服务器。它提供了一个可以研究的例子：网页工具也能把主要处理工作放在用户设备上。

第一版先解决一个使用时刻

“做一个图片压缩平台”还是太宽。更有帮助的描述是：一个人准备发布图文，发现截图文件太大，希望降低文件体积，保留可辨认的文字，并下载处理后的图片。

沿着这个时刻，第一版只需要一条完整路径：选择图片、看见原图信息、调整处理参数、比较结果、下载。登录、历史记录、批量队列和云盘同步都可以等到出现实际需要时再考虑。它们会引入额外的存储、权限和清理问题。

图注：原创功能流程图，表示本文建议的练习范围，不是 Squoosh 界面截图。

范围小不等于可以省略细节。上传区写“支持图片”不够清楚，下载按钮写“成功”也不能证明生成的文件真的能打开。对第一版来说，一条可靠的路径，比十个还没定义清楚的入口更有用。

从 Squoosh 学到的第一个选择：图片在哪里处理

图片压缩通常可以在服务器处理，也可以在浏览器中完成。浏览器本地处理能省掉图片上传和服务端文件保存这段链路，适合不需要协作存储的单图工具。大文件的解码和编码成本，则由用户的设备承担。

Squoosh 的项目说明还提供了一个容易被忽略的细节：在声明不上传图片的同时，它单独列出了 Google Analytics 收集的基础访问数据、处理前后图片大小等信息。因此，“图片在本地处理”和“网页完全不联网”是两件需要分别核对的事。

如果自己的工具要承诺“图片不上传”，就要检查文件内容是否进入了网络请求，也要清楚说明统计行为。引入一个远程处理 API 后，数据路径已经改变；不能继续沿用原来的隐私表述。对于练习项目，可以先不加入统计和远程图片处理，让数据路径更容易理解和验证。

本地处理也有边界。浏览器仍需加载页面资源，设备性能会影响处理速度，大尺寸图片还会占用较多内存。是否离线可用，需要另行设计缓存和离线入口，不能只凭“在浏览器运行”就作出承诺。

真正需要定义的是四个处理规则

先决定是否缩小像素尺寸。 一张用于文章插图的大照片，不一定需要保留原始宽高。缩小尺寸可以减少要编码的像素，但也会丢失细节。工具应显示输出宽高，并默认保持宽高比例，避免用户下载后才发现图片变形。

再决定输出格式。 JPEG 适合许多照片场景，但不支持透明背景；WebP 可以支持透明度。截图、细小文字和透明图标的要求不同，不能用一个预设包办。第一版可以只提供少量明确格式，遇到透明图片导出 JPEG 时，提示用户选择背景颜色，或阻止导出并说明原因。

把质量参数当成调节项。 浏览器的 canvas.toBlob() 可以请求输出格式和质量；MDN 说明，质量参数用于支持有损编码的格式，范围是 0 到 1。它不是“文件缩小百分比”，也不能保证输出刚好低于某个 KB 数值。若要实现目标体积，需要额外的尝试、停止条件和失败提示。

允许出现“处理后更大”。 输入文件可能已经经过优化，换一种格式或参数重新编码，结果不一定更小。此时应如实显示大小变化，让用户选择保留原图。把所有处理结果都写成“压缩成功”，会掩盖工具最需要解释的结果。

图注：原创取舍示意图。图中不包含压缩率数据，不代表任何格式在所有图片上都更优。

给 AI 的需求，要写到下载文件这一步

对于这个项目，AI 的角色是协助实现工具。图片处理本身可以交给浏览器 API 或经过选择的编码器，不需要为了压缩图片再调用生成式模型。

可以用下面这份需求开始，再根据目标浏览器和使用场景调整。它描述的是练习方案，并不表示已经有一个按此实现、通过测试的成品。

做一个单页图片压缩工具，第一版只处理一张图片。
输入：JPEG、PNG；其他格式给出明确的不支持提示。
处理：在浏览器本地完成，不上传文件内容，不调用远程图片处理 API。
参数：可设置最大宽度并保持比例；输出 WebP 或 JPEG；可调整编码质量。
结果：显示原始/输出尺寸、文件大小、实际输出格式和前后预览。
透明图片：导出 JPEG 前要求选择背景色，不能静默变成黑底。
下载：扩展名必须符合实际输出类型，下载文件应能重新打开。
异常：处理失败、格式不支持、超出配置限制时显示原因；保留重新选择入口。
暂不加入：账号、付费、云端保存、批量处理和访问统计。
验收：用照片、文字截图、透明 PNG 和错误文件分别走完流程。

文件大小和像素上限也应配置，但数值要结合目标设备试出来。压缩文件体积很小，不代表解码后占用也小：常见的四通道像素缓冲大致需要“宽 × 高 × 4”字节，处理过程还可能同时保留多份数据。只限制上传文件的 MB 数，不能完整控制内存消耗。

如果还不习惯把模糊想法改成输入、约束和验收条件，可以继续参考AI 编程需求描述模板。不要一次让 AI 添加很多尚未决定规则的功能，否则很难判断问题出在需求还是实现。

用四类文件检查工具是否真的可用

验收时不要只选一张顺手的样例。不同图片会暴露不同问题，至少应覆盖下面四类，并记录原始文件、输出参数和下载结果。

• 普通照片：检查方向、颜色、输出宽高，以及下载文件能否在另一款查看器中打开。手机照片的方向信息尤其值得留意。
• 有细小文字的截图：按实际显示尺寸检查文字边缘，再放大比较。文件明显变小，却看不清按钮和数字，并不适合原来的发布场景。
• 透明 PNG：检查 WebP 输出是否保留透明区域，以及 JPEG 输出的背景处理是否符合用户选择。
• 错误或超限文件：用不支持的格式、损坏文件和超出配置限制的文件检查提示。处理失败后应能重新选择，不应一直显示“处理中”。

还要确认下载得到的类型。MDN 提醒，toBlob() 遇到未指定或不支持的输出格式时会使用 PNG；所以文件名不能只依据下拉框里的选项拼接，应该核对实际生成的 Blob 类型。名为 .webp 的 PNG，可能在某个查看器里能打开，却给后续上传和格式判断留下问题。

发布之前，再到实际托管页面完成这些操作。测试“图片不上传”时，检查网络请求中有无文件内容；测试速度时记录设备、浏览器和图片条件，不要把一次顺畅操作写成所有手机上的性能保证。更多上线前的边界检查，可对照AI 代码发布前检查清单。

做完以后，先判断它为谁省了一步

Squoosh 已经提供了成熟的图片压缩方案，练习项目没有必要声称“全面替代”。更有价值的下一步，是找一个具体使用者，看他是否还需要在多个工具之间来回切换。

例如，社群运营者可能只需要固定宽度的文章配图；产品同学可能更在意截图里的文字；设计师则可能优先考虑透明背景。这些是可以继续验证的需求假设，不是已经得到用户证明的市场结论。

先把一个场景里的选择做得清楚，再决定是否增加批量处理或预设。用 AI 做第一个小工具，真正值得学会的，是把输入、处理规则、结果解释和失败处理连成一条用户能走完的路径。图片压缩提供了一个范围可控、结果可比较的起点。

参考资料

• Squoosh 开源项目及其 README：产品用途、本地图片处理和统计数据说明。资料核对日期为 2026 年 10 月 29 日。
• MDN：HTMLCanvasElement.toBlob()：输出格式、质量参数、Blob 生成和不支持格式时的行为。