前段時間看到一篇關于 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 營銷系統才真正具備走向生產環境的條件。