这篇文章是我对「浮光造梦局 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 里的后端接口框架适合快速写 APISQLAlchemy 可以理解成代码和数据库之间的翻译层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 这些技术本身并不神秘。真正重要的是我通过这个项目理解了它们各自解决什么问题以及哪些临时方案会在后面变成返工来源。这个项目还不完美但它是我从零开始认真拉通的一条完整链路。这次复盘不是终点更像是一个阶段性存档。后面我会继续把它往更工程化、更稳定、更接近真实产品的方向推进。