一篇博文，三种时间：网页幻灯与 Remotion 动效的交付逻辑
内容提要
文章介绍在SUMSEC.ME博客中，如何用网页版PPT和Remotion动效，将同一内容交付给深读、扫读、听讲三种场景。核心是保持Markdown为唯一真源，衍生品继承站点样式，通过Skill规范生成、验收，避免版本混乱。强调动效是论证压缩，非装饰，并给出端到端流程和硬规矩，确保可追溯、可引用、可搜索。
延伸解读
三种时间，三种履约
文章指出，同一篇技术长文在深读、扫读、听讲三种场景下，对读者提出的要求完全不同：深读要可追溯、可引用、可搜索；扫读要结构和图能一眼说明白；听讲要节拍、留白、一页一个命题。这三种时间可能叠加在同一个人身上，比如先收藏、后扫读、再听讲。如果术语漂移、数字不一致、视觉像两个品牌，读者就会怀疑该信哪一版。因此，问题不只是要不要做PPT，而是能否在不自相矛盾的前提下，把同一套内容交付给三种时间。
动效是论证的压缩，不是装饰
作者强调，Remotion动效不是装饰，而是论证的压缩。时间轴会逼你承认自己在画什么，静态图可以把矛盾藏在构图里，但动效节奏不对，自己先觉得假。静态图里能混过去的延迟感，在动效里往往一秒露馅。因此，动效用于扫读时那一眼，帮助读者快速理解论证结构，而不是第二篇正文。
Skill 是规格书，不是自动生成器
文章中的Skill指预置给代码助手的规则包，包含路径约定、验收清单、禁止项。它不保证你讲得好，只减少你在低级坑里装专业的概率。Skill和扔给模型一段话的差别在于，换一篇文章还能走同一套清单；收尾必须进浏览器滚、按、缩放过；禁止项写白。它把编辑权从生成流程里往回拽一道，确保模型帮你生成deck时，不替你决定信息优先级。
可讲性要付维护税
作者认为，经常在写透和讲清之间两头跑，就要算一笔账：可讲性要不要付维护税。仓库把税收成固定工序，对照UI做成可选，视觉尽量跟正文别分家。它替不了你裁内容、改稿子，但能给你很朴素的东西：深读、扫读、听讲三条线同时来的时候，版本和语境上少给自己挖坑。短文、一次性备忘、纯链接聚合，强行做slide多半是制造维护负担。
Q&A
SUMSEC.ME博客如何实现同一篇博文同时满足深读、扫读和听讲三种场景？
SUMSEC.ME通过三条线实现：网页版PPT（用creating-blog-web-ppt将Markdown转为独立单文件HTML幻灯，用于听讲）、Remotion动效（用remotion-blog-motion-assets生成静帧或短循环视频，用于扫读）、站点对照阅读（Jekyll根据front matter挂载deck，提供分栏、仅正文、仅PPT等模式）。核心是保持Markdown为唯一真源，衍生品继承站点样式，并通过Skill规范生成和验收。
为什么在制作网页版PPT时，要先写三句主张再写HTML？
因为拆页本质是编辑权，模型和人容易把密度误当成信息。先写三句主张（visual thesis、content plan、interaction thesis）能强制回答“这一页如果只能留一句话该留什么”，避免一页塞满字、三张图、两条链，导致听众记不住。这能把编辑权从生成流程中拽回来，确保信息优先级由人决定，而不是外包给模型。
Remotion动效在博客中的作用是什么？为什么说动效不是装饰？
Remotion动效用于扫读场景，提供静帧或短循环视频，帮助读者一眼理解论证。动效是论证的压缩，不是第二篇正文。因为时间轴会逼你承认自己在画什么，静态图可以藏矛盾，动效节奏不对会立刻露馅。所以动效能更真实地呈现论证逻辑，而非仅仅装饰。
在SUMSEC.ME中，网页版PPT和Remotion动效的Skill分别管什么？为什么不能混用？
creating-blog-web-ppt管独立单文件网页幻灯，输出与源.md同目录的.html，全内联CSS/JS，不吃Jekyll layout；remotion-blog-motion-assets管栅格静帧、H264短片、可选GIF，输出到YYYY/pic/<主题>/等。混用会导致两类错误搅在一起：网页幻灯怕认知超载，Remotion怕渲染假设不成立（如GIFW和画布W不一致）。分开管理能避免用做slide的直觉去拧视频编码参数。
在Jekyll中，如何通过front matter控制文章是否显示PPT？有哪些命名策略？
通过front matter中的ppt字段控制。策略A：默认同名，如foo.md与foo.html同stem，可不写ppt，布局猜同目录foo.html；策略B：-ppt后缀，如foo-ppt.html，须写ppt: ./foo-ppt.html。ppt也可写成绝对URL，但跨域时scifi.js会做同源判断，不发fetch探测。deck没准备好就别写ppt，否则空iframe占读者时间。
文章页的对照阅读模式有哪些？各自适用什么场景？
对照阅读模式有四种：分栏（左正文右iframe，适合审稿时对照依据和主线）、仅正文（适合可搜索、可复制、可评论的长文阅读）、仅看PPT（适合用节拍验收自己能否讲）、独立打开（新标签打开deck，适合投屏或第二屏）。宽屏默认分栏，窄屏默认纯文，以scifi.js中matchMedia约768px为界。
在制作Remotion动效时，导出MP4和GIF有哪些注意事项？
导出MP4时，--crf只影响压缩，CRF越低越接近无损、文件越大，仓库批量示例用16。要更清晰应改大Root.tsx中的W/H（建议16:9，如1280×720）再重渲，别靠后期缩放假装分辨率。GIF只有256色，循环动效推荐用<video>引用mp4；若仍要GIF，用两阶段ffmpeg（palettegen→paletteuse），且GIFW必须与Root.tsx的W相同。
文章提到的端到端流程是怎样的？改正文时哪些衍生品最容易出错？
端到端流程：md定稿→按creating-blog-web-ppt吐deck→按命名规则写或省略ppt→需要示意再走Remotion，资源进该文pic/→本地jekyll serve检查各模式→单独打开deck测试。改正文时，数字和结论最容易先坏在deck；动效坏得慢，但一改画布就要整套重渲。顺序写死，发版时知道该grep哪里。
文章最后给出了哪些适用于其他静态博客的硬规矩？
硬规矩包括：真源只认一份（以正文或单一Markdown源为准）；幻灯和动效是投影，不是第二份独立副本；颜色字体从站点样式继承；可讲性用显式开关承诺，资源不存在时降级；不迷信自动同步黑盒，每份派生物都经过验收。另外，短文、一次性备忘等不必强行做slide，避免维护负担。
