给博客发布助手加上照片墙维护能力

这次更新了什么

上一篇文章里，我已经把 fffcx-blog-publisher 写成了一套博客发布工作流：它知道 Hexo 的目录结构，知道 Redefine 的写作约定，也知道在正式修改文件前要先给我方案。

这一次更新没有重做整套系统，而是把它往一个更具体的方向推进了一步：让它开始能够维护博客里的照片墙。

也就是说，它现在不只是“帮我写文章”的助手，还要能在我发送照片之后，理解这些照片应该如何进入 Redefine 的 Masonry 相册页：图片放在哪里，文件名怎么整理，标题和描述怎么写，宽高怎么读取，EXIF 要不要打开，以及 masonry.yml 应该怎样更新。

这听起来像是一个很小的功能，但其实它刚好补上了博客发布流程里很容易出错的一环。

为什么照片墙需要单独处理

Redefine 的照片墙并不是普通 Markdown 文章里的图片列表。

它有自己的页面模板。相册页通常是：

1	source/masonry/index.md

这个页面的 Front Matter 里需要写：

1	template: masonry

真正的照片数据则放在：

1	source/_data/masonry.yml

也就是说，如果把照片墙误写成普通文章里的 ![图片](/images/...)，表面上也许能显示图片，但它并不是 Redefine 官方的 Masonry 实现。之后标题、描述、宽高、EXIF、图片查看器这些能力都会变得混乱。

所以这次更新最先写进去的规则就是：不要把 Masonry 当成普通 Markdown 图集，也不要自行发明不存在的 Gallery 标签。

它现在会怎样处理照片

以后如果我说“把这些照片放进照片墙”，这个 skill 不应该立刻动手改 masonry.yml。

它要先做三件事。

第一，读取现有照片墙配置。它需要检查：

source/masonry/index.md
source/_data/masonry.yml
_config.redefine.yml
现有图片目录，通常是 source/images/masonry/

这样做是为了确认照片墙页面是否已经存在，template: masonry 是否正确，导航路径是否和页面路径一致，已有照片条目是什么风格。

第二，分析这次收到的照片。它需要逐张判断照片主体、横竖比例、原始宽高、是否有可识别人物、是否可能包含隐私信息、是否适合作为首图、是否和其他照片太相似。

这里我特意给它加了一条边界：不能编造地点、人物身份、拍摄时间和摄影参数。看不出来的东西就保持为空，或者只写客观可见的画面。

第三，先给我一份实施方案。方案里至少要说明：

收到几张照片
建议加入几张
哪些建议暂不加入，为什么
推荐排列顺序
文件命名规则
存放目录
标题和描述风格
EXIF 是否开启
需要修改哪些文件
发布前要做哪些检查

只有我确认之后，它才能真的修改文件。

文件名、宽高和 EXIF

这次更新里，我把几个很具体但很重要的细节写进了 skill。

照片文件名要使用稳定的英文命名，例如：

1 2	sysu-campus-20260714-01.webp guangzhou-night-20260714-01.webp

不使用中文、不使用空格、不保留 IMG_1234 这种无意义名称，也不随便改已经发布过的旧路径。照片默认放在：

1	source/images/masonry/

在 masonry.yml 里，每张照片推荐写成：

- image: /images/masonry/sysu-campus-20260714-01.webp
  width: 1920
  height: 1280
  exif: true
  title: 夏日校园
  description: 午后的阳光落在教学楼与树影之间。

其中 width 和 height 必须尽量使用真实原始尺寸。这个规则很重要，因为 Masonry 页面需要提前知道图片比例，才能减少加载时的布局跳动。

同样，EXIF 也不能机械地全部打开。原图有有效 EXIF 时可以建议开启；截图、海报、网络图片、压缩多次的图片通常关闭。远程图片还要考虑 CORS，含有 GPS 信息的照片则需要提醒我检查隐私。

它可以分析和建议，但不能伪造。

标题和描述也有边界

照片墙不是素材仓库。标题和描述需要有一点摄影感，但不能变成夸张文案。

我给它设定的标题规则是：简短、自然、准确，一般控制在 4 到 12 个汉字。描述则尽量客观，控制在 15 到 50 个汉字，不重复标题，也不编造照片背后的故事。

比如：

1 2	title: 午后的逸仙路 description: 阳光穿过树叶，在安静的校道上留下细碎光影。

这类描述的重点不是“写得多漂亮”，而是让照片多一点可以被记住的语境。它应该像一个轻轻的标注，而不是替照片抢话。

更新后的发布检查

为了让这个能力真正可用，我也把照片墙加入了发布检查清单。

现在它需要检查：

source/masonry/index.md 是否存在
Front Matter 是否包含 template: masonry
source/_data/masonry.yml 是否存在且 YAML 格式正确
_config.redefine.yml 里是否有相册导航
图片路径是否真实存在
是否有重复路径
宽高是否真实
EXIF 是否合理
是否可能暴露 GPS 隐私
/masonry/ 页面能否打开
手机端显示是否正常
控制台是否有图片 404

最后才是常规的 Hexo 流程：

1
2
3

hexo clean
hexo generate
hexo server

确认没有问题之后，再考虑：

1	hexo deploy

这条顺序也被写进了 skill：部署不是自动化的第一步，而是检查通过之后的最后一步。

我想让它变成怎样的助手

这次更新让我更确定了一件事：一个真正好用的博客助手，不应该只会生成内容，还应该懂得维护内容进入站点的方式。

文章有文章的入口，项目有项目的入口，照片也有照片自己的入口。它们都属于博客，但不应该被压成同一种 Markdown 形态。

照片墙尤其如此。它不只是“把图片放上去”，而是一次小型编辑：选择、排序、命名、描述、检查隐私、确认路径、预览页面。这里面任何一步做得太随意，最后都会变成站点里的长期负担。

所以我给这个 skill 加上的不是一个炫技功能，而是一组边界：

不覆盖旧照片
不编造信息
不擅自迁移路径
不把官方 Masonry 写法改成自创组件
不在没有确认时直接修改正式文件

这些规则会让自动化慢一点，但也让它更可靠。

小结

这次更新之后，fffcx-blog-publisher 更像是一个会维护博客秩序的助手了。

它原本负责文章、项目、HTML 页面和发布流程；现在，它也开始理解照片墙这种更偏视觉整理的内容。以后我只需要把照片交给它，它就应该能先读懂当前相册结构，再给出一份清楚的处理方案，等我确认后再更新 masonry.yml 和相关文件。

我喜欢这种进展：不是一下子做一个巨大的系统，而是把真实会用到的环节一点点补上。

长期来看，博客自动化最重要的可能不是“更快发布”，而是让每一次发布都更少遗漏、更有秩序，也更像这个站点本来该有的样子。

Welcome to FFFCX's Blog