前段时间看到一篇关于 AI 带货的报道某团队在 TikTok Shop 上搭建了一套完全由 AI 驱动的“内容工厂”批量生成带货短视频持续推销一款已经被 FDA 召回的保健品。这里的“Slop Factory”准确概括了这类流水线的本质——用极低的内容成本海量生产、快速分发至于产品合不合规、宣传内容有没有违规风险整条链路里根本没有一个环节去把关。这个案例非常值得做技术复盘。它揭示的问题不是“AI 能不能做营销”而是“AI 营销系统的工程链路里为什么可以把产品合规审查完全漏掉”。这篇文章会从技术角度拆解这类 AI 带货视频一键成片系统的工作原理分析被召回产品为何仍会被 AI 大量推销并给出构建一套具备合规审查能力的 AI 营销内容系统的思路和代码示例。适合人群正在做 AI 营销工具、AIGC 内容中台、社交电商自动化的开发者以及关注内容安全和产品合规的测试、产品、运营同学。1. 什么是 AI 内容工厂从一个被曝光的案例说起1.1 案例背景TikTok Shop 上的保健品带货TikTok Shop 是近年来增长很快的社交电商场景短视频带货、直播带货、达人分销已经形成完整生态。和传统货架电商不同TikTok Shop 的内容属性很强一条视频如果钩子够好、互动率够高可能带来大量自然流量。这种“内容即货架”的模式天然适合批量生产、快速试错的内容打法。于是出现了所谓的 AI 内容工厂一套系统自动生成带货脚本、自动配音、自动剪辑、自动生成字幕最后通过多个矩阵账号批量发布。它们往往以“AI 带货视频一键成片系统”为卖点宣称几分钟就能生成几百条视频大大提高铺量效率。问题在于当产品本身存在安全问题例如被 FDA 召回AI 生产的内容越多风险扩散得越快。FDA 召回意味着产品可能存在安全隐患继续在电商渠道推广通常是被严格禁止的。但在这条 AI 流水线上系统并不知道产品被召回它只知道“卖点文案是什么”“视频模板怎么套”于是被召回的产品继续被包装成“健康好物”推给大量用户。1.2 技术链条全景把这类系统拆开看技术链路其实并不复杂通常包含 5 个核心层产品信息层维护产品库、卖点素材、资质文件。内容生成层用大语言模型生成脚本用 TTS 生成语音用数字人或者模板生成视频画面。视频合成层把脚本、字幕、配音、背景音乐、商品卡片组合成成品视频。发布管理层多平台账号授权、定时发布、批量分发。数据回流层采集播放量、互动率、转化数据反哺下一轮内容生成。单看每一层技术难点都不高。常见做法是调用 OpenAI、Claude 等模型生成文案调用现有 TTS 服务生成配音再用 FFmpeg 做视频拼接。真正把系统区分开的是工程化能力和合规风控能力。1.3 案例中的致命缺口在这个被曝光的案例中致命缺口出现在两个位置第一产品合规状态没有接入系统。系统只读取了产品的基础卖点信息没有查询召回清单、下架清单也没有校验产品的注册信息和资质文件。产品是否合法、是否被召回这些数据完全没有进入系统。第二内容发布环节没有合规拦截。AI 生成脚本后直接进入配音合成流程缺少广告法违禁词检查、医疗功效断言检查、说明书一致性检查。于是“提升免疫力”“修复细胞”“对抗衰老”这类夸张宣传大量出现进一步放大了风险。这不是某一个 AI 模型的问题而是系统设计时根本没有定义“红线”。下面我们从技术角度把这条链路完整拆一遍。2. AI 带货视频一键成片系统的技术原理2.1 脚本生成层LLM 如何生成带货文案带货脚本生成是整条链路的第一环。早期做法是准备大量文案模板用变量替换的方式生成不同变体。后来大语言模型普及系统普遍改用 LLM 直接生成脚本因为生成结果更自然、每一条内容都不一样不容易重复。下面是一个简化示例演示如何调用 LLM 生成带货脚本。请注意这只是技术演示实际生产环境中必须加入合规审查层。# 示例代码调用 LLM 生成带货脚本 # 文件路径script_generator.py from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlyour-base-url # 如果使用代理或私有化部署需要按实际环境填写 ) PRODUCT_PROMPT 你是一名短视频带货文案策划请根据以下产品信息生成一条 15 秒的短视频脚本。 产品名称{product_name} 产品类目{category} 核心卖点{selling_points} 目标人群{target_audience} 请按以下结构输出 1. 开场钩子15字以内 2. 痛点引入30字以内 3. 产品介绍60字以内 4. 行动号召20字以内 注意内容不得涉及医疗功效承诺不得使用“根治”“包治”“绝对有效”等违规表述。 def generate_script(product): prompt PRODUCT_PROMPT.format( product_nameproduct[name], categoryproduct[category], selling_points.join(product[selling_points]), target_audienceproduct[target_audience], ) response client.chat.completions.create( modelgpt-4o-mini, messages[ {role: system, content: 你是一个合规意识很强的带货文案助手。}, {role: user, content: prompt}, ], temperature0.8, max_tokens500, ) return response.choices[0].message.content这段代码本身没有技术难度但有两个值得注意的点。第一提示词里即使写了“不得涉及医疗功效承诺”LLM 仍然可能输出违规内容因为模型本质上是在做概率生成不是规则执行。合规不能只靠提示词必须在生成后接一层独立的检测逻辑。第二产品信息从哪来很关键。如果产品信息来自一个未经审核的数据库里面甚至包含已经下架、召回的产品那么生成脚本在源头上就已经出问题了。合规过滤应该发生在生成之前而不是生成之后。2.2 视频合成层数字人、TTS 与批量渲染脚本生成后进入视频合成阶段。典型的合成步骤包括用 TTS 服务将脚本合成为音频。选择数字人形象或商品展示模板。用 FFmpeg 将音频、视频画面、字幕、背景音乐合成。添加商品展示卡片和点击链接。TTS 调用示例# 示例代码调用 TTS 生成配音 # 文件路径tts_service.py import edge_tts import asyncio async def generate_voice(text, output_path, voicezh-CN-XiaoxiaoNeural): communicate edge_tts.Communicate(text, voice) await communicate.save(output_path) return output_path if __name__ __main__: script 上班久坐总觉得没精神这款产品可以帮你找回状态。 asyncio.run(generate_voice(script, output.mp3))这里的重点是合成阶段不应该只做音画合成还应该在合成前再次检查文本内容。很多系统只在 LLM 生成脚本时做一次是否合规的判断之后脚本被改写、截断、拼接内容可能再次变化。合理的做法是在最终渲染前对最终脚本做一次完整的合规扫描。FFmpeg 合成命令示例ffmpeg -i output.mp3 -i product_bg.mp4 -c:v libx264 -c:a aac -shortest final_video.mp4这条命令把配音和背景视频合并成一个文件。实际操作中还会加上字幕烧录、转场特效、商品贴图等操作但核心思路是一样的。2.3 发布与迭代层矩阵分发与数据回流视频合成完以后系统会批量推送到抖音、TikTok Shop、快手等平台。常见的做法是维护一个账号池每个账号绑定不同的设备环境和网络参数通过官方开放 API 或自动化工具实现定时发布。这部分工程实现要复杂一些核心是三个模块账号管理模块负责账号授权、Token 刷新、防封策略。任务调度模块负责任务拆分、定时执行、失败重试。数据回传模块采集视频的播放量、互动率、点击率、转化率存储到分析库。从技术角度看这套链路已经把内容生产变成了标准化流水线。但正是这种“标准化”让不合规内容能够以极大规模扩散。一条违规视频被平台删除后系统可以立刻生成 10 条新视频再次上传。如果没有上游的产品合规拦截这种对抗几乎是永动的。3. 案例拆解被召回的产品为什么还能被 AI 大量推3.1 召回机制与电商合规先说明一个基本概念。FDA 召回是指产品因存在安全问题被监管机构要求或建议下架、回收的流程。膳食补充剂类产品虽然不是处方药但同样受到监管如果含有未申报成分、剂量超标或者存在虚假宣传就可能被警告甚至召回。在电商场景中产品一旦被召回理论上应该同时从商品库、内容库中移除。这里的“库”不只是运营手里的 Excel 表格还包括 AI 系统里的产品数据库、历史内容素材库、自动化发布计划。很多团队在做召回处理时只通知运营人员却忽略了 AI 系统还在按旧数据批量生成内容这就是漏洞所在。3.2 合规断层出现在哪几个环节结合前面拆解的技术链路这个案例中的合规断层非常清晰第一个断层产品入库阶段。系统对接产品数据时没有设置“产品合规状态”字段也没有定时同步监管机构发布的召回清单。一个曾经合法销售的产品被召回后数据库里仍然显示“正常在售”系统自然继续为它生成内容。第二个断层脚本生成阶段。LLM 生成脚本时产品信息已经被标记为正常生成的结果自然围绕“功效”“优惠”“立即购买”展开完全没有风险提示。即使提示词里写了禁止医疗功效承诺模型的输出也未必稳定。第三个断层发布审核阶段。平台侧审核通常有滞后性AI 批量发布的内容又数量巨大人工审核很难覆盖全量。系统没有自己的预发布审核模块等于把“是否安全”完全交给平台去兜底这是非常危险的。3.3 核心原因缺少产品视角的合规状态机把上面几个断层压缩成一句话系统缺少一张“产品合规状态机”。产品合规状态机应该至少包含这些状态状态含义是否允许 AI 生成内容PENDING待审核否APPROVED审核通过是REJECTED资质不符否RECALLED被召回否SUSPENDED临时停售否EXPIRED资质过期否产品合规状态机是 AI 营销系统里的“红绿灯”如果没有它车辆就会闯红灯。这个案例中被 FDA 召回的产品之所以还能继续被推销就是因为它的状态停留在 APPROVED没有自动切换到 RECALLED。4. 如何构建一套带合规审查的 AI 营销内容系统既然问题清楚了我们就能给出正向的工程方案。下面逐步演示如何把合规审查内建到 AI 营销内容系统中。4.1 系统总体架构推荐采用“漏斗式”架构在每一个内容生产环节前都设置检查点产品库 ↓ 产品合规检查召回清单、资质、状态机 合规产品池 ↓ 脚本生成LLM ↓ 文案合规检查违禁词、医疗功效、资质声明 脚本审核结果 ↓ 视频合成TTS 数字人 FFmpeg ↓ 合成结果预览 审核日志 发布审批 ↓ 平台发布 ↓ 数据回流 投诉监测 下架监控这样设计的好处是问题内容越早被拦截后续浪费的合成、发布成本越低。最理想的情况是产品在进入内容生成池之前就已经被过滤掉。4.2 产品合规过滤模块首先做一个产品合规检查器。它的职责非常简单在输入产品信息时同步查询本地的召回清单、黑名单、资质过期表如果命中任何一个禁止条件就拒绝这个产品进入内容生成流程。# 示例代码产品合规检查器 # 文件路径compliance/product_checker.py from datetime import datetime from typing import Optional class ProductComplianceChecker: 产品合规检查器 负责检查产品是否在召回清单、黑名单中以及资质是否有效。 def __init__(self, recall_listNone, blacklistNone): # 召回清单set of product_id self.recall_list set(recall_list or []) # 品牌/店铺黑名单 self.blacklist set(blacklist or []) def check(self, product: dict) - dict: 检查单个产品 - product[product_id]: 产品 ID - product[brand]: 品牌名 - product[license_expire_date]: 资质到期时间 product_id product[product_id] brand product[brand] expire_date product.get(license_expire_date) if product_id in self.recall_list: return {passed: False, reason: 产品已被召回} if brand in self.blacklist: return {passed: False, reason: 品牌在黑名单中} if expire_date: expire_dt datetime.fromisoformat(expire_date) if expire_dt datetime.now(): return {passed: False, reason: 产品资质已过期} return {passed: True, reason: ok} # 使用示例 checker ProductComplianceChecker( recall_list{P001, P002}, blacklist{某违规品牌}, ) product { product_id: P003, brand: 正常品牌, license_expire_date: 2026-12-31, } result checker.check(product) print(result) # 输出{passed: True, reason: ok}在实际项目中召回清单和黑名单不应该手工维护而是通过定时任务从监管机构公开接口、平台公告、内部审核系统同步。更新频率至少一天一次高风险品类可以做到每小时一次。# 示例代码定时同步召回清单伪代码逻辑 # 文件路径jobs/sync_recall_list.py import requests import logging logger logging.getLogger(__name__) def sync_recall_list_from_fda(): 从监管公开接口同步召回清单。 不同国家和地区的接口格式不同这里只演示流程。 url https://api.example-fda.gov/recalls try: resp requests.get(url, timeout10) resp.raise_for_status() data resp.json() recall_ids {item[product_id] for item in data[results]} return recall_ids except Exception as exc: logger.exception(同步召回清单失败: %s, exc) # 同步失败时宁可返回上次数据也不要把清单清空 return None这里有一个特别重要的工程细节同步失败时不要返回空列表否则会把召回清单“冲掉”。更稳妥的做法是继续沿用上一次成功同步的数据并触发告警。4.3 文案合规检查模块产品通过检查后进入脚本生成环节。脚本生成后不能直接合成视频需要先经过文案合规检查。文案合规检查可以分为两层规则层和模型层。规则层适合处理确定性比较强的内容比如广告法违禁词、绝对化用语、医疗功效断言。模型层适合处理语义层面的问题比如“虽然没有明确说治病但整个文案隐含了治疗功效”。# 示例代码文案合规检查 # 文件路径compliance/text_checker.py import re from typing import List # 常见广告法违禁词示例 FORBIDDEN_WORDS [ 最好, 第一, 顶级, 极致, 根治, 包治, 绝对有效, 立刻见效, 永不复发, 替代药物, ] # 医疗功效断言模式 MEDICAL_CLAIM_PATTERNS [ re.compile(r治疗(.*?)疾病), re.compile(r修复(.*?)细胞), re.compile(r抗癌|抗肿瘤|降血糖|降血压), ] class TextComplianceChecker: def __init__(self, use_llm: bool False): self.use_llm use_llm def check(self, text: str) - dict: hits [] # 第一层规则匹配 for word in FORBIDDEN_WORDS: if word in text: hits.append({type: 违规词, matched: word, level: block}) for pattern in MEDICAL_CLAIM_PATTERNS: matched pattern.findall(text) if matched: hits.append({type: 医疗功效断言, matched: matched, level: block}) passed len(hits) 0 return {passed: passed, hits: hits} checker TextComplianceChecker() result checker.check(这款保健品是最好的能彻底根治失眠立刻见效) print(result[passed]) # False for hit in result[hits]: print(hit)规则层有一个明显局限只靠关键词无法覆盖语义变体。比如把“治疗疾病”换成“让你告别困扰”规则层基本抓不到。因此在实际系统中还需要用 LLM 做一层语义审查。# 示例代码使用 LLM 做文案语义审查 # 文件路径compliance/text_judge.py from openai import OpenAI client OpenAI( api_keyyour-api-key, base_urlyour-base-url, ) JUDGE_PROMPT 你是一名内容安全审核员。请判断下面的带货文案是否存在以下问题 1. 存在疾病治疗、治愈、替代药物等医疗功效断言 2. 使用了绝对化用语 3. 内容与产品实际资质不符 4. 存在欺骗、误导消费者的表述。 文案内容 {text} 请直接输出 JSON格式如下 {{passed: true或false, reasons: [原因1, 原因2]}} def llm_judge(text: str) - dict: prompt JUDGE_PROMPT.format(texttext) response client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: prompt}], response_format{type: json_object}, ) return response.choices[0].message.content在工程落地时不建议把 LLM 判断结果作为唯一依据更合理的策略是规则层命中直接拦截不再调用 LLM。规则层通过调用 LLM 做语义审查。规则层和 LLM 都通过才允许进入视频合成。任一环节不确定时默认进入人工审核队列。人工复核示例表格文案规则层结果LLM 语义审查最终结论这款产品可以改善睡眠质量通过存疑转人工这款产品彻底治愈失眠拦截-拒绝每天一粒状态在线通过通过通过4.4 人机协同审核与审计日志自动化检查再完善也不能完全替代人工审核尤其是在高客单价、保健食品、医疗健康等高风险品类上。合理的做法是自动检查负责拦截确定性问题人工审核负责处理语义模糊和规则边界的情况。同时所有审核动作都必须写入审计日志。日志字段建议包含内容 ID产品 ID生成时间审核模型及版本规则命中详情人工审核人最终审核结论发布平台及状态审计日志不仅用于追责更重要的是用于持续优化规则库。例如如果发现某个新表述反复绕过审查就可以把这个表述加入新的规则模板。4.5 发布后的监控与反馈闭环内容发布不代表流程结束。在 AI 内容工厂的场景里必须建立发布后的监控体系重点关注四类数据平台下架率如果内容频繁被平台判违规下架说明上游合规策略失效。用户投诉量投诉率突然上升往往是产品体验或内容夸大的信号。退货率保健品类目退货率异常可能说明产品功效严重不符。舆情反馈评论区和社交平台上的负面讨论需要用 NLP 情感分析定期抓取。建议把监控结果回写产品合规状态机。例如某产品发布内容后 7 天内平台下架率达到 20%系统应自动将该产品状态切换为 SUSPENDED停止后续内容生成。# 示例代码根据下架率自动调整产品状态 # 文件路径jobs/auto_suspend_product.py def auto_suspend_product_by_takedown_rate(product_id: str, takedown_rate: float, threshold: float 0.2): if takedown_rate threshold: # 更新产品状态为临时停售 update_product_status(product_id, SUSPENDED) # 停止所有与该产品相关的待执行内容任务 cancel_pending_tasks(product_id) # 触发告警通知运营人员 send_alert(f产品 {product_id} 下架率过高已自动停售)这部分代码比较简单但思想很重要AI 营销系统不能只负责“跑得快”还要负责“刹得住”。5. 常见问题与排查思路在开发 AI 营销内容系统时以下几个问题是最常见的。问题现象常见原因解决思路AI 生成的带货文案总是夸大功效提示词缺少合规约束生成后没有检测层在提示词中加入合规规则增加规则层和 LLM 审查层被召回产品仍在生成内容产品数据库状态未同步建立产品合规状态机定时同步召回清单生成前强制检查视频发布后频繁被平台下架内容违反平台广告规则建立平台规则知识库对历史下架内容做归因分析合规模块影响整体生成速度每个环节都串行调用模型合规过滤前置规则层和模型层并行对通过检查的内容做缓存人工审核队列堆积严重自动化过滤阈值过严或过松调整规则阈值优化 LLM 判断 prompt增加审核人员分配策略召回清单同步失败导致误放行同步接口异常时返回了空数据同步失败时保留上一次有效数据增加失败告警6. 最佳实践与工程建议6.1 合规即功能而不是事后补救很多团队会把“合规”理解为上线前的一次人工审核或者运营自己把握一下尺度。但在 AI 内容工厂这种大规模自动化生产场景下合规必须被设计成系统能力嵌入到产品流转链路的每一步。具体做法产品入库时强制校验产品资质和合规状态。脚本生成时使用提示词约束与生成后检测相结合。视频渲染前对最终文本再做一次完整扫描。发布前记录审核日志和责任人。发布后建立下架率、投诉率监控。6.2 建立标准化的风险漏斗从产品进入系统到内容发布每一层都对应一个风险漏斗。建议按下面顺序设计检查点产品层查询召回清单、资质状态、品牌黑名单。文案层违禁词、绝对化用语、医疗功效断言。素材层图片和视频素材是否有授权、是否有违规标识。发布层是否符合不同平台的广告政策。售后层投诉、退货、下架数据的实时监测。只有前面四层全部通过内容才应该被发布。第五层用于反向修正前四层的规则。6.3 用“AI 对抗 AI”的工程思路在内容安全领域生成端 AI 和检测端 AI 可以形成对抗关系。生成端负责产出效率检测端负责安全兜底。检测端模型需要定期用已知违规样本重新微调并基于最新平台规则更新判据。同样规则库也不应该是一份静态的 Excel。建议把每一次被拦截的内容、被平台下架的内容、被用户投诉的内容都作为正负样本回流到规则库优化流程中。6.4 安全边界与最小权限原则AI 营销系统通常需要接入电商平台 API、内容平台 API、数据库和存储服务。权限设计上要注意发布账号与内容审核权限分离避免一个人既上传内容又直接发布。高风险操作如批量解禁产品、删除违规记录需要二次审批。所有自动化任务都应有操作日志和回滚机制。对外调用模型服务时不要在日志中记录完整 prompt尤其是包含用户敏感信息时。这些原则不是为了降低开发效率而是为了保证当系统出现误判或被攻击时损失的边界是可控的。7. 写在最后回到开头那个案例。AI TikTok Shop 带货内容工厂之所以会成为问题不是因为 AI 生成视频这个技术方向错了而是因为它把“生产效率”放到了“合规安全”之前系统里没有任何产品合规状态机没有召回清单同步没有文案审查层没有人工复核环节。技术本身不会评判对错但工程系统必须设置边界。如果你正在开发 AI 营销视频一键成片系统或者任何形式的 AIGC 内容生产工具建议把合规审查当成核心模块来设计而不是上线前补一个按钮。具体可以做的事情有三个第一为产品建立合规状态机和召回清单同步第二在内容生成链路中嵌入双层文案审查第三用发布后的投诉和下架数据反向优化规则。AI 时代内容生产的边际成本确实趋近于零但责任的边际成本不会消失。系统的每一条自动生成内容最终都应该能回答一个问题谁在产品层面为这条内容负责又拿什么数据证明它是安全的把这个问题想清楚AI 营销系统才真正具备走向生产环境的条件。