> 这篇文章是我对「浮光造梦局 Dreamweaver Studio」的一次阶段性总结。它还不是一个完美项目，但它让我真实经历了一次从想法、原型、前后端、AI 接入、视频导出到工程整理的完整过程。
一、为什么想做这个项目
一开始我只是想做一个比较有意思的 AI 应用：用户输入一个故事创意，系统自动帮他生成剧本、分镜、画面、视频、配音和字幕，最后导出一条 1 到 3 分钟的漫剧短片。
刚开始想得很简单，好像只要有页面、有接口、有数据库，再接几个大模型 API，就能做出来。
真正做下来才发现，这不是一个简单的“调用 AI 生成文本”的项目，而是一条很长的生产流水线。每一步都要把上一阶段的数据接住，再传给下一阶段。只要中间某个环节的数据乱了，后面就会跟着乱。
这也是我在这个项目里学到的第一件事：AI 应用真正难的地方，不只是提示词，而是如何把不稳定的 AI 输出接进稳定的工程流程。
二、这个项目到底在做什么
简单说，我希望用户只需要输入一个创意，系统就能一步步帮他生成：
创意输入 ->Story Plan -> 剧本生成 ->Production Context -> 分镜拆解
-> 画面生成 -> 视频片段 -> 配音字幕 -> 时间线合成 -> FFmpeg导出 MP4
这里有几个词可以先用大白话解释一下：
- Story Plan：故事策划稿，先把人物、场景、剧情大致定好。
- Production Context：剧组设定本，后面的分镜、画面、配音都从这里取统一设定。
- 分镜：把剧本拆成一个个镜头，比如谁出现、在哪个场景、镜头怎么拍。
- 时间线：类似剪辑软件里的轨道，把视频、配音、字幕、BGM 按顺序排好。
- FFmpeg：命令行里的视频剪辑合成工具，负责最后把素材合成 MP4。
三、我用了哪些技术
前端我用了 Vue 3、Vite、TypeScript、Element Plus、Pinia 和 Tailwind CSS。
Vue 3 可以理解成负责搭页面的“积木系统”；Vite 是前端开发启动器，优点是启动快、热更新快；TypeScript 是给 JavaScript 加一层类型说明，减少低级错误；Element Plus 提供现成的按钮、表单、弹窗、表格；Pinia 是前端状态仓库，用来保存登录状态、项目状态和编辑器状态。
后端我用了 FastAPI、SQLAlchemy、MySQL 和 Redis。
FastAPI 是 Python 里的后端接口框架，适合快速写 API；SQLAlchemy 可以理解成代码和数据库之间的翻译层；MySQL 是项目的正式账本，用户、项目、剧本、分镜、素材都存在这里；Redis 像一个高速临时记事本，适合做验证码频控、缓存和后续任务队列。
AI 和媒体处理方面，项目接入了 DeepSeek、豆包、智谱、Kimi 等文本模型，也接入了图片、视频和 TTS 配音相关能力。最后通过 FFmpeg 做成片合成和导出。
四、从原型到真实链路
项目早期更像一个前端原型，很多页面靠 mock 数据撑起来。
mock 数据可以理解成“假数据”。它很适合早期快速画页面，但如果长期依赖 mock，后面接真实接口的时候就会很痛苦。因为真实系统会有登录状态、接口失败、数据库保存、刷新恢复、权限校验、任务等待等问题。
我在项目里就经历过这个过程：页面看起来都能点，但真正接上登录、项目、AI 任务以后，问题才集中暴露出来。
比如未登录用户能不能进入创作页？刷新页面后当前项目还能不能恢复？AI 生成失败后任务状态怎么显示？剧本生成完成后，分镜页面应该从哪里读取数据？
这些问题都不是单个页面能解决的，而是需要前端、后端、数据库和状态管理一起配合。
五、几个最值得沉淀的经验
1. 不要让 mock 陪你走太久
mock 能帮你快速搭原型，但核心链路一定要尽早换成真实接口。真实接口会逼你面对登录、权限、错误处理、数据持久化和状态恢复。越晚接入，返工越重。
2. 长任务要有任务状态
AI 生成小说、分镜、图片、视频、配音、导出，这些都不是普通接口。它们可能要等很久，也可能失败。
所以我做了 AI 任务表。可以把它理解成“任务登记簿”：每次生成任务都会有一个 taskId，系统记录它是排队中、运行中、成功、失败还是取消。
目前项目里使用 FastAPI BackgroundTasks 做轻量后台任务。它适合开发和演示，但还不够生产级。后续应该升级成 Celery、RQ 或 Redis Streams 这类更可靠的任务队列。
任务队列可以理解成“排队叫号系统”：用户提交任务后不用一直等，后台按顺序处理，前端只需要查进度。
3. 稳定 ID 比名字可靠
早期很容易用角色名、场景名去串数据，比如“女主”“咖啡馆”。但项目复杂后会遇到改名、重名、歧义等问题。
后来我引入了 Production Context，让角色、场景、剧情节拍都有稳定的 key。这样后面的分镜、画面、配音不用靠猜，而是从同一份“设定本”里取数据。
这件事给我的启发很大：名字是给人看的，稳定 ID 才是给系统用的。
4. 文档是长期项目的地图
这个项目周期比较长，功能多，返工也多。中间如果没有文档，很容易忘记某个设计为什么这么做，也很难判断现在到底完成了什么。
后来我把文档整理成产品、设计、功能、历史、笔记几个目录，并维护了一份“当前实现状态”作为总入口。
这让我感受到：文档不是事后补作业，而是项目地图。
六、踩过的坑
第一个坑是 mock 数据。早期页面推进很快，但真实后端接入后，登录状态、路由守卫、项目恢复、接口错误都需要重新处理。
第二个坑是短信服务。普通短信服务往往涉及企业资质，个人开发者并不一定能顺利接入。最后项目里增加了开发模式和频控逻辑，先保证本地开发和演示流程能跑。
第三个坑是密钥安全。.env里可以放真实密钥，但.env.example不能放。日志、提交历史、示例配置都要检查，否则很容易把 AccessKey 暴露出去。
第四个坑是数据库迁移。现在项目还没有正式引入 Alembic。Alembic 可以理解成数据库表结构的版本管理工具。没有它，表结构一多，后续修改和回滚都会很麻烦。
第五个坑是 AI 输出不稳定。大模型不是传统函数，同样的输入不一定每次都返回完全一样的结构。所以后端必须做 JSON 约束、结果校验、失败重试和质量门禁。
质量门禁可以理解成“出厂检查”：AI 生成的内容不是直接进入下一步，而是先检查有没有缺字段、乱引用、占位文本或明显错误。
七、项目现在还不完美
我不想把这篇文章写成“项目已经大功告成”。
事实上，它还有很多问题。支付订阅、积分额度、作品社区、团队协作、内容安全检测还没有真正落地。AI 任务现在也还不是生产级任务队列，服务重启时后台任务存在丢失风险。数据库迁移、密钥扫描、监控告警、水印策略、多画幅导出，也都需要继续补。
但我觉得这正是这个项目的价值。它不是一个包装得很完美的展示品，而是一个真实项目在成长过程中的阶段性切片。
八、下一阶段准备怎么做
后续我会优先做几件事：
- 引入 Alembic，把数据库结构变更规范起来。
- 把 BackgroundTasks 升级成 Celery 或 RQ，让 AI 生成和视频导出任务更可靠。
- 补内容安全检测，尤其是文本、图片、视频导出前的审核。
- 继续完善积分、订阅、作品社区这些产品闭环。
- 整理文档、交付包和启动脚本，让别人能更容易理解和运行项目。
九、总结
做这个项目之前，我对“完整项目”的理解比较简单：页面能打开，接口能调用，数据库能存数据，就差不多了。
做完这个阶段后，我的理解变了。
一个完整项目不只是页面和接口，还包括数据流、状态恢复、权限控制、任务状态、错误处理、文档维护、安全意识和后续演进能力。
Vue、FastAPI、MySQL、Redis、AI 模型和 FFmpeg 这些技术本身并不神秘。真正重要的是，我通过这个项目理解了它们各自解决什么问题，以及哪些临时方案会在后面变成返工来源。
这个项目还不完美，但它是我从零开始认真拉通的一条完整链路。
这次复盘不是终点，更像是一个阶段性存档。后面我会继续把它往更工程化、更稳定、更接近真实产品的方向推进。
```
