企业官网建设流程全解析

AI 生成 PPT 这个话题，其实已经被讨论过很多次了。打开任何一家在线工具，输入一个主题，几秒钟就能产出一套设计精美的幻灯片。但这里有一个很多人忽略的问题：当你把公司内部数据、项目方案、技术架构图描述丢进在线平台时，你对内容流向的控制力是有限的。如果你只是做一份通用模板风格的汇报，在线工具确实方便；如果你希望 PPT 的内容、结构、排版逻辑真正可控，同时数据不出本地，这条路目前还没有被大多数“一键生成”工具覆盖。

这篇文章要讲的，是一套偏向“过程可控”的本地范式：本地部署 Qwen3.8-27B 这类大模型，再通过 WorkBuddy 这类 Agent 工具把“内容生成”和“PPT 文件生成”串起来。你可以把它理解成一条数据不出本机的完整流水线：模型负责写大纲、想文案，WorkBuddy 负责调度工具、调用模型，最后由 python-pptx 之类的代码真正落成.pptx文件。

我会按这样几个层面展开：先解释为什么需要这种组合，再拆解 Qwen3.8-27B、Ollama、WorkBuddy、Skill 这些概念，然后给出从环境准备、模型部署、Agent 配置到代码生成 PPT 的完整路径。整个流程不需要你拥有多高端的显卡，但会给出不同硬件档位的参考思路。读完你至少能跑通一条本地生成 PPT 的最小链路，也能理解 AI PPT 生成这件事，在“在线工具”之外还有另一种更工程化的做法。

1. 这篇文章真正要解决的问题

很多开发者的刚需不是“做一份好看的 PPT”，而是“做一份属于自己逻辑、随时可改、批量可生成”的 PPT。这两种需求看起来相似，实际差别很大。

在线 AI PPT 工具的优势是模板精美、上手快，但在真实开发场景里会遇到几个绕不开的问题：

• 内容隐私与合规：公司内部的技术方案、未公开的产品规划、客户数据，不太适合直接粘贴到外部服务。
• 结构可控性差：很多在线工具生成出来的大纲是“顺滑但平庸”的，它并不理解你项目的关键约束，比如部署架构里哪些节点不能写、某一页需要放命令还是放架构图。
• 难以二次工程化：在线工具导出的 PPT 往往是最终文件，不方便纳入版本管理。你很难说“改一行大纲，重新生成整个 PPT”，更难把生成能力封装成团队内部的一个自动化脚本或服务。

WorkBuddy 加本地模型的组合，解决的不是“做得快不快”，而是“这条生成链路可不可控”。它把任务拆成几个可替换的环节：

1. 模型层：本地运行的 Qwen3.8-27B，负责理解你的主题、输出结构化大纲。
2. Agent 层：WorkBuddy 负责理解用户意图、决定调哪个工具、把模型输出转换为后续动作，例如生成 Office 文件、运行脚本。
3. 执行层：通过 python-pptx 或 Skill 把大纲渲染成实际的 PPTX 文件。

从架构上看，这条链路和在线工具最大区别在于：在线工具是黑盒，本地范式是白盒。每一层都可以独立替换，这也意味着你可以在自己的服务器或开发机上搭建一套私有的、可审计的“PPT 生成中台”。

适合读这篇文章的读者，我判断主要是三类：

• 在团队内部做 AI Agent 工具调研的开发者。
• 需要批量产出技术分享、项目汇报 PPT，同时又对内容隐私有要求的工程师。
• 想理解 Ollama 本地模型接入 Agent 工具，并完成一次最小闭环的实践型学习者。

2. 核心概念：Qwen3.8-27B、Ollama、WorkBuddy 与 Skill

2.1 Qwen3.8-27B 到底是什么

从材料看，Qwen3.8-27B 是一个挂在大模型生态里的本地可部署模型版本，量级在 27B 参数左右。这里需要说明：不同教程、不同仓库对同一个模型的命名习惯可能不一样，你在 Ollama 或模型仓库里看到的标签也可能不叫这个名字。文章里我沿用标题里的称呼，但实际部署时应该以你选择的模型仓库里真实存在的标签为准。

27B 参数意味着它属于中等偏大的本地模型。相比 7B、8B 级别，它在复杂指令理解、结构化输出上的表现通常会更好；相比 70B 级别，它对硬件要求又友好很多。从实操角度看，27B 模型的核心价值是：当你给它一段复杂任务说明时，它更不容易“跑偏”。生成 PPT 大纲这种任务，看起来简单，但模型需要同时理解主题、受众、页数和内容深度，参数太小的模型经常会丢三落四。

2.2 Ollama 在中间扮演什么角色

Ollama 是目前本地部署大模型最常见的工具之一。它的作用是帮你把 Hugging Face 或其他模型仓库里的模型，转换成可以直接在本地运行的服务，并暴露一个兼容 OpenAI 格式的接口。

+----------------+ HTTP API +----------------+ | Qwen3.8-27B | <------------> | Ollama Server | +----------------+ +----------------+ | | OpenAI 兼容接口 v +----------------------+ | WorkBuddy / 其他Agent | +----------------------+

也就是说，Ollama 把“模型文件下载、量化、进程管理、接口暴露”这些事情封装掉了。你不需要自己写推理代码，只需要拉取模型，然后启动服务。

2.3 WorkBuddy 是做什么的

WorkBuddy 在热搜词里经常和“AI Agent”“Skill”“本地部署”一起出现，说明它是一款偏 Agent 形态的本地工具。简单理解，它不是大模型本身，而是一个让大模型能力可以“付诸行动”的调度器。

常规的大模型对话只能输出文字，不能直接帮你操作文件、调用工具。WorkBuddy 这类 Agent 工具做的事是：

1. 接收你的自然语言指令，比如“帮我生成一个关于 Spring AI 的 10 页 PPT”。
2. 调用本地或远程的大模型，先规划如何完成任务。
3. 根据规划调用对应的“技能”，比如执行 Python 脚本、调用 python-pptx 生成 PPT。
4. 把执行结果返回给你，并生成最终文件。

在 PPT 生成这个场景里，WorkBuddy 的价值不是替你打开 PowerPoint 手动操作，而是把“内容生成”和“文件生成”串成一条自动化链路。

2.4 Skill 是什么

Skill 在 WorkBuddy 体系里可以理解为“预定义的工具能力”。你可以把生成 PPT 的完整 Python 脚本封装成一个 Skill，让 WorkBuddy 知道：当你收到“生成 PPT”的请求时，应该调用哪个脚本、需要哪些参数、输出文件放在哪里。

Skill 的价值在于复用。如果你每次生成 PPT 都要把 python-pptx 脚本重新写给 Agent，效率很低。封装成 Skill 之后，Agent 只需要根据具体主题和页数，往 Skill 模板里填充内容，再执行脚本即可。

2.5 四个概念之间的关系

用一句话总结：Qwen3.8-27B 是大脑，Ollama 是大脑的宿主，WorkBuddy 是调度中枢，Skill 是调度中枢手里的工具。没有 WorkBuddy，模型只能产出文字大纲；没有 Skill，WorkBuddy 不知道怎么把文字变成文件。这四者组合起来，才构成一条真正可以交付文件的 PPT 生成链路。

3. 环境准备：本地部署 Qwen3.8-27B 之前要确认的事

在动手之前，先明确一下这套方案对机器的基本要求。这不只是为了顺利跑通，也是为了避免“拉到 27B 模型后发现显存不足，又卡在启动阶段”这种常见挫折。

3.1 硬件档位参考

这里只讲一般性判断，具体以你实际机器的显存和内存为准。

• 第一档：24GB 显存及以上这是比较理想的情况。可以尝试运行体积完整的 27B 量化版本，推理速度和上下文处理能力都相对均衡。实际测试中，单次生成一页 PPT 大纲的响应速度会比较理想。

• 第二档：16GB 显存需要选择量化程度更高、体积更小的模型文件，或者通过 Ollama 的上下文长度参数做限制。生成的批次可以小一点，一次性生成 10 页内容可能偏慢。

• 第三档：8GB 显存甚至以下也不是不能玩，但更建议退一步，尝试 Qwen3 系列的 4B、7B 或 8B 版本。先用小模型跑通 WorkBuddy 到 PPT 生成的链路，确认整个流程没问题后，再在更高配置的机器上升级模型。

重要原则：先跑通，再调优。 不要一上来就追求“最强模型”， 先用最小链路验证 Agent、Skill、代码生成这三层是否正常。

3.2 软件环境清单

这套流程与操作系统关系不大，Windows、Linux、macOS 上都可以完成，差异主要体现在安装命令上。本文以 Ollama 在 Linux / macOS 上的常见安装方式演示，Windows 用户建议直接使用 Ollama 桌面安装包，后续命令保持一致。

需要准备的基础软件：

• Python 3.9 以上，用于运行 python-pptx 脚本。
• Ollama，用于本地拉取和运行 Qwen3.8-27B 模型。
• WorkBuddy 客户端或命令行工具，用于加载本地模型并调度 Skill。
• pip 依赖：python-pptx、requests。

3.3 需要提前理解的一个关键点

很多人第一次接触这套链路时，会误以为 WorkBuddy 自带 PPT 生成能力。实际上，它负责的是“调度”，真正把文字排成 PPT 的是你通过 Skill 或脚本定义的 python-pptx 逻辑。这个区分很重要：如果你的 Skill 脚本写得不好，再强的模型也无法生成好看的 PPT。

4. 本地模型安装与启动：Ollama 部署 Qwen3.8-27B 实操

4.1 安装 Ollama

安装这一步不做拓展解 释，直接给常见写法。注意，安装方式请以 Ollama 官方文档为准，因为不同系统、不同版本可能存在差异。

# macOS 或 Linux 下常见安装方式 curl -fsSL https://ollama.com/install.sh | sh # 安装完成后，查看 ollama 是否可用 ollama --version

Windows 用户可以直接下载安装包。安装完成后，打开命令行执行同样的ollama --version命令验证是否安装成功。

4.2 拉取本地模型

在拉取模型之前，先明确一点：不同模型仓库提供的标签名可能不一样。下面命令中的qwen3:27b是示意写法，具体标签请以 Ollama 模型库中真实存在的名字为准。

# 拉取模型，以仓库实际标签为准 ollama pull qwen3:27b

如果模型体积比较大，下载时间会偏长。下载完成后，可以用ollama list查看本地已有的模型列表。

ollama list

预期输出中包含你拉取的模型名称、体积和修改时间。

4.3 启动 Ollama 服务

Ollama 安装完成后默认会在本机启动服务。如果没有启动，可以手动执行：

ollama serve

服务启动后，默认监听本机11434端口。你可以通过 curl 验证服务是否正常响应。

curl http://localhost:11434/api/tags

如果返回了一个 JSON 列表，里面包含你已经 Pull 的模型信息，说明 Ollama 服务已经正常启动。

4.4 验证模型可以正常对话

在命令行里直接和模型对话，确认推理链路通。

ollama run qwen3:27b

进入交互模式后输入一句测试：

请用一句话介绍 python-pptx 库的作用。

如果模型能在合理时间内返回有意义的内容，说明本地模型部署完成。如果响应很慢或直接报错，通常和显存、内存、模型量化版本有关，可以回到第 3 节重新确认硬件档位。

5. WorkBuddy 安装与模型接入配置

5.1 WorkBuddy 安装

WorkBuddy 的具体安装步骤在不同版本上可能存在差异。一种常见的方式是从官方发布渠道获取安装包，按提示完成安装。另一种是以命令行方式运行，具体命令以项目文档为准。

这里给一个示意：

# 示意命令，实际请以 WorkBuddy 官方文档为准 workbuddy install

安装完成后，启动 WorkBuddy：

workbuddy start

如果安装包方式更友好，你会在界面中看到配置入口。

5.2 将 Ollama 模型配置为 WorkBuddy 的本地模型

WorkBuddy 通常支持配置多个模型来源，包括云端模型和本地模型。本地模型接入时，核心配置项就是 Ollama 的服务地址和模型名称。

配置内容通常类似：

model_provider: ollama ollama: base_url: http://localhost:11434 model: qwen3:27b temperature: 0.7 max_tokens: 2048

配置完成后，可以先在 WorkBuddy 里做一次简单对话测试，确认它能调用到本地模型。

5.3 加载一个 PPT 生成 Skill

Skill 的作用是告诉 WorkBuddy“生成 PPT 时应该做什么”。一个最简单的 Skill 定义通常包含：

• 技能名称。
• 触发条件或者描述。
• 调用的脚本或命令。
• 需要的参数模板。

示意结构如下：

{ "name": "generate_ppt", "description": "根据用户提供的大纲内容生成 pptx 文件", "script": "scripts/generate_ppt.py", "parameters": { "title": "幻灯片标题", "pages": "大纲列表" } }

注意，这只是一个示意结构。实际 Skill 格式请参考你使用的 WorkBuddy 版本。这里的关键是让你理解：你需要把“生成 PPT”这个动作封装成工具，Agent 才能调用。如果 Skill 没有被加载，WorkBuddy 即使拥有再强的模型，也不知道该怎么帮你生成文件。

6. 完整流程拆解：从一句话到一份 PPT 文件

这个章节我们走一遍完整链路。假设你现在要做一份内容主题为“Spring AI 入门”的技术分享，页数 10 页左右。

6.1 第一步：设计提示词

提示词是整个流程中影响最大的环节。模型生成的大纲质量，直接决定 PPT 的结构是否合理。一段高可用的提示词应该明确以下信息：

• 主题。
• 受众。
• 页数。
• 内容结构要求。
• 输出格式。

这里给出一个可行的提示词模板：

请为一个面向 Java 后端开发者的技术分享生成 PPT 大纲。 主题：Spring AI 入门 页数：10 页 要求： 1. 第 1 页为封面，包含标题和副标题。 2. 中间 8 页按照“背景 - 核心概念 - 快速上手 - 关键代码 - 常见坑 - 生产建议”组织。 3. 最后一页为总结和 Q&A。 4. 输出格式为 Markdown 列表，每页标注页数、标题、要点。

6.2 第二步：在 WorkBuddy 中向本地模型发起请求

启动 WorkBuddy 后，在对话输入框粘贴上面的提示词。WorkBuddy 会调用本地 Qwen3.8-27B 模型，并返回一份结构化的 Markdown 大纲。

此时，整条链路已经完成了“内容生成”环节。但注意：WorkBuddy 还没有生成 PPT 文件。它只是拿到了大纲文本。要想产出.pptx，需要继续走到下一步。

6.3 第三步：WorkBuddy 调用 Skill 执行 PPT 生成脚本

当 WorkBuddy 拿到 Markdown 大纲后，它可以根据你预置的 Skill 定义，调用一个 Python 脚本。脚本的核心任务是解析 Markdown 大纲，然后使用 python-pptx 创建 PPT 文件。

这个环节真正考验的是脚本的质量。如果脚本能处理 Markdown 标题、列表和代码块，那生成出来的 PPT 结构会比较完整；如果只是固定模板，内容的呈现力就会弱很多。

6.4 第四步：保存并检查文件

脚本执行完毕后，会在指定输出目录生成.pptx文件。此时可以打开文件检查版式和内容。如果发现某一页的文字太多，或者某一页要点顺序不对，不要手动在 PowerPoint 里改，而是回到提示词或大纲层面去调整，然后重新生成。这恰恰是本地链路相对于在线工具的核心优势：内容是数据，文件是产物，数据改掉之后，产物可以重新渲染。批量修改和维护的成本会低很多。

7. 完整示例：python-pptx 生成 PPT 的最小实现

为了让整套流程更具体，这里给出一个可以直接运行的 python-pptx 示例。假设你已经通过 WorkBuddy 或模型对话拿到了一个包含“标题、小标题、要点”的简单大纲 JSON，下面的脚本会把它渲染成 PPT。

7.1 准备依赖

pip install python-pptx

7.2 大纲文件示例

在项目目录下创建outline.json：

{ "title": "Spring AI 入门", "subtitle": "Java 开发者的本地 AI 应用实践", "sections": [ { "heading": "为什么要关注 Spring AI", "points": [ "把 AI 能力集成进 Java 应用", "降低大模型 API 的接入成本", "与 Spring 生态无缝整合" ] }, { "heading": "核心概念", "points": [ "ChatClient", "Prompt Template", "Model 与 Embedding" ] }, { "heading": "快速上手步骤", "points": [ "创建 Spring Boot 项目", "添加 Spring AI 依赖", "配置本地模型地址", "编写测试接口" ] } ] }

7.3 Python 脚本

在项目目录下创建generate_ppt.py：

import json from pptx import Presentation from pptx.util import Inches def create_presentation(outline_path, output_path): with open(outline_path, "r", encoding="utf-8") as f: outline = json.load(f) prs = Presentation() # 封面页 slide_layout = prs.slide_layouts[0] slide = prs.slides.add_slide(slide_layout) slide.shapes.title.text = outline["title"] if outline.get("subtitle"): slide.placeholders[1].text = outline["subtitle"] # 内容页 content_layout = prs.slide_layouts[1] for section in outline["sections"]: slide = prs.slides.add_slide(content_layout) slide.shapes.title.text = section["heading"] body = slide.placeholders[1].text_frame body.text = section["points"][0] for point in section["points"][1:]: p = body.add_paragraph() p.text = point prs.save(output_path) print(f"PPT 已生成：{output_path}") if __name__ == "__main__": create_presentation("outline.json", "spring_ai_intro.pptx")

7.4 运行与验证

python generate_ppt.py

如果代码正常执行，会在当前目录生成spring_ai_intro.pptx。用 PowerPoint 打开后，应该看到 4 页内容：第 1 页封面，后 3 页分别对应 outline 中的三个 section。

这个示例本身很简单，但它已经具备了一个可运行的 PPT 生成核心。把代码中的outline.json读取部分替换为 WorkBuddy 接收的模型输出，再对页面布局做增强，就变成了一条真正可复用的本地生成链路。

8. 常见问题与排查思路

以下是在本地部署和 PPT 生成过程中出现频率较高的问题。

除了这些具体问题，还有一个需要养成的排查习惯：分层排查。当链路不通时，先确认模型层是否正常，也就是直接通过 Ollama 对话能否得到结果；再确认 Agent 层是否正常，也就是 WorkBuddy 能否调用模型；最后确认执行层，也就是 Skill 脚本能否在命令行单独运行成功。大多数问题都可以定位在某一个层。

9. 最佳实践与工程建议

9.1 内容与文件分离

把 PPT 的内容大纲和最终文件分开管理。大纲可以是一份 Markdown、JSON 或 YAML，保存在项目目录里；最终 PPT 文件由脚本生成。这样你不仅能用 Git 追踪大纲的变更，还能在内容修改后一键重新生成文件。这是本地方案相对在线编辑最有工程价值的点。

9.2 提示词模板化

不要把提示词写在 WorkBuddy 对话框里。建议单独建一个prompts/ppt_generation.md，把常用提示词沉淀下来。每次生成 PPT 时，只需要替换主题、页数和受众几个关键变量。这样可以减少模型输出的随机性，保证不同主题的 PPT 风格相对稳定。

9.3 Skill 脚本要做得足够“窄”

一个 Skill 最好只做一件事。PPT 生成 Skill 就专注于大纲转 PPTX，不要在脚本里混入 PDF 转换、图片搜索、文档解析等其他能力。Skill 职责越单一，WorkBuddy 调度起来越稳定，排错也越方便。

9.4 上下文长度与显存控制

本地模型的显存占用受上下文长度影响明显。如果你的机器显存不是特别充裕，可以在 Ollama 配置里适当降低上下文长度。生成 PPT 大纲这种任务，不需要特别长的上下文，压缩到 8K 甚至更短通常已经够用，能显著降低响应时间。

9.5 安全与权限边界

这套方案本身是本地化的，所以在隐私方面先天占优。但要注意，Skill 脚本可能包含文件写入、网络请求等操作，所以：

• 不要在 Skill 脚本中硬编码敏感信息。
• 对脚本可访问的目录做最小授权。
• 在团队内推广时，建议提供一个默认配置模板，不允许个人随意修改底层脚本路径。

9.6 从最小链路开始迭代

第一次搭建时，建议先用最小的模型版本跑通整个 WorkBuddy 到 PPT 生成的链路，确认 Agent 和 Skill 都正常工作后，再切换到 27B 模型做内容层面的优化。不要一开始就把两个未知变量同时引入系统。先保证流程稳定，再追求模型输出的质量。

10. 总结

这条链路的本质，是把一个在线 AI 工具的卖点拆成了三个可替换的模块：本地模型负责内容理解，Agent 负责任务调度，python-pptx 脚本负责文件渲染。理解了这一点，你就不会把“AI 生成 PPT”看作一个神秘的黑盒，而是把它看作一个可以逐步改造、按需增强的工程流水线。

实际做一遍之后，你会发现真正的难点不在模型，也不在 Agent，而在“如何把内容转化为合适的文件结构”。提示词写得清楚，脚本做得规整，生成的 PPT 才会稳定可靠，而不是偶尔给你一份结构混乱的页面堆叠。

建议收藏本文，动手搭一条最小链路的时候对照着做。跑通之后，再按照自己团队的使用场景优化提示词、扩展 Skill，把它变成真正能交付的工程能力。