AI PPT生成系统实践：从自由生成到可控生成的工程演进复盘

项目定位 ：面向毕业答辩、课题汇报和个人成果展示场景，尝试做一个低成本、可在线编辑、生成过程可控的 AI PPT 工具。

文章重点：不展开源码细节，主要记录项目为什么做、测试过哪些方案、为什么放弃、真正的难点在哪里，以及最终如何一步步收敛到当前方案。

[AI PPT生成系统实践：从自由生成到可控生成的工程演进复盘](#AI PPT生成系统实践：从自由生成到可控生成的工程演进复盘)
- 一、项目背景与立项目标
- - [1. 项目希望解决的三个问题](#1. 项目希望解决的三个问题)
  - [2. 当前产品形态](#2. 当前产品形态)
- 二、项目全流程迭代链路
- - [2.1 前期产品与技术路线调研](#2.1 前期产品与技术路线调研)
  - - [路线一：Image / SVG 视觉生成](#路线一：Image / SVG 视觉生成)
    - [路线二：PPT Master / Agent 工作流](#路线二：PPT Master / Agent 工作流)
  - [2.2 过渡方案：自研编辑器 + SVG 混合渲染](#2.2 过渡方案：自研编辑器 + SVG 混合渲染)
  - [2.3 自研在线渲染：第一次真正暴露前端问题](#2.3 自研在线渲染：第一次真正暴露前端问题)
  - [2.4 从 PPT Master Skill 思路中抽取三阶段生成流程](#2.4 从 PPT Master Skill 思路中抽取三阶段生成流程)
  - [2.5 从"模板越多越稳定"到规则驱动布局](#2.5 从“模板越多越稳定”到规则驱动布局)
  - [2.6 从"溢出就失败"到分级质量治理](#2.6 从“溢出就失败”到分级质量治理)
  - [2.7 从单页可控到整套 PPT 可控](#2.7 从单页可控到整套 PPT 可控)
- 三、当前产品效果与验证结果
- - [3.1. 成本](#3.1. 成本)
  - [3.2. 速度](#3.2. 速度)
  - [3.3. 编辑能力](#3.3. 编辑能力)
  - [3.4. Demo 完整流程验证](#3.4. Demo 完整流程验证)
- 四、项目中的核心难点与方案沉淀
- - [4.1. 视觉自由度与可编辑性的平衡](#4.1. 视觉自由度与可编辑性的平衡)
  - [4.2. AI 内容与前端布局之间的容量问题](#4.2. AI 内容与前端布局之间的容量问题)
  - [4.3. Agent 思路与 Web API 场景的适配问题](#4.3. Agent 思路与 Web API 场景的适配问题)
  - [4.4. "严格校验"不等于"好的用户体验"](#4.4. “严格校验”不等于“好的用户体验”)
  - [4.5. AI 辅助开发工程化：从"让 AI 直接改"到"先理解、再定位、再小范围修改"](#4.5. AI 辅助开发工程化：从“让 AI 直接改”到“先理解、再定位、再小范围修改”)
  - - [5.1 遇到 Bug 时，先让 AI 说清楚系统逻辑](#5.1 遇到 Bug 时，先让 AI 说清楚系统逻辑)
    - [5.2 通过流程图、数据流和日志，把问题逐层缩小](#5.2 通过流程图、数据流和日志，把问题逐层缩小)
    - [5.3 AI 分析正确但修改失败时，继续缩小修改范围](#5.3 AI 分析正确但修改失败时，继续缩小修改范围)
    - [5.4 从这套开发方式中沉淀出的原则](#5.4 从这套开发方式中沉淀出的原则)
- 五、当前边界
- 六、项目总结与后续方向

一、项目背景与立项目标

最初做这个项目的原因其实很简单：我在实际使用通用 Chatbot 和专业 AI PPT 工具时，发现两类方案都不能完全满足自己的需求。

通用大模型的优势是灵活、便宜，内容总结和文案生成也已经比较成熟，但真正拿来做 PPT 时，最终页面往往需要大量人工调整。尤其是当生成结果以图片或一次性文件形式存在时，后续修改和重新生成某一页并不顺畅，整个"生成---修改---继续生成"的过程是割裂的。

专业 AI PPT 平台的页面效果通常更成熟，但也有另外的问题：高质量能力往往需要付费，模型和生成流程由平台封装，用户很难自由选择模型、调整底层生成逻辑或根据自己的需求重新组织页面；图片生成和正文内容也不一定总能准确匹配。

所以这个项目一开始是想：

能不能做一个成本更低、生成结果可继续编辑、同时又能把关键环节控制住的 AI PPT 工具？

我希望最终用户能够完成这样一条链路：

text 复制代码

输入主题 / 大纲
        ↓
AI 辅助生成内容
        ↓
系统生成 PPT 页面
        ↓
在线编辑与调整
        ↓
得到最终演示文稿

1. 项目希望解决的三个问题

第一，降低内容生产成本。

大模型已经擅长内容总结、信息组织和文案生成，因此希望让 AI 负责完成主题理解、内容结构规划和页面文案生成，减少用户从零整理 PPT 的时间。

第二，提高生成结果的可用性。

PPT 并不是把文字放到页面上就结束了。一个可用页面还需要考虑内容层级、页面结构、视觉一致性和页面容量。项目需要解决的并不是"让模型多写一点内容"，而是如何让生成结果真正进入一个稳定的页面系统。

第三，支持生成后的持续编辑。

相比"生成完就导出"的方式，我更希望用户可以直接在网页中继续修改文字、调整页面元素、替换图片或重新优化某一页。项目的目标不是一次生成完全无需修改，而是让 AI 先完成高成本的初稿工作，再把最终控制权交还给用户。

2. 当前产品形态

经过多轮迭代，目前已经形成一条可以实际演示的生成链路：

复制代码

用户输入内容
      ↓
AI 生成结构化页面内容
      ↓
系统完成页面编排与渲染
      ↓
进入在线编辑器
      ↓
用户继续修改文字、组件和图表

当前重点不是追求"商业产品级视觉效果"，而是先把 生成、布局、编辑、质量控制 这条核心链路跑通，并保证每一层都有明确的责任边界。

二、项目全流程迭代链路

这个项目并不是一开始就确定了最终架构，而是在不断试错中逐步收敛。

整体经历可以概括为：

复制代码

体验现有产品
    ↓
比较不同技术路线
    ↓
验证视觉生成方案
    ↓
尝试 Agent 工作流
    ↓
自研编辑器 + SVG 混合方案
    ↓
自研统一在线渲染
    ↓
发现前端布局与容量问题
    ↓
重构 Prompt 与渲染规则
    ↓
增加质量治理
    ↓
继续向 Deck 级编排演进

2.1 前期产品与技术路线调研

项目初期，我调研和测试了 Gamma、Beautiful.ai、AiPPT，以及 Codex Image、PPT Master 等不同路线。

最开始我关注的是"怎样才能生成得更好看"，因此优先测试了视觉自由度比较高的方案。

路线一：Image / SVG 视觉生成

最早尝试过通过 AI 生成视觉结果，再转换为 SVG 页面。

这类方案的优势很明显：

页面自由度高；
不需要提前设计大量模板；
单页视觉效果可以比较丰富。

但测试后发现两个问题。

首先，Image 转 SVG 的过程中会产生一定视觉损失。其次，即使直接得到 SVG，它更适合作为"已经设计好的页面描述"，而不是我的 H5 在线编辑器所需要的数据模型。

SVG 可以描述文本、矩形、路径、图片等绘制元素，但在线编辑系统真正需要的是带业务语义的页面组件，例如"这是标题""这是正文""这是卡片内容""这个元素允许用户继续编辑"。如果直接把 SVG 当成最终页面，就需要额外做解析、识别和转换，才能进入自己的编辑器。

因此这一阶段并没有让我立刻放弃 SVG，而是让我意识到一个新的问题：

视觉生成可以解决"看起来像 PPT"的问题，但如果在线编辑也是核心目标，就需要考虑怎样把 SVG 的视觉结果接入自己的编辑体系。

这也直接引出了后面的"自研编辑器 + SVG"混合方案尝试。

路线二：PPT Master / Agent 工作流

随后我重点研究了 PPT Master。

PPT Master 的思路给了我很大启发：它不是简单让模型一次把所有事情做完，而是把 PPT 制作拆成内容理解、结构规划、页面设计和最终检查等步骤，让不同阶段各自承担一部分责任。

这种方式生成质量更高，但我很快发现一个现实问题：

PPT Master 更适合运行在 Agent 环境中，而我的产品本质上是一个 Web 系统，通过后端直接调用大模型 API。

如果照搬 Agent 工作流，就意味着要在自己的系统里承担多轮模型调用、上下文维护、任务状态、失败恢复等复杂度。

当时我也尝试过高能力模型组合，但 Claude / Opus 等方案成本偏高；随后尝试使用更便宜的 DeepSeek V4，希望保留类似工作流，却忽略了前面的一个重要前提------PPT Master 的很多步骤原本依赖 Agent 帮助维护任务上下文和执行状态。

在自己的 API 调用环境中，长链路调用表现并不稳定。实际测试甚至出现过等待约 60 分钟仍未得到完整结果，只返回少量组件的情况。

这让我意识到：

不能简单把 Agent 的工作方式拆成多个 API 请求，就认为能够得到相同效果。

我真正需要的，是保留其中"分阶段思考"的优点，但把链路重新设计成适合自己 Web 系统的形式。

2.2 过渡方案：自研编辑器 + SVG 混合渲染

在验证 SVG 的视觉效果之后，我没有直接从 SVG 跳到完全自研渲染，而是先尝试过一个折中方案：

保留 SVG 页面较好的视觉表现，同时在自己的 H5 编辑器中把部分页面元素改造成可编辑组件。

当时的设想是，希望同时保留两种方案的优点：

SVG 继续负责背景、图片和复杂视觉表现；
自研编辑器负责文字和基础组件编辑；
用户既能保留生成页面的视觉效果，也能对关键内容进行修改。

实际改造后，这个方案只完成了非常有限的编辑能力。

当时最终能够较完整进入自研数据结构的主要是标题页中的文字元素。标题文字可以在网页中继续修改，但原 SVG 中的图片、背景和其他复杂视觉元素并没有同步结构化。

结果导致同一套 PPT 中出现了明显的两套页面体系：

复制代码

标题页
→ 部分元素进入自研编辑器
→ 可以修改文字
→ 但图片和背景缺失

其他内容页
→ 继续使用完整 SVG
→ 视觉效果保留
→ 但无法获得同等的组件级编辑能力

从单页来看，标题页确实"变得可编辑了"；但放回整套 PPT 后，问题反而更加明显：

标题页由于缺少原有图片和背景，视觉效果明显变简单；
其他 SVG 页面仍保留完整视觉设计，两者风格非常割裂；
同一套 PPT 同时存在结构化组件和 SVG 两套数据模型；
后续每增加一种可编辑页面，都要继续解决 SVG 到编辑器组件的映射问题；
产品体验和工程维护复杂度都会持续上升。

因此，这个阶段让我认识到：

局部把 SVG 改造成可编辑组件，并不能真正解决问题。只要一部分页面依赖 SVG、一部分页面依赖自研组件，整套 PPT 的视觉体验和编辑体验就很难统一。

这也是我最终放弃"自研编辑器 + SVG 混合方案"，转向统一结构化页面模型的重要原因。

2.3 自研在线渲染：第一次真正暴露前端问题

在确认"自研编辑器 + SVG"混合方案无法同时保证视觉一致性和统一编辑体验后，我决定不再继续逐页改造 SVG，而是统一页面数据模型：让大模型输出结构化内容，再由自己的前端系统完成渲染。

这个方向理论上很合理：

复制代码

LLM 输出内容
      ↓
结构化 JSON
      ↓
前端组件
      ↓
可编辑页面

好处是页面不再是一张图片，而是可以继续修改的文本、卡片、图表等组件。

但第一版效果很差。

页面虽然"能生成"，视觉效果却很生硬：组件比例不好、页面节奏差、内容密度不合理。

这也说明，仅仅把页面数据结构化并不意味着页面自然会变好看。为了继续提升生成质量，我开始把 PPT Master 中"分阶段规划和校验"的思路融入自己的结构化渲染流程。

这时出现了一次很尴尬的测试：

模型长时间思考；
最后只生成少量组件；
页面效果依然很差；
文本会超出卡片；
文本框和卡片区域无法正确匹配。

一开始我仍然怀疑是模型生成有问题，但继续排查后才意识到：

真正的瓶颈已经从"模型怎么生成"转移到了"前端怎么渲染"。

因为大模型本身并没有输出具体的 x/y 坐标。页面坐标、组件宽高、字号和间距都是前端系统计算的。

也就是说，文本溢出、卡片装不下等问题，并不能简单归因于"大模型乱生成布局"，而是因为：

AI 生成内容的长度，与前端组件实际能够承载的容量之间没有建立清晰的约束。

这是整个项目里非常重要的一次认知变化。

2.4 从 PPT Master Skill 思路中抽取三阶段生成流程

确认不能直接照搬 PPT Master + Agent 后，我没有完全放弃 PPT Master 的思路，而是保留了它"分阶段处理复杂任务"的方法。

我把原本复杂的 Agent 工作流简化成三次有序的大模型调用，并通过 Session 保存前一阶段的结果，让下一次调用可以继续使用上下文。

目前的三阶段大致为：

复制代码

第一次调用
内容规划与整套 PPT 故事线
        ↓
第二次调用
页面类型、布局意图与视觉风格
        ↓
第三次调用
整套内容与风格一致性检查
        ↓
输出结构化页面数据

这里的关键不是让模型输出具体坐标，而是让模型负责"这页应该讲什么、属于什么类型、需要怎样的信息结构"。

真正的坐标、宽高、字号和组件布局仍然交给系统。

这种方式相比完整 Agent 循环更容易控制：

调用次数固定；
每一步职责明确；
可以通过 Session 传递上下文；
后端更容易记录和定位失败阶段；
成本和等待时间更容易估算。

当前生成链路通常可以控制在分钟级完成。由于使用中转 API，外部模型服务本身存在明显波动，相同文案和相同模型曾出现约 18 秒到 180 秒的响应差异，因此我没有把单次最快耗时当作稳定性能指标。

2.5 从"模板越多越稳定"到规则驱动布局

生成链路逐渐稳定后，新的问题集中到了前端布局。

第一版为了保证页面稳定，我采用了很直接的方法：提前把不同内容数量对应的页面都设计出来。

例如：

复制代码

points_1
points_2
points_3
points_4

cards_1
cards_2
cards_3
cards_4

然后让 AI 选择页面类型，前端根据内容数量匹配对应模板。

这个方案短期有效，因为每一种情况都有明确的布局答案。

但很快出现两个问题。

第一，模板数量会不断膨胀。

如果卡片页、要点页、流程页、对比页都按照 1、2、3、4、5 个内容分别设计，模板数量会越来越多，维护成本迅速增加。

第二，固定模板并不能解决内容密度变化。

同样是 3 张卡片：

每张卡片只有 20 个字时很宽松；
每张卡片有 100 个字时就可能溢出。

所以问题并不是"有没有模板"，而是：

布局系统是否知道自己真正能装多少内容。

因此前端开始从"保存每一个布局答案"，逐步转向"保存布局规则"。

系统根据：

Canvas 尺寸；
页面边距；
gap；
内容数量；
字体大小；
文本实际高度；

动态计算最终的：

x / y；
width / height；
卡片排列；
字号与间距。

同时引入 Design Token，集中管理字体、颜色、间距、圆角等视觉规范。

这里也进一步明确了 Design Token 的边界：

Design Token 解决的是视觉一致性，不直接解决内容是否放得下。

真正解决溢出问题，还需要独立的容量约束和质量校验。

2.6 从"溢出就失败"到分级质量治理

在布局规则逐步稳定后，我开始增加生成质量校验。

最早的处理非常严格：

只要文本在最小字号下仍然无法放入页面，就认为生成失败，直接阻止用户进入编辑器。

从代码质量角度，这个逻辑没有问题：

复制代码

内容超出布局
    ↓
ERROR
    ↓
拒绝生成

但真实使用后很快发现，这个设计对用户并不友好。

因为：

大模型调用已经产生了成本；
整套内容其实已经生成完成；
可能只是某一张卡片多了几十个字；
系统却让整个生成结果作废；
用户连问题在哪一页都看不到。

这和 AI 产品的真实使用逻辑并不一致。

AI 生成的 PPT 本质上首先是一份"可编辑草稿"，并不需要保证第一次输出就完全无需修改。

因此我重新设计了质量门禁：

状态	处理方式
PASS	正常进入编辑器
WARNING	保留完整生成结果，提示具体页面和字段，由用户修改
ERROR	结构非法等硬错误，直接阻断

这样就把"结构不可用"和"排版不完美"区分开来。

随后又进一步把布局容量前置到 Prompt：系统已经知道不同页面类型能够容纳多少条内容、标题大概多长、正文允许多少行，就没有必要等模型生成以后再第一次告诉它"写太多了"。

因此形成了：

复制代码

布局容量规则
      ↓
前置到 Prompt
      ↓
模型第一次生成时主动控制内容长度
      ↓
系统再次确定性检查
      ↓
PASS / WARNING / ERROR

这也是项目从"Prompt 调优"走向"AI 应用质量治理"的一个关键阶段。

2.7 从单页可控到整套 PPT 可控

当单页问题逐渐解决后，又出现了更高一层的问题：

每一页都合法，并不代表整套 PPT 看起来像一份正常的 PPT。

例如模型可能连续生成大量 cards 页面。

从单页角度看：

卡片数量合法；
内容没有溢出；
坐标没有越界；

但整套 PPT 会显得节奏非常单一。

另外，如果只让用户选择"生成 5 页"，还会出现：

是否包含封面？
是否包含目录？
是否需要结束页？
目录和正文标题是否一致？

这些问题已经不是单页 Layout 能解决的，而是 Deck 级结构问题。

因此当前方案进一步把"用户选择页数"定义为"内容页数"，封面、目录、结束页由系统补齐，并让目录从正文标题中派生，而不是让模型单独生成一份可能和正文不一致的目录。

后续继续优化的重点则是 Deck Structure：

在生成单页内容之前，先约束整套 PPT 应该包含哪些页面角色，以及不同版式在整套演示中的组合和节奏，减少全篇都是同一类卡片页的问题。

三、当前产品效果与验证结果

经过上述多轮调整，当前版本已经可以跑通：

复制代码

输入主题 / 大纲
        ↓
AI 内容生成与页面规划
        ↓
结构化页面数据
        ↓
规则驱动布局
        ↓
质量检查
        ↓
在线编辑

目前已经实现标题页、目录页、要点页、卡片页等核心页面类型，并支持生成后继续修改文字、页面元素和图表。

3.1. 成本

在当前使用的中转 API 测试环境下，5 页 PPT 的一次生成成本约为 0.04 元。图片生成成本则取决于所选图片模型和调用方式。

这个数字不是为了证明"越便宜越好"，而是说明通过自主选择模型和控制调用链，可以把商业平台中不可见的生成成本变成自己可以评估和调整的变量。

3.2. 速度

早期复杂生成链路曾经需要约 30 分钟。

当前主链路已经压缩到分钟级，实际测试通常在 1-2 分钟内完成，但第三方中转 API 波动明显，同样输入、同样模型也曾出现约 18 秒和 180 秒的差异。

因此目前更合理的结论是：

架构本身已经从"多阶段重链路"收敛到分钟级生成，但最终响应时间仍会受到外部模型服务稳定性的影响。

3.3. 编辑能力

相比单纯生成图片或最终文件，当前结果会进入网页编辑器，用户可以继续调整生成内容。

这也是整个项目从一开始就没有放弃的核心目标：

AI 提高初稿效率，但最终控制权仍然属于用户。

3.4. Demo 完整流程验证

为了验证前面形成的方案是否真正能够落到产品中，我又用一条完整用户链路对当前 Demo 进行了验证。

当前实际操作流程为：

复制代码

登录进入首页
      ↓
选择模板
      ↓
输入需要生成的内容
      ↓
进入提示词编辑页面
      ↓
根据需要手动或自动拆分页
      ↓
点击生成
      ↓
AI 完成内容生成，系统逐页渲染
      ↓
进入在线编辑器继续修改
      ↓
保存到工作台继续管理

在生成前，用户可以继续补充提示内容，并选择自动分页；生成完成后，页面不是一次性图片，而是可以继续修改的结构化内容。

当前 Demo 已经可以验证以下几类核心能力：

从主题 / 素材输入到整套 PPT 生成的完整主链路；
生成前的 Prompt 调整和自动分页；
生成后的逐页渲染；
文字内容在线编辑；
插入组件、图表等页面元素；
生成结果进入工作台继续查看和编辑；
后台对模板、版式、Prompt 和模型配置进行管理。

这里 Demo 的价值并不是证明"功能很多"，而是验证前面的方案选择确实能够形成一个闭环产品：

AI 生成的结果可以进入系统渲染，再进入编辑器继续修改，而不是生成完以后就和产品流程断开。

在 CSDN 正文中，我只保留关键流程截图，而不会把完整 21 页操作说明全部展开，避免项目复盘变成产品使用手册。

1.登录页

2.首页

3.提示词编辑页

自动分页

5.点击生成PPT

完成渲染
编辑修改内容
自行添加组件

8.工作台
后台管理PPT模板和提示词模板

四、项目中的核心难点与方案沉淀

回顾整个项目，真正困难的并不是"如何调用一个大模型 API"，而是如何把一个概率性的生成能力接入一个需要确定性的产品系统。

4.1. 视觉自由度与可编辑性的平衡

SVG / 图片类方案能够提供更高的视觉自由度，但和自己的在线编辑数据模型并不天然兼容。

纯结构化组件方案容易编辑，却需要自己承担布局和视觉设计能力。

最终选择规则驱动的结构化渲染，本质上是在两者之间取平衡：

不追求任意自由排版，而是优先保证稳定、可编辑，再逐步提高视觉上限。

4.2. AI 内容与前端布局之间的容量问题

项目中一个很重要的误判是：

文本溢出不一定是模型"乱生成布局"。

因为模型并没有输出坐标。

真正的问题是：

模型生成的内容长度，与前端布局实际容量之间缺少共享规则。

因此后续才会出现 Capacity Contract、真实文本测量和质量 Gate。

4.3. Agent 思路与 Web API 场景的适配问题

PPT Master 给了我很多设计上的启发，但直接复制 Agent 工作方式并不适合当前系统。

最终保留的是：

分阶段思考；
内容规划；
页面语义；
统一校验；

放弃的是：

开放式 Agent 循环；
不确定调用次数；
高成本模型强依赖。

把 Agent 思路重新压缩成固定的 API 工作流，是整个项目里非常重要的一次方案取舍。

4.4. "严格校验"不等于"好的用户体验"

最早把所有溢出都直接判定失败，从工程角度很干净，但从产品角度反而浪费了已经生成的内容。

最后改成：

硬错误阻断，软问题提示，用户继续编辑。

这个调整让我更加明确：

AI 产品的质量控制不是追求所有结果第一次就完美，而是要让失败成本可控，让用户能够继续完成任务。

4.5. AI 辅助开发工程化：从"让 AI 直接改"到"先理解、再定位、再小范围修改"

除了 PPT 生成链路本身，这个项目还让我重新调整了使用 AI 开发软件的方式。

项目早期，我曾经尝试把开发流程做得非常完整：给不同阶段配置多个 SubAgent，让它们分别负责需求、设计、开发、测试、质量检查，再通过 Hook 在提交代码后继续做需求对齐、质量检测和测试。

最初的想法是：

流程越完整，AI 开发出来的结果应该越可靠。

但真实使用后发现，一个 Demo 如果照搬完整的软件工程门禁，会出现另一个问题：流程本身开始比功能开发更重。

例如一个并不复杂的功能，也可能经历：

复制代码

需求分析
   ↓
方案设计
   ↓
开发实现
   ↓
质量检查
   ↓
测试
   ↓
Git 提交
   ↓
Hook 再次做需求对齐 / 质量检测 / 测试

结果是：

同一类检查在不同阶段重复出现；
Token 大量消耗在流程和上下文传递上；
一个功能的验证时间被明显拉长；
对 Demo 阶段而言，工程成本超过了实际风险。

这段经历让我意识到：

AI 工程化不是把所有流程都自动化，而是根据项目阶段和风险选择必要的控制点。

因此后续我把研发方式从"重流程、多 Agent、多门禁"逐步调整为"轻流程、关键节点校验"，把 AI 更多用于理解系统、分析问题和缩小范围，而不是让它在不清楚原因的情况下反复修改代码。

5.1 遇到 Bug 时，先让 AI 说清楚系统逻辑

开发过程中，我逐渐发现一个非常典型的问题：

如果直接告诉 AI：

"这里报错了，帮我修复。"

它很容易根据表面现象猜原因，然后直接修改代码。

即使 AI 最后说"问题已经解决"，也可能出现：

实际问题仍然存在；
修改到了错误的层；
同时改动多个文件，难以判断到底哪一个修改生效；
原来的问题没解决，又引入新的问题。

所以后来遇到复杂问题时，我不会第一步就让 AI 改代码，而是先要求它把当前系统解释清楚，包括：

当前功能的业务流程是什么；
前端事件从哪里触发；
调用了哪个 API；
后端经过哪些模块；
数据在哪里被转换；
最终通过什么结构返回前端；
哪一层负责真正的页面渲染。

通常我会要求 AI 先给出类似这样的链路：

复制代码

用户操作
   ↓
前端事件
   ↓
请求参数
   ↓
API 接口
   ↓
后端业务逻辑
   ↓
模型 / 数据处理
   ↓
返回结果
   ↓
前端状态更新
   ↓
组件渲染

只有先把这条链路说明白，后面的修改才有依据。

5.2 通过流程图、数据流和日志，把问题逐层缩小

逻辑梳理完成后，下一步不是继续猜，而是补证据。

我会根据问题所在链路，让 AI 建议需要观察的关键数据，然后通过：

前端 Console；
Network 请求；
后端日志；
模型原始返回；
JSON 中间结构；
数据库状态；

逐层确认"预期是什么、实际是什么"。

例如页面没有正确显示时，不直接假设是前端问题，而是逐层检查：

复制代码

模型是否正确返回内容？
        ↓
后端是否正确解析？
        ↓
结构化 JSON 是否正确？
        ↓
接口是否把正确数据返回前端？
        ↓
前端状态是否正确更新？
        ↓
布局计算是否正确？
        ↓
组件是否正确渲染？

只要某一层"预期值"和"实际值"第一次出现差异，问题范围就可以明显缩小。

这比让 AI 根据报错信息直接大范围修改代码更稳定，也更容易知道问题真正发生在哪里。

5.3 AI 分析正确但修改失败时，继续缩小修改范围

实际开发中还经常遇到另一种情况：

AI 对问题原因的分析是对的，但它给出的修改仍然失败。

这时我不会继续让它重新生成一套更大的修改，而是进一步限制范围。

例如把任务从：

"修复生成流程。"

缩小到：

"只检查这个接口的返回结构，不修改其他文件。"

如果仍然失败，再继续缩小到：

"只检查这个函数中从 structured_json 到前端 DTO 的映射。"

必要时进一步要求：

一次只修改一个文件；
一次只处理一个判断条件；
修改前先说明当前逻辑；
明确哪一行数据出现异常；
修改后只验证对应问题，不顺带重构其他代码。

这样做的目的，是把 AI 的修改从"大范围重写"变成"最小可验证修改"。

最终形成的调试方式更接近：

复制代码

发现问题
   ↓
先理解系统逻辑
   ↓
画流程 / 数据流
   ↓
补关键日志
   ↓
寻找第一个异常节点
   ↓
锁定最小修改范围
   ↓
让 AI 修改
   ↓
验证结果
   ↓
必要时再进入下一层

5.4 从这套开发方式中沉淀出的原则

经过多次踩坑后，我对 AI 辅助开发形成了几个比较稳定的原则：

第一，先解释，再修改。

如果 AI 不能把当前逻辑解释清楚，就不应该直接让它修改复杂代码。

第二，证据优先于猜测。

日志、请求数据和中间结构比"可能是这里的问题"更可靠。

第三，大范围修改失败时，不要继续扩大修改，而要缩小范围。

AI 越是一次修改很多文件，越难判断问题是否真正解决。

第四，自动化程度要和项目阶段匹配。

正式生产系统需要更严格的测试和质量门禁，但 Demo 阶段应该优先验证产品假设，避免流程本身成为主要成本。

第五，人仍然负责定义边界和验收结果。

AI 可以帮助分析、编码、测试和复盘，但最终仍需要开发者判断：问题有没有真正解决、修改是否符合原始设计、是否值得引入额外复杂度。

这套方法和前面 AI PPT 的架构演进其实是同一个逻辑：

无论是让 AI 生成 PPT，还是让 AI 参与软件开发，都不能只依赖模型自由发挥，而需要通过流程、边界、日志和验证机制，把不确定性逐步收敛。

相关的 SubAgent 过度工程化经历，我也单独整理过一篇复盘：

《我给 AI Demo 配了 7 个 Subagent 后，开发反而慢了：一次"过度工程化"的真实复盘》

https://blog.csdn.net/weixin_56706427/article/details/164302841

五、当前边界

目前这套系统已经跑通核心生成和编辑链路，但距离成熟商业 AI PPT 产品仍有明显差距。

当前主要边界包括：

页面视觉效果仍需要继续提升；
页面类型还不够丰富；
Deck 级页面节奏和版式多样性仍在继续优化；
图片生成依赖外部模型服务，稳定性受供应商影响；
PPT / PDF 导出链路仍需要继续完善；
当前重点仍然是毕业答辩 / 学术汇报类场景，并未尝试覆盖所有 PPT 类型。

这些限制也是下一阶段优化的依据。

六、项目总结与后续方向

这个项目最开始只是想解决一个很实际的问题：

现有 AI PPT 工具要么便宜但效果不稳定，要么效果更好但价格和流程受限，能不能自己做一个低成本、可编辑、可控制的版本？

真正做下去以后，问题逐渐从"模型选什么"变成了：

AI 应该负责什么？
系统应该负责什么？
哪些能力适合交给模型？
哪些能力必须由确定性代码控制？
当 AI 结果不完美时，系统应该失败，还是允许用户继续修改？

最终形成的核心原则是：

AI 负责不确定性的内容理解和生成，系统负责确定性的规则、布局和质量兜底。

后续还会继续优化两个方向：

Deck 级全局编排：从"单页合法"进一步升级到整套 PPT 的结构、节奏和版式组合可控；
视觉能力提升：在不破坏结构化编辑能力的前提下，继续丰富 Layout Family、图表和视觉规范。

这个项目当前的价值并不在于已经做出了一个比商业 AI PPT 更漂亮的产品，而在于完整经历了：

复制代码

需求发现
→ 方案调研
→ 技术验证
→ 失败定位
→ 范围收敛
→ 架构重构
→ 质量治理
→ 产品闭环

也让我真正理解：

生成式 AI 应用落地的关键，不只是让模型"能生成"，而是让生成结果进入一个可验证、可编辑、可维护的系统。