如果你最近在用 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 放在一起比较。这里有必要做一个区分。
MCP（Model Context Protocol）解决的是“Agent 如何调用外部工具与数据”的问题。它相当于给模型开放了一组可执行的接口，比如读取本地文件、调用某个 API、查询数据库。MCP 是一种运行时能力和系统集成。
Skill 解决的是“模型如何在特定领域把事情做对”的问题。它不调用外部系统，而是在提示词层面对模型进行知识注入与行为约束。Skill 更像是一本随身携带的“专家操作手册”，它本身不产生新的工具能力，而是让已有的能力在特定场景下表现更专业。
表格对比更清楚：
| 对比维度 | Skill | MCP |
|---|---|---|
| 解决的核心问题 | 让模型按特定领域规则完成任务 | 让模型获得外部工具与数据访问能力 |
| 运行方式 | 通过文件加载知识，在提示词层生效 | 通过协议连接外部服务，在运行时生效 |
| 是否需要独立进程 | 不需要，通常只是文件与脚本 | 通常需要独立服务或进程 |
| 典型场景 | 代码规范、运镜提示词、文案风格 | 查数据库、发请求、操作文件 |
| 对模型的改变 | 改变回答的规则和风格 | 改变模型的能力边界 |
理解这个区别很重要，否则你可能会在搭建过程中用错了方向，本来应该整理知识，结果去搭了一个不必要的 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.md：Skill 的入口文件，包含 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.json
SKILL.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(path="assets/camera_library.json"): with open(path, "r", encoding="utf-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 = ( f"Visual: {args.subject}, {args.scene}, {args.shot.replace('_', ' ')}, " f"shot_type_desc={shot_desc}, movement_desc={movement_desc}" ) camera = ( f"Camera: {movement_en}, {args.direction}, " f"intensity {intensity}, {args.speed} speed" ) return visual + "\n" + camera def main(): parser = argparse.ArgumentParser(description="Build camera prompt for AI video.") parser.add_argument("--subject", required=True, help="Main subject of the scene") parser.add_argument("--scene", required=True, help="Scene or background") parser.add_argument("--shot", default="medium_shot", help="Shot type key in camera_library.json") parser.add_argument("--movement", default="dolly_left", help="Movement type key") parser.add_argument("--direction", default="left to right", help="Movement direction") parser.add_argument("--speed", default="medium", help="extremely 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 的过程中，有不少细节容易出错。我直接把典型问题整理成下面这张排查表。
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 模型完全没有调用 Skill | Skill 目录放错位置，或 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 复用、被团队复用、被未来自己复用的数字资产。只要这个思维转变了，你学任何新知识，都会比别人多一层收获。
