做本地工具链和 AI 助手的朋友碰到“图片上传外链”这种需求时最烦的就是重复造轮子。我之前对接过阿里 OSS、七牛、又拍云每换一个图床就要重写一套上传逻辑AK/SK 还得小心翼翼地塞进环境变量。直到有一天我把 PicGo 这个桌面图床工具翻了个底朝天发现它自带一个本地服务默认跑在 127.0.0.1:36677只需要 POST 一个 JSON 过去PicGo 就会把你指定的本地图片上传到它已经配置好的图床再把公共 URL 原样返回。这等于把“图床 SDK 鉴权 上传重试”全部外包给了本地服务。我据此写了一个 PicGo-Skill一个专门负责“调用本地 PicGo 服务上传图片”的能力模块可以被 AI Agent、自动化脚本、博客工具甚至测试环境直接复用。这篇文章把它的定位、原理、完整代码和踩坑记录全部写出来。不管你是想给自己的助手加一个“帮我传图”技能还是想在项目里省掉图床 SDK 的接入成本这篇内容都值得你花几分钟看完。1. 项目定位先搞清楚这个 Skill 到底解决什么问题1.1 为什么我不愿意在自己的代码里直接接图床 SDK先说我之前遭遇过的真实场景。我维护的一个自动化项目需要把生成的截图、临时图片转成可访问的 URL供企业微信机器人、博客草稿甚至 AI Prompt 引用。最初我按部就班地在后端接了阿里云 OSS 的 SDK申请 Bucket、设置 AccessKey、写签名、处理 CORS还要把 AK/SK 放到配置中心里加密管理。这套东西写完就能用但维护成本全在后面。首先是 SDK 版本问题——阿里云 OSS 的 Python SDK、Node SDK 互不兼容我业务里同时有 Python 服务和 Node.js 自动化脚本意味着同一套上传逻辑要写两遍其次是图床切换的问题——有段时间我把图床从阿里 OSS 换到了腾讯云 COS结果签名算法、上传参数全得推倒重来更别提某些图床平台偶尔抽风需要在业务层写重试、写超时代码越堆越厚。站在工程角度这叫“把不该业务关注的复杂度引入了业务代码”。上传图片这件小事本质上是“把本地文件安全地送到远端并拿到外链”它不应该知道你在用哪家云、你的密钥怎么管理。这就是我转向“本地服务”这个思路的起点。1.2 Skill 的边界它负责什么、不负责什么PicGo-Skill 的职责非常收敛我把它定义成三层输入一个或多个本地图片的绝对路径动作向本地 PicGo 服务的 /upload 接口发起 HTTP POST 请求输出结构化的结果对象包括成功标志、外链 URL 列表、失败原因。它不负责下载网络图片不负责压缩图片不负责删除远端图床上传错的图片也不负责把 URL 进一步拼成 Markdown、HTML 或者其他格式。这些功能如果你需要应该在 Skill 外层再加一层“流程编排”而不是膨胀这个 Skill 本身。边界清晰的最大好处是我可以把它当积木一样用在 N 个场景里不必每次复制一堆代码。1.3 和“苍穹外卖”式本地图片上传的差别说到“本地图片上传”很多后端开发者第一反应是“苍穹外卖”那类教学项目里的做法把客户端传上来的 MultipartFile 用 FileOutputStream 写到服务器本地磁盘再通过静态资源映射把本地路径变成 URL 返回给前端。这个经典方案在小系统里挺好用但它和 PicGo-Skill 是两回事。我画了个表对比项苍穹外卖式本地磁盘上传PicGo-Skill 调本地服务文件去向服务器本地磁盘云端图床OSS/GitHub/SM.MS 等外链有效期依赖服务器存活与磁盘清理由图床决定一般可达永久鉴权凭证无凭证由 PicGo 本地管理业务代码不接触扩展性换存储要改业务代码换图床只改 PicGo 配置代码复杂度需自己处理流、目录、重名一次 HTTP 调用适用场景开发学习、内网小系统自动化流程、AI 助手、外部可访问需求一句话总结那个模式是“把图片留在本地”而这个 Skill 的思路是“把图片送到云端再拿地址回来”。理解到这一层你后面看代码就不会觉得莫名其妙。2. 本地服务原理PicGo 的 36677 端口里到底发生了什么2.1 PicGo Server 是怎么跑起来的PicGo 是个基于 Electron 的桌面应用通常大家只在它的 GUI 界面上点“上传区”手工传图。但它内置了一个可选开关叫“PicGo Server”。你在设置界面里打开它之后PicGo 会在本机监听 36677 端口对外提供 HTTP 接口。只要 PicGo 这个进程活着端口就一直在任何本机程序都可以往 http://127.0.0.1:36677 发请求。这里有两个关键点值得强调。第一PicGo Server 默认只绑定 127.0.0.1也就是只能本机访问其他机器过不来。这不是限制而是保护——它暴露的是文件上传接口如果不限制 IP等于任何人往你本机发个路径就能触发一次图床上传这会成为免费给别人刷流量的漏洞。所以 Skill 跑在哪台机器PicGo 就装在哪台机器这是硬前提。第二这个服务和传统 Windows 系统服务比如 Windows Installer 那种在 services.msc 里注册的服务不是一回事。PicGo Server 是应用自己开的 HTTP 端口不是注册在系统服务管理器里的进程。所以当我们排查“本地服务”起不来的时候别去 services.msc 里找 PicGo 的名字——那会找不到你该看的是进程和端口状态。这个坑我在第 5 节专门展开。2.2 /upload 接口的请求与响应格式PicGo Server 最常用的接口就是 POST /upload。它接受一个 JSON body核心字段是 list里面放你要上传的本地图片绝对路径数组。请求长这样curl -X POST http://127.0.0.1:36677/upload \ -H Content-Type: application/json \ -d {list:[/Users/me/Pictures/test.png]}如果上传成功PicGo 会返回这样的 JSON{ success: true, result: [ https://cdn.example.com/2023/11/test.png ] }如果失败返回结构里 success 是 false并且会有 message 字段告诉你挂在哪一步{ success: false, message: 上传失败无法获取文件... }这里有个不容易察觉的对应关系list 数组里路径的顺序和 result 数组里 URL 的顺序一一对应。一次请求可以传多张图PicGo 逐个上传最后按相同顺序把 URL 返回。也就是说你发的第二张图没传成功result 数组里第二个位置通常对不上号处理批量上传时最好按索引去对齐不要只取第一个 URL。另外PicGo Server 还提供 GET /config 和 POST /config 两个接口可以读取和修改 PicGo 的配置。我在 Skill 里一般只用 /upload但 /config 在调试期很有用——你可以快速确认当前图床插件是否启用、默认上传器是不是你预期的那个。返回的 config 是个大 JSON字段很多包含 plugins、picBed 等建议只读不要直接改除非你完全清楚每个字段的含义。2.3 为什么这是“本地服务”而不是“本地文件上传”一个容易混淆的点是名字。很多人听到“本地服务”会以为是把图片存到本地或者是在本地跑一个文件服务然后给外网访问。其实 PicGo 本地服务的真实工作流是你的 Skill 把本地图片路径发给 PicGo ServerPicGo Server 读取这个本地文件PicGo 内部的图床插件把文件推送到云端存储云端返回 URLPicGo 把 URL 返回给你的 Skill。所以“本地”指的是“服务跑在本机、接口只监听本机”而不是“图片最终存在本机”。最终落点还是云端但鉴权、签名、推送这些脏活全被 PicGo 干掉了。用生活化的话说PicGo 就像一个住在你电脑上的“传图代办员”你只需要把文件路径递给它它会用自己的门路把图搬到云端再把收件单号带回来。这套设计的精妙之处在于你的 Skill 永远不需要知道图床的密钥。密钥只存在于 PicGo 的配置里。就算你在公司服务器上部署服务器环境变量里也不需要出现任何 AK/SK 的影子即使配置泄露也不会直接暴露云厂商的完整凭证。对安全敏感的场景这个特性非常值钱。3. Skill 的工程实现代码结构与调用约定3.1 Skill 的标准形态在 AI Agent 和自动化工具链里Skill 通常不是一段孤立的函数而是一个带“自我描述”的可调用单元。标准形态包含三件套名称告诉调度器这个技能叫什么描述用自然语言说明这个技能在什么情况下应该被调用、能解决什么问题参数定义调用它时需要哪些入参以及每个入参的类型和约束。有了这三件套LLM 才能在你做完意图识别之后正确地把“帮我把这张图传到图床上”映射到 picgo_upload 这个 Skill并自动补全 image_paths 参数。这其实是很多 Agent 框架里面 function calling 的标准协议。我们实现的 Skill 完全可以对齐这个协议{ skill: picgo_upload, description: 调用本地 PicGo 服务的 /upload 接口把本地图片上传到已配置的图床返回可公开访问的图片 URL 列表。适用于需要让 AI 助手、脚本或自动化流程获取图片外链的场景。, parameters: { type: object, properties: { image_paths: { type: array, items: { type: string }, description: 本地图片的绝对路径列表 } }, required: [image_paths] } }这里我不针对特定平台展开只强调一个设计原则参数越少、越原始Skill 越好用。我只暴露 image_paths 一个参数其它如端口、超时、图床选项全部走配置默认值。这样调用方不需要关心内部的任何细节。3.2 Python 核心实现我的自动化主服务是 Python所以先放 Python 版。这个实现刻意做得很薄只做三件事校验路径、调接口、规范输出。# picgo_skill.py import requests from pathlib import Path from typing import List PICGO_BASE_URL http://127.0.0.1:36677 def upload_images(image_paths: List[str], timeout: int 60) - dict: # 1. 路径预校验提前发现低级错误避免进入上传流程才报错 for p in image_paths: path Path(p) if not path.exists(): return {success: False, message: f文件不存在: {p}} if not path.is_file(): return {success: False, message: f路径不是文件: {p}} # 2. 调用 PicGo 本地服务 try: resp requests.post( f{PICGO_BASE_URL}/upload, json{list: image_paths}, timeouttimeout, headers{Content-Type: application/json}, ) resp.raise_for_status() except requests.exceptions.ConnectionError: return { success: False, message: 无法连接 PicGo 本地服务请确认 PicGo 已启动且 PicGo Server 已开启默认端口 36677, } except requests.exceptions.Timeout: return {success: False, message: f调用 PicGo 服务超时{timeout}s} # 3. 解析返回结果按索引对齐图片与 URL data resp.json() if data.get(success): urls data.get(result, []) return { success: True, count: len(urls), urls: urls, pairs: list(zip(image_paths, urls)), } return {success: False, message: data.get(message, 未知错误)}几个细节说一下。第一把 ConnectionError 单独捕获并转成清晰的中文提示是因为这个错误出现的频率最高——十次里八次是 PicGo 没开或者端口被占用。第二返回里我额外提供了 pairs把“原始路径 - 结果 URL”对排好方便上层在批量上传时定位哪张图失败了。第三timeout 设成 60 秒是因为上传大图时图床响应不一定快太短的超时会把慢速但成功的请求误判成失败。3.3 Node.js 版本与多语言适配如果你和我一样手头还有 Node 自动化脚本那我会再放一个 JS 版本。逻辑一模一样只是换了一门语言。两边共享同一套 HTTP 约定这也是“服务化”的好处语言只是客户端真正的核心在 PicGo 那个进程里。// picgoSkill.js const axios require(axios); const fs require(fs); const PICGO_UPLOAD_URL http://127.0.0.1:36677/upload; async function uploadImages(imagePaths) { for (const p of imagePaths) { if (!fs.existsSync(p)) { return { success: false, message: 文件不存在: ${p} }; } } try { const { data } await axios.post( PICGO_UPLOAD_URL, { list: imagePaths }, { timeout: 60000 } ); if (data.success) { const urls data.result || []; return { success: true, count: urls.length, urls, pairs: imagePaths.map((p, i) [p, urls[i]]) }; } return { success: false, message: data.message || 上传失败 }; } catch (e) { if (e.code ECONNREFUSED) { return { success: false, message: 无法连接 PicGo 本地服务请确认 PicGo 已启动且 PicGo Server 已开启 }; } return { success: false, message: 请求异常: ${e.message} }; } } module.exports { uploadImages };跨语言的关键在于把“调用 PicGo”这个动作收敛成一个薄薄的 HTTP 封装。我在团队里甚至让 Java 同事照着同一个接口也写了一个版本三份代码加起来不到 100 行维护成本几乎可以忽略。如果哪天接口变了改动也是局部且可同步的。3.4 参数校验与返回标准化为什么参数校验这么重要因为 Skill 的调用方往往是 LLMLLM 生成参数时偶尔会把相对路径当成绝对路径传进来或者把文件夹路径当文件路径。如果你不校验直接用 requests 发给 PicGo返回的报错会非常晦涩LLM 也看不懂只会继续乱试。所以我在进入网络请求之前就做两道闸路径是否存在路径是否是文件。如果希望更严谨可以在校验前把相对路径用 os.path.abspath 转成绝对路径因为 PicGo Server 对相对路径的处理在不同系统、不同版本下表现不一致统一转绝对路径能省掉很多怪问题。但要小心如果你把相对路径基于“当前工作目录”转绝对路径而 Skill 被多个项目复用每个项目的工作目录不同转换结果也可能不同。更稳妥的做法是强制要求调用方传绝对路径并在文档里写清楚。返回标准化也很关键。实际生产里上层不关心你是怎么调 PicGo 的它只关心三件事成没成、URL 是啥、失败原因是什么。所以我固定返回 success、count、urls、message 四类字段。加 count 是因为很多调用方拿“返回 URL 数量是否等于请求图片数”来判断是否全部成功省得它自己 len 一下。3.5 重试、超时与日志的取舍要不要加重试逻辑我的建议是重试可以加但要有边界。PicGo 上传失败的原因里有一类是图床网络抖动重试 1 次就有大概率成功另一类是配置错误或图床账号异常这种情况重试 10 次也没用还白白阻塞业务。所以我在调用方那一层做了一个简单的重试策略失败后间隔 2 秒重试一次最多两次两次都失败就上报错误。日志上我建议至少记录以下内容调用时间、请求的路径列表、PicGo 返回的原始 JSON。路径本身一般不算敏感但如果项目里路径含机器用户名建议做脱敏处理。这套日志在你接入了 AI Agent 后特别有用因为一旦 LLM 反复调一个 Skill 失败你可以直接从日志里看到它到底传了什么参数而不是打开黑盒瞎猜。4. 实战跑通从安装 PicGo 到 Skill 返回 URL4.1 安装 PicGo 并开启本地服务第一步去 PicGo 的 GitHub Releases 页面下载对应系统的安装包。我的是 macOS下载 dmg 安装完直接打开。Windows 用户下载 exe安装过程一路 Next 就好。安装完打开主界面进入“设置” - “PicGo 设置”你会看到“PicGo Server”相关选项端口默认 36677。把开关打开PicGo Server 就开始监听了。这一步不做后面所有请求都会连接失败我见过太多人卡在这里。提示PicGo 在 macOS 上如果开启了系统代理个别版本可能影响本地服务的响应行为。实测下来影响不大但如果你遇到“请求发出去但一直不返回”的怪现象先尝试关掉系统代理再做最小复现。检查监听状态可以用 lsofmacOS/Linux或 netstatWindows# macOS / Linux lsof -i :36677 # Windows netstat -ano | findstr 36677正常情况你应该看到有进程在 LISTENING 状态PID 指向 PicGo 进程。看到这个输出才说明本地服务真的活着。4.2 配置图床以 GitHub 和 SM.MS 为例PicGo 服务只是“传话的”真正决定图片传到哪里的是图床插件配置。我常用两种分别代表“私人定制”和“快速上手”。GitHub 图床在 PicGo 设置里选择 GitHub填写 token 和仓库名owner/repo还要选一个存储分支和自定义域名。GitHub 图床的优点是不限上传次数缺点是国内访问速度看网络心情还有一个坑是仓库体积过大后访问性能明显下滑大文件图片尤其明显。所以我的建议是 GitHub 图床只放小体积截图大图走正规对象存储。SM.MS 图床注册账号拿 token在 PicGo 设置里选 SM.MS填 token 就行。免费版对单张图片大小和存储容量都有限制胜在稳定、域名访问速度快。适合用来临时传几张演示图不适合做正式的存量图床。配置完成后可以直接在 PicGo 主界面的“上传区”拖一张图进去测试。上传成功后通知区域会显示已经复制到剪贴板的 URL这说明图床链路是通的。注意这一步是在验证“PicGo 本身能不能传图”它通了你的 Skill 才可能通。4.3 用 curl 先做一次冷验证很多人的毛病是一上来就写代码然后出了问题在代码层排查半天。我的习惯是先用 curl 验证服务本身把“服务问题”和“代码问题”切分开。curl -X POST http://127.0.0.1:36677/upload \ -H Content-Type: application/json \ -d {list:[/Users/me/Desktop/demo.png]}如果返回 JSON 里 result 有 URL恭喜你说明 PicGo 服务和图床配置完全正常。这时候再去调 Skill心里就有底了。如果 curl 这一步就已经失败问题一定在 PicGo 这边跟你的语言、代码无关。4.4 把 Skill 接入 AI 助手一个最小示例我在自己的助手项目里是把 Skill 注册到 agent 的 function list 里的。下面是一个极简的注册代码展示意图层怎么把自然语言请求分发到这个 Skillfrom picgo_skill import upload_images def handle_tool_call(func_name, arguments): if func_name picgo_upload: return upload_images(arguments[image_paths]) ...这样当用户说“把 /tmp/screenshot.png 传到图床给我链接”时助手解析出的动作就是调用 picgo_upload参数是 [/tmp/screenshot.png]。整个过程对用户几乎是透明的他只知道“我说了一句话链接就回来了”。这里有一个实操体验很想分享AI 助手调用 Skill 时它传的路径往往不是它能“看到”的路径而是它“猜测”的路径。比如多轮对话里用户说“刚才那张图”LLM 如果没有上下文记住具体路径就会乱猜一个。解决方法是在上层对 LLM 输出的 image_paths 做一次存在性校验如果校验不过不要直接把错误返回给 LLM 让它瞎改而是提示“请用户在对话中重新提供图片的准确路径”。这个小设计能省掉无数失败的循环调用。4.5 实测效果与性能观察我用一张 1280x720 的 PNG 截图做了实测从 Skill 收到请求到拿到 URL本地链路耗时在 200ms 以内不含图床上传的时间而图床推送环节根据网络情况在 0.5~3 秒之间徘徊。也就是说这个 Skill 的实际瓶颈永远在图床网络而不是本地服务。批量传 10 张小图时PicGo 会串行逐个上传总耗时大概是单张时间的累加。如果你的场景对批量上传速度有要求建议把 list 长度控制在 5 张以内或者在前端做并行调用。5. 常见问题排查上传失败的 6 个高频坑5.1 PicGo 服务没起来端口怎么查出现“连接失败”时第一件事不是改代码而是确认服务进程。按上面说的用 lsof 或 netstat 查 36677 端口。如果端口没监听大概率是这三种情况PicGo 没打开PicGo 打开了但设置里的 Server 开关没开PicGo 开了但绑定到了别的端口。我印象比较深的一次是PicGo 升级后设置被重置Server 开关默认又变回关闭结果我排查了半天服务代码最后发现是版本升级把配置搞丢了。所以升级 PicGo 之后建议第一时间检查 Server 开关状态和图床配置别让升级变成隐形炸弹。5.2 successfalse 的常见原因如果 HTTP 请求通了但返回 JSON 里 success 是 false问题几乎都在 PicGo 的图床侧。我遇到的典型报错有“上传失败: 仓库不存在”GitHub 仓库名写错或者 token 没有该仓库的写权限“upload failed”没有具体原因的通用失败多半是网络不通、token 过期“文件超过大小限制”SM.MS 免费版对文件大小有限制压缩或换图床即可。针对这类问题建议直接到 PicGo 主界面上手动传一次同样的图观察它的完整报错和日志。PicGo GUI 的报错比 HTTP 接口返回的 message 详细得多能帮你快速定位是 token、仓库还是网络问题。5.3 文件路径的跨平台坑这是 Skill 实际使用时的高频踩坑点。Windows 路径是 C:\Users\xxx\Desktop\demo.pngmacOS 路径是 /Users/xxx/Desktop/demo.png。如果 Skill 跑在 Windows 上而调用方给出的是 POSIX 风格路径或者反过来那么路径校验第一关就过不去。解决办法是严格规定image_paths 必须是“运行 PicGo 的那台机器”上的绝对路径。任何跨机器的路径传递都不在本 Skill 范围内。如果你需要从远端上传那应该在远端先把文件下载到 PicGo 所在机器再调用 Skill。这一步看起来很笨但它是保持 Skill 实现简单的关键也让错误边界非常清晰——路径错了一定是调用方的问题而不是 Skill 的锅。5.4 中文文件名与特殊字符另一个隐蔽的坑是文件名里的中文、空格和特殊符号。PicGo 在读取本地文件时一般没问题但图床返回 URL 时有些图床会保留中文原样有些会做 URL 编码还有些会直接把中文替换成随机 ID。如果你后续要把 URL 拼进 Markdown注意不要对 URL 做二次编码否则两次编码后的地址大概率是 404。我的建议是上传前在 Skill 入口做一次文件名规范化把中文和空格替换成短横线例如“我的截图 001.png”改成“my-shot-001.png”。这能避开非常多平台兼容性问题。别嫌多此一举把问题消灭在入口比在 URL 层面补救便宜得多。5.5 同机限制远端机器调用不了本地服务因为 127.0.0.1 只监听本机所以你的 Skill 若部署在服务器 A而 PicGo 在你自己笔记本上那无论如何都连不上。很多人想“在笔记本上开发、在服务器上跑”就会撞上这个限制。要打破这个限制不是让 PicGo 改绑定 0.0.0.0有安全风险而是把 Skill 和 PicGo 部署在同一台机器。如果确实需要跨机器更稳妥的方案是通过加密隧道把本机端口暴露给那台服务器但这属于网络架构改造不在本文范围。我自己的实践经验是一台常年开机的迷你主机装 PicGo所有自动化任务都指向它一劳永逸。5.6 本地服务启动失败的共性问题最后说一个和 PicGo 相关的“通用型”问题。有时候你的机器上某个本地服务就是起不来而且报错很诡异比如 Windows 下常见的“Windows 无法启动 Windows Installer 服务位于本地计算机上。错误 1053服务没有及时响应启动或控制请求”。遇到 1053 这类“服务启动超时/没有响应”的报错先别急着重装系统按这个顺序排查去 services.msc 确认服务的启动类型是不是“自动”如果不是改成自动再手动启动一次打开事件查看器eventvwr.msc看 Windows 日志 - 应用程序找到对应时间点的错误事件那里通常有真正的异常堆栈用命令重注册对应服务的可执行组件比如 msiexec 相关服务可以用msiexec /unregister之后msiexec /regserver重置如果以上都不行考虑是否有杀毒软件或安全策略拦截了服务启动临时退出后再试。这套思路适用性很广本质是“服务启动失败先看事件日志里的具体原因再做针对性修复而不是凭报错编号瞎猜”。PicGo Server 虽不是 Windows 系统服务但它“启动不了”的排查逻辑也一样先查日志、查端口、查进程残留一层层剥总能定位到根因。注意上面 1053 的排查步骤主要用于系统级服务故障。PicGo 本体如果双击打不开优先查是不是被杀毒软件隔离、是不是多开冲突任务管理器里是否已有 PicGo 进程残留。6. 经验沉淀与后续扩展6.1 “本地服务 Skill”模式的适用边界写到这里你应该能感受到PicGo-Skill 本质是一个“小服务 薄客户端”的典型应用。它的优点非常多但也有明确的适用边界。如果你的场景是这几个我强烈建议采用本机或局域网内的自动化工具需要上传图片AI 助手需要把生成或截图文件变成外链多语言项目想少写图床 SDK 的重复代码。但如果你的场景是以下这些就需要重新评估纯线上 Serverless 函数里要上传图片——根本没有“本地 PicGo”可言高并发生产接口——PicGo 桌面进程不是为高并发设计的扛不住大量并发上传对图床凭证安全级别要求极高的合规场景——你更应该在服务端做独立的凭证托管而不是依赖一个桌面应用。一句话这个组合适合“轻量、本机、自动化”不适合“重负载、分布式、纯云端”。6.2 可以继续扩展的方向我在实际使用中已经尝到了甜头接下来准备做几个扩展增加“图片处理前置管线”在调用 Skill 前先用本地脚本或 CLI 做压缩、裁剪、加水印再把处理后的图片路径传给 PicGo。这样 AI 生成的超大图也能变成体积可控的外链。增加“URL 后处理模板”Skill 之外加一层格式化器根据目标平台Markdown、HTML、聊天机器人自动生成不同格式的图片引用。把同一个“本地服务 Skill”模式复制到其他本地能力上比如本地 OCR、本地视频转码只要本地有一个服务在 127.0.0.1 上监听你的 Skill 就能用同样的 HTTP 调用模式去对接。从我个人体会来说这个项目给我最大的启发不是“PicGo 真方便”而是“很多重复的脏活其实早就被某个桌面工具解决了只是它额外暴露了一个本地接口。聪明地复用它比重新造一个轮子要省太多成本。”如果你也正在为图床上传的事挠头不妨先打开你电脑上 PicGo 的设置看一眼找到那个 Server 开关你的体验可能就从此不一样了。
用PicGo本地服务封装图片上传能力：AI助手与自动化脚本的通用Skill
做本地工具链和 AI 助手的朋友碰到“图片上传外链”这种需求时最烦的就是重复造轮子。我之前对接过阿里 OSS、七牛、又拍云每换一个图床就要重写一套上传逻辑AK/SK 还得小心翼翼地塞进环境变量。直到有一天我把 PicGo 这个桌面图床工具翻了个底朝天发现它自带一个本地服务默认跑在 127.0.0.1:36677只需要 POST 一个 JSON 过去PicGo 就会把你指定的本地图片上传到它已经配置好的图床再把公共 URL 原样返回。这等于把“图床 SDK 鉴权 上传重试”全部外包给了本地服务。我据此写了一个 PicGo-Skill一个专门负责“调用本地 PicGo 服务上传图片”的能力模块可以被 AI Agent、自动化脚本、博客工具甚至测试环境直接复用。这篇文章把它的定位、原理、完整代码和踩坑记录全部写出来。不管你是想给自己的助手加一个“帮我传图”技能还是想在项目里省掉图床 SDK 的接入成本这篇内容都值得你花几分钟看完。1. 项目定位先搞清楚这个 Skill 到底解决什么问题1.1 为什么我不愿意在自己的代码里直接接图床 SDK先说我之前遭遇过的真实场景。我维护的一个自动化项目需要把生成的截图、临时图片转成可访问的 URL供企业微信机器人、博客草稿甚至 AI Prompt 引用。最初我按部就班地在后端接了阿里云 OSS 的 SDK申请 Bucket、设置 AccessKey、写签名、处理 CORS还要把 AK/SK 放到配置中心里加密管理。这套东西写完就能用但维护成本全在后面。首先是 SDK 版本问题——阿里云 OSS 的 Python SDK、Node SDK 互不兼容我业务里同时有 Python 服务和 Node.js 自动化脚本意味着同一套上传逻辑要写两遍其次是图床切换的问题——有段时间我把图床从阿里 OSS 换到了腾讯云 COS结果签名算法、上传参数全得推倒重来更别提某些图床平台偶尔抽风需要在业务层写重试、写超时代码越堆越厚。站在工程角度这叫“把不该业务关注的复杂度引入了业务代码”。上传图片这件小事本质上是“把本地文件安全地送到远端并拿到外链”它不应该知道你在用哪家云、你的密钥怎么管理。这就是我转向“本地服务”这个思路的起点。1.2 Skill 的边界它负责什么、不负责什么PicGo-Skill 的职责非常收敛我把它定义成三层输入一个或多个本地图片的绝对路径动作向本地 PicGo 服务的 /upload 接口发起 HTTP POST 请求输出结构化的结果对象包括成功标志、外链 URL 列表、失败原因。它不负责下载网络图片不负责压缩图片不负责删除远端图床上传错的图片也不负责把 URL 进一步拼成 Markdown、HTML 或者其他格式。这些功能如果你需要应该在 Skill 外层再加一层“流程编排”而不是膨胀这个 Skill 本身。边界清晰的最大好处是我可以把它当积木一样用在 N 个场景里不必每次复制一堆代码。1.3 和“苍穹外卖”式本地图片上传的差别说到“本地图片上传”很多后端开发者第一反应是“苍穹外卖”那类教学项目里的做法把客户端传上来的 MultipartFile 用 FileOutputStream 写到服务器本地磁盘再通过静态资源映射把本地路径变成 URL 返回给前端。这个经典方案在小系统里挺好用但它和 PicGo-Skill 是两回事。我画了个表对比项苍穹外卖式本地磁盘上传PicGo-Skill 调本地服务文件去向服务器本地磁盘云端图床OSS/GitHub/SM.MS 等外链有效期依赖服务器存活与磁盘清理由图床决定一般可达永久鉴权凭证无凭证由 PicGo 本地管理业务代码不接触扩展性换存储要改业务代码换图床只改 PicGo 配置代码复杂度需自己处理流、目录、重名一次 HTTP 调用适用场景开发学习、内网小系统自动化流程、AI 助手、外部可访问需求一句话总结那个模式是“把图片留在本地”而这个 Skill 的思路是“把图片送到云端再拿地址回来”。理解到这一层你后面看代码就不会觉得莫名其妙。2. 本地服务原理PicGo 的 36677 端口里到底发生了什么2.1 PicGo Server 是怎么跑起来的PicGo 是个基于 Electron 的桌面应用通常大家只在它的 GUI 界面上点“上传区”手工传图。但它内置了一个可选开关叫“PicGo Server”。你在设置界面里打开它之后PicGo 会在本机监听 36677 端口对外提供 HTTP 接口。只要 PicGo 这个进程活着端口就一直在任何本机程序都可以往 http://127.0.0.1:36677 发请求。这里有两个关键点值得强调。第一PicGo Server 默认只绑定 127.0.0.1也就是只能本机访问其他机器过不来。这不是限制而是保护——它暴露的是文件上传接口如果不限制 IP等于任何人往你本机发个路径就能触发一次图床上传这会成为免费给别人刷流量的漏洞。所以 Skill 跑在哪台机器PicGo 就装在哪台机器这是硬前提。第二这个服务和传统 Windows 系统服务比如 Windows Installer 那种在 services.msc 里注册的服务不是一回事。PicGo Server 是应用自己开的 HTTP 端口不是注册在系统服务管理器里的进程。所以当我们排查“本地服务”起不来的时候别去 services.msc 里找 PicGo 的名字——那会找不到你该看的是进程和端口状态。这个坑我在第 5 节专门展开。2.2 /upload 接口的请求与响应格式PicGo Server 最常用的接口就是 POST /upload。它接受一个 JSON body核心字段是 list里面放你要上传的本地图片绝对路径数组。请求长这样curl -X POST http://127.0.0.1:36677/upload \ -H Content-Type: application/json \ -d {list:[/Users/me/Pictures/test.png]}如果上传成功PicGo 会返回这样的 JSON{ success: true, result: [ https://cdn.example.com/2023/11/test.png ] }如果失败返回结构里 success 是 false并且会有 message 字段告诉你挂在哪一步{ success: false, message: 上传失败无法获取文件... }这里有个不容易察觉的对应关系list 数组里路径的顺序和 result 数组里 URL 的顺序一一对应。一次请求可以传多张图PicGo 逐个上传最后按相同顺序把 URL 返回。也就是说你发的第二张图没传成功result 数组里第二个位置通常对不上号处理批量上传时最好按索引去对齐不要只取第一个 URL。另外PicGo Server 还提供 GET /config 和 POST /config 两个接口可以读取和修改 PicGo 的配置。我在 Skill 里一般只用 /upload但 /config 在调试期很有用——你可以快速确认当前图床插件是否启用、默认上传器是不是你预期的那个。返回的 config 是个大 JSON字段很多包含 plugins、picBed 等建议只读不要直接改除非你完全清楚每个字段的含义。2.3 为什么这是“本地服务”而不是“本地文件上传”一个容易混淆的点是名字。很多人听到“本地服务”会以为是把图片存到本地或者是在本地跑一个文件服务然后给外网访问。其实 PicGo 本地服务的真实工作流是你的 Skill 把本地图片路径发给 PicGo ServerPicGo Server 读取这个本地文件PicGo 内部的图床插件把文件推送到云端存储云端返回 URLPicGo 把 URL 返回给你的 Skill。所以“本地”指的是“服务跑在本机、接口只监听本机”而不是“图片最终存在本机”。最终落点还是云端但鉴权、签名、推送这些脏活全被 PicGo 干掉了。用生活化的话说PicGo 就像一个住在你电脑上的“传图代办员”你只需要把文件路径递给它它会用自己的门路把图搬到云端再把收件单号带回来。这套设计的精妙之处在于你的 Skill 永远不需要知道图床的密钥。密钥只存在于 PicGo 的配置里。就算你在公司服务器上部署服务器环境变量里也不需要出现任何 AK/SK 的影子即使配置泄露也不会直接暴露云厂商的完整凭证。对安全敏感的场景这个特性非常值钱。3. Skill 的工程实现代码结构与调用约定3.1 Skill 的标准形态在 AI Agent 和自动化工具链里Skill 通常不是一段孤立的函数而是一个带“自我描述”的可调用单元。标准形态包含三件套名称告诉调度器这个技能叫什么描述用自然语言说明这个技能在什么情况下应该被调用、能解决什么问题参数定义调用它时需要哪些入参以及每个入参的类型和约束。有了这三件套LLM 才能在你做完意图识别之后正确地把“帮我把这张图传到图床上”映射到 picgo_upload 这个 Skill并自动补全 image_paths 参数。这其实是很多 Agent 框架里面 function calling 的标准协议。我们实现的 Skill 完全可以对齐这个协议{ skill: picgo_upload, description: 调用本地 PicGo 服务的 /upload 接口把本地图片上传到已配置的图床返回可公开访问的图片 URL 列表。适用于需要让 AI 助手、脚本或自动化流程获取图片外链的场景。, parameters: { type: object, properties: { image_paths: { type: array, items: { type: string }, description: 本地图片的绝对路径列表 } }, required: [image_paths] } }这里我不针对特定平台展开只强调一个设计原则参数越少、越原始Skill 越好用。我只暴露 image_paths 一个参数其它如端口、超时、图床选项全部走配置默认值。这样调用方不需要关心内部的任何细节。3.2 Python 核心实现我的自动化主服务是 Python所以先放 Python 版。这个实现刻意做得很薄只做三件事校验路径、调接口、规范输出。# picgo_skill.py import requests from pathlib import Path from typing import List PICGO_BASE_URL http://127.0.0.1:36677 def upload_images(image_paths: List[str], timeout: int 60) - dict: # 1. 路径预校验提前发现低级错误避免进入上传流程才报错 for p in image_paths: path Path(p) if not path.exists(): return {success: False, message: f文件不存在: {p}} if not path.is_file(): return {success: False, message: f路径不是文件: {p}} # 2. 调用 PicGo 本地服务 try: resp requests.post( f{PICGO_BASE_URL}/upload, json{list: image_paths}, timeouttimeout, headers{Content-Type: application/json}, ) resp.raise_for_status() except requests.exceptions.ConnectionError: return { success: False, message: 无法连接 PicGo 本地服务请确认 PicGo 已启动且 PicGo Server 已开启默认端口 36677, } except requests.exceptions.Timeout: return {success: False, message: f调用 PicGo 服务超时{timeout}s} # 3. 解析返回结果按索引对齐图片与 URL data resp.json() if data.get(success): urls data.get(result, []) return { success: True, count: len(urls), urls: urls, pairs: list(zip(image_paths, urls)), } return {success: False, message: data.get(message, 未知错误)}几个细节说一下。第一把 ConnectionError 单独捕获并转成清晰的中文提示是因为这个错误出现的频率最高——十次里八次是 PicGo 没开或者端口被占用。第二返回里我额外提供了 pairs把“原始路径 - 结果 URL”对排好方便上层在批量上传时定位哪张图失败了。第三timeout 设成 60 秒是因为上传大图时图床响应不一定快太短的超时会把慢速但成功的请求误判成失败。3.3 Node.js 版本与多语言适配如果你和我一样手头还有 Node 自动化脚本那我会再放一个 JS 版本。逻辑一模一样只是换了一门语言。两边共享同一套 HTTP 约定这也是“服务化”的好处语言只是客户端真正的核心在 PicGo 那个进程里。// picgoSkill.js const axios require(axios); const fs require(fs); const PICGO_UPLOAD_URL http://127.0.0.1:36677/upload; async function uploadImages(imagePaths) { for (const p of imagePaths) { if (!fs.existsSync(p)) { return { success: false, message: 文件不存在: ${p} }; } } try { const { data } await axios.post( PICGO_UPLOAD_URL, { list: imagePaths }, { timeout: 60000 } ); if (data.success) { const urls data.result || []; return { success: true, count: urls.length, urls, pairs: imagePaths.map((p, i) [p, urls[i]]) }; } return { success: false, message: data.message || 上传失败 }; } catch (e) { if (e.code ECONNREFUSED) { return { success: false, message: 无法连接 PicGo 本地服务请确认 PicGo 已启动且 PicGo Server 已开启 }; } return { success: false, message: 请求异常: ${e.message} }; } } module.exports { uploadImages };跨语言的关键在于把“调用 PicGo”这个动作收敛成一个薄薄的 HTTP 封装。我在团队里甚至让 Java 同事照着同一个接口也写了一个版本三份代码加起来不到 100 行维护成本几乎可以忽略。如果哪天接口变了改动也是局部且可同步的。3.4 参数校验与返回标准化为什么参数校验这么重要因为 Skill 的调用方往往是 LLMLLM 生成参数时偶尔会把相对路径当成绝对路径传进来或者把文件夹路径当文件路径。如果你不校验直接用 requests 发给 PicGo返回的报错会非常晦涩LLM 也看不懂只会继续乱试。所以我在进入网络请求之前就做两道闸路径是否存在路径是否是文件。如果希望更严谨可以在校验前把相对路径用 os.path.abspath 转成绝对路径因为 PicGo Server 对相对路径的处理在不同系统、不同版本下表现不一致统一转绝对路径能省掉很多怪问题。但要小心如果你把相对路径基于“当前工作目录”转绝对路径而 Skill 被多个项目复用每个项目的工作目录不同转换结果也可能不同。更稳妥的做法是强制要求调用方传绝对路径并在文档里写清楚。返回标准化也很关键。实际生产里上层不关心你是怎么调 PicGo 的它只关心三件事成没成、URL 是啥、失败原因是什么。所以我固定返回 success、count、urls、message 四类字段。加 count 是因为很多调用方拿“返回 URL 数量是否等于请求图片数”来判断是否全部成功省得它自己 len 一下。3.5 重试、超时与日志的取舍要不要加重试逻辑我的建议是重试可以加但要有边界。PicGo 上传失败的原因里有一类是图床网络抖动重试 1 次就有大概率成功另一类是配置错误或图床账号异常这种情况重试 10 次也没用还白白阻塞业务。所以我在调用方那一层做了一个简单的重试策略失败后间隔 2 秒重试一次最多两次两次都失败就上报错误。日志上我建议至少记录以下内容调用时间、请求的路径列表、PicGo 返回的原始 JSON。路径本身一般不算敏感但如果项目里路径含机器用户名建议做脱敏处理。这套日志在你接入了 AI Agent 后特别有用因为一旦 LLM 反复调一个 Skill 失败你可以直接从日志里看到它到底传了什么参数而不是打开黑盒瞎猜。4. 实战跑通从安装 PicGo 到 Skill 返回 URL4.1 安装 PicGo 并开启本地服务第一步去 PicGo 的 GitHub Releases 页面下载对应系统的安装包。我的是 macOS下载 dmg 安装完直接打开。Windows 用户下载 exe安装过程一路 Next 就好。安装完打开主界面进入“设置” - “PicGo 设置”你会看到“PicGo Server”相关选项端口默认 36677。把开关打开PicGo Server 就开始监听了。这一步不做后面所有请求都会连接失败我见过太多人卡在这里。提示PicGo 在 macOS 上如果开启了系统代理个别版本可能影响本地服务的响应行为。实测下来影响不大但如果你遇到“请求发出去但一直不返回”的怪现象先尝试关掉系统代理再做最小复现。检查监听状态可以用 lsofmacOS/Linux或 netstatWindows# macOS / Linux lsof -i :36677 # Windows netstat -ano | findstr 36677正常情况你应该看到有进程在 LISTENING 状态PID 指向 PicGo 进程。看到这个输出才说明本地服务真的活着。4.2 配置图床以 GitHub 和 SM.MS 为例PicGo 服务只是“传话的”真正决定图片传到哪里的是图床插件配置。我常用两种分别代表“私人定制”和“快速上手”。GitHub 图床在 PicGo 设置里选择 GitHub填写 token 和仓库名owner/repo还要选一个存储分支和自定义域名。GitHub 图床的优点是不限上传次数缺点是国内访问速度看网络心情还有一个坑是仓库体积过大后访问性能明显下滑大文件图片尤其明显。所以我的建议是 GitHub 图床只放小体积截图大图走正规对象存储。SM.MS 图床注册账号拿 token在 PicGo 设置里选 SM.MS填 token 就行。免费版对单张图片大小和存储容量都有限制胜在稳定、域名访问速度快。适合用来临时传几张演示图不适合做正式的存量图床。配置完成后可以直接在 PicGo 主界面的“上传区”拖一张图进去测试。上传成功后通知区域会显示已经复制到剪贴板的 URL这说明图床链路是通的。注意这一步是在验证“PicGo 本身能不能传图”它通了你的 Skill 才可能通。4.3 用 curl 先做一次冷验证很多人的毛病是一上来就写代码然后出了问题在代码层排查半天。我的习惯是先用 curl 验证服务本身把“服务问题”和“代码问题”切分开。curl -X POST http://127.0.0.1:36677/upload \ -H Content-Type: application/json \ -d {list:[/Users/me/Desktop/demo.png]}如果返回 JSON 里 result 有 URL恭喜你说明 PicGo 服务和图床配置完全正常。这时候再去调 Skill心里就有底了。如果 curl 这一步就已经失败问题一定在 PicGo 这边跟你的语言、代码无关。4.4 把 Skill 接入 AI 助手一个最小示例我在自己的助手项目里是把 Skill 注册到 agent 的 function list 里的。下面是一个极简的注册代码展示意图层怎么把自然语言请求分发到这个 Skillfrom picgo_skill import upload_images def handle_tool_call(func_name, arguments): if func_name picgo_upload: return upload_images(arguments[image_paths]) ...这样当用户说“把 /tmp/screenshot.png 传到图床给我链接”时助手解析出的动作就是调用 picgo_upload参数是 [/tmp/screenshot.png]。整个过程对用户几乎是透明的他只知道“我说了一句话链接就回来了”。这里有一个实操体验很想分享AI 助手调用 Skill 时它传的路径往往不是它能“看到”的路径而是它“猜测”的路径。比如多轮对话里用户说“刚才那张图”LLM 如果没有上下文记住具体路径就会乱猜一个。解决方法是在上层对 LLM 输出的 image_paths 做一次存在性校验如果校验不过不要直接把错误返回给 LLM 让它瞎改而是提示“请用户在对话中重新提供图片的准确路径”。这个小设计能省掉无数失败的循环调用。4.5 实测效果与性能观察我用一张 1280x720 的 PNG 截图做了实测从 Skill 收到请求到拿到 URL本地链路耗时在 200ms 以内不含图床上传的时间而图床推送环节根据网络情况在 0.5~3 秒之间徘徊。也就是说这个 Skill 的实际瓶颈永远在图床网络而不是本地服务。批量传 10 张小图时PicGo 会串行逐个上传总耗时大概是单张时间的累加。如果你的场景对批量上传速度有要求建议把 list 长度控制在 5 张以内或者在前端做并行调用。5. 常见问题排查上传失败的 6 个高频坑5.1 PicGo 服务没起来端口怎么查出现“连接失败”时第一件事不是改代码而是确认服务进程。按上面说的用 lsof 或 netstat 查 36677 端口。如果端口没监听大概率是这三种情况PicGo 没打开PicGo 打开了但设置里的 Server 开关没开PicGo 开了但绑定到了别的端口。我印象比较深的一次是PicGo 升级后设置被重置Server 开关默认又变回关闭结果我排查了半天服务代码最后发现是版本升级把配置搞丢了。所以升级 PicGo 之后建议第一时间检查 Server 开关状态和图床配置别让升级变成隐形炸弹。5.2 successfalse 的常见原因如果 HTTP 请求通了但返回 JSON 里 success 是 false问题几乎都在 PicGo 的图床侧。我遇到的典型报错有“上传失败: 仓库不存在”GitHub 仓库名写错或者 token 没有该仓库的写权限“upload failed”没有具体原因的通用失败多半是网络不通、token 过期“文件超过大小限制”SM.MS 免费版对文件大小有限制压缩或换图床即可。针对这类问题建议直接到 PicGo 主界面上手动传一次同样的图观察它的完整报错和日志。PicGo GUI 的报错比 HTTP 接口返回的 message 详细得多能帮你快速定位是 token、仓库还是网络问题。5.3 文件路径的跨平台坑这是 Skill 实际使用时的高频踩坑点。Windows 路径是 C:\Users\xxx\Desktop\demo.pngmacOS 路径是 /Users/xxx/Desktop/demo.png。如果 Skill 跑在 Windows 上而调用方给出的是 POSIX 风格路径或者反过来那么路径校验第一关就过不去。解决办法是严格规定image_paths 必须是“运行 PicGo 的那台机器”上的绝对路径。任何跨机器的路径传递都不在本 Skill 范围内。如果你需要从远端上传那应该在远端先把文件下载到 PicGo 所在机器再调用 Skill。这一步看起来很笨但它是保持 Skill 实现简单的关键也让错误边界非常清晰——路径错了一定是调用方的问题而不是 Skill 的锅。5.4 中文文件名与特殊字符另一个隐蔽的坑是文件名里的中文、空格和特殊符号。PicGo 在读取本地文件时一般没问题但图床返回 URL 时有些图床会保留中文原样有些会做 URL 编码还有些会直接把中文替换成随机 ID。如果你后续要把 URL 拼进 Markdown注意不要对 URL 做二次编码否则两次编码后的地址大概率是 404。我的建议是上传前在 Skill 入口做一次文件名规范化把中文和空格替换成短横线例如“我的截图 001.png”改成“my-shot-001.png”。这能避开非常多平台兼容性问题。别嫌多此一举把问题消灭在入口比在 URL 层面补救便宜得多。5.5 同机限制远端机器调用不了本地服务因为 127.0.0.1 只监听本机所以你的 Skill 若部署在服务器 A而 PicGo 在你自己笔记本上那无论如何都连不上。很多人想“在笔记本上开发、在服务器上跑”就会撞上这个限制。要打破这个限制不是让 PicGo 改绑定 0.0.0.0有安全风险而是把 Skill 和 PicGo 部署在同一台机器。如果确实需要跨机器更稳妥的方案是通过加密隧道把本机端口暴露给那台服务器但这属于网络架构改造不在本文范围。我自己的实践经验是一台常年开机的迷你主机装 PicGo所有自动化任务都指向它一劳永逸。5.6 本地服务启动失败的共性问题最后说一个和 PicGo 相关的“通用型”问题。有时候你的机器上某个本地服务就是起不来而且报错很诡异比如 Windows 下常见的“Windows 无法启动 Windows Installer 服务位于本地计算机上。错误 1053服务没有及时响应启动或控制请求”。遇到 1053 这类“服务启动超时/没有响应”的报错先别急着重装系统按这个顺序排查去 services.msc 确认服务的启动类型是不是“自动”如果不是改成自动再手动启动一次打开事件查看器eventvwr.msc看 Windows 日志 - 应用程序找到对应时间点的错误事件那里通常有真正的异常堆栈用命令重注册对应服务的可执行组件比如 msiexec 相关服务可以用msiexec /unregister之后msiexec /regserver重置如果以上都不行考虑是否有杀毒软件或安全策略拦截了服务启动临时退出后再试。这套思路适用性很广本质是“服务启动失败先看事件日志里的具体原因再做针对性修复而不是凭报错编号瞎猜”。PicGo Server 虽不是 Windows 系统服务但它“启动不了”的排查逻辑也一样先查日志、查端口、查进程残留一层层剥总能定位到根因。注意上面 1053 的排查步骤主要用于系统级服务故障。PicGo 本体如果双击打不开优先查是不是被杀毒软件隔离、是不是多开冲突任务管理器里是否已有 PicGo 进程残留。6. 经验沉淀与后续扩展6.1 “本地服务 Skill”模式的适用边界写到这里你应该能感受到PicGo-Skill 本质是一个“小服务 薄客户端”的典型应用。它的优点非常多但也有明确的适用边界。如果你的场景是这几个我强烈建议采用本机或局域网内的自动化工具需要上传图片AI 助手需要把生成或截图文件变成外链多语言项目想少写图床 SDK 的重复代码。但如果你的场景是以下这些就需要重新评估纯线上 Serverless 函数里要上传图片——根本没有“本地 PicGo”可言高并发生产接口——PicGo 桌面进程不是为高并发设计的扛不住大量并发上传对图床凭证安全级别要求极高的合规场景——你更应该在服务端做独立的凭证托管而不是依赖一个桌面应用。一句话这个组合适合“轻量、本机、自动化”不适合“重负载、分布式、纯云端”。6.2 可以继续扩展的方向我在实际使用中已经尝到了甜头接下来准备做几个扩展增加“图片处理前置管线”在调用 Skill 前先用本地脚本或 CLI 做压缩、裁剪、加水印再把处理后的图片路径传给 PicGo。这样 AI 生成的超大图也能变成体积可控的外链。增加“URL 后处理模板”Skill 之外加一层格式化器根据目标平台Markdown、HTML、聊天机器人自动生成不同格式的图片引用。把同一个“本地服务 Skill”模式复制到其他本地能力上比如本地 OCR、本地视频转码只要本地有一个服务在 127.0.0.1 上监听你的 Skill 就能用同样的 HTTP 调用模式去对接。从我个人体会来说这个项目给我最大的启发不是“PicGo 真方便”而是“很多重复的脏活其实早就被某个桌面工具解决了只是它额外暴露了一个本地接口。聪明地复用它比重新造一个轮子要省太多成本。”如果你也正在为图床上传的事挠头不妨先打开你电脑上 PicGo 的设置看一眼找到那个 Server 开关你的体验可能就从此不一样了。