# 一篇内容从建任务到效果验证：六个阶段与 12 道关卡的真实位置

> 「我们的内容要过 12 道关卡」这句话不准确——那 12 道挂在三个不同时点，实际经过几道取决于走哪条发布路径。本文按代码真实执行顺序讲清六阶段主线、每一关卡在哪、两个状态字段的区别，以及这条链路能保证什么、不能保证什么。

## 一个必须先讲清的事实：「12 道关卡」不是每篇内容都过

先纠正一个在讲 GEO 内容生产时很常见的错误说法：**「我们的内容要过 12 道关卡才能发布」**。

这句话听起来很有说服力，但它不准确。准确的说法是：系统里共有 12 道把关机制，它们挂在**不同时点**，一篇内容实际经过的关卡取决于它走哪条发布路径。

分清这一点很重要：客户拿这句话去核对系统时，会发现某些关卡在自己的流程里从没触发过，然后开始怀疑整套说法。**把机制清单说成流程承诺，是这类介绍最容易犯的错**——所以我们先按真实调用位置把三档讲清楚。

## 三个阶段时点

按代码里的实际执行顺序，关卡分三类时点：

**① 生成时（generate）**：内容生成或重新保存时执行。这类关卡拦的是“内容本身有问题”——关键词冲突、敏感词、品牌语气不符、价值观风险。

**② 发布时（publish）**：后台人工点“发布”时执行。这类拦的是“这个平台不让发”——平台合规预检、行业合规包。

**③ 全路径（always）**：由工作流或系统强制，无论走哪条路径都跑。这类是兜底与法定义务——托管自动预检、AI 内容标识。

这个分档不是文字游戏，它决定了每一关该由谁负责：生成时的关卡是编辑在自己电脑上就会遇到的，发布时的关卡是运营在点按钮时才遇到的，全路径的关卡是系统自己做的、没人需要操作。

## 六阶段主线：从建任务到效果验证

把上面的关卡放回完整链路，内容生产是一条六阶段的主线：

| 阶段 | 执行者 | 做什么 |
|---|---|---|
| 一、建任务 | 人 | 定方向、选引擎、备物料、定审发、配协作 |
| 二、AI 生成 | AI | 调度 → 挑标题 → 拼提示词 → 检索知识库 → 写正文 → 配图 → 摘要 → 语气与公序良俗检查 → GEO 评分 → 落库 |
| 三、审核 | 人 + AI | 过风险门禁、品牌手册、公序良俗、行业合规包、人工审核 |
| 四、发布 | 系统 | 三种发布方式、六种状态、失败重试三重保底 |
| 五、监测 | AI | 多引擎真机采样、固定问题集复测、竞品对照、信源分析 |
| 六、验证 | 人 + AI | 测量条件快照 + 假提升自检，数字可复算 |

六个阶段各有明确产出物，且**能被下一阶段验证**：建任务产出配置，生成产出稿件，审核产出结论，发布产出回执，监测产出采样，验证产出对比。这是它和“六个工具的拼盘”的区别——拼盘没有交接，这条线上每一环都在给下一环交付东西。

## 阶段一：建任务，五组配置决定后面所有事

这一步最容易被当成“填表”，但配置项直接决定产出质量。按代码里的实际分组是五组：

**方向组**：内容简报、证据要求、语言与格式。

**引擎组**：用技能还是用提示词、选哪个模型、失败如何切换、挂哪些知识库。

**物料组**：标题库、图片库、作者与分类。

**审发组**：是否需要审核、发布范围、发布间隔、分发渠道、数量限制。

**协作组**：指派给谁、是否自动提关键词、是否自动生成描述。

其中两项值得单独说：

**“证据要求”是很多团队会关掉、然后后悔的一项。** 关掉之后模型不被要求提供可追溯的事实来源，产出会更快，但可引用性会明显下降——而可引用性正是 GEO 的核心目标。这个开关不是“严格程度”的选择，是“要不要做 GEO”的选择。

**“失败如何切换”** 决定了稳定性。单一模型在高峰期可能超时或限流，配了备选模型的任务不会整批失败。这一项在试点时看不出价值，在批量跑的时候价值极高。

## 阶段二：生成，十个动作按固定顺序

生成链路的顺序是固定的，每个动作有明确的执行者（人配置的静态数据 / 模型调用 / 确定性算法 / 系统调度）：

1. **调度**（系统）— 排队取任务
2. **挑标题**（算法）— 从标题库选
3. **拼提示词**（算法）— 按配置组装
4. **注入内容参数**（算法）— 价格、营业时间、政策这类“会过期的事实”
5. **检索知识库**（算法）— 混合召回，只注入相关切片
6. **写正文**（AI）
7. **配图**（AI）
8. **生成摘要**（人 + AI）
9. **品牌语气与公序良俗检查**（AI）
10. **GEO 评分**（算法）→ 落库

**第 4 步是很多人不知道但很关键的一步。** 价格、营业时间、政策这类事实如果写在内容里，改一次就要改几十篇，漏改就产生错误信源——而 AI 恰恰最喜欢引用具体数字。所以我们把它们单独维护成参数表，在生成时注入，而不是让模型从上下文里推断。这样改一处即全站生效。

**第 5 步的“只注入相关切片”也不是优化，是必需。** 把整个知识库塞进提示词会稀释信号、拉高成本，还可能让模型引用到不该引用的产品线（多产品线品牌尤其明显）。

## 阶段三：审核，关卡顺序是有原因的

按实际调用顺序，生成时的六道关卡是：

1. **关键词蚕食检测** — 新内容和已有内容抢同一个关键词时拦截
2. **敏感词与风险扫描** — 平台规则 + 租户自有词库
3. **风险门禁** — 综合风险判定
4. **品牌手册检查** — 语气、措辞是否符合品牌规范
5. **公序良俗审查** — AI 语义审查“字面合规但价值观不当”的内容
6. **自定义技能门禁** — 租户自己配的审核规则

**蚕食检测排在最前**，因为它是唯一一个“内容还没写完就能判定”的问题——两个内容抢同一个词，写得多好都是浪费。让它先跑，可以避免后面五关白跑。

发布时的两道：

7. **平台合规预检** — 目标平台的违禁词与格式要求
8. **行业合规包** — 医药、金融、教育等强监管行业的专项规则

全路径的两道：

11. **托管自动预检** — 全自动模式下，确定性预检全绿才自动放行
12. **AI 内容标识** — 系统注入，不可绕过

**第 12 项是法定强制项**，对应《人工智能生成合成内容标识办法》，任何路径都会执行，也不提供关闭开关。这一项不是“可配置的选项”，所以它出现在全路径档而不是生成档。

## 一个必须讲清的细节：状态有两个字段

所有审核流都会遇到同一个困惑：**为什么状态看起来有“两套”**。

原因是 `status` 和 `review_status` 是两个独立字段：

- **`status`**（内容是否对外可见）：draft / published / private
- **`review_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 关全过就能发布**。少一道都不行（除了明确标为可选的客户确认），但如果客户自己配了支持文案，自定义技能门禁可能全部通过——这是配置的结果，不是链路的承诺。
- **不保证人工审核的质量**。系统能保证“必须有人点过”，不能保证“点的人认真看了”。这是组织问题，不是产品能解决的。

最后一句可能是整篇文章最该记住的：**把链路做完整，是把可控的部分做到可控；把不可控的部分说成可控，就是另一种形式的假提升。**