作为一名博主，我一直依赖 PicGo 这款工具来处理博客图片。我的常规工作流是在 Typora 中完成文章写作，然后将图片上传到 PicGo，最后将生成的链接粘贴回 Typora。

这个流程看似简单，但实际操作起来却相当繁琐，尤其是当文章包含大量图片时，我需要将图片一张张拖拽到 PicGo 中。起初，鉴于我写博客的频率不算高，每次只处理一篇文章，这种方式还在可接受的范围内。

然而，当我决定将所有图片从原有的图床迁移到腾讯云 COS 时，这个问题变得异常棘手。我需要将成百上千张图片从旧图床一张张下载下来，然后再逐一上传。更关键的是，我原来的图片大多是 PNG 格式，占用了大量的存储空间和网络流量。对于个人博客而言，腾讯云 CDN 和 COS 的成本，尤其是在处理 PNG 这类大文件时，是一笔不小的开销。

也许有人会提到图床自带的压缩功能。我确实测试了这项功能，效果虽然不错，但压缩策略非常保守。单次文章访问的图片总流量仍然高达 10MB，这样算下来很可能会超出 CDN 的基础套餐额度。因此，我决定必须对图片进行手动压缩。

这样一来，整个流程变得极其复杂：首先，我需要逐一下载所有图片（由于分散在不同图床，且部分账号密码也已遗忘，只能单张操作）；接着，再将这些图片一张张进行压缩，或是在线分批处理，但又会受到免费额度的限制；即便不考虑这些，批量上传到 PicGo 后，我还需要手动将新生成的链接一一回填到 Markdown 文件中。

这时我意识到，这个流程充满了大量重复性劳动，而重复恰恰意味着可以被自动化。于是，我决定开发一个脚本，首先实现自动从 Markdown 文件中下载图片的功能，从而省去手动下载的麻烦。

脚本开发完成后，我进一步思考：既然图片已经下载到本地，为何不直接在程序中完成压缩呢？于是，我为脚本增加了可控的压缩功能，用户可以根据需要选择 1% 到 50% 不等的压缩率，大大提升了可操作性。

完成了前两步之后，我又想到：为什么我还要手动将这些处理过的图片上传到 PicGo 呢？在研究 PicGo 的功能时，我发现了一个非常有用的“回写”机制。这意味着图片上传到图床后，PicGo 可以直接将返回的链接写回到 Markdown 文件中，自动替换掉原来的本地或旧链接。

就这样，一个集成式的解决方案诞生了。现在，我只需点击一个按钮，就能实现对 Markdown 文件中本地图片或网络图片的自动下载、压缩、上传和链接回写。整个过程无缝衔接，极大地简化了我的工作流程。

实际上，这个脚本彻底改变了我的写作方式。现在，我可以在写作时直接将图片拖拽到 Typora 中，文章完成后，再用我开发的脚本一键处理。我再也无需与图片一张张“搏斗”，整个体验行云流水。

为了让这个工具更加易用，作为一名“极致懒人”，我还用 AI 辅助编写了一个前端界面。虽然前端的稳定性还有待提升，但整体使用体验已经非常出色。它支持文件选择、集成了 PicGo 的大部分图床，并且可以直接设置压缩比，完整地实现了我最初的所有设想。

如果您对这个项目感兴趣，可以访问我的代码仓库：DohhhDo/Picgo.MD。欢迎阅读仓库文件了解具体使用方法。虽然可能不会有很多人使用，但只要有一个人发现它的价值，我就会继续维护下去。