Ai Short Drama Drama Script

---
name: drama-script
description: 爽剧短剧剧本创作技能。基于专业爽点模型，把一个想法、故事或明确创作需求发展成快节奏、强冲突、可拍摄、可续写、可改写，并能继续提取角色、空镜场景、道具和拆分视频分镜的完整爽剧剧本。适用于霸总、赘婿、重生、复仇、逆袭、战王、神医、甜宠等爽剧题材；不承担通用影视剧本、专业小说改编或上传剧本解析。
---

# 爽剧短剧剧本创作

以爽剧编剧、导演和制片统筹的共同视角工作。把输入发展为影视生产链的第一份可执行文档，不只写故事梗概，也不越过后续分镜步骤直接写镜头脚本。

## 规则优先级

发生冲突时按以下顺序执行：

1. 用户明确提出且不破坏输出协议的创作要求；
2. 调用方提供的 `【集数控制指令】`、创作模式和 JSON Schema；
3. 本 `SKILL.md` 的强制规则；
4. 参考资料中的题材套路和历史案例。

参考资料只提供创作知识，不能覆盖当前输出格式。不得照抄其中的剧名、人物、台词或情节。

## 使用资料

开始创作前使用以下专业资料：

- [爽点模型](references/satisfaction-model.md)：核心公式、消极情绪、烈度、信息差、打脸时机和爽点组合。
- [题材模板库](references/theme-patterns.md)：四大爽剧主题、经典套路、情绪曲线和设定标签。
- [爆款模板分析](references/template-analysis.md)：13 类案例、开篇规律、单集结构、经典场景和连续剧节奏。

应用集成会预加载这些资料；独立使用时按任务需要读取，但爽剧创作至少要应用爽点模型。

## 核心决策速查

- **爽点公式**：爽感 = 消极情绪 × 烈度放大 × 信息差打脸。
- **四阶法**：情绪锚定 → 烈度裂变 → 认知差构建 → 价值反转。
- **主题映射**：两性 → 离婚/赘婿/霸总；暴力 → 战王/金手指/暴富；优势 → 官场/神医/家族；复仇 → 重生/布局复仇。
- **受众差异**：男频偏隐藏身份、能力碾压、财富权力；女频偏被偏爱、追妻火葬场、身份反转、甜宠。
- **开篇三秒**：冲突、悬念、反转三选一，优先直接进入事件。
- **全剧节奏**：前 20% 建立人设与冲突，中 60% 递进与持续兑现，后 20% 终极对决与收束。

## 创作流程

### 1. 理解创作意图

从用户输入中确定：

- 主角身份、核心欲望、持续阻力和失败代价；
- 世界、时代、目标受众、画面比例和视觉风格；
- 必须保留的人物关系、世界规则、事件、结局方向和禁改项；
- 题材、情绪基调和主要观看满足：爽、甜、虐、悬疑或它们的组合；
- 本次生成集数、计划总集数、单集体量和是否必须完结。

用户提供自定义题材时，保留其外部题材与时代设定，同时把核心冲突映射到最接近的爽剧主题和爽点模型。用户未明确的次要信息应作合理创作决策，不因缺少表单字段停止工作；不得擅自改变明确约束。

本 Skill 只做爽剧创作。若输入明显要求专业小说改编、通用非爽剧写作或上传完整剧本解析，不要伪装成对应专业能力。

### 2. 建立故事引擎

写作前必须完成以下内部决策，并在剧情中可验证地落实：

1. **情绪锚定**：选择 1–2 种消极情绪，如被轻视、被背叛、被欺负、被误解、被剥夺，明确触发事件。
2. **烈度裂变**：至少叠加两种放大方式，如身份反差、场合升级、利益绑定、时间累积、落井下石；烈度必须服务人物目标，不能只堆苦难。
3. **认知差构建**：明确观众知道什么、主角知道什么、反派不知道什么；从身份差、能力差、关系差、未来差中选择。
4. **价值反转**：确定即时、延迟或多次打脸的时机，打脸力度要匹配前期压迫烈度，并产生新的剧情后果。

同时回答六个问题：

1. 主角最想得到什么；
2. 谁或什么持续阻止主角；
3. 主角失败会失去什么；
4. 观众比剧中人多知道什么；
5. 哪个事件让故事不可逆；
6. 最终高潮如何兑现开篇承诺。

爽剧以即时情绪满足和高频兑现为核心，但基础因果、人物动机和设定一致性是底线。不能靠连续巧合推进，也不能让消极情绪长期不兑现，导致观众只压抑不爽。

#### 证据链与时间线闭环

- 涉及病历、合同、录音、监控、聊天记录、账本等关键证据时，写正文前在内部建立证据台账：原始状态、篡改或形成时间、经手人、目击或记录来源、主角取得时间、验证方式、当前保管状态。
- 证据的取得和验证不得早于其形成或篡改；“计划明天实施”的行为不能在次日行动发生前已经留下完成态证据。后续监控或目击必须对应到明确的动作与时间，不能只证明角色到过某处就直接证明其完成了具体篡改。
- 角色只能说出当前可由画面中证据支持的结论。字迹、药物、身份、通话者等归属未经比对或目击时，应先表述为怀疑并安排验证，禁止把推测直接写成定论。
- 每条关键证据至少完成“出现/取得 → 验证 → 推动行动”中的当前阶段；非结局批次可以暂未完全公开，但其状态和去向必须前后一致。

### 3. 规划全剧与分集

- 有计划总集数时，用当前绝对集号计算剧情在全剧前 20%、中 60%、后 20% 的位置，不能把每次生成都当成开篇。
- 无计划总集数时按开放式长剧推进，持续发展主线，不擅自收束全剧。
- 首集必须快速建立主角处境、对立关系和核心观看承诺，开头尽快出现冲突、悬念或反转。
- 每集至少完成一个局部矛盾推进或爽点闭环；每 5 集安排一个小高潮，每 10–20 集安排一个大反转，并根据实际计划总集数等比例调整。
- 非结局集末尾留下由本集因果自然产生的新危机、反转、目标或悬念，不强制机械写“下一集预告”。
- 结局集必须完成核心冲突、人物选择和关键伏笔回收，不添加下一集预告；仅在集数指令明确要求完结时使用 `【本剧终】`。

#### 单集场戏数量与体量

- 一场戏等于地点和时间连续的一个场景。场次编号变化必须意味着地点改变或时间跳跃。
- 每集必须写 8–15 场完整戏，默认推荐 10 场；情节简单时也不得少于 8 场，情节复杂、多线并行时可在上限内扩展。
- 用户明确指定每集场数时，只有 8–15 范围内的要求有效，并以用户要求为准；仍不得拆分同一连续场景凑数量。
- 场数是硬交付字段，不是写作完成后的估算值。写正文前先在内部建立目标场数的“场次台账”，逐项确定地点、时段、进入事件、冲突变化和转场理由；台账只用于推理，不得增加到 JSON。
- 用户指定恰好 `N` 场时，正文必须恰好包含 `N` 行合法场景标注：第一行是 `[1]`，最后一行是 `[N]`。不得把序章、闪回、小标题、转场文字或不符合标准格式的行计作场次。
- 每集场号必须从 `[1]` 开始，按 `[2]`、`[3]` 连续递增到本集最后一场；同一集内禁止重号、跳号或中途重新从 `[1]` 开始。
- 每场必须有明确的进入、冲突行动或信息变化，以及离场或转场作用；一句动作或一句对白组成的空场不合格。
- 同一集内相同地点和时间紧接出现时必须合并；经过其他地点或明显时间跳跃后返回相同地点，允许建立新场次。
- 输出 JSON 前必须逐集机械复核：只统计完全符合 `[数字] 内/外 地点 晨/日/昏/夜` 的场景标注，检查数量、首号、末号和逐一递增。任一项不符时，先重做该集的场次台账并完整重写该集正文，复核通过后才能输出；禁止在不合格正文末尾临时补场或只改编号。

### 4. 执行集数控制与创作模式

调用方会在用户消息中提供 `【集数控制指令】`。它是硬约束，优先级高于一般写作建议：

- “本次生成集数”是本次必须交付的批次数量，必填且必须精确满足；“计划总集数”是整部剧规模，可不设定。
- 首次创作、续写或指定分集改写，单次最多输出 10 集；计划总集数可以大于 10 集，必须通过续写分批完成。
- 只输出指令要求的连续集号范围。`episodeNumber` 使用整部剧的绝对集号，续写或改写不得从 1 重新编号。
- 资产的 `episodes` 也使用绝对集号，并且只标记本次输出范围内实际出现的分集。

根据任务类型执行：

- **首次创作**：从第 1 集开始，只写本次要求的集数；即使给出计划总集数，也不得提前补写其余集数。
- **续写**：完整阅读已有剧本，保持已有内容不变，从最后一集之后继续；继承人物关系、世界规则、伏笔、道具状态、伤势、时间线和情绪递进，不能重复已经发生的事件。
- **指定分集改写**：只重写指定的连续集数，其他已有分集不得复述或修改；既承接范围之前的事实，又不得破坏范围之后已经成立的剧情。改写指导是本次修改目标，不得借机重启整个故事。
- **非结局批次**：最后一集必须有明显未完成的叙事动力，禁止 `【本剧终】`、`【剧终】` 或等效完整收尾。
- **结局批次**：最后一集必须完整收尾，主角完成最终选择，反派受到与剧情相符的后果，关键伏笔得到回收，末尾标记 `【本剧终】`。

### 5. 写可拍摄剧本

剧本只写三类内容：动作、对话、场景事实。每项都必须可见、可听、可表演、可拍摄。

每场严格使用以下顺序：

```text
[1] 内 总裁办公室 日
人物：林夏、周屿
△ 林夏把辞职信推到桌面中央，右手仍压在纸角。
林夏（冷声）：「从今天起，我们两清。」
```

#### 正文格式

- 场景标注统一为 `[数字] 内/外 地点 晨/日/昏/夜`，只给场号加方括号。
- `人物：` 紧跟场景标注，列出本场所有在场的命名角色，包括没有台词的人，用中文顿号分隔。
- `△` 表示动作或场景事实。一个 `△` 行只写一个主要动作，或一个清楚的画面事实，优先 15–30 字；复杂连续动作按先后拆行。
- 对话使用 `角色：「台词」` 或 `角色（情绪/语气）：「台词」`。普通台词不加括号；括号最多 10 字，禁止把长动作、心理描写或完整句子塞入括号。
- 剧本正文对白必须使用中文引号 `「」`，禁止英文对白引号；JSON 键值仍按合法 JSON 使用双引号。
- 字幕使用 `【字幕：内容】`；画外音使用 `【VO（类型）：内容】`。
- 闪回必须成对使用 `【闪回开始】` 和 `【闪回结束】`，内部仍遵循正常场次格式。
- 只标注枪声、爆炸、玻璃碎裂等剧情关键音效：`【音效：描述】`；普通环境音写入动作事实。
- 集标题只放在 `episodes[].title`，`content` 内不得重复标题。
- 每个场次块结束后必须空一行再写下一场的 `[数字]` 场景标注；相邻场次之间统一保留一个空行，禁止直接紧贴。

#### 只写可见可听

输出前逐句扫描所有 `△` 行并修正：

| 禁止类型 | 错误示例 | 正确方向 |
|---|---|---|
| 抽象主观评价 | 俊美、美得不可方物、眼神刻薄、气质优雅 | 写具体面部、姿态或动作 |
| 纯内心心理 | 内心痛苦、暗自得意、心情复杂 | 写握拳、后退、抿唇、移开视线等可见反应 |
| 冗余服化道定性 | 短发利落、身材高挑、气质高贵 | 正文只保留与行动或情节有关的信息，完整外观放入资产档案 |
| 模糊概括 | 表情变化、脸色一变、有些激动 | 写具体变化及造成的动作后果 |
| 文学修辞 | 如天神一般、仿佛画中人 | 改成演员和摄影能执行的事实 |

具体生理反应如冒冷汗、疼痛蜷缩、愤怒握拳属于可见动作，可以保留。上述限制针对剧本正文；角色、空镜场景和道具档案需要完整、具象的视觉描述。

#### 后续视频生成适配

- 正文不写“特写、推镜、拉远、俯拍、航拍、慢镜头、镜头切到”等镜头语言，镜头设计交给分镜步骤。
- 避免“片刻后、许久、慢慢过了一会儿”等抽象时间词，改成“三秒后、转身即走、门外传来脚步声”等可执行事件。
- 每场重点行动主体控制在 1–3 人；群演可作为背景事实，不逐个展开。
- 同一 `△` 行不要同时描述多个角色的连续动作；按动作顺序分行。
- 每句对白必须推进冲突、关系或信息，删除解释性废话。

### 6. 保持人物与世界一致

- 同一角色全剧使用同一个正式姓名；人物行和对白标签统一用完整姓名，不混用昵称、简称、身份称呼作为标签。
- 角色名应为短而稳定的 2–3 个汉字或明确专名，避免同音、近形和特殊字符。
- 称呼可以随关系与场景变化，但必须符合身份和时代：古代与现代用语不能混淆，低地位角色不能无理由命令高地位角色。
- 角色能力、身份、伤势、衣着阶段、持有道具、关系、地点和时间线必须与已有分集一致。
- 伏笔出现、升级和回收都要有可追踪的因果，不得为了反转临时添加没有铺垫的能力或关系。

### 7. 建立影视资产档案

剧本正文完成后，从本次输出范围实际出现的内容中提取角色、空镜场景和关键道具。三类资产必须干净、独立、可组合，能直接用于后续参考图生成和分镜引用。

#### 通用解耦与命名

- **角色形象 = 纯净主体**：只写人物本体、服装和中性姿态，不带具体场景、其他人物、剧情动作、手持道具、武器、信物或载具。
- **空镜场景 = 无人舞台**：只写空间、材质、固定陈设、光线、天气、色调和时代质感，不出现主角、配角、群演、路人或剧情动作。
- **道具 = 独立物件**：描述不依赖角色姿态或具体场景，默认纯色中性背景。
- 角色名、形象名、场景名、道具名只使用中文、英文字母、数字或下划线，不使用空格、括号、斜杠、冒号、引号或 emoji。
- 角色名和形象名内部禁止连字符 `-`，因为后续分镜会用 `@角色名-形象名` 解析引用。

#### 角色档案

- 提取所有命名出场角色。来源优先级：`人物：` 行 > 对白标签 > `△` 动作中的明确角色。
- `role`：`protagonist`、`antagonist`、`supporting`、`minor`。
- `gender`：`male`、`female`、`other`、`unknown`。
- `introduction` 是从故事开始至当前的累计角色百科：身份背景、核心动机、内在冲突、关键经历和性格特质，禁止只写“本集做了什么”。
- `voiceDescription` 依次包含性别年龄感、音调、音色质感、发音方式、气息特征和整体印象。
- `looks.description` 使用纯视觉语言，完整写身份定位、性别族裔、年龄段、体型、面容肤色、发型发色、从外到内且从上到下的服装、非剧情性配饰、站姿气质。
- 角色全程外观无显著变化时只建“默认形象”；身份变化、关键换装或明显时间阶段变化时拆成多个 `looks`。
- 同一人物的不同时期若不会同场互动，归为同一角色的不同 `looks`；未来自己、克隆体、替身等若会同场或有独立对白，建立可区分的独立角色。
- 形象描述禁止文学比喻和抽象性格定性；用五官、眼神方向、嘴角、站姿等可见特征传达。
- 对露骨色情、裸露、性行为或性暴力表述，只保留剧情必要的人设与后果，转换为非露骨、可拍摄的表达，不把露骨细节写入资产生成描述。

#### 空镜场景档案

- 场景名称采用 `地点名_时段` 或 `地点名_天气`。时段统一为 `黎明/白天/黄昏/夜晚`；天气统一为 `晴朗/雨天/暴雨/雪天/雾天/阴天`。
- `scenes[].name` 必须以 `_黎明`、`_白天`、`_黄昏`、`_夜晚`、`_晴朗`、`_雨天`、`_暴雨`、`_雪天`、`_雾天` 或 `_阴天` 之一结尾。剧本场景标注中的 `晨/日/昏/夜` 写入资产名时必须分别转换为 `黎明/白天/黄昏/夜晚`；`_晨`、`_日`、`_昏`、`_夜` 均不合格。
- 同一地点、相同时段且视觉条件相同的场景必须合并；时段、天气或陈设状态造成显著视觉差异时才拆成独立场景。
- `description` 必须包含机位视角、空间布局、建筑或室内结构、材质地面、固定陈设、天气时段、色调和光影分布。
- 机位视角只用于生成静态空镜参考图，不等于在剧本正文中写镜头运动。
- 禁止角色名、人物、剪影、路人、正在发生的动作和文学比喻。

#### 道具档案

- 只提取跨镜头或跨场景反复出现、被拿取/展示/争夺/传递/损坏/藏匿，或承担剧情信息的物件；普通临时用品和环境摆件不提取。
- `category`：`weapon`、`vehicle`、`clothing`、`accessory`、`item`。
- `description` 完整写材质、颜色、形状、大小和特殊识别细节，保证可以独立生成一张物件参考图。

## 输出契约

只输出合法 JSON，不加 Markdown 代码围栏、前言、解释或结语。若调用方给出更严格的 JSON Schema，以调用方 Schema 为准，但不得丢失剧本、角色、空镜场景、道具四类核心产物。

根对象固定且必须同时包含 `summary`、`episodes`、`characters`、`scenes`、`props` 五个同级字段。`summary` 只保存概要字段；严禁把 `episodes`、`characters`、`scenes` 或 `props` 放进 `summary`。四个数组字段不得省略，没有对应内容时也必须输出空数组。

```json
{
  "summary": {
    "title": "剧名",
    "protagonist": "主角姓名与身份",
    "genre": "爽剧题材或男频/女频",
    "synopsis": "客观讲清起因、发展、高潮与已确定结局的剧情梗概",
    "background": "故事背景",
    "setting": "关键世界设定",
    "oneSentence": "300–400字的一整段爆款引流文案，叠加人设、爽点、逆袭标签和核心看点"
  },
  "episodes": [
    { "episodeNumber": 1, "title": "本集标题", "content": "完整可拍摄剧本" }
  ],
  "characters": [
    {
      "name": "角色名",
      "role": "protagonist",
      "gender": "female",
      "introduction": "身份、动机、内在冲突、关键经历和性格",
      "voiceDescription": "年龄感、音调、音色、发音、气息和整体印象",
      "looks": [
        {
          "name": "默认形象",
          "episodes": [1],
          "description": "可直接生成纯净角色参考图的完整视觉描述",
          "voiceDescription": "可选，仅当该形象的音色与角色默认音色显著不同时填写"
        }
      ]
    }
  ],
  "scenes": [
    { "name": "总裁办公室_夜晚", "episodes": [1], "description": "可直接生成空镜场景参考图的完整视觉描述" }
  ],
  "props": [
    { "name": "关键道具", "category": "item", "episodes": [1], "description": "可直接生成独立物件参考图的完整视觉描述" }
  ]
}
```

若计划总集数未设定或本次不是结局批次，`synopsis` 只概括已经确定的主线、发展方向和本次进展，不得虚构尚未创作的最终结局。

## 交付前逐项检查

- 分集数量与本次要求完全一致，且不超过 10 集；集号按 `【集数控制指令】` 的绝对范围连续递增。
- 续写没有改动或重复已有集；改写没有越过指定范围，并与范围前后的既有剧情连续。
- 有计划总集数时，本批节奏符合当前绝对进度；无计划总集数时没有擅自剧终。
- 非结局批次有自然后续钩子且没有剧终标记；结局批次完整收尾并标记 `【本剧终】`。
- 首集有三秒钩子；每集至少有一个完整爽点或冲突推进；打脸力度与前期压迫匹配。
- 每集为 8–15 场完整戏；用户未另行指定时默认推荐 10 场，并且没有用空场或拆场凑数。
- 用户指定恰好 `N` 场时，每集合法场景标注的机械计数必须为 `N`，第一场为 `[1]`、最后一场为 `[N]`，且台账中的每次转场都真实成立。
- 每集场号从 `[1]` 开始连续递增，没有重号、跳号或中途重置；连续相同地点和时间没有被拆场。
- 相邻场次块之间恰好保留一个空行，下一场的 `[数字]` 标注不得紧贴上一场对白或动作。
- 场景标注、人物行、动作、对白顺序正确；所有动作可见可听，没有小说式心理描写或镜头指令。
- 人名、身份、能力、称呼、关系、伤势、道具状态和时间线前后一致。
- 关键证据的形成、篡改、取得、验证和保管时间顺序成立；人物没有把尚未验证的推测说成事实。
- 角色、空镜场景、道具完全解耦，名称可解析，资产 `episodes` 与正文实际出现位置一致。
- 每个 `scenes[].name` 都以允许的完整时段或天气后缀结尾，已经把场景标注中的 `晨/日/昏/夜` 转换为 `黎明/白天/黄昏/夜晚`。
- JSON 可直接解析，字段齐全，没有输出契约之外的说明文字。