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 年国产模型主流区间约为输入 ¥14/百万 token、输出 ¥216/百万 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 列表」透出，天然满足可解释与可审计要求。

核心设计：

{
  "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 次/秒。

成本量级（⚠️ 时效性）：图片审核约 ¥1025/万张，文本审核约 ¥1025/万条（套餐包价格更低）。相对 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 下线），使用前请复核标注了 ⚠️ 时效性 的条目。

---

相关文档

• 文档索引
• 技术架构文档（本文结论的落地形态）
• 需求规格说明（选型需满足的 NFR 约束）
• 合规与安全方案（§5 合规选型的完整义务解读）
• 开发任务拆解（未收口项对应的 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 项转入待业务输入