digital-human-video

name	digital-human-video
description	用抖音系服务(火山引擎·即梦AI)制作竖版短视频,两条路线:数字人口播(OmniHuman,对口型)与氛围画面配旁白(视频生成3.0 Pro,不对口型),动手前先选。先问清场景(给谁看/看完得到什么/要他做什么/片子类型),再定选题;输入=一段文本(主题或原始素材)+目标时长+人像或场景图;文案、生成的图片、分镜与成本表三处均须用户确认(成本确认可被用户常驻豁免),确认后才调计费 API 制作(TTS→数字人或视频生成→ffmpeg 竖版合成,含 AI 标识)。当用户要"做数字人视频/口播视频/宣传视频/AI 生成视频"时使用。首次使用前须先跑 digital-human-video-init 配置密钥。

数字人口播视频 · 制作

⓪ 先问场景(硬门,不问清不动手)

2026-08-02 教训:跳过这一步做出来的片子「非常没有意思」。 当时用户给了一份现成的数据稿, 技能直接照做,产出一条讲「我们跑了 45 道题、某引擎提了我们 22 次」的片子——数据全对、合规全过、 观众毫无理由看完。根因是拿内容源当需求用:有人给一段文本,不等于这段文本适合做成这条片子。

动手前必须问到下面四件,缺哪件问哪件,不许替用户假设:

1. 给谁看——目标观众是谁、他们此刻的处境是什么。写「中小企业市场负责人,老板问他品牌在 AI 里 排第几,他答不上来」这种具体的人,不写「潜在客户」。
2. 看完得到什么——观众能带走的一件事:学会一个判断方法 / 看懂一个现象 / 避开一个坑。 如果答不出观众能带走什么,这条片子不该做。
3. 要他做什么(转化目标)——看完去哪、怎么承接(关注公众号 / 私信关键词 / 官网 / 什么都不做只求曝光)。
4. 片子类型——干货科普 / 现象观察 / 案例拆解 / 观点表达 / 产品演示。

这四问是给一个账号/一个系列定调的,定过一次就不必每条重问;后续每条片子只按下面「输入」那两样收料即可。

引流片 ≠ 推广片(最常见的一次性搞砸)

	引流片	推广片
主角	观众的问题	我们的产品
数据的用法	当论据支撑一个观众关心的判断	当成绩陈列
观众的收获	学到能自己用的东西	知道了有这么个产品
适用场景	冷启动、涨粉、公域引流	已有信任的私域、落地页、发布会

默认按引流片写。 用户明确说「做产品介绍/发布」才写推广片。 自查一句:把品牌名全部抹掉,这条片子还有人看吗? 没有 → 是推广片,回炉。

输入(每条片子固定收两样,缺一不做)

① 文案

口播全文,或要点(由本技能改写成口播稿)。时长由文案长度决定:每 13 秒 ≈ 65 汉字。

⚠️ 文案完整性优先于时长——不得为了凑短而删内容(2026-08-03 用户明确要求)。 15 秒是 OmniHuman 单次调用的上限,不是成片的上限:超了就按语义拆成多段、逐段生成、 拼接成一条完整片子。硬压文案会把信息压没——把「五种角色各自是干什么的」压成五个光秃秃的 名词,观众记不住也听不懂,等于白做。

⚠️ 文案是素材不是需求:若 ⓪ 尚未定过调,先问完再动笔。常见情形是用户手边只有一份 内部数据稿,而它并不适合直接做片子——此时据 ⓪ 另提选题给用户选,不要照着硬做。

② 一张图

这张图同时决定成片里的「人」和「背景」——OmniHuman 只接收图 + 音频,没有任何场景 提示词参数(2026-08 核实)。所以图什么样,成片就什么样。

要求:单人、正脸、人脸占比大,JPG/PNG <5MB <4096²(sips -g pixelWidth -g pixelHeight 核验); 竖版 9:16 最省事(横图会按原比例出片,与竖版成片不匹配)。 肖像须已获本人授权(或为 AI 合成形象);用户主动提供并指示用于本片,即视为授权,如实记档, 不必反复追问。

这张图从哪来(按优先级):

来源	何时用	注意
实拍照片	车里、办公室、家里这类随手能拍的场景	首选。真脸真光真环境,零 AI 味、零肖像争议;五分钟拍三五张够用很久
用户自备的生成图	用户自己做好了图	直接用,不必追问怎么来的
gen_scene.py 图生图	拍不到、又要人物在场景里	见下方「进阶」的实测结论
gen_scene.py 文生图 + make_portrait.sh 合成	拍不到的场景,且必须保住真脸	脸 100% 不动,代价是可能有贴纸感

前置:配置文件 ~/.config/zmh-dhv/env 存在(所有脚本自动读取);不存在则引导用户先跑 digital-human-video-init。

进阶:自己做输入图(拍不到的场景才用)

两个脚本,都在 scripts/:

# 文生图:生成纯场景空镜(不含人物)
python3 scripts/gen_scene.py --prompt "汽车驾驶座,暖色车内,窗外街景虚化" --out scene.png
# 图生图:带入参考图里的人物
python3 scripts/gen_scene.py --image <人像公网URL> --prompt "同一个人坐在驾驶座上" --strength 0.45 --out shot.png
# 绿幕/透明底人像 + 场景 → 合成输入图(脸 100% 不动)
scripts/make_portrait.sh green <绿幕人像> scene.png out.png [相似度] [羽化]
scripts/make_portrait.sh check out.png          # 人景协调自检(色温/画幅)

2026-08-02 实测结论,别重复踩:

• 提示词里不要写「留出人物站位」这类话——模型会照办,直接画一个灰色人形占位块。 空镜就老实写「空镜,画面中没有人」。
• 图生图 strength=0.45 时人脸已被换掉:发色改变、脸型削瘦、五官磨皮成通用 AI 脸, 另有手部结构错误与过曝高光。用户一眼判「很假」。降到 0.25~0.3 能多保住脸,但融合变差, 容易变成「证件照硬贴进场景」的另一种假。
• 因此:本人出镜的片子优先实拍。生成图的用武之地是拍不到的场景(演播室、机房、 发布会背景板),以及封面配图这类不涉及本人真实呈现的素材。
• 若仍要用生成图做本人出镜:必须把图交给本人确认「这还是我」,不确认不进 OmniHuman。

两条产出路线(动手前先选,选错整条片子废)

技能有两个互不相通的引擎,区别只有一条,但它决定整条片子的形态:

	数字人 OmniHuman	视频生成 3.0 Pro
脚本	jimeng_dh.py	jimeng_video.py
req_key	jimeng_realman_avatar_picture_omni_v15	jimeng_ti2v_v30_pro
接口	CVSubmitTask / CVGetResult	CVSync2AsyncSubmitTask / CVSync2AsyncGetResult
对不对口型	对	不对
片子形态	真人口播(人在说话)	氛围画面配画外音
输入图要求	正面、匀光、简背景、嘴部无遮挡(极严)	宽松,侧脸暗调都能出
输出画幅	不固定:见过 480P 小画幅,也见过 1088x1920 整幅	1088x1920(注意不是 1080)
单段长度	跟音频走	frames 121≈5s / 241≈10s
segments.txt 类型	dh	clip

别搞混:拿 jimeng_video.py 做口播,会得到「人在动、嘴不动、声音在念」的诡异片子。 要嘴型对得上只有 OmniHuman 一条路。

数字人的输出画幅不固定,合成前必须探

同一个 jimeng_realman_avatar_picture_omni_v15,2026-08-02 回的是 480P 小画幅, 2026-08-04 回的是 1088x1920 整幅。compose.sh 的 dh 分支原先写死「缩到画面上部、 下方留字幕区」,拿整幅素材跑会把画面往下推 200px 再裁掉底部。

现已改为按 ffprobe 探到的实际高度分流(≥1600 视为整幅,走铺满裁切;否则走上部留白)。 教训:输出画幅是服务端的事,不是我们能假设的常量。 任何「XX 一定是 480P」这类 写死的画幅假设,都该换成一次 ffprobe。

数字人段合成时用 - 走 mp4 自带音轨,不要外挂原始 wav:OmniHuman 的输出会比 源音频长 0.04~0.18 秒(收尾帧对齐),外挂 wav 有让口型与声音错位的风险, 自带音轨则严格同源。

视频生成的两条实测纪律

1. 每段都锚回同一张原图,不要拿上一段的末帧接龙(2026-08-04 实测踩到)。 接龙的本意是接成一条连续镜头,实际上 ti2v 每次都是拿首帧重新合成人脸与场景, 误差逐代累积:第 2 代人物转身只剩后脑勺,第 3 代换了张脸,第 4 代连街景都从 红霓虹漂成绿路灯。七段下来是七个人物不一致的镜头,不是一条镜头。 正确做法:每段首帧都用同一张原图,靠 --prompt 里的运镜描述做出差异, 靠 --seed 固定可复现。宁可少切几刀——frames 241(10 秒)出 4 段, 比 frames 121(5 秒)出 7 段剪切点少一半,脸也更稳。
2. 提示词写运镜和动态,不写画面内容。内容已经由首帧图决定了,再描述一遍只会打架。 写「镜头极缓慢推近,人物轻微呼吸与眨眼,背景霓虹光斑流动」, 不写「一个女性站在雨夜街头」。结尾固定加「电影感,人物面容保持一致,画面稳定不变形」。

req_key 备胎(某一个额度用尽时直接顶上)

即梦的视频能力是按 req_key 分别计额度的,一个用尽不影响另一个。实测可互换:

req_key	名义	实测	规格
jimeng_ti2v_v30_pro	3.0 Pro 图文生视频	吃 image_urls	1088x1920,241帧=10.04s
jimeng_t2v_v30_1080p	3.0 1080P 文生视频	同样吃 image_urls	与上完全一致

名字里的 t2v 不代表它不收图(2026-08-04 实测:3.0 Pro 额度耗尽后,同样的 image_urls + frames + aspect_ratio 原样换到 jimeng_t2v_v30_1080p, 两段都一次出成,参数一个字没改)。所以出片脚本应当按 req_key 列表依次退避, 而不是撞到 50400 就停下来问用户充值:

for RK in jimeng_t2v_v30_1080p jimeng_ti2v_v30_pro jimeng_i2v_first_tail_v30; do
  python3 scripts/jimeng_video.py --req-key "$RK" ... && break
done

零成本判断某个 key 还能不能用:拿假 task_id 打 CVSync2AsyncGetResult, 50400 = 该 key 不可用(额度尽或未开通),50500 = 可用(查不到假任务而已), 50200 = 名字不存在。注意这里 50500 反而是好消息,与直觉相反。

已知瞬时错误

• 50220 Download Url Error — 即梦服务端拉不到我们图床上的首帧图(connection reset)。 不是参数错,重试即可,别去改 URL 或重传图片。批量出片时要能单段补跑。
• 50400 Access Denied: api forbidden — 这个码有歧义,别一看到就断定「没开通」。 2026-08-04 实测:同一个 jimeng_ti2v_v30_pro,同一批里第 1、3 段成功、第 2、4 段回 50400。 能力显然是开通的,所以此处的 50400 是限流或额度耗尽,不是权限。 判别法:这个 req_key 在本次会话里成功过吗? 成功过 → 限流/额度,隔开重试,别去动权限和 IAM; 从没成功过 → 才考虑是能力未开通(此时再用别的已开通 key 做对照探针)。

批量出片必须能单段补跑:一批里失败几段是常态(上面两个码都会随机命中), 脚本要按段落文件名判断哪些缺失、只补缺的那几段,不能整批重来——重来等于把 成功的那几段再花一次钱。

流程(严格按序,三道确认门)

① 生成视频脚本(不花钱)

前提:⓪ 四问已答完。 未答完不进本步——照着一段现成文本硬写,产出的必然是「数据都对但没人想看」的片子。

开篇 3 秒决定完播率,写之前先定钩子。可用的三种(都不要以「大家好」「今天跟大家聊聊」开场):

• 反常识:「AI 说错一个产品的价格时,它不会说不知道,它会编一张完整的价目表。」
• 具体处境:「老板问你品牌在豆包里排第几,你答得上来吗?」
• 可验证的动作:「教你十分钟自己查一遍,不用买任何工具。」

首尾两段必须是人脸(2026-08-10 用户定的硬规则)

片子的第一段和最后一段一律用数字人,中间可以用图卡。

理由是两端承担的功能不同,都撑不住静态卡:

• 第一段决定留不留人。留存曲线显示前 7 秒流失 86%,而人脸是短视频里最强的注意力钩子。 开头放一张静态卡等于把最贵的 7 秒交给了最弱的画面。
• 最后一段决定行不行动。CTA 由一个人说出来,和由一张卡片写出来,说服力不是一回事。

顺带解决一个听感问题:同一段 TTS 配「会动的嘴」和配「静态卡」,听起来是不一样的。 2026-08-10 实测——用户反馈第 3 条「语音跟前两条不一样」,而字节级比对证明 TTS 完全相同 (同一句话两次生成 md5 一致)。差异来自两处:① 该片满是英文专有名词,中文 TTS 读英文韵律不同; ② 全片无人脸。视听整合会改变听感,这不是错觉。所以首尾配人脸也是在稳听感。

开场:唯一有实测数据的一条(2026-08-10 首条成片回流)

第一条片子发出后拿到了真实留存曲线,结论比任何经验之谈都硬:

0s 100%  →  7s ≈14%  →  14s ≈10%  →  21s ≈8%  →  28s ≈5%  →  35s ≈0

前 7 秒流失 86%,7 秒之后近似平线。(片长 36.5s,完播率 7.13%,平均播放 10.06s)

三条可直接照用的推论:

1. 一条片子的成败几乎全在前 7 秒。中后段做什么都影响不到大多数人—— 那条片子 9 秒处才切出精心画的框架图,而那时观众只剩 14%,绝大多数人根本没看到。 所以:先把开场做对,再谈结构。
2. 别把需要背景知识的专有名词放开头。原开场第一句是「Anthropic 很多团队九成以上的代码」, 对不认识 Anthropic 的人,前 3 秒等于没有信息——而前 3 秒正是决定划走的窗口。
3. 别在开场把结论说完。原开场以「这套分法过时了」收尾,观众信息到手即可离开。

改法(同一内容只换开头的示范):

原:「Anthropic 很多团队九成以上的代码,已经是 AI 写的。Claude Code 之父说, 　　正因为人人都能写代码,前端、后端、产品、设计这套分法过时了。」

改:「写代码这件事,正在从『会不会』变成『还要不要人写』。九成——这是 Anthropic 内部 　　现在由 AI 写出的代码比例。他们团队因此重新分了工,分成五种人,其中一种现在特别抢手。」

三处变化:数字前置(第 3 秒就砸出具体数字)、留悬念(不说是哪一种)、 开头不放需要背景知识的专有名词。

⚠️ 这条数据只来自 1 条片子,是信号不是定律。 但它推翻了我们自己此前的一个推断 (曾从「完播率+平均时长」两个聚合数推出「观众在切图表处流失」,曲线证明是错的), 所以:能拿到留存曲线时,永远不要用聚合数去推流失点。

⚠️ 「改开场」这个变量单独测不出来:同一账号不能把同一条内容发两遍, 新开场必然伴随新选题。留存若改善,无法区分是开场还是选题的功劳。 交付时要如实说明这一点,不要包装成对照实验。

按输入文本与时长产出分镜脚本,格式:

• 分镜表:段号 | 形态(数字人/图卡) | 口播文案(每段 ≤65 字) | 预计秒数 | 预计成本
• 成本优化默认形态:数字人只出镜开场与收尾,中段用零成本数据图卡;用户点名全程数字人则照做并重报成本
• 图卡文案(如有)
• 合计:总时长、总成本(数字人段秒数合计 × 1 元 + TTS<1 元)

长文案的拆段规则(超 15 秒时按此拆,不许删内容):

1. 按语义拆,不按字数硬切:一个完整意思落在一段里;拆在句号处,绝不在半句或词中间断开。

2. 每段 ≤65 汉字(约 13~14 秒 @1.0x 语速),留出余量——TTS 实际时长会因语速与标点浮动, 顶着 15 秒写容易超。写完用 tts.py 实测,以实测秒数为准,不用估的。 注意语速会改变字数与秒数的换算:TTS_RATE=+50%(1.5 倍速)时,同样 65 字只要约 9 秒, 单段可以放到约 95 字。永远以 tts.py 报的实测秒数为准,别按字数硬套。

3. 拆完先自检衔接:逐段连读一遍,段与段之间不能出现「话说一半」。compose.sh 是 concat -c copy 直接拼接,段间没有过渡也没有留白,是硬切——所以每段的收尾要是一个 可以停顿的位置。

4. 成本按总秒数线性算:数字人 1 元/秒,拆成 3 段 45 秒就是 ¥45,不因为分段而变便宜。 成本表必须报总时长与总金额,不能只报单段。

5. 中段若可以用图卡承载(数据、清单、对比),优先用图卡——零成本,且清单类信息看比听记得住。 有先后/层级关系的内容,用 make_diagram.py 画框架图,别用 make_card.sh 罗列文字: 五个角色摆成五行字,观众只看到一张清单;画成「想法→产品→规模」的链路加两个贯穿角色, 观众看到的是一个结构。同一张框架图分段 --highlight 不同节点,能让观众跟着讲解 一步步建立心智模型,比每段换一张不相干的卡有效得多。

   ⚠️ 画框架图不等于可以重排用户给的内容(2026-08-03 实测踩到):用户给了五个角色的 有序清单,技能自作主张拆成「主链 + 贯穿全程」两组,把第 3 位的「维护者」挪到了第 4 位 「扩展者」后面——顺序错了,而且那个分组是技能凭空发明的、原文里没有。 规则:结构可以可视化,顺序与语义不能改。 原文是有序列表就照序画成链;要提出别的 组织方式,先在门 A 连同文案一起报给用户,由用户定,不许直接落到图上。

   框架图一律用代码画,不要用 AI 生成图:AI 生成图里的中文几乎必错(缺笔画、造字、 串行),而框架图的信息全在文字上,错一个字整张图就废。代码画的字 100% 可控、可复现, 改词重画成本为零。AI 生成图适合做底纹与氛围,不适合承载文字信息。

语速:由配置项 TTS_RATE 控制(edge-tts 的百分比增量,+0%=1.0x、+50%=1.5x; 豆包与 macOS say 兜底会自动换算成各自的倍率)。短视频平台上 1.5 倍速通常比常速更抓人。

⚠️ 语速只能在 TTS 阶段调,绝不能在成片上加速:数字人口型由音频驱动,成片加速会把口型 一起拉快、看着像快放;而 TTS 按目标语速合成时,口型天然就是那个节奏。 ⚠️ 改语速 = 音频变了 = 数字人段必须重新生成(重新计费)。所以语速要在门 A 确认文案时 一并定下来,别等成片出来再改。

文案红线(违反即返工):不承诺"保证收录/霸屏/快速见效";数字可溯源且带口径限定;竞品不贬损;结尾引导语统一取配置项 BRAND_CTA(grep '^BRAND_CTA=' ~/.config/zmh-dhv/env),未配置则问用户要一句、用户说不加就不加,不得自行编造品牌名或引导语;若文本涉敏感词风险(品牌名密集)在脚本下方注明 50413 备选改法。

确认门 A:文案(硬门)

口播稿写完先给用户看,拿到确认才继续。 给的时候连这几项一起报:全文、分段、每段字数与预计秒数、 钩子是哪句。用户改就改完再确认一次。

为什么单独设这道门:文案是整条片子的地基,改文案要重配音、重生成数字人段——在这里改是零成本, 到成片再改是重新烧钱。

确认门 B:图片(硬门,仅当图由我们生成时)

凡是我们生成的图(文生图/图生图/合成图),一律先发给用户看,拿到确认才往下走。 不确认不上传、 不进 OmniHuman。

• 本人出镜的片子,确认的问题是「这还是你吗」,不是「好不好看」。2026-08-02 实测:图生图 strength=0.45 就已经换脸(发色、脸型、五官全变),用户一眼判「很假」。这种图拿去驱动口型, 等于用一张不是本人的脸对外说话。
• 用户自带的图跳过本门(他自己给的,不必替他审)。
• 确认时一并报清楚:图从哪来(实拍/文生图/图生图/合成)、用了什么提示词与参数——用户要复现或 微调时用得上。

确认门 C:分镜与成本(硬门,可被用户常驻豁免)

本工作区现行豁免(2026-08-04,用户明示):「后续确认好文案后直接生成,不需要确认视频了」。 即门 A 通过后,门 C 视为已授权,可直接带 --confirmed 出片,不必逐段回来问成本。 边界:豁免的是成本确认,不豁免门 A(文案)与门 B(图片);换账号、换计费方式、 或单次量级明显超出既往(例如从几十秒跳到几分钟)时,仍要回来报一次。 用户说「停一下/先别花钱」即刻失效。

无豁免时:把完整分镜脚本 + 成本表报给用户,明确拿到"确认/开做"才进入 ③。用户改稿则改后再确认。 未确认不得调用 CVSubmitTask / CVSync2AsyncSubmitTask(这两个是仅有的计费接口)。

这道门有机器闸兜底:jimeng_dh.py / jimeng_video.py 不带 --confirmed 会直接拒绝提交, 并打印本段的时长与预估。纪律会漏,闸门不会。 有常驻豁免时 --confirmed 才是默认可带的;没有豁免时它应当是「已拿到用户确认」的证据, 不是一个固定参数。

③ 制作(开始花钱)

cd "${CLAUDE_PLUGIN_ROOT}/skills/digital-human-video"   # 未装插件时为本技能所在目录
python3 scripts/tts.py --script <确认稿.md> --outdir work/<项目名>/audio     # 按「## 段N」分段配音,报每段实际秒数
scripts/make_card.sh work/<项目名>/card1.png "标题" "行1|行2|行3" "脚注"      # 纯文字图卡
python3 scripts/make_diagram.py --out work/<项目名>/diag.png --title "五种角色" \
  --chain "原型师|抓住第一个想法" "构建者|做成产品" "扩展者|放大十倍" \
  --side "维护者|守住它" "收尾人|打磨" --stage "想法" "产品" "规模" --highlight 0 1   # 框架图(有结构关系时用)
scripts/upload_asset.sh <人像图> work/<项目名>/audio/seg_01.wav ...          # 换公网 URL(仅数字人段音频需上传)
python3 scripts/jimeng_dh.py --image <图URL> --audio <段URL> --out work/<项目名>/dh_XX.mp4 --confirmed   # 逐段,串行(并发 1),RTF≈20;--confirmed 仅在门 C 通过后加
# —— 走视频生成路线时改用下面这条(不对口型,配画外音;每段都锚回同一张原图,别接龙)——
python3 scripts/jimeng_video.py --image <同一张图URL> --prompt "<运镜与动态描述>" \
  --frames 241 --aspect-ratio 9:16 --seed <固定值> --out work/<项目名>/clip_XX.mp4 --confirmed
# 写 work/<项目名>/segments.txt
#   dh   <mp4> - <字幕txt>          数字人段(自带音轨)
#   card <png> <wav> <字幕txt>      静态图卡段
#   clip <mp4> <wav> <字幕txt>      生成视频段(铺满整幅,时长以旁白为准)
scripts/compose.sh work/<项目名> work/<项目名>/成品.mp4

• 音频每段必须 ≤15 秒(超了回 ① 按语义拆段,不是删文案);video_url 1 小时有效,脚本已即时下载。
• 数字人段生成失败:5041x/5051x=审核不过(按脚本备选改法换词重来,只重做失败段)、50429/50430=限流退避、50500/50501=可重试。
• 制作完把服务器上的临时素材删掉(尤其人像图):ssh $ZMH_ASSET_SSH rm ...。

④ 交付与归档

• 给用户成片路径 + 实际总成本(按各段产出秒数合计)+ 生成耗时;
• 显式「视频由 AI 制作」角标已由 compose.sh 烧录,jimeng_dh.py 输出 aigc_meta_tagged=true 才算隐式标识成功——两者缺一在交付时明示;
• 运营用途的片子:成片信息按所在工作区的归档约定记档(有台账则记入当期档);提醒发布时在平台侧勾选 AI 生成声明;发布一律人工,不在本技能内。

背景音乐(可选,但只能用自己合成的)

永远不要给成片配一首现成的曲子。 受版权保护的音乐发到公开平台就是侵权,平台的 版权识别还会给视频打标记直接限流——法律和流量两头都是硬伤。素材站上标「免费下载」的, 多半只是免费试听,授权条款经常不许商用或要求署名,逐条核实的成本比自己合成还高。

make_bgm.py 纯代码合成,每个采样点都是现算的,可商用、可修改、无需署名、零成本:

python3 scripts/make_bgm.py --out work/<项目名>/bgm.wav --seconds 33 --mood calm
# mood: calm(夜景/思考类,默认) / bright(结论/产品类) / tense(问题/风险类)

混音:默认恒定音量,不要侧链闪避

侧链闪避(人一说话音乐自动下潜)在广播里是标准做法,但在短视频里听感是「音乐忽大忽小」, 用户会直接抱怨(2026-08-04 实测)。短视频只有几十秒、人声几乎不停,闪避不断触发与释放, 观众听到的就是一层不停呼吸的底噪。默认不用闪避,选一个从头到尾压得住的恒定音量。

两遍 loudnorm,第二遍必须 linear=true——单遍 loudnorm 本身是动态的, 即使去掉了侧链,它也会自己把音乐泵起来又压下去。「忽大忽小」有这两个来源, 只去掉侧链是修不干净的。

# 第一遍:测量
ffmpeg -i 成片.mp4 -i bgm.wav -filter_complex \
  "[1:a]volume=0.09[m];[0:a][m]amix=inputs=2:normalize=0:duration=first[a]" \
  -map "[a]" -c:a pcm_s16le mix_raw.wav
ffmpeg -i mix_raw.wav -af loudnorm=I=-14:TP=-1.5:LRA=11:print_format=json -f null -   # 取 input_i/tp/lra/thresh

# 第二遍:linear=true 施加单一恒定增益
ffmpeg -y -i 成片.mp4 -i bgm.wav -filter_complex "
  [1:a]volume=0.09[m];[0:a][m]amix=inputs=2:normalize=0:duration=first[mx];
  [mx]loudnorm=I=-14:TP=-1.5:LRA=11:linear=true:measured_I=<I>:measured_TP=<TP>:measured_LRA=<LRA>:measured_thresh=<TH>[a]" \
  -map 0:v -map "[a]" -c:v copy -c:a aac -b:a 192k -shortest 成片-配乐.mp4

• normalize=0 必带,否则 amix 会把总音量砍半
• loudnorm=I=-14 是社交平台的通行响度,不做的话在信息流里会明显比别人小声
• 验收:量音乐层逐秒电平的标准差,σ<4 dB 才算平稳;残余波动应能归因到曲子本身

调平必须量 1~4kHz,不能量全频段(这条最容易错)

2026-08-04 实测:全频段 RMS 显示音乐「低于人声 8.8 dB」,数字很合理, 用户在手机上完全听不见。逐频段拆开才看到真相:

频段	音乐 vs 人声	手机能不能放
20~150 Hz	+27.9 dB	放不出
150~400 Hz	+8.3 dB	很弱
400~1200 Hz	−3.3 dB	勉强
1200~4000 Hz	−19.7 dB	手机最响、人耳最敏感
4000~8000 Hz	−33.7 dB	空

音乐能量几乎全堆在手机放不出的低频,把全频段 RMS 撑得很好看,而真正决定 「听不听得见」的 1~4kHz 是空的。手机喇叭在 1~4kHz 效率最高,人耳也在这一带最敏感。

所以调平只看 1~4kHz 这一段的音乐/人声差值:

位置	1~4kHz 音乐应低于人声
人声停顿处	6~10 dB
人声最响处	14~18 dB

def band_db(x, lo, hi, SR):          # x 为单声道浮点样本
    X = np.fft.rfft(x); f = np.fft.rfftfreq(len(x), 1/SR); m = (f >= lo) & (f < hi)
    return 20*np.log10(max(np.sqrt((np.abs(X[m])**2).sum()/len(x)), 1e-9))

配乐若是外来成品,选曲时就该挑有中高频内容的(钢琴、吉他分解、铃音、轻打击); 纯低频 pad 或纯氛围垫在手机上必然消失,再怎么调音量也救不回来。

另一个测量陷阱:不要拿「混音后 vs 原音轨」去测侧链闪避。音乐在总和里占比很小, 压不压都测不出差别,会误判成「侧链没工作」。必须把音乐支路单独渲出来与人声逐秒比对。

⚠️ zsh 陷阱:本机默认 shell 是 zsh,$2:ratio= 里的 :r、:a 会被当成参数修饰符 (:r 去扩展名、:a 转绝对路径),把滤镜串吃坏且报错难懂。滤镜里引用位置参数一律写 ${2} 带花括号。

结尾引流卡(CTA)

引流片结尾加一张 CTA 卡,配音 + 图卡 + 字幕三处同时给出同一句话。

配音要补静音:TTS 念一句短 CTA 只要 2 秒左右,卡片跟着只停留 2 秒——观众来不及看清、 更来不及去评论。补静音到 3.5~4 秒再进合成:

ffmpeg -y -i cta.wav -af "apad=pad_dur=1.65" -t 3.6 cta_padded.wav

照用户原话渲染,不要替他改写措辞。 CTA 是转化环节,用词是用户的决定。

短标题与描述(发布必备,与成片、封面一起交付)

成片不是交付物的全部。 一条片子要发出去,至少需要四样:成片、封面、短标题、描述。 少任何一样,用户都得自己现编——而临场编出来的东西不会被记进台账,复盘时说不清用的是哪版。

短标题(6~16 字)

平台用它做搜索与话题聚合。规则:

• 把片子最硬的那个具体事实塞进去,别写概括性的标题。 「九成代码已经是AI写的」优于「聊聊 AI 写代码」;「数据全在小王微信里」优于「企业为什么用不好 AI」。
• 不重复封面上的字。封面和短标题在信息流里同时出现,写一样等于浪费一个位置。

描述

体例固定四段,按序:

1. 钩子句 —— 通常就是口播稿的第一句。信息流会截断,第一行决定展不展开。
2. 内容要点 —— 把片子的骨架用文字再给一遍。这不是冗余:很多人静音刷, 描述是他们唯一能读到的完整内容;而且文字内容会被平台索引。
3. CTA —— 必须与片尾口播一致。片尾说 A、描述写 B,观众会困惑该做哪个。
4. 话题标签 3~5 个 —— 多了会被判堆砌,少了进不了话题池。

置顶评论(有归因需求时必备)

置顶评论不是描述的重复,它有两个职责:

1. 承载归因链接(带参 URL,让服务器日志能识别来源)
2. 补一件片子里没说的事

第 2 条才是关键。 只放链接的置顶评论没人点开,链接也就白放了。 必须给一个「片子看完了还值得看这条评论」的理由。

好用的三种补法(2026-08 三条片子各用了一种):

补法	例子
解释片中一个没展开的概念	片尾 CTA 提到一个术语,正文没解释——评论区补上,顺带把断裂变成钩子
把片中的一个自测题扩成一份清单	片里给 1 个问题,评论区给 3 个,成为可直接拿去用的自查表
补核实时读到、但片长放不下的内容	核实第三方事实时官方页里的次要事实,片子放不下,正好填评论区

最后一种最省力:核实本来就要做,副产品直接就是评论区的料。

写完存台账,与描述放在一起,发布后原样粘贴。

三条硬规矩

• 引用第三方事实必须标来源,并且发布前自己核实过。 2026-08-10 实测:用户给的一条 AI 资讯,核实后发现基本属实, 但官方页里有一层用户那份没提(检测工具尚未公开),那一层反而成了片子最值钱的落点。 核实不只是防错,还常常能捡到别人没说的东西。
• 引流片的描述里不出现自有产品名、不写任何效果承诺。判断标准与片子本身一致: 把品牌名全部抹掉,这段描述还有人愿意读完吗?
• 描述定稿后原样存进台账,发布时复制粘贴,不临场改。改了就和登记的对不上。

封面(发布必备,与成片一起交付)

make_cover.py 从原图或成片抽帧加大字钩子,输出 1080x1440(视频号封面比例)。

python3 scripts/make_cover.py --image 原图.png --out cover.png --anchor 0.78 \
  --tag "Anthropic 内部" --line "九成代码" --line "已经是 AI 写的"

封面是在缩略图尺寸下被看到的,一切取舍由此而来:字要极大、一行 ≤8 字、 最多两行、深底金/白字加深色描边。写满一句话在信息流里就是一团灰。

三条实测纪律(2026-08-04 都踩过):

1. 用原图,不要从成片抽帧 —— 成片有烧录字幕和 AI 角标,会一起被抠进封面。
2. 文字不能压在脸上。人脸是封面最大的注意力钩子,压掉它等于自废武功。 人像片子把文字放在胸口/大衣区域(--anchor 0.78)或头顶上方(--anchor 0.15), 出图后一定要看一眼——脚本不知道脸在哪,--anchor 是人来定的。
3. 钩子里要有具体数字。「九成代码已经是 AI 写的」止得住手指, 「分成了五种角色」缺主语、单看封面不知道在说谁。

成片验收(合成完必做,不做不交付)

抽帧看全画幅,每个分镜至少一帧。 不是看素材图、不是看日志——素材单看都是好的, 毛病全出在叠加之后:字幕条是 45% 半透明黑,压住图上的字不是遮掉,是透出一层鬼影。

for t in 4 14 22 29; do ffmpeg -y -loglevel error -ss $t -i 成片.mp4 -frames:v 1 -vf scale=380:-1 f_$t.png; done
ffmpeg -y -loglevel error -i f_4.png -i f_14.png -i f_22.png -i f_29.png -filter_complex "[0][1][2][3]hstack=inputs=4" grid.png

逐条看:① 图上有没有内容被字幕条压住 ② 字幕有没有标点落行首 ③ 词有没有被拦腰断开 ④ 角标在不在 ⑤ 图里的顺序/措辞与口播稿是否逐项一致(第 ⑤ 条最容易漏,因为图本身好看)。

2026-08-03 实测:同一条片子连交两次都带着「出处小字透在字幕里」,原因就是只看了 框架图 PNG、没看合成后的帧。素材没问题 ≠ 成片没问题。

计费事实(2026-07 文档口径,报价前可复核控制台)

数字人快速模式 1 元/秒(480P,并发 1);即梦视频生成3.0 若用作 B-roll:720P 0.28 元/秒。只有调用成功才计费。

技术路线

数字人与视频生成统一走抖音系服务(火山引擎·即梦AI API),需企业认证账号并在控制台开通「数字人快速模式」。本技能产片定位为实验/宣传用途,成片是否用于正式投放由使用方另行决定。