mshen6666/HTML-PPT-Editor 教程
2026-07-10 3391434
2026-07-10 0
yihan1944/ppt-cc 最容易被误会的地方,是把它当成“把内容渲成一组 PPT 图片”的工具。仓库里的 PPT-CC 走的是 Claude Code + MCP 的本地链路:先解析文本、PDF、DOCX、Markdown 或 URL,再规划 DeckPlan,再用 python-pptx 渲染出可继续编辑的 .pptx。所以新手判断它是否合适,核心标准是自己是否需要 PowerPoint 原生对象,而不是页面第一眼是否漂亮。
它的价值在于把“材料到演示稿初稿”这段流程接到 Claude Code 里:输入材料、触发 /ppt,拿到能打开、能改字、能调图表和表格的 PPTX。第一个限制也要先说清楚:它不是云端一键网页服务,第一次要准备 Python 3.11+、uv,并把本地 MCP server 注册进 Claude Code;没有这一步,单独复制一句需求不会生成文件。

yihan1944/ppt-cc skill 更适合需要后续人工微调的场景,比如咨询式汇报、研究报告转演示、项目复盘、方案提案和会议材料初稿。它支持的输入包括普通文本、Markdown、PDF、DOCX 和 URL,生成端则偏向咨询风格主题:深墨蓝、鼠尾草绿、Calibri 字体,以及标题页、目录页、章节页、双栏页、图表页、表格页、金句页、关键结论页和结束页等常见页面类型。
这里的“可编辑”很关键。README 里明确写的是原生可编辑 PPTX,使用真实 PowerPoint 对象,而不是把每页做成图片或 SVG 塞进幻灯片。对新手来说,这意味着跑通后要重点检查两件事:文件能不能在 PowerPoint、WPS 或 Keynote 里打开;页面里的文字、表格、图表对象能不能继续选中修改。只要你的工作后面还有审稿、改数据、换标题和调版式,这类产物就比静态图片更稳。
安装前先确认本机能运行 Claude Code,并且终端里能调用 uv。仓库的依赖由 uv sync 处理,技术栈包括 Python 3.11+、python-pptx、FastMCP、Pydantic v2、PyMuPDF、python-docx、httpx 和 BeautifulSoup4。第一次不要直接拿几十页正式报告试,先把依赖和 MCP 注册跑顺。
git clone https://github.com/yihan1944/ppt-cc.git
cd ppt-cc
uv sync
claude mcp add --transport stdio ppt-cc -- uv --directory . run python -m server.main
上面第四行是在 Claude Code 里登记一个 stdio 传输的 MCP server。登记完成后,回到 Claude Code 里输入 /ppt 加需求,Claude Code 才能调用这个仓库里的工具链。仓库 README 里的示例是让它做一个关于 AI 趋势的演示文稿,也可以把报告文件交给它处理;新手第一次建议把主题缩小,先验证最短链路。

最小测试可以从 5 页小主题开始,让它先证明解析、规划和渲染链路都通了。比如在 Claude Code 里输入:
/ppt 做 5 页团队例会汇报,主题是本周项目进展
如果这一步能正常触发,接着去仓库的 output/ 目录看有没有新的 .pptx。README 的架构图里把结果写成 output.pptx,项目结构也把 output/ 标为生成 PPTX 的目录。不要只看命令是否结束,还要把文件打开,确认标题页、目录页、内容页和结尾页是否都生成,文字对象是否可编辑。
跑通后再换成真实材料。文本和 Markdown 通常最容易稳定;DOCX、PDF 和 URL 要看原文结构是否清楚。报告里有明确章节、表格和列表,Planner 更容易整理成 DeckPlan;如果材料本身是扫描图片、杂乱网页或没有层次的长段落,生成结果就容易偏粗,需要先把原文整理干净。
它能帮你从材料生成咨询风格 PPT 初稿,但不等于替你完成最终提案。品牌模板很严格、图表数据必须逐项校准、PDF 主要由扫描图组成、网页内容需要登录才能读取,或公司要求固定母版时,都应该把 PPT-CC 当作起稿工具,而不是交付终点。
更稳的做法是先用小主题确认 /ppt 可以调用,再用一份结构清楚的 Markdown 或 DOCX 试正式流程。拿到 output/ 下的 PPTX 后,重点检查文字是否完整、图表是否对应原始数据、页面类型是否符合汇报节奏。这样用 yihan1944/ppt-cc skill,它解决的是“从材料到可编辑演示初稿”的时间成本,而不是替代后面的审稿和排版判断。