「我们的内容要过 12 道关卡」这句话不准确——那 12 道挂在三个不同时点，实际经过几道取决于走哪条发布路径。本文按代码真实执行顺序讲清六阶段主线、每一关卡在哪、两个状态字段的区别，以及这条链路能保证什么、不能保证什么。
一个必须先讲清的事实：「12 道关卡」不是每篇内容都过
先纠正一个在讲 GEO 内容生产时很常见的错误说法：「我们的内容要过 12 道关卡才能发布」。
这句话听起来很有说服力，但它不准确。准确的说法是：系统里共有 12 道把关机制，它们挂在不同时点，一篇内容实际经过的关卡取决于它走哪条发布路径。
分清这一点很重要：客户拿这句话去核对系统时，会发现某些关卡在自己的流程里从没触发过，然后开始怀疑整套说法。把机制清单说成流程承诺，是这类介绍最容易犯的错——所以我们先按真实调用位置把三档讲清楚。
三个阶段时点
按代码里的实际执行顺序，关卡分三类时点：
① 生成时（generate）：内容生成或重新保存时执行。这类关卡拦的是“内容本身有问题”——关键词冲突、敏感词、品牌语气不符、价值观风险。
② 发布时（publish）：后台人工点“发布”时执行。这类拦的是“这个平台不让发”——平台合规预检、行业合规包。
③ 全路径（always）：由工作流或系统强制，无论走哪条路径都跑。这类是兜底与法定义务——托管自动预检、AI 内容标识。
这个分档不是文字游戏，它决定了每一关该由谁负责：生成时的关卡是编辑在自己电脑上就会遇到的，发布时的关卡是运营在点按钮时才遇到的，全路径的关卡是系统自己做的、没人需要操作。
六阶段主线：从建任务到效果验证
把上面的关卡放回完整链路，内容生产是一条六阶段的主线：
| 阶段 | 执行者 | 做什么 |
|---|---|---|
| 一、建任务 | 人 | 定方向、选引擎、备物料、定审发、配协作 |
| 二、AI 生成 | AI | 调度 → 挑标题 → 拼提示词 → 检索知识库 → 写正文 → 配图 → 摘要 → 语气与公序良俗检查 → GEO 评分 → 落库 |
| 三、审核 | 人 + AI | 过风险门禁、品牌手册、公序良俗、行业合规包、人工审核 |
| 四、发布 | 系统 | 三种发布方式、六种状态、失败重试三重保底 |
| 五、监测 | AI | 多引擎真机采样、固定问题集复测、竞品对照、信源分析 |
| 六、验证 | 人 + AI | 测量条件快照 + 假提升自检，数字可复算 |
六个阶段各有明确产出物，且能被下一阶段验证：建任务产出配置，生成产出稿件，审核产出结论，发布产出回执，监测产出采样，验证产出对比。这是它和“六个工具的拼盘”的区别——拼盘没有交接，这条线上每一环都在给下一环交付东西。
阶段一：建任务，五组配置决定后面所有事
这一步最容易被当成“填表”，但配置项直接决定产出质量。按代码里的实际分组是五组：
方向组：内容简报、证据要求、语言与格式。
引擎组：用技能还是用提示词、选哪个模型、失败如何切换、挂哪些知识库。
物料组：标题库、图片库、作者与分类。
审发组：是否需要审核、发布范围、发布间隔、分发渠道、数量限制。
协作组：指派给谁、是否自动提关键词、是否自动生成描述。
其中两项值得单独说：
“证据要求”是很多团队会关掉、然后后悔的一项。 关掉之后模型不被要求提供可追溯的事实来源，产出会更快，但可引用性会明显下降——而可引用性正是 GEO 的核心目标。这个开关不是“严格程度”的选择，是“要不要做 GEO”的选择。
“失败如何切换” 决定了稳定性。单一模型在高峰期可能超时或限流，配了备选模型的任务不会整批失败。这一项在试点时看不出价值，在批量跑的时候价值极高。
阶段二：生成，十个动作按固定顺序
生成链路的顺序是固定的，每个动作有明确的执行者（人配置的静态数据 / 模型调用 / 确定性算法 / 系统调度）：
- 调度（系统）— 排队取任务
- 挑标题（算法）— 从标题库选
- 拼提示词（算法）— 按配置组装
- 注入内容参数（算法）— 价格、营业时间、政策这类“会过期的事实”
- 检索知识库（算法）— 混合召回，只注入相关切片
- 写正文（AI）
- 配图（AI）
- 生成摘要（人 + AI）
- 品牌语气与公序良俗检查（AI）
- GEO 评分（算法）→ 落库
第 4 步是很多人不知道但很关键的一步。 价格、营业时间、政策这类事实如果写在内容里，改一次就要改几十篇，漏改就产生错误信源——而 AI 恰恰最喜欢引用具体数字。所以我们把它们单独维护成参数表，在生成时注入，而不是让模型从上下文里推断。这样改一处即全站生效。
第 5 步的“只注入相关切片”也不是优化，是必需。 把整个知识库塞进提示词会稀释信号、拉高成本，还可能让模型引用到不该引用的产品线（多产品线品牌尤其明显）。
阶段三：审核，关卡顺序是有原因的
按实际调用顺序，生成时的六道关卡是：
- 关键词蚕食检测 — 新内容和已有内容抢同一个关键词时拦截
- 敏感词与风险扫描 — 平台规则 + 租户自有词库
- 风险门禁 — 综合风险判定
- 品牌手册检查 — 语气、措辞是否符合品牌规范
- 公序良俗审查 — AI 语义审查“字面合规但价值观不当”的内容
- 自定义技能门禁 — 租户自己配的审核规则
蚕食检测排在最前，因为它是唯一一个“内容还没写完就能判定”的问题——两个内容抢同一个词，写得多好都是浪费。让它先跑，可以避免后面五关白跑。
发布时的两道：
- 平台合规预检 — 目标平台的违禁词与格式要求
- 行业合规包 — 医药、金融、教育等强监管行业的专项规则
全路径的两道：
- 托管自动预检 — 全自动模式下，确定性预检全绿才自动放行
- AI 内容标识 — 系统注入，不可绕过
第 12 项是法定强制项，对应《人工智能生成合成内容标识办法》，任何路径都会执行，也不提供关闭开关。这一项不是“可配置的选项”，所以它出现在全路径档而不是生成档。
一个必须讲清的细节：状态有两个字段
所有审核流都会遇到同一个困惑：为什么状态看起来有“两套”。
原因是 status 和 review_status 是两个独立字段：
status（内容是否对外可见）：draft / published / privatereview_status（审核走到哪一步）：pending / submitted / approved / auto_approved / rejected / client_pending / client_approved / client_rejected
两者取值域不重叠，组合起来才描述完整状态。比如一篇文章可能是 status=draft + review_status=approved（审过了但还没发），也可能是 status=published + review_status=submitted（已上线但内容改过、需要重新审）。
把这两个字段画成一条链是常见的错误画法，客户对着系统会找不到对应状态。我们在文档里只描述 review_status 的流转，并显式说明两个字段的区别。
多级审核时，review_status 的流转是：submitted → client_pending → client_approved / client_rejected。驳回会由工作流把 status 归回 draft——被驳回的内容不可能还挂在线上，这一条是强制的。
阶段四：发布，三种方式与三重保底
三种发布方式对应三种不同的技术路径：
- API 直发：走平台官方接口，能回传回执与阅读数据；
- 桌面端本机发布：在客户自己的电脑上执行，用客户已有的登录态；
- 人工发布 + 回填链接：没有接口也没有自动化的平台，发完手动填链接。
为什么要三种而不是一种？因为没有一套技术能覆盖所有平台。有官方 API 的走 API，需要登录态的在本地执行，两者都不具备的手动补。承认这个现实并给三条路径，比宣称“全平台一键发布”更实用——后者通常意味着大量平台发不出去且没有回执。
六种发布状态：queued / sending / synced / failed / cancelled / processing。
三重重试保底：回执重投、指数退避、手动重试。这三层解决的是不同问题——回执重投应对网络抖动导致的回执丢失，指数退避应对平台限流，手动重试应对需要人工判断的失败。
还有一个容易忽略的机制：发布前预检有两种结果。blocker 级问题会跳过该渠道（发了必失败），warning 级问题记录后继续（可能失败但值得试）。区分这两级，是为了避免“一个平台的小问题导致整批不发布”。
阶段五与六：监测与验证
这两个阶段的价值不在“多做了两件事”，而在于它们让前四个阶段的产出可被检验。
监测阶段做的是：同一套问题集投向多个引擎真机采样（不是缓存查询）、每条回答记录原始信源、按问题价值分级采样、竞品同题对照。
验证阶段做的是：留测量条件快照（问题集、平台集合、采样窗口、评分口径）、做假提升自检、把“这一期和上一期的条件差在哪”写清楚。
没有第六阶段，前五个阶段的“成功”是无法验证的——你可以发出 100 篇内容、报告显示提及率上升，但如果问题集变了、引擎集合变了，这个上升可能完全不真实。这一点我们在另一篇文章里专门讲过（复测的五类假提升）。
托管航线：无人值守的十个节点
全自动模式下，整条链路被串成十个节点，其中人工卡点是显式标注的：
AI 可见性采样 → 效果核验 → 关键词挖掘 → 内容生成 → 合规检查 → GEO 评分 → 内容审核（人工卡点）→ 内容分发 → 效果回读 → 完成
开托管不等于放手。 航线上有关键节点必须人点头，未确认不流转。这是产品决策而不是技术限制：把“审核”这一步做成全自动，等于把内容风险完全交给模型，而这个风险由客户承担。
托管模式下，内容审核节点会先跑一遍确定性预检，全绿才自动放行，否则转人工。这个设计让常规内容不用人等，异常内容一定有人看。
这套链路能保证什么、不能保证什么
能保证：
- 每一道关卡都对应真实实现，且执行顺序与代码一致（这一点由测试交叉校验，代码改了测试会失败）；
- 每一步执行留痕，出了问题能定位到具体环节；
- 内容状态、审核状态、发布状态三者一致，不会出现“页面显示已发布但实际没发”。
不能保证：
- 不保证内容会被 AI 引用。这条链路保证的是“内容具备被引用的基础条件 + 合规 + 可追溯”，引用还取决于问题选择、引擎偏好、竞争格局。
- 不保证 12 关全过就能发布。少一道都不行（除了明确标为可选的客户确认），但如果客户自己配了支持文案，自定义技能门禁可能全部通过——这是配置的结果，不是链路的承诺。
- 不保证人工审核的质量。系统能保证“必须有人点过”，不能保证“点的人认真看了”。这是组织问题，不是产品能解决的。
最后一句可能是整篇文章最该记住的：把链路做完整，是把可控的部分做到可控；把不可控的部分说成可控，就是另一种形式的假提升。