野生码农
我的公众号内容产线早就自动化了:AI 写母稿、品控脚本判卷、组装脚本出分发包。但产线跑得越顺,下游越乱——330 条发布记录横跨多个平台,哪篇发了哪篇没发、数据回没回来,全靠标题文字人肉对账。标题改一个字,链条就断了。于是有了 IPMS:一套把内容全生命周期钉进数据库的中后台系统。
怎么实现的
技术栈没什么花哨的:后端 Python + FastAPI + SQLite,67 个文件 12,134 行;前端 Vue 3 + Vite + Element Plus,12 个视图页,信息密度优先。一共 20 张表,装下系列、篇目、物料、发布记录、排产槽、指标时序、操作日志全部业务对象,外加 19 个测试文件兜底。
核心设计三条:
- item_key 贯穿一切。每个篇目一个全局唯一 ID(比如"解密#10"),fabu 包目录名、稿源 front matter、台账全部以它为锚。从选题→母稿→品控→发布包→多平台发布→数据回收,五段对齐靠 ID,不靠标题文字。
- 状态机收口。篇目状态固定 8 态,只允许走定义好的路径流转,钩子自动推进或终审/核销动作推进,不许跳态私改。
- 钩子在执行路径上。产线脚本完成时自动落库:品控过了置"品控过",fabu 组装完登记物料、做齐套校验、为每个目标平台生成一条"待发"记录,采集脚本发现平台上出现了这篇文就自动核销。不靠事后补录,补录的对账我不信。
硬核在哪
- 对账是双向的。每天早上 07:10、晚上 19:00 两条计划任务全自动跑数据链:采集→追补灌库→对账,输出四类红灯——48 小时未核销、排产空槽、漏登记、漏发。系统不催你干活,但会准时告诉你哪里烂了。
- "指标缺失"是一等公民。采集失败就是失败,数据模型原生支持缺失语义,绝不拿 0 冒充。做数据分析的人都知道,假 0 比没数据可怕得多——前者会污染一切均值和趋势判断。
- 合规红线写进章程。系统不做代发布:任何设计、代码不得包含自动发布到平台的能力,发布键永远我本人手点。系统只做备齐、呈现、核对、提醒。这不是技术做不到,是账号安全的底线设计。
- fabu 六件契约机器可判。分发包的齐套校验是硬闸:人为删一件物料重跑,缺件立刻标出,状态不许置"就绪"。这套校验有明确的验收命令,不是写在文档里的口号。
- 与无头产线打通。系统界面里可直接发起"新写母稿""新组包"无头任务,调起 Kimi CLI 跑完整产线;库内还挂了 FTS5 全文检索,翻旧稿不用开文件夹。
实测数据 / 现场
上图是终审工作台实截。库里的真实存量:330 条发布记录(其中 125 条已核销)、3,619 条指标时序、1,239 条操作日志、298 件物料、63 篇目、48 个排产槽。
这套系统也是被真实测试蹂躏过的。测试员曾抓出一个月报图表全空的 bug:
修复后重放同一操作验证通过:
这套东西能复用到哪
- 电商多店铺运营:SKU 对应 item_key,上架记录对应发布记录,48 小时未核销红灯改成"超期未发货"就是现成告警。
- 自媒体 MCN 代运营:多账号多平台发布核销与数据回收,缺的就是贯穿 ID 和自动对账这两块。
- 软件发布管理:版本号当 item_key,各渠道(应用商店、官网、镜像站)的发布状态核销,思路完全同构。
- 任何"AI 产线+人工发布"的合规场景:自动化备齐物料、人工保留最后一键,这套边界设计可以直接抄。
现状与下一步
P1 本地单机版已投产日常使用,P2(上服务器+手机浏览器访问+登录口令)在设计文档里有约束但还没动手。下一步不急着部署,先把红灯清单的推送通道打通——对账结果躺在库里没人看,等于没对账。