PowerPoint 演示文稿(PPT)最耗时间的地方,通常不是“打字”,而是把内容组织成清晰结构,再把结构落到版式、图表、配色和页面细节里。
CodeBuddy Skills 的价值在于:它不只是让人工智能(AI,Artificial Intelligence)写一段大纲,而是让 AI Agent(能够自主规划步骤、调用工具并产出文件的人工智能代理)具备处理真实办公文件的能力。通过 document-skills,CodeBuddy 可以创建、编辑、分析 PowerPoint、Word、Excel、PDF 等文件,尤其适合把材料快速转成可汇报的 PPT 初稿,再由人做最后校对和微调。
整体过程可以理解为一条自动化流水线:
flowchart LR
A[输入需求、材料、模板] --> B[CodeBuddy Agent 理解任务]
B --> C[选择 document-skills]
C --> D{任务类型}
D --> E[从零创建 PPT]
D --> F[编辑已有 PPT]
D --> G[套用模板生成 PPT]
D --> H[从 Word / HTML / Markdown 转 PPT]
E --> I[生成并验证 PPTX]
F --> I
G --> I
H --> I
I --> J[人工检查与微调]
1. CodeBuddy Skills 解决的核心问题
传统做 PPT 会卡在四类问题上:
| 问题 | 典型表现 | Skills 能提供的帮助 |
|---|---|---|
| 缺模板 | 没有统一样式,只能到处找模板 | 基于品牌色、主题和受众自动设计页面 |
| 缺结构 | 知道要讲什么,但不知道怎么排 | 根据汇报目标生成目录、主线和页面内容 |
| 缺资源 | 图表、排版、美化成本高 | 自动生成图表、布局和可编辑 PPTX |
| 缺时间 | 改格式、调字号、挪元素很耗时 | 通过多轮指令批量修改页面 |
document-skills 不是一个单独的“PPT 生成按钮”,而是一组可被 Agent 调用的工作流、脚本、依赖和约束。例如:
- 从 HTML(超文本标记语言)渲染出幻灯片;
- 解包 PPTX,直接修改 Office Open XML(OOXML,Office 文档底层 XML 标准);
- 分析模板里的文本框、标题、正文和占位符;
- 替换文本后重新验证文件是否可打开、内容是否溢出。
这也是它比普通对话式生成更稳定的原因:AI 负责规划和内容,Skill 负责落地到文件格式。
2. 安装 CodeBuddy 与 document-skills
CodeBuddy 有两种常见入口:
| 入口 | 适合人群 | 特点 |
|---|---|---|
| CodeBuddy IDE(Integrated Development Environment,集成开发环境) | 非开发者、产品、运营、项目管理人员 | 图形界面更友好,适合通过对话完成办公文件任务 |
| CodeBuddy Code | 开发者、DevOps(开发运维一体化)工程师、命令行用户 | 适合终端操作、脚本化和项目级配置 |
2.1 安装 CodeBuddy IDE
下载地址:
https://copilot.tencent.com/ide
安装后创建一个本地工作目录,用来存放输入材料、模板文件和最终生成的 PPTX。
2.2 安装 CodeBuddy Code
终端执行:
npm install -g @tencent-ai/codebuddy-code
codebuddy update
安装完成后输入:
codebuddy
进入 CodeBuddy Code 交互环境。
3. 安装 document-skills
document-skills 来自 Anthropic Skills 仓库,能力覆盖 docx、pptx、pdf、xlsx 等办公文件类型。
仓库地址:
https://github.com/anthropics/skills
3.1 CodeBuddy IDE 配置方式
CodeBuddy IDE 通常支持用户级 Skill 和项目级 Skill:
| 配置级别 | 作用范围 | 适合场景 |
|---|---|---|
| 用户级 Skill | 所有工作目录可用 | 常用办公能力,建议放这里 |
| 项目级 Skill | 只在当前项目目录可用 | 某个项目专用的模板、脚本或流程 |
如果使用图形界面导入 Skill,需要把 document-skills 解压或放置到对应配置路径,然后在 Skill 配置页导入。导入成功后,应能看到与 pptx、docx、pdf、xlsx 相关的 Skill 项。
3.2 命令行配置方式
可以把 Skills 放到本地用户目录或项目目录中。
# 用户级 Skills
mkdir -p ~/.codebuddy/skills
# 项目级 Skills
mkdir -p .codebuddy/skills
克隆仓库后,确保 document-skills 位于 CodeBuddy 能扫描到的 Skill 路径下:
git clone https://github.com/anthropics/skills.git
如果使用 CodeBuddy Code 的插件市场方式,可以在交互环境里执行:
/plugin marketplace add anthropics/skills
/plugin install document-skills@anthropic-agent-skills
4. 第一次生成 PPT:从网站内容到演示文稿
一个最小可用的 Prompt 可以这样写:
面向非专业开发者,基于 https://copilot.tencent.com 网站内容,写一份 CodeBuddy 介绍 PPT。
要求:
1. 背景色使用腾讯蓝 #0161FF;
2. 页面风格简洁、偏商务科技;
3. 受众是第一次了解 CodeBuddy 的用户;
4. 输出文件命名为:CodeBuddy-腾讯蓝版本.pptx。
这个 Prompt 给了 AI 四类关键信息:
| 信息类型 | 示例 | 作用 |
|---|---|---|
| 受众 | 非专业开发者 | 决定内容深度和术语解释方式 |
| 信息来源 | 网站 URL | 决定材料从哪里来 |
| 视觉约束 | 腾讯蓝 #0161FF | 决定品牌色和页面基调 |
| 输出要求 | 文件名、PPTX | 决定最终产物 |
更稳妥的 Prompt 模板可以写成:
请使用 document-skills 生成一份 PPTX。
主题:
<要汇报的主题>
受众:
<CEO / 技术评审 / 晋升委员会 / 新用户 / 客户>
目标:
<希望听众理解什么、做出什么判断或采取什么行动>
输入材料:
<网页、Word、Markdown、数据、已有 PPT、模板文件路径>
结构要求:
1. 封面
2. 背景与问题
3. 解决方案
4. 核心能力或关键成果
5. 数据证明
6. 风险与后续计划
7. 总结页
视觉要求:
1. 主色:<品牌色>
2. 风格:<科技 / 商务 / 极简 / 活泼 / 产品原型>
3. 每页只突出 1~2 个重点
4. 需要可编辑 PPTX,不要只输出图片
质量要求:
1. 检查文字是否溢出;
2. 检查标题层级是否统一;
3. 检查页面配色和字体是否一致;
4. 生成完成后说明输出文件位置。
5. 四类典型使用场景
5.1 无模板生成:适合做原型、方案和初稿
无模板场景适合“从 0 到 1”生成内容,例如产品原型、技术方案、培训课件、项目总结初稿。
示例:生成音乐 App 高保真原型,并把原型保存在 PPT 中。
我想开发一个酷炫的音乐 App,需要用 document-skills 输出高保真原型,并最终生成 PPTX。
请完成这些任务:
1. 用户体验分析
- 分析目标用户、主要功能和核心交互路径;
- 明确首页、发现页、播放页、歌单页、个人中心等关键页面。
2. 产品界面规划
- 定义每个页面的信息架构;
- 说明页面之间的跳转关系。
3. 高保真 UI 设计
- 尽量贴近 iOS / Android 常见设计规范;
- 使用现代化 UI 元素;
- 模拟 iPhone 16 Pro 尺寸;
- 添加状态栏、导航栏和底部 Tab Bar。
4. HTML 原型实现
- 使用 HTML + Tailwind CSS;
- 每个页面独立成一个 HTML 文件,例如 home.html、player.html、profile.html;
- index.html 作为总入口,通过 iframe 平铺展示所有页面;
- 使用真实图片资源,不使用纯占位符。
5. PPTX 输出
- 把关键页面整理进 PPT;
- 每页展示一个界面,并附简短设计说明;
- 输出文件命名为:音乐APP原型设计.pptx。
这种方式有两个好处:
- HTML 原型可以直接给前端或产品继续调整;
- PPT 可以直接用于评审、立项或需求沟通。
适合快速验证最小可行产品(MVP,Minimum Viable Product),但不能替代完整交互稿。复杂手势、动画、边界状态仍然需要专门的设计工具或前端实现。
5.2 编辑已有 PPT:适合补页、改文案、批量替换
如果已经有一份 PPT,只想补充一页或修改部分内容,可以把 PPT 放到当前工作目录,然后在对话中明确“基于哪份文件修改”。
示例 Prompt:
请基于当前目录中的 CodeBuddy介绍.pptx 进行编辑。
任务:
在第 7 页后面新增一页,主题是“CodeBuddy 在腾讯内部的落地情况”。
新增页内容:
- 腾讯云代码助手 Tencent Cloud CodeBuddy,简称 CodeBuddy;
- 覆盖多款主流 IDE、编程语言和框架;
- 超 90% 的腾讯程序员使用;
- 微信、QQ、元宝、腾讯会议、王者荣耀、和平精英、腾讯云等产品团队均有使用;
- 2025 年腾讯新增代码中,50% 由 CodeBuddy 生成;
- 整体研发效率提升超过 20%。
要求:
1. 新增页必须延续原 PPT 的背景、字体、配色和版式风格;
2. 不要修改其他页面;
3. 生成一个新文件,不覆盖原文件;
4. 输出前检查页面是否有文字溢出。
这种任务更依赖 OOXML 工作流。PPTX 本质是 ZIP 压缩包,里面有大量 XML(可扩展标记语言)文件。Skill 可以解包、定位页面、复制版式、插入内容,再重新打包成 PPTX。
不过,已有 PPT 的字体、母版和布局可能很复杂。AI 生成的补页通常能接近原风格,但标题字号、行距、局部对齐仍需要人工检查。
5.3 基于模板生成:适合正式汇报
如果有公司模板、团队模板或个人常用模板,应优先提供模板。模板会显著降低视觉不一致的问题。
示例 Prompt:
请使用当前目录中的 CEO汇报模板.pptx,生成一份面向 CEO 的 CodeBuddy 汇报 PPT。
已知数据:
- 周活跃用户数:5 万+
- AI 代码生成占比:超过 50%
- 人均编码时间:缩短 40%
- 人均千行 Bug 率:降低 31.5%
要求:
1. 使用模板中的封面、目录页、数据页和总结页风格;
2. 内容结构需要适合 CEO 阅读,突出业务价值、投入产出和规模化落地;
3. 数据页需要用图表或大数字呈现,不要堆长段文字;
4. 每页标题必须直接表达结论;
5. 输出文件命名为:CodeBuddy-CEO-Report.pptx。
基于模板生成通常效果最好,因为 AI 不需要重新发明视觉系统,只需要完成三件事:
- 识别模板页面适合表达什么内容;
- 把新材料映射到合适页面;
- 替换文本并保持原来的版式。
5.4 从 Word、HTML、Markdown 转 PPT
很多材料本来就存在于 Word、Markdown 或 HTML 中,例如技术方案、培训讲稿、会议纪要、产品说明。此时不要让 AI 重新“猜内容”,而是让它读取材料并重新组织成演示结构。
示例 Prompt:
请使用 document-skills 读取当前目录中的 技术分享.docx,并生成一份培训 PPTX。
要求:
1. 不要逐段搬运文档内容;
2. 将长段落拆成适合演示的页面;
3. 每页只保留关键观点、关键数据和必要解释;
4. 对流程、架构、对比内容优先转成图表;
5. 风格采用简洁技术培训风;
6. 输出文件命名为:技术分享培训版.pptx。
HTML 转 PPT 也很适合“先设计页面,再汇总成演示稿”的流程:
当前目录中有 14 个 HTML 页面,分别对应一次技术分享的不同章节。
请把这些 HTML 页面整理成一份 PPTX。
要求:
1. 按章节顺序合并;
2. 每个 HTML 页面生成一页或多页 PPT;
3. 页面内容要可读,避免直接截图导致文字模糊;
4. 删除重复页;
5. 添加封面、目录和总结页;
6. 输出文件命名为:团队AI研发流程分享.pptx。
6. 写高质量 Prompt 的几个原则
6.1 把任务拆成互不干扰的小块
AI 更擅长完成边界清晰的任务。一个好的任务应具备明确的输入、处理规则和输出结果。
不够清晰的写法:
帮我做一个好看的汇报 PPT。
更清晰的写法:
请基于 项目复盘.md 生成一份 12 页以内的项目复盘 PPT。
受众:技术管理者。
目标:说明项目为什么延期、采取了哪些修复措施、后续如何避免。
结构:
1. 项目背景
2. 目标与实际结果对比
3. 延期原因分析
4. 关键技术问题
5. 修复措施
6. 经验沉淀
7. 后续计划
视觉要求:
- 使用深蓝 + 白色科技风;
- 数据页使用柱状图;
- 每页标题使用结论句;
- 输出 PPTX 文件。
6.2 一次只改一个目标
一次性要求“换模板、改结构、加图表、缩短页数、统一字体、增加动画”,很容易让结果不可控。更稳的做法是按阶段迭代:
flowchart LR
A[生成初稿] --> B[调整结构]
B --> C[补充数据页]
C --> D[统一视觉风格]
D --> E[检查溢出与错别字]
E --> F[人工最终校对]
每轮只改一个目标,例如:
只修改第 3 页:
把这一页从长段文字改成“三个关键问题 + 三个解决动作”的左右结构。
不要修改其他页面。
6.3 用文件、图片和约束补充上下文
AI 不知道团队内部模板、业务背景、指标口径和汇报对象偏好。需要把这些上下文放进工作目录,或直接写进 Prompt:
约束:
1. DAU 表示日活跃用户数,不能写成下载量;
2. “提效 20%”指端到端研发周期缩短,不是单纯编码时间;
3. 所有页面不要使用红色作为主色,因为红色在内部汇报中表示风险;
4. 第 5 页必须保留原模板中的四象限布局。
6.4 用 Git 做版本保护
AI 修改文件时,可能出现样式偏移、内容误删或生成方向跑偏。只要每个关键节点提交一次,随时可以回退。
git init
git add .
git commit -m "初始化 PPT 项目"
# AI 完成一轮修改后
git add .
git commit -m "生成 CodeBuddy 汇报初稿"
# 查看提交记录
git log --oneline
如果改坏了,可以回到上一个稳定版本:
git checkout <commit_id> -- .
对不熟悉 Git 的用户,只需要记住一个原则:每次让 AI 大改之前,先提交一次。
7. PPT 内容本身怎么组织
AI 能帮忙生成页面,但 PPT 的说服力仍然来自结构。做汇报前需要先明确三件事:
| 问题 | 解释 |
|---|---|
| 谁来看 | CEO、技术评审、客户、晋升评委、培训学员关注点完全不同 |
| 要证明什么 | 是证明业务价值、技术能力、方案可行性,还是争取资源 |
| 希望对方做什么 | 通过评审、投入资源、理解方法、采纳方案 |
一个通用结构是 Why-How-What:
flowchart LR
A[Why 为什么要做] --> B[How 怎么做]
B --> C[What 结果是什么]
C --> D[Next 下一步计划]
对应到页面可以这样组织:
| 页面 | 重点 |
|---|---|
| 背景页 | 为什么这个问题值得解决 |
| 痛点页 | 当前有什么损失、风险或机会 |
| 方案页 | 核心思路是什么 |
| 实施页 | 做了哪些关键动作 |
| 数据页 | 结果是否可验证 |
| 复盘页 | 经验、风险和可复用方法 |
| 计划页 | 下一步需要什么资源或动作 |
7.1 晋升、复盘、案例分享可以用 STAR
STAR 法则适合讲项目贡献:
| 模块 | 含义 | PPT 中怎么写 |
|---|---|---|
| Situation | 背景 | 当时业务处在什么状态 |
| Task | 任务 | 需要解决什么关键问题 |
| Action | 行动 | 做了哪些判断、设计和推进 |
| Result | 结果 | 带来了什么可量化收益 |
7.2 数据页要有解释,不要只堆数字
观众关心的不是数字本身,而是数字说明了什么。
一个数据页应包含:
关键指标 + 可视化图表 + 对比维度 + 结论解释
图表选择可以按这个规则:
| 图表类型 | 适合表达 | 示例 |
|---|---|---|
| 折线图 | 趋势变化 | 月活用户数连续 6 个月增长 |
| 柱状图 | 数值对比 | 三个团队的提效幅度对比 |
| 饼图 / 环图 | 占比分布 | AI 生成代码占总新增代码比例 |
| 漏斗图 | 转化过程 | 从试用到日常使用的转化率 |
| 散点图 | 相关关系 | 代码生成量与缺陷率关系 |
不推荐这样写:
周活 5 万+,AI 代码生成占比 50%,编码时间缩短 40%,Bug 率降低 31.5%。
更适合 PPT 的写法:
CodeBuddy 已进入规模化使用阶段:
- 使用规模:周活跃用户数 5 万+;
- 生产贡献:新增代码中超过 50% 由 AI 生成;
- 效率收益:人均编码时间缩短 40%;
- 质量收益:人均千行 Bug 率降低 31.5%。
结论:AI 编码能力已经从辅助尝试进入研发流程主链路。
7.3 视觉风格保持克制
正式 PPT 不需要复杂装饰,最重要的是一致性。
| 规则 | 建议 |
|---|---|
| 配色 | 控制在 3 种以内:背景色、主色、辅助色 |
| 字体 | 控制在 2 种以内:标题字体、正文字体 |
| 重点 | 每页突出 1~2 个重点 |
| 行距 | 正文保持 1.2~1.5 倍行距 |
| 对齐 | 同类元素统一左对齐或居中对齐 |
| 留白 | 不要把页面填满,留白能提升阅读速度 |
8. PPTX Skill 的内部工作流
document-skills 里的 PPTX 能力主要有三条路线:
flowchart TB
A[PPTX Skill] --> B[从零创建]
A --> C[编辑已有 PPT]
A --> D[基于模板创建]
B --> B1[HTML / CSS 设计页面]
B1 --> B2[Playwright 渲染]
B2 --> B3[提取 DOM 位置和样式]
B3 --> B4[PptxGenJS 生成 PPTX]
C --> C1[解包 PPTX]
C1 --> C2[修改 OOXML]
C2 --> C3[验证 XML 结构]
C3 --> C4[重新打包 PPTX]
D --> D1[分析模板缩略图和文本]
D1 --> D2[建立内容与页面映射]
D2 --> D3[复制、重排、替换文本]
D3 --> D4[视觉检查和输出]
三条路线分别适合不同任务:
| 工作流 | 适合场景 | 优势 | 代价 |
|---|---|---|---|
| HTML → PPTX | 从零生成、产品原型、视觉页 | 设计灵活,AI 熟悉 HTML / CSS | 部分复杂 CSS 无法完全转成 PPT 元素 |
| OOXML 编辑 | 修改已有 PPT、补页、批量替换 | 能保留原文件结构和样式 | 底层 XML 复杂,错误会导致文件损坏 |
| 模板系统 | 公司模板汇报、品牌统一场景 | 风格一致,生成速度快 | 依赖模板质量和占位符结构 |
9. 工作流一:HTML 到 PPTX
从零创建 PPT 时,Skill 常采用“HTML 优先”的方式。AI 先生成 HTML 和 CSS(层叠样式表),再通过浏览器渲染页面,随后把页面中的文本、图形、图片位置转换成 PPTX 元素。
sequenceDiagram
participant AI as AI Agent
participant HTML as HTML/CSS
participant Browser as Playwright/Chromium
participant DOM as DOM 解析
participant PPT as PptxGenJS
participant File as PPTX 文件
AI->>HTML: 生成幻灯片 HTML
HTML->>Browser: 无头浏览器渲染
Browser->>DOM: 提取元素位置、尺寸、样式
DOM->>PPT: 转换为 PPT 对象
PPT->>File: 输出 .pptx
核心依赖通常包括:
| 组件 | 作用 |
|---|---|
| Playwright | 启动无头浏览器,渲染 HTML 页面 |
| Chromium | 提供浏览器渲染能力 |
| Sharp | 处理图片、SVG、图标栅格化 |
| PptxGenJS | 用 JavaScript 生成 PPTX |
| React Icons | 提供可复用图标资源 |
9.1 尺寸与单位转换
Web 页面常用像素 px,PowerPoint 内部常用点 pt、英寸 inch 和 EMU(English Metric Units,Office 用于表示尺寸的内部单位)。
常用换算关系:
1 px = 0.75 pt
1 inch = 96 px
1 inch = 72 pt
1 inch = 914400 EMU
简化后的转换逻辑:
const PT_PER_PX = 0.75;
const PX_PER_IN = 96;
function pxToPt(px) {
return px * PT_PER_PX;
}
function pxToInch(px) {
return px / PX_PER_IN;
}
function rgbToHex(rgbStr) {
// "rgb(255, 0, 0)" -> "FF0000"
const match = rgbStr.match(/rgb\((\d+),\s*(\d+),\s*(\d+)\)/);
if (!match) return null;
return match
.slice(1)
.map((n) => parseInt(n, 10).toString(16).padStart(2, "0"))
.join("")
.toUpperCase();
}
9.2 溢出检测
HTML 生成 PPT 最容易出问题的是文字溢出。页面在浏览器里看起来正常,不代表转换成 PPT 后仍然正常,因为字体渲染、行高和文本框边界可能发生变化。
一个基础检测方式是比较页面可视尺寸和滚动尺寸:
const bodyDimensions = await page.evaluate(() => {
const body = document.body;
const style = window.getComputedStyle(body);
return {
width: parseFloat(style.width),
height: parseFloat(style.height),
scrollWidth: body.scrollWidth,
scrollHeight: body.scrollHeight,
};
});
const hasOverflow =
bodyDimensions.scrollWidth > bodyDimensions.width ||
bodyDimensions.scrollHeight > bodyDimensions.height;
如果出现溢出,常见修复方式包括:
- 减少每页文字;
- 降低字号;
- 增加页面留白;
- 把一页拆成两页;
- 将长列表转为图表或分组卡片。
10. 工作流二:直接操作 OOXML
PPTX 不是一个神秘的二进制文件,它本质上是一个 ZIP 压缩包。解压后可以看到一组 XML、关系文件和媒体资源。
典型结构如下:
presentation.pptx
├── [Content_Types].xml
├── _rels/
│ └── .rels
├── docProps/
│ ├── app.xml
│ └── core.xml
└── ppt/
├── presentation.xml
├── _rels/
│ └── presentation.xml.rels
├── slides/
│ ├── slide1.xml
│ ├── slide2.xml
│ └── _rels/
│ ├── slide1.xml.rels
│ └── slide2.xml.rels
├── slideLayouts/
├── slideMasters/
├── theme/
│ └── theme1.xml
├── media/
│ ├── image1.png
│ └── image2.jpg
└── notesSlides/
直接编辑已有 PPT 时,流程通常是:
flowchart LR
A[原始 PPTX] --> B[解包 ZIP]
B --> C[定位 slideN.xml]
C --> D[修改文本、关系、样式]
D --> E[XSD Schema 验证]
E --> F[重新打包]
F --> G[新 PPTX]
解包示例:
import zipfile
from pathlib import Path
def unpack_document(office_file, output_dir):
output_dir = Path(output_dir)
output_dir.mkdir(parents=True, exist_ok=True)
with zipfile.ZipFile(office_file, "r") as zf:
zf.extractall(output_dir)
unpack_document("presentation.pptx", "unpacked")
重新打包前需要注意:
[Content_Types].xml必须正确描述文件类型;_rels关系文件不能丢;- 新增图片、页面、布局后,需要同步更新关系引用;
- XML 命名空间不能随意删除;
- 页面数量、幻灯片 ID、关系 ID 要保持一致。
10.1 XSD 验证
XSD(XML Schema Definition,XML 结构定义)用于检查 XML 是否符合 Office Open XML 标准。验证不通过的 PPTX 可能无法打开,或打开后提示修复。
简化后的验证逻辑:
from pathlib import Path
from lxml import etree
def validate_xml_files(xml_files, xsd_path):
schema_doc = etree.parse(str(xsd_path))
schema = etree.XMLSchema(schema_doc)
errors = []
for xml_file in xml_files:
doc = etree.parse(str(xml_file))
if not schema.validate(doc):
for error in schema.error_log:
errors.append(f"{xml_file}:{error.line} {error.message}")
return errors
这种方式适合对已有 PPT 做精确修改,例如:
- 批量替换公司名;
- 替换某些页面中的指标;
- 新增一页并复用原模板;
- 删除或重排幻灯片。
11. 工作流三:模板分析与文本替换
基于模板生成 PPT 时,Skill 要先理解模板。它通常会提取每页中的形状、文本框、占位符、字体、颜色、位置等信息,形成一个“清单”。
清单可以抽象成这样的数据结构:
from dataclasses import dataclass
from typing import Optional, List
@dataclass
class ParagraphData:
text: str
bullet: bool = False
level: Optional[int] = None
alignment: Optional[str] = None
font_name: Optional[str] = None
font_size: Optional[float] = None
bold: Optional[bool] = None
italic: Optional[bool] = None
color: Optional[str] = None
line_spacing: Optional[float] = None
@dataclass
class ShapeData:
left: float
top: float
width: float
height: float
placeholder_type: Optional[str]
paragraphs: List[ParagraphData]
overflow: Optional[dict] = None
11.1 视觉排序
模板里的文本框并不一定按阅读顺序存储,所以需要根据位置排序。常见规则是“从上到下、从左到右”。
def sort_shapes_by_position(shapes):
if not shapes:
return shapes
shapes = sorted(shapes, key=lambda s: (s.top, s.left))
result = []
row = [shapes[0]]
row_top = shapes[0].top
for shape in shapes[1:]:
if abs(shape.top - row_top) <= 0.5:
row.append(shape)
else:
result.extend(sorted(row, key=lambda s: s.left))
row = [shape]
row_top = shape.top
result.extend(sorted(row, key=lambda s: s.left))
return result
这里的 0.5 英寸是容差。模板设计者手工拖动元素时,很少做到完全对齐,如果没有容差,两个视觉上属于同一行的文本框可能被错误拆开。
11.2 递归处理组合形状
PPT 里很多元素会被组合成 GroupShape。组合内部的坐标是相对坐标,需要把父级偏移累加成绝对坐标。
def collect_shapes_with_absolute_positions(shape, parent_left=0, parent_top=0):
if hasattr(shape, "shapes"):
abs_left = parent_left + shape.left
abs_top = parent_top + shape.top
result = []
for child in shape.shapes:
result.extend(
collect_shapes_with_absolute_positions(child, abs_left, abs_top)
)
return result
if is_valid_shape(shape):
return [{
"shape": shape,
"absolute_left": parent_left + shape.left,
"absolute_top": parent_top + shape.top,
}]
return []
模板系统的核心不是“随便找个文本框填进去”,而是先建立稳定 ID:
slide-0 / shape-0
slide-0 / shape-1
slide-1 / shape-0
...
然后根据清单把新内容替换到合适的位置。
12. 质量保证:生成之后必须验证
AI 生成 PPT 的质量控制至少包含四层:
| 验证层 | 检查内容 |
|---|---|
| HTML 验证 | 标签结构、页面尺寸、CSS 兼容性 |
| 布局验证 | 元素边界、边距、对齐、文字溢出 |
| 内容验证 | 标题层级、术语一致性、数据口径 |
| 文件验证 | PPTX 是否能打开、关系文件是否完整 |
一种常见做法是把 PPT 转成缩略图网格,用于快速人工检查页面整体效果。
def generate_thumbnail_grid(pptx_path, output_prefix, cols=5):
try:
pdf_path = convert_pptx_to_pdf(pptx_path)
images = convert_pdf_to_images(pdf_path)
grid = create_image_grid(images, cols)
output_filename = f"{output_prefix}.jpg"
grid.save(output_filename, quality=85)
except Exception as e:
raise RuntimeError(f"thumbnail generation failed: {e}")
缩略图检查尤其适合发现这些问题:
- 某页标题跑出边界;
- 某页风格和其他页面明显不一致;
- 图表比例异常;
- 字号过小;
- 某页内容密度过高。
13. 设计约束与内置风格能力
PPTX Skill 在设计上通常会遵循几类约束:
| 约束 | 目的 |
|---|---|
| 使用网页安全字体 | 避免跨设备打开后字体丢失 |
| 保持强对比度 | 提升投影、会议屏幕和远程共享可读性 |
| 重复页面模式 | 保证整套 PPT 风格统一 |
| 控制字号层级 | 让标题、重点、正文关系清楚 |
| 避免复杂动画 | 保证 PPTX 可编辑、可复用 |
常见安全字体包括:
| 字体 | 类型 | 适合场景 |
|---|---|---|
| Arial | 无衬线 | 通用正文和标题 |
| Helvetica | 无衬线 | 现代商务风 |
| Times New Roman | 衬线 | 正式报告、学术材料 |
| Georgia | 衬线 | 屏幕阅读较友好 |
| Courier New | 等宽 | 代码、日志、数据对齐 |
| Verdana | 无衬线 | 小字号屏幕阅读 |
配色可以从主题出发选择,不要随机堆颜色:
| 风格 | 示例配色 |
|---|---|
| 科技商务 | 深蓝、灰、白 |
| 活力产品 | 橙、浅灰、炭黑 |
| 高端汇报 | 黑、金、米白 |
| 自然稳定 | 森林绿、奶油白、炭灰 |
| 年轻视觉 | 粉、珊瑚、紫 |
14. 性能优化与错误处理
批量生成多页 PPT 时,如果每页 HTML 都串行渲染,耗时会明显增加。更合理的方式是限制并发数量,分批处理。
async function processSlidesParallel(htmlFiles, pptx) {
const concurrency = 3;
const chunks = chunkArray(htmlFiles, concurrency);
for (let i = 0; i < chunks.length; i++) {
const chunk = chunks[i];
const promises = chunk.map((htmlFile) =>
html2pptx(htmlFile, pptx)
.then((res) => ({
...(typeof res === "object" && res !== null ? res : { result: res }),
file: htmlFile,
}))
.catch((error) => ({
error: error.message,
file: htmlFile,
}))
);
const results = await Promise.all(promises);
handleProcessingResults(results);
}
}
稳定的 PPT 生成系统还需要这些机制:
| 机制 | 作用 |
|---|---|
| 渐进式降级 | HTML 转换失败时生成基础幻灯片,避免整个任务中断 |
| 批量错误报告 | 一次返回所有错误,减少反复试错 |
| 自动备份 | 编辑已有 PPT 前复制原文件 |
| 回滚能力 | 生成失败时恢复到修改前状态 |
| 并发限制 | 避免浏览器渲染和图片处理占满资源 |
15. 能力边界
CodeBuddy Skills 适合做 PPT 自动化,但不是万能设计师,也不是最终审核者。
| 能力 | 适合 | 不适合 |
|---|---|---|
| 从材料生成初稿 | 汇报、培训、产品介绍、技术方案 | 对审美要求极高的品牌发布会主视觉 |
| 套模板生成 | 公司内部汇报、周期性周报月报 | 模板结构混乱、页面元素没有规律的文件 |
| 编辑已有 PPT | 补页、替换文字、调整结构 | 复杂动画、特殊插件、非标准字体强依赖 |
| 生成原型页 | MVP 讨论、需求评审、产品概念表达 | 完整交互设计和可上线前端代码 |
技术层面也有一些限制:
- 部分 CSS 渐变、复杂动画和深层嵌套布局不能完全还原;
- 非标准字体在不同设备上可能显示不一致;
- 千页级文档会带来明显性能开销;
- 数据真实性、指标口径和业务结论必须人工确认;
- 自动生成的页面需要检查错别字、术语、排版和逻辑链。
16. 一个可复用的 PPT 自动化流程
比较稳的工作方式不是“一次生成最终稿”,而是分阶段完成。
flowchart TB
A[准备材料] --> B[明确受众和目标]
B --> C[生成大纲]
C --> D[确认结构]
D --> E[生成 PPT 初稿]
E --> F[逐页修改]
F --> G[统一视觉]
G --> H[验证文件和缩略图]
H --> I[人工校对]
I --> J[最终交付]
每个阶段都可以给 CodeBuddy 一个明确任务:
阶段 1:只生成目录和每页标题,不生成 PPT。
阶段 2:基于确认后的目录生成 PPTX 初稿。
阶段 3:只优化第 4 页的数据表达。
阶段 4:统一所有页面的标题格式和主色。
阶段 5:检查是否存在文字溢出、错别字和术语不一致。
这样做的好处是可控。AI 负责提高生成速度,人负责判断内容是否准确、结论是否成立、汇报对象是否能理解。对于正式汇报、晋升答辩、培训课件和产品评审,这种人机协作方式比单纯手工制作更省时间,也比一次性全自动生成更可靠。