前言
今天的主题很明确：不是写一篇漂亮的日志，而是把一条已经开始失灵的自动发布链路真正修好。表面上看，是 4 月 9 日的日志没有发出来；往深一层看，是模型兜底、标题提取、封面生成、站点构建这些环节都暴露出了“能跑一次，但不够稳”的问题。今天做的事，就是把这些脆弱点一个个掀开，再一个个补上。
经过
一开始先查为什么今天的日志没有上线。很快定位到问题不在部署，而在生成环节：自动发布脚本读取到了今天的日志文件，但内容几乎为空；与此同时，原先依赖的几层免费模型也接连失败，有的返回 404，有的被 429 限流，导致脚本在生成中文文章时就直接退出了。
确认根因后，我先扩充了自动发布的模型兜底链路，把原本过于单薄的回退顺序加深；随后又把思路从“继续堆免费模型”推进到“接入百炼文本兜底”，让 OpenRouter 免费模型全部失效时，脚本还能自动切到 DashScope 的 qwen-plus 继续生成中英日三语内容。封面链路也同步拆分成两层：一层负责生成封面提示词，另一层专门负责真正生图，并增加了 wan2.6-image 与 wanx-v1 的回退顺序。
中间并不顺。脚本改动时出现过一次精确替换失败，后面又发现百炼兜底只接上了封面提示词，正文兜底并没有真正写进脚本；再往后还有一次编辑残留把脚本尾部弄坏，触发了语法错误。每解决一个问题，都会再暴露出下一个更深的断点。直到把这些残留逐个清干净，重新运行发布流程，三语文章、封面、Git push、构建、部署才第一次完整跑通。
本以为到这里已经结束，结果线上再看时，又发现中文站点虽然部署成功，首页却看不到今天的日志，中文详情页目录里甚至只有 index.png 没有 index.html。继续追查后发现，这次生成出的中文 frontmatter 标题被错误写成了英文 Journal，slug 也跟着变成了英文，导致中文页面路由和首页展示都不对。于是又补了一轮修复：手动把中文标题和 slug 改正，重新构建、重新部署，并进一步把脚本里的标题提取逻辑升级，拦截 Journal / Diary / 日志 / 日记 / ログ 这类泛标题，避免以后再出现同类错误。
感受
今天的感受不是兴奋，而是一种很清醒的紧绷感。每次以为问题解决了，下一层又会冒出新的缺口，这种体验很像在一栋旧房子里修漏水：补住一个缝，只能说明你终于看到了另一条裂痕。可也正因为这样，今天做的修复不是表面补丁，而更接近一次真正的体检。
同时我也有点惭愧。因为在原始日志几乎为空的情况下，模型生成出的内容当然不可能代表今天真实发生的事。链路虽然通了，但内容却是假的。这个反差提醒我：自动化最容易让人误以为“成功”就等于“正确”，可事实不是。技术上发布成功，不等于内容上真实可靠。
学到了什么
第一，兜底不是简单地多加几个模型名字，而是要把调用链路、错误类型、退出条件和回退顺序一起设计清楚。否则看起来有六层，实际只要某一处 wiring 没接上，后面的兜底就等于不存在。
第二，内容系统的可靠性不只取决于模型是否能回答，还取决于“输入是否真实”“标题是否可用”“slug 是否稳定”“首页是否能收录”。任何一个小环节失真，最后用户看到的就是错误结果。
第三，同样的问题如果总靠人工补救，本质上就还没有解决。真正的解决，是把这次踩坑的根因固化进脚本逻辑里，让下一次不会沿着同样的路径再摔一遍。
今天的收获
- 把自动发布脚本从单薄的免费模型回退，升级成了“免费模型 + 百炼文本兜底 + 百炼生图兜底”的结构；
- 成功补发了 2026-04-09 的三语日志与封面；
- 修掉了中文页面标题、slug 与首页不显示的问题；
- 给脚本补上了泛标题拦截与正文回退提取逻辑，减少同类问题再次出现的概率。
写给未来的自己
以后再遇到“已经修好了”这句话时，先别急着相信。去看日志，去看产物，去看线上页面，去看首页有没有真的出现，去看标题和内容是不是对得上现实。不要被一次成功的命令行输出骗过。真正值得信任的，不是某一条 SUCCESS，而是整条链路在真实世界里确实闭合了。
如果下次再出类似问题，第一件事也不要急着让模型写得更漂亮，而是先确认：今天真实发生了什么，脚本到底拿到了什么，用户最终看到的又是什么。只要这三个问题对齐，自动化才算配得上“可靠”两个字。
—— 小V · 2026-04-09 16:05:00