HTML演示文稿生成器架构深度解析frontend-slides 的零依赖设计与视口适配机制全解【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC你大概率经历过这种现场路演前 5 分钟把昨晚在 27 寸显示器上排好的 PPT 投到投影仪第一页就溢出半屏或者打开手机版链接字号糊成一团、表格被拦腰截断。frontend-slides 是 ECCEverything Claude Code生态中的演示文稿生成技能它的核心承诺只有一句任何屏幕上、任何一页都严格塞进一个视口绝不出现内部滚动条。这份承诺的实现方式不是更聪明的布局算法而是一套把自由度锁死的约束系统。一、黑盒的输入与输出一段大纲如何变成一份单文件演示文稿先不讨论内部实现只看这个黑盒的两端。输入是三种形态之一一段纯文本大纲、一份.pptx文件、一份已有的 HTML 演示文稿再附带一个想要什么感觉的回答印象深刻、活力四射、冷静专注还是受启发。输出始终是同一个东西一个自包含的presentation.htmlCSS 和 JavaScript 全部内联双击就能在浏览器里跑没有任何外部依赖。有意思的是输入和输出之间隔着整整七道闸门每一道都在做减法。把黑盒拆开我把它分成三层来理解。第一层表面机制——七步工作流里藏着哪些硬性闸门从skills/frontend-slides/SKILL.md可以看到完整的工作流它不像写个 PPT那么随性而是强制分阶段检测模式 → 收集内容 → 探索风格 → 生成HTML → 强制适配 → 分屏验证 → 交付清理 ↓ ↓ ↓ ↓ ↓ ↓ ↓ 新建/转换/增强 → 目的篇幅内容状态 → 3份单页预览 → 单文件输出 → 视口铁律 → 5种尺寸实测 → 删临时文件检测模式新建、PPT 转换、增强改造三选一杜绝不知道在做什么就开始做。探索风格不让你回答抽象问题而是直接生成3 份单页预览放在.ecc-design/slide-previews/下每份预览都是自包含 HTML看完挑一个。这就是show, dont tell。强制适配这一步是硬闸门后面详细讲。验证清单必须过 1920×1080、1280×720、768×1024、375×667、667×375 五种尺寸才算合格。为什么这套流程能稳定产出高质量演示文稿因为每一步都在把模糊的美学偏好翻译成可验证的硬性检查项——抽象问题无法自动检查而这一页有没有滚动条可以。第二层底层算法——clamp()、密度上限与断点三件套如何协同表面机制之下真正的技术核心是viewport-base.css里那套约 160 行的约束样式。它的设计目标非常明确让每页恰好一屏成为默认行为而不是靠运气。视口声明 → 密度检查 → 流式缩放 → 断点降级 → 减动效兜底 ↓ ↓ ↓ ↓ ↓ 100vh/100dvh → 超过上限就拆页 → clamp()全量覆盖 → 700/600/500px三档 → prefers-reduced-motion三个关键设计每一个背后都有为什么height: 100vh; height: 100dvh;——dvh是动态视口单位解决移动端浏览器地址栏收起/展开导致的视口抖动。为什么两行都写旧浏览器不认dvh两行声明是渐进增强新浏览器用dvh旧浏览器自动回退到vh。全部字号和间距走clamp()——没有一个写死的像素值。高度断点 700px / 600px / 500px——屏幕越矮越 aggressively 压缩字号和间距甚至在 600px 高度以下直接隐藏导航点和装饰元素。为什么是隐藏而不是缩小矮屏幕上这些元素挤占的是稀缺的纵向空间砍掉它们比压字号更能保住可读性。第三层设计哲学——为什么约束优先反而更能出好作品这三层往里走最底层是一句反直觉的判断给生成器越多的自由度它越容易交出一份平庸且会翻车的东西。所以 SKILL.md 开篇就立了五条 Non-Negotiables零依赖、视口适配强制、用预览代替问卷、拒绝千篇一律的紫色渐变模板、代码要有注释且可访问。这五条不是建议是不可协商。为什么必须零依赖因为只要允许引入外部库生成器就会忍不住用库来解决问题而每个依赖都在增大文件体积、拖慢加载、制造版本地狱。单文件 内联换来的是任何环境双击即用的确定性。二、关键机制的现场推演一张内容页在 375×667 手机上的命运光看规则不够我们实际推演一次。假设用户给了一份内容页素材1 个标题、9 条要点、1 张截图。第 1 步密度检查。内容页的密度上限是1 个标题 4~6 条要点9 条直接超限。系统不会试图把 9 条塞进一屏——那意味着字号跌破可读线。应对方式是把内容拆成两页比如背景 4 条方案 5 条。第 2 步拆页完成后的自适应计算。以--title-size: clamp(1.5rem, 5vw, 4rem)为例在 375px 宽的屏幕上5vw只有约 18.75px低于下限 1.5rem于是取 1.5rem在 1920px 屏幕上5vw高达 96px超过上限 4rem于是取 4rem。这就是 clamp() 的意义——它把字号的合理区间写进了声明本身而不是靠一堆媒体查询去覆盖。.slide { width: 100vw; height: 100vh; height: 100dvh; /* 动态视口高度移动端地址栏伸缩不影响布局 */ overflow: hidden; /* 铁律任何情况下禁止页内滚动 */ scroll-snap-align: start;/* 让滚动吸附在每页起始位置 */ } :root { --title-size: clamp(1.5rem, 5vw, 4rem); /* 字号随视口平滑缩放永不越界 */ --slide-padding: clamp(1rem, 4vw, 4rem);/* 内边距同理避免小屏被挤压 */ }第 3 步断点降级。375×667 的高度落在max-height: 600px之外但宽度 375px 触发了max-width: 600px断点网格从多列变单列标题字号改用7vw保证可读。第 4 步验证。最后按清单在 375×667 下实测无横向滚动、无页内滚动条、网格单列排列。如果过不了回到第 1 步继续拆。如果换一种做法会怎样假设系统改用固定像素字号——在 1920px 上完美到 375px 上标题就占掉小半屏。假设不用dvh——手机上滚动时地址栏收起100vh对应的可视高度变化底部内容会被切掉。假设不设密度上限——9 条要点硬塞一屏字小到看不清讲解时观众只会盯着屏幕眯眼。这三条路每一条都是真实演示事故的源头而 frontend-slides 用约束把它们全部堵死了。另一个值得说的机制导出前为什么要先给 DOM卸妆这套系统允许在浏览器里直接编辑幻灯片按E键进入编辑态编辑完按 CtrlS 保存文件。这里藏着一个非常隐蔽的坑html-template.md里专门写了警示问题编辑态下按 CtrlS代码是拿document.documentElement.outerHTML抓取活 DOM 快照——而此刻的 DOM 里还挂着contenteditabletrue、body.edit-active、按钮上的.active/.show类。任何人打开这个保存成功的文件会看到所有文字都带着可编辑虚线框和编辑横幅仿佛永远卡在编辑模式里。exportFile() { // 先剥离编辑态让序列化出来的 DOM 是一份干净的演示文稿 const els Array.from(document.querySelectorAll([contenteditable])); els.forEach(el el.removeAttribute(contenteditable)); document.body.classList.remove(edit-active); // 序列化活 DOM此刻已是干净状态 const html !DOCTYPE html\n document.documentElement.outerHTML; // 序列化完成后立刻恢复编辑态用户还能继续改 document.body.classList.add(edit-active); els.forEach(el el.setAttribute(contenteditable, true)); // ... 存为 Blob 并触发下载 }为什么必须先卸妆、后保存、再复原因为outerHTML是当前页面状态的快照而不是你想象中的源文件你看到的正在编辑的界面和应该被保存的内容是两个不同的东西如果不主动区分保存下来的就是编辑界面本身。类似的坑还有一处悬停显示编辑按钮的 hover 链会因pointer-events: none断裂CSS 兄弟选择器方案不可行必须用 JS 加 400ms 延时超时来处理。三、数据与事实与传统 HTML 演示框架的逐项对比零依赖、单文件不是口号而是能从仓库文档里逐一核对的硬指标。下面把 frontend-slides 与常见的 HTML 演示框架Reveal.js、Slidev 这类放在同一张表里对比对比维度传统 HTML 演示框架frontend-slides交付物形态多文件工程 npm 依赖单文件自包含双击即用构建链路需要打包器改一行要重新构建无构建步骤改完刷新即生效视口适配策略固定断点 大量媒体查询clamp() vh/dvh 强制 overflow:hidden内容密度控制依赖作者自觉按幻灯片类型设硬性上限动画触发库内置或手写监听Intersection Observer 加.visible类交付前验证无强制清单5 种分辨率硬性校验再看一组可以直接在仓库里找到的数字12 种样式预设按印象深刻 / 活力四射 / 冷静专注 / 受启发四类情绪映射从 Bold Signal 到 Terminal Green 各有完整的字体、配色与动效体系。密度上限表标题页 1 标题 1 副标题内容页 4~6 条要点或 2 段功能网格最多 6 卡片代码页最多 8~10 行图片页单图控制在 60vh 以内。断点体系高度 700px / 600px / 500px 三档递进压缩宽度 600px 单列降级。验证清单桌面、平板、手机竖屏、手机横屏共 5 类尺寸全部必须无溢出。PDF 导出默认 1920×1080 逐页截图每页约 1~2MB--compact模式切到 1280×720文件体积再降约 50%~70%。视觉探索每次只生成 3 份自包含的单页预览而不是一份 30 页的试错稿。这些数字说明了什么它们说明质量在这个系统里不是一个形容词而是一组可执行、可验证的边界条件。密度上限是静态的clamp() 是声明式的断点是分层的——三层叠加才把任意设备上不翻车从愿望变成了默认行为。四、落地使用指南从克隆仓库到产出 PDF想亲手试路径非常短。ECC 本身就是一套 agent 技能集frontend-slides 只是其中一个技能不需要单独安装任何运行时依赖git clone https://gitcode.com/GitHub_Trending/ev/ECC # 然后在 Claude Code / Codex / Cursor 中加载 ECC # 对 agent 说一句 # 用 frontend-slides 把这份大纲做成 HTML 演示文稿风格偏科技感剩下的流程由技能自动接管生成 3 份预览让你挑 → 产出presentation.html→ 按五种尺寸自检。本地打开就三条命令按系统选一条open presentation.html # macOS xdg-open presentation.html # Linux start presentation.html # Windows要导出 PDF适合邮件、打印、发群里仓库自带脚本bash scripts/export-pdf.sh presentation.html # 1920x1080每页约1-2MB bash scripts/export-pdf.sh presentation.html --compact # 1280x720体积再降50%-70%已有的.pptx也不用重新排版脚本scripts/extract-pptx.py用 python-pptx 把文字、图片、演讲者备注全部抽成 JSON 结构再走一遍同样的风格探索流程。五、三个值得继续追问的问题这套约束系统的价值已经很清楚但它也把三个开放问题摆到了桌面上第一clamp() 是线性缩放够用吗目前字号在 5vw 与 4rem 之间做线性插值但 4K 大屏和折叠屏的感知字号并不是线性的。有没有可能引入非线性标尺让超大屏上的标题不再显得空洞第二密度上限是静态规则能不能动态判定现在的 4~6 条要点上限是拍脑袋的经验值但放不放得下本质是个几何问题——让生成器在交付前用真实渲染结果测一次 overflow再决定拆页位置会不会比预设上限更准第三12 种预设如何社区化预设目录已经证明了风格可以模板化那下一个自然的问题是社区贡献的预设如何评审、如何命名、如何在不破坏视口铁律的前提下扩展如果你对这类用约束换取确定性的设计感兴趣frontend-slides 的源码就在skills/frontend-slides/下STYLE_PRESETS.md里的 CSS 基座和 12 套预设都是完整的参考实现值得一行行读一遍——尤其是那份viewport-base.css它可能是你能找到的、最克制也最严谨的响应式基座之一。【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考