科普讲解长视频

环境事实（本机已确认，勿重复探测）

• node: C:\Users\DELL\.workbuddy\binaries\node\versions\22.22.2-3\node.exe

• ffmpeg/ffprobe: C:\Users\DELL\AppData\Local\Microsoft\WinGet\Packages\Gyan.FFmpeg_Microsoft.Winget.Source_8wekyb3d8bbwe\ffmpeg-8.1.2-full_build\bin\ffmpeg(.exe)

• Chromium: C:\Users\DELL\AppData\Local\ms-playwright\chromium-1243\chrome-win64\chrome.exe

• playwright-core: C:\Users\DELL\.workbuddy\binaries\node\workspace\node_modules\playwright-core

• shell 是 PortableGit bash，PATH 缺 coreutils：命令前先 export PATH="/c/Users/DELL/.workbuddy/binaries/PortableGit/versions/1.2.0/bin:/c/Users/DELL/.workbuddy/binaries/PortableGit/versions/1.2.0/usr/bin:$PATH"

流程

• 脚本化内容：把源材料蒸馏成 scenes 数组（见 index.html 顶部 SCENES）。每场含 type/start/end + 内容字段。总时长 = 最后一场 end。

• 写 index.html：数据驱动的信息图引擎（本 skill 的 scripts/index.template.html 可复用骨架）。场景类型：intro / overview / dim(维度) / cta。每场子元素带 .anim，用 data-in（秒）控制错峰入场。

• 快速校验（务必先做）：两种校验手段，优先用 probe.cjs：

• scripts/probe.cjs <时间点...>：DOM 量测，输出可见场景（含 opacity，验证无叠加）、越界元素清单（R/B/L/T 像素超出量）、指定容器的尺寸与折行数。这是本机唯一可靠的排版校验方式——多模态模型常读不了 PNG 截图，且量尺寸比目视更准。

• scripts/shot.cjs [时间点...]：截图存档，给人看。不要每次改完就整段重录（每次约 6 分钟）。

• 录制：scripts/record.cjs（替换 EXE/FILE/TOTAL）。Playwright recordVideo 录 webm。

• 转码：ffmpeg -y -i in.webm -c:v libx264 -pix_fmt yuv420p -crf 21 -preset medium -movflags +faststart out.mp4

• 抽帧 ffmpeg -ss <t> -i out.mp4 -frames:v 1 -q:v 2 chk.png 复核 → present_files。

系列片去重（做第 2 集起必查，血泪）

「不同题库」≠「内容不重复」。 两个不同来源的题库（如 store-location 23 题 / store-knowledge 24 题），考点可能大面积重叠——因为底层是同一套行业知识。《二》初版按「误区」切题，做完才发现 6 个误区里 4 个《一》已完整讲过，占旁白约六成，整片作废重做。

• 去重比对必须只统计「可见文案」：grep 整份 index.html / gen_audio.py 会把注释也算进去（/* 已避让前两集术语：漏斗 / 曝光 … */ 会把自己列的词全部命中）→ 报出一堆假重复。正确做法——只取旁白（正则 "text":"(.*?)" 从 gen_audio.py 抽）和画面文案（const SCENES = [ 到「时间轴」注释之间那段），再 count。我先用整文件比对得出「漏斗 2 次 / 曝光 3 次」，切到可见文案后发现真实只剩 1 处（旁白里一个「曝光量」），改成「声量」即归零。

• 切题前先做覆盖度比对（不能等做完）：

• 把上一集的考点逐条列出（SCENES 里的 laws[].n / name / summary）。

• 把本集候选素材逐条列出（题库逐题 q + why）。

• 建一张「本集项 → 上一集是否讲过 → 判定」表。重叠率超三成就要换切题角度。

• 换角度优先按「维度」切，不按「并列清单」切。反面清单（误区）极易和正面清单（法则）撞车——因为它们是同一批知识点的正反面。有效区分：

• 《一》= 经验法则（靠右截流、黄金街宽…「往哪挪」）

同一片知识，一个讲现象、一个讲机理，即可零重复。

• 《二》= 数据框架（漏斗五层、商圈占比、评估权重、评分线…「怎么判断」）

• 成片后做双向关键词验证（脚本化，可复现）：把两集旁白全文取出，各挑 15–30 个核心术语互相 count 一遍。

• 残留重复则是结构性撞车，靠改词救不回来，必须换切题角度；

• 干净的结果应是双向全 0（《二》实测 16 + 28 个词双向 0 次）。

• 验收标准：不是「读起来不太一样」，而是上一集的核心术语在下一集出现 0 次。这个可以用脚本证明，别凭感觉。

特例：同一源页已经出过「介绍片」时（《五》踩盘调研的坑）

用户说「做成科普型的，注意和之前那个 XX 视频做区隔」时，先别猜「之前那个」指哪一条——去磁盘上找。典型情况是：同一个源页面早先做过一条竖屏 60 秒工具介绍片（<proj>/<tool>视频/timeline.json + render.py，或 <项目名>_60秒介绍片_<署名>.mp4），那条片子的旁白就是把源页的步骤按顺序念一遍。

• 这会让常规去重失效：常规做法只比对本系列前一集，但介绍片是「另一条产品线」，不打进系列、也没被算进比对对象。结果是你以为「这是新内容」，其实观众已经看过一遍了。

• 规则：find 全盘搜 *踩盘* / *实地* / *考察* / *survey* / *60秒*，找到介绍片后把它的 timeline.json（旁白）和 render.py（字幕/卡片文案）也并入去重语料的 ROOTS。

• 区隔靠「元逻辑」而不是「换词」：介绍片讲的是清单本身（6 步分别是什么），知识长视频要讲清单的元逻辑（为什么是这个顺序 / 每一项怎么查才算数）。同一份材料的「内容层」vs「方法层」，天然零重复；只换措辞是救不回来的。

• 视觉一并反转：介绍片通常沿用工具页原色（浅色）+ 竖屏；长视频若系列前几集都是深色，可考虑首次切浅色底（如米黄纸 + 朱砂红「检查单风」），一眼就能看出不是同一条片子。浅色底同时天然契合「打勾 / 划掉」的检查单隐喻。

特例：新集与旧集出自「同一个题库」时（《六》实体店营销判断力的坑，最凶险）

用户给两个源链接看起来是「不同题库」（lab/yx-quiz vs lab/yx-quiz-shiti），实则是同一套方法论的线上版与实体店版——同一个 lab 目录、同一个命题框架、六维度结构相同，只是案例从线上换成实体店。这类同源关系，常规去重（比对本系列前一集）会完全失效，因为你比的是「结构」而撞的是「案例」。

识别信号（动手前 30 秒就能查）：

• 两个 URL 在同一个 lab 子目录下（/lab/yx-quiz → /lab/yx-quiz-shiti），或命名只差一个后缀。

• 两边题库都是「六维度 / 相同维度名」的结构。

• 用户提供的新题库里，出现了旧集旁白里已经讲过的品牌名。

处理规则：

• 去重必须下沉到「案例级」，不能只比术语。建「本集每道题 → 旧集是否讲过该案例 → 判定」表，逐题过。

• 判据要分强弱两档：强判据＝品牌名（沃尔玛、界界乐）+ 案例独有数据点（满九十九、九块九、LBS、最近门店）；弱判据＝通用词（会员、梯度、分层）——后者会大面积误报（实测 15 题命中里 11 题是假撞车）。

• 品牌词重合 ≠ 案例撞车，必须回读上下文。实测误报模式：旧集讲奈雪会员充值、新库有奈雪水蜜桃助力——品牌同名、手法完全不同，可用。判断要点是「讲的是不是同一个动作」。

• 真正的撞车集中在「旧集讲得最透的那一段」——通常是旧集的收尾高潮段（观众记忆最深）。《六》的 4 个真撞车案例全部落在《三》的 d5「第五个盲区·实体零售」。找到那一段，把它的案例清单整个拉黑。

• 区隔靠「换视角 + 换结构」，不靠换案例。同源题库换案例照原结构讲，观众会觉得「这不就是上集换个例子」。有效的三层区隔：

• 视角：旧集消费者视角（别被套路）→ 新集店主视角（我该怎么搭）；

• 结构：旧集「六个并列盲区」（散点）→ 新集一条闭环链（流程，六格递进）；

• 视觉：换一套与全系列都不同的底色+主色。

• 给维度名做一次「翻译」。题库的维度名是运营术语（引流到店/转化客单/留存复购…），观众记不住；翻成动作链口语（让人来/让人买/让人再买/让人带人/把人圈住/让人记住），既好记又天然构成「一条链」，顺便把结构区隔做掉了。

• 挖一个旧集没有、且只属于新集场景的「地基概念」当串线。《六》用的是服务半径（实体店专属，前五集 0 次）——它同时解释了「内衣店敢让人到店领」「钱大妈敢开业前拉群」「索菲亚必须留资邀约」三个看似无关的案例，比按维度硬讲有说服力得多。

• 中段可有「该维度都讲完了」的天然截图点：六格链在第 3 格讲完时正好过半，是插入静态速查卡的理想位置（见下节）。

口径一致性（内容类视频的高频硬伤，动手前必查）

源材料里常有多套数字口径并存（封面文案、SEO description、正文、题库名录），它们往往互相矛盾。例：题库封面写「12 条法则」，逐题数却是 15 个考点——因为封面是「每类取 3 条凑数」。

• 动手前：把源材料的所有数字口径抓出来并列比对（grep 关键词计数 + 读正文），确认哪个是权威口径。

• 常见陷阱：字段名 ≠ 内容分类。如题库 tag:"原理" 只是题型标签，不是考点名，别拿它当考点去重。

• 关键词计数法：某考点在源文件里出现 0 次，未必是「自己编的」——可能是源材料用了不同表述。必须回读该项对应的正文（如 why 字段）确认。

• 一旦发现不一致，别自行编造成因。我犯过一次：把「12 vs 15」的差异解释成「源材料把两条合并成一条」，实际是「封面每类取 3 条凑数」。回源逐条核对后再写结论。

• 改口径时，列全所有出现位置（title / 角标 / 正文卡片 / 配音文案 / 总览页），漏一处就还是不一致。配音文案改了必须重录 TTS 并重排时间轴。

• 片内口径必须自洽：片头/片名说「六个误区」，某一页旁白却写「这是八大误区里最常见的一个」——观众会卡在「说八大为何只讲六个」。《二》就是这么踩的：源材料确实出现「八大误区」字样，但只能自证 6 个，于是全片统一为「六个」，改口径时顺手把这类「引用源材料原文」的残留一并清掉（grep 关键词逐个确认，注意区分「该改的」和「核实记录里该留的」）。

• 旁白文案只能有一份真源：gen_audio.py 的 SCENES 和脚本 md 的「旁白全文」是两份拷贝，改一处不改另一处就会漂移（《二》md 落后了 6 处修订）。规则：改文案先改 gen_audio.py，再写脚本从它同步 md（正则解析 {"id":"x", "text":"..."} 后逐段替换）；校验要点——注意 \r\n 行尾会让 \n{2,} 类正则失配，可用 (.*?)(?=\n### |\n---) 这类末尾锚定，别依赖空行。

常见问题