把技术内容转成可拍摄视频脚本时：用双栏节拍表、30…

当你需要为技术视频/录屏（演示、教程、代码走查、把博客或 changelog 转成视频）写或审一份可直接开拍的脚本时使用。

适用场景

解决思路

1. 先做访谈，一次只问一个问题，能提供选项就用多选题；一旦能说清 promise、观众和素材来源就停止提问。
2. 访谈中拒绝形容词：把“精致”“技术性强”“有吸引力”等转化为具体决策（时长、观众、屏幕上的产物）后再继续。
3. 吸收溢出信息：当某个回答已覆盖下一个问题时，不要再问那个问题。
4. 绝不用看似合理的内容填补空白：只写用户说过的内容，推断的内容在草稿中标注 `[unconfirmed]` 并追问。
5. 访谈需覆盖：素材来源（已发布文章/文档页、changelog 或 PR、可运行 demo、已录制演讲、还是尚未动笔）；观众看完能做什么或决定什么；观众是谁（评估者、遇到具体报错的用户、学新功能的老用户、不会动手的买家侧观众）；视频发布在哪里（视频平台、文档页嵌入、发布公告、社交信息流、内部赋能库）；现实时长及它是约束还是猜测；必须发布的日期（发布、活动、发版窗口或无截止日期）；是一次性收益还是可复利资产；投入上限（录制与剪辑小时数、是否有人能做图或维护配套仓库、需多少评审）；出镜形式（露脸、仅配音、还是静音字幕）；谁来录、在谁的机器上录；屏幕上绝不能出现什么（客户数据、未发布功能、内部主机名、定价）；是否有配套产物（仓库、分支、gist、文档页）；是全新制作还是挽救表现不佳的视频（挽救时先拿到留存曲线）。
6. 在选形状前先问清发布日期、一次性/复利、投入上限这三个问题，因为它们会重排形状表：硬发布日期提升 changelog 短片和报错/修复视频、删除深度解析；复利任务提升跟做教程和深度解析、降级短命短视频；无作图支持的投入上限删除概念讲解；无人维护配套仓库删除跟做教程。
7. 工作流第 1 步——提炼 promise：一句话说明“对这个观众，这个视频展示了这个具体的东西在运行”。如果这句话需要“和”，你就有两个视频。
8. 工作流第 2 步——把素材转成论点而非章节：书面素材为扫读而组织，视频按时间组织；列出素材证明了什么，丢弃其标题，只保留 promise 需要的论点（博客的背景章节通常是第一个牺牲品）。
9. 工作流第 3 步——选形状：先删除被访谈投入上限排除的形状，再按效率顺序取存活者中最高者，并结合日期与一次性/复利答案重排；把排序、删除项和最终选择说出来。形状在任何一行写出前就决定了时长、钩子和深度。
10. 工作流第 4 步——把素材切成段：每段一个论点，每段约 6 分钟以内，各自有标题；段就是章节。
11. 工作流第 5 步——先写开场节拍，对准 30 秒窗口；先写它而不是最后写，因为它是其余脚本必须满足的约束。
12. 工作流第 6 步——用双栏格式写节拍，每个节拍包含：视觉（画面里是什么）、屏幕动作（发生了什么变化）、旁白（口播原话）、起始状态、核心/可删；一个节拍一个想法，约 20 秒旁白，无法一次录完的节拍就是两个节拍。
13. 工作流第 7 步——预算时长：旁白字数 ÷ 录制者实测语速，加上每个节拍显式估算的死时间（构建、安装、页面加载、刻意停顿）；与目标对比，在录制前删减，绝不在录制后删。
14. 工作流第 8 步——做纯音频通读：关掉屏幕只读旁白列，任何离开画面就失去意义的句子都是指示性句子，需要改写。
15. 工作流第 9 步——只对旁白列做 humanizer 处理（绝不动命令或代码），让它读起来像工程师在解释而不是模型在叙述。
16. 工作流第 10 步——附上录制简报：章节列表、每节拍起始状态、必须避开屏幕的内容、脚本已包含的元数据。
17. 工作流第 11 步——对照通过阈值验证，反复迭代直到通过；未通过前脚本不可开拍。
18. 工作流第 12 步——埋点：命名发布后要看的留存检查点；若环境有持久记忆，存储 promise、观众、形状和刻意舍弃的论点，使系列中下一个视频不与之矛盾或重复。
19. 按效率顺序选形状：报错/修复 > changelog 短片 > 短视频 > 功能/产品走查 > 概念讲解 > 跟做教程 > 深度解析；价值顺序：跟做教程 > 深度解析 > 概念讲解 > 功能走查 > 报错/修复 > changelog 短片 > 短视频；投入顺序：深度解析 > 跟做教程 > 概念讲解 == 功能走查 > 报错/修复 == changelog 短片 == 短视频；合规成本：功能走查 > changelog 短片 > 深度解析 > 其余并列最低。
20. 效率顺序会饿死跟做教程和深度解析（两者价值最高、投入也最高，比值每轮都输），因此当满足条件时仍要提升：评估者必须先动手构建才能决策且访谈给出复利任务时提升跟做教程；技术信誉或招聘是真实目标、无近期日期、投入上限确实允许一个季度时提升深度解析。
21. 开场节拍在 30 秒内完成四件事：用观众自己的话点出问题（报错、症状、他们搜索的任务）；展示结果在运行（不是承诺，是实物本身）；说明前置条件，让不合适的观众在第 20 秒离开而不是第 4 分钟流失；说明时长，因为观众已在寻找它。
22. 开场仪式感只有约 5 秒余量，超过就读作填充：片头动画、频道品牌、“大家好欢迎回来”；安装、配置和凭据绝不属于这里，应放在回报之后或配套仓库里。
23. 代码上屏的节奏决策写进节拍：先讲后演（说明代码块做什么，再展示让观众阅读，旁白与阅读竞争会两败俱伤）；结果出现后保持画面（留出足够阅读输出的静默是脚本化节拍，用解说填满它是开发者视频最常见的节奏缺陷）；绝不敲与教学无关的内容（import、样板、配置、长字符串、重复脚手架预先提供、粘贴或片段展开，只慢慢敲视频要讲的那几行）；展示 diff 而非两个文件（放大、高亮或压暗其余部分来标示承载论点的那一行，并说出是哪一行）；用能承载论点的最小片段（整文件上屏等于什么都没突出）；清理画面（关通知、关无关标签页、不显示没人打开的文件树、无收件箱角标、无个人书签，每次移除都把注意力还给代码并消除意外泄露风险）；可读性下限：终端文字 ≥24pt、编辑器文字 ≥20pt，高对比主题要在手机尺寸播放上验证而非作者显示器上；绝不单靠颜色传达含义。
24. 强化信号手段，因为代码录屏本身处于劣势：用运动、标注、缩放，并在刻意时刻切入人脸；每个手段都是视觉列里的一行，而不是剪辑时的补救。
25. 在写脚本时决定分段边界，它们就是章节：把每个章节标题写在对应段旁，时间码剪辑后填入；章节标题用观众搜索词汇中的任务或结果命名（如“修复 CORS 错误”而非“第二部分”）；主流视频平台要求第一个时间戳 `00:00`、至少三个时间戳、每章 ≥10 秒、按升序排列；文档站播放器通常把同一列表当作字幕提示，一份章节列表两处通用；若能联网，发布前复查当前规则，若不能则沿用这些并说明未复查；没有自然章节边界的视频通常是两个视频。
26. 旁白语言：禁止指示性旁白（“如你所见”“点这里”“把这个改成那个”离开画面零信息，也让自动字幕不可用），改写为整合描述（“我把 `timeout` 字段从 30 改成 5 秒”“打开 Settings，然后 Webhooks 标签页”“请求返回 403 和 `invalid_signature`”）；这是 W3C 的整合描述方法：把视觉信息写进主旁白，再验证纯音频仍能教会内容；在脚本阶段做远比在成片上加独立描述轨便宜，也让视频可作为收听、转录和翻译使用。
27. 旁白其他要求：短陈述句（从句在纸面存活、在耳朵里死亡）；用缩略语、第二人称、开发者在白板上会用的词；标识符首次出现时在脚本里标注发音（`char`、`kubectl`、`SQLite`），避免录制卡壳；不要为理解而注水——语速与参与度正相关但语速只是热情的代理指标，不是杠杆，要带能量而非强行加速，时长按录制者实测语速预算而非表格值；逐字稿还是要点大纲由录制者选择，但必须标出必须逐字说的句子：论点、版本号、术语、行动号召；旁白要能独立成立，因为录制者可能先录音频、先录视频或同时录，只在特定画面下成立的句子会破坏其中两种顺序。
28. 审阅他人脚本或表现不佳的视频时先诊断而非重写：观众离开只有三个原因，逐行可查——逻辑断裂（上一拍结束于 A，下一拍开始于 C，桥接句从未说出）、密度下降（该拍重复屏幕已展示的内容，或把一句话能说清的点绕圈）、不可说的句子（太长、太书面、一口气读不下来）。
29. 按三因模型依次处理：把节拍列成表（编号、主题、功能、状态），再把每个发现评为高风险（观众可能在此离开）、中风险（注意力漂移）、低风险（改了更好）；宁可漏掉小建议也不要埋没高风险项。
30. 审阅的三条诚实规则：先问格式（口播讲解和静音字幕短片评判标准不同，答案会改变一半发现）；保留作者原文（把原句和替换建议并排展示而非覆盖，被拒的建议下一轮仍可追溯）；不要制造发现（脚本流畅就用三行说明）。
31. 把某个节拍当离题删掉前，先检查观众能否在下一个关键时刻推断出缺失含义；若不能，它就是承重论点而非填充；只评判怎么说，绝不评判主张什么——作者的论点、例子和数字属于他们。
32. 按通过阈值迭代直到七道门全过：promise 是一句话且开场节拍在 30 秒内交付它；每个节拍都有精确到可单独重拍的起始状态；纯音频通读仍能教会内容——零指示性句子残留；时长估算包含每拍死时间且落在目标内；每段都有章节标题且每章满足平台最短长度；每个节拍标注核心或可删，且删掉所有可删节拍后仍能交付 promise；屏幕上或旁白中的每个事实主张都是录制者能在录制机器上复现的。第 6 条最常被跳过——没有删减清单的脚本会变成 14 分钟视频，因为剪辑时没人能决定舍弃什么。
33. KPI 只与同形状的自家往期视频比较，绝不与虚构基准比较：开场留存（30 秒后仍在观看的百分比，只评价开场节拍）；流失位置映射回具体节拍（曲线说在哪里，脚本说改什么）；平均观看百分比在同形状内比较（深度解析被当作 changelog 短片看是形状错了而非标题错了）；章节使用（哪些章节被直接跳入，大量直接进入意味着视频被当参考用，应拆分）；配套链接点击及其导向的动作（克隆仓库、文档页、注册）；录制时每拍条数（需要六条的节拍是脚本缺陷，通常是不现实的起始状态）；对峰值保持怀疑：被重看的片段可能是“太棒了”也可能是“我不得不看三遍”，优化前先看评论。
34. 按失败模式对症修复：前 30 秒是设置和问候→把可运行结果移到第 1 拍，设置放到回报之后或仓库里；观众每次都在同一分钟流失→朗读那一拍，通常是两个概念挤在一拍或未解释的敲击；录制时时长翻倍→死时间从未预算，为构建、安装和停顿加每拍估算；旁白复述屏幕文字→改写一个通道，屏幕展示、旁白解释为什么；脚本无法从中间重拍→补起始状态，任何节拍不得依赖上一拍的实时输出；字幕在技术术语上不可读→对照旁白列修正自动字幕，不要重新转录；剪辑时还得有人决定删减→删减清单属于脚本，在录制前决定；代码在手机上不可读→提高字号、放大片段、展示 diff 而非文件；第 3 条时屏幕上出现客户名→机器卫生和种子数据属于录制简报，按拍落实；视频成了功能巡览→回到 promise，删掉每个不能证明它的节拍；走查被写成从头到尾看一遍→分段、给段起标题、每段给起始状态，因为程序性视频是从中间进入并被重看的。
35. 按观众情境调整：个人采用/自助（PLG B2B 混合）——观众既是自助评估的开发者也是通过其分享到达的管理者，一个视频服务两者；把整条路径保持在免费层内，绝不在演示中途露出付费墙，把配套仓库链接放在足够早能被捕获的节拍里；同时应用 B2B 脱敏规则。
36. 销售主导的 B2B、企业或买家侧——第二类观众不会动手，屏幕录制是可转发、可长期保存的文件：对每个显示客户名、租户 ID、内部主机名和定价的屏幕做脱敏或种子化；把版本和限制说出来，因为视频里的过度声称会比它描述的版本活得更久；预期视频会在采购或安全审查中被回放，而那里“视情况而定”是看不见的。
37. B2C/面向个人——同个人采用/自助：观众不欠你任何东西，随时可以离开。
38. 交付物默认包含：Promise（一句话：对 <观众>，这个视频展示 <东西> 在运行）、Beats（表格：# | 视觉 | 屏幕动作 | 旁白 | 起始状态 | 估算秒数 | 核心/可删）、Chapters（00:00 <任务式标题> · <下一个> · <下一个>）、Cut plan（标为可删的节拍，按时长超支时的删除顺序）、Recording brief（起始状态、机器卫生、必须避开屏幕的内容、字幕/描述包）、Runtime（旁白字数 ÷ 实测语速 + 每拍死时间 = 估算 vs 目标）。

适用边界 · 注意事项

• 现场舞台演示——改用 samber/developer-relations-skills@developer-live-demo-design。
• 视频剪辑或播客嘉宾出镜。
• 读者滚动阅读的书面页面、会议演讲、决定本季度做哪些视频、或让视频完成渲染——这些应路由到对应技能而非拉伸本技能。