摘要： 用 n8n 把内容采集、格式初审、事实核查、人工复核和 CMS 发布串成一条可追踪的流程，让 AI 负责重复检查，让编辑保留最终决定权。
内容团队使用 AI 后，产量通常先增加，审核压力随后增加。真正需要自动化的不是“让模型直接发布”，而是把重复检查、来源整理和人工确认串成一条有记录的流程。
n8n 适合做这个连接层：它可以接收表单、文档或 RSS 内容，调用不同模型与工具，保存状态，并在关键节点等待人工决定。下面是一套可以逐步搭建的基础方案。
工作流总览
- 采集待审内容与必要元数据。
- 检查结构、格式、敏感词和缺失字段。
- 抽取可核查事实，并查找或验证来源。
- 把风险项提交给编辑人工复核。
- 通过后写入 CMS；不通过则退回修改。
关键原则是：每个节点只负责一种明确判断，并输出结构化结果。不要用一个超长提示词同时完成改写、核查、评分和发布。
一、设计输入数据
无论入口是表单、Notion、Google Docs、Webhook 还是 RSS，建议统一成下面这些字段：
- 标题、正文、作者、内容类型和目标栏目；
- 原始来源链接与资料日期；
- 是否包含价格、数字、政策、医疗或金融等高风险信息；
- 提交时间、当前状态和唯一内容 ID。
唯一 ID 很重要，它能防止工作流重试时重复创建文章，也方便把每次审核结果写回同一条记录。
二、第一层只做确定性检查
格式和完整性优先使用普通规则节点，而不是全部交给大模型。例如检查标题长度、正文是否为空、链接格式、必填字段、禁用 HTML 标签和敏感词。确定性规则更快、更便宜，也更容易解释。
如果检查失败，直接生成问题清单并退回，不必继续消耗模型调用。
三、让 AI 输出结构化初审结果
第二层让模型检查表达和潜在风险，但要求返回固定 JSON，而不是一段散文：
{
"summary": "内容摘要",
"claims": [{"text": "待核查事实", "risk": "high"}],
"issues": [{"type": "unsupported_claim", "location": "第3段"}],
"decision": "review"
}在 n8n 中对返回结果做 Schema 校验。解析失败时进入重试或人工队列，不要把无法解析的文本当成“审核通过”。
四、事实核查要拆成“抽取”和“验证”
先让模型从正文中抽取需要核查的主张，再针对每一条寻找来源。优先级通常是：官方文档、原始研究、政府或机构资料，其次才是二手报道。
核查结果至少保存：原句、支持或反对的证据、来源链接、资料日期、置信度和无法确认的原因。找不到证据不等于事实错误，但必须进入人工复核。
对于价格、版本、人员任职和产品功能等易变化信息，增加“更新时间”检查。旧来源即使曾经正确，也不一定适合当前文章。
五、人工复核节点怎样设计
人工页面或通知中不要只放“通过/拒绝”按钮。编辑至少应看到：
- 原文与 AI 建议修改的差异；
- 高风险事实及对应来源；
- 没有找到证据的句子；
- 格式、版权、隐私和品牌风险提示；
- 通过、退回修改、暂缓发布三种动作。
医疗、金融、法律、个人信息和重大品牌声明应始终人工确认。AI 可以排序风险，但不应拥有最终发布权。
六、写入 CMS 时加入安全护栏
发布节点使用权限最小的专用账号，只允许创建草稿或定时文章。先写入草稿，确认标题、slug、栏目、正文、链接和图片正常后，再改变状态。
为每次写入保存 CMS 返回的文章 ID；重试时先查询该 ID，避免重复发布。正式上线前还可以加入链接检查、图片 alt、canonical 和预览页截图等步骤。
七、错误处理和成本控制
- 节点级重试：网络错误可以退避重试，内容错误不要无限重跑。
- 失败队列：把失败原因、输入和最后一步保存下来，便于人工恢复。
- 模型分工：轻量模型做分类和格式检查，高能力模型只处理复杂判断。
- 内容去重：用内容哈希或唯一 ID 阻止重复任务。
- 日志脱敏：不要在执行日志中保存密码、令牌和完整个人信息。
建议的上线顺序
- 先做“采集 → 格式检查 → 人工通知”，不接自动发布。
- 稳定后增加结构化 AI 初审和事实抽取。
- 再加入来源核查、CMS 草稿写入和状态回写。
- 最后根据误报率决定哪些低风险内容可以自动进入定时队列。
结语
一条可靠的 AI 内容审核工作流，不追求完全无人值守，而是让机器承担重复劳动，让人把精力放在事实、风险和最终表达上。先把每一步做小、做透明、做可重试，再逐步提高自动化比例，通常比“一次搭出全自动编辑部”更稳。