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