lhg-ve-audit:口播成片自检流程
目标:把"自我检查"变成固定流程,而不是凭感觉看一遍。 核心纪律:先跑脚本(机器),再做评审(人);blocker 不清零,不许说做完了。
1. 何时使用
- 成片渲染完成后、发布前 → 跑全流程
- 只想快速看一眼 → 只跑第 2 步(脚本),5 秒出结果
- 收到用户反馈"这条数据不好" → 用第 5 节清单复盘,定位是钩子/节奏/合规哪环的问题
2. 第一步:跑确定性审计脚本(必做,零 LLM 成本)
在交付目录执行插件自带的审计脚本(用你所在平台执行本地脚本的方式):
python3 <插件目录>/scripts/audit/video_audit.py --target <交付目录>
交付目录里应有:字幕文件(.srt/.ass/.vtt)、edl.json、封面图(cover.png/jpg)、meta.json(时长/响度/音乐来源等)。
- 脚本输出 JSON(含每条发现的文件、行号、规则说明)与人类可读报告,共 31 条规则。
- 有 blocker 时脚本以非零 exit code 退出——这是设计,不是 bug。
--fail-on控制 exit code 语义:默认blocker;想要更严的门禁可设为warning。- 脚本只做"机器可判定"的事:错别字、时间轴重叠、封面尺寸、响度参数、违禁词。它判定不了"钩子够不够狠",那是第 5 步的事。
2.5 meta.json 规范
审计脚本从 meta.json 读成片元数据,字段缺失会导致对应规则跳过(不是"通过",是"没查"——两回事):
{
"title": "三个让完播率翻倍的剪辑技巧",
"duration_sec": 58,
"target_sec": 60,
"loudnorm": {"I": -14, "TP": -1.5, "LRA": 11},
"channels": 2,
"music_source": "平台免费曲库(剪映)"
}
duration_sec/target_sec:成片实际时长与目标时长(DUR-* 规则用)loudnorm:响度归一参数,短视频平台标准I=-14, TP=-1.5, LRA=11(AUD-* 规则用)music_source:BGM 来源三选一:自制 / 已购版权 / 平台免费曲库(CPL-MUSIC-001 用)title:发布标题,同样过极限词检查(CPL-TITLE-001)
建议渲染流水线最后一步自动生成 meta.json,不要手写——手写的元数据与成片对不上的事故见得太多了。
规则覆盖六类:
| 类别 | 规则数 | 查什么 |
|---|---|---|
| 字幕 SUB-* | 8 | 错别字、时间格式/重叠、单行超长、停留过短、空条目、编码 |
| EDL EDL-* | 8 | JSON 合法、片段重叠/零时长/超界、切点淡变、残留口头禅/大静音 |
| 时长 DUR-* | 2 | 与目标时长偏差、过短 |
| 封面 COV-* | 5 | 缺失、尺寸、长宽比、文件过大 |
| 音频 AUD-* | 4 | 响度归一参数、目标 -14 LUFS、峰值、声道 |
| 合规 CPL-* | 4 | 极限词/违禁词、投资话术、版权音乐来源声明 |
3. 第二步:分级
| 级别 | 定义 | 处理 |
|---|---|---|
| blocker | 发布后会出事:时间轴重叠、违禁词、封面尺寸错、响度未归一 | 必须修,不修不许发布 |
| warning | 大概率是坑:单行字幕超长、切点无淡变、残留口头禅、音乐来源不明 | 本次修掉;修不掉写理由进报告 |
| nit | 洁癖项:字幕序号不连续、封面文件略大 | 顺手修 |
分级是死的,判断是活的:如果某条 warning 在你的题材里就是会出事(如金融题材的"稳赚"话术),把它升成 blocker,并在报告里写清理由。
4. 第三步:修复 blocker
- blocker 逐条修,修一条跑一遍脚本确认消失。
- 修复顺序:合规类先修(违禁词、投资话术——这些是"正在流血"的)→ 结构类(时间轴重叠、EDL 非法)→ 体验类(响度、封面尺寸)。
- 修不掉的 blocker(如需用户重录口播):列进报告的"需人工处理"区,不许为了清零而删规则或改脚本阈值。
- 违禁词类 blocker 靠"换词"修:把极限词换成合规说法("最牛"→"很能打"),不许靠删规则修。
5. 第四步:人工评审(脚本覆盖不到的)
完播率视角清单
- 前 3 秒:钩子是否成立?画面第一帧有信息量吗?(拿掉声音看一遍也成立才算过)
- 节奏:60 秒里有没有超过 8 秒无变化的段落?(有 → 观众在这里划走)
- 字幕可读性:手机端抽查 3 处,字号/描边/位置,有没有被平台 UI 遮挡
- 音画同步:切点处听 3 处,有无爆音;字幕与口型误差 >0.3 秒吗
- 封面点击欲:把封面缩到拇指大小,标题还看得清吗?想点开吗
- 结尾:CTA 是否具体?("记得关注"是废话,"点主页看工具清单"才算)
合规视角清单
- 题材踩线检查:金融/医疗/教育题材是否有必要的风险提示?("投资有风险"不是摆设)
- 极限词:标题、封面、口播三处都要查,不只是字幕文件
- 音乐:BGM 来源是否明确?(自制/已购版权/平台免费曲库三选一,"网上下的"不算来源)
- 肖像与素材:出镜人、空镜素材是否有授权?(用自己的脸也要确认)
评审输出
每项写"通过 / 不通过(原因)",不通过的进待办,不许写"大概没问题"。
6. 第五步:输出报告
报告模板:
# 自查报告:<成片名>(日期)
## 结论:通过 / 不通过
## blocker(n):已修 n,剩余 n
- [规则ID] 文件:行 —— 说明 —— 状态(已修/需人工)
## warning(n):已修 n,豁免 n(理由)
## nit(n)
## 人工评审:完播率 x/y 通过,合规 x/y 通过
## 需人工处理
- ...
报告建议存进项目(如 docs/audit-YYYYMMDD.md),下次复盘时对照。
7. 豁免规则
- 豁免只针对 warning/nit,blocker 不许豁免。
- 豁免必须写理由 + 有效期(如"这期赶热点,先发,封面下期补"),到期复查。
- 豁免清单进报告,藏着不写等于没豁免。
8. 反模式
- ❌ 只跑脚本不做人工评审——脚本抓不到"钩子很烂"这种问题
- ❌ 为了清零改脚本规则——这是作弊,不是自查
- ❌ 违禁词靠删规则"修掉"——平台罚的是你,不是脚本
- ❌ "先发了再说,数据不好再改"——首发流量只有一次
- ❌ 自查报告只写"通过"两个字——没有过程的结论不可信
9. 误报处理
规则是启发式,一定会误伤。误报不可怕,乱处理才可怕:
- 判断三问:这段字幕真的有问题吗?这条规则的本意是什么?按规则改了会不会破坏原意?
- 确认误报:记入报告的豁免清单并写清原因(如"‘第一’指‘第一次尝试’,非极限词 —— 豁免 CPL-WORD-001")。
- 拿不准:按 warning 处理,不要直接忽略。
- 规则本身有问题:附最小复现字幕提 issue(见第 10 节),不要自己改脚本阈值。
10. 自检与反馈
每次执行完本 skill,做一次轻量自检:
- 脚本是否真的跑了(而不是"我看了一遍觉得没问题")?→ 没跑不算做。
- blocker 是否清零或全部列入"需人工处理"?→ 有遗漏就补。
- 人工评审清单是否逐项打勾?→ 打勾要有依据(截图/时间点)。
标准冒烟用例:对插件自带的 fixtures/ 跑脚本,确认坏 fixture 的 blocker 全命中、好 fixture 零 blocker(见仓库根 smoke_test.py)。
反馈渠道:以 [QC] <一句话问题> 为标题提交到 https://github.com/lhg-plugs/lhg-video-edit/issues,正文写清"输入 → 错误输出 → 期望输出"。规则误报/漏报请附最小复现字幕。
出品:刘洪光
本 skill 由真人出镜 IP「刘洪光」(安徽合肥)出品,归属 lhg-skills。
- GitHub 主页:https://github.com/lhg-skills —— 全部 skill 开源在此,欢迎 star
- 视频号:搜「刘洪光实名上网」
- 微信:lhgsmsw