AIGC 内容生产案例:从生成到审核发布的流水线

0阅读11分钟

模型跑得越快,后面越容易出事

去年我给一个内容团队做过一次复盘。他们用大模型批量生成行业分析稿,日均产出从 5 篇涨到 80 篇。产量上去了,但两个月后搜索引擎收录率从 72% 掉到 31%,站内编辑返工量反而比手写时代还高。问题不在模型——模型干的事没什么大毛病。问题出在生成之后的环节全是空的:没有事实校验、没有版权检查、没有风格一致性控制,生成完就直接进了 CMS 待发布队列。

这不是个例。2026 年初中国 AIGC 用户规模已经突破 5 亿(数据来源:东方财富 2026 年 AI 视频生成行业报告),大量团队已经把 LLM 接入了日常内容生产,但多数人的精力花在 Prompt 工程和模型选型上,对「生成之后」的流水线投入不够。

这篇文章把我这几年做 AIGC 内容系统的经验整理出来,重点不是怎么让模型写得更好,而是怎么让生成的内容安全、可控、可追踪地到达读者面前。

流水线的理论基础:分层治理 + 人在回路

AIGC 内容系统本质上是一个多阶段的信息处理管道。每一层有不同的职责,不能混在一起。

六层工作流模型

阿里云开发者社区在 2026 年 5 月提出过一个「企业 AI 智能体六层工作流」框架(原文链接),把从需求到输出的过程分成:

  1. 需求输入 — 明确任务目标和约束条件
  2. 信息整理 — 把散乱资料结构化
  3. AI 处理 — 模型生成初稿
  4. 人工审核 — 事实、合规、口径把关
  5. 标准输出 — 格式化为可发布内容
  6. 数据复盘 — 记录效果,反馈到 Prompt 优化

这个模型的关键点是:模型输出永远不是最终交付物。AI 处理只是六层中的一层,前后各有依赖。

人在回路(Human-in-the-Loop)的三种模式

Kili Technology 在一篇技术博客中(原文链接)区分了三种审核介入方式:

模式含义适用场景
Human-in-the-Loop人工逐条审批或修改后才放行医疗、金融、法律等高风险领域
Human-on-the-Loop人工监控仪表盘,异常时介入批量内容生产、营销文案
LLM-as-a-Judge用另一个 LLM 评分和审查初筛、大规模质量检测

实际操作中,三种模式往往组合使用。我的经验是用 LLM-as-a-Judge 做第一道快速过滤,把明显问题拦住;然后 Human-on-the-Loop 处理常规内容;只有涉及敏感话题、数据引用或法律风险的内容才走 Human-in-the-Loop 逐条审核。

五层质量管控栈

对于生产级系统,我推荐一个五层质量管控架构:

层级功能延迟成本
L1 规则过滤敏感词、格式校验、字数检查< 10ms极低
L2 模型检测AI 生成概率、重复率、事实置信度100-500ms
L3 LLM 评审用另一个模型评分(准确性、可读性、风格)1-5s
L4 人工审核领域专家审核高风险内容分钟-小时
L5 发布后监控用户反馈、搜索表现、举报处理持续中等

每一层只处理自己擅长的事,成本从低到高递增,越早拦截问题修复成本越低。

案例一:事实校验缺失——数据引用「张冠李戴」

场景

一家 B2B SaaS 公司的内容团队用 GPT-4 级别的模型生成行业白皮书。模型在文中引用了多组数据:「2025 年中国 CRM 市场规模达 68.3 亿元,同比增长 23.7%」。

翻车

发布后被行业读者指出,这个数字实际来自 2023 年的报告,而且口径是「亚太区」而非「中国」。模型把年份、区域和数字做了错误组合。更麻烦的是,文中附的「数据来源」链接指向了一个 404 页面——模型编造了一个看起来很像真的 URL。

这篇文章在官网挂了 11 天才被发现,期间被 3 家媒体引用。

修复方案

我们给流水线加了三级事实校验:

// ❌ 坏做法:模型输出直接入库
async function publishDraft(draft: GeneratedDraft) {
  await cms.publish({
    title: draft.title,
    body: draft.content,
    status: 'published'
  })
}
 
// ✅ 好做法:三级事实校验后再入库
async function publishDraft(draft: GeneratedDraft) {
  // 第一级:自动提取所有数据声明
  const claims = await extractClaims(draft.content)
 
  // 第二级:逐条交叉验证
  const results = await Promise.all(
    claims.map(claim => verifyClaim(claim, {
      sources: trustedDataSource,  // 可信数据源白名单
      maxAge: '1y',                // 数据时效性上限
      checkUrl: true               // 验证引用链接可达性
    }))
  )
 
  // 第三级:有未通过验证的声明 → 进人工审核
  const failed = results.filter(r => r.status === 'unverified')
  if (failed.length > 0) {
    return routeToHumanReview(draft, failed)
  }
 
  await cms.publish({
    title: draft.title,
    body: draft.content,
    factCheckReport: results,  // 附加校验报告
    status: 'published'
  })
}

校验模块的核心是 extractClaims 函数——它用专门的 Prompt 从文章中提取所有包含数字、日期、百分比、引用的句子,然后和已知数据源做交叉比对。

事实校验 Prompt 模板

// ❌ 坏做法:模糊的验证指令
const badPrompt = `请检查这篇文章有没有事实错误。`
 
// ✅ 好做法:结构化提取 + 明确验证标准
const goodPrompt = `从以下文章中提取所有事实性声明,按以下格式输出 JSON 数组:
[
  {
    "claim": "原文中的事实性句子",
    "type": "statistics|date|quote|url|comparison",
    "specificValue": "具体数字或引用内容",
    "sourceMentioned": "文中提到的来源",
    "confidence": "high|medium|low"
  }
]
 
提取标准:
- 包含具体数字、百分比、金额的声明
- 包含具体日期或年份的声明
- 明确归因于某个来源的引用
- 包含 URL 或报告名称的引用
- 涉及「最大」「第一」「首次」等排他性表述
 
不要提取观点性陈述或常识性描述。`

加上这套机制后,白皮书的事实错误率从每万字 4.2 处降到 0.3 处。代价是每篇文章的平均发布延迟增加了约 15 分钟(主要是 L3 LLM 评审的耗时),但对于需要长期留存的深度内容来说,这个交换值得。

案例二:版权风险——AI 生成的内容「太像」原文

场景

一个电商内容团队用 LLM 生成商品描述。为了追求「专业感」,Prompt 里写了「参考行业头部品牌的表述风格」。

翻车

生成的商品描述和某个竞品的官方文案有段落级别的相似度。法务同事用查重工具一扫,连续 3 篇商品描述与竞品文案的相似度超过 60%。虽然法律上「AI 生成的内容是否构成侵权」目前仍有争议(参见君合律师事务所 AIGC 侵权责任分析),但平台收到竞品投诉后的处理成本是实实在在的。

修复方案

在生成后增加原创性检测层,结合传统查重和语义相似度检测:

// ❌ 坏做法:只看精确文本匹配
function checkOriginality_bad(content: string, competitorTexts: string[]) {
  // 只做字符串包含检测,完全抓不到改写后的相似
  return competitorTexts.some(text => content.includes(text))
}
 
// ✅ 好做法:多层原创性检测
interface OriginalityReport {
  exactMatchScore: number      // 精确匹配率
  semanticSimilarity: number   // 语义相似度 (0-1)
  ngramOverlap: number         // n-gram 重叠率
  flaggedSegments: Array<{     // 具体风险段落
    text: string
    matchedSource: string
    similarity: number
  }>
  riskLevel: 'low' | 'medium' | 'high'
}
 
async function checkOriginality(
  content: string,
  referenceCorpus: string[]  // 竞品文案、已知版权内容库
): Promise<OriginalityReport> {
  // 第一层:精确文本匹配(快速排除直接复制)
  const exactMatchScore = calculateExactMatch(content, referenceCorpus)
 
  // 第二层:n-gram 重叠检测(抓改写和微调)
  const ngramOverlap = calculateNgramOverlap(content, referenceCorpus, { n: 5 })
 
  // 第三层:语义相似度(用 embedding 模型检测「换汤不换药」)
  const contentEmbedding = await getEmbedding(content)
  const referenceEmbeddings = await Promise.all(
    referenceCorpus.map(ref => getEmbedding(ref))
  )
  const semanticSimilarity = Math.max(
    ...referenceEmbeddings.map(refEmb =>
      cosineSimilarity(contentEmbedding, refEmb)
    )
  )
 
  // 综合评分
  const riskScore = exactMatchScore * 0.3
    + ngramOverlap * 0.3
    + semanticSimilarity * 0.4
 
  return {
    exactMatchScore,
    semanticSimilarity,
    ngramOverlap,
    flaggedSegments: findFlaggedSegments(content, referenceCorpus),
    riskLevel: riskScore > 0.6 ? 'high' : riskScore > 0.3 ? 'medium' : 'low'
  }
}
检测方式能抓到的问题盲区
精确文本匹配直接复制粘贴同义词替换、句式改写
n-gram 重叠小幅改写、段落重组完全重写但观点结构相同
语义相似度 (embedding)核心观点高度雷同通用表述、行业术语重合
组合使用覆盖绝大多数场景需要调参避免误报

上线后我们观察到,语义相似度阈值设在 0.75 以上时,误报率约 8%(通用行业术语导致的正常相似被标记)。调到 0.82 后误报率降到 3% 以下,可以作为可接受水平。

案例三:风格漂移——同一品牌的内容读起来像三个人写的

场景

一个内容中台同时服务官网博客、微信公众号和知乎专栏三个渠道。编辑团队用同一个 LLM 生成内容,但发现不同渠道的内容风格差异过大:知乎文章过于口语化,公众号文章用了太多感叹号,博客文章读起来像产品说明书。

问题

不是模型能力问题。三个渠道用了不同的 Prompt,但缺少一个统一的风格约束层。每个 Prompt 各自描述了风格,但描述方式不一致,有的说「专业但友好」,有的说「轻松活泼」,模型对这些抽象形容词的理解和编辑团队的预期存在偏差。

修复方案

建立风格锚点系统——用真实文章作为风格参考,而不是依赖抽象形容词:

// ❌ 坏做法:用抽象形容词描述风格
const badStylePrompt = `
请用专业但友好的语气写这篇文章。
不要太正式,也不要太随意。
保持简洁有力的表达风格。
`
// 问题:「专业但友好」对不同模型含义不同,且无法量化验证
 
// ✅ 好做法:用风格锚点 + 可量化规则
interface StyleProfile {
  name: string
  referenceExcerpts: string[]    // 真实文章片段作为锚点
  sentenceLengthAvg: [number, number]  // 平均句长范围
  formalityLevel: 'formal' | 'neutral' | 'casual'
  forbiddenPatterns: string[]    // 禁用的表达模式
  requiredElements: string[]     // 必须包含的元素
}
 
const zhihuProfile: StyleProfile = {
  name: '知乎专栏',
  referenceExcerpts: [
    '这个方案的核心不在于技术选型,而在于团队有没有能力在两周内完成迁移。',
    '我们做过一次 A/B 测试,结果是指标没有显著变化,但用户反馈里出现了新的抱怨。'
  ],
  sentenceLengthAvg: [15, 25],
  formalityLevel: 'neutral',
  forbiddenPatterns: ['!', '真的', '超级', '家人们', '震惊'],
  requiredElements: ['至少一个具体案例', '明确的数据来源']
}
 
async function generateWithStyle(
  topic: string,
  profile: StyleProfile,
  model: LLMClient
) {
  const response = await model.generate({
    system: `你是一个内容编辑。请参考以下风格样本写作:
 
【风格样本 1】
${profile.referenceExcerpts[0]}
 
【风格样本 2】
${profile.referenceExcerpts[1]}
 
写作规则:
- 平均句长控制在 ${profile.sentenceLengthAvg[0]}-${profile.sentenceLengthAvg[1]} 字
- 正式程度:${profile.formalityLevel}
- 禁止使用:${profile.forbiddenPatterns.join('、')}
- 必须包含:${profile.requiredElements.join('、')}`,
    user: `主题:${topic}`
  })
 
  // 生成后验证风格一致性
  const styleCheck = await validateStyle(response.content, profile)
  if (!styleCheck.passed) {
    // 不通过则带反馈重新生成(最多重试 2 次)
    return generateWithStyle(topic, profile, model)
  }
 
  return response.content
}
风格约束方式可控性维护成本效果
抽象形容词(「专业友好」)模型理解偏差大,不同次生成风格飘忽
风格锚点 + 量化规则风格一致性显著提升,但需要维护样本库
Fine-tuning很高最稳定,但需要足够的训练数据和算力
风格锚点 + LLM 评审生成后用另一个模型按风格标准打分,不合格则重写

我们最终选了「风格锚点 + LLM 评审」的组合:生成后用一个独立的 LLM 调用,给它风格样本和评分标准,让它判断新文章和样本的风格匹配度(1-10 分),低于 7 分的重新生成。三个渠道的风格一致性评分从之前的平均 5.2 提升到了 7.8。

完整流水线:从选题到发布监控

把上面三个案例的解决方案串起来,一个完整的 AIGC 内容生产流水线是这样的:

流程图画布 · 115%
Mermaid 流程图加载中...

各阶段工具选型对比

事实校验工具

工具/方案类型优势局限适合场景
LLM 声明提取 + 数据源交叉验证自建灵活度高,可定制校验规则需要维护可信数据源库行业报告、白皮书
ClaimBuster开源工具可检测值得验证的声明英文为主,中文需适配新闻、媒体内容
Google Fact Check Tools API商业 API覆盖已有事实核查数据库仅覆盖已核查过的声明公共话题、热点事件
人工专家审核人工判断力最强慢、贵、不可规模化高风险、高影响内容

原创性检测方案

方案核心原理速度准确率适用规模
精确字符串匹配文本包含检测极快低(只能抓直接复制)初筛
SimHash / MinHash局部敏感哈希大规模去重
Embedding 余弦相似度语义向量比较中等中等规模深度检测
Turnitin / 知网查重商业数据库比对中等学术、出版场景

人在回路介入方式

方式人工参与度吞吐量质量保障推荐场景
全量人工审核100%最高医疗、金融、法律内容
抽检(随机 10-20%)10-20%中等低风险营销内容
异常触发审核按需较高较高自动化程度较高的流水线
LLM 初审 + 人工复审20-40%中等较高推荐的通用方案

发布后监控指标

指标类别具体指标采集方式报警阈值建议
内容质量编辑返工率CMS 修改记录> 30% 触发复盘
搜索表现收录率、平均排名Search Console API收录率 < 50% 报警
用户反馈页面停留时间、跳出率分析工具停留 < 30s 或跳出 > 80%
合规风险举报数量、侵权投诉客服系统 / 平台通知任何侵权投诉立即响应
生产效率从生成到发布的平均耗时流水线日志趋势恶化 > 20% 报警
事实准确性勘误率、读者纠错反馈评论区 / 反馈渠道每万字 > 0.5 处触发审查

上线前检查清单

一、生成阶段

  • Prompt 模板经过 3 轮以上迭代,有版本记录
  • 风格锚点样本库已建立,每个渠道至少 5 个样本
  • 模型输出包含结构化元数据(来源、置信度、生成时间)
  • 设置了单次生成的最大长度,防止无意义膨胀

二、校验阶段

  • 事实校验模块已对接至少 1 个可信数据源
  • 版权检测覆盖精确匹配 + 语义相似度两层
  • 敏感词/违禁词库保持更新(至少每月一次)
  • URL 引用验证可达性,404 链接自动拦截

三、审核阶段

  • 高风险内容分类规则已定义(涉及数字、法律、医疗、竞品)
  • 审核人员有明确的检查清单和判断标准
  • 审核修改点有记录,可回流到 Prompt 优化
  • 紧急内容有快速通道,但不能跳过事实校验

四、发布与监控

  • 发布后 24 小时内自动检查搜索收录状态
  • 用户举报和反馈有自动归类到对应内容的机制
  • 内容下架流程可在 30 分钟内完成
  • 每周有一次流水线数据复盘(通过率、返工率、耗时分布)

写在最后

AIGC 内容系统的价值不在于「生成了多少篇」,而在于「稳定发布了多少篇质量达标的内容」。生成能力是廉价的——调用一次 API 只需要几秒和几分钱。但生成之后的校验、审核、监控、复盘,这些环节加起来占了一个内容系统 70% 以上的工作量。

我在实践中观察到,投入足够多精力在「后半段流水线」的团队,内容质量指标(收录率、用户停留、编辑返工率)通常在 3-6 个月内会有明显改善。而只关注生成端的团队,往往陷入「越生成越多,越多越要改,越改越累」的循环。

流水线思维不是 AIGC 独有的——传统内容工厂也有类似流程。但 AIGC 的特殊之处在于生成速度远超人工审核速度,这要求我们在流水线设计上做好「快慢分离」:快路径处理低风险内容,慢路径处理高风险内容,而不是所有内容都走同一套流程。

参考资料

评论 0

0 / 1000