self-media-compliance-review

self-media-compliance-review

自媒体视频发布前的违规风险审核 Skill。

适用于 Claude Code / Codex / OpenClaw / Hermes 等支持 Skills 的 agent。把它装进 agent 后，可以在短视频、切片、封面、标题、字幕、口播、商品链接和发布文案交付前，按本仓库整理的参考规则做一遍结构化风险审核。

它不是“敏感词表”，而是一套面向发布前质检的审核流程：会检查画面、声音、文字、封面、评论引导、带货信息、资质、授权、引流和平台常见风险，并给出具体修改建议。

也欢迎大家在 Issues 里提供各平台规则资料、审核经验、踩坑案例和整改思路。后续会不定期整理进这个 skill。

---

能做什么

• 按平台读取参考文件：根据目标平台读取视频号、微信公众号、抖音、快手、B站、小红书的规则参考。
• 电商合规审核：商品三一致检查（视频 vs 详情页 vs 口播）、千川低质素材避坑、功效声明核验、行业资质排查、价格/赠品/活动一致性。
• 覆盖常见发布面：检查脚本、封面、标题、字幕、口播、画面、BGM、评论、商品链接和账号资料。
• 本地视频证据分析：自动提取首 0–5 秒、场景切换、周期帧、结尾帧、音轨、字幕和技术信号，生成可追溯的视频审核证据包。
• 风险分级：输出 Pass / Low / Medium / High / Blocker。
• 证据定位：要求标注视频时间点、字幕行、封面文案、商品链接或待核验证据。
• 修改建议：给出消音、打码、删改、补资质、补授权、改写话术、移除链接等具体动作。
• 案例排查参考：对限流、封号、申诉、原创争议、评论灰产等场景给出排查方向和申诉材料清单。
• 本地证据检索：默认可用，只搜索随 Skill 发布的规则和案例文件，不联网、不消耗 API 额度，并返回可追溯的文件和行号。
• 实时平台证据（可选）：仅在用户明确要求实时搜索时，通过当前环境已有的平台浏览插件/Skill、浏览器工具、TikHub 直连 REST API 或 MediaCrawler 本机浏览器路线检索近期案例和讨论；TikHub 不走 MCP，MediaCrawler 免费、用用户自己的账号登录。
• 视频证据防幻觉：分开记录分享文案、平台元数据、实际媒体、OCR/ASR 和多模态模型输出；来源不一致时只报告异常与待核验原因，不武断归因。
• 隐形规则补充：除官方规则外，整理了各平台创作者实际发布和评论区讨论中的经验样本，用来补充官方没写明的隐形审核尺度（作为症状和争议线索，不当作平台规则）。
• 机器可读输出：支持 JSON 格式输出，可接入胶囊影院、选品助手和飞书审批流程。
• 稳定的数据契约：视频证据、商品一致性和最终审核报告均提供带版本号的 JSON Schema。
• 可扩展规则文件：新增平台时，可以按相同结构补充参考文件。

适合哪些场景

已覆盖平台与电商专项

规则来源汇总见：docs/sources.md。跨平台案例索引见：recent-cases-2025-2026.md。

安装

把下面这段话发给你的 AI 助手即可：

帮我安装 self-media-compliance-review： https://github.com/JuneYaooo/self-media-compliance-review

安装方式取决于你正在使用的 agent。安装完成后，让它告诉你如何调用，以及是否需要重启或刷新当前 session。

更新仓库后，应重新执行同一种安装流程来刷新已安装副本。很多 agent 会在 session 启动时缓存 Skill 指令，所以更新完成后通常需要新开一次 session。

怎么用

直接用自然语言调用：

使用 self-media-compliance-review，审核这个视频的标题、封面、字幕、口播、商品链接和发布文案，目标平台是抖音和小红书。

分析本地视频文件：

使用 self-media-compliance-review，分析这个本地视频是否可能违规，目标平台是抖音。先提取视频帧、音轨和字幕证据，再给出带时间点的风险结论；如果声音或画面没有审完，不要判定 Pass。

或在视频交付前：

交付前跑一遍 self-media-compliance-review，平台是视频号、B站。

排查账号状态或申诉问题：

使用 self-media-compliance-review，帮我排查小红书笔记小眼睛为 0 的可能原因，并按案例库给出申诉前要准备的证据。

参考既往案例和创作者讨论：

使用 self-media-compliance-review，结合案例库里抖音"带货话术被判违规"的既往经验和评论讨论，帮我看看这条口播会不会踩隐形规则。

电商场景的几种入口：

使用 self-media-compliance-review，审核这个带货视频的商品一致性、千川低质素材和功效声明，目标平台是抖音电商。

使用 self-media-compliance-review，帮我看看这个品能不能带，有哪些资质要求和风险点。

使用 self-media-compliance-review，写文案前帮我扫一遍这个商品的详情页，标出禁用词和需要补证据的卖点。

本地视频分析

仓库提供 tools/analyze_video.py，用于把本地视频整理成 agent 可以逐项审核的证据包。它依赖 ffmpeg 和 ffprobe，默认完全在本机运行，不调用 TikHub，也不会搜索平台内容。

证据包包含目标平台、视频元数据和 SHA-256、首 0–5 秒帧、场景切换帧、周期帧、结尾帧、contact sheet、音轨、嵌入/同名字幕、用户单独提供的口播稿或字幕、黑屏和静音区间，以及文本中的功效、绝对化、价格、数据、竞品比较和监管话题预筛信号。所有帧都带时间点，方便在最终报告中引用。

Whisper 转写是可选能力，不是默认依赖。只有明确启用转写并且本机安装了 Whisper 时才会运行；模型可能需要下载，因此 agent 应先说明。没有转写、口播稿或音频审核能力时，报告必须把声音标为“待核验”，不能因为抽样画面正常就判断视频通过。

脚本不会自动给视频定性。它输出的黑屏、静音和文本命中只是预筛；agent 仍需检查 contact sheet 和疑似时间点原帧，结合目标平台规则判断 Pass/Low/Medium/High/Blocker。抽帧可能漏掉极短画面，高风险、快切、长视频以及医疗、金融、未成年人等内容应提高采样密度或检查完整时间线。

商品对比和文案扫描也是预筛：它们可以精确比较结构化价格、SKU、赠品和活动字段，或定位可疑声明，但不会自动打开详情页、验证资质、理解全部画面，也不会代替人工给最终结论。所有自动命中都要回到原始证据复核。

抽帧证据不能被描述成“人工逐一看完每一帧”。需要 Gemini 或其他视频多模态模型时，必须提交经过 ffprobe 和哈希验证的实际视频文件，保存成功的原始结构化响应，再用原帧、可见字幕和可确认音频交叉核验时间码。模型调用失败时返回的默认结果不构成证据。完整规则见 video-evidence-integrity.md。

默认：本地证据检索

普通审核可以自动搜索仓库随 Skill 发布的 references/**/*.md 和 docs/sources.md，不需要 TikHub、浏览器、登录状态或额外授权，也不会产生网络请求。适合从多个平台规则和案例文件中查找与“导流、限流、封号、搬运、功效、申诉”等症状相关的段落。

本地检索结果会保留文件路径、行号、章节标题和来源类型，便于复核。它只代表当前仓库中的静态知识，不能冒充实时平台信息；没有命中也不代表内容合规或平台上不存在相似案例。开发机上的 local/ 历史采集目录不会随 Skill 发布，因此不属于正式检索语料。

可选：用户明确要求时实时检索

实时检索默认关闭。即使当前环境已经配置 TikHub key，或者安装了小红书浏览插件、相关 Skill、agent-browser 等浏览器工具，也不会因此自动联网搜索。普通审核只使用静态规则、案例库和用户提供的材料。

只有当用户明确提出“实时搜一下”“查近期案例”“看看平台当前讨论”等要求时，agent 才检查当前环境是否存在可用通道：

• 用户指定 TikHub、MediaCrawler、opencli 或某个浏览器工具时，只使用用户指定的通道；不可用时说明情况，不静默换源。
• 用户没有指定通道时，按上表档位顺位启用：宿主有 ①computer use / ②浏览器工具（agent-browser 一类真实浏览工具）就直接用，不打扰用户；宿主没有 ①② 时进入“问用户”环节（③ opencli 为第一选项，④ TikHub 花钱需先征得明确同意）；⑤ MediaCrawler 仅当 ①-④ 都不可用时使用。
• 浏览器类通道应遵守登录、访问权限、验证码、频率限制和平台规则，不绕过访问控制；出现反爬信号就停下并在报告中说明。
• 所有实时通道失败时，静态合规审核继续进行；不能把“搜索失败”写成“没有相似案例”。

仓库自带的 tools/xhs_dynamic_evidence.py 是 TikHub 的一个可选小红书适配器，tools/tikhub/bin/tikhub 则可调用已缓存目录中的抖音和小红书 REST 端点。它们只请求 TikHub 官方 https://api.tikhub.io/api/v1/...（中国大陆可显式配置 .dev 基础域名），使用 Bearer API key，禁止请求 mcp.tikhub.io 或任何 TikHub MCP 工具。调用可能产生 TikHub 费用或消耗账号额度，因此不会作为默认审核步骤。

调用前在进程环境或已被 git 忽略的 .env 中设置 TIKHUB_API_KEY；中国大陆网络可按需设置 TIKHUB_API_BASE_URL=https://api.tikhub.dev。不要把任何密钥写入命令输出、报告、测试夹具或提交记录。

TikHub 返回的原始响应、媒体、签名 URL、日志和报告必须放在 .gitignore 已覆盖的本地目录。仓库只提交通用代码、OpenAPI 端点目录、测试、Skill 指令和静态知识，不提交 API key、Cookie、认证令牌、账号安全标识或付费查询结果。

实时检索通道：档位与启用条件

需要实时平台证据时，agent 按以下档位顺位启用（用户点名了某个通道则只用它，不静默换源）：

MediaCrawler（免费兜底，最后手段）

以上通道都不可用、且用户接受风险时，才用 MediaCrawler 走本机浏览器路线：python tools/mediacrawler_search.py --setup 一条命令自动完成安装（克隆到被 git 忽略的 vendor/、建独立虚拟环境、装 chromium、自动补丁配置；pip/Chromium/GitHub 下载源自动择优镜像，慢网下明显更快），首次搜索时用自己的账号扫码登录一次（登录态长期复用），之后即可免费做关键词搜索取证，例如 python tools/mediacrawler_search.py --platform xiaohongshu --keywords "小红书 限流 申诉" --max-notes 20（可先 --dry-run 预览、--status 检查安装与登录态）。

支持小红书、抖音、快手、B站、微博、贴吧、知乎（视频号不支持，走 TikHub），输出归一化的 records.json 与 digest.md（默认写入被 git 忽略的 local/mc_output/），记录结构与 TikHub 路线的采集记录对齐；账号保