xsl/meida
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
main
meida/docs/鸿蒙美搭-智能穿搭美学助手-产品方案.md
T
xsl f244f14ab8 feat(billing): 任务换额度端侧闭环（T2b 定稿 4 任务） 
- TaskBonusPanel 重写：每日任务/新手任务分组、五态按钮、真实「去完成」跳转（first_report→诊断落地页；report_feedback/share_report→报告结果页）、40311/40310 文案、panel_view/task_tap 埋点
- ReportPdfPage 分享成功→静默 claim share_report；ReportResultPage SUCCEEDED 展示→静默 claim first_report（后端 40910 幂等兜底，老用户首进补发一次属预期回填）
- ChatPage/ReportResultPage 修 bonus_granted 类型误写（boolean→number）
- docs：T2b 任务书（验收 11 条）+ 产品方案 §3.2 任务目录定稿（签到对话+10/日、报告反馈发型+2/日、分享换装+3/日、首测重生成+1/终身；邀请好友砍）

偏差说明：share_report 落点为报告结果页而非 PDF 预览页（该页强依赖本地 pdfPath，直达需下迭代加持久化）。
2026-09-12 00:25:08 +08:00

108 KiB
Raw Permalink Blame History

「美搭」- 智能穿搭美学助手 详细产品方案

1. 产品概述

1.1 产品名称

「美搭」- 智能穿搭美学助手

1.2 产品定位

面向爱美用户的智能穿搭指导应用，集成换装、换发型、美学报告等核心能力，为用户提供个性化、专业化的形象管理方案。第一版采用鸿蒙原生开发，首发鸿蒙（HarmonyOS）应用市场。

1.3 产品愿景

成为用户最值得信赖的智能美学助手，让每个人都能轻松拥有专业级的形象管理能力。

1.4 技术选型

完整选型结论与理由见《技术选型与调研报告》，技术方案见《技术架构文档》。此处仅列结论。

层面 选型 决策编号
客户端 鸿蒙原生 ArkTS + ArkUI（V1 单端） TD-01
服务端 Python 3.12 + FastAPI（模块化单体 + 独立 AI 能力服务） TD-02
基础设施 腾讯云（CVM / PostgreSQL+pgvector / Redis / COS / CDN / CLS） TD-03
大模型 DeepSeek（主）+ 智谱 GLM（备与视觉），自建 LLM 网关 TD-04
视觉能力 腾讯云人脸识别 + 自建人体关键点（RTMPose）+ 自建抠图（BiRefNet） TD-05~TD-07
首发平台 鸿蒙 HarmonyOS NEXT —
后续规划 iOS / Android 多端在 V2 重新评估跨端方案 TD-01

为什么 V1 改为鸿蒙原生（原方案为 Uni-App-x）：V1 只发鸿蒙一个端，跨端框架的收益此刻为零而成本已经付出；且本产品重度依赖系统能力（相机与大图压缩、长耗时任务后台通知、华为账号、支付、Canvas 长图、流式渲染），原生支持更完整。Uni-App-x 虽自 HBuilderX 4.61+ 支持纯血鸿蒙，但官方明确提示鸿蒙端「处于发展初期，能用有坑，应降低验收期望」，与本项目「效果优先」的定位冲突。多端需求在 V2 明确后再统一评估。

1.5 目标用户

核心用户

  • 人群特征：25-35岁都市白领女性
  • 消费能力：月收入 8000-15000 元
  • 消费特征：注重形象管理，愿意为美丽付费
  • 使用场景：职场穿搭、约会造型、社交媒体分享

扩展用户

  • 时尚爱好者：追求潮流趋势，需要专业指导
  • 社交媒体创作者：需要快速产出优质穿搭内容
  • 形象管理初学者：希望系统性提升穿搭品味

1.6 文档地图

本方案为总纲。完整文档索引与阅读路径见《文档索引 README》。文档分四层，冲突时以下层为准：

第二层｜做什么

文档 内容 对应本文档章节
📎 需求规格说明 统一需求编号（FR/NFR/CR）、优先级、验收标准 —— 开发与测试的索引 全篇
📎 美学报告需求文档 报告触发时机、初级/全面分级、诊断维度字典、生成流程、付费策略 2.2
📎 穿搭 Agent 需求文档 对话能力、意图识别、场景理解、能力联动 2.3
📎 用户系统与记忆系统需求文档 账号体系、会员与配额、L0~L5 分层记忆模型 2.4
📎 美学知识库建设方案 12 类知识分类体系、7 种模态、构建流程、检索链路 2.5

第三层｜怎么做

文档 内容
📎 技术架构文档 分层架构、模块划分、数据模型、关键链路、API 规范、部署与成本模型
📎 技术选型与调研报告 31 项技术决策的结论、理由、备选与切换条件
📎 合规与安全方案 人脸信息、AI 生成内容标识、备案登记、内容审核、数据安全

第四层｜谁来做、什么时候做

文档 内容
📎 开发任务拆解 WBS、依赖关系图、六个里程碑、任务验收条件

四者的关系：知识库提供专业能力 → 美学报告生产用户画像 → 记忆系统承载并持续演进画像 → Agent 与试穿功能消费画像。缺少任何一环，个性化能力都会退化为通用建议。

   知识库（专业性）
        │
        ▼
   美学报告（诊断） ──写入──▶ 记忆系统（个性化） ──驱动──▶ Agent / 换装 / 发型
        ▲                                                      │
        └───────────────── 行为回流 ◀──────────────────────────┘

2. 核心功能设计（第一版）

2.1 智能试穿系统

2.1.1 换装试穿

  • 测试页面：https://meida.xiangsilian.com/

  • API 文档：https://meida.xiangsilian.com/api

  • 核心接口：POST https://meida.xiangsilian.com/change_cloth_base64

  • Swagger 调试：https://meida.xiangsilian.com/docs

  • 接口能力（服务端按传入字段自动选择工作流）：

    传入字段 工作流
    仅 human_img 单图编辑（改背景/按提示词编辑）
    human_img + cloth_img 模特 + 上衣换装
    human_img + cloth_img + kuzi_img 模特 + 上衣 + 裤子换装

  • 请求参数：

    字段 类型 必填 说明
    human_img string 是 模特/人物图 Base64（支持 Data URL）
    cloth_img string 否 上衣图 Base64，默认 ""
    kuzi_img string 否 裤子图 Base64，默认 ""，传了则走上衣+裤子流程
    change_desc string 否 提示词，空则使用默认提示

  • 响应格式：

    {
  "ret": 0,
  "state": 0,
  "msg": "success",
  "data": "https://xiangsilian.oss-cn-beijing.aliyuncs.com/tryon/xxxx.png?..."
}
    • ret === 0 && data 判断业务成功
    • data 为阿里云 OSS 签名链接，可直接展示

  • 功能描述：

    • 虚拟试衣间：上传用户照片 → 选择服装单品 → 实时换装预览
    • 多场景适配：职场/约会/运动/聚会/旅行等场景切换
    • 单图编辑：基于提示词对人物图进行编辑（如更换背景）
    • 上衣+裤子组合换装：完整搭配预览

  • 用户体验流程：

    1. 用户上传正面全身照（或调用摄像头拍摄）
    2. 选择换装模式：单图编辑 / 上衣换装 / 上衣+裤子换装
    3. 选择服装单品（上衣/裤子图片）
    4. 可选填写提示词（如"换成白色背景"、"保留发型"等）
    5. 点击生成，等待换装结果（前端展示已等待秒数）
    6. 查看换装效果，支持保存/分享
    7. 可基于结果继续编辑或重新生成

  • 关键注意事项：

    • 推理耗时较长（几十秒到几分钟），前端超时需 ≥ 320 秒
    • 前端需展示 loading 进度和已等待秒数，避免用户误以为卡死
    • 图片建议先压缩到长边 1024~2048 再上传
    • 裤子流程必须同时传 cloth_img，否则解码失败
    • OSS 结果链接为签名链接，长期存储需自行转存
    • 健康检查：GET /health，status 为 ok 时可正常换装

2.1.2 发型设计

  • 测试页面：https://meida.xiangsilian.com/hair/

  • API 文档：https://meida.xiangsilian.com/hair/api-doc.html

  • API 基础路径：https://meida.xiangsilian.com/hair/api

  • 认证方式：无需认证

  • 发型库：60 款发型，预览图分辨率 634×950

  • 接口能力：

    ① 获取发型列表

    • 接口：GET /hair/api/hairstyles
    • 参数：无
    • 响应： 
      {
  "success": true,
  "data": {
    "hairstyles": [
      {
        "id": "1953267161121464322",
        "name": "发型4322",
        "image_url": "/hair/images/hairstyles/1953267161121464322.jpg"
      }
    ]
  }
}
    • image_url 为相对路径，完整链接 = https://meida.xiangsilian.com + image_url

    ② 更换发型

    • 接口：POST /hair/api/change-hair
    • Content-Type：multipart/form-data
    • 参数：
      参数名 类型 必填 描述
      image File 是 用户图片（png/jpg/jpeg/gif，最大 16MB）
      hairstyle_id String 是 目标发型 ID
    • 响应： 
      {
  "success": true,
  "data": {
    "result_image": "data:image/jpeg;base64,/9j/4AAQ..."
  }
}
    • 超时时间 120 秒；远程调用失败时返回原图作为降级处理

    ③ 更换头发颜色

    • 接口：POST /hair/api/change-hair-color
    • Content-Type：multipart/form-data
    • 参数：
      参数名 类型 必填 描述
      image File 是 用户图片（最大 16MB）
      rgb String 是 RGB 颜色值，格式 "[R, G, B]"，如 "[255, 106, 0]"
      ratio String 是 替换强度 0.0~1.0，如 "0.9"
    • 响应：同更换发型接口
    • ratio 越大颜色替换越明显；超时 120 秒

  • 功能描述：

    • 发型浏览：发型列表/分类/搜索/收藏
    • 发型试戴：上传面部照片 → 选择发型 → 实时预览
    • 发色仿真：在已换发型基础上调整发色（黑/棕/金/红/自定义 RGB）
    • 强度调节：通过 ratio 控制发色替换强度
    • 风格筛选：按长发/短发/卷发/直发等风格筛选发型

  • 用户体验流程：

    1. 用户上传面部特写照片
    2. 浏览发型库（支持风格筛选/搜索）
    3. 选择目标发型，点击预览
    4. 等待 AI 处理（展示进度，最长 120 秒）
    5. 查看发型更换效果
    6. 可选：调整发色（选择预设色或自定义 RGB + 强度）
    7. 支持保存/分享/对比

2.2 专业美学报告（详见独立文档）

美学报告是产品的画像生产者与专业感锚点：体型、脸型、肤色、季型、量感、直曲等结论一次诊断、全局复用，Agent 对话与试穿推荐全部依赖它。详细需求见独立文档：

📎 美学报告需求文档

2.2.1 分级设计

报告拆分为两级，第一版只做初级报告（免费），全面报告与支付放在 V2：

初级报告「形象速测」 全面报告「形象深度诊断」
上线版本 V1 V2（V1 仅做占位入口）
价格 免费 付费（定价待 V2 按真实数据确定，见 §5.0）
输入 1 张全身照 + 4 项问卷 全身正/侧 + 面部特写 + 12~15 项问卷
诊断维度 覆盖 21 / 32 项（首屏突出 8 项核心结论） 覆盖全部 32 项
色彩精度 四季粗判 + 8 色色板 十二季细分 + 24+ 色完整色板
发型内容 3 条要点 独立发型专项报告（8 小节）
场景方案 1 个 4+ 个（含配色公式）
篇幅 / 时长 1~2 屏 / ≤60s 15~25 屏 / ≤5min（异步）
额度 每 30 天可重新生成 1 次（任务可 +1） 按次购买 / 会员权益（V2）

内容深度对标：全面报告对齐线下形象顾问交付标准（见 reference/个人形象报告.pdf），涵盖风格核心诊断、色彩诊断、身材穿搭指南、配饰规划、发型专项、场景方案包六大篇章，并新增线下报告普遍缺失的「30 天形象提升计划」。

2.2.2 触发时机（关键设计）

原则：报告是个性化的前置条件，要尽早触发；但需要用户投入拍照与问卷，所以不能强制。 解法是多入口触发 + 价值前置 + 可跳过可回补。

类型 触发点 预期承接
首次生成 ① 注册后引导（价值前置页 → 授权 → 问卷 → 拍照 → 生成），必须可跳过 主触发，约 60%
② 功能内价值触发：首次换装完成后 / 首次试戴后 / Agent 缺失画像时 / 收藏满 3 个 / 第 3 次打开 App 承接跳过用户
③ 常驻入口：首页「我的形象报告」卡片、个人中心形象档案、Agent 快捷问题 长尾
④ 社交触发：好友分享长图的落地页 增长
更新生成 体重变化 ≥3kg / 距上次 ≥90 天 / 换季（3·6·9·12 月）/ 上传新照片 / 换发型后 / 算法升级 主动提示，不自动扣额度
付费触发（V2） 初级报告结果页底部、章节内容截断处、Agent 深度问题、发型模块、会员页、营销节点、分享回流 转化
拦截不触发 非人像/多人/非全身/面部遮挡/光线过暗/分辨率过低/疑似未成年/未授权 不消耗额度
  • 报告必须版本化保留，更新后进入「形象档案时间轴」，支持前后对比，成为留存资产而非一次性内容
  • 无照片或拒绝人脸授权的用户走「问卷版轻画像」降级路径，不让个性化能力完全失效

2.2.3 第一版的付费意愿验证

V1 不做支付链路，在初级报告结果页保留「全面报告」预览卡片（模糊目录 + 内容清单），点击进入「即将上线，抢先预约」并留资埋点。决策门槛：预约率 ≥ 8% 则 V2 立即开发付费报告；< 3% 则重新评估内容形态。

⚠️ 卡片不得展示价格（FR-BILL-07）。原设计中的「预计价格」与「点击价格档位」已移除 —— V1 全产品线不出现任何价格字样，否则会污染 V2 的定价空间，也会让用户形成"处处收费"的第一印象。价格敏感度改用线下用户访谈采集（T-P0-26），这比在 App 里挂一个假价格更准，也没有副作用。

同时要承认这个指标的局限：预约不等于付费，留资到实付的衰减通常很大。因此 V2 定价前应补一次小范围真实收费灰度（T-P6-03b），不要仅凭预约率就全量定价。

2.3 AI 穿搭 Agent（详见独立文档）

穿搭 Agent 作为产品的智能交互核心，承担智能对话、场景理解、个性化推荐等能力。详细需求见独立文档：

📎 穿搭 Agent 需求文档

  • 第一版核心能力：

    • 自然语言对话（文字/语音）
    • 穿搭场景理解与建议
    • 与换装/换发型能力联动
    • 个性化偏好学习

  • 典型场景：

    • "我今天有个面试，怎么穿？"
    • "下雨天适合穿什么鞋子？"
    • "帮我搭一套法式优雅风格的look"
    • "这件白衬衫配什么裤子？"

2.4 用户系统与记忆系统（详见独立文档）

穿搭建议的价值高度依赖"懂这个人"。没有记忆系统，产品只能给出百科式的通用答案，而通用答案在内容平台上免费且更丰富——记忆系统是本产品相对于内容平台与通用大模型的核心护城河。详细需求见独立文档：

📎 用户系统与记忆系统需求文档

2.4.1 用户系统要点

  • 登录方式：华为账号授权登录（鸿蒙首发主路径）+ 手机号验证码 + 游客模式。「一键登录获取手机号」需企业开发者资质，降级为 V2（TD-29）
  • 游客模式：未登录即可完成 1 次换装、1 次试戴、1 次初级报告、3 次对话，注册后数据无感迁移，显著降低首启流失
  • 授权管理：人脸信息属敏感个人信息，必须单独授权、可单独撤回，并留存授权记录
  • 账号生命周期：支持数据导出、清空照片、撤回人脸授权、注销（7 日冷静期后彻底删除）

2.4.2 记忆系统：六层模型

层级 名称 内容 写入方式 生命周期
L0 身份档案 性别、生日、身高体重、职业、城市 用户填写 长期
L1 美学画像 体型、脸型、肤色、季型、量感、直曲、动静、风格、核心诉求 美学报告写入（唯一权威源） 长期，90 天复核
L2 偏好与禁忌 偏好风格/颜色/品类；禁忌项（不穿短裙、不露肩）；预算 显式设置 + 隐式行为推断 长期，隐式项衰减
L3 事件记忆 试穿、收藏、分享、采纳/拒绝、对话摘要 自动埋点 180 天滚动
L4 会话记忆 当前多轮对话上下文与场景槽位 运行时 会话结束或 24h
L5 衣橱记忆 用户已有单品（图片 + 属性 + 使用频率） 用户上传 + 视觉识别 长期（V2）

关键机制：

  • 带置信度与来源：用户确认(1.0) > 显式陈述(0.9) > 视觉分析(0.85) > 自评(0.6) > 行为推断(0.5)，隐式记忆 30 天未强化则衰减
  • 隐式推断需确认：同属性连续 3 次拒绝 → 生成待确认候选 → 恰当时机征询"看起来你不太喜欢露肩款？"，用户确认后才生效
  • 用户偏好高于专业结论：专业判定与用户喜好冲突时，按用户喜好执行 + 附加专业提示（不说教）
  • 可见可控：「我的记忆」页面可查看、修改、删除每条记忆，并可一键关闭个性化推荐（合规刚需 + 信任基础）
  • 注入有预算：记忆注入合计 ≤1400 token（V1 实际 ≤1200，事件召回为 V2 能力），不做无脑全量拼接。完整分项预算见《技术架构文档》§7.2（唯一事实源）

2.5 美学知识库（详见独立文档）

不能只靠大模型：会幻觉、不可审计、不可解释，且推荐的单品没有图就无法调用换装接口，"建议 → 预览"的闭环会断裂。详细方案见独立文档：

📎 美学知识库建设方案

2.5.1 四层架构

④ 检索与推理层：硬过滤 → 向量召回 → 图谱扩展 → 重排 → 生成（带引用）
③ 资产层：单品白底图 / look 图 / 发型图 / 色板图 / 图示
② 内容层：规则条目 / 专业解释 / 场景模板 / 报告话术 / 搭配方案
① 本体层：实体定义 + 属性字典 + 枚举值 + 实体关系

建设顺序不可颠倒：先定义本体（属性字典与枚举值），再灌内容与资产。否则会出现"同一个领型有 5 种写法"，导致检索与规则全部失效。

2.5.2 知识分类：12 类实体

🔗 规模数值的唯一定义位置是《美学知识库-建设方案》§9.1（区分「V1 硬指标」与「长期目标」两列）。本表只列内容构成，不复述规模 —— 此前本表的「第一版目标量级」与本文 §2.8、知识库 §9 三处互相矛盾（单品 800/300、规则 800/400、方案 300/100）。

类目 内容
① 单品 Item 品类树 + 廓形/领型/袖型/腰线/长度/图案/正式度/量感/直曲等属性
② 色彩 Color 色名 + HEX/HSL/Lab + 冷暖/明度/彩度 + 季型归属 + 配色关系
③ 风格 Style 9 型基因风格 + 20+ 潮流风格（法式/韩系/清冷/老钱风…）
④ 身材 Body 5 体型 + 13 局部特征（溜肩/短颈/长短腰…）→ 修饰策略
⑤ 面部与发型 7 种脸型/三庭五眼/量感/直曲 × 发长/卷度/刘海/发色 适配矩阵
⑥ 场景 Occasion 20 场景 × Dress Code × 温度带（8 档）。天气来自用户自述，V1 不接天气 API（TD-33）
⑦ 材质 Material 垂感/挺括/透气/保暖/易皱/光泽 + 季节与季型适配
⑧ 配饰 Accessory 8 品类的量感、材质、颜色、佩戴位置规则
⑨ 妆容 Makeup 12 季型 × 底妆/眼妆/唇妆 色值方案
⑩ 搭配法则 Rule 结构化 IF-THEN 规则（供规则引擎执行）—— 核心资产
⑪ 搭配方案 Outfit 成套 look（单品组合 + 配色公式 + 适配画像 + 试穿素材）
⑫ 趋势 Trend 时效性流行趋势，独立库、月更、过期降权

2.5.3 模态构成：7 种模态

这是"知识库是什么模态"的直接回答——它是多模态混合知识库，每种模态有明确分工，不可互相替代：

模态 存储与索引 用途 优先级
① 结构化 关系库 + 索引 硬过滤与计算，零幻觉、可审计 P0
② 规则 规则引擎（决策表） 核心结论由规则产出，不交给大模型 P0
③ 文本 全文 + 向量索引（200~400 字分块） RAG 生成解释与话术 P0
④ 图像 对象存储 + CDN + 图像向量 展示 + 换装 API 试穿素材 + 图搜 P0
⑤ 色彩数值 关系库 + 色差计算 肤色→季型归属、ΔE 匹配度 P0
⑥ 图谱 图库 / 邻接表 多跳推理 + 「为什么推荐」可解释链 P1
⑦ 视频/音频 CDN / TTS 造型教程、报告语音讲解 P2

各模态不是并列的独立数据，而是同一实体的多个面，通过统一 ID 串联，且入库时需交叉校验一致性（如图像标注颜色必须与色值一致）。

2.5.4 两个必须前置解决的数据缺口

缺口 影响 解法
发型库无适配标签 现有 60 款发型仅有 id/name/image_url，导致"按脸型推荐发型"根本无法实现 人工打标 60 款（脸型/量感/直曲/长度/卷度/刘海/正式度），约 1~2 人日
无单品白底图素材 换装接口需要 cloth_img/kuzi_img，没有素材则"一键试穿"不可用，用户只能自己找图 建立抠图流水线，V1 至少产出 300 件 tryon_ready 单品

换装接口仅支持上衣与裤子，连衣裙、鞋、包、配饰无法试穿。因此每个单品必须标注 tryon_slot 与 tryon_ready，产品端只对可试穿单品展示"一键试穿"，其余展示"加入搭配"，避免用户点了没反应。

2.6 我的衣橱（V2 规划，差异化重点）

当前所有 AI 穿搭产品的通病是"推荐了用户没有、也买不到的衣服"。衣橱功能让建议落到用户真实拥有的单品上：

  • 拍照入库 → 自动抠图 → 视觉识别属性（品类/颜色/廓形）→ 用户微调确认
  • 能力：一衣多搭（这件衬衫能配什么）、衣橱体检（哪些不适合你的季型/体型）、缺口建议（补齐 3 件即可多出 12 套搭配）、按场景生成 look
  • 与记忆系统 L5 打通，是提升长期留存的核心功能
  • V1 可先埋入口收集意愿，不开发

2.7 任务中心（长耗时任务产品化）

换装最长 320s、发型 120s、全面报告 ≤5min，长耗时是本产品的固有特征，不能靠"转圈等待"硬扛：

  • 所有 AI 生成走异步任务队列，返回 task_id，前端轮询或长连接获取状态
  • 用户可最小化任务、退出页面甚至退出 App，完成后推送通知召回
  • 任务中心统一展示进行中/已完成/失败任务，失败可一键重试（不重复扣减配额）
  • 生成过程步骤可视化（识别人像 → 测算体型 → 分析面部 → 采样色彩 → 生成方案），并展示已等待秒数
  • 等待期填充内容：美学小知识卡、报告样例、热门搭配
  • 端侧前置质量校验（是否人像/单人/全身/清晰/光线），不合格直接拦截，既省成本又省用户时间

2.8 第一版功能范围

✅ 第一版包含

  • 换装试穿（单图编辑 / 上衣 / 上衣+裤子）
  • 发型设计（发型更换 / 发色更换）+ 60 款发型适配标签
  • 初级美学报告（免费）+ 形象档案与版本对比
  • AI 穿搭 Agent（基础对话 + 画像注入）
  • 用户系统（华为账号授权登录 / 手机号验证码 / 游客模式 + 数据迁移）
  • 记忆系统 L0~L4 + 「我的记忆」管理页
  • 美学知识库 V1（规则 400 条 / 自采单品 300 件 / 方案 100 套 / 12 套色板 / 发型打标）
  • 任务中心 + 完成推送 + 端侧照片预检
  • 历史记录、收藏、分享长图
  • 配额限制与成本计量（V1 唯一的成本控制手段，且为 V2 定价提供真实数据）
  • 备案编号公示页（合规必需，上架核验项）
  • 运营后台极简版（顾问维护知识与规则、素材上传、发布回滚）

🅿️ 第一版做入口、不做实现（意愿验证）

  • 全面美学报告（预约留资 + 埋点，不展示价格）
  • 我的衣橱（入口收集意愿）
  • 会员权益（静态展示 + 「上线提醒我」留资，不出现价格、不开放支付）

❌ 第一版不包含（后续版本规划）

  • 全部支付能力：IAP、订单、会员订阅、点数购买、退款与对账（TD-28）
  • 广告变现（不接开屏、信息流、激励视频，避免影响首发体验与评价）
  • 华为账号一键登录（需企业资质，TD-29）
  • 购物引导、商城与电商导购分成
  • 化妆指导（接口待定）
  • 社区与 UGC
  • B 端 API 输出
  • 多端协同（平板/手表/车机）
  • 系统级集成（服务卡片/语音唤醒等）
  • 五行 / 命理模块（永久不做，TD-31）

3. 产品形态与权益设计

3.1 原方案的成本风险与改造

原方案设定"会员 ¥9.9/月 = 无限换装"，在成本上不成立：换装是长耗时 GPU 推理（几十秒到几分钟），单次成本在角到元量级，重度用户单月可消耗数十元，会员越活跃越亏损。

V1 的解法比点数制更彻底：干脆不收费，只限量（TD-28）。不收费就没有"付费用户应该无限用"的压力，配额可以设得紧、熔断可以设得狠，不必担心损害已付费用户的权益。点数制留给 V2 —— 届时有了 V1 的真实成本数据，点数消耗比才有依据。

⚠️ 但要澄清一个常见误解：配额不等于总成本封顶。配额约束单个用户，总成本 = MAU × 人均，而 MAU 无上限。真正封顶的是全局日成本熔断（NFR-COST-02），详见 §5.3.1。

3.2 V1 配额设计（唯一在 V1 生效的一张表）

V1 无付费、无会员、无点数购买，所有注册用户使用同一套配额。额度用尽后只有两条路：等自然恢复，或做任务换额度。

🔒 本表是 V1 全部配额数值的唯一定义位置（含游客）。FR-ACC-02、FR-BILL-*、用户系统 §2.4.1、bl_quota_rule 的初始化数据一律引用本表。

能力 游客（设备维度，终身） 注册用户基础额度 可通过任务额外获得 硬上限（防刷）
初级美学报告（首次） 1 次 1 次（终身） — —
报告重新生成 ❌ 每 30 天 1 次 +1 次/月 每日 ≤ 2
换装试穿 1 次 每日 3 次 +3 次/日 每日 ≤ 8
发型 / 发色试戴 1 次 每日 3 次 +2 次/日 每日 ≤ 6
AI 对话 3 轮 每日 10 轮 +10 轮/日 每日 ≤ 40
记忆条数 不写入长期记忆 200 条 — —
高清导出 ❌ 每日 1 次 — 每日 ≤ 3

游客配额的三个要点：

  1. 是终身额度，不是每日额度 —— 游客额度的目的是"让人尝一口就想注册"，每日恢复会让相当一部分用户永远不注册。
  2. 按设备维度计量（设备指纹 + 匿名 ID），因此必然可以被清数据绕过。这是可接受的：游客额度极小，绕过的收益低于用户重装 App 的成本，不值得为它上强风控。
  3. 额度用尽必须是"引导登录"而非"静默失败" —— 这是游客模式唯一的转化时机，做成一个报错就白费了。

任务奖励额度的获取方式（全部不涉及金钱）。V1 任务目录已于 2026-09-11 定稿（原为占位；研发任务书见《开发任务包/T2b-任务换额度-端侧闭环》）：

任务 task_key 奖励 领取周期 完成判定 内测期状态
每日签到 sign_in AI 对话 +10 轮 每日 点击签到即完成（登录态 + 服务端日幂等），行为本身即任务 ✅ 上
给报告结论打反馈 report_feedback 发型/发色 +2 次 每日 服务端可信：当日 rp_feedback 存在本人记录 ✅ 上
分享我的报告 share_report 换装 +3 次 每日 端侧自报：调起系统分享面板即算完成，埋点观测 ✅ 上（自报水位）
完成首次形象速测 first_report 报告重生成 +1 次 终身一次 服务端可信：rp_report 存在本人已完成报告 ✅ 上（替代原「完善画像资料」）
邀请好友 invite_friend — — 无可信信号（无邀请码/回流链路） ❌ 内测期下架，V2 有邀请链路后重评

数值决策理由（2026-09-11）：

  1. 与配额种子精确对齐：四个任务的奖励合计恰好等于 bl_quota_rule.task_bonus_max（对话 10 / 换装 3 / 发型 2 / 重生成 1），只需改 TASK_BONUS_RULES_JSON 配置即生效，不动配额种子、不发版（FR-BILL-04）。
  2. 签到独得对话 +10：Agent 单轮成本最低（≤¥0.05），签到让对话额度翻倍（10→20 轮/日）是最直接的日活钩子；物理上限 hard_cap 40 不变，§5.2.1 成本模型不受影响。
  3. 反馈奖发型 +2/日（改掉原配置「反馈奖重生成 +1」）：反馈是每日可重复行为，而重生成月封顶 1 次——原配置下用户当月第 2 天起再反馈必撞 40310，等于白做。且反馈数据是结论认同率/修正率指标（FR-RPT-19）的唯一数据来源，值得用高频日奖励驱动。
  4. 分享只能端侧自报，内测期接受：Share Kit 系统分享无「实际发送成功」回调，内测期不做服务端事件校验（埋点本身可伪造且批上报有节流，做校验是自欺）。刷满收益被 hard_cap 8 锁死，已含在 §5.2.1 物理上限成本模型内，零增量成本风险；埋点观测滥用率，内测后复评。
  5. 邀请好友直接砍：无邀请码与回流链路，任何形态都只能纯自报且无观测锚点，上了等于无条件每日 +1 换装。
  6. 「完善画像资料」改造为「完成首次形象速测」：资料维护功能（FR-ACC-06）V1 未实现，无可信信号；完成速测是产品核心漏斗（报告是画像生产者），服务端有 rp_report 记录可校验，语义闭环「觉得不准，本月可重来一次」。
  7. 主表「报告重新生成 +1 次/月」在内测期由 first_report 一次性兑现；月度循环获取途径等 V2 任务体系扩展时再补。

三条不可违反的设计纪律：

  1. 额度是服务端硬限制，不是前端提示 —— 服务端校验后直接拒绝，不存在绕过路径。这是成本封顶能成立的前提（见 §5.3.1）。
  2. 文案中不出现任何价格或购买字样 —— 额度用尽的提示是「今日额度已用完，明天再来，或做个任务多换 3 次」，不是「升级会员解锁」。V1 出现价格暗示会污染 V2 的定价空间，也会让用户觉得这是个"处处收费"的产品。
  3. 每次消耗前置提示剩余量（"本次将使用 1 次换装额度，今日还剩 2 次"），禁止静默扣减。

3.3 V2 权益规划（V1 不实现，仅作架构预留）

下表是 V2 的规划草案，定价与点数消耗比均需按 V1 采集的真实数据重算（TD-16、T-P6-16），现在的数字只是占位。V1 的数据模型需为这张表预留字段，但不实现任何付费逻辑。

权益项 免费版 会员版（价格待定） 高级版（价格待定）
每日换装 / 发型 3 次 10 次 20 次
每日 AI 对话 10 轮 100 轮 不限（防刷上限）
月度权益点数 0 待定 待定
初级美学报告 每 30 天 1 次 每 7 天 1 次 不限（每日 ≤3）
全面美学报告 单次付费 折扣价 含 1 次/季
我的衣橱容量 20 件 200 件 不限
记忆条数上限 200 条 500 条 不限
高清导出 / 去水印 ❌ ✅ ✅
  • 点数消耗与获取、扣减顺序：V2 设计时确定。架构上已按「reserve → commit / refund 预扣三段式」预留（见《技术架构文档》§7.4），保证长耗时任务不会出现"扣了额度但没交付"。
  • V1 与 V2 的衔接：V1 的「配额账本」与 V2 的「点数账本」是同一张表的两种用法 —— V1 有 system_grant（系统发放）、consume（消耗）、refund（退还）三种流水类型，V2 增加 purchase（购买）与 gift（赠送）。这样 V2 不需要数据迁移。refund 不可省略：预扣三段式与熔断退还额度都依赖它。

3.4 第一版的计量要求（不可裁剪）

V1 不收费，但计量是 V1 最重要的隐性交付物，它决定 V2 能不能定出合理的价格：

  • 每次 AI 调用完整落库（ob_ai_call）：功能、用户、模型、token 数、耗时、成本、成功与否
  • 每次配额变动落流水（bl_ledger）：发放来源、消耗去向、余额快照，每日自动对账
  • 会员页做静态权益展示 + 「上线提醒我」留资，验证订阅意愿（不出现价格）
  • 全面报告做预约留资，验证单次付费意愿（决策门槛 ≥ 8%）
  • V2 依据以上数据确定定价，避免拍脑袋定价导致亏损或滞销

4. 市场分析与竞争策略

4.1 市场规模

本节数据已于 2026-08-13 全部替换为可核实的官方信源（国家统计局、CNNIC、华为官方发布），原三处无出处引用已删除（TD-30）。凡属本方案推算的数字，均显式标注为「推算」并给出推算口径，不与官方数据混排。

4.1.1 服装与美妆消费大盘（国家统计局）

指标 2025 年实际值 同比
限额以上单位服装、鞋帽、针纺织品类零售额 15,215 亿元 +3.2%
限额以上单位化妆品类零售额 4,653 亿元 +5.1%
社会消费品零售总额 501,202 亿元 +3.7%

信源：《中华人民共和国 2025 年国民经济和社会发展统计公报》（国家统计局，2026-02-28）；《2025 年 12 月份社会消费品零售总额》（国家统计局，2026-01-19）。

对本产品的意义：大盘稳定增长但已进入个位数增速的存量阶段。这说明增量不在"买得更多"，而在"买得更准" —— 降低试错率、提高单件利用率的工具，其价值主张与当前消费心态是一致的。这比"刺激购买"的叙事更站得住。

4.1.2 生成式 AI 的用户基础（CNNIC）

指标 截至 2025-12 同比
生成式人工智能用户规模 6.02 亿人 +141.7%
生成式 AI 普及率 42.8% +25.2pp
网民规模 11.25 亿人 普及率突破 80%

信源：第 57 次《中国互联网络发展状况统计报告》（中国互联网络信息中心 CNNIC，2026-02-05 发布）。

对本产品的意义：用户教育成本已经不是问题。普及率一年从 17.6% 涨到 42.8%，"和 AI 对话获得建议"已是大众行为而非早期尝鲜。这消除了 Agent 形态的最大不确定性 —— 我们不需要再花力气教用户"可以跟它说话"，可以直接把预算投在建议质量上。

4.1.3 鸿蒙生态：可触达规模的真实口径（华为官方）

⚠️ 这一节需要特别小心，因为公开传播中三个不同量级的数字经常被混用，直接影响目标设定是否成立。

口径 数值（截至 2026-06） 与本产品的关系
鸿蒙生态设备总数（含 IoT、开源鸿蒙、车机、穿戴） 超 13 亿台 ❌ 与本产品无关，绝大多数无法安装手机 App
HarmonyOS 6 终端设备数 6,600 万台 ✅ 这才是本产品的可触达基数
注册开发者 超 1,100 万 生态供给侧活跃度
应用市场可获取应用与服务 超 40 万 竞争密度参考

信源：《HarmonyOS 7 开发者 Beta 正式启动》《星河璀璨，百花齐放：HDC 2026》（华为官方新闻，2026-06-12 / 06-15，HDC 2026）。华为同时表述 HarmonyOS 已成为中国第二大智能手机操作系统。另有第三方监测（Wonder Toolbox）显示 2026-06 底 HarmonyOS 6 装机约 7,010 万台，与官方口径基本吻合。

为什么只能用 6,600 万这个口径：本产品是纯血鸿蒙原生应用（ArkTS / ArkUI，见 TD-01），只能运行在 HarmonyOS NEXT 及以上版本（即 HarmonyOS 5 / 6 / 7），无法运行在兼容安卓的 HarmonyOS 4 及更早版本。13 亿是整个 IoT 生态，与我们的分发无关；把它写进商业计划是常见但严重的误导。

推算（非官方数据，仅为规划口径）：HarmonyOS 5/6/7 合计装机量在本产品上线时点（预计 2027 上半年）按当前增速外推，量级约 1.5~2 亿台。后续所有渗透率与用户目标均以此为分母，见 §8.1。

4.2 竞品对比

产品 优势 劣势 我们的差异化
美图秀秀 用户基数大，技术成熟 主要是工具类，缺少专业美学 专业美学报告 + AI Agent
小红书 社区活跃，内容丰富 试穿能力弱，缺少专业性 实时换装 + 系统性搭配
传统试衣间App 功能专注 用户体验差，功能单一 报告驱动的系统性建议 + AI 穿搭 Agent
品牌自研 深度绑定品牌 封闭生态，用户受限 开放平台 + 跨品牌推荐

4.3 竞争策略

4.3.1 壁垒的真实来源（需要重新校准）

换装/发型接口是可替代的通用能力，竞品同样能接入，因此不构成壁垒。真正可积累、难复制的资产有三项，也是资源投入的重点：

资产 为什么难复制 投入方式
美学知识库（专家规则 + 12 套色板 + 适配矩阵，规模见知识库 §9.1） 需要专业形象顾问长期投入，无法靠大模型生成后直接使用 全职顾问（TD-27）+ 人审流水线
用户画像与记忆资产 数据随使用时长复利增长，用户迁移成本高 报告 + 记忆系统
可试穿素材库（白底单品图 + 属性标注） 需要采集、抠图、标注的重投入，且是"建议→预览"闭环的唯一入口 素材运营流水线

短期可用优势（非壁垒，但决定上市速度）：自有可控的换装/发型推理服务（可改造、可扩容、成本可归因，这比调用第三方接口更有价值）、鸿蒙生态先发。

4.3.2 差异化定位

  • 不仅是试穿：系统性美学指导，而非单一工具
  • 懂你的建议：画像 + 记忆驱动的个性化，而非通用百科答案
  • 建议可预览：结论直接联动换装/试戴，闭环体验
  • 专业可解释：每条建议可追溯到体型/色彩/场景规则
  • 形象档案化：报告版本化 + 前后对比，把一次性内容变成长期资产

4.3.3 快速迭代

  • MVP 优先：以里程碑出口条件衡量进度，不承诺日历周期（见 §6 与《开发任务拆解》）
  • 用户反馈：快速收集用户反馈
  • 数据驱动：基于数据优化产品
  • 小步快跑：持续快速迭代

⚠️ 原「1-2 个月上线 MVP」已删除。本项目的排期原则已改为「不按人日估算，按实测产能倒排」（TD-27、T-P0-20/T-P0-21）—— 关键路径是内容与素材生产，而它的产能必须先测出来才能倒排。在测出产能前给出日历承诺，只会得到一个必然被打破的承诺。

5. 商业模式

5.0 ⚠️ V1 的商业化策略：不收费，只限量

V1 不接入任何支付能力（TD-28、TD-29）。这是明确的产品决策，本章其余内容全部属于 V2 及以后的规划，V1 不实现。

项 V1 V2
支付能力（华为 IAP） ❌ 不接入 ✅ 接入
会员 / 订阅 ❌ 无 ✅ 有
点数购买 ❌ 无 ✅ 有
全面报告付费 ❌ 只做预约留资 ✅ 单次付费
广告 ❌ 不接 待评估
成本控制手段 ✅ 配额限制（免费额度 + 任务奖励额度） 配额 + 付费扩容

为什么这个顺序是对的：定价需要三个前提 —— 真实的单次成本、真实的用户使用频次、真实的付费意愿。这三个数据 V1 之前一个都没有，现在定价只能是猜。V1 用配额把成本锁死在可承受范围，同时把这三个数据采齐，V2 再定价，届时定出来的价格才是有依据的。

这个决策带来的直接简化（已同步到架构与任务拆解）：

  • 无需接入华为 IAP，也就无需应对 30% 平台抽成，TD-16 对 V1 不再适用
  • 无需华为企业开发者资质中与 IAP 结算相关的部分（TD-29）
  • billing 域从「订单 + 支付 + 点数账本 + 对账」降级为「配额账本 + 消耗流水」，去掉了整条支付链路与对账逻辑
  • 无需交易类合规材料（虚拟商品协议、退款政策、发票）
  • 但计量埋点一项都不能省 —— 这是 V2 定价的唯一数据来源，见 NFR-COST-01

V1 的配额设计原则：额度用完时不是"付钱解锁"，而是"明天再来 / 做任务换额度"。文案不出现任何价格与购买字样，避免用户形成"这是个要花钱的产品"的第一印象，反而影响 V2 的定价空间。

5.1 收入来源（V2 起适用，V1 不实现）

⚠️ 以下所有价格均为占位草案，不得作为开发或对外沟通依据。定价必须在 V1 采集到真实成本、频次、意愿数据后重算，并扣除华为 IAP 约 30% 抽成（TD-16、T-P6-16）。

5.1.1 单次付费内容（V2 起的主力）

  • 全面美学报告：单次购买为主力形态，另设「重新生成」低价档
  • 定价的参考锚点（不是结论）：线下形象诊断客单价 300~2000 元，本产品可定位"十分之一价格、八成内容"
  • 为什么以报告为主力：内容型交付物边际成本低、价值感知清晰、不产生持续的 GPU 消耗，比"无限次生成"健康得多。这是从原方案的成本教训中得出的结论
  • 定价前必须做的一步：小范围真实收费灰度（T-P6-03b）—— 预约率无法替代实付验证

5.1.2 会员订阅

  • 分会员版与高级版两档，权益见 §3.3
  • 价格、赠送点数、转化率预期全部待定，需 V1 数据支撑
  • 权益以"额度 + 点数"计量，避免无限供给导致的成本失控（见 §3.1）

5.1.3 点数增值

  • 点数包售卖（规格与价格待定）
  • 激励视频换点数（把重度免费用户的成本转移给广告主）

5.1.4 广告变现

  • 开屏广告：CPM 计费，预计 ¥50/CPM
  • 信息流广告：CPC 计费，预计 ¥2/CPC
  • 激励视频：换取点数/额度，兼顾体验与收益
  • 品牌合作：原生广告 / 联名色板 / 品牌单品进入素材库，预计 ¥10-20 万/次

5.1.5 后续收入（V3+）

电商导购分成、B 端 API 输出（服装品牌/线下门店/形象顾问工具）、线上形象顾问 1v1 服务撮合

5.2 成本结构

5.2.1 技术成本（含单位经济模型）

必须先算清单用户成本，再定价。V1 的核心任务之一就是采集真实成本数据：

成本项 单次成本目标 说明
换装生成 ≤ ¥0.50 GPU 长耗时推理，成本主导项
发型/发色生成 ≤ ¥0.20 —
初级美学报告 ≤ ¥0.30 视觉分析 + LLM 生成
全面美学报告 ≤ ¥2.00 章节多、输出 token 大
Agent 单轮对话 ≤ ¥0.05 含 RAG 检索
高清导出 ≤ ¥0.02 服务端渲染

单用户月度成本必须分三档说清，不能只给一个数（此前只写「≤ ¥8」，既算不出来也误导了成本封顶的论证）：

档位 口径 单用户月成本 用途
① 物理上限 防刷硬上限天天打满（8 换装 + 6 发型 + 40 对话 + 2 报告重生成 + 3 导出 = ¥7.86/日） ≈ ¥236 单用户成本的绝对天花板，任何用户都不可能超过
② 重度用户 基础额度 + 任务奖励天天用满（6 + 5 + 20 = ¥5.0/日） ≈ ¥150 极少数深度用户的实际量级
③ 人均预期 由 §8.2.2 用量推算 ÷ MAU 反算 ≈ ¥0.8 预算口径，含使用率假设，见 §5.3.1

①②③ 相差两个数量级不是矛盾，而是「配额上限」与「实际使用率」的差别 —— 绝大多数用户远远用不满额度。做预算必须用 ③，谈风险必须看 ①。

成本控制手段：端侧预检拦截无效请求、结构化结论走规则引擎不走 LLM、LLM 固定前缀设计以最大化 Prompt 缓存命中（输入成本可降至 1/5~1/30）、相同参数结果缓存、模板化减少输出 token、分级画质、免费用户错峰排队、GPU 实例按需启停。

成本核算的架构前提：所有付费调用必须落 ob_ai_call 表并可归因到功能与用户，否则用户量上来后无法定位成本来源。详见《技术架构文档》§13 成本模型与 NFR-COST-01。

5.2.1.1 平台抽成（V1 不适用，V2 定价时必须计入）

V1 不接入支付，因此本节对 V1 不产生任何影响。但 V2 定价时这是绕不过的前提，先记录在此：

虚拟商品（会员、点数、全面报告）在鸿蒙上必须走华为 IAP，且需签署《华为数字商品及联运服务协议》。Payment Kit 明确不支持虚拟商品，无法绕开。

  • 平台抽成量级约为交易额的 30%（部分公开资料给出「10% 基础技术服务费 + 30% 联运分成」的更高口径）。
  • 影响：定价 ¥39 的全面报告实际到账约 ¥27 或更低。
  • §5.1 与 §5.3 的全部收入数字均为交易额口径、未扣抽成。V2 定价前需按到账口径重算（TD-16）。
  • ⚠️ 时效性：抽成比例与协议条款需在 V2 启动时向华为重新确认，不要沿用本文数字。

5.2.2 其他技术成本

  • 云计算：服务器/数据库/向量库/对象存储/CDN
  • 知识库建设：顾问费 + 素材采集与抠图 + 标注（一次性 12~18 万元，见知识库方案 §9）
  • 技术维护：开发/测试/运维

5.2.3 运营成本

  • 内容运营：穿搭内容/教程/UGC
  • 用户增长：推广/营销/活动
  • 客服支持：在线客服/电话客服
  • 数据分析：数据分析师/BI工具

5.2.4 营销成本

  • 用户获客：广告投放/KOL合作
  • 品牌推广：品牌广告/公关活动
  • 线下活动：快闪店/时尚活动

5.3 财务预期

5.3.1 V1：不做收入预测，只做成本封顶

V1 收入恒为 ¥0，因此不存在盈利预测。V1 阶段的财务管理目标只有一条：把成本压在可承受区间，同时把 V2 定价所需的数据采齐。

项 V1 目标 说明
月度 AI 总成本（MAU 15 万口径） ¥7~12 万/月（预期，含假设） 由 §8.2.2 用量推算 × §5.2.1 单次成本得出，不是硬上限
单用户月度 AI 成本（人均） ≈ ¥0.8 §5.2.1 档位③；物理上限为 ¥236，见该表
日成本熔断阈值 ¥5,000/日 这才是真正的成本封顶机制，见下方
知识库一次性建设投入 ¥12~18 万 含全职顾问、素材自采、抠图标注
必须采齐的数据 单次真实成本 / 人均使用频次 / 预约率 这是 V1 唯一的"商业产出"

¥7~12 万是怎么来的（可复算）：报告 35 万份 × ¥0.3 + 试穿 812 万次 × ¥0.5 + 发型 46 万次 × ¥0.2 + 对话 3050 万轮 × ¥0.05 = ¥7.2~11.2 万/月。

它隐含一条必须写明的假设：人均每月约 1 次试穿 + 几轮对话。这与本产品「低频决策型工具」的定位一致（也正是 §8.1.1 用季度回访率而非 DAU 考核的原因），但它是假设，不是保证 —— V1 上线后由 ob_ai_call 实测校准，这是 T-P1-25 计量埋点不可裁剪的直接原因。

⚠️ 此处原有一个错误论证，已更正：原文称「月度成本上限 = MAU × 单用户配额成本上限，是可以事前算准的确定值」。这个推理不成立，有两个漏洞： ① 数字算不平 —— 15 万 × ¥8 = ¥120 万，与 ¥12 万差 10 倍； ② 更根本的是，按人头发配额封不住总成本。配额约束的是「单个用户能用多少」，而总成本 = MAU × 人均，MAU 没有上限。用户涨到 50 万、或人均使用强度超出假设 5 倍，成本都会线性上涨且没有任何天花板。配额防的是"单个用户刷爆"，防不了"总量涨爆"。

真正让成本封顶的是全局日成本熔断（NFR-COST-02，V1 必须实现）：平台当日累计 AI 成本触及阈值时，系统自动降级而非仅告警 —— 依次关闭非核心 AI 能力（先停高清导出与报告重生成 → 再停发型 → 最后只保留已付出成本的在途任务），并向用户展示「今日服务繁忙，请明天再试」。这是唯一与用户规模无关的硬闸门，也是"不收费"模式下唯一可靠的止损手段。

"不收费"确实带来一个真实的成本好处，但不是"上限可算准"：不收费就没有"付费用户应该无限用"的预期压力，因此配额可以设得紧、熔断可以设得狠，不必担心因限流而损害已付费用户的权益。这在 V2 收费后会变成一个真实的两难。

5.3.2 V2 起的盈利预测

⚠️ 原第一年季度预测（Q1~Q4，净利润 -25 万 → +120 万）已整体废弃，四项假设全部不再成立： ① 基于"无限次会员"模型，与现行配额制不符； ② 未计入 GPU 成本随活跃度线性增长； ③ 未扣除华为 IAP 约 30% 抽成； ④ 用户规模假设（200 万注册 / DAU 30 万）已按 §8.1.1 下调至 50 万 / MAU 15 万。

重做财务模型的前提是 V1 的真实数据，因此在 V1 上线并运行满一个完整周期前，不产出新的盈利预测 —— 现在做只是把猜测写得更精确。对应任务 T-P6-16，需校准四项假设：单用户月度生成次数、换装单次真实成本、报告付费转化率、抽成后到账比例。

6. 实施计划

详细任务拆解、依赖关系与验收条件见《开发任务拆解》，本章只给阶段目标与范围。

6.0 Phase 0：前置验证（备案已完成，本阶段已大幅瘦身）

本阶段几乎不产出代码，但决定项目能否成立。以下三条并行：

① ✅ 备案登记 —— 已完成（关键路径已解除）

备案已办结，原本 2~4 个月的外部审批周期不再构成上线瓶颈。这是本轮最重要的进展：项目从「先等审批、再谈开发节奏」变成「开发进度就是上线进度」，Phase 0 的关键路径从外部审批转移到内部技术验证。

但备案完成 ≠ 合规完成，以下四项转为持续义务，仍需在开发中落地（详见《合规与安全方案》§2.2、TD-19）：

事项 要求 为什么不能省
编号界面公示 在 App 显著位置（关于页 / 设置页）公示模型名称与备案编号 浙江、江苏、安徽、陕西等地明确要求界面显著位置公示；应用市场上架时会核验
备案范围与实际调用一致 实际调用的模型清单（DeepSeek + GLM 双路由）必须与备案登记的一致 ⚠️ 最需要注意的一条：若备案时只登记了单一模型，上线双路由即属超范围，需先办变更
实质变更后 30 个工作日内办变更 新增模型、变更服务功能或算法机制时触发 逾期属违规
上架材料留档 备案编号、AI 标识说明、安全自评估报告 应用市场核验

⚠️ 需要你确认一件事：备案时登记的模型清单是否已包含 DeepSeek 与智谱 GLM 两家？如果只登记了一家，双路由方案需先办变更备案，或 V1 先只用已登记的那一家（架构上 LLM 网关已做多路由抽象，切换成本很低）。这是目前唯一可能影响 V1 上线的合规不确定项。

② 关键技术验证（现在是 Phase 0 的真正关键路径）

备案完成后，以下验证成为决定后续方案的唯一前置，不能带着不确定性进入开发：

验证项 验收标准 编号
体型测算方案（人像分割掩膜宽度剖面 + 关键点定高） 30~50 样本与人工标注一致率 ≥ 80% T-P0-10
色彩季型判定（Lab 采样 + 规则） 与人工判定一致率 ≥ 75% T-P0-11
抠图流水线（BiRefNet） 10 件样本走通全流程，质检通过 ≥ 90% T-P0-12
换装接口能力与单次真实成本实测 得到 gpu_seconds 与成功率基线，填入成本模型 T-P0-13
AI 标识元数据全链路存活 经水印/COS/CDN/客户端保存后元数据仍存在 T-P0-18
鸿蒙端骨架（ArkTS） 打通登录、拍照、直传、任务轮询、结果展示 T-P0-17

⚠️ 一个已经发生的选型变更：腾讯云的人体检测与人体关键点接口（DetectBody/DetectBodyJoints）已于 2025-10-30 下线，原「体型关键点走第三方 API」的路径不再存在。现方案为人脸走腾讯云、人体关键点自建（RTMPose ONNX）。详见 TD-05。

③ 数据与内容准备（备案解除后，这里成为新的最长工序）

备案不再是瓶颈，内容与素材生产就成了实际的关键路径 —— 它是唯一无法靠 AI 辅助开发加速的部分。

  • 全职形象顾问入场（已定：全职编制，TD-27）—— 到岗即开始本体 Schema 评审与规则库撰写
  • 知识库本体 Schema 与属性字典定稿
  • 60 款发型适配标签打标（脸型/量感/直曲/长度/卷度/刘海/正式度）
  • 单品素材自采启动（已定：自采模式，TD-26）—— 采购、拍摄、抠图、标注流水线搭建，详见《美学知识库-建设方案》§4.2.1
  • 目标用户访谈（验证全面报告付费意愿与心理价位，为 V2 定价储备依据）

Phase 0 出口条件（已按备案完成调整）：六项技术验证有明确结论；本体 Schema 与发型打标完成；全职顾问到岗且规则库产出节奏可测算；自采流水线跑通首批 20 件单品；备案编号公示位已在端上预留。

6.1 Phase 1 = V1：MVP

周期以出口条件衡量，不设日历周期（原「1-2 个月」已删除，理由见 §4.3.3）。里程碑与依赖关系见《开发任务拆解》§1。

6.1.1 目标

  • 验证市场需求
  • 验证技术可行性
  • 积累初始用户
  • 收集用户反馈

6.1.2 任务清单

  • 技术准备

    • 鸿蒙 ArkTS 工程搭建（签名、权限、AGC 配置、SHA256 双证书指纹）
    • 服务端骨架与 CI（FastAPI + 依赖规则检查 + 静态检查）
    • 工程地基：统一任务中心、统一合规出口、LLM 网关、配额预扣三段式（详见 T-P1-19~T-P1-28，这些被所有业务功能依赖，必须先于业务功能完成）
    • 鸿蒙环境配置与打包流程
    • 集成换装接口（/change_cloth_base64）
    • 集成发型接口（/hair/api/*）
    • 接口超时与异常处理（换装 320s / 发型 120s）

  • 功能开发

    • 换装试穿功能（单图/上衣/上衣+裤子）
    • 发型列表浏览与更换
    • 发色调整功能
    • 用户系统（华为账号 / 手机号 / 游客模式 + 注册后数据迁移）
    • 隐私授权流程（人脸信息单独授权 + 授权记录）
    • 历史记录与收藏

  • 美学报告（初级）

    • 引导流程（价值前置页 → 授权 → 问卷 → 拍照）
    • 端侧照片质量预检（人像/单人/全身/清晰度/光线）
    • 视觉分析能力选型与接入（体型/面部/肤色采样）
    • 规则引擎 + 报告生成链路 + 一致性校验
    • 报告页面、术语词典、数据修正
    • 形象档案与版本对比
    • 分享长图（默认结论版，不含照片）
    • 全面报告预约入口 + 埋点（付费意愿验证）

  • 记忆系统

    • L0~L4 数据模型与 MemoryService
    • 报告结论写入 L1
    • 显式偏好写入 + 回执确认
    • 画像摘要生成与注入（token 预算控制）
    • 「我的记忆」管理页 + 关闭个性化开关

  • 知识库 V1

    • 本体 Schema 与属性字典定义
    • 专家规则 400 条（体型/色彩/场景/风格）
    • 12 套季型色板 + 400 色色值库
    • 60 款发型适配标签打标（当前最大数据缺口）
    • 单品素材 300 件（含白底试穿图）+ 抠图流水线
    • 搭配方案 100 套（含试穿素材绑定）
    • 混合检索链路（硬过滤 + 向量召回 + 重排）
    • 黄金评测集 330 例，分四个子集（检索 100 / Agent 问答 100 / 诊断 100 / 报告结构 30，见知识库 §7）+ 回归测试脚本

  • Agent 基础能力

    • 大模型选型与对接、流式输出
    • 意图识别 + 画像注入
    • 快捷问题入口、对话历史

  • 体验与治理

    • 任务中心（异步任务 + 完成推送 + 失败重试）
    • 生成过程步骤可视化 + 已等待秒数
    • 图片上传前压缩处理
    • 结果图保存与分享（水印 + AI 生成标识）
    • 配额中心 + ob_ai_call 成本计量 + bl_ledger 配额流水
    • 内容安全与敏感词过滤（含外貌负面表述红线）

  • 测试上线

    • 内部测试 + 黄金集准确率验收
    • 小范围灰度发布
    • 收集用户反馈
    • 鸿蒙应用上架（Beta 版）

6.1.3 交付物

  • MVP 版本鸿蒙应用
  • 初级美学报告与形象档案能力
  • 知识库 V1 + 60 款发型标签 + 300 件可试穿素材
  • 用户反馈报告、技术验证报告
  • 单用户成本报告与付费意愿验证结论（V2 定价依据）

6.2 Phase 2 = V2：核心功能完善与商业化

本阶段即 V2。所有付费能力都在这里，不属于 V1 范围（TD-28）。

6.2.1 目标

  • 完善核心功能
  • 提升用户体验
  • 首次引入商业化（V1 收入为 0）
  • 扩大用户规模

6.2.2 任务清单

  • 全面美学报告（付费）

    • 六大篇章内容生成（风格诊断/色彩/身材/配饰/发型专项/场景包）
    • 十二季细分色彩算法与专业校准
    • 30 天形象提升计划 + 打卡
    • PDF 导出与长图排版
    • [ ] 五行幸运色模块 —— 已决定不做（TD-31），见 §7.3.4

  • 会员与支付体系（V1 完全不做，本阶段从零建设）

    • 华为企业开发者认证 + 数字商品联运协议签署（TD-29）
    • 华为 IAP 接入（商品配置、服务端收据校验、purchase_token 防重、掉单补发）
    • 配额账本扩展为点数账本（增加 purchase/gift 两种 tx_type，无需数据迁移）
    • 会员权益管理与订单/退款/对账
    • 小范围真实收费灰度（验证预约率到实付的衰减，T-P6-03b）
    • 基于 V1 真实数据的定价落地（前提：单次成本、人均频次、预约率、抽成后到账口径四项齐备，T-P6-16）
    • 华为账号一键登录（企业资质就位后补，FR-ACC-13）

  • 记忆系统进阶

    • 隐式行为推断 + 待确认机制
    • 置信度衰减与冲突消解
    • L3 事件向量召回
    • 主动推荐（天气/日程驱动）

  • 我的衣橱（L5）

    • 单品拍照入库 + 自动抠图 + 属性识别
    • 一衣多搭、衣橱体检、缺口建议

  • 知识库扩充

    • 知识库规模由 V1 硬指标扩充至长期目标（规则 8001200 条 / 方案 300500 套 / 单品 800~1500 件，见知识库 §9.1）
    • 知识库管理后台（增删改查 + 审核工作流 + 版本对比 + 效果看板）
    • 知识缺口周报机制
    • 图谱层与「为什么推荐」解释链

  • Agent 增强

    • 语音输入、多轮上下文记忆
    • 联动换装/发型的完整闭环
    • 图片输入理解（穿搭评价）

  • 体验优化

    • UI/UX 优化、性能与稳定性优化
    • A/B 实验平台与埋点规范
    • 用户反馈与知识修正闭环

  • 正式上线

    • 正式版上线、市场推广、用户增长、数据分析

6.2.3 交付物

  • 正式版鸿蒙应用
  • 付费全面报告 + 完整会员与点数体系（本产品的首笔收入发生在这里）
  • 我的衣橱 V1
  • 知识库管理后台完整版
  • 基于真实数据重做的财务模型与定价（替代 §5.3.2 中已废弃的季度预测）

6.3 Phase 3：多端扩展

6.3.1 目标

  • 扩展多端（iOS / Android），届时重新评估跨端方案（保留鸿蒙原生另起跨端工程 / Uni-App-x / Flutter），判断依据是那时的鸿蒙生态成熟度与团队构成（TD-01、T-P6-15）
  • 拓展用户触达渠道
  • 完善生态系统

6.3.2 任务清单

  • 多端发布

    • Android 版本发布
    • iOS 版本发布
    • 小程序版本发布
    • H5 版本发布

  • 功能扩展

    • 化妆指导功能（接口确认后）
    • 更多场景模板
    • 社区/UGC 功能

  • 运营优化

    • 内容运营体系
    • 用户运营体系
    • 数据分析体系
    • 客服支持体系

6.3.3 交付物

  • 多端应用版本
  • 完整运营体系

6.4 Phase 4：规模化（持续）

6.4.1 目标

  • 规模化用户增长
  • 国际化扩展
  • 持续技术创新
  • 建立行业影响力

6.4.2 任务清单

  • 用户增长

    • 品牌营销
    • 社区运营
    • KOL 合作

  • 国际化

    • 多语言支持
    • 本地化运营
    • 海外市场拓展

  • 技术创新

    • AI 模型优化
    • 新功能探索
    • 技术专利申请

7. 风险与应对

7.1 技术风险

7.1.1 API 稳定性

  • 风险描述：换装/发型接口可能不稳定或超时
  • 应对措施：
    • 换装接口设置 ≥ 320s 超时，发型接口设置 ≥ 120s 超时
    • 前端展示已等待秒数，避免误以为卡死
    • 发型接口失败时使用原图降级处理
    • 监控 /health 接口可用性
    • 建立容错机制和重试策略

7.1.2 性能瓶颈

  • 风险描述：高并发情况下性能可能不足
  • 应对措施：
    • 缓存优化（发型列表等静态数据）
    • 请求队列管理
    • 错峰处理提示
    • 性能监控

7.1.3 隐私安全（人脸属敏感个人信息，最高优先级）

  • 风险描述：用户照片数据可能泄露或滥用；人脸信息处理不合规将面临监管处罚与下架风险
  • 应对措施：
    • 人脸信息单独授权，不可默认勾选，可单独撤回
    • 原始照片处理完即显式删除，临时桶生命周期 ≤ 2 小时兜底，只保留派生特征与结论（唯一事实源：CR-02 与《合规与安全方案》§2.1.2）
      • ⚠️ 原文写「保留 ≤24h 仅用于任务重试」已废弃，与本文 §7.3.4、CR-02 冲突。2 小时已足够覆盖重试窗口（最长任务 320s，重试上限 3 次），24h 只是白担合规风险 —— 保留期越长，"存储的人脸信息数量"越可能被认定为非零，进而触发 10 万人备案义务
    • 明确承诺照片不用于模型训练，并写入隐私政策
    • 数据加密传输与存储，OSS 签名链接短时效
    • 分享长图默认"结论版"（不含照片），降低泄露面
    • 支持数据导出、清空照片、注销彻底删除
    • 疑似未成年人拒绝生成；第三方数据处理方在隐私政策中列明
    • 定期合规审计

7.1.4 客户端技术风险（原「Uni-App-x 跨平台风险」，已随选型变更改写）

  • 风险描述：V1 改为鸿蒙原生 ArkTS 后，跨端框架的兼容性风险消除，但引入两个新风险：① 团队 ArkTS 经验不足；② V2 多端时需要额外投入。
  • 应对措施：
    • Phase 0 的第一个技术任务就打通端到端骨架（登录、拍照、直传、任务轮询、结果展示），把主要坑一次性踩完（T-P0-17）
    • ArkTS 是 TypeScript 超集、ArkUI 为声明式写法，与 Vue/React 心智模型接近，学习曲线可控
    • 服务端保持端无关（标准 REST + SSE + OpenAPI 生成客户端类型），多端时服务端零改动
    • 鸿蒙证书与权限体系较复杂（调试/发布双证书、指纹生效最迟 25 小时），需写入发布手册避免临上线踩坑

7.1.4.1 云厂商能力下线风险（本轮调研中已实际发生一次）

  • 风险描述：腾讯云的人体检测与人体关键点接口（DetectBody/DetectBodyJoints）已于 2025-10-30 下线，原「体型关键点走第三方 API」的方案失效。
  • 应对措施：
    • 核心能力（人体关键点、抠图）自建，不把产品核心资产押在单一云 API 的存续上（TD-05/TD-07）
    • 对仍在使用的云能力（人脸属性与关键点、人像分割、内容审核）保留替换预案，并在选型文档中标注 ⚠️ 时效性，开发启动前复核一次
    • 开源模型使用前必须核对商用许可 —— 本轮就发现被引用最多的抠图模型 RMBG-2.0 实为 CC BY-NC 4.0 非商用许可（TD-07）

7.1.5 知识库与素材缺口（第一版最大隐性风险）

  • 风险描述：两项数据缺口会直接导致核心功能"看起来做完了但不可用"——
    • 现有 60 款发型只有 id/name/image_url，没有适配标签，"按脸型推荐发型"无法实现
    • 没有白底单品图素材，换装接口无图可传，"AI 建议 → 一键试穿"闭环断裂，用户只能自己找图
  • 应对措施：
    • 将发型打标（1~2 人日）与素材抠图流水线列为 Phase 0/1 前置任务，不可延后
    • V1 至少产出 300 件 tryon_ready 单品，未达标则功能降级为"加入搭配"而非"一键试穿"
    • 单品标注 tryon_slot（换装接口只支持上衣与裤子，连衣裙/鞋/包/配饰不支持），产品端据此控制按钮展示
    • 素材已定为自采模式（TD-26）：优点是版权干净、规格统一、可控；代价是这成了备案解除后的新关键路径，需按每周产能倒排（详见《美学知识库-建设方案》§4.2.1）
    • 素材版权：只用自采实拍图，禁止抓取电商与社交平台图片；保留采购凭证与拍摄原始文件，建立 license 字段与审核环节

7.1.6 AI 生成质量与幻觉

  • 风险描述：大模型可能给出违反美学规则或用户禁忌的建议（如给柔夏型推荐正红色、给明确拒绝短裙的用户推荐短裙），一次错误就会摧毁"专业"信任
  • 应对措施：
    • 核心结论由规则引擎产出，LLM 只负责组织语言，不允许自由发挥
    • 检索链路先做硬过滤（画像约束 + 禁忌项 + 色板范围），再做向量召回
    • 生成后一致性校验：禁忌项违反率必须为 0（红线）
    • 200 条黄金评测集回归测试，知识准确率 ≥95% 才允许发布

7.1.7 生成成本失控

  • 风险描述：换装/报告为 GPU 长耗时推理，重度用户与刷量行为可能造成成本远超收入
  • 应对措施：
    • 配额中心统一管控 + ob_ai_call 逐次记账（成本）+ bl_ledger 逐次记账（额度）
    • 端侧预检拦截无效请求（不合格照片不进队列、不计额度）
    • 结构化结论走规则引擎而非 LLM；相同参数结果缓存
    • 设备/账号/IP 三重限流，异常账号冻结
    • V1 因不收费而不存在"付费用户应无限用"的压力，配额即硬上限，月度成本可事前算准（见 §5.3.1）；V2 引入付费后此风险重新升级，需在定价时用 V1 的真实成本数据校准

7.2 市场风险

7.2.1 用户接受度

  • 风险描述：用户可能不接受虚拟试穿的效果，或不信任 AI 给出的形象诊断结论
  • 应对措施：
    • AI 使用门槛已不是问题：生成式 AI 普及率 2025 年底已达 42.8%、用户 6.02 亿（§4.1.2），无需再做基础用户教育，应把力气全部投在建议质量上
    • 真正的接受度风险在换装效果的观感：接口只支持上衣与裤子，效果不及预期时用户会直接判定"不准"。对策是产品端主动管理预期（明示适用范围、提供合格照片引导），而不是让用户自己发现限制
    • 以 报告结论认同率 > 70%（§8.1.2）作为诊断可信度的度量，低于阈值即回查规则库而非调整文案
    • 用户反馈机制 + A/B 测试

7.2.2 竞争激烈

  • 风险描述：市场竞争激烈，可能被超越。鸿蒙应用市场可获取应用与服务已超 40 万（§4.1.3），"生态先发"的窗口比预想的窄
  • 应对措施：
    • 差异化定位（§4.3.2），不与工具类产品比功能数量
    • 把资源集中在三项真实壁垒上（知识库、画像记忆、可试穿素材库，见 §4.3.1），而非追加功能
    • 素材自采与全职顾问都是慢变量投入，竞品即使决定跟进也需要同等时间，这是"先发"真正能兑现的地方

7.2.3 商业模式验证（V1 主动延后，风险性质已改变）

  • 风险描述：商业模式可能无法盈利。V1 不收费，因此这个风险在 V1 阶段不会暴露，也不会被证伪 —— 这是本项目最需要警惕的一点：不收费意味着看不到真实付费意愿，只能靠预约率这一个代理指标。
  • 应对措施：
    • 预约率 8% 是唯一的决策门槛（§8.1.3）。低于此值不应硬上付费报告，而应先回查报告质量与认同率
    • 承认代理指标的局限：预约≠付费，行业经验中留资到实付的衰减通常很大。因此 V2 定价前应补一次小范围真实收费灰度（哪怕只对少量用户开放），而不是直接全量定价
    • V1 必须把三类数据采齐（单次真实成本、人均使用频次、预约率），否则 V2 定价依然是猜（§3.4）
    • 大盘处于个位数增速的存量阶段（§4.1.1），"买得更准"的价值主张比"刺激购买"更成立，定价叙事应围绕降低试错成本而非增加消费

7.3 政策风险

完整的法规清单、义务解读、落地要求与上线检查清单见《合规与安全方案》。以下为风险摘要。

7.3.0 ✅ 备案登记风险 —— 已解除（原为最高级别风险）

  • 原风险描述：需办理大模型登记 + 算法备案，属地网信办审批周期 2~4 个月，若等开发完成才启动会卡在上架环节数月。
  • 当前状态：备案已完成，此风险关闭。项目关键路径从外部审批转移到内部的内容生产与技术验证。
  • 残留风险（需持续管理，不可视为已完结）：
    • ⚠️ 备案范围与实际调用不一致 —— 若备案登记的模型清单未覆盖 DeepSeek + GLM 双路由，上线即属超范围。这是目前唯一可能影响 V1 上线的合规不确定项，需在 Phase 0 内核实。缓解手段：LLM 网关已做多路由抽象，必要时 V1 先只启用已登记的模型，切换成本很低
    • 实质变更未及时办理变更备案 —— 新增模型、变更服务功能或算法机制均触发，须在 30 个工作日内办理
    • 编号未在界面显著位置公示 —— 多地明确要求，应用市场上架核验项
    • 直接使用 DeepSeek / 智谱官方 API，不走云平台 MaaS 中转 —— 部分应用商店要求提供「应用主体与算法技术主体的合作协议」，云厂商无法代第三方模型厂商出具并盖章。此约束不因备案完成而失效
    • 长周期材料需持续维护：安全自评估报告、拦截关键词库、评估测试题集

7.3.1 数据合规

  • 风险描述：可能违反《个人信息保护法》与《人脸识别技术应用安全管理办法》（2025-06-01 施行）
  • 应对措施：
    • 人脸信息按敏感个人信息处理，独立的单独同意页，不得混入总协议
    • 架构层面规避备案阈值：人脸原图不落盘（临时桶 ≤ 2 小时 + 处理后显式删除），只保留派生的结构化特征，使「存储的人脸信息数量」恒为 0，不触发「达 10 万人须向省级以上网信部门备案」的义务
    • 禁止存储人脸特征向量与 888 点稠密关键点原始坐标（精度足以重建轮廓，属生物识别信息）
    • 完成个人信息保护影响评估（PIA），建立第三方处理者清单并在隐私政策中披露
    • 用户知情同意 + 可撤回 + 可删除；注销后 7 日内彻底删除

7.3.2 AI 生成内容合规

  • 风险描述：违反《人工智能生成合成内容标识办法》（2025-09-01 施行）+ GB 45438-2025、《生成式人工智能服务管理暂行办法》、《互联网信息服务深度合成管理规定》
  • 应对措施：
    • 双重标识：显式标识（画面内可见「AI 生成」、会话界面固定提示）+ 隐式标识（文件元数据含生成属性、服务提供者编码、27 位内容编号）
    • 统一合规出口：所有生成物必须经过同一个模块才能对外发布（审核 + 水印 + 元数据 + 编号登记）。不要让每个业务模块各自实现，一定会漏
    • ⚠️ 最易踩的坑：元数据在 CDN 图片处理、客户端保存相册、二次加水印等环节会被静默剥离。需专项自动化测试覆盖全路径（T-P0-18）；也正因如此，显式水印必须在画面内，不能只做界面提示
    • 生成记录与审核日志留存 ≥ 6 个月
    • V1 不提供「去除显式标识」功能（办法允许用户申请，但需签协议并留存日志 ≥ 6 个月，额外增加义务）
    • 保留免责声明："AI 计算可能存在误差，结论仅供参考"
    • 换装能力限制为仅本人照片，禁止上传他人照片（防换脸滥用），V2 增加人脸一致性校验
    • 未成年人保护：疑似未成年拒绝生成

7.3.3 内容审核

  • 风险描述：用户生成内容可能违规
  • 应对措施：
    • 腾讯云天御 IMS（图片）+ TMS（文本），机器审核 + 人工复核双层机制
    • 审核对象六类全覆盖：用户上传照片、生成结果图、用户对话输入、模型输出、报告文案与长图、运营录入的知识内容
    • fail-close 原则：审核服务不可用时一律按「拦截」处理（与其他外部依赖的 fail-soft 策略相反）。漏审一条违规内容的代价远高于短时功能不可用
    • 用户举报与违规处理机制
    • 外貌评价文案红线：禁止"腿粗""脸大"等负面表述，统一改为中性描述 + 修饰策略，敏感词表在生成后校验环节强制过滤
    • 报告不得包含医疗、减肥、整形类建议

7.3.4 ✅ 命理内容审核风险 —— 已通过「不做」规避

  • 原风险描述：五行/幸运色模块在部分应用市场审核中属敏感内容，可能影响整体上架。
  • 决策：该模块 V1 与 V2 均不纳入（TD-31）。风险从"需要用娱乐声明 + 服务端开关来缓解"变成"根本不存在"。
  • 为什么直接砍掉比保留更好：这个模块的收益是边缘的（它不影响诊断准确性，也不是用户来的理由），但风险是全局的 —— 一个模块可能拖累整个应用的上架。用一个可关闭的开关来管理它，意味着仍要为它准备合规材料、敏感词策略与审核话术，长期维护成本大于它带来的价值。
  • 连带清理：诊断维度从 34 项减为 32 项（删除「五行分布」「幸运色」），报告篇章结构不受影响。生日字段仍保留，用于生日权益与年龄段判断，不再用于命理推算。
  • 保留的边界要求：对话中出现命理类提问时正确拒答（CR-12），这属于越界拒答范畴，与是否做该模块无关。

8. 成功指标

8.1 用户指标

8.1.1 规模指标（已按鸿蒙可触达基数重设）

⚠️ 原目标（DAU 30 万 / MAU 100 万 / 注册 200 万）已废弃，原因有两条，都是硬伤： ① 分母错了 —— 纯血鸿蒙原生应用只能装在 HarmonyOS NEXT+ 设备上，可触达基数是千万到两亿量级（§4.1.3），不是 13 亿； ② 粘性假设错了 —— 原目标隐含 DAU/MAU = 30%，那是社交与短视频的量级。形象诊断是低频决策型工具：用户做完报告可能两三周不打开，但换季、面试、约会时会回来。用日活考核这类产品会逼着团队做无意义的签到打卡，反而破坏产品。

第一年目标改为三档，并以月活与回访为主考核指标，不考核日活：

指标 保守 目标 挑战 说明
注册用户 20 万 50 万 100 万 对应可触达设备渗透率约 0.1% / 0.3% / 0.5%
MAU 6 万 15 万 30 万 MAU/注册 ≈ 30%，符合工具类首年水平
季度回访率（90 天内至少回访 1 次） 25% 35% 45% 替代 DAU 作为核心粘性指标
DAU（仅监测，不作考核） — 2 万 — 参考值，DAU/MAU 预期落在 12~15%

为什么把"季度回访率"放在核心位置：本产品的价值主张是"形象档案随时间复利增长"。能验证这一点的不是用户今天有没有打开，而是换季/重要场合时会不会想起我们。这个指标同时反映了报告的长期价值与记忆系统是否真的让二次体验更好。

8.1.2 质量指标

  • 留存率：次日 >35%，7 日 >18%，30 日 >10%（较原目标下调，对齐低频工具的合理区间）
  • 报告首次阅读时长：>4 分钟 —— 比"日均使用时长"更能反映内容质量，是核心质量信号
  • 日均使用时长：>5 分钟（仅监测）
  • 满意度：>4.5/5
  • 报告结论认同率（用户主动确认"说得准"）：>70% —— 诊断可信度的直接度量

8.1.3 转化指标

V1 无任何付费能力（TD-28），因此 V1 只考核意愿类指标；下表付费指标自 V2 起考核。

指标 目标 何时考核
全面报告预约率 > 8% V1（唯一的商业化验证指标，决定 V2 是否开发付费报告）
会员转化率 > 3% V2
全面报告付费转化率（曝光→购买） > 3% V2
整体付费率 > 5% V2

8.1.4 报告与个性化指标（第一版核心）

报告与记忆系统是第一版的验证重点，指标单列：

指标 目标 意义
报告完成率（生成成功 / 新用户） > 40% 画像覆盖度，决定所有个性化能力的上限
人脸授权通过率 > 60% 合规前提下的转化能力
照片合格率（通过预检 / 上传） > 75% 引导与预检质量，直接影响成本
报告 → 试穿转化率 > 35% "建议 → 预览"闭环是否成立
报告 → Agent 转化率 > 20% 报告是否有效导流对话
报告分享率 > 15% 增长杠杆
全面报告预约率 > 8% V2 是否开发付费报告的决策门槛
画像完备率（L1 关键 8 项） > 70% 记忆系统地基
人均记忆条数（L2） > 8 条 个性化学习深度
结论修正率 < 15% 诊断准确性反向指标
Agent 重复询问率 < 3% 记忆注入是否真正生效
有画像 vs 无画像用户的建议采纳率差值 > 15pp 验证记忆系统的真实价值
有报告 vs 无报告用户次日留存差值 > 15pp 验证报告的留存价值
关闭个性化推荐比例 < 5% 信任度反向指标

8.2 业务指标

8.2.1 收入指标

V1 收入 = 0，这是主动选择，不是缺陷（TD-28）。V1 不接入支付、不设购买入口，通过配额限制控制成本。因此 V1 阶段唯一的商业指标是"预约率 > 8%"，其余收入指标自 V2 起适用，且需按届时的真实成本数据重算（T-P6-16）。

指标 目标 何时考核
V1 总收入 ¥0（预期值，非失败） V1
ARPU 待 V2 定价后设定 V2
会员收入 / 广告收入 待重做财务模型 V2

8.2.2 运营指标

原「第一年」口径已随 §8.1.1 规模指标下调，按 MAU 15 万的目标档重新推算：

指标 推算值（MAU 15 万口径） 用途
美学报告生成量 3~5 万份/月 画像覆盖与报告成本主项
试穿次数 8~12 万次/月 GPU 成本的最大驱动因子，需与配额策略联动监控
发型设计次数 4~6 万次/月 —
Agent 对话轮次 30~50 万轮/月 LLM 成本主项

8.2.3 成本指标（新增，与收入指标同等重要）

  • 单次成本：换装 ≤ ¥0.50 / 发型 ≤ ¥0.20 / 初级报告 ≤ ¥0.30 / 全面报告 ≤ ¥2.00 / 对话 ≤ ¥0.05（单一事实源：§5.2.1）
  • 人均月度 AI 成本：≈ ¥0.8（预期值，上线后按 ob_ai_call 实测校准；三档口径见 §5.2.1）
  • 日成本：≤ ¥4,000/日为健康区间，触及 ¥5,000/日自动熔断降级（NFR-COST-02）
  • 无效调用率（被预检拦截前的浪费调用）：< 5%
  • 缓存命中率：> 20%
  • 毛利率：> 60%（V2 起考核，V1 无收入不适用）

8.3 技术指标

8.3.1 性能指标

🔗 性能指标的唯一定义位置是《需求规格说明》§4.1（编号 NFR-PERF-01~08、NFR-REL-01）。本节不再复述数值，避免出现第二套口径。

本轮收口时修正了本节原有的四处数值，理由记录如下：

原值 现口径 修正理由
初级报告 < 60s NFR-PERF-03：p95 < 90s 视觉分析 + LLM + 渲染串行，60s 过紧
全面报告 < 5min NFR-PERF-04：p95 < 180s 且明确为 V2 指标，V2 立项时重新基线
换装 < 320s NFR-PERF-05：两段式（现状基线 → 40s 优化目标） 320s 是现状、40s 是目标，两者不是同一件事，须分开表达
系统可用性 > 99.9% NFR-REL-01：≥ 99.5% V1 单可用区 Docker Compose 部署，无跨区冗余，99.9% 在架构上无法兑现
  • Agent 首字延迟 < 2s 是唯一在体验上关键的延迟指标（输出为流式），整轮完成时间见 NFR-PERF-02b
  • 错误率：< 0.1%

8.3.2 质量指标

  • 崩溃率：<0.1%
  • ANR 率：<0.05%
  • 加载时间：<3s（首屏）

8.3.3 安全与质量红线

  • 数据泄露：0 次
  • 安全事件：0 次
  • 合规审计：100% 通过
  • 用户禁忌项违反率：0（推荐了用户明确拒绝的品类/风格，视为 P0 缺陷）
  • 知识准确率：≥ 95%（黄金评测集）

诊断准确率必须分两档，此前两套数值互相冲突的根源就是没区分它们（单一事实源：《美学报告-需求文档》§9.4）：

指标 ① Phase 0 验证门槛 ② 上线质量门槛 两档的作用不同
体型识别 ≥ 80% ≥ 85% ①判断"这条技术路线是否走得通"（不达标就换方案）；②判断"能否交付给用户"
四季季型 ≥ 75% ≥ 80% 同上
脸型识别 ≥ 75% ≥ 80% 同上
意图识别 ≥ 85% ≥ 90% 同上
  • ①由 T-P0-10/T-P0-11 在 Phase 0 用小样本验证，未达标则触发方案切换（TD-05/TD-06 的备选路径）
  • ②由上线前黄金集全量回归验收，未达标则该维度降级为"仅供参考"或不展示，而不是延期上线

9. 下一步行动

完整任务清单（含依赖、验收标准、任务编号）见《开发任务拆解》。本章为摘要。

9.0 ✅ 备案已完成，最高优先级已转移

原本的第一优先级（备案登记，外部周期 2~4 个月）已完成，关键路径解除。新的最高优先级是内容与素材生产 —— 备案解除后，它成为唯一无法靠 AI 辅助开发压缩的工序。

本周必须启动的三件事（按优先级）：

  • 核实备案登记的模型清单是否覆盖 DeepSeek + 智谱 GLM 两家（T-P0-01）。若只覆盖一家，需办变更备案或 V1 先单路由。这是目前唯一可能影响上线的合规不确定项
  • 全职形象顾问招聘与入场（T-P0-20）—— 规则库产能直接决定 M2 能否按期
  • 单品自采流水线启动（T-P0-21）—— 目标 300 件 tryon_ready，按每周产能倒排

9.1 立即启动（本周）

9.1.1 技术验证

  • 换装接口能力测试（三种工作流）+ 单次真实成本测算（T-P0-13）
  • 发型接口能力测试（发型列表/更换/发色）（T-P0-14）
  • 接口性能与稳定性评估
  • 体型测算方案验证：人像分割掩膜宽度剖面 + 关键点定高，与人工标注一致率 ≥ 80%（T-P0-10）
  • 色彩季型判定验证：Lab 采样 + 规则，一致率 ≥ 75%（T-P0-11）
  • 抠图流水线验证：BiRefNet，10 件样本走通全流程（T-P0-12）
  • AI 标识元数据全链路存活验证（水印 → COS → CDN → 客户端保存）（T-P0-18）
  • 鸿蒙 ArkTS 端骨架验证（登录、拍照、直传、任务轮询、结果展示）（T-P0-17）

9.1.2 数据前置任务（备案解除后已升为实际关键路径）

  • 60 款发型适配标签打标（脸型/量感/直曲/长度/卷度/刘海/正式度）
  • 单品自采流水线搭建：采购 → 拍摄（白底规范）→ BiRefNet 抠图 → 属性标注 → 质检（T-P0-21）
  • 单品白底图抠图流水线验证（10 件样本走通全流程）
  • 知识库本体 Schema 与属性字典定稿
  • 全职形象顾问入场，开始规则撰写与黄金集标注（T-P0-20）

9.1.3 产品原型

  • 鸿蒙应用原型开发
  • 核心功能原型（含报告引导流程与任务中心）
  • UI/UX 设计初版
  • 用户测试

9.1.4 市场调研

  • 目标用户访谈（重点验证：是否愿意为形象报告付费、心理价位）
  • 需求验证
  • 竞品分析
  • 市场数据信源补齐 —— 已完成（TD-30）：§4.1 已全部替换为国家统计局、CNNIC、华为 HDC 2026 的可核实数据

9.2 2 周内完成

9.2.1 技术方案

  • 技术架构设计（见《技术架构文档》）
  • 技术选型定稿（见《技术选型与调研报告》）
  • 技术评审（架构文档过审）
  • 鸿蒙工程与打包流程确认（签名、权限、AGC 配置、SHA256 双证书指纹）
  • 接口契约定稿（OpenAPI 先行，客户端类型由其生成）

9.2.2 设计方案

  • UI/UX 设计
  • 交互设计
  • 视觉设计
  • 设计评审

9.2.3 运营计划

  • 上线策略
  • 推广方案
  • 运营计划
  • 预算规划

9.3 后续（按里程碑出口条件推进，不设日历周期）

原标题「1 个月内」已删除 —— 与「按实测产能倒排」的排期原则冲突（见 §4.3.3）。下列内容对应《开发任务拆解》的 M1~M5，各里程碑的出口条件见该文档。

9.3.1 MVP 开发

  • 接口集成（换装/发型）
  • 前端页面开发
  • 用户系统开发
  • 测试调试

9.3.2 测试发布

  • 内部测试
  • 灰度发布
  • 用户反馈
  • 问题修复

9.3.3 正式上线

  • 鸿蒙应用上架
  • 市场推广
  • 用户运营
  • 数据监控

10. 附录

10.1 现有接口清单

10.1.1 换装接口

10.1.2 发型接口

接口 方法 路径
获取发型列表 GET /hair/api/hairstyles
更换发型 POST /hair/api/change-hair
更换头发颜色 POST /hair/api/change-hair-color

10.1.3 化妆指导接口

  • 状态：⏳ 待确认（第一版暂不包含，后续版本规划）

10.1.4 现有接口的能力边界（产品设计必读）

限制 影响 产品应对
换装仅支持上衣（cloth_img）+ 裤子（kuzi_img） 连衣裙、鞋、包、配饰无法试穿 单品标注 tryon_slot，不可试穿的只展示"加入搭配"
裤子流程必须同时传 cloth_img 单独换裤子会解码失败 前端强制校验，缺上衣时用默认上衣素材
需要传入具体服装图片 没有素材库则功能形同虚设 建设白底单品素材库（见 §2.5.4）
换装耗时几十秒~几分钟 前台等待体验差 异步任务中心 + 完成推送（见 §2.7）
发型接口仅返回 60 款、无适配标签 无法按脸型/量感推荐 人工打标 60 款（见 §2.5.4）
发型失败时返回原图降级 用户可能误以为"没变化" 前端检测结果与原图一致时提示"处理失败，请重试"
OSS 结果为签名链接 链接过期后历史记录图片失效 结果图需转存到自有存储
接口无认证 存在被盗用与刷量风险 服务端代理转发 + 自有鉴权与限流，不在客户端直连

10.2 技术栈概要

层面 选型
客户端 鸿蒙原生 ArkTS + ArkUI；系统能力用 Account Kit / IAP Kit / Push Kit / Core Speech Kit(V2)
服务端 Python 3.12 + FastAPI + SQLAlchemy 2.0 + Pydantic v2；模块化单体 + 独立 AI 能力服务
异步任务 Celery + Redis，按 gpu / cpu / io / beat 四队列分离
数据 PostgreSQL 16 + pgvector（业务、知识库、向量、事件同库）；Redis；COS 四桶 + CDN
大模型 DeepSeek（主）+ 智谱 GLM（备与视觉），自建 LLM 网关（路由/降级/Prompt 版本/成本计量）
视觉 腾讯云人脸识别（属性/90 点/888 点）+ 人像分割；自建 RTMPose 人体关键点；自建 BiRefNet 抠图
Embedding 自建 BGE-M3
审核 腾讯云天御 IMS（图片）+ TMS（文本），输入输出双向、fail-close
渲染 Playwright 服务端渲染报告长图与 PDF
可观测 OpenTelemetry + Prometheus + Grafana + CLS；三张看板（业务漏斗 / AI 成本 / 任务健康）
部署 Docker Compose（V1，含按需启停的 GPU 实例）→ TKE（V2）

完整技术方案见《技术架构文档》；每项选型的理由、备选与切换条件见《技术选型与调研报告》。

10.3 关联文档清单

文档 说明
文档索引 README 文档地图、按角色的阅读路径、编号体系、术语表
需求规格说明 统一需求编号（FR/NFR/CR）、优先级、验收标准、V1 范围矩阵
美学报告需求文档 触发时机、初级/全面分级、32 项诊断维度字典、生成流程、付费策略
穿搭 Agent 需求文档 对话能力、意图识别、场景理解、能力联动
用户系统与记忆系统需求文档 账号与会员、配额计量、L0~L5 记忆模型、置信度与冲突消解
美学知识库建设方案 12 类知识分类、7 种模态、建设流程、混合检索链路
技术架构文档 分层架构、模块划分、数据模型、关键链路、API 规范、部署与成本
技术选型与调研报告 31 项技术决策、调研依据与信源
合规与安全方案 人脸信息、AI 生成内容标识、备案登记、内容审核、数据安全
开发任务拆解 WBS、依赖图、六个里程碑、任务验收
reference/个人形象报告.pdf 线下形象顾问交付样例，全面报告的内容深度基准

10.4 参考资料

10.4.1 数据信源（已收口）

⚠️ 原列的三条「待确认发布机构与时间」的行业报告已全部删除（TD-30）。它们无法核实来源，属于不可引用的数据。§4.1 已改用下列可核实的官方信源：

信源 用途 出处
国家统计局 服装与化妆品零售大盘 官方统计公报
CNNIC 第 57 次《中国互联网络发展状况统计报告》 生成式 AI 用户规模与普及率 CNNIC 官网
华为 HDC 2026 HarmonyOS 终端规模（可触达基数口径，非含 IoT 的生态总数） 华为官方发布

引用纪律：凡属本方案推算的数字，必须显式标注「推算」并给出推算口径，不与官方数据混排。

10.4.2 合规法规依据

完整清单、义务解读与落地要求见《合规与安全方案》§1。

  • 《中华人民共和国个人信息保护法》（人脸信息按敏感个人信息处理）
  • 《人脸识别技术应用安全管理办法》（网信办、公安部令第 19 号，2025-06-01 施行；存储人脸信息达 10 万人需备案）
  • 《生成式人工智能服务管理暂行办法》（需大模型登记 + 算法备案）
  • 《人工智能生成合成内容标识办法》（四部门，2025-09-01 施行）+ GB 45438-2025（显式标识 + 隐式元数据标识）
  • 《互联网信息服务深度合成管理规定》（换装/换脸类能力，含日志留存义务）
  • 《互联网信息服务算法推荐管理规定》（算法备案）
  • 《未成年人网络保护条例》
  • 《移动互联网应用程序个人信息保护管理暂行规定》

10.4.3 技术文档

10.4.4 设计规范

  • 鸿蒙设计规范
  • Material Design 设计规范
  • iOS Human Interface Guidelines

11. 待决策事项汇总

11.1 已决策（本轮收口）

# 决策项 结论 依据
1 第一版是否只做初级报告、不做支付 ✅ 采纳。V1 只做初级报告，用预约率验证付费意愿 需求规格说明 §5.2
2 会员权益是否改为点数制 ✅ 采纳。基础额度 + 点数制 §3
3 客户端框架 ✅ 改为鸿蒙原生 ArkTS（原 Uni-App-x） TD-01
4 后端技术栈 ✅ 全 Python（FastAPI），模块化单体 + 独立 AI 服务 TD-02
5 云厂商 ✅ 腾讯云为主 TD-03
6 大模型 ✅ DeepSeek 主 + 智谱 GLM 备/视觉，自建网关 TD-04
7 视觉分析自研 vs 第三方 ✅ 混合：人脸走腾讯云，人体关键点自建（腾讯云已下线该能力） TD-05
8 向量库 / 图谱 / 规则引擎 ✅ pgvector / PG 邻接表 / 自研决策表，均不引入新组件 TD-08~TD-10
9 抠图模型 ✅ BiRefNet；禁用 RMBG-2.0（非商用许可） TD-07
10 12 季色彩体系版权 ✅ 自建色板与自研命名，规避「CMB / 四季色彩」商标 TD-18
11 报告长图渲染 ✅ 服务端 Playwright 渲染 TD-12
12 知识库运营后台排期 ✅ V1 就做极简版（内容运营不能靠改数据库） TD-25
13 备案路径 ✅ 备案已完成（原需大模型登记 + 算法备案）。转为持续义务：编号界面公示、范围一致性、变更备案 TD-19
14 是否支持一账号多形象档案 ✅ V1 仅预留 profile_id 字段，不做 UI FR-ACC-12
15 报告术语通俗化 ✅ 采用「专业术语 + 一句白话释义」并列展示，不改名 NFR-UX-03
16 单品素材来源 ✅ 自采（采购 → 实拍 → 抠图 → 标注）。版权干净、规格统一，代价是成为新的关键路径 TD-26
17 形象顾问合作方式 ✅ 全职编制。规则库产能可控、可深度参与后台设计与黄金集标注 TD-27
18 V1 是否收费 ✅ V1 完全不收费，用配额限制控制成本；支付、会员、点数全部推到 V2 TD-28
19 华为 IAP 与企业开发者资质 ✅ V1 不接支付，IAP 不涉及；一键登录降级为 P1，V1 用华为账号授权登录 + 手机号验证码 TD-29
20 市场数据信源 ✅ 已全部替换为官方可核实信源（国家统计局、CNNIC、华为 HDC 2026）；并据此下调用户规模目标 TD-30、§4.1、§8.1.1
21 五行/命理模块 ✅ 不做（V1 与 V2 均不纳入），规避应用市场审核风险 TD-31
22 短信验证码通道 ✅ 腾讯云短信，与云厂商收口一致。V1 必需 —— 它是华为账号之外唯一的独立登录通道（一键登录已推 V2），须配套三重频控与刷量告警 TD-32、FR-ACC-04/14
23 天气数据源 ✅ V1 不接天气 API。Agent 遇天气问题时反问用户或按城市月份推断气候区，绝不编造具体温度与降水。省掉一项定位权限与一条工程链路 TD-33
24 成本封顶机制 ✅ 配额不封顶总成本（总成本 = MAU × 人均，MAU 无上限），真正封顶的是全局日成本熔断（四档自动降级，非仅告警） NFR-COST-02、§5.3.1

11.2 仍待业务输入

# 决策项 需要的输入 阻塞什么 编号
1 备案登记覆盖的模型清单 备案时是否已包含 DeepSeek 与智谱 GLM 两家 双路由能否在 V1 启用；若只覆盖一家需办变更或先单路由 TD-19

除上述一项外，其余业务决策已全部收口。这一项之所以保留，是因为它是唯一可能影响 V1 上线合规性的未知项，且答案只能来自备案材料本身。

文档版本：v6.1 创建日期：2026-08-04 更新日期：2026-08-13 作者：产品团队 状态：待评审 变更说明：

  • v6.1（2026-08-13）：文档一致性评审修订（2026-08-13）
    • §5.2.1 / §5.3.1 成本口径彻底重写，并推翻一个错误论证。原文称「月度成本上限 = MAU × 单用户配额成本上限，是可事前算准的确定值」，有两个漏洞：① 数字算不平（15 万 × ¥8 = ¥120 万 ≠ ¥12 万）；② 更根本的是，按人头发配额封不住总成本 —— 配额约束单用户，而总成本 = MAU × 人均，MAU 无上限。现改为：单用户成本分物理上限 ¥236 / 重度 ¥150 / 人均预期 ¥0.8 三档；总成本 ¥7~12 万定性为预期值（含使用率假设）而非硬上限，并给出可复算的算式；新增「全局日成本熔断」为唯一真正的封顶机制（NFR-COST-02，四档自动降级，非仅告警）
    • §8.3.1 性能指标改为引用 NFR-PERF-*，不再自成一套。连带修正四处：初级报告 60s→90s、全面报告 5min→180s、换装改「现状基线 → 目标值」两段式、可用性 99.9%→99.5%（V1 单可用区无冗余，99.9% 在架构上无法兑现）
    • §8.3.3 诊断准确率拆为「Phase 0 验证门槛 / 上线质量门槛」两档，此前两套数值冲突的根源就是没区分这两档（两者的失败后果完全不同：前者触发换方案，后者触发维度降级）
    • §3.2 配额表补入「游客」列并升为唯一事实源，此前游客额度只写在正文叙述里，导致 FR-ACC-02 无法验收
    • §2.2.1 维度覆盖改为准确口径：初级覆盖 21/32 项（首屏突出 8 项核心结论），全面覆盖 32 项。原「8 项核心 / 40+ 项完整」中的 40+ 在字典里根本不存在
    • §7.1.4 人脸原图保留期由 ≤24h 改为「处理完即删 + 临时桶 2 小时兜底」，与本文 §7.3.4、CR-02 统一（2 小时已覆盖重试窗口，24h 只是白担合规风险）
    • §2.5.2 / §4.3.1 / §6.1.2 知识库规模改为引用知识库 §9.1；黄金集改为「330 例分四子集」
    • 删除全部日历周期承诺（§4.3.3「1-2 个月」、§6.1/§6.2/§6.3 标题周期、§9.3「1 个月内」），与「按实测产能倒排」的排期原则统一
    • §11.1 决策表新增 3 项（TD-32 短信通道、TD-33 天气数据源、成本封顶机制），共 24 项
    • 措辞收口：「不重复计费」→「不重复扣减配额」；流水类型由「两种」更正为「三种」（refund 不可省略）；§10.4.1 三条无出处行业报告删除
  • v6.0（2026-08-13）：业务决策全部收口，商业模式与市场数据重做
    • §5.0 新增「V1 不收费，只限量」：V1 不接入任何支付能力，会员/点数/付费报告全部推到 V2。连带简化：无 IAP、无 30% 抽成、无交易类合规材料，billing 域降级为「配额账本 + 消耗流水」（TD-28、TD-29）
    • §3 权益设计重构：拆为「§3.2 V1 配额设计（唯一生效）」+「§3.3 V2 权益规划（仅架构预留）」+「§3.4 计量要求（不可裁剪）」。明确三条纪律：配额是服务端硬限制、V1 文案不出现价格字样、禁止静默扣减
    • §4.1 市场规模全部重写：三处无出处引用已删除，替换为国家统计局、CNNIC、华为 HDC 2026 的可核实数据（TD-30）。并纠正一处严重口径错误 —— 纯血鸿蒙原生应用只能装在 HarmonyOS NEXT+ 设备（HarmonyOS 6 为 6,600 万台），此前引用的「13 亿设备」是含 IoT 的生态总数，与本产品分发无关
    • §8.1.1 用户规模目标下调并改变考核方式：原「DAU 30 万 / MAU 100 万 / 注册 200 万」废弃（分母错、粘性假设错）。改为注册 50 万 / MAU 15 万，并以季度回访率替代 DAU 作为核心粘性指标 —— 形象诊断是低频决策型工具，用日活考核会逼出无意义的签到打卡
    • §5.3 财务预期重写：V1 收入恒为 ¥0（主动选择），只做成本封顶（月度 AI 成本 ≤ ¥12 万）与数据采集；原 Q1~Q4 季度盈利预测因四项假设全部失效而废弃，V1 跑满一个周期前不产出新预测
    • §6.0 / §7.3.0 / §9.0 备案状态更新为已完成：原最高级别风险（2~4 个月审批周期）关闭，关键路径转移到内容与素材生产。备案完成后的四项持续义务（编号公示、范围一致性、变更备案、材料留档）已列明
    • §11 决策表：新增 6 项收口（素材自采、顾问全职、V1 不收费、IAP 不涉及、市场数据信源、命理模块不做），待业务输入项从 6 项减至 1 项
  • v5.0（2026-08-13）：本轮完成全文档 review、重构与技术选型收口
    • 文档体系升级为四层：新增《需求规格说明》《技术架构文档》《技术选型与调研报告》《合规与安全方案》《开发任务拆解》《文档索引 README》，并同步更新 §1.6 文档地图与 §10.3 关联文档清单
    • §1.2 / §1.4 技术选型变更：客户端由 Uni-App-x 改为鸿蒙原生 ArkTS；补齐服务端、基础设施、大模型、视觉能力的选型结论（TD-01~TD-07）
    • §5.2 新增平台抽成口径修正：虚拟商品在鸿蒙必须走华为 IAP，抽成约 30%，原收入预测为交易额口径、偏乐观（TD-16）
    • §6 新增 Phase 0：前置验证与资质，含备案登记（外部周期 2~4 个月，上线决定性瓶颈）、六项关键技术验证、数据与内容准备；Phase 1 补充「工程地基先于业务功能」的要求
    • 修正一处已失效的技术假设：腾讯云人体检测与人体关键点接口已于 2025-10-30 下线，体型测算改为自建 RTMPose + 人像分割掩膜宽度剖面法（TD-05/TD-06）
    • §7.3 政策风险重写：新增 §7.3.0 备案登记周期风险（升为最高级别风险）；数据合规补充「人脸原图不落盘以规避 10 万人备案阈值」的架构策略；AI 内容合规补充显式 + 隐式双重标识、统一合规出口、元数据被静默剥离的坑；内容审核明确六类对象全覆盖与 fail-close 原则
    • §4.3 短期优势表述修正：删去「Uni-App-x 多端能力」，改为强调换装/发型服务自有可控（可改造、可扩容、成本可归因）
    • §10.2 技术栈概要重写；§10.4.2 合规法规依据补齐 2025 年新规（人脸识别办法、AI 生成内容标识办法 + GB 45438-2025）
    • §11 待决策事项拆分为「已决策（15 项收口）」与「仍待业务输入（6 项）」
  • v4.0（2026-08-11）：
    • 新增 §1.6 文档地图，明确四个子系统文档的关系与依赖链路
    • 重构 §2.2 美学报告：拆分为初级（V1 免费）/ 全面（V2 付费）两级，补充完整触发时机设计（首次生成 4 类触点、更新触发 7 项条件、付费触发 7 个位置、拦截规则 11 项），并明确第一版以"预约留资"验证付费意愿；详细内容拆分为独立文档
    • 新增 §2.4 用户系统与记忆系统：账号体系（含游客模式与数据迁移）+ L0~L5 六层记忆模型；详细内容拆分为独立文档
    • 新增 §2.5 美学知识库：四层架构、12 类知识分类、7 种模态设计，并指出 60 款发型无标签、无白底单品素材两项前置数据缺口；详细内容拆分为独立文档
    • 新增 §2.6 我的衣橱（V2 差异化重点）、§2.7 任务中心（长耗时任务产品化）
    • 重写 §3 产品形态：会员制改为「基础额度 + 权益点数」，修正原"¥9.9 无限换装"的成本失控问题；V1 只做免费额度与计量
    • §4.3 重新校准壁垒来源：接口非壁垒，真实壁垒为知识库、画像记忆资产、可试穿素材库
    • §5 商业模式：新增全面报告单次付费为 V2 主力收入、点数增值、单位经济模型与单次成本目标；标注原盈利预测口径待修正
    • §6 实施计划：Phase 1 补充报告、记忆系统、知识库 V1、任务中心、配额计量等任务；Phase 2 补充付费体系、衣橱、知识库后台
    • §7 风险：新增知识库与素材缺口、AI 幻觉、成本失控、AI 生成内容合规、命理内容审核五类风险，强化隐私安全条款
    • §8 指标：新增报告与个性化指标（含预约率 8% 决策门槛、采纳率差值 15pp 验证指标）、成本指标、质量红线
    • §10.1.4 新增现有接口能力边界（换装仅支持上衣+裤子等 9 项限制及产品应对）
    • 新增 §11 待决策事项汇总
  • v3.0（2026-08-11）：
    • 技术栈调整为 Uni-App-x，首发鸿蒙
    • 更新换装 API 为生产环境（https://meida.xiangsilian.com）
    • 更新发型 API 为生产环境（/hair/api）
    • 移除第一版购物与商城功能
    • 移除鸿蒙系统特殊功能（分布式/原子化服务/系统级能力）
    • 移除技术架构章节，聚焦产品需求
    • 穿搭 Agent 拆分为独立需求文档
  • v2.0：初始版本
Reference in New Issue View Git Blame Copy Permalink