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 项目才能真正轻装上阵，而不是把旧系统的问题带过去。