做这个项目的起因很简单每次要出一份带逻辑、有层次的PPT光是列大纲、想标题、逐页抠文案就得耗掉半天时间。我当时的想法是既然 DeepSeek 的 API 调用已经足够便宜干脆写个小工具输入一个主题让模型把整个PPT的骨架和文案全部生成出来再用代码渲染成能直接编辑的pptx文件。做完之后我最大的感受是真正费工夫的不是调 API而是怎么把大模型的输出“接住”让它变成一个可控、可复用的产物。这篇文章就围绕这个实战项目展开适合正在用大模型API做小工具、或者想搞清楚 DeepSeek 怎么落地到实际业务的人。我会从方案选型、结构化输出设计、Prompt 调优、渲染实现到问题排查把每一步踩过的坑和替换过的方案都写清楚尽量做到你看完就能照着再造一个。1. 先拆需求PPT生成器到底是要“写内容”还是“做排版”1.1 这件事到底在解决什么问题如果你只是想要一个“输入题目输出一个还不错的PPT文件”的效果市面上现成的AI PPT产品已经很多。但这类产品的通病是模板锁定重、内容可编辑性差经常生成完还得去网页里手动调半天。我想要的其实是另一件事一个能自己掌控全流程、内容结构可控、之后能轻松二次编辑的生成管线。拆开来看PPT生成的痛点无非三个结构规划难不知道一页讲什么、整体讲几条线。文案打磨慢标题怎么起、要点怎么浓缩、措辞怎么平衡专业性和可读性。排版负担重写好了内容还要反复调字号、对齐、换布局。所以这个项目的第一层目标就很明确了让AI负责“内容策划文案填充”让代码负责“把策划案变成文件”。大模型不需要懂排版代码也不需要懂文案两者各干各的再用一份结构化数据把两边衔接起来。这样的好处是不管以后换模型还是换渲染库改起来都很快。1.2 技术选型为什么是DeepSeek而不是别的大模型我当时在选型上其实对比过几套方案。GPT系列的效果确实稳但是按生成一份20页PPT的token量算成本还是偏高的。国内其他家的API我也简单试过早期版本在长文本JSON输出上不够稳定容易在中途截断或者格式跳变。最后选了 DeepSeek 的云 API核心原因有三个便宜生成一份二三十页的完整PPT内容量全部加起来成本也就几分钱到几毛钱这个量级基本可以忽略不计。稳定性deepseek-chat 在结构化输出上表现不错尤其是给足示例之后很少出现格式乱掉的情况。兼容性DeepSeek API 兼容 OpenAI 的调用格式直接用 openai 这个 Python SDK 改一下 base_url 就能跑通省掉了重写客户端的麻烦。还有人会考虑本地部署 DeepSeek好处是数据不出内网、不担心限流但对硬件的门槛不低而且小参数模型在长文档规划类任务上的表现确实不如云端满血版。我的观点是做工具原型的阶段直接调云 API 是性价比最高的路径等业务量稳定了再评估要不要切成本地推理也不迟。2. 方案设计让大模型只写内容不碰排版2.1 内容与样式分离是这条链路最核心的设计很多人在做AI生成PPT的时候最容易犯的一个错误是试图让模型“直接生成整个文件”。大模型其实根本不适合直接生成二进制文件它更适合做的事情是生成纯文本形态的“内容结构”。这就像写报纸记者只需要交稿排版师傅负责把稿子排进版面。你把这两个角色混在一起两边都会别扭。我采用的方案是模型输出严格的结构化JSON代码再把JSON渲染成PPT。JSON 里面有整份演示文稿的标题、副标题、每一页的版式类型、标题文案、要点列表、备注以及一些给渲染层的提示字段。这样做有三个落地层面的好处可控JSON 里每一项都能校验缺字段、多字段、类型不对代码里可以提前拦截。便宜相比让模型反复产出完整HTML或Markdown再去转换JSON 的token开销更低。可复用渲染成 PPT 只是其中一种消费方式。同一份 JSON 还能用来生成演讲备注、转成思维导图、或者作为知识库条目存起来。所以我整个项目的“心脏”不是渲染代码而是这份JSON的Schema设计。2.2 结构化输出的核心把PPT拆成JSON我定义的 JSON 结构一开始比较简单只有 title 和 slides后来在实际跑的过程中迭代了几版。最终版大致长这样{ title: 2025年AI Agent落地实践, subtitle: 从工具链到业务价值的完整拆解, slides: [ { layout: cover, title: AI Agent落地实践, bullets: [], notes: 开场介绍主题说明本次分享的三大板块。 }, { layout: bullets, title: 核心观点, bullets: [ Agent不是单一模型而是模型工具流程的组合, 落地效果取决于场景选择而非模型能力, 评估指标要从准确率转向交付效率 ], notes: 先用三句话建立听众的整体认知。 } ] }字段设计上layout 是渲染层用来选版式的bullets 是每页的要点notes 是演讲备注。对生成结果不要求每页都有副标题、图表类型这类复杂字段宁可少一点先保证链路通畅再逐步加复杂功能。2.3 Prompt设计怎么让DeepSeek稳定输出JSON我没有用 function calling 那套机制因为对于这种纯文本生成的场景直接通过 Prompt 约束输出反而是最简单、最不依赖版本变动的方案。核心的 Prompt 写法我总结成四条经验角色设定不要虚直接说“你是一个PPT内容策划专家”然后给具体任务。任务分成两步走第一步只生成大纲 JSON第二步再在每页框架上填充详细文案。一次生成的页数多了模型容易写到后面开始“偷懒”要点越写越短。给出一段 Few-shot 示例而不是只描述格式。示例比规则有用得多模型看过一条完整的“输入-输出”之后模仿起来更精准。明确要求“只输出JSON不要输出任何解释”。如果不加这句话模型经常会在JSON前后加一些“这是我为您生成的方案”之类的废话增加解析负担。另外temperature 要压低。我一般用 0.3 到 0.7 之间低了文案会比较死板高了容易出现花哨但无用的表达。如果你用的是 deepseek-reasoner 这类推理模型注意它不支持 temperature 参数直接传上去会报错这块后面实操章节会细说。3. 实操过程从API接入到PPT渲染的完整实现3.1 环境准备依赖其实只有三个整个项目我用的是 Python依赖非常轻。除了 Python 3.10 以上版本真正用到的库只有三个openai作为 DeepSeek API 的客户端。python-pptx负责把JSON渲染成pptx文件。pydantic可选用来做JSON校验和字段类型检查不想多装依赖的话也可以只用内置json和手工断言。安装命令如下pip install openai python-pptx如果以后想扩展成Web服务再补 FastAPI 和 uvicorn 也不迟。我最初把依赖控制得很小就是为了让这个工具能在一台普通电脑上直接跑不引入重框架。你如果习惯在 Java 项目里开发也可以参考 Spring AI 这类封装库但我会更推荐直接用官方兼容接口少一层中间件反而更容易排查问题。3.2 调通DeepSeek API兼容OpenAI的客户端用法DeepSeek 的接口地址是https://api.deepseek.com模型名分为deepseek-chat和deepseek-reasoner两种。因为我做的是内容生成任务用deepseek-chat就够速度和稳定性都好一些。下面是基础调用方式from openai import OpenAI client OpenAI( api_keysk-你的key, base_urlhttps://api.deepseek.com ) resp client.chat.completions.create( modeldeepseek-chat, messages[ {role: system, content: 你是一个PPT内容策划专家。}, {role: user, content: 请为主题AI Agent落地实践生成一份20页PPT的大纲JSON。} ], temperature0.5, max_tokens6000 ) print(resp.choices[0].message.content)这里有个细节值得注意base_url不要填错SDK 会自动拼上补全路径。我第一次测试时把base_url填成了带/v1的地址导致路径被拼成了/v1/chat/completions的二次拼接白白浪费了半小时排查。如果你在 VSCode 里面做测试可以直接装一个 DeepSeek 的 IDE 插件来快速验证 Prompt但项目内集成还是要走 SDK两者别混淆。3.3 两阶段生成先搭骨架再填血肉最开始我尝试一次性让模型生成整份PPT的JSON结果规律性地出现两个问题内容写到中后段开始重复总token数一高输出被 max_tokens 截断导致 JSON 不完整。后来我改成两阶段生成。第一阶段只生成大纲每个 slide 只含 title、layout、keywords不写具体文案。第二阶段拿着这份大纲逐页生成 bullets 和 notes。每页单独调用一次API虽然请求变多了但每次返回都在可控长度内质量明显提升。实现起来大概是这样的伪代码def generate_outline(topic): prompt OUTLINE_PROMPT.format(topictopic) content chat_with_deepseek(prompt) return extract_json(content) def generate_slide_details(outline): slides [] for slide in outline[slides]: prompt SLIDE_PROMPT.format( titleslide[title], layoutslide[layout], keywords,.join(slide.get(keywords, [])) ) detail chat_with_deepseek(prompt) slide_data extract_json(detail) slides.append(slide_data) return {title: outline[title], slides: slides}很多人会担心两阶段调用太慢但实测下来一份20页左右的PPT总耗时也就一两分钟完全在可接受范围内。这比一次性生成然后反复纠错要快得多。3.4 渲染层用python-pptx把JSON变成能编辑的PPT渲染层我用的是 python-pptx。它不复杂核心就是三个动作创建演示文稿、添加幻灯片、填充文本框。下面是我渲染单页的简化代码from pptx import Presentation from pptx.util import Inches, Pt def add_content_slide(prs, title, bullets): slide prs.slides.add_slide(prs.slide_layouts[1]) slide.shapes.title.text title body slide.shapes.placeholders[1].text_frame body.clear() for i, bullet in enumerate(bullets): p body.paragraphs[0] if i 0 else body.add_paragraph() p.text bullet p.font.size Pt(16)这里有个容易踩的坑placeholders[1]不一定在所有模板里都存在。如果你自定义了母版或者选择的 layout 没有正文占位符取这个索引会直接报错。稳妥的做法是先判断一下if len(slide.placeholders) 1: body slide.placeholders[1].text_frame另外一份PPT能不能“见人”很大程度上取决于版式是否多样。我给 layout 字段做了几个固定值比如cover、bullets、section、two-column再在渲染层做一个简单的映射表layout 值渲染方式适用场景cover大标题居中封面页bullets标题要点列表内容页section章节分隔页转场页two-column标题左右两栏正文对比、并列内容一开始不要追求太多版式先把两三种跑通后续再看需求补充。3.5 内容溢出处理动态字号和自动换行实际渲染时最难受的问题不是格式而是文字太长导致溢出。比如模型把一条 bullet 写出了两三百字哪怕用 14 号字也会溢出版心。我的处理办法是在渲染层根据内容长度自动调整字号和换行。def fit_font_size(text, max_size18, min_size12): length len(text) if length 150: return min_size if length 100: return min_size 1 return max_size很朴素但至少能兜底。更精细的做法是把文本框的高度算出来逐级降字号直到不溢出这个看你有多少精力去打磨。对我来说先保证不溢出、可读比完美排版更重要。4. 常见问题与排查技巧实录4.1 模型输出的JSON总是带“杂质”怎么办这是我遇到最多的一个问题。模型明明被要求“只输出JSON”但实际返回里还是会出现 Markdown 代码块标记比如json 开头和结尾甚至偶尔在前面加一句“好的这是您的JSON”。针对这个问题我写了一个非常实用的解析函数import json, re def extract_json(text): # 尝试提取 json ... 块 match re.search(rjson\s*(\{.*?\})\s*, text, re.S) if match: return json.loads(match.group(1)) # 退化情况直接干掉所有和语言标记 clean re.sub(rjson|, , text).strip() return json.loads(clean)如果这样还解析失败那就说明模型真的返回了不完整内容重试一次往往就好了。真正到生产环境可以再加一个“解析失败就重试最多3次”的循环。4.2 生成内容太慢怎么优化响应时间两阶段生成相比单次调用肯定会更慢因为请求次数变多了。如果对速度有要求可以从四个方向调整控制页数默认生成10页以内质量更容易保证。控制每页要点数量限制在3到5条既符合 PPT 的阅读习惯也减少 token。换成 deepseek-chatreasoner 在复杂推理上更慢内容生成场景用不上。开启流式输出用streamTrue让用户一边看生成一边等体验上会好很多。4.3 模型生成的内容“假大空”AI生成PPT最大的毛病不是跑偏而是正确但没用的废话。比如你问“如何提升销售额”它给你列三条“加强市场推广、提升客户满意度、优化产品结构”——听起来都对等于没说。我的解决方法是两招结合。第一招在 Prompt 里强制要求“每个要点必须包含一个具体动作或指标”。第二招在第二阶段生成时把第一阶段大纲中的行业背景、目标人群这些关键词一起喂给模型让它围绕具体语境写而不是泛泛而谈。试过之后内容质量会有肉眼可见的提升。4.4 成本预估和控制很多人担心大模型 API 是不是很贵。按我实际项目的经验DeepSeek 的定价折算下来一次完整的 PPT 生成大纲20页内容大概消耗一万多 token成本也就是几分钱到几毛钱人民币的级别。相比省下来的时间这个成本完全可以接受。控制成本最有效的方法是限制max_tokens。如果你不限制模型可能因为某些异常情况“滔滔不绝”地输出造成不必要的费用。我给每次调用的max_tokens都会结合当前任务预估比如大纲阶段设 3000单页内容阶段设 800。4.5 调用频率过高被限流怎么办你要是拿这个工具给团队多人同时用就可能会遇到限流。我的处理方案是加退避重试第一次失败等1秒第二次等2秒第三次等4秒。同时在客户端侧做请求合并比如同一用户一分钟内重复生成相同主题直接返回上次结果。import time def chat_with_retry(client, messages, max_retries3): for attempt in range(max_retries): try: return client.chat.completions.create( modeldeepseek-chat, messagesmessages, temperature0.5, max_tokens3000 ) except Exception as e: if 429 in str(e) or rate in str(e).lower(): wait 1 * (2 ** attempt) time.sleep(wait) else: raise说实话DeepSeek 的限流策略已经算宽松了。非高频调用基本遇不到问题加上重试之后就更是稳如老狗。结尾一点个人体会这个项目做完以后我最深的一个感受是AI 应用开发的大头不在“调用模型”而在“约束模型”。模型本身只是一个生成能力很强的引擎怎么让它稳定输出、怎么兜底、怎么把输出变成生产可用的一环才是真正花时间的地方。整个过程中 DeepSeek 的 API 没有给我添什么麻烦麻烦的往往都是我自己对 Prompt 边界想得不够清楚。最后分享一个小习惯我每个生成结果都会同时保存一份 JSON 源文件和渲染出来的 pptx。这样后面想改版式、换模板、或者把内容重新导出成其他格式都不用重新调模型直接改渲染层就行。这个思路扩展一下还可以把 JSON 喂给不同的前端模板一套内容输出多种形态整体效率会提升得非常明显。