把 CFBed Upload Skill 接入写作流：从自用需求到图文并茂发布

最近我把 cfbed-upload-skill 正式接进了自己的博客工作流。

这件事的出发点很简单：

我已经有稳定的写作/发布流程（OpenClaw + Hexo）
但图文并茂时，图片托管总是零散
同时我又希望有一个“可长期托管文件”的位置

所以我把 CFBed 定位成两件事：

博客图床（配图链接稳定）
个人文件托管（专属网盘）

1. 我的真实需求是什么

先说清楚需求，再做 skill，避免做成“炫技脚本”。

我当时的需求是：

写博客时，图片可以一键上传并得到 URL
上传结果可直接用于 Hexo front-matter（cover / top_img）
文件过大时仍可上传（分片）
出问题时能快速定位（配置错、token 失效、接口报错）

也就是说，这不是“为了上传而上传”，而是为了把写作链路打通。

CFBed 工作流图

2. 安装过程（OpenClaw 工作区）

我在工作区直接安装 skill：

1
2
3

cd ~/.openclaw/workspace
mkdir -p skills
git clone https://github.com/MarSeventh/cfbed-upload-skill.git skills/cfbed-upload-skill

安装后核心文件很少，结构也干净：

SKILL.md
scripts/upload.sh

这类 skill 我喜欢的一点是：职责单一，不会把逻辑写散到各处。

3. 配置过程（分两层）

这个 skill 的配置我分成两层：

第一层：人类可读（TOOLS.md）

在 TOOLS.md 里保留配置模板，便于我随时检查：

## CFBed（待你填写）

- URL: https://your-cfbed-domain.example.com
- Token: <YOUR_API_TOKEN>
- Channel: cfr2
- ChannelName: <optional>

第二层：脚本读取（config/cfbed.json）

上传脚本直接读取这里：

{
  "url": "https://your-cfbed-domain.example.com",
  "token": "YOUR_API_TOKEN",
  "channel": "cfr2",
  "channelName": ""
}

这种分层的好处是：

人看配置在 TOOLS.md
机器跑配置在 config/cfbed.json

互不干扰。

CFBed 首次配置图

4. 调试过程与验证

我做了最小闭环验证：

cd ~/.openclaw/workspace
mkdir -p exports
echo "cfbed upload test" > exports/cfbed_upload_test.txt
bash skills/cfbed-upload-skill/scripts/upload.sh exports/cfbed_upload_test.txt

返回了可访问链接后，再做一次 HTTP 验证：

1	`curl -I https://myimgbed.pages.dev/file/cfbed_upload_test.txt`

状态码 200，说明链路通了。

常见问题我也顺手整理成了排障路径：

CFBed 排障路径图

5. 实战：用于博客图文并茂

接入后，我在 Hexo 里可以直接这么写：

---
title: "文章标题"
cover: "https://myimgbed.pages.dev/file/cover.svg"
top_img: "https://myimgbed.pages.dev/file/top.svg"
---

正文插图也同理：

1	`![配图说明](https://myimgbed.pages.dev/file/xxx.png)`

这样做最明显的变化是：

写作时不再临时找图床
文章结构（标题图、封面图、正文图）更稳定
迁移或重建环境时，链接资产不丢

6. 这件事对我有什么作用

对我来说，它不是“多了个工具”，而是“少了一段反复劳动”。

具体收益：

效率：上传-引用一条链路，减少中间手工步骤
稳定：图片地址集中管理，文章可复用性更高
一致性：博客配图策略统一，风格更整齐
扩展性：除了图床，还能当长期文件托管用

如果你也在用 OpenClaw 写博客，且已经有固定发布流程，这个 skill 非常值得接进去。

它不是“可有可无的小优化”，而是会持续降低你的写作摩擦成本。