如果你最近在用 AI 生成视频大概率会遇到一个让人有点沮丧的现象换了更强的模型、写了更长的提示词成片的画面依然像“PPT 加了一点动效”。问题往往不在模型而在运镜。运镜是电影语言里最基础也最容易被忽略的部分。一个镜头是推是拉、是快是慢、是跟随还是环绕直接决定了观众看到这段画面时的情绪。很多 AI 视频生成教程都在讲“怎么写提示词”但很少讲“怎么像导演一样思考镜头”。我花了 95 分钟专门看了一门 AI 电影运镜的课程然后没有把笔记留在备忘录里而是一个 Skill 的目录结构、规则文件和脚本代码把它们全部固化了下来。这篇文章会把整个过程拆开讲运镜知识如何提炼、Skill 是什么、它和 MCP 有什么区别、目录怎么建、规则怎么写、脚本怎么跑、踩了哪些坑。如果你正在用 Claude Code、Codex、Cursor 这类工具又对 AI 视频生成感兴趣这篇文章应该能帮你少走不少弯路。1. 这篇文章真正要解决的问题先说一个判断大部分 AI 视频作品看起来“很 AI”不是因为你提示词写得少而是因为你没有镜头意识。模型其实能理解“推近镜头”“环绕拍摄”“跟拍”这类描述但绝大多数用户根本不会在提示词里精确表达这些信息。大家习惯写的是“一个女孩在街道上走路电影感4K超清”这种提示词生成出来的画面往往只有一个静止的全身镜头或者毫无逻辑地乱晃。问题不在模型而在用户没有把“运镜”这个维度纳入思考。我这次做 Skill 的动机就是解决两个问题。第一个问题学了知识但下次上课时还是不会用。电影运镜的知识点其实并不多镜头类型、运动方向、速度节奏、镜头组合翻来覆去就那些东西。但人脑的记忆不可靠尤其是当你一周后才开始真正做视频时你几乎想不起来“环绕镜头应该配什么速度”“情绪压抑的段落适合什么运镜”。第二个问题AI 编程工具越来越强但大部分人的用法还停留在“问答”。Claude Code、Codex、Cursor 这类工具确实能写代码但它们更擅长的是把一套专家知识固化成可以重复调用的能力。既然运镜知识可以被结构化为什么不直接做成一个 Skill让 AI 在生成视频提示词时自动按电影语言的规则来所以这篇文章真正想讲的不只是一个 AI 视频运镜 Skill 的实现细节而是一套更通用的方法如何把一门课程、一本书、一份文档里的非结构化知识提炼成 AI 能执行的结构化规则如何设计 Skill 的目录和文件让它能被 Claude Code、Codex 这类工具正确识别如何写“规则 参数 示例”三层结构让模型既能理解又能按格式输出如何验证一个 Skill 真的有效而不是看起来有效读者画像也很明确正在折腾 AI 编程工具、想拓展 Agent 能力边界的开发者以及用 AI 做视频、但被提示词卡住的创作者。这两类人看起来方向不同但交集正是“Skill”。2. 运镜、Skill、MCP先把几个容易混淆的概念讲清楚2.1 运镜到底指什么运镜全称是“运动镜头”指摄影机在拍摄过程中发生的运动。电影语言里最基础的运镜方式其实很有限常见的大致是这几类推镜头Push In摄影机向被摄主体靠近视觉上会强化注意力常用于揭示情绪或强调细节。拉镜头Pull Out摄影机向后远离被摄主体常用于交代环境、制造疏离感。摇镜头Pan摄影机位置不动水平或垂直转动模拟人转动头部观察环境。移镜头Dolly摄影机整体横向移动画面呈现出“滑行”的视觉感受。跟镜头Tracking摄影机跟随运动主体移动让观众始终与主体保持相对位置。升降镜头Pedestal / Crane摄影机在垂直方向上升或下降常用于改变视角、呈现空间关系。环绕镜头Orbit摄影机围绕主体旋转视觉冲击力强适合展示主体与环境的关系。手持镜头Handheld画面带有轻微晃动增加真实感和紧张感。学运镜学的不是背下这些名词而是知道“什么情境下用哪一种”。比如表现角色内心动摇可以用缓慢的手持或小幅度的推近表现场景的宏大先拉后升的镜头组合会更有说服力。这些知识看起来简单但真正写提示词时很少有人会主动运用。2.2 Skill 是什么在 Claude Code、Codex 这类工具里Skill 是一种把专业知识与操作流程封装起来的文件集合。一个 Skill 通常包含一个SKILL.md主文件里面写清楚“这个技能是做什么的、什么时候调用、遵循什么规则”还可以附带脚本、模板、参考文档等资源文件。Skill 的核心价值是让模型在处理特定任务时不再依赖用户临时把一整套规则塞进上下文而是通过一个清晰的入口加载已经整理好的知识与流程。以我做的运镜 Skill 为例只要模型检测到用户需要生成 AI 视频运镜提示词它就会主动读取 Skill 中的镜头类型表、速度参数说明、提示词模板然后按照既定规则输出结果。用户不需要在每次对话时把“推镜头是什么、环绕镜头怎么描述”再讲一遍。2.3 Skill 和 MCP 的区别很容易被搞混现在很多人一提到 Agent 工具就说 MCP容易把 Skill 和 MCP 放在一起比较。这里有必要做一个区分。MCPModel Context Protocol解决的是“Agent 如何调用外部工具与数据”的问题。它相当于给模型开放了一组可执行的接口比如读取本地文件、调用某个 API、查询数据库。MCP 是一种运行时能力和系统集成。Skill 解决的是“模型如何在特定领域把事情做对”的问题。它不调用外部系统而是在提示词层面对模型进行知识注入与行为约束。Skill 更像是一本随身携带的“专家操作手册”它本身不产生新的工具能力而是让已有的能力在特定场景下表现更专业。表格对比更清楚对比维度SkillMCP解决的核心问题让模型按特定领域规则完成任务让模型获得外部工具与数据访问能力运行方式通过文件加载知识在提示词层生效通过协议连接外部服务在运行时生效是否需要独立进程不需要通常只是文件与脚本通常需要独立服务或进程典型场景代码规范、运镜提示词、文案风格查数据库、发请求、操作文件对模型的改变改变回答的规则和风格改变模型的能力边界理解这个区别很重要否则你可能会在搭建过程中用错了方向本来应该整理知识结果去搭了一个不必要的 MCP 服务。3. 为什么把运镜知识做成 Skill而不是写进 Prompt这是一个值得先想清楚的问题。你完全可以把运镜知识写进一长段 Prompt然后在每次生成视频提示词时复制粘贴。但这么做的体验非常差。第一提示词越长模型越容易丢失关键信息尤其是放在很靠后的规则模型可能会忽略。第二你不可能每次都在聊天窗口里粘贴一段几千字的规则。第三运镜知识是迭代增长的每学到新内容都要手工修改 Prompt容易出错。Skill 的价值在于“知识封装”和“按需加载”。封装意味着你把运镜的镜头类型、速度参数、提示词模板、示例都整理成一个结构化的文件集而不是一段杂乱无章的 Prompt。按需加载意味着模型只有在判断当前任务和运镜相关时才读取这些规则平时不会占用上下文空间。这和“把所有话都塞进 Prompt”是本质不同的思路。另外还有一个很现实的原因AI 工具现在的技能系统越来越成熟Claude Code 的 Skills、Codex 的类似机制、Cursor 的规则配置都是同一个方向。你可以把同样的 SKILL.md 结构迁移到不同工具里不需要重新发明轮子。从材料看现在业界对这个方向关注度也很高。Skill 相关的话题在开发者社区讨论量上涨明显它已经不只是 Anthropic 的一个实验性功能而是 Agent 工作流里的标准组成部分。如果你还在用“一个大 Prompt 打天下”的方式那说明你的工作方式还停留在上一个阶段。所以我的结论是运镜这类“有明确规则、需反复使用、内容会持续迭代”的知识天然适合做成 Skill。这不是炫技而是效率选择。4. 我的 Skill 目录结构一个最简但完整的骨架在动手写规则之前我先确定 Skill 的目录结构。以 Claude Code 为例一个 Skill 通常放在~/.claude/skills/skill-name/下其中至少要包含一个SKILL.md文件。我这个运镜 Skill 的目录结构如下~/.claude/skills/cinematic-camera/ ├── SKILL.md ├── assets/ │ ├── camera_library.json │ └── prompt_template.md └── scripts/ └── build_camera_prompt.py目录结构本身不复杂关键是每个文件职责要清晰SKILL.mdSkill 的入口文件包含 frontmatter元信息和正文规则。assets/camera_library.json镜头知识库按“镜头类型、方向、幅度、速度、适用场景”组织。assets/prompt_template.md输出提示词的模板让模型生成结果时保持统一结构。scripts/build_camera_prompt.py一个辅助脚本传入镜头参数生成标准化的英文提示词片段。为什么这样分因为纯文本的SKILL.md适合描述规则但镜头参数如果全写在 Markdown 里模型查找效率会很低。拆分到 JSON 里可以让模型在需要时精准读取某个镜头类型的数据而不是面对一大段文字。脚本的作用则是把“参数”变成“可复制的提示词”这属于工程化处理。实际使用中模型不一定非要执行这个 Python 脚本。它更像是一个离线工具用来在调试时生成标准输出也可以被模型在支持执行命令的工具里调用。这种做法会帮助你验证规则是否合理。5. 从 95 分钟课程到结构化规则知识提炼的完整过程这是整篇文章里我认为最有价值的一段。因为绝大多数人学完课程得到的是一堆零零散散的概念而不是一套可以交给 AI 执行的知识结构。5.1 课程里最重要的不是“名词”而是“决策规则”95 分钟的课程如果只是按时间记录笔记最后只会得到“推镜头是什么、拉镜头是什么”这种字典式内容。但这些东西对生成 AI 视频提示词没有直接帮助因为生成视频时你要做的是“当前画面我应该选什么运镜”而不是“推镜头的定义”。所以我在提炼时给自己定了两个问题这个知识点能帮我做出什么决策这个决策需要哪些参数来描述比如课程里讲“特写镜头配合缓慢推近可以表现角色内心情绪”我提炼出来的就不是“特写镜头的定义”而是一条决策规则当目标是表现角色情绪变化时推荐使用“特写 缓慢推近”推近幅度控制在 20%-30%速度等级为 low。这样提炼之后知识就变成了一条可以直接执行的规则而不是一个需要我再思考的概念。5.2 运镜知识可以归纳成 5 个维度为了不让规则变成一堆碎片我把课程里的内容归并成 5 个维度这也是后续 JSON 知识库的字段来源镜头类型Shot Type特写、中景、全景、远景等。运动方式Movement Type推、拉、摇、移、跟、升降、环绕、手持。方向与幅度Direction Intensity前进、后退、左右横移、上升、下降、旋转角度或推进百分比。速度与节奏Speed Rhythm极慢、慢、中、快、极快以及匀速/变速。情绪与叙事目的Emotion Narrative Intent表达紧张、舒缓、孤独、宏大、悬疑等。前 4 个是“物理参数”AI 视频模型能直接理解。第 5 个是“决策依据”帮助模型在用户描述需求时选择合适的参数组合。5.3 规则的表达方式越是确定性的规则越容易被模型遵守我在写SKILL.md时有一个明显的体会模型对“如果……那么……”这种确定性规则的遵守程度远高于“你可以考虑……”“酌情使用……”这种模糊表述。比如这条规则如果用户描述的情绪是“紧张、不安”运镜应优先选择手持镜头或小幅快速推近避免使用缓慢的升降镜头。这比“表达紧张情绪时可以采用手持镜头”有效得多。前者给了模型明确的选择范围和排除项后者则更像一个建议模型可能在多种镜头里随便选一个。5.4 用示例强化规则SKILL.md里我每个大规则后面都跟了 1 到 2 个完整的输入输出示例而不是只写抽象规则。原因很简单模型在上下文里对“示例”的学习效率远高于“规则描述”。你给它看一个从用户输入到提示词输出的完整样例它就能模仿这个格式处理新输入。这个技巧在写任何 Skill 时都适用。规则负责约束示例负责示范两者缺一不可。6. 完整示例运镜 Skill 的代码实现下面是我这个运镜 Skill 的核心文件内容。你可以直接拷贝按自己的需求修改。6.1 入口文件SKILL.md--- name: cinematic-camera description: 生成 AI 视频的运镜提示词。当用户需要编写视频生成提示词、描述镜头运动、设计镜头语言时使用。 --- # Cinematic Camera Skill 你是一位熟悉电影镜头语言的 AI 视频提示词工程师。你的任务是根据用户的画面描述输出包含明确运镜信息的视频生成提示词。 ## 使用前提 - 只处理与视频生成、运镜、镜头语言相关的任务。 - 如果用户只想要静图不要使用本技能的运动描述。 ## 输出规则 1. 必须先解析用户的画面需求提取主体、场景、情绪、时长。 2. 根据情绪和叙事目的选择合适的镜头类型与运动方式。 3. 每个镜头必须包含镜头类型、运动方式、运动方向、推拉幅度或旋转角度、速度等级。 4. 输出分为两段第一段为视觉画面描述第二段为镜头运动描述。 5. 镜头运动描述必须使用下面列出的标准词汇不要自造词汇。 ## 镜头运动标准词汇 | 分类 | 可用词汇 | | --- | --- | | 运动方式 | push in, pull out, pan left, pan right, tilt up, tilt down, dolly left, dolly right, tracking, crane up, crane down, orbit around subject, handheld | | 运动方向 | toward subject, away from subject, left to right, right to left, upward, downward, clockwise, counterclockwise | | 推拉幅度 | 10%, 20%, 30%, 40%, 50% | | 速度等级 | extremely slow, slow, medium, fast, extremely fast | ## 情绪与运镜对照规则 - 紧张、不安优先 handheld或小幅快速 push in避免升降镜头。 - 舒缓、宁静优先 slow tracking或极缓慢的 pull out速度用 slow。 - 宏大、开阔优先 crane up结合 slow pull out速度用 medium。 - 孤独、疏离优先 long shot slow dolly left或极缓慢的 orbit速度用 slow。 - 悬疑、未知优先 medium push in幅度 20%-30%速度用 slow。 ## 提示词模板 用户输入主体、场景、情绪 输出模板 Visual: {subject}, {scene}, {shot type}, {lighting or mood} Camera: {movement type}, {direction}, {intensity}, {speed} ## 示例 用户输入一个女孩独自站在雨夜的街道上情绪孤独。 输出 Visual: a lonely girl standing on a rainy street at night, long shot, cold blue lighting, melancholic atmosphere Camera: slow dolly left, left to right, 30% lateral movement, extremely slow speed 用户输入主角在考场等待成绩非常紧张。 输出 Visual: a student waiting for exam results in a classroom, close-up, shallow depth of field, tense atmosphere Camera: handheld, subtle movement, toward subject, slow speed这个SKILL.md是核心它告诉模型三件事什么时候用、按什么规则选镜头、输出成什么格式。6.2 镜头知识库camera_library.jsonSKILL.md里放的是最常用的规则而更完整的镜头知识库放在 JSON 里方便模型按需查询。{ shot_types: { extreme_close_up: { desc: 极特写只展示眼睛或局部细节, scene: 情绪爆发、关键细节 }, close_up: { desc: 特写展示面部表情, scene: 情绪表达、对话关键点 }, medium_shot: { desc: 中景展示人物腰部以上, scene: 日常对话、动作交代 }, full_shot: { desc: 全景展示整个人物, scene: 动作展示、角色出场 }, long_shot: { desc: 远景人物在环境中很小, scene: 交代环境、制造孤独感 }, extreme_long_shot: { desc: 极远景环境为主, scene: 宏大场面、空间关系 } }, movement_types: { push_in: { desc: 推镜头靠近主体, intensity: 10%-40%, typical_speed: slow to medium }, pull_out: { desc: 拉镜头远离主体, intensity: 20%-50%, typical_speed: slow to medium }, pan_left: { desc: 水平向左摇, intensity: swing angle 10-90 degrees, typical_speed: medium }, pan_right: { desc: 水平向右摇, intensity: swing angle 10-90 degrees, typical_speed: medium }, tilt_up: { desc: 垂直向上摇, intensity: 10-90 degrees, typical_speed: slow to medium }, tilt_down: { desc: 垂直向下摇, intensity: 10-90 degrees, typical_speed: slow to medium }, dolly_left: { desc: 向左横移, intensity: 20%-50%, typical_speed: slow to medium }, dolly_right: { desc: 向右横移, intensity: 20%-50%, typical_speed: slow to medium }, tracking: { desc: 跟随主体移动, intensity: follow distance 20%-60%, typical_speed: medium to fast }, crane_up: { desc: 升降机上升, intensity: height 20%-100%, typical_speed: slow to medium }, crane_down: { desc: 升降机下降, intensity: height 20%-100%, typical_speed: slow to medium }, orbit: { desc: 环绕主体旋转, intensity: angle 90-360 degrees, typical_speed: medium }, handheld: { desc: 手持镜头画面微晃, intensity: subtle to strong shake, typical_speed: fast } } }这个 JSON 文件并不是让模型死记硬背的而是在模型需要具体参数时提供参考。比如用户说“我想要一个环绕镜头”模型就可以查orbit这个条目知道它适合什么场景、角度范围、速度等级。6.3 辅助脚本build_camera_prompt.py脚本不是必须的但它能帮你快速测试规则也能在支持执行脚本的 Agent 环境中做格式化输出。#!/usr/bin/env python3 文件路径scripts/build_camera_prompt.py 用途根据镜头参数生成标准化的 AI 视频运镜提示词 用法python3 build_camera_prompt.py --subject a girl on rainy street --scene night city --shot long_shot --movement dolly_left --speed slow import argparse import json def load_library(pathassets/camera_library.json): with open(path, r, encodingutf-8) as f: return json.load(f) def build_prompt(lib, args): shot_desc lib[shot_types].get(args.shot, {}).get(desc, args.shot) movement_desc lib[movement_types].get(args.movement, {}).get(desc, args.movement) intensity lib[movement_types].get(args.movement, {}).get(intensity, default) movement_mapping { push_in: push in, pull_out: pull out, pan_left: pan left, pan_right: pan right, tilt_up: tilt up, tilt_down: tilt down, dolly_left: dolly left, dolly_right: dolly right, tracking: tracking, crane_up: crane up, crane_down: crane down, orbit: orbit around subject, handheld: handheld, } movement_en movement_mapping.get(args.movement, args.movement) visual ( fVisual: {args.subject}, {args.scene}, {args.shot.replace(_, )}, fshot_type_desc{shot_desc}, movement_desc{movement_desc} ) camera ( fCamera: {movement_en}, {args.direction}, fintensity {intensity}, {args.speed} speed ) return visual \n camera def main(): parser argparse.ArgumentParser(descriptionBuild camera prompt for AI video.) parser.add_argument(--subject, requiredTrue, helpMain subject of the scene) parser.add_argument(--scene, requiredTrue, helpScene or background) parser.add_argument(--shot, defaultmedium_shot, helpShot type key in camera_library.json) parser.add_argument(--movement, defaultdolly_left, helpMovement type key) parser.add_argument(--direction, defaultleft to right, helpMovement direction) parser.add_argument(--speed, defaultmedium, helpextremely slow / slow / medium / fast / extremely fast) args parser.parse_args() lib load_library() prompt build_prompt(lib, args) print(prompt) if __name__ __main__: main()这个脚本把“参数化运镜描述”这件事变成了一条可复用的命令。你不需要每次打开记事本手工拼提示词直接传参就能得到标准输出。6.4 安装到 Claude Code / Codex目录文件准备好之后安装就很简单了。以 Claude Code 为例# 创建 Skill 目录 mkdir -p ~/.claude/skills/cinematic-camera/assets mkdir -p ~/.claude/skills/cinematic-camera/scripts # 拷贝文件假设你已经写好上面三个文件 cp SKILL.md ~/.claude/skills/cinematic-camera/ cp assets/camera_library.json ~/.claude/skills/cinematic-camera/assets/ cp assets/prompt_template.md ~/.claude/skills/cinematic-camera/assets/ cp scripts/build_camera_prompt.py ~/.claude/skills/cinematic-camera/scripts/如果你用的是 Codex目录路径通常是~/.codex/skills/或者项目目录下的.codex/skills/。不同工具的默认路径可能不同以官方文档为准。关键是保持目录结构一致。安装完成后重新打开工具然后在对话中描述一个视频画面需求模型就应当自动调用这个 Skill。7. 运行结果与效果验证Skill 写完之后不能直接宣布“完成”必须验证。我的验证方法是分三层进行的。7.1 第一层脚本输出验证先用脚本直接生成一个提示词看看格式是否符合预期python3 build_camera_prompt.py \ --subject a lonely girl on a rainy street \ --scene night city, neon lights \ --shot long_shot \ --movement dolly_left \ --direction left to right \ --speed slow预期输出类似Visual: a lonely girl on a rainy street, night city, neon lights, long shot, shot_type_desc远景人物在环境中很小, movement_desc向左横移 Camera: dolly left, left to right, intensity 20%-50%, slow speed如果脚本报错优先检查assets/camera_library.json的路径是否写对了或者 JSON 格式是否合法。这一步能确认代码层面没问题。7.2 第二层模型遵循度验证打开 Claude Code输入一段需求 “一个男人在办公室看着窗外心情很压抑帮我生成视频提示词。”判断标准有三条模型有没有在输出中体现运镜设计而不是只给画面描述。选择的镜头类型和运动方式是否符合“压抑”情绪对应的规则比如缓慢拉远、或失焦的移镜。输出格式是否贴近模板包含 Visual 和 Camera 两段。如果模型只是给了一段“男人 办公室 窗外”的静态画面描述说明 Skill 没有被正确加载或者description写得太窄模型没判断出要调用它。7.3 第三层真实视频生成平台效果验证Skill 输出的是提示词真正生成视频还要拿到 Runway、Pika、可灵、即梦这类平台里去跑。我建议你在测试时固定一个对比组用同一个画面描述分别用“普通提示词”和“运镜 Skill 提示词”各生成一条视频然后对比两者在镜头运动上的差异。判断一个运镜提示词有没有生效主要看三点画面里是否出现了你指定的镜头运动推近、横移、环绕等。运动速度是否符合预期缓慢推近和快速推近的观感完全不同。运镜是否服务了情绪表达压抑场景下急促的推近会显得很奇怪。如果生成的视频里镜头完全没动或者运动方向和你描述的不一致多半是提示词里的镜头词汇和视频模型内部理解不匹配。这时候需要参考目标视频平台的提示词规范调整标准词汇。8. 常见问题与排查方法在搭建和使用 Skill 的过程中有不少细节容易出错。我直接把典型问题整理成下面这张排查表。问题现象可能原因排查方式解决方案模型完全没有调用 SkillSkill 目录放错位置或 frontmatter 的 description 太窄检查 Skill 目录是否在~/.claude/skills/下检查 description 是否覆盖运镜场景调整目录位置把 description 改得更通用且明确提到“生成视频提示词”模型加载了 Skill 但输出不符合格式SKILL.md 中的输出规则不明确查看模型输出是否包含 Visual / Camera 段落在 SKILL.md 中增加严格模板和示例删掉模糊表述运镜词汇被视频模型忽略使用的词汇与视频平台不兼容在目标平台测试单独镜头词汇参考平台官方提示词文档统一标准词汇镜头运动速度不符合预期速度等级描述太笼统对比同一主体在不同速度词下的生成结果给出具体的速度描述词如“slow push in over 5 seconds”模型在普通对话中也输出运镜信息description 写得太宽泛触发范围过大检查模型是否在纯文本任务中误用 Skill收窄 description 范围明确只处理视频/运镜任务Python 脚本运行报错assets 路径写错或 JSON 格式错误运行python3 -m json.tool assets/camera_library.json检查 JSON修正路径或修复 JSON 格式另外还有一个常见认知误区很多人在 Skill 里写了一大堆“电影理论”但完全没有和实际视频生成平台对齐。运镜 Skill 最终产出的是给视频模型用的提示词不是一篇影评。理论再深如果视频模型不能理解push in和dolly的区别效果依然会打折扣。所以写 Skill 之前最好先了解你目标视频平台支持哪些镜头运动词汇。9. 最佳实践与工程建议9.1 把“知识”当代码来管理做 Skill 最忌讳的是把文档当成一次性笔记。它的维护节奏应该和代码项目一样版本化、可回溯、可迭代。我建议你把 Skill 目录纳入 Git 管理每次修改规则都要提交一次并写上清晰的 commit message比如“增加手持镜头在紧张场景下的使用规则”。这样当视频效果变差时你可以很快定位是哪次规则调整导致的。9.2 规则粒度要适中不是越细越好如果规则写得太细把几十种镜头组合全部塞进去模型在大量约束下反而容易“不知道该听哪条”。我在实践中发现每个维度的规则控制在 5 到 10 条左右比较合适再加上示例模型就能稳定输出。别追求“百科全书式”的 Skill它不是知识库它是决策助手。9.3 用示例驱动规则迭代而不是用理论驱动当你发现模型输出不理想时第一反应该是补充一个“错误输入 - 正确输出”的对比示例而不是在规则部分增加更多文字描述。一个高质量的示例往往胜过十行抽象规则。模型学习示例的模式匹配能力比你想象的强得多。9.4 为不同视频平台准备词汇映射Runway、Pika、可灵、即梦对镜头运动的支持程度不同。与其写一个通用 Skill 然后寄希望于所有平台都能理解不如在 Skill 中加一个小的平台词汇映射表。比如某个平台不支持orbit你可以映射成“缓慢环绕拍摄”或者提示模型用pan 360替代。这个思路可以在SKILL.md里加一个“平台兼容性”章节处理。9.5 边界与安全提醒运镜 Skill 本身只是生成提示词不会绕过任何平台的合规限制。使用 AI 视频生成时要注意遵守各平台的内容政策不要生成违法违规内容。另外如果你在团队里共享这个 Skill建议把SKILL.md里的规则写成中性、专业的技术描述避免夹带个人主观偏好这样团队其他人也更容易理解和维护。10. 总结与后续学习方向回头看这 95 分钟课程学到的不只是“推拉摇移”这些镜头名词而是一种把感性经验转化为工程规则的方式。真正让我觉得有收获的不是做出来了这个运镜 Skill而是发现了一种可以复用的工作流学一个领域、提炼决策规则、设计提示词模板、封装成 Skill、在实际工具里反复验证。如果你也想做一个自己的 Skill可以从这几个方向入手从你最近在学的一门课开始把课堂知识拆成“决策规则 参数 示例”的结构。先不要贪多挑一个你最常用的场景做一个最小可用的 Skill。把 Skill 放到 Claude Code 或 Codex 里实际使用一周按真实反馈迭代规则。AI 视频运镜只是一个起点。同样的思路也可以用来做代码审查规则、SQL 优化建议、文案风格控制、数据库设计规范。把知识做成 Skill本质上是把你的个人经验沉淀成一件可以被 AI 复用、被团队复用、被未来自己复用的数字资产。只要这个思维转变了你学任何新知识都会比别人多一层收获。
AI视频生成总像PPT？用Skill固化运镜知识，像导演一样思考镜头
如果你最近在用 AI 生成视频大概率会遇到一个让人有点沮丧的现象换了更强的模型、写了更长的提示词成片的画面依然像“PPT 加了一点动效”。问题往往不在模型而在运镜。运镜是电影语言里最基础也最容易被忽略的部分。一个镜头是推是拉、是快是慢、是跟随还是环绕直接决定了观众看到这段画面时的情绪。很多 AI 视频生成教程都在讲“怎么写提示词”但很少讲“怎么像导演一样思考镜头”。我花了 95 分钟专门看了一门 AI 电影运镜的课程然后没有把笔记留在备忘录里而是一个 Skill 的目录结构、规则文件和脚本代码把它们全部固化了下来。这篇文章会把整个过程拆开讲运镜知识如何提炼、Skill 是什么、它和 MCP 有什么区别、目录怎么建、规则怎么写、脚本怎么跑、踩了哪些坑。如果你正在用 Claude Code、Codex、Cursor 这类工具又对 AI 视频生成感兴趣这篇文章应该能帮你少走不少弯路。1. 这篇文章真正要解决的问题先说一个判断大部分 AI 视频作品看起来“很 AI”不是因为你提示词写得少而是因为你没有镜头意识。模型其实能理解“推近镜头”“环绕拍摄”“跟拍”这类描述但绝大多数用户根本不会在提示词里精确表达这些信息。大家习惯写的是“一个女孩在街道上走路电影感4K超清”这种提示词生成出来的画面往往只有一个静止的全身镜头或者毫无逻辑地乱晃。问题不在模型而在用户没有把“运镜”这个维度纳入思考。我这次做 Skill 的动机就是解决两个问题。第一个问题学了知识但下次上课时还是不会用。电影运镜的知识点其实并不多镜头类型、运动方向、速度节奏、镜头组合翻来覆去就那些东西。但人脑的记忆不可靠尤其是当你一周后才开始真正做视频时你几乎想不起来“环绕镜头应该配什么速度”“情绪压抑的段落适合什么运镜”。第二个问题AI 编程工具越来越强但大部分人的用法还停留在“问答”。Claude Code、Codex、Cursor 这类工具确实能写代码但它们更擅长的是把一套专家知识固化成可以重复调用的能力。既然运镜知识可以被结构化为什么不直接做成一个 Skill让 AI 在生成视频提示词时自动按电影语言的规则来所以这篇文章真正想讲的不只是一个 AI 视频运镜 Skill 的实现细节而是一套更通用的方法如何把一门课程、一本书、一份文档里的非结构化知识提炼成 AI 能执行的结构化规则如何设计 Skill 的目录和文件让它能被 Claude Code、Codex 这类工具正确识别如何写“规则 参数 示例”三层结构让模型既能理解又能按格式输出如何验证一个 Skill 真的有效而不是看起来有效读者画像也很明确正在折腾 AI 编程工具、想拓展 Agent 能力边界的开发者以及用 AI 做视频、但被提示词卡住的创作者。这两类人看起来方向不同但交集正是“Skill”。2. 运镜、Skill、MCP先把几个容易混淆的概念讲清楚2.1 运镜到底指什么运镜全称是“运动镜头”指摄影机在拍摄过程中发生的运动。电影语言里最基础的运镜方式其实很有限常见的大致是这几类推镜头Push In摄影机向被摄主体靠近视觉上会强化注意力常用于揭示情绪或强调细节。拉镜头Pull Out摄影机向后远离被摄主体常用于交代环境、制造疏离感。摇镜头Pan摄影机位置不动水平或垂直转动模拟人转动头部观察环境。移镜头Dolly摄影机整体横向移动画面呈现出“滑行”的视觉感受。跟镜头Tracking摄影机跟随运动主体移动让观众始终与主体保持相对位置。升降镜头Pedestal / Crane摄影机在垂直方向上升或下降常用于改变视角、呈现空间关系。环绕镜头Orbit摄影机围绕主体旋转视觉冲击力强适合展示主体与环境的关系。手持镜头Handheld画面带有轻微晃动增加真实感和紧张感。学运镜学的不是背下这些名词而是知道“什么情境下用哪一种”。比如表现角色内心动摇可以用缓慢的手持或小幅度的推近表现场景的宏大先拉后升的镜头组合会更有说服力。这些知识看起来简单但真正写提示词时很少有人会主动运用。2.2 Skill 是什么在 Claude Code、Codex 这类工具里Skill 是一种把专业知识与操作流程封装起来的文件集合。一个 Skill 通常包含一个SKILL.md主文件里面写清楚“这个技能是做什么的、什么时候调用、遵循什么规则”还可以附带脚本、模板、参考文档等资源文件。Skill 的核心价值是让模型在处理特定任务时不再依赖用户临时把一整套规则塞进上下文而是通过一个清晰的入口加载已经整理好的知识与流程。以我做的运镜 Skill 为例只要模型检测到用户需要生成 AI 视频运镜提示词它就会主动读取 Skill 中的镜头类型表、速度参数说明、提示词模板然后按照既定规则输出结果。用户不需要在每次对话时把“推镜头是什么、环绕镜头怎么描述”再讲一遍。2.3 Skill 和 MCP 的区别很容易被搞混现在很多人一提到 Agent 工具就说 MCP容易把 Skill 和 MCP 放在一起比较。这里有必要做一个区分。MCPModel Context Protocol解决的是“Agent 如何调用外部工具与数据”的问题。它相当于给模型开放了一组可执行的接口比如读取本地文件、调用某个 API、查询数据库。MCP 是一种运行时能力和系统集成。Skill 解决的是“模型如何在特定领域把事情做对”的问题。它不调用外部系统而是在提示词层面对模型进行知识注入与行为约束。Skill 更像是一本随身携带的“专家操作手册”它本身不产生新的工具能力而是让已有的能力在特定场景下表现更专业。表格对比更清楚对比维度SkillMCP解决的核心问题让模型按特定领域规则完成任务让模型获得外部工具与数据访问能力运行方式通过文件加载知识在提示词层生效通过协议连接外部服务在运行时生效是否需要独立进程不需要通常只是文件与脚本通常需要独立服务或进程典型场景代码规范、运镜提示词、文案风格查数据库、发请求、操作文件对模型的改变改变回答的规则和风格改变模型的能力边界理解这个区别很重要否则你可能会在搭建过程中用错了方向本来应该整理知识结果去搭了一个不必要的 MCP 服务。3. 为什么把运镜知识做成 Skill而不是写进 Prompt这是一个值得先想清楚的问题。你完全可以把运镜知识写进一长段 Prompt然后在每次生成视频提示词时复制粘贴。但这么做的体验非常差。第一提示词越长模型越容易丢失关键信息尤其是放在很靠后的规则模型可能会忽略。第二你不可能每次都在聊天窗口里粘贴一段几千字的规则。第三运镜知识是迭代增长的每学到新内容都要手工修改 Prompt容易出错。Skill 的价值在于“知识封装”和“按需加载”。封装意味着你把运镜的镜头类型、速度参数、提示词模板、示例都整理成一个结构化的文件集而不是一段杂乱无章的 Prompt。按需加载意味着模型只有在判断当前任务和运镜相关时才读取这些规则平时不会占用上下文空间。这和“把所有话都塞进 Prompt”是本质不同的思路。另外还有一个很现实的原因AI 工具现在的技能系统越来越成熟Claude Code 的 Skills、Codex 的类似机制、Cursor 的规则配置都是同一个方向。你可以把同样的 SKILL.md 结构迁移到不同工具里不需要重新发明轮子。从材料看现在业界对这个方向关注度也很高。Skill 相关的话题在开发者社区讨论量上涨明显它已经不只是 Anthropic 的一个实验性功能而是 Agent 工作流里的标准组成部分。如果你还在用“一个大 Prompt 打天下”的方式那说明你的工作方式还停留在上一个阶段。所以我的结论是运镜这类“有明确规则、需反复使用、内容会持续迭代”的知识天然适合做成 Skill。这不是炫技而是效率选择。4. 我的 Skill 目录结构一个最简但完整的骨架在动手写规则之前我先确定 Skill 的目录结构。以 Claude Code 为例一个 Skill 通常放在~/.claude/skills/skill-name/下其中至少要包含一个SKILL.md文件。我这个运镜 Skill 的目录结构如下~/.claude/skills/cinematic-camera/ ├── SKILL.md ├── assets/ │ ├── camera_library.json │ └── prompt_template.md └── scripts/ └── build_camera_prompt.py目录结构本身不复杂关键是每个文件职责要清晰SKILL.mdSkill 的入口文件包含 frontmatter元信息和正文规则。assets/camera_library.json镜头知识库按“镜头类型、方向、幅度、速度、适用场景”组织。assets/prompt_template.md输出提示词的模板让模型生成结果时保持统一结构。scripts/build_camera_prompt.py一个辅助脚本传入镜头参数生成标准化的英文提示词片段。为什么这样分因为纯文本的SKILL.md适合描述规则但镜头参数如果全写在 Markdown 里模型查找效率会很低。拆分到 JSON 里可以让模型在需要时精准读取某个镜头类型的数据而不是面对一大段文字。脚本的作用则是把“参数”变成“可复制的提示词”这属于工程化处理。实际使用中模型不一定非要执行这个 Python 脚本。它更像是一个离线工具用来在调试时生成标准输出也可以被模型在支持执行命令的工具里调用。这种做法会帮助你验证规则是否合理。5. 从 95 分钟课程到结构化规则知识提炼的完整过程这是整篇文章里我认为最有价值的一段。因为绝大多数人学完课程得到的是一堆零零散散的概念而不是一套可以交给 AI 执行的知识结构。5.1 课程里最重要的不是“名词”而是“决策规则”95 分钟的课程如果只是按时间记录笔记最后只会得到“推镜头是什么、拉镜头是什么”这种字典式内容。但这些东西对生成 AI 视频提示词没有直接帮助因为生成视频时你要做的是“当前画面我应该选什么运镜”而不是“推镜头的定义”。所以我在提炼时给自己定了两个问题这个知识点能帮我做出什么决策这个决策需要哪些参数来描述比如课程里讲“特写镜头配合缓慢推近可以表现角色内心情绪”我提炼出来的就不是“特写镜头的定义”而是一条决策规则当目标是表现角色情绪变化时推荐使用“特写 缓慢推近”推近幅度控制在 20%-30%速度等级为 low。这样提炼之后知识就变成了一条可以直接执行的规则而不是一个需要我再思考的概念。5.2 运镜知识可以归纳成 5 个维度为了不让规则变成一堆碎片我把课程里的内容归并成 5 个维度这也是后续 JSON 知识库的字段来源镜头类型Shot Type特写、中景、全景、远景等。运动方式Movement Type推、拉、摇、移、跟、升降、环绕、手持。方向与幅度Direction Intensity前进、后退、左右横移、上升、下降、旋转角度或推进百分比。速度与节奏Speed Rhythm极慢、慢、中、快、极快以及匀速/变速。情绪与叙事目的Emotion Narrative Intent表达紧张、舒缓、孤独、宏大、悬疑等。前 4 个是“物理参数”AI 视频模型能直接理解。第 5 个是“决策依据”帮助模型在用户描述需求时选择合适的参数组合。5.3 规则的表达方式越是确定性的规则越容易被模型遵守我在写SKILL.md时有一个明显的体会模型对“如果……那么……”这种确定性规则的遵守程度远高于“你可以考虑……”“酌情使用……”这种模糊表述。比如这条规则如果用户描述的情绪是“紧张、不安”运镜应优先选择手持镜头或小幅快速推近避免使用缓慢的升降镜头。这比“表达紧张情绪时可以采用手持镜头”有效得多。前者给了模型明确的选择范围和排除项后者则更像一个建议模型可能在多种镜头里随便选一个。5.4 用示例强化规则SKILL.md里我每个大规则后面都跟了 1 到 2 个完整的输入输出示例而不是只写抽象规则。原因很简单模型在上下文里对“示例”的学习效率远高于“规则描述”。你给它看一个从用户输入到提示词输出的完整样例它就能模仿这个格式处理新输入。这个技巧在写任何 Skill 时都适用。规则负责约束示例负责示范两者缺一不可。6. 完整示例运镜 Skill 的代码实现下面是我这个运镜 Skill 的核心文件内容。你可以直接拷贝按自己的需求修改。6.1 入口文件SKILL.md--- name: cinematic-camera description: 生成 AI 视频的运镜提示词。当用户需要编写视频生成提示词、描述镜头运动、设计镜头语言时使用。 --- # Cinematic Camera Skill 你是一位熟悉电影镜头语言的 AI 视频提示词工程师。你的任务是根据用户的画面描述输出包含明确运镜信息的视频生成提示词。 ## 使用前提 - 只处理与视频生成、运镜、镜头语言相关的任务。 - 如果用户只想要静图不要使用本技能的运动描述。 ## 输出规则 1. 必须先解析用户的画面需求提取主体、场景、情绪、时长。 2. 根据情绪和叙事目的选择合适的镜头类型与运动方式。 3. 每个镜头必须包含镜头类型、运动方式、运动方向、推拉幅度或旋转角度、速度等级。 4. 输出分为两段第一段为视觉画面描述第二段为镜头运动描述。 5. 镜头运动描述必须使用下面列出的标准词汇不要自造词汇。 ## 镜头运动标准词汇 | 分类 | 可用词汇 | | --- | --- | | 运动方式 | push in, pull out, pan left, pan right, tilt up, tilt down, dolly left, dolly right, tracking, crane up, crane down, orbit around subject, handheld | | 运动方向 | toward subject, away from subject, left to right, right to left, upward, downward, clockwise, counterclockwise | | 推拉幅度 | 10%, 20%, 30%, 40%, 50% | | 速度等级 | extremely slow, slow, medium, fast, extremely fast | ## 情绪与运镜对照规则 - 紧张、不安优先 handheld或小幅快速 push in避免升降镜头。 - 舒缓、宁静优先 slow tracking或极缓慢的 pull out速度用 slow。 - 宏大、开阔优先 crane up结合 slow pull out速度用 medium。 - 孤独、疏离优先 long shot slow dolly left或极缓慢的 orbit速度用 slow。 - 悬疑、未知优先 medium push in幅度 20%-30%速度用 slow。 ## 提示词模板 用户输入主体、场景、情绪 输出模板 Visual: {subject}, {scene}, {shot type}, {lighting or mood} Camera: {movement type}, {direction}, {intensity}, {speed} ## 示例 用户输入一个女孩独自站在雨夜的街道上情绪孤独。 输出 Visual: a lonely girl standing on a rainy street at night, long shot, cold blue lighting, melancholic atmosphere Camera: slow dolly left, left to right, 30% lateral movement, extremely slow speed 用户输入主角在考场等待成绩非常紧张。 输出 Visual: a student waiting for exam results in a classroom, close-up, shallow depth of field, tense atmosphere Camera: handheld, subtle movement, toward subject, slow speed这个SKILL.md是核心它告诉模型三件事什么时候用、按什么规则选镜头、输出成什么格式。6.2 镜头知识库camera_library.jsonSKILL.md里放的是最常用的规则而更完整的镜头知识库放在 JSON 里方便模型按需查询。{ shot_types: { extreme_close_up: { desc: 极特写只展示眼睛或局部细节, scene: 情绪爆发、关键细节 }, close_up: { desc: 特写展示面部表情, scene: 情绪表达、对话关键点 }, medium_shot: { desc: 中景展示人物腰部以上, scene: 日常对话、动作交代 }, full_shot: { desc: 全景展示整个人物, scene: 动作展示、角色出场 }, long_shot: { desc: 远景人物在环境中很小, scene: 交代环境、制造孤独感 }, extreme_long_shot: { desc: 极远景环境为主, scene: 宏大场面、空间关系 } }, movement_types: { push_in: { desc: 推镜头靠近主体, intensity: 10%-40%, typical_speed: slow to medium }, pull_out: { desc: 拉镜头远离主体, intensity: 20%-50%, typical_speed: slow to medium }, pan_left: { desc: 水平向左摇, intensity: swing angle 10-90 degrees, typical_speed: medium }, pan_right: { desc: 水平向右摇, intensity: swing angle 10-90 degrees, typical_speed: medium }, tilt_up: { desc: 垂直向上摇, intensity: 10-90 degrees, typical_speed: slow to medium }, tilt_down: { desc: 垂直向下摇, intensity: 10-90 degrees, typical_speed: slow to medium }, dolly_left: { desc: 向左横移, intensity: 20%-50%, typical_speed: slow to medium }, dolly_right: { desc: 向右横移, intensity: 20%-50%, typical_speed: slow to medium }, tracking: { desc: 跟随主体移动, intensity: follow distance 20%-60%, typical_speed: medium to fast }, crane_up: { desc: 升降机上升, intensity: height 20%-100%, typical_speed: slow to medium }, crane_down: { desc: 升降机下降, intensity: height 20%-100%, typical_speed: slow to medium }, orbit: { desc: 环绕主体旋转, intensity: angle 90-360 degrees, typical_speed: medium }, handheld: { desc: 手持镜头画面微晃, intensity: subtle to strong shake, typical_speed: fast } } }这个 JSON 文件并不是让模型死记硬背的而是在模型需要具体参数时提供参考。比如用户说“我想要一个环绕镜头”模型就可以查orbit这个条目知道它适合什么场景、角度范围、速度等级。6.3 辅助脚本build_camera_prompt.py脚本不是必须的但它能帮你快速测试规则也能在支持执行脚本的 Agent 环境中做格式化输出。#!/usr/bin/env python3 文件路径scripts/build_camera_prompt.py 用途根据镜头参数生成标准化的 AI 视频运镜提示词 用法python3 build_camera_prompt.py --subject a girl on rainy street --scene night city --shot long_shot --movement dolly_left --speed slow import argparse import json def load_library(pathassets/camera_library.json): with open(path, r, encodingutf-8) as f: return json.load(f) def build_prompt(lib, args): shot_desc lib[shot_types].get(args.shot, {}).get(desc, args.shot) movement_desc lib[movement_types].get(args.movement, {}).get(desc, args.movement) intensity lib[movement_types].get(args.movement, {}).get(intensity, default) movement_mapping { push_in: push in, pull_out: pull out, pan_left: pan left, pan_right: pan right, tilt_up: tilt up, tilt_down: tilt down, dolly_left: dolly left, dolly_right: dolly right, tracking: tracking, crane_up: crane up, crane_down: crane down, orbit: orbit around subject, handheld: handheld, } movement_en movement_mapping.get(args.movement, args.movement) visual ( fVisual: {args.subject}, {args.scene}, {args.shot.replace(_, )}, fshot_type_desc{shot_desc}, movement_desc{movement_desc} ) camera ( fCamera: {movement_en}, {args.direction}, fintensity {intensity}, {args.speed} speed ) return visual \n camera def main(): parser argparse.ArgumentParser(descriptionBuild camera prompt for AI video.) parser.add_argument(--subject, requiredTrue, helpMain subject of the scene) parser.add_argument(--scene, requiredTrue, helpScene or background) parser.add_argument(--shot, defaultmedium_shot, helpShot type key in camera_library.json) parser.add_argument(--movement, defaultdolly_left, helpMovement type key) parser.add_argument(--direction, defaultleft to right, helpMovement direction) parser.add_argument(--speed, defaultmedium, helpextremely slow / slow / medium / fast / extremely fast) args parser.parse_args() lib load_library() prompt build_prompt(lib, args) print(prompt) if __name__ __main__: main()这个脚本把“参数化运镜描述”这件事变成了一条可复用的命令。你不需要每次打开记事本手工拼提示词直接传参就能得到标准输出。6.4 安装到 Claude Code / Codex目录文件准备好之后安装就很简单了。以 Claude Code 为例# 创建 Skill 目录 mkdir -p ~/.claude/skills/cinematic-camera/assets mkdir -p ~/.claude/skills/cinematic-camera/scripts # 拷贝文件假设你已经写好上面三个文件 cp SKILL.md ~/.claude/skills/cinematic-camera/ cp assets/camera_library.json ~/.claude/skills/cinematic-camera/assets/ cp assets/prompt_template.md ~/.claude/skills/cinematic-camera/assets/ cp scripts/build_camera_prompt.py ~/.claude/skills/cinematic-camera/scripts/如果你用的是 Codex目录路径通常是~/.codex/skills/或者项目目录下的.codex/skills/。不同工具的默认路径可能不同以官方文档为准。关键是保持目录结构一致。安装完成后重新打开工具然后在对话中描述一个视频画面需求模型就应当自动调用这个 Skill。7. 运行结果与效果验证Skill 写完之后不能直接宣布“完成”必须验证。我的验证方法是分三层进行的。7.1 第一层脚本输出验证先用脚本直接生成一个提示词看看格式是否符合预期python3 build_camera_prompt.py \ --subject a lonely girl on a rainy street \ --scene night city, neon lights \ --shot long_shot \ --movement dolly_left \ --direction left to right \ --speed slow预期输出类似Visual: a lonely girl on a rainy street, night city, neon lights, long shot, shot_type_desc远景人物在环境中很小, movement_desc向左横移 Camera: dolly left, left to right, intensity 20%-50%, slow speed如果脚本报错优先检查assets/camera_library.json的路径是否写对了或者 JSON 格式是否合法。这一步能确认代码层面没问题。7.2 第二层模型遵循度验证打开 Claude Code输入一段需求 “一个男人在办公室看着窗外心情很压抑帮我生成视频提示词。”判断标准有三条模型有没有在输出中体现运镜设计而不是只给画面描述。选择的镜头类型和运动方式是否符合“压抑”情绪对应的规则比如缓慢拉远、或失焦的移镜。输出格式是否贴近模板包含 Visual 和 Camera 两段。如果模型只是给了一段“男人 办公室 窗外”的静态画面描述说明 Skill 没有被正确加载或者description写得太窄模型没判断出要调用它。7.3 第三层真实视频生成平台效果验证Skill 输出的是提示词真正生成视频还要拿到 Runway、Pika、可灵、即梦这类平台里去跑。我建议你在测试时固定一个对比组用同一个画面描述分别用“普通提示词”和“运镜 Skill 提示词”各生成一条视频然后对比两者在镜头运动上的差异。判断一个运镜提示词有没有生效主要看三点画面里是否出现了你指定的镜头运动推近、横移、环绕等。运动速度是否符合预期缓慢推近和快速推近的观感完全不同。运镜是否服务了情绪表达压抑场景下急促的推近会显得很奇怪。如果生成的视频里镜头完全没动或者运动方向和你描述的不一致多半是提示词里的镜头词汇和视频模型内部理解不匹配。这时候需要参考目标视频平台的提示词规范调整标准词汇。8. 常见问题与排查方法在搭建和使用 Skill 的过程中有不少细节容易出错。我直接把典型问题整理成下面这张排查表。问题现象可能原因排查方式解决方案模型完全没有调用 SkillSkill 目录放错位置或 frontmatter 的 description 太窄检查 Skill 目录是否在~/.claude/skills/下检查 description 是否覆盖运镜场景调整目录位置把 description 改得更通用且明确提到“生成视频提示词”模型加载了 Skill 但输出不符合格式SKILL.md 中的输出规则不明确查看模型输出是否包含 Visual / Camera 段落在 SKILL.md 中增加严格模板和示例删掉模糊表述运镜词汇被视频模型忽略使用的词汇与视频平台不兼容在目标平台测试单独镜头词汇参考平台官方提示词文档统一标准词汇镜头运动速度不符合预期速度等级描述太笼统对比同一主体在不同速度词下的生成结果给出具体的速度描述词如“slow push in over 5 seconds”模型在普通对话中也输出运镜信息description 写得太宽泛触发范围过大检查模型是否在纯文本任务中误用 Skill收窄 description 范围明确只处理视频/运镜任务Python 脚本运行报错assets 路径写错或 JSON 格式错误运行python3 -m json.tool assets/camera_library.json检查 JSON修正路径或修复 JSON 格式另外还有一个常见认知误区很多人在 Skill 里写了一大堆“电影理论”但完全没有和实际视频生成平台对齐。运镜 Skill 最终产出的是给视频模型用的提示词不是一篇影评。理论再深如果视频模型不能理解push in和dolly的区别效果依然会打折扣。所以写 Skill 之前最好先了解你目标视频平台支持哪些镜头运动词汇。9. 最佳实践与工程建议9.1 把“知识”当代码来管理做 Skill 最忌讳的是把文档当成一次性笔记。它的维护节奏应该和代码项目一样版本化、可回溯、可迭代。我建议你把 Skill 目录纳入 Git 管理每次修改规则都要提交一次并写上清晰的 commit message比如“增加手持镜头在紧张场景下的使用规则”。这样当视频效果变差时你可以很快定位是哪次规则调整导致的。9.2 规则粒度要适中不是越细越好如果规则写得太细把几十种镜头组合全部塞进去模型在大量约束下反而容易“不知道该听哪条”。我在实践中发现每个维度的规则控制在 5 到 10 条左右比较合适再加上示例模型就能稳定输出。别追求“百科全书式”的 Skill它不是知识库它是决策助手。9.3 用示例驱动规则迭代而不是用理论驱动当你发现模型输出不理想时第一反应该是补充一个“错误输入 - 正确输出”的对比示例而不是在规则部分增加更多文字描述。一个高质量的示例往往胜过十行抽象规则。模型学习示例的模式匹配能力比你想象的强得多。9.4 为不同视频平台准备词汇映射Runway、Pika、可灵、即梦对镜头运动的支持程度不同。与其写一个通用 Skill 然后寄希望于所有平台都能理解不如在 Skill 中加一个小的平台词汇映射表。比如某个平台不支持orbit你可以映射成“缓慢环绕拍摄”或者提示模型用pan 360替代。这个思路可以在SKILL.md里加一个“平台兼容性”章节处理。9.5 边界与安全提醒运镜 Skill 本身只是生成提示词不会绕过任何平台的合规限制。使用 AI 视频生成时要注意遵守各平台的内容政策不要生成违法违规内容。另外如果你在团队里共享这个 Skill建议把SKILL.md里的规则写成中性、专业的技术描述避免夹带个人主观偏好这样团队其他人也更容易理解和维护。10. 总结与后续学习方向回头看这 95 分钟课程学到的不只是“推拉摇移”这些镜头名词而是一种把感性经验转化为工程规则的方式。真正让我觉得有收获的不是做出来了这个运镜 Skill而是发现了一种可以复用的工作流学一个领域、提炼决策规则、设计提示词模板、封装成 Skill、在实际工具里反复验证。如果你也想做一个自己的 Skill可以从这几个方向入手从你最近在学的一门课开始把课堂知识拆成“决策规则 参数 示例”的结构。先不要贪多挑一个你最常用的场景做一个最小可用的 Skill。把 Skill 放到 Claude Code 或 Codex 里实际使用一周按真实反馈迭代规则。AI 视频运镜只是一个起点。同样的思路也可以用来做代码审查规则、SQL 优化建议、文案风格控制、数据库设计规范。把知识做成 Skill本质上是把你的个人经验沉淀成一件可以被 AI 复用、被团队复用、被未来自己复用的数字资产。只要这个思维转变了你学任何新知识都会比别人多一层收获。
