日常写博客会比较多，我也经常需要在 Markdown 里粘贴图片，自动上传到 OSS 并返回链接。刚好有时间就去找了找相关工具, 也确实是有现成的, 插件市场里有一个 aliyun oss upload image，但代码是几年前的，源码仓库也 404 了...
顺着 fork 链找到一份残留代码，clone 下来，开工
工具：Qoder 社区版 + GLM-5.2
项目：https://github.com/felixzhang-glitch/vscode-aliyun-upload-image
先建 Wiki
拿到一份陈旧代码，第一件事很有必要的可能是先搞清楚它到底做了什么、实现路径，以及是否有坑。
Qoder 社区版的 repo wiki 是付费功能(得加钱)，所以自己写了个 wiki skills 做简单复刻。跑了一遍，生成系统架构、模块详解、核心流程三部分文档。代码只有
extension.js179 行加lib/upload.js73 行，但 Wiki 梳理出来之后，几个问题直接暴露了：
- 依赖了
axios和shelljs，实际上代码里根本没用到 expiration变量初始值 0 且从未更新，客户端复用逻辑完全失效- 只支持 PNG，剪贴板脚本里的格式检测写死了单一类型
package.json里残留了原作者邮箱和 fork 故事
反正肯定会有坑，先记录下来，让 Agent 后面自己处理就好
Spec 驱动，先写方案再干活
打开 spec 模式，输入需求：
粘贴图片到 VSCode 直接转换为 Aliyun OSS URL，需要支持常见图片格式，转化为公开 URL，最后发布博客使用。重构代码，保证稳定性，删除冗余代码和原作者私人信息。
剩下的等它自己干。几轮反馈确认——主要是确认方案里哪些命令该删、哪些该留——执行阶段就不用再管了。
改动不算大，但很琐碎。它逐文件完成的事情：
- 接管
Cmd+V/Ctrl+V，智能区分图片和文本。有图片上传 OSS，没图片回退正常粘贴 - 支持 PNG / JPEG / GIF / WebP / TIFF，通过 magic bytes 检测实际格式，扩展名不对就自动重命名
- Region 格式自动补全。第一次配置我填了
cn-hangzhou，SDK 报socket hang up，排查发现它是拿region直接拼 URL 的，补上oss-前缀就通了 - 移除
axios、shelljs、moment三个冗余依赖，moment用原生 Date 替代 - 删除原作者邮箱、个人域名、fork 故事，
overview.md直接删掉 - 代码从回调模式改成 async/await，
var改成const
踩点小坑
Region 的问题值得单独说一句。
报错日志是 socket hang up，请求的 URL 里 domain 是 public-files-dev.cn-hangzhou.aliyuncs.com——少了 oss- 前缀。原因是 ali-oss SDK 把 region 参数直接拼进 endpoint，不做任何处理。你填 cn-hangzhou，它就发到 cn-hangzhou.aliyuncs.com，这个域名不处理 OSS 请求，连接直接挂掉。
解决方式：在 upload.js 里加了一行自动补全，region 不以 oss- 开头就自动补上。然后顺手在 extension.js 里也加了一个 normalizeRegion()，域名替换的时候不会因为 region 格式不一致而匹配失败。
vibe coding 有点问题很正常, 难道不是么
配置 OSS，一句话搞定
需要一个 public 的 OSS bucket 和对应的 AK/SK。
懒人就不去阿里云控制台点来点去了。换个 skills，一句话：
创建 OSS bucket，配置 RAM 用户，生成 AccessKey，权限设为公共读
配置写进 VSCode 的 settings.json
打包
验证通过，打包。npx vsce package 的时候遇到几个小问题：
- 项目里有
yarn.lock但我用的是 npm，vsce默认检测到yarn.lock就调yarn，需要加-no-yarn repository字段为空，vsce要求必须有，补回了 GitHub 地址- 没有 LICENSE 文件，
printf 'y\n'管道自动确认
最后产出一个 .vsix，code --install-extension 就装上了。这个包是 macOS Apple Silicon 上打的，README 里写了其他平台自己打包的流程。
Vibe Coding的一些建议
这次重构虽然项目体量不大，但也验证了一套适合 AI 辅助开发的流程：先 spec，再 goal，查漏补缺，最后审查上线
在开始任何需求之前，先用 spec 模式把需求描述清楚，让 AI 输出一份完整的方案说明，确认理解一致、边界清晰，避免“边做边猜”。这一步最好能像本文一样，把关键约束、支持格式、删除范围都写进需求里
方案确认后，切换到 goal 模式开始执行。goal 模式更适合拆解任务、逐步实现，过程中可以穿插验证——比如运行测试、手动检查关键路径，确保每一步都符合预期。查漏补缺这一环尤其重要，像 Region 补全、格式检测这些细节，往往是自动生成容易遗漏的地方
准备发生产前，再走一轮 代码审查（/ultra-review），让 AI 对最终改动做一次全局审视，检查是否有未处理的边界情况、安全风险或残留的冗余代码。审查通过后，整个流程就变成了 spec 驱动 → goal 开发 → 审查发布 的闭环
当然，工具能帮你理清代码，但“为什么这样做”——那个判断还是得人来做。对于更大的项目或多轮迭代的场景，建议补充 Rules 和 Agents.md，让 AI 的决策更稳定，也让这套流程的复用性更高
参考
工具：Qoder 社区版 + GLM-5.2
项目：https://github.com/felixzhang-glitch/vscode-aliyun-upload-image
