本地大模型+AI Agent：Ollama部署Qwen自动生成PPT的完整方案

最近在折腾“本地模型 + AI 办公”这条链路时，我一直在想一个问题：既然本地大模型已经能跑起来写文案、做总结，那能不能顺便把 PPT 也一起生成掉？如果能做到，内容不出本机、不依赖在线 AI 平台，对知识管理、离线办公和隐私敏感场景都非常友好。

带着这个想法，我把 Ollama 本地部署的 Qwen3.8-27B、WorkBuddy 这个 AI Agent 工作台和 python-pptx 脚本串在了一起，做了一轮完整的实战测试。整体流程跑通之后，链路实用性和稳定性都超出我的预期。这篇文章就把整套“AI 生成 PPT”的本地方案拆开讲清楚，包括模型部署、代理工具配置、PPT 生成脚本、Skill 封装、常见报错排查和工程落地建议。

适合三类读者：想用本地模型替代在线 PPT 工具的人、刚接触 WorkBuddy 不知道从哪里入手的同学，以及准备把“大模型 + 文档生成”做成自动化能力的技术人员。

1. 为什么用本地模型生成 PPT

1.1 在线 AI 生成 PPT 的常见痛点

现在打开浏览器，输入一段主题，自动生成一套 PPT 的工具已经非常多了。多数的流程是：云端大模型生成大纲 → 套用模板 → 渲染成 PPT 文件。这类产品确实降低了做 PPT 的门槛，但在实际使用中，我经常遇到几类问题：

• 内容隐私不好控制。把公司数据、项目方案、课程讲义丢到在线平台，后续这些内容会不会被拿去训练模型，很难说清楚。
• 大纲质量不稳定。免费额度下生成的内容往往比较空，深度不够；想要更高质量的输出，通常需要付费。
• 后续编辑成本高。很多在线工具导出 PPT 之后，排版、字体、配色都不容易二次修改，反而比从零做还麻烦。
• 网络依赖强。没有稳定网络时，整个生成流程直接不可用。

这些痛点在批量生成、内部知识沉淀、离线环境下会被放大。

1.2 本地 Qwen3.8-27B 能带来什么

本地部署 Qwen3.8-27B 之后，上面的问题大部分都能得到缓解。Qwen 系列的量化版本可以在消费级显卡或 Mac 上通过 Ollama 跑起来，模型完全控制在本地，数据不出机器。生成的 PPT 内容，从大纲设计到文案填充，都可以由同一个模型完成。

更重要的是，本地模型可以配合 Agent 工具使用。比如通过 WorkBuddy 把“生成 PPT”封装成一个 Skill，那么这个 Skill 不仅可以用自然语言触发，还可以被其他工作流复用。说一句“帮我生成一份关于实验室安全培训的 PPT”，Agent 会自动拆解任务、调用模型生成内容、调用 python-pptx 脚本渲染文件，整个过程不需要打开在线编辑器。

1.3 本地生成 PPT 的整体架构

先看一条完整链路：

用户输入需求 ↓ WorkBuddy（AI Agent 工作台） ↓ 读取 Skill 配置 PPT Skill（指令 + Prompt + 脚本） ↓ 调用 Ollama / Qwen3.8-27B 本地模型 ↓ 返回结构化大纲 python-pptx 渲染脚本 ↓ 输出 .pptx 文件

简单理解就是：WorkBuddy 是“调度中枢”，Qwen 是“内容大脑”，python-pptx 是“排版工人”。三个角色配合，才能完成从一句话需求到成品 PPT 的闭环。如果只用模型本身，模型只能输出文本，没法直接生成二进制 pptx 文件；如果只写脚本，又缺少内容生成能力。两者结合起来才是完整的方案。

2. 核心概念：Qwen、WorkBuddy 与 Skill

2.1 Qwen3.8-27B 是什么

Qwen 是开源大模型系列，参数规模覆盖多个档位。Qwen3.8-27B 在社区中通常指 Qwen3 系列中 8B 到 27B 量级的本地可部署版本，具体参数以你拉取的模型标签为准。这类规模的优势在于：

• 8B 量化版对显存要求友好，很多 8GB 到 12GB 显存的机器可以运行；
• 27B 量化版能提供更强的逻辑推理和内容组织能力，适合生成结构化大纲；
• 都支持 Ollama 一键部署，不需要手动配置复杂的 Python 推理环境。

在 PPT 生成任务中，模型的作用不是直接“画图”，而是完成核心的知识工作：把主题拆成章节、为每页提炼标题、给每个章节填充要点，甚至能给出排版建议。这些内容质量直接决定 PPT 的下限。

2.2 WorkBuddy 是什么

WorkBuddy 是一个 AI Agent 工作台，核心思路是让用户通过自然语言触发已经配置好的“技能”。它本身不一定关心底层大模型是公有云还是本地 Ollama，而是通过标准接口连接模型服务。

在我这次的测试里，WorkBuddy 承担的任务是：

• 接收用户的 PPT 生成需求；
• 识别并选择对应的 PPT Skill；
• 将需求填充到 Skill 的 Prompt 模板中；
• 调用本地 Qwen 模型，拿到结构化结果；
• 执行 Skill 绑定的脚本，产出 PPT 文件。

所以 WorkBuddy 就像一个“万能遥控器”，把模型能力、脚本能力、文件处理能力组合成一个可重复执行的任务。

2.3 Skill 机制

Skill 可以理解为一个“任务模板包”，通常包含：

• 触发条件或指令描述；
• 发给模型的系统 Prompt；
• 处理模型输出结果的脚本；
• 输出文件的后处理逻辑。

举个例子，PPT Skill 的典型配置可能是：

• 描述：根据主题生成一份 10 页左右的 PPT；
• Prompt：让模型输出一个符合指定 JSON 结构的页面列表；
• 脚本：读取 JSON，逐页写入 python-pptx 生成的演示文稿中。

这种设计的价值在于：把“生成 PPT”这件事变成可复用的工程能力，而不是每次都在对话里重新描述一遍格式要求。配置好一次后，团队内所有人都可以反复使用。

2.4 生成 PPT 的两种路径

在整个生态里，生成 PPT 常见有两种路径，我的测试里两条都走通了一部分。

第一种是“文本大纲 + 模板渲染”。模型先生成 Markdown 或 JSON 格式的大纲，再由脚本把大纲映射到 PPT 页面。这种路径代码量少，适合文字型 PPT，比如培训讲义、方案说明、读书笔记。

第二种是“生成器代码 + 动态排版”。模型调用一个预置的生成函数，自己决定页面结构、标题层级和内容块。这种路径更灵活，但需要模型遵循函数调用的格式，对模型指令遵循能力要求更高。

本文的实战部分会以第一条路径为主，因为它最稳妥、最容易被新手复现。

3. 环境准备与版本说明

3.1 硬件与操作系统

本地部署 Qwen3.8-27B 并不需要夸张的配置，但不同参数规模的体验差异较大。

• 如果是 8B 量化模型：建议 16GB 内存起步，8GB 以上显存体验更好；
• 如果是 27B 量化模型：建议 32GB 内存，显存 12GB 以上；
• 纯 CPU 推理也能跑，但生成速度会明显变慢，适合不追求速度的文本处理任务。

以下示例在 Windows 11 + Ollama + Python 3.10 环境下测试通过。Mac 或 Linux 的流程类似，命令差异不大。

3.2 软件清单

我使用的软件和版本如下：

版本需要根据你的项目实际情况调整，本文示例以常见环境为例，重点演示配置思路。如果你使用的 Ollama 版本较新，部分命令输出可能略有差异，但不影响核心流程。

3.3 安装 Ollama 并启动服务

Ollama 的安装方式很简单，到官网下载对应系统的安装包，按提示安装即可。安装完成后，命令行执行：

ollama --version

能看到版本号，说明安装成功。接下来需要确保 Ollama 服务正常运行。Windows 下安装后一般会自动在后台启动，也可以通过命令行手动启动：

ollama serve

服务默认监听 11434 端口。可以在浏览器访问：

http://localhost:11434

如果看到 Ollama 的提示信息，说明服务已经起来了。

3.4 拉取 Qwen 模型

Ollama 拉取模型使用的是ollama pull命令。以 Qwen3 系列为例：

ollama pull qwen3:8b

如果你的机器配置更高，需要更强的内容组织能力，可以尝试更大参数的版本：

ollama pull qwen3:27b

实际模型标签请以 Ollama 仓库中存在的标签为准。拉取完成后，可以通过下面的命令快速测试模型是否可用：

ollama run qwen3:8b "用三句话说明 AI Agent 是什么"

如果模型能正常返回内容，说明本地模型已经就绪。

4. WorkBuddy 安装与本地模型接入

4.1 下载安装 WorkBuddy

WorkBuddy 的安装一般有桌面客户端和命令行两种方式，具体以官方发布渠道为准。安装完成后，第一次启动需要完成基础配置，包括：

• 指定一个工作目录，用于存放 Skill 配置和生成的文件；
• 选择模型提供方；
• 配置模型接口地址。

由于不同版本界面差异较大，这里不写死具体的点击路径，重点说明思路：所有模型提供方本质上都是“接口地址 + 模型名称”两个参数。只要能配置这两个参数，就能接入本地 Ollama。

4.2 配置本地模型服务

在 WorkBuddy 的模型配置中，添加一个“Ollama”类型的服务，填写以下信息：

• API 地址：http://localhost:11434
• 模型名称：qwen3:8b或qwen3:27b
• 鉴权方式：本地服务通常不需要 Token，留空即可

配置完成后，可以先在 WorkBuddy 中发起一次普通对话，验证模型连接是否正常。如果对话能返回结果，说明“本地模型接入”这步已经打通。

这里有一个常见的误区：AI Agent 工具往往默认要求配置 OpenAI 兼容的接口。Ollama 本身就提供了 OpenAI 兼容的 API，因此很多 Agent 工具可以直接选择“OpenAI 兼容”类型，然后把 Base URL 指向http://localhost:11434/v1。如果 WorkBuddy 也支持这种方式，优先这样配置。

4.3 准备 PPT 生成脚本

在配置 Skill 之前，我们需要先准备好一个能被 WorkBuddy 调用的 PPT 生成脚本。这个脚本负责把模型输出的结构化内容渲染成.pptx文件。

我先建一个项目目录，方便后续管理：

ppt-skill/ ├── skills/ │ └── create-ppt/ │ ├── skill.yaml │ └── generate_ppt.py └── output/

generate_ppt.py是核心脚本，它读取一个 JSON 格式的输入文件，里面包含 PPT 的标题、副标题和页面列表，然后生成 PPT 文件。完整代码如下：

# 文件路径：ppt-skill/skills/create-ppt/generate_ppt.py import json import sys from pptx import Presentation from pptx.util import Inches def main(input_path, output_path): with open(input_path, "r", encoding="utf-8") as f: data = json.load(f) prs = Presentation() # 首页：标题 + 副标题 title_slide = prs.slides.add_slide(prs.slide_layouts[0]) title_slide.shapes.title.text = data.get("title", "未命名 PPT") if data.get("subtitle"): title_slide.placeholders[1].text = data["subtitle"] # 内容页：根据页面列表批量创建 for page in data.get("pages", []): slide = prs.slides.add_slide(prs.slide_layouts[1]) slide.shapes.title.text = page.get("title", "") content = page.get("points", []) if content: body_shape = slide.placeholders[1] text_frame = body_shape.text_frame text_frame.clear() for i, point in enumerate(content): if i == 0: text_frame.text = point else: p = text_frame.add_paragraph() p.text = point prs.save(output_path) print(f"PPT 已生成：{output_path}") if __name__ == "__main__": # 用法：python generate_ppt.py input.json output.pptx main(sys.argv[1], sys.argv[2])

这个脚本已经把“内容生成”和“文件渲染”解耦了。模型负责生成input.json，脚本负责把 JSON 变成 PPT。这样即使以后换别的模型，也不需要改动渲染逻辑。

4.4 编写 Skill 配置

WorkBuddy 的 Skill 通常可以配置在一个文本文件中。下面是一份简化的skill.yaml示例，它不保证适配所有版本，但思路是通用的。

# 文件路径：ppt-skill/skills/create-ppt/skill.yaml name: create-ppt description: 根据主题生成 PPT 文件，输出 .pptx 格式 model: qwen3:8b prompt: | 你是一个 PPT 内容策划专家。请根据用户提供的主题，生成一个 JSON 对象。 JSON 必须包含 title、subtitle、pages 三个字段。 pages 是页面列表，每页包含 title 和 points。 points 中每一项是一句完整、可展示的 PPT 要点。 只输出 JSON，不要输出任何解释文字。 script: python generate_ppt.py {input_json} {output_file}

这个配置重点在prompt和script两部分。prompt决定模型输出什么结构，script决定怎么把模型输出变成文件。两个部分一旦固定，用户的体验就变成了“输入一句话，得到一份 PPT”。

4.5 在 WorkBuddy 中加载 Skill

在 WorkBuddy 中指向你的ppt-skill目录，它会自动识别skills/create-ppt下的 Skill 配置。加载成功后，你可以在交互界面直接输入：

请帮我生成一份关于“实验室安全培训”的 PPT

WorkBuddy 会匹配到create-pptSkill，调用配置好的 Qwen 本地模型，把返回的 JSON 写入临时文件，再执行generate_ppt.py，最终输出 PPT 文件到output目录。

5. 完整实测：让 Qwen 生成一份可编辑的 PPT

5.1 实测场景设定

我这次测试的主题是“实验室安全培训 PPT”。主题偏培训讲解类，非常适合验证内容结构和排版流程。我期望生成的 PPT 包含以下几类页面：

• 封面页：标题 + 副标题；
• 培训目标页；
• 实验室常见风险页；
• 安全操作规范页；
• 应急处理流程页；
• 总结与问答页。

5.2 先用 Ollama 直接验证模型输出

在配置 WorkBuddy 之前，先用 Ollama 直接调用模型，确认模型能输出符合要求的 JSON。命令行执行：

ollama run qwen3:8b "请生成一份关于实验室安全培训的PPT大纲，用JSON格式返回，包含title、subtitle、pages字段，pages每页有title和points。"

模型的输出通常会带有 Markdown 代码块标记，比如```json ... ```。真正交给脚本之前，需要去掉这些包裹标记，只保留纯 JSON。在实际使用中，WorkBuddy 的 Skill 配置会通过 Prompt 要求模型“只输出 JSON，不要输出任何解释文字”，能有效减少这类问题。

5.3 构造模型返回的 JSON 文件

为了验证渲染脚本是否正常，我先手工构造一份小的input.json作为测试数据：

{ "title": "实验室安全培训", "subtitle": "从意识到行动，构建安全实验环境", "pages": [ { "title": "培训目标", "points": [ "掌握实验室常见风险识别方法", "熟悉个人防护装备的正确使用", "了解紧急情况下的应急处置流程" ] }, { "title": "常见风险类型", "points": [ "化学品灼伤与中毒风险", "电气设备短路与火灾风险", "生物样本泄漏与感染风险" ] }, { "title": "安全操作规范", "points": [ "进入实验室前必须穿戴防护装备", "实验过程中严禁饮食与拨打电话", "离开实验室前必须完成台面清洁与物品归位" ] }, { "title": "应急处理流程", "points": [ "发现异常立即停止实验并上报", "根据风险类型选择对应应急处置措施", "必要时拨打急救电话并疏导周边人员" ] } ] }

5.4 运行渲染脚本

在ppt-skill目录下执行：

pip install python-pptx

然后运行脚本：

python skills/create-ppt/generate_ppt.py input.json output/实验室安全培训.pptx

预期输出：

PPT 已生成：output/实验室安全培训.pptx

此时打开输出目录，可以看到生成好的 PPT 文件。用 WPS 或 PowerPoint 打开检查，每一页都有对应的标题和正文要点。

5.5 填入真实模型输出后的效果

手工测试通过后，再把模型真正生成的内容替换进去。实测过程中，Qwen 生成的大纲通常比手工示例更全面，有时会自动补充“设备维护”“个人防护装备清单”等页面。只要 JSON 结构符合脚本预期，PPT 就会自动把这些页面全部渲染出来。

这里有个实际经验：模型生成的内容可能会过长，导致单页文字过密。解决方案有两个：

• 在 Prompt 中明确指定“每页最多 5 个要点，每个要点不超过 20 个字”；
• 在渲染脚本中做截断处理，超出部分自动忽略。

我的建议是先通过 Prompt 约束，毕竟模型更懂内容优先级，脚本截断只是兜底方案。

5.6 真实链路效果

完整链路跑通之后，整体体验是：

用户输入主题 ↓ WorkBuddy 识别 Skill ↓ WorkBuddy 调用 Ollama 本地 Qwen 模型 ↓ 模型返回 JSON 大纲 ↓ generate_ppt.py 渲染 PPT ↓ 输出文件

从输入主题到拿到 PPT 文件，整个过程都在本地完成，没有把任何内容发送到云端。这正好满足离线办公和隐私敏感场景的需求。

6. 常见问题与排查思路

本地模型 + WorkBuddy + PPT 脚本这条链路由多个组件组成，任何一环出问题，都会导致最终结果异常。以下是我实测中遇到的高频问题。

排查的顺序建议按照“模型服务 → 接口连通性 → Prompt 输出格式 → 脚本调试 → 文件输出”的流程进行。先从最简单的一环开始排除，不要一上来就怀疑模型能力。

7. 最佳实践与工程建议

7.1 把内容结构与排版解耦

这是整个方案中最重要的设计思想。模型负责内容，脚本负责排版，两者通过 JSON 接口通信。这样做的好处非常多：

• 换模型时不需要改脚本；
• 换排版时不需要重新生成内容；
• 出现问题时能快速定位是内容错了还是渲染错了。

建议所有 AI 生成文档类的项目都采用这个模式，不要写“模型直接输出整段 HTML”类型的强耦合方案。

7.2 做好 Prompt 版本管理

Prompt 是这套系统真正的“算法”。随着模型版本升级，同一个 Prompt 的效果可能发生变化。建议把每个 Skill 的 Prompt 也纳入版本管理，和代码一起提交。修改 Prompt 后，记得重新测试一份旧数据，防止回归。

7.3 增加输出文件的后处理机制

脚本直接生成的 PPT 通常比较朴素，没有公司 LOGO，没有统一配色。这很正常，毕竟 python-pptx 的职责是“内容准确”，不是“设计美观”。工程化建议是：

• 先使用一个标准 PPT 模板文件作为基础；
• 在模板基础上补充标题、正文占位符；
• 生成后再用脚本统一设置字体、字号、颜色。

如果你需要的是高度美观的 PPT，可以先用本方案生成内容准确的初稿，再套用精美模板二次加工。这比从零开始做省力得多。

7.4 批量生成时做好并发控制

本地模型在同一时间只能处理有限数量的请求。如果团队里多人同时用 WorkBuddy 生成 PPT，建议加上任务队列，避免 Ollama 服务被打满。最简单的方式是在 WorkBuddy 前面加一层排队逻辑，或者限制同时运行的 Skill 实例数量。

7.5 安全边界：本地部署也不代表完全无风险

虽然本地部署避免了数据上传，但仍需注意：

• 不要随意加载来源不明的模型文件；
• Skill 脚本如果来自第三方，先检查源码再执行；
• 涉及敏感文件路径时，限制脚本只访问指定目录；
• 生成的内容仍需人工审核，尤其是专业性较强的场景。

本地模型不等于“无限制模型”，使用 AI 生成内容时应遵守相关法律法规和内容安全规范，不能把模型用于生成违法、违规内容。

7.6 从脚本生成到自动化工作流

当 Skill 稳定运行后，可以继续扩展：

• 接入企业知识库，让模型基于内部文档生成 PPT；
• 把生成的 PPT 自动上传到内部网盘；
• 定时批量生成周报、月报 PPT；
• 增加图表渲染能力，让模型顺便输出图表数据。

每扩展一步，都要保持“模型出内容、脚本做渲染”的解耦原则。

8. 总结与后续路线

这次实测让我确定了一件事：本地大模型生成 PPT 已经不是“能不能做”的问题，而是“怎么做更稳”的问题。通过 Ollama 部署 Qwen、通过 WorkBuddy 编排 Skill、通过 python-pptx 渲染文件，整套方案可以做到完全本地化，而且生成结果是可以编辑、可以二次加工的普通 PPT 文件。

下一步比较值得投入的方向有两个：一个是把 PPT 模板做成可配置项，让不同场景自动套用不同风格；另一个是给脚本加入图表能力，让模型不仅输出文字大纲，还能输出图表数据，进一步提高 PPT 的信息密度。

如果你也在做 AI Agent 相关的本地化办公尝试，建议先用最简单的 8B 量化模型跑通闭环，再逐步升级到更大的参数模型。链路通了，剩下的优化只是时间问题。希望这篇文章能帮你少踩几个坑，把“一句话生成 PPT”真正落地到自己的环境里。