AI 内容生成流水线：从选题到多平台分发的全自动方案

自动化目标不是无人审核

一条可靠的 AI 内容流水线应减少复制、整理和格式转换，而不是把未经核对的模型输出直接发布。本文把流程分为选题入队、资料收集、结构化生成、质量检查、人工审批、渠道适配和发布回写七段。任何涉及事实、版权、品牌承诺或公开发布的内容都保留证据和人工闸门。

输入可以承接已有的公众号文章采集工作流，也可以来自 RSS、表单和选题表。采集外部内容前确认授权与平台规则，只保存完成编辑所需的数据。不要把整篇受版权保护的原文直接拼进提示词并要求改写发布。

建立选题队列与幂等键

Schedule Trigger 定时读取状态为 candidate 的选题，每次限制数量，避免一次执行耗尽模型额度。字段至少包含 topicId、主题、目标读者、内容目的、来源链接、负责人和状态。用 topicId 作为主键，工作流启动后以条件更新将状态改为 researching；如果更新影响行数为零，说明该选题已被其他执行领取，应立即跳过。

{
  "topicId": "agent-tools-001",
  "topic": "如何限制 AI Agent 的工具权限",
  "audience": "刚开始使用 N8N 的运营与开发者",
  "goal": "给出可执行的最小权限清单",
  "sources": ["https://docs.example/security"],
  "status": "candidate"
}

所有后续产物都带 topicId 和 executionId。这样重试单个节点不会创建第二篇文章，发布回调也能关联原始选题。

资料收集与可信度标记

用 HTTP Request 抓取允许访问的来源，设置超时、重定向上限和响应大小约束。HTML Extract 只提取标题、发布时间和正文区域，再由 Code 节点清理导航。每条资料保留 sourceId、URL、抓取时间和原文片段。对官方文档、团队一手数据、媒体转述分别标记来源类型，模型不应把不同可信度的内容混成同等事实。

抓取失败时不要让模型补齐未知事实。将失败来源写入 source_errors，如果核心来源缺失则暂停选题；非核心来源失败可以继续，但在编辑任务中提示缺口。涉及“最新”“当前”等易变化陈述，上线前必须重新核验。

用两次模型调用分离策划和写作

第一次调用只输出提纲和证据映射。System Prompt 指定读者、目标、禁区和 JSON Schema；用户消息提供选题与编号资料。要求每个章节列出使用的 sourceId，资料不支持的观点标记为 needsResearch。

{
  "title": "文章标题",
  "sections": [
    { "heading": "章节名", "purpose": "解决的问题", "sourceIds": ["S1"], "needsResearch": false }
  ],
  "riskNotes": ["需核对权限边界"]
}

Code 节点解析并验证：章节不能为空，sourceIds 必须存在于输入，不能出现未定义字段。验证通过后，第二次调用根据已批准提纲生成正文。写作提示应明确“不得编造版本、价格、案例数据；代码参数不确定时用语义说明；引用只能来自给定资料；输出 Markdown 正文而不是发布动作”。把品牌语气单独保存成短规则，避免每篇提示词各写一套而逐渐漂移。

自动质量检查不是事实审核的替代品

正文生成后并行执行确定性检查：标题长度、必需章节、禁用词、链接格式、代码围栏闭合、是否出现无来源数字。另一个模型可以做编辑建议，但不能把自己的判断当事实证据。让审核模型输出问题列表与对应段落，不直接重写全文，否则改写可能引入新错误。

将结果汇总成编辑包：正文、来源列表、提纲证据映射、自动检查、风险备注和预览链接。写入内容库后状态设为 review，通过邮件或协作工具通知负责人。Wait 节点或审批 Webhook 等待人工选择“通过、退回、终止”，回调必须验证签名、审批人权限和 topicId 当前状态。

多平台适配与发布

审批通过的主稿是唯一事实源。为公众号、知识社区和邮件分别创建子工作流，只做格式与长度适配，不重新发明事实。渠道提示输入主稿与平台约束，输出结构化标题、摘要、正文和原文链接。发布前再次扫描敏感字段并生成最终预览。

{
  "topicId": "agent-tools-001",
  "channel": "newsletter",
  "title": "本期标题",
  "summary": "供列表页使用的摘要",
  "body": "适配后的正文",
  "canonicalUrl": "https://flowhub.blog/articles/example"
}

发布节点前查询 publication 表中 topicId 与 channel 组合是否已成功。成功则跳过；失败可重试，但要区分网络超时与内容校验错误。若接口超时且不知道远端是否已经发布，先用外部幂等键或查询接口确认，不能盲目再次创建。每个渠道发布后记录远端 ID、URL、响应摘要和时间。

失败恢复与运营反馈

为模型调用、抓取、审批和发布分别设置错误工作流。错误记录包含阶段、topicId、executionId、可重试类别和脱敏消息。认证失败、字段错误、审核拒绝不可自动重试；限流和临时网络错误采用有限退避。不要把完整提示词、凭证或包含个人信息的正文发进公开通知群。

发布后定时读取各渠道允许获取的基础反馈，并回写到同一 topicId。数据用于判断选题是否解决问题，而不是让模型自动追逐单一点击指标。选题复盘应同时看搜索意图、读者反馈、订阅变化和内容修订次数。

上线验收

同一选题被并发触发时只有一个执行取得处理权。
缺少核心来源时流程暂停，不生成“看似完整”的文章。
提纲中的每个来源编号都真实存在，正文中的数字与结论可以回溯。
人工未批准时，任何渠道发布节点都无法执行。
审批回调被重复发送时不会重复发布。
某一渠道失败不会覆盖其他渠道的成功记录，可从失败阶段单独恢复。
导出的工作流不包含凭证值，执行日志不保存不必要的原文与个人数据。

这条流水线真正节省的是信息搬运和重复排版时间。选题责任、事实判断与发布授权依然属于编辑团队；N8N 负责把这些责任变成清晰可审计的状态流转。