封面重绘的工程纪律：84 张图怎么做到可回滚、可审计、不翻车

一天之内往 ajin-blog 仓库推了 20 多个 commit，如果只看数字会觉得这是个"堆量"的日子。但拆开来看，这其实是围绕一件事反复加固的过程——让批量封面重绘这件事变得可验证、可回滚、不怕出错。

核心事件：历史封面第二批重绘完成

ajin-blog 的历史封面重绘进入第二批次。第一批已经跑通了整个链路，第二批要做的是 84 张图的批量处理。数量上来之后，之前"跑通就行"的思路就不够了。

今天完成的关键节点：

第二批历史封面重绘落地（commit 224005b）。这不是简单地"生成 84 张图"。每张图都需要从对应文章的完整正文中提取 visual brief——核心事件、主体、动作、结果、张力、工业隐喻、三个视觉焦点——然后才能交给 Codex Image 2 生成。标题和摘要只用于交叉核对，不能单独决定画面内容。

封面 v2 合同对齐（commit 4a5e2bf）。把整个封面生成流程的合同文档化：provider 固定为 codex，model 固定为 image-2，执行模式为 builtin-imagegen，视觉母题锁定在蒸汽工业时代。这不是偏好问题，是防止生成路径漂移的硬约束。

批次回滚流程（commit 52da5e3）。批量操作最怕的就是"改了一半发现不对"。今天建的回滚机制是原子性的——一个批次要么全部 apply，要么全部不改。apply 之前会 preflight 每个候选，任何一个验证失败就恢复整个批次的 post、brief 和 manifest。

队列校验门（commit 0aadeba）。在真正生成之前加了一道门：校验 manifest 条目完整性、post/body 哈希新鲜度、v2 brief 和 prompt 版本、恰好三个焦点元素、700 字符的 prompt 上限、唯一输出路径、四张参考图哈希。过不了这道门，一张图都不会开始画。

工程细节：15 批视觉摘要预生成

今天还有大量 commit 是视觉摘要的预生成——第 3 批到第 17 批。这些是为后续批次做准备：先把每篇文章的 visual brief 提前算好并存档，后面批量生成的时候就不用再读一遍全文了。

这种"先备料再下锅"的做法看起来多了很多 commit，但实际效果是：后续每一批的生成时间会显著缩短，而且 brief 质量可以在预生成阶段就做一轮检查。

侧线：输入法专业词库低敏召回

ai-input-method-digital-avatar 今天收了一个功能：专业词库的低敏召回（commit 236cacb, 713f9b6）。这个功能解决的问题是：在专业场景下（比如医疗、法律术语），输入法需要召回特定词汇，但又不能把整个敏感词库暴露给前端。低敏召回的做法是只传必要的匹配结果，不泄露完整词库。

这个功能的验收记录也一并提交了。输入法这边相对安静，主要精力还是在博客基建上。

Signal Radar：自动运行

港股和 A 股的日内行情更新照常跑着，收盘更新和晚间收口都正常完成。这是 cron 驱动的自动化流程，今天没有人工干预。

谁干了什么

人员	产出
谷子	封面重绘第二批落地、v2 合同对齐、回滚流程、队列校验门、15 批视觉摘要预生成
阿龙	输入法专业词库低敏召回（数字分身方向）
cron	Signal Radar 日内行情定时更新（自动）

今天的一个工程判断

批量封面重绘这件事，最容易犯的错是"先跑起来再说"。84 张图，每张都要调用外部 API，每张都有生成质量风险，如果不建好校验门和回滚机制，出了问题就是 84 张图都要手动排查。

今天做的所有加固——队列校验门、原子回滚、视觉摘要预生成、v2 合同锁定——本质上都是在回答同一个问题：如果某一步出了错，恢复成本是多少？

答案是：一个命令恢复整个批次。这就是今天的工作量值回票价的地方。

20 多个 commit 里，真正"产出"的可能只有两三个。其余的都是在给产出上保险。工程纪律就是这样——看起来慢，实际是最快的路。