从一句“把分支处理干净”开始

这天最先浮上来的事是仓库卫生。Codex 会话里很早就确认了一件事：当前分支并没有需要合进 main 的提交，真正要收的不是分支本身，而是工作区和两个旧 worktree 的残留改动。main 工作区里有 24 个已修改文件和 5 组未跟踪文件/目录，混着日报管理后台扩展、博客流程文档调整和一堆 .claude-* 任务状态文件。这个状态我一点都不意外——它就是那种“每天修一点、攒一点、永远清不完”的形状。Codex 给出的策略是“保留并整理”：先把两棵 backfill worktree 里没提交的内容保住，再处理能安全整理的部分，不丢东西，也不擅自推。听起来很克制，但克制本身就是这一天的主题。

到了傍晚，针对那句“shide”的回复基本就是这个策略的回声——确认理解、按保留并整理走、不会擅自推送。没有戏剧性，但这种克制其实来之不易，因为工作区里 24 个修改文件里不少是“还没想好要不要留”的状态。

封面和发布会卡在哪里

仓库卫生之外，另一条线更让人头疼。10 月 1 日的正式日报重跑结果 c8ca22dfbfb24bd6a81f4d56b3819a07，正文和隐私审稿都已经过了，发布却一直没完成。Codex 会话里的诊断一步一步收窄：

先是封面生成挂了 20 分钟超时。Codex 内置的 image_gen 一直不返回结果，回执也没记录实际跑的是哪个模型版本，所以“是否因为 GPT Image 2.5 推出后没切换到位”这种猜测，目前没有证据支持。官方发布说明确实确认 2.5 在向 Codex 用户推出，官方 API 文档也支持显式指定 gpt-image-2.5-sunburst 或 gpt-image-2.5-flare，但“工具发布了”和“这次失败就是它造成的”是两回事。

接着一次隔离生成倒是正常返回了——约 24 秒出图，画面也符合项目的蒸汽工业铜版画风格。这能证明的是“当前内置生图能跑通一次”，但既不能证明上次 20 分钟已经解决，也不能证明这次实际用了 2.5，因为工具没有暴露模型版本元数据。

更让人皱眉的是 Git 远端那次看起来像“推送失败”的事。Codex 查完之后结论很干脆：Git 推送本身没失败，失败的是推送后触发的构建/部署校验。Vercel 日志里写的是“OpenClaw brief 来源合同无效”，退出码 1。原因并不神秘：日报封面简报里记的是 provider=minimax、model=MiniMax-M3，但当时远端代码里来源身份还写死成 claude / claude…。这种“数据已经换签名，合同还没跟上”的错位，几乎是模型身份切换期的标准坑。

至于把发布页面状态手工改成“成功”这条路，Codex 直接否了：状态是从正式发布回执算出来的，手动改库会和运行记录冲突。2026-10-01 当时还有 18 次运行记录，最新那条回执里 published=false、terminal_gate_passed=false，证据链是完整的，不能用 UI 状态去覆盖。

最后那张图被补作 2026-10-01 日报封面，和正文、全文封面简报、优化清单一起推到了两个远端。文件路径指向 /Volumes/Sata/ChenjinProjects/active/ajin-blog/public/covers/2026-10-01-progress.png。补图这一步是个“止血”动作，把推送链路本身的卡点绕过去，至于正经的封面流程还得后面再修。

文章发布编辑器和它的版本

在这一堆运维和回执之外，今天还把一件原本模糊的事查清楚了：文章发布用的编辑器是 Tiptap。具体看，文章发布组件挂的是仓库里的 ArticleEditor，通过 @tiptap/react 创建编辑器，配的是 StarterKit 等扩展；版本方面，Tiptap 核心相关包是 2.24.1，写在 apps/web-root/package.json 里。

这件小事单独看不大，但它意味着后面如果要做扩展插件（比如自定义节点、封面区、引用块），就不用再花精力去验证“到底是不是 Tiptap”。这种结论型信息一旦落到脑子里，工作流里那种“先猜一下、错了再翻代码”的循环就能少跑几次。

审稿尺度在悄悄放宽

今天最让我想停一下多想想的，是审稿提示词和程序逻辑的调整。Codex 自己承认之前写得偏窄：提示把“无来源支撑、来源冲突、推断”都定义成阻断，程序又把这些状态直接转成“需修订”，还要求每篇都必须有可核验事实才能 PASS。这次改的方向是：只让“隐私风险”真正阻断；事实争议和未证实信息降级为可见的编辑提示；写稿提示也不再锁死在单一素材线。

我理解这个调整的动机——之前那套对“事实”太苛，对“隐私”又太松，而真正应该被门禁卡住的只有后者。同时保留文章哈希、材料哈希和运行身份绑定这种审计追溯控制，让“可见的编辑提示”不会变成“无迹可查的猜测”。

但说实话，我对“放宽”这件事的感受是复杂的。一方面，事实性瑕疵和隐私风险本来就是两件事，把它们塞进同一个阻断桶里其实是降维，迟早要出问题。另一方面，写稿助手收到“可以写推断”这种信号后，会不会滑向另一种失控？我倾向于认为关键不在提示词本身，而在配套的展示：编辑提示是否真的足够可见，读者是否能分辨“已被核实”和“仍存争议”，审计追溯是否真的能回放。Codex 这次同步改了状态展示逻辑（提交 f51bb03：fix: 按验收证据展示阶段完成状态），说明它意识到“怎么说”和“怎么做”得绑在一起。如果未来哪天只改提示词、不动展示，我会比较警惕。

把今天看成一张网

把这些事摆在一起看，今天并不是某一件大事的日子，而是“几根线同时在纠缠”的日子：分支卫生是慢病，封面链路是急性卡点，编辑器信息是阶段性结论，审稿尺度是制度调整。它们看起来不相干，但其实都被同一个东西牵着——项目从“原型期”跨向“可发布期”时的接合面松动。模型身份变了，合同没跟上；工具升级了，配置没跟上；写稿要求变了，门禁尺度也得跟上。

我比较喜欢今天这种“什么大事也没发生，但每件事都往前挪了半步”的状态。它不戏剧化，但比起戏剧化更有用——因为下一次真正卡住的时候，这些半步会变成回旋的余地。