AIGC 内容生产案例:从生成到审核发布的流水线
模型跑得越快,后面越容易出事
去年我给一个内容团队做过一次复盘。他们用大模型批量生成行业分析稿,日均产出从 5 篇涨到 80 篇。产量上去了,但两个月后搜索引擎收录率从 72% 掉到 31%,站内编辑返工量反而比手写时代还高。问题不在模型——模型干的事没什么大毛病。问题出在生成之后的环节全是空的:没有事实校验、没有版权检查、没有风格一致性控制,生成完就直接进了 CMS 待发布队列。
这不是个例。2026 年初中国 AIGC 用户规模已经突破 5 亿(数据来源:东方财富 2026 年 AI 视频生成行业报告),大量团队已经把 LLM 接入了日常内容生产,但多数人的精力花在 Prompt 工程和模型选型上,对「生成之后」的流水线投入不够。
这篇文章把我这几年做 AIGC 内容系统的经验整理出来,重点不是怎么让模型写得更好,而是怎么让生成的内容安全、可控、可追踪地到达读者面前。
流水线的理论基础:分层治理 + 人在回路
AIGC 内容系统本质上是一个多阶段的信息处理管道。每一层有不同的职责,不能混在一起。
六层工作流模型
阿里云开发者社区在 2026 年 5 月提出过一个「企业 AI 智能体六层工作流」框架(原文链接),把从需求到输出的过程分成:
- 需求输入 — 明确任务目标和约束条件
- 信息整理 — 把散乱资料结构化
- AI 处理 — 模型生成初稿
- 人工审核 — 事实、合规、口径把关
- 标准输出 — 格式化为可发布内容
- 数据复盘 — 记录效果,反馈到 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 内容生产流水线是这样的:
各阶段工具选型对比
事实校验工具
| 工具/方案 | 类型 | 优势 | 局限 | 适合场景 |
|---|---|---|---|---|
| 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 的特殊之处在于生成速度远超人工审核速度,这要求我们在流水线设计上做好「快慢分离」:快路径处理低风险内容,慢路径处理高风险内容,而不是所有内容都走同一套流程。
参考资料
- 企业如何搭建 AI 智能体工作流:从需求输入到人工审核的六层设计 — 阿里云开发者社区,2026 年 5 月
- Human-in-the-Loop, Human-on-the-Loop, and LLM-as-a-Judge for Validating AI Outputs — Kili Technology
- How to Fact-Check AI Content Like a Pro — Articulate,2025 年 1 月
- AIGC 侵权的责任划分:AI 平台与用户的责任边界 — 君合律师事务所,2026 年 1 月
- Building a "Fact-Checking" Workflow: How to Prevent Factual Errors — CNABKE,2026 年 4 月
- 2026 年中国 AIGC 产业链及竞争现状 — 中国产业信息网,2026 年 2 月
- How to Run Human-in-the-Loop Evals for LLM Apps — Braintrust,2026 年 4 月
- AIGC 检测技术如何重塑内容查重规则 — AIGC.cn