PPT Agent 工作流：从需求调研到 SVG 设计稿
案例定位
这篇
linux.do帖子真正有价值的地方，不是“AI 一键生成 PPT”，而是把做 PPT 这件事拆成了一条更像专家团队协作的流程：需求调研 → 资料搜集 → 大纲策划 → 策划稿 → 设计稿。它更接近一个PPT Agent workflow，而不是普通模板工具。
这条思路为什么值得记
原帖发布于 2026-03-19，作者 sandun 展示的是一种明显不同于常见 AI PPT 工具的路线：
- 不是上来先套模板
- 不是直接吐一个粗糙大纲
- 不是把“美观”放在“表达目标”前面
它强调的是：
PPT 的灵魂先是内容和表达目的，其次才是样式和皮相。
这和 大模型/08-个体重构/02-工作流重构/AI时代个人工作流重构框架 里“先把任务拆清楚，再谈自动化”的思路是完全一致的。
工作流拆解
1. 先做需求调研，不急着生成
这套方法最重要的起点，是让 AI 先像顾问一样把需求问清楚：
- 这份 PPT 是给谁看的
- 场景是什么
- 想达成什么目的
- 需要突出哪些信息
也就是说，AI 不是先“做图”，而是先“提问”。
2. 基于资料检索生成更有针对性的大纲
原帖提到，系统会先做一轮外部资料搜索，再结合用户回答生成大纲。这样的大纲不是凭空瞎写，而是带有主题背景和事实支撑。
这一步本质上就是把 搜索/调研 接到了 PPT 结构规划 前面。
3. 用“数字便利贴”组织每一页
作者把自己长期做复杂 PPT 的“便利贴法”做进了产品：每一页先作为一张独立卡片存在，便于：
- 看全局结构
- 调整顺序
- 删除冗余页面
- 补齐逻辑断点
这和把复杂任务拆成多个可编辑中间状态是同一种思想，也能和 大模型/08-个体重构/05-案例观察/智能工作台中的多Agent工作流实践 对照来看。
4. 先出策划稿，再出设计稿
这里的关键不是“一步到位”，而是分层产出：
- 大纲解决“讲什么”
- 策划稿解决“这一页怎么组织信息”
- 设计稿再解决“最终视觉怎么呈现”
这样比直接从主题跳到最终页面更可控，也更方便人工校正。
5. 最终生成整页 SVG，而不是只靠模板或 HTML
根据原帖后续讨论，作者选择的是 整页 SVG 方案，而不是单纯模板拼装或直接 HTML。
这么做的好处是：
- 可导入较新的 PowerPoint / Office 环境继续编辑
- 矢量清晰，放大不糊
- 对设计元素的位置、层级和样式更容易精确控制
代价也很明显：
- 工程实现更复杂
- 提示词和布局约束更难调
- 从策划稿到设计稿的一致性需要持续打磨
设计层的几个关键判断
1. 卡片式 / Bento Grid 是核心版式语言
帖子讨论里多次提到：面对信息密度较高的页面，卡片式布局 是当前最稳妥的一类解法。
它的价值在于：
- 用卡片大小建立信息层级
- 让复杂内容更容易分组
- 保留足够留白，减少拥挤感
从搜索结果能看到，作者在 SVG 提示词里明确约束了 1280x720 画布、卡片间距和 Bento Grid 结构，这说明它不是随便出图，而是在做可控布局生成。
2. 内容驱动布局，而不是布局反过来绑架内容
这条很重要。原帖思路不是“先选一个好看的模板，再把内容硬塞进去”，而是让布局跟着信息结构走。
这和传统 PPT 制作里“先定表达，再定视觉”的专业做法是一致的。
3. 中间态必须可见、可改、可回退
“数字便利贴”本质上是在给用户保留中间编辑层。
这意味着一个好的 PPT Agent 不应该只是黑盒吐结果，而应该让用户能在：
- 需求层
- 大纲层
- 策划层
- 设计层
分别介入。
从个体工作流角度看，这个案例说明了什么
这篇帖子其实说明了一件很重要的事：
复杂内容生产任务，最值得被 AI 接管的不是最后那一下“排版”，而是前面那一长串调研、提问、拆解、组织与结构化工作。
换句话说，PPT 只是表面场景，底层模式其实是：
- 明确目标
- 补足上下文
- 产出结构
- 组织页面
- 生成视觉
- 人工复核
这是一条非常典型的 Agent + Workflow 路径，也能和 大模型/08-个体重构/02-工作流重构/MCP、RAG 与 Agent 在个体重构中的位置 放在一起理解。
局限与风险
从原帖讨论和后续反馈看，这条路线仍然有几个明显挑战：
- 巨量纯文字页面未必适合卡片式布局
- 模板复用、企业规范和品牌样式约束仍然难
- 策划稿和设计稿之间可能出现风格偏差
- 搜索语料质量会直接污染内容判断
- 最终结果依然需要人工审稿和事实校验
所以它更像“高质量初稿生成器 + 结构规划助手”，而不是完全替代人的终局方案。
我对这篇内容的归纳
如果只保留一句话，我会这样记：
真正强的 PPT Agent，不是帮你更快套模板，而是先像研究员、策划师、信息架构师和设计师那样，把一套内容生产链条跑顺。