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

目标分层：

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