博客素材链：从“黑箱”到可点名
博客这边最先让我注意到的是 Codex 在一次会话里的自述。他说：“目前对我来说是一个黑箱，我需要你排查一遍这些来源是否能够正常的拿到数据和素材。” 这句话把一天的基调定了下来——素材能不能正常采集，不是假设，是要逐项核实的。他按照 9 月 30 日那份最近的完整素材包，逐项对了每一个来源：哪个拿到了、哪个没拿到、采集结果能不能回到原始文件。结果不算坏，但也不算让人放心：主要素材确实拿到了，但并不是所有已配置来源都在正常供数；其中 Hermes 日报素材被明确点名为“确定的漏采”。这个结论很重要，因为它不是“可能有问题”，而是当天的逐项排查记录显示“有问题”。
紧接着，Codex 又被追问了一个更基础的问题：博客素材采集到底有哪些来源，是不是稳定、是不是真实，位置是不是还符合现在的工作台场景。他查出来两条不同的链路：一条是 blog_materials_builder.py 在写作前汇总多个 Git 仓库提交、Codex 会话、Claw 会话等，生成原始素材 JSONL 和汇总文件；另一条是日报工作台那边用来观察文章生产和发布状态的采集器。前者是“给文章喂粮”的，后者是“盯着文章生产”的。两条链路各自跑各自的，平时混在一起看就会觉得是个黑箱。
到了晚上 20:14 左右，有人在会话里直接问：“今天的呢，有吗？”Codex 的回答是：今天的素材候选已经有了，但完整素材包还没生成——2026-10-01.jsonl 和对应的 summary 文件都不存在。当天 13 个 session 文件里，有 12 个解析出了素材轮次，共 38 条候选，其中 35 条被标为公开候选。这里要注意，Codex 自己也说“初步筛选不代表 35 条都是合格的”，所以这个数字只能说明“机器初步认出了这些条”，不能说明“它们都会进今天的稿子”。openclaw_memory 那边的记录里也出现了一个候选文件 2026-10-01.md，但也只是“检测到”，还没到能直接引用的程度。
流程精简：从“两次审稿”到“一次审稿”
博客这条线上今天动静最大的，是流程精简这件事的落地。Codex 在一次会话里复盘：“已按你确认的内容更新 OpenClaw 发布提示词：每次运行只做一次独立事实审稿，未通过就停止，不自动修订或复审。” 这背后是一段来回：先把方案文档整理出来——docs/blog-content-workflow-simplification-plan.md——把调整分成五块：收敛写稿和事实审稿、保留必要的封面质量门禁、合并重复发布校验、把失败恢复从每日主链里分开、保持对历史回填的可追溯。
Codex 会话里写着：“已完成本轮代码范围内的流程精简。”具体动作包括：每日发布现在只调用一次 npm run verify，文章与封面校验由 build → prebuild → posts:validate 完成，原来重复跑的封面校验和文章校验被合并掉；历史封面回填校验被移出日常流程，单独提供 npm run verify:backfill；发布器调用终态检查时使用 --dry-run，失败时不直接破坏状态。他还特意强调“仅修改授权的两个文件”，一个是 package.json，另一个我没看到具体名字，但从上下文看也是发布链路上的关键文件。
9 月 30 日那批内容被明确“作废”，用新流程重跑了一遍。Codex 自述：新稿通过唯一一次事实审稿和封面视觉审查，流程只执行了一次 npm run verify，验证通过；新文章、简报和 Image 2 封面已提交并推送到 origin/main、github/main，两端均回读到提交 4f127c20，提交信息以 docs: 发布… 开头，后面的细节在素材里被截断了，但“两端回读一致”这件事本身已经在记录里写明。
在这之前，还跑过一次“测试性的完整复现”。Codex 核对 9 月 30 日的运行记录后说：那次已经成功发布，终态回执是 status=ok、published=true，CI 为 success，回执哈希和本地工作流状态文件一致。但紧接着他自己加了一句：“不过，这次成功运行还没有覆盖刚调整的精简流程。”也就是说，9 月 30 日的成功是旧流程的成功，今天才算在新流程下重新走通一次。这种“自述式的诚实”在素材里很显眼——既不说旧流程不行，也不把新流程的成绩算到旧账上。
Codex 还在一次会话里把“阶段映射”的改动提交并推送到 ajin-blog，远端 SHA 是 6a3fa454f48f4977e0a3c188807696fbfc2bd908；OpenClaw 流程代码也作为 74c0fe60 提交，描述里带着“保留首轮事实审稿”的字样。提交号、描述都在记录里，没看到“据说”“听说”这种说法。
后台与发布：删除按钮、文章删除与 CI 的小插曲
管理后台这条线，今天最直观的变化是“日报记录”里加上了删除按钮。Codex 会话里写得很具体：删除按钮加在了“日报记录”每行的“操作”栏，本机日报总览里能看到；点击后会弹确认框，确认后这条记录会从后台列表和详情中隐藏，关联的运行证据和处理意见仍保留在本机数据库；采集器不会把这条记录重新显示，也不会去改博客源文件或生产回执。他特意点出“当前没有删除任何日报”，这一点值得记下来——按钮加上了，但没有任何一条真的被点掉，所以这是一个“能力已具备，但还没动数据”的状态。他也写了“新版后台已重启生效”，后面的话被截断了，但从“已重启生效”来看，至少在本机环境里是加载了的。
博客文章后台这边，Codex 完成了列表和删除的支持：新增“博客文章”页面，列出 Git 跟踪的 content/progress 与 content/diary 下的 MDX 文章；删除前会核对文章版本和 Git 状态，存在未提交改动或版本变化时会拒绝删除；删除时先把文章源文件备份到本机后台数据目录，再从仓库移除，不会自动提交或推送。修改功能在他那次的自述里被提了一句“后续再补”，但具体进度在今天没看到进一步说明。
文章删除这件事，今天也有一次实操：有人让 Codex “把这篇内容删除了”，他完成了删除并提交推送，提交号是 bd52419，同时删除了文章对应的 brief 和封面，npm run posts:validate 和 npm run verify 均通过；线上 API 已经不再返回这篇文章，原文章页和封面地址返回 404。一个小插曲是：删除后那次 CI 因为 origin/main 被另一笔并发提交推进而取消了，那笔新提交以 bd52… 开头，后面的哈希没在素材里出现。这里我能判断的是“CI 被并发提交挤掉”，但具体是哪笔提交把 CI 顶掉的，素材没给完整信息，我就不去补。
输入法：把“上屏了”误当成“用户认可”
输入法这条线离博客稍远，但今天它也冒出了两次会话讨论，主题都围着“用户习惯”打转。第一次，Codex 自述：“我看下来，核心问题是：系统把‘上屏了’当成‘用户认可并形成习惯’。” 他指出在现有实现里，每次普通上屏都会进入学习流程；符合长度条件的内容会累计为词、短语或句式，并参与个人候选排序。第二次会话把问题更具体地描述出来：“关于用户习惯有一个问题，有可能是用户打错字了，也会出现到下次打的前面，这个是不对的，我们需要做优化。” 他回到代码层面，确认现在的学习入口会把每次上屏的文字直接记下来，文件指向 RuntimeControl.swift。
这两次会话指向的是同一个根：输入法在“学”的时候，分不清“我打对的”上屏和“我打错了也送上去了”的上屏。素材里没有给出当天的最终方案，只有“需要优化”的结论和代码定位。所以严格来说，这是一项“已诊断、待收敛”的工作，而不是“已完成”的工作。我倾向于把这个状态如实写出来，而不是替它补一个“已经修好了”的尾巴。
关于这一天，我自己的几点判断
把素材合在一起看，我有几个直观的判断。
第一，10 月 1 日博客侧并不是“没事干”的一天，而是“流程切换”的一天。旧流程的成功属于 9 月 30 日，新流程的第一次完整跑通属于今天，这次切换是用“作废昨天、重跑一遍”完成的。Codex 在素材里反复强调“只跑一次 verify”“只做一次事实审稿”，这不是修辞，是流程精简的硬约束。
第二，素材采集的“黑箱”今天被点名了，但只是被点名。Codex 给出了排查方法和结论（Hemes 日报漏采），但今天没看到修补动作。换句话说，10 月 1 日的素材包仍然带着这个已知问题，这一点值得在后续工作里盯一下。
第三，后台的两个删除能力（日报记录的删除、文章的删除）今天都具备了，但实际触发次数是零。这通常意味着“给操作者多一个选项”，而不是“开始清理历史”。我倾向于把这种状态描述为“能力已上线、数据未动”，而不是“已删除 N 条”。
第四，输入法“把错字也学进去”的问题，今天停在“诊断+定位代码”这一步，没有看到闭环方案。这件事和博客、后台是独立的，但它出现在今天的素材里，说明它确实是当天在推进的事项之一。
最后，关于当天完整素材包“还没生成”这件事，Codex 在 20:14 给了明确答复。这意味着如果今天要出一篇正式的“10 月 1 日工作日报”，要么是基于“候选+自述”来写，要么就如实标注“素材包尚未生成，本文为候选汇编”。我选择后者，并把这一点直接放在文章开头，让读者知道这份汇总来自当天经过初步筛选的素材，而不是来自一个已经定稿的素材包。