这不是一篇兰溪牛肉面的美食文章，而是一次 AI 做 PPT 的实践复盘。我用“兰溪牛肉面制作过程”当测试题材，真正想看的，是 guizang-ppt-skill 这类工具在真实项目里能不能把 PPT 从一个想法快速推进到可展示、可打包、可发布的状态。
这次做出来的不是传统 .pptx，而是一份横向翻页的网页 PPT。最终文件是一个 index.html，配合图片和本地动效脚本，可以直接在浏览器里打开，也适合后面放到 GitHub Pages 或个人网站上展示。
我关心的不是“AI 能不能生成几页幻灯片”，而是更实际的几个问题：
- 从一个主题到一套 PPT，流程能不能跑通。
- 这个 skill 的风格模板在真实内容里是否好用。
- AI 生成页面之后，哪些地方还必须人工判断。
- 如果后面要推到 GitHub，文件应该怎么组织。
效果展示：PPT 第 2 页和第 3 页
下面两张图是这次网页 PPT 成品里的第 2 页和第 3 页。第 2 页用来展示一碗面的制作总览，第 3 页进入具体步骤，把“面先有筋”这个动作做成一页完整的杂志风版式。
为什么拿兰溪牛肉面做测试
我选兰溪牛肉面，不是因为这次要重点研究牛肉面，而是因为它很适合测试网页 PPT 的完整流程。
它有清楚的制作顺序：和面、切肉、备料、爆炒、煮面、合锅、收束。这个顺序天然适合拆成一页一页的展示内容。
它也有很强的画面感：面粉、手擀面、牛肉、雪菜、笋片、番茄、锅气、热汤，这些元素都适合放进电子杂志风的页面里。
更重要的是，这个题材不需要复杂的数据核验。它能让我把注意力放在 AI 做 PPT 的流程本身：结构怎么拆、风格怎么选、图片怎么配、最后怎么交付。
所以这次的主角不是牛肉面，而是工作流。
这次用到的 skill 是什么
这次核心使用的是 guizang-ppt-skill。
它的定位很明确：生成横向翻页的网页 PPT。它不是传统 PowerPoint 生成器，也不是一个多人协作编辑工具，而是更像一个静态网页 slides 生成器。
这个 skill 里面有两套主要风格：
- 电子杂志风：更适合人文、美食、城市、故事、项目复盘这类内容。
- 瑞士国际主义风：更适合数据、系统、产品、技术、发布会这类内容。
这次我选择了电子杂志风。
原因很简单：兰溪牛肉面这个题材需要热气、食材、手艺和地方感。如果用瑞士风，页面会更像信息图，适合讲产业链或数据分析；但这次我更想测试的是“美食过程能不能被做成一份有观看节奏的网页 PPT”。
从结果看，电子杂志风是合适的。它让页面更像一篇可以翻看的美食专题，而不是一个冷冰冰的流程说明。
从一个主题拆成 8 页
这次真正节省时间的地方，不是 AI 帮我写了几句话，而是它很快帮我把主题拆成了可以展示的页面结构。
最后这份 PPT 做成了 8 页：
- 封面：兰溪牛肉面，一碗热气里的手艺。
- 总览：一碗面的六个瞬间。
- 和面：面先有筋。
- 切肉与备料：兰溪味道藏在一把配料里。
- 爆炒锅气：锅气起来。
- 烹制流程：从沸水到合锅。
- 吸汤入味：不是浇上去的味道，而是煮进去的味道。
- 收束：热气散开的时候，兰溪的味道才真正出现。
这个结构不是菜谱。
如果按菜谱写，页面会变成“第一步放什么、第二步煮多久、第三步加什么调料”。那样可以讲清楚操作，但不一定适合展示。
我更想测试的是展示型 PPT：每一页只抓一个动作或一个感受。封面负责定调，总览负责建立全局，过程页负责讲制作动作，最后一页负责收束味道。
这让我更确定一件事：AI 做 PPT，第一步不是美化页面，而是拆结构。
结构定得好，后面的图片和版式才有位置。结构定错了，页面再漂亮也只是拼贴。
图片是这次最容易出问题的地方
这次最有价值的坑，出现在图片环节。
早期版本里，页面已经有图，但那些图更像占位图或临时插图。它们能让页面看起来不空，但还没有真正达到“电子杂志美食专题”的质感。
后面我重新生成并替换了一组图片，效果才明显提升。但这里真正关键的，不是生成了 8 张图，而是每一张图要放在正确的位置。
图片不能按生成顺序硬塞。它必须和页面任务对应：
- 封面需要成品图，因为第一眼要知道主题。
- 和面页需要揉面图，因为文案讲的是“面先有筋”。
- 备料页需要切牛肉和配料图，因为这一页讲地方风味。
- 锅气页需要爆炒图，因为这一页承担视觉转折。
- 流程页需要煮面图，因为它讲从沸水到合锅。
- 吸汤页需要面条入汤图，因为这一页讲“味道是煮进去的”。
- 收尾页需要成品夹面图，因为它对应最后入口的瞬间。
这一点很像做网站文章配图。图不是装饰，它要承担叙事任务。
AI 可以帮我生成素材，但不能自动知道哪张图最适合哪一页。最后决定成片质量的，还是编辑判断。
网页 PPT 和传统 PPT 的差别
这次做完以后，我对网页 PPT 的交付边界更清楚了。
传统 PPT 通常是一个文件。发出去，对方打开就能看。
网页 PPT 不一样。它至少包含三个部分：
lanxi-beef-noodle-ppt-final-clean/
├── index.html
├── images/
│ ├── final-01-cover.png
│ ├── final-02-dough.png
│ ├── final-03-beef-slicing.png
│ ├── final-04-ingredients.png
│ ├── final-05-wok.png
│ ├── final-06-boil-noodles.png
│ ├── final-07-absorb.png
│ └── final-08-closing.png
└── assets/
└── motion.min.jsindex.html 是主文件，images/ 是图片，assets/ 里放本地动效脚本。
这里最容易出问题的是路径。
如果只发一个 HTML，图片会丢。 如果图片文件名改了，但 HTML 里没改，图片也会丢。 如果动效脚本没有放进去，离线展示时也可能出问题。
所以网页 PPT 做完之后，最后一步一定不是“看起来生成了”，而是要打开最终目录里的 index.html 检查一遍：图片是否都在、翻页是否正常、打包目录是否干净。
这一步很小，但它决定别人能不能顺利打开。
这个 skill 实际好不好用
这次用下来，我觉得 guizang-ppt-skill 的价值很明确：它适合快速做出有风格的网页 slides。
它最强的地方有三个。
第一，它让项目很快进入可观看状态。不是停留在大纲和文字，而是直接生成一个可以翻页的页面。
第二，它提前约束了风格。字体、配色、版式、动效、翻页方式都有模板，不需要每一页从零设计。
第三，它天然适合发布。因为最终是静态 HTML，所以可以放到 GitHub Pages、个人网站或其他静态服务里。
但它也有边界。
如果要做公司正式汇报、多人协作、复杂表格、可编辑图表，传统 PPT 还是更合适。这个 skill 更像是“个人分享 / 项目展示 / 视觉化文章”的生成工具。
这次实践以后，我对它的判断是：
它能把从 0 到可展示初稿的时间压得很短，但不能替代选题判断、结构判断和素材判断。
AI 和 skill 负责加速执行，人还是要负责判断方向。
后面推到 GitHub 怎么放
如果后面把这个案例推到 GitHub，我会把它当成一个完整项目，而不是只放一个 HTML。
推荐结构是这样：
ai-ppt-lanxi-beef-noodle/
├── README.md
├── docs/
│ └── review.md
├── deck/
│ ├── index.html
│ ├── images/
│ └── assets/
└── assets/
└── ai-ppt-workflow-mindmap.svgREADME.md 放项目简介、预览地址、使用工具和打开方式。 docs/review.md 放这篇复盘文章。 deck/ 放最终网页 PPT。 assets/ 放流程图这类文章配图。
这样仓库就不只是一个 PPT 文件，而是一个完整案例：有成品、有过程、有复盘，也方便后面继续迭代。
这次最大的收获
这次测试让我更清楚地看到，AI 做 PPT 的速度优势不是“自动替我想好一切”，而是把重复执行的部分接过去。
它可以更快地生成页面骨架，更快地套用模板，更快地组织图片路径，更快地把结果变成一个可打开的网页。
但它不能替我决定：
- 这个主题到底适合什么风格。
- 内容应该拆成几页。
- 每页要完成什么表达任务。
- 哪张图和哪段文字真正匹配。
- 最后应该怎么交付给别人。
所以这次不是“AI 自动做了一份牛肉面 PPT”，而是跑通了一条更有复用价值的流程：
主题输入 → 风格选择 → 页面拆解 → 网页 PPT 生成 → 图片匹配 → 本地校验 → 打包发布 → 文章复盘兰溪牛肉面只是测试样本。真正留下来的，是一套用 AI 快速做网页 PPT 的方法。
以后换成别的主题，我会继续沿用这个顺序：先定结构，再定风格，再生成页面和图片，最后检查交付。工具让速度变快，但让内容成立的，仍然是清楚的编辑判断。
返回记录页