meida/docs/技术选型与调研报告.md

# 技术选型与调研报告

> 版本：**v1.2**　｜　调研截止日期：2026-08-13　｜　状态：已定稿（可执行）
>
> 本文的作用是把散落在各需求文档中的「待确认事项」一次性收口。每一条都给出：**结论 → 理由 → 备选方案 → 触发切换的条件 → 信源**。
>
> **使用约定**：
> - 各需求文档不再重复讨论技术选型，一律引用本文的决策编号（如 `TD-08`）。
> - 带 `⚠️ 时效性` 标记的条目（主要是价格与厂商接口能力）需在开发启动前复核一次，云厂商接口下线与调价都很频繁——本次调研就撞上了一个（见 `TD-05`）。
> - 结论分三档：**已定**（可直接进入开发）、**已定方向待验证**（需要一个验证任务确认）、**待业务输入**（不是技术问题）。

---

## 0. 已确认的项目前提

以下前提由项目决策直接给出，是本文所有技术判断的边界条件：

| 前提 | 取值 | 对架构的影响 |
| --- | --- | --- |
| 换装/发型服务归属（**编号为 `TD-00`**） | **自有服务，源码可控，可改造** | 可以把它从「黑盒 HTTP 接口」升级为「受管控的内部推理服务」：加鉴权、改异步回调、独立扩容、埋成本点。改造要求见架构 §4.4，被 `FR-TRY-01` 等需求依赖 |
| 团队规模 | 4~6 人（前端 + 后端 + 算法 + 产品/设计） | 不上微服务。V1 采用**模块化单体 + 独立 AI 能力服务**的两层结构 |
| 后端技术栈 | **全 Python（FastAPI）** | 业务与 AI 同栈，模型侧代码可直接复用，无跨语言序列化成本 |
| 云厂商 | **腾讯云为主** | 存储、审核、人脸能力优先用腾讯云；不足处允许跨云补齐（见 `TD-05`） |
| 前端框架 | 可调整，按调研结论定 | 见 `TD-01` |
| 视觉分析 | 优先第三方 API | 但腾讯云人体能力已下线，必须部分自建，见 `TD-05`/`TD-06` |
| 大模型 | **DeepSeek + 智谱 GLM** | 双供应商路由，见 `TD-04` |
| 排期约束 | 以 AI 辅助开发为主，不按人日排期 | 任务拆解按**依赖关系与里程碑**组织，不写人日估算 |
| 预算约束 | 暂不设上限，效果优先 | 允许自建 GPU 推理与服务端渲染；但仍要求全链路成本可观测（否则用户量上来后无法归因） |

---

## 1. 决策总表

| 编号 | 议题 | 结论 | 状态 |
| --- | --- | --- | --- |
| **TD-00** | **换装/发型服务的纳管改造** | 自有服务，源码可控；改造为受管控内部服务（鉴权 + 异步回调 + 成本埋点 + 独立扩容） | 已定，见 §0 与架构 §4.4 |
| 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 均不纳入） | 已定 |
| **TD-32** | **短信验证码通道** | 腾讯云短信（SMS），与云厂商收口一致 | 已定，V1 必需 |
| **TD-33** | **天气数据源** | **V1 不接天气 API**，改为「用户告知 + 季节推断」降级 | 已定，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。

**必须从第一天就埋的事件**（漏斗断点一旦漏埋，数据就永远补不回来）：

**V1 必埋**：注册、授权同意、拍照上传、报告触发、报告完成、报告页各模块曝光与展开、**报告结论认同/修正**（`FR-RPT-19`）、分享、Agent 会话开始/轮次/满意度、换装发起/成功/失败、**配额消耗与退还**、**全面报告预约留资**（`FR-RPT-20`）、**会员页曝光与「上线提醒我」留资**（`FR-BILL-12`）、**熔断降级触发**。

**V2 才有（V1 无对应功能，不埋）**：付费页曝光、下单、支付成功、点数购买。

---

## 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 方案，把工程量压到最小。前台体验投入优先给用户端。

### TD-32　短信验证码通道：腾讯云短信

> 🆕 **本条是文档评审新发现的缺口**。`FR-ACC-04`（手机号验证码登录）是 **P0/V1 的登录兜底通道**，但此前 31 项技术决策中**没有短信服务商选型**，架构的外部依赖表、系统上下文图、成本模型里也都没有短信。这是"需求存在但无人认领"的典型，会在开发到登录模块时直接卡住。

**结论**：用**腾讯云短信（SMS）**。

**理由**：

1. **与云厂商收口一致**（`TD-03`）。同账号、同 SDK 体系、同一套密钥管理与账单，不额外引入一家供应商的接入与对账成本。
2. **短信是纯商品化能力**，各家在到达率与价格上差异很小，选型不值得花精力，跟随主云厂商是最省事的正确答案。
3. 单条约 ¥0.03~0.045，V1 量级下**成本可忽略**，但仍需纳入成本模型以免被遗漏。

**为什么手机号通道不能省**（它不是"多一种登录方式"这么简单）：

- **华为账号是唯一登录通道时，一旦华为侧授权异常或用户拒绝授权，用户直接无法进入产品**，没有任何兜底。
- 一键登录已降级为 P1/V2（`TD-29`，需企业资质），因此 V1 的登录只有「华为账号授权」与「手机号验证码」两条，**后者是唯一的独立通道**。

**必须一并实现的防刷措施**（`NFR-SEC-05` 原文只提了"防刷"，未覆盖短信场景，已补）：

| 措施 | 具体要求 | 不做的后果 |
| --- | --- | --- |
| 单号码频控 | 同一号码 60s 内 1 条、1 小时 ≤ 5 条、24 小时 ≤ 10 条 | 用户被短信轰炸，投诉与运营商处罚 |
| 单 IP / 设备频控 | 同 IP 24 小时 ≤ 20 条；同设备指纹 ≤ 10 条 | 被脚本批量刷，**短信费用是真金白银的直接损失** |
| 图形/行为验证 | 触发频控阈值后强制人机校验 | 同上 |
| 验证码本身 | 6 位数字，有效期 5 分钟，**校验失败 5 次即作废**，一次性使用 | 暴力枚举可撞开任意账号 |
| 号码脱敏 | 日志与后台一律掩码（`138****8888`），`phone_enc` 加密存储 | 违反 `NFR-SEC-03` |
| 发送量告警 | 日发送量环比突增告警 | 被刷时无人知晓，直到看账单 |

**降级策略**：短信通道不可用时，**华为账号登录必须仍然可用**，登录页给出明确提示而非笼统报错。两条通道不得互相依赖。

### TD-33　天气数据源：V1 不接，改为降级方案

> 🆕 **本条同为评审新发现的缺口**。Agent 的意图类别含「天气适配」，典型场景直接演示了"明天 15 度有雨怎么穿"，知识库场景实体含温度带映射，L0 的城市字段用途还写着"天气定位"—— 但全部文档中**没有任何天气 API 的选型、来源与成本说明**。

**结论**：**V1 不接入天气 API**。Agent 遇到天气类问题时走以下降级路径：

1. **优先让用户自己说**：「今天你那边大概多少度？下雨吗？」—— 一句反问即可拿到最准确的信息，用户成本极低。
2. **按城市 + 日期做季节推断**：用 L0 的城市字段映射到气候区，结合当前月份推出温度带（如"上海 8 月 → 炎热潮湿"），给出季节性建议而不谎报具体天气。
3. **绝不编造具体天气数值**。这是硬红线 —— 模型幻觉出一个"明天 18 度"会直接摧毁用户对整个产品专业性的信任，而这个错误用户第二天一定会发现。

**为什么 V1 不做**：

1. **天气只是穿搭建议的一个输入变量，不是核心价值**。本产品的差异化在"基于你的体型与色彩的个性化建议"，不在天气预报，接入天气不改变竞争力。
2. **投入产出比低**：要做对就得处理定位授权、城市映射、缓存策略、供应商配额与降级，是一条完整的工程链路；而"让用户说一句"这个降级方案的体验损失很小。
3. **省掉一项定位权限**。为天气申请定位授权会拉高授权拒绝率，并增加隐私合规面（`CR-*`），代价明显超过收益。

**V2 再评估的触发条件**：若「知识缺口埋点」（`FR-AGT-11`）显示天气类 query 占比 **> 5%**，或主动推荐（`FR-AGT-18`）立项，则接入天气 API。届时优先考虑和主云厂商体系一致的方案，避免再增加一家供应商。

**必须同步修正的表述**：Agent 文档中「场景理解：理解场合/季节/**天气**/风格偏好」的 P0 描述已改为不含天气；L0 城市字段的用途改为「气候区推断与区域化内容」，不再写"天气定位"。

---

## 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. **规则库不是一次性交付物，而是需要持续迭代的资产**。V1 的 400 条规则写完只是起点（长期目标 800~1200 条，见知识库 §9.1），之后要根据用户反馈与结论修正率反复校准。按条计酬的外部顾问在"交付完成"后就没有继续投入的动力，而这恰恰是质量提升最关键的阶段。
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.2 | **文档一致性评审修订，补齐两个"需求存在但无人认领"的选型空洞**。**新增 `TD-32` 短信验证码通道**（腾讯云 SMS）—— `FR-ACC-04` 是 P0/V1 的登录兜底通道，但此前 31 项决策中没有短信选型，架构外部依赖表、系统上下文图、成本模型里也都没有它；一并给出六项防刷措施（短信是被刷时的直接现金损失，且没有配额兜底）与「两条登录通道不得互相依赖」的要求。**新增 `TD-33` 天气数据源** —— Agent 的意图类别含天气适配、典型场景直接演示温度降水，但全部文档没有天气 API 的来源与成本；结论是 **V1 不接**，改为「反问用户 + 城市月份推断气候区」，并立下硬红线**绝不编造具体天气数值**（模型幻觉出一个温度，用户第二天一定会发现）。**补 `TD-00` 定义** —— 换装/发型服务的纳管改造此前被 `FR-TRY-01` 与架构 §4.4 引用却从未编号定义。另：埋点清单拆分 V1 必埋与 V2 事件（V1 无支付，不应埋付费漏斗）；措辞「扣点数」→「扣减配额」；规则规模改为引用知识库 §9.1 |
| 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 项转入待业务输入 |