xsl/meida
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

save

Browse Source
This commit is contained in:
xsl
2026-08-13 23:10:49 +08:00
parent d784d4ae15
commit e31755e343
11 changed files with 4063 additions and 305 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/README.md
+208
View File
@@ -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`；强化计量要求 |
docs/合规与安全方案.md
+428
View File
@@ -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 生成内容显式 + 隐式双重标识，经统一合规出口收口 |
docs/开发任务拆解.md
+418
View File
@@ -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
任务：<一句话说明要做什么>
背景：<为什么需要，解决什么问题>
交付物：<可检查的产出：代码模块 / 接口 / 数据 / 报告 / 配置>
验收标准：<可判定的条件，含具体数值或测试用例>
依赖：<前置任务编号>
关联需求：<FR-xx / CR-xx / NFR-xx>
风险：<已知不确定性与备选方案>
```
---
## 相关文档
- [文档索引](./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 定为备案与前置验证阶段并与开发并行 |
docs/技术架构文档.md
+1019
View File
File diff suppressed because it is too large Load Diff
docs/技术选型与调研报告.md
+711
View File
@@ -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 项转入待业务输入 |
docs/用户系统与记忆系统-需求文档.md
+130 -51
View File
@@ -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)
docs/穿搭Agent-需求文档.md
+33 -11
View File
@@ -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)
docs/美学报告-需求文档.md
+79 -28
View File
@@ -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)
docs/美学知识库-建设方案.md
+107 -18
View File
@@ -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)
docs/需求规格说明.md
+427
View File
@@ -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 | 首次建立统一需求编号体系，收拢五份需求文档 |
docs/鸿蒙美搭-智能穿搭美学助手-产品方案.md
+503 -197
View File
File diff suppressed because it is too large Load Diff