做 OmniAI 的时候，我的想法已经不只是“做一个 AI 功能”了。我开始想：如果把不同类型的 AI 创作能力放到一个统一入口里，它会不会更像一个真正的工作台？
这个项目的定位是本地优先的 AI 创作空间。主应用是一个 Vite 壳，里面集成了 AI 视频工作区。视频工作区来自一个 Next.js 应用，通过 /video-ai 路径接入。也就是说，它不是一个简单页面，而是一个主站加子工作区的组合。
为什么要做成工作台
我最开始接触 AI 工具时，经常遇到一个问题：每个能力都是分散的。视频生成在一个地方，图片生成在另一个地方，PPT 又是另一个入口。真正使用时，不断切换工具会打断思路。
OmniAI 想解决的是入口统一的问题。主界面提供一个创作平台的框架，把视频、图片、PPT 等能力放在同一个仪表盘里。当前重点接入的是 AI 视频生成，图片和 PPT 作为规划中的模块保留入口。
这种设计让我开始从“页面”转向“产品结构”思考：一个平台要有首页、模块入口、设置、用户管理、状态反馈、空状态、错误提示，还要能在部署后稳定运行。
项目里的关键结构
主应用使用 React、Vite 和 React Router。页面包括 Dashboard、Settings、UserManagement、AuthGate、WaooVideoEntry 等。仪表盘会展示项目统计、最近项目、核心创作模块入口，也会处理项目数据加载失败时的状态。
视频工作区通过集成的 waoowaoo-full Next.js 应用提供。主应用负责统一入口，视频工作区负责具体的视频生成流程。为了让本地使用更简单，我保留了 start-omniai.bat，通过一个启动脚本把需要的服务拉起来。
生产部署部分也做了整理。项目提供了 Dockerfile.prod 和生产环境说明，可以用 Docker Compose 启动。生产环境里，Web 入口对外暴露，MySQL、Redis、MinIO 留在 Docker 网络内部。这个设计让我第一次认真考虑“开发能跑”和“生产能部署”之间的差距。
本地优先带来的思考
OmniAI 的一个重要关键词是 local-first。它不是一开始就把所有东西都放到云上，而是优先保证本地工作流可用。
这带来了几个好处：
- 本地启动更符合我自己的开发习惯；
- 调试前端、后端、视频工作区更直接；
- 数据和配置更容易掌控；
- 后续再做生产部署时，可以从一个已经可用的本地工作流出发。
但本地优先也会带来新的问题。比如启动脚本要处理多个服务，日志要能看，生产环境变量不能乱放，备份和恢复也要有说明。项目里单独写了备份脚本和恢复文档，就是因为我开始意识到：一个工具只要涉及数据，就不能只考虑“启动成功”。
从功能到产品化
这个项目给我的成长，不在于某一个特别复杂的算法，而在于我开始补齐产品化意识。
以前我做项目，容易只关注主要功能，比如“能不能生成视频”。但 OmniAI 让我开始关注这些问题：
- 第一次打开时，用户看到什么；
- 没有项目数据时，页面怎么提示；
- 后端服务没接好时，如何返回清楚的错误；
- 生产环境的密码和密钥怎么管理；
- 数据库、对象存储、缓存服务应该暴露在哪里；
- 如果数据丢了，能不能恢复。
这些东西看起来不像核心功能，但它们决定一个项目是“演示页面”，还是“可以继续维护的系统”。
我学到的东西
第一，我学到平台型项目最重要的是边界。主站负责导航、入口和全局体验，子工作区负责具体能力。如果边界不清楚，项目会很快变成一团乱。
第二，我学到部署不是最后一步，而是设计的一部分。Docker、环境变量、内部网络、备份脚本，这些都应该在项目还不大的时候就想清楚。
第三，我开始理解“本地优先”不是拒绝上线，而是先保证自己能稳定地使用、调试和恢复。只有本地链路稳定，后续部署才更有底气。
回头看
OmniAI 目前还不是一个完整的商业化平台，但它对我来说是一次重要的跨越。
它让我从单点功能，走向集成式工作台；从写页面，走向考虑部署、备份和生产安全；从“能跑就行”，走向“以后还要能维护”。
这也是我做 AI 项目过程中很重要的一步。