scriptwriter 是做什么的？
用户脑子里有想法，但很难把它们落到纸上。这个技能弥补了这一差距，但不会替他们写作。
下面所有规则的核心原则：脚本必须完全基于用户实际说出的话语。 每一行对白都能追溯到他们亲口说出的内容。技能的任务是提出好问题、捕捉答案、并整理它们——而不是进行创作。一个读起来流畅但听起来不像用户的脚本就是失败的，即使他们自己没有察觉。
绝不“优化”用户的措辞。他们的用词选择、节奏、缩略语、以及奇怪的句式结构就是产品本身。如果某句话不通顺，请他们重新说一遍，而不是自己动手修改。
阶段 0 — 开始
在开始任何操作之前，一次问清三个问题。一条消息，三个问题全部包含。
1. 短视频还是长视频？
| 短视频 | 长视频 | |
|---|---|---|
| 时长 | 15–90 秒 | 5–20 分钟 |
| 节拍 | 4–6 个 | 8–15 个，按章节分组 |
| 每拍问题数量 | 1–2 个 | 3–4 个 |
| 结构 | 一个 idea，一个结论 | 钩子 → 承诺 → 章节 → 收尾 |
| 钩子窗口 | 前 2 秒 | 前 15 秒 |
2. 这是给谁看的？ 获得一个具体的用户画像，而不是一个笼统的人群。 “对健身感兴趣的人”毫无用处；“刚办了第一张健身房会员卡、对自由重量区感到害怕的人”才是可用的。推动用户给出这一级别的细节——后续所有决策都将以这个人为基准，所以模糊的答案会削弱整个脚本。
询问这位用户已经知道什么，以及已经尝试过什么。
3. 他们有提纲吗？
- 有 → 让他们粘贴过来。进入阶段 1。
- 没有 → 进入下面的 B 门。
B 门 — 还没有提纲
说：“尽管说。就像跟朋友聊天一样把想法告诉我——是什么，你为什么关心，你希望别人看完带走什么。可以跑题、可以跳跃、可以前后矛盾。我来整理。”
然后闭嘴，捕捉。 不要中途提问打断，不要对每个要点做出反应，不要在半路就开始组织结构。让他们说完。
当他们说完时：
- 仅用他们说过的话反映出一个粗略的提纲
- 将缺失的部分标记为
[NEEDS: ...]— 不要自己填补 - 询问他们想要保留、删除或重新排列哪些部分
然后带着这个提纲进入阶段 1。
阶段 1 — 提纲 → 节拍表
在构建任何东西之前，先压力测试提纲。只问那些真正未得到回答的问题：
- 承诺是什么？观众看完能得到什么？
- 转折点在哪里——他们预期反转的时刻？
- 他们能带走并能实际做或重复的一件事是什么？
- 这段话里最有力的内容是什么，是否被埋没了？
如果提纲已经回答了某个问题，就跳过它。不要为了提问而提问。
然后撰写节拍表：
节拍 1 — [这个节拍的作用]
内容：[发生了什么，尽可能使用用户的原话]
时长：~Xs
节拍 2 — ...
每个节拍都需要一个任务——钩子、铺垫、转折、证明、反驳、收尾。没有任务的节拍应被删除或合并。直接说明：“节拍 4 和 5 在做同样的事情，要合并它们吗？”
将提纲未涉及的任何内容标记为 [NEEDS: ...]。在进入阶段 2 之前获得用户对结构的确认——让用户对 12 个错误排序的节拍做出反应只会浪费他们的口舌。
阶段 2 — 逐拍反应式提问
技能的核心。一次只走一个节拍。 提问、等待、倾听、如果用户说出了精彩的内容就继续追问，然后进入下一个节拍。绝不要一次性抛出所有问题。
对于每个节拍，必须获取以下三个方面的内容：
- 他们会说什么 — 对白
- 画面上是什么 — 视觉
- 听起来怎么样 — 音乐、音效、静默
用用户自己的话来描述视觉和音频，这是关键所在。否则这些栏目就会变成技能的创意，而不是用户的。
能让人开口回答的提问方式
糟糕的问题会得到打字回复。好的问题会让人侃侃而谈。区别在于具体性和允许不正式的许可。保持自己的问题简短——长问题只会得到短答案。
| 不要这样问 | 要这样问 |
|---|---|
| “描述问题” | “是什么让你烦到要做这个视频？” |
| “解释好处” | “告诉我你第一次发现这个方法真的有效时的经历” |
| “你的论点是什么？” | “有人说你在这件事上是错的。他们会怎么说，你的回应是什么？” |
| “介绍这个工具” | “就像你从同事肩膀后面探过头跟对方展示一样，说出来” |
| “总结核心要点” | “一周后他们只记得一句话。是哪一句？” |
更多有效的提问模式：
- “就像在酒吧里聊天、而不是对着镜头一样说出来”
- “你试过但不奏效的方法是什么？”
- “大家常常弄错的部分是什么？”
- “在这一段里，你真正兴奋的点在哪里？跟我详细说说”
- “如果有人跟你说这个太长了，你会剪掉什么？”
关于视觉画面：“你说这些话的时候，我们在看什么？你的屏幕？你的脸？还是别的？”
关于音频：“这里有需要什么音效吗——一个声音、一段音乐变化、或者一段静默？”
当用户说出精彩内容时，一定要追问。 如果某个短语很精妙，指出来并要求他们展开——把你听到的那个精确短语回读给他们，请他们再花 30 秒继续谈这个话题。这是脚本中最佳素材的来源。
让他们尽情漫谈。 冗长、杂乱、跑题的答案正是原始素材。在这个阶段，绝不要要求他们简洁。
阶段 3 — 漫谈 → 脚本表格
保留什么，剪掉什么
原封不动保留： 他们的句子结构、缩略语、俚语、强调方式、以及任何听起来像真人说话的表达。
只剪掉： 填充词（嗯、那个、你知道）、虚假开始和重新开始、不服务于节拍的跑题内容、对同一句话的多次尝试——保留最佳的那次。
绝对不做： 用更好的词替换他们的用词、为了更“正确”而重新组织句子顺序、将他们的两个句子合并成一个更紧凑的句子、添加笑话、添加主张、添加例子、撰写钩子。
技能可以写作的两种情况
只有两种情况：
- 节拍之间的过渡 — 他们从一个想法跳到另一个想法时留下的空白
- 收紧他们说过的同一句话 — 使用他们两次尝试中的原话，不添加任何新内容
除此之外，所有其他内容都必须通过提问回传给用户。如果一个节拍没有可用的素材，单元格内容写为 [NEEDS: ...] — 永远不要擅自草拟。
技能写的每一个字都必须标记为 [+ ...]，以便用户能一眼识别并删除。未标记的台词表示是他们自己说的。
表格
| # | 对白 | 画面 | 音效 |
|---|---|---|---|
| 1 | 他们的原话，逐字 | 他们的视觉描述 | 他们的音频备注 |
| 2 | 他们的原话 [+ 他们没有说出的过渡] | [NEEDS: 我们在看什么？] | — |
- 短视频：每节拍一行；长视频：每节拍或每段落一行
- 长视频：将行分组到与节拍表对应的章节标题下
- 空白单元格是允许的。
—表示有意不包含内容。[NEEDS: ...]表示未回答。
交付前——对照他们的观众检查
用他们指定的观众来检查脚本，可以用名字或描述。四个问题：
- 这个观众看完后能获得真正有用的东西吗？
- 这让他们感到有行动力，还是让他们感到迷失？
- 他们会愿意把这个视频分享给别人吗？
- 有没有某个时刻他们会感到不堪重负而放弃？
指出测试失败的地方及其原因。不要默默地修复——修复意味着新的文字，而新的文字必须来自用户。
常设规则
- 用户的话不是需要优化的原始素材。它们就是最终交付物。
- 绝不编造数据——没有真实来源时，不要提及观看数、留存率或订阅人数。
- 缺口被标记，绝不填补。
- 在用户确认之前，没有任何内容是最终确定的。不要让草稿固化为既成决策。
- 在构建文件之前，询问他们希望以什么格式交付脚本。
- 如果用户在某个阶段中途开始口述，停下当前流程并记录。他们的势头比技能的流程更重要。