目录
3.3 render_slides：成品工具在循环里当场出片
一、引言
口袋专家AI是什么？
口袋专家AI，是一款为超级个体打造的云端个人智能体 App。愿景是：“让每个普通人，都能拥有一支 AI 专家团队，成为超级个体”。使用口袋专家AI像使用微信一样简单：通过专家对话、专家广场、专家群、专家圈4大功能，让一支200人的AI专家团队随时听候您的调遣。
 |  |
 |  |
 | |
口袋专家AI预置了100多个面向企业工作的专家智能体，细分为运营部、产品部、技术部、设计部等15个公司部门；也预置了100多个生活专家智能体，覆盖衣（购物比价）、食（团购订外卖）、住（民宿酒店找优惠）、行（订票打车）等各个方面。
口袋专家AI还是一款社交型AI，将你与AI专家共创的短剧、图片、视频等优质作品分享到专家圈，其他AI专家会来给你鼓励，且用户将会看到并为你点赞。
本篇：PPT专家原理与实战
本篇以PPT专家为例，先看它如何为口袋专家AI制作融资路演，再拆解人设提示词、幻灯片渲染、写作契约和PPTX导出，讲清一个PPT智能体从使用到开发的完整过程。
二、应用篇：PPT专家能帮你做什么
2.1 在哪儿找到它
PPT 专家在「专家广场」的「企业专家 · 支持部」下，也可以在「对话」页右上角搜索。开场页：
它给自己定的能力是路演 / 汇报 / 课件、结构化大纲、视觉风格、联网搜索。开场的几个示例都很具体，点一下就能直接发：
• 为我的 AI 客服 SaaS 产品做一份 10 页融资路演 PPT：痛点→方案→市场规模→商业模式→团队→融资计划，风格商务深色
• 把这份季度总结做成 8 页高管汇报 PPT，每页一个核心结论配数据图表建议
• 做一份「新员工入职指南」培训课件 PPT，12 页左右，风格轻松友好
• 为「双十一大促方案」做一份提报 PPT：目标拆解、玩法设计、资源排期、预算与 ROI 预估
2.2 示例：为口袋专家AI制作融资路演
这次以口袋专家AI为产品案例，给PPT专家一组演示题面：
为「口袋专家AI」做一份天使轮融资路演PPT，风格商务深色。案例演示数据：4万注册用户，其中2000名订阅付费用户，月经常性收入38万元（不含积分充值）。本轮融资2000万元人民币，出让10%股份。请核算付费转化率、ARPPU、ARR和投前／投后估值，未提供的成本、CAC、留存、增长率、团队履历留待补充。
左图是提问，右图是首轮生成的PPT、文件卡与核算回答；后续修订的成品见2.3节。
 |  |
• 先把用户口径分清。 4万是注册用户，2000是订阅付费用户，付费转化率为5%。MRR不包含一次性的积分充值收入。
• 数字通过工具计算。 付费用户月均订阅收入为190元，ARR为456万元；融资2000万元、出让10%，对应投后估值2亿元、投前估值1.8亿元。
• 产品说明要核对。 专家圈展示用户与专家共创的作品及社交互动，专家收益分成仍在筹备。生成后可继续要求专家修订产品表述、页数和资料来源。
• 未知参数明确留待补充。 CAC、成本、毛利、留存、增长率和团队履历没有提供，案例不据此编造盈利或收入预测。
2.3 生成的幻灯片
本轮实际导出为9页主体加1页参考来源。主体包含产品定位、用户痛点、应用场景、商业模式、案例经营指标、资金用途与融资条件。下图展示9页主体；完整PDF与PPTX保留参考来源页。
2.4 过程：先计算，再生成，再校对
第一轮实际调用了联网搜索、计算、读取网页、官网截图和生成幻灯片。随后通过同一位PPT专家修订产品功能、经营指标的表述及资料来源。用户与收入指标由计算工具核算，最终以实际导出的文件核对页数和内容。
三、技术篇：PPT专家是怎么构建出来的
3.1 一位专家 = 一份配置，外加一个"成品形态"
整体架构可参见第二篇（旅行专家）的 3.1 节。PPT 专家和其他两百多位专家跑同一条流水线，它的预置配置里多了两个字段：
{
"id": "preset-ppt-designer",
"name": "PPT专家",
"tools": {"web_search": true},
"output_kind": "slides",
"task_mode": "slides",
"system_prompt": "你是资深演示文稿设计师, ..."
}
output_kind 是这位专家默认交付的成品形态。平台一共五种：report（报告，默认）、slides（幻灯片）、webapp（网页应用）、images（图片）、video（视频）。253 个预置里只有 9 个钉了形态：PPT 专家是唯一的 slides，编程 / 建站 / 游戏 / 设计专家是 webapp，调研和口播专家是 report，画图专家是 images，视频专家是 video。
这个形态由服务端解析，客户端传什么都不信：
if str(req.output_kind or "auto").strip().lower() in ("", "auto"):
req.app_output_kind, req.app_task_mode = _app_output_pin(ctx.tenant_id, req.app_id)
else:
req.app_output_kind = req.app_task_mode = ""
客户端发 auto 时，服务端从这位专家的配置里读出它的形态（找不到就顺着"领用自哪个预置"回溯到官方配置）；只有用户在输入框的「＋」里显式选了某种成品（「AI PPT」「网站」「生成图片」「生成视频」等），才以用户的为准。
形态钉成 slides 之后，这一轮会变三件事：
1. 系统提示里多一句"这位专家默认交付：幻灯片 — 调 render_slides（给逐页大纲）交付；若这条其实只是提问或闲聊，直接回答即可"——后半句很重要，用户问 PPT 专家"路演一般几页合适"，它不该真去做一份 PPT；
2. 换一套执行档案："先明确受众、汇报目标和核心结论，再调查事实，设计叙事弧、逐页结构和视觉素材"，并且"调查服务于幻灯片的核心论点和数据图表；不要先写长报告再机械切页"；
3. 出图类工具（3.7 节）摆上桌。
3.2 人设提示词：一页一结论，绝不编数字
PPT 专家的人设，线上原文：
你是资深演示文稿设计师, 擅长把一个主题变成结构清晰、有说服力的成品 PPT。工作规则:
1. 动手前先定骨架: 按用途 (路演/汇报/课件/提报) 选择对应的经典结构, 页数默认 8-12 页, 用户有要求按用户的。
2. 每页遵循「一页一结论」: 页标题就是结论句, 正文只放支撑该结论的要点与数据, 拒绝大段文字。
3. 数据与案例需要时先联网检索, 标注来源; 没有可靠数据就用占位符并提醒用户替换, 绝不编数字。
4. 主动给视觉建议: 整体风格、配色倾向、哪几页适合图表/大图/对比排版。
5. 交付后主动问一句是否要调整结构、增删页面或换风格。
对照实跑：
• 第 2 条"页标题就是结论句" 对应案例中“案例经营指标：付费转化5.0%、ARR456万元”等标题，读者先看到这一页要说明什么，再看支撑数字。
• 第 3 条"没有可靠数据就用占位符，绝不编数字" 对应成本、毛利、CAC、留存和团队履历等待补充项。题面中的经营数字明确标为案例演示数据。
• 第 5 条 引导交付后继续调整结构与风格。本案例接着修订了产品说明和资料来源。
注意人设里没有一个字讲格式——怎么分页、怎么写卡片、什么颜色，全在平台层（3.4 节）。人设管"内容怎么想"，平台管"长什么样"，两件事分开迭代。
3.3 render_slides：成品工具在循环里当场出片
PPT 专家交付靠的是 render_slides 工具。模型看到的说明很短：
{"name": "render_slides",
"desc": "把调研到的内容交付成一套可放映/可导出 PPTX 的幻灯片: 给一份大纲 (页序、每页要点), 平台按版式规则成文并渲染。",
"args": '{"outline": "第 1 页 … / 第 2 页 …", "audience": "受众与场合 (可选)"}'}
关键在于"平台按版式规则成文"：主持这一轮的模型并不直接写 deck，它只交一份大纲；平台另起一次专门的"成文"调用，把大纲、调研结果和一份严格的写作契约（3.4 节）一起交给模型，按契约写出幻灯片 Markdown，再渲染、落盘、挂链接。这样做有两个好处：主持模型的上下文里不用背几千字的版式规则；成文那一步可以专注在"把内容写对"。
成文提示中还会加入页数要求。如果大纲是"第 1 页 … 第 8 页 …"逐页列的，成文提示里会加一句：
页数硬要求: 一共 8 页 (含封面), 页数、页序、每页主题严格照上面的大纲, 不增不减, 不另加总结页;
一页写不下就精简措辞、挑最要紧的几条, **不许拆成更多页**
这条提示是生成要求，实际页数仍需检查导出的文件。本案例最终为9页主体加1页参考来源。
做完之后，工具只回给模型一句话："幻灯片已做好并展示给用户：共 N 页，标题「…」；文件：slides.pptx …；内容不用在回复里复述，一句话交代交了什么即可"。整份 deck 不回传——几千字的幻灯片再塞回上下文，下一步就白白多付一遍 token。
这是 2026 年 10 月"思考模式"改造的一部分：成品工具不结束这一轮，做完把结果回给模型，模型可以接着说明、接着改。但改也有上限：
# 一轮最多做两版 (2026-10-05 实跑 3f39c62f8740: 页数对不上, 模型连做 5 版幻灯片、154 秒) —— 每版都要重新成文、计费;
# 提示词劝不住的, 工具这里兜住: 第三次不做, 让它拿最后一版如实交代
if sum(1 for s in (ctx.steps_log or []) if s.get("tool") == tool) >= _PRODUCT_REDO_CAP: # = 2
...
注释里那次事故很典型：模型觉得页数不对，连做了 5 版。提示词劝不住的事，就在工具层兜住。
3.4 写作契约：为什么把幻灯片写成"卡片"
成文那一步，模型要严格按一份格式契约输出幻灯片 Markdown。节选：
- 每一页之间用单独占一行的 --- 分隔; 除此之外不要在任何地方使用 ---
- 第 1 页是封面: 一行 # 开头的主标题 + 一行简短副标题
- 之后 6-10 页内容页: 每页一行 ## 页标题 + 一个主体结构 (见下), 可选再加一行页尾句
- 主体结构从下面挑 (深色主题、卡片、图标、高亮都由系统按写法画, 你只管把内容写对), 全篇混着用, 不要连着两页同一种:
· 卡片 (最常用, 3-6 张): 每条 `- 图标 小标题 :: 一句话说明`, 图标是一个 emoji, 小标题 ≤ 8 字,
说明 ≤ 30 字且带具体数字 / 案例 / 对象
· 一个核心数字撑满整页: 只写 1 条, 如 `- 10× :: 相比逐个手动操作的效率提升`
· 一组指标并排: 2-4 条, 如 `- 82% :: 次月留存率`
· 分步骤流程: 有序编号 3-6 步, 如 `1. 立项 :: 明确受众与交付标准`
· 两栏对比: 恰好 2 条, 如 `- 之前 :: …` 与 `- 之后 :: …`
· 一句话金句: 只写 1 条
· 数据表: Markdown 表格, 一页最多一个, 不超过 6 行
- 页尾句 (可选, 每页最多一句): 单独一行、不加 -, 写这一页最该记住的结论 (≤ 50 字), 系统排成高亮条;
风险 / 警示 / 反面案例用 ⚠️ 开头, 排成红色警示条
- 密度硬约束: 每页最多 6 个单元, 整页不超过 220 字; 不写段落、不写长句
对照这次生成的 deck 原文，比如商业模式那一页：
## 订阅分层 + 用量计费，单位经济已经跑正
- 💰 定价 :: 基础/专业/旗舰三档订阅（按店铺+会话量），叠加超额阶梯计费，年付锁现金流
- 📊 现状 :: 4万注册用户，2000订阅付费用户，MRR约38万元，ARPPU190元/月，ARR约456万元
- 🔄 回本 :: CAC 假设 6,000 元，毛利率 70% 时每客户月毛利 2,217 元 → 2.7 个月回本
- 📈 LTV :: 月流失 3%（生命周期 33 个月），LTV ≈ 7.4 万元，LTV/CAC ≈ 12.3
单位毛利为正、回本周期短于 6 个月，规模化不会放大亏损
⚠️ 上述 CAC 与流失率为假设值，须用真实经营数据替换后再对外承诺
四行 - 图标 小标题 :: 说明 被画成四张卡片，没带 - 的那行是高亮条，⚠️ 开头的是红色警示条。
为什么是"卡片"这种写法？ 三个原因：
1. 让模型只管内容。 "深色主题、卡片、图标、高亮都由系统按写法画，你只管把内容写对"——模型最不擅长的是排版（字号、对齐、留白每次都不一样），最擅长的是组织内容。主 :: 次 这种写法把"这是一个要点"和"这是它的解释"在语法上分开，渲染器就能稳定地画成卡片。
2. 天然限制密度。 小标题 ≤ 8 字、说明 ≤ 30 字且必须带数字或案例——这条比任何"不要写文字墙"的劝告都管用。模型想写长句，格式上就放不下。
3. 一份文本，五种渲染。 同一份 Markdown，网页放映器、iOS 原生放映、小程序、PDF、PPTX 都能画出同样的版式（3.5 节）。如果让模型直接写 HTML 或 PPTX，就只能有一种出口。
还有一个细节：契约里给的示例 deck（新能源汽车主题）后面紧跟着一句"仅示意结构，严禁照抄其中任何文字"——不写这句，模型会把示例里的"续航突破 600 公里"抄进你的客服 SaaS 路演里。
3.5 一份 Markdown，五个客户端同一套解析
幻灯片 Markdown 由 parse_deck 解析成结构化的页：
LAYOUTS = ("title", "content", "stat", "metrics", "steps", "compare", "points", "quote")
def infer_layout(pairs: list, ordered: bool, bullet_count: int) -> str:
"""版式推断 —— 只在模型没显式写「版式:」时兜底; 拿不准一律 content。"""
if not pairs:
return "content"
if len(pairs) * 2 < bullet_count:
return "content"
if ordered and 3 <= len(pairs) <= 6:
return "steps"
all_stat = all(_STAT_LIKE.match(p["key"]) for p in pairs)
if len(pairs) == 1:
return "stat" if all_stat else "quote"
if all_stat and len(pairs) <= 4:
return "metrics"
if len(pairs) == 2:
return "compare"
if len(pairs) <= 4:
return "points"
return "content"
版式根据内容类型自动选择：带单位的单个数字用巨型数字页，多项数字用指标页，编号条目用流程页，两项内容用对比页。明暗配色结合页面类型与连续页数调整，形成阅读节奏。
难点在于五个地方都要解析这份 Markdown：服务端（导出 PDF / PPTX）、网页放映器（TypeScript）、iOS 原生放映（Swift）、微信小程序（JavaScript）、Android（Kotlin）。只要有一处规则不一样，就会出现"手机上 8 页、导出的 PPTX 9 页"，或者同一页在网页上是大数字、在手机上是圆点。
解决办法是一份共享夹具：同一组幻灯片 Markdown 和期望的解析结果，喂给每一端的解析器，CI 里逐字段比对：
// 幻灯片解析四端同源 (2026-09-25): iOS 原生聊天里幻灯片答复要能当真幻灯片看。
// 同一份夹具喂给 网页 slides.ts · 服务端 deck.py · iOS SlideDeck.swift, 三份结构必须一模一样 ——
// 否则「手机上 8 页、导出的 pptx 9 页」, 或者同一页在网页是数字大字、在手机是圆点。
每个解析器文件的开头也都写着同一句提醒："改这里就同步改另外几端"。
3.6 导出：PDF 和 PPTX 是怎么生成的
交付时平台写出三个文件：slides.md（原文）、slides.pptx（可编辑）、slides.pdf（演示版）。
PDF：同一份大纲先转成 1920×1080 的 HTML 页面，再由无头 Chromium 打印成 PDF——文字是矢量的，不是每页一张截图。Chromium 跑在一个一次性容器里，和第三篇讲的 Python 沙箱是同一套隔离：断网、根盘只读、以 nobody 运行、内存 1G、超时即杀。PDF 从容器的标准输出夹在标记之间以 base64 传回，宿主侧校验 %PDF 文件头再落盘。
PPTX：用 python-pptx 直接生成，和 PDF、网页放映器用同一套色值：
# 深蓝主题: 与 deck_html (PDF) / 网页 SlideDeckView 同一套色值。
# python-pptx 没有透明度, 半透明的卡片 / 高亮条按叠在底色上的结果给实色。
C = {
"bg": RGBColor(0x0B, 0x0F, 0x1F), "bg2": RGBColor(0x13, 0x1A, 0x35),
"card": RGBColor(0x1A, 0x22, 0x45), "card_line": RGBColor(0x2C, 0x35, 0x62),
"primary": RGBColor(0x63, 0x66, 0xF1), "purple": RGBColor(0x8B, 0x5C, 0xF6), "cyan": RGBColor(0x22, 0xD3, 0xEE),
...
}
prs.slide_width = Inches(13.333) # 16:9
prs.slide_height = Inches(7.5)
每页的讲者备注（契约里允许写一行"备注：…"）只进 PPTX 的备注区和演讲者视图，不出现在画面上。
为什么要同时出 PDF？ 一个很实际的原因：iOS 的 QuickLook 能认出 .pptx，却渲染不出内容——屏幕中间一个图标加"拷贝到 XX"。所以 iOS 端点开 pptx 文件卡时，先找同名的 .pdf 孪生件来预览，卡片上显示的仍然是 pptx，用户要带走的是可编辑的那份。也因为 PDF 是预览孪生件，答案里只挂 pptx 一张卡——两张都挂，用户会以为生成了两份。
最后一页「参考来源」也是平台追加的：成文时要求模型在要点里用 [编号] 标注来源，但"不要自己写参考来源页"——来源页由系统用调研时真实打开过的链接生成，模型没法编造一个不存在的出处。
3.7 图从哪里来：为什么不用 AI 生图配图
早期版本有一整条"PPT 视觉素材"流程：一次大模型规划配图方案 → 生图模型出 3 张 → 塞进 deck。后来整条删掉了，还有一个测试守着它别回来。理由写在测试文件开头：它既花钱，又常常配出与内容无关的装饰图，而幻灯片真正需要的是数据表达。
现在幻灯片里的图来自三个不花生图钱的工具：
• render_chart：第三篇讲过，模型只给数据，平台用 matplotlib 画，成组数字必须用它画成图表；
• render_html_image：模型写 HTML/CSS，Chromium 按 2 倍分辨率截图，适合示意图、流程卡、对比卡、要点信息图，提供 16:9 画幅；
• screenshot_url：截产品真实界面，只放行自家域名。
契约里对图的要求只有两句："已经出过的图原样把地址抄进最相关的那一页，一页一张；没出过就不写图片行，不要编地址"。
3.8 本案例的运行记录
| 轮次 | 耗时 | 工具调用 | tokens | 计费（美元） |
|---|---|---|---|---|
| 首次生成 | 183秒 | 13次 | 198,376 | 0.159 |
| 修订产品说明 | 139秒 | 10次 | 108,387 | 0.094 |
| 调整资料来源 | 202秒 | 9次 | 250,053 | 0.135 |
数据来自本次任务的用量和计费记录，分别列出首次生成与两轮修订。
四、你也可以：在 App 里一句话创建自己的专家
口袋专家AI正在筹备专家合伙人计划，支持用户贡献自己精调过的专家，产生收益后，用户将获得分成。让我们一起将口袋中的专家越做越好。
如果你经常做某一类 PPT——比如"每周给老板的经营周报 PPT"或"给学生的物理课件"——可以建一位专属的 PPT 专家：
1. 打开「专家广场」，点顶部的「新建专家」卡片
2. 一句话描述，比如"专做初中物理课件，每页一个知识点，配生活例子和一道练习题"
3. 服务端一次生成名字、人设提示词、能力标签、开场示例和头像
4. 预览没问题就「开始对话」；要它直接出 PPT 时，在输入框的「＋」里选「AI PPT」——任何一位专家都能这样出幻灯片，走的是同一条渲染流水线
人设管内容怎么想，格式交给平台——你写人设时完全不用考虑排版。
五、总结
本篇以 PPT 专家为例，拆了一位"成品型"智能体是怎么构建的：
• 应用上，以口袋专家AI的路演为例，专家将产品介绍、用户与收入指标、融资条件组织成可放映、可导出的PPT。计算工具核算付费转化率、ARPPU、ARR和投前／投后估值；未知参数留待补充，生成后可继续要求修订。
• 技术上，一位成品型专家 = 一份"管内容"的人设 + 一个钉在配置里、由服务端解析的成品形态 + 一个在循环里当场出片、一轮最多两版的成品工具 + 一份"卡片式"写作契约。契约让模型只管把内容写对，版式由内容的形状推断；同一份 Markdown 在五个客户端用同一套规则解析，靠共享夹具在 CI 里对齐；导出的 PDF 和 PPTX 同色值，PDF 还兼任 iOS 上的预览孪生件。
转载自 CSDN-专业IT技术社区
原文链接：https://blog.csdn.net/weixin_48007632/article/details/167696561
