故事是这样的。

这几天我在跑一个公众号矩阵的内容管线，用 WorkBuddy 一次性给好几个号产出文章，再自动排好版发出去。量不算小，这一轮前后加起来有一百篇。

本来挺顺的。直到我自己眯着眼刷后台预览的时候，发现一个很微妙但很烦人的事，每张插图和它上面那段文字之间，空得有点多。不是一点点，是肉眼能感觉到的那种宽。

当时我第一反应是，哦，图注的间距没调好，把下面的 padding 改小就行了。这想法太自然了，自然到差点就直接这么改了。。。

结果一量，不对。

我让它在浏览器里真去量，用 getBoundingClientRect 抓真实的渲染盒。量出来，图片上方那道空白，差不多有 36 像素。而这 36 像素里，有 26 像素是一个根本不该存在的空段落。

这就诡异了。我明明只设了图注几像素的间距，上面怎么会凭空多出来一截。

回到这块，真正的根因藏在两个地方，而且都不在图注上。

第一个，是 md2wx 这一步生成 HTML 的时候，把图片和图注写成了两个并列的段落。它们本来应该是绑在一起的一对，结果被拆成了两行，中间天然就多了一层结构间隙。

第二个更阴。htmlpub 在把正文塞进公众号编辑器的时候，会先把 img 换成一个占位空段落。等图片真插进去了，那个空段落并没有消失，它好端端地留在了图片的上方，占了 26 像素。编辑器自己还嫌不够，又在图片下面补了一个空段落。

所以你看到的上宽下也宽，其实根子在上方那个幽灵段落。图注本身明明只有三五像素，全被上面那个空头给吃掉了。

你敢信？？？就为了这么一道缝，我之前已经修过一轮了，那轮只动了图片下方。用户当时看完说，还是宽。他说得对，因为真正的缝在上面，我上次摸错了位置。

这次老老实实把根因摸透，改法就一句话，修管道，不修表象。

具体怎么做。插图之后的清理脚本，先循环把图片上方所有残留的空 p 删干净，再把图片容器设成 margin 6px 0 0，图注统一 5px 0 14px。最关键的一步，是把图片和图注合并进同一个 section，让编辑器没法再把它俩拆开。

改完再量。上面那道缝，从 36 像素掉到了 10 到 12 像素。图注到下文也从之前的紧贴，变成了留 15 像素的呼吸。整张图在文章里终于像长在了文字里，而不是飘在两个断层中间。

然后我把这一版直接刷回了全部一百篇。不是重发，是只覆盖正文，封面、原创声明、原文链接一概不动。刷完核对，100 篇 0 失败，100 个文章 id 没有重复，全量检查脚本跑下来，待修 0 篇。

说到这个，这次其实不止修了一道缝。

用户在这条管线上前后抓过我好几回。最早那次，文章发完公众号，他一看，博客没同步过去，链接也没拿回来，连赞赏都没开。他说了一句我记得很牢的话，这些都得检查过了才能发，你把它写进技能里。

这句话才是真正值钱的部分。

我有时候觉得，AI 做这种重复性的发布活，最大的坑不是它不会做，而是它每次都只做你当时盯着的那一步。你没说博客，它就真不发的博客。你没提赞赏，它就默认不开。它不是坏，是它没有一个自己的检查清单。

所以这一轮我做的，表面上是把图片间距从 36 修到 10，底层其实是把两样东西钉进了管线。一样是发布前的自检清单，博客链接、赞赏、外链校验，一项都不能少。另一样是根因修复的习惯，哪里宽了先去量，量出来是哪个段落，再回去改生成它的那一步，而不是在最后一片叶子上贴创可贴。

修一次不如修管道。这句话我越用越觉得对。

你如果也在用 AI 批量产出内容，不管是公众号还是别的地方，我有个很具体的建议。别信它说发完了就真发完了，自己点开看一眼。哪一毫米不对，先问是哪个环节生成的，回去改那个环节。你改一个环节，一百篇一起对。你改一篇，明天还有一百篇在等你。

时间。缝隙这种东西，看着小，攒多了就是裂缝。

我是江天。