我把公众号草稿流程跑了几轮，最后留下的不是自动发布

我最近把“文章写完以后，自动进入公众号草稿箱”这件事重新跑了一遍。最初以为难点是排版：标题、摘要、封面、正文要在不同字段里拼好，再处理一堆 HTML。

但真正让流程出问题的，往往不是文章写得不好，而是机器以为自己已经完成了：字段缺失，来源没有链接，作者被错误覆盖，或者接口返回成功却没有拿到平台的草稿 ID。

我现在更愿意把这件事理解成一个小型交付系统。它的目标不是替编辑做最后判断，而是把“可以送审的稿件”和“还不能送审的输入”分开，并且让每一次失败都能找到位置。

这套做法不只适用于公众号。任何“内容批准后写回 CMS”的流程，都值得先问一句：自动化交付的终点，究竟是发布，还是一个可核验、可回退的草稿？

在第一次搭流程时，我把注意力放在了文章内容和视觉样式上。后来才发现，自动化最先暴露的不是审美问题，而是输入不够结构化。

一篇人工看起来完整的文章，机器并不知道“摘要”在哪里，也不知道哪些段落属于开头、哪些是正文、哪些来源必须在文末出现。如果把整篇 Markdown 直接塞给发布节点，短期可能能跑，下一次换一种文章结构就很容易出现空字段、超长标题或丢失来源。

所以我先把交付对象拆成几个明确字段：标题、摘要、开头段落、事实信号、章节、结尾和来源。每个章节再分别保存标题、正文段落和事实要点。文章仍然是给人读的，但提交包必须先给机器验收。

这一步也改变了写作本身。标题不能再依赖“感觉不错”，而要能在正文里找到兑现它的事实；“一张清单”“7 个检查项”这样的说法，也必须真的在内容里交付对应材料。

在我的流程里，文章先经过规则检查，再进入排版。规则检查至少包括：标题和摘要长度、章节数量、来源是否有名称和 URL、发布模式是否为 draft，以及正文是否落在适合手机阅读的范围内。

这里用到的 n8n，不是一个替你决定文章能不能发布的“AI 编辑”。它更像一层连接和编排工具：接收结构化提交，执行确定性检查，把合格字段转换成公众号需要的 HTML，再调用平台接口。

我选择它，是因为这条流程同时要连接内容输入、规则校验、HTML 渲染和微信接口。它可以自托管，也有云服务，但许可证、外部连接器和模型 API 的数据边界要单独确认；对小团队来说，真正的门槛不是拖几个节点，而是有人能维护凭据、日志和失败重试。

流程的核心不是“接入 AI”，而是先把确定性部分固定下来。

• 标题、摘要、正文和来源进入固定 schema，缺字段直接退回，不让下游节点猜。
• 文章内容统一转成适合移动端的 HTML，字号、行高、章节标题和来源区域由渲染器控制。
• 作者字段由工作流固定为“申老师”，单篇输入不能覆盖。
• 封面使用已经准备好的永久素材，不在每次运行时重新抓取网络图片。
• 提交包保留 submission_id，让一次重试仍然指向同一篇稿件，而不是生成一个新身份。
• 规则负责判断能不能继续，模型最多负责受限的改写、抽取或提示。标题长度、发布模式、来源 URL 和作者字段不交给模型判断。

现在这条流程分成三个明显阶段。

第一阶段是本地成稿。先保存 Markdown 供人阅读，再保存同一篇文章的 JSON 提交包。两份文件共用一个 submission_id，并在本地扫描禁词、重复主题和基本结构。进入私人公众号的内容还要做一次雇主避嫌扫描，不能把研究素材中的不可公开信息带进标题、正文、来源或图片文字。

第二阶段是 dry run。提交包带上 dry_run=true，流程只做归一化、规则校验和 HTML 渲染，不调用微信创建草稿。返回结果至少要告诉我：校验是否通过、可见字符数、来源数量、章节数量和当前排版版本。任何一项不对，都在这里改，而不是等平台接口报错。

第三阶段才是正式创建。把同一个 JSON 的 dry_run 改为 false，只执行一次。微信公众号的草稿接口负责新增草稿，n8n 的 Webhook 则负责接收提交并返回明确结果。成功不等于“节点变绿”：必须从执行结果中读回平台返回的草稿 ID，再把它写入运行记录。

这就是我后来坚持“回读”的原因。一次接口调用显示成功，只能证明请求没有明显报错；只有拿到平台草稿 ID，并确认文章确实处于草稿状态，才算完成了交付。否则下游无法区分“已经创建”和“只是请求发出去了”。

这套两段式提交也让人工审核的位置更清楚：人工审核在草稿箱，不在自动化的盲区里。编辑可以检查事实、来源、封面和排版；自动化只负责把合格输入稳定地送到这个位置，不替人勾选原创声明，也不绕过发布审核。

实际运行几轮以后，我最重视的不是成功路径有多短，而是失败时能不能马上知道该修什么。

输入校验失败，说明稿件本身还不能进入平台，应该返回字段级错误，例如缺少来源、章节不足或正文过短。它可以修正后复用同一个 submission_id 重试，不需要创建第二篇文章。

如果是微信接口临时错误，先确认响应里没有草稿 ID，再按规则最多重试一次。如果请求已经发出、但平台结果无法确认，就不能盲目再提交：那是“未知”状态，需要先查平台草稿列表或后台，再决定是否继续。自动化最危险的不是失败，而是把未知当成失败后重复写入。

还有几类错误不适合靠重试解决：作者字段被覆盖、发布模式变成非 draft、来源 URL 不完整、命中雇主避嫌词，或者文章内容超过工作流的长度边界。这些都应该停在校验层，由人修改输入。

我也给流程留下了最小的运行记录：日期、标题、submission_id、执行 ID、平台草稿 ID、来源文件和状态。记录不是为了制造报表，而是为了回答三个实际问题：今天有没有成功草稿？这篇稿件是否已经提交过？如果要删除或重做，应该追踪哪一个对象？

这里需要留一个边界。自动草稿链路可以证明“内容交付得更可靠”，不能证明文章一定有人读，也不能把草稿创建数量包装成传播效果。真正的结果还要经过人工审稿、发布和后续数据反馈。

我现在对内容自动化的判断是：先把终点从“自动发布”改成“可审草稿”，再把每个中间状态写清楚。它看起来慢了一步，却减少了最昂贵的错误——把一篇还没准备好的内容，误当成已经完成的公开内容。