# BookFlow — Layer 1: 战略层 (Strategy) > 文档版本：v3.0 > 日期：2026-04-29 > 设计框架：Jesse James Garrett《用户体验要素》五层模型 > v3.0 变更：系统A 增加成果物追踪和微服务架构预留；系统B 增加管理员后台、用户分层、SEO 运营 --- ## 1.1 产品定义 BookFlow 由**两个独立子系统**共享同一套后端基础设施： ``` ┌─────────────────────────────────────────────────────────────────────┐ │ BookFlow 后端基础设施 │ │ │ │ 爬虫 → 下载 → OCR → 翻译 → 存储 → 闲鱼上架 → AI 客服 → TTS │ │ │ ├────────────────────────────────┬────────────────────────────────────┤ │ │ │ │ 子系统A：内部自动化管线 │ 子系统B：外部用户服务 │ │ (Internal Pipeline) │ (Customer Portal) │ │ │ │ │ 使用者：内部团队 (gerry) │ 使用者A：外部付费用户 │ │ 核心：服务监控+成果物追踪 │ 使用者B：系统管理员 │ │ 架构：面向微服务演进 │ 核心：搜索→下载/翻译→查看管理 │ │ 扩展：多数据源/多店铺/多账号 │ 扩展：用户分层/SEO运营/内容管理 │ │ │ │ └────────────────────────────────┴────────────────────────────────────┘ ``` ### 两个子系统的根本区别 | 维度 | 子系统A：内部自动化管线 | 子系统B：外部用户服务 | |------|----------------------|---------------------| | **谁用** | 内部团队（gerry） | 外部用户 + 管理员 | | **做什么** | 监控服务运行、追踪成果物、管理资源 | 搜索书籍、下载/翻译、查看对比、管理文件 | | **看什么** | 每个服务/子服务的状态 + 每个成果物的状态 | 搜索结果 + 翻译进度 + 文件库 + 原文/译文对比 | | **扩展方向** | 多数据源、多店铺、多AI供应商池 | 多用户层级、SEO运营、内容管理 | | **架构预留** | 微服务（服务注册/发现/监控） | 用户管理/计费/权限 | --- ## 1.2 用户画像 ### 子系统A 用户：内部运营者（gerry） ``` ┌─────────────────────────────────────────────────────────────┐ │ 👤 运营者 (gerry) │ │ │ │ 角色：BookFlow 全部后端服务的运维者和管理者 │ │ │ │ 核心关注： │ │ 1. 各服务是否正常运行（健康状态、心跳、在线率） │ │ 2. 各成果物处于什么状态（下载了多少？OCR 了多少？） │ │ 3. 资源消耗和成本（Token 用了多少？存储用了多少？） │ │ 4. 产能和效率（日处理量、瓶颈在哪、失败率多少） │ │ │ │ 扩展性诉求： │ │ · 数据源会从 1 个（Anna's）扩展到多个（LibGen、Google等） │ │ · 店铺会从 1 个闲鱼扩展到多个店铺 │ │ · 翻译账号会从 1 个扩展到多供应商×多账号的池子 │ │ · 所有服务未来演进为微服务架构（注册/发现/监控） │ │ · 界面需要为这些扩展预留空间和操作入口 │ └─────────────────────────────────────────────────────────────┘ ``` ### 子系统B 用户A：外部用户 ``` ┌─────────────────────────────────────────────────────────────┐ │ 👥 外部用户（多层级） │ │ │ │ 核心需求： │ │ 1. 搜索书籍 → 下载原文 或 翻译为中文 │ │ 2. 在线查看原文、译文、或左右对照对比 │ │ 3. 管理自己的文件库（已下载/已翻译的文件列表） │ │ 4. 对文件进行操作（下载、删除、分享链接） │ │ │ │ 用户层级（影响限额和功能）： │ │ ┌──────────┬──────────┬──────────┬──────────┐ │ │ │ Free │ Pro │ Max │ API │ │ │ │ │ │ │ │ │ │ │ 搜索:50/日│ 搜索:无限│ 搜索:无限│ 搜索:无限│ │ │ │ 下载:3/日 │ 下载:20/日│ 下载:无限│ 下载:无限│ │ │ │ 翻译:10页 │ 翻译:500页│ 翻译:3000│ 翻译:5000│ │ │ │ 存储:100MB│ 存储:5GB │ 存储:50GB│ 存储:无限│ │ │ │ 保留:7天 │ 保留:90天 │ 保留:1年 │ 保留:永久│ │ │ │ 对比:仅看 │ 对比:全功能│ 对比:全功能│ API访问 │ │ │ └──────────┴──────────┴──────────┴──────────┘ │ │ │ │ 不关心：下载怎么实现的、OCR 怎么做的、翻译用的什么模型 │ └─────────────────────────────────────────────────────────────┘ ``` ### 子系统B 用户B：系统管理员 ``` ┌─────────────────────────────────────────────────────────────┐ │ 🛡️ 系统管理员（gerry 或授权人员） │ │ │ │ 角色：子系统的运营管理者 │ │ │ │ 核心关注： │ │ 1. 用户管理：注册数、活跃用户、各层级分布 │ │ 2. 业务统计：搜索量、翻译量、下载量、成功率/失败率 │ │ 3. 异常追踪：失败的搜索、失败的翻译、失败的下载 │ │ 4. 服务状态：各后端模块对外部用户的可用性 │ │ 5. SEO 运营：博客文章管理、关键词、内外链、热门榜单解读 │ │ 6. 内容运营：发布文章、采集外部数据、标注关键字 │ │ │ │ 与子系统A 的区别： │ │ · 子系统A 关注的是后端服务的运行状态 │ │ · 管理员关注的是面向用户的业务运营数据 │ │ · 两者视角不同，界面不同 │ └─────────────────────────────────────────────────────────────┘ ``` --- ## 1.3 产品目标与成功指标 ### 子系统A：内部自动化管线 | # | 目标 | 衡量标准 | |---|------|---------| | A1 | **全流程自动化运行** | 每日自动发现 10+ 本新书并进入处理管线 | | A2 | **成果物全链路可追踪** | 每本书的每个阶段成果物状态一目了然 | | A3 | **异常快速发现和修复** | MTTR < 5 分钟 | | A4 | **多实例可扩展** | 新增数据源/店铺/供应商无需改界面结构 | | A5 | **微服务架构演进预留** | 界面设计兼容未来的服务注册/发现/监控模式 | **成功指标：** | 指标 | 当前 | 目标 | |------|------|------| | 查看全局状态耗时 | 5-10 分钟（SSH） | < 10 秒（仪表盘首屏） | | 成果物追踪可见性 | 看不到（SSH + sqlite3） | 每个服务页面实时展示 | | 新增数据源/店铺的工作量 | 需改代码 | 在界面上添加配置即可 | ### 子系统B：外部用户服务 | # | 目标 | 衡量标准 | |---|------|---------| | B1 | **搜索即得** | 已处理的书直接可下载 | | B2 | **在线查看** | 原文、译文、左右对照三种查看模式 | | B3 | **文件全生命周期** | 搜索 → 下载/翻译 → 查看 → 管理（CRUD）闭环 | | B4 | **用户分层运营** | 不同层级对应不同限额，引导升级 | | B5 | **管理可控** | 管理员可追踪所有业务数据和异常 | **成功指标：** | 指标 | 目标 | |------|------| | 搜索命中率 | > 80% | | 用户任务完成率 | > 70%（从搜索到拿到结果） | | Free → Pro 转化率 | > 3% | | 管理员发现异常耗时 | < 1 分钟 | --- ## 1.4 核心场景 ### 子系统A 场景 **A1：每日巡检（高频）** > 打开仪表盘 → 7 个主服务卡片各自显示健康状态和关键成果物计数 → 有异常则红色高亮 → 点击处理。 **A2：追踪某本书的成果物状态（高频）** > 管道看板中找到一本书 → 展开详情 → 看到它从发现到当前的每一步成果物（已下载 ✓ → 已上传R2 ✓ → OCR 73% → ...）→ 每个成果物有自己的状态。 **A3：管理扩展性资源（中频）** > 翻译管理 → API 密钥池 → 当前有 3 个 Key → 点击「添加」新增第 4 个 Key → 或者「添加供应商」接入新的翻译引擎。闲鱼管理 → 当前 1 个店铺 → 点击「添加店铺」接入第 2 个。书籍发现 → 当前 1 个数据源（Anna's）→ 点击「添加数据源」接入 LibGen。 ### 子系统B 场景 **B1：搜索 → 下载原文（高频）** > 搜索书名 → 找到 → 下载原文 PDF → 在浏览器中查看原文。 **B2：搜索 → 翻译 → 查看译文（高频）** > 搜索书名 → 点击翻译 → 等进度条 → 翻译完成 → 左右对照查看原文和译文 → 下载译文。 **B3：管理自己的文件库（中频）** > 打开「我的文件」→ 看到已下载/已翻译的所有文件 → 可以下载、删除、复制分享链接。 **B4：管理员查看运营数据（中频）** > 打开管理后台 → 查看今日注册/搜索/翻译/下载数量 → 查看失败任务列表 → 处理异常。 **B5：管理员发布 SEO 文章（中频）** > 打开内容管理 → 写/编辑博客文章 → 标注关键词 → 添加内外链 → 发布。 --- ## 1.5 技术演进方向 ### 微服务架构演进（子系统A） 当前各模块是独立的 FastAPI 服务，未来演进为完整微服务架构： ``` 当前状态： 各模块独立运行，无统一注册中心 演进目标： ┌─────────────────────────────────────────────────┐ │ 服务注册与发现中心 │ │ (Consul / Nacos / 自建) │ ├─────────────────────────────────────────────────┤ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ Anna's │ │ LibGen │ │ Google │ ... │ │ │ 数据源 │ │ 数据源 │ │ Reader │ │ │ └────────┘ └────────┘ └────────┘ │ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ 本地 │ │ R2 │ │ IPFS │ │ │ │ 存储 │ │ 存储 │ │ 存储 │ │ │ └────────┘ └────────┘ └────────┘ │ │ ┌────────┐ ┌────────┐ ┌────────┐ │ │ │ OpenAI │ │ DeepSeek│ │ Ollama │ ... │ │ │ 翻译 │ │ 翻译 │ │ 翻译 │ │ │ └────────┘ └────────┘ └────────┘ │ │ ┌────────┐ ┌────────┐ │ │ │ 闲鱼#1 │ │ 闲鱼#2 │ ... │ │ │ 店铺 │ │ 店铺 │ │ │ └────────┘ └────────┘ │ └─────────────────────────────────────────────────┘ ``` **界面设计原则：** - 每个「可扩展维度」（数据源/存储/翻译引擎/店铺）在界面中都是**列表形式** - 列表中的每一项可以独立查看状态、编辑配置、启停 - 新增一项 = 往列表中添加一条，不需要改界面结构 --- ## 1.6 技术约束 | 约束 | 说明 | |------|------| | 单服务器 | 51AC（116.204.12.137），微服务演进在同服务器上的 Docker 网络内 | | 无前端构建链 | 子系统A 静态 HTML+CSS+JS；子系统B Cloudflare Pages | | 后端 API 已存在 | 各模块 REST API 已实现 | | 中文优先 | 子系统A 纯中文；子系统B 中英双语 | --- *L1 战略层 v3.0 完成。核心变更：① 子系统A 增加成果物追踪和微服务架构演进方向；② 子系统B 增加管理员用户画像和 SEO 运营场景；③ 用户分层（Free/Pro/Max/API）限额体系；④ 所有可扩展维度（数据源/店铺/供应商）需在界面中以列表形式呈现。*