一个内容生产 AI 工作流的设计思路：任务状态、知识库与人工审核

如果要把文章生产接入 AI，比较稳妥的目标不是「输入一个标题，自动发布一篇文章」，而是搭建一条可追踪、可审核、可回滚的任务流程。

本文记录一个内容生产工作流的基础设计。流程从需求录入开始，经过知识库检索、初稿生成、人工审核、排期发布和数据复盘。AI 负责生成与整理，人负责事实确认、风险判断和最终放行。

一、工作流整体架构

一个最小可用的内容生产系统，可以拆成六个模块：

flowchart LR A[任务创建] --> B[知识库检索] B --> C[AI 初稿生成] C --> D[人工审核] D -->|通过| E[排期与发布记录] D -->|退回| C E --> F[数据采集与复盘] F --> G[更新知识库与模板] G --> B

这里有两个设计重点。

第一个是「生成」和「发布」必须分离。模型生成的文本只能进入待审核状态，不能直接进入发布状态。

第二个是复盘结果要回到系统内部。审核中发现的表述问题、发布后出现的高频问答、表现稳定的内容结构，都可以沉淀为后续任务可调用的资料。

二、数据结构设计

每篇内容都应被视为一条带状态的任务，而不是单独保存的一份 Markdown 文件。一个基础的数据模型可以这样设计：

yaml 复制代码

content_task:
  id: "CNT-20260525-001"
  title: "一个内容生产 AI 工作流的设计思路"
  topic: "AI 工作流与内容系统"
  platform: "juejin"
  content_type: "technical_article"
  owner: "editor_a"
  reviewer: "reviewer_b"

  requirements:
    target_reader: "开发者与自动化实践者"
    target_length: "1500-2200"
    required_sections:
      - "整体架构"
      - "状态流转"
      - "人工审核"
    forbidden_claims:
      - "未经验证的数据结论"
      - "无法核实的案例"

  knowledge_context:
    collection: "content_guidelines"
    query: "AI 工作流 内容生产 人工审核"
    top_k: 5
    retrieved_chunks:
      - chunk_id: "kb-017"
        source: "review-rules.md"
        version: "v3"
        score: 0.91

  generation:
    model: "llm-model-name"
    prompt_template: "technical_article_v2"
    draft_version: 1
    output_path: "drafts/CNT-20260525-001-v1.md"
    generated_at: "2026-05-25T10:30:00+08:00"

  review:
    status: "pending_review"
    factual_check: false
    compliance_check: false
    style_check: false
    comments: []
    reviewed_at: null

  publication:
    scheduled_at: null
    published_at: null
    url: null
    final_version: null

  metrics:
    views: null
    likes: null
    comments: null
    collected_at: null

  retrospective:
    summary: null
    reusable_rules: []

这类结构有三个好处：

生成文本所依赖的资料可以追踪；
审核结果可以明确记录；
发布后的反馈可以关联回原始任务。

三、状态流转设计

内容任务不应只有「写完」和「发布」两个状态。推荐将流程拆得更明确：

text 复制代码

draft -> pending_review -> approved -> scheduled -> published -> reviewed

各状态含义如下：

状态	说明	可执行动作
`draft`	已创建任务或已有初稿	检索资料、重新生成
`pending_review`	初稿生成完成，等待人工检查	审核、退回修改
`approved`	已通过事实与表达检查	进入排期
`scheduled`	已设置发布时间	发布或取消排期
`published`	已实际发布并记录链接	采集数据
`reviewed`	已完成结果复盘	更新模板和知识库

状态流转需要有约束。例如：

未通过审核的任务不能进入 scheduled；
没有最终版本号的任务不能标记为 published；
没有发布链接或发布凭证的任务不进入数据复盘。

这种约束可以避免系统把「模型已经输出」错误理解为「内容可以公开」。

四、知识库检索节点

知识库节点的任务，是在生成之前为模型准备相对可靠的上下文。

可以存入知识库的资料包括：

技术术语说明；
文章风格约束；
已确认的事实资料；
过往审核规则；
常见问题与标准回答；
已发布文章中可复用的结构。

一次检索请求建议包含：

json 复制代码

{
  "query": "内容生产 AI 工作流 人工审核设计",
  "collection": "content_guidelines",
  "topK": 5,
  "filters": {
    "status": "verified",
    "platform": ["general", "juejin"]
  }
}

检索结果不能只返回正文片段，还应返回来源、版本和更新时间。否则资料被修改后，很难说明初稿依据的是哪一版内容。

在实际实现中，可以将文档切片后写入向量数据库，并保留元数据：

json 复制代码

{
  "chunkId": "kb-017",
  "source": "review-rules.md",
  "version": "v3",
  "updatedAt": "2026-05-20",
  "content": "公开发布前需要检查事实来源、承诺性表述和隐私信息。"
}

五、AI 初稿生成节点

生成节点的输入，不应只有文章标题。至少应包含：

任务主题；
目标平台；
读者类型；
结构要求；
知识库检索结果；
禁止使用的表述；
输出格式要求。

建议让模型返回结构化结果，而不是只返回正文：

json 复制代码

{
  "title": "一个内容生产 AI 工作流的设计思路",
  "markdown": "# ...",
  "referencesUsed": ["kb-017", "kb-021"],
  "uncertainStatements": [
    "具体工具选型尚未指定"
  ],
  "reviewChecklist": [
    "检查示例字段是否与实现一致",
    "检查发布状态流转说明"
  ]
}

这样，审核人员不仅能看文章，也能快速看到模型使用了哪些资料、哪里存在待确认信息。

六、人工审核节点

人工审核是整个流程中不可跳过的发布闸门。

审核可以拆成四类：

1. 事实检查

检查术语、数据、引用、功能描述和示例是否准确。如果文章中提到了具体系统能力，应确认该能力确实存在。

2. 风险检查

检查是否包含未经确认的结论、敏感信息、隐私数据、版权风险或容易引起误解的表述。

3. 技术检查

检查流程图、字段设计、状态迁移和代码示例是否自洽。例如文章写了 published 状态需要 URL，那么代码中也应做对应判断。

4. 平台表达检查

掘金文章需要有实现结构和技术判断。如果全文只有观点，没有数据模型、流程设计或示例代码，即使表达流畅，也不符合技术文章预期。

七、判断内容能否进入发布状态

下面是一个简化的 JavaScript 示例，用于判断任务是否允许从 pending_review 进入 approved，再进入 scheduled：

js 复制代码

function canApprove(task) {
  if (task.review.status !== "pending_review") {
    return { ok: false, reason: "当前任务不在待审核状态" };
  }

  const checks = [
    task.review.factual_check,
    task.review.compliance_check,
    task.review.style_check
  ];

  if (checks.some((passed) => passed !== true)) {
    return { ok: false, reason: "人工审核项尚未全部通过" };
  }

  if (!task.generation.output_path || task.generation.draft_version < 1) {
    return { ok: false, reason: "缺少可发布的内容版本" };
  }

  return { ok: true };
}

function schedulePublication(task, scheduledAt) {
  const approval = canApprove(task);

  if (!approval.ok) {
    throw new Error(approval.reason);
  }

  return {
    ...task,
    review: {
      ...task.review,
      status: "approved"
    },
    publication: {
      ...task.publication,
      scheduled_at: scheduledAt
    },
    status: "scheduled"
  };
}

真实系统中，还可以增加版本锁、审核人权限、操作日志和失败重试机制。

八、发布记录与数据复盘节点

文章发布后，应将最终标题、正文版本、链接和发布时间写回任务记录：

yaml 复制代码

publication:
  final_version: 3
  published_at: "2026-05-26T09:00:00+08:00"
  url: "https://example.com/post/123"
  status: "published"

随后进入数据复盘节点。复盘不必只看阅读数，还可以记录：

评论区出现了哪些技术问题；
哪些段落被读者引用或讨论；
审核阶段修改最频繁的内容是什么；
哪些信息适合补充到知识库；
哪些提示词模板需要调整。

例如，多次审核都发现文章把「模型生成结果」写得过于确定，就可以将一条新规则写入审核库：

yaml 复制代码

rule:
  id: "RULE-042"
  content: "涉及模型输出时，使用辅助生成、待人工确认等描述。"
  source: "retrospective"
  status: "verified"

下一次生成时，这条规则就可以通过知识库检索节点被重新使用。

九、实现时容易忽略的细节

一个内容生产工作流在实现阶段，还需要考虑几个工程问题：

幂等性：重复触发生成任务时，是否会创建多个冲突版本；
版本管理：发布的是哪一稿，后续修改如何追踪；
权限控制：谁可以审核，谁可以发布；
失败重试：模型接口或发布接口失败后如何恢复；
审计日志：谁在什么时间修改了什么状态；
知识更新：旧规则被替换后，历史文章是否仍能追溯原始依据。

这些部分比「一次生成了多少文字」更能决定系统是否可维护。

十、结语

内容生产接入 AI 后，最值得先工程化的，不是写作本身，而是任务状态、上下文资料、审核闸门、发布记录和复盘回流。

一套可用的工作流应当满足三件事：

生成过程有可靠上下文；
发布之前有明确人工审核；
发布之后有数据和经验回流。

当任务能够从 draft 稳定走到 reviewed，并把复盘结果重新写回知识库和提示词模板，AI 才真正成为内容系统中的一个可维护组件，而不是临时生成文本的接口。