weekly-video

name	weekly-video
description	把一个视频（YouTube / B站 / 本地录制）做成一份"观点提炼报告"——一个自包含的 HTML，带侧边栏目录、可回放的时间戳播放按钮（点一下视频就跳到那一秒）、按价值排序的结论、以及编者的行动清单。当用户给出一个视频链接并说"提炼观点 / 做成报告 / 本周最佳视频 / 分析这个视频 / 给学员分享这个视频"时使用。默认输出中文；原视频是英文或双语时输出中英双语（中文正文 + 英文原话）。这个 skill 关心的是**观点**，不是逐字纪要，也不是给说话人打分（打分请用 interview-analysis）。

每周最佳视频 · 观点提炼报告

这个 skill 要产出什么

一份 单文件 HTML，读者打开就能：

1. 3 分钟内拿到这个视频里最值钱的 6–8 条结论（在最顶上，卡片式）；
2. 每条结论旁边有 播放按钮，点一下播放器就跳到原话那一秒，画面和声音一起对上——读者可以随时验证"编者有没有转述歪"。 播放器一开始是页面顶部的大屏（不会找不到），往下读时自动钉到右下角变小屏，播放不中断；
3. 左侧常驻目录，按"从最有价值到最细节"排序；
4. 清楚区分：哪些是嘉宾说的（带时间戳），哪些是编者的判断（青色 .editor 块，不带时间戳）。

这不是纪要，不是逐字稿，不是打分报告。核心问题只有一个： 一个人看完这份报告，能不能拿走 5 条可执行的东西？

---

硬规矩（每次都要遵守）

1. 观点优先，流程其次。 不要按视频时间顺序复述"他先说了 A 再说了 B"。 按 "对读者的价值" 重排：最反直觉、最可执行、最有数据支撑的放最前面。 00 节永远是「先看这个：N 条最重要的结论」。
2. 每个事实性结论必须挂时间戳。 没时间戳的段落 = 编者的话，必须放进 .editor 块并标明。 报告最后一节固定是「来源与口径」，按用户全局规则里的 A/B/C/D 分级标注， 并且明确写出自己最没把握的 2–3 条。
3. 引述要短。 一条引述一两句话，够支撑观点即可。不要贴大段转写、不要把整份 transcript 塞进 HTML。 转写文件留在本期目录里供下次核对，但 .gitignore 挡住它——公开仓库里不放别人视频的完整文本。
4. 语言跟着原片走。
   • 纯中文视频 → 只出中文，别硬凑英文。
   • 英文 / 双语视频 → 中文正文承担解释，关键原话用英文原文附在下面（.quote 里加 <span class="en">）。
5. 时间戳必须准。 data-t 是秒，按钮文字是 mm:ss，两者必须一致—— 写完一律跑 scripts/check_report.py 自检，不要靠眼睛。
6. 只提炼「主角」的观点。 一期视频通常有主持人和嘉宾，先跟用户确认谁是主角（默认是嘉宾）。 主持人的话只在两种情况下收录：他把嘉宾逼出了更清楚的表述，或者他提出了一个值得对照的相反判断—— 收录时要写明是主持人说的。
7. 临时文件不留。 中间产物处理完删掉；本期目录里只留 index.html / meta.txt / transcript.srt / blocks.txt / media/video.mp4， 后三样被 .gitignore 挡住，不进仓库。

---

工作流

第 1 步 · 抓字幕 + 视频

skills/weekly-video/scripts/fetch.sh "<视频URL>" "2026/<日期>_<主角>-<主题>"

• 优先用官方字幕（时间戳准、无幻觉）；没有才回落本地 whisper。
• whisper 回落时必查幻觉：整段重复同一句（"Thank you." / "字幕志愿者…"）就加 --condition-on-previous-text False 重跑。
• 视频本体一定要下，落在 <本期>/media/video.mp4。理由见下面「播放器」一节—— 在线播放器在 file:// 下是坏的，本地文件才是唯一稳的回放方式。
• 画质取 H.264（avc1）最高档（脚本默认 ≤1080p）。不要无脑 bestvideo： 1440p/2160p 在 YouTube 上只有 VP9/AV1 编码，Safari / QuickTime 可能直接播不了。

第 2 步 · 通读

fetch.sh 会顺手生成 blocks.txt（把 SRT 合并成 20 秒一块的时间戳文本，一小时视频约 200 行）。 完整读一遍，不要只读开头和结尾——最好的观点经常埋在 60% 处。

边读边记三样东西：

• 反直觉的（读者以为 X，嘉宾说其实 Y）
• 有分母的（带数字、比例、样本量的判断——这是最稀缺的）
• 可执行的（读者明天就能做的动作）

第 3 步 · 排结构

先写目录，再写正文。典型骨架（按需增删，但 00 和最后两节固定）：

节	内容
00	先看这个：N 条最重要的结论（.takes 卡片，每张一句话标题 + 3 行解释 + 播放按钮）
01	现状 / 数据：把最硬的数字做成 .stats 四宫格
02–07	主题分块。每块 = 一个观点簇，配 1–2 条原话引述 + 一个 .editor 编者按
08	延伸话题（创业 / 行业等，与主线相关但不是主线）
09	本周行动清单（编者写，ol.steps，7 条以内，每条能在一周内做完）
10	金句索引（按时间顺序，全是播放按钮，方便重听）
11	来源与口径（A/B/C/D 分级 + 最没把握的几条 + 本报告未收录什么）

第 4 步 · 写 HTML

用 assets/report_shell.html 作骨架（CSS/播放器/主题切换都在里面），替换 {{...}} 占位符， 把正文塞进 {{SECTIONS}}。可用的组件见 references/components.md。

播放按钮写法（data-t 是秒，文字是 mm:ss）：

<button class="pb" data-t="386">06:26</button>

第 5 步 · 自检

python3 skills/weekly-video/scripts/check_report.py <本期>/index.html <本期>/transcript.srt

查：时间戳是否自洽、是否超出片长、目录锚点是否都对得上、占位符有没有漏替换。 然后在浏览器里真的点两三个播放按钮——UI 行为只能靠实测，不能靠读代码下结论。

第 6 步 · 收尾

• 更新仓库根 README.md 的期号索引表；
• 删掉临时文件（中间产物）。媒体和转写留在本地，靠 .gitignore 挡住即可。

---

播放器（这一节踩过坑，别改坏）

播放器按这个顺序自己挑，写在 report_shell.html 里，一般不需要动：

顺序	条件	行为
①	media/video.mp4 存在	原生 <video>：秒开、有声、离线可用、seek 精确。默认走这条
②	没有本地文件，且页面是 http(s) 打开的	YouTube IFrame JS API，可无刷新 seek
③	没有本地文件，且页面是 file:（或 data:/blob:）	YouTube 普通 iframe，每次跳转 ?start= 重载一次
④	10 秒还没就绪（断网/被墙）	点时间戳改成在新标签打开 YouTube 对应位置

为什么必须本地文件优先： YouTube 的 JS API 需要一个合法 origin。 双击打开 HTML 时 origin 是 "null"，YouTube 直接拒绝并在播放器里显示 「视频播放器配置错误」——这不是代码 bug，是它的策略，绕不过去。 而双击打开正是最常见的用法，所以在线播放器不能作为主路径。

两个已知坑，改代码时注意：

• 钉住 = 给同一个元素加 position:fixed，不是把它搬进另一个容器。 搬 DOM 会让 <video> / <iframe> 重新加载，播放当场断掉。
• 静态服务器必须支持 Range 请求。 python3 -m http.server 不支持， 表现是"一 seek 就弹回 0"。GitHub Pages 支持。本地双击打开没有这个问题。

非 YouTube 视频（B站 / 本地录制）： 下好 media/video.mp4 就行，走 ① 分支， 其余逻辑不用改；把 FGT_VIDEO_ID 留空即可。

语气

诚实、具体、不恭维。评价视频时可以说"这段没讲清楚""这个数字是单一来源，别当基准"。 编者按要有立场——读者是来看你怎么想的，不是来看你复述的。 但立场和转述必须视觉上可分辨：带时间戳的是他说的，青色块是你说的。