企业官网建设流程全解析

简介：针对Coze平台智能体生成PPT的完整实操教程，以单个PDF文档（共1个文件，约4.26MB）整理呈现。教程面向希望提升PPT制作效率的企业员工与个人用户，重点解决传统制作中耗时长、版式设计依赖审美经验、反复修改等痛点，尤其适合缺乏专业设计能力的人群。内容详细对比了传统方式与AI智能体制作PPT的优劣，并给出基于Coze平台的两种生成路径：一是配置智能体技能并调用iSlide等插件直接生成；二是创建工作流，通过编排插件顺序获得更稳定的输出质量。文中还提供角色提示词设计、插件配置、工作流节点设置与测试方法等完整步骤，并在附录中介绍了DeepSeek、Kimi、通义千问等大模型协作生成PPT的操作思路，帮助读者按需选择工具组合。目前已有473人学习，适合希望在短时间内生成符合特定风格与内容要求的PPT、降低重复劳动的读者参考，是一份可以直接上手的Coze智能体实操资料。

1. 基于Coze平台打造PPT智能体：真正要省的是选题和排版之间的那段路

一份20页的季度汇报PPT，从搜模板、凑大纲、排文案到调格式，少说也得花三个小时。我以前最烦的不是内容不够，而是内容明明都在脑子里，却要在PPT编辑界面里一点点搬。后来我在Coze平台上搭了个PPT智能体：丢给它一个主题，它会自己拆出大纲、补足资料，再渲染成一个能直接打开的pptx文件。这事听起来有一点点玄学，但它本质上是把“想”和“做”拆开——大模型负责想，脚本负责做，平台负责把它们串起来。这篇笔记适合两类人：想用Coze快速做出能用的PPT的职场人，以及想把智能体开发这条链路跑通的学生和工程师。新手可以照步骤走，熟手可以直接看第五章的坑。

2. 为什么这个PPT智能体应该建在Coze：原理、选型和链路边界

在动手搭之前，先想清楚一个问题：PPT智能体解决的是“做PPT”这个完整过程，而不是“生成一段PPT文案”。只有理解了这条链路，你才不会被网上各种教程带偏。下面我把原理、平台选型和适用边界一次说清。

2.1 智能体不等于聊天机器人：一次完整的“理解、检索、编排、渲染”过程

很多第一次接触智能体开发的人，会把智能体当成一个大号聊天框。实际在Coze里搭一个PPT智能体，你要设计的是四件事：理解、检索、编排、渲染。理解负责把“我想做一个关于YOLO算法讲解的PPT”这种模糊需求，拆成“主题、页数、受众、风格”；检索负责补充资料，比如行业数据、公司大事记；编排负责决定先出大纲还是先写单页文案；渲染负责把结构化数据变成真正的pptx文件。这四个环节不是只有聊天能完成，而是工作流、插件、代码节点和知识库的协作。

以“做一个YOLO算法讲解PPT，15页，面向刚入门的技术同学”为例，完整链路在Coze里是这样的：

1. 用户在对话框输入主题和限制条件。
2. 开始节点把主题、页数、受众三个参数拆出来。
3. 搜索插件抓取几篇关于YOLO的公开资料。
4. 大模型节点把需求、资料和你的要求综合起来，输出一份15页的JSON。
5. 渲染服务接收JSON，套用模板，输出pptx。
6. 结束节点把文件下载链接和一句使用说明返回给用户。

这六步在Coze里就是六个节点，节点间用连线串起来。Coze把每一步都解耦了，所以你能单独排查哪一环出了问题。

为什么中间一定要用JSON？因为大模型直接输出整篇文案时，渲染端很难把每一页的内容精确切割进模板。JSON是一种中间契约，渲染端不需要理解自然语言，只需要按字段读取。只要契约稳定，你换模型、换模板都不会影响整条链路。在Coze工作流左侧的面板里，你至少会用到开始、大模型、插件、知识库、代码、条件分支、结束这几类节点。照着上面的六步，把对应节点拖进去连线，就有一个最小骨架。

2.2 对比自研和对比Dify，Coze的优势落在哪里

自研一套PPT智能体，不是不行，我也写过。大模型API接入、Prompt管理、多轮会话保存、文件生成、任务队列，一套下来至少两周。Coze把这些基础设施替你承担了：身份管理、变量存储、插件市场、知识库、工作流日志都内置好了，你要做的只是把业务逻辑填进去。

同类的智能体平台里，大家最常拿来对比的是Coze和Dify。Coze在国内常被叫作扣子，上手门槛更低，插件的即插即用感更强，尤其适合最短时间验证需求；Dify在工程自定义和私有化方面更细致，适合公司内部深度定制。不是谁说更好，而是你的场景决定了选谁。如果只是想快速看到PPT智能体长什么样，Coze目前是成本最低的一条路。下面这张表帮你判断：

表格只是选型参考，不是真理。我自己的经验是：如果你的目标是判断“这个方案值不值得做”，先用Coze跑通最小版本，不要一上来就钻到自研的坑里。PPT智能体有价值的部分在业务编排，不在基建。

如果你还没在Coze里建过Bot，可以先花五分钟把下面的最小骨架建出来：创建一个Bot，不写人设；创建一个工作流，拖入开始、大模型、结束三个节点；在大模型节点随便写一句“总结{{topic}}的主要结论”；发布到对话框测试。这一圈走下来，你就理解了节点和变量的关系。然后再回来把人设替换成PPT要求。这个动作不是为了做PPT，而是为了让你先把Coze的交互习惯跑一遍。

这里有个常见误区：总想找一个“能直接生成PPT”的现成功能。Coze本身不内置PPT生成器，真正的能力来自你如何组合节点。同一平台，有人搭出来的是查天气Bot，有人搭出来的是完整的内容生产线。PPT智能体的价值，更多取决于你的编排设计。

2.3 先定边界：这台智能体能做什么，不能做什么

它能做的是：工作汇报、课程课件、项目方案、产品说明，凡是结构化内容大于设计感需求的PPT都适合。它做不好的是：需要复杂动画、精细排版、创意视觉的发布级PPT。原因很直白，当前自动渲染方案大多基于模板布局，一个页面里放几句话、一张图可以做到规范，但要像设计师那样让每个素材都长在合适位置，还不存在通用的AI方案。

所以我给你一个实操建议：把PPT制作拆成内容生产和版式设计两个阶段。智能体负责内容生产——大纲、文案、数据整理、演讲备注；版式设计如果有严格标准，就靠模板来兜底，不要让智能体自由发挥。比如给投资人看的品牌提案，我会让智能体只出大纲和文案，排版这步人工接住。

另外要注意，纯文字页面好做，公式页、结构图页、跨页表格页要复杂得多。如果需求里包含LaTeX公式或架构图，建议人工介入，否则渲染服务要处理的东西会无限膨胀。认清楚这条边界，比学会某个参数更重要，它会让你写Prompt和调接口时少很多内耗。

3. 最小可跑通版本：从Bot人设到渲染服务一次打通

这一章带你搭出一个能跑通的最小版本。它一共三步：先建一个Bot，再配置工作流，最后把渲染服务准备好。不需要你完整理解所有配置，先让它动起来，你再去品。

3.1 第一步：创建PPT智能体Bot，把“人设”当成说明书来写

进入Coze控制台，创建一个Bot，命名为“PPT助手”。创建之后会进入人设与回复逻辑编辑页。这个地方你不要只写“你是一个PPT助手”这种废话，要写清楚你希望它如何工作。人设就是一份面向大模型的接口文档。我的人设Prompt如下。

你是PPT智能体。用户给你一个主题后，你的目标是输出一份可直接用于生成PPT的结构化内容。 要求： 1. 先判断需求：如果主题不够具体，只回一句“请补充主题、页数和风格”，不要展开。 2. 不需要开场白，直接输出JSON。 3. JSON格式固定为： { "title": "主标题", "subtitle": "副标题", "slides": [ { "title": "一页小标题", "bullets": ["要点1", "要点2"], "speaker_notes": "演讲备注，0-1句话" } ] } 4. 整本PPT控制在用户要求的页数内，未指定时默认12页。 5. 小标题要能单独站得住，不要只写“概述”“详情”这种空词。

这段人设之所以有效，是因为它同时约束了三件事：用户输入不完整时别硬做；输出格式必须固定；小标题必须具体。很多PPT智能体翻车，第一原因就是没在这个环节管住大模型的发挥。

还有一个小细节：在Coze里，Bot默认会开启“对话开场白”，这会让你一打开就收到“你好，我是PPT助手，请问需要什么帮助？”这种废话。我建议关掉，或者把开场白改成“请把PPT主题、页数和风格一次发给我”，否则用户会在寒暄上浪费时间。

提示：人设Prompt会直接影响后续所有生成，修改后建议用同一主题测3次再决定要不要保留。

3.2 第二步：大模型节点产出结构化PPT数据，用JSON做中间契约

在Coze里，你要做一个工作流，而不是让Bot直接在对话里生成。因为工作流可以把内容生成和文件渲染拆开，出问题也好排查。新建一个工作流，命名为ppt_workflow，然后开始配置节点。

开始节点里定义输入参数。创建后，开始节点默认已经有一个user_input，但我们不直接用。加一个topic（主题），一个page_count（页数，默认12），一个style（风格，默认商务）。这样上游参数可控。

然后添加一个“大模型”节点。在模型选择上，同一个平台可能提供多个模型，日常生成PPT我建议优先选上下文长、价格不高的。把3.1的人设Prompt复制进System Prompt区，把变量传进去。

你是PPT智能体，请根据以下参数生成PPT内容。 主题：{{topic}} 页数：{{page_count}} 风格：{{style}} 受众：{{audience}} 输出严格按如下JSON格式，不要输出额外文字： { "title": "主标题", "subtitle": "副标题", "slides": [ { "title": "一页小标题", "bullets": ["要点1", "要点2"], "speaker_notes": "演讲备注" } ] }

模型参数里的温度我一般调到0.3。这个值生成PPT内容时需要稳定和准确，太高会让文案飘，太低会显得死板。你可以在0.2到0.5之间试，找到自己内容口味的下限。

大模型节点的输出变量名为ppt_json。注意，很多模型会顺手把JSON包在Markdown代码块里，这会让后面的json.loads报错。我们在后面代码节点统一清理，现在不用纠结。经常有人用Coze做Markdown转Word工作流，其实把Markdown转成PPT也一样，中间层都先转结构化的JSON，再做渲染。

3.3 第三步：写出一个本地PPT渲染服务，让Coze通过HTTP调用

接下来解决“把JSON变成pptx”的问题。Coze的代码节点可以做轻量文本处理，但要在沙箱里直接生成pptx，新手经常会卡在依赖库安装上。我习惯的走法是：把渲染放到一个独立的小服务里，Coze工作流只负责把ppt_json通过HTTP送过去。你把这个服务部署到任何一台有Python的服务器上，拿到公网URL就行。

下面是一个最小可用的FastAPI渲染服务，依赖只有四个：fastapi、uvicorn、python-pptx、pydantic。

# app.py # PPT渲染服务：接收JSON，返回pptx文件 from fastapi import FastAPI, HTTPException from fastapi.responses import FileResponse from pptx import Presentation from pptx.util import Pt from pydantic import BaseModel from typing import List, Optional app = FastAPI() class Slide(BaseModel): title: str bullets: Optional[List[str]] = [] speaker_notes: Optional[str] = "" class PPTRequest(BaseModel): title: str subtitle: Optional[str] = "" slides: List[Slide] @app.post("/render_ppt") def render_ppt(req: PPTRequest): try: prs = Presentation() # 封面：布局0是标题页 slide = prs.slides.add_slide(prs.slide_layouts[0]) slide.shapes.title.text = req.title if req.subtitle and len(slide.placeholders) > 1: slide.placeholders[1].text = req.subtitle # 内容页：布局1是标题+正文 for s in req.slides: slide = prs.slides.add_slide(prs.slide_layouts[1]) slide.shapes.title.text = s.title body = slide.placeholders[1].text_frame for i, bullet in enumerate(s.bullets): if i == 0: p = body.paragraphs[0] else: p = body.add_paragraph() p.text = bullet p.font.size = Pt(18) if s.speaker_notes: slide.notes_slide.notes_text_frame.text = s.speaker_notes out = "/tmp/result.pptx" prs.save(out) return FileResponse(out, filename="generated_ppt.pptx") except Exception as e: raise HTTPException(status_code=500, detail=str(e))

这段代码做了什么？它把大模型输出的JSON映射到python-pptx的三种元素：标题、正文要点、演讲者备注。封面单做，内容页循环生成。你只需要在服务器上执行pip install fastapi uvicorn python-pptx pydantic，然后启动服务。如果你完全不想维护服务器，也可以用云函数托管同样的代码，只要暴露一个HTTP地址即可。

接着回到Coze工作流，在大模型节点后面接一个代码节点。这个代码节点的作用是把ppt_json发给我们刚部署的服务，拿回文件。代码示例如下。

# Coze工作流中的代码节点 import requests import json # 上游大模型节点传过来的 ppt_json 可能是字符串，先做清理 if isinstance(ppt_json, str): ppt_json = json.loads(ppt_json.strip()) # 替换成你自己的渲染服务地址 resp = requests.post( "https://your-server.com/render_ppt", json=ppt_json, timeout=60 ) if resp.status_code == 200: # 把返回的pptx保存为本地文件，结束节点会把它返回给用户 with open("/tmp/generated.pptx", "wb") as f: f.write(resp.content) return {"file": "/tmp/generated.pptx"} else: raise Exception("渲染失败: " + resp.text)

这段代码里最重要的一行是timeout=60。渲染服务第一次调用时可能要初始化或加载字体，给60秒不容易翻车。如果Coze平台本身对代码节点的超时限制较短，你要去检查结束节点的配置，尽量把文件输出放在最后一步。

最后在结束节点把file变量返回给用户。这样你就在Coze里搭出了一个真正能生成pptx的智能体。第一次跑通后，你再去优化Prompt和渲染细节，会从容很多。

4. 让PPT智能体真正可用：变量、知识库和资料检索的四个落点

最小版本能跑通，说明链路没问题。但它生成的PPT大概率还是“能看但不好用”。要让智能体从一个玩具变成生产力工具，你需要在变量、知识库、资料检索三个方向做加固。下面四个落点是我认为性价比最高的。

4.1 把用户需求拆成输入参数：主题、页数、风格、受众谁先定义

最小版本里我们只在开始节点放了三个参数，实际上还少一个：受众。同一份YOLO主题，给管理层讲和给开发同学讲，PPT完全不一样。给领导讲，结论要前置，术语要少；给开发同学讲，可以从网络结构、损失函数讲起。所以在开始节点里增加一个audience（受众）参数，默认“通用”。

参数定义好后，大模型节点的Prompt要跟着改，不要只在System Prompt里写死。我的习惯是做一个模板，把变量都暴露出来。

你是PPT智能体，请根据以下输入生成PPT JSON： 主题：{{topic}} 页数：{{page_count}} 风格：{{style}} 受众：{{audience}} 额外约束： - 受众是管理层时，每页首行必须是结论句，不要先讲背景。 - 受众是开发同学时，允许出现术语，但必须给一句大白话解释。 - 每页要点数量：4到6个，不要铺满整页。

把受众单独拎出来，而不是让大模型自己猜，能明显改善内容空洞的问题。很多AI生成的PPT被一眼看穿，就是因为没有明确的受众。另外，页数不是硬性数字。大模型很容易把12页理解成正好12页，结果内容少了硬凑。我在Prompt里会写成“页数是建议值，允许上下浮动20%”。

变量一旦定义好，后续Prompt和渲染服务要共用同一套命名，减少歧义。比如page_count在开始节点叫页面数量，在大模型节点改成pages，就很容易对不上。建议从开始就统一用英文小写下划线命名。

4.2 给智能体喂“审美”：知识库里放什么才能让PPT不再撞脸

PPT智能体还有个常见问题：排版不丑，但千篇一律。最大的原因是缺少你个人或公司的风格约束。解决办法不是去调渲染脚本，而是给智能体建一个很小的知识库，里面放三类东西：一是你常用的模板版式说明，二是品牌色和字体规范，三是你写过的高质量PPT文案。

在Coze里创建知识库，上传一个Markdown或PDF文件。文件内容不用长，但要结构化。这是我常用的知识库条目。

# 品牌规范 - 主色：#0E4C92（深蓝） - 辅助色：#00B4D8（亮蓝），只用于图表强调 - 正文字体：微软雅黑 18pt - 标题字体：微软雅黑 28pt 加粗 # 版式偏好 - 每页标题不超过10个字 - 要点列表不超过6条 - 数据页优先用柱状图，少用表格 - 每页底部保留页码和logo位置 # 内容习惯 - 结论写在标题里，不要写在结尾 - 有数字则用数字，不用“很多”“较快”

知识库建好后，在工作流里加一个“知识库节点”，把topic作为查询词，输出kb_results，然后在大模型节点里加入下面这段。

以下是你的品牌规范和内容习惯，必须遵守： {{kb_results}} 如果检索结果与用户要求冲突，以用户要求为准。

在Coze的知识库节点里，有一个召回数量参数，默认是10。对PPT智能体，我只取3条，多了会干扰大模型判断。知识库影响的是内容和表达，不是直接改渲染颜色。想真正让输出PPT的颜色、字体按规范走，你需要让大模型在生成JSON时额外输出一个style字段，渲染服务再据此改模板样式。把知识库规范当作内容约束，把视觉约束交给模板，两件事分开管，效率更高。

4.3 加一条搜索链路：先用资料填充事实，再让大模型写观点

PPT最怕没有事实支撑。做“YOLO算法讲解”，如果直接让大模型编，它会给一堆“正确但没用”的话。正确做法是在工作流里加一个搜索插件，把和主题相关的事实先捞出来，再让大模型基于事实写PPT。

常见的搜索插件都以query为入参，返回多条结果。你可以只取前三条的标题和摘要，塞给大模型。如果希望搜索内容更精准，可以在query里带上受众，例如“{{topic}} + 面向初学者的教程”，这样搜索返回的内容更贴合PPT受众。如果资料太多，反而会让输出不稳定。我的做法是让搜索节点返回之后，在大模型节点加了这样一段Prompt。

以下是关于“{{topic}}”的初步检索结果，请据此撰写PPT内容。 检索结果： {{search_results}} 要求： - 只采用检索结果中明确支持的事实，不编造数据来源。 - 如果检索结果为空，请明确说“暂时没有检索到足够资料”，不要硬编。 - 输出格式仍为之前约定的JSON。

加入搜索链路后，工作流整体耗时会长几秒。我在开始节点里加了一个timeout配置，把搜索插件的超时放宽到60秒。如果你做的是内部汇报PPT，主题本身很敏感，建议把搜索关掉，只走知识库。

有一个坑要提醒：AI会一本正经地编参考资料。所以即使加了搜索，PPT里如果出现“某某报告显示”这类字眼，我仍然会让人工核实。这条血泪经验适用于所有智能体项目，不只是PPT。

5. PPT智能体常见问题排查：这里记录的是我踩过的五个坑

很多人照着教程搭出来之后，第一版PPT往往能用但不能深看。下面五个问题，是我把智能体从能跑带到能用的过程中真实遇到的，每条按现象、原因、解决来写，方便你遇到问题时对着查。

5.1 翻车现象：生成出来的PPT页面稀碎，一页一个标题

现象：用户说做15页PPT，结果生成的文件有40多页，很多页只有一行标题，正文是空的。原因：大模型输出的JSON里，bullets为空。渲染服务拿到这样的JSON，也老老实实为每一条生成一页。本质是Prompt没有约束内容完整性，服务端也没有防御。

解决分两头：一是在Prompt里加“每页至少两个要点，没有内容就不要单独成页”；二是在渲染服务里过滤无效slide。我后来在渲染服务里加了这段防御代码，宁可少页数也不要产生碎页。

# 渲染服务中的防御：过滤空内容页 valid_slides = [] for s in req.slides: if s.title and (s.bullets or s.speaker_notes): valid_slides.append(s) if not valid_slides: raise HTTPException(status_code=400, detail="没有可渲染的页面")

加了之后，即使大模型偶尔出错，输出也不会太难看。这个习惯后来被我带进了所有模板渲染项目。

5.2 翻车现象：中文字体成了方块，演示现场下不来台

现象：在开发机上生成的pptx打开正常，换到会议室电脑就变成方块。原因：python-pptx生成文本时如果没指定字体，PowerPoint会沿用系统默认字体写入文件。开发机上碰巧有这个字体，会议室没有，中文字形就会缺失。

解决：在渲染服务里给每个run显式设置字体，并设置东亚字体属性。python-pptx对中文字体的设置比英文多一步，代码是这样。

from pptx.oxml.ns import qn def set_font(run, name="微软雅黑", size=18): run.font.size = Pt(size) run.font.name = name rpr = run._r.get_or_add_rPr() ea = rpr.find(qn('a:ea')) if ea is None: ea = rpr.makeelement(qn('a:ea'), {}) rpr.append(ea) ea.set('typeface', name)

在写入bullet时，对每个add_run后的run调用set_font即可。更保险的办法是渲染服务用固定字体文件，并把字体嵌入PPT。但嵌入会增大文件体积，我一般只在客户电脑不确定时才做。另外，如果是重要场合，导出PDF比pptx更安全。

5.3 翻车现象：Coze工作流频繁超时，卡在“渲染中”

现象：本地服务在浏览器里访问秒回，但Coze工作流经常跑一半卡住，最后提示超时。原因：最常见的是服务地址填了localhost或内网IP，Coze云端节点根本访问不到；其次是渲染服务执行耗时超过平台允许的限制。

解决：先把渲染服务部署到公网，用域名或公网IP。然后在Coze代码节点里加一个健康检查，而不是一上来就渲染。健康检查接口也就几行。

@app.get("/health") def health(): return {"status": "ok"}

在正式调用前，先请求https://你的服务器.com/health，如果通，再发渲染请求。这样能快速区分是网络问题还是渲染超时。还有一个经验：渲染大PPT时，每页文字量要控制，如果整个流程很容易超过30秒，就考虑把任务改成异步，先返回任务ID，再由Coze轮询结果。

注意：如果你的渲染服务部署在境内云服务器，访问路径中的HTTPS证书要先配置好，否则Coze调用时可能会因证书问题报错。

5.4 翻车现象：大模型返回了不合法的JSON，渲染直接报错

现象：流程里json.loads抛异常，工作流终止。原因：大模型输出里带了```json代码块，或者末尾多了一句“请查收”之类的解释。这不是偶发，长输出时概率很高。

解决：不要指望大模型保证纯净，写一个clean_json函数，把代码块标记和废话去掉。最小实现如下。

import json import re def clean_json(text: str): text = text.strip() text = re.sub(r"^```(json)?", "", text) text = re.sub(r"```$", "", text) start = text.find("{") end = text.rfind("}") if start == -1 or end == -1: raise ValueError("找不到JSON括号") return text[start:end + 1] ppt_json = json.loads(clean_json(raw_string))

我还建议在工作流里加一次重试：当JSON解析失败时，让大模型节点重跑一次，并把上一次的错误信息作为输入。Coze的节点重试机制能救回不少偶发失败。注意重试次数设2次就够，设太多会浪费token。

5.5 翻车现象：AI味太浓，领导一看就知道是机器写的

现象：每页都是首先其次最后，结尾来一句综上所述，通篇都是“赋能”“抓手”。原因：Prompt只约束了格式，没约束表达方式。大模型默认输出结构化套话，尤其是中文。

解决：在系统Prompt里明确禁止套话，并要求每页必须有具体结论。例如我常用的一句话是：每个小标题都要可独立阅读，不要用“概述”“详情”这种空词。再给一段表达约束。

表达要求： - 每句不超过25个字 - 禁止使用：首先、其次、最后、综上所述、赋能、抓手、闭环 - 每页必须有一个结论句，出现位置：标题或首个要点 - 能用数字就用数字，例如“耗时三个月”而不是“时间较长”

这招在这个场景下很管用。但要注意，这些约束要放在人设Prompt靠前的位置，靠后的内容容易被长指令覆盖。我每次重新整理Prompt，都把表达约束放在前五行。

6. 从“PPT能打开”到“PPT能打”：验证方法和三个进阶方向

跑通链路只是开始。真正让人愿意把PPT智能体用起来的，是每次生成的东西都能拿得出手。这一章讲我事后用得最多的三个方法，都是能直接抄的。

6.1 给智能体加一道“自检”：生成后先跑质量评分

PPT质量很难用客观标准衡量，但有一个办法很省力：让大模型在生成JSON时，同时输出一个quality_check评分。相当于让它自己审一遍自己的稿子。

{ "title": "YOLO算法讲解", "slides": [ { "title": "YOLO为什么快", "bullets": ["单阶段检测，省略候选框阶段", "整图一次前向得到位置和类别"], "speaker_notes": "强调单阶段相对两阶段的实时性优势" } ], "quality_check": { "score_structure": 9, "score_content": 7, "score_visualizable": 8, "suggestions": ["第3页缺一张对比图", "第7页标题可再短一点"] } }

然后在代码节点读这个字段，低于8分就触发一次重新生成。这个分支在Coze里用条件分支节点就能实现。我不建议用这个评分去做绝对判断，它更适合筛掉明显的烂稿。筛完之后你只需要人工看剩下的一部分，效率会高很多。

6.2 让知识库长成你的“个人素材库”

智能体做久了就会积累一批不错的PPT。我每次做完一份好PPT，会把大纲、金句、数据说明存进Coze知识库。下一份同类PPT出来时，智能体就能复用素材，而不是从头编。关键动作是：把知识库按主题拆成多个文件，命名带日期和类型，例如20250115_yolo_ppt大纲.md。Coze的检索默认按相关度排序，清晰的命名能帮助你更快找到需要的片段。

如果你想更近一步，可以把每份PPT最后人工改过的版本作为标准答案存进知识库。这样智能体输出的风格会一步步向你的真实审美靠拢，而不是停留在平台通用的AI味上。

6.3 一个关于迭代节奏的习惯

最后想分享一个习惯：不要把你的PPT智能体当成一次性交付。我每次用完它，会把需要人工修改的地方记下来，然后翻译成一条新的Prompt规则。例如“表格数据超过5行时拆成两页”“并列的3个要点优先用表格而不是列表”“引用数据要标注来源”。每过一两周，这条智能体的脾气就会越来越接近你，最终它生成的PPT，通常只需要换换措辞和数据就能直接用。

这也是我判断一个技术方向值不值得投入的标准：它能不能持续积累。Coze这套方案帮我做到了一点，把原来两三个小时的工作压到十几分钟，剩下的时间花在真正需要人判断的地方。如果你也在研究Coze和PPT智能体，希望这些思路和踩坑记录帮到你。

本文还有配套的精品资源，点击获取