和 WorkBuddy 聊天，聊出了个「多平台小程序备案 AI 中枢」

大家好，我是小悟。

做小程序备案运营的人，大多有过这种经历。

上午微信小程序被驳回，理由是主体证件照反光；下午群里有人问抖音那边的短信核验是不是超了 24 小时；晚上你翻快手后台，才发现管局受理已经过去十八个工作日，进度卡在「待补充材料」。你同时管着微信、支付宝、抖音、快手、百度五家平台，本质上是在跑五场规则相似、细节各异的接力赛——每一家都要求备案，但材料表单、核验方式、时限口径、驳回原因各写各的；进度散在各自后台，提醒散在群聊截图，风险藏在某个没人记得的截止日里。

这不是某家公司的个案，是这个活的结构性问题：信息分散、口径不一、巡检靠记、风险滞后。过去我的解法是五张 Excel，每天下班挨个翻一遍。漏看一次，就是一次被打回重来，上线排期往后挪。

后来我没再开第六张表，而是和 WorkBuddy 聊了几次天，造了一个东西——「多平台小程序备案 AI 中枢」。它每天替我把五个平台的备案风险推到群里。下面记录的，是它解决什么、由哪些模块组成，以及我是怎么把一句模糊的抱怨，聊成一个能用的系统的。

一、它解决了三件事

很多工具一上来就堆功能，我更愿意先把痛点钉死。这个中枢对应的是三件让我头疼的具体事：

第一，信息碎片化。 五个平台的备案规则、材料清单、驳回高频点，分散在各自的开放平台文档、群聊截图和口头经验里。新人接手要重新踩一遍坑，结论还常常口径不一。中枢的做法是把「要不要备、怎么备」做成一张五平台对照表，且统一到最严口径——只要是小程序，无论主体是企业、个人还是个体工商户，无论展示、交易还是内容，一律判定需备案，只在材料和流程上体现平台差异。

第二，时效不可视。 备案链条很长：平台初审 1–2 天 → 工信部短信核验 24 小时内必须完成 → 属地管局终审 1–20 天。关键节点靠人工记表格，短信核验超时、管局超期这类硬 deadline 经常漏盯，轻则被打回，重则小程序被强制下线。中枢把「记」改成「算」：你登记几个关键日期，系统实时推算当前阶段和剩余天数，临近超时自动顶上来。

第三，风险滞后发现。 材料被打回往往发生在提交之后，缺少「提交前预判」的机制。中枢在提交前就按平台结构化逐字段校验，把驳回风险拦在门口，而不是等被拒了再补救。

一句话概括：它把「分散、滞后、靠记」的备案管理，重构成「集中、主动、可追」的中枢。

二、工作台五大模块，各管一摊

打开首页就是「总览驾驶舱」，往下是五个功能模块。它们不是孤立的按钮，而是一条从录入到预警的链路。

备案诊断台——选业务类型、主体性质、目标平台，它输出五家平台的对比结论：要不要备、各自要什么材料、走什么流程、时效多久、风险点在哪，每条都带权威来源引用。我第一次用它在十秒内看清了「抖音微短剧类额外要成本配置比例报告和片酬承诺书」这种冷门差异，以前得翻半天文档。

材料预审台——按平台把材料拆成结构化字段填进去，系统逐字段校验，给出驳回风险清单和可执行的补正建议。它不依赖图像识别，只盯文本字段的完整性和合规规律，所以稳、可解释。

进度看板——登记每个平台的三个关键里程碑日期（提交日、核验短信日、管局受理日），看板立刻算出「当前在核验期、还剩 6 天」。五家平台的状态收在同一屏，不用再切后台。

风险提醒中心——基于登记表和当前日期实时滚动风险列表，同时展示定时巡检回传的播报记录。它是整个系统「主动」的体现：不是你去找风险，是风险来找你。

政策问答——用自然语言问政策，比如「快手备案号格式是什么」「百度不备案能过审吗」，结论带出处。规则能答的走规则，配了云端密钥的走增强检索，答案还会沉淀下来。

五大模块之下，还压着三层看不见的底座：三通道推送（企业微信、钉钉、飞书群机器人，各自可独立开关、支持加签）、轻量多租户隔离（用 sha256(QODER_PAT) 当租户钥匙，A 填的密钥看不到 B 的数据，删除操作都带归属校验）。

三、信息是怎么流起来的

把五家平台、知识库、模块、推送通道的关系画出来，逻辑就清楚了：

平台不直接进系统，把已知事实登记进来；中枢内部，知识中枢和数据共同喂给五大模块；模块在配了密钥时调用多 Agent，产出再经三通道推回。平台没有统一接口，账号授权又涉及安全，与其去摸五家的内部，不如把已经掌握的事实收拢到一个地方。

四、把想法聊成系统：我和 WorkBuddy 的几次关键对话

这部分是我想重点说的。这个项目没有写一行需求文档，没有拉分支联调，整个系统在 WorkBuddy 的对话框里长出来的。回看下来，有几次对话是关键转折：

第一次对话：把混沌讲清楚。 我没有甩一份 PRD，而是直接把需求原原本本说出来。WorkBuddy 帮我把散点归纳成三件事，并确认了「不爬平台、只收拢人工事实」这个克制原则。这一步决定了后面所有的技术取舍。

第二次对话：让它搭骨架。 我提了个视觉方向——深空数据中枢风格，霓虹渐变加玻璃拟态。它直接产出了前端骨架和真实的后端 FastAPI 服务，规则引擎、SQLite 持久化、三通道通知、定时巡检的雏形一次就位。

第三次对话：一个模块一个模块聊。 这是最耗时的部分，也是最像「结对编程」的部分。跟它聊诊断台的五平台对照口径、材料预审的字段校验逻辑、聊看板怎么算剩余天数。它不是一次性吐一大坨代码，而是跟着我的顺序，把五大模块逐个落地。配合多 Agent 的接入，诊断与问答在配了密钥后才叠加智能增强，没配就回退规则。

第四次对话：部署到公网。 最省时间的一段。WorkBuddy 直接生成了适配魔搭创空间的 Dockerfile，端口锁死 7860，密钥通过环境变量一次性注入。从「本地能跑」到「公网有链接」，中间没离开过同一个对话框。

第五次对话：上线后才开始的修复。 真正考验不是在本地，是在真机上。下面这节单独说。

五、上线后才懂的两件工程细节

工具能用不难，难的是在真实平台里稳。部署到魔搭后我撞上两件事，值得记一笔，因为它们只有真机才会暴露，本地永远遇不到。

第一件，登录 200、后续接口全 401。 排查下来，魔搭的公网网关会把标准的 Authorization 请求头剥掉，令牌因此传不过来。解决办法是让前端额外带一个 X-Access-Token 头，后端也同步认这个头，再补一个 ?token= 查询参数兜底，三通道解析令牌。同样的逻辑后来也用在了管理员身份判定上。

第二件更隐蔽：在界面改了访问密码，提示保存成功，用新密码却登不进。 根因是后端判定「是不是管理员」时只读 Authorization 头——在魔搭上它永远为空，于是访问密码被静默丢弃，保存接口却照常返回成功。修复后，敏感写操作也走和鉴权完全一致的多渠道令牌解析，问题消失。顺带把数据库落点改到了魔搭的持久化卷 /mnt/workspace，容器重启不再丢配置。

这两件事背后，是定时巡检这条链路的工程较真。巡检是系统「主动」的部分，我设计成「云端为主、本地兜底」：

云端 Deployment 到点在 Asia/Shanghai 时区触发，跑完通过 Webhook 回传；本地有一条兜底线程，只在云端当天没动静、又过了整点末尾时才补位。两路共用「检查—占位—执行」的原子去重，加上同会话五分钟去重和全局一百八十秒冷却，所以绝不会同一天推两次。手动巡检随时能点，只受冷却约束。

六、它不替你做什么

写到这里，得把边界说清。这个中枢不替你提交备案、不改平台上的任何字段；它做的是把你已经掌握的事实结构化、把分散的风险集中化、把该提醒的主动推到你面前。

换句话说，它是运营的认知外骨骼，不是替代运营的人。

七、写在最后

回头看，这个项目最值得说的，不是用了多少 Agent、接了几家通道，而是它把我从「想做个工具」到「工具真的在公网跑起来」之间的距离压短了一大截。WorkBuddy 在这里不只是写代码——它帮我定架构、抠部署细节、把一次次报错变成可复用的修复。对一个想把脑子从重复劳动里解放出来的运营来说，这种「自己也能造轮子」的感觉，比工具本身更有价值。

如果你也在被五块屏幕、五张表格拖着走，也许值得试一次：先把痛点讲清楚，再让对话把想法一点点变成现实。

谢谢你看我的文章，既然看到这里了，如果觉得不错，随手点个赞、转发、在看三连吧，感谢感谢。那我们，下次再见。

您的一键三连，是我更新的最大动力，谢谢

山水有相逢，来日皆可期，谢谢阅读，我们再会

我手中的金箍棒，上能通天，下能探海