一天 300 篇母版：从「选题库」到「批量产线」

🗂️ 选题库：先建原料

这天把 6 张选题库入库（系列累计 7 张共 700 条），每张 100 题，都带分型 / 优先级 / 搜索意图等元数据。

关键点：选题不是"想到什么写什么"，而是一张可排序、可编程的表格。 每张还配了不同视图（按板块 / 按优先级 / 按漏斗阶段 / 按短视频优先级）。

排坑：某个视图排序接口的 JSON 必须是对象结构，不能传数组。

跑完三套各 100 篇：

累计 300 篇母版入库，编号 1–315 连续唯一。

多个任务并发跑，编号会撞。修法：

母版编号 = 全局最大值 + 1（从文件系统算）。

不按批次算、不按板块算 —— 只有全局 max 才不会被并发和继承搞乱。修完之后，几套连跑再没撞过。

对账时写了个清洗脚本，删掉了 90 个文件。

能全部恢复的原因是设计上做对了一件事：母版不散落在别处 —— 从产出源头重新生成一遍就回来了，零丢失。

由此立下第二条铁律：

删文件前绝不写清洗脚本。读内容重建，远比删安全。

新写的脚本崩溃，原因很简单：用了内置模块但没 import。于是加了一条习惯：新脚本先排查所有用到的内置模块。

这天又产出 5 篇（累计 24 个文件，系列正好到 30 篇）。每篇结尾都接上自家业务的应用映射 —— 不只翻译，还要说清对我这门生意意味着什么。

一个真实缺口被审计出来：现有 3 篇博客全部缺作者和更新时间字段 —— E-E-A-T 要求有，直接列进待办。

四个技能都过了 6 项校验 + 冒烟测试。

底盘护板这套源文档里没有 AI 可执行度数据，于是改用优先级 P0 作为编排维度 —— 而不是"估一个填上"。

太阳膜没有每题分型，就用漏斗阶段 + 优先级作为类型维度。结构差异据实适配字段，不硬套模板。

还有一处：源文档的总结数字和正文对不上（29/30/41 vs 31/30/39），以正文为准 —— 因为逐行相加比总结更可信。