---

name: fight-video-create-skill description: 将用户的打斗构想通过场景、动作分镜方案、招式库、技能库和示例剧本的多层关键词检索，编译为可靠的战斗剧情、动作链、空间路线与动作分镜。用于打斗剧情构思、动作设计、招式设计、条件型技能设计、战斗分镜；不负责提示词生成，也不负责资料吸收与入库（吸收与入库由 fight-video-increase-skill 承担）。

战斗设计与动作分镜

核心约束

• 以用户锁定的人物、关系、武器、能力、动作顺序、胜负、时长、画幅、媒介和结尾为最高优先级。
• 本 Skill 只交付战斗剧情、动作设计、空间调度与动作分镜，不生成任何模型或平台的提示词。
• 提示词包装、模型或平台语法、生成参数、负面词、字幕/声音指令和成片提示语不得写入本资料包（data/ 与 reference/）。
• 先路由、后读正文。不得预读所有资料后凭印象强行关联。
• 自动匹配必须至少命中路由元中的一个关键词；零命中即视为无匹配。
• 命中数越多排名越高；同命中数再按强字段权重和路由元裁决规则排序。
• 单字关键词（如“剑”“刀”）与高频通用词（如“连招”“腿法”“清场”，以及“战场”“打斗”“招式”“追击”这类跨条目通用概念）不单独构成候选：前者几乎必然命中、后者跨条目通用，都没有区分度；只有全库都没有更强命中时才回退使用，回退时结果中 weak_fallback 为 true，并优先返回命中词字数 ≥ 2 的候选。
• 一次只加载一个主动作/分镜方案。其他方案只作为可选项列出，用户确认前不混读、不拼接协议。
• 参考资料提供机制、结构和质量标准，不覆盖用户锁定事实。
• 不输出内部推理。应清楚说明选用了哪些资料、如何使用，以及哪些部分为全新设计。
• 招式与技能的效果展示样本是必交付项，不是可选参考素材：展示招式候选或技能候选时就须把样本 GIF 的文件本身推给用户看，只把路径写成文字不算展示；该动作不受本轮任务是否继续或完成影响。当前环境确实不具备文件推送能力时（如只回显文本、不渲染附件的终端环境），必须明确写出「本环境无法推送文件」并逐条给出样本的绝对路径，不得静默省略、不得默认已展示。

路径与工具

资料（场景、动作/分镜方案、招式、技能、示例剧本的关键词表与全部正文）已封装进本 Skill 的加密资料包：data/catalog.bin 存关键词表与调参常量，data/corpus.bin 存全部正文。 目录内没有可直接打开的正文文件，正文一律通过下面的命令读取。

执行确定性检索：

python -X utf8 "<Skill 根目录>/scripts/route_reference.py" <scenes|design|moves|skills|scripts> --query "用户原文与提炼关键词"

读取正文——本文档中所有「读取某条正文」「读取所选方案正文」「读取案例」「读取技能正文」 均指这条命令：

python -X utf8 "<Skill 根目录>/scripts/route_reference.py" --read <scope>/<id>

<scope> 取检索结果顶层的 scope 字段，<id> 取候选的 id 字段，拼成 <scope>/<id>； 也可以直接传候选 file 字段的文件名。命令输出该条完整正文。

招式与技能的展示样本分属两个不同目录，不得混用： reference/action-storyboard-design/招式库/招式展示样本/ 与 reference/action-storyboard-design/技能库/技能展示样本/。showcase 字段的值是 Skill 根目录下的完整相对路径，形如 招式库/招式展示样本/<编号>-<名>.gif， 已含所在库与样本目录名，无需再判断属于哪个库。 命中招式后必须去招式库自己的展示样本目录按条目编号查找 <编号>-*.gif：找到就把 该 GIF 文件本身推给用户看（如 present_files），找不到写「该招式暂无预览」， 不得用别的条目样本顶替，也不得跳过该候选；技能样本只在技能库自己的目录里找。 展示候选时样本必须与候选在同一次回复里一起出现，只把路径写成文字不算展示； 当前环境确实不具备文件推送能力时（如只回显文本、不渲染附件的终端环境），须明确写 「本环境无法推送文件」并逐条给出样本绝对路径。样本不参与匹配或排序。

关键词表的维护（增删条目、改检索词、重排编号、批量改范围词）由维护方在源码仓库进行， 用 python -X utf8 scripts/validate_routes.py 校验；本发布包不含该校验脚本， 也不含任何散装正文文件。

意图路由

先判断任务类型：

1. 用户提供构想并要战斗剧情、动作设计或动作分镜：执行“创作流程”。
2. 用户提供一个或多个文件并要求吸收、学习、入库、更新资料：不属于本 Skill。移交 fight-video-increase-skill，不要在此读取、拆分或写入用户的资料文件。
3. 一个请求同时包含创作与吸收：说明吸收部分已移交，然后只用当前已有的资料执行创作流程，不为吸收读取用户文件。
4. 意图不清或文件用途不唯一：先询问。

创作流程

0. 提炼创作卡

从自然语言静默提炼：

• 锁定事实：人物、敌我、武器、能力、必备动作、顺序、胜负、对白、时长、比例、媒介、结尾。
• 设计关键词：题材、时代、场所、对战规模、战斗方式、武学/兵器、动作密度、写实程度、空间机制、镜头诉求、情绪、结局。
• 缺口：只有会影响路线选择或成稿可靠性的必要信息。

不要让用户填写内部表格。若缺少时长和比例且不影响设计，可先采用资料方案默认值并在交付中声明。

1. 场景抽取

先判断用户是否已给出可执行场景。场景至少应包含明确地点或空间类型；仅有“古代”“赛博朋克”“仙侠”等题材不算完整场景。

已有场景：尊重用户场景，直接进入阶段 2；不要为了使用资料而替换场景。

没有场景：

1. 用用户原文与场景相关提炼词检索 scenes。
2. 有命中时，只读取排名第一的主场景；混合题材确有必要时最多再读一个辅助场景。
3. 从资料中提取空间锚点、路线限制、可交互物、材质与光色，重新设计为适配当前剧情的场景，不复制无关角色或情节。
4. 零命中时明确写“场景资料无关键词命中，将进行原创场景设计”，再按人物能力、战斗方式和情绪设计最小充分场景。

2. 动作与分镜方案

1. 用用户原文、创作卡关键词和阶段 1 的场景摘要检索 design。
2. 若有命中，向用户展示：
   • 推荐方案：名称、文件、命中词、推荐原因；
   • 其他方案：从 available 列出其名称与定位；
   • 选择项：采用推荐方案 / 改用其他方案 / 用户输入自定义方案。
3. 必须等待用户确认。确认前不读取任何方案正文。
4. 用户确认后只读取所选方案正文。用户主动改选零命中方案属于手动覆盖，应说明“按用户指定使用”，不得伪称自动匹配。
5. 若零命中，提供两项：用户输入设计方案 / 智能体原创方案。不得把通用方案当作无条件回退；只有它也至少命中一个关键词时才能自动推荐。
6. 读取所选方案后，将其编译为当前项目的动作因果、空间路线、镜头结构和连续性约束，不照抄与当前剧情冲突的默认角色、镜头数、时长或结尾。

2A. 招式检索与合理性门禁

仅当用户要求具体招式、武学绑定、逐招拆解、兵器技法或动作链需要专业技法支撑时执行：

1. 用角色、身体条件、武器、主战距离、环境、对手和目标检索 moves。
2. 只读取有关键词命中的候选，通常 1 个主文件，必要时最多 2 个互补文件。
3. 展示招式候选 = 同时把样本推给用户看：候选名称、命中词与效果展示样本必须在同一次回复里一起出现。
   • 每个命中招式都必须去招式库自己的展示样本目录 reference/action-storyboard-design/招式库/招式展示样本/ 下、按条目编号查找 <编号>-*.gif；不得去技能库的样本目录找，也不得只看字段而不查目录；
   • 找到即返回：把该 GIF 文件本身推给用户看（用当前环境的文件推送能力，如 present_files），有几个候选就推几个样本；
   • 00-路由元.json 的 showcase 字段是同一条路径的登记值，用于交叉核对；以目录里实际存在的文件为准，两者不一致时按编号查找的结果执行；
   • 按编号找不到时，以「该招式暂无预览」明确告知，不得用别的条目样本顶替，也不得因无样本而跳过该候选；
   • 只把路径写进正文文字不算展示；该动作与后续流程、任务是否完成无关，不得推迟到成稿阶段、不得等用户追问；
   • 当前环境确实不具备文件推送能力时（如只回显文本、不渲染附件的终端环境），明确写「本环境无法推送文件」并逐条给出样本的绝对路径，不得静默省略。
4. 对每个候选招式检查：
   • 角色是否掌握或能够合理使用；
   • 武器形制、肢体条件与主战距离是否兼容；
   • 当前姿态能否进入，上一动作末态能否衔接；
   • 场景是否提供所需空间、支点和落点；
   • 在目标时长内能否完成起势、接触、反馈和结果；
   • 是否破坏用户锁定的动作顺序、胜负或写实程度。
5. 合理性高才选用并具体化身体路径、接触点和结果；合理性低则弃用，不为命中资料强改剧情。
6. 全部候选不合理时，按同等生物力学完整度原创招式。
7. 资料或索引提及但 --read 取不到的条目只能报告缺失，不得伪造其内容。

2B. 技能检索与特殊条件门禁

仅当角色需要独立能力机制，且该机制不能由招式库中的具体武学、兵器技法、身体路径或连续招式表达时执行：

1. 先招式、后技能：先完成阶段 2A 的招式库检索与合理性判断；招式库已有或可由现有资料表达的内容不得改从技能库重复取用。
2. 根据能力作用目标提炼且只提炼“单体”“群体”或“buff”，用该范围词检索 skills；不得把特殊法器、身体部位、介质、状态或发动动作加入技能匹配查询。
3. 技能检索只做宽松候选召回，不采用 primary，也不得因路由编号靠前自动选中。展示候选 = 同时把样本推给用户看：候选名称、能力定位、适用边界与效果展示样本必须在同一次回复里一起出现，再让用户选择。
   • 每条技能的展示样本是 00-路由元.json 里的 showcase 字段，指向 技能库/技能展示样本/<编号>-<技能名>.gif，已是 Skill 根目录下的完整相对路径；
   • 技能样本只在技能库自己的展示样本目录 reference/action-storyboard-design/技能库/技能展示样本/ 下查找，不得去招式库的样本目录找，两库目录不得混用；
   • 把该相对路径解析成本机绝对路径；
   • 必须把解析出的 GIF 文件本身推给用户看（用当前环境的文件推送能力，如 present_files），逐个候选、逐个文件推送，让用户直接看到这个技能的画面效果；
   • 只把路径写进正文文字不算展示：文件没有推出去，就等于这一步没做；
   • 用户比较多个候选时逐个带出各自样本，不要只给推荐项；有 N 个候选就推 N 个样本；
   • 该动作与后续流程、任务是否完成无关：不得推迟到成稿阶段、不得等用户追问、不得以「样本只是参考素材」或「本轮只做检索」为由省略；
   • 当前环境确实没有文件推送能力时（如只回显文本、不渲染附件的终端环境），明确写「本环境无法推送文件」并逐条给出样本的绝对路径，不得静默省略、不得默认已展示；
   • 候选没有样本时明确写「暂无展示样本」，不得用别的条目样本顶替，也不得因没有样本而跳过该候选。
4. 选中候选后，必须展示该项 selection_notice 中的：
   • secondary_keywords：特殊法器、身体部位、介质、状态或控制接口；
   • condition_prompt：发动前必须满足的条件；
   • condition_options：可创造条件、可行替代和放弃选项；
   • move_library_exclusions：与招式库的互斥边界。
5. 若二级条件已经满足，才读取技能正文并应用；若未满足，让用户或智能体明确选择：创造合理条件 / 采用允许的替代条件 / 不采纳该技能。不得静默补设关键法器、身体结构、血契、介质或科技装备。
6. 技能只补充“前置 → 发动 → 作用 → 终止”的能力机制。具体起势、身体路径、兵器接触、受力反馈和动作衔接仍从招式库获取或按同等完整度原创。
7. 所有候选条件不兼容时放弃技能库，不为使用资料而修改用户锁定事实。

3. 剧情设计

1. 用用户原文、创作卡和已确认动作方案检索 scripts。
2. 有命中时读取排名第一的案例；只有宽泛题材且前两名确实互补时才读取第二个。
3. 设计前明确告知用户：“将参考《文件名》的结构进行仿写/改编，不复用其专有角色与无关情节。”
4. 只借用可迁移的剧情机制：冲突升级、攻防转折、空间阶段、高潮接口、结尾结构和时长组织。
5. 不复制案例的专有角色、连续句子、独特设定或与用户输入冲突的胜负。
6. 零命中时明确写“示例剧本无关键词命中，剧情将全新设计”。

4. 编译成稿

根据用户要求输出战斗剧情、动作设计或动作分镜。用户未指定格式时，按以下结构交付：

1. 采用依据：已确认方案、场景参考、招式来源、案例参考及原创部分。
2. 剧情设计：目标、冲突、升级、转折、胜负因果和结尾。
3. 角色动作签名：起手、距离、移动、主战、破招、受击与终结。
4. 动作设计：动作目的 → 起势/轨迹 → 对手响应 → 接触/落空/格挡 → 受力反馈 → 位移/状态结果 → 下一动作条件。
5. 空间路线：起点、转向点、终点、环境机制和观察轴。
6. 分镜表：时间段｜叙事目的｜景别与机位｜人物位置｜动作与攻防｜主运镜及终点｜接力状态｜环境反馈。
7. 连续性约束：角色/武器状态稳定、无身体融合、无回合制复位、无随机越轴、视觉效果不遮挡关键接触。

成稿必须满足：开场快速进入有效动作；重要动作有因果与结果；上一段末态成为下一段起点；一打多不排队；终结来自前文破绽；最后一帧仍有主体、摄影机或环境余波运动。

禁止事项

• 生成、改写或适配任何模型或平台的提示词。
• 将提示词包装、模型/平台语法、生成参数、负面词、字幕/声音指令或成片提示语写入资料库。
• 零关键词命中却声称“匹配到资料”。
• 为了利用资料而更改用户指定角色、武器、动作顺序或胜负。
• 未经确认混合多个动作方案的默认协议。
• 只列招式名，不写身体路径、接触、反馈与后续条件。
• 把示例剧本仿写成换名字的复制品，或不告知用户使用了案例参考。
• 跳过招式库优先判断，用技能库顶替招式库已有或可收录的内容。
• 用特殊法器、身体部位、介质或状态等二级条件匹配技能；选中技能后不提示条件就直接采用。
• 引用不存在的资料文件，或根据文件名伪造缺失内容。
• 用其他技能或招式的效果样本来顶替候选自己的展示样本。
• 展示招式候选或技能候选时只写样本路径、不把样本 GIF 文件本身推给用户看，或以「只是参考素材」「本轮只做检索」为由省略样本展示、推迟到成稿阶段再给；环境不具备推送能力时不说明、不给绝对路径就当作已完成。
• 去错库的展示样本目录找样本（招式去技能库找、技能去招式库找），或把两库的展示样本目录当成同一个。
• 读取、拆分、改写或写入用户提供的资料文件（吸收与入库不属于本 Skill）。