一个 21K Star 的开源项目，专治「AI 味」PPT

过去半年，AI 生成 PPT 的工具遍地开花。但你有没有发现一个规律——它们做出来的东西长得都差不多？

紫白渐变背景，圆角卡片布局，Inter 或 Roboto 字体，整齐到令人窒息的对称排版。拿到手一看就知道：AI 做的。

这个现象有个名字叫 “AI slop”——AI 审美疲劳。模型倾向于输出统计学上的“均值审美”，安全、正确、乏味。你让 100 个人用同一个模型做 PPT，得到 100 份长得差不多的东西。

今天要聊的这个开源项目，偏偏要跟这个趋势对着干。

Frontend Slides，一个 Claude Code 插件，GitHub 上 21K star，专门用来生成网页演示文稿。它的核心理念写在 README 里：

“bye-bye, purple gradients on white.”

翻译过来就是：别再搞那些紫白渐变了。

21K Star 的底气从哪来

先说清楚这个项目到底是什么。

Frontend Slides 不是传统软件。你不会 npm install 它，它也没有图形界面。它是一个 Claude Code 的 Skill（技能包）——一组精心编排的 Markdown 文件，告诉 AI 编程助手如何生成高质量的 HTML 演示文稿。

输入一段关于演讲内容的描述，它会生成一个零依赖的单 HTML 文件，浏览器打开就是一份带动画、带转场的完整演示文稿。不需要网络，不需要构建工具，十年后照样能打开。

它的功能不只是从零创建。如果你有一个 .pptx 文件，它也能帮你提取内容，转换成网页版演示文稿——文字、图片、演讲者备注，全部保留。

为什么会火？因为踩中了三个痛点：

设计门槛高。 大部分工程师和产品经理不是设计师，但经常需要做分享。PPT 工具本身不难，难的是做出“好看”的东西。

AI 生成的太丑。 通用 AI 助手（ChatGPT、Gemini）做 PPT，审美停留在“均值”水平。能用，但拿不出手。

工具链太重。 reveal.js 需要 Node.js 环境，Slidev 需要 Markdown 知识，Marp 要装 VS Code 插件。Frontend Slides 输出的是一个 HTML 文件，扔到哪都能用。

「AI 味」是怎么产生的

理解 Frontend Slides 的设计哲学，得先搞明白“AI 味”是怎么来的。

大语言模型的训练数据决定了它的审美偏好。训练集里 Inter、Roboto 使用频率最高，紫白渐变是近十年最“安全”的配色方案，对称式卡片布局是设计系统的默认选择。模型在做的是概率预测——选最可能的选项。

最可能的选项，往往就是最无聊的选项。

Frontend Slides 的应对策略分三层：

第一层：显式禁止列表。 SKILL.md 里直接写死了不能用什么。Inter、Roboto、Arial、system-ui，统统拉黑。紫白渐变，明令禁止。对称式仪表盘布局，不给用。这不是建议，是硬约束。

第二层：人工策展的预设风格。 项目内置了 12 套风格预设，分四类：

• 暗色系（Bold Signal、Electric Studio、Creative Voltage、Dark Botanical）
• 浅色系（Notebook Tabs、Pastel Geometry、Split Pastel、Vintage Editorial）
• 特殊风格（Neon Cyber、Terminal Green、Swiss Modern、Paper & Ink）

每套预设不是简单的配色方案，而是完整的设计系统——字体搭配、色彩层级、间距比例、签名式视觉元素，全部精确定义。

第三层：34 套大胆模板。 来自配套的 beautiful-html-templates 仓库。名字就很说明问题：8-bit Orbit、Neo-Grid Bold、Liquid Chrome……每套模板都有鲜明的个性，不存在“安全的中庸选择”。

但最精妙的设计决策不在模板本身，而在于怎么让用户选模板。

与其问用户“你喜欢什么风格”（大部分人说不出来），不如直接生成三张预览图让他们选。一张安全预设、一张大胆模板、一张出其不意的“野路子”。用户看到具体画面，一秒就能做出判断。

这个交互设计的核心洞察是：审美判断是视觉的，不是语言的。

渐进式加载：34 套模板塞不进上下文怎么办

这里有个技术问题，乍一看不起眼，实际上决定了整个架构。

Frontend Slides 有 34 套模板。每套的完整设计规范（design.md）包含 YAML 格式的颜色值、字体定义、间距系统、组件规范——信息量很大。34 套全加载进 AI 的上下文窗口，光是模板数据就要占掉大量 token。

传统前端解决这个问题的方案是懒加载——用到哪个加载哪个。但 AI 编程助手的“内存”是上下文窗口，没法像浏览器那样动态请求资源。怎么办？

Frontend Slides 用了三层渐进式加载：

Tier 1：索引文件。 selection-index.json 是一个精简目录，只有每个模板的名称、标语、情绪标签、适用场景。34 套模板的元数据压缩到很小。

Tier 2：预览卡片。 当 AI 筛选出几个候选模板后，只读取对应的 preview.md——一个极小的文件，包含一个标题页的风格预览。

Tier 3：完整规范。 用户做出最终选择后，才加载那唯一一套模板的完整 design.md。

这个设计模式值得所有做 AI Skill 的人学习。本质上，这是给 AI 看的懒加载——通过精心的信息分层，让 AI 在有限的上下文窗口里做出高质量的决策。

对比传统前端的懒加载方案：

这不是性能优化，而是架构层面的约束适应。AI 编程助手的上下文窗口是有限资源，就像 2010 年前端的带宽是稀缺资源一样。你必须在信息量和决策质量之间做取舍。

固定舞台模型：为什么不做响应式

Frontend Slides 有一个反直觉的技术决策：不做响应式设计。

在 2026 年，一个前端项目不做响应式，听起来像是倒退。但仔细想想，PPT 本来就不是响应式的——你在 16:9 的投影仪上放幻灯片，不会因为屏幕小就重新排版。

具体实现是这样的：创建一个固定 1920×1080 像素的画布（.deck-stage），然后用 JavaScript 计算缩放比例：

const scale = Math.min(
  window.innerWidth / 1920,
  window.innerHeight / 1080
);
// 应用 transform: scale(factor) 居中显示

内容永远在 1920×1080 的坐标系里布局，缩放只是整体的等比变化。宽了就 letterbox（上下黑边），窄了就 pillarbox（左右黑边）。内容不会重排，布局不会变。

这意味着你在 27 寸显示器上做的演示文稿，在手机上打开也是一模一样的——只是小了。

这个决策的代价是放弃了小屏设备上的可读性。但项目的判断是：演示文稿的首要场景是投影和桌面，移动端只是“能看就行”。与其做出一个在所有设备上都凑合的响应式版本，不如在主要场景上做到完美。

这个取舍很果断。实际上，reveal.js 的很多用户也会遇到响应式带来的排版错乱问题。PPT 的本质是“固定画布上的视觉设计”，硬要做响应式反而违背了媒介特性。

六阶段工作流：给 AI 看的说明书

Frontend Slides 的核心不是代码，而是一个叫 SKILL.md 的文件。这个文件定义了完整的六阶段工作流：

整个工作流的设计思路是渐进收窄。Phase 0-1 是发散（搞清楚要什么），Phase 2 是收敛（锁定风格），Phase 3 是执行（生成结果），Phase 4-6 是后处理。

值得注意的是 Phase 1 的“内容密度”决策。用户必须二选一：

• speaker-led（演讲驱动）：低密度，每页一个核心观点，大字号
• reading-first（阅读优先）：高密度，信息完整，可独立阅读

没有“中等密度”选项。这是故意的。项目认为“中等密度”就是“两边都不讨好”——演讲时太密，阅读时太浅。逼用户做二选一的决策，反而能产出更好的结果。

还有一个细节：每个生成的 HTML 文件默认内置了行内编辑器。鼠标悬停左上角或按 E 键，就能直接在浏览器里修改文字，Ctrl+S 保存。这不是什么大功能，但解决了一个真实痛点——拿到 AI 生成的 PPT 后，你几乎总需要微调文案。

这不只是个 PPT 工具

Frontend Slides 的意义不在于它做了一份漂亮的 PPT。

它示范了一种全新的软件形态：给 AI 看的说明书，就是软件本身。

传统的软件是给人写的——有 API、有 UI、有配置文件。Frontend Slides 是给 AI 写的——有 SKILL.md（流程说明）、有 STYLE_PRESETS.md（设计规范）、有 selection-index.json（数据索引）。人类用户从来不直接跟这些文件交互，AI 才是这些文件的“用户”。

这个模式正在成为一种趋势。Claude Code 的 Skill 系统、OpenAI Codex 的插件生态、Gemini CLI 的工具链，都在往这个方向走。当 AI 编程助手越来越强，“怎么让 AI 做出好东西”就变成了一个新的设计问题。

Frontend Slides 给出了几个值得借鉴的答案：

显式约束比模糊指令更有效。 与其说“做得漂亮一点”，不如直接说“不能用 Inter、不能用紫色渐变、不能用对称布局”。AI 在清晰的约束下反而能产出更好的结果。

用视觉决策代替语言描述。 让用户描述审美偏好是低效的——大部分人说不出自己要什么。直接展示选项让他们选，效率和满意度都更高。

信息分层是上下文管理的核心技巧。 渐进式加载不只是优化，更是架构决策。在设计 AI Skill 时，必须考虑“AI 需要在什么时候看到什么信息”。

对抗 AI 的“均值化”倾向需要刻意设计。 模型天然倾向于输出安全的、中庸的结果。如果你想要有个性的输出，就得在系统层面设计对抗机制——禁止列表、人工策展、极端选项。

说句掏心窝的话，这个项目让我对“AI 时代的软件设计”有了新的理解。以前我们设计软件是设计给人用的交互，现在还得设计给 AI 用的交互。Frontend Slides 做到了两件很难的事：让 AI 做出不像 AI 做的东西，同时把这种能力封装成了可复用的 Skill。

21K star，实至名归。