VPS + 青龙调度：把网文连载的每日更新做成一条自动化流水线

每天手动在几个站点发章节，是我之前最不想干、又最不敢漏的一件事。漏发一天读者就断更，发错顺序后台编辑会来找。索性花了个周末，把这件事做成了一条定时流水线：一台 VPS 上跑青龙面板做调度，章节文本放在 git 仓库里，每天自动「同步—构建—生成草稿—发布」，每本书每天一章，外加一个简陋但够用的 Web 控制面板，专门处理定时任务之外的手动干预。

先说整体长什么样

• 一台 VPS：跑所有东西。没什么特殊要求，稳定、能跑定时任务、有公网就行。
• 一个 git 仓库：所有书的章节文本都在仓库里，按「书 / 卷 / 章节序号-标题」组织。章节只追加、不改历史文件，流水线永远只读仓库，不写回。
• 青龙面板：只做一件事——定时触发。每天固定时间跑一次主任务，重试策略也配在青龙里。
• 一套发布脚本：真正的业务逻辑，分四个阶段：sync（拉仓库）、build（格式转换）、draft（按台账生成草稿）、publish（发布并更新台账）。
• 一份台账（ledger）：记录每本书「已发布的最新章节序号」。这是整个流水线最重要的状态，顺序校验和幂等都靠它。
• 一个 Web 控制面板：三个按钮——手动同步、生成草稿、立即发布。定时任务之外，比如某本书要加更、或者某天定时任务没跑起来，就在这里手动点一下。

流水线每天在干什么

1. 同步：git pull 拉取仓库最新章节。拉取失败直接告警退出，不继续往下走——用旧版本发章节，比不发更可怕。
2. 构建：把 Markdown 章节转成目标站点编辑器接受的格式，主要是分段、标题层级和特殊符号转义。构建是纯函数：输入章节文件，输出待发布文本，不碰台账。
3. 生成草稿：读台账，算出每本书的「下一章」序号，只为下一章生成草稿。硬规则：一次只生成一章，不多不少。
4. 顺序校验：发布前再核对一次——待发布章节的序号必须等于「台账序号 + 1」。跳号、重号直接拦截，这是我给自己设的最后防线。
5. 发布：逐个站点提交，每本书每天只发一章。发完立刻更新台账，台账更新成功才算一次发布完成。

Web 控制面板为什么还留着

自动化跑起来之后，手动操作的需求并没有消失：

• 某本书临时要加更，不想等明天的定时任务；
• 某天定时任务因为网络抖动没跑起来，需要手动补一次；
• 发布前想先看一眼今天生成的草稿内容对不对。

所以面板上就三个动作：手动同步、生成草稿、立即发布，每个动作都复用同一套脚本，只是跳过定时调度。面板本身很简陋——一个单页、几个按钮、一个日志输出框——但它解决的是「自动化之外的那 5% 场景」，而这 5% 恰恰是半夜会把你叫醒的部分。

踩过的几个坑

1. 时区：VPS 默认是 UTC，青龙的定时任务一开始按 UTC 跑，章节总在北京时间凌晨发布。改成 Asia/Shanghai 时区后才正常。教训：凡是和「每天」有关的任务，第一件事先对时区。
2. 幂等：发布脚本必须能安全重跑。有一次发布到一半网络断了，重跑差点把同一章发两遍。现在的规则是：台账没更新就不算发布成功；重跑时会先查站点上是否已存在该章节，存在则跳过。
3. 草稿和发布是两个状态：一开始我把「生成草稿」和「发布」写在一个脚本里顺序执行，结果有一次草稿内容有问题，发布也跟着出去了。现在强制分开：草稿生成后必须经过校验（至少是自动的序号校验），发布是独立的一步。
4. 登录态会过期：站点登录的 cookie / session 不是永久的，脚本里加了发布前的登录态检查，失效就告警而不是硬发。这个告警已经救过我两次。
5. 台账是单点：台账文件损坏等于流水线失忆。所以每次更新台账前先备份一份，保留最近几天的版本。文件很小，备份成本忽略不计。

现状

现在每天早上我只需要看一眼：青龙任务是否成功、台账序号是否正常 +1。大部分时间什么都不用做，偶尔在控制面板上点一次手动发布。下一步想加的是发布结果的推送通知——现在还是靠每天早上人工看一眼，不够优雅，但够用。

回头看，这套东西的技术含量并不高：定时任务 + 脚本 + 一个状态文件。它的价值在于把「每天不能忘、不能错」的事情，变成「每天只需要确认一次」的事情。如果你也在做需要固定频率更新的内容（连载、日报、定时同步），可以参考这个思路：先保证幂等和顺序校验，再谈自动化。