FTK SERCET Minimax H3

Minimax H3文生视频、图生视频动作武打提示词生成，将用户的打斗构想通过场景、动作分镜方案、招式库、技能库和示例剧本的多层关键词检索，编译为可靠的战斗剧情、动作链、空间路线与动作分镜；也可将用户提供的一个或多个资料文件按用途吸收到 reference 资料库并维护路由元。用于打斗剧情构思、动作设计、招式设计、条件型技能设计、战斗分镜、资料入库或扩充打斗资料库；不负责提示词生成。

战斗设计、动作分镜与资料吸收

核心约束

• 以用户锁定的人物、关系、武器、能力、动作顺序、胜负、时长、画幅、媒介和结尾为最高优先级。
• 本 Skill 只交付战斗剧情、动作设计、空间调度与动作分镜，不生成任何模型或平台的提示词。
• 提示词包装、模型或平台语法、生成参数、负面词、字幕/声音指令和成片提示语不得写入 reference/；吸收来源包含这些内容时必须先剥离。
• 先路由、后读正文。不得预读所有资料后凭印象强行关联。
• 自动匹配必须至少命中路由元中的一个关键词；零命中即视为无匹配。
• 命中数越多排名越高；同命中数再按强字段权重和路由元裁决规则排序。
• 一次只加载一个主动作/分镜方案。其他方案只作为可选项列出，用户确认前不混读、不拼接协议。
• 参考资料提供机制、结构和质量标准，不覆盖用户锁定事实。
• 不输出内部推理。应清楚说明选用了哪些资料、如何使用，以及哪些部分为全新设计。

路径与工具

资料固定存放在当前 Skill 内，从仓库根目录使用以下路径：

• 场景：.cursor/skills/fight-video-create-skill/reference/scenes/00-路由元.json
• 动作/分镜方案：.cursor/skills/fight-video-create-skill/reference/action-storyboard-design/00-路由元.json
• 招式：.cursor/skills/fight-video-create-skill/reference/action-storyboard-design/招式库/00-路由元.json
• 技能：.cursor/skills/fight-video-create-skill/reference/action-storyboard-design/技能库/00-路由元.json
• 示例剧本：.cursor/skills/fight-video-create-skill/reference/example-scripts/00-路由元.json

执行确定性检索：

bash

python -X utf8 .cursor/skills/fight-video-create-skill/scripts/route_reference.py <scenes|design|moves|skills|scripts> --query "用户原文与提炼关键词"

资料入库或路由变更后执行：

bash

python -X utf8 .cursor/skills/fight-video-create-skill/scripts/validate_routes.py

检索结果中的 eligible 只包含至少命中一个关键词的候选；available 用于展示所有可手动选择的方案，不代表自动匹配成功。技能库例外：只按“单体”或“群体”召回宽松候选，primary 固定为空；selection_notice 中的二级条件只用于选中后的提醒，不参与匹配或排序。

意图路由

先判断任务类型：

1. 用户提供构想并要战斗剧情、动作设计或动作分镜：执行“创作流程”。
2. 用户提供一个或多个文件并要求吸收、学习、入库、更新资料：执行“资料吸收流程”。
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. 对每个候选招式检查：
   • 角色是否掌握或能够合理使用；
   • 武器形制、肢体条件与主战距离是否兼容；
   • 当前姿态能否进入，上一动作末态能否衔接；
   • 场景是否提供所需空间、支点和落点；
   • 在目标时长内能否完成起势、接触、反馈和结果；
   • 是否破坏用户锁定的动作顺序、胜负或写实程度。
4. 合理性高才选用并具体化身体路径、接触点和结果；合理性低则弃用，不为命中资料强改剧情。
5. 全部候选不合理时，按同等生物力学完整度原创招式。
6. 路由或索引提及但磁盘不存在的专项文件只能报告缺失，不得伪造其内容。

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

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

1. 先招式、后技能：先完成阶段 2A 的招式库检索与合理性判断；招式库已有或可通过吸收形成的内容不得改从技能库重复取用。
2. 根据能力作用目标提炼且只提炼“单体”或“群体”，用该范围词检索 skills；不得把特殊法器、身体部位、介质、状态或发动动作加入技能匹配查询。
3. 技能检索只做宽松候选召回，不采用 primary，也不得因路由编号靠前自动选中。向用户或当前智能体展示候选名称、能力定位和适用边界后再选择。
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. 连续性约束：角色/武器状态稳定、无身体融合、无回合制复位、无随机越轴、视觉效果不遮挡关键接触。

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

资料吸收流程

1. 识别与确认用途

逐个读取用户文件，建立清单：文件名、格式、主题、可复用内容、建议目标、重复/冲突风险。按主要用途分类：

• 场景、空间、环境调度 → .cursor/skills/fight-video-create-skill/reference/scenes/
• 动作导演规则、分镜方案、镜头协议 → .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/
• 具体武学、兵器、招式、连招、身法 → .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/招式库/
• 无法转成招式、但具备独立前置、发动、作用与终止机制的能力 → .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/技能库/
• 完整剧情、案例脚本、战斗结构拆解 → .cursor/skills/fight-video-create-skill/reference/example-scripts/

一个文件有多个用途时，优先拆成职责单一的资料；无法无损拆分时询问用户。不得仅因主题相近就覆盖现有文件。

完成识别与分类后，必须先向用户输出确认清单，至少包含：每个文件的拟入库位置、主要用途、可复用内容摘要、重复或冲突风险，以及需要拆分或用户决定的事项。明确写出“以上识别结果和入库用途待确认”；在用户确认、修正或补充前，不得读取目标目录路由元、相近资料或必要索引，也不得执行去重、整合或写入。

2. 去重与整合

用户确认用途后：

1. 先读取目标目录路由元、相近资料和必要索引。
2. 若内容可能属于招式或技能，必须先按招式库入库条件判断：能转成具体武学、兵器技法、身体路径、接触结果或连续动作链的内容进入招式库；只有无法满足这些条件、但具备独立“前置 → 发动 → 作用 → 终止”机制的内容才进入技能库。
3. 将新信息分为：新增事实、已有重复、与现有规则冲突、低可信或不可执行内容。
4. 招式库与技能库互斥：招式库已有或可收录的机制不得在技能库重复建档；已存在技能后来能被完整转换为招式时，迁移到招式库并删除技能侧重复内容。
5. 重复内容不重复入库；新内容合并到职责最接近的文件，独立主题才新建文件。
6. 保留来源说明和用户提供的关键语义；不要把推断伪装成原资料事实。
7. 冲突时保留用户明确指示；未明确时并列记录适用条件，不静默覆盖。

3. 更新路由元

任何新增、删除、改名、拆分、合并或定位变化都同步维护目标目录的 00-路由元.json：

• meta.inventory_count、meta.last_verified；
• routes、inventory；
• 自然、可检索且区分度高的关键词；
• 场景的 retrieval_hint，动作方案的 plot_signatures/avoid_when/conflict_resolution，案例的 script_types/scene_signatures，招式的 technique_signatures/avoid_when，技能的 range_keywords/secondary_keywords/condition_prompt/condition_options/ability_signatures/move_library_exclusions/avoid_when。

关键词必须来自用户可能输入的自然表达。宽泛词不能单独造成误路由。新增目标至少有一个关键词，且文件必须真实存在。技能库是唯一例外：range_keywords 只能是“单体”或“群体”，并允许宽松召回；secondary_keywords 及其他条件字段绝不参与检索。

4. 动作方案的特殊同步

只要吸收内容涉及 .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/ 或会改变动作、剧情、分镜的通用规则：

1. 更新对应专项方案或新增方案；
2. 同步更新 .cursor/skills/fight-video-create-skill/reference/action-storyboard-design/互补融合大杂烩版本.md；
3. 只把可跨题材复用、与现有系统互补的规则提炼进综合版，不粘贴整份原文；
4. 保持综合版“稳定连续、动作因果、空间路线、武学选招、镜头接力、视觉反馈、质量门禁”的职责结构；
5. 若改动 frontmatter 中的内容定位，按项目规则递增 version。

招式资料变更还要同步 招式库/00-招式库索引.md；技能资料变更还要同步 技能库/00-技能库索引.md，并重新检查与招式库的互斥关系。若分类文件仍声明来自 武打skill.md，必须同步源文件或明确改写来源，禁止索引与实际来源失真。

5. 验证与汇报

1. 运行路由校验器，修复全部错误后再交付。
2. 用每个新增路由的 1 个强关键词执行检索烟测，确认可命中正确目标。
3. 汇报：吸收了什么、存放位置、去掉了哪些重复、如何处理冲突、更新了哪些路由、综合版更新点、校验结果。

禁止事项

• 生成、改写或适配任何模型或平台的提示词。
• 将提示词包装、模型/平台语法、生成参数、负面词、字幕/声音指令或成片提示语写入资料库。
• 零关键词命中却声称“匹配到资料”。
• 为了利用资料而更改用户指定角色、武器、动作顺序或胜负。
• 未经确认混合多个动作方案的默认协议。
• 只列招式名，不写身体路径、接触、反馈与后续条件。
• 把示例剧本仿写成换名字的复制品，或不告知用户使用了案例参考。
• 入库后不更新路由元、库存数量、索引或综合版。
• 将招式库已有或可收录的内容重复写入技能库，或跳过招式库优先判断。
• 用特殊法器、身体部位、介质或状态等二级条件匹配技能；选中技能后不提示条件就直接采用。
• 引用不存在的资料文件，或根据文件名伪造缺失内容。