第一轮：裸跑 Codex，效果一般

测试方式

直接让 Codex 生成一个网页 PPT（单 HTML 文件，横向翻页），主题设定为一个技术分享的演示文稿。

实际输出的问题

排版混乱是最大的感受。

具体来说：

1. 字体毫无层次——标题、正文、注释全用同一种无衬线字体，字号差异也不够大。整页看过去一片灰色，视觉焦点无处可落。

2. 配色失控——Codex 自己拼了一组渐变背景和彩色卡片，但色彩之间没有体系，看起来像从三套模板里各取了一部分拼在一起。深色页和浅色页也没有节奏规划，连续几张暗底让人视觉疲劳。

3. 布局随意——图文排列没有网格对齐的概念，图片比例不统一（有的16:9有的4:3混着来），文字和图片之间的间距也不一致。部分页面的内容甚至溢出了视口。

4. 动画生硬——Codex 加了 CSS 动画，但只有一种 fadeIn 效果从头用到尾，所有元素同时出现，没有错落感。

5. 内容密度失控——有的页面塞了太多文字，有的页面又只有一行标题加一张图，节奏感很差。

6. 没有章节感——全程平铺直叙，缺少幕封页、大数字页、引言页这类节奏调节手段，十几页看下来像在滚一篇长文档。

小结

Codex 的代码能力没问题，HTML/CSS/JS 都能写。

但 PPT 是一个高度依赖设计规范的输出物——字体层级、配色体系、页面节奏、图文比例，这些不是"写代码"能自然解决的问题，而是需要预制的设计约束来兜底。

裸跑 Codex，等于让一个没有设计意识的程序员凭感觉排版，结果可想而知。

第二轮：加装 guizang-ppt-skill，效果质变

什么是 guizang-ppt-skill

guizang-ppt-skill 是一个为 Claude Code 设计的 PPT 生成技能插件。它的核心思路是：把设计规范固化成约束，让 AI 在框架内填内容，而不是从零画白板。

它提供的东西包括：

• 5 套预设主题（墨韵经典、靛蓝瓷白、森林墨绿、牛皮纸、沙丘），每套主题的色值完全锁定，AI 不许自创颜色
• 10 种页面布局模板（封面、幕封、大数字、引言配图、图片网格、流程管线、大引言、前后对比等），AI 只需选模板填内容
• 三级字体体系（衬线用于标题、无衬线用于正文、等宽用于标签），严格绑定，不可混用
• WebGL 流体背景（暗色页用全息色散 shader，亮色页用螺旋涡流 shader），自动切换
• 节奏规则：不许连续3页同色系，8页以上的 PPT 必须包含 hero light 和 hero dark 页面
• 5 种动画配方（级联、英雄、引言、方向、管线），按页面类型自动匹配

测试方式

在 Claude Code 中安装 guizang-ppt-skill，用 /guizang-ppt-skill 触发同样的 PPT 生成需求。

实际输出的改善

1. 字体层级清晰，一眼分出主次

标题用衬线体（Noto Serif SC），正文用无衬线体（Noto Sans SC），标注用等宽体（IBM Plex Mono）。

三级字体配合字号阶梯，页面的信息层次非常明确——不会把标题当成正文，也不会把注释当成重点。

2. 配色克制，整体感强

选了"墨韵经典"主题后，整份 PPT 只有黑、白、暖米色三个色值。没有渐变、没有彩色卡片、没有花哨的背景色。但正是这种克制，让内容本身成为了视觉焦点——像在读一本排版精良的杂志。

3. 布局有网格感，图文不打架

每个布局模板都有明确的网格系统：图片用固定 height:Nvh 控制尺寸，不依赖 aspect-ratio；文字和图片各占固定列数；间距统一。不再出现图片比例混乱或内容溢出的问题。

4. WebGL 背景只出现在 hero 页，克制但高级

普通页面几乎是纯色背景，内容清晰可读。只在章节封面（hero 页）才露出 WebGL 流体背景——暗色页是全息色散效果，亮色页是螺旋涡流效果。

这个"80%克制 + 20%惊艳"的比例，比全程炫技好看得多。

5. 页面节奏有呼吸感

幕封页隔开章节、大数字页突出数据、引言页放慢节奏、管线页展示流程——不同类型的页面交替出现，看 PPT 的体验从"滚文档"变成了"翻杂志"。

6. 动画服务内容，不是为了动而动

级联动画让列表项依次出现，引言动画让文字逐行揭示，管线动画要手动触发每一步——每种动画都在帮观众理解信息结构，而不是分散注意力。

核心结论

一句话总结：AI 生成 PPT 的瓶颈不在代码能力，在设计约束。

Codex（或任何代码 Agent）能写出语法正确的 HTML/CSS/JS，但"好看"需要的是预制的设计规范——字体绑定、色值锁定、布局模板、节奏规则。

guizang-ppt-skill 的价值就在于把这些规范固化成约束条件，让 AI 在框架内创作，而不是从零开始凭感觉排版。

这个思路其实适用于所有 AI 生成设计类内容的场景：先定义规则，再让 AI 填内容。比"给 AI 一个需求然后祈祷"靠谱得多。