xiaoxia-saas/docs/saas-rebuild-kickoff-plan.md

# 小虾 SaaS 重建启动方案

## 1. 背景与结论

当前桌面版代码已经不适合作为未来主线继续演进。

核心结论：

- 旧桌面版停止作为未来主线，不再继续做架构性重构。
- 新系统按 **SaaS 版** 重新开始开发。
- 目标不是“在旧系统上修补”，而是按正规软件工程方式做一个长期可维护、可扩展、可迭代的新系统。
- 旧代码只作为 **业务参考样本**、**规则参考**、**流程参考**，不再作为主开发容器。
- 新旧代码必须彻底隔离，避免再次混乱。

## 2. 总目标

做一个全新的 SaaS 系统，业务功能覆盖当前桌面版的核心能力：

- 素材库管理
- 配音库管理
- 素材分类与诊断
- 视频生成
- 批量生成
- 云同步
- 更新/版本机制（未来按 SaaS 方式重新设计）
- 任务进度与结果管理

目标要求：

- 可长期迭代
- 可多人协作开发
- 可上线部署
- 可观察、可回滚、可测试
- 不再回到“哪里报错改哪里”的状态

## 3. 基本原则

### 3.1 先定规则，再开始

在新项目开始编码前，必须先确认：

- 产品边界
- 一期范围
- 核心对象
- 核心流程
- 技术栈
- 架构分层
- 开发规范
- 发布规范
- AI 团队协作方式

### 3.2 新旧彻底隔离

- 旧桌面版代码继续保留，但只作参考
- 新 SaaS 项目必须在全新目录中开始
- 禁止把旧桌面版代码直接混入新系统主线
- 旧系统的安装脚本、Tkinter 逻辑、桌面发布链路不带入新主线

### 3.3 先盘点，再设计，再开发

执行顺序必须固定：

1. 盘点现状
2. 确认边界
3. 明确规则
4. 设计架构
5. 搭项目骨架
6. 分模块开发
7. Review / 测试 / 部署

## 4. 新系统目标架构

采用：

- **Clean Architecture**
- **MVVM / Presenter**
- **Ports / Adapters**

目标分层：

```text
Domain
  ↑
Application / Use Cases
  ↑
Ports
  ↑
Adapters
  ↑
Presentation (Presenter / ViewModel)
  ↑
Web UI / API / Worker
```

原则：

- 界面不写业务逻辑
- 业务逻辑不依赖框架
- 外部能力通过接口接入
- 任务、文件、存储、云服务全部可替换

## 5. 我们现在已有的资产

### 5.1 业务资产

- 现有桌面版就是最完整的业务样本
- 已经沉淀出大量业务规则和异常治理经验
- 已经明确的功能模块：
  - 素材库
  - 配音库
  - 批量生成
  - 云同步
  - 素材分类
  - 缺口诊断
  - 更新治理
  - 稳定性治理

### 5.2 工程资产

- Gitea 代码仓库
- CI / 基础自动化能力
- 巡检机器人
- 项目推进经验
- 既有测试体系雏形
- 架构规约基础文档

### 5.3 人和协作资产

- 你负责产品方向和最终拍板
- 小虾负责技术架构、拆解、规范、收口
- 已经形成连续迭代经验

## 6. 我们明显还缺的东西

### 6.1 产品边界

还需要明确：

- SaaS 面向谁
- 是个人 SaaS 还是团队 SaaS
- 是否多租户
- 是否有角色权限系统
- 是否有套餐/支付

### 6.2 系统边界

还需要明确：

- 素材文件存在哪里
- 视频生成在哪里跑
- 任务如何调度
- 节点/worker 怎么管理
- 哪些功能是一期，哪些延后

### 6.3 技术边界

还需要明确：

- 前端框架
- 后端框架
- 数据库
- 队列系统
- 对象存储
- 鉴权方式
- 部署方式
- 监控和日志方案

## 7. AI 团队工具怎么来

### 7.1 原则

前期 **不自研 AI 平台**。

策略：

- 直接购买/使用现成 AI 工具
- 我们自己做的是协作机制、流程和规则
- 工具是能力来源，制度才是稳定产出的关键

### 7.2 工具来源分类

#### 编码类 AI

用于：

- 写代码
- 重构
- 补测试
- 查仓库
- 做具体模块实现

候选工具：

- Codex / Codex CLI
- Claude Code
- Cursor
- Windsurf

#### 通用大模型类

用于：

- 需求整理
- 架构讨论
- 文档撰写
- 方案对比
- 总结与沟通

候选工具：

- ChatGPT
- Claude
- Gemini

#### UI / 原型类

用于：

- 页面草图
- 交互流程
- 组件原型
- 设计样稿

候选工具：

- Figma
- Figma AI
- v0
- Lovable

#### 协作 / 自动化基础设施

用于：

- 代码托管
- 持续集成
- 告警巡检
- 发布流程
- 项目推进

保留资产：

- Gitea
- CI/CD
- 巡检机器人
- 轻量项目推进机制

### 7.3 工具获取顺序

第一批先具备：

1. ChatGPT / Claude
2. Cursor 或同类编码 AI IDE
3. Figma
4. 保留现有 Gitea / CI / 巡检机器人

第二批按需要补：

1. v0 / Lovable
2. 专门 Review / QA 的 AI 会话体系
3. 更完整的测试辅助和流程自动化工具

### 7.4 工具不是越多越好

关键不是堆模型，而是：

- 谁负责什么
- 谁来拍板
- 谁来 review
- 谁来回归
- 所有人是否围绕同一套真相文档工作

## 8. AI 团队角色分工

### 8.1 人类角色

#### 你（产品负责人）

负责：

- 方向
- 目标
- 优先级
- 体验偏好
- 最终拍板

#### 小虾（技术负责人 / 总协调）

负责：

- 架构方案
- 任务拆解
- 规范制定
- 边界约束
- 技术决策收口
- 最终合并口径

### 8.2 AI 角色

#### UI 设计 AI

负责：

- 页面结构
- 交互流
- 页面草图
- 视觉方案辅助

#### 编码 AI

负责：

- 前端实现
- 后端实现
- 基础模块实现
- 脚手架和具体模块开发

#### Review AI

负责：

- 代码审查
- 风险检查
- 架构偏移检查
- 规范一致性检查

#### QA / Bug AI

负责：

- 复现问题
- 补测试
- 回归验证
- 测试建议

#### 文档 AI

负责：

- PRD 草稿
- 接口文档
- 架构文档
- 发布说明
- 迁移说明

### 8.3 协作铁律

- 一个问题只有一个 owner
- 架构只能由一个统一 owner 维护
- 写代码的人不能代替 Review
- 修 bug 的人不能代替 QA
- 所有 AI 输出必须围绕统一文档体系

## 9. 现有基础设施去留

### 9.1 保留

- 代码仓库（Gitea）
- CI/CD 理念和流程能力
- 巡检机器人
- 项目推进机制（轻量化）

### 9.2 不照搬

- 旧桌面版安装/同步/发布链路
- Tkinter 相关工程结构
- 旧系统临时修补脚本文化
- 为兼容旧桌面版而存在的特殊逻辑

### 9.3 新系统要重建的基础设施

- 新项目仓库结构
- 新 CI/CD 流水线
- 新日志/监控/告警规范
- 新部署流程
- 新测试流程

## 10. 每一步怎么走

### 第 1 步：盘点现状

盘 4 张表：

1. 我们现在已有的功能
2. 我们已有的工程资产
3. 我们已有的工具
4. 我们缺少的能力和基础设施

### 第 2 步：确认产品边界

确认：

- SaaS 给谁用
- 单人还是团队
- 多租户是否需要
- 一期和后续范围怎么划分

### 第 3 步：确认核心对象

确认是否保留和如何设计：

- 用户
- 团队 / 工作区
- 项目
- 素材库
- 配音库
- 生成任务
- 成片
- 任务节点 / worker
- 版本 / 发布对象

### 第 4 步：确认核心流程

要把这些完整走通：

- 上传素材
- 素材分类
- 配音管理
- 生成任务
- 批量生成
- 结果查看
- 下载/发布
- 后台任务监控

### 第 5 步：确认技术栈

需要明确：

- 前端
- 后端
- 数据库
- 队列
- 对象存储
- 鉴权
- 部署方式
- 监控日志

### 第 6 步：确认制度

包括：

- 目录结构
- 代码规范
- 接口规范
- 数据模型规范
- 提交流程
- 发布流程
- AI 协作流程

### 第 7 步：定义 MVP

列出：

- 一期必须做什么
- 可以延后什么
- 明确不做什么

### 第 8 步：再开始搭骨架

包括：

- 新项目目录
- 前后端工程骨架
- 数据库迁移体系
- CI/CD 初版
- 日志与配置体系

### 第 9 步：模块化开发

严格按架构和边界执行。

### 第 10 步：Review / QA / 上线

必须经过：

- Code Review
- 自动化测试
- 回归验证
- 预发布验证
- 正式发布与监控

## 11. 制度怎么落实

### 制度 1：先文档后开发

没有边界、架构、一期范围确认，不开工。

### 制度 2：单一真相源

必须建立统一文档源：

- PRD
- 架构文档
- 数据模型
- API 文档
- 里程碑

### 制度 3：架构 owner 唯一

- 架构由小虾负责收口
- 你负责最终确认
- 其他 AI 不得随意改方向

### 制度 4：AI 不直接上线

AI 产出必须经过：

- Review
- 测试
- CI
- 验收

### 制度 5：禁止临时修补进入主线

- 所有变更必须走既定流程
- 不允许口头规则替代正式规则

### 制度 6：一次只处理一个阶段问题

- 先定需求
- 再定架构
- 再定页面
- 再开发
- 再测试

### 制度 7：发布必须可回滚

- 每次上线必须可回滚
- 必须有监控与告警

### 制度 8：新旧彻底隔离

- 旧项目只参考
- 新项目主线独立开发

## 12. 当前最重要的下一步

不是写 SaaS 代码，而是先盘点：

### 第一张表：我们现在有什么

需要逐项盘清：

- 现有功能
- 现有工具
- 现有基础设施
- 可复用的业务规则
- 缺少的能力

只有这一步做清楚，后面技术选型、架构设计、AI 分工、项目骨架才不会跑偏。

## 13. 当前状态结论

我们现在已经统一了方向：

- 旧桌面版不再作为未来主线
- 新 SaaS 项目全新开始
- 必须正规化开发
- 必须先盘点、先定边界、先定制度
- AI 工具采用现成能力 + 明确分工，不自研底座
- 现有 Gitea / CI / 巡检机器人保留，但未来服务于新系统

下一步进入：

**《SaaS 重建盘点总表》第一阶段：我们现在有什么、还缺什么。**

配套文档：

- `docs/saas-rebuild-inventory.md`
- `docs/ai-team-tooling-checklist.md`
- `docs/infrastructure-keep-rebuild-matrix.md`
- `docs/saas-core-objects.md`
- `docs/saas-core-flows.md`
- `docs/saas-tech-stack-options.md`
- `docs/saas-mvp-scope.md`
- `docs/saas-project-structure-spec.md`
- `docs/saas-development-workflow.md`