★ `min_motion_ratio: 0.7` 那行注释：什么才算「真实动效」

2026-08-09

在 OpenMontage 里翻治理相关的代码，最值得停下来看两遍的不是某个函数，而是一行行末注释。

lib/delivery_promise.py 的 PROMISE_RULES 表里，motion_led 那一行写着 "min_motion_ratio": 0.7，后面跟了一句：

# At least 70% of cuts must be real motion (video/animation, not Remotion slides)

至少 70% 的镜头必须是真实动效——视频/动画，不是 Remotion 幻灯片。

这句注释干了一件很多项目不肯干的事：它把「真实动效」这个听上去很主观的词，用一个数字加一条排除项固定了下来。这篇就只讲这一个数字。

0.7 到底写在哪一行的哪个字段上

先把位置说死，方便你自己去仓库里核。这个数字不在 README 里，也不在配置文件里，它在 lib/delivery_promise.py 的 PROMISE_RULES 常量表中，属于 motion_led 这一条承诺类型。同一行上还有另外两个开关：

字段	`motion_led` 的取值
`still_fallback_allowed`	`False`
`requires_video_generation`	`True`
`min_motion_ratio`	`0.7`

这三个字段要连起来读才有意义。requires_video_generation: True 说的是这类片子必须具备视频生成能力；still_fallback_allowed: False 说的是不允许退回静图；min_motion_ratio: 0.7 则给出了「到什么程度才算数」的量化线。前两个是布尔开关，第三个才是那把尺子。

这条承诺的 description 原文是 “Video’s quality depends on real motion — generated video clips, footage, or animation.”（这类视频的质量取决于真实动效——生成的视频片段、实拍素材，或者动画。）注意它列了三类东西，注释里那句 video/animation 是同一个意思的简写。

四档比例里，0.7 是唯一的高位

八种交付承诺各有自己的 min_motion_ratio，八条规则里去重之后只剩四个取值：0.7、0.3、0.2、0.0。八种承诺类型的完整表格我们另有一篇专门拆，这里只把与 0.7 直接相关的几行拎出来对照：

0.7：只有 motion_led 一种
0.3：source_led 和 avatar_presenter
0.2：hybrid
0.0：data_explainer、teacher_explainer、screen_demo、localization 四种

这个分布本身就把 0.7 的分量说清楚了。次高档是 0.3，中间隔了一大截；而四种承诺的下限直接是 0.0——也就是说，讲解片、教学片、录屏演示和本地化配音，在规则层面完全允许零动效。规则并没有把「有动效」当成普遍要求，它只在你自己宣称要做一条靠动效撑起来的片子时，才把线抬到 70%。

另一个容易被略过的对照：不允许静图回退（still_fallback_allowed: False）的承诺类型有两种——motion_led 和 avatar_presenter，它们也正是唯二要求 requires_video_generation: True 的。但 avatar_presenter 的比例下限只有 0.3。同样是「必须有视频生成」，两者对动效占比的要求差了一倍多。

「真实动效」是被反向定义的

回到那行注释里最有信息量的半句：not Remotion slides。

它没有正面给「真实动效」下定义，而是点名排除了一样东西——用 Remotion 做出来的幻灯片式画面。这是一种很务实的写法：正面定义动效很难写，但「加了转场的静态画面不算」是能落地判断的。

这里有一处值得放在一起看的文本。README 在两套合成运行时的表格里描述 Remotion 时写的是：当没有配置任何视频生成 provider 时，agent 生成静态图，由 Remotion 把它们变成完全动起来的视频。而 lib/delivery_promise.py 那行注释把 “Remotion slides” 明确排除在 real motion 之外。两处文本说的不是一回事，我不打算推断哪一处更准，也不打算替代码解释它的意图——只是提醒你，如果你的片子被定成 motion_led，那么「用 Remotion 把静态图动起来」这条路，在这行注释的口径里是被单独点了名的。以仓库当前状态为准。

顺带说一处对比。同一套治理里的 lib/slideshow_risk.py 有六个维度，其中一个就叫 weak_motion，模块 docstring 对它的解释是「有动效但没有叙事目的」；六个维度各按 0-5 分打，分越低越好，判定门槛是 < 2.0 强、< 3.0 可接受、< 4.0 需修改、≥ 4.0 直接判失败且不应进入 compose 阶段。有意思的是，这个文件里 render_runtime 参数的 docstring 原文说得很清楚：评分逻辑当前对运行时是中立的——文字很重的 HyperFrames 合成和文字很重的 Remotion 合成一样「幻灯片化」，参数保留只是为了让调用方把 runtime 和 family 一起记进审计。

所以同一套治理里，一处点名了 Remotion，一处明说自己 runtime 中立。这是两份源码注释之间可核实的口径差异，陈述到此为止。

这个数字在流程里被谁用

DeliveryPromise 上有一个方法叫 validate_cuts(cuts)，它的 docstring 说返回一个含 'valid'、'violations'、'motion_ratio' 三个键的 dict。签名和返回结构是明的，但它到底怎么算出那个 motion_ratio、怎么判定某一刀算不算动效，这部分代码我们没有读完，所以不描述——你要用，就自己去读那段实现。

能确定的是这条线会在两个地方被用到，README 的 Production Governance 一节写得很直接：

一处是 Pre-compose validation，违反交付承诺时阻断渲染，README 举的例子恰好就是「动效主导的视频里 80% 是静图」；同一道闸还会在幻灯片风险分为 critical 时阻断、渲染器 family 缺失时阻断。这一节的原话是：在浪费 GPU 时间之前抓住坏掉的计划。

另一处是 Post-render self-review，渲染完成后要跑 ffprobe 校验、在 4 个位置抽帧检查黑帧和坏掉的叠层、分析音量查静音和削波、核验交付承诺是否被兑现、检查字幕是否存在；README 明写评审不通过视频就不会被呈现。

也就是说，同一个承诺在合成前查一次计划、渲染后查一次成品。这是文档口径，不是我们跑出来的结果。

为什么非得把它锁死

lib/delivery_promise.py 的模块 docstring 把动机说得比任何架构图都清楚。它要防的是「最具破坏性的失败模式」：在用户不知情的情况下，从动效主导悄悄降级成静图主导。交付承诺在提案阶段设定并锁定，compose 阶段兑现不了时，系统必须停下来问，而不是悄悄替换。

配套的实现是 DeliveryPromise 上的 approved_fallback 字段，它只有两个具名取值——"animatic"（动态分镜）和 "still_led"（静图主导）——或者 None。降级不是不能发生，而是必须以一个被显式批准的值存在；没被批准过的降级，这个字段就是 None。

同一个数据类的反序列化默认值也值得记一下：from_dict() 里 motion_required 和 source_required 都默认 False，tone_mode 默认 "corporate"，quality_floor 默认 "presentable"（三档 draft / presentable / broadcast 里的中间档）。默认状态不是「要动效」，动效是你主动挑 motion_led 才要的。

那你该不该把片子标成 `motion_led`

顺着这些数值往回推，判断路径其实不复杂。

先看你手上有没有视频生成能力。motion_led 的 requires_video_generation 是 True，这是规则层面的前置条件。README 的视频生成清单列了 15 个 provider，按类型数是 8 个 Cloud API、4 个 Local GPU（含标注为 Local GPU / Modal 的 LTX-Video）、3 个 Stock。这些描述和分类都是 README 自己写的，我们没有调用过其中任何一个 API，也不据此推荐任何一家。

再看你能不能接受「不通过就停」。still_fallback_allowed: False 加上 70% 这条线，意味着这类项目在规则上没有静图兜底路径；真要退，也只能退到一个被显式批准的 approved_fallback 上。如果你的实际情况是随时可能改主意、能出片就行，那把承诺定成 hybrid（0.2）或者干脆走 data_explainer / teacher_explainer（0.0）这类下限为零的类型，反而更诚实——注意后两类的 description 原文本身就带价值取向，教学类写的是 “Clarity and comprehension over spectacle”（清晰与理解高于奇观），录屏类写的是 “Legibility over cinematic dressing”（可读性高于电影感包装）。

最后提醒一句边界。上面这些全是仓库里的规则文本和默认值，是写给这套系统和 agent 看的约束，不是「配好了就一定拿到 70% 真实动效」的保证。能不能兑现，取决于你实际接了哪些 provider、agent 有没有照规矩走完那几道闸。这套系统我们没有安装或运行过，本文只负责把数字和它所在的位置说准。

本文依据 OpenMontage 官方仓库（github.com/calesthio/OpenMontage）的 README、 AGENT_GUIDE.md、config.yaml、pipeline_defs/ 与 lib/ 下的治理模块整理，核对日 2026-08-09。本文内容为仓库源码与文档口径，我们没有安装或运行过该系统，也没有调用过其中任何一个 provider API，文中出现的成本数字均为项目方在 README 中自行标注的金额，非我们的实测结果。该项目以 AGPL-3.0 发布，部分流水线在 manifest 中自标 stability: beta，请以仓库最新内容为准。