Skill: Multi-Variant Scripting
Owner: Sara
Version: 1.0
First used: 2026-03-24 (Reddi Agent Protocol — 3-variant pipeline)
What This Does
Produces 2–4 distinct script variants for the same product from a single brief. Each variant serves a different audience or communication style. Variants must be genuinely distinct — not the same script with synonyms swapped.
When to use this skill: Any time the demo-video playbook calls for 2+ variants. Read this before writing the first word of any script.
The Variant Differentiation Test
Before writing a single scene, define these three things for each variant:
- 1. What does this audience already know? (Don't explain what they know — assume it)
- What's the ONE thing this variant needs them to feel or understand? (Not a list — one thing)
- What's the register? (cinematic / conversational / technical)
If two variants have the same answers to all three → they are not distinct → collapse them into one.
Running this test upfront prevents the most common failure: writing three scripts that tell the same story three different ways, rather than three genuinely different stories about the same product.
Variant Labelling Convention
Use these labels consistently across all projects so Finn knows the production approach without reading the script:
| Label | Audience | Style | VO Density |
|---|
| A | Technical or sophisticated | Cinematic — minimal VO, UI carries story | Sparse |
| B |
General / accessible | Walkthrough — guided, second person | Medium |
|
C | Developer / architect | Explainer — structured, covers architecture | Dense |
Word Count Targets
Check these before calling any script done:
| Target Length | Narration Word Count |
|---|
| 60s | 110–130 words |
| 90s |
160–195 words |
| 2min | 220–260 words |
| 3min | 330–390 words |
At natural TTS pace: ~130 words/min. Count words in the clean narration section only (no stage directions).
Interleaved Writing Technique
The wrong way:
Write A fully → Write B fully → Write C fully
By the time you write C, it has unconsciously borrowed A's metaphors and B's sentence structure. C ends up sounding like a compressed remix of the first two.
The right way (interleaved):
Write Scene 1 for A, B, C → Write Scene 2 for A, B, C → continue scene by scene
This forces explicit differentiation at each narrative beat. When you write Scene 2 for C, you've just written Scene 2 for A and B — so you're actively thinking "how is C different here?" rather than just continuing a flow.
Common Failure Modes
Drift
What it is: Writing C after A and B causes C to unconsciously borrow A's metaphors and B's structural patterns.
Fix: Use interleaved writing. Never fully complete one variant before starting the others.
Jargon Bleed
What it is: Technical terms written for C leak into B because they were written in the same session.
Fix: Before writing, define a jargon whitelist per variant. Terms on C's whitelist should not appear in B. Terms on B's whitelist should not appear in A unless they're genuinely plain-language.
Example:
- - A whitelist: (none — no jargon, let the UI speak)
- B whitelist: "agent", "automates", "dashboard"
- C whitelist: "MCP protocol", "orchestrator", "tool-call", "mesh routing"
Length Creep
What it is: All variants drift toward the same word count because the writer fills to a comfortable length.
Fix: Count words in the clean narration section after writing each scene. Stop when you hit the ceiling. Tighten, don't pad.
Output Checklist — Before Handoff to Finn
Run this check on all variants together, not one at a time:
- - [ ] Each variant has a clean narration section (narration only — no stage directions, no scene headers)
- [ ] Word counts checked against length targets (count them, don't estimate by feel)
- [ ] No variant shares an opening line with another (first sentence must be unique per variant)
- [ ] Jargon that appears in C does not appear in B
- [ ] Jargon that appears in B does not appear in A
- [ ] Screenshot/recording requirements section is complete and specific
- [ ] "Notes for Finn" section includes timing gotchas, transition notes, any unusual assembly requirements
- [ ] Differentiation test re-run on final drafts — confirm answers to all three questions are still distinct
Handoff Format
Each script file must follow the standard format:
CODEBLOCK0
All three script files are handed to Finn together. Finn does not start production until Nissan has approved all scripts.
技能:多变量脚本编写
所有者: Sara
版本: 1.0
首次使用: 2026-03-24(Reddi Agent 协议 — 3变量流水线)
功能说明
根据单一简报,为同一产品生成 2–4 个不同的脚本变量。每个变量面向不同的受众或沟通风格。变量必须真正有所区别——而非仅替换同义词的相同脚本。
何时使用此技能: 当演示视频剧本要求 2 个及以上变量时。在撰写任何脚本的第一个字之前,请先阅读本文。
变量差异化测试
在撰写任何一个场景之前,为每个变量定义以下三项内容:
- 1. 该受众已经知道什么?(不要解释他们已知的内容——假设他们已知)
- 该变量需要他们感受或理解的唯一一件事是什么?(不是列表——仅一件事)
- 语域是什么?(电影感 / 对话式 / 技术性)
如果两个变量对以上三项的回答相同 → 它们没有区别 → 合并为一个。
提前进行此项测试可防止最常见的失败:写出三个以三种不同方式讲述同一故事的脚本,而非三个关于同一产品的真正不同的故事。
变量标签规范
在所有项目中一致使用这些标签,以便 Finn 无需阅读脚本即可了解制作方法:
| 标签 | 受众 | 风格 | 旁白密度 |
|---|
| A | 技术型或资深型 | 电影感 — 最少旁白,UI 承载故事 | 稀疏 |
| B |
普通 / 易理解型 | 引导式 — 有指导,第二人称 | 中等 |
|
C | 开发者 / 架构师型 | 解释型 — 结构化,涵盖架构 | 密集 |
字数目标
在宣布任何脚本完成前,请检查以下内容:
160–195 字 |
| 2分钟 | 220–260 字 |
| 3分钟 | 330–390 字 |
以自然 TTS 语速计算:约 130 字/分钟。仅统计纯旁白部分的字数(不含舞台指示)。
交错写作技巧
错误方式:
完整写完 A → 完整写完 B → 完整写完 C
当你写 C 时,它已无意识地借用了 A 的隐喻和 B 的句子结构。C 最终听起来像是前两者的压缩混音版。
正确方式(交错):
为 A、B、C 写场景 1 → 为 A、B、C 写场景 2 → 逐个场景继续
这迫使在每个叙事节拍上进行明确的差异化。当你为 C 写场景 2 时,你刚刚写完 A 和 B 的场景 2——因此你正在积极思考“C 在这里有何不同?”,而非仅仅延续一个流程。
常见失败模式
漂移
是什么: 在 A 和 B 之后写 C 导致 C 无意识地借用 A 的隐喻和 B 的结构模式。
修复: 使用交错写作。在开始其他变量之前,切勿完整完成任何一个变量。
术语渗透
是什么: 为 C 编写的技术术语因在同一会话中编写而渗入 B。
修复: 在写作前,为每个变量定义一个术语白名单。C 白名单上的术语不应出现在 B 中。B 白名单上的术语不应出现在 A 中,除非它们确实是通俗语言。
示例:
- - A 白名单:(无——无术语,让 UI 说话)
- B 白名单:“代理”、“自动化”、“仪表盘”
- C 白名单:“MCP 协议”、“编排器”、“工具调用”、“网格路由”
长度蔓延
是什么: 所有变量趋向于相同的字数,因为作者填充到舒适的长度。
修复: 在写完每个场景后,统计纯旁白部分的字数。达到上限时停止。精简,而非填充。
输出检查清单 — 移交给 Finn 前
对所有变量一起运行此检查,而非逐个进行:
- - [ ] 每个变量都有纯旁白部分(仅旁白——无舞台指示,无场景标题)
- [ ] 字数已对照时长目标检查(统计字数,而非凭感觉估算)
- [ ] 没有变量与另一个变量的开场白相同(每个变量的第一句话必须独一无二)
- [ ] 出现在 C 中的术语未出现在 B 中
- [ ] 出现在 B 中的术语未出现在 A 中
- [ ] 截图/录制要求部分完整且具体
- [ ] “给 Finn 的备注”部分包含时间节点注意事项、过渡说明、任何不寻常的组装要求
- [ ] 对最终草稿重新运行差异化测试——确认对全部三个问题的回答仍然不同
移交格式
每个脚本文件必须遵循标准格式:
markdown
视频脚本 [A/B/C] — [标题]
版本: 1.0
目标时长: X 秒
受众: [谁]
风格: [描述]
逐个场景
场景 N — [标题] (M:SS–M:SS)
屏幕: [页面/状态]
操作: [如有交互]
旁白: “[确切口语内容]”
音乐/氛围: [描述]
完整旁白(纯朗读)
[仅旁白——此为直接 TTS 输入]
截图/录制要求
[所需具体素材,附复用说明]
给 Finn 的备注
[时间、过渡、组装注意事项]
所有三个脚本文件一并移交给 Finn。在 Nissan 批准所有脚本之前,Finn 不会开始制作。