【实践记录】PPT 管线能否替代 HyperFrames 日报视频线：逐能力对表与可行性判定
分析日期：2026-09-04（同日追记 frontend-slides 第三路线）。范围：仅 ai-news-digest 视频线（article-to-video 明确不动，用户点名）；出片路径约束：不走 WPS「输出为视频」（用户点名）。证据来源：2026-09-03/04 本机一手实测（详见《PPT转视频方案分析与 HyperFrames 对比》§七实操增补）+ 交付面盘点（ai-news-digest references/scripts 精确引用）+ 动效验证稿实测（放映/advTm/音频三环节）+ frontend-slides 全量克隆审读（《frontend-slides 调研报告》）。
判定结论
技术上可以替代，但不建议切换主产线；建议立项为「备份产线」，以月度手动演练保鲜。
- 动机①帧渲染提速：PPT 录屏管线出片 ≈5 分钟（实时 1× 录制+后处理）vs hyperframes 帧渲染 16-43 分钟——单段确实快一个量级；但全跑 ~4h 的主耗时在打分/写作/Stage C worker 全程，帧渲染只占约 15-20%，切产线的总时长收益 <15%，为提速换产线不划算（§5）。更便宜的提速路径：hyperframes render quality 降档试验（high→medium 对 1080×1920 竖版的影响需实测一次）、帧 worker 并发已到位（ADR-032）。
- 动机②备份路线：成立。hyperframes 是外部插件（CLI 全局 0.8.20 与插件缓存 0.8.6 双轨漂移有先例、版本升级存在破坏在产管线的风险），PPT 管线全部关键能力都有等价物（§1），且本周已验证其中约 60% 的组件（§6）——是合格的 Plan B。frontend-slides 组合线（§3）作为备份梯队第二候选：它是三条路线里唯一「无头全自动+出片前可程序化预览」的，但组件验证度为零、且本质是自建轻量渲染器。
- 三条路线一句话定位：PPT 管线（§1/§2）＝借 WPS 当播放引擎，验证度最高但桌面会话依赖；装 Office＝真全自动但要授权；frontend-slides+Playwright（§3）＝HTML 直渲，工程模式最现代，但等于自造一个小 hyperframes。
一、逐能力对表（替代性判定核心证据）
| 能力 | hyperframes 现状（引用） | PPT 管线等价物 | 判定 |
|---|---|---|---|
| 产物规格 1080×1920 / 30fps / H.264+AAC | render 直出；video 门硬断言（video_artifact.py：h264+aac、恰 1+1 流、1080×1920、30fps±0.01、duration>0） | 录屏：WPS 放映 9画布在 2160 高屏幕上渲染区 1215×2160 → ffmpeg crop 居中区 → scale 1080×1920（超采样）、-r 30、libx264+aac | ✅ 达标，需后处理链 |
| 词级字幕（3-12 字/组+逐词 karaoke 高亮，暖白板+橙描边，带位 y1370-1660） | captions.html 合成轨（captions.mjs build + align_captions.py 语义重分组 + patch_caption_band.py 安全区上移） | 关键发现：不是缺口。 words[] 词级时间戳在手（audio_meta），生成 ASS 字幕——\k 卡拉OK 逐词高亮是 ASS 原生机制；暖白板 #F5EDE3+橙描边 #FF6A2B 用 ASS Style（BorderStyle=3 底板+Outline 色）复刻；组切分直接复用 align_captions 的 3-12 字分组逻辑；ffmpeg subtitles 滤镜烧录 | ✅ 机制等价，样式近似 |
| VO-paced reveal 动效 | GSAP 全语法（弹性/过冲/count-up 微调/呼吸 idle，词点驱动） | PPT timing XML：fade/wipe 按词点 delay——注入已验证（63 动效全过 WPS 结构校验）；放映中动画播放待人工验收 | ⚠️ 降级：无弹性 easing、无 count-up、无无限呼吸（advTm 到点即翻页） |
| 两秒留存 hook 门 | check_hook_opening.py：H1-H3 读 SCRIPT+words 时间轴；H4 正则解析 hyperframes 帧 HTML（hero 在场/count-up 起点/入场时间） | H1-H3 原样复用（数据源不变）；H4 改为解析 pptx timing XML 的 hero 节点 delay/duration | ⚠️ 小改造（一个解析器） |
| video 完成门 | ffprobe 现场+零账本 | 产物是 mp4+双 PNG，门原样可跑，零改动 | ✅ |
| SFX | HF 插件内置 19 个（STORYBOARD 每帧 sfx 字段） | ffmpeg amix 后混：音效文件从 HF 库目录取用（.media 缓存），时间点沿用 STORYBOARD | ⚠️ 自建混音脚本 |
| BGM | 无（audio_meta bgm，全 skill 无 BGM 键） | 无 | ✅ 平 |
| 双封面 1080×1440 / 1080×810 | cover-video-template.html + snapshot + DPR 修正 | PPT 封面页 WPS COM 转 PDF→PyMuPDF 高分出图→PIL 裁 3/4（COM→PDF 链路 2026-09-04 已验证可靠） | ✅ |
| 出片前 QA 预览 | snapshot/lint/帧 worker 逐帧自检（豁免前移 ADR-032） | 无对应物：动画效果出片前无法程序化预览；只能出片后抽帧+人眼 | ❌ 最大盲区 |
二、不走 WPS 导出的出片路径（约束下的方案空间）
- A（推荐主力）WPS 放映 + ffmpeg gdigrab 录屏 + 后混：WPS 只当「动画播放引擎」，视频由 ffmpeg 抓屏生成——绕开 WPS 导出器。已验证环节：F5 SendKeys 启动放映流程跑通、advTm 自动换片实测工作（P1→P2 按时切换实测）、每页旁白 mp3 嵌入+自动播放（用户已听到）。旁白不录系统声：mp3 源文件按帧 duration_s 顺序拼接后混（advTm=duration_s，音画天然对齐），SFX 同法 amix。掐头去尾：黑帧检测或音频互相关。脆弱点如实列出：桌面会话独占（出片 3-4 分钟内不能动机器，鼠标一动就穿帮）、DPI/多屏布局/窗口焦点/UAC 弹窗敏感、需无人值守时段跑（深夜档）。
- B 装 Microsoft Office：PowerPoint COM
CreateVideo全自动、动画全保、VertResolution 可控——唯一真全自动路径。判断依据：若定位是备份产线，不值得为此购授权；若日后决定切主产线再议（届时 B 优于 A：无桌面会话依赖、无脆弱点）。 - 死路清单（已实锤，勿再试）：WPS COM 视频导出（V13 官方文档无 CreateVideo、视频枚举值 37/39 静默降级存 pptx）；LibreOffice（放映可播动画但零视频导出能力）；Aspose.Slides Python 版（只出 GIF）；Office 网页版（无导出视频）。
三、frontend-slides：第三条路线（HTML 直渲）专析
依据《frontend-slides 调研报告》（2026-09-04 全量克隆审读）。先正名：frontend-slides 本体不是视频产线——它是「面向编码代理的单 skill，从零或从 PPTX 生成零依赖 HTML 演示文稿」，固定舞台 1920×1080 横版、人在场翻页放映、没有任何渲染 MP4 的通道（PDF 导出丢动画、HTML→PPTX 无管道）。把它纳入本分析的原因是：其 HTML 产物可与 Playwright 组合出「无头全自动 HTML→视频」路线（下称 FE-Slides+PW 组合线），且该组合恰好命中 PPT 管线的两大弱点。
组合线形态：frontend-slides（或直接手写 HTML，SelfMediaTools 项目封面/帧模板本就是 HTML 系）产出竖版 HTML slides → Playwright recordVideo 录制「程序自动翻页放映」（每页停 advTm 时长、页内词点 reveal 用 JS/animation-delay 驱动）→ webm → ffmpeg 转 H.264+AAC、旁白后混同 §二A。
能力对表（增量项，其余沿用 §一）：
| 能力 | FE-Slides+PW 组合线 | 判定 |
|---|---|---|
| 无人值守全自动 | 无头浏览器，无桌面会话依赖、可并发——三路线唯一无头全自动且零授权 | ✅ 碾压 §二A |
| 动效表达 | CSS/JS 全语法（animation-delay 词点驱动、transform 全家桶），接近 GSAP | ✅ 优于 PPT timing |
| 词级字幕 | words[] 在 HTML 内原生渲染 karaoke（JS 定时），样式自由 | ✅ 原生，优于 ASS 后混 |
| 出片前 QA 预览 | Playwright 任意时刻截图/DOM 检查——可程序化预览 | ✅ 补上 PPT 管线最大盲区 |
| 产物规格 | recordVideo 跟 viewport 定尺寸（竖版可设 1080×1920）→ ffmpeg 编码 | ✅ 可达标 |
| 竖版画布 | frontend-slides 固定舞台 1920×1080 横版是 NON-NEGOTIABLE 不变量——竖版要么改其 viewport-base.css（动核心不变量），要么只用其生成纪律、舞台自建 | ⚠️ 需改造/绕开 |
| 时序确定性 | CSS 动画实时播放录制，时点有 ±几十 ms 抖动（vs hyperframes 确定性逐帧渲染）；要确定性需 CDP Animation seek 逐帧截（工程量另计） | ⚠️ 弱于 hyperframes |
| 组件验证度 | 零——SelfMediaTools 项目未做过一次组合线实验（vs PPT 管线 60%） | ❌ 最大保留项 |
定位判定：FE-Slides+PW 组合线的本质是自建一个小 hyperframes（时间轴驱动+竖版舞台+渲染器全要自建或改造）——hyperframes 已是成熟的确定性渲染引擎，为替代它而自造轮子，在「备份产线」定位下仅当 A 路线的桌面会话约束不可接受时才值得升级；但作为「若 hyperframes 生态生变」的中期重建方案，它的工程底座（HTML+Playwright+ffmpeg，全仓库内自控、零外部插件依赖）是最健康的。frontend-slides 本体的直接价值不在视频线：横版讲演型 deck（人在场放映）场景它是现成答案，其 skill 工程模式（三预览流/三级渐进披露/踩坑成文）另见调研报告 §9 五条借鉴点。
四、差距与代价清单（如实）
- 动效表达降级：fade/wipe/缩放预设 vs GSAP 抗议海报式快节奏（snappy/overshoot/呼吸）——日报视频的视觉签名会变钝；hook 帧「2.4T 终值 t=0 在场+脉冲确认」可用 PPT 近似（终值在场=静态在场，脉冲=强调动画），但 count-up 微调等无对应。
- QA 盲区：hyperframes 出片前有 snapshot/lint/帧 worker 三层过程 QA；PPT 管线动画效果只有出片后抽帧可查——质量保障降一档，首次全链必须人眼验收。
- 录屏环境脆弱性：见 §二A。
- 新增工程量：五个新脚本——audio_meta→timing 翻译器（词点映射逻辑本周已验证，批量化是纯工程活）、录屏控制器（F5/ESC/ffmpeg 编排）、对齐裁剪编码链、ASS 字幕生成器、封面 PIL 裁剪；外加 hook 门 H4 解析器改造。一次性 1-2 天+长期维护面。
- 发布面零改动：抖音视频模式前置门读 canonical mp4+双封面（publishing.md），产物达标即放行。
五、提速量化对比
| 段 | hyperframes 全跑 | PPT 管线（估） |
|---|---|---|
| 帧构建+worker | Stage C 拆层后 worker 段 16-43min 方差 | PPT 构建+timing 注入 <1min |
| 渲染/出片 | render —quality high（分钟-十分钟级） | 实时录屏 1×（~3min 片≈3-4min）+后处理 ~1min |
| 全流程 | ~4h（晚间档） | 前段（打分/写作/深读/TTS）完全相同，总时长收益 <15% |
结论：提速收益集中在渲染段且被前段稀释；更便宜的提速先试 hyperframes render quality 降档（一次实测定夺），不动产线。
六、备份产线蓝图（建议定位）
- 触发条件（建议）：hyperframes 升级破坏在产管线且 24h 内无法回退/修复；或插件生态变化（商业转向/停维）。
- 备份梯队（两候选）：首选 A＝WPS 放映+录屏后混（§二A，组件验证度 60%，桌面会话约束在备份场景可容忍——触发时深夜跑一次即可）；第二候选 B2＝FE-Slides+Playwright 组合线（§三，零验证度但当 A 的桌面会话约束不可接受、或触发条件升级为「长期重建」时启用——无头全自动+出片前可预览的工程底座更健康）。
- 已验证资产（本周）：build_daily_style.js（帧源→PPT 逐 hex 换算复刻）、inject_full_timing.py（63 动效词点注入+WPS 结构校验通过）、advTm/音频嵌入放映实测、WPS COM→PDF（封面源）、qa_check/render_pdf（QA 链）。
- 待补组件：A 线——录屏控制器+对齐裁剪编码链、ASS 字幕生成器、封面 PIL 裁剪、hook 门 H4 解析器、SFX 后混；B2 线——竖版舞台 HTML 模板、Playwright 自动翻页录制器、词点 reveal 驱动层（全部未动工）。
- 保鲜方式：备份线不做常备自动化（维护成本不值），月度手动演练一次全链（用最近一期目录跑通即归档）。
七、明确不替代的范围
article-to-video 零改动（用户点名）；ai-news-digest 主产线不切换；本周的暗场 deck/日报风复刻/动效版继续作为独立交付物与实验线存在。
八、信息源
- 本机实测（2026-09-03/04）：WPS COM 全套定案、timing 注入与放映实测、日报风复刻与 QA 全程——详见《PPT转视频方案分析与 HyperFrames 对比》§六/§七。
- ai-news-digest 交付面盘点（2026-09-04）：video-finalize.md/publishing.md/video-hyperframes.md/video-captions.md、video_artifact.py、align_captions.py、check_hook_opening.py、patch_caption_band.py、video-profile.json、config.json 精确引用。
- frontend-slides 全量克隆审读（2026-09-04）：《frontend-slides 调研报告》——仓库形态/六阶段工作流/固定舞台不变量/三层资产/CJK 支持与局限；本分析 §三 的能力面事实全部取自该报告。