[I.2] 个人作业：软件案例分析
[I.2] 个人作业：软件案例分析
| 项目 | 内容 |
|---|---|
| 这个作业属于哪个课程 | 网站 |
| 这个作业的要求在哪里 | [I.2] 个人作业：软件案例分析 |
| 我在这个课程的目标是 | 锻炼团队协作能力；学习项目开发范式；学习复杂性较高内容较多的完整项目开发 |
| 这个作业再哪个具体方面帮助我实现目标 | 学习现有软件的设计思路，思考其设计理念和改进方法，学会辨别优秀的软件，提高对优秀软件的理解并将贯彻到自己的项目开发中 |
一、选题说明
本次作业我选择分析的对象是开源软件 banana-slides。它是一个面向演示文稿生产场景的 AI 原生 PPT 生成工具，项目主页将其定义为“基于 nano banana pro 的原生 AI PPT 生成应用”，强调“支持上传任意模板图片、上传任意素材并智能解析、从想法/大纲/页面描述自动生成 PPT、口头修改指定区域，并一键导出可编辑 PPT”。截至我撰写本文时，该项目在 GitHub 上约有 13k stars、1.5k forks、587 commits，采用 AGPL-3.0 许可证，最新版本为 v0.4.0（2026-02-09）。(GitHub)
我之所以选择它，而不是传统办公软件或普通 AI 幻灯片网站，主要有三点原因。第一，它是一个真实可用而不是单纯演示性质的开源项目：既有完整前后端，也有导出、素材处理、部署文档和版本迭代。第二，它所在的赛道有明确现实价值。演示软件市场在 2025 年的全球规模已被多家研究机构估计在 76 亿至 82 亿美元量级，并继续增长；相关报告还将 Gamma、Canva、Beautiful.ai 等产品列为主要参与者，说明“AI 生成演示文稿”已经形成了实际市场。(GII) 第三，它的产品定位很有代表性：不是把 PPT 仅仅当成“文字自动排版”，而是试图把素材解析、页面生成、区域编辑和可编辑导出整合为完整工作流。(GitHub)
二、第一部分：调研与评测
1. 软件使用
本次测试覆盖了 banana-slides 的一条较完整主流程：
服务测试 → 一句话生成 → 大纲编辑 → 页面描述生成 → 局部页面编辑 → 导出设置 → 导出到 WPS 检查结果。
1.1 使用过程记录
截图显示，Baidu OCR、文本生成模型、图片识别模型、Baidu 图像修复、图像生成模型、MinerU PDF 解析等服务均测试成功，说明部署环境在测试时处于可用状态。这一点很重要，因为它排除了很多“其实只是环境没配好”的伪 Bug，保证后续问题更可能来自软件逻辑本身。
我在首页选择了“一句话生成”模式，输入“生成一份介绍软件工程的 PPT”，点击下一步。这个入口非常直观，几乎不需要学习成本，符合项目面向“小白用户”和“学生用户”的定位。项目 README 也明确写到，它支持“想法、大纲、页面描述”三种起步方式。(GitHub)
系统生成了一个 8 页的大纲。界面支持添加页面、重新生成大纲、导出大纲，并支持页面级的编辑和删除。这里的优点是：banana-slides 并没有把 AI 生成结果做成不可修改黑盒，而是允许用户在“真正开始做图之前”先调整结构。
进入逐页描述后，可以看到每页都生成了页面标题、正文文字，以及部分页面的表格说明。此阶段支持“批量生成描述”和逐页“编辑/重新生成”。从软件工程角度看，这一步把“内容结构”和“视觉生成”拆开了，这是一个很合理的设计：先保证信息结构，再进入图像化页面生产。
我在第 7 页进入页面编辑，系统允许选择区域、编辑页面大纲、编辑页面描述、上传上下文图片或调用素材库，然后再输入修改指令。这说明 banana-slides 的设计目标不是一次性生成后就结束，而是强调后续的“vibe 编辑”。
生成后的页面视觉质量较高，风格统一，信息组织也比较像真实汇报场景中的展示页。结合项目主页展示的“学生、教育工作者、职场人士”等适用场景来看，这种“先快速生成一个可看版本，再逐步修”的工作流确实有现实吸引力。(GitHub)
软件在导出前提供了较细的选项：组件提取方式、背景图获取方式等，推荐用户选择“混合提取”和“混合方式获取”。这说明开发者很清楚“可编辑导出”是产品竞争力之一，而不是附属功能。
实际导出的结果在 WPS 中依旧表现为整页大图，文字不可编辑。这直接关联到后文的第二个功能性 Bug。
1.2 产品是否解决了用户需求
整体来看，banana-slides 基本能够解决“快速完成一份结构完整、视觉统一的演示稿”这一核心需求。
它至少解决了以下三类真实痛点：
第一，从零开始难。很多用户并不是不会写内容，而是不知道如何把内容转成页结构；banana-slides 用“一句话生成 → 大纲 → 描述 → 页面”的链路降低了起步门槛。项目文档也强调其目标是“降低 PPT 制作门槛，让每个人都能快速创作出美观专业的演示文稿”。(GitHub)
第二，传统 AI PPT 工具自由度不够。README 直接点名传统产品常见问题：模板死、自由度低、同质化严重、素材质量差、图文排版割裂；banana-slides 的解决思路是加入模板参考图、素材解析、自然语言编辑和区域指定编辑。(GitHub)
第三，用户并不只需要“看起来像 PPT”，还需要“后续能交付和继续修改”。因此，导出 PDF/PPTX，尤其是导出“可编辑 PPTX”，是它非常关键的价值点。项目 v0.4.0 甚至把“可编辑 pptx 导出全面升级”作为版本亮点之一。(GitHub)
1.3 优缺点分析
优点
（1）工作流完整。
banana-slides 不只做“生成第一页”，而是把输入、结构编辑、逐页描述、区域编辑、导出都连起来了，这比许多只会出静态页面的工具更接近真实生产场景。(GitHub)
（2）素材处理能力较强。
项目 README 明确支持 PDF、Docx、MD、Txt 等多种文件输入，并自动解析关键点、图片链接和图表信息，还支持上传参考图或模板定制风格。(GitHub)
（3）视觉结果有吸引力。
从我的实测截图看，页面整体风格统一，图像生成质量较高，适合作为课程作业、讲解型报告或概念展示的初稿。
（4）面向非设计用户。
一句话生成入口非常低门槛，这一点对学生尤其重要。
缺点
（1）编辑语义与区域控制不够稳定。
我在第一个 Bug 中会详细说明：选中了“键盘”并要求“往里边挪一挪”，结果系统没有移动键盘，而是在旁边生成了一个磁带。这说明局部编辑的“指令理解”和“区域约束”存在偏差。
（2）“可编辑导出”与实际结果不一致。
第二个 Bug 说明，即便按推荐选项配置“可编辑 PPTX 导出”，最终仍可能得到一个整页图片式 PPT，无法编辑文字，直接损害核心卖点。
（3）部署和环境依赖较复杂。
banana-slides 不是纯在线小工具，而是一个包含 OCR、图像生成、图像修复、PDF 解析等多模块的系统；项目近期更新也集中修复了导出相关 500、数据错位、任务轮询错误项目等问题，说明其系统复杂度不低。(GitHub)
1.4 改进意见
如果从产品经理视角给改进建议，我认为 banana-slides 当前最需要优先做的不是再加更多炫酷功能，而是先把“可控性”和“可信交付性”做稳。
第一，提高局部编辑的目标对齐能力。用户已经明确圈选了区域，并且修改意图只是“移动”而非“新增”，系统就不应擅自生成语义上不相关的新物体。
第二，让导出结果与设置名实相符。既然界面写的是“可编辑 PPTX 导出设置”，那用户就会天然期待文字、表格、组件至少部分可编辑；如果某些页面只能退化成图片，也应该显式提示，而不是让用户导出后才发现。
第三，增加失败反馈与可解释性。例如导出时应给出“本页可编辑组件提取成功/失败”的统计信息，让用户知道问题出在哪里，而不是只能靠打开 WPS 之后自行判断。
2. 用户调研
这一部分你还没把采访材料发给我，所以我先把正文骨架写好，你后面只要把内容填进去即可。
2.1 采访对象背景
【待补：采访对象是2306的王琦，为吴际软工班级学生】
我选择采访该同学的原因是：TA 平时需要做课程展示，但并不擅长从零设计 PPT，因此与 banana-slides 的目标用户高度吻合。TA 的核心需求是：在较短时间内完成一份结构清晰、排版美观、还能继续修改的汇报材料。
3. 评测结论
如果按照课程要求给出一个定性结论，我的评价是：
d）好，不错
理由是：banana-slides 已经不是简单的“AI 出图演示项目”，而是有明确产品定位、较完整主流程、较强视觉生成能力和较活跃社区关注度的开源项目；但从我的实测结果看，它在区域编辑精确性和可编辑导出可靠性这两个核心能力上仍有明显不足，因此我暂时不给“非常推荐”。其当前质量更像“很有潜力、已经可用，但关键链路仍需打磨”的状态。项目的社区规模、版本迭代与功能路线也支持这个判断。(GitHub)
3.1 一个定量评分模型
为了避免只给主观印象，我采用 100 分量化模型：
| 维度 | 权重 | 本次评分 |
|---|---|---|
| 功能完整度 | 25 | 22 |
| 生成质量 | 20 | 17 |
| 可编辑性 | 15 | 8 |
| 易用性 | 10 | 8 |
| 素材处理能力 | 10 | 9 |
| 稳定性 | 10 | 6 |
| 用户体验 | 10 | 7 |
总分：77/100
这个分数的逻辑是：
它在“能不能快速产出一份像样的 PPT 初稿”上表现不错，但在“能不能按用户精确意图编辑”和“导出后能不能真正继续改”这两项上失分较多。也就是说，它已经把“从无到有”做得相当好，但“从有到可控、可交付”仍是短板。
三、Bug 分析与提交
0. Bug 严重性量化标准
为便于后文分析，我先给出统一标准：
-
5 星：核心功能失效、数据损坏或严重安全问题
-
4 星：主流程严重受影响，用户难以完成核心任务
-
3 星：功能异常明显，但有替代路径
-
2 星：局部异常，对主流程影响有限
-
1 星：轻微表现问题
我采用三个维度判断严重性：
系统功能影响、用户体验影响、商业承诺/产品预期落差。
Bug 1：区域编辑未按指令移动选中物体，反而生成无关新元素
1.1 测试环境
Demo网站
1.2 可复现性与复现步骤
该问题具备明确触发路径：
-
打开某一页生成结果，进入“编辑页面”弹窗。
-
在页面中框选键盘区域。
-
输入修改指令。
-
提交编辑请求。
-
查看结果。
1.3 Bug 现象描述
-
编辑前，用户明确选中了页面底部偏右的键盘元素；
-
指令并不是“增加物体”或“替换成别的物体”，而只是非常轻量的空间调整；
-
编辑后，键盘位置没有按要求向里移动；
-
系统反而在其附近新增了一个磁带状元素。
用户给定了目标对象、给定了修改范围、给定了修改动作，系统仍未执行目标动作。
1.4 Bug 分析
我认为该 Bug 的可能成因有：
指令语义被错误解释。
“往里挪一挪”本质是一个几何位置调整命令，但生成模型可能更擅长“添加/替换/重绘”，不擅长保持对象身份并做受限位移。
局部编辑策略设计不够严格。
如果系统使用的是“局部重生成”而非“结构化对象变换”，就容易出现这种：看上去局部有变化，但实际上并未完成用户指定操作。
1.5 严重性评估
我给这个 Bug 3 星。
-
从系统功能看，它没有让整个页面报错，但它破坏了“区域编辑”的可信度；
-
从用户体验看，问题比较严重，因为用户会迅速失去对局部编辑功能的信任；
-
从产品承诺看，banana-slides 把“口头修改指定区域”写成核心能力之一，因此这个 Bug 发生在产品卖点上。(GitHub)
1.6 为什么团队可能没有在发布前修复
我认为原因可能是以下几点：
-
设计质量层面：当前局部编辑更像“图像生成式修补”，不是严格对象级编辑。
-
测试覆盖不足：开发者可能更多测试了“换风格、加元素、改标题”等任务，而没有大量覆盖“轻微位置调整”这种细粒度命令。
-
用户需求理解偏差：用户认为“圈选 + 口头命令”意味着接近精确编辑；开发者可能默认它只是一个“高自由度局部重生成”工具。
-
模型能力：当前图像生成模型的能力可能不足，难以理解用户指令。
还有一些原因可能与开源软件的开发方式有关：
- 开源项目的开发，使用场景并非生产环境，因此不必面面俱到。
- 核心维护者主要是项目所有者一人，因此难以进行全面测试。
1.7 改进建议
正常行为应当是：
当用户明确圈选一个元素，并给出“移动”“缩小”“放大”“删除”等确定性操作时，系统应优先执行结构性变换，而不是自由生成新物体。
实现上可考虑：
-
把“移动类指令”与“重绘类指令”分开处理；
-
在局部编辑前做一次命令分类；
-
对于“移动/缩放/删除”，尽量走几何变换或对象级编辑通道；
-
在结果返回前做一次差异检测，若新增了无关元素则提示失败并重试。
Bug 2：按推荐设置导出“可编辑 PPTX”，实际仍导出为整页图片，文字不可编辑
2.1 测试环境
Demo网站
2.2 可复现性与复现步骤
复现路径明确且完整：
- 完成 PPT 页面生成。
- 打开“可编辑 PPTX 导出设置”。
- 组件提取方式选择“混合提取（推荐）”。
- 背景图获取方式选择“混合方式获取（推荐）”。
- 导出为可编辑 PPTX。
- 用 WPS 打开导出文件。
- 检查文字是否能单独选中和编辑。
2.3 Bug 现象描述
- 导出前，用户已经按照产品推荐设置开启“混合提取”和“混合方式获取”；
- 导出后在 WPS 中，整张页面被当作一张大图片处理；
- 页面文字不能像文本框那样单独选择、编辑或修改。
这个问题之所以是功能性 Bug，而不是“正常但不理想”，关键在于：
软件界面和功能命名已经明确承诺这是“可编辑 PPTX 导出”。
如果最终结果只是静态图片，那它与普通“图片型 PPT 导出”在用户层面几乎没有本质差别。
2.4 Bug 分析
我认为这个 Bug 的可能成因主要有三类：
第一类：组件提取失败后静默回退为图片。
系统可能在 OCR、版面分析、组件切分或文本框重建阶段失败，然后直接退化成整页图片，但没有向用户明确提示。
第二类：背景图与前景组件分离不成功。
“可编辑导出”的核心是把背景和文本、表格、图标等前景组件重新拆开；一旦背景清理或组件分层失败，就可能整体扁平化成单张位图。
第三类：导出设置与实际导出逻辑不一致。
UI 提供了看上去很细的选项，但后端可能在某些页面类型上并未真正实现相应的可编辑重建能力。
2.5 严重性评估
我给这个 Bug 4 星。
原因很直接：
-
它发生在主流程末端，也就是用户最关心的“交付”环节；
-
它直接削弱了 banana-slides 最重要的差异化卖点之一；
-
对学生、教师、职场用户来说，能否继续编辑 PPT 往往决定了是否愿意把它用于真实任务。
项目 v0.4.0 专门强调“可编辑 pptx 导出全面升级”，并将其作为版本亮点，这更说明这个能力在产品定位中是核心能力。(GitHub)
2.6 为什么团队可能没有在发布前修复
我认为可能原因包括：
-
测试把关不严：只验证了“导出成功”，但没有充分验证“导出后是否真的可编辑”。
-
边界条件复杂：不同页面结构、字体、背景、图像风格、OCR 精度都会影响可编辑重建。
-
为了保证成功率做了静默降级：开发者可能为了“至少导出一个可打开文件”，优先保证结果可见，而不是保证结果可编辑。
-
其他原因：作者可能做了基本的测试，但是实际部署中，存在各种不同的环境。由于开源软件的开发能力限制，很难全面测试。作者应该是打算先把功能上线，利用开源社区的反馈，进行不断完善。
2.7 改进建议
正常行为应当是：
只要导出按钮命名为“可编辑 PPTX”，系统就应在结果中尽可能恢复文本框、表格和可选组件；若某些页面只能退化为图片，也必须明确告诉用户退化比例。
具体建议：
-
导出完成后给出“可编辑元素恢复报告”，例如：文本框恢复 14 个，表格恢复 1 个，失败页面 2 页；
-
在文件中对失败页面单独标记，而不是整份都静默扁平化；
-
在导出前做页面预检查，提前告诉用户哪些页面大概率只能输出图片。
2.8 Issue报告
截图中的用户信息，包括了学校和本人姓名拼音。
汇报了pptx导出的问题，得到了项目所有者的回复。
issue报告的链接是[https://github.com/Anionex/banana-slides/issues/335]
四、分析部分
1. 工作量分析
如果让我估算：一个 6 人左右的团队，成员为具备计算机本科背景的开发者，并有专业 UI 支持，想把 banana-slides 做到当前这种程度，我认为大致需要 16~24 周。
理由如下。
banana-slides 不是单一模型调用 Demo，而是一个多模块系统：
前端需要实现首页输入、大纲编辑、逐页描述、页面局部编辑、导出设置、历史版本等交互；后端要处理文档解析、OCR、图片生成、区域编辑、导出、任务轮询、状态同步；另外还有 Docker、多架构镜像、国际化、暗黑模式、测试与部署文档。项目仓库当前已经积累了 587 次提交，代码主要由 TypeScript 和 Python 构成，近期更新中还修复了导出相关 500、outline/page 数据错位、任务轮询错误项目、图片预览内存泄漏等问题，这说明它已进入到“系统联调和复杂 bug 修复”阶段，而不是刚开始做 MVP。(GitHub)
如果拆分模块，我会这样估算：
-
前端主流程与编辑器：4~5 人周
-
文档解析与素材管理：3~4 人周
-
页面生成与局部编辑：4~6 人周
-
导出与可编辑 PPTX：4~6 人周
-
部署、测试、修复和 UI 打磨：4~5 人周
总量大约在 20 人周到 26 人周的核心开发，再加上多轮联调与修复，就会落到 16~24 周的 6 人团队周期区间。
如果只做“输入一句话，生成静态图片型 PPT”会快很多；但如果要做成 banana-slides 现在这种较完整形态，这个估算是合理的。
2. 软件质量分析
2.1 当前质量处于同类产品什么位置
如果只比较开源 AI PPT 生成工具，我认为 banana-slides 目前可以排进第一梯队。
原因很简单。
一方面，它的 GitHub 热度在同类开源项目中非常突出：banana-slides 约 13k stars，高于 Presenton 的约 4.3k、PPTAgent 的约 3.5k，以及 ALLWEONE Presentation AI 的约 2.6k。(GitHub)
另一方面，它的功能闭环也更完整：不仅能从想法、大纲、页面描述生成内容，还支持多格式素材解析、区域编辑和导出；而 Presenton 更强调“本地运行、隐私控制、多模型接入”，PPTAgent 更偏“反思式 Agent 框架”，ALLWEONE 则偏“在线生成 + 主题化演示”。(GitHub)
但是，如果把它和商业产品一起比较，它就还不是第一梯队的成熟赢家。
Gamma 官方将自己定位为“AI presentation maker & website builder”；Canva 的 Magic Design 已经可以通过提示词直接创建 Presentation；Beautiful.ai 则把“Smart Slides 自动对齐与自适应排版”做成了成熟卖点，并提供 300+ 布局。(Gamma)
相比这些商业产品，banana-slides 的强项在于开源、自部署、可研究、图像风格强；弱项则在于稳定性、导出可靠性、团队协作和商业级 polish。
所以我的判断是：
在开源同类中，banana-slides 在第一梯队；在整个 AI 演示工具市场中，它属于很强的特色型开源选手，但还不是大众市场里的最成熟答案。
2.2 软件工程方面最需要提高的一个重要方面
我认为 banana-slides 团队最需要提高的一点，是：
围绕“导出链路”和“局部编辑链路”的集成测试能力。
原因很明确。
这个产品最吸引用户的地方，不只是“能生成图”，而是“能生成并且能继续改”。而我这次找到的两个 Bug，恰恰都发生在最关键的承诺上：
- 说是“指定区域编辑”，结果不能按指定对象执行；
- 说是“可编辑 PPTX 导出”，结果仍然导出成整页图片。
这类问题说明：单独模块也许可用，但端到端体验没有被稳定地保证。
因此，相比继续加更多功能，我认为更重要的是建立：
- 局部编辑回归测试集
- 导出可编辑性测试集
- 页面类型覆盖矩阵
- 降级路径显式提示机制
五、建议和规划
1. 市场现状
1.1 市场概况
演示软件市场不是一个小众市场。多家市场研究报告显示，2025 年全球 presentation software market 大致在 76 亿到 82 亿美元区间，并保持双位数增长；相关市场报告还直接把 Canva、Beautiful.ai、Gamma.app 等列为主要参与者。(GII)
这意味着 banana-slides 所处的并不是一个临时热点，而是一个已经被验证存在长期需求的生产力市场。
其中，直接用户包括：学生、教师、产品经理、市场人员、销售、咨询顾问、研究人员；潜在用户则几乎覆盖所有“需要做展示、但不想自己排版”的知识工作者。
1.2 竞争产品
如果从开源产品看，我认为最值得拿来比较的有三个：
-
Presenton：强调本地运行、隐私保护、可接 OpenAI/Gemini/Ollama，更像“本地化 AI 演示生成器”。(GitHub)
-
PPTAgent：定位为“Reflective PowerPoint Generation”的 Agent 框架，更偏研究型和任务规划型。(GitHub)
-
ALLWEONE Presentation AI：强调在线生成、主题可定制，直接把自己宣传为 Gamma Alternative。(GitHub)
如果从商业产品看，主要竞争者则包括：
-
Gamma：强调 AI 生成 presentation、website 等多种形式内容。(Gamma)
-
Canva：Magic Design 已经把 AI presentation 作为标准能力之一。(Canva)
-
Beautiful.ai：用 Smart Slides 解决“排版自动适应”的问题。(Beautiful.ai)
1.3 产品定位、优势与劣势
我认为 banana-slides 的定位可以概括为：
面向学生、教师和知识工作者的开源 AI 原生 PPT 生成工具，主打高质量页面生成、区域编辑和可编辑导出。
它的优势在于：
-
开源，可自部署
-
视觉结果质量高
-
支持素材解析与模板参考
-
支持多阶段编辑，而不是一锤子买卖
-
社区关注度高
它的劣势在于：
-
导出可编辑性仍不稳定
-
局部编辑精确度不足
-
系统复杂，部署与维护门槛较高
-
相比商业产品，协作生态和 polished 体验较弱
2. 市场与产品生态
2.1 核心用户群
banana-slides 的核心用户主要有三类。
第一类：学生。
18~25 岁居多，预算有限，但课程汇报、答辩、展示频繁。表面需求是“快点做出 PPT”，潜在需求是“不要太丑、最好还能继续改”。
第二类：教育工作者和研究型用户。
他们经常有现成讲义、论文、PDF，希望快速转为讲课或报告页面。表面需求是“节约制作时间”，潜在需求是“内容可靠、图文一致、导出后方便再编辑”。
第三类：职场知识工作者。
包括产品、运营、市场、销售等，他们更重视效率、风格统一和交付质量。
这与项目 README 中列出的“小白、PPT 专业人士、教育工作者、学生、职场人士”等适用场景基本一致。(GitHub)
2.2 用户之间能否形成生态
可以。
学生和教师之间可以形成“教学—作业—汇报”的自然链条；学生毕业后进入职场，也会把“快速生成展示材料”的需求带过去。也就是说，banana-slides 的用户生态不是割裂的，而是存在明显迁移路径。
2.3 产品生态
banana-slides 本身也有形成生态的潜力：
-
主产品：AI 生成 PPT
-
素材生态：模板图、参考图、PDF/Docx/MD/Txt、素材库
-
输出生态：PDF、普通 PPTX、可编辑 PPTX
-
未来方向：搜索、Agent、协作、模板市场
如果这些能力继续完善，它完全有可能从“一个 AI 工具”成长为“一个开源的演示生产平台”。
3. 产品规划
3.1 我会优先做的新功能：可信编辑导出模式
如果我是新上任的项目经理，我不会优先加更多风格模板，而会先做一个新功能：
可信编辑导出模式（Trustworthy Editable Export）
为什么做这个功能，而不是其他功能
因为 banana-slides 当前最关键的产品矛盾不是“会不会生成”，而是：
-
用户能不能准确改
-
用户导出后能不能真改
-
用户敢不敢把它用于真实任务
这三个问题，正好被我本次发现的两个 Bug 暴露了。
所以，最优先的新功能不是锦上添花，而是把“区域编辑”和“可编辑导出”从卖点变成真正可靠的能力。
3.2 NABCD 分析
N — Need
学生、教师和职场用户都需要一种工具，既能快速出稿，又能在最后阶段进行可控修改，并且导出后还能继续编辑。
A — Approach
做一个“可信编辑导出模式”：
-
在局部编辑前先识别命令类型：移动、缩放、删除、替换、重绘
-
对“移动/缩放/删除”优先走结构化编辑，不走自由生成
-
导出时提供页面级恢复报告
-
对无法恢复为可编辑对象的页面，显式标记为图片页
B — Benefit
对用户来说，可信度大幅上升；
对产品来说，最核心卖点会真正成立；
对市场竞争来说，它能和“只会出图的 AI PPT”拉开差异。
C — Competition
商业产品强在成熟和稳定，开源产品强在可控和可定制。banana-slides 要赢，不能只比“我也能生成几页 PPT”，而要比“我更能让用户继续控制结果”。
D — Delivery
先做 V1：
-
局部编辑命令分类
-
导出恢复报告
-
图片页显式标记
-
可编辑性成功率统计
3.3 6 人团队配置
如果给我 6 个人、16 周时间，我会这样配：
| 角色 | 人数 | 主要职责 |
|---|---|---|
| 项目经理/产品经理 | 1 | 需求管理、里程碑、验收 |
| 前端工程师 | 2 | 编辑器、预览、导出交互、提示系统 |
| 后端/AI 工程师 | 1 | 编辑任务编排、命令分类、模型调用 |
| 导出/文档工程师 | 1 | 可编辑 PPTX 导出、OCR、组件恢复 |
| 测试/DevOps | 1 | 回归测试、部署、监控、CI |
3.4 16 周详细规划
第 1 周：需求调研、复盘现有 Bug、明确 V1 范围
第 2 周：产品原型、导出报告和局部编辑交互稿
第 3 周：技术方案评审，划分命令类型
第 4 周：前端搭建新交互骨架
第 5 周：后端实现局部编辑命令分类
第 6 周：接入结构化移动/删除策略
第 7 周：可编辑导出增加页面级报告
第 8 周：中期联调，修第一轮核心 Bug
第 9 周：建立页面类型测试集
第 10 周：建立导出恢复成功率统计
第 11 周：处理静默降级问题，增加显式提示
第 12 周：邀请真实用户试用
第 13 周：修复高频问题
第 14 周：完善文档、FAQ、错误提示
第 15 周：预发布与全面回归
第 16 周：正式发布与社区反馈跟踪
六、结论
通过这次评测，我对 banana-slides 的判断是：
它已经是一款非常值得研究和体验的开源 AI PPT 产品，但离“稳定、可信、真正可交付”的成熟状态还有一段距离。
它的优点很明显：
完整工作流、优秀视觉结果、低门槛生成、多阶段编辑、较高社区热度。(GitHub)
它的缺点也同样集中：
在最关键的两个环节——区域编辑和可编辑导出——仍然存在功能性缺陷。
所以如果从课程作业的角度给出一句总结，我会写成：
banana-slides 展现了开源软件在快速创新和产品原型落地上的优势，但本次实测也说明，一个真正优秀的软件，不只要“看起来很强”，更要在用户最核心的承诺上做到稳定可信。
浙公网安备 33010602011771号