diff --git a/docs/README.md b/docs/README.md new file mode 100644 index 0000000..a52bd0c --- /dev/null +++ b/docs/README.md @@ -0,0 +1,208 @@ +# 「美搭」文档索引 + +> 智能穿搭美学助手 · 文档体系导航 +> 最后更新：2026-08-13 + +--- + +## 0. 当前状态（先看这里） + +### 0.1 已经定下来的关键前提 + +| 项 | 结论 | 影响 | +|---|------|------| +| **备案** | ✅ **已完成** | 原本 2~4 个月的上线瓶颈解除，**开发进度即上线进度** | +| **V1 商业化** | **完全不收费**，用配额限制控成本 | 无 IAP、无会员、无点数购买、无广告；billing 域降级为配额与计量 | +| 客户端 | 鸿蒙原生 ArkTS（V1 单端） | 可触达基数是 HarmonyOS NEXT+ 设备，非全部鸿蒙生态设备 | +| 单品素材 | **全部自采实拍** | 版权干净，但**成为项目新的关键路径** | +| 形象顾问 | **全职编制** | 规则库产能可控，但到岗时间决定 M2 排期 | +| 五行/命理模块 | **永久不做** | 诊断维度 34 → **32 项** | + +### 0.2 现在最该先做的三件事 + +按优先级，这三件都不产出代码，但决定后面全部节奏： + +1. ⚠️ **核实备案登记覆盖的模型清单**（`T-P0-01`）—— 是否含 DeepSeek 与智谱 GLM 两家？若只含一家，双路由属超范围提供服务，需办变更备案或 V1 先单路由。**这是目前唯一可能影响 V1 上线合规性的未知项** +2. 🔴 **全职形象顾问招聘与入场**（`T-P0-20`）—— 规则库产能直接决定 M2 能否按期，且顾问到岗第一件事是评审本体 Schema，**必须在建表前完成** +3. 🔴 **单品自采流水线搭通并测出每周产能**（`T-P0-21`）—— 300 件 `tryon_ready` 的达成时间要靠实测产能倒排，不能靠估算 + +> **为什么是这三件**：备案完成后，项目的关键路径从"等外部审批"变成"内部内容产能"。第 2、3 项是唯一无法靠 AI 辅助开发压缩的工序 —— 招聘要时间、采购要物流、拍摄要棚时。**它们晚一周启动，上线就晚一周，没有任何技术手段可以追回。** + +### 0.3 待业务输入的事项 + +**仅剩 1 项**：备案登记覆盖的模型清单（见上方第 1 条）。其余 20 项决策已全部收口，见产品方案 §11 与技术选型报告 §7。 + +--- + +## 1. 文档地图 + +文档分四层，每层解决不同的问题。**遇到冲突时，以下层为准**（下层更具体、更晚更新）。 + +``` +第一层｜为什么做 +└─ 产品方案（总纲）──────── 定位、市场、商业模式、范围、路线图 + 鸿蒙美搭-智能穿搭美学助手-产品方案.md + +第二层｜做什么 +├─ 需求规格说明 ★ ───────── 统一需求编号、优先级、验收标准（开发与测试的索引） +│ 需求规格说明.md +├─ 美学报告-需求文档 ─────── 报告分级、触发时机、诊断维度字典 +├─ 穿搭Agent-需求文档 ────── 对话能力、意图、场景、输入输出规范 +├─ 用户系统与记忆系统 ────── 账号体系、分层记忆模型、权益与配额 +└─ 美学知识库-建设方案 ───── 知识分类、模态、构建流程、检索与推理 + +第三层｜怎么做 +├─ 技术架构文档 ★ ───────── 分层架构、模块划分、数据模型、关键链路、部署 +│ 技术架构文档.md +├─ 技术选型与调研报告 ★ ──── 所有技术决策的结论、理由、备选与切换条件 +│ 技术选型与调研报告.md +└─ 合规与安全方案 ★ ─────── 人脸/AI 标识/备案登记/内容审核/数据安全 + 合规与安全方案.md + +第四层｜谁来做、什么时候做 +└─ 开发任务拆解 ★ ───────── WBS、依赖关系、里程碑、验收条件 + 开发任务拆解.md +``` + +★ = 本轮新增文档 + +**文档清单（可点击）** + +| 层 | 文档 | 一句话 | +| --- | --- | --- | +| 1 | [产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md) | 总纲：定位、市场、商业模式、路线图 | +| 2 | [需求规格说明](./需求规格说明.md) ★ | 统一编号的需求与验收标准，开发测试的索引 | +| 2 | [美学报告-需求文档](./美学报告-需求文档.md) | 报告分级、触发时机、**32 项**诊断维度 | +| 2 | [穿搭 Agent-需求文档](./穿搭Agent-需求文档.md) | 对话能力、意图识别、能力联动 | +| 2 | [用户系统与记忆系统-需求文档](./用户系统与记忆系统-需求文档.md) | 账号与配额、L0~L5 分层记忆 | +| 2 | [美学知识库-建设方案](./美学知识库-建设方案.md) | 12 类知识、7 种模态、混合检索 | +| 3 | [技术架构文档](./技术架构文档.md) ★ | 分层架构、数据模型、关键链路、部署 | +| 3 | [技术选型与调研报告](./技术选型与调研报告.md) ★ | 31 项技术决策的结论、理由与切换条件 | +| 3 | [合规与安全方案](./合规与安全方案.md) ★ | 人脸、AI 标识、**备案后的持续义务**、审核、数据安全 | +| 4 | [开发任务拆解](./开发任务拆解.md) ★ | WBS、依赖图、六个里程碑、验收条件 | + +--- + +## 2. 按角色的阅读路径 + +| 角色 | 阅读顺序 | +| --- | --- | +| **新加入的工程师** | 产品方案 §1~§2（了解产品）→ 技术架构文档（全文）→ 技术选型报告（查为什么这么选）→ 开发任务拆解（找自己的任务）→ 对应模块的需求文档 | +| **前端/客户端** | 技术架构文档 §7 关键链路、§9 API 规范 → 需求规格说明（自己模块）→ 各需求文档的交互章节 | +| **后端** | 技术架构文档 §4 模块、§6 数据模型、§7 链路、§8 AI 层 → 需求规格说明 | +| **算法** | 技术选型报告 TD-04~TD-07、TD-22 → 技术架构文档 §8 → 美学报告需求文档 §4 诊断维度 → 知识库方案 §6 | +| **产品/设计** | 产品方案 → 需求规格说明 → 各需求文档 → 合规方案 §3 内容伦理红线 | +| **运营/内容（含形象顾问）** | 美学知识库-建设方案（全文）→ 美学报告需求文档 §4 → 需求规格说明 FR-KB/FR-ADM | +| **法务/合规** | 合规与安全方案（全文）→ 需求规格说明 §3 合规需求 | +| **管理者/评审** | 产品方案 → 需求规格说明 §5 V1 范围矩阵 → 开发任务拆解 §1 里程碑 + §9 风险提醒 | + +--- + +## 3. 快速查找 + +| 我想知道… | 去哪里 | +| --- | --- | +| **现在最该先做什么** | 本文 §0.2 | +| V1 到底做什么、不做什么 | 需求规格说明 §5 V1 范围矩阵 | +| V1 为什么不收费、怎么控成本 | 产品方案 §5.0 + §3.2 配额表；技术选型报告 `TD-28` | +| 备案完成后还要做什么 | 合规与安全方案 §2.2.0 四项持续义务 | +| 市场数据的出处 | 产品方案 §4.1（国家统计局 / CNNIC / 华为 HDC 2026） | +| 某个功能的验收标准 | 需求规格说明，按 `FR-xx` 查 | +| 为什么选 A 不选 B | 技术选型与调研报告，按 `TD-xx` 查 | +| 报告是怎么生成的 | 技术架构文档 §7.1 | +| Agent 怎么用知识库和画像 | 技术架构文档 §7.2、§8.3、§8.4 | +| 数据库有哪些表 | 技术架构文档 §6.2 | +| 接口规范与错误码 | 技术架构文档 §9 | +| 人脸数据怎么处理才合法 | 合规与安全方案 §2.1 | +| 上线前必须做完什么 | 合规与安全方案 §5 检查清单 | +| 我的任务依赖谁 | 开发任务拆解 §1 依赖图 + 各任务表的「依赖」列 | +| 报告触发时机的完整规则 | 美学报告-需求文档 §3 | +| 记忆分层与冲突消解规则 | 用户系统与记忆系统-需求文档 §3 | +| 知识库有哪些类目和模态 | 美学知识库-建设方案 §3、§4 | + +--- + +## 4. 编号体系 + +| 前缀 | 含义 | 定义位置 | +| --- | --- | --- | +| `FR-<模块>-<序号>` | 功能需求 | 需求规格说明 §2 | +| `NFR-<类别>-<序号>` | 非功能需求 | 需求规格说明 §4 | +| `CR-<序号>` | 合规需求（不可裁剪） | 需求规格说明 §3 | +| `TD-<序号>` | 技术决策 | 技术选型与调研报告 §1 | +| `ADR-<序号>` | 架构决策记录 | 技术架构文档 §18 | +| `T-P<阶段>-<序号>` | 开发任务 | 开发任务拆解 | +| `R-<域>-<序号>` | 知识库规则 ID | 美学知识库-建设方案 | + +**引用纪律**：跨文档引用一律用编号，不要复制内容。同一事实只在一处定义，其他地方引用——这是这套文档能长期维护的前提。 + +--- + +## 5. 术语表 + +| 术语 | 含义 | +| --- | --- | +| **画像** | 由报告产出的结构化诊断结论（体型、色彩季型、脸型等 **32** 个维度） | +| **记忆系统** | 分层存储用户身份、画像、偏好、事件、衣橱的系统，L0~L5 | +| **初级报告 / 全面报告** | 免费版（V1）/ 付费版（V2）的美学报告 | +| **诊断维度** | 报告输出的单个结论项，含 value + confidence + evidence + rule_hits | +| **硬约束 / 禁忌** | 规则库中 `is_hard=true` 的规则，生成结果绝不允许违反 | +| **tryon_ready** | 单品素材已具备换装所需的白底图与规格，可用于试穿 | +| **混合检索** | 硬过滤 + 规则命中 + 向量召回 + 关键词召回 + 重排的检索链路 | +| **黄金集** | 固定输入与期望输出的测试样本集，用于质量回归 | +| **统一合规出口** | 所有 AI 生成物对外发布前必经的模块（审核 + 水印 + 元数据标识 + 编号登记） | +| **配额** | **V1 的资源限制单位**（次数），可通过任务奖励获得，**不可购买**。V1 唯一的成本控制手段 | +| **点数** | **V2 的消耗单位**，可通过任务获取或购买。与配额共用同一张账本表，仅 `tx_type` 不同 | +| **预扣三段式** | reserve（冻结）→ commit（确认）/ refund（退还），保证长耗时任务不会「扣了额度未交付」 | +| **任务中心** | 承载全部长耗时任务的统一视图与状态机 | +| **内容编号** | AI 生成内容的 27 位唯一标识，写入文件元数据用于隐式标识 | +| **大模型登记** | 调用已备案第三方模型对外提供服务时，向属地网信办办理的登记。**本项目已完成**，转为编号公示与变更备案等持续义务 | +| **量感 / 直曲** | 形象顾问领域术语，分别指身体线条的体量感与曲直特征。对用户展示时必须配白话释义 | +| **色彩季型** | 基于肤色、发色、瞳色的冷暖/明度/纯度特征划分的用色类型（自建体系，不使用外部商标名称） | + +--- + +## 6. 文档维护规范 + +| 规则 | 说明 | +| --- | --- | +| 单一事实来源 | 同一信息只在一处定义，其余引用编号 | +| 变更留痕 | 修改需求或验收标准时，在文档末尾变更记录中登记日期与原因 | +| 版本号 | 结构性调整升主版本，内容补充升次版本 | +| 待确认事项 | 技术类结论统一收口在《技术选型与调研报告》§1 决策总表；仍需业务拍板的收口在该文 §7《待业务输入的事项》。各需求文档的「待确认事项」章节只保留结论摘要与编号引用，不再各自展开 | +| 冲突处理 | 发现文档间冲突时以「下层优先」原则处理，并同步修正上层文档 | +| 时效性标记 | 价格、厂商接口能力等易变信息标注 `⚠️ 时效性`，使用前复核 | + +--- + +## 7. 文档状态 + +| 类别 | 状态 | +| --- | --- | +| 产品需求 | 已定稿（V1 范围明确，见需求规格说明 §5） | +| 技术选型 | 已定稿（**31 项决策全部收口**，待业务输入仅剩 1 项） | +| 业务决策 | ✅ **已全部收口**（素材自采、顾问全职、V1 不收费、命理不做、市场数据信源） | +| 备案 | ✅ **已完成**，转为持续义务 | +| 技术架构 | 待技术评审 | +| 合规方案 | 待法务复核 | +| 任务拆解 | 待评审后进入执行 | + +**最紧急的三件事见 §0.2**（备案完成后已重排：模型清单核实 → 顾问到岗 → 自采流水线）。 + +--- + +## 8. 本轮（2026-08-13）文档更新摘要 + +九份文档全部更新，核心是三件事：**备案完成**、**V1 不收费**、**市场数据换成官方信源**。 + +| 文档 | 版本 | 主要变更 | +| --- | :---: | --- | +| [产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md) | v6.0 | §5.0 新增「V1 不收费只限量」；§3 权益拆为 V1 配额与 V2 规划；§4.1 市场数据全部换官方信源并纠正鸿蒙可触达口径；§8.1.1 用户目标下调且**以季度回访率替代 DAU**；§5.3 财务预期重写；备案风险关闭 | +| [需求规格说明](./需求规格说明.md) | v1.1 | BILL 域由「权益与计费」改为「配额与计量」，V1 移除全部支付；一键登录降级 V2；五行模块标记永久不做；§5.3 前置阻塞项状态重排 | +| [技术架构文档](./技术架构文档.md) | v1.1 | billing 域降级为配额与计量，`bl_point_tx`→`bl_ledger` 且新增 `tx_type` 使 V2 免迁移；§7.4 拆为 V1 配额与 V2 支付；成本模型补 V1 上限公式；风险登记重排 | +| [技术选型与调研报告](./技术选型与调研报告.md) | v1.1 | §7 由「待业务输入」改为「决策收口」，`TD-26`~`TD-31` 六项全部给出结论与理由；`TD-19` 备案已办结 | +| [合规与安全方案](./合规与安全方案.md) | v1.1 | 新增 §2.2.0 备案后四项持续义务；公示要求升为开发任务并加三条实现要求；检查清单标记已完成项 | +| [开发任务拆解](./开发任务拆解.md) | v1.1 | **关键路径转移**：备案申报任务关闭，内容与素材生产升为最优先；`T-P0-20`/`21` 要求输出每周产能用于倒排 | +| [美学知识库-建设方案](./美学知识库-建设方案.md) | v1.2 | 新增 §4.2.1 素材自采流水线（五工序 + 拍摄规范 + 降级路径）、§5.1.1 全职顾问工作流（四项职责按投入顺序） | +| [美学报告-需求文档](./美学报告-需求文档.md) | v1.2 | 五行模块整体移除（维度 34→32）；预约卡片不得展示价格，价格敏感度改用访谈采集 | +| [用户系统与记忆系统-需求文档](./用户系统与记忆系统-需求文档.md) | v1.2 | §2.4 重构为 V1 配额表 + V2 规划；一键登录降级；主表移除 `points_balance`；强化计量要求 | diff --git a/docs/合规与安全方案.md b/docs/合规与安全方案.md new file mode 100644 index 0000000..000034b --- /dev/null +++ b/docs/合规与安全方案.md @@ -0,0 +1,428 @@ +# 「美搭」合规与安全方案 + +> 版本：v1.0　｜　更新日期：2026-08-13　｜　状态：待法务/合规复核 +> +> **为什么这份文档单独存在**：本产品同时踩在三条监管线上——处理**人脸信息**（敏感个人信息）、提供**生成式 AI 服务**、产出**AI 生成合成内容**。这三条线各自有独立的法定义务，把它们混在技术文档里会被当成技术细节忽略，所以单独成文。 +> +> **状态提示（2026-08-13）**：三条主线中，主线二（生成式 AI 服务备案）**已办结** —— 原本 2~4 个月的审批周期不再是上线瓶颈。但备案完成不等于合规完成：**主线一（人脸）与主线三（AI 标识）的义务全部是工程实现要求，一项都没有减少**，且备案本身还留下四项持续义务（见 §2.2.0）。这份文档的价值不因备案完成而下降。 +> +> **本文不是法律意见**。所列条款为公开法规的工程化解读，正式上线前应经法务确认，并与属地网信部门核实具体材料要求（各地执行标准不一致）。 + +--- + +## 1. 适用法规清单 + +| 法规 | 施行时间 | 与本产品的关系 | +| --- | --- | --- | +| 《个人信息保护法》 | 2021-11-01 | 全部个人信息处理活动的基础法 | +| 《人脸识别技术应用安全管理办法》（网信办、公安部令第 19 号） | **2025-06-01** | 拍照分析涉及人脸信息处理 | +| 《生成式人工智能服务管理暂行办法》 | 2023-08-15 | 报告文案、Agent 对话属生成式 AI 服务 | +| 《互联网信息服务算法推荐管理规定》 | 2022-03-01 | 个性化推荐 + 算法备案义务 | +| 《互联网信息服务深度合成管理规定》 | 2023-01-10 | 换装/发型属深度合成，含标识与日志义务 | +| 《人工智能生成合成内容标识办法》（四部门） | **2025-09-01** | 全部 AI 产出物的标识义务 | +| GB 45438-2025《网络安全技术 人工智能生成合成内容标识方法》 | 配套国标 | 隐式标识的技术实现依据 | +| 《未成年人网络保护条例》 | 2024-01-01 | 年龄识别与功能限制 | +| 《网络安全法》《数据安全法》 | — | 安全等级保护与数据分类分级 | +| 《广告法》 | — | 效果宣传不得绝对化 | + +--- + +## 2. 三条主线的义务与落地 + +### 2.1 主线一：人脸信息处理 + +#### 2.1.1 法定义务 + +| 义务 | 条款要点 | 我们的做法 | +| --- | --- | --- | +| **单独同意** | 处理敏感个人信息须取得单独同意，不得与其他授权捆绑 | 独立的人脸授权页，单独勾选与确认。拒绝后仍可用问卷降级路径（`FR-RPT-11`） | +| **告知义务** | 告知处理目的、方式、保存期限、影响 | 授权页明示：仅用于生成你的形象报告；分析后立即删除原图；不用于识别身份；不共享给第三方用于其他目的 | +| **最小必要** | 不得超出必要范围收集 | 只要一张正面照 + 可选全身照；不采集身份证、不做人脸比对与身份识别 | +| **不得强制** | 不得以人脸作为唯一验证方式 | 登录不用人脸；人脸仅用于报告功能 | +| **PIA 评估** | 需开展个人信息保护影响评估并留存 | 上线前完成 PIA 报告（`CR-10`） | +| **备案** | 存储人脸信息达 **10 万人**时，自达到之日起 30 个工作日内向省级以上网信部门备案（线上系统 `grxxbh.cacdtsc.cn`） | **架构上规避**：见下 | +| 变更/终止 | 备案信息实质变更或终止应用，30 个工作日内变更或注销备案 | 纳入合规运维清单 | + +#### 2.1.2 「原图不落盘」的完整设计 + +这是本产品最重要的一个合规设计决策：**通过架构使「存储的人脸信息数量」恒为 0**，从而不触发 10 万人备案阈值，同时把数据泄露的风险面降到最小。 + +``` +用户拍照 + │ ① 客户端压缩（不上传原始大图） + ▼ +② 预签名直传 → COS 临时桶 cos://meida-temp/ + │ · 桶级生命周期：2 小时自动删除（兜底） + │ · 服务端加密（SSE） + │ · 私有权限，仅预签名访问 + ▼ +③ Worker 拉取 → 内存中处理 + │ · 内容审核 + │ · 分割 / 关键点 / 属性 / 色值采样 + │ · 体型与季型测算 + ▼ +④ 输出**派生特征**（不可反推人脸） + │ 例：{"skin_lab":[68.2,12.4,18.7], "body_shape":"X", "face_shape":"椭圆"} + ▼ +⑤ **显式删除临时对象**（不等生命周期） + ▼ +⑥ 落库：仅派生特征 + 图片元信息（尺寸、时间、质量评分） +``` + +**明确的红线**： + +| 禁止 | 原因 | +| --- | --- | +| 将人脸原图写入用户内容桶或数据库 | 会形成人脸信息存储，触发备案义务与更高安全要求 | +| 存储人脸特征向量（faceprint/embedding） | 属可用于识别特定自然人的生物识别信息，风险等级等同原图 | +| 存储 888 点稠密关键点原始坐标 | 精度足以重建面部轮廓，视为生物识别信息。只保留**归一化比例与分类结论** | +| 在日志、监控、错误上报中打印图片 URL 或人脸数据 | 日志系统的访问控制通常弱于业务库 | +| 将人脸数据传给未签署数据处理协议的第三方 | 需有委托处理协议与安全评估 | + +**换装结果图的定性**：结果图包含用户面部，属个人信息，但它是**用户主动生成并选择保存的内容**，存于用户内容桶，随账号注销删除，用户可随时单独删除。它不进入「用于人脸识别技术的人脸信息存储」范畴，但仍需私有桶 + 签名访问 + 防盗链保护。 + +#### 2.1.3 第三方处理者管理 + +人脸数据会传给腾讯云（分割、人脸属性与关键点）与自有换装服务： + +| 接收方 | 数据 | 要求 | +| --- | --- | --- | +| 腾讯云人脸识别/人体分析 | 照片（API 调用） | 签署云服务协议与数据处理条款；在隐私政策中披露；确认其不留存 | +| 自有换装服务 | 照片 + 单品图 | 内网隔离；处理后不留存原图；纳入同一套安全要求 | +| 大模型服务商 | **不传人脸图片** | 只传派生的结构化特征与文本，图片不出我们的边界（V2 图片理解功能需重新评估并单独告知） | + +**隐私政策中必须有一张「第三方共享清单」**，列明接收方、数据类型、目的、方式。这是上架审核会查的项。 + +### 2.2 主线二：生成式 AI 服务备案（✅ 已完成，转为持续义务） + +> **状态更新（2026-08-13）**：**备案已办结**。原本 2~4 个月的外部审批周期不再是上线瓶颈，本节的重心从「如何办下来」转为「**办下来之后要持续做什么**」。 +> +> #### 2.2.0 备案完成后的四项持续义务 +> +> | # | 义务 | 具体要求 | 落点 | +> |---|------|---------|------| +> | 1 | **编号界面公示** | 在 App 显著位置公示模型名称与备案编号 | §2.2.4，`CR-08` | +> | 2 | **备案范围与实际调用一致** | ⚠️ **最需要核实的一条**。实际调用的模型清单必须与备案登记的一致 | 见下方风险提示 | +> | 3 | **变更备案** | 新增模型、变更服务功能或算法机制后，**30 个工作日内**办理变更 | §6 持续合规运维 | +> | 4 | **材料维护** | 安全自评估报告、拦截关键词库、评估测试题集、测试通道与虚拟账号需持续可用 | §2.2.2、§6 | +> +> ⚠️ **唯一的开放风险 —— 备案覆盖的模型清单** +> +> 架构上选定的是 **DeepSeek 主 + 智谱 GLM 备/视觉** 的双路由方案（`TD-04`）。**如果备案登记时只申报了其中一家，上线双路由即属超范围提供服务。** +> +> 处理方式（按优先顺序）： +> 1. 核实备案材料中申报的模型清单 +> 2. 若已覆盖两家 → 无需动作 +> 3. 若只覆盖一家 → **V1 先只启用已登记的那一家**，同时启动变更备案。LLM 网关已做多路由抽象（§8.1），切换是配置级改动，不影响排期 +> +> **不建议靠推测处理**：超范围提供服务的后果远大于少用一个备用模型带来的可用性损失。 + +#### 2.2.1 路径判定（保留，作为变更备案的判定依据） + +``` +我们是否自研或微调模型？── 否（仅调用 DeepSeek/GLM 官方 API） + │ + ▼ + 不需要「大模型备案」 + │ + ▼ + 面向境内公众提供，具舆论属性或社会动员能力？── 是 + │ + ▼ + 需要：① 大模型登记（属地网信办）✅ 已完成 + ② 算法备案（beian.cac.gov.cn）✅ 已完成 + ③ 安全自评估 ✅ 已完成 +``` + +#### 2.2.2 材料清单（已提交，但需持续维护 —— 变更备案时会再次用到） + +| 材料 | 责任方 | 提前量 | 备注 | +| --- | --- | --- | --- | +| 安全自评估报告 | 合规 + 技术 | 早 | 参照《生成式人工智能服务安全基本要求》 | +| 调用已备案大模型的情况说明 + 证明材料 | 商务 + 技术 | 早 | **需模型厂商侧的备案号与配合证明** | +| 与算法技术主体的合作协议 | 商务 | 早 | ⚠️ 若通过云厂商 MaaS 平台中转调用，云厂商**无法代第三方模型厂商出具并盖章**。**因此直接使用 DeepSeek / 智谱官方 API**，便于获取材料 | +| 产品服务协议、隐私政策 | 法务 | 早 | 需体现 AI 生成告知 | +| 内容安全管理制度 | 合规 | 中 | 审核流程、人工复核、应急处置 | +| **拦截关键词库** | 技术 + 合规 | 中 | 部分地区要求万级规模 | +| 评估测试题集 | 技术 + 合规 | 中 | 用于验证拒答与安全能力 | +| API 接口信息 + 虚拟测试账号 | 技术 | 中 | **需提供「附加审核策略」与「不附加审核策略」两种测试通道** | +| 算法安全自评估、算法机制机理说明 | 技术 | 中 | 算法备案用 | + +#### 2.2.3 ~~时间线~~ → 已完成，不再影响项目节奏 + +原时间线（T+0 沟通 → T+1 提交 → T+3~4 取得编号 → T+4 上架）**已走完**。 + +**这对项目意味着什么**：原本"备案 4 个月 vs 开发 3 个月"的并行关系不再存在，**开发进度现在就是上线进度**。项目的关键路径转移到内部工序，其中最长的是**素材自采与规则库生产**（`TD-26`、`TD-27`）—— 这是唯一无法靠 AI 辅助开发压缩的部分。 + +**变更备案的时间线（将来可能用到）**：实质变更后须在 **30 个工作日内**办理。因此若 V2 计划新增模型，应在开发启动时同步提交变更申请，而非等功能完成。 + +#### 2.2.4 公示要求（**现在是必须落地的开发任务，不再是待办材料**） + +浙江、江苏、安徽、陕西等地明确要求：已上线的生成式 AI 应用需在**界面显著位置**注明模型名称、备案号及服务情况。应用市场上架时也会核验。 + +**产品落地**：在「设置 → 关于」页面固定展示（编号已取得，可直接填入）： +``` +本应用的 AI 能力由 <模型名称> 提供 +大模型登记号 / 算法备案号：<编号> +AI 生成内容仅供参考，不构成专业建议 +``` + +**三条实现要求**： +- 公示位在端上是**硬编码的固定入口**，不走服务端配置下发 —— 避免配置异常导致公示消失 +- 编号内容可服务端下发（便于变更备案后更新），但**入口本身不可隐藏** +- 若展示的模型名称与实际调用不一致，等同于未公示。因此**公示文案必须与 LLM 网关的实际路由配置同源**，不允许两处各自维护 + +### 2.3 主线三：AI 生成内容标识 + +#### 2.3.1 覆盖对象 + +| 产物 | 类型 | 显式标识 | 隐式标识 | +| --- | --- | --- | --- | +| 换装结果图 | 图片 | 画面内可见「AI 生成」 | EXIF/XMP 元数据 | +| 发型效果图 | 图片 | 同上 | 同上 | +| 报告长图 | 图片 | 首屏与分享图均标识 | 同上 | +| 报告 PDF | 文档 | 页内标识 | 文档元数据 | +| Agent 回复 | 文本 | 会话界面固定提示 | 交互场景以界面提示为主 | +| 报告文案 | 文本 | 报告内提示 | 随长图元数据 | + +#### 2.3.2 隐式标识的字段要求 + +按办法第五条，文件元数据中需包含： + +| 字段 | 内容 | +| --- | --- | +| 生成合成内容属性信息 | 标明为 AI 生成合成内容（属性标签：明确/可能/疑似） | +| 服务提供者名称或编码 | 按《服务提供者编码规则》实践指南取得/生成 | +| 内容编号 | **27 位数字或大写字母**，全局唯一，登记入 `cp_content_registry` | + +内容编号生成方案（需与国标编码规则最终核对）： + +``` +27 位 = 服务提供者编码段 + 时间段 + 序列段（Base32 大写字母与数字，无易混字符） +生成即登记，可反查：内容编号 → 生成时间、模型、场景、关联业务 ID +``` + +#### 2.3.3 最容易踩的坑：元数据被剥离 + +**这是本项目在合规上最可能出问题的地方**，因为它不会报错，只会静默失效： + +| 环节 | 风险 | 必须验证 | +| --- | --- | --- | +| CDN 图片处理 | 缩放/压缩/格式转换常剥离 EXIF/XMP | 关闭图片处理的元数据剥离，或对原图与派生图分别处理 | +| 客户端保存到相册 | 系统相册可能重编码 | 保存后读回验证元数据 | +| 用户分享到第三方平台 | 平台会重编码，元数据必失 | 无法控制，但**显式水印必须保留在画面内**——这就是为什么显式标识不能只做界面提示 | +| 服务端二次处理（加水印） | 处理库默认丢弃元数据 | 水印与元数据写入必须在**同一个处理步骤的末尾**完成 | + +**验收要求（`CR-05`）**：编写一个自动化测试，覆盖「生成 → 加水印 → 上传 COS → CDN 分发 → 客户端下载 → 保存相册 → 读回」全链路，断言元数据字段存在。 + +#### 2.3.4 显式标识的设计要求 + +不只是「加个水印」这么简单，要考虑被规避的情况： + +- 位置：不放在图片边缘（容易被裁掉），放在画面内相对固定的安全区 +- 对比度：保证在任意背景上可辨识 +- 分享图：分享用的长图/卡片必须**独立确认**标识存在（这是最容易漏的路径） +- **V1 不提供「去除显式标识」的功能**——办法允许用户申请去除，但需签订协议并留存日志至少 6 个月，额外增加义务，V1 不值得 + +### 2.4 内容审核 + +#### 2.4.1 审核矩阵 + +| 对象 | 时机 | 工具 | 失败处理 | +| --- | --- | --- | --- | +| 用户上传照片 | 分析前 | 腾讯云 IMS | 拒绝并提示，不消耗点数 | +| 换装/发型结果图 | 返回前 | IMS | 拦截，任务标记失败并退点 | +| 用户对话输入 | 送 LLM 前 | 腾讯云 TMS + 自有关键词库 | 返回安全提示，记录日志 | +| LLM 输出 | 返回前 | TMS | 重新生成（最多 2 次）或返回兜底话术 | +| 报告文案与长图 | 发布前 | TMS + IMS | 降级为模板文案 | +| 运营录入的知识内容 | 发布前 | 机审 + 人工双轨 | 打回修改 | +| 用户昵称、头像 | 保存时 | TMS + IMS | 拒绝保存 | + +#### 2.4.2 fail-close 原则 + +**审核服务不可用时，一律按「拦截」处理。** 这与其他外部依赖的 fail-soft 策略相反，是有意为之：漏审一条违规内容的代价（下架、处罚）远高于短时间功能不可用。 + +实现要求：审核调用失败要与「审核判定为违规」区分记录，前者告警（需要运维介入），后者是正常业务流。 + +#### 2.4.3 关键词库 + +- 来源：备案要求的拦截词库 + 行业通用敏感词 + 本产品特有边界词（医疗、命理、身材贬损、他人评价） +- 承载：腾讯云 TMS 自定义关键词库（单次最多 2000 个，需分批维护）+ 本地词库兜底 +- 维护：后台可维护，变更留审计；命中记录留存 + +### 2.5 未成年人保护 + +| 要求 | 落地 | +| --- | --- | +| 年龄判定 | 注册时采集年龄段；华为账号提供未成年人模式信号时优先采用 | +| 功能限制 | 未成年账号：禁用付费、禁用外观评价类内容、报告表述更保守 | +| 监护提示 | 明确提示需监护人知情同意 | +| 内容分级 | 涉及身材、体型的表述对未成年人使用更谨慎的措辞 | + +--- + +## 3. 内容伦理红线（产品自律，高于法规） + +这类产品最容易造成的伤害不是数据泄露，而是**对用户外观的评判造成心理伤害**。以下是写进 Prompt 与规则库的硬约束： + +| 红线 | 反例（禁止） | 正例（要求） | +| --- | --- | --- | +| 描述而非评判 | 「你的脸型有点大，不好看」 | 「你的脸型轮廓偏圆润，适合有一定纵向线条的发型来延展视觉比例」 | +| 不使用缺陷框架 | 「腿短是你的缺点」 | 「上下身比例接近 1:1.2，通过提高腰线可以让腿部比例视觉上更修长」 | +| 不做医疗判断 | 「你的皮肤有问题，建议就医」「你需要减肥」 | 不涉及。转向穿搭与色彩建议 | +| 不做绝对化承诺 | 「按这个搭配一定显瘦 10 斤」 | 「这个搭配有助于视觉上拉长身形」 | +| 不评价他人 | 对用户上传的他人照片做评价 | 拒答并说明只服务本人形象 | +| 不做身份推断 | 推断收入、职业层级、地域并据此差异化表述 | 不做 | +| 尊重多样性 | 暗示某种体型/肤色更优 | 每种特征都给出正向的搭配路径 | + +**技术落点**：这些约束同时写入三处，缺一处就会漏——① 系统 Prompt；② 规则库的硬约束（禁忌用词表）；③ 生成后校验（贬损词检测）。 + +--- + +## 4. 数据安全 + +### 4.1 数据分类分级 + +| 级别 | 数据 | 存储要求 | 访问要求 | +| --- | --- | --- | --- | +| **L4 敏感个人信息** | 人脸原图 | **不持久化**（临时桶 ≤ 2h） | 仅 Worker 进程内，预签名短期 | +| **L3 重要个人信息** | 诊断结论、体型/季型标签、结果图 | 加密存储，私有桶 | 严格归属校验，日志脱敏 | +| **L2 一般个人信息** | 昵称、头像、UnionID、设备信息 | 常规加密 | 归属校验 | +| **L1 业务数据** | 知识库、规则、色板 | 常规 | 后台权限 | +| **L0 公开** | 产品配置、文案 | — | — | + +### 4.2 安全措施清单 + +| 领域 | 措施 | +| --- | --- | +| 传输 | 全链路 HTTPS/TLS 1.2+；证书自动续期 | +| 存储 | COS 服务端加密；数据库敏感字段加密；备份加密 | +| 密钥 | SSM/KMS 集中管理；禁止进代码、镜像、明文环境变量；定期轮换 | +| 访问控制 | 最小权限；后台独立账号体系与网段；生产数据库禁止直连（走跳板与审计） | +| 越权防护 | 所有资源访问校验 `user_id` 归属；越权用例进自动化测试 | +| 日志 | 脱敏中间件（手机号、UnionID、图片地址、诊断结论）；审计日志独立留存 ≥ 6 个月 | +| 图片访问 | 私有桶 + 短期签名 URL + CDN 防盗链 + Referer 校验 | +| 防刷 | 设备指纹、频控、异常注册识别、点数消耗 | +| Prompt 注入 | 用户内容与系统指令严格分区；输出侧校验；用户内容不得触发工具调用决策 | +| 漏洞管理 | 依赖漏洞扫描进 CI；密钥泄露扫描 pre-commit | +| 应急 | 数据泄露应急预案 + 联系人 + 上报流程（法定 72 小时内通知义务） | + +### 4.3 数据生命周期 + +| 数据 | 保留期 | 删除触发 | +| --- | --- | --- | +| 人脸原图 | ≤ 2 小时（实际处理完即删） | 处理完成 / 桶生命周期 | +| 报告与诊断结论 | 账号存续期间 | 用户删除 / 注销后 7 日内 | +| 换装结果图 | 账号存续期间 | 用户删除 / 注销后 7 日内 | +| 对话原文 | 90 天 | 到期自动清理 | +| 对话摘要（L3/L4 记忆） | 180 天 | 到期或用户删除 | +| 审核日志、生成记录 | ≥ 6 个月（法定） | 到期归档 | +| 埋点事件 | 12 个月 | 分区滚动删除 | +| 审计日志 | 24 个月 | — | + +**注销的删除必须是真删除**：包括数据库记录、COS 对象、缓存、备份中的可识别数据（备份按周期自然滚动，需在隐私政策中说明备份滚动周期）。删除任务本身要有执行记录以证明履行义务（`FR-ACC-09`）。 + +--- + +## 5. 上线前合规检查清单 + +> 这份清单是上线的门禁。每一项都要有责任人和证据。 + +### 5.1 资质与备案 + +- [x] 企业主体资质、ICP 备案 +- [x] **大模型登记号取得** +- [x] **算法备案号取得** +- [x] 安全自评估报告归档 +- [x] 与模型厂商的合作证明材料齐备 +- [ ] ⚠️ **核实备案覆盖的模型清单是否含 DeepSeek + 智谱 GLM 两家**（见 §2.2.0，唯一开放项） +- [ ] **界面显著位置公示模型名称与编号**（编号已取得，待端上实现，见 §2.2.4） +- [ ] 公示文案与 LLM 网关实际路由配置同源校验 +- [ ] ~~华为企业开发者认证~~ —— **V1 不需要**：不接 IAP，一键登录降级 V2（`TD-29`） + +### 5.2 文档与协议 + +- [ ] 用户协议（含 AI 生成告知、免责边界） +- [ ] 隐私政策（含第三方共享清单、数据保留期、用户权利行使方式） +- [ ] 人脸信息单独同意文案 +- [ ] 未成年人保护声明 +- [ ] PIA 个人信息保护影响评估报告 +- [ ] 内容安全管理制度 +- [ ] 数据泄露应急预案 + +### 5.3 功能验证 + +- [ ] 人脸原图处理后确实删除（抽查临时桶无残留） +- [ ] 人脸单独同意为独立页面，拒绝后降级路径可用 +- [ ] 所有生成物含显式标识（含分享图路径） +- [ ] 隐式元数据全链路存活测试通过（CDN → 客户端 → 相册） +- [ ] 输入输出双向审核全部生效 +- [ ] 审核服务不可用时 fail-close 生效 +- [ ] 关键词拦截库生效并可维护 +- [ ] 未成年账号功能限制生效 +- [ ] 注销流程 7 日内彻底删除，且有执行记录 +- [ ] 越权访问测试全部拦截 +- [ ] 日志中无敏感信息（人工抽查 + 自动扫描） +- [ ] 越界问题（医疗/命理/他人评价）拒答测试通过 —— **命理模块已决定不做（`TD-31`），但对话侧仍须拒答** +- [ ] 贬损性表述检测生效（用负面样本集验证） +- [ ] 备案编号公示位在发布包中可见且内容正确 +- [ ] ~~支付与交易类合规项~~ —— **V1 不涉及**（无 IAP、无订单、无退款，`TD-28`） + +### 5.4 运营准备 + +- [ ] 人工复核值班机制（审核申诉处理） +- [ ] 用户投诉与个人信息权利请求受理渠道 +- [ ] 合规运维日历（备案变更、协议版本更新、日志归档） + +--- + +## 6. 持续合规运维 + +> **备案完成后，本节从"将来要做的事"变成"现在就要执行的事"** —— 这是备案完成带来的责任转移，容易被忽略。 + +| 事项 | 频率 | 责任 | +| --- | --- | --- | +| **备案信息实质变更后办理变更** | 变更后 **30 个工作日内** | 合规 | +| **备案范围与实际调用模型的一致性核对** | **每次发版前** | 技术 + 合规 | +| **公示编号与模型名称的正确性检查**（含发布包实机验证） | 每次发版前 | 技术 | +| 人脸信息存储量监控（若策略变更导致开始存储） | 月度 | 技术 | +| 关键词库更新 | 月度 | 合规 | +| 审核准确率抽检（误杀与漏放） | 月度 | 运营 | +| 隐私政策与协议版本复审 | 季度 | 法务 | +| 法规跟踪（新规与征求意见稿） | 季度 | 合规 | +| 数据删除任务执行审计 | 季度 | 技术 | +| 备份恢复演练 | 半年 | 技术 | +| 安全渗透测试 | 年度 | 技术 | + +**特别关注的立法动向**：《人工智能拟人化互动服务管理暂行办法》已进入公开征求意见阶段，其中包含分发平台核验义务与算法备案年度复审要求。本产品的 Agent 具备拟人化互动特征，若该办法正式施行，需重新评估适用性。 + +--- + +## 7. 与其他文档的对应 + +| 本文内容 | 对应 | +| --- | --- | +| 全部义务的需求化 | 《需求规格说明》CR-01 ~ CR-12 | +| 原图不落盘的工程实现 | 《技术架构文档》§7.1、§11.2 | +| 统一合规出口 | 《技术架构文档》§7.5 | +| 备案时间线对项目的影响 | 《开发任务拆解》Phase 0 | +| 内容伦理红线的规则落地 | 《美学知识库-建设方案》规则库 + 《美学报告-需求文档》§9 | + +--- + +## 相关文档 + +- [文档索引](./README.md) +- [需求规格说明](./需求规格说明.md)（本文义务对应 `CR-01`~`CR-12`，不可裁剪、不可降级） +- [技术架构文档](./技术架构文档.md)（§7.5 统一合规出口、§11 安全设计） +- [技术选型与调研报告](./技术选型与调研报告.md)（§5 合规与法务，含选型对备案的影响） +- [开发任务拆解](./开发任务拆解.md)（Phase 0 为备案与合规前置阶段） + +--- + +## 变更记录 + +| 日期 | 版本 | 变更 | +| --- | --- | --- | +| 2026-08-13 | v1.1 | **主线二状态更新为「备案已完成」**。新增 §2.2.0「备案完成后的四项持续义务」（编号公示、备案范围与实际调用一致、变更备案 30 工作日、材料维护），并标出唯一开放风险 —— 备案覆盖的模型清单是否含 DeepSeek + GLM 两家，若只含一家则双路由属超范围。§2.2.3 时间线改为已完成说明，指出关键路径已转移到素材与规则库生产。§2.2.4 公示要求从"待办材料"升为"必须落地的开发任务"，补充三条实现要求（入口硬编码、编号可下发、文案与网关路由同源）。§5.1 检查清单标记已完成项，移除华为企业开发者认证（V1 不需要）；§5.3 移除支付类合规项 | +| 2026-08-13 | v1.0 | 首次输出。确立三条主线：① 人脸原图不落盘以规避 10 万人备案阈值；② 大模型登记 + 算法备案须在 Phase 0 启动（周期 2~4 个月）；③ AI 生成内容显式 + 隐式双重标识，经统一合规出口收口 | diff --git a/docs/开发任务拆解.md b/docs/开发任务拆解.md new file mode 100644 index 0000000..b679366 --- /dev/null +++ b/docs/开发任务拆解.md @@ -0,0 +1,418 @@ +# 「美搭」开发任务拆解（WBS） + +> 版本：v1.0　｜　更新日期：2026-08-13　｜　状态：待评审 +> +> **本文的定位**：把需求与架构翻译成可指派、可验收的任务清单，并明确任务之间的依赖与关键路径。 +> +> **拆解原则**： +> 1. **按依赖排序，不按人日估算**。项目以 AI 辅助开发为主，人日估算意义不大；真正决定节奏的是任务依赖与外部审批周期。 +> 2. **每个任务都有交付物与验收标准**，不写「优化 XX」「完善 XX」这类无法判定完成的任务。 +> 3. **验证型任务（Spike）单独标注**，它们的产出是结论与数据，不是功能。 +> 4. **地基优先**。任务中心、合规出口、LLM 网关、配额三段式是被所有业务功能依赖的地基，必须先于业务功能完成，否则后面每个功能都要返工。 +> 5. 每个任务标注关联的需求编号（`FR-xx`/`CR-xx`），便于反查覆盖率。 + +**任务编号**：`T-<阶段>-<序号>`　　**类型**：`SPIKE`（验证）/ `DEV`（开发）/ `DATA`（数据生产）/ `OPS`（运维）/ `BIZ`（业务与资质） + +--- + +## 1. 里程碑总览 + +| 里程碑 | 名称 | 完成标志 | 阻塞关系 | +| --- | --- | --- | --- | +| **M0** | 前置验证与内容启动 | 六项技术验证有结论；**顾问到岗 + 自采流水线跑通**（备案已完成） | **内容与素材生产是新的关键路径** | +| **M1** | 工程地基可用 | 骨架跑通：登录 → 上传 → 提交任务 → 查状态 → 拿到带标识的产物 | 阻塞所有业务功能 | +| **M2** | 知识库可运营 | 顾问能在后台独立录入规则与素材并发布，检索链路返回可解释结果 | 阻塞报告与 Agent 的质量 | +| **M3** | 报告闭环打通 | 用户能完整走通初级报告并产出画像与记忆 | 阻塞 Agent 与换装的个性化 | +| **M4** | 三大功能闭环 | 报告 + Agent + 换装/发型均可用且互相联动 | — | +| **M5** | 上线就绪 | 合规检查清单全绿、压测通过、监控齐备、**备案编号公示位实机验证通过** | 依赖 M0 的编号公示实现 | +| **M6** | V2 能力 | 全面报告付费、IAP 接入、衣橱、多端评估 | **依赖 V1 的成本与频次数据** | + +### 依赖关系图 + +``` +M0 前置验证与内容启动 + ├─ ✅ 备案（已完成）── 仅剩编号公示实现 + 模型清单核实 + ├─ 技术验证（体型/色彩/抠图/换装成本/端骨架/AI标识） + └─ 🔴 内容与素材生产启动 ─────────────────────────────┐ + ├─ 全职顾问到岗 ──────────────────┐ │ + └─ 自采流水线跑通 ────────────┐ │ │ + │ │ │ +M1 工程地基 │ │ │ + ├─ 仓库与 CI │ │ │ + ├─ 账号与会话 │ │ │ + ├─ 任务中心 │ │ │ + ├─ 统一合规出口 │ │ │ + ├─ LLM 网关 │ │ │ + ├─ 配额账本（无支付） │ │ │ + └─ 端侧骨架 │ │ │ + │ │ │ │ + ├──────────────┬────────────┼───┼──────┐ │ + ▼ ▼ ▼ ▼ ▼ │ +M2 知识库 M3 报告闭环 M4 换装/发型 │ + ├─ 本体与色板 ├─ 视觉分析 ├─ 换装服务改造 │ + ├─ 规则引擎 ◀────┤ 诊断生成 ├─ 素材入库 ◀───┘ + ├─ 混合检索 ├─ 文案生成 └─ 发型打标与推荐 + ├─ 素材入库 ├─ 长图渲染 + └─ 极简后台 └─ 记忆写入 + │ │ │ + └──────────────┴──────────────┘ + ▼ + M4 Agent 对话 + ▼ + M5 上线就绪 + ▼ + M6 V2（含 IAP 与付费报告） +``` + +**关键路径已经改变（这是本轮最重要的变化）**： + +| | 原关键路径 | 现关键路径 | +|---|-----------|-----------| +| 主导因素 | **备案登记（外部审批 2~4 月）** | **内容与素材生产（内部产能）** | +| 能否压缩 | 不能，只能等 | 能，但只能靠增加人手/棚时，**不能靠 AI 加速** | +| 风险性质 | 时间确定、结果不确定 | 时间取决于产能、结果可控 | + +现在的关键路径是 `顾问到岗 + 自采流水线` → `M2 知识库` → `M3 报告` → `M4 Agent` → `M5 上架`。 + +**这个转变的实际含义**：过去"开发快了也没用，反正要等备案"，现在**每一天的开发进度都直接兑现为上线时间**。同时，`T-P0-20`（顾问招聘）与 `T-P0-21`（自采流水线）成为全项目最该优先启动的两个任务 —— 它们不产出代码，却决定了 M2 之后的全部节奏。 + +--- + +## 2. Phase 0：前置验证与资质（M0） + +> 这一阶段的任务大部分不产出代码，但决定项目能否成立。**不要因为「想早点看到界面」而跳过它。** + +### 2.1 资质与备案（✅ 备案已完成，本节大幅瘦身） + +> **备案已办结**，原 `T-P0-01`~`T-P0-08` 中的申报类任务全部关闭。剩下的是**备案完成后的落地与核实任务** —— 这些容易被"备案搞定了"的心态忽略，但它们同样是上架核验项。 + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| **T-P0-01** | **BIZ** | ⚠️ **核实备案覆盖的模型清单** | 核实结论 | 明确备案是否含 DeepSeek + 智谱 GLM 两家。**若只含一家，输出处置方案**（办变更 or V1 单路由） | TD-19、TD-04 | +| T-P0-02 | BIZ | 归集备案编号与全套材料，建立合规档案 | 合规档案 | 登记号、备案号、自评估报告、合作证明可随时调取 | CR-08 | +| T-P0-03 | DEV | **端上备案编号公示位实现** | 「设置→关于」页 | 编号与模型名称显著展示；入口硬编码不可隐藏；**发布包实机验证通过** | CR-08、合规方案 §2.2.4 | +| T-P0-04 | DEV | 公示文案与 LLM 网关路由配置同源校验 | 校验机制 | 展示的模型名称与实际调用一致；不一致时 CI 或启动自检告警 | CR-08 | +| T-P0-05 | BIZ | 编写用户协议、隐私政策、人脸单独同意文案 | 三份文档 | 含第三方共享清单、保留期、权利行使方式。**V1 无支付，不含交易与退款条款** | CR-09 | +| T-P0-06 | BIZ | 完成 PIA 个人信息保护影响评估 | PIA 报告 | 归档（处理敏感个人信息的独立法定要求，与备案无关） | CR-10 | +| T-P0-07 | BIZ | 关键词拦截库导入与内容安全管理制度落地 | 制度 + 词库 | 词库可导入 TMS 并生效 | CR-06、CR-07 | +| T-P0-08 | OPS | 保留监管抽查用测试通道与虚拟测试账号 | staging 通道 | 提供「附加审核策略」与「不附加审核策略」两种 | TD-19 | +| ~~T-P0-09~~ | — | ~~补齐市场数据信源~~ | ✅ **已完成** | 已替换为国家统计局 / CNNIC / 华为 HDC 官方数据 | TD-30 | + +### 2.2 技术验证（Spike，产出结论与数据） + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P0-10 | SPIKE | **体型测算方案验证**（掩膜宽度剖面法） | 验证报告 + 参数基线 | 30~50 样本与人工标注一致率 ≥ 80%；低置信度可识别 | FR-RPT-05、TD-06 | +| T-P0-11 | SPIKE | **色彩季型判定验证**（Lab 采样 + 规则） | 验证报告 + 色板初版 | 与人工判定一致率 ≥ 75% | FR-RPT-05、TD-18 | +| T-P0-12 | SPIKE | **抠图流水线验证**（BiRefNet） | 10 件样本全流程产物 | 抠图人工质检通过 ≥ 90%，换装可用 | FR-KB-08、TD-07 | +| T-P0-13 | SPIKE | **换装接口能力与成本实测**（三工作流） | 成本与成功率报告 | 得到单次 `gpu_seconds` 与成功率基线，填入成本模型 | FR-TRY-01 | +| T-P0-14 | SPIKE | **发型接口能力实测** | 报告 | 发型列表/更换/发色可用性与耗时基线 | FR-HAIR-01 | +| T-P0-15 | SPIKE | 腾讯云人脸能力验证（属性/90 点/888 点） | 报告 | 确认字段可用性、耗时、单价 | TD-05 | +| T-P0-16 | SPIKE | RTMPose ONNX 部署验证 | 可运行服务 + 基准 | CPU 单张推理耗时可接受，关键点稳定 | TD-05 | +| T-P0-17 | SPIKE | 鸿蒙端骨架验证（ArkTS） | 可运行 Demo | 打通：登录、拍照、直传 COS、轮询任务、展示结果 | TD-01 | +| T-P0-18 | SPIKE | AI 标识元数据全链路存活验证 | 测试报告 | 经水印/COS/CDN/客户端保存后元数据仍存在 | CR-05 | +| T-P0-19 | SPIKE | LLM 缓存命中率验证 | 报告 | 确认固定前缀设计下的实际命中率与成本降幅 | TD-04 | + +### 2.3 数据与内容准备（🔴 **备案解除后，这里成为新的关键路径**） + +> **这一节的优先级已经升到最高**。备案不再是瓶颈后，内容与素材生产成为唯一无法靠 AI 辅助开发压缩的工序：招聘要时间、采购要物流、拍摄要棚时、质检要人眼。**这些任务晚一周启动，上线就晚一周**，且没有任何技术手段可以追回。 + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| **T-P0-20** | **BIZ** | 🔴 **全职形象顾问招聘与入场** | 到岗顾问 | 全职编制到岗；完成本体 Schema 评审；输出规则库产能基线（条/周），用于倒排 M2 | TD-27 | +| **T-P0-21** | **DATA** | 🔴 **单品自采流水线搭建并跑通** | 可运行流水线 + 首批 20 件 | 采购 → 拍摄（白底规范）→ BiRefNet 抠图 → 属性标注 → 质检全流程闭环；**输出每周产能数据**用于倒排 300 件目标 | TD-26、FR-KB-08 | +| T-P0-22 | DATA | 拍摄规范与质检标准定稿 | SOP 文档 | 灯光、背景、角度、分辨率、`tryon_slot` 判定标准明确，新人照此可独立操作 | TD-26 | +| T-P0-23 | DATA | 知识库本体 Schema 与属性字典定稿 | Schema 文档 | 12 类实体字段、枚举、必填项全明确 | FR-KB-01 | +| T-P0-24 | DATA | **60 款发型适配标签打标** | 打标数据 | 100% 完成，抽检复核通过 | FR-HAIR-02 | +| T-P0-25 | DATA | 诊断维度字典与规则矩阵框架定稿 | 文档 | **32 维度**（五行两项已移除）与三大规则矩阵结构确定 | FR-RPT-06、TD-31 | +| T-P0-26 | BIZ | 目标用户访谈（价格敏感度 + 需求验证） | 访谈报告 | ≥ 15 人。**因 V1 不展示价格，价格敏感度只能靠访谈采集**，这是 V2 定价的重要输入 | TD-28 | +| ~~T-P0-27~~ | — | ~~定价与点数消耗比测算~~ | **推迟到 V2** | V1 不收费，定价需 V1 真实数据（`T-P6-16`） | TD-28 | +| T-P0-28 | BIZ | 素材版权留档机制 | 留档规范 | 采购凭证与拍摄原始文件归档；`license` 字段标记 `self_shot` | TD-26 | + +**M0 出口条件**（已按备案完成重排）： +1. ✅ 备案编号已归档，**模型清单核实完成**（`T-P0-01`） +2. 六项核心技术验证有明确结论（`T-P0-10`/`11`/`12`/`13`/`17`/`18`） +3. 本体 Schema 与发型打标完成 +4. 🔴 **全职顾问到岗且产能基线可测算** +5. 🔴 **自采流水线跑通首批 20 件，每周产能数据可用于倒排** + +--- + +## 3. Phase 1：工程地基（M1） + +> **这一阶段不交付任何用户可见的业务功能**，但它决定后面每个功能的实现成本。跳过地基直接写业务，会导致每个功能各自实现一遍任务状态、审核、水印、配额扣减，然后在集成时全部返工。 + +### 3.1 工程基建 + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P1-01 | DEV | 仓库结构与包边界搭建 | 可运行骨架 | 目录结构符合架构 §16.1；`packages/domain` 无 IO 依赖 | NFR-MAINT-03 | +| T-P1-02 | OPS | CI 流水线（ruff + mypy strict + pytest + 依赖规则检查） | CI 配置 | 违规提交被阻断 | NFR-MAINT-02/03 | +| T-P1-03 | OPS | 本地开发环境（Compose：PG+pgvector、Redis、COS mock） | compose 文件 + 文档 | 新成员一条命令起环境 | — | +| T-P1-04 | OPS | 腾讯云基础设施开通与配置（VPC/CVM/PG/Redis/COS 四桶/CDN/CLS） | 环境清单 | 四桶权限与生命周期策略生效 | TD-03、CR-02 | +| T-P1-05 | DEV | 配置与密钥管理（SSM/KMS 接入） | 配置模块 | 无密钥进代码与镜像 | NFR-SEC-01 | +| T-P1-06 | DEV | Alembic 迁移基线与规范 | 首个迁移 | 迁移可正向与回滚 | NFR-MAINT-06 | +| T-P1-07 | DEV | 统一响应、错误码体系、异常处理中间件 | 中间件 + 错误码表 | 每个错误码有 message + hint | FR-SYS-02 | +| T-P1-08 | DEV | 可观测性接入（OTel + Prometheus + 日志脱敏） | 可用链路追踪 | 一次请求可看到完整 span；日志无敏感字段 | NFR-SEC-03 | +| T-P1-09 | OPS | 三张监控看板搭建（漏斗/成本/任务） | Grafana 看板 | 能回答架构 §15 的三个问题 | FR-SYS-05 | +| T-P1-10 | DEV | 埋点上报接口与事件字典 | 接口 + 事件表 | 漏斗关键节点无缺失 | FR-SYS-06 | + +### 3.2 账号与会话 + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P1-11 | DEV | 用户数据模型与身份映射 | 表 + 迁移 | UnionID 映射唯一；预留 `profile_id` | FR-ACC-01、FR-ACC-12 | +| T-P1-12 | DEV | 华为账号登录（服务端） | 接口 | 登录成功率 ≥ 99%（联调环境） | FR-ACC-01 | +| T-P1-13 | DEV | 双令牌会话与撤销 | 接口 | 登出后旧令牌立即失效 | FR-ACC-05 | +| T-P1-14 | DEV | 游客模式与数据合并 | 接口 | 合并幂等；多设备场景有确定策略 | FR-ACC-02/03 | +| T-P1-15 | DEV | 同意授权记录（含人脸单独同意） | 表 + 接口 | 记录含版本与时间，可查询 | CR-01、FR-ACC-08 | +| T-P1-16 | DEV | 账号注销与数据删除任务 | 接口 + 定时任务 | 7 日内彻底删除，含 COS 对象；有执行记录 | CR-03、FR-ACC-09 | +| T-P1-17 | DEV | 未成年人判定与功能限制 | 中间件 | 未成年账号禁用付费与外观评价 | CR-04、FR-ACC-11 | +| T-P1-18 | DEV | 越权防护与归属校验（含自动化测试） | 依赖注入 + 测试 | 越权用例全部拦截 | FR-SYS-01 | + +### 3.3 地基能力（被所有业务依赖） + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P1-19 | DEV | **统一任务中心**（状态机、幂等、进度、查询、取消） | 模块 + 接口 | 状态机完整；相同幂等键不重复执行 | FR-TASK-01/02/05/06 | +| T-P1-20 | DEV | Celery 四队列与 Worker 部署（gpu/cpu/io/beat） | 部署配置 | 队列隔离生效；beat 防重 | TD-11 | +| T-P1-21 | DEV | 死信队列与失败告警 | 配置 + 告警 | 连续失败进死信并告警 | FR-TASK-07 | +| T-P1-22 | DEV | **统一合规出口**（审核 + 水印 + 元数据 + 内容编号登记） | 模块 | 所有产物必经；元数据全链路存活测试通过 | CR-05、CR-06 | +| T-P1-23 | DEV | 内容审核接入（IMS + TMS + 关键词库） | 模块 | 六类审核对象全覆盖；fail-close 生效 | CR-06/07 | +| T-P1-24 | DEV | **LLM 网关**（路由/降级/熔断/结构化输出/Prompt 版本/成本记录） | 模块 | 主备切换 < 3s；成本 100% 记录 | FR-SYS-04 | +| T-P1-25 | DEV | 成本归因表与日成本预警 | 表 + 告警 | 可按功能/模型/用户聚合；突增告警生效。**不允许后置到上线后补**（V2 定价的唯一数据来源） | FR-BILL-08、NFR-COST-01、FR-SYS-07 | +| T-P1-26 | DEV | **配额账本**（余额、流水、预扣三段式、周期重置、规则配置化） | 模块 + 接口 | 余额可由流水重算；失败自动退还；**表结构含 `tx_type` 字段，V2 上支付无需迁移**；服务端硬校验不可绕过 | FR-BILL-01/02/04/05/06 | +| T-P1-26b | DEV | 额度耗尽文案与提示 | 端侧组件 | **不出现任何价格、购买、会员、升级字样**；消耗前提示剩余量 | FR-BILL-07 | +| T-P1-27 | DEV | 图片直传（预签名 URL）与临时桶生命周期 | 接口 + 桶策略 | 图片不经应用服务器；2 小时自动清理 | FR-SYS-03、CR-02 | +| T-P1-28 | DEV | 推送接入（Push Kit + Token 管理） | 模块 | 到达率 ≥ 90%；文案无敏感结论 | FR-TASK-04 | + +### 3.4 客户端骨架 + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P1-29 | DEV | 鸿蒙工程初始化（签名、权限、AGC 配置、SHA256 指纹） | 可打包工程 | 真机可运行；调试与发布双证书配置文档化 | TD-01、TD-15 | +| T-P1-30 | DEV | 网络层与 OpenAPI 类型生成 | SDK | 接口变更后类型自动更新 | NFR-MAINT-01 | +| T-P1-31 | DEV | 登录与用户中心页面 | 页面 | 登录、资料、设置可用 | FR-ACC-06/07 | +| T-P1-32 | DEV | 拍照/相册选择 + 端侧压缩 + 直传 | 组件 | 大图压缩后上传成功率 ≥ 99% | FR-RPT-03 | +| T-P1-33 | DEV | 任务中心页面与进度组件 | 页面 | 进度、排队位次、失败重试可用 | FR-TASK-03 | +| T-P1-34 | DEV | SSE 流式渲染组件 | 组件 | 流式输出顺滑，断线可恢复 | FR-AGT-01 | +| T-P1-35 | DEV | 设计系统与基础组件库 | 组件库 | 主要组件齐备，风格统一 | — | + +**M1 出口条件**：能用测试账号走通「登录 → 拍照上传 → 提交一个 mock 长耗时任务 → 看到进度 → 收到推送 → 拿到带 AI 标识的产物 → 配额正确扣减与退还」。这条链路一旦跑通，后面的业务功能都是往里填内容。 + +--- + +## 4. Phase 2：知识库与检索（M2） + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P2-01 | DEV | 知识库数据模型（实体/关系/规则/文本块/素材/色板） | 表 + 迁移 | 12 类实体可存取；`tryon_ready` 标志可用 | FR-KB-01 | +| T-P2-02 | DEV | 规则引擎（决策表求值 + 硬约束校验 + 命中链输出） | 模块 | 求值 p95 < 50ms；硬约束可拦截 | FR-KB-05 | +| T-P2-03 | DEV | Embedding 服务（BGE-M3 + 批量向量化） | 服务 | 向量化可重跑；模型版本可切换 | TD-22 | +| T-P2-04 | DEV | 混合检索链路（硬过滤 + 规则 + 向量 + 关键词 + 重排） | 模块 | 检索 p95 < 200ms；硬过滤零漏 | FR-KB-06 | +| T-P2-05 | DEV | 图谱关系查询与解释路径输出 | 模块 | 1~3 跳可返回路径 | FR-KB-07 | +| T-P2-06 | DEV | 知识缺口埋点与统计 | 表 + 任务 | 无结果 query 全量记录并可排序 | FR-KB-10 | +| T-P2-07 | DEV | 抠图批处理服务（BiRefNet + 白底标准化 + 规格校验） | 服务 | 批量可跑；规格校验拦截不合格图 | FR-KB-08 | +| T-P2-08 | DEV | 视觉模型辅助属性预标注 | 服务 | 预标注准确率 ≥ 70%，人工可修正 | FR-KB-12 | +| T-P2-09 | DEV | **极简运营后台**（登录、条目 CRUD、规则编辑、素材上传、审核、发布回滚） | 后台 | 顾问可独立完成内容维护，无需工程介入 | FR-ADM-01~04 | +| T-P2-10 | DEV | 知识库版本号与缓存失效机制 | 机制 | 发布后检索缓存自然失效 | 架构 §10 | +| T-P2-11 | DEV | 黄金测试集框架与 CI 集成 | 测试集 + CI | ≥ 100 用例；指标退化阻断合并 | FR-KB-11 | +| T-P2-12 | DATA | 自建色板录入（12 季型 Lab 色值） | 数据 | 每季型含主色/点缀/禁忌，命名自研 | FR-KB-02 | +| T-P2-13 | DATA | 规则库冷启动录入（体型×场合、季型×色彩、脸型×发型） | 数据 | 三大矩阵覆盖；每条含依据与审核人 | FR-KB-04 | +| T-P2-14 | DATA | 实体内容录入（单品、场合、材质、配饰等） | 数据 | 达到知识库文档 §9 的冷启动规模 | FR-KB-03 | +| T-P2-15 | DATA | 单品自采与白底图生产（**目标 300 件 `tryon_ready`**） | 素材 | 抠图质检通过 ≥ 90%；换装接口实测可出图；`license=self_shot` 且留档完整 | FR-KB-08、TD-26 | +| T-P2-16 | DATA | 黄金集标注（检索/规则/报告） | 标注数据 | 由顾问参与标注，作为质量基线 | FR-KB-11 | + +**M2 出口条件**：顾问在后台录入一条新规则并发布后，Agent 与报告的输出在 5 分钟内体现变化；黄金集在 CI 中稳定通过。 + +--- + +## 5. Phase 3：报告闭环（M3） + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P3-01 | DEV | 视觉服务（分割 + 关键点 + 人脸属性 + 关键点 + 色值采样） | 服务 | 各项返回置信度与质量标记 | FR-RPT-05 | +| T-P3-02 | DEV | 图片质量门禁（多人/遮挡/过暗/侧脸） | 模块 | 拦截准确率 ≥ 85%；给出具体重拍指引 | FR-RPT-03 | +| T-P3-03 | DEV | 体型测算实现（掩膜宽度剖面法） | 模块 | 达到 T-P0-10 的验证基线 | FR-RPT-05 | +| T-P3-04 | DEV | 色彩季型判定实现 | 模块 | 达到 T-P0-11 的验证基线 | FR-RPT-05 | +| T-P3-05 | DEV | 脸型与五官比例判定 | 模块 | 与人工标注一致率 ≥ 80% | FR-RPT-05 | +| T-P3-06 | DEV | 结构化诊断生成（**32 维度** + 置信度 + 依据 + 规则命中） | 模块 | 每维度四要素完整；缺失显式标注 | FR-RPT-06、TD-31 | +| T-P3-07 | DEV | 报告触发资格与频控 | 模块 | 触发规则符合需求文档 §3；配额生效 | FR-RPT-02、FR-RPT-13 | +| T-P3-08 | DEV | 问卷采集与存储 | 接口 + 页面 | 完成率 ≥ 80%；可跳过不阻断 | FR-RPT-04 | +| T-P3-09 | DEV | 报告生成编排（含中间态落库与分步恢复） | Worker 任务 | LLM 或渲染失败不需重新上传照片 | 架构 §7.1 | +| T-P3-10 | DEV | 报告文案生成（Prompt + 结构化输出约束） | Prompt + 模块 | 结论与诊断值一致，无自相矛盾 | FR-RPT-07 | +| T-P3-11 | DEV | 生成后校验（禁忌/色值/维度引用/贬损词） | 模块 | 黄金集违反数 = 0；贬损词零通过 | FR-RPT-08、CR-12 | +| T-P3-12 | DEV | 长图渲染服务（Playwright + 模板） | 服务 | p95 < 8s；跨设备一致 | FR-RPT-12、TD-12 | +| T-P3-13 | DEV | 报告页面与交互（分模块、术语释义、置信度降级表述） | 页面 | 术语 100% 配白话释义 | FR-RPT-10、NFR-UX-03/05 | +| T-P3-14 | DEV | 报告分享（长图 + 可失效链接） | 功能 | 分享图含显式标识；链接可撤回 | FR-RPT-12 | +| T-P3-15 | DEV | 画像与记忆写入（L0~L2 + 冲突消解 + 审计） | 模块 | 报告完成后 L1 记忆同步生成 | FR-MEM-01/02/07/12 | +| T-P3-16 | DEV | 「我的记忆」页面（可见可编辑可删除） | 页面 | 删除后不再注入；编辑优先级最高 | FR-MEM-05、CR-02 | +| T-P3-17 | DEV | 记忆快照与注入（token 预算裁剪 + 缓存） | 模块 | 注入 ≤ 500 token；记忆变更即失效缓存 | FR-MEM-04 | +| T-P3-18 | DEV | 记忆衰减定时任务 | 任务 | 未强化记忆置信度按规则下降 | FR-MEM-06 | +| T-P3-19 | DEV | 无照片/拒绝授权的降级路径 | 功能 | 问卷可生成简版画像，明确告知差异 | FR-RPT-11 | +| T-P3-20 | DEV | 报告引导流程（首次进入核心功能前） | 功能 | 可跳过；跳过后有降级说明 | FR-RPT-02 | + +**M3 出口条件**：真实用户（内部 10 人）走完报告流程，人工评审报告质量：结论准确、无禁忌违反、无贬损表述、术语可理解；画像正确写入并能被 Agent 读到。 + +--- + +## 6. Phase 4：Agent 与换装闭环（M4） + +### 6.1 穿搭 Agent + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P4-01 | DEV | 会话与消息模型（含检索轨迹与规则命中） | 表 + 迁移 | 每条回答可复盘 | FR-AGT-09 | +| T-P4-02 | DEV | 意图识别（含越界意图拒答） | 模块 | 主要意图准确率 ≥ 85%；越界正确拒答 | FR-AGT-02、CR-12 | +| T-P4-03 | DEV | 上下文组装与 token 预算控制 | 模块 | 输入 ≤ 3700 token；超限按优先级裁剪 | FR-AGT-03 | +| T-P4-04 | DEV | 流式对话接口（SSE） | 接口 | 首字 p95 < 2s | FR-AGT-01 | +| T-P4-05 | DEV | 生成后校验（复用 T-P3-11） | 模块 | 黄金集违反数 = 0 | FR-AGT-05 | +| T-P4-06 | DEV | 搭配方案结构化输出与卡片渲染 | 功能 | 可解析为单品组合，字段完整 | FR-AGT-06 | +| T-P4-07 | DEV | 显式偏好抽取 + 用户回执 | 功能 | 抽取成功率 ≥ 90%；回执可撤销 | FR-AGT-08、FR-MEM-03 | +| T-P4-08 | DEV | 快捷问题入口 | 功能 | 场景化快捷问题可用 | FR-AGT-07 | +| T-P4-09 | DEV | 无画像用户降级路径 | 功能 | 通用建议 + 报告引导 | FR-AGT-10 | +| T-P4-10 | DEV | 会话页面与历史列表 | 页面 | 可回看，符合保留策略 | FR-AGT-09 | +| T-P4-11 | DEV | 反馈收集（点赞/点踩/原因） | 功能 | 反馈可用于质量评估与隐式推断 | FR-AGT-13 依赖 | + +### 6.2 换装与发型 + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P4-12 | DEV | **换装服务改造**（鉴权/异步回调/幂等/并发上报/成本埋点/COS 迁移） | 改造后服务 | 架构 §4.4 全部改造项完成 | FR-TRY-01 | +| T-P4-13 | DEV | 换装任务编排（三工作流） | 模块 | 成功率 ≥ 90%（排除输入不合格） | FR-TRY-01 | +| T-P4-14 | DEV | 输入前置校验（人像质量 + 单品白底图规格） | 模块 | 不合格输入在扣点前拦截 | FR-TRY-02 | +| T-P4-15 | DEV | GPU 队列容量保护与排队体验 | 机制 + 页面 | 展示位次与预估；超阈值拒绝新任务 | FR-TRY-04 | +| T-P4-16 | DEV | 结果审核 + 合规标识 + 存储 | 流程 | 100% 经统一合规出口 | FR-TRY-03、CR-05 | +| T-P4-17 | DEV | 结果收藏与管理（含删除清理对象） | 功能 | 删除后 COS 对象同步清理 | FR-TRY-06 | +| T-P4-18 | DEV | 前后对比视图 | 功能 | — | FR-TRY-07 | +| T-P4-19 | DEV | 基于画像的单品推荐 | 功能 | 推荐项 100% 为 `tryon_ready` | FR-TRY-08 | +| T-P4-20 | DEV | 发型更换与发色调整 | 功能 | 成功率 ≥ 90% | FR-HAIR-01 | +| T-P4-21 | DEV | 基于脸型与画像的发型推荐 | 功能 | 不含该脸型禁忌发型（规则校验 100%） | FR-HAIR-03 | +| T-P4-22 | DEV | GPU 实例按需启停机制 | 运维脚本 | 队列积压拉起，空闲释放 | NFR-COST-04 | + +**M4 出口条件**：报告 → Agent → 换装三条链路互通；同一用户的画像在三处表现一致；全链路成本可在看板上按功能查看。 + +--- + +## 7. Phase 5：上线就绪（M5） + +| 编号 | 类型 | 任务 | 交付物 | 验收标准 | 关联 | +| --- | --- | --- | --- | --- | --- | +| T-P5-01 | DEV | 任务奖励额度发放（签到/完善资料/反馈/邀请/分享） | 功能 | 完成即到账，**同一任务同一周期幂等** | FR-BILL-03 | +| T-P5-02 | DEV | 配额消耗表配置化 | 配置 | 不硬编码，可热更新不发版 | FR-BILL-04 | +| T-P5-03 | DEV | 知识缺口看板（后台） | 页面 | 按频次排序，可导出 | FR-ADM-05 | +| T-P5-04 | DEV | 客服支持查询（用户任务与配额流水） | 页面 | 可按用户排查客诉 | FR-ADM-06 | +| T-P5-05 | DEV | 外部依赖降级策略实现与演练 | 实现 + 演练记录 | 各依赖失效表现符合架构 §2；审核 fail-close | FR-SYS-08 | +| T-P5-06 | OPS | 压力测试（API/报告/换装/检索） | 压测报告 | 达到 NFR-PERF 全部指标 | NFR-PERF-* | +| T-P5-07 | OPS | 数据备份与**恢复演练** | 演练记录 | RPO ≤ 5min，RTO ≤ 1h 实测达成 | FR-SYS-09、NFR-REL-04 | +| T-P5-08 | OPS | 告警分级与值班机制 | 配置 + 文档 | P0/P1/P2 告警路由正确 | — | +| T-P5-09 | DEV | 全链路埋点走查 | 走查报告 | 漏斗无缺失（用测试账号逐节点验证） | FR-SYS-06 | +| T-P5-10 | BIZ | **合规检查清单逐项验收** | 检查清单（全绿） | 《合规与安全方案》§5 全部项通过 | CR-01~CR-12 | +| T-P5-11 | DEV | 备案号公示页面**实机验收**（`T-P0-03` 的验证环节） | 验收记录 | **发布包**（非调试包）中显著位置正确展示模型名称与编号；展示内容与网关实际路由一致 | CR-08 | +| T-P5-12 | BIZ | 应用市场上架材料准备与提交 | 提交记录 | 含 AI 生成服务说明、标识材料、**已取得的备案编号** | CR-08 | +| T-P5-13 | OPS | 灰度发布机制 | 机制 | 按用户哈希分流；可快速回滚 | 架构 §14.3 | +| T-P5-14 | BIZ | 内部测试与用户测试（种子用户） | 测试报告 | 核心链路无 P0 缺陷；报告质量人工评审通过 | — | +| T-P5-15 | DEV | **配额对账任务与告警** | 定时任务 | 每日校验余额与流水一致性，不一致告警。V1 就要做，否则 V2 上支付时对账逻辑无历史数据可验证 | FR-BILL-02 | +| T-P5-16 | BIZ | 全文案价格字样扫描 | 扫描报告 | 全端文案不含价格、购买、会员、升级字样（`FR-BILL-07`） | TD-28 | + +**M5 出口条件**：合规清单全绿 + **编号公示实机验证通过** + 压测达标 + 恢复演练完成 + 无 P0 缺陷。 + +> **与上一版的差别**：备案编号已取得，M5 不再被"等编号"阻塞。但**公示位的实现与实机验证仍是上架硬要求** —— 编号拿到了却没在界面上正确展示，一样过不了核验。这是个容易松懈的地方：备案完成的心理暗示会让人以为这件事已经结束了。 + +--- + +## 8. Phase 6：V2 能力（M6） + +| 编号 | 类型 | 任务 | 关联 | +| --- | --- | --- | --- | +| T-P6-01 | DEV | 全面报告内容生成（含面部精细分析、场景搭配方案） | FR-RPT-15 | +| T-P6-02 | DEV | 华为 IAP 接入（商品配置、服务端收据校验、掉单补发、对账） | FR-BILL-09/11 | +| T-P6-02b | BIZ | 华为企业开发者认证 + 数字商品联运协议签署 | TD-29、TD-16 | +| T-P6-02c | DEV | 华为账号一键登录（企业资质就位后） | FR-ACC-13 | +| T-P6-03 | DEV | 会员等级与权益体系 | FR-BILL-10 | +| T-P6-03b | BIZ | **小范围真实收费灰度**（验证预约率到实付的衰减） | TD-28 | +| T-P6-04 | DEV | 付费触发点与转化设计 | FR-RPT-16 | +| T-P6-05 | DEV | 隐式行为推断 + 待确认机制 | FR-MEM-08 | +| T-P6-06 | DEV | L3 事件记忆与语义召回 | FR-MEM-09 | +| T-P6-07 | DEV | L4 会话滚动摘要 | FR-MEM-10 | +| T-P6-08 | DEV | 「为什么推荐」解释链自然语言化 | FR-AGT-13 | +| T-P6-09 | DEV | 联动换装 / 联动发型（Agent 一键跳转） | FR-AGT-14/15 | +| T-P6-10 | DEV | 图片输入理解与穿搭评价 | FR-AGT-16 | +| T-P6-11 | DEV | 语音输入（Core Speech Kit） | FR-AGT-17 | +| T-P6-12 | DEV | 我的衣橱（录入、管理、基于衣橱搭配） | FR-WDB-01~03 | +| T-P6-13 | DEV | 报告 PDF 导出 | FR-RPT-17 | +| T-P6-14 | DEV | 运营后台完整版（版本管理、效果看板） | FR-ADM-07 | +| T-P6-15 | BIZ | 多端方案重新评估 | TD-01 | +| T-P6-16 | BIZ | **单位经济模型重做与定价**（基于 V1 真实数据） | 产品方案 §5.3、TD-28 | + +> **T-P6-16 的前置输入（缺一不可）**：① `ob_ai_call` 累积的单次真实成本；② `bl_ledger` 反映的人均使用频次；③ V1 的全面报告预约率；④ 华为 IAP 抽成的实际到账比例。这四项齐备后定价才有依据 —— 这也是为什么 V1 的计量埋点不允许裁剪。 +> +> **顺序要求**：`T-P6-16`（定价）应在 `T-P6-03b`（小范围收费灰度）之后确定最终价格，而不是仅凭预约率推算。预约到实付的衰减无法用代理指标估计。 + +--- + +## 9. 并行建议与关键提醒 + +### 9.1 可并行的工作流 + +``` +流 1（内容生产，🔴 现在最长）：T-P0-20 顾问到岗 ─┐ + T-P0-21 自采流水线 ─┴→ T-P2-12~16（持续到上线） +流 2（技术验证） ：T-P0-10~19 +流 3（工程开发） ：M1 → M2 → M3 → M4 → M5 +流 4（合规落地，已大幅缩短） ：T-P0-01 核实模型清单 → T-P0-03 公示位 → T-P5-11 实机验收 +流 5（设计） ：设计系统 → 报告页 → Agent 页 → 换装页 +``` + +**流 1 必须在流 3 之前启动，且是现在唯一的关键路径**。它不占用开发资源，但它的产能上限就是项目的进度上限。 + +> **与上一版的关键差别**：原来的「流 1 外部审批」已完成，它曾经是最长的一条流，也曾经掩盖了内容生产的长尾问题 —— 因为反正要等备案，内容慢一点看不出来。**现在这层缓冲没有了，内容生产的产能会直接暴露为上线延期。** + +### 9.2 五个最容易翻车的地方 + +1. ~~**备案登记启动太晚**~~ → ✅ **已完成**。但换来一个新的风险：**"备案搞定了"的松懈心态** —— 编号公示位没实现、或备案范围未覆盖双路由模型，一样过不了上架核验。对策：`T-P0-01` 核实模型清单，`T-P5-11` 实机验收公示位。 +2. **内容与素材产能被低估**（🔴 **现在是第一风险**）→ 功能都好了但 `tryon_ready` 单品不够 300 件，「建议→试穿」闭环不成立，产品核心价值落空。备案解除后这条已无缓冲。对策：`T-P0-21` 必须先跑通流水线并**测出每周产能**，据此倒排；未达标则功能降级为「加入搭配」而非硬等。 +3. **地基没打就写业务** → 每个功能各自实现任务状态/审核/水印/配额扣减，集成时全部返工。对策：M1 出口条件必须硬性验收。 +4. **AI 标识元数据静默失效** → 上架被拒或事后整改。对策：`T-P0-18` 提前验证，`T-P1-22` 落地时带自动化测试。 +5. **成本埋点后补** → **V1 不收费让这一条的后果更严重**：V1 没有收入，成本是唯一财务变量，且埋点数据是 V2 定价的唯一依据。埋点缺失的功能在 V2 定价时就是一个必须靠猜的空洞。对策：`T-P1-25` 与 LLM 网关同批交付，不允许后置。 + +### 9.3 需求覆盖率检查 + +任务拆解完成后需反查：《需求规格说明》中每一条 **P0 需求与 CR 需求**都能在本文找到至少一个对应任务。建议在评审时逐条勾对，缺口即是遗漏的任务。 + +--- + +## 10. 任务卡模板 + +新增任务时按此格式，避免出现无法验收的任务： + +``` +编号：T-Px-xx +类型：SPIKE / DEV / DATA / OPS / BIZ +任务：<一句话说明要做什么> +背景：<为什么需要，解决什么问题> +交付物：<可检查的产出：代码模块 / 接口 / 数据 / 报告 / 配置> +验收标准：<可判定的条件，含具体数值或测试用例> +依赖：<前置任务编号> +关联需求： +风险：<已知不确定性与备选方案> +``` + +--- + +## 相关文档 + +- [文档索引](./README.md) +- [需求规格说明](./需求规格说明.md)（任务的 `关联需求` 字段指向此处） +- [技术架构文档](./技术架构文档.md)（任务按此文的模块边界与关键链路切分） +- [技术选型与调研报告](./技术选型与调研报告.md)（SPIKE 类任务多为此文中标注了切换条件的项） +- [合规与安全方案](./合规与安全方案.md)（Phase 0 的备案与合规任务依据） + +--- + +## 变更记录 + +| 日期 | 版本 | 变更 | +| --- | --- | --- | +| 2026-08-13 | v1.1 | **关键路径转移**。备案已完成，原 `T-P0-01`~`T-P0-08` 申报类任务关闭，替换为备案后的落地与核实任务（模型清单核实、编号公示位实现、公示与网关路由同源校验）。§2.3 内容与素材生产升为新的关键路径，`T-P0-20` 顾问到岗与 `T-P0-21` 自采流水线成为全项目最优先任务，并要求输出**每周产能数据**用于倒排。配额相关任务去除支付语义（`T-P1-26` 强调 `tx_type` 字段使 V2 免迁移，新增 `T-P1-26b` 文案约束、`T-P5-15` 对账、`T-P5-16` 价格字样扫描）。诊断维度改 32。Phase 6 新增企业开发者认证、一键登录、**小范围真实收费灰度**，并明确 `T-P6-16` 定价的四项前置输入 | +| 2026-08-13 | v1.0 | 首次输出。六个里程碑（M0~M5 为 V1，M6 为 V2+），Phase 0 定为备案与前置验证阶段并与开发并行 | diff --git a/docs/技术架构文档.md b/docs/技术架构文档.md new file mode 100644 index 0000000..0a0ff72 --- /dev/null +++ b/docs/技术架构文档.md @@ -0,0 +1,1019 @@ +# 「美搭」技术架构文档 + +> 版本：v1.0　｜　更新日期：2026-08-13　｜　状态：待技术评审 +> +> **本文的定位**：把产品需求翻译成可直接拆解为开发任务的技术方案。读完这份文档，应该能回答三个问题——系统由哪些部分组成、数据长什么样、每条关键链路怎么跑通。 +> +> **前置阅读**：《技术选型与调研报告》（所有选型结论与理由，本文只引用编号 `TD-xx`，不重复论证） +> **配套阅读**：《需求规格说明》（需求编号 `FR-xx`/`NFR-xx`）、《合规与安全方案》、《开发任务拆解》 + +--- + +## 1. 架构目标与约束 + +### 1.1 这个系统真正难的地方 + +在动手设计之前先明确难点，否则很容易把它当成一个「CRUD + 调几个 AI 接口」的普通应用，那会在三个月后付出代价： + +1. **它是一个「长耗时任务为主」的系统，不是请求-响应系统**。报告生成、换装出图都在数十秒量级。这意味着任务中心、状态机、幂等、进度反馈、失败退款、断线恢复不是附加功能，而是**主干链路**。 +2. **AI 输出必须被约束，而不是被信任**。报告结论与搭配建议要可解释、可审计、不能违反禁忌规则。因此架构上必须有「检索 → 规则约束 → 生成 → 生成后校验」的闭环，而不是把用户问题直接丢给大模型。 +3. **它处理的是敏感个人信息（人脸）**，且产出的全部是 AI 生成内容。合规不是上线前补的文档，而是**架构约束**：原图不落盘、生成物统一打标识、输入输出双向审核。 +4. **成本随活跃度线性增长**。GPU 出图与大模型调用都是按量付费。如果没有从第一天就把成本埋进链路并可归因到功能和用户，用户量上来后无法优化，只能凭感觉砍功能。 +5. **知识库是持续演进的资产**，它的更新频率远高于代码。所以规则、色板、单品必须是**数据**而不是代码，且有配套的运营入口与回归测试。 + +### 1.2 质量属性优先级 + +按项目当前阶段（V1 单端、效果优先、团队 4~6 人）排序： + +| 优先级 | 质量属性 | 具体要求 | +| --- | --- | --- | +| 1 | **正确性与可解释性** | 建议不违反硬性禁忌；每条结论可追溯到规则或知识条目 | +| 2 | **合规性** | 人脸处理、AI 标识、内容审核、备案登记均满足现行要求 | +| 3 | **可演进性** | 域边界清晰，V2 拆服务/换模型/多端时不需要重写 | +| 4 | **可观测性** | 业务漏斗、AI 成本、任务健康三张看板齐备 | +| 5 | 性能 | 见 `NFR` 指标；报告与出图允许秒级到分钟级，但**等待体验必须做好** | +| 6 | 极致成本优化 | V1 只要求「可归因、可预警」，不要求「最省」 | + +### 1.3 架构约束（不可协商） + +| 约束 | 来源 | +| --- | --- | +| 客户端为鸿蒙原生 ArkTS，服务端保持端无关 | `TD-01` | +| 服务端全 Python（FastAPI） | 项目决策 | +| 基础设施以腾讯云为主，服务器部署在中国大陆 | 项目决策 + `TD-15` 手机号获取要求 | +| 人脸原图不进入持久化存储 | `TD-20` | +| 所有对外生成物必须经过统一合规出口 | `TD-21` | +| **V1 不接入任何支付能力**，配额为唯一成本控制手段 | `TD-28` | +| V2 起虚拟商品支付必须走华为 IAP | `TD-16` | +| V1 不上微服务、不上 K8s、不上专用向量库与图数据库 | `TD-08`/`TD-09`，团队规模 | + +--- + +## 2. 系统上下文 + +``` + ┌──────────────────────┐ + │ 鸿蒙客户端 (ArkTS) │ + └──────────┬───────────┘ + │ HTTPS / SSE + ▼ +┌──────────────────────────────────────────────────────────────────────────┐ +│ 美搭服务端 (Python / 腾讯云) │ +│ │ +│ API 层 ──▶ 业务域模块 ──▶ AI 能力层 ──▶ 数据层 │ +│ │ │ +│ └──▶ 任务队列 ──▶ Worker │ +└───┬──────────┬──────────┬──────────┬──────────┬──────────┬───────────────┘ + │ │ │ │ │ │ + ▼ ▼ ▼ ▼ ▼ ▼ +┌────────┐┌────────┐┌────────┐┌────────┐┌────────┐┌──────────────┐ +│华为服务 ││大模型 ││腾讯云AI ││自有换装 ││腾讯云 ││腾讯云基础设施 │ +│账号/推送││DeepSeek││人脸识别 ││发型服务 ││天御审核 ││COS/CDN/PG/ │ +│Push ││智谱GLM ││ ││(GPU) ││ ││Redis/CLS │ +└────────┘└────────┘└────────┘└────────┘└────────┘└──────────────┘ +``` + +**外部依赖及其失效影响**（每一个都要有降级方案，见 §13.4）： + +| 外部系统 | 用途 | 失效影响 | 降级策略 | +| --- | --- | --- | --- | +| 华为 Account Kit | 登录 | 新用户无法注册 | 游客模式可继续体验非付费功能 | +| 华为 IAP | 支付（**V2 起**） | 无法购买 | 提示稍后再试，不影响已有权益。V1 不依赖此项 | +| 华为 Push Kit | 任务完成通知 | 通知不到 | 应用内任务中心轮询兜底 | +| DeepSeek / GLM | 文案生成、对话 | 报告与对话不可用 | 双供应商自动切换；均失败时报告排队重试，对话返回兜底话术 | +| 腾讯云人脸识别 | 面部分析 | 报告无法生成面部维度 | 报告降级为「体型+色彩」子集，标注待补全 | +| 自有换装服务 | 出图 | 换装不可用 | 任务转排队，不扣配额，超时退还 | +| 腾讯云天御 | 内容审核 | **不可降级** | 审核失败一律按「拦截」处理（fail-close），宁可少发不可漏审 | + +--- + +## 3. 总体架构 + +### 3.1 分层视图 + +``` +┌───────────────────────────────────────────────────────────────────────┐ +│ L1 客户端层 │ +│ 鸿蒙 ArkTS：页面 / 状态管理 / 端侧缓存 / 图片压缩 / SSE流式渲染 │ +└───────────────────────────────────────────────────────────────────────┘ + ▼ +┌───────────────────────────────────────────────────────────────────────┐ +│ L2 接入层 │ +│ CLB + Nginx：TLS / 限流 / 防刷 / 请求日志 / 静态与图片走 CDN │ +└───────────────────────────────────────────────────────────────────────┘ + ▼ +┌───────────────────────────────────────────────────────────────────────┐ +│ L3 API 层（FastAPI，面向端的编排层） │ +│ 认证鉴权 · 参数校验 · 幂等 · 配额校验与预扣 · 统一响应 · OpenAPI │ +└───────────────────────────────────────────────────────────────────────┘ + ▼ +┌───────────────────────────────────────────────────────────────────────┐ +│ L4 业务域层（模块化单体：包内隔离，禁止跨域直接访问对方数据表） │ +│ ┌────────┬────────┬────────┬────────┬────────┬────────┬────────┐ │ +│ │identity│profile │ report │ agent │ tryon │ kb │billing │ │ +│ │账号会话│画像记忆│美学报告│对话Agent│换装发型│ 知识库 │配额计量│ │ +│ ├────────┼────────┼────────┼────────┼────────┴────────┴────────┤ │ +│ │ task │wardrobe│compliance│ notify │ │ │ +│ │任务中心│ 衣橱V2 │合规出口 │ 通知 │ │ │ +│ └────────┴────────┴─────────┴────────┴────────────────────────┘ │ +└───────────────────────────────────────────────────────────────────────┘ + ▼ +┌───────────────────────────────────────────────────────────────────────┐ +│ L5 AI 能力层（可独立部署与扩容，对上以内部 API 暴露） │ +│ ┌──────────────┬──────────────┬──────────────┬──────────────┐ │ +│ │ llm-gateway │ vision-svc │retrieval-svc │ rules-engine │ │ +│ │多模型路由 │分割/关键点/ │混合检索+重排 │决策表求值+ │ │ +│ │Prompt版本 │色值采样/体型 │ │可解释路径 │ │ +│ ├──────────────┼──────────────┼──────────────┴──────────────┤ │ +│ │ matting-svc │ tryon-svc │ │ │ +│ │批量抠图 │换装/发型(GPU)│ │ │ +│ └──────────────┴──────────────┴─────────────────────────────┘ │ +└───────────────────────────────────────────────────────────────────────┘ + ▼ +┌───────────────────────────────────────────────────────────────────────┐ +│ L6 数据层 │ +│ PostgreSQL + pgvector（业务/知识库/向量/事件）· Redis（缓存/队列/限流） │ +│ COS 四桶（临时/用户内容/知识素材/报告产物）· CLS（日志与审计） │ +└───────────────────────────────────────────────────────────────────────┘ + + ┌──────────────────────────────┐ + 横向贯穿： │ Celery Workers（gpu/cpu/io/beat）│ + │ 可观测性（OTel/Prom/Grafana） │ + │ 配置与密钥（SSM/KMS） │ + └──────────────────────────────┘ +``` + +### 3.2 为什么是「模块化单体 + 独立 AI 服务」 + +这是本架构最关键的一个取舍，理由： + +**业务域做单体**：identity/profile/report/agent/billing 之间事务关联紧密（一次报告生成要扣配额、写画像、写记忆、记成本）。拆成微服务后这些操作就需要分布式事务或最终一致性补偿，对 4~6 人团队是净损失。单进程内一个数据库事务就解决了。 + +**AI 能力做独立服务**：它们的资源画像与业务代码完全不同——GPU 依赖、模型文件体积、推理并发模型、扩缩容节奏都不一样。混在一个进程里会导致「换装排队把 API 拖慢」。独立部署后可以单独限流、单独扩容、单独重启。 + +**但单体不等于混乱**。硬性规则： + +1. 每个域是一个 Python 包，**只能通过对方暴露的 service 接口调用，禁止直接查对方的表**。 +2. 领域逻辑放在 `packages/domain`，不依赖 FastAPI、不依赖数据库会话，可纯单元测试。 +3. 跨域的写操作通过**域内事件**（进程内事件总线 + 持久化 outbox）解耦，例如「报告完成」事件被 profile（写画像）、memory（写记忆）、notify（推送）、billing（结算成本）分别消费。 +4. 数据库虽是单库，但表按域前缀命名，**为将来拆库预留边界**。 + +**演进触发条件**：当某个域的写入 QPS 或数据量成为瓶颈，或需要独立发布节奏时，按 §19 的路径拆出。不要提前拆。 + +--- + +## 4. 模块职责与依赖 + +### 4.1 业务域模块清单 + +| 模块 | 职责 | 关键对外能力 | 不负责 | +| --- | --- | --- | --- | +| `identity` | 账号、登录、会话、设备、游客迁移、同意授权记录 | `login()` `get_current_user()` `merge_guest()` `record_consent()` | 权益判定（归 billing） | +| `profile` | 用户画像（诊断结论）+ 分层记忆系统 | `get_profile()` `get_memory_snapshot()` `write_memory()` `resolve_conflict()` | 报告生成流程 | +| `report` | 报告触发判定、生成编排、版本管理、分享 | `can_trigger()` `create_report()` `get_report()` `create_share()` | 具体的视觉分析与文案生成（调 AI 层） | +| `agent` | 会话管理、意图识别、上下文组装、生成编排 | `chat_stream()` `extract_preference()` | 知识检索实现（调 retrieval） | +| `tryon` | 换装/发型的业务编排、素材校验、结果管理 | `create_tryon_task()` `get_result()` | GPU 推理（调 tryon-svc） | +| `kb` | 知识实体/关系/规则/素材的读写与发布 | `query_entities()` `get_rules()` `publish()` | 检索算法（调 retrieval） | +| `billing` | **V1**：配额账本、流水、周期重置、任务奖励发放。**V2 增**：会员、订单、IAP 校验 | `check_quota()` `reserve()` `commit()` `refund()` `grant()` | 定价策略配置（配置化）；V1 无支付相关职责 | +| `task` | 统一任务中心：创建、状态机、进度、查询、取消 | `submit()` `get_status()` `list_user_tasks()` | 具体任务实现（Worker） | +| `compliance` | **统一合规出口**：审核、水印、元数据标识、内容编号登记、审计 | `moderate()` `publish_asset()` `register_content()` | 业务判断 | +| `notify` | 推送、应用内消息、Token 管理 | `push()` `notify_task_done()` | — | +| `wardrobe` | 我的衣橱（V2） | — | — | + +### 4.2 依赖规则 + +``` +identity ← 所有模块（读当前用户） +billing ← report / tryon / agent（消耗资源前预扣） +task ← report / tryon（长耗时任务统一走它） +compliance ← report / tryon / agent / kb（所有产物出口） +profile ← report（写入）/ agent（读取+写入） +kb ← agent / report（读取） +``` + +**禁止的依赖**：`compliance` 不得反向依赖任何业务域（它必须能被任何模块安全调用）；`identity` 不得依赖其他业务域（避免登录链路被业务拖累）。 + +### 4.3 AI 能力层服务 + +| 服务 | 形态 | 内容 | 资源 | +| --- | --- | --- | --- | +| `llm-gateway` | 进程内包（V1）→ 独立服务（V2） | 多供应商路由、Prompt 版本、结构化输出约束、流式、缓存前缀优化、成本计量、限流降级 | IO 密集 | +| `vision-svc` | 独立服务 | 人像分割（云）、人体关键点（ONNX 自建）、色值采样、体型测算、人脸属性与关键点（云） | CPU（含 ONNX） | +| `retrieval-svc` | 进程内包 | 混合检索：硬过滤 → 规则命中 → 向量召回 → BM25 → 重排 → 解释路径 | CPU + PG | +| `rules-engine` | 进程内包 | 决策表求值、硬约束校验、命中链输出 | CPU | +| `matting-svc` | 离线批处理 | BiRefNet 抠图 + 白底标准化 + 规格校验 | GPU（按需） | +| `tryon-svc` | 独立服务（现有服务改造） | 换装三工作流、发型更换/发色 | GPU（常驻或按需） | + +**`llm-gateway` 为何 V1 先做进程内包**：它没有独立的资源诉求（纯 IO），拆成服务只增加一跳网络。但它的**接口必须按远程调用来设计**（无共享内存假设、明确超时、可序列化的入参出参），这样 V2 拆出去时零成本。 + +### 4.4 现有换装服务的改造要求 + +既然服务自有可控（`TD-00` 前提），必须做以下改造，否则它会成为整个系统的不稳定源： + +| 改造项 | 现状问题 | 要求 | +| --- | --- | --- | +| 鉴权 | 可能是开放接口 | 改为内部服务，仅允许内网/网关调用，带服务间令牌 | +| 调用模式 | 同步长连接 | 改为**提交任务 + 回调通知**（或提供任务查询接口），避免长连接占用 | +| 幂等 | 无 | 接受 `idempotency_key`，重复提交返回同一结果 | +| 并发控制 | 无 | 明确最大并发数并对外暴露，让上游队列按容量限流 | +| 成本埋点 | 无 | 每次推理返回 `gpu_seconds` 与模型版本，供成本归因 | +| 结果存储 | 直传阿里云 OSS | 改为写入腾讯云 COS（统一存储与生命周期治理）；历史数据做迁移或双读 | +| 输入校验 | 未知 | 前置校验图片规格、人脸存在性、单品白底图规格，尽早失败 | +| 版本管理 | 未知 | 模型/工作流版本号随结果返回，便于回溯效果变化 | + +--- + +## 5. 技术栈总览 + +| 层次 | 选型 | 决策依据 | +| --- | --- | --- | +| 客户端 | HarmonyOS ArkTS + ArkUI | `TD-01` | +| 端侧能力 | Account Kit / Push Kit（V1）；IAP Kit / Core Speech Kit（V2） | `TD-15`~`TD-17`、`TD-14`、`TD-28` | +| 接入 | 腾讯云 CLB + Nginx + CDN | `TD-03` | +| 服务端 | Python 3.12 + FastAPI + Uvicorn/Gunicorn | `TD-02` | +| ORM/迁移 | SQLAlchemy 2.0 (async) + Alembic | `TD-02` | +| 校验 | Pydantic v2（同时用于 LLM 结构化输出约束） | `TD-02` | +| 任务 | Celery + Redis（gpu/cpu/io/beat 四队列） | `TD-11` | +| 数据库 | PostgreSQL 16 + pgvector | `TD-08` | +| 缓存 | Redis 7 | — | +| 存储 | 腾讯云 COS（4 桶）+ CDN | `TD-03` | +| 大模型 | DeepSeek（主）+ 智谱 GLM（备/视觉） | `TD-04` | +| Embedding | BGE-M3（自建 ONNX） | `TD-22` | +| 视觉 | 腾讯云人脸识别 + RTMPose(ONNX) + BiRefNet | `TD-05`~`TD-07` | +| 审核 | 腾讯云天御 IMS/TMS | `TD-13` | +| 渲染 | Playwright + Chromium（服务端长图/PDF） | `TD-12` | +| 可观测 | OpenTelemetry + Prometheus + Grafana + CLS | `TD-24` | +| 部署 | Docker + Docker Compose（V1）→ TKE（V2） | `TD-03` | +| CI/CD | GitHub Actions 或腾讯云 CODING；ruff + mypy + pytest 卡关 | `TD-02` | + +--- + +## 6. 数据模型 + +### 6.1 设计原则 + +1. **单库多域**，表名以域前缀区分（`id_`/`pf_`/`rp_`/`kb_`/`ag_`/`tr_`/`bl_`/`tk_`/`cp_`）。 +2. **主键统一用雪花 ID（bigint）**，不用自增（避免枚举攻击与将来分库冲突），不用 UUID 作主键（索引局部性差）。对外暴露的 ID 做混淆编码。 +3. **不存人脸原图，不存可反推生物特征的数据**。诊断结果只存分类标签与色值等派生量（`TD-20`）。 +4. **所有涉及配额/金额的表都有幂等键与流水**，任何余额变更必须有对应流水记录，余额可由流水重算校验。V1 虽不涉及金钱，此原则同等适用 —— 用户对"次数被白扣"的敏感度不比扣钱低。 +5. **软删除 + 硬删除双轨**：常规软删除；账号注销走**硬删除任务**（合规要求，见《合规与安全方案》）。 +6. JSONB 用于「结构会演进但不需要索引全部字段」的场景（诊断结论、规则条件、检索轨迹）；需要过滤的字段一律提升为列。 + +### 6.2 核心表清单 + +#### identity 域 + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `id_user` | `user_id` PK, `status`, `nickname`, `avatar_key`, `register_source`, `created_at`, `last_active_at`, `deleted_at` | 内部主键，与外部身份解耦 | +| `id_user_identity` | `user_id`, `provider`('huawei'), `union_id`, `open_id`, UNIQUE(`provider`,`union_id`) | 一个用户可有多个外部身份 | +| `id_guest` | `guest_id`, `device_fp`, `merged_to_user_id`, `created_at` | 游客数据，登录后合并 | +| `id_device` | `device_id`, `user_id`, `push_token`, `os_version`, `last_seen_at` | 推送 Token 管理 | +| `id_consent` | `consent_id`, `user_id`, `consent_type`('terms'/'privacy'/'face'/'minor'), `doc_version`, `granted_at`, `revoked_at`, `client_ip`, `ua` | **合规留证**：人脸的单独同意必须独立成行 | +| `id_session` | `session_id`, `user_id`, `refresh_token_hash`, `expire_at`, `revoked` | 刷新令牌服务端可撤销 | + +#### profile 域（画像与记忆） + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `pf_profile` | `profile_id`, `user_id`, `label`, `is_default` | **预留多档案**（帮家人诊断的场景），V1 只创建默认档案 | +| `pf_diagnosis` | `diagnosis_id`, `profile_id`, `source_report_id`, `dimensions` JSONB, `version`, `overall_confidence`, `created_at` | 34 个诊断维度的结构化结论；按版本追加，不覆盖 | +| `pf_memory` | `memory_id`, `user_id`, `layer`(L0~L5), `mem_key`, `mem_value` JSONB, `confidence` numeric, `status`('active'/'pending_confirm'/'archived'/'rejected'), `source`('explicit'/'implicit'/'report'/'behavior'), `evidence_ref`, `valid_from`, `last_reinforced_at`, `decay_after`, `created_at` | 记忆项主表；索引 (`user_id`,`layer`,`status`) | +| `pf_memory_event` | `event_id`, `memory_id`, `action`('create'/'reinforce'/'decay'/'conflict'/'user_edit'/'delete'), `detail` JSONB, `created_at` | 记忆变更审计，支撑「我的记忆」页面的可解释性 | +| `pf_memory_snapshot` | `user_id`, `snapshot` JSONB, `token_count`, `content_hash`, `built_at`, `expire_at` | 注入 LLM 的画像摘要缓存，避免每轮重算 | + +#### report 域 + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `rp_report` | `report_id`, `user_id`, `profile_id`, `tier`('basic'/'full'), `status`, `version`, `result` JSONB, `model_info` JSONB, `content_code`, `rendered_asset_key`, `cost_cents`, `created_at`, `completed_at` | `content_code` 为 AI 标识内容编号（`TD-21`） | +| `rp_input` | `input_id`, `report_id`, `questionnaire` JSONB, `photo_meta` JSONB, `derived_features` JSONB | **只存派生特征与图片元信息，不存原图** | +| `rp_share` | `share_id`, `report_id`, `share_token`, `expire_at`, `view_count`, `revoked` | 分享链接可失效、可撤回 | + +#### kb 域（知识库） + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `kb_entity` | `entity_id`, `entity_type`(12 类), `name`, `attrs` JSONB, `status`('draft'/'reviewing'/'published'/'archived'), `version`, `source`, `license`, `updated_by` | 12 类实体统一表 + `attrs` 差异化 | +| `kb_relation` | `from_id`, `rel_type`, `to_id`, `weight`, `confidence`, `evidence` | 邻接表，递归 CTE 做多跳（`TD-09`） | +| `kb_rule` | `rule_id`, `version`, `status`, `priority`, `conditions` JSONB, `effects` JSONB, `is_hard`, `evidence`, `author`, `reviewer`, `published_at` | 决策表（`TD-10`） | +| `kb_chunk` | `chunk_id`, `entity_id`, `chunk_type`, `text`, `embedding` vector(1024), `embedding_model`, `embedding_version`, `tsv` tsvector | 向量 + 全文双索引，支撑混合检索 | +| `kb_asset` | `asset_id`, `entity_id`, `asset_type`, `cos_key`, `spec_check` JSONB, `tryon_ready` bool, `review_status`, `license` | `tryon_ready` 是换装闭环的关键标志位 | +| `kb_color` | `color_id`, `season_code`, `role`('base'/'accent'/'avoid'), `lab_l`,`lab_a`,`lab_b`, `hex`, `name_cn` | 自建色板（`TD-18`） | +| `kb_gap` | `gap_id`, `query_text`, `filter_ctx` JSONB, `hit_count`, `first_seen_at` | 知识缺口埋点：无检索结果的查询，驱动内容生产 | + +#### agent 域 + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `ag_conversation` | `conv_id`, `user_id`, `title`, `rolling_summary`, `status`, `msg_count`, `created_at` | 长会话滚动摘要存这里（L4 记忆） | +| `ag_message` | `msg_id`, `conv_id`, `role`, `content`, `intent`, `retrieval_trace` JSONB, `rule_hits` JSONB, `model`, `tokens_in/out/cached`, `cost_cents`, `moderation` JSONB, `created_at` | `retrieval_trace` + `rule_hits` 让每个回答可复盘 | +| `ag_feedback` | `feedback_id`, `msg_id`, `rating`, `reason`, `created_at` | 驱动隐式偏好推断与质量评估 | + +#### tryon 域 + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `tr_task` | `task_id`, `user_id`, `workflow_type`, `input_refs` JSONB, `result_asset_key`, `gpu_seconds`, `model_version`, `content_code`, `cost_cents` | 与统一任务中心 `tk_task` 一对一关联 | +| `tr_favorite` | `fav_id`, `user_id`, `asset_key`, `tags`, `created_at` | 用户收藏的效果图 | + +#### task 域（统一任务中心） + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `tk_task` | `task_id`, `user_id`, `task_type`('report'/'tryon'/'hairstyle'/'matting'/'render'), `status`, `progress`, `stage_text`, `idempotency_key` UNIQUE, `payload` JSONB, `error_code`, `retry_count`, `points_reserved`, `submitted_at`, `started_at`, `finished_at`, `eta_seconds` | **全系统唯一的长耗时任务视图**，前端任务中心直接读它 | + +#### billing 域（V1 为配额与计量，无支付） + +> **V1 不接支付**（`TD-28`）。本域在 V1 的职责是配额限制与计量。**关键设计：表结构一次做到位，V2 上支付时不需要迁移**。 + +| 表 | 关键字段 | V1 | 说明 | +| --- | --- | :--: | --- | +| `bl_wallet` | `user_id` PK, `balance`, `version`（乐观锁） | ✅ | V1 存「可用额度」，V2 语义扩展为点数余额。**同一张表，不改结构** | +| `bl_ledger` | `tx_id`, `user_id`, `delta`, `tx_type`, `reason`, `ref_type`, `ref_id`, `balance_after`, `idempotency_key` UNIQUE, `created_at` | ✅ | **流水是真相**，余额是缓存。`tx_type` V1 只用 `system_grant`/`consume`/`refund`，V2 增加 `purchase`/`gift` —— 这是 V1→V2 免迁移的关键 | +| `bl_quota` | `user_id`, `quota_key`, `period_key`, `used`, `limit_value` | ✅ | 周期配额计量（日/月/终身），按 `period_key` 自然重置，无需定时任务清零 | +| `bl_quota_rule` | `quota_key`, `period_type`, `base_limit`, `task_bonus_max`, `hard_cap` | ✅ | 配额规则配置化（`FR-BILL-04`），改配置不发版 | +| `bl_membership` | `user_id`, `level`, `valid_from`, `valid_to`, `source_order_id`, `auto_renew` | ❌ V2 | 会员 | +| `bl_order` | `order_id`, `user_id`, `product_id`, `product_type`, `price_cents`, `platform`('huawei_iap'), `purchase_token` UNIQUE, `status`, `verified_at`, `raw_receipt` JSONB | ❌ V2 | `purchase_token` 唯一约束防重复发货（`TD-16`） | + +> **原 `bl_point_tx` 改名为 `bl_ledger`**：V1 阶段它记录的是配额流水而非点数流水，用 `point` 命名会在 V1 造成误解。改用中性名称，同时新增 `tx_type` 字段承载两个阶段的语义差异。 + +#### compliance 域 + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `cp_content_registry` | `content_code` PK(27 位), `content_type`, `ref_type`, `ref_id`, `provider_code`, `model_info` JSONB, `generated_at` | AI 生成内容编号登记（`TD-21`） | +| `cp_moderation_log` | `log_id`, `target_type`, `target_id`, `provider`, `suggestion`, `labels` JSONB, `action`, `created_at` | 审核留证 | +| `cp_audit_log` | `audit_id`, `actor_type`, `actor_id`, `action`, `target`, `before` JSONB, `after` JSONB, `ip`, `created_at` | 后台操作审计，知识库改动必须留痕 | +| `cp_data_request` | `request_id`, `user_id`, `type`('export'/'delete'), `status`, `completed_at` | 个人信息导出/删除请求（法定权利） | + +#### 观测与成本 + +| 表 | 关键字段 | 说明 | +| --- | --- | --- | +| `ob_ai_call` | `call_id`, `user_id`, `scene`, `provider`, `model`, `tokens_in/out/cached`, `latency_ms`, `cost_cents`, `success`, `error_code`, `ref_type`, `ref_id`, `created_at` | **成本归因的唯一数据源**，按月分区 | +| `ob_event` | `event_id`, `user_id`, `event_name`, `props` JSONB, `client_ts`, `server_ts` | 埋点事件，按月分区（`TD-23`） | + +### 6.3 诊断维度的存储形态 + +34 个诊断维度用 `pf_diagnosis.dimensions` JSONB 存储，但**每个维度都是结构化三元组**，不是自由文本： + +```json +{ + "color_season": { + "value": "浅暖柔和型", + "confidence": 0.82, + "evidence": ["skin_lab:[68.2,12.4,18.7]", "hair_lab:[24.1,6.2,9.8]", "contrast:low"], + "source": "vision+rule", + "rule_hits": ["R-COLOR-0021", "R-COLOR-0034"] + }, + "body_shape": { + "value": "X型", + "confidence": 0.76, + "evidence": ["shoulder_hip_ratio:1.02", "waist_hip_ratio:0.71"], + "source": "vision+rule", + "rule_hits": ["R-BODY-0007"] + } +} +``` + +**为什么必须带 `confidence` 和 `evidence`**：低置信度维度要在报告中降级表述（「你的体型偏向 X 型」而不是断言），并且要能在用户质疑时说明依据。这也是记忆系统冲突消解的输入——用户显式反馈会覆盖低置信度的机器推断。 + +--- + +## 7. 关键链路设计 + +### 7.1 美学报告生成（最复杂的链路） + +``` +客户端 API task/Worker AI 能力层 + │ │ │ │ + │ 1.POST /reports │ │ │ + │ (idempotency_key) │ │ │ + ├───────────────────────▶│ │ │ + │ │ 2.触发资格校验 │ │ + │ │ (已有报告?配额?) │ │ + │ │ 3.配额预扣(reserve) │ │ + │ │ 4.创建 tk_task │ │ + │◀── task_id ────────────┤ │ │ + │ │ 5.入队(cpu队列) │ │ + │ ├───────────────────▶│ │ + │ 6.订阅进度(轮询/Push) │ │ 7.拉取临时区原图 │ + │ │ ├───────────────────▶│ + │ │ │ 8.内容审核(图片) │ + │ │ │ 9.人像分割 │ + │ │ │ 10.人体关键点(ONNX) │ + │ │ │ 11.人脸关键点+属性 │ + │ │ │ 12.色值采样(Lab) │ + │ │ │ 13.体型/季型/脸型测算│ + │ │ │◀── 结构化诊断 ──────┤ + │ │ │ 14.**立即删除原图** │ + │ │ │ 15.规则引擎求值 │ + │ │ │ (建议/禁忌/依据) │ + │ │ │ 16.知识库检索 │ + │ │ │ (配色/单品/发型) │ + │ │ │ 17.LLM 生成文案 │ + │ │ │ (结构化输出约束) │ + │ │ │ 18.生成后校验 │ + │ │ │ (禁忌违反=0?色值在板内?)│ + │ │ │ 19.文本审核 │ + │ │ │ 20.渲染长图(Playwright)│ + │ │ │ 21.合规出口: │ + │ │ │ 水印+元数据+编号登记│ + │ │ │ 22.写画像/记忆/成本 │ + │ │ │ 23.配额 commit │ + │ │ │ 24.Push 通知 │ + │◀──── 报告就绪 ─────────┴────────────────────┤ │ +``` + +**关键工程要求**： + +| 要求 | 做法 | +| --- | --- | +| **原图生命周期** | 上传直传 COS 临时桶（预签名 URL，不经过应用服务器）；Worker 拉取后处理，第 14 步显式删除；桶级 2 小时生命周期作为兜底 | +| **失败即退款** | 任何步骤失败，`tk_task` 转 failed 并触发 `refund()`；用户看到明确原因与「重试」入口 | +| **分步可恢复** | 第 7~13 步的视觉分析结果落库为中间态，LLM 或渲染失败时**不需要重跑视觉分析**（也就不需要用户重新上传） | +| **生成后校验不可跳过** | 校验失败最多重试 2 次（提高约束强度），仍失败则降级为「规则直出模板文案」，绝不放行违规内容 | +| **等待体验** | 阶段文案随进度更新；预估时间基于历史 p50；超过阈值转为「后台生成 + 完成推送」，允许用户离开页面 | +| **幂等** | 相同 `idempotency_key` 重复提交返回同一 `task_id`，不重复扣点 | + +### 7.2 Agent 对话（含检索与画像注入） + +``` +用户提问 + │ + ▼ +① 输入审核（TMS + 备案关键词库）───拦截──▶ 返回安全提示，记录日志 + │ 通过 + ▼ +② 意图识别（轻量模型 / 规则前置） + ├─ 场景咨询 / 单品搭配 / 风格建议 / 闲聊 / 越界（医疗、身材评判等） + ▼ +③ 上下文组装（token 预算严格分配） + ├─ 系统提示词（固定前缀，放最前以命中缓存） + ├─ 画像摘要（L0/L1/L2，来自 pf_memory_snapshot） + ├─ 会话滚动摘要（L4） + └─ 检索结果（见 ④） + ▼ +④ 混合检索（retrieval-svc） + ├─ a. 硬过滤：SQL WHERE（季型/体型禁忌/场合/季节） + ├─ b. 规则命中：rules-engine 求值，取建议与禁忌 + ├─ c. 向量召回：pgvector 相似度 Top-K + ├─ d. 关键词召回：tsvector BM25 + ├─ e. 融合重排：RRF + 规则权重 + 新鲜度 + └─ f. 输出：知识片段 + 命中规则 ID + 图谱路径（供解释链） + ▼ +⑤ LLM 生成（llm-gateway，流式 SSE） + └─ 约束：只能使用检索到的知识；硬禁忌不得出现；输出结构化搭配卡片 + ▼ +⑥ 生成后校验：禁忌违反检查 + 色值在色板内检查 + ▼ +⑦ 输出审核（TMS）───拦截──▶ 重新生成或返回兜底 + ▼ +⑧ 落库：message + retrieval_trace + rule_hits + 成本 + ▼ +⑨ 异步：偏好抽取 → 写入 L2 记忆（显式）/ 生成待确认候选（隐式） +``` + +**Token 预算分配（必须硬性限制，否则成本会失控）**： + +| 部分 | 预算 | 说明 | +| --- | --- | --- | +| 系统提示词 | ≤ 800 | 固定不变，放在最前以最大化缓存命中 | +| 画像摘要 | ≤ 500 | 从记忆快照裁剪，按置信度与相关性排序 | +| 会话摘要 | ≤ 400 | 滚动压缩 | +| 检索知识 | ≤ 1500 | 重排后取前 N 条，超出则截断而非全塞 | +| 用户当前输入 | ≤ 500 | 超长提示精简 | +| **输入合计** | **≤ 3700** | | +| 输出 | ≤ 800 | 超长回答不利于阅读，也贵 | + +**缓存前缀纪律**：系统提示词与稳定知识片段必须放在 prompt 头部且**不含时间戳、随机 ID、用户昵称等变量**，否则缓存永远不命中，输入成本翻数倍（`TD-04`）。 + +### 7.3 换装任务 + +``` +① 前置校验：单品是否 tryon_ready？用户照片是否合规且质量达标？ +② 配额：check_quota → reserve +③ 创建 tk_task(type=tryon) → 入 gpu 队列 +④ Worker：调 tryon-svc（带 idempotency_key），拿到 gpu_seconds +⑤ 结果图审核（IMS） +⑥ 合规出口：水印「AI 生成」+ 写入元数据与内容编号 → 存 COS 用户内容桶 +⑦ commit 配额、记录成本、Push 通知 +⑧ 失败：区分可重试（网络/排队超时）与不可重试（输入非法/审核拒绝），后者立即退点 +``` + +**队列即容量**：`gpu` 队列的并发上限直接由 GPU 容量决定，并把「当前排队位次 + 预估等待」返回给用户。**不要让请求无限积压**——超过阈值直接拒绝新任务并提示稍后再试，这比让用户等 10 分钟体验更好。 + +### 7.4 配额消耗（V1）与 IAP 支付（V2） + +#### V1：配额三段式 + +``` +校验：GET 配额 → 判定 bl_quota.used < limit_value + task_bonus + ↓ （服务端硬校验，客户端提示仅为体验，FR-BILL-06） +预扣：reserve → bl_ledger 写 delta=-N, tx_type=consume, status=reserved + ↓ +任务执行（Celery，长耗时） + ↓ +成功：commit → 确认扣除，status=committed +失败：refund → 写反向流水 delta=+N, tx_type=refund（带 idempotency_key） + +发放：任务奖励 → bl_ledger 写 delta=+N, tx_type=system_grant + ↓ （同一任务同一周期幂等，FR-BILL-03） +``` + +**为什么预扣而不是直接扣**：长耗时任务可能失败，直接扣会产生「扣了额度没拿到结果」的客诉。先冻结再确认，失败自动释放。V1 虽然不涉及金钱，这个问题依然存在 —— **用户对"次数被白扣"的敏感度不比扣钱低**，而且 V1 没有客服退款兜底手段，只能靠机制保证。 + +**对账**：所有变更都写流水，余额可由流水重算校验（每日定时，不一致则告警）。V1 就要做，否则 V2 上支付时对账逻辑得从零开发且无历史数据验证。 + +#### V2：IAP 支付（V1 不实现） + +``` +购买：客户端 IAP 下单 → 支付成功拿 purchase_token + ↓ + POST /orders/verify (purchase_token) + ↓ + 服务端调华为 IAP 校验接口（**必须服务端校验**，不可信客户端结果） + ↓ + UNIQUE(purchase_token) 保证只发货一次 + ↓ + 发放点数/会员 → 写 bl_ledger（tx_type=purchase，带 idempotency_key） +``` + +**V1→V2 的衔接成本被刻意压到最低**：消耗侧逻辑（reserve/commit/refund）完全复用，只需新增「购买」这一条发放路径。这是 §6.2 中坚持让 V1 与 V2 共用 `bl_wallet` / `bl_ledger` 的收益。 + +### 7.5 统一合规出口 + +**所有对外生成物必须经过 `compliance.publish_asset()`，没有例外。** + +```python +async def publish_asset( + raw: bytes | str, + content_type: Literal["image", "text", "pdf"], + ref: ContentRef, + model_info: ModelInfo, +) -> PublishedAsset: + # 1. 内容审核（fail-close：审核服务不可用则拒绝发布） + # 2. 生成 27 位内容编号并登记 cp_content_registry + # 3. 显式标识：图片加可见「AI 生成」水印；文本加提示语 + # 4. 隐式标识：写入文件元数据（属性信息 + 服务提供者编码 + 内容编号） + # 5. 上传目标 COS 桶，返回带签名的访问地址 +``` + +**必须专门测试的点**：图片经过 CDN、缩略图处理、客户端保存与再次分享后，**元数据是否仍然存在**。很多图片处理链路会剥离 EXIF/XMP，一旦剥离就等于没做隐式标识（`TD-21`）。 + +--- + +## 8. AI 能力层设计 + +### 8.1 LLM 网关 + +```python +class LLMGateway: + async def complete( + self, + scene: Scene, # 场景决定模型档位、超时、预算 + messages: list[Message], + schema: type[BaseModel] | None, # 需要结构化输出时传 Pydantic 模型 + stream: bool = False, + user_id: int | None = None, + ) -> Completion | AsyncIterator[Chunk]: + ... +``` + +**内置能力**： + +| 能力 | 实现要点 | +| --- | --- | +| 场景化路由 | `scene → (provider, model, temperature, max_tokens, timeout)` 全部配置化，改模型不改代码 | +| 故障转移 | 主供应商超时/5xx/限流 → 自动切备用；连续失败触发熔断，冷却后半开探测 | +| 结构化输出 | 传入 Pydantic Schema，网关负责 JSON Schema 约束 + 解析失败重试 + 校验 | +| Prompt 版本 | Prompt 存文件（随代码版本化）+ 场景绑定版本号；A/B 时按用户哈希分流 | +| 成本计量 | 每次调用写 `ob_ai_call`，含缓存命中 token 数 | +| 预算保护 | 场景级日预算 + 用户级频控；超限降级到轻量模型或拒绝 | +| 审核联动 | 输入输出审核在网关内统一完成，业务方无需关心 | +| 可复现 | 记录 prompt 版本 + 模型版本 + 参数，便于回溯「为什么当时这么答」 | + +### 8.2 视觉服务 + +``` +POST /internal/vision/analyze + ├─ segment_portrait → 腾讯云 SegmentPortraitPic → 前景掩膜 + ├─ body_keypoints → RTMPose ONNX → 关键点（肩/髋/踝定高） + ├─ face_landmarks → 腾讯云 AnalyzeFace(90点) / AnalyzeDenseLandmarks(888点，仅全面报告) + ├─ face_attributes → 腾讯云 DetectFaceAttributes(Skin/Hair/Shape/Eye/...) + ├─ color_sampling → 自研：按关键点定位采样区，转 Lab，稳健统计（去高光/阴影） + └─ body_measure → 自研：掩膜宽度剖面法（TD-06） +返回：结构化特征 + 每项置信度 + 质量问题标记（模糊/遮挡/多人/姿态异常） +``` + +**质量门禁前置**：图片质量不达标（多人、遮挡、侧脸过大、光线过暗）应在分析前就返回明确的重拍指引，而不是硬算出一个低置信度结果。**用户宁愿重拍一次，也不愿收到一份错的报告。** + +### 8.3 混合检索的实现 + +核心是一条 SQL 完成硬过滤 + 向量召回（这正是选 pgvector 的收益）： + +```sql +WITH filtered AS ( + SELECT c.chunk_id, c.entity_id, c.text, c.embedding, e.attrs + FROM kb_chunk c + JOIN kb_entity e ON e.entity_id = c.entity_id + WHERE e.status = 'published' + AND e.entity_type = ANY(:entity_types) + AND (:occasion IS NULL OR e.attrs->'occasions' ? :occasion) + AND NOT (e.attrs->'avoid_body_shapes' ? :body_shape) -- 硬禁忌直接排除 +), +vec AS ( + SELECT chunk_id, 1 - (embedding <=> :query_vec) AS vec_score + FROM filtered ORDER BY embedding <=> :query_vec LIMIT 50 +), +kw AS ( + SELECT chunk_id, ts_rank(tsv, plainto_tsquery('simple', :query_text)) AS kw_score + FROM kb_chunk WHERE tsv @@ plainto_tsquery('simple', :query_text) LIMIT 50 +) +SELECT ... -- RRF 融合，再叠加规则权重与新鲜度 +``` + +**重排权重**（可配置，需用黄金集调参）：`最终分 = 0.45×向量 + 0.2×关键词 + 0.25×规则权重 + 0.1×新鲜度`。规则命中的条目要有明显加权——**专业规则的可信度高于语义相似度**，这是自建知识库的意义所在。 + +### 8.4 记忆系统的读写 + +**读（注入）**： +``` +get_memory_snapshot(user_id, budget_tokens) + → 优先级排序：L0 身份 > L1 画像 > L2 显式偏好 > L5 衣橱 > L3 事件 + → 过滤：status='active' AND confidence >= 阈值 + → 裁剪到预算内 → 缓存（hash 变更才重建） +``` + +**写**： +``` +显式（用户明确说的） → confidence=0.95，立即生效，回执告知用户「已记住」 +报告产出（机器诊断） → confidence=诊断置信度，写 L1 +行为推断（隐式） → 累积证据，达阈值生成 status='pending_confirm' + → 在合适时机征询确认，确认后才转 active +``` + +**衰减与冲突**：定时任务按 `decay_after` 降低未被强化的记忆置信度；同 key 冲突时**显式 > 报告 > 隐式**，时间新 > 时间旧，并写 `pf_memory_event` 留痕。用户在「我的记忆」页面的编辑拥有最高优先级且不可被自动覆盖。 + +--- + +## 9. API 设计规范 + +### 9.1 基本约定 + +| 项 | 约定 | +| --- | --- | +| 基础路径 | `/api/v1`，大版本进路径 | +| 风格 | 面向资源的 REST；流式对话用 SSE（`text/event-stream`） | +| 认证 | `Authorization: Bearer `（JWT，15 分钟）+ 刷新令牌（服务端可撤销） | +| 幂等 | 写操作支持 `Idempotency-Key` 头，服务端 24 小时内保证同键同结果 | +| 分页 | 游标分页（`cursor` + `limit`），不用 offset | +| 时间 | 全部 ISO 8601 UTC，客户端负责本地化 | +| 文档 | FastAPI 自动生成 OpenAPI，**契约先行**：先定 schema 再写实现 | + +### 9.2 统一响应 + +```json +{ "code": 0, "message": "ok", "data": { }, "request_id": "..." } +``` + +```json +{ "code": 40301, "message": "今日额度已用完", "data": { "required": 1, "remaining": 0, "reset_at": "..." }, + "request_id": "...", "hint": "明天恢复，或完成任务多换 3 次" } +``` + +**错误码分段**：`4xxxx` 客户端错误、`5xxxx` 服务端错误、`6xxxx` 外部依赖错误（便于监控区分「我们的问题」和「厂商的问题」）。每个错误码都要有**用户可读的 message** 和**可选的 hint（告诉用户怎么办）**——AI 产品的失败场景多，错误文案是体验的一部分。 + +### 9.3 主要接口清单 + +| 域 | 方法与路径 | 说明 | +| --- | --- | --- | +| 认证 | `POST /auth/huawei` `POST /auth/refresh` `POST /auth/guest` `POST /auth/merge` | 登录、刷新、游客、游客合并 | +| 用户 | `GET/PATCH /me` `POST /me/consents` `DELETE /me`（注销） | 含同意记录与注销 | +| 上传 | `POST /uploads/presign` | 返回 COS 临时桶预签名 URL，**图片不经应用服务器** | +| 报告 | `POST /reports` `GET /reports/{id}` `GET /reports` `POST /reports/{id}/share` `POST /reports/{id}/regenerate` | | +| 画像 | `GET /profile` `GET /profile/memories` `PATCH /profile/memories/{id}` `DELETE /profile/memories/{id}` | 「我的记忆」可见可控 | +| Agent | `POST /agent/conversations` `POST /agent/conversations/{id}/messages`（SSE） `POST /agent/messages/{id}/feedback` | | +| 换装 | `POST /tryon/tasks` `GET /tryon/tasks/{id}` `POST /tryon/results/{id}/favorite` | | +| 发型 | `GET /hairstyles` `POST /hairstyles/tasks` | | +| 任务 | `GET /tasks` `GET /tasks/{id}` `POST /tasks/{id}/cancel` | 任务中心 | +| 知识 | `GET /kb/items` `GET /kb/items/{id}` | 只读对外 | +| 配额 | `GET /quota` `GET /quota/ledger` `POST /quota/tasks/{task_key}/claim` | V1；`hint` 文案不得含价格字样（`FR-BILL-07`） | +| 支付 | ~~`GET /products` `POST /orders/verify`~~ | **V2 起** | +| 埋点 | `POST /events/batch` | 客户端批量上报 | + +--- + +## 10. 缓存策略 + +| 数据 | 位置 | TTL | 失效方式 | +| --- | --- | --- | --- | +| 记忆快照 | Redis | 1 小时 | 记忆写入时按 `user_id` 主动失效 | +| 知识检索结果 | Redis | 10 分钟 | 键含 query hash + 过滤条件 + 知识库版本号 | +| 规则集（已发布） | 进程内 + Redis | 5 分钟 | 发布时广播失效 | +| 色板 | 进程内 | 长期 | 版本号变更时重载 | +| 报告长图 | COS + CDN | 长期 | 报告版本变更生成新对象（不覆盖，便于回溯） | +| LLM 结果 | 不缓存业务层 | — | 依赖供应商 prompt 缓存降本，不做业务层结果缓存（个性化内容缓存意义不大） | +| 用户配额 | Redis 计数器 + PG 落账 | 周期 | 周期切换重置 | + +**知识库版本号是关键设计**：所有检索缓存键都带上全局 `kb_version`，知识库发布时版本号 +1，**所有旧缓存自然失效**，不需要精确追踪哪些缓存受影响。 + +--- + +## 11. 安全设计 + +### 11.1 认证与授权 + +- JWT 短期 access token（15 分钟）+ 服务端可撤销的 refresh token；登出/注销时撤销全部会话。 +- 所有资源访问必须校验归属（`report.user_id == current_user.id`），**不能只靠 ID 不可猜**。越权是这类应用最常见的漏洞。 +- 后台采用独立账号体系与独立域名/网段，不与用户端共用鉴权。 + +### 11.2 数据安全 + +| 数据 | 措施 | +| --- | --- | +| 人脸原图 | 临时桶、服务端加密、2 小时生命周期、处理后立即删除、访问全程走预签名 URL | +| 诊断结论 | 属敏感个人信息衍生数据，数据库加密存储敏感字段，日志中禁止打印 | +| 结果图 | 私有桶 + CDN 签名 URL（短期有效）+ 防盗链，禁止公开可读 | +| 密钥 | 全部走 SSM/KMS，禁止进代码、镜像、环境变量明文 | +| 日志 | 脱敏中间件：手机号、UnionID、图片 URL、诊断结论一律脱敏或不记录 | +| 备份 | PG 自动备份 + 定期恢复演练（**没演练过的备份等于没有备份**） | + +### 11.3 防刷与滥用 + +| 风险 | 措施 | +| --- | --- | +| 免费额度被批量刷取 | 设备指纹 + 华为账号绑定；同设备多账号限制；异常注册风控 | +| 换装接口被外部盗用 | 内网隔离 + 服务间令牌；对外接口强制登录 + 配额消耗 | +| 恶意图片攻击 | 上传前校验类型/尺寸/像素上限；解码走安全库；审核前置 | +| Prompt 注入 | 用户输入与系统提示词严格分区；输出侧校验；禁止用户内容影响工具调用决策 | +| 爬取知识库 | 对外接口只暴露必要字段，加频控与签名 | + +### 11.4 降级与熔断 + +每个外部依赖都要有明确的降级行为（见 §2 表格）。**唯一不允许降级的是内容审核**：审核服务不可用时按拦截处理（fail-close）。其他能力遵循 fail-soft，保证核心体验可用。 + +--- + +## 12. 性能与容量 + +### 12.1 性能目标（NFR） + +| 链路 | 指标 | 目标 | +| --- | --- | --- | +| 普通 API | p95 响应 | < 300ms | +| Agent 首字 | p95 | < 2s | +| Agent 整轮 | p95 | < 8s | +| 初级报告生成 | p50 / p95 | < 45s / < 90s | +| 全面报告生成 | p95 | < 180s（允许后台生成 + 推送） | +| 换装出图 | p95 | < 40s（受 GPU 容量约束，排队时间单独统计） | +| 知识检索 | p95 | < 200ms | +| 长图渲染 | p95 | < 8s | +| 可用性 | 月度 | ≥ 99.5%（V1） | + +**排队时间与执行时间必须分开统计**。混在一起看会得出错误结论：明明是 GPU 容量不足（该扩容），却被误判为推理慢（去优化模型）。 + +### 12.2 容量假设与压力点 + +以 1 万 DAU 为规划基线（V1 实际远低于此，用于确认架构不会在早期就撞墙）： + +| 资源 | 估算 | 压力点 | +| --- | --- | --- | +| API QPS | 峰值约 100~200 | 单机 FastAPI 多 worker 足够 | +| 报告生成 | 首日集中，后续每日新增用户量级 | CPU 队列 + 视觉分析，可水平扩 worker | +| 换装出图 | **最大瓶颈** | GPU 数量决定吞吐，靠队列削峰 + 配额限制需求 | +| PG 连接 | 需连接池（asyncpg pool + 上限保护） | 长事务与 Worker 争用，必须分离读写池 | +| 向量检索 | 十万级向量 | pgvector HNSW 足够，索引重建走低峰 | + +--- + +## 13. 成本模型 + +**架构上的硬性要求：每一次付费调用都必须落 `ob_ai_call`，并可归因到用户与功能。** 没有这张表，成本优化只能靠猜。 + +> ⚠️ **V1 不收费让这张表的地位更高，不是更低**（`TD-28`）。V1 没有收入，因此成本是唯一的财务变量；同时 `ob_ai_call` 是 **V2 定价的唯一数据来源** —— 单次真实成本与人均使用频次都从这里出。埋点缺失的功能，在 V2 定价时就是一个必须靠猜的空洞。**这一项不允许"先上线后补埋点"。** + +**V1 的成本上限是可以事前算准的确定值**（这是不收费换来的好处）： + +``` +月度 AI 成本上限 = MAU × Σ(各功能日配额上限 × 单次成本 × 30) +``` + +因为配额是服务端硬限制（`FR-BILL-06`），不存在超额路径，所以这是上限而非估计值。按 MAU 15 万、免费用户月成本上限 ¥8 计算，月度上限约 ¥12 万（产品方案 §5.3.1）。 + +单位成本核算公式（数值需在 Phase 0 验证任务中实测填入，此处为建模框架）： + +| 功能 | 成本构成 | 建模公式 | +| --- | --- | --- | +| 初级报告 | 人脸 API + 分割 API + 自建推理 + LLM + 审核 + 渲染 | `≈ C_face + C_seg + C_llm(in≈8k, out≈3k) + C_mod×n + C_render` | +| 全面报告 | 初级 + 稠密关键点 + 更长文案 | `≈ 初级 × 3~4` | +| Agent 单轮 | LLM（缓存命中后输入成本大幅下降）+ 检索 + 双向审核 | `≈ C_llm(in≈3.7k 多数缓存, out≈0.8k) + C_mod×2` | +| 换装单次 | GPU 秒数 + 审核 + 存储 + CDN | `≈ gpu_seconds × 单价 + C_mod + C_storage` | +| 抠图单件 | GPU 秒数（离线批量摊薄） | 批量跑，按批次成本 / 件数 | + +**必须设置的三道成本闸门**： + +1. **场景级日预算**：某功能超预算自动降级（切轻量模型/暂停非核心功能），并告警。 +2. **用户级频控**：配额硬上限（服务端校验，`FR-BILL-06`），防单用户异常消耗。 +3. **日成本预警**：日成本环比突增超过阈值立即告警——通常意味着有 bug（重试风暴、缓存失效）或被刷。 + +--- + +## 14. 部署架构 + +### 14.1 V1 部署（单可用区，Docker Compose） + +``` +腾讯云 VPC +├─ CLB（公网入口，TLS 终止） +├─ CVM-app（2~4 核） +│ ├─ nginx +│ ├─ api （FastAPI × N workers） +│ ├─ admin （极简运营后台） +│ ├─ worker-cpu （Celery: cpu 队列） +│ ├─ worker-io （Celery: io 队列） +│ ├─ beat （定时任务，单实例） +│ └─ vision-svc （ONNX 推理） +├─ CVM-gpu（按需启停） +│ ├─ tryon-svc （换装/发型推理） +│ ├─ worker-gpu （Celery: gpu 队列） +│ └─ matting （批量抠图，仅素材生产期运行） +├─ 云数据库 PostgreSQL（含 pgvector） +├─ 云数据库 Redis +├─ COS × 4 桶 + CDN +└─ CLS / 监控告警 +``` + +**GPU 实例按需启停**是 V1 最有效的成本手段：换装量小的时候没必要 7×24 常驻。实现方式是队列有积压时拉起、空闲一段时间后释放（配合任务中心的排队体验，用户可接受冷启动的额外等待）。 + +### 14.2 环境 + +| 环境 | 用途 | 数据 | +| --- | --- | --- | +| local | 本地开发 | Docker Compose 起 PG/Redis/COS 模拟；AI 能力走 mock 或少量真实调用 | +| dev | 联调 | 独立库；外部 API 用测试账号与低配额 | +| staging | 预发/验收 | 结构与生产一致，**保留可供监管抽查的测试通道与虚拟测试账号**（备案已完成，但变更备案与日常抽查仍需，`TD-19`） | +| prod | 生产 | — | + +### 14.3 发布 + +- 容器镜像 + 标签化版本；数据库迁移在发布流程中作为独立步骤执行（先迁移后发布，保证向后兼容）。 +- **迁移必须向后兼容**（加列不删列、先双写后切读），避免回滚时数据不兼容。 +- 灰度：按用户哈希分流；报告与 Agent 这类核心链路的 Prompt/规则变更必须先灰度 + 看黄金集回归。 + +--- + +## 15. 可观测性 + +| 类型 | 工具 | 关键内容 | +| --- | --- | --- | +| 链路追踪 | OpenTelemetry | 一次报告生成的完整 span 树（含各外部调用耗时），排障必需 | +| 指标 | Prometheus + Grafana | 三张看板：业务漏斗、AI 成本、任务健康（`TD-24`） | +| 日志 | CLS | 结构化 JSON，带 `request_id`/`user_id`/`task_id` 贯穿 | +| 审计 | `cp_audit_log` | 后台操作、知识库变更、权限变更 | +| 告警 | 云监控 + 企业微信/飞书 | 分级：P0（服务不可用/审核失效）、P1（任务失败率超阈值/成本突增）、P2（延迟劣化） | + +**必须能一键回答的三个问题**（这是可观测性的验收标准）： + +1. 「某用户说他的报告生成失败了」→ 用 `user_id` 找到 task，看到失败在哪一步、错误码、是否已退点。 +2. 「昨天成本涨了 3 倍」→ 按功能/模型分组的成本对比，定位到具体场景。 +3. 「换装最近变慢了」→ 区分是排队变长（扩容）还是推理变慢（模型/资源）。 + +--- + +## 16. 工程规范 + +### 16.1 仓库结构 + +``` +meida/ +├─ apps/ +│ ├─ api/ # FastAPI 应用（路由、依赖注入、中间件） +│ ├─ worker/ # Celery 任务定义 +│ └─ admin/ # 极简运营后台 +├─ services/ +│ ├─ vision/ # 视觉推理服务 +│ ├─ matting/ # 抠图批处理 +│ └─ tryon/ # 换装服务（改造纳管） +├─ packages/ +│ ├─ domain/ # 领域模型与业务规则（纯逻辑，无 IO，可纯单测） +│ ├─ llm/ # LLM 网关 +│ ├─ retrieval/ # 混合检索 +│ ├─ rules/ # 规则引擎 +│ ├─ memory/ # 记忆系统 +│ ├─ compliance/ # 审核 / 水印 / 元数据标识 +│ └─ shared/ # 配置、日志、错误、DB、COS、可观测 +├─ prompts/ # Prompt 模板（版本化，随代码走） +├─ migrations/ # Alembic +├─ tests/ +│ ├─ unit/ # 领域逻辑 +│ ├─ integration/ # 带 DB/Redis（testcontainers） +│ └─ golden/ # 黄金集回归（检索/规则/报告） +├─ deploy/ # Dockerfile / compose / CI 配置 +├─ docs/ # 本文档集 +└─ client-harmony/ # 鸿蒙 ArkTS 工程 +``` + +### 16.2 AI 辅助开发下的质量防线 + +既然主要由 AI 编码，人工 review 的带宽会成为瓶颈，因此**必须把规范变成机器可执行的检查**： + +| 防线 | 内容 | 卡关方式 | +| --- | --- | --- | +| 契约先行 | 接口先写 Pydantic schema 与 OpenAPI，再写实现 | 客户端类型由 OpenAPI 生成，schema 变更即可见 | +| 静态检查 | ruff（lint+format）+ mypy strict（覆盖 `packages/domain`、`packages/llm`） | CI 失败即阻断合并 | +| 分层依赖检查 | 用 import-linter 之类的工具声明层间依赖规则 | 跨域直接访问对方表 → CI 报错 | +| 黄金集回归 | 检索准确率、规则命中正确性、报告结构完整性、禁忌违反数=0 | 每次 PR 跑，指标退化即阻断 | +| 迁移检查 | Alembic 迁移必须可逆或明确标注不可逆 | Review 检查清单 | +| 敏感信息扫描 | 密钥/Token 扫描 | pre-commit + CI | + +**黄金集是最重要的一道**：AI 改代码时最容易破坏的是那些「没有断言保护的隐性行为」。检索链路和规则引擎必须有一套固定输入 → 期望输出的样本集，这既是质量防线，也是《美学知识库-建设方案》中质量保障章节的落地形式。 + +--- + +## 17. 架构演进路线 + +| 阶段 | 架构形态 | 触发条件 | +| --- | --- | --- | +| V1 | 模块化单体 + 独立 AI 服务；单机 Compose；PG 单库 | — | +| V1.5 | 读写分离；Redis 集群；GPU 自动伸缩 | 报告/换装量上升，PG 读压力显现 | +| V2 | 拆出 `llm-gateway`、`retrieval-svc` 为独立服务；引入 TKE | 需要独立发布节奏或独立扩容 | +| V2 | 多端（iOS/Android）→ 重新评估跨端框架 | 明确的多端商业需求（`TD-01`） | +| V3 | 向量迁 Qdrant/Milvus；事件流引入消息队列；数仓引入 ClickHouse | 向量 > 500 万 / 跨域事件复杂度上升 / 需要即席分析 | + +**演进纪律**：每一次架构升级都必须先出现**可测量的瓶颈**，再动手。提前架构化是这个阶段最大的浪费。 + +--- + +## 18. 架构决策记录（ADR 索引） + +| ADR | 决策 | 详见 | +| --- | --- | --- | +| ADR-01 | 客户端用鸿蒙原生 ArkTS，不用跨端框架 | `TD-01` | +| ADR-02 | 业务域用模块化单体，AI 能力独立服务 | §3.2 | +| ADR-03 | 向量检索用 pgvector，不引入专用向量库 | `TD-08` | +| ADR-04 | 图谱用 PG 邻接表 + 递归 CTE | `TD-09` | +| ADR-05 | 规则引擎自研数据驱动决策表 | `TD-10` | +| ADR-06 | 人体关键点自建（腾讯云已下线） | `TD-05` | +| ADR-07 | 体型测算用掩膜宽度剖面法 | `TD-06` | +| ADR-08 | 抠图用 BiRefNet，禁用 RMBG-2.0 | `TD-07` | +| ADR-09 | 自建 LLM 网关，双供应商路由 | `TD-04` | +| ADR-10 | 人脸原图不落盘，只存派生特征 | `TD-20` | +| ADR-11 | 统一合规出口，所有生成物必经 | `TD-21` | +| ADR-12 | 报告长图服务端渲染 | `TD-12` | +| ADR-13 | 配额预扣-确认-退还三段式；V1 与 V2 共用账本表 | §7.4、`TD-28` | +| ADR-14 | 统一任务中心承载全部长耗时任务 | §7 | + +--- + +## 19. 技术风险登记 + +| 风险 | 影响 | 概率 | 应对 | +| --- | --- | --- | --- | +| ~~备案登记周期拖延上线~~ | ~~最高~~ | **已消除** | ✅ **备案已完成**，此风险关闭（`TD-19`） | +| **备案范围与实际调用的模型不一致** | 高：超范围提供服务 | 中 | 核实备案覆盖的模型清单；LLM 网关已做多路由抽象，必要时 V1 先单路由（`TD-19` 残留项） | +| **素材自采产能不足** | 高：`tryon_ready` < 300 件则「建议→试穿」闭环不成立 | **中高** | 备案解除后这是最长工序（`TD-26`）。按周产能倒排，未达标则功能降级为「加入搭配」 | +| **全职顾问到岗延迟** | 中：规则库启动即延后，M2 顺延 | 中 | Phase 0 最早启动招聘（`TD-27`、`T-P0-20`） | +| 团队缺乏 ArkTS 经验 | 前端进度不确定 | 中 | 第一个任务就打通端到端骨架，尽早暴露问题 | +| 体型测算准确率不达标 | 报告核心结论不可信 | 中 | Phase 0 验证任务（≥80% 一致率）；不达标则降级表述 + 引入人工校准 | +| 换装成功率依赖白底图素材 | 核心闭环卡住 | 高 | 素材生产列为 Phase 1 前置任务，先小批量走通再规模化 | +| GPU 成本随活跃度线性增长 | 单位经济恶化 | **低（V1）** | V1 不收费，配额为硬上限，**月度成本上限 = MAU × 单用户配额成本，可事前算准**。V2 引入付费后此风险重新升级 | +| 大模型调价或能力变动 | 成本与质量波动 | 中 | 网关抽象 + 双供应商 + 场景配置化 | +| 云 API 下线（已发生一次） | 能力缺口 | 中 | 核心能力（关键点、抠图）自建；对云能力保留替换预案 | +| AI 标识元数据在链路中被剥离 | 合规不达标 | 中 | 专项测试覆盖 CDN/压缩/客户端保存全路径 | +| 知识库内容生产跟不上 | 建议质量低、可解释性弱 | 高 | 知识缺口埋点驱动优先级；顾问资源尽早接洽（`TD-27`） | + +--- + +## 20. 与需求文档的映射 + +| 本文章节 | 对应需求文档 | +| --- | --- | +| §7.1 报告生成链路 | 《美学报告-需求文档》§6 生成流程 | +| §7.2 Agent 链路、§8.3 混合检索 | 《穿搭Agent-需求文档》§3.4、《美学知识库-建设方案》§6 | +| §6.2 profile 域、§8.4 记忆读写 | 《用户系统与记忆系统-需求文档》§3 | +| §6.2 kb 域、§8.3 | 《美学知识库-建设方案》§2~§6 | +| §7.4 配额与支付 | 《用户系统与记忆系统-需求文档》§2.4/2.5、《需求规格说明》§2.9 | +| §7.5、§11 | 《合规与安全方案》全文 | +| §13 成本模型 | 《产品方案》§5.2 成本结构 | + +--- + +## 相关文档 + +- [文档索引](./README.md) +- [需求规格说明](./需求规格说明.md)（本文实现的需求编号来源） +- [技术选型与调研报告](./技术选型与调研报告.md)（本文每项技术选择的理由、备选与切换条件） +- [合规与安全方案](./合规与安全方案.md)（§7.5 统一合规出口与 §11 安全设计的义务来源） +- [开发任务拆解](./开发任务拆解.md)（按本文的模块与链路切分的 WBS） +- [美搭 · 智能穿搭美学助手 产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md) + +--- + +## 变更记录 + +| 日期 | 版本 | 变更 | +| --- | --- | --- | +| 2026-08-13 | v1.1 | 按业务决策收口调整。**billing 域降级为「配额与计量」**：V1 移除支付、订单、会员、IAP；`bl_point_tx` 改名 `bl_ledger` 并新增 `tx_type` 字段，使 V1 配额账本与 V2 点数账本共用同一张表（V2 免数据迁移）；新增 `bl_quota_rule` 配额规则表。§7.4 拆为「V1 配额三段式」与「V2 IAP 支付」。§13 成本模型补充「V1 成本上限可事前算准」的公式，并强调 `ob_ai_call` 是 V2 定价的唯一数据来源、不允许后补。§19 风险登记：备案风险关闭，新增备案范围一致性、素材自采产能、顾问到岗三项风险 | +| 2026-08-13 | v1.0 | 首次输出。确立「模块化单体 + 独立 AI 服务」架构、十个业务域数据模型、五条关键链路、统一合规出口、V1 单机 Docker Compose 部署与成本模型 | diff --git a/docs/技术选型与调研报告.md b/docs/技术选型与调研报告.md new file mode 100644 index 0000000..bb45f02 --- /dev/null +++ b/docs/技术选型与调研报告.md @@ -0,0 +1,711 @@ +# 技术选型与调研报告 + +> 版本：v1.0　｜　调研截止日期：2026-08-13　｜　状态：已定稿（可执行） +> +> 本文的作用是把散落在各需求文档中的「待确认事项」一次性收口。每一条都给出：**结论 → 理由 → 备选方案 → 触发切换的条件 → 信源**。 +> +> **使用约定**： +> - 各需求文档不再重复讨论技术选型，一律引用本文的决策编号（如 `TD-08`）。 +> - 带 `⚠️ 时效性` 标记的条目（主要是价格与厂商接口能力）需在开发启动前复核一次，云厂商接口下线与调价都很频繁——本次调研就撞上了一个（见 `TD-05`）。 +> - 结论分三档：**已定**（可直接进入开发）、**已定方向待验证**（需要一个验证任务确认）、**待业务输入**（不是技术问题）。 + +--- + +## 0. 已确认的项目前提 + +以下前提由项目决策直接给出，是本文所有技术判断的边界条件： + +| 前提 | 取值 | 对架构的影响 | +| --- | --- | --- | +| 换装/发型服务归属 | **自有服务，源码可控，可改造** | 可以把它从「黑盒 HTTP 接口」升级为「受管控的内部推理服务」：加鉴权、改异步回调、独立扩容、埋成本点 | +| 团队规模 | 4~6 人（前端 + 后端 + 算法 + 产品/设计） | 不上微服务。V1 采用**模块化单体 + 独立 AI 能力服务**的两层结构 | +| 后端技术栈 | **全 Python（FastAPI）** | 业务与 AI 同栈，模型侧代码可直接复用，无跨语言序列化成本 | +| 云厂商 | **腾讯云为主** | 存储、审核、人脸能力优先用腾讯云；不足处允许跨云补齐（见 `TD-05`） | +| 前端框架 | 可调整，按调研结论定 | 见 `TD-01` | +| 视觉分析 | 优先第三方 API | 但腾讯云人体能力已下线，必须部分自建，见 `TD-05`/`TD-06` | +| 大模型 | **DeepSeek + 智谱 GLM** | 双供应商路由，见 `TD-04` | +| 排期约束 | 以 AI 辅助开发为主，不按人日排期 | 任务拆解按**依赖关系与里程碑**组织，不写人日估算 | +| 预算约束 | 暂不设上限，效果优先 | 允许自建 GPU 推理与服务端渲染；但仍要求全链路成本可观测（否则用户量上来后无法归因） | + +--- + +## 1. 决策总表 + +| 编号 | 议题 | 结论 | 状态 | +| --- | --- | --- | --- | +| TD-01 | 客户端框架 | 鸿蒙原生 ArkTS + ArkUI（V1 单端） | 已定 | +| TD-02 | 后端框架与运行时 | Python 3.12 + FastAPI + SQLAlchemy 2.0 + Pydantic v2 | 已定 | +| TD-03 | 云基础设施 | 腾讯云：CVM + COS + CDN + PostgreSQL + Redis + CLS | 已定 | +| TD-04 | 大模型与路由 | DeepSeek 为主 + GLM 为备，自建 LLM 网关；VLM 用 GLM-4V 系 | 已定 | +| TD-05 | 人脸/人体视觉能力 | 人脸走腾讯云；**人体关键点必须自建**（腾讯云已下线） | 已定 | +| TD-06 | 体型测算方案 | 人像分割掩膜宽度剖面 + 关键点定高 | 已定方向待验证 | +| TD-07 | 抠图（白底图流水线） | 自建 BiRefNet；**禁用 RMBG-2.0**（非商用许可） | 已定 | +| TD-08 | 向量检索 | PostgreSQL + pgvector，不引入专用向量库 | 已定 | +| TD-09 | 知识图谱 | PG 邻接表 + 递归 CTE，不上 Neo4j | 已定 | +| TD-10 | 规则引擎 | 自研数据驱动决策表（规则存库、JSON DSL） | 已定 | +| TD-11 | 异步任务 | Celery + Redis，按资源分队列 | 已定 | +| TD-12 | 报告长图/PDF | 服务端 HTML 渲染（Playwright）为主 | 已定 | +| TD-13 | 内容审核 | 腾讯云天御 IMS + TMS（含 AI 生成鉴别） | 已定 | +| TD-14 | 语音输入 | 鸿蒙 Core Speech Kit 端侧识别 | 已定（V2 功能） | +| TD-15 | 账号与登录 | 华为 Account Kit 授权登录 + 手机号验证码；**一键登录降级为 P1**（需企业资质） | 已定 | +| TD-16 | 支付 | **V1 不接支付**；V2 起虚拟商品强制华为 IAP，抽成约 30% | 已定，V1 不适用 | +| TD-17 | 消息推送 | 华为 Push Kit（用于长耗时任务完成通知） | 已定 | +| TD-18 | 色彩季型体系版权 | 自建色板与自研命名，规避「CMB/四季色彩」商标 | 已定 | +| TD-19 | 生成式 AI 备案路径 | 大模型**登记** + 算法备案 —— **✅ 已办结**，转为持续义务 | 已完成，阻塞解除 | +| TD-20 | 人脸信息合规 | 原图不落盘策略，规避 10 万人备案阈值 | 已定 | +| TD-21 | AI 生成内容标识 | 显式水印 + 隐式元数据（含 27 位内容编号） | 已定，**上架审核硬要求** | +| TD-22 | Embedding 模型 | 自建 BGE-M3（CPU/GPU 皆可） | 已定 | +| TD-23 | 埋点与分析 | PG 事件表 + 定时聚合，不上数仓 | 已定 | +| TD-24 | 可观测性 | OpenTelemetry + Prometheus + Grafana + CLS | 已定 | +| TD-25 | 知识库运营后台 | V1 极简版（增删改查 + 素材上传 + 审核） | 已定 | +| TD-26 | 单品素材来源 | **全部自采实拍**，不采购图库、不用品牌供图 | 已定 | +| TD-27 | 形象顾问合作 | **全职编制**，深度参与规则库、黄金集与后台设计 | 已定 | +| TD-28 | V1 商业化 | **V1 完全不收费，用配额限制控成本**；定价推迟到 V2 | 已定 | +| TD-29 | 企业开发者资质 | V1 不依赖（不接 IAP）；一键登录降级为 P1 | 已定 | +| TD-30 | 市场数据信源 | 已替换为国家统计局 / CNNIC / 华为 HDC 官方数据 | 已定 | +| TD-31 | 五行/命理模块 | **不做**（V1 与 V2 均不纳入） | 已定 | + +--- + +## 2. 客户端与端侧能力 + +### TD-01　客户端框架：鸿蒙原生 ArkTS + +**结论**：V1 用**鸿蒙原生 ArkTS + ArkUI**，不用 Uni-App-x。后端保持端无关（标准 REST + SSE），为将来多端留出空间。 + +**理由**： + +1. **V1 只发鸿蒙，跨端框架的收益此刻为零，成本却已经付出**。Uni-App-x 的价值在一套代码多端复用；当前只有鸿蒙一个目标端，等于只承担成本不拿收益。 +2. **官方对鸿蒙端的成熟度自评就是保守的**。Uni-App-x 自 HBuilderX 4.61+ 支持纯血鸿蒙，但官方文档明确写着「鸿蒙整体处于发展初期，能用，有坑，大部分坑有规避方案，但开发者应建议其领导、客户、质量部门降低期望，不能严格比照 Android 和 iOS 的验收标准」。项目定位是「效果优先」，与这个前提相冲突。 +3. **本产品重度依赖的恰好都是系统能力**：相机/相册与大图压缩、长耗时任务的后台通知（Push Kit）、华为账号登录、IAP 支付、Canvas 长图导出、AI 回答的流式渲染。这些在原生 ArkTS 中是一等公民；在跨端框架里要经过一层封装，鸿蒙侧还存在「provider 机制的模块（支付、定位）仍需自行添加」这类手工配置。 +4. **工程链路更短**。Uni-App-x 鸿蒙端不支持云打包，必须本地装 DevEco 出包；权限要在 `harmony-config` 手工配置。既然无论如何都绕不开 DevEco 与鸿蒙证书体系，直接用原生反而少一层中间态。 +5. AI 辅助开发弱化了「多写一套代码」的边际成本，而框架层的疑难问题（渲染差异、SDK 兼容）恰恰是 AI 最难替你兜住的部分。 + +**备选与切换条件**：当 V2 明确要上 iOS/Android 时，重新评估三条路径——① 保留鸿蒙原生、另起跨端工程；② 用 Uni-App-x 重写；③ 用 Flutter。届时的判断依据是那时的鸿蒙生态成熟度和团队构成，现在下结论为时过早。**不要为了一个尚未确定的多端需求，在 V1 就承担框架风险。** + +**风险**：团队若无 ArkTS 经验，存在学习曲线。缓解：ArkTS 是 TypeScript 超集，ArkUI 声明式写法与 Vue/React 心智模型接近；Phase 1 的第一个技术任务就是搭通「登录 + 拍照上传 + 长耗时任务轮询 + 结果页」骨架，把主要坑一次性踩完。 + +**信源**：Uni-App-x 官方 harmony 开发指南、兼容性表格、`uniapp.dcloud.io` 鸿蒙运行与发行文档（2026-08 访问）。 + +### TD-15　账号与登录：华为 Account Kit + +**结论**：V1 登录方式为**华为账号授权登录（UnionID/OpenID）+ 手机号验证码**双通道；「一键登录获取手机号」**降级为 P1**，V1 不做（`TD-29`）；保留游客模式（本地匿名 ID）与账号绑定迁移路径。 + +**关键约束（调研得到，必须提前处理）**： + +| 约束 | 内容 | 应对 | +| --- | --- | --- | +| 一键登录资质 | 华为账号一键登录（获取绑定手机号）**仅支持企业开发者**，仅面向中国大陆用户 | ✅ **已决策（`TD-29`）：一键登录降级为 P1，V1 不做**。V1 用「华为账号授权登录（UnionID）+ 手机号验证码」双方式，均无特殊资质门槛。一键登录只是少输一次验证码的体验优化，不值得阻塞排期 | +| scope 申请 | 需申请 `quickLoginMobilePhone` scope，未申请时即使接口调通也**不会返回手机号** | V1 不涉及；实现一键登录时再提交 | +| 服务器地域 | 服务端获取绑定手机号时，**服务器必须部署在中国大陆** | 与腾讯云选型一致，无冲突 | +| 证书指纹 | AGC 需配置 SHA256 证书指纹，**调试证书与发布证书是两套**；指纹添加后最迟 25 小时生效（可通过改 `versionCode` 加速） | 写入发布手册，避免临上线才发现登录失败 | + +**用户标识策略**：内部主键用自有 `user_id`（雪花 ID），华为 `UnionID` 作为外部身份映射存于独立表。**不要用手机号或 UnionID 作为主键**——将来接入其他登录方式或多端时会很难改。 + +**信源**：华为开发者文档 Account Kit（`account-unionid-login-V5`）、2026-03 一键登录实战整理。 + +### TD-16　支付：V1 不接支付；V2 起虚拟商品强制走华为 IAP + +> **V1 不适用**：`TD-28` 已决定 V1 完全不收费，因此 V1 **不接入 IAP，也不受 30% 抽成影响**。本节内容为 V2 的前置约束，提前记录以免 V2 定价时重复调研。 + +**结论**：全面报告、会员、点数包均属**虚拟商品**，在鸿蒙上**必须接入 IAP Kit**，且需签署《华为数字商品及联运服务协议》。Payment Kit 明确不支持虚拟商品，不能用它绕开。 + +**这是一条会改动商业模型的发现（V2 定价时必须计入）**： + +- 平台抽成量级约为交易额的 **30%**（部分资料给出「10% 基础技术服务费 + 30% 联运分成」的更高口径）。 +- 意味着定价 ¥39 的全面报告，实际到账约 ¥27 或更低。原有单位经济模型（按全额收入测算毛利）**偏乐观**，必须按到账口径重算。 + +**工程要求**： + +1. IAP 商品需在 AGC 后台配置商品 ID，客户端下单、服务端**必须做收据二次校验**（防止客户端伪造发货）。 +2. 服务端需实现订单幂等：`(user_id, purchase_token)` 唯一约束，重复回调只发货一次。 +3. 点数发放与消费必须在同一事务边界内可追溯（点数流水表，见架构文档数据模型）。 +4. 消耗型（点数包）与订阅型（会员）走不同的 IAP 商品类型，退款/掉单对账逻辑不同。 + +**行动项**：定价与点数消耗比（原 `用户系统与记忆系统-需求文档` 待确认项）需在抽成口径下重算，见 `TD-28`。 + +**信源**：华为 IAP/Payment Kit 官方文档、华为云开发者社区分成政策说明、开发者社区联运要求整理。⚠️ 时效性：抽成比例以签署的正式协议为准，本文数值仅用于建模。 + +### TD-17　消息推送：Push Kit + +**结论**：用华为 Push Kit 承载「长耗时任务完成」通知（报告生成完成、换装出图完成），配合应用内任务中心。 + +**约束**：消息体最大 4096 字节（不含 Token）；应用通知开关默认关闭，需主动请求通知授权；Token 需上报服务端并处理失效刷新。本地通知用 Notification Kit。 + +**设计要点**：推送只承载「跳转指令 + 极简摘要」，业务数据一律回到应用内拉取，避免 4KB 限制和敏感信息外泄（**报告结论不得出现在推送文案里**，那属于个人敏感信息，锁屏可见）。 + +### TD-14　语音输入：Core Speech Kit + +**结论**：V2 功能。使用鸿蒙 **Core Speech Kit** 端侧语音识别，不引入云端 ASR。端侧识别延迟低、无音频外传（隐私更优）、无按量成本。若端侧识别准确率不达标，再评估腾讯云 ASR 作为兜底。 + +--- + +## 3. AI 与视觉能力 + +### TD-04　大模型选型与路由 + +**结论**：自建 **LLM 网关**，双供应商： + +| 用途 | 主模型 | 备用 | 理由 | +| --- | --- | --- | --- | +| Agent 对话、报告文案生成 | DeepSeek 主力对话模型 | GLM 同级模型 | 单价低、缓存命中折扣显著（系统提示词固定的场景最受益），中文表达自然 | +| 结构化抽取（偏好抽取、意图识别、属性归一） | DeepSeek 轻量档 | GLM 轻量档 | 走 JSON Schema 约束输出，对模型能力要求不高，优先压成本 | +| 图像理解（单品属性标注、穿搭评价） | 智谱 GLM-4V 系视觉模型 | 阿里 Qwen-VL 系 | DeepSeek 视觉能力覆盖不足；智谱另提供开箱的**衣物识别智能体**（`clothes_recognition_agent`），可直接输出品类/颜色/材质/款式/版型/图案/风格/领型等结构化属性 | + +**为什么必须是网关，而不是直接调 SDK**： + +1. **成本可归因**。每次调用要落库：场景、模型、输入/输出 token、缓存命中、耗时、费用。没有这张表，用户量上来后根本无法回答「哪个功能在烧钱」。 +2. **可切换**。国内模型调价与迭代极频繁（本次调研中同一模型在不同信源就有 ¥1~¥12/百万 token 的差异），把模型名写死在业务代码里，将来换模型要改几十处。 +3. **可降级**。主供应商故障时自动切备用；配额耗尽时降级到轻量模型或返回缓存结果。 +4. **Prompt 版本化**。Prompt 是本产品的核心资产之一，必须像代码一样有版本、有 A/B、有回滚，而不是散落在字符串里。 +5. **合规单点**。备案要求的关键词拦截、输入输出审核、日志留存，在网关一处实现即可覆盖全部场景（见 `TD-19`/`TD-13`）。 + +**成本参考（⚠️ 时效性，开发前需按官网复核）**：2026 年国产模型主流区间约为输入 ¥1~4/百万 token、输出 ¥2~16/百万 token，缓存命中可将输入成本降至 1/5~1/30。本产品「系统提示词 + 知识库片段 + 画像摘要」在同类请求间高度重复，**缓存命中率是成本控制的第一杠杆**，网关设计必须显式支持（固定前缀置于 prompt 头部、避免在前缀里插入时间戳等变量）。 + +**信源**：多家 2026 年国产大模型 API 价格横评、智谱 BigModel 衣物识别智能体文档、阿里百炼视觉理解文档。 + +### TD-05　人脸与人体视觉能力（本次调研最重要的发现） + +**⚠️ 关键发现：腾讯云的人体分析能力已下线。** `DetectBody`（人体检测）与 `DetectBodyJoints`（人体关键点）等接口及相关数据结构已于 **2025-10-30** 从腾讯云人体分析产品中删除。原方案中「体型关键点走腾讯云」的路径**已不存在**。 + +**调整后的能力矩阵**： + +| 能力 | 方案 | 说明 | +| --- | --- | --- | +| 人脸检测与属性 | 腾讯云 `DetectFaceAttributes` | 可按需返回 `Skin`（肤色）、`Hair`（发型）、`Shape`（脸型）、`Eye`、`Eyebrow`、`Nose`、`Mouth`、`Headpose` 等；支持指定属性以降低耗时 | +| 人脸关键点（五官定位） | 腾讯云 `AnalyzeFace`（90 点） | 眉 16、眼 16、鼻 13、嘴 22、脸型轮廓 21、瞳孔 2。**脸型轮廓 21 点足以支撑脸型判定** | +| 人脸稠密关键点 | 腾讯云 `AnalyzeDenseLandmarks`（888 点） | 仅在需要精细五官比例（如全面报告的面部三庭五眼）时调用，成本更高 | +| 人像分割 | 腾讯云 `SegmentPortraitPic` / `SegmentCustomizedPortraitPic` | **未下线**，是体型测算的关键输入 | +| **人体关键点** | **自建**：RTMPose（ONNX Runtime）或 MediaPipe Pose | 见下方选型 | +| 肤色/唇色/发色取值 | **自研**：关键点定位采样区 + Lab 色彩空间统计 | 云 API 只给「肤色分类」，我们需要的是**可进入色彩计算的实际色值**，必须自研 | + +**人体关键点自建选型**： + +| 方案 | 关键点数 | 评价 | +| --- | --- | --- | +| **RTMPose（推荐）** | 17/26/133（可选全身） | OpenMMLab 系，精度/速度平衡好，支持 ONNX/TensorRT/ncnn 多后端，CPU 可跑，适合服务端批量推理 | +| MediaPipe Pose | 33（含 3D + 可选分割掩膜） | 移动端实时场景标杆，自带分割掩膜是加分项；服务端部署不如 ONNX 方案顺手 | +| 阿里云 `BodyPosture` | 18 | 跨云调用，18 点**不含腰部点**，且引入第二家云厂商的账号与合规面 | +| 百度 `人体关键点识别` | 21（含头顶） | 含头顶点对身高比例计算有用，按 QPS 计费 | + +**决策**：主用 **RTMPose ONNX**（服务端 CPU 推理即可满足非实时的报告生成场景），备选 MediaPipe。**不跨云调用**——理由是体型测算是核心资产，自建后可持续调优，而云 API 的下线风险刚刚在腾讯云身上验证过一次。 + +**信源**：腾讯云人体分析更新历史（接口删除记录）、腾讯云人脸识别 API 文档（`AnalyzeFace`/`AnalyzeDenseLandmarks`/`DetectFaceAttributes`）、阿里云视觉智能开放平台 `BodyPosture`、百度智能云人体关键点文档、MediaPipe Pose Landmarker 文档。 + +### TD-06　体型测算方案 + +**结论**：不依赖骨骼关键点直接算体型，而是**「分割掩膜 + 关键点定高」的宽度剖面法**： + +``` +1. 人像分割 → 得到人体前景掩膜（腾讯云 SegmentPortraitPic） +2. 人体关键点 → 定位肩点、髋点、踝点的纵向位置（RTMPose） +3. 在关键高度处横切掩膜，测量像素宽度： + - 肩宽线：两肩关键点连线所在高度 + - 腰宽线：肩线与髋线之间的最窄处（自动搜索极小值） + - 臀宽线：髋点下方固定比例处的最宽处 +4. 以身高（头顶到踝）归一化，得到无量纲比例： + 肩/腰、臀/腰、肩/臀 +5. 比例进入规则表 → 输出体型分类（H/X/A/V/O）+ 置信度 +``` + +**为什么这样做**：骨骼关键点给的是**关节位置**，不是**身体轮廓宽度**；而体型分类（沙漏/梨形/倒三角）本质上是轮廓宽度关系。只用关键点算出来的「肩宽」是肩关节间距，会系统性低估实际肩宽。掩膜提供轮廓，关键点提供解剖学定位，两者结合才对。 + +**状态：已定方向待验证**。Phase 0 需要一个验证任务：采集 30~50 张不同体型的样本图，人工标注体型分类，验证本方案的分类一致率。**验收标准：与人工标注一致率 ≥ 80%，且低置信度样本能被正确识别并触发人工兜底话术。** + +**已知风险与缓解**： + +| 风险 | 缓解 | +| --- | --- | +| 宽松衣物导致轮廓失真 | 拍照引导要求「贴身或合体着装、正面站立、双臂略微离开身体」；检测到手臂贴身时提示重拍 | +| 拍摄距离/角度导致透视误差 | 只用**无量纲比例**，不输出绝对尺寸（cm）。产品文案上也不承诺「量体数据」，只给体型类型 | +| 单图无法获知真实三围 | 明确不做尺码推荐（这是另一个量级的问题）。报告只讲比例与视觉平衡 | + +### TD-07　抠图流水线：BiRefNet，禁用 RMBG-2.0 + +**结论**：单品白底图流水线用 **BiRefNet**（开源可商用）自建，离线批处理。 + +**⚠️ 许可陷阱（必须避开）**：`RMBG-2.0`（BRIA AI）是被引用最多的「开源抠图模型」，但它的许可是 **CC BY-NC 4.0，仅限非商业使用**，商用需与 BRIA 单独签商业协议。RMBG-2.0 本身就是基于 BiRefNet 架构 + 自有数据集训练的。**直接自部署 RMBG-2.0 用于商业产品属于违反许可。** 同类提醒：`rembg` 库本身是 MIT，但它封装的 18+ 个模型各自许可不同，不能因为库是 MIT 就认为模型可商用。 + +**方案**： + +- 主模型：BiRefNet（边缘质量强，对发丝、蕾丝、镂空等细结构表现好，正是服装抠图的难点） +- 备选：U²-Net / IS-Net（Apache 2.0，更快，复杂场景质量略低），BEN2 +- 部署形态：**离线批处理**服务。素材生产不是实时链路，不需要为它常驻 GPU；用按需 GPU 实例批量跑，跑完释放。 +- 人工质检环节不可省：抠图结果进入知识库前需运营确认，边缘毛刺/透明材质失败的样本走人工修图。 + +**验收标准**：10 件样本走通「原图 → 抠图 → 白底标准化 → 尺寸/命名规范 → 入库 → 换装可用」全流程；换装成功率与视觉可接受率由人工评分。 + +**信源**：BRIA RMBG-2.0 官方仓库与许可说明、BiRefNet 项目、2026 抠图 API/模型横评（明确指出 RMBG 许可陷阱）。 + +### TD-22　Embedding 模型 + +**结论**：自建 **BGE-M3**（中文语义检索表现好、支持多粒度、可商用），与 pgvector 配套。不使用云端 embedding API——知识库条目量级不大且更新不频繁，一次性离线批量向量化即可；自建可避免「向量维度被厂商绑定」，将来换模型只需重跑一次索引。 + +**约束**：向量维度写入配置而非硬编码；`kb_chunk` 表保留 `embedding_model` 与 `embedding_version` 字段，支持双写平滑迁移。 + +--- + +## 4. 数据与检索 + +### TD-08　向量检索：PostgreSQL + pgvector + +**结论**：用 **PostgreSQL + pgvector**，不引入专用向量数据库。 + +**理由**： + +1. **规模远未到需要专用库的量级**。按知识库规划，条目与文本块合计在**万级到十万级**向量，pgvector 的舒适区是百万级以下（业界实践普遍认为数百万到 5000 万都可用）。 +2. **我们的检索本质是「强过滤 + 弱语义」**。混合检索链路的第一步是硬过滤（季型、场合、体型禁忌），这是典型 SQL `WHERE`；纯向量库的元数据过滤能力反而是短板。把向量放在 PG 里，硬过滤与向量召回可以在**同一条 SQL** 里完成，还能和业务表 JOIN。 +3. **运维成本近乎为零**。团队 4~6 人，多引入一个有状态组件就多一份备份、监控、扩容、故障演练的负担。 +4. **一致性**。知识条目与其向量在同一个事务里更新，不存在「条目改了向量没改」的窗口期——这个问题在双系统架构里非常常见且难查。 + +**切换条件（写清楚，避免将来凭感觉迁移）**：出现以下任一情况才考虑迁移 Qdrant/Milvus——① 向量量级超过 500 万；② 过滤后召回的 p99 延迟超过 200ms 且已确认无法通过索引优化解决；③ 需要多租户向量隔离。 + +**索引策略**：HNSW（查询性能优先），注意索引构建期间的资源竞争，批量重建走低峰期。 + +**信源**：pgvector RAG 实践、2026 向量数据库五家横评、腾讯云向量数据库选型文章（其自身内容也建议小规模场景用 pgvector）。 + +### TD-09　知识图谱：PG 邻接表 + 递归 CTE + +**结论**：不上 Neo4j。用 PostgreSQL 的 `kb_relation(from_entity, relation_type, to_entity, weight, confidence)` 邻接表存关系，多跳查询用递归 CTE。 + +**理由**：知识库的图查询需求是**有界的浅层遍历**——「这件单品适合哪些场合」「这个季型的禁忌色有哪些」「从体型到剪裁建议的推理路径」，深度基本在 1~3 跳。这类查询递归 CTE 完全够用。Neo4j 的价值在于任意深度路径搜索与图算法（社区发现、最短路），我们不需要，却要为它承担一整套独立的运维与数据同步。 + +**「为什么推荐」解释链**：把遍历路径（起点实体 → 关系 → 终点实体 + 命中的规则 ID）作为结构化结果返回，再交给 LLM 转成自然语言。**解释链的事实部分必须来自数据库路径，不能让 LLM 自己编推理过程**——否则解释听起来很专业但不可审计，这恰恰是自建知识库要解决的问题。 + +### TD-10　规则引擎：自研数据驱动决策表 + +**结论**：自研轻量规则引擎，规则以 **JSON DSL 存在数据库**，不引入通用规则引擎框架。 + +**理由**： + +1. 我们的规则形态高度规整——「条件（季型/体型/场合/身份属性）→ 建议或禁忌 → 权重 → 依据说明」，本质是**决策表**，不是复杂的前向链推理。 +2. 规则必须**由运营/形象顾问维护**，不能是代码。存库 + 后台编辑 + 版本化 + 灰度，是产品需求而非技术偏好。 +3. 通用规则引擎（如 Drools 类）的表达能力我们用不到 20%，却要接受它的 DSL 学习成本与调试困难。 +4. 自研可以直接把「命中的规则 ID 列表」透出，天然满足可解释与可审计要求。 + +**核心设计**： + +```json +{ + "rule_id": "R-COLOR-0137", + "version": 3, + "status": "published", + "priority": 80, + "conditions": { + "all": [ + { "field": "profile.color_season", "op": "in", "value": ["浅暖型", "柔暖型"] }, + { "field": "context.occasion", "op": "eq", "value": "商务正式" } + ] + }, + "effects": [ + { "type": "recommend", "target": "color", "value": ["驼", "米白", "浅灰蓝"], "weight": 0.9 }, + { "type": "avoid", "target": "color", "value": ["纯黑", "冷紫"], "weight": 1.0, "hard": true } + ], + "evidence": "低对比度暖调面部特征在高对比冷色下会显得五官被压……", + "author": "顾问A", + "reviewed_by": "顾问B" +} +``` + +**硬约束（`hard: true`）必须在生成后校验环节强制执行**：LLM 输出的搭配方案要逐项比对禁忌规则，违反则重新生成或剔除该项。这是「禁忌项违反 = 0」这条质量指标的实现方式。 + +### TD-11　异步任务：Celery + Redis + +**结论**：Celery + Redis 作为 broker，按资源类型分队列。 + +**队列划分**： + +| 队列 | 任务类型 | 并发策略 | +| --- | --- | --- | +| `gpu` | 换装出图、发型更换、批量抠图 | 并发数 = GPU 容量，严格限流，队列可见等待位次 | +| `cpu` | 关键点推理、色值采样、体型测算、长图渲染 | 中等并发 | +| `io` | LLM 调用、云 API 调用、推送、审核 | 高并发（IO 密集） | +| `beat` | 定时任务：记忆衰减、指标聚合、素材巡检、配额重置 | 单实例，需防重 | + +**必须实现的能力**（这些是长耗时任务产品化的地基，不是可选项）： + +- **幂等**：任务以业务幂等键（如 `tryon_task_id`）去重，重试不会重复扣点数、不会重复出图。 +- **状态机**：`pending → running → succeeded / failed / cancelled / timeout`，状态变更落库并可查询。 +- **超时与重试**：区分可重试错误（网络、限流）与不可重试错误（输入非法、审核拒绝），后者立即失败并**退还点数**。 +- **进度上报**：给前端可展示的阶段（排队中 / 分析中 / 生成中 / 后处理中）与预估剩余时间。 +- **死信处理**：连续失败进入死信队列并告警，不静默丢弃。 + +**为什么不用更轻的方案**：ARQ/Dramatiq 更简洁，但 Celery 的队列路由、beat 定时、结果后端、监控生态（Flower）成熟度更高，长耗时任务的可观测性是本产品的刚需。 + +### TD-12　报告长图与 PDF 渲染 + +**结论**：**服务端渲染为主**——HTML 模板 + Playwright（Chromium）截长图/导 PDF，产物存 COS。 + +**理由**：报告是要被分享传播的核心资产，必须**跨设备完全一致、可加水印、可加 AI 标识元数据、可服务端审核后再放行**。端侧 Canvas 渲染在字体、行高、图片加载时序上很难保证一致，且无法在分享前做内容审核。 + +**成本控制**：渲染任务进 `cpu` 队列；同一报告版本的长图**只渲染一次并缓存**，重复分享直接取 COS 对象。 + +**备选**：端侧 Canvas 作为「无网络/渲染服务故障」时的降级方案，仅生成简版分享卡片。 + +### TD-23　埋点与数据分析 + +**结论**：V1 不上数据仓库。事件写入 PG 的 `event_log` 表（按月分区），配合定时聚合任务生成指标宽表，Grafana 直读。 + +**理由**：需求文档里的漏斗指标（报告触发率、完成率、付费转化率）都是明确的、有限的、可预先定义的聚合，不需要即席探索能力。当指标需求变成「随时切任意维度」时再引入 ClickHouse。 + +**必须从第一天就埋的事件**（漏斗断点一旦漏埋，数据就永远补不回来）：注册、授权同意、拍照上传、报告触发、报告完成、报告页各模块曝光与展开、分享、Agent 会话开始/轮次/满意度、换装发起/成功/失败、点数消耗、付费页曝光/下单/支付成功。 + +--- + +## 5. 合规与法务 + +> 本节只给结论。落地要求、文案、流程见《合规与安全方案》。 + +### TD-19　生成式 AI 备案路径（✅ 已办结，阻塞解除） + +> **状态更新（2026-08-13）**：**备案已完成**。原本 2~4 个月的外部审批周期不再是上线瓶颈，项目关键路径从外部审批转移到内部的内容与素材生产。下方保留完整的路径分析，作为**变更备案与持续义务的依据** —— 备案完成不等于合规完成。 +> +> **转为持续义务的四项**： +> +> | 事项 | 要求 | +> |------|------| +> | 编号界面公示 | 在 App 显著位置公示模型名称与备案编号（浙江、江苏、安徽、陕西等地明确要求；应用市场上架核验项） | +> | **备案范围与实际调用一致** | ⚠️ 实际调用的模型清单必须与备案登记的一致。**若备案只覆盖单一模型，上线 DeepSeek + GLM 双路由即属超范围** —— 这是唯一可能影响 V1 上线的合规不确定项，需核实备案材料 | +> | 变更备案 | 新增模型、变更服务功能或算法机制后，**30 个工作日内**办理变更 | +> | 材料留档与维护 | 备案编号、AI 标识说明、安全自评估报告、拦截关键词库、评估测试题集需持续维护 | +> +> **不因备案完成而失效的一条约束**：仍应直接使用 DeepSeek / 智谱官方 API，不走云平台 MaaS 中转（原因见本节末）。 + +**原路径分析**：本产品面向境内公众提供生成式 AI 服务，路径为： + +| 事项 | 是否需要 | 依据与说明 | +| --- | --- | --- | +| **大模型备案** | 不需要 | 备案针对自研或对开源模型做微调/二次训练的情形。我们仅调用已备案第三方 API（DeepSeek/GLM）且不做训练 | +| **大模型登记** | **需要** | 通过 API 调用已备案模型并向境内公众提供服务的情形，需向**属地网信办**办理登记。流程较备案简化，但周期约 **2~4 个月** | +| **算法备案** | **需要** | 《生成式人工智能服务管理暂行办法》第十七条 + 《互联网信息服务算法推荐管理规定》：具有舆论属性或社会动员能力的服务需履行算法备案。填报入口 `beian.cac.gov.cn` | +| 安全自评估 | **需要** | 备案/登记材料的一部分 | +| 上架材料 | **需要** | 应用市场审核时会要求说明是否提供 AI 生成合成服务，并核验算法备案号/登记号、与模型技术方的合作说明、标识材料 | + +~~**这条必须写进项目计划的最前面**~~ —— **已办结，此段仅作历史记录**：登记周期 2~4 个月，与开发周期高度重叠。各地要求不一致（北京、河北更严；浙江、江苏、安徽、陕西强调**在界面显著位置公示模型名称与备案号** —— 这一条现已转为我们的持续义务）。 + +**材料清单**（已提交，但需持续维护，变更备案时会再次用到）：安全自评估报告、调用已备案大模型的情况说明与证明材料、用户协议与隐私政策、内容安全管理制度、**拦截关键词库**、评估测试题集、可供审核的测试通道与虚拟测试账号（需提供「附加审核策略」与「不附加审核策略」两种）。 + +**⚠️ 一个容易被忽略的点**：部分应用商店要求提供「应用主体与算法技术主体的合作协议」，而云厂商作为模型中转方**无法代第三方模型厂商出具并盖章**。若走云平台中转（如某云的 MaaS 平台），可能拿不到这份材料。**建议直接使用 DeepSeek/智谱的官方 API**，便于获取其备案号与合作证明。 + +**信源**：《生成式人工智能服务管理暂行办法》、算法备案与大模型备案/登记区别解析、华为云 MaaS 上架资质 FAQ（明确说明无法出具第三方模型合作协议）、腾讯云大模型登记详解。 + +### TD-20　人脸信息合规 + +**结论**：《人脸识别技术应用安全管理办法》自 **2025-06-01** 施行。关键条款与我们的应对： + +| 要求 | 应对 | +| --- | --- | +| 存储人脸信息达 **10 万人**需在 30 个工作日内向省级以上网信部门备案（线上系统 `grxxbh.cacdtsc.cn`） | **架构上规避**：人脸原图不落盘、不长期存储，只保留派生的结构化特征（色值、比例、分类标签）与用户可见的报告产物。使「存储的人脸信息数量」始终为 0/极低，从根本上不触发该阈值 | +| 备案材料含个人信息保护影响评估（PIA）报告 | 无论是否达阈值，**PIA 都要做**——这是处理敏感个人信息的独立法定要求 | +| 单独同意、告知处理目的与方式 | 拍照授权页面必须是**独立的单独同意**，不能混在用户协议里一勾了之 | +| 备案信息变更/终止的 30 工作日义务 | 写入合规运维清单 | + +**「原图不落盘」的工程含义**（这是架构约束，不是文案承诺）：上传的人脸图在处理管道中以临时对象存在，分析完成后立即删除；若因异步任务必须暂存，则使用带**生命周期策略的独立 COS 桶**（如 2 小时自动过期）+ 服务端加密 + 签名访问，并在数据流图中标注为「临时区」。用户主动保存的换装结果图属于用户内容，另行管理并支持一键删除。 + +**信源**：国家网信办、公安部令第 19 号《人脸识别技术应用安全管理办法》；网信办关于开展人脸识别技术应用备案工作的公告（2025-05-30）。 + +### TD-21　AI 生成内容标识 + +**结论**：《人工智能生成合成内容标识办法》自 **2025-09-01** 施行，配套国标 **GB 45438-2025**。本产品的换装结果图、发型效果图、报告长图/PDF、AI 对话回复**全部属于生成合成内容**，必须双重标识： + +**显式标识**（用户可明显感知）： +- 图片类产物：画面内可见的「AI 生成」文字标识，位置固定、不被裁切裁掉（分享图尤其注意） +- 文本类（Agent 回复）：会话界面固定位置提示「内容由 AI 生成」 +- 报告：首屏与分享图均需标识 + +**隐式标识**（文件元数据）： +- 在生成文件的元数据中写入：生成合成内容属性信息、服务提供者名称或编码、**内容编号**（27 位数字或大写字母） +- 图片走 EXIF/XMP，PDF 走文档元数据 +- 需保证经过压缩、转存、CDN 分发后元数据不丢失——**这条要专门测试**，很多图片处理链路会剥离元数据 + +**其他义务**： +- 应用市场上架审核时需说明提供 AI 生成合成服务并提交标识相关材料 +- 若提供「用户申请去除显式标识」的能力，需签订协议并**留存日志至少 6 个月**（建议 V1 不提供此能力，避免额外义务） + +**工程落点**：在架构上设一个统一的 `compliance` 模块，所有生成类产物**必须经过它才能对外发布**（打水印 + 写元数据 + 登记内容编号 + 送审）。不要让每个业务模块各自实现，一定会漏。 + +**信源**：四部门《人工智能生成合成内容标识办法》全文、CAC 发布说明、《服务提供者编码规则》实践指南。 + +### TD-13　内容审核 + +**结论**：腾讯云天御 **IMS（图片内容安全）+ TMS（文本内容安全）**。 + +**要审的对象**（全都要审，别漏）： + +| 对象 | 时机 | 说明 | +| --- | --- | --- | +| 用户上传的照片 | 上传后、进入分析前 | 拦截违法违规、涉黄内容 | +| 换装/发型生成结果图 | 生成后、返回前 | 生成模型可能产出不当结果 | +| 用户输入的对话文本 | 送入 LLM 前 | 同时做备案要求的关键词拦截 | +| LLM 输出的文本 | 返回前 | 输出侧审核是备案的明确要求 | +| 报告文案与长图 | 发布前 | 尤其是分享出去的版本 | +| 运营录入的知识内容 | 发布前 | 走人工 + 机审双轨 | + +**能力匹配**：IMS 支持涉黄/违法违规/广告检测、自定义图片库，并有 **AI 生成鉴别**能力；TMS 支持涉黄/违法/广告、**自定义关键词库**（正好承载备案要求的拦截词库）与 AI 生成识别。文本长度上限 10000 字符，默认 1000 次/秒；图片默认 100 次/秒。 + +**成本量级（⚠️ 时效性）**：图片审核约 ¥10~25/万张，文本审核约 ¥10~25/万条（套餐包价格更低）。相对 LLM 与 GPU 成本可忽略，**不要为省这点钱而漏审**。 + +**信源**：腾讯云 IMS/TMS 产品与计费文档、`TextModeration` API 文档。 + +### TD-18　色彩季型体系的版权与商标 + +**结论**：**自建色板 + 自研命名**，不引进外部色彩体系授权。 + +**调研结论**： +- 四季/十二季色彩**理论方法本身属于思想与方法，不受著作权保护**，可以自由借鉴其分类逻辑（冷暖、明度、纯度三维度划分）。 +- 但「**四季色彩**」「**CMB / Color Me Beautiful**」在国内**存在注册商标**（相关企业公开声明二十余年前即取得国内注册商标）。**不得将这些词用作服务名称、功能名称或宣传标识**。 +- 他人的**具体色布/色卡集合**（如某机构的「20+2 鉴定色布」「46 色调验证色布」）是投入独创性劳动的成果，直接复制其色值集合存在侵权与商业秘密风险。 + +**执行要求**： + +1. 色板由我们自行构建：定义每个季型的 Lab 色域边界与代表色，色值自行确定并记录构建依据。 +2. 季型命名使用**描述性自研名称**（如「浅暖柔和型」「深冷明艳型」），不使用带商标属性的表述；对外文案避免暗示与任何机构的授权关系。 +3. 知识库条目保留 `source` 与 `license` 字段，杜绝来源不明的内容混入（见知识库文档的数据治理章节）。 +4. 报告中的专业术语（量感、直曲、对比度）属于行业通用词汇，可用；但需配通俗解释（原报告文档已提出的术语通俗化问题，此处一并解决：**术语并列展示，专业词 + 一句白话释义**）。 + +**信源**：四季色彩/祺馨色彩等机构关于 CMB 与国内注册商标的公开表述、十二季色彩理论沿革资料、商标信息公开检索。⚠️ 建议在正式对外宣传前做一次商标检索确认。 + +--- + +## 6. 基础设施与工程 + +### TD-02　后端框架与运行时 + +**结论**： + +| 组件 | 选型 | 说明 | +| --- | --- | --- | +| 语言 | Python 3.12 | 与 AI 生态一致 | +| Web 框架 | FastAPI | 原生异步、Pydantic 校验、自动 OpenAPI 文档 | +| ASGI | Uvicorn（Gunicorn 管理多 worker） | | +| ORM | SQLAlchemy 2.0（async）+ Alembic | 迁移必须版本化 | +| 校验/序列化 | Pydantic v2 | 同时用于 LLM 结构化输出的 Schema 约束 | +| 任务 | Celery + Redis | 见 `TD-11` | +| 推理运行时 | ONNX Runtime | 关键点/抠图模型统一走 ONNX，避免绑定训练框架 | +| 测试 | pytest + pytest-asyncio + testcontainers | | +| 质量 | ruff + mypy | AI 辅助开发下，**静态检查是主要防线**，必须进 CI | + +**AI 辅助开发的工程约束（重要）**：既然主要由 AI 编码，就必须把「机器可验证的规范」前置，否则代码会快速失控： + +1. **OpenAPI 先行**：接口先定义 schema，再生成实现与客户端类型，前后端并行且不打嘴仗。 +2. **强类型 + 严格 lint 进 CI**：mypy strict 模式覆盖核心域。 +3. **契约测试与黄金集测试**：知识库检索、规则命中、报告生成都要有可回归的黄金测试集（见知识库文档质量保障章节），这是防止「AI 改一处坏一片」的唯一有效手段。 +4. **数据库迁移必须走 Alembic**，禁止手改表结构。 + +### TD-03　云基础设施（腾讯云） + +| 用途 | 产品 | 说明 | +| --- | --- | --- | +| 计算 | CVM（V1）→ TKE（V2 有扩容需求时） | V1 用 Docker Compose 单机多容器，够用且省 | +| GPU 计算 | GPU 云服务器（按需/竞价） | 换装推理、批量抠图。**按需启停，不常驻** | +| 数据库 | 云数据库 PostgreSQL（含 pgvector 扩展） | 主库 + 只读实例（按需） | +| 缓存 | 云数据库 Redis | 缓存、会话、限流、Celery broker | +| 对象存储 | COS（分桶：临时区/用户内容/知识库素材/报告产物） | 生命周期策略是隐私合规的执行手段 | +| CDN | 内容分发 + 防盗链 + 签名 URL | 结果图与素材加速 | +| 内容安全 | 天御 IMS / TMS | 见 `TD-13` | +| 人脸能力 | 人脸识别（`AnalyzeFace` 等） | 见 `TD-05` | +| 日志 | CLS | 应用日志与审计日志 | +| 密钥 | SSM/KMS | API Key 一律不进代码与镜像 | + +**分桶策略要在第一天就定下来**，因为它承载了合规义务： + +``` +cos://meida-temp/ # 临时区：上传原图，生命周期 2 小时自动删除，服务端加密 +cos://meida-user/ # 用户内容：用户主动保存的结果图，随账号注销删除 +cos://meida-kb/ # 知识库素材：单品白底图、发型图、色板 +cos://meida-report/ # 报告产物：长图/PDF，含 AI 标识元数据 +``` + +### TD-24　可观测性 + +**结论**：OpenTelemetry 埋链路 → Prometheus 存指标 + Grafana 看板；应用与审计日志进 CLS。 + +**必须有的三块看板**（缺一块就等于没做）： + +1. **业务漏斗**：注册 → 授权 → 报告完成 → 分享/付费，逐步转化率 +2. **AI 成本**：按功能/模型/用户分组的调用次数、token 消耗、GPU 秒数、单位成本；**日成本预警** +3. **任务健康**：各队列积压、p50/p95/p99 耗时、失败率与失败归因、死信数量 + +### TD-25　知识库运营后台 + +**结论**：V1 做**极简版**，范围严格限定为：知识条目增删改查、规则编辑与发布、素材上传与抠图任务触发、内容审核（送审/人工复核）、发布与回滚。 + +**为什么不能推到 V2**：知识库是持续运营的资产，靠改数据库来运营意味着每次内容更新都要工程介入，形象顾问无法自主工作——冷启动阶段这会直接卡住内容生产节奏。但完整的版本管理、效果看板、A/B 能力可以留到 V2。 + +**实现取巧**：后台不做独立前端工程，用 FastAPI + 服务端渲染或现成 admin 方案，把工程量压到最小。前台体验投入优先给用户端。 + +--- + +## 7. 业务决策收口（原「待业务输入」，2026-08-13 已全部关闭） + +### TD-26　单品素材来源：全部自采实拍 + +**结论**：**全部自采** —— 自行采购实物单品，按统一规范拍摄，走 BiRefNet 抠图与属性标注流水线。不采购授权图库，不使用品牌供图，不抓取电商与社交平台图片。 + +**理由**： +1. **版权最干净**。这是唯一能彻底避免版权争议的路径。图库授权通常限制"用于生成合成内容"的场景，品牌供图则受渠道合作关系约束，一旦合作终止素材即须下架 —— 而素材库是我们的核心资产，不能建在别人的授权之上。 +2. **规格可统一**。换装接口对输入图有严格要求（白底、正面平铺、无遮挡、`tryon_slot` 明确）。外部来源的图片规格千差万别，返工成本往往高于重新拍摄。 +3. **属性标注可在拍摄时同步完成**。实物在手，材质、版型、色值都能准确记录；靠图片反推属性的准确率明显更低，而属性准确性直接决定检索与推荐质量。 + +**代价（必须正视）**：**素材生产取代备案，成为项目新的关键路径**。这是唯一无法靠 AI 辅助开发压缩的工序 —— 采购要等物流、拍摄要占棚时、抠图要人工质检。300 件 `tryon_ready` 单品需按每周产能倒排，详见《美学知识库-建设方案》§4.2.1 与 `T-P0-21`。 + +**必须建立的留档**：采购凭证、拍摄原始文件、`license` 字段标记为 `self_shot`。这既是版权自证，也是将来若引入外部素材时区分来源的依据。 + +--- + +### TD-27　形象顾问合作：全职编制 + +**结论**：**全职**，而非外部按条计酬或顾问入股。 + +**理由**： +1. **规则库不是一次性交付物，而是需要持续迭代的资产**。800 条规则写完只是起点，之后要根据用户反馈与结论修正率反复校准。按条计酬的外部顾问在"交付完成"后就没有继续投入的动力，而这恰恰是质量提升最关键的阶段。 +2. **顾问需要深度参与知识库后台的设计**。V1 就要做极简运营后台（`TD-25`），它的使用者就是顾问本人。全职顾问会天天用它，能持续反馈易用性问题；外部顾问只会在交付期短暂接触，很难提出有价值的改进。 +3. **黄金评测集的标注需要口径一致**。100~200 例样本若由多位外部顾问分批标注，口径漂移几乎不可避免，而黄金集是所有质量指标的基准，一旦口径不稳，后续的准确率数字就失去意义。 + +**对排期的影响（正面）**：产能从"不可控的外部档期"变成"可测算的内部产能"，规则库的交付时间第一次变得可预测。这让 M2 的排期有了实际依据。 + +**注意**：全职顾问到岗时间直接决定规则库启动时间，因此招聘应在 Phase 0 最早启动（`T-P0-20`），与技术验证并行。 + +--- + +### TD-28　V1 商业化：完全不收费，用配额限制控成本 + +**结论**：**V1 不接入任何支付能力**。无会员、无点数购买、无付费报告、无广告。成本通过**配额硬限制**控制。定价与支付整体推迟到 V2。 + +**理由**： +1. **现在定价只能是猜**。合理定价需要三个前提：单次真实成本、人均使用频次、真实付费意愿。V1 之前这三个数据一个都没有。先上一个猜出来的价格，会同时承担"定高了没人买"和"定低了赔钱"两种风险，而且一旦发布，涨价的代价远高于首次定价。 +2. **不收费反而让成本更可控**。付费模式隐含"付了钱就该多用"的预期，重度付费用户可能亏损（这正是原方案「¥9.9 无限换装」的问题）。不收费时配额可以是纯粹的硬限制，**月度成本上限 = MAU × 单用户配额成本，是可以事前算准的确定值**，不需要事后控制。 +3. **省掉的工作量相当可观**：华为 IAP 接入、订单与支付链路、对账逻辑、退款流程、发票、虚拟商品协议、交易类合规材料，以及 30% 抽成对定价模型的全部影响。 + +**代价（必须正视）**：**V1 无法验证真实付费意愿**，只能靠"预约率"这个代理指标。预约到实付的衰减通常很大，因此 V2 定价前应补一次**小范围真实收费灰度**，而不是直接依据预约率全量定价。 + +**架构上的要求**：billing 域降级为「配额账本 + 消耗流水」，但**必须与 V2 的点数账本共用同一张表** —— V1 只用「系统发放」与「消耗」两种流水类型，V2 增加「购买」与「赠送」，这样 V2 不需要数据迁移。同时**计量埋点一项都不能省**（`NFR-COST-01`），它是 V2 定价的唯一数据来源。 + +--- + +### TD-29　企业开发者资质：V1 不依赖 + +**结论**：V1 **不依赖**华为企业开发者资质中与 IAP 结算相关的部分（因为不接支付）。登录方案相应调整： + +| 登录方式 | V1 | 说明 | +|---------|:--:|------| +| 华为账号授权登录（Account Kit 基础授权，获取 openid/unionid） | ✅ P0 | 标准 OAuth 流程，无特殊资质门槛 | +| 手机号验证码登录 | ✅ P0 | 兜底方案，覆盖不愿授权华为账号的用户 | +| **华为账号手机号一键登录** | **⏸ 降级为 P1** | 需企业开发者资质 + 额外 scope 申请，V1 不做 | + +**理由**：一键登录只是体验优化（少一次输入验证码），不是能力缺口。为它阻塞 V1 排期不值得。企业资质到位后再补，属于纯增量改动，登录模块已按多方式抽象设计。 + +**仍需保留的前置项**：SHA256 证书指纹双套配置（调试与发布证书都要在 AGC 登记），这与资质等级无关，漏配会导致登录在发布包中直接失败 —— 这是个高频踩坑点。 + +--- + +### TD-30　市场数据信源：已替换为官方可核实数据 + +**结论**：产品方案 §4.1 的三处无出处引用**已全部删除**，替换为可核实的官方数据： + +| 数据 | 来源 | 发布时间 | +|------|------|---------| +| 服装鞋帽针纺织品类零售额 15,215 亿元（+3.2%）、化妆品类 4,653 亿元（+5.1%） | 国家统计局《2025 年国民经济和社会发展统计公报》 | 2026-02-28 | +| 生成式 AI 用户 6.02 亿人（+141.7%）、普及率 42.8% | CNNIC 第 57 次《中国互联网络发展状况统计报告》 | 2026-02-05 | +| HarmonyOS 6 终端 6,600 万台、开发者 1,100 万、应用与服务 40 万 | 华为官方 HDC 2026 新闻稿 | 2026-06-12 | + +**同时纠正了一处严重的口径错误**：原文引用「鸿蒙设备超 3 亿台」（现公开数据为 13 亿），但这是**含 IoT、车机、穿戴、开源鸿蒙的生态总数**，与本产品的分发毫无关系。纯血鸿蒙原生应用（`TD-01`）只能安装在 HarmonyOS NEXT 及以上版本，**可触达基数是 HarmonyOS 6 的 6,600 万台**这个量级。 + +**连带影响**：据此下调了用户规模目标（注册 200 万 → 50 万，MAU 100 万 → 15 万），并**用季度回访率替代 DAU 作为核心粘性指标** —— 原目标隐含 DAU/MAU = 30%，那是社交产品的量级，形象诊断是低频决策型工具。详见产品方案 §8.1.1。 + +⚠️ **时效性**：以上数据为 2026-08 时点，鸿蒙装机量增长很快，评审材料引用前请复核最新一期数据。 + +--- + +### TD-31　五行/命理模块：不做 + +**结论**：**V1 与 V2 均不纳入**。整体移除，不保留"可关闭开关"形态。 + +**理由**：收益是边缘的（不影响诊断准确性，也不是用户使用产品的理由），但风险是全局的 —— 命理内容在部分应用市场属敏感类目，一个模块可能拖累整个应用上架。保留"可关闭开关"并不能免除为它准备合规材料、敏感词策略与渠道审核话术的成本，实际维护成本大于其价值。 + +**连带影响**：诊断维度由 34 项减为 **32 项**（删除「五行分布」「幸运色」），编号 33/34 不再复用；`birthday` 字段保留，用途收窄为生日权益与年龄段判断，不再用于命理推算。 + +**保留的边界要求**：Agent 对话中出现命理类提问时正确拒答（`CR-12`），这属于越界拒答能力，与是否做该模块无关。 + +--- + +### 仍然开放的唯一一项 + +| 编号 | 事项 | 需要的输入 | 阻塞什么 | +| --- | --- | --- | --- | +| `TD-19` 残留 | **备案登记覆盖的模型清单** | 备案材料中是否已包含 DeepSeek 与智谱 GLM 两家 | 双路由能否在 V1 启用。若只覆盖一家，需办变更备案，或 V1 先单路由（网关已做多路由抽象，切换成本很低） | + +> 这是目前唯一可能影响 V1 上线合规性的未知项，答案只能来自备案材料本身。**不建议靠推测处理** —— 超范围提供服务的后果远大于少用一个备用模型。 + +--- + +## 8. 与既有文档的冲突修正清单 + +本次调研推翻或修正了既有文档中的若干表述，已在对应文档同步更新： + +| 文档 | 原表述 | 修正为 | 依据 | +| --- | --- | --- | --- | +| 美学报告-需求文档 | 体型关键点走第三方 API | 人体关键点自建（RTMPose），人脸走腾讯云 | 腾讯云人体接口已下线（`TD-05`） | +| 美学报告-需求文档 | 报告渲染方案待定 | 服务端 Playwright 渲染 | `TD-12` | +| 美学知识库-建设方案 | 抠图模型待选型 | BiRefNet，明确禁用 RMBG-2.0 | 许可限制（`TD-07`） | +| 美学知识库-建设方案 | 向量库/图谱待选型 | pgvector + PG 邻接表 | `TD-08`/`TD-09` | +| 美学知识库-建设方案 | 12 季色彩体系版权待确认 | 自建色板，规避商标 | `TD-18` | +| 用户系统与记忆系统 | 华为账号登录接入待验证 | Account Kit；一键登录需企业资质 + scope 申请 | `TD-15` | +| 用户系统与记忆系统 | 会员点数定价待定 | **V1 不收费**，配额账本替代点数；定价推迟到 V2 | `TD-28` | +| 穿搭 Agent-需求文档 | 大模型选型待定 | DeepSeek + GLM 双路由 + 自建网关 | `TD-04` | +| 穿搭 Agent-需求文档 | 内容审核方案待定 | 腾讯云 IMS/TMS，输入与输出双向审核 | `TD-13` | +| 产品方案总纲 | 技术选型为 Uni-App-x | 鸿蒙原生 ArkTS（V1） | `TD-01` | +| 产品方案总纲 | 商业模式按全额收入测算 | **V1 收入为 0**；V2 定价须按 IAP 到账口径重算 | `TD-28`、`TD-16` | +| 产品方案总纲 | 实施计划从技术准备开始 | Phase 0：前置验证（**备案已完成，阻塞解除**） | `TD-19` | +| 产品方案总纲 | 鸿蒙设备超 3 亿台 | **HarmonyOS 6 终端 6,600 万台**才是可触达基数；13 亿为含 IoT 的生态总数，与分发无关 | `TD-30` | +| 产品方案总纲 | DAU 30 万 / MAU 100 万 / 注册 200 万 | 注册 50 万 / MAU 15 万，**并以季度回访率替代 DAU 考核** | `TD-30` | +| 产品方案总纲 | 五行幸运色列入 Phase 4 | **整体不做** | `TD-31` | +| 美学报告-需求文档 | 预约卡片展示预计价格与档位 | **V1 不展示任何价格**，价格敏感度改用线下访谈采集 | `TD-28` | +| 美学报告-需求文档 | 诊断维度 34 项 | **32 项**（删除五行分布、幸运色） | `TD-31` | + +--- + +## 附录：信源清单 + +调研于 2026-08-13 完成，主要信源： + +**官方法规** +- 《人脸识别技术应用安全管理办法》（网信办、公安部令第 19 号，2025-06-01 施行） +- 关于开展人脸识别技术应用备案工作的公告（CAC，2025-05-30） +- 《人工智能生成合成内容标识办法》（四部门，2025-09-01 施行）+ GB 45438-2025 +- 《生成式人工智能服务管理暂行办法》 +- 《互联网信息服务算法推荐管理规定》《互联网信息服务深度合成管理规定》 + +**厂商文档** +- 腾讯云：人体分析更新历史（接口下线记录）、人脸识别 API（`AnalyzeFace`/`AnalyzeDenseLandmarks`/`DetectFaceAttributes`）、天御 IMS/TMS、向量数据库 +- 华为：Account Kit、IAP Kit、Payment Kit、Push Kit、Core Speech Kit 官方文档；AGC 分成与联运政策 +- DCloud：Uni-App-x harmony 开发指南、兼容性表格 +- 智谱 BigModel：衣物识别智能体；阿里百炼：视觉理解文档 +- BRIA RMBG-2.0 仓库与许可、BiRefNet 项目 + +**技术评测与实践** +- 2026 国产大模型 API 价格横评（多来源交叉） +- 2026 向量数据库选型对比、pgvector RAG 生产实践 +- 2026 抠图模型/API 横评（含许可陷阱提示） +- MediaPipe Pose、RTMPose、阿里云 BodyPosture、百度人体关键点文档 + +> ⚠️ **时效性提醒**：本文涉及的模型价格、厂商接口能力与法规施行状态均为 2026-08-13 的调研结果。价格与接口在半年内可能显著变化（本轮就发现腾讯云人体关键点接口已于 2025-10-30 下线），使用前请复核标注了 `⚠️ 时效性` 的条目。 + +--- + +## 相关文档 + +- [文档索引](./README.md) +- [技术架构文档](./技术架构文档.md)（本文结论的落地形态） +- [需求规格说明](./需求规格说明.md)（选型需满足的 NFR 约束） +- [合规与安全方案](./合规与安全方案.md)（§5 合规选型的完整义务解读） +- [开发任务拆解](./开发任务拆解.md)（未收口项对应的 SPIKE 任务） + +--- + +## 变更记录 + +| 日期 | 版本 | 变更 | +| --- | --- | --- | +| 2026-08-13 | v1.1 | **业务决策全部收口，§7 由「待业务输入」改为「决策收口」**。六项结论：素材全部自采（`TD-26`）、顾问全职编制（`TD-27`）、V1 完全不收费改用配额限制（`TD-28`）、V1 不依赖企业开发者资质且一键登录降级 P1（`TD-29`）、市场数据替换为官方信源并纠正鸿蒙可触达口径（`TD-30`）、五行命理模块不做（`TD-31`）。另 `TD-19` 备案已办结，上线阻塞解除，转为持续义务。§8 冲突清单新增 5 条 | +| 2026-08-13 | v1.0 | 首次输出。31 项技术决策收口，其中四项修正了既有文档的假设：客户端改鸿蒙原生 ArkTS（非 Uni-App-x）、人体关键点改自建 RTMPose（腾讯云接口已下线）、抠图改 BiRefNet（RMBG-2.0 非商用许可）、12 季色彩改自建色板（规避商标）。另有 6 项转入待业务输入 | diff --git a/docs/用户系统与记忆系统-需求文档.md b/docs/用户系统与记忆系统-需求文档.md index 9ba5746..8a33630 100644 --- a/docs/用户系统与记忆系统-需求文档.md +++ b/docs/用户系统与记忆系统-需求文档.md @@ -30,12 +30,17 @@ ### 2.1 账号与登录 -| 方式 | 优先级 | 说明 | -|------|-------|------| -| **华为账号一键登录** | P0（鸿蒙首发主路径） | 首发平台原生能力，转化率最高，V1 必须支持 | -| 手机号 + 验证码 | P0 | 通用兜底，跨端一致 | -| **游客模式** | P0 | 未登录即可体验核心功能，降低首启流失 | -| 微信 / Apple 登录 | P2 | 多端扩展阶段接入 | +| 方式 | 优先级 | 版本 | 说明 | +|------|-------|:----:|------| +| **华为账号授权登录**（UnionID/OpenID） | P0（鸿蒙首发主路径） | V1 | 标准 OAuth 授权，**无特殊资质门槛** | +| 手机号 + 验证码 | P0 | V1 | 通用兜底，覆盖不愿授权华为账号的用户 | +| **游客模式** | P0 | V1 | 未登录即可体验核心功能，降低首启流失 | +| ⏸ 华为账号**一键登录**（直接获取绑定手机号） | **P1（降级）** | **V2** | ⚠️ 需**企业开发者资质** + `quickLoginMobilePhone` scope。V1 不做（`TD-29`） | +| 微信 / Apple 登录 | P2 | V2+ | 多端扩展阶段接入 | + +> **为什么一键登录从 P0 降为 P1**：它需要企业开发者资质与额外 scope 申请，而它带来的收益只是"少输一次验证码"——**这是体验优化，不是能力缺口**。为它阻塞 V1 排期不值得。登录模块按多方式抽象设计，资质到位后补上属于纯增量改动（`TD-29`）。 +> +> **仍需保留的前置项**：AGC 的 **SHA256 证书指纹需配置两套**（调试证书与发布证书），且指纹添加后最迟 25 小时生效。这与资质等级无关，漏配会导致登录**在发布包中直接失败而调试包正常** —— 这是个高频踩坑点，必须写入发布手册。 #### 游客模式与数据迁移（关键设计） @@ -58,10 +63,10 @@ | `huawei_open_id` | string | 华为账号标识 | | `nickname` / `avatar` | string | 昵称、头像 | | `gender` | enum | 女 / 男 / 不便告知 | -| `birthday` | date | 生日（用于色彩、五行、生日权益） | -| `member_level` | enum | free / member / premium | -| `member_expire_at` | datetime | 会员到期时间 | -| `points_balance` | int | 权益点数余额（见 §2.4） | +| `birthday` | date | 生日。**用途限于生日权益与年龄段判断**，五行推算已取消（`TD-31`） | +| `member_level` | enum | free / member / premium。**V1 恒为 `free`**，字段预留 | +| `member_expire_at` | datetime | 会员到期时间。**V1 恒为空**，字段预留 | +| ~~`points_balance`~~ | — | **不放在主表**。余额统一存 `bl_wallet.balance`，以 `bl_ledger` 流水为真相（架构 §6.2）。在主表冗余余额会引入两处数据不一致的风险，而余额是最不能出错的字段 | | `register_channel` | string | 注册渠道（归因） | | `status` | enum | active / frozen / deleting / deleted | | `created_at` / `last_active_at` | datetime | — | @@ -91,48 +96,73 @@ │ ├─ 发型记录 │ └─ 收藏夹（搭配 / 发型 / 单品 / 色板） ├─ 我的衣橱（V2） -├─ 会员中心（权益、点数、订单） +├─ 我的额度（剩余次数、任务换额度） ← V1；无价格与购买入口 +│ └─ 会员中心（权益、点数、订单） ← V2 ├─ 设置 │ ├─ 隐私与授权管理（单项开关、撤回） │ ├─ 数据管理（导出个人数据 / 清空照片 / 注销账号） -│ ├─ 内容偏好（关闭五行模块、关闭个性化推荐） +│ ├─ 内容偏好（关闭个性化推荐） +│ ├─ 关于（**模型名称 + 备案编号公示**，合规必需） │ └─ 通知设置 └─ 帮助与反馈 ``` -### 2.4 会员与权益（含点数制改造） +### 2.4 权益设计：V1 只有配额，没有付费 -**现存风险**：原方案"会员 ¥9.9/月 = 无限换装"在成本上不成立。换装单次为长耗时 GPU 推理（几十秒到几分钟），单次成本量级在角到元，重度用户一个月可轻松消耗数十元，会员越活跃越亏损。 +**原方案的成本风险**："会员 ¥9.9/月 = 无限换装"在成本上不成立 —— 换装是长耗时 GPU 推理，单次成本在角到元量级，重度用户一个月可消耗数十元，**会员越活跃越亏损**。 -**改造方案：基础权益 + 点数制** +**V1 的解法：完全不收费，用配额限制控成本**（`TD-28`）。 -| 权益项 | 免费 | 会员 ¥9.9/月 | 高级 ¥29.9/月 | -|--------|------|-------------|--------------| -| 每日免费换装 | 3 次 | 10 次 | 20 次 | -| 每日免费试戴发型 | 3 次 | 10 次 | 20 次 | +#### 2.4.1 V1 配额表（唯一生效的一张表） + +所有用户共用同一套配额，无会员、无点数购买。 + +| 能力 | 基础额度 | 任务可额外获得 | 硬上限（防刷） | +|------|---------|--------------|--------------| +| 初级美学报告（首次） | 1 次（终身） | — | — | +| 报告重新生成 | 每 30 天 1 次 | +1 次/月 | 每日 ≤ 2 | +| 换装试穿 | 每日 3 次 | +3 次/日 | 每日 ≤ 8 | +| 发型 / 发色试戴 | 每日 3 次 | +2 次/日 | 每日 ≤ 6 | +| AI 对话 | 每日 10 轮 | +10 轮/日 | 每日 ≤ 40 | +| 记忆条数 | 200 条 | — | — | +| 高清导出 | 每日 1 次 | — | 每日 ≤ 3 | + +**任务奖励额度**（全部不涉及金钱）：每日签到、完善画像资料、给报告结论打反馈、邀请好友、分享报告长图。 + +**三条不可违反的纪律**： + +1. **额度是服务端硬限制**（`FR-BILL-06`）—— 服务端校验后直接拒绝，不存在绕过路径。这是成本可事前算准的前提。 +2. **文案中不出现任何价格或购买字样**（`FR-BILL-07`）—— 额度用尽的提示是「今日额度已用完，明天再来，或做个任务多换 3 次」，**不是**「升级会员解锁」。V1 出现价格暗示会污染 V2 的定价空间，也会让用户觉得这是个处处收费的产品。 +3. **每次消耗前置提示剩余量**，禁止静默扣减。 + +#### 2.4.2 V2 权益规划（仅作架构预留，V1 不实现） + +> ⚠️ 下表价格全部为**占位**，需按 V1 采集的真实数据重算（`TD-16`、`T-P6-16`）。 + +| 权益项 | 免费 | 会员 | 高级 | +|--------|------|------|------| +| 每日换装 / 发型 | 3 次 | 10 次 | 20 次 | | 每日 AI 对话 | 10 轮 | 100 轮 | 不限（防刷上限） | -| 月度权益点数 | 0 | 300 点 | 1000 点 | +| 月度权益点数 | 0 | 待定 | 待定 | | 初级美学报告 | 每 30 天 1 次 | 每 7 天 1 次 | 不限（每日 ≤3） | -| 全面美学报告（V2） | 单次 ¥29.9 | 单次 ¥19.9 | 含 1 次/季 | -| 广告 | 有 | 无 | 无 | -| 我的衣橱容量（V2） | 20 件 | 200 件 | 不限 | -| 记忆条数上限 | 50 条 | 500 条 | 不限 | +| 全面美学报告 | 单次付费 | 折扣价 | 含 1 次/季 | +| 我的衣橱容量 | 20 件 | 200 件 | 不限 | +| 记忆条数上限 | 200 条 | 500 条 | 不限 | | 高清导出 / 去水印 | ❌ | ✅ | ✅ | -- **点数消耗**：换装 10 点/次、发型 5 点/次、全面报告 200 点、高清重绘 20 点 -- **点数获取**：会员月度赠送、签到、邀请好友、观看激励广告、单独购买（¥6 = 100 点） -- **免费额度与点数关系**：先扣免费次数，用尽后扣点数，点数不足才引导付费 -- 每次消耗都要有明确的前置提示（"本次将消耗 10 点，剩余 290 点"），禁止静默扣费 +**V1 → V2 免数据迁移的关键设计**：配额账本与点数账本是**同一张表**（`bl_wallet` + `bl_ledger`）。V1 只使用 `system_grant` / `consume` / `refund` 三种 `tx_type`，V2 增加 `purchase` / `gift`。消耗侧的预扣三段式逻辑完全复用，V2 只需新增「购买」这一条发放路径（架构 §6.2、§7.4）。 -> V1 落地范围：**只做免费额度与计量**（记录每次调用的成本与次数），会员/点数/支付在 V2 开启。V1 期间用埋点数据校准真实单用户成本，再定价。 +### 2.5 配额与计量（V1 最重要的隐性交付物） -### 2.5 配额与计量 - -- 所有 AI 能力调用统一走**配额中心**：`check(user_id, ability) → allow/deny + 扣减方式` -- 每次调用落 `usage_log`：`user_id / ability / cost_estimate / duration / result / trace_id` -- 失败调用不扣额度（区分用户侧失败与服务端失败） +- 所有 AI 能力调用统一走**配额中心**：`check(user_id, ability) → allow/deny`，**服务端校验，客户端提示仅为体验** +- 消耗采用**预扣三段式**：`reserve`（冻结）→ `commit`（确认）/ `refund`（退还）。长耗时任务可能失败，直接扣会产生「扣了次数没拿到结果」的客诉 —— **V1 没有客服退款兜底手段，只能靠机制保证** +- 每次调用落 `ob_ai_call`：`user_id / scene / provider / model / tokens / duration / cost / result / trace_id` +- 每次额度变动落 `bl_ledger` 流水，余额可由流水重算校验，**每日自动对账，不一致告警** +- 失败调用不扣额度（区分用户侧失败与服务端失败）；**预检拦截发生在预扣之前**，不合格照片不消耗额度 - 风控：设备维度 + 账号维度 + IP 维度三重限流，异常账号冻结并进人工审核 +> ⚠️ **为什么 V1 不收费反而让计量更重要**：V1 没有收入，成本是唯一的财务变量；同时 `ob_ai_call` 与 `bl_ledger` 是 **V2 定价的唯一数据来源** —— 单次真实成本与人均使用频次都从这里出。**埋点缺失的功能，在 V2 定价时就是一个必须靠猜的空洞**。这一项不允许「先上线后补埋点」（`NFR-COST-01`、`FR-BILL-08`）。 + ### 2.6 账号生命周期 | 操作 | 处理 | @@ -314,15 +344,17 @@ ### 3.9 存储与技术形态 +> 选型结论见《[技术选型与调研报告](./技术选型与调研报告.md)》`TD-02`/`TD-08`；表结构见《[技术架构文档](./技术架构文档.md)》§5.2。 + | 数据 | 存储 | 说明 | |------|------|------| -| L0 / L1 / L2 结构化画像 | 关系型数据库 | 强一致、可索引、可审计 | -| L3 事件与对话摘要 | 关系库 + 向量库 | 向量库用于语义召回 | -| L4 会话状态 | KV 缓存（带 TTL） | 高频读写 | -| L5 衣橱单品 | 关系库 + 对象存储（图片）+ 图像向量 | 支持图搜与属性筛选 | -| 变更审计 | 追加写日志表 | 记录每次记忆变更的 before/after 与操作者 | +| L0 / L1 / L2 结构化画像 | PostgreSQL | 强一致、可索引、可审计 | +| L3 事件与对话摘要 | PostgreSQL + pgvector | 同一库内完成硬过滤与语义召回，不引入专用向量库 | +| L4 会话状态 | Redis（带 TTL） | 高频读写 | +| L5 衣橱单品 | PostgreSQL + COS（图片）+ pgvector（图像向量） | 支持图搜与属性筛选 | +| 变更审计 | 追加写日志表 `memory_audit` | 记录每次记忆变更的 before/after 与操作者 | -- 端侧缓存画像摘要，支持弱网/离线时的基础个性化展示 +- 端侧仅缓存画像**摘要**，支持弱网/离线时的基础个性化展示；**不缓存记忆明文**（含体型尺寸等敏感项） - 所有记忆读写走统一 `MemoryService`，禁止各业务模块直连表，保证冲突消解与审计逻辑唯一 ### 3.10 隐私与合规 @@ -372,9 +404,11 @@ ### 5.1 用户系统 - 游客 → 注册转化率 > 25% -- 华为账号一键登录占比 > 60%（首发平台） +- **华为账号授权登录占比 > 60%**（首发平台；一键登录 V1 不做，故不考核其占比） - 登录成功率 > 99%，注销请求处理时效 100% 达标 - 人脸授权通过率 > 60% +- **配额对账差异 = 0**（每日校验余额与流水一致性） +- **额度耗尽提示中出现价格字样的次数 = 0**（`FR-BILL-07` 的红线，发版前全文案扫描） ### 5.2 记忆系统 | 指标 | 目标 | 意义 | @@ -390,25 +424,70 @@ --- -## 6. 待确认事项 +## 6. 待确认事项（已收口） -- [ ] 华为账号登录的接入方式与 Uni-App-x 兼容性验证 -- [ ] 游客数据迁移的边界情况（多设备、换机、重装）处理方案 -- [ ] 向量库选型（自建 / 云服务）与成本评估 -- [ ] 会员点数制的最终定价与点数消耗比（依赖 V1 真实成本数据） -- [ ] 隐式记忆推断的阈值与确认时机的 A/B 方案 -- [ ] 记忆数据保留时长与法务确认（L3 事件建议 180 天） -- [ ] 是否支持家庭/多人档案（一个账号多个形象档案，如帮家人做诊断）——影响数据模型，建议 V1 预留 `profile_id` 字段 -- [ ] 端侧记忆缓存的加密方案 +### 6.1 已确认 + +| 原待确认项 | 结论 | 依据 | +|-----------|------|------| +| 华为账号登录接入方式 | 客户端改为**鸿蒙原生 ArkTS**，直接使用 **Account Kit**（`@kit.AccountKit`），不再涉及跨端框架兼容性问题。主登录取 UnionID/OpenID | `TD-01`、`TD-15` | +| 用户主标识 | 内部主键用自有 `user_id`（雪花 ID），UnionID 存独立映射表。**不用手机号或 UnionID 做主键**，否则将来接入其他登录方式很难改 | 架构 §6.2 | +| 向量库选型 | **PostgreSQL + pgvector**，不引入专用向量库。规模在十万级向量，且我们的检索是「强过滤 + 弱语义」，硬过滤与向量召回可在同一条 SQL 完成 | `TD-08` | +| 记忆数据保留时长 | 对话原文 90 天；L3/L4 摘要 180 天；报告与画像随账号存续；注销后 7 日内彻底删除 | `CR-03`、合规方案 §4.3 | +| 多形象档案 | V1 **仅预留 `pf_profile.profile_id`** 并创建默认档案，不做 UI | `FR-ACC-12` | +| 端侧记忆缓存加密 | V1 **端侧不缓存记忆明文**。记忆快照在服务端组装与缓存（Redis），端侧只持有展示所需的片段。这样既避免端侧加密方案的复杂度，也减少泄露面 | 架构 §10 | +| 记忆快照的性能方案 | 服务端 `pf_memory_snapshot` 表 + Redis 缓存，按 `content_hash` 变更才重建；记忆写入时按 `user_id` 主动失效 | 架构 §8.4 | + +| **V1 是否收费** | **完全不收费**（`TD-28`）。无会员、无点数购买、无 IAP。用配额硬限制控成本，额度用尽只有「等恢复」与「做任务换额度」两条路径，文案不出现价格字样 | `TD-28`、`FR-BILL-07` | +| **登录方式** | V1 用「华为账号授权登录 + 手机号验证码」双通道；**一键登录降级为 P1 推至 V2**（需企业资质，属体验优化非能力缺口） | `TD-29`、`FR-ACC-13` | +| **余额字段位置** | 余额存 `bl_wallet`，**不在 `user` 主表冗余** `points_balance`；以 `bl_ledger` 流水为真相 | 架构 §6.2 | +| **配额账本与点数账本的关系** | **同一张表**。V1 用 `system_grant`/`consume`/`refund` 三种 `tx_type`，V2 增加 `purchase`/`gift`，V2 上支付**无需数据迁移** | 架构 §6.2、§7.4 | + +### 6.2 仍待业务输入 + +本文档的待确认事项**已全部收口**，无遗留项。 + +唯一保留的开放项属于 V2 范畴，且需 V1 数据支撑： + +- [ ] 隐式记忆推断的阈值与确认时机 A/B 方案 —— V2 功能（`FR-MEM-08`），需 V1 行为数据支撑 +- [ ] V2 定价与点数消耗比 —— 依赖 V1 的真实成本与频次数据，并需按 IAP 抽成后的到账口径计算（`T-P6-16`） + +### 6.3 本轮补充的关键约束 + +| 约束 | 说明 | 依据 | +|------|------|------| +| 一键登录有资质门槛 | 华为账号一键登录（获取绑定手机号）**仅支持企业开发者**、仅面向中国大陆用户，需申请 `quickLoginMobilePhone` scope，且服务端必须部署在中国大陆。**已据此降级为 P1 推至 V2**（`TD-29`） | `TD-15` | +| **证书指纹配置** | AGC 需配置 SHA256 证书指纹，**调试证书与发布证书是两套**，指纹添加后最迟 25 小时生效（改 `versionCode` 可加速）。⚠️ 漏配的表现是**调试包登录正常、发布包登录失败**，很容易在临上线时才暴露。必须写入发布手册 | `TD-15` | +| ~~虚拟商品必须走 IAP~~ | **V1 不适用**（不接支付）。V2 起：会员、点数、全面报告均属虚拟商品，鸿蒙上必须接入 IAP Kit 并签署联运协议；Payment Kit 明确不支持虚拟商品；服务端必须做收据二次校验，`purchase_token` 唯一约束防重复发货 | `TD-16`、`FR-BILL-09` | +| 配额消耗采用预扣三段式 | `reserve`（冻结）→ `commit`（确认）/ `refund`（退还）。长耗时任务可能失败，直接扣会产生「扣了次数没结果」的客诉 —— **V1 无客服退款兜底，只能靠机制保证**。所有变更写流水，余额可由流水重算对账 | `FR-BILL-05`、架构 §7.4 | +| 游客合并策略 | 合并操作幂等；多设备场景以先登录设备为准并给用户明确提示 | `FR-ACC-03` | +| **备案编号需在设置页公示** | 「设置 → 关于」固定展示模型名称与备案编号，入口硬编码不可隐藏，且展示内容须与 LLM 网关实际路由同源 | `CR-08`、合规方案 §2.2.4 | --- -**文档版本**：v1.0 +**文档版本**：v1.2 **创建日期**：2026-08-11 +**更新日期**：2026-08-13 **作者**：产品团队 **状态**：待评审 +**变更说明**： +- v1.2（2026-08-13）：业务决策收口，§6 已无 V1 遗留待确认项 + - **§2.4 重构为「V1 只有配额，没有付费」**（`TD-28`）：拆为「§2.4.1 V1 配额表（唯一生效）」与「§2.4.2 V2 权益规划（仅架构预留）」。给出 V1 配额与任务奖励额度的具体数值，以及三条纪律（服务端硬限制、文案不出现价格字样、禁止静默扣减）。说明配额账本与点数账本共用同一张表，V2 上支付免数据迁移 + - **§2.1 登录方式调整**（`TD-29`）：一键登录由 P0 降为 **P1 并推至 V2**（需企业资质，属体验优化非能力缺口）；V1 用「华为账号授权登录 + 手机号验证码」双通道。强调证书指纹双套配置漏配时"调试包正常、发布包失败"的表现 + - **§2.2 移除主表 `points_balance` 字段**：余额统一存 `bl_wallet`，避免两处数据不一致；`member_level`/`member_expire_at` 保留为预留字段。`birthday` 用途收窄，五行推算已取消（`TD-31`） + - **§2.5 强化计量要求**：说明 V1 不收费反而让计量更重要 —— `ob_ai_call` 与 `bl_ledger` 是 V2 定价的唯一数据来源，不允许"先上线后补埋点" + - §2.3 用户中心新增「我的额度」与「关于（备案编号公示）」，移除五行模块开关 + - §5.1 新增两项红线指标：配额对账差异 = 0、额度提示中价格字样出现次数 = 0 +- v1.1（2026-08-13）：§6 待确认事项收口，7 项确认、3 项转入业务输入；补充一键登录的企业开发者资质门槛与 scope 申请要求、证书指纹双套配置、虚拟商品强制 IAP 与抽成影响、点数预扣三段式；明确向量库为 pgvector、端侧不缓存记忆明文 +- v1.0（2026-08-11）：初始版本 + **关联文档**： +- [文档索引](./README.md) +- [需求规格说明](./需求规格说明.md)（本文需求对应 `FR-ACC-*`、`FR-MEM-*`、`FR-BILL-*`） - [美搭 · 智能穿搭美学助手 产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md) +- [技术架构文档](./技术架构文档.md)（数据模型见 §6.2，记忆读写见 §8.4，配额与支付链路见 §7.4） +- [技术选型与调研报告](./技术选型与调研报告.md) +- [合规与安全方案](./合规与安全方案.md) - [美学报告需求文档](./美学报告-需求文档.md) - [穿搭 Agent 需求文档](./穿搭Agent-需求文档.md) - [美学知识库建设方案](./美学知识库-建设方案.md) diff --git a/docs/穿搭Agent-需求文档.md b/docs/穿搭Agent-需求文档.md index 93f7ef1..3783c9d 100644 --- a/docs/穿搭Agent-需求文档.md +++ b/docs/穿搭Agent-需求文档.md @@ -474,31 +474,53 @@ Agent 推荐发型（基于脸型知识） --- -## 10. 待确认事项 +## 10. 待确认事项（已收口） -- [ ] 大模型选型：GPT 系列 / 文心一言 / 讯飞星火 / 通义千问 / 自研（需评估合规备案要求） -- [ ] 语音识别方案：鸿蒙系统能力 / 第三方 ASR -- [ ] 对话数据存储策略与保留时长（建议 L3 摘要 180 天，原文更短） -- [ ] 内容审核方案：自建 / 第三方 -- [ ] 成本预算与调用配额（单轮 ≤ ¥0.05 是否可达） -- [ ] 长对话的摘要压缩策略与触发轮次 -- [ ] 是否需要"造型师人格"设定（语气、称呼、专业度分级） +### 10.1 已确认 -> 知识库技术方案（向量库 / 图谱 / RAG）与记忆系统技术方案的待确认项已移交对应独立文档，避免重复维护。 +| 原待确认项 | 结论 | 依据 | +|-----------|------|------| +| **大模型选型** | **DeepSeek 为主 + 智谱 GLM 为备**，通过**自建 LLM 网关**路由。对话与文案用 DeepSeek（单价低、缓存命中折扣显著、中文表达自然）；结构化抽取用轻量档；**图像理解用 GLM-4V 系**（DeepSeek 视觉覆盖不足）。**直接使用厂商官方 API，不走云平台 MaaS 中转** —— 因为备案与上架需要模型厂商侧的备案号与合作证明，云厂商无法代第三方模型厂商出具并盖章 | `TD-04`、`TD-19` | +| 为什么必须自建网关而非直接调 SDK | ① 成本可归因（无 `ob_ai_call` 表则无法回答「哪个功能在烧钱」）；② 可切换（国内模型调价与迭代极频繁）；③ 可降级（主备切换、配额耗尽降级）；④ Prompt 版本化（Prompt 是核心资产，要像代码一样有版本与回滚）；⑤ 合规单点（关键词拦截、输入输出审核、日志留存一处实现全场景覆盖） | 架构 §8.1 | +| 语音识别方案 | **鸿蒙 Core Speech Kit 端侧识别**，V2 功能。端侧延迟低、无音频外传（隐私更优）、无按量成本。准确率不达标时再评估云端 ASR 兜底 | `TD-14` | +| 内容审核方案 | **腾讯云天御 IMS（图片）+ TMS（文本）**，输入与输出**双向审核**。TMS 的自定义关键词库正好承载备案要求的拦截词库，并提供 AI 生成识别能力。**审核不可用时 fail-close**（按拦截处理）—— 与其他外部依赖的 fail-soft 策略相反，因为漏审一条违规内容的代价远高于短时功能不可用 | `TD-13`、`CR-06` | +| 成本预算与配额 | 单轮 ≤ ¥0.05 可达，**关键在缓存命中率**：主流模型缓存命中可将输入成本降至 1/5~1/30。因此**固定前缀纪律**是硬性设计要求 —— 系统提示词与稳定知识片段放 prompt 头部，且不得包含时间戳、随机 ID、用户昵称等变量，否则缓存永不命中、输入成本翻数倍。另设场景级日预算 + 用户级频控 + 日成本预警三道闸门 | `TD-04`、`NFR-COST-*` | +| 对话数据保留时长 | 对话原文 90 天；L3/L4 摘要 180 天；审核日志与生成记录 ≥ 6 个月（法定） | `CR-03`、`CR-11` | +| 长对话摘要压缩策略 | L4 滚动摘要存 `ag_conversation.rolling_summary`，压缩后 ≤ 400 token，关键约束（禁忌、明确偏好）不得在压缩中丢失。V2 功能 | `FR-MEM-10` | +| 「造型师人格」设定 | **做，但用统一人格 + 白话释义，不做人格分级**。人格通过系统 Prompt 固定（固定前缀还能提升缓存命中率）。专业术语必须配一句白话释义；外观表述遵循「描述而非评判」 | `NFR-UX-03`/`04` | + +### 10.2 本轮补充的实现约束 + +| 约束 | 说明 | 依据 | +|------|------|------| +| Token 预算硬性分配 | 系统提示词 ≤ 800、画像摘要 ≤ 500、会话摘要 ≤ 400、检索知识 ≤ 1500、用户输入 ≤ 500，**输入合计 ≤ 3700**，输出 ≤ 800。超限按优先级裁剪而非报错 | `FR-AGT-03`、架构 §7.2 | +| 每条回答必须可复盘 | `ag_message` 需存 `retrieval_trace`（检索轨迹）与 `rule_hits`（命中规则 ID）。没有这两个字段，「为什么这么答」永远查不清 | `FR-AGT-09` | +| 越界意图必须正确拒答 | 医疗诊断、身材贬损、评价他人、身份推断（收入/职业层级）均需拒答。这类约束要同时写入系统 Prompt、规则库禁忌用词表、生成后校验三处 | `CR-12`、合规方案 §3 | +| Agent 回复需 AI 生成显式标识 | 会话界面固定位置提示「内容由 AI 生成」 | `CR-05` | +| Prompt 注入防护 | 用户输入与系统指令严格分区；用户内容不得影响工具调用决策；输出侧校验 | `NFR-SEC-04` | +| 解释链事实来自数据库 | 「为什么推荐」的推理路径来自图谱遍历与规则 ID，LLM 只做自然语言转写 | `FR-AGT-13` | + +> 知识库技术方案（向量库 / 图谱 / RAG）与记忆系统技术方案的选型结论已在《技术选型与调研报告》统一收口，本文不重复。 --- -**文档版本**：v1.1 +**文档版本**：v1.2 **创建日期**：2026-08-11 -**更新日期**：2026-08-11 +**更新日期**：2026-08-13 **作者**：产品团队 **状态**：待评审 **变更说明**： +- v1.2（2026-08-13）：§10 待确认事项全部收口 —— 大模型定为 DeepSeek + GLM 双路由并自建网关（明确不走云平台 MaaS 中转，因备案需模型厂商合作证明）；语音用鸿蒙 Core Speech Kit；审核用腾讯云 IMS/TMS 双向且 fail-close；补充 token 预算硬性分配、缓存前缀纪律、回答可复盘字段、越界拒答三处落点等实现约束 - v1.1：明确 Agent 与记忆系统、知识库的依赖边界；§3.4 改为规则前置的混合检索链路并补充防幻觉红线；§3.5 改为记忆读取与注入策略（含 token 预算与画像摘要示例）；补充 Phase 1 的画像注入、生成后校验、知识缺口埋点等任务 - v1.0：初始版本 **关联文档**： +- [文档索引](./README.md) +- [需求规格说明](./需求规格说明.md)（本文需求对应 `FR-AGT-01`~`FR-AGT-18`） - [美搭 · 智能穿搭美学助手 产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md) +- [技术架构文档](./技术架构文档.md)（对话链路见 §7.2，LLM 网关见 §8.1，混合检索见 §8.3） +- [技术选型与调研报告](./技术选型与调研报告.md) +- [合规与安全方案](./合规与安全方案.md) - [美学报告需求文档](./美学报告-需求文档.md) - [用户系统与记忆系统需求文档](./用户系统与记忆系统-需求文档.md) - [美学知识库建设方案](./美学知识库-建设方案.md) diff --git a/docs/美学报告-需求文档.md b/docs/美学报告-需求文档.md index f1b6b72..5abb4a6 100644 --- a/docs/美学报告-需求文档.md +++ b/docs/美学报告-需求文档.md @@ -138,9 +138,13 @@ - 材质与图案选择指南 - 一键试穿入口 -#### 可选模块：幸运色（五行） -- 输入生日 → 推导年月日柱五行分布 → 缺失/旺盛属性 → 幸运色建议 → 场景化应用 → 四季动态调整 -- **合规要求**：必须标注"娱乐性质，不构成任何决策建议"，且提供**全局开关可关闭**（详见 §9.3） +#### ~~可选模块：幸运色（五行）~~ —— 已决定不做 + +**该模块 V1 与 V2 均不纳入**（`TD-31`，2026-08-13 决策）。原设计为「输入生日 → 推导五行分布 → 幸运色建议」，现整体移除。 + +**移除理由**：收益边缘（不影响诊断准确性，也不是用户使用产品的理由），但风险是全局的 —— 命理内容在部分应用市场属敏感类目，一个模块可能拖累整个应用上架。保留一个"可关闭开关"并不能免除为它准备合规材料与审核话术的成本。 + +**连带影响**：诊断维度由 34 项减为 **32 项**（删除 `#33 五行分布`、`#34 幸运色`）；`birthday` 字段保留但用途收窄为生日权益与年龄段判断（见 §9.3）。 #### 增量创新：30 天形象提升计划 线下报告普遍缺失的部分，也是本产品的差异点：把结论拆成可执行的 30 天任务清单（第 1 周替换基础单品、第 2 周引入配饰、第 3 周尝试色彩升级……），配合打卡与前后对比，把一次性报告变成持续留存的产品。 @@ -152,14 +156,16 @@ | 参考报告板块 | 本方案对应 | 初级 | 全面 | |-------------|-----------|:----:|:----:| | 个人风格核心诊断（风格密码/基因风格/心理风格） | 篇章一 | 粗判 Top1 | ✅ 完整 | -| 面部色彩维度 + 四季色彩定位 + 色板 | 篇章二 | 四季粗判 + 8 色 | ✅ 十二季 + 完整色板 | +| 面部色彩维度 + 季型定位 + 色板 | 篇章二 | 冷暖×明度四类粗判 + 8 色 | ✅ 十二季型 + 完整色板 | | 身材分析与穿搭指南 | 篇章三 | 3 条要点 | ✅ 逐品类四要素 | | 配饰规划 | 篇章四 | ❌ | ✅ | | 发型报告 | 篇章五 | 3 条要点 | ✅ 独立成篇 | | 分场景穿搭方案 | 篇章六 | 1 场景 | ✅ 4+ 场景 | -| 幸运色（五行） | 可选模块 | ❌ | ✅ 可关闭 | +| ~~幸运色（五行）~~ | **不做**（`TD-31`） | ❌ | ❌ | | —（本产品增量） | 30 天提升计划 | ❌ | ✅ | +> ⚠️ **命名合规**：上表左列为参考报告的原始板块名，仅用于对照。本产品对外文案**不得使用「四季色彩」「CMB / Color Me Beautiful」**（国内已注册商标），季型一律使用自研的描述性命名。见 `TD-18`。 + ### 2.5 付费策略与第一版落地方式 **第一版（V1）明确不做支付**，但要做**付费意愿验证**，这是本节最重要的产品决策： @@ -170,16 +176,20 @@ - 记录：预约用户数 / 预约率 / 停留时长 / 点击价格档位 - 决策门槛：若预约率 ≥ 8%，V2 立即开发付费全面报告；若 < 3%，重新评估定价与内容形态 -**V2 定价设计**（待验证后确认）： +> ⚠️ **V1 的预览卡片不得展示具体价格**。原设计中的「预计价格 / 点击价格档位」已移除 —— V1 全产品线不出现任何价格与购买字样（产品方案 §3.2 纪律二），否则会污染 V2 的定价空间，也会让用户形成"处处收费"的第一印象。预约卡片只展示**内容清单与模糊化目录截图**，收集"想要"的意愿，不收集"愿意付多少"。 +> +> 价格敏感度改用**线下用户访谈**采集（`T-P0-24`），这比在 App 里挂一个假价格更准，也没有副作用。 -| 购买方式 | 价格 | 说明 | -|---------|------|------| -| 单次购买 | ¥29.9 | 主力售卖形态，一次生成永久可查 | -| 会员价 | ¥19.9 | 会员用户折扣 | +**V2 定价设计**（⚠️ 全部为占位草案，不可作为开发依据）： + +| 购买方式 | 价格（占位） | 说明 | +|---------|------------|------| +| 单次购买 | 待定 | 主力售卖形态，一次生成永久可查 | +| 会员价 | 待定 | 会员用户折扣 | | 高级版权益 | 含 1 次/季 | 季度重新诊断 | -| 重新生成 | ¥9.9 | 已购用户身材/季节变化后更新（非全价） | +| 重新生成 | 待定（低于全价） | 已购用户身材/季节变化后更新 | -> **定价依据**：线下形象诊断服务客单价 300~2000 元，AI 报告定位为"十分之一价格、八成内容"，¥29.9 处于冲动消费区间且显著高于会员月费 ¥9.9 的边际收益，适合做单点变现主力。 +> **定价的参考锚点**（不是结论）：线下形象诊断服务客单价 300~2000 元，AI 报告可定位为"十分之一价格、八成内容"。但最终定价必须满足三个前提，缺一不可：① V1 采集到的单次真实成本；② V1 的人均使用频次；③ 扣除华为 IAP 约 30% 抽成后的到账口径。三者齐备前的任何数字都是猜测（`TD-16`、`T-P6-16`）。 --- @@ -346,8 +356,8 @@ | 30 | 偏好与禁忌 | 喜欢/不接受的风格、颜色、品类、露肤度 | 问卷 + 行为 | 部分 | ✅ | | 31 | 发长与卷度现状 | 短/中/长 × 直/微卷/大卷 | 视觉分析 | ❌ | ✅ | | 32 | 发色现状 | 色值 + 冷暖 | 视觉分析 | ❌ | ✅ | -| 33 | 五行分布 | 金木水火土计数 | 生日推算 | ❌ | ✅（可关闭） | -| 34 | 幸运色 | 色值列表 | 五行映射 | ❌ | ✅（可关闭） | + +> ~~`#33 五行分布`、`#34 幸运色`~~ 已于 2026-08-13 移除（`TD-31`），维度总数由 34 项减为 **32 项**。编号 33/34 **不再复用**，避免历史数据与文档交叉引用错位。 > 每个维度的输出必须携带 `confidence`（0~1）与 `source`（`vision` / `self_reported` / `rule` / `llm`），低置信维度在报告中以"参考"语气呈现，并允许用户手动修正。用户修正后置信度置为 1.0 且标记 `user_confirmed`。 @@ -502,10 +512,14 @@ - 报告不得包含医疗、减肥、整形等医疗健康建议（如"建议减重"需改为中性表述），避免越界 - 禁止对用户外貌做负面评价性表述（"腿粗""脸大"等），统一改为中性描述 + 修饰策略（"下半身量感偏大 → 建议…"）。这是文案红线，需建立敏感词表在 ⑧ 校验环节强制过滤。 -### 9.3 五行/命理模块的合规处理 -- 定位为**娱乐模块**，标注"仅供娱乐，不构成任何建议" -- 提供全局开关（设置页可关闭，关闭后报告不含该章节） -- 应用商店审核风险：部分渠道对命理内容敏感，需准备"关闭该模块"的可配置开关（服务端下发），避免因单一模块影响整体上架 +### 9.3 命理内容：不做，并作为越界话题拒答 + +**五行/幸运色模块已决定不做**（`TD-31`），因此不需要娱乐声明、不需要全局开关、不需要为其准备渠道审核话术 —— 这些成本一并消除。 + +仍需落地的两条约束： + +- **对话中的命理类提问按越界处理**（`CR-12`）：不推算、不暗示，统一拒答并引导回穿搭议题。这与是否做该模块无关，属于 Agent 的边界能力 +- **`birthday` 字段用途收窄**：仅用于生日权益与年龄段判断（影响风格建议的适龄性），**不得用于任何命理推算**。字段本身保留，但推算逻辑不实现 ### 9.4 准确性保障 - 建立 **100 例黄金评测集**（由专业形象顾问标注体型/脸型/季型/风格），每次算法或知识库更新回归测试 @@ -551,25 +565,62 @@ --- -## 11. 待确认事项 +## 11. 待确认事项（已收口） -- [ ] 视觉分析能力来源：自研模型 / 第三方 API（体型关键点、面部关键点、肤色采样分别选型） -- [ ] 十二季细分色彩的算法方案与专业校准方（是否引入外部形象顾问背书） -- [ ] 报告长图/PDF 渲染方案：端侧 Canvas / 服务端渲染（服务端更可控但成本更高） -- [ ] 报告数据保留期限与注销后删除时效（建议注销后 7 日内彻底删除） -- [ ] 五行模块是否纳入 V2（合规与审核风险评估） -- [ ] 全面报告定价与内容边界的最终确认（依赖 V1 预约率数据） -- [ ] 专业顾问合作：是否引入 1~2 位持证形象顾问参与规则校准与黄金集标注 -- [ ] 报告术语体系的本地化命名（"量感/直曲"对普通用户认知门槛较高，是否需要更通俗的替代表述） +### 11.1 已确认 + +| 原待确认项 | 结论 | 依据 | +|-----------|------|------| +| 视觉分析能力来源 | 人脸属性与关键点走**腾讯云**（`DetectFaceAttributes` / `AnalyzeFace` 90 点 / `AnalyzeDenseLandmarks` 888 点，后者仅全面报告用）；**人体关键点自建 RTMPose ONNX**；肤色/唇色/发色取值**自研 Lab 采样**（云 API 只给分类，我们需要可进入色彩计算的实际色值） | `TD-05` | +| 体型测算算法 | **人像分割掩膜宽度剖面法 + 关键点定高**：骨骼关键点给的是关节位置而非轮廓宽度，只用关键点会系统性低估肩宽。仅输出无量纲比例，不承诺量体尺寸 | `TD-06` | +| 十二季色彩算法与校准 | **自建色板**（自采 Lab 色域边界与代表色），季型采用描述性自研命名。**不得使用「四季色彩」「CMB / Color Me Beautiful」等已注册商标**，也不得直接复制他人色布/色卡的色值集合 | `TD-18` | +| 报告长图/PDF 渲染 | **服务端渲染**（HTML 模板 + Playwright）。报告是分享传播的核心资产，必须跨设备一致、可加水印与 AI 标识元数据、可在分享前审核。端侧 Canvas 仅作降级方案 | `TD-12` | +| 报告数据保留与删除时效 | 报告与结果图随账号存续；注销后 7 日内彻底删除（含 COS 对象），删除执行有记录可审计 | `CR-03`、合规方案 §4.3 | +| 报告术语的通俗化 | 采用**「专业术语 + 一句白话释义」并列展示**，不改名。既保留专业感，又降低理解门槛 | `NFR-UX-03` | +| 专业顾问合作 | **全职编制的形象顾问**参与规则校准与黄金集标注（不是外部按条计酬）。产能可控、可深度参与知识库后台设计 | `TD-27` | +| 五行/命理模块 | **不做**（V1 与 V2 均不纳入）。诊断维度由 34 项减为 32 项，见 §9.3 | `TD-31` | +| V1 是否收费 | **完全不收费**。全面报告只做预约留资，且**预览卡片不展示价格**；配额限制替代付费门槛 | `TD-28` | +| 全面报告定价 | **推迟到 V2**，前提是 V1 采齐三类数据（单次真实成本、人均频次、预约率），并按 IAP 抽成后的到账口径计算 | `TD-16`、`T-P6-16` | + +### 11.2 仍待业务输入 + +本文档的待确认事项**已全部收口**，无遗留项。 + +唯一与本文档相关的外部不确定项：备案登记覆盖的模型清单是否包含 DeepSeek 与智谱 GLM 两家（`TD-19`）—— 若只覆盖一家，报告生成的 LLM 路由需相应调整，但不影响报告的需求定义。 + +### 11.3 新增的合规约束（本轮调研补充） + +| 约束 | 说明 | 依据 | +|------|------|------| +| **人脸原图不落盘** | 上传直传 COS 临时桶（生命周期 ≤ 2 小时），Worker 处理后**显式删除**，仅保留派生的结构化特征。这使「存储的人脸信息数量」恒为 0，从架构上规避 10 万人备案阈值 | `CR-02`、`TD-20` | +| 禁止存储生物识别特征 | 不得存储人脸特征向量，也不得存储 888 点稠密关键点原始坐标（精度足以重建轮廓），只保留归一化比例与分类结论 | 合规方案 §2.1.2 | +| 人脸单独同意 | 必须是独立同意页，不可混入总协议；拒绝后仍可走问卷降级路径 | `CR-01`、`FR-RPT-11` | +| 报告产物双重标识 | 长图/PDF 需含可见「AI 生成」标识 + 文件元数据隐式标识（含 27 位内容编号）；**分享图路径必须单独验证** | `CR-05` | +| 生成后校验新增贬损词检测 | 除禁忌违反、色值越界外，还需检测贬损性表述与医疗化表述 | `FR-RPT-08`、`CR-12` | --- -**文档版本**：v1.0 +**文档版本**：v1.2 **创建日期**：2026-08-11 +**更新日期**：2026-08-13 **作者**：产品团队 **状态**：待评审 +**变更说明**： +- v1.2（2026-08-13）：业务决策收口，§11 已无遗留待确认项 + - **五行/幸运色模块整体移除**（`TD-31`）：诊断维度由 34 项减为 **32 项**，编号 33/34 不再复用；§9.3 由「命理模块的合规处理」改为「不做 + 越界拒答」；`birthday` 用途收窄为生日权益与年龄段判断 + - **§2.5 移除价格展示**：V1 预约卡片不得出现任何价格与档位（原设计含「预计价格」「点击价格档位」），价格敏感度改用线下访谈采集；V2 定价表全部改为占位，并列明定价的三个前提 + - **形象顾问确定为全职编制**（`TD-27`），非外部按条计酬 + - §2.4 补充命名合规提醒：对外文案不得使用「四季色彩」「CMB」等注册商标 +- v1.1（2026-08-13）：§11 待确认事项收口，7 项确认、3 项转入业务输入；补充本轮调研得出的 5 项合规约束（人脸原图不落盘、禁存生物特征、单独同意、双重 AI 标识、贬损词检测）；明确视觉能力选型（腾讯云人体关键点接口已于 2025-10-30 下线，改为自建 RTMPose） +- v1.0（2026-08-11）：初始版本 + **关联文档**： +- [文档索引](./README.md) +- [需求规格说明](./需求规格说明.md)（本文需求对应 `FR-RPT-01`~`FR-RPT-18`） - [美搭 · 智能穿搭美学助手 产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md) +- [技术架构文档](./技术架构文档.md)（报告生成链路见 §7.1，视觉服务见 §8.2） +- [技术选型与调研报告](./技术选型与调研报告.md) +- [合规与安全方案](./合规与安全方案.md) - [穿搭 Agent 需求文档](./穿搭Agent-需求文档.md) - [用户系统与记忆系统需求文档](./用户系统与记忆系统-需求文档.md) - [美学知识库建设方案](./美学知识库-建设方案.md) diff --git a/docs/美学知识库-建设方案.md b/docs/美学知识库-建设方案.md index 0c3bb1b..417db03 100644 --- a/docs/美学知识库-建设方案.md +++ b/docs/美学知识库-建设方案.md @@ -340,10 +340,34 @@ Agent 和报告推荐的实际交付物是"成套 look"，而非零散规则。 | 色板图 | 程序化生成（由色值渲染），不手工制图 | | 体型/脸型图示 | 统一插画风格，避免真人照片的合规风险 | -- 抠图流水线：原图 → 自动抠图（分割模型）→ 白底合成 → 质量抽检 → 入库并置 `tryon_ready = true` -- 版权：所有图像资产必须有明确授权来源（自拍摄 / 商用授权库 / 品牌授权 / AI 生成），**禁止直接抓取电商与社交平台图片**，需建立 `license` 字段与审核环节 +- 抠图流水线：原图 → BiRefNet 抠图（`TD-07`）→ 白底合成 → 质量抽检 → 入库并置 `tryon_ready = true` +- **版权来源已收口为「全部自采」**（`TD-26`）：不采购授权图库、不使用品牌供图、**禁止抓取电商与社交平台图片**。`license` 字段统一标记 `self_shot` - AI 生成素材需标注 `ai_generated = true`，符合生成内容标识要求 +#### 4.2.1 素材自采流水线（`TD-26` 落地方案） + +**为什么定为全部自采**：这是唯一版权彻底干净的路径。图库授权通常限制"用于生成合成内容"的场景，品牌供图受合作关系约束（合作终止即须下架），而素材库是我们的核心资产之一，不能建在别人的授权之上。另外实物在手时属性标注的准确率远高于靠图片反推，而属性准确性直接决定检索与推荐质量。 + +**五个工序**： + +| 工序 | 内容 | 输出 | 质检标准 | +|------|------|------|---------| +| ① 采购 | 按品类与季型需求清单采购实物 | 实物 + 采购凭证 | 覆盖计划中的 `tryon_slot` 与色系分布 | +| ② 拍摄 | 白底棚拍，正面平铺或正挂，无模特 | 原始图（RAW/高质量 JPG） | 见下方拍摄规范 | +| ③ 抠图 | BiRefNet 批量处理 → 白底合成 | 标准化白底图 | 边缘无残留、无破洞，人工抽检通过率 ≥ 90% | +| ④ 标注 | 品类、`tryon_slot`、色值（Lab）、材质、版型、季型适配、场合 | 结构化属性 | 必填项无缺失；色值由实物取样而非图片估计 | +| ⑤ 入库 | 置 `tryon_ready`、`license=self_shot`，归档原始文件 | 可用素材 | 换装接口实测可出图 | + +**拍摄规范（`T-P0-22` 需定稿为 SOP）**：纯白背景、均匀无影灯光、主体占比 > 70%、长边 1024~2048px、正面无透视畸变、无水印无标牌遮挡。**规范必须写到新人照做即可的程度** —— 拍摄是重复性工序，标准不明确会导致大量返工，而返工的代价是重新占用棚时。 + +**产能是本项目的关键路径（必须正视）**： + +备案已完成后，素材自采成为**唯一无法靠 AI 辅助开发压缩的工序** —— 采购要等物流、拍摄要占棚时、质检要人眼。因此： + +- `T-P0-21` 的核心交付物不是"跑通流程"，而是**测出每周产能**（件/周），据此倒排 300 件 `tryon_ready` 的达成时间 +- 若产能不足，**降级路径要提前定好**：优先保证「上衣 + 裤子」两个 `tryon_slot`（换装接口仅支持这两类），其余品类只做「加入搭配」不做「一键试穿」 +- **不要用"再等等素材"来阻塞功能上线** —— 功能按已有素材量降级发布，素材持续补充 + --- ## 5. 建设流程 @@ -353,29 +377,49 @@ Agent 和报告推荐的实际交付物是"成套 look"，而非零散规则。 | 阶段 | 内容 | 产出 | 人力与周期 | |------|------|------|-----------| | **P0 本体定义** | 定义 12 类实体的字段、枚举值、关系；建立属性字典 | Schema 文档 + 数据库表 | 产品 + 架构，1 周 | -| **P1 专家冷启动** | 形象顾问撰写核心规则、色板、风格定义；产品整理场景模板 | 800 条规则 + 12 季色板 + 9 型风格 + 20 场景 | 顾问 2 人 + 产品 1 人，3~4 周 | -| **P2 素材生产** | 单品图采集/拍摄 → 抠图 → 属性标注；60 款发型补齐标签 | 800+ 单品（含试穿图）+ 60 发型标签 | 运营 2 人，3 周（可并行） | +| **P1 专家冷启动** | **全职形象顾问**撰写核心规则、色板、风格定义；产品整理场景模板 | 800 条规则 + 12 季色板 + 9 型风格 + 20 场景 | **全职顾问 1 人** + 产品 1 人，按实际产能倒排 | +| **P2 素材生产** | **自采**：采购 → 拍摄 → 抠图 → 属性标注；60 款发型补齐标签 | V1 目标 **300 件 `tryon_ready`** + 60 发型标签 | 运营 2 人，产能待 `T-P0-21` 实测 | | **P3 方案组装** | 由规则 + 单品组合出成套 look，顾问审核 | 300~500 套 Outfit | 顾问 + 运营，2 周 | | **P4 半自动扩充** | LLM 从专业书籍/公开资料抽取候选知识 → **人工审核后入库** | 规则与文本扩充至 2000+ 条 | 持续 | > **关键判断**：P1（专家冷启动）不可跳过、不可用大模型代替。这 800 条规则是产品专业性的地基，也是唯一无法被竞品快速复制的资产。用 LLM 生成规则再让顾问审核，效率高于纯人工，但**审核环节是准确率红线，不可省略**。 +> ⚠️ **两处口径修正**：① 原「800+ 单品」是长期目标，**V1 的硬指标是 300 件 `tryon_ready`**（与产品方案 §7.1.5、`FR-KB-08` 对齐）；② 原「3~4 周」「3 周」的周期估算已删除 —— 全职顾问与自采流水线的实际产能需由 `T-P0-20`/`T-P0-21` 实测后倒排，凭估算排期在这两项上风险最高。 + +#### 5.1.1 全职形象顾问的工作流（`TD-27` 落地方案） + +**为什么是全职而非外部按条计酬**：规则库不是一次性交付物。800 条写完只是起点，之后要根据用户反馈与结论修正率反复校准 —— 而按条计酬的外部顾问在"交付完成"后就没有继续投入的动力，恰恰错过质量提升最关键的阶段。另外黄金评测集若由多位外部顾问分批标注，口径漂移几乎不可避免，而黄金集是所有质量指标的基准，口径一旦不稳，后续准确率数字就失去意义。 + +**顾问的四项职责（按投入顺序）**： + +| # | 职责 | 交付物 | 与开发的接口 | +|---|------|-------|------------| +| 1 | 本体 Schema 评审 | 修订意见 | 到岗第一件事。字段设计错了后面全要返工，**必须在建表前完成** | +| 2 | 规则库撰写与校准 | 800 条规则（含 `is_hard` 标记与解释链） | 通过运营后台自行录入，不经工程转录 | +| 3 | 黄金评测集标注 | 100~200 例标注样本 | 单人标注保证口径一致 | +| 4 | 持续校准 | 按结论修正率与用户反馈迭代规则 | 长期职责，是全职的主要理由 | + +**这对运营后台提出了更高要求**：顾问是后台的**日常使用者**而非偶尔录入者。因此后台的易用性直接决定规则库产能 —— 一个难用的后台会让顾问的有效产出打对折。这是 `TD-25` 把极简后台从 Phase 2 提前到 V1 的核心原因，也意味着后台应在顾问到岗后**根据其真实使用反馈快速迭代**，不能一次交付就不管。 + +**排期上的含义**：顾问到岗时间直接决定 P1 启动时间，进而决定 M2 与 M3 的时间。因此 `T-P0-20`（招聘）应与技术验证**并行且最早启动**，不要等技术方案确定后再招人。 + ### 5.2 内容来源与合规 | 来源 | 使用方式 | 注意事项 | |------|---------|---------| | 专业书籍/教材（色彩理论、服装造型学） | 提炼知识点，**不得整段摘录** | 版权风险，需重述表达 | -| 认证形象顾问经验 | 结构化访谈 + 撰写 | 建立署名与背书（可作为营销资产） | +| **全职形象顾问**（`TD-27`） | 直接撰写与校准，通过后台录入 | 建立署名与背书（可作为营销资产） | | 公开时尚媒体/品牌资料 | 趋势类参考 | 标注来源，不复制图片 | | 用户 UGC 与行为数据 | 高采纳方案入候选库 | 需审核 + 用户授权 | | AI 生成 | 初稿与扩充 | 必须人审，标注 `ai_generated` | +| **单品图像素材** | **全部自采实拍**（`TD-26`） | 不采购图库、不用品牌供图、不抓取平台图片；保留采购凭证与原始文件 | ### 5.3 数据治理 - **版本化**：知识库整体带版本号（如 `kb-v1.3`），报告与推荐记录生成时使用的知识库版本，便于问题追溯与结论复现 - **审核工作流**：`草稿 → 顾问审核 → 抽检 → 发布`，每条知识记录 `reviewer` 与 `reviewed_at` - **变更影响评估**：修改高优先级规则前，跑黄金集回归，评估对历史报告的影响 -- **运营后台**：必须提供知识库管理后台（增删改查 + 审核 + 版本对比 + 效果看板），否则知识库无法迭代。这是常被漏排的开发工作量，需在 Phase 2 立项。 +- **运营后台**：必须提供知识库管理后台（增删改查 + 审核 + 版本对比 + 效果看板），否则知识库无法迭代。**V1 就要做极简版**（`TD-25`）—— 全职顾问是它的日常使用者，后台易用性直接决定规则库产能。 --- @@ -470,38 +514,83 @@ Agent 和报告推荐的实际交付物是"成套 look"，而非零散规则。 | 项目 | 第一版目标 | 说明 | |------|-----------|------| | 规则条目 | 800 条 | 覆盖 5 体型 × 12 局部 × 主要场景 | -| 单品实体 | 800 条（其中 ≥ 400 条 `tryon_ready`） | 试穿闭环的最小可用量 | +| 单品实体 | 长期 800 条；**V1 硬指标 300 条 `tryon_ready`** | 试穿闭环的最小可用量；全部自采（`TD-26`） | | 搭配方案 | 300 套 | 覆盖 4 场景 × 12 季型的基本组合 | | 色彩条目 | 400 色 + 12 套色板 | — | | 发型标签 | 60 款全量打标 | 补齐现有发型库 | | 文本知识块 | 1500 块 | 用于 RAG | | 图像资产 | 2000 张 | 含单品/look/发型/图示 | -| 人力投入 | 顾问 2 人 × 1 月 + 内容运营 2 人 × 1.5 月 + 开发 1.5 人月（后台） | 预估 12~18 万元 | +| 人力投入 | **全职顾问 1 人**（`TD-27`）+ 内容运营 2 人 + 开发 1.5 人月（后台） | 预估 12~18 万元；**另需计入单品采购与棚拍成本**（自采模式新增，`TD-26`） | +| 自采单品成本 | 300 件 × 单件采购均价 + 棚拍与抠图人工 | ⚠️ 需在 `T-P0-21` 跑通流水线后按实际单件成本核算 | | 存储与检索成本 | 月度 < ¥2000 | 向量库 + 对象存储 + CDN | > 分期建议：V1 只需**规则 400 条 + 单品 300 条 + 方案 100 套 + 发型 60 款打标 + 12 套色板**即可支撑初级报告与基础对话，其余在 V2 补齐。不要为了知识库的完整性阻塞首版上线。 --- -## 10. 待确认事项 +## 10. 待确认事项（已收口） -- [ ] 技术选型：向量库（自建 Milvus/Qdrant vs 云服务）、图谱（Neo4j vs 关系库邻接表，V1 建议后者） -- [ ] 规则引擎方案：自研决策表 vs 开源规则引擎 -- [ ] 形象顾问合作模式：外部顾问按条计酬 vs 全职招聘 vs 顾问入股 -- [ ] 单品素材来源：自拍摄成本 vs 商用图库授权 vs 品牌合作供图（影响 400 条 `tryon_ready` 的达成方式） -- [ ] 抠图流水线的模型选型与准确率验收标准 -- [ ] 知识库管理后台的开发排期（建议 Phase 2 立项，不可依赖数据库直接改数据） -- [ ] 是否引入外部专业内容授权（如引进现有色彩体系授权，加速冷启动） -- [ ] 12 季色彩体系的版权确认（部分色彩体系存在商业授权要求） +### 10.1 已确认 + +| 原待确认项 | 结论 | 依据 | +|-----------|------|------| +| 向量库 | **PostgreSQL + pgvector**，不引入 Milvus/Qdrant。知识库向量在万级到十万级，远未到需要专用库的量级；且检索链路的第一步是硬过滤（季型、场合、体型禁忌），这是典型 SQL `WHERE`，专用向量库的元数据过滤反而是短板。**切换条件**：向量 > 500 万，或过滤后召回 p99 > 200ms 且确认无法通过索引优化解决 | `TD-08` | +| 图谱 | **PG 邻接表 `kb_relation` + 递归 CTE**，不上 Neo4j。我们的图查询是有界的 1~3 跳浅层遍历，递归 CTE 完全够用；Neo4j 的价值在任意深度路径与图算法，我们不需要，却要为它承担独立运维与数据同步 | `TD-09` | +| 规则引擎 | **自研数据驱动决策表**，规则以 JSON DSL 存库。规则形态高度规整（条件 → 建议/禁忌 → 权重 → 依据），本质是决策表；且必须由顾问在后台维护而非写代码。通用规则引擎的表达能力我们用不到 20%，却要接受其 DSL 学习成本与调试困难。自研可直接透出「命中规则 ID 列表」，天然满足可解释与可审计 | `TD-10` | +| **抠图模型** | **BiRefNet**（开源可商用）自建，离线批处理。⚠️ **禁用 RMBG-2.0** —— 它是被引用最多的「开源抠图模型」，但许可是 **CC BY-NC 4.0，仅限非商业使用**，商用需与 BRIA 单独签协议。同样提醒：`rembg` 库本身是 MIT，但其封装的 18+ 模型各自许可不同 | `TD-07` | +| 抠图验收标准 | 10 件样本走通「原图 → 抠图 → 白底标准化 → 规格校验 → 入库 → 换装可用」全流程；人工质检通过率 ≥ 90%；边缘毛刺与透明材质失败样本走人工修图 | `FR-KB-08`、`T-P0-12` | +| **12 季色彩体系版权** | **自建色板，不引进外部授权**。四季/十二季理论本身属思想与方法，不受著作权保护，可借鉴其冷暖/明度/纯度三维划分逻辑；但「四季色彩」「CMB / Color Me Beautiful」在国内**存在注册商标**，不得用作服务名称、功能名称或宣传标识；他人的具体色布/色卡集合（如某机构的「20+2 鉴定色布」）属独创性劳动成果，直接复制其色值集合存在侵权风险 | `TD-18` | +| 是否引进外部内容授权 | **不引进**。改为自建色板 + **全职顾问**撰写与校准，既规避授权与商标风险，又形成自有资产 | `TD-18`、`TD-27` | +| **单品素材来源** | **全部自采实拍**。不采购授权图库、不使用品牌供图。版权最干净、规格可统一、属性可在拍摄时同步准确记录。**代价是这成为项目的关键路径**（备案已完成后，它是最长工序），详见 §4.2.1 | `TD-26` | +| **形象顾问合作模式** | **全职编制**。规则库需持续迭代而非一次交付；顾问是运营后台的日常使用者；黄金集需单人标注保证口径一致。详见 §5.1.1 | `TD-27` | +| 知识库管理后台排期 | **提前到 V1，做极简版**（条目 CRUD、规则编辑与发布、素材上传与抠图触发、审核、发布回滚）。知识库是持续运营的资产，靠改数据库运营意味着每次内容更新都要工程介入，冷启动阶段会直接卡住内容生产节奏。完整的版本管理与效果看板留到 V2 | `TD-25`、`FR-ADM-01`~`04` | +| Embedding 模型 | 自建 **BGE-M3**。条目量级不大且更新不频繁，离线批量向量化即可；自建避免向量维度被厂商绑定。`kb_chunk` 保留 `embedding_model` 与 `embedding_version` 字段以支持双写平滑迁移 | `TD-22` | +| 属性标注降本 | 引入**视觉大模型辅助预标注**（智谱提供开箱的衣物识别智能体 `clothes_recognition_agent`，可输出品类/颜色/材质/款式/版型/图案/风格/领型等结构化属性）+ 人工复核。预标注准确率 ≥ 70% 即达标（目的是降低人工量，不是替代人工） | `TD-04`、`FR-KB-12` | + +### 10.2 仍待业务输入 + +本文档的待确认事项**已全部收口**，无遗留项。 + +需要持续关注的不是决策，而是**两项产能数据**（它们决定排期，但只能实测得出）： + +| 待实测 | 任务 | 用途 | +|-------|------|------| +| 自采流水线每周产能（件/周） | `T-P0-21` | 倒排 300 件 `tryon_ready` 的达成时间 | +| 全职顾问规则产出速率（条/周） | `T-P0-20` | 倒排 M2 知识库可运营的时间 | + +### 10.3 本轮补充的实现约束 + +| 约束 | 说明 | 依据 | +|------|------|------| +| 硬约束必须在生成后强制校验 | 规则的 `is_hard=true` 项不能只当作提示词。LLM 输出的搭配方案要逐项比对禁忌规则，违反则重新生成或剔除。这是「禁忌违反 = 0」这条质量指标的唯一可靠实现方式 | `TD-10`、`FR-KB-05` | +| 解释链的事实部分不得由 LLM 生成 | 「为什么推荐」的推理路径必须来自数据库的图谱遍历路径与命中规则 ID，LLM 只做自然语言转写。否则解释听起来专业但不可审计，恰恰违背自建知识库的初衷 | `TD-09`、`FR-AGT-13` | +| 知识库版本号驱动缓存失效 | 所有检索缓存键带全局 `kb_version`，发布时版本号 +1，旧缓存自然失效，不需精确追踪受影响缓存 | 架构 §10 | +| 内容伦理约束写入规则库 | 「描述而非评判」「不使用缺陷框架」「不做医疗判断」等红线需同时落在三处：系统 Prompt、规则库禁忌用词表、生成后校验。缺一处就会漏 | 合规方案 §3 | +| 每条内容必须有 `source` 与 `license` | 杜绝来源不明的内容混入，这是版权风险的第一道闸门 | `FR-KB-03` | --- -**文档版本**：v1.0 +**文档版本**：v1.2 **创建日期**：2026-08-11 +**更新日期**：2026-08-13 **作者**：产品团队 **状态**：待评审 +**变更说明**： +- v1.2（2026-08-13）：业务决策收口，§10 已无遗留待确认项 + - **§4.2.1 新增「素材自采流水线」**（`TD-26`）：素材来源定为**全部自采实拍**，不采购图库、不用品牌供图。给出五个工序（采购→拍摄→抠图→标注→入库）、拍摄规范要点、以及产能倒排要求。⚠️ 明确指出**备案完成后素材自采成为项目关键路径**，并预设了产能不足时的降级路径（优先保上衣+裤子两个 `tryon_slot`） + - **§5.1.1 新增「全职形象顾问工作流」**（`TD-27`）：顾问定为**全职编制**，四项职责按投入顺序排列（本体 Schema 评审须在建表前完成 → 规则库撰写 → 黄金集标注 → 持续校准）。指出顾问是运营后台的日常使用者，后台易用性直接决定规则库产能 + - **§5.1 修正两处口径**：V1 单品硬指标由「800+」改为**300 件 `tryon_ready`**；删除「3~4 周」等周期估算，改为按 `T-P0-20`/`T-P0-21` 实测产能倒排 + - §9 成本估算新增自采单品采购与棚拍成本项 +- v1.1（2026-08-13）：§10 待确认事项收口，10 项确认、2 项转入业务输入；关键变更三处 —— ① 抠图明确用 BiRefNet 并**禁用 RMBG-2.0**（非商用许可）；② 12 季色彩体系改为**自建色板 + 规避 CMB/四季色彩商标**，不引进外部授权；③ 知识库管理后台从 Phase 2 **提前到 V1 极简版**。另补充硬约束强制校验、解释链事实不得由 LLM 生成、版本号驱动缓存失效等实现约束 +- v1.0（2026-08-11）：初始版本 + **关联文档**： +- [文档索引](./README.md) +- [需求规格说明](./需求规格说明.md)（本文需求对应 `FR-KB-01`~`FR-KB-13`、`FR-ADM-*`） - [美搭 · 智能穿搭美学助手 产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md) +- [技术架构文档](./技术架构文档.md)（kb 域数据模型见 §6.2，混合检索实现见 §8.3） +- [技术选型与调研报告](./技术选型与调研报告.md) +- [合规与安全方案](./合规与安全方案.md) - [美学报告需求文档](./美学报告-需求文档.md) - [穿搭 Agent 需求文档](./穿搭Agent-需求文档.md) - [用户系统与记忆系统需求文档](./用户系统与记忆系统-需求文档.md) diff --git a/docs/需求规格说明.md b/docs/需求规格说明.md new file mode 100644 index 0000000..918accd --- /dev/null +++ b/docs/需求规格说明.md @@ -0,0 +1,427 @@ +# 「美搭」需求规格说明 + +> 版本：v1.0　｜　更新日期：2026-08-13　｜　状态：待评审 +> +> **本文的定位**：把散落在五份需求文档中的需求统一编号、统一优先级、统一验收标准，成为开发任务拆解与测试用例编写的唯一索引。 +> +> **本文与其他文档的关系**： +> - 各模块的**设计细节与推理过程**仍在各自的需求文档中（报告分级逻辑、记忆分层模型、知识分类体系等），本文不重复。 +> - 本文提供**可勾选、可验收、可指派**的需求条目。开发任务、测试用例、验收清单都引用本文编号。 +> - 技术实现方式见《技术架构文档》，技术选型理由见《技术选型与调研报告》。 + +--- + +## 1. 编号与优先级规范 + +### 1.1 编号规则 + +``` +FR-<模块>-<序号> 功能需求（Functional Requirement） +NFR-<类别>-<序号> 非功能需求 +CR-<序号> 合规需求（Compliance Requirement，不可裁剪） +``` + +模块代码： + +| 代码 | 模块 | 主文档 | +| --- | --- | --- | +| ACC | 账号与用户系统 | 用户系统与记忆系统-需求文档 | +| MEM | 记忆系统 | 用户系统与记忆系统-需求文档 | +| RPT | 美学报告 | 美学报告-需求文档 | +| AGT | 穿搭 Agent | 穿搭Agent-需求文档 | +| TRY | 智能试穿（换装） | 产品方案 §2.1 | +| HAIR | 发型设计 | 产品方案 §2.1 | +| KB | 美学知识库 | 美学知识库-建设方案 | +| TASK | 任务中心 | 产品方案 §2.7 | +| BILL | 权益与计费 | 产品方案 §3、§5 | +| ADM | 运营后台 | 技术选型报告 TD-25 | +| WDB | 我的衣橱 | 产品方案 §2.6 | +| SYS | 系统级/横切 | 技术架构文档 | + +### 1.2 优先级定义 + +| 级别 | 含义 | 判定标准 | +| --- | --- | --- | +| **P0** | V1 必须有 | 缺它则核心闭环不成立，或无法合法上线 | +| **P1** | V1 期望有 / V2 必须有 | 缺它体验受损但闭环仍在 | +| **P2** | 增强 | 锦上添花，可随时后置 | + +### 1.3 验收标准的书写要求 + +每条 P0 需求必须有**可判定**的验收标准。不合格的写法与合格的写法对比： + +| ❌ 不可验收 | ✅ 可验收 | +| --- | --- | +| 报告生成速度快 | 初级报告 p95 生成耗时 < 90s，超时转后台并推送 | +| 建议要专业 | 生成结果中硬性禁忌规则违反数 = 0（黄金集 100 例全通过） | +| 记忆要准确 | 显式偏好写入后，下一轮对话注入率 100%，且用户可在「我的记忆」看到该条 | + +### 1.4 完成定义（DoD） + +任一需求标记为完成，必须同时满足： + +1. 功能实现且通过验收标准； +2. 单元/集成测试覆盖主路径与关键异常路径； +3. 涉及生成内容的，已接入统一合规出口（`CR-05`）； +4. 涉及配额消耗的，已接入预扣-确认-退还三段式（`FR-BILL-05`），且消耗前有剩余量提示； +5. 关键埋点已上报（`FR-SYS-06`）； +6. 失败态有用户可读的错误文案与下一步指引。 + +--- + +## 2. 功能需求 + +### 2.1 ACC 账号与用户系统 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-ACC-01 | 华为账号登录（UnionID/OpenID） | P0 | V1 | 登录成功率 ≥ 99%；首次登录自动创建用户；UnionID 与内部 user_id 映射唯一 | TD-15 | +| FR-ACC-02 | 游客模式：未登录可体验非付费功能 | P0 | V1 | 游客可完成拍照与初级报告体验流程中被允许的部分；关键动作前引导登录 | — | +| FR-ACC-03 | 游客数据迁移：登录后合并游客期间产生的数据 | P0 | V1 | 合并后游客期的报告、收藏、记忆归属新账号；重复合并幂等；多设备场景以先登录设备为准并提示 | FR-ACC-02 | +| FR-ACC-04 | 手机号验证码登录 | P0 | V1 | 作为华为账号登录之外的兜底通道；验证码 5 分钟有效、单号限频；与华为账号可互相绑定 | TD-15 | +| FR-ACC-13 | 华为账号一键登录获取手机号 | P1 | **V2** | 需企业开发者资质 + `quickLoginMobilePhone` scope。V1 不做（`TD-29`），仅为体验优化非能力缺口 | TD-15、TD-29 | +| FR-ACC-05 | 会话管理：access/refresh 双令牌，可撤销 | P0 | V1 | 登出后旧令牌立即失效；refresh 令牌服务端可单条撤销 | — | +| FR-ACC-06 | 个人资料维护（昵称、头像、性别、年龄段） | P0 | V1 | 修改即时生效；头像走私有桶签名访问 | — | +| FR-ACC-07 | 用户中心：报告入口、我的记忆、我的收藏、**剩余额度**、设置 | P0 | V1 | 各入口可达且状态正确（无报告时显示引导）；额度展示为「今日剩余 N 次」，**不出现价格与购买入口** | FR-BILL-07 | +| FR-ACC-08 | 授权同意记录：协议、隐私政策、人脸单独同意 | P0 | V1 | 人脸授权为**独立单独同意**页，非混入总协议；同意记录含版本号与时间，可查询 | CR-01 | +| FR-ACC-09 | 账号注销：数据删除 | P0 | V1 | 提交后 7 日内彻底删除个人数据；期间可撤销；删除完成有记录可审计 | CR-03 | +| FR-ACC-10 | 个人信息导出 | P1 | V2 | 用户可申请导出自身数据，机器可读格式 | CR-03 | +| FR-ACC-11 | 未成年人保护：年龄判定与功能限制 | P0 | V1 | 识别为未成年时禁用外观评价类内容并提供监护提示（V1 无付费功能，故无付费限制项） | CR-04 | +| FR-ACC-12 | 多形象档案（帮家人诊断） | P2 | V2+ | 数据模型 V1 预留 `profile_id`，不实现 UI | — | + +### 2.2 MEM 记忆系统 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-MEM-01 | 分层记忆模型 L0~L2 落地（身份/画像/显式偏好） | P0 | V1 | 三层均可写入、可查询、可注入；数据结构含置信度与来源 | — | +| FR-MEM-02 | 报告结论自动写入 L1 画像记忆 | P0 | V1 | 报告完成后 L1 记忆同步生成，置信度继承诊断置信度 | FR-RPT-06 | +| FR-MEM-03 | 显式偏好抽取与写入 L2 | P0 | V1 | 用户明确表达偏好（「我不穿裙子」）后写入成功率 ≥ 90%，并给用户回执确认 | FR-AGT-08 | +| FR-MEM-04 | 记忆注入 Agent 上下文 | P0 | V1 | 注入 token ≤ 500；有画像用户的回答需体现画像（人工抽检 ≥ 80% 体现） | FR-AGT-03 | +| FR-MEM-05 | 「我的记忆」页面：可见、可编辑、可删除 | P0 | V1 | 用户可看到每条记忆的内容、来源、时间；删除后不再注入；编辑后优先级最高 | CR-02 | +| FR-MEM-06 | 置信度与衰减机制 | P1 | V1 | 定时任务按规则降低未强化记忆的置信度；低于阈值不再注入 | — | +| FR-MEM-07 | 冲突消解：显式 > 报告 > 隐式，新 > 旧 | P0 | V1 | 同 key 冲突时按规则裁决并写变更事件；用户编辑不被自动覆盖 | FR-MEM-05 | +| FR-MEM-08 | 隐式行为推断 + 待确认机制 | P1 | V2 | 同属性连续 3 次拒绝生成待确认候选；确认后才生效；不打断当前任务 | — | +| FR-MEM-09 | L3 事件记忆与语义召回 | P1 | V2 | 可按语义召回历史事件（「上次面试穿的那套」） | — | +| FR-MEM-10 | L4 会话滚动摘要 | P1 | V2 | 长会话摘要压缩后 token ≤ 400，关键约束不丢失 | — | +| FR-MEM-11 | L5 衣橱记忆 | P1 | V2 | 与衣橱模块联动 | FR-WDB-01 | +| FR-MEM-12 | 记忆变更审计 | P0 | V1 | 每次写入/衰减/冲突/用户编辑均留事件记录 | — | + +### 2.3 RPT 美学报告 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-RPT-01 | 初级报告（免费）内容生成 | P0 | V1 | 覆盖需求文档 §2.2 全部模块；结构完整率 100%；无空模块 | — | +| FR-RPT-02 | 触发时机：首次进入核心功能前引导生成 | P0 | V1 | 未有报告的用户进入换装/Agent 时出现引导，可跳过但有降级说明 | FR-RPT-11 | +| FR-RPT-03 | 拍照/上传引导与质量校验 | P0 | V1 | 不合格照片（多人/遮挡/过暗/侧脸过大）在分析前拦截并给出具体重拍指引，拦截准确率 ≥ 85% | — | +| FR-RPT-04 | 问卷采集（生活场景、风格倾向、禁忌） | P0 | V1 | 问卷完成率 ≥ 80%；可跳过项不阻断生成 | — | +| FR-RPT-05 | 视觉分析：体型 / 色彩季型 / 脸型 | P0 | V1 | 与人工标注一致率：体型 ≥ 80%、季型 ≥ 75%、脸型 ≥ 80%（各 30~50 样本） | TD-05、TD-06 | +| FR-RPT-06 | 结构化诊断结论（**32 维度字典**） | P0 | V1 | 每维度输出 value + confidence + evidence + rule_hits；缺失维度显式标注 | FR-KB-04、TD-31 | +| FR-RPT-07 | 报告文案生成（规则约束 + LLM 表达） | P0 | V1 | 硬禁忌违反数 = 0；结论与诊断值一致（无自相矛盾）；黄金集 30 例人工评审通过 | FR-KB-05 | +| FR-RPT-08 | 生成后校验 | P0 | V1 | 校验项：禁忌违反、色值在色板内、维度引用存在、无绝对化医疗/身材贬损表述；不通过则重试或降级模板 | — | +| FR-RPT-09 | 生成进度与等待体验 | P0 | V1 | 阶段文案随进度更新；超阈值转后台生成 + 完成推送；用户离开页面不丢任务 | FR-TASK-01 | +| FR-RPT-10 | 报告页展示与交互 | P0 | V1 | 分模块展开；术语配白话释义；低置信度维度降级表述 | — | +| FR-RPT-11 | 无照片/拒绝授权的降级路径 | P0 | V1 | 可用问卷生成简版画像，明确告知能力差异，不阻断产品使用 | — | +| FR-RPT-12 | 报告分享（长图） | P0 | V1 | 服务端渲染，跨设备一致；含 AI 生成显式标识；分享链接可失效 | TD-12、CR-05 | +| FR-RPT-13 | 重新生成 / 更新报告 | P1 | V1 | 有频控与配额（每 30 天 1 次，任务可 +1）；历史版本保留可对比 | FR-BILL-04 | +| FR-RPT-14 | 报告与其他模块联动 | P0 | V1 | 报告结论驱动 Agent 建议、换装推荐、发型推荐 | FR-MEM-02 | +| FR-RPT-15 | 全面报告内容 | P1 | V2 | 覆盖需求文档 §2.3 全部模块；付费前有清晰的内容对比说明。**V1 仅做预约留资，且预览卡片不展示任何价格**（`TD-28`） | FR-BILL-09 | +| FR-RPT-16 | 全面报告付费触发点 | P1 | V2 | 触发点不影响免费体验完整性；无诱导性欺骗文案 | — | +| FR-RPT-17 | 报告 PDF 导出 | P2 | V2 | 含 AI 标识元数据 | — | +| ~~FR-RPT-18~~ | ~~五行/命理模块~~ | — | **不做** | **已决定 V1 与 V2 均不纳入**（`TD-31`）。诊断维度由 34 项减为 32 项；编号不再复用 | — | + +### 2.4 AGT 穿搭 Agent + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-AGT-01 | 文字对话与流式输出 | P0 | V1 | 首字 p95 < 2s；整轮 p95 < 8s；断线可恢复 | — | +| FR-AGT-02 | 意图识别（场景咨询/单品搭配/风格建议/越界） | P0 | V1 | 主要意图识别准确率 ≥ 85%；越界意图（医疗、身材贬损、他人评价）正确拒答 | — | +| FR-AGT-03 | 画像注入 + token 预算控制 | P0 | V1 | 输入 token ≤ 3700；预算超限时按优先级裁剪而非报错 | FR-MEM-04 | +| FR-AGT-04 | 知识库混合检索 | P0 | V1 | 检索 p95 < 200ms；黄金集 Top-5 命中率 ≥ 80% | FR-KB-06 | +| FR-AGT-05 | 生成后校验（禁忌违反 = 0、色值在板内） | P0 | V1 | 黄金集 100 例违反数 = 0 | FR-KB-05 | +| FR-AGT-06 | 搭配方案结构化输出（卡片） | P0 | V1 | 输出可解析为结构化单品组合，字段完整 | — | +| FR-AGT-07 | 快捷问题入口 | P0 | V1 | 首屏提供场景化快捷问题，点击直达 | — | +| FR-AGT-08 | 显式偏好抽取与回执 | P0 | V1 | 抽取成功后给用户可见回执（「已记住」），可撤销 | FR-MEM-03 | +| FR-AGT-09 | 对话历史保存与会话列表 | P0 | V1 | 会话可回看；保留期符合数据保留策略 | CR-03 | +| FR-AGT-10 | 无画像用户的降级路径 | P0 | V1 | 无画像时给通用建议 + 报告引导，不空转 | FR-RPT-11 | +| FR-AGT-11 | 知识缺口埋点 | P0 | V1 | 无检索结果的 query 全量记录，可导出驱动内容生产 | FR-KB-10 | +| FR-AGT-12 | 输入输出双向内容审核 | P0 | V1 | 输入拦截、输出拦截均生效；审核不可用时 fail-close | CR-06 | +| FR-AGT-13 | 「为什么推荐」解释链 | P1 | V2 | 解释的事实部分来自知识库路径与规则 ID，非模型自由生成 | FR-KB-07 | +| FR-AGT-14 | 联动换装试穿 | P1 | V2 | 从建议卡片一键发起换装任务 | FR-TRY-01 | +| FR-AGT-15 | 联动发型设计 | P1 | V2 | 同上 | FR-HAIR-01 | +| FR-AGT-16 | 图片输入理解（穿搭评价） | P1 | V2 | 支持上传穿搭照获得点评，评价不含贬损表述 | TD-04 | +| FR-AGT-17 | 语音输入 | P1 | V2 | 端侧识别；识别失败可切文字 | TD-14 | +| FR-AGT-18 | 主动推荐（天气/日程驱动） | P2 | V3 | — | — | + +### 2.5 TRY 智能试穿 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-TRY-01 | 换装任务提交与出图（三种工作流） | P0 | V1 | 任务成功率 ≥ 90%（排除输入不合格）；p95 < 40s（不含排队） | TD-00 改造 | +| FR-TRY-02 | 输入前置校验（人像质量、单品白底图规格） | P0 | V1 | 不合格输入在提交前拦截并说明原因，**不消耗配额**（拦截发生在预扣之前） | FR-KB-08 | +| FR-TRY-03 | 结果图审核与合规标识 | P0 | V1 | 100% 经审核 + 显式水印 + 隐式元数据 | CR-05、CR-06 | +| FR-TRY-04 | 排队与容量保护 | P0 | V1 | 展示排队位次与预估时间；超阈值拒绝新任务并提示 | FR-TASK-02 | +| FR-TRY-05 | 失败退还配额 | P0 | V1 | 不可重试失败立即退还；对账日报中无「扣额未出图」记录 | FR-BILL-05 | +| FR-TRY-06 | 结果收藏与管理 | P0 | V1 | 可收藏、删除；删除后存储对象同步清理 | — | +| FR-TRY-07 | 结果对比（原图/换装后） | P1 | V1 | 前后对比视图 | — | +| FR-TRY-08 | 基于画像的单品推荐入口 | P0 | V1 | 推荐单品需 `tryon_ready`，避免推荐了却试不了 | FR-KB-08 | +| FR-TRY-09 | 多单品组合试穿 | P2 | V2 | — | — | + +### 2.6 HAIR 发型设计 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-HAIR-01 | 发型更换与发色调整 | P0 | V1 | 成功率 ≥ 90%；p95 < 40s | — | +| FR-HAIR-02 | 发型库适配标签打标（脸型/量感/直曲/长度/卷度/刘海/正式度） | P0 | V1 | 60 款发型 100% 完成打标并通过抽检复核 | FR-KB-03 | +| FR-HAIR-03 | 基于脸型与画像的发型推荐 | P0 | V1 | 推荐结果不含该脸型禁忌发型（规则校验通过率 100%） | FR-RPT-06 | +| FR-HAIR-04 | 结果审核与合规标识 | P0 | V1 | 同 FR-TRY-03 | CR-05 | + +### 2.7 KB 美学知识库 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-KB-01 | 本体 Schema 与属性字典定稿 | P0 | V1 | 12 类实体的字段、枚举值、必填项全部明确并落库 | — | +| FR-KB-02 | 自建色板（12 季型 Lab 色值） | P0 | V1 | 每季型含主色/点缀色/禁忌色，色值可用于计算；命名自研规避商标 | TD-18 | +| FR-KB-03 | 实体内容录入（单品、发型、场合、材质等） | P0 | V1 | 达到冷启动规模目标（见知识库文档 §9）；每条含 source 与 license | — | +| FR-KB-04 | 规则库（建议/禁忌，含硬约束标记） | P0 | V1 | 覆盖体型×场合、季型×色彩、脸型×发型三大矩阵；每条含依据说明与审核人 | FR-ADM-02 | +| FR-KB-05 | 规则引擎求值与硬约束校验 | P0 | V1 | 求值 p95 < 50ms；硬约束校验可拦截违规输出 | — | +| FR-KB-06 | 混合检索链路（硬过滤+规则+向量+关键词+重排） | P0 | V1 | 黄金集 Top-5 命中率 ≥ 80%；硬过滤零漏（禁忌项不得出现在候选中） | TD-08 | +| FR-KB-07 | 图谱关系与解释路径输出 | P1 | V1 | 1~3 跳查询可返回路径，供解释链使用 | TD-09 | +| FR-KB-08 | 单品白底图流水线（抠图+规格校验+入库） | P0 | V1 | 10 件样本走通全流程；`tryon_ready` 标志准确；抠图人工质检通过率 ≥ 90% | TD-07 | +| FR-KB-09 | 内容审核与发布流程（草稿→审核→发布→归档） | P0 | V1 | 未审核内容不进入线上检索；发布可回滚 | FR-ADM-03 | +| FR-KB-10 | 知识缺口发现与优先级排序 | P0 | V1 | 缺口按命中频次排序，可导出为内容生产任务 | FR-AGT-11 | +| FR-KB-11 | 黄金测试集与回归 | P0 | V1 | ≥ 100 条测试用例；CI 中自动跑；指标退化阻断合并 | — | +| FR-KB-12 | 视觉模型辅助属性标注 | P1 | V1 | 单品属性自动预标注 + 人工复核；预标注准确率 ≥ 70%（降低人工量即达标） | TD-04 | +| FR-KB-13 | 趋势内容更新机制 | P2 | V2 | — | — | + +### 2.8 TASK 任务中心 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-TASK-01 | 统一任务提交与状态查询 | P0 | V1 | 所有长耗时任务（报告/换装/发型）统一入口；状态机完整 | — | +| FR-TASK-02 | 进度与预估时间 | P0 | V1 | 阶段文案 + 排队位次 + 预估剩余时间（基于历史 p50） | — | +| FR-TASK-03 | 任务列表页（进行中/已完成/失败） | P0 | V1 | 失败项有原因与重试入口 | — | +| FR-TASK-04 | 完成推送通知 | P0 | V1 | 推送到达率 ≥ 90%；文案不含敏感结论 | TD-17 | +| FR-TASK-05 | 幂等与重试 | P0 | V1 | 相同幂等键不重复扣点、不重复出图；可重试错误自动重试并有上限 | — | +| FR-TASK-06 | 任务取消 | P1 | V1 | 排队中可取消并退点；执行中标记取消，不再返回结果 | — | +| FR-TASK-07 | 死信与告警 | P0 | V1 | 连续失败进死信队列并告警，不静默丢弃 | — | + +### 2.9 BILL 配额与计量 + +> ⚠️ **V1 不收费**（`TD-28`）。本模块在 V1 的职责是「**配额限制 + 计量**」，不含任何支付、订单、购买能力。 +> +> **架构约束（不可妥协）**：V1 的配额账本与 V2 的点数账本**必须是同一张表** —— V1 只使用 `system_grant`（系统发放）与 `consume`（消耗）两种流水类型，V2 增加 `purchase`（购买）与 `gift`（赠送）。这样 V2 上支付时不需要数据迁移，也不需要重写扣减逻辑。 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-BILL-01 | 配额定义与周期重置 | P0 | V1 | 按周期（日/月/终身）正确重置；跨时区按 UTC+8 统一；额度耗尽有明确提示与获取途径 | — | +| FR-BILL-02 | 配额账本与流水 | P0 | V1 | 余额可由流水完整重算校验；每日自动对账无差异；流水类型可扩展至购买/赠送而无需改表结构 | — | +| FR-BILL-03 | 任务奖励额度发放 | P0 | V1 | 签到、完善资料、反馈、邀请、分享完成即到账；**发放幂等**（同一任务同一周期不重复发放） | — | +| FR-BILL-04 | 配额消耗表（配置化） | P0 | V1 | 各功能消耗量可配置，不硬编码；改配置不需发版 | TD-28 | +| FR-BILL-05 | 预扣-确认-退还三段式 | P0 | V1 | 长耗时任务失败自动退还；**无「扣了额度但没出图」case**；退还幂等 | FR-TASK-05 | +| FR-BILL-06 | 服务端硬校验与防绕过 | P0 | V1 | 额度校验在服务端，客户端提示仅为体验；伪造请求无法超额；设备/账号/IP 三重限流 | NFR-SEC-04 | +| FR-BILL-07 | 额度耗尽文案约束 | P0 | V1 | **提示中不出现任何价格、购买、会员、升级字样**；只提供「等待恢复」与「做任务换额度」两条路径 | — | +| FR-BILL-08 | 成本归因记录 | P0 | V1 | 每次 AI 调用落 `ob_ai_call`，可按功能/模型/用户聚合；**这是 V2 定价的唯一数据来源，不可裁剪** | NFR-COST-01 | +| ~~FR-BILL-09~~ | ~~华为 IAP 商品购买~~ | P1 | **V2** | 服务端收据校验；`purchase_token` 唯一防重复发货；掉单可补发 | TD-16 | +| ~~FR-BILL-10~~ | ~~会员等级与权益~~ | P1 | **V2** | 权益判定集中在 billing 域，其他模块只查询 | — | +| ~~FR-BILL-11~~ | ~~订单与退款对账~~ | P1 | **V2** | 日对账报表；异常订单告警 | — | + +> **编号变更说明**：原 `FR-BILL-02`（点数钱包）语义改为「配额账本」；原 `FR-BILL-06`~`FR-BILL-08`（IAP / 会员 / 对账）顺延为 `FR-BILL-09`~`FR-BILL-11` 且全部推至 V2；原 `FR-BILL-09`（成本归因）改为 `FR-BILL-08`。新增 `FR-BILL-06`（服务端硬校验）与 `FR-BILL-07`（文案约束）两条 V1 需求。 + +### 2.10 ADM 运营后台（极简版） + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-ADM-01 | 独立登录与权限（运营/顾问/管理员） | P0 | V1 | 与用户端账号体系隔离；操作留审计日志 | — | +| FR-ADM-02 | 知识条目与规则的增删改查 | P0 | V1 | 顾问可独立完成内容维护，无需工程介入 | FR-KB-04 | +| FR-ADM-03 | 素材上传与抠图任务触发 | P0 | V1 | 批量上传、查看抠图结果、标记 `tryon_ready` | FR-KB-08 | +| FR-ADM-04 | 内容发布与回滚 | P0 | V1 | 发布后线上检索生效；可回滚到上一版本 | FR-KB-09 | +| FR-ADM-05 | 知识缺口看板 | P1 | V1 | 按频次展示缺口，支持导出 | FR-KB-10 | +| FR-ADM-06 | 用户与配额查询（客服支持） | P1 | V1 | 可按用户查任务状态与配额流水，用于客诉处理（V1 无订单概念） | — | +| FR-ADM-07 | 版本管理与效果看板 | P2 | V2 | — | — | + +### 2.11 WDB 我的衣橱 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-WDB-01 | 衣物录入（拍照 + 自动属性识别） | P1 | V2 | 属性自动识别准确率 ≥ 70%，可人工修正 | TD-04 | +| FR-WDB-02 | 衣橱管理与分类 | P1 | V2 | — | — | +| FR-WDB-03 | 基于真实衣橱的搭配建议 | P1 | V2 | 建议只使用用户实际拥有的单品 | FR-MEM-11 | + +### 2.12 SYS 系统级需求 + +| 编号 | 需求 | P | 版本 | 验收标准 | 依赖 | +| --- | --- | --- | --- | --- | --- | +| FR-SYS-01 | 统一鉴权与越权防护 | P0 | V1 | 所有资源访问校验归属；越权测试用例全通过 | — | +| FR-SYS-02 | 统一错误码与用户可读文案 | P0 | V1 | 每个错误码有 message + hint；无裸露堆栈 | — | +| FR-SYS-03 | 图片直传（预签名 URL） | P0 | V1 | 图片不经应用服务器；上传失败可重试 | — | +| FR-SYS-04 | LLM 网关（路由/降级/成本/Prompt 版本） | P0 | V1 | 主供应商故障自动切备用，切换耗时 < 3s；成本 100% 记录 | TD-04 | +| FR-SYS-05 | 三张监控看板 | P0 | V1 | 业务漏斗、AI 成本、任务健康均可用 | TD-24 | +| FR-SYS-06 | 全链路埋点 | P0 | V1 | 漏斗关键节点无缺失（上线前用测试账号走查验证） | TD-23 | +| FR-SYS-07 | 成本预警 | P0 | V1 | 日成本环比突增超阈值告警；场景级日预算生效 | NFR-COST-02 | +| FR-SYS-08 | 外部依赖降级策略 | P0 | V1 | 各依赖失效时表现符合架构文档 §2 表格；审核为 fail-close | — | +| FR-SYS-09 | 数据备份与恢复演练 | P0 | V1 | 至少完成一次真实恢复演练并记录 RTO/RPO | — | + +--- + +## 3. 合规需求（不可裁剪） + +> 这些需求不接受「先上线后补」。缺失将直接导致无法上架或面临处罚。详见《合规与安全方案》。 + +| 编号 | 需求 | 依据 | 验收标准 | +| --- | --- | --- | --- | +| CR-01 | 人脸信息单独同意 + 处理目的告知 | 人脸识别技术应用安全管理办法 | 独立同意页；拒绝后仍可使用降级功能；同意记录含版本与时间 | +| CR-02 | 人脸原图不持久化，仅保留派生特征 | 同上 + 最小必要原则 | 处理完成后原图删除；临时桶生命周期 ≤ 2 小时；抽查无残留 | +| CR-03 | 数据保留与删除：注销后 7 日内彻底删除 | 个人信息保护法 | 删除任务可审计；对象存储同步清理 | +| CR-04 | 未成年人保护 | 未成年人网络保护条例 | 未成年账号禁用外观评价与付费；有监护提示 | +| CR-05 | AI 生成内容双重标识（显式 + 隐式元数据） | 人工智能生成合成内容标识办法 + GB 45438-2025 | 所有生成物含可见标识；元数据含属性信息、服务提供者编码、27 位内容编号；**经 CDN/压缩/客户端保存后元数据仍存在** | +| CR-06 | 内容审核：输入与输出双向 | 生成式人工智能服务管理暂行办法 | 用户上传图、生成图、用户文本、模型输出、知识内容全覆盖；审核不可用时 fail-close | +| CR-07 | 关键词拦截库 | 备案要求 | 拦截库可维护；命中记录留存 | +| CR-08 | 大模型登记 + 算法备案 | 生成式 AI 管理暂行办法 + 算法推荐管理规定 | 取得登记号/备案号；界面显著位置公示模型名称与编号 | +| CR-09 | 隐私政策与用户协议 | 多项法规 | 明确 AI 生成、数据处理、第三方共享清单；版本化留存 | +| CR-10 | 个人信息保护影响评估（PIA） | 个人信息保护法 | 完成 PIA 报告并归档 | +| CR-11 | 日志留存 | 深度合成管理规定 | 生成记录与审核日志留存 ≥ 6 个月 | +| CR-12 | 不得提供医疗、命理等越界结论 | 广告法 + 内容合规 | 报告与对话中无诊疗承诺、无绝对化效果承诺；越界问题正确拒答 | + +--- + +## 4. 非功能需求 + +### 4.1 性能（NFR-PERF） + +| 编号 | 指标 | 目标 | +| --- | --- | --- | +| NFR-PERF-01 | 普通 API p95 | < 300ms | +| NFR-PERF-02 | Agent 首字 p95 / 整轮 p95 | < 2s / < 8s | +| NFR-PERF-03 | 初级报告 p50 / p95 | < 45s / < 90s | +| NFR-PERF-04 | 全面报告 p95 | < 180s | +| NFR-PERF-05 | 换装出图 p95（不含排队） | < 40s | +| NFR-PERF-06 | 知识检索 p95 | < 200ms | +| NFR-PERF-07 | 长图渲染 p95 | < 8s | +| NFR-PERF-08 | 客户端首屏 | < 1.5s | + +### 4.2 可靠性（NFR-REL） + +| 编号 | 指标 | 目标 | +| --- | --- | --- | +| NFR-REL-01 | 月度可用性 | ≥ 99.5% | +| NFR-REL-02 | 任务最终成功率（含重试） | ≥ 95% | +| NFR-REL-03 | 数据零丢失 | 已提交任务不因重启丢失 | +| NFR-REL-04 | RPO / RTO | RPO ≤ 5min，RTO ≤ 1h（需演练验证） | + +### 4.3 成本（NFR-COST） + +| 编号 | 要求 | +| --- | --- | +| NFR-COST-01 | 所有付费调用 100% 可归因到功能与用户 | +| NFR-COST-02 | 场景级日预算 + 日成本预警生效 | +| NFR-COST-03 | LLM 缓存命中率可观测，固定前缀设计到位 | +| NFR-COST-04 | GPU 实例按需启停，空闲不计费 | + +### 4.4 安全（NFR-SEC） + +| 编号 | 要求 | +| --- | --- | +| NFR-SEC-01 | 敏感数据传输与存储加密；密钥不落代码 | +| NFR-SEC-02 | 结果图私有桶 + 短期签名 URL + 防盗链 | +| NFR-SEC-03 | 日志脱敏（手机号、UnionID、诊断结论、图片地址） | +| NFR-SEC-04 | Prompt 注入防护：用户内容不得影响系统指令与工具决策 | +| NFR-SEC-05 | 防刷：设备指纹 + 频控 + 异常注册风控 | + +### 4.5 可维护性（NFR-MAINT） + +| 编号 | 要求 | +| --- | --- | +| NFR-MAINT-01 | 契约先行：接口 schema 先定义，客户端类型由 OpenAPI 生成 | +| NFR-MAINT-02 | ruff + mypy strict 进 CI，失败阻断合并 | +| NFR-MAINT-03 | 域间依赖规则由工具校验，禁止跨域直查表 | +| NFR-MAINT-04 | 黄金集回归进 CI，指标退化阻断合并 | +| NFR-MAINT-05 | 规则/色板/定价/模型路由全部配置化，不硬编码 | +| NFR-MAINT-06 | 数据库变更必须走 Alembic 且向后兼容 | + +### 4.6 体验（NFR-UX） + +| 编号 | 要求 | +| --- | --- | +| NFR-UX-01 | 所有长耗时操作有进度反馈与可离开能力 | +| NFR-UX-02 | 所有失败态有原因说明 + 下一步指引 | +| NFR-UX-03 | 专业术语必须配白话释义 | +| NFR-UX-04 | 外观相关表述遵循「描述而非评判」，不使用贬损性词汇 | +| NFR-UX-05 | 低置信度结论使用不确定表述，不做断言 | + +--- + +## 5. V1 范围矩阵（一页看清） + +### 5.1 V1 包含（P0 全量） + +| 模块 | V1 交付内容 | +| --- | --- | +| 账号 | 华为账号授权登录 + 手机号验证码、游客与迁移、资料、同意授权、注销、未成年保护 | +| 记忆 | L0~L2 + 报告写入 + 注入 + 我的记忆页 + 冲突消解 + 审计 | +| 报告 | **初级报告完整闭环**（引导→拍照→问卷→分析→诊断→文案→校验→长图→分享） | +| Agent | 文字对话、意图识别、画像注入、混合检索、生成后校验、偏好抽取、缺口埋点 | +| 换装 | 三工作流出图、前置校验、审核标识、排队保护、失败退还配额、收藏 | +| 发型 | 发型更换与发色、60 款打标、基于脸型推荐 | +| 知识库 | 本体定稿、自建色板、冷启动内容、规则库、混合检索、白底图流水线、黄金集 | +| 任务中心 | 统一提交与状态、进度、列表、推送、幂等、死信告警 | +| 配额与计量 | 配额定义与重置、配额账本与流水、任务奖励发放、消耗表配置化、预扣三段式、服务端硬校验、**成本归因埋点**。⚠️ **不含支付、订单、购买** | +| 后台 | 极简版：知识与规则维护、素材上传、发布回滚、缺口看板 | +| 系统 | 鉴权、错误码、直传、LLM 网关、三看板、埋点、成本预警、降级、备份演练 | +| 合规 | CR-01 ~ CR-12 全部 | + +### 5.2 V1 明确不做 + +| 内容 | 原因 | 归属 | +| --- | --- | --- | +| **全部支付能力**（IAP、会员、点数购买、订单、退款、对账） | **V1 完全不收费**，用配额限制控成本。定价需要 V1 采集的真实数据才有依据（`TD-28`） | V2 | +| 全面报告 | 需先用 V1 预约率验证意愿；**V1 预览卡片不展示价格** | V2 | +| 广告变现 | V1 不接任何广告，避免影响首发体验与评价 | V2+ | +| 华为账号一键登录 | 需企业资质 + scope；属体验优化非能力缺口（`TD-29`） | V2 | +| 我的衣橱 | 依赖属性识别与记忆 L5，工作量大 | V2 | +| 语音输入、图片输入理解 | 非核心闭环 | V2 | +| 联动试穿/联动发型（从 Agent 一键跳转） | 各自功能先独立稳定 | V2 | +| 解释链自然语言化 | 数据结构 V1 已具备，展示层后置 | V2 | +| 多形象档案 | 仅预留数据字段 | V2+ | +| **五行/命理** | **永久不做**：收益边缘但渠道审核风险全局（`TD-31`） | **不做** | +| 多端（iOS/Android） | 见 `TD-01` | V2+ | + +### 5.3 V1 的前置阻塞项（不属于开发，但决定能否上线） + +| 事项 | 状态 | 说明 | +| --- | --- | --- | +| 大模型登记 + 算法备案 | ✅ **已完成** | 原周期 2~4 个月的关键路径已解除。转为持续义务：编号界面公示、备案范围一致性、变更备案（`CR-08`） | +| 备案覆盖的模型清单核实 | ⏳ **唯一开放项** | 若备案未覆盖 DeepSeek + GLM 两家，双路由属超范围，需办变更或 V1 先单路由（`TD-19`） | +| ~~华为企业开发者资质~~ | ✅ 已解除依赖 | V1 不接 IAP，一键登录降级 V2（`TD-29`） | +| **全职形象顾问到岗** | 🔴 **新的关键路径** | 规则库产能直接决定 M2 排期（`TD-27`） | +| **单品素材自采产能** | 🔴 **新的关键路径** | 300 件 `tryon_ready` 需按周产能倒排；备案解除后这是最长工序（`TD-26`） | + +--- + +## 6. 需求变更控制 + +| 情形 | 处理 | +| --- | --- | +| 新增 P0 需求 | 必须同时说明它挤掉哪个现有 P0，或延后哪个里程碑 | +| 合规需求（CR-xx） | 不可裁剪、不可降级，只能新增 | +| 验收标准调整 | 需在本文更新并记录原因，不允许口头放宽 | +| 优先级变更 | 在本文标注变更日期与原因 | + +--- + +## 7. 相关文档 + +- [文档索引](./README.md) +- [技术架构文档](./技术架构文档.md)（§20 给出章节与本文需求的映射） +- [技术选型与调研报告](./技术选型与调研报告.md)（`TD-xx` 编号来源） +- [合规与安全方案](./合规与安全方案.md)（`CR-xx` 的义务来源与落地要求） +- [开发任务拆解](./开发任务拆解.md)（每条 P0 与 CR 需求都应能反查到至少一个任务） +- 需求原文：[美学报告](./美学报告-需求文档.md)、[穿搭 Agent](./穿搭Agent-需求文档.md)、[用户系统与记忆系统](./用户系统与记忆系统-需求文档.md)、[美学知识库](./美学知识库-建设方案.md)、[产品方案](./鸿蒙美搭-智能穿搭美学助手-产品方案.md) + +--- + +## 变更记录 + +| 日期 | 版本 | 变更 | +| --- | --- | --- | +| 2026-08-13 | v1.1 | 按业务决策收口调整需求范围。**§2.9 BILL 由「权益与计费」改为「配额与计量」**：移除 V1 全部支付能力，新增 `FR-BILL-06`（服务端硬校验防绕过）与 `FR-BILL-07`（额度耗尽文案不得出现价格字样）；IAP/会员/对账顺延至 `FR-BILL-09`~`11` 并推至 V2。`FR-ACC-04` 改为手机号验证码登录（P0），一键登录移为 `FR-ACC-13`（V2）。`FR-RPT-18` 五行模块标记为永久不做。§5.2 新增「全部支付能力」「广告变现」两项 V1 不做。**§5.3 前置阻塞项状态更新**：备案已完成、企业资质依赖已解除，新的关键路径为全职顾问到岗与素材自采产能 | +| 2026-08-13 | v1.0 | 首次建立统一需求编号体系，收拢五份需求文档 | diff --git a/docs/鸿蒙美搭-智能穿搭美学助手-产品方案.md b/docs/鸿蒙美搭-智能穿搭美学助手-产品方案.md index a39486b..7a30abc 100644 --- a/docs/鸿蒙美搭-智能穿搭美学助手-产品方案.md +++ b/docs/鸿蒙美搭-智能穿搭美学助手-产品方案.md @@ -6,20 +6,26 @@ **「美搭」- 智能穿搭美学助手** ### 1.2 产品定位 -面向爱美用户的智能穿搭指导应用，集成换装、换发型、美学报告等核心能力，为用户提供个性化、专业化的形象管理方案。第一版基于 Uni-App-x 跨平台框架开发，首发鸿蒙（HarmonyOS）应用市场。 +面向爱美用户的智能穿搭指导应用，集成换装、换发型、美学报告等核心能力，为用户提供个性化、专业化的形象管理方案。第一版采用鸿蒙原生开发，首发鸿蒙（HarmonyOS）应用市场。 ### 1.3 产品愿景 成为用户最值得信赖的智能美学助手，让每个人都能轻松拥有专业级的形象管理能力。 ### 1.4 技术选型 -- **开发框架**：Uni-App-x（一次开发，多端发布） -- **首发平台**：鸿蒙 HarmonyOS NEXT -- **后续规划**：iOS、Android、小程序等多端扩展 -- **选型理由**： - - 跨平台能力降低多端开发成本 - - 原生渲染性能接近原生应用 - - 鸿蒙生态快速增长，先发优势明显 - - 支持 Vue 语法，开发效率高 + +> 完整选型结论与理由见《[技术选型与调研报告](./技术选型与调研报告.md)》，技术方案见《[技术架构文档](./技术架构文档.md)》。此处仅列结论。 + +| 层面 | 选型 | 决策编号 | +|------|------|---------| +| 客户端 | **鸿蒙原生 ArkTS + ArkUI**（V1 单端） | `TD-01` | +| 服务端 | Python 3.12 + FastAPI（模块化单体 + 独立 AI 能力服务） | `TD-02` | +| 基础设施 | 腾讯云（CVM / PostgreSQL+pgvector / Redis / COS / CDN / CLS） | `TD-03` | +| 大模型 | DeepSeek（主）+ 智谱 GLM（备与视觉），自建 LLM 网关 | `TD-04` | +| 视觉能力 | 腾讯云人脸识别 + 自建人体关键点（RTMPose）+ 自建抠图（BiRefNet） | `TD-05`~`TD-07` | +| 首发平台 | 鸿蒙 HarmonyOS NEXT | — | +| 后续规划 | iOS / Android 多端在 V2 重新评估跨端方案 | `TD-01` | + +**为什么 V1 改为鸿蒙原生（原方案为 Uni-App-x）**：V1 只发鸿蒙一个端，跨端框架的收益此刻为零而成本已经付出；且本产品重度依赖系统能力（相机与大图压缩、长耗时任务后台通知、华为账号、支付、Canvas 长图、流式渲染），原生支持更完整。Uni-App-x 虽自 HBuilderX 4.61+ 支持纯血鸿蒙，但官方明确提示鸿蒙端「处于发展初期，能用有坑，应降低验收期望」，与本项目「效果优先」的定位冲突。多端需求在 V2 明确后再统一评估。 ### 1.5 目标用户 @@ -36,15 +42,32 @@ ### 1.6 文档地图 -本方案为总纲，四个核心子系统各有独立需求文档，评审与开发时以子文档为准： +本方案为总纲。完整文档索引与阅读路径见《[文档索引 README](./README.md)》。文档分四层，**冲突时以下层为准**： + +**第二层｜做什么** | 文档 | 内容 | 对应本文档章节 | |------|------|--------------| +| 📎 [需求规格说明](./需求规格说明.md) | **统一需求编号（FR/NFR/CR）、优先级、验收标准** —— 开发与测试的索引 | 全篇 | | 📎 [美学报告需求文档](./美学报告-需求文档.md) | 报告触发时机、初级/全面分级、诊断维度字典、生成流程、付费策略 | 2.2 | | 📎 [穿搭 Agent 需求文档](./穿搭Agent-需求文档.md) | 对话能力、意图识别、场景理解、能力联动 | 2.3 | | 📎 [用户系统与记忆系统需求文档](./用户系统与记忆系统-需求文档.md) | 账号体系、会员与配额、L0~L5 分层记忆模型 | 2.4 | | 📎 [美学知识库建设方案](./美学知识库-建设方案.md) | 12 类知识分类体系、7 种模态、构建流程、检索链路 | 2.5 | +**第三层｜怎么做** + +| 文档 | 内容 | +|------|------| +| 📎 [技术架构文档](./技术架构文档.md) | 分层架构、模块划分、数据模型、关键链路、API 规范、部署与成本模型 | +| 📎 [技术选型与调研报告](./技术选型与调研报告.md) | 31 项技术决策的结论、理由、备选与切换条件 | +| 📎 [合规与安全方案](./合规与安全方案.md) | 人脸信息、AI 生成内容标识、备案登记、内容审核、数据安全 | + +**第四层｜谁来做、什么时候做** + +| 文档 | 内容 | +|------|------| +| 📎 [开发任务拆解](./开发任务拆解.md) | WBS、依赖关系图、六个里程碑、任务验收条件 | + **四者的关系**：知识库提供专业能力 → 美学报告生产用户画像 → 记忆系统承载并持续演进画像 → Agent 与试穿功能消费画像。缺少任何一环，个性化能力都会退化为通用建议。 ``` @@ -209,14 +232,14 @@ | | 初级报告「形象速测」 | 全面报告「形象深度诊断」 | |---|---------------------|------------------------| | 上线版本 | **V1** | **V2**（V1 仅做占位入口） | -| 价格 | 免费 | 付费（单次 ¥29.9，会员 ¥19.9） | +| 价格 | 免费 | 付费（**定价待 V2 按真实数据确定**，见 §5.0） | | 输入 | 1 张全身照 + 4 项问卷 | 全身正/侧 + 面部特写 + 12~15 项问卷 | | 诊断维度 | 8 项核心 | 40+ 项完整 | | 色彩精度 | 四季粗判 + 8 色色板 | 十二季细分 + 24+ 色完整色板 | | 发型内容 | 3 条要点 | 独立发型专项报告（8 小节） | | 场景方案 | 1 个 | 4+ 个（含配色公式） | | 篇幅 / 时长 | 1~2 屏 / ≤60s | 15~25 屏 / ≤5min（异步） | -| 免费额度 | 每 30 天可重新生成 1 次 | 按次购买 / 会员权益 | +| 额度 | 每 30 天可重新生成 1 次（任务可 +1） | 按次购买 / 会员权益（V2） | > **内容深度对标**：全面报告对齐线下形象顾问交付标准（见 `reference/个人形象报告.pdf`），涵盖风格核心诊断、色彩诊断、身材穿搭指南、配饰规划、发型专项、场景方案包六大篇章，并新增线下报告普遍缺失的「30 天形象提升计划」。 @@ -239,7 +262,11 @@ #### 2.2.3 第一版的付费意愿验证 -V1 不做支付链路，但在初级报告结果页保留「全面报告」预览卡片（模糊目录 + 内容清单 + 预计价格），点击进入「即将上线，抢先预约」并留资埋点。**决策门槛：预约率 ≥ 8% 则 V2 立即开发付费报告；< 3% 则重新评估定价与内容形态。** +V1 不做支付链路，在初级报告结果页保留「全面报告」预览卡片（模糊目录 + 内容清单），点击进入「即将上线，抢先预约」并留资埋点。**决策门槛：预约率 ≥ 8% 则 V2 立即开发付费报告；< 3% 则重新评估内容形态。** + +> ⚠️ **卡片不得展示价格**（`FR-BILL-07`）。原设计中的「预计价格」与「点击价格档位」已移除 —— V1 全产品线不出现任何价格字样，否则会污染 V2 的定价空间，也会让用户形成"处处收费"的第一印象。**价格敏感度改用线下用户访谈采集**（`T-P0-26`），这比在 App 里挂一个假价格更准，也没有副作用。 +> +> **同时要承认这个指标的局限**：预约不等于付费，留资到实付的衰减通常很大。因此 V2 定价前应补一次小范围真实收费灰度（`T-P6-03b`），不要仅凭预约率就全量定价。 ### 2.3 AI 穿搭 Agent（详见独立文档） @@ -266,7 +293,7 @@ V1 不做支付链路，但在初级报告结果页保留「全面报告」预 📎 **[用户系统与记忆系统需求文档](./用户系统与记忆系统-需求文档.md)** #### 2.4.1 用户系统要点 -- **登录方式**：华为账号一键登录（鸿蒙首发主路径）+ 手机号验证码 + **游客模式** +- **登录方式**：华为账号授权登录（鸿蒙首发主路径）+ 手机号验证码 + **游客模式**。「一键登录获取手机号」需企业开发者资质，降级为 V2（`TD-29`） - **游客模式**：未登录即可完成 1 次换装、1 次试戴、1 次初级报告、3 次对话，注册后数据无感迁移，显著降低首启流失 - **授权管理**：人脸信息属敏感个人信息，必须**单独授权、可单独撤回**，并留存授权记录 - **账号生命周期**：支持数据导出、清空照片、撤回人脸授权、注销（7 日冷静期后彻底删除） @@ -375,26 +402,31 @@ V1 不做支付链路，但在初级报告结果页保留「全面报告」预 - 发型设计（发型更换 / 发色更换）+ **60 款发型适配标签** - **初级美学报告**（免费）+ 形象档案与版本对比 - AI 穿搭 Agent（基础对话 + 画像注入） -- 用户系统（华为账号 / 手机号 / 游客模式 + 数据迁移） +- 用户系统（华为账号授权登录 / 手机号验证码 / 游客模式 + 数据迁移） - 记忆系统 L0~L4 + 「我的记忆」管理页 -- 美学知识库 V1（规则 400 条 / 单品 300 条 / 方案 100 套 / 12 套色板 / 发型打标） +- 美学知识库 V1（规则 400 条 / **自采单品 300 件** / 方案 100 套 / 12 套色板 / 发型打标） - 任务中心 + 完成推送 + 端侧照片预检 - 历史记录、收藏、分享长图 -- 配额与成本计量（为 V2 定价提供真实数据） +- **配额限制与成本计量**（V1 唯一的成本控制手段，且为 V2 定价提供真实数据） +- **备案编号公示页**（合规必需，上架核验项） +- 运营后台极简版（顾问维护知识与规则、素材上传、发布回滚） #### 🅿️ 第一版做入口、不做实现（意愿验证） -- 全面美学报告（预约留资 + 埋点，验证付费意愿） +- 全面美学报告（预约留资 + 埋点，**不展示价格**） - 我的衣橱（入口收集意愿） -- 会员订阅（灰度开关预留，不开放支付） +- 会员权益（静态展示 + 「上线提醒我」留资，**不出现价格、不开放支付**） #### ❌ 第一版不包含（后续版本规划） -- 支付与订单链路、会员点数体系 +- **全部支付能力**：IAP、订单、会员订阅、点数购买、退款与对账（`TD-28`） +- **广告变现**（不接开屏、信息流、激励视频，避免影响首发体验与评价） +- 华为账号一键登录（需企业资质，`TD-29`） - 购物引导、商城与电商导购分成 - 化妆指导（接口待定） - 社区与 UGC - B 端 API 输出 - 多端协同（平板/手表/车机） - 系统级集成（服务卡片/语音唤醒等） +- **五行 / 命理模块（永久不做，`TD-31`）** --- @@ -402,37 +434,59 @@ V1 不做支付链路，但在初级报告结果页保留「全面报告」预 ### 3.1 原方案的成本风险与改造 -原方案设定"会员 ¥9.9/月 = 无限换装"，在成本上不成立：换装是长耗时 GPU 推理（几十秒到几分钟），单次成本在角到元量级，重度用户单月可消耗数十元，**会员越活跃越亏损**。改造为「基础免费额度 + 权益点数制」，把不可控的无限供给变成可控的点数消耗。 +原方案设定"会员 ¥9.9/月 = 无限换装"，在成本上不成立：换装是长耗时 GPU 推理（几十秒到几分钟），单次成本在角到元量级，重度用户单月可消耗数十元，**会员越活跃越亏损**。 -### 3.2 权益对照表 +**V1 的解法比点数制更彻底：干脆不收费，只限量**（`TD-28`）。不收费就没有"付费用户应该无限用"的压力，配额可以是纯粹的硬限制，月度成本上限因此变成可以事前算准的确定值（§5.3.1）。点数制留给 V2 —— 届时有了 V1 的真实成本数据，点数消耗比才有依据。 -| 权益项 | 免费版 | 会员版 ¥9.9/月 | 高级版 ¥29.9/月 | -|--------|--------|---------------|----------------| -| 每日免费换装 | 3 次 | 10 次 | 20 次 | -| 每日免费试戴发型 | 3 次 | 10 次 | 20 次 | +### 3.2 V1 配额设计（唯一在 V1 生效的一张表） + +V1 无付费、无会员、无点数购买，**所有用户使用同一套配额**。额度用尽后只有两条路：等自然恢复，或做任务换额度。 + +| 能力 | 基础额度 | 可通过任务额外获得 | 硬上限（防刷） | +|------|---------|------------------|--------------| +| 初级美学报告（首次） | 1 次（终身） | — | — | +| 报告重新生成 | 每 30 天 1 次 | +1 次/月 | 每日 ≤ 2 | +| 换装试穿 | **每日 3 次** | +3 次/日 | 每日 ≤ 8 | +| 发型 / 发色试戴 | **每日 3 次** | +2 次/日 | 每日 ≤ 6 | +| AI 对话 | **每日 10 轮** | +10 轮/日 | 每日 ≤ 40 | +| 记忆条数 | 200 条 | — | — | +| 高清导出 | 每日 1 次 | — | 每日 ≤ 3 | + +**任务奖励额度的获取方式**（全部不涉及金钱）：每日签到、完善画像资料、给报告结论打反馈、邀请好友、分享报告长图。 + +**三条不可违反的设计纪律**： + +1. **额度是服务端硬限制，不是前端提示** —— 服务端校验后直接拒绝，不存在绕过路径。这是成本封顶能成立的前提（见 §5.3.1）。 +2. **文案中不出现任何价格或购买字样** —— 额度用尽的提示是「今日额度已用完，明天再来，或做个任务多换 3 次」，不是「升级会员解锁」。V1 出现价格暗示会污染 V2 的定价空间，也会让用户觉得这是个"处处收费"的产品。 +3. **每次消耗前置提示剩余量**（"本次将使用 1 次换装额度，今日还剩 2 次"），**禁止静默扣减**。 + +### 3.3 V2 权益规划（V1 不实现，仅作架构预留） + +> 下表是 V2 的规划草案，**定价与点数消耗比均需按 V1 采集的真实数据重算**（`TD-16`、`T-P6-16`），现在的数字只是占位。V1 的数据模型需为这张表预留字段，但不实现任何付费逻辑。 + +| 权益项 | 免费版 | 会员版（价格待定） | 高级版（价格待定） | +|--------|--------|-----------------|-----------------| +| 每日换装 / 发型 | 3 次 | 10 次 | 20 次 | | 每日 AI 对话 | 10 轮 | 100 轮 | 不限（防刷上限） | -| 月度权益点数 | 0 | 300 点 | 1000 点 | +| 月度权益点数 | 0 | 待定 | 待定 | | 初级美学报告 | 每 30 天 1 次 | 每 7 天 1 次 | 不限（每日 ≤3） | -| 全面美学报告（V2） | 单次 ¥29.9 | 单次 ¥19.9 | 含 1 次/季 | -| 我的衣橱容量（V2） | 20 件 | 200 件 | 不限 | -| 记忆条数上限 | 50 条 | 500 条 | 不限 | +| 全面美学报告 | 单次付费 | 折扣价 | 含 1 次/季 | +| 我的衣橱容量 | 20 件 | 200 件 | 不限 | +| 记忆条数上限 | 200 条 | 500 条 | 不限 | | 高清导出 / 去水印 | ❌ | ✅ | ✅ | -| 广告 | 开屏 + 信息流 | 无 | 无 | -| 优先体验新功能 / 专属客服 | ❌ | 部分 | ✅ | -- **点数消耗**：换装 10 点、发型 5 点、全面报告 200 点、高清重绘 20 点 -- **点数获取**：会员月赠、签到、邀请好友、观看激励广告、单独购买（¥6 = 100 点） -- **扣减顺序**：先扣免费次数 → 再扣点数 → 点数不足才引导付费 -- 每次消耗必须有前置提示（"本次消耗 10 点，剩余 290 点"），**禁止静默扣费** +- **点数消耗与获取、扣减顺序**：V2 设计时确定。架构上已按「reserve → commit / refund 预扣三段式」预留（见《技术架构文档》§7.4），保证长耗时任务不会出现"扣了额度但没交付"。 +- **V1 与 V2 的衔接**：V1 的「配额账本」与 V2 的「点数账本」是同一张表的两种用法 —— V1 只有系统发放与消耗两种流水类型，V2 增加购买与赠送类型。这样 V2 不需要数据迁移。 -### 3.3 第一版落地方式 +### 3.4 第一版的计量要求（不可裁剪） -V1 **只做免费额度与计量**，不开放支付： +V1 不收费，但**计量是 V1 最重要的隐性交付物**，它决定 V2 能不能定出合理的价格： -- 完整记录每次调用的成本、耗时、结果（`usage_log`），用真实数据校准单用户成本与点数定价 -- 会员页做静态权益展示 + 「上线提醒我」留资，验证订阅意愿 -- 全面报告做预约留资，验证单次付费意愿（门槛 ≥8%） -- V2 依据 V1 数据确定最终定价，避免拍脑袋定价导致亏损或滞销 +- 每次 AI 调用完整落库（`ob_ai_call`）：功能、用户、模型、token 数、耗时、成本、成功与否 +- 每次配额变动落流水（`bl_ledger`）：发放来源、消耗去向、余额快照，**每日自动对账** +- 会员页做**静态权益展示 + 「上线提醒我」留资**，验证订阅意愿（不出现价格） +- 全面报告做**预约留资**，验证单次付费意愿（决策门槛 ≥ 8%） +- V2 依据以上数据确定定价，避免拍脑袋定价导致亏损或滞销 --- @@ -440,25 +494,48 @@ V1 **只做免费额度与计量**，不开放支付： ### 4.1 市场规模 -> ⚠️ **数据待补来源**：以下市场数据尚未标注出处，评审前需补齐信源（报告名称、发布机构、发布时间）并标注为预测值或实际值。缺乏信源的市场数据在投资与立项评审中会被直接质疑，属于必须修补的文档缺陷。 +> 本节数据已于 2026-08-13 全部替换为**可核实的官方信源**（国家统计局、CNNIC、华为官方发布），原三处无出处引用已删除（`TD-30`）。凡属本方案推算的数字，均显式标注为「推算」并给出推算口径，不与官方数据混排。 -#### 4.1.1 中国时尚电商市场 -- **市场规模**：2025年预计达 2.8 万亿元 -- **增长率**：年复合增长率 15%+ -- **用户规模**：超过 5 亿用户 -- **移动端占比**：超过 80% +#### 4.1.1 服装与美妆消费大盘（国家统计局） -#### 4.1.2 AI 美妆市场 -- **市场规模**：2025年预计达 500 亿元 -- **增长率**：年复合增长率 25%+ -- **用户规模**：超过 2 亿用户 -- **渗透率**：仍在快速提升 +| 指标 | 2025 年实际值 | 同比 | +|------|-------------|------| +| 限额以上单位服装、鞋帽、针纺织品类零售额 | **15,215 亿元** | +3.2% | +| 限额以上单位化妆品类零售额 | **4,653 亿元** | +5.1% | +| 社会消费品零售总额 | 501,202 亿元 | +3.7% | -#### 4.1.3 鸿蒙生态 -- **用户规模**：已超 1 亿，快速增长 -- **设备数量**：超过 3 亿台设备 -- **应用数量**：超过 50 万个应用 -- **开发者生态**：超过 500 万开发者 +**信源**：《中华人民共和国 2025 年国民经济和社会发展统计公报》（国家统计局，2026-02-28）；《2025 年 12 月份社会消费品零售总额》（国家统计局，2026-01-19）。 + +**对本产品的意义**：大盘稳定增长但已进入个位数增速的存量阶段。这说明**增量不在"买得更多"，而在"买得更准"** —— 降低试错率、提高单件利用率的工具，其价值主张与当前消费心态是一致的。这比"刺激购买"的叙事更站得住。 + +#### 4.1.2 生成式 AI 的用户基础（CNNIC） + +| 指标 | 截至 2025-12 | 同比 | +|------|-------------|------| +| 生成式人工智能用户规模 | **6.02 亿人** | +141.7% | +| 生成式 AI 普及率 | **42.8%** | +25.2pp | +| 网民规模 | 11.25 亿人 | 普及率突破 80% | + +**信源**：第 57 次《中国互联网络发展状况统计报告》（中国互联网络信息中心 CNNIC，2026-02-05 发布）。 + +**对本产品的意义**：**用户教育成本已经不是问题**。普及率一年从 17.6% 涨到 42.8%，"和 AI 对话获得建议"已是大众行为而非早期尝鲜。这消除了 Agent 形态的最大不确定性 —— 我们不需要再花力气教用户"可以跟它说话"，可以直接把预算投在建议质量上。 + +#### 4.1.3 鸿蒙生态：可触达规模的真实口径（华为官方） + +⚠️ **这一节需要特别小心，因为公开传播中三个不同量级的数字经常被混用，直接影响目标设定是否成立。** + +| 口径 | 数值（截至 2026-06） | 与本产品的关系 | +|------|---------------------|--------------| +| 鸿蒙生态设备总数（含 IoT、开源鸿蒙、车机、穿戴） | 超 13 亿台 | ❌ **与本产品无关**，绝大多数无法安装手机 App | +| **HarmonyOS 6 终端设备数** | **6,600 万台** | ✅ **这才是本产品的可触达基数** | +| 注册开发者 | 超 1,100 万 | 生态供给侧活跃度 | +| 应用市场可获取应用与服务 | 超 40 万 | 竞争密度参考 | + +**信源**：《HarmonyOS 7 开发者 Beta 正式启动》《星河璀璨，百花齐放：HDC 2026》（华为官方新闻，2026-06-12 / 06-15，HDC 2026）。华为同时表述 HarmonyOS 已成为**中国第二大智能手机操作系统**。另有第三方监测（Wonder Toolbox）显示 2026-06 底 HarmonyOS 6 装机约 7,010 万台，与官方口径基本吻合。 + +**为什么只能用 6,600 万这个口径**：本产品是**纯血鸿蒙原生应用**（ArkTS / ArkUI，见 `TD-01`），只能运行在 HarmonyOS NEXT 及以上版本（即 HarmonyOS 5 / 6 / 7），**无法运行在兼容安卓的 HarmonyOS 4 及更早版本**。13 亿是整个 IoT 生态，与我们的分发无关；把它写进商业计划是常见但严重的误导。 + +**推算（非官方数据，仅为规划口径）**：HarmonyOS 5/6/7 合计装机量在本产品上线时点（预计 2027 上半年）按当前增速外推，量级约 1.5~2 亿台。后续所有渗透率与用户目标均以此为分母，见 §8.1。 ### 4.2 竞品对比 @@ -466,7 +543,7 @@ V1 **只做免费额度与计量**，不开放支付： |------|------|------|-------------| | **美图秀秀** | 用户基数大，技术成熟 | 主要是工具类，缺少专业美学 | 专业美学报告 + AI Agent | | **小红书** | 社区活跃，内容丰富 | 试穿能力弱，缺少专业性 | 实时换装 + 系统性搭配 | -| **传统试衣间App** | 功能专注 | 用户体验差，功能单一 | 跨平台 + AI 穿搭 Agent | +| **传统试衣间App** | 功能专注 | 用户体验差，功能单一 | 报告驱动的系统性建议 + AI 穿搭 Agent | | **品牌自研** | 深度绑定品牌 | 封闭生态，用户受限 | 开放平台 + 跨品牌推荐 | ### 4.3 竞争策略 @@ -481,7 +558,7 @@ V1 **只做免费额度与计量**，不开放支付： | **用户画像与记忆资产** | 数据随使用时长复利增长，用户迁移成本高 | 报告 + 记忆系统 | | **可试穿素材库**（白底单品图 + 属性标注） | 需要采集、抠图、标注的重投入，且是"建议→预览"闭环的唯一入口 | 素材运营流水线 | -短期可用优势（非壁垒，但决定上市速度）：已验证的换装/发型接口、Uni-App-x 多端能力、鸿蒙生态先发。 +短期可用优势（非壁垒，但决定上市速度）：**自有可控的换装/发型推理服务**（可改造、可扩容、成本可归因，这比调用第三方接口更有价值）、鸿蒙生态先发。 #### 4.3.2 差异化定位 - **不仅是试穿**：系统性美学指导，而非单一工具 @@ -500,21 +577,47 @@ V1 **只做免费额度与计量**，不开放支付： ## 5. 商业模式 -### 5.1 收入来源 +### 5.0 ⚠️ V1 的商业化策略：不收费，只限量 + +**V1 不接入任何支付能力**（`TD-28`、`TD-29`）。这是明确的产品决策，本章其余内容全部属于 **V2 及以后的规划**，V1 不实现。 + +| 项 | V1 | V2 | +|---|---|---| +| 支付能力（华为 IAP） | ❌ 不接入 | ✅ 接入 | +| 会员 / 订阅 | ❌ 无 | ✅ 有 | +| 点数购买 | ❌ 无 | ✅ 有 | +| 全面报告付费 | ❌ 只做预约留资 | ✅ 单次付费 | +| 广告 | ❌ 不接 | 待评估 | +| **成本控制手段** | **✅ 配额限制（免费额度 + 任务奖励额度）** | 配额 + 付费扩容 | + +**为什么这个顺序是对的**：定价需要三个前提 —— 真实的单次成本、真实的用户使用频次、真实的付费意愿。这三个数据 V1 之前一个都没有，现在定价只能是猜。V1 用配额把成本锁死在可承受范围，同时把这三个数据采齐，V2 再定价，届时定出来的价格才是有依据的。 + +**这个决策带来的直接简化**（已同步到架构与任务拆解）： +- 无需接入华为 IAP，也就**无需应对 30% 平台抽成**，`TD-16` 对 V1 不再适用 +- 无需华为企业开发者资质中与 IAP 结算相关的部分（`TD-29`） +- billing 域从「订单 + 支付 + 点数账本 + 对账」降级为「**配额账本 + 消耗流水**」，去掉了整条支付链路与对账逻辑 +- 无需交易类合规材料（虚拟商品协议、退款政策、发票） +- **但计量埋点一项都不能省** —— 这是 V2 定价的唯一数据来源，见 `NFR-COST-01` + +**V1 的配额设计原则**：额度用完时不是"付钱解锁"，而是"明天再来 / 做任务换额度"。文案不出现任何价格与购买字样，避免用户形成"这是个要花钱的产品"的第一印象，反而影响 V2 的定价空间。 + +### 5.1 收入来源（V2 起适用，V1 不实现） + +> ⚠️ **以下所有价格均为占位草案，不得作为开发或对外沟通依据**。定价必须在 V1 采集到真实成本、频次、意愿数据后重算，并扣除华为 IAP 约 30% 抽成（`TD-16`、`T-P6-16`）。 #### 5.1.1 单次付费内容（V2 起的主力） -- **全面美学报告**：单次 ¥29.9（会员 ¥19.9），重新生成 ¥9.9 -- **定价依据**：线下形象诊断客单价 300~2000 元，本产品定位"十分之一价格、八成内容"；¥29.9 处于冲动消费区间，且边际收益显著高于 ¥9.9 月费 -- **为什么以报告为主力**：内容型交付物边际成本低、价值感知清晰、不产生持续的 GPU 消耗，比"无限次生成"更健康 +- **全面美学报告**：单次购买为主力形态，另设「重新生成」低价档 +- **定价的参考锚点**（不是结论）：线下形象诊断客单价 300~2000 元，本产品可定位"十分之一价格、八成内容" +- **为什么以报告为主力**：内容型交付物边际成本低、价值感知清晰、**不产生持续的 GPU 消耗**，比"无限次生成"健康得多。这是从原方案的成本教训中得出的结论 +- **定价前必须做的一步**：小范围真实收费灰度（`T-P6-03b`）—— 预约率无法替代实付验证 #### 5.1.2 会员订阅 -- **会员版**：¥9.9/月（含 300 点），预计转化率 3~5% -- **高级版**：¥29.9/月（含 1000 点 + 季度深度报告），预计转化率 1~2% -- **年费优惠**：会员版 ¥99/年，高级版 ¥299/年 -- 权益以"额度 + 点数"计量，避免无限供给导致的成本失控（见 §3） +- 分**会员版**与**高级版**两档，权益见 §3.3 +- 价格、赠送点数、转化率预期**全部待定**，需 V1 数据支撑 +- 权益以"额度 + 点数"计量，避免无限供给导致的成本失控（见 §3.1） #### 5.1.3 点数增值 -- 点数包售卖：¥6 = 100 点 / ¥30 = 600 点 +- 点数包售卖（规格与价格待定） - 激励视频换点数（把重度免费用户的成本转移给广告主） #### 5.1.4 广告变现 @@ -541,7 +644,20 @@ V1 **只做免费额度与计量**，不开放支付： | Agent 单轮对话 | ≤ ¥0.05 | 含 RAG 检索 | | **免费用户月成本上限** | **≤ ¥8** | 按每日 3 次换装 + 3 次发型 + 10 轮对话的额度上限倒推 | -**成本控制手段**：端侧预检拦截无效请求、结构化结论走规则引擎不走 LLM、相同参数结果缓存、模板化减少输出 token、分级画质、免费用户错峰排队。 +**成本控制手段**：端侧预检拦截无效请求、结构化结论走规则引擎不走 LLM、LLM 固定前缀设计以最大化 Prompt 缓存命中（输入成本可降至 1/5~1/30）、相同参数结果缓存、模板化减少输出 token、分级画质、免费用户错峰排队、GPU 实例按需启停。 + +> **成本核算的架构前提**：所有付费调用必须落 `ob_ai_call` 表并可归因到功能与用户，否则用户量上来后无法定位成本来源。详见《技术架构文档》§13 成本模型与 `NFR-COST-01`。 + +#### 5.2.1.1 平台抽成（V1 不适用，V2 定价时必须计入） + +V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定价时这是绕不过的前提，先记录在此： + +**虚拟商品（会员、点数、全面报告）在鸿蒙上必须走华为 IAP**，且需签署《华为数字商品及联运服务协议》。Payment Kit 明确不支持虚拟商品，无法绕开。 + +- 平台抽成量级约为交易额的 **30%**（部分公开资料给出「10% 基础技术服务费 + 30% 联运分成」的更高口径）。 +- 影响：定价 ¥39 的全面报告实际到账约 ¥27 或更低。 +- **§5.1 与 §5.3 的全部收入数字均为交易额口径、未扣抽成**。V2 定价前需按到账口径重算（`TD-16`）。 +- ⚠️ **时效性**：抽成比例与协议条款需在 V2 启动时向华为重新确认，不要沿用本文数字。 #### 5.2.2 其他技术成本 - **云计算**：服务器/数据库/向量库/对象存储/CDN @@ -559,38 +675,83 @@ V1 **只做免费额度与计量**，不开放支付： - **品牌推广**：品牌广告/公关活动 - **线下活动**：快闪店/时尚活动 -### 5.3 盈利预测（第一年） +### 5.3 财务预期 -> ⚠️ **预测口径待修正**：以下预测基于原"无限次会员"模型，未计入按次生成的 GPU 成本随活跃度线性增长的特性，也未计入知识库一次性建设投入与全面报告收入。**待 V1 采集到真实单用户成本数据后重做财务模型**，重点校准三项假设：单用户月度生成次数、换装单次真实成本、报告付费转化率。 +#### 5.3.1 V1：不做收入预测，只做成本封顶 -#### 5.3.1 Q1：验证市场 -- **目标**：积累 10 万用户 -- **收入**：广告收入 ¥20 万 + 会员收入 ¥5 万 = ¥25 万 -- **成本**：技术成本 ¥30 万 + 运营成本 ¥20 万 = ¥50 万 -- **净利润**：-¥25 万 +**V1 收入恒为 ¥0**，因此不存在盈利预测。V1 阶段的财务管理目标只有一条：**把成本压在可承受区间，同时把 V2 定价所需的数据采齐**。 -#### 5.3.2 Q2：推出会员 -- **目标**：积累 50 万用户，会员转化率 5% -- **收入**：广告收入 ¥50 万 + 会员收入 ¥30 万 = ¥80 万 -- **成本**：技术成本 ¥40 万 + 运营成本 ¥30 万 = ¥70 万 -- **净利润**：+¥10 万 +| 项 | V1 目标 | 说明 | +|---|---------|------| +| 月度 AI 总成本（MAU 15 万口径） | **≤ ¥12 万/月** | 由配额上限硬性决定，不随用户行为失控 | +| 单免费用户月度 AI 成本 | ≤ ¥8 | 见 §5.2.1，配额倒推 | +| 知识库一次性建设投入 | ¥12~18 万 | 含全职顾问、素材自采、抠图标注 | +| **必须采齐的数据** | 单次真实成本 / 人均使用频次 / 预约率 | **这是 V1 唯一的"商业产出"** | -#### 5.3.3 Q3：扩大规模 -- **目标**：积累 100 万用户 -- **收入**：广告收入 ¥80 万 + 会员收入 ¥80 万 = ¥160 万 -- **成本**：技术成本 ¥50 万 + 运营成本 ¥40 万 + 营销成本 ¥30 万 = ¥120 万 -- **净利润**：+¥40 万 +**成本封顶为什么能成立**：配额是硬限制而非软提示 —— 额度用尽时服务端直接拒绝，不存在超额消耗的路径。因此月度成本上限 = MAU × 单用户配额成本上限，是可以事前算准的确定值，而不是需要事后控制的风险项。这是"不收费"换来的一个额外好处：不收费就没有"付费用户应该无限用"的压力。 -#### 5.3.4 Q4：盈亏平衡 -- **目标**：积累 200 万用户，DAU 30 万+ -- **收入**：广告收入 ¥120 万 + 会员收入 ¥150 万 = ¥270 万 -- **成本**：技术成本 ¥60 万 + 运营成本 ¥50 万 + 营销成本 ¥40 万 = ¥150 万 -- **净利润**：+¥120 万 +#### 5.3.2 V2 起的盈利预测 + +> ⚠️ **原第一年季度预测（Q1~Q4，净利润 -25 万 → +120 万）已整体废弃**，四项假设全部不再成立： +> ① 基于"无限次会员"模型，与现行配额制不符； +> ② 未计入 GPU 成本随活跃度线性增长； +> ③ 未扣除华为 IAP 约 30% 抽成； +> ④ 用户规模假设（200 万注册 / DAU 30 万）已按 §8.1.1 下调至 50 万 / MAU 15 万。 +> +> **重做财务模型的前提是 V1 的真实数据**，因此在 V1 上线并运行满一个完整周期前，不产出新的盈利预测 —— 现在做只是把猜测写得更精确。对应任务 `T-P6-16`，需校准四项假设：单用户月度生成次数、换装单次真实成本、报告付费转化率、抽成后到账比例。 --- ## 6. 实施计划 +> 详细任务拆解、依赖关系与验收条件见《[开发任务拆解](./开发任务拆解.md)》，本章只给阶段目标与范围。 + +### 6.0 Phase 0：前置验证（备案已完成，本阶段已大幅瘦身） + +本阶段几乎不产出代码，但决定项目能否成立。以下三条并行： + +**① ✅ 备案登记 —— 已完成（关键路径已解除）** + +**备案已办结**，原本 2~4 个月的外部审批周期不再构成上线瓶颈。这是本轮最重要的进展：项目从「先等审批、再谈开发节奏」变成「**开发进度就是上线进度**」，Phase 0 的关键路径从外部审批转移到内部技术验证。 + +但备案完成 ≠ 合规完成，以下四项**转为持续义务**，仍需在开发中落地（详见《合规与安全方案》§2.2、`TD-19`）： + +| 事项 | 要求 | 为什么不能省 | +|------|------|------------| +| **编号界面公示** | 在 App 显著位置（关于页 / 设置页）公示模型名称与备案编号 | 浙江、江苏、安徽、陕西等地明确要求界面显著位置公示；应用市场上架时会核验 | +| **备案范围与实际调用一致** | 实际调用的模型清单（DeepSeek + GLM 双路由）必须与备案登记的一致 | ⚠️ **最需要注意的一条**：若备案时只登记了单一模型，上线双路由即属超范围，需先办变更 | +| **实质变更后 30 个工作日内办变更** | 新增模型、变更服务功能或算法机制时触发 | 逾期属违规 | +| **上架材料留档** | 备案编号、AI 标识说明、安全自评估报告 | 应用市场核验 | + +> ⚠️ **需要你确认一件事**：备案时登记的模型清单是否已包含 DeepSeek 与智谱 GLM 两家？如果只登记了一家，双路由方案需先办变更备案，或 V1 先只用已登记的那一家（架构上 LLM 网关已做多路由抽象，切换成本很低）。这是目前唯一可能影响 V1 上线的合规不确定项。 + +**② 关键技术验证（现在是 Phase 0 的真正关键路径）** + +备案完成后，以下验证成为决定后续方案的唯一前置，不能带着不确定性进入开发： + +| 验证项 | 验收标准 | 编号 | +|-------|---------|------| +| 体型测算方案（人像分割掩膜宽度剖面 + 关键点定高） | 30~50 样本与人工标注一致率 ≥ 80% | `T-P0-10` | +| 色彩季型判定（Lab 采样 + 规则） | 与人工判定一致率 ≥ 75% | `T-P0-11` | +| 抠图流水线（BiRefNet） | 10 件样本走通全流程，质检通过 ≥ 90% | `T-P0-12` | +| 换装接口能力与**单次真实成本实测** | 得到 `gpu_seconds` 与成功率基线，填入成本模型 | `T-P0-13` | +| AI 标识元数据全链路存活 | 经水印/COS/CDN/客户端保存后元数据仍存在 | `T-P0-18` | +| 鸿蒙端骨架（ArkTS） | 打通登录、拍照、直传、任务轮询、结果展示 | `T-P0-17` | + +> ⚠️ **一个已经发生的选型变更**：腾讯云的人体检测与人体关键点接口（`DetectBody`/`DetectBodyJoints`）已于 2025-10-30 下线，原「体型关键点走第三方 API」的路径不再存在。现方案为人脸走腾讯云、**人体关键点自建（RTMPose ONNX）**。详见 `TD-05`。 + +**③ 数据与内容准备（备案解除后，这里成为新的最长工序）** + +备案不再是瓶颈，**内容与素材生产就成了实际的关键路径** —— 它是唯一无法靠 AI 辅助开发加速的部分。 + +- **全职形象顾问入场**（已定：全职编制，`TD-27`）—— 到岗即开始本体 Schema 评审与规则库撰写 +- 知识库本体 Schema 与属性字典定稿 +- **60 款发型适配标签打标**（脸型/量感/直曲/长度/卷度/刘海/正式度） +- **单品素材自采启动**（已定：自采模式，`TD-26`）—— 采购、拍摄、抠图、标注流水线搭建，详见《美学知识库-建设方案》§4.2.1 +- 目标用户访谈（验证全面报告付费意愿与心理价位，为 V2 定价储备依据） + +**Phase 0 出口条件**（已按备案完成调整）：六项技术验证有明确结论；本体 Schema 与发型打标完成；全职顾问到岗且规则库产出节奏可测算；自采流水线跑通首批 20 件单品；**备案编号公示位已在端上预留**。 + ### 6.1 Phase 1：MVP（1-2 个月） #### 6.1.1 目标 @@ -601,7 +762,9 @@ V1 **只做免费额度与计量**，不开放支付： #### 6.1.2 任务清单 - [ ] **技术准备** - - [ ] Uni-App-x 项目搭建 + - [ ] 鸿蒙 ArkTS 工程搭建（签名、权限、AGC 配置、SHA256 双证书指纹） + - [ ] 服务端骨架与 CI（FastAPI + 依赖规则检查 + 静态检查） + - [ ] **工程地基**：统一任务中心、统一合规出口、LLM 网关、**配额预扣三段式**（详见 `T-P1-19`~`T-P1-28`，这些被所有业务功能依赖，必须先于业务功能完成） - [ ] 鸿蒙环境配置与打包流程 - [ ] 集成换装接口（`/change_cloth_base64`） - [ ] 集成发型接口（`/hair/api/*`） @@ -652,7 +815,7 @@ V1 **只做免费额度与计量**，不开放支付： - [ ] 生成过程步骤可视化 + 已等待秒数 - [ ] 图片上传前压缩处理 - [ ] 结果图保存与分享（水印 + AI 生成标识） - - [ ] 配额中心 + `usage_log` 成本计量 + - [ ] 配额中心 + `ob_ai_call` 成本计量 + `bl_ledger` 配额流水 - [ ] 内容安全与敏感词过滤（含外貌负面表述红线） - [ ] **测试上线** @@ -668,12 +831,14 @@ V1 **只做免费额度与计量**，不开放支付： - 用户反馈报告、技术验证报告 - **单用户成本报告与付费意愿验证结论**（V2 定价依据） -### 6.2 Phase 2：核心功能完善（2-3 个月） +### 6.2 Phase 2 = V2：核心功能完善与商业化（2-3 个月） + +> **本阶段即 V2**。所有付费能力都在这里，**不属于 V1 范围**（`TD-28`）。 #### 6.2.1 目标 - 完善核心功能 - 提升用户体验 -- 建立会员体系 +- **首次引入商业化**（V1 收入为 0） - 扩大用户规模 #### 6.2.2 任务清单 @@ -682,13 +847,16 @@ V1 **只做免费额度与计量**，不开放支付： - [ ] 十二季细分色彩算法与专业校准 - [ ] 30 天形象提升计划 + 打卡 - [ ] PDF 导出与长图排版 - - [ ] 五行幸运色模块（含娱乐声明与可关闭开关） + - ~~[ ] 五行幸运色模块~~ —— **已决定不做**（`TD-31`），见 §7.3.4 -- [ ] **会员与支付体系** - - [ ] 支付系统集成（华为支付） - - [ ] 权益点数体系（发放/消耗/购买/对账） - - [ ] 会员权益管理与订单/退款 - - [ ] 基于 V1 成本数据的最终定价落地 +- [ ] **会员与支付体系**（V1 完全不做，本阶段从零建设） + - [ ] 华为企业开发者认证 + 数字商品联运协议签署（`TD-29`） + - [ ] 华为 IAP 接入（商品配置、**服务端收据校验**、`purchase_token` 防重、掉单补发） + - [ ] 配额账本扩展为点数账本（增加 `purchase`/`gift` 两种 `tx_type`，**无需数据迁移**） + - [ ] 会员权益管理与订单/退款/对账 + - [ ] **小范围真实收费灰度**（验证预约率到实付的衰减，`T-P6-03b`） + - [ ] **基于 V1 真实数据的定价落地**（前提：单次成本、人均频次、预约率、抽成后到账口径四项齐备，`T-P6-16`） + - [ ] 华为账号一键登录（企业资质就位后补，`FR-ACC-13`） - [ ] **记忆系统进阶** - [ ] 隐式行为推断 + 待确认机制 @@ -721,15 +889,15 @@ V1 **只做免费额度与计量**，不开放支付： #### 6.2.3 交付物 - 正式版鸿蒙应用 -- 付费全面报告 + 完整会员与点数体系 +- 付费全面报告 + 完整会员与点数体系（**本产品的首笔收入发生在这里**） - 我的衣橱 V1 -- 知识库管理后台 -- 修正后的财务模型与增长报告 +- 知识库管理后台完整版 +- **基于真实数据重做的财务模型与定价**（替代 §5.3.2 中已废弃的季度预测） ### 6.3 Phase 3：多端扩展（3-4 个月） #### 6.3.1 目标 -- 基于 Uni-App-x 扩展多端 +- 扩展多端（iOS / Android），**届时重新评估跨端方案**（保留鸿蒙原生另起跨端工程 / Uni-App-x / Flutter），判断依据是那时的鸿蒙生态成熟度与团队构成（`TD-01`、`T-P6-15`） - 拓展用户触达渠道 - 完善生态系统 @@ -814,23 +982,33 @@ V1 **只做免费额度与计量**，不开放支付： - 疑似未成年人拒绝生成；第三方数据处理方在隐私政策中列明 - 定期合规审计 -#### 7.1.4 Uni-App-x 跨平台风险 -- **风险描述**：Uni-App-x 在鸿蒙端的兼容性和性能 +#### 7.1.4 客户端技术风险（原「Uni-App-x 跨平台风险」，已随选型变更改写） + +- **风险描述**：V1 改为鸿蒙原生 ArkTS 后，跨端框架的兼容性风险消除，但引入两个新风险：① 团队 ArkTS 经验不足；② V2 多端时需要额外投入。 - **应对措施**： - - 提前验证鸿蒙端关键能力 - - 关注 DCloud 官方鸿蒙适配进展 - - 必要时使用原生插件补充能力 - - 性能瓶颈点用原生实现 + - Phase 0 的第一个技术任务就打通端到端骨架（登录、拍照、直传、任务轮询、结果展示），把主要坑一次性踩完（`T-P0-17`） + - ArkTS 是 TypeScript 超集、ArkUI 为声明式写法，与 Vue/React 心智模型接近，学习曲线可控 + - 服务端保持端无关（标准 REST + SSE + OpenAPI 生成客户端类型），多端时服务端零改动 + - 鸿蒙证书与权限体系较复杂（调试/发布双证书、指纹生效最迟 25 小时），需写入发布手册避免临上线踩坑 + +#### 7.1.4.1 云厂商能力下线风险（本轮调研中已实际发生一次） + +- **风险描述**：腾讯云的人体检测与人体关键点接口（`DetectBody`/`DetectBodyJoints`）已于 2025-10-30 下线，原「体型关键点走第三方 API」的方案失效。 +- **应对措施**： + - 核心能力（人体关键点、抠图）**自建**，不把产品核心资产押在单一云 API 的存续上（`TD-05`/`TD-07`） + - 对仍在使用的云能力（人脸属性与关键点、人像分割、内容审核）保留替换预案，并在选型文档中标注 `⚠️ 时效性`，开发启动前复核一次 + - 开源模型使用前**必须核对商用许可** —— 本轮就发现被引用最多的抠图模型 RMBG-2.0 实为 CC BY-NC 4.0 非商用许可（`TD-07`） #### 7.1.5 知识库与素材缺口（第一版最大隐性风险） - **风险描述**：两项数据缺口会直接导致核心功能"看起来做完了但不可用"—— - 现有 60 款发型只有 `id/name/image_url`，没有适配标签，"按脸型推荐发型"无法实现 - 没有白底单品图素材，换装接口无图可传，"AI 建议 → 一键试穿"闭环断裂，用户只能自己找图 - **应对措施**： - - 将发型打标（1~2 人日）与素材抠图流水线列为 Phase 1 **前置任务**，不可延后 + - 将发型打标（1~2 人日）与素材抠图流水线列为 Phase 0/1 **前置任务**，不可延后 - V1 至少产出 300 件 `tryon_ready` 单品，未达标则功能降级为"加入搭配"而非"一键试穿" - 单品标注 `tryon_slot`（换装接口只支持上衣与裤子，连衣裙/鞋/包/配饰不支持），产品端据此控制按钮展示 - - 素材版权：禁止抓取电商与社交平台图片，建立 `license` 字段与审核环节 + - **素材已定为自采模式**（`TD-26`）：优点是版权干净、规格统一、可控；代价是**这成了备案解除后的新关键路径**，需按每周产能倒排（详见《美学知识库-建设方案》§4.2.1） + - 素材版权：**只用自采实拍图**，禁止抓取电商与社交平台图片；保留采购凭证与拍摄原始文件，建立 `license` 字段与审核环节 #### 7.1.6 AI 生成质量与幻觉 - **风险描述**：大模型可能给出违反美学规则或用户禁忌的建议（如给柔夏型推荐正红色、给明确拒绝短裙的用户推荐短裙），一次错误就会摧毁"专业"信任 @@ -843,51 +1021,69 @@ V1 **只做免费额度与计量**，不开放支付： #### 7.1.7 生成成本失控 - **风险描述**：换装/报告为 GPU 长耗时推理，重度用户与刷量行为可能造成成本远超收入 - **应对措施**： - - 配额中心统一管控 + `usage_log` 逐次记账 + - 配额中心统一管控 + `ob_ai_call` 逐次记账（成本）+ `bl_ledger` 逐次记账（额度） - 端侧预检拦截无效请求（不合格照片不进队列、不计额度） - 结构化结论走规则引擎而非 LLM；相同参数结果缓存 - 设备/账号/IP 三重限流，异常账号冻结 - - 用点数制替代"无限次"权益（见 §3.1） + - **V1 因不收费而不存在"付费用户应无限用"的压力，配额即硬上限，月度成本可事前算准**（见 §5.3.1）；V2 引入付费后此风险重新升级，需在定价时用 V1 的真实成本数据校准 ### 7.2 市场风险 #### 7.2.1 用户接受度 -- **风险描述**：用户可能不接受虚拟试穿 +- **风险描述**：用户可能不接受虚拟试穿的效果，或不信任 AI 给出的形象诊断结论 - **应对措施**： - - 快速迭代 - - 用户反馈机制 - - A/B 测试 - - 用户教育 + - **AI 使用门槛已不是问题**：生成式 AI 普及率 2025 年底已达 42.8%、用户 6.02 亿（§4.1.2），无需再做基础用户教育，应把力气全部投在建议质量上 + - 真正的接受度风险在**换装效果的观感**：接口只支持上衣与裤子，效果不及预期时用户会直接判定"不准"。对策是产品端主动管理预期（明示适用范围、提供合格照片引导），而不是让用户自己发现限制 + - 以 `报告结论认同率 > 70%`（§8.1.2）作为诊断可信度的度量，低于阈值即回查规则库而非调整文案 + - 用户反馈机制 + A/B 测试 #### 7.2.2 竞争激烈 -- **风险描述**：市场竞争激烈，可能被超越 +- **风险描述**：市场竞争激烈，可能被超越。鸿蒙应用市场可获取应用与服务已超 40 万（§4.1.3），"生态先发"的窗口比预想的窄 - **应对措施**： - - 差异化定位 - - 快速创新 - - 建立壁垒 + - 差异化定位（§4.3.2），不与工具类产品比功能数量 + - 把资源集中在三项真实壁垒上（知识库、画像记忆、可试穿素材库，见 §4.3.1），而非追加功能 + - 素材自采与全职顾问都是**慢变量投入**，竞品即使决定跟进也需要同等时间，这是"先发"真正能兑现的地方 -#### 7.2.3 商业模式验证 -- **风险描述**：商业模式可能无法盈利 +#### 7.2.3 商业模式验证（V1 主动延后，风险性质已改变） +- **风险描述**：商业模式可能无法盈利。**V1 不收费，因此这个风险在 V1 阶段不会暴露，也不会被证伪** —— 这是本项目最需要警惕的一点：不收费意味着看不到真实付费意愿，只能靠预约率这一个代理指标。 - **应对措施**： - - 小步快跑 - - 数据驱动 - - 多元化收入 - - 灵活调整 + - **预约率 8% 是唯一的决策门槛**（§8.1.3）。低于此值不应硬上付费报告，而应先回查报告质量与认同率 + - 承认代理指标的局限：**预约≠付费**，行业经验中留资到实付的衰减通常很大。因此 V2 定价前应补一次**小范围真实收费灰度**（哪怕只对少量用户开放），而不是直接全量定价 + - V1 必须把三类数据采齐（单次真实成本、人均使用频次、预约率），否则 V2 定价依然是猜（§3.4） + - 大盘处于个位数增速的存量阶段（§4.1.1），"买得更准"的价值主张比"刺激购买"更成立，定价叙事应围绕**降低试错成本**而非增加消费 ### 7.3 政策风险 +> 完整的法规清单、义务解读、落地要求与上线检查清单见《[合规与安全方案](./合规与安全方案.md)》。以下为风险摘要。 + +#### 7.3.0 ✅ 备案登记风险 —— 已解除（原为最高级别风险） + +- **原风险描述**：需办理大模型登记 + 算法备案，属地网信办审批周期 2~4 个月，若等开发完成才启动会卡在上架环节数月。 +- **当前状态**：**备案已完成**，此风险关闭。项目关键路径从外部审批转移到内部的内容生产与技术验证。 +- **残留风险（需持续管理，不可视为已完结）**： + - ⚠️ **备案范围与实际调用不一致** —— 若备案登记的模型清单未覆盖 DeepSeek + GLM 双路由，上线即属超范围。**这是目前唯一可能影响 V1 上线的合规不确定项**，需在 Phase 0 内核实。缓解手段：LLM 网关已做多路由抽象，必要时 V1 先只启用已登记的模型，切换成本很低 + - **实质变更未及时办理变更备案** —— 新增模型、变更服务功能或算法机制均触发，须在 30 个工作日内办理 + - **编号未在界面显著位置公示** —— 多地明确要求，应用市场上架核验项 + - **直接使用 DeepSeek / 智谱官方 API，不走云平台 MaaS 中转** —— 部分应用商店要求提供「应用主体与算法技术主体的合作协议」，云厂商无法代第三方模型厂商出具并盖章。此约束不因备案完成而失效 + - 长周期材料需持续维护：安全自评估报告、拦截关键词库、评估测试题集 + #### 7.3.1 数据合规 -- **风险描述**：可能违反数据保护法规 +- **风险描述**：可能违反《个人信息保护法》与《人脸识别技术应用安全管理办法》（2025-06-01 施行） - **应对措施**： - - 严格遵守《个人信息保护法》，人脸信息按敏感个人信息单独授权 - - 建立数据合规体系与处理者清单 - - 定期合规审计 - - 用户知情同意 + 可撤回 + 可删除 + - 人脸信息按敏感个人信息处理，**独立的单独同意页**，不得混入总协议 + - **架构层面规避备案阈值**：人脸原图不落盘（临时桶 ≤ 2 小时 + 处理后显式删除），只保留派生的结构化特征，使「存储的人脸信息数量」恒为 0，不触发「达 10 万人须向省级以上网信部门备案」的义务 + - 禁止存储人脸特征向量与 888 点稠密关键点原始坐标（精度足以重建轮廓，属生物识别信息） + - 完成个人信息保护影响评估（PIA），建立第三方处理者清单并在隐私政策中披露 + - 用户知情同意 + 可撤回 + 可删除；注销后 7 日内彻底删除 #### 7.3.2 AI 生成内容合规 -- **风险描述**：违反《生成式人工智能服务管理暂行办法》《互联网信息服务深度合成管理规定》 +- **风险描述**：违反《人工智能生成合成内容标识办法》（**2025-09-01 施行**）+ GB 45438-2025、《生成式人工智能服务管理暂行办法》、《互联网信息服务深度合成管理规定》 - **应对措施**： - - 报告页、结果图、分享长图**标注 AI 生成标识** + - **双重标识**：显式标识（画面内可见「AI 生成」、会话界面固定提示）+ 隐式标识（文件元数据含生成属性、服务提供者编码、**27 位内容编号**） + - **统一合规出口**：所有生成物必须经过同一个模块才能对外发布（审核 + 水印 + 元数据 + 编号登记）。不要让每个业务模块各自实现，一定会漏 + - ⚠️ **最易踩的坑**：元数据在 CDN 图片处理、客户端保存相册、二次加水印等环节会被**静默剥离**。需专项自动化测试覆盖全路径（`T-P0-18`）；也正因如此，显式水印必须在画面内，不能只做界面提示 + - 生成记录与审核日志留存 ≥ 6 个月 + - V1 **不提供「去除显式标识」功能**（办法允许用户申请，但需签协议并留存日志 ≥ 6 个月，额外增加义务） - 保留免责声明："AI 计算可能存在误差，结论仅供参考" - 换装能力**限制为仅本人照片**，禁止上传他人照片（防换脸滥用），V2 增加人脸一致性校验 - 未成年人保护：疑似未成年拒绝生成 @@ -895,17 +1091,20 @@ V1 **只做免费额度与计量**，不开放支付： #### 7.3.3 内容审核 - **风险描述**：用户生成内容可能违规 - **应对措施**： - - 机器审核 + 人工审核双层机制 + - 腾讯云天御 IMS（图片）+ TMS（文本），机器审核 + 人工复核双层机制 + - **审核对象六类全覆盖**：用户上传照片、生成结果图、用户对话输入、模型输出、报告文案与长图、运营录入的知识内容 + - **fail-close 原则**：审核服务不可用时一律按「拦截」处理（与其他外部依赖的 fail-soft 策略相反）。漏审一条违规内容的代价远高于短时功能不可用 - 用户举报与违规处理机制 - **外貌评价文案红线**：禁止"腿粗""脸大"等负面表述，统一改为中性描述 + 修饰策略，敏感词表在生成后校验环节强制过滤 - 报告不得包含医疗、减肥、整形类建议 -#### 7.3.4 命理内容审核风险 -- **风险描述**：五行/幸运色模块在部分应用市场审核中属敏感内容，可能影响整体上架 -- **应对措施**： - - 明确标注"仅供娱乐，不构成任何建议" - - **服务端可配置开关**，必要时整模块下线，不影响其他功能 - - 上架前与渠道审核规则逐条核对 +#### 7.3.4 ✅ 命理内容审核风险 —— 已通过「不做」规避 + +- **原风险描述**：五行/幸运色模块在部分应用市场审核中属敏感内容，可能影响整体上架。 +- **决策**：**该模块 V1 与 V2 均不纳入**（`TD-31`）。风险从"需要用娱乐声明 + 服务端开关来缓解"变成"根本不存在"。 +- **为什么直接砍掉比保留更好**：这个模块的收益是边缘的（它不影响诊断准确性，也不是用户来的理由），但风险是全局的 —— 一个模块可能拖累整个应用的上架。用一个可关闭的开关来管理它，意味着仍要为它准备合规材料、敏感词策略与审核话术，长期维护成本大于它带来的价值。 +- **连带清理**：诊断维度从 34 项减为 **32 项**（删除「五行分布」「幸运色」），报告篇章结构不受影响。生日字段仍保留，用于生日权益与年龄段判断，**不再用于命理推算**。 +- **保留的边界要求**：对话中出现命理类提问时正确拒答（`CR-12`），这属于越界拒答范畴，与是否做该模块无关。 --- @@ -913,21 +1112,40 @@ V1 **只做免费额度与计量**，不开放支付： ### 8.1 用户指标 -#### 8.1.1 规模指标 -- **DAU**：30 万（第一年） -- **MAU**：100 万（第一年） -- **注册用户**：200 万（第一年） +#### 8.1.1 规模指标（已按鸿蒙可触达基数重设） + +> ⚠️ **原目标（DAU 30 万 / MAU 100 万 / 注册 200 万）已废弃**，原因有两条，都是硬伤： +> ① **分母错了** —— 纯血鸿蒙原生应用只能装在 HarmonyOS NEXT+ 设备上，可触达基数是千万到两亿量级（§4.1.3），不是 13 亿； +> ② **粘性假设错了** —— 原目标隐含 DAU/MAU = 30%，那是社交与短视频的量级。形象诊断是**低频决策型工具**：用户做完报告可能两三周不打开，但换季、面试、约会时会回来。用日活考核这类产品会逼着团队做无意义的签到打卡，反而破坏产品。 + +第一年目标改为三档，并**以月活与回访为主考核指标，不考核日活**： + +| 指标 | 保守 | 目标 | 挑战 | 说明 | +|------|:----:|:----:|:----:|------| +| 注册用户 | 20 万 | **50 万** | 100 万 | 对应可触达设备渗透率约 0.1% / 0.3% / 0.5% | +| MAU | 6 万 | **15 万** | 30 万 | MAU/注册 ≈ 30%，符合工具类首年水平 | +| 季度回访率（90 天内至少回访 1 次） | 25% | **35%** | 45% | **替代 DAU 作为核心粘性指标** | +| DAU（仅监测，不作考核） | — | 2 万 | — | 参考值，DAU/MAU 预期落在 12~15% | + +**为什么把"季度回访率"放在核心位置**：本产品的价值主张是"形象档案随时间复利增长"。能验证这一点的不是用户今天有没有打开，而是**换季/重要场合时会不会想起我们**。这个指标同时反映了报告的长期价值与记忆系统是否真的让二次体验更好。 #### 8.1.2 质量指标 -- **留存率**：次日 >40%，7 日 >20%，30 日 >10% -- **活跃度**：日均使用时长 >10 分钟 -- **满意度**：用户满意度 >4.5/5 +- **留存率**：次日 >35%，7 日 >18%，30 日 >10%（较原目标下调，对齐低频工具的合理区间） +- **报告首次阅读时长**：**>4 分钟** —— 比"日均使用时长"更能反映内容质量，是核心质量信号 +- **日均使用时长**：>5 分钟（仅监测） +- **满意度**：>4.5/5 +- **报告结论认同率**（用户主动确认"说得准"）：**>70%** —— 诊断可信度的直接度量 #### 8.1.3 转化指标 -- **会员转化率**：>3%（免费转付费，按点数制修正后的保守目标） -- **高级版转化率**：>1%（会员转高级） -- **全面报告付费转化率**：>3%（曝光转购买，V2） -- **付费率**：>5%（整体付费率） + +> **V1 无任何付费能力**（`TD-28`），因此 V1 只考核意愿类指标；下表付费指标自 V2 起考核。 + +| 指标 | 目标 | 何时考核 | +|------|------|---------| +| **全面报告预约率** | **> 8%** | **V1（唯一的商业化验证指标，决定 V2 是否开发付费报告）** | +| 会员转化率 | > 3% | V2 | +| 全面报告付费转化率（曝光→购买） | > 3% | V2 | +| 整体付费率 | > 5% | V2 | #### 8.1.4 报告与个性化指标（第一版核心） @@ -953,15 +1171,25 @@ V1 **只做免费额度与计量**，不开放支付： ### 8.2 业务指标 #### 8.2.1 收入指标 -- **ARPU**：¥15/月（第一年） -- **会员收入**：¥150 万/年（第一年） -- **广告收入**：¥120 万/年（第一年） + +> **V1 收入 = 0，这是主动选择，不是缺陷**（`TD-28`）。V1 不接入支付、不设购买入口，通过配额限制控制成本。因此 V1 阶段**唯一的商业指标是"预约率 > 8%"**，其余收入指标自 V2 起适用，且需按届时的真实成本数据重算（`T-P6-16`）。 + +| 指标 | 目标 | 何时考核 | +|------|------|---------| +| **V1 总收入** | **¥0（预期值，非失败）** | V1 | +| ARPU | 待 V2 定价后设定 | V2 | +| 会员收入 / 广告收入 | 待重做财务模型 | V2 | #### 8.2.2 运营指标 -- **API 调用量**：100 万次/月（第一年） -- **试穿次数**：50 万次/月（第一年） -- **发型设计次数**：30 万次/月（第一年） -- **美学报告生成量**：20 万份/月（第一年） + +原「第一年」口径已随 §8.1.1 规模指标下调，按 MAU 15 万的目标档重新推算： + +| 指标 | 推算值（MAU 15 万口径） | 用途 | +|------|----------------------|------| +| 美学报告生成量 | 3~5 万份/月 | 画像覆盖与报告成本主项 | +| 试穿次数 | 8~12 万次/月 | **GPU 成本的最大驱动因子**，需与配额策略联动监控 | +| 发型设计次数 | 4~6 万次/月 | — | +| Agent 对话轮次 | 30~50 万轮/月 | LLM 成本主项 | #### 8.2.3 成本指标（新增，与收入指标同等重要） - **单用户月度 AI 成本**：免费用户 ≤ ¥8，会员 ≤ ¥20 @@ -997,20 +1225,35 @@ V1 **只做免费额度与计量**，不开放支付： ## 9. 下一步行动 +> 完整任务清单（含依赖、验收标准、任务编号）见《[开发任务拆解](./开发任务拆解.md)》。本章为摘要。 + +### 9.0 ✅ 备案已完成，最高优先级已转移 + +原本的第一优先级（备案登记，外部周期 2~4 个月）**已完成**，关键路径解除。新的最高优先级是**内容与素材生产** —— 备案解除后，它成为唯一无法靠 AI 辅助开发压缩的工序。 + +本周必须启动的三件事（按优先级）： +- [ ] **核实备案登记的模型清单是否覆盖 DeepSeek + 智谱 GLM 两家**（`T-P0-01`）。若只覆盖一家，需办变更备案或 V1 先单路由。**这是目前唯一可能影响上线的合规不确定项** +- [ ] **全职形象顾问招聘与入场**（`T-P0-20`）—— 规则库产能直接决定 M2 能否按期 +- [ ] **单品自采流水线启动**（`T-P0-21`）—— 目标 300 件 `tryon_ready`，按每周产能倒排 + ### 9.1 立即启动（本周） #### 9.1.1 技术验证 -- [ ] 换装接口能力测试（三种工作流） -- [ ] 发型接口能力测试（发型列表/更换/发色） -- [ ] 接口性能与稳定性评估 + **单次真实成本测算** -- [ ] 视觉分析能力选型验证（体型关键点 / 面部关键点 / 肤色采样） -- [ ] Uni-App-x 鸿蒙端环境搭建 +- [ ] 换装接口能力测试（三种工作流）+ **单次真实成本测算**（`T-P0-13`） +- [ ] 发型接口能力测试（发型列表/更换/发色）（`T-P0-14`） +- [ ] 接口性能与稳定性评估 +- [ ] **体型测算方案验证**：人像分割掩膜宽度剖面 + 关键点定高，与人工标注一致率 ≥ 80%（`T-P0-10`） +- [ ] **色彩季型判定验证**：Lab 采样 + 规则，一致率 ≥ 75%（`T-P0-11`） +- [ ] **抠图流水线验证**：BiRefNet，10 件样本走通全流程（`T-P0-12`） +- [ ] AI 标识元数据全链路存活验证（水印 → COS → CDN → 客户端保存）（`T-P0-18`） +- [ ] 鸿蒙 ArkTS 端骨架验证（登录、拍照、直传、任务轮询、结果展示）（`T-P0-17`） -#### 9.1.2 数据前置任务（不做则功能不可用，优先级同技术验证） +#### 9.1.2 数据前置任务（**备案解除后已升为实际关键路径**） - [ ] **60 款发型适配标签打标**（脸型/量感/直曲/长度/卷度/刘海/正式度） +- [ ] **单品自采流水线搭建**：采购 → 拍摄（白底规范）→ BiRefNet 抠图 → 属性标注 → 质检（`T-P0-21`） - [ ] 单品白底图抠图流水线验证（10 件样本走通全流程） - [ ] 知识库本体 Schema 与属性字典定稿 -- [ ] 形象顾问资源接洽（规则撰写与黄金集标注） +- [ ] **全职形象顾问入场**，开始规则撰写与黄金集标注（`T-P0-20`） #### 9.1.3 产品原型 - [ ] 鸿蒙应用原型开发 @@ -1027,10 +1270,11 @@ V1 **只做免费额度与计量**，不开放支付： ### 9.2 2 周内完成 #### 9.2.1 技术方案 -- [ ] Uni-App-x 项目架构设计 -- [ ] 鸿蒙打包流程确认 -- [ ] 接口封装方案 -- [ ] 技术评审 +- [x] 技术架构设计（见《[技术架构文档](./技术架构文档.md)》） +- [x] 技术选型定稿（见《[技术选型与调研报告](./技术选型与调研报告.md)》） +- [ ] 技术评审（架构文档过审） +- [ ] 鸿蒙工程与打包流程确认（签名、权限、AGC 配置、SHA256 双证书指纹） +- [ ] 接口契约定稿（OpenAPI 先行，客户端类型由其生成） #### 9.2.2 设计方案 - [ ] UI/UX 设计 @@ -1113,22 +1357,36 @@ V1 **只做免费额度与计量**，不开放支付： ### 10.2 技术栈概要 -- **前端框架**：Uni-App-x（Vue 3 语法） -- **首发平台**：鸿蒙 HarmonyOS NEXT -- **后续平台**：iOS / Android / 小程序 / H5 -- **图片处理**：前端 Base64 编码 + 压缩 -- **网络请求**：uni.request（注意超时配置） +| 层面 | 选型 | +|------|------| +| 客户端 | 鸿蒙原生 ArkTS + ArkUI；系统能力用 Account Kit / IAP Kit / Push Kit / Core Speech Kit(V2) | +| 服务端 | Python 3.12 + FastAPI + SQLAlchemy 2.0 + Pydantic v2；模块化单体 + 独立 AI 能力服务 | +| 异步任务 | Celery + Redis，按 gpu / cpu / io / beat 四队列分离 | +| 数据 | PostgreSQL 16 + pgvector（业务、知识库、向量、事件同库）；Redis；COS 四桶 + CDN | +| 大模型 | DeepSeek（主）+ 智谱 GLM（备与视觉），自建 LLM 网关（路由/降级/Prompt 版本/成本计量） | +| 视觉 | 腾讯云人脸识别（属性/90 点/888 点）+ 人像分割；自建 RTMPose 人体关键点；自建 BiRefNet 抠图 | +| Embedding | 自建 BGE-M3 | +| 审核 | 腾讯云天御 IMS（图片）+ TMS（文本），输入输出双向、fail-close | +| 渲染 | Playwright 服务端渲染报告长图与 PDF | +| 可观测 | OpenTelemetry + Prometheus + Grafana + CLS；三张看板（业务漏斗 / AI 成本 / 任务健康） | +| 部署 | Docker Compose（V1，含按需启停的 GPU 实例）→ TKE（V2） | -> 详细技术架构方案将在技术设计阶段单独输出。 +> 完整技术方案见《[技术架构文档](./技术架构文档.md)》；每项选型的理由、备选与切换条件见《[技术选型与调研报告](./技术选型与调研报告.md)》。 ### 10.3 关联文档清单 | 文档 | 说明 | |------|------| -| [美学报告需求文档](./美学报告-需求文档.md) | 触发时机、初级/全面分级、34 项诊断维度字典、生成流程、付费策略 | +| [文档索引 README](./README.md) | 文档地图、按角色的阅读路径、编号体系、术语表 | +| [需求规格说明](./需求规格说明.md) | 统一需求编号（FR/NFR/CR）、优先级、验收标准、V1 范围矩阵 | +| [美学报告需求文档](./美学报告-需求文档.md) | 触发时机、初级/全面分级、**32 项**诊断维度字典、生成流程、付费策略 | | [穿搭 Agent 需求文档](./穿搭Agent-需求文档.md) | 对话能力、意图识别、场景理解、能力联动 | | [用户系统与记忆系统需求文档](./用户系统与记忆系统-需求文档.md) | 账号与会员、配额计量、L0~L5 记忆模型、置信度与冲突消解 | | [美学知识库建设方案](./美学知识库-建设方案.md) | 12 类知识分类、7 种模态、建设流程、混合检索链路 | +| [技术架构文档](./技术架构文档.md) | 分层架构、模块划分、数据模型、关键链路、API 规范、部署与成本 | +| [技术选型与调研报告](./技术选型与调研报告.md) | 31 项技术决策、调研依据与信源 | +| [合规与安全方案](./合规与安全方案.md) | 人脸信息、AI 生成内容标识、备案登记、内容审核、数据安全 | +| [开发任务拆解](./开发任务拆解.md) | WBS、依赖图、六个里程碑、任务验收 | | `reference/个人形象报告.pdf` | 线下形象顾问交付样例，全面报告的内容深度基准 | ### 10.4 参考资料 @@ -1139,16 +1397,25 @@ V1 **只做免费额度与计量**，不开放支付： - 《鸿蒙生态发展报告》——待确认发布机构与时间 #### 10.4.2 合规法规依据 + +> 完整清单、义务解读与落地要求见《[合规与安全方案](./合规与安全方案.md)》§1。 + - 《中华人民共和国个人信息保护法》（人脸信息按敏感个人信息处理） -- 《生成式人工智能服务管理暂行办法》（AI 生成内容标识） -- 《互联网信息服务深度合成管理规定》（换装/换脸类能力） +- 《人脸识别技术应用安全管理办法》（网信办、公安部令第 19 号，**2025-06-01 施行**；存储人脸信息达 10 万人需备案） +- 《生成式人工智能服务管理暂行办法》（需大模型登记 + 算法备案） +- 《人工智能生成合成内容标识办法》（四部门，**2025-09-01 施行**）+ GB 45438-2025（显式标识 + 隐式元数据标识） +- 《互联网信息服务深度合成管理规定》（换装/换脸类能力，含日志留存义务） +- 《互联网信息服务算法推荐管理规定》（算法备案） +- 《未成年人网络保护条例》 - 《移动互联网应用程序个人信息保护管理暂行规定》 #### 10.4.3 技术文档 -- Uni-App-x 官方文档：[https://doc.dcloud.net.cn/uni-app-x/](https://doc.dcloud.net.cn/uni-app-x/) -- 鸿蒙开发官方文档 +- 鸿蒙开发官方文档（ArkTS / ArkUI / Account Kit / IAP Kit / Push Kit / Core Speech Kit） +- 腾讯云：人脸识别、人体分析、天御内容安全、COS、PostgreSQL +- DeepSeek / 智谱 GLM 开放平台文档 - 换装 API 文档：[https://meida.xiangsilian.com/api](https://meida.xiangsilian.com/api) - 发型 API 文档：[https://meida.xiangsilian.com/hair/api-doc.html](https://meida.xiangsilian.com/hair/api-doc.html) +- Uni-App-x 官方文档（V2 多端评估时参考）：[https://doc.dcloud.net.cn/uni-app-x/](https://doc.dcloud.net.cn/uni-app-x/) #### 10.4.4 设计规范 - 鸿蒙设计规范 @@ -1159,27 +1426,66 @@ V1 **只做免费额度与计量**，不开放支付： ## 11. 待决策事项汇总 -需在评审中拍板的关键决策（按优先级）： +### 11.1 已决策（本轮收口） -| # | 决策项 | 影响 | 建议 | +| # | 决策项 | 结论 | 依据 | |---|-------|------|------| -| 1 | 第一版是否只做初级报告、不做支付 | 决定 Phase 1 范围与工期 | ✅ 建议采纳，用预约率验证付费意愿 | -| 2 | 会员权益是否改为点数制 | 决定成本可控性 | ✅ 建议采纳，避免无限供给亏损 | -| 3 | 单品素材来源（自拍摄 / 图库授权 / 品牌合作） | 决定"一键试穿"能否落地 | 建议图库授权 + 品牌合作双轨 | -| 4 | 是否引入持证形象顾问参与知识库建设 | 决定专业性与壁垒 | ✅ 建议引入 2 人，可作为营销背书 | -| 5 | 视觉分析能力自研 vs 第三方 | 决定成本与准确率 | V1 用第三方快速验证 | -| 6 | 五行模块是否纳入 V2 | 审核与合规风险 | 做但可服务端关闭 | -| 7 | 是否支持一账号多形象档案（帮家人诊断） | 影响数据模型 | V1 预留 `profile_id` 字段 | -| 8 | 报告术语体系是否需要通俗化改名 | 影响理解成本与转化 | 用户测试后决定 | +| 1 | 第一版是否只做初级报告、不做支付 | ✅ 采纳。V1 只做初级报告，用预约率验证付费意愿 | 需求规格说明 §5.2 | +| 2 | 会员权益是否改为点数制 | ✅ 采纳。基础额度 + 点数制 | §3 | +| 3 | 客户端框架 | ✅ **改为鸿蒙原生 ArkTS**（原 Uni-App-x） | `TD-01` | +| 4 | 后端技术栈 | ✅ 全 Python（FastAPI），模块化单体 + 独立 AI 服务 | `TD-02` | +| 5 | 云厂商 | ✅ 腾讯云为主 | `TD-03` | +| 6 | 大模型 | ✅ DeepSeek 主 + 智谱 GLM 备/视觉，自建网关 | `TD-04` | +| 7 | 视觉分析自研 vs 第三方 | ✅ 混合：人脸走腾讯云，**人体关键点自建**（腾讯云已下线该能力） | `TD-05` | +| 8 | 向量库 / 图谱 / 规则引擎 | ✅ pgvector / PG 邻接表 / 自研决策表，均不引入新组件 | `TD-08`~`TD-10` | +| 9 | 抠图模型 | ✅ BiRefNet；**禁用 RMBG-2.0**（非商用许可） | `TD-07` | +| 10 | 12 季色彩体系版权 | ✅ 自建色板与自研命名，规避「CMB / 四季色彩」商标 | `TD-18` | +| 11 | 报告长图渲染 | ✅ 服务端 Playwright 渲染 | `TD-12` | +| 12 | 知识库运营后台排期 | ✅ V1 就做极简版（内容运营不能靠改数据库） | `TD-25` | +| 13 | 备案路径 | ✅ **备案已完成**（原需大模型登记 + 算法备案）。转为持续义务：编号界面公示、范围一致性、变更备案 | `TD-19` | +| 14 | 是否支持一账号多形象档案 | ✅ V1 仅预留 `profile_id` 字段，不做 UI | `FR-ACC-12` | +| 15 | 报告术语通俗化 | ✅ 采用「专业术语 + 一句白话释义」并列展示，不改名 | `NFR-UX-03` | +| 16 | 单品素材来源 | ✅ **自采**（采购 → 实拍 → 抠图 → 标注）。版权干净、规格统一，代价是成为新的关键路径 | `TD-26` | +| 17 | 形象顾问合作方式 | ✅ **全职编制**。规则库产能可控、可深度参与后台设计与黄金集标注 | `TD-27` | +| 18 | V1 是否收费 | ✅ **V1 完全不收费，用配额限制控制成本**；支付、会员、点数全部推到 V2 | `TD-28` | +| 19 | 华为 IAP 与企业开发者资质 | ✅ V1 不接支付，IAP 不涉及；一键登录降级为 P1，V1 用华为账号授权登录 + 手机号验证码 | `TD-29` | +| 20 | 市场数据信源 | ✅ **已全部替换为官方可核实信源**（国家统计局、CNNIC、华为 HDC 2026）；并据此下调用户规模目标 | `TD-30`、§4.1、§8.1.1 | +| 21 | 五行/命理模块 | ✅ **不做**（V1 与 V2 均不纳入），规避应用市场审核风险 | `TD-31` | + +### 11.2 仍待业务输入 + +| # | 决策项 | 需要的输入 | 阻塞什么 | 编号 | +|---|-------|-----------|---------|------| +| 1 | **备案登记覆盖的模型清单** | 备案时是否已包含 DeepSeek 与智谱 GLM 两家 | 双路由能否在 V1 启用；若只覆盖一家需办变更或先单路由 | `TD-19` | + +> 除上述一项外，**其余业务决策已全部收口**。这一项之所以保留，是因为它是唯一可能影响 V1 上线合规性的未知项，且答案只能来自备案材料本身。 --- -**文档版本**：v4.0 +**文档版本**：v6.0 **创建日期**：2026-08-04 -**更新日期**：2026-08-11 +**更新日期**：2026-08-13 **作者**：产品团队 **状态**：待评审 **变更说明**： +- v6.0（2026-08-13）：业务决策全部收口，商业模式与市场数据重做 + - **§5.0 新增「V1 不收费，只限量」**：V1 不接入任何支付能力，会员/点数/付费报告全部推到 V2。连带简化：无 IAP、无 30% 抽成、无交易类合规材料，billing 域降级为「配额账本 + 消耗流水」（`TD-28`、`TD-29`） + - **§3 权益设计重构**：拆为「§3.2 V1 配额设计（唯一生效）」+「§3.3 V2 权益规划（仅架构预留）」+「§3.4 计量要求（不可裁剪）」。明确三条纪律：配额是服务端硬限制、V1 文案不出现价格字样、禁止静默扣减 + - **§4.1 市场规模全部重写**：三处无出处引用已删除，替换为国家统计局、CNNIC、华为 HDC 2026 的可核实数据（`TD-30`）。**并纠正一处严重口径错误** —— 纯血鸿蒙原生应用只能装在 HarmonyOS NEXT+ 设备（HarmonyOS 6 为 6,600 万台），此前引用的「13 亿设备」是含 IoT 的生态总数，与本产品分发无关 + - **§8.1.1 用户规模目标下调并改变考核方式**：原「DAU 30 万 / MAU 100 万 / 注册 200 万」废弃（分母错、粘性假设错）。改为注册 50 万 / MAU 15 万，并**以季度回访率替代 DAU 作为核心粘性指标** —— 形象诊断是低频决策型工具，用日活考核会逼出无意义的签到打卡 + - **§5.3 财务预期重写**：V1 收入恒为 ¥0（主动选择），只做成本封顶（月度 AI 成本 ≤ ¥12 万）与数据采集；原 Q1~Q4 季度盈利预测因四项假设全部失效而废弃，V1 跑满一个周期前不产出新预测 + - **§6.0 / §7.3.0 / §9.0 备案状态更新为已完成**：原最高级别风险（2~4 个月审批周期）关闭，关键路径转移到内容与素材生产。备案完成后的四项持续义务（编号公示、范围一致性、变更备案、材料留档）已列明 + - **§11 决策表**：新增 6 项收口（素材自采、顾问全职、V1 不收费、IAP 不涉及、市场数据信源、命理模块不做），待业务输入项从 6 项减至 1 项 +- v5.0（2026-08-13）：本轮完成全文档 review、重构与技术选型收口 + - **文档体系升级为四层**：新增《需求规格说明》《技术架构文档》《技术选型与调研报告》《合规与安全方案》《开发任务拆解》《文档索引 README》，并同步更新 §1.6 文档地图与 §10.3 关联文档清单 + - **§1.2 / §1.4 技术选型变更**：客户端由 Uni-App-x 改为**鸿蒙原生 ArkTS**；补齐服务端、基础设施、大模型、视觉能力的选型结论（`TD-01`~`TD-07`） + - **§5.2 新增平台抽成口径修正**：虚拟商品在鸿蒙必须走华为 IAP，抽成约 30%，原收入预测为交易额口径、偏乐观（`TD-16`） + - **§6 新增 Phase 0：前置验证与资质**，含备案登记（外部周期 2~4 个月，上线决定性瓶颈）、六项关键技术验证、数据与内容准备；Phase 1 补充「工程地基先于业务功能」的要求 + - **修正一处已失效的技术假设**：腾讯云人体检测与人体关键点接口已于 2025-10-30 下线，体型测算改为自建 RTMPose + 人像分割掩膜宽度剖面法（`TD-05`/`TD-06`） + - **§7.3 政策风险重写**：新增 §7.3.0 备案登记周期风险（升为最高级别风险）；数据合规补充「人脸原图不落盘以规避 10 万人备案阈值」的架构策略；AI 内容合规补充显式 + 隐式双重标识、统一合规出口、元数据被静默剥离的坑；内容审核明确六类对象全覆盖与 fail-close 原则 + - **§4.3 短期优势表述修正**：删去「Uni-App-x 多端能力」，改为强调换装/发型服务自有可控（可改造、可扩容、成本可归因） + - **§10.2 技术栈概要重写**；§10.4.2 合规法规依据补齐 2025 年新规（人脸识别办法、AI 生成内容标识办法 + GB 45438-2025） + - **§11 待决策事项**拆分为「已决策（15 项收口）」与「仍待业务输入（6 项）」 - v4.0（2026-08-11）： - **新增 §1.6 文档地图**，明确四个子系统文档的关系与依赖链路 - **重构 §2.2 美学报告**：拆分为初级（V1 免费）/ 全面（V2 付费）两级，补充完整触发时机设计（首次生成 4 类触点、更新触发 7 项条件、付费触发 7 个位置、拦截规则 11 项），并明确第一版以"预约留资"验证付费意愿；详细内容拆分为独立文档