xiaoxia-saas/docs/saas-rebuild-inventory.md

# 小虾 SaaS 重建盘点总表（第一版）

本文档用于回答两个最核心的问题：

1. 我们现在已经有什么？
2. 我们为了启动新的 SaaS 项目，还缺什么？

目的不是罗列名词，而是为后续 **产品边界、技术选型、架构设计、AI 协作分工、开发排期** 提供真实依据。

---

## 1. 当前已有资产总览

当前资产分为 5 类：

1. 业务资产
2. 工程资产
3. 基础设施资产
4. AI 协作资产
5. 人和流程资产

这些是我们重建 SaaS 时真正可以利用的起点。

---

## 2. 业务资产盘点

### 2.1 已有功能样本

现有桌面版已经覆盖了未来 SaaS 需要继承的主要业务能力：

- 素材库管理
- 配音库管理
- 素材分类
- 素材缺口诊断
- 视频生成
- 批量生成
- 云同步
- 更新治理
- 错误治理
- 稳定性治理

### 2.2 已沉淀的业务规则

这些规则以后不一定直接复用代码，但应该复用为 SaaS 业务规则或用例设计输入：

- 坏素材文件必须隔离，不能拖垮整批扫描
- 单个候选生成失败不能拖垮整个批次
- 长任务必须异步执行，不能阻塞 UI / 主流程
- 更新必须可回滚、可记录状态
- 主流程必须有错误诊断和恢复能力
- 核心业务逻辑比表面覆盖率数字更重要

### 2.3 现有业务理解深度

我们已经搞清楚了这些关键业务对象和关系：

- 视频素材
- 配音素材
- 素材库
- 配音库
- 生成策略
- 批量生成任务
- 生成结果
- 云端同步对象
- 更新版本 / 补丁包
- 错误诊断记录

这意味着新 SaaS 不是从“需求不清楚”开始，而是从“实现要重做，但业务已经摸透”开始。

---

## 3. 工程资产盘点

### 3.1 现有代码资产

旧桌面版代码虽然不再作为未来主线，但仍然是非常重要的参考资产：

- 它提供了完整功能样本
- 它暴露了真实复杂度和真实坑点
- 它帮助我们识别哪些模块是高风险区
- 它为 SaaS 重建提供业务规则、异常分支、边界条件参考

### 3.2 已有架构资产

虽然旧系统的最终实现不一致，但我们已经沉淀出一些正确方向：

- `Domain → Repository → Service → Facade` 的分层意识
- `Controller / View` 分离意识
- `EventBus` 的组件解耦尝试
- `Ports / Adapters / Application / Presentation` 新基线目录已经建立

### 3.3 已有测试资产

当前旧项目已经有一定测试基础：

- controller 测试
- service 测试
- repository 测试
- domain 测试
- update rollback 测试
- startup guard 测试
- material isolation 测试

这些测试未来不一定直接复用，但可以帮助我们：

- 提取业务规则
- 识别边界条件
- 设计 SaaS 版测试策略

---

## 4. 基础设施资产盘点

### 4.1 当前已经有的基础设施

- **代码仓库**：Gitea
- **CI 基础**：已有 CI 经验和工作流雏形
- **巡检机器人**：已有自动巡检思路和脚本基础
- **开发环境**：Windows 开发机 + Ubuntu 服务器
- **发布/同步经验**：已有正式版同步、回滚、状态记录经验

### 4.2 这些资产的保留策略

#### 必须保留

- Gitea
- CI/CD 思路
- 巡检机器人
- 服务器资源
- 版本管理流程

#### 只保留经验，不保留实现

- Tkinter 桌面版安装发布链
- 桌面版同步脚本体系
- 旧桌面版兼容逻辑
- 临时修复脚本文化

---

## 5. AI 协作资产盘点

### 5.1 当前已经具备的 AI 协作方式

- 已经形成“你拍板、小虾收口”的稳定协作模式
- 已经知道 AI 不能一个人包完所有角色
- 已经明确未来需要分角色使用 AI：
  - 架构
  - UI
  - 编码
  - Review
  - QA
  - 文档

### 5.2 当前还没有真正落地的 AI 团队能力

还缺：

- 明确的 AI 工具采购清单
- 明确的 AI 账号归属
- 明确的角色与工具映射
- 明确的 AI 输入输出规范
- 明确的安全边界（密钥、服务器、数据库等）

---

## 6. 人和流程资产盘点

### 6.1 当前团队形态

本质上还是：

- 你：产品负责人
- 小虾：技术负责人 / 协调者
- 其他 AI：按角色配合

这是一个“小团队”模式，所以新系统必须遵守两个现实：

- 技术栈不能过重
- 流程不能过重

### 6.2 当前已有流程经验

我们已经明确过的重要工程流程：

- 源码只在单一源目录修改
- 修改后先验证
- 再同步正式版
- 再确认
- 再 `git add / commit / push`
- 不能停在 commit

这个流程意识未来可以保留，但要升级为 SaaS 项目的正式流程。

---

## 7. 当前最核心的缺口

下面这些是现在真正缺少的，而且不补就不能稳启动 SaaS 项目。

### 7.1 产品边界缺口

还没最终拍板：

- SaaS 面向谁
- 单用户还是团队使用
- 是否多租户
- 是否有工作区概念
- 是否要权限系统
- 是否要付费/套餐系统

### 7.2 系统边界缺口

还没最终拍板：

- 素材文件存储在哪里
- 视频生成在什么节点执行
- 是否需要分布式 worker
- 是否有对象存储 / OSS / S3
- 是否支持多设备 / 多节点协同

### 7.3 技术选型缺口

还没确认：

- 前端框架
- 后端框架
- 数据库
- 队列系统
- 任务调度方式
- 鉴权方式
- 部署方式
- 日志/监控方案

### 7.4 工程制度缺口

还没正式落地：

- SaaS 项目目录结构
- API 规范
- 数据模型规范
- 提交流程
- 分支策略
- 测试规范
- 发布规范
- 回滚规范

### 7.5 AI 团队工具缺口

还没确认和落地：

- 编码 AI 用哪些
- UI AI 用哪些
- Review AI 用哪些
- QA AI 用哪些
- 工具怎么购买 / 开通 / 管理
- 哪些人/角色使用哪些工具

---

## 8. 当前最应该保留的东西

### 必须保留

- 业务规则和业务理解
- Gitea 仓库体系
- CI/CD 思路
- 巡检/健康检查能力
- 稳定性治理经验
- 测试意识
- 版本与回滚意识

### 必须放弃

- 继续在旧桌面版上做主线重构
- 临时脚本救火式开发
- 架构半拉子状态
- 一边想边改、一边改一边返工

---

## 9. 下一步盘点顺序

现在不应该直接进入代码开发。

接下来建议按这个顺序盘：

### 第 1 张表：我们现在有什么（当前文档）

已开始。

### 第 2 张表：我们还缺什么

在当前文档中已经列出核心缺口，但还需要进一步定级：

- 必须先有
- 可以后补
- 暂时不做

### 第 3 张表：AI 团队工具清单

需要补充：

- 工具名称
- 用途
- 谁用
- 优先级
- 获取方式
- 是否立即需要

### 第 4 张表：基础设施保留 / 废弃 / 重建清单

需要明确：

- 哪些沿用
- 哪些只保留经验
- 哪些必须全新搭建

---

## 10. 当前阶段的结论

### 我们现在真正拥有的，不只是代码

我们拥有：

- 完整业务样本
- 已知复杂度
- 已知坑点
- 已知异常处理经验
- 已有工程基础设施
- 已有协作方式

### 我们现在真正缺的，也不是代码

我们缺：

- 清晰边界
- 明确规则
- 技术选型
- AI 工具体系
- 正式工程制度

### 所以下一步的重点

不是“赶紧开工写 SaaS 代码”，而是：

- 继续把盘点做全
- 把边界定死
- 把工具准备好
- 把制度落成文档

只有这样，新的 SaaS 项目才能真正轻装上阵，而不是把旧系统的问题带过去。