Silver-Fight-Video-Skill v1.0.0

把用户的一两句话和角色/场景参考素材，编译成真正发生位移、追击、接触、反击、破防和终结的战斗视频提示词。目标不是写得像武侠小说，而是让视频模型优先理解：谁先动、从哪里冲到哪里、镜头如何追、何时接触、谁被迫位移、大招如何穿越战场并改变结果。

首要原则

1. 动作优先于展示：正式提示词开头先声明速度、动作占用率和主攻防链，再写精简身份锁；不要用几百字外观描述把模型诱导成角色展示片。
2. 高速不等于加速播放：速度来自爆发启动、跨空间位移、连续重心转移、追击、急停和再加速。全片正常速度为主；关键接触只允许 2–4 帧清晰顿挫，立即继续，不使用覆盖整段的慢动作。
3. 运镜必须被动作触发：贴身追拍、平行疾移、擦镜转向、命中急停、冲击后撤都要绑定具体动作。禁止“镜头运动丰富”这种无执行意义的空话。
4. 多人战不是轮流表演：为每个对手分配压力通道和战斗职能；后一威胁必须利用前一击造成的姿态、位移或路线缺口，形成可检查的 [压力接力N]。威胁可以同时存在，关键接触错开 0.2–0.6 秒；非当前主攻者也必须包抄、封路、蓄势或被前一击干扰，不能站着等。
5. 大招必须穿场命中：主体不能只围绕施法者旋转展示。它必须跨越可见距离、遭遇反制、完成决定性接触，使敌人和环境产生方向明确的位移、破坏与余波。
6. 动作拍不等于摄影镜头：一个动作拍可以用关系镜头、接触镜头和结果镜头共同完成。高燃战不能把“6–7拍动作脊柱”误写成只有6–7个长镜头。
7. 详细不等于过载：保留高价值动作、镜头、接触和特效因果；删除重复外观、重复否定、摄影器材堆词和无法同时执行的枝节。
8. 证据诚实：静态校验不能证明生成质量。没有审看目标模型真实成片时写 Production Validation: NOT_TESTED。
9. 轻锁世界，强锁路线：场景参考默认只锁世界身份、地貌材质、天气和光向，不复刻固定构图；高燃多人战必须沿相连地理推进，不得把山路或森林发明成中央圆形擂台。
10. 完整能力不得隐藏：复杂任务默认启用 SIGNATURE_FULL。路线、压力链、镜头、打击物理、逐击特效、移动大招、逐敌结算和负面门禁不得为了“稳定”被静默删成普通短提示词。
11. 接力必须在画面中发生：文字因果不足以防止模型按熊、狼、蛇分段。前8秒至少三次 [双威胁同框N]，当前接触尚未结束时下一敌人已进入同镜攻击路径。
12. 结算必须看得见敌人：最后3.5–4.0秒连续兑现三次目标命中；每名敌人接触后仍可见0.35–0.60秒并抵达具体落点。水雾、强光、出画或消失不能代替终态。

零、如何调用本 Skill

本包是一个可调用主 Skill，内部的高速动作、镜头、打击感、特效、大招、十三系属性库和兵器身法库是按需读取的模块，不是需要分别输入 $大招skill、$水系skill 的独立 Skill。

主调用名只有一个：

$silver-fight-video-skill

支持两种调用方式：

1. 自动调用：用户直接说“写15秒仙侠1V3高燃打斗提示词”“这个视频打得太慢，帮我修”等符合 frontmatter 描述的任务时自动启用；
2. 显式调用：用户在请求开头写“使用 $silver-fight-video-skill”，并可附路由、档位、模型、时长、素材编号、属性或招式偏好。

显式调用模板：

使用 $silver-fight-video-skill。
路由：D 武斗接大招；档位：SIGNATURE_FULL；时长：15秒；模型：Seedance 2.5。
图1主角，图2–4敌人，图5场景；主角水系龙族持戟盾，1V3。
调用水系大招库、长枪/长柄兵器身法、双威胁并发、移动触发大招和可见终结。
输出：只要一条可复制的完整提示词＋分类负面约束。

若用户没有写路由，由本 Skill 自动判断：纯近身打斗选 A；武斗带仙术选 B；只设计大招选 C；打斗后释放大招选 D；需要多段连续生成选 E；分析失败成片并重写选 F。用户点名属性或兵器时，只读取对应库段落，不把十三系大招或全部兵器招式同时塞进提示词。

常用显式短句：

使用 $silver-fight-video-skill 路由A：只做高速近身武斗，不要大招。
使用 $silver-fight-video-skill 路由C：调用雷系大招库，设计一个15秒独立终极技能。
使用 $silver-fight-video-skill 路由D SIGNATURE_FULL：高速武斗接水龙大招，1V3，最后逐敌可见结算。
使用 $silver-fight-video-skill 路由F：根据我提供的失败视频诊断站桩、慢动作、轮流表演和大招遮挡，再输出修复提示词。

一、选择路由

有参考素材时还读 平台与素材职责。平台已指定或需要多模型版本时读 模型适配。具体招式才读 兵器身法库；不要把整库塞入成品。

二、简单输入必须自动拆解

用户只给“人物、属性、谁打谁、一个场景、时长”也足够。不要把拆解责任退回用户；按 简单输入战斗编译器 内部完成：

身份与媒介锁
→ 体型/兵器/移动方式推导战斗职能
→ 把场景参考拆成世界锁和可扩展的三战区路线
→ 画出主角与每个敌人的攻击通道与三项压力接力
→ 为双方建立目标与战术协同
→ 设计一个可连续执行的动作脊柱
→ 安排速度节拍与镜头触发
→ 让大招从当前运动中触发并解决前段建立的问题
→ 压缩成目标模型可执行提示词

如果输入含多角度角色设定图，默认每张图描述一个角色，不把面板变成分身；但这条防复制约束只写一次，不在每阶段重复。

三、默认全能力档 SIGNATURE_FULL

满足任一条件即默认启用：11–15秒高燃、3名以上战斗单位、角色图与场景图并存、武斗接大招、用户要求炫酷特效/打击感/高速追击。此档不是“多写形容词”，而是必须按以下顺序完整编译：

三条多人执行核 → 素材职责 → 战斗职能 → 世界锁与三战区路线 → 三项压力接力与三次双威胁同框
→ 6–7拍动作因果 → 9–12镜摄影脊柱 → 普通/重击逐击特效
→ 敌方连续性台账 → 移动触发大招 → 三段可见终结 → 终态全景 → 声音 → 分类负面词 → 模型适配

用户没有提供复杂拆解时由 Skill 自动补全；不要把创作责任退回用户。平台容量不足时先删重复外观和空泛质量词；仍装不下就拆 SEQUENCE。禁止静默删除本 Skill 的核心能力后交付“安全但平庸”的短提示词。

四、十五秒高燃硬门槛

路由 A、B、D 的 11–15 秒片段默认 KINETIC_HIGH。除非用户明确要求沉重慢战，否则成品至少满足：

• 复杂 FULL 档字数：3名及以上战斗单位、带参考图或大招的15秒高燃 MASTER，目标为3000–4500个中文字符；低于3000判为细节不足，高于4500优先去重。目标模型适配版可以因平台容量压缩，但必须保留动作、逐击特效和终结结算。普通1V1和单动作不强制凑到3000。
• 开场 0.0–0.6 秒内已有推进、扑击、格挡或闪避，不先列阵展示；
• 有 6–7 个清楚动作拍；动作拍负责攻防因果，不等同于摄影镜头；
• 激烈1V1使用8–10个明确镜头，激烈1V多使用9–12个明确镜头；宏大战场/大招展示即使节奏较沉重也至少6个、通常6–8个镜头。 只有用户明确要求一镜到底时才豁免；
• 每个镜头写入镜起态、主动作/接触、单一主运镜、切点和出镜终态；普通动作镜通常0.6–1.8秒，大招穿场镜可到2.5秒，不能用少量3–5秒长镜头冒充高速；
• 主角至少 3 次明显换位，其中至少 1 次跨越前后景或 3 米以上空间；
• 高燃1V多默认显式跨越 [战区1]、[战区2]、[战区3]；场景构图或擂台只有用户明确要求时才固定，否则场景图只锁世界身份和路线种子；
• 至少 3 项 [压力接力N]，后一敌人必须利用前一击造成的滑退、失衡、遮挡、破坏或路线缺口；
• 前8秒至少 3 项 [双威胁同框N]；当前接触结束前，下一敌人已在同镜1–3米/上空攻击路径中，不得只在背景观看；
• 使用 [敌方连续性] 记录每名敌人的离镜状态、再次进入和最终落点，禁止瞬移复位或无解释消失；
• 至少 4 次可读接触/擦身避让/武器咬合，至少 1 次环境碰撞；
• 任一纯站立蓄力或展示段不超过 0.5 秒；
• 每个明确镜头都由动作、接触、遮挡、方向切换或尺度升级触发，并有构图终点；不能只在段首笼统写一次“动态运镜”；
• 全片至少 75% 时间处于推进、攻防、换位、追击、受击或回收运动中；
• 大招占 2.5–4.0 秒，包含“预兆压缩—主体穿场—对方反制—决定性命中—余波”，不能只生成环形水龙/光圈围绕施法者；
• 武斗接大招必须写 [运动触发大招]：从滑退、疾冲、坠落、反蹬、旋身卸力或被压入地形时触发；无明确安全窗口时禁止站定读条；
• 仙侠强化战必须形成“普通攻击三层、重击四层、大招五层”的视觉升级；轨迹贴合动作，接触核心只在真实命中点出现，碎屑/液滴沿受力方向喷射；
• 1V多大招必须为每名主要敌人写独立 [终结结算N]，包含命中部位、反制、位移终态和环境残迹；
• 设置 [终结窗口] 与 [终态全景]：每个结算的目标在接触前可见、接触面清楚、命中后继续可见0.35–0.60秒；最后核对三敌不同位置/姿态，不用水雾遮挡或主角胜利pose替代；
• 最后 0.4–0.8 秒保留惯性、滑停、碎屑/水雾衰减和双方终态，不回到开场列阵。
• 正文末尾设置独立负面约束块，至少覆盖动作速度、接触物理、身份/武器、运镜空间、特效/大招、终态/画面六类中的五类；不把负面词散落成一句含糊的“避免错误”。

这些是编译门槛，不要求在成品里机械打印统计表；但交付前必须能逐项指出对应动作。

五、提示词优先级与顺序

模型注意力按以下顺序分配：

1. 一句高优先动作总令：正常速度高速实战、立即开打、无长慢镜
2. 角色别名、数量、兵器与参考图职责（精简）
3. 场景职责、三战区路线和开场运动状态
4. 多人压力接力与双威胁同框：上一结果怎样制造下一威胁，下一敌人如何在当前接触结束前进入同镜攻击路径
5. 分镜脊柱：按能量与规模生成6–12个明确镜头；每镜的入镜状态、跟随对象、运动触发、切点与落点构图
6. 逐击特效脊柱：普通击、重击与终结的轨迹—接触—定向反馈—状态改变—衰减
7. 敌方连续性台账、移动触发大招的跨区路径、三段可见结算和终态全景
8. 声音节拍与物理质量证据
9. 分类负面约束块：复杂多人战通常12–24条短约束，覆盖至少五类风险

不要把长篇世界观、角色外观复述或几十条负面词放在动作之前。参考图已经明确的外观只锁不可漂移字段；把字数留给运动。

六、动作与镜头共同编译

每个关键节拍至少包含：

起始惯性 → 0.2–0.5 秒预载 → 爆发启动 → 可见路径与跨距
→ 对手匹配防守/闪避 → 接触点 → 受力结构和位移
→ 相机在接触处短停 → 立即追随结果或转向下一威胁
→ 下一拍从当前姿势和动量继续

多人围攻再加：当前主攻者、次威胁所在通道、第三者怎样封路。禁止“敌人从四面同时攻击”但没有路径与先后。

读取 双威胁并发与可见终结。每个普通/重击镜头结尾必须交代下一敌人已进入哪里；不能让每名敌人独占2–3秒。最后3.5–4.0秒的三个 [终结结算N] 必须分别显示目标接触、位移和落点，不能用敌人消失或全屏水雾完成。

战场空间按 战场路线与压力接力 编译。换背景不算路线推进；必须是攻击冲量、追击、遮挡或封路把人物和相机从一个战区带到下一战区。

七、特效必须参加战斗

读取 战斗特效编译器。不能把“特效完整生命周期”误解为只需在片尾生成一个大招。仙侠武斗中的关键普通击和重击也必须把属性绑定到动作：

动作源头 → 贴身轨迹 → 局部接触核心 → 定向介质反馈
→ 对手姿态/位移改变 → 残留按材质衰减

普通击至少三层，重击增加受体结果，大招再升级为独立主体、穿场传播和分目标结算。若所有攻击都使用同一种圆弧光、同一种爆闪，或特效在人物停止后仍无原因循环，判定为 VFX_ACTION_UNBOUND_FAIL。

八、大招高燃门槛

按 大招编译器 建立招式卡。必须写出：

• 前段哪次受压、破防、借力或阵位提供释放资格；
• 释放时人物正在滑退、疾冲、坠落、反蹬或旋身卸力中的哪一种；
• 去掉颜色仍可识别的主体轮廓；
• 主体从哪里出现，跨越哪段战场，先撞什么、再改变什么；
• 敌方至少一次有效反制，终结如何在速度、密度、体量或规则上升级；
• 至少三类实体受体和两个不同时间尺度的余波；
• 命中后敌方与场景的不可逆终态。
• 多人战中，每名主要敌人一项可检查的 [终结结算N]，不能由同一团白光代替。
• 每项结算命中后目标轮廓仍可见0.35–0.60秒；最后用 [终态全景] 或一次短横移核对三名敌人，不以主角举武器站立作为收尾。

若大招只“盘旋、环绕、亮起、消散”，没有穿场、反制和命中，判定为 ULTIMATE_DECORATIVE_FAIL，必须重写。

九、模型适配

不要把一条主提示词原封不动投给所有模型。用户指定模型时，仅输出对应适配版；用户要跨模型测试时，先建立同一套 MASTER_ACTION_TRUTH，再根据 模型适配 输出各自版本，保持角色、动作结果和大招机制一致，只改变表达密度、镜头拆法和负面约束长度。

具体平台能力会变化；本包中的 Seedance 2.0 Mini、MiniMax H3、Seedance 2.0 Pro、Seedance 2.5 修复路由来自用户提供的四条 15 秒样片，属于样片驱动适配，不冒充平台官方规格。

十、正式输出

读取 输出合同。默认交付：

1. 制作设置与模型路由；
2. 简短素材职责表；
3. 动作设计摘要：执行核、场景职责、三战区路线、战斗职能、压力接力、双威胁同框、敌方连续性、大招解决的问题；
4. 一条可直接复制的目标模型提示词；
5. 动感门禁与冲突检查结果。

用户说“只要提示词”时只给成品，不输出推理过程。用户提供失败视频时，先以真实成片为证据审计，再改 Skill/提示词；不以原提示词意图代替成片事实。

十一、维护与验证

• 运行 scripts/validate_prompt.py 检查时长、素材编号、动作链、速度、镜头、大招、声音和冲突。
• 运行 scripts/validate_package.py 与官方 quick_validate.py 检查包。
• 运行 tests/test_validator.py、tests/test_examples.py 做回归。
• 静态通过只表示结构和规则无已知冲突；真实模型仍需生成审看，Production Validation 保持 NOT_TESTED 或记录各模型实测状态。