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

收口文档评审冲突并补齐 Sprint 执行计划

Browse Source 
统一性能、token、配额与成本口径，补齐短信登录等缺口任务，并回写脚手架实测暴露的思考模式与峰谷计价约束。

Co-authored-by: Cursor <cursoragent@cursor.com>
This commit is contained in:
xsl
2026-08-14 09:40:50 +08:00
co-authored by Cursor
parent e31755e343
commit f4075f6827
13 changed files with 1200 additions and 290 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/鸿蒙美搭-智能穿搭美学助手-产品方案.md
+139 -58
View File
@@ -234,7 +234,7 @@
| 上线版本 | **V1** | **V2**（V1 仅做占位入口） |
| 价格 | 免费 | 付费（**定价待 V2 按真实数据确定**，见 §5.0） |
| 输入 | 1 张全身照 + 4 项问卷 | 全身正/侧 + 面部特写 + 12~15 项问卷 |
| 诊断维度 | 8 项核心 | 40+ 项完整 |
| 诊断维度 | **覆盖 21 / 32 项**（首屏突出 8 项核心结论） | **覆盖全部 32 项** |
| 色彩精度 | 四季粗判 + 8 色色板 | 十二季细分 + 24+ 色完整色板 |
| 发型内容 | 3 条要点 | 独立发型专项报告（8 小节） |
| 场景方案 | 1 个 | 4+ 个（含配色公式） |
@@ -314,7 +314,7 @@ V1 不做支付链路，在初级报告结果页保留「全面报告」预览
- **隐式推断需确认**：同属性连续 3 次拒绝 → 生成待确认候选 → 恰当时机征询"看起来你不太喜欢露肩款？"，用户确认后才生效
- **用户偏好高于专业结论**：专业判定与用户喜好冲突时，**按用户喜好执行 + 附加专业提示**（不说教）
- **可见可控**：「我的记忆」页面可查看、修改、删除每条记忆，并可一键关闭个性化推荐（合规刚需 + 信任基础）
- **注入有预算**：画像摘要 ≤250 token + 偏好 ≤150 + 事件召回 ≤200 + 会话 ≤800，合计 ≤1400 token，不做无脑全量拼接
- **注入有预算**：记忆注入合计 ≤1400 token（V1 实际 ≤1200，事件召回为 V2 能力），不做无脑全量拼接。**完整分项预算见《技术架构文档》§7.2（唯一事实源）**
### 2.5 美学知识库（详见独立文档）
@@ -335,20 +335,22 @@ V1 不做支付链路，在初级报告结果页保留「全面报告」预览
#### 2.5.2 知识分类：12 类实体
| 类目 | 内容 | 第一版目标量级 |
|------|------|--------------|
| ① 单品 Item | 品类树 + 廓形/领型/袖型/腰线/长度/图案/正式度/量感/直曲等属性 | 800 条（≥400 条可试穿） |
| ② 色彩 Color | 色名 + HEX/HSL/**Lab** + 冷暖/明度/彩度 + 季型归属 + 配色关系 | 400 色 + 12 套色板 |
| ③ 风格 Style | 9 型基因风格 + 20+ 潮流风格（法式/韩系/清冷/老钱风…） | 29 条 |
| ④ 身材 Body | 5 体型 + 12 局部特征（溜肩/短颈/长短腰…）→ 修饰策略 | 60 组映射 |
| ⑤ 面部与发型 | 脸型/三庭五眼/量感/直曲 × 发长/卷度/刘海/发色 适配矩阵 | 60 款发型全量打标 |
| ⑥ 场景 Occasion | 20 场景 × Dress Code × 温度带（8 档）× 天气 | 80 组 |
| ⑦ 材质 Material | 垂感/挺括/透气/保暖/易皱/光泽 + 季节与季型适配 | 40~60 种 |
| ⑧ 配饰 Accessory | 8 品类的量感、材质、颜色、佩戴位置规则 | — |
| ⑨ 妆容 Makeup | 12 季型 × 底妆/眼妆/唇妆 色值方案 | 36 组 |
| ⑩ 搭配法则 Rule | 结构化 IF-THEN 规则（供规则引擎执行） | **800 条（核心资产）** |
| ⑪ 搭配方案 Outfit | 成套 look（单品组合 + 配色公式 + 适配画像 + 试穿素材） | 300 套 |
| ⑫ 趋势 Trend | 时效性流行趋势，独立库、月更、过期降权 | 每季 30~50 条 |
> 🔗 **规模数值的唯一定义位置是《美学知识库-建设方案》§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 种模态
@@ -390,7 +392,7 @@ V1 不做支付链路，在初级报告结果页保留「全面报告」预览
- 所有 AI 生成走**异步任务队列**，返回 `task_id`，前端轮询或长连接获取状态
- 用户可最小化任务、退出页面甚至退出 App，完成后**推送通知**召回
- 任务中心统一展示进行中/已完成/失败任务，失败可一键重试（不重复计费）
- 任务中心统一展示进行中/已完成/失败任务，失败可一键重试（**不重复扣减配额**）
- 生成过程**步骤可视化**（识别人像 → 测算体型 → 分析面部 → 采样色彩 → 生成方案），并展示已等待秒数
- 等待期填充内容：美学小知识卡、报告样例、热门搭配
- 端侧**前置质量校验**（是否人像/单人/全身/清晰/光线），不合格直接拦截，既省成本又省用户时间
@@ -436,21 +438,31 @@ V1 不做支付链路，在初级报告结果页保留「全面报告」预览
原方案设定"会员 ¥9.9/月 = 无限换装"，在成本上不成立：换装是长耗时 GPU 推理（几十秒到几分钟），单次成本在角到元量级，重度用户单月可消耗数十元，**会员越活跃越亏损**。
**V1 的解法比点数制更彻底：干脆不收费，只限量**（`TD-28`）。不收费就没有"付费用户应该无限用"的压力，配额可以是纯粹的硬限制，月度成本上限因此变成可以事前算准的确定值（§5.3.1）。点数制留给 V2 —— 届时有了 V1 的真实成本数据，点数消耗比才有依据。
**V1 的解法比点数制更彻底：干脆不收费，只限量**（`TD-28`）。不收费就没有"付费用户应该无限用"的压力，配额可以设得紧、熔断可以设得狠，不必担心损害已付费用户的权益。点数制留给 V2 —— 届时有了 V1 的真实成本数据，点数消耗比才有依据。
> ⚠️ **但要澄清一个常见误解**：配额**不等于**总成本封顶。配额约束单个用户，总成本 = MAU × 人均，而 MAU 无上限。真正封顶的是**全局日成本熔断**（`NFR-COST-02`），详见 §5.3.1。
### 3.2 V1 配额设计（唯一在 V1 生效的一张表）
V1 无付费、无会员、无点数购买，**所有用户使用同一套配额**。额度用尽后只有两条路：等自然恢复，或做任务换额度。
V1 无付费、无会员、无点数购买，**所有注册用户使用同一套配额**。额度用尽后只有两条路：等自然恢复，或做任务换额度。
| 能力 | 基础额度 | 可通过任务额外获得 | 硬上限（防刷） |
|------|---------|------------------|--------------|
| 初级美学报告（首次） | 1 次（终身） | — | — |
| 报告重新生成 | 每 30 天 1 次 | +1 次/月 | 每日 ≤ 2 |
| 换装试穿 | **每日 3 次** | +3 次/日 | 每日 ≤ 8 |
| 发型 / 发色试戴 | **每日 3 次** | +2 次/日 | 每日 ≤ 6 |
| AI 对话 | **每日 10 轮** | +10 轮/日 | 每日 ≤ 40 |
| 记忆条数 | 200 条 | — | — |
| 高清导出 | 每日 1 次 | — | 每日 ≤ 3 |
> 🔒 **本表是 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. **额度用尽必须是"引导登录"而非"静默失败"** —— 这是游客模式唯一的转化时机，做成一个报错就白费了。
**任务奖励额度的获取方式**（全部不涉及金钱）：每日签到、完善画像资料、给报告结论打反馈、邀请好友、分享报告长图。
@@ -476,7 +488,7 @@ V1 无付费、无会员、无点数购买，**所有用户使用同一套配额
| 高清导出 / 去水印 | ❌ | ✅ | ✅ |
- **点数消耗与获取、扣减顺序**：V2 设计时确定。架构上已按「reserve → commit / refund 预扣三段式」预留（见《技术架构文档》§7.4），保证长耗时任务不会出现"扣了额度但没交付"。
- **V1 与 V2 的衔接**：V1 的「配额账本」与 V2 的「点数账本」是同一张表的两种用法 —— V1 只有系统发放与消耗两种流水类型，V2 增加购买与赠送类型。这样 V2 不需要数据迁移。
- **V1 与 V2 的衔接**：V1 的「配额账本」与 V2 的「点数账本」是同一张表的两种用法 —— V1 有 `system_grant`（系统发放）、`consume`（消耗）、`refund`（退还）**三种**流水类型，V2 增加 `purchase`（购买）与 `gift`（赠送）。这样 V2 不需要数据迁移。`refund` 不可省略：预扣三段式与熔断退还额度都依赖它。
### 3.4 第一版的计量要求（不可裁剪）
@@ -554,7 +566,7 @@ V1 不收费，但**计量是 V1 最重要的隐性交付物**，它决定 V2
| 资产 | 为什么难复制 | 投入方式 |
|------|------------|---------|
| **美学知识库**（800 条专家规则 + 12 套色板 + 适配矩阵） | 需要专业形象顾问长期投入，无法靠大模型生成后直接使用 | 顾问合作 + 人审流水线 |
| **美学知识库**（专家规则 + 12 套色板 + 适配矩阵，规模见知识库 §9.1） | 需要专业形象顾问长期投入，无法靠大模型生成后直接使用 | **全职顾问**（`TD-27`）+ 人审流水线 |
| **用户画像与记忆资产** | 数据随使用时长复利增长，用户迁移成本高 | 报告 + 记忆系统 |
| **可试穿素材库**（白底单品图 + 属性标注） | 需要采集、抠图、标注的重投入，且是"建议→预览"闭环的唯一入口 | 素材运营流水线 |
@@ -568,11 +580,13 @@ V1 不收费，但**计量是 V1 最重要的隐性交付物**，它决定 V2
- **形象档案化**：报告版本化 + 前后对比，把一次性内容变成长期资产
#### 4.3.3 快速迭代
- **MVP 优先**：1-2 个月上线 MVP
- **MVP 优先**：以**里程碑出口条件**衡量进度，不承诺日历周期（见 §6 与《开发任务拆解》）
- **用户反馈**：快速收集用户反馈
- **数据驱动**：基于数据优化产品
- **小步快跑**：持续快速迭代
> ⚠️ **原「1-2 个月上线 MVP」已删除**。本项目的排期原则已改为「**不按人日估算，按实测产能倒排**」（`TD-27`、`T-P0-20`/`T-P0-21`）—— 关键路径是内容与素材生产，而它的产能必须先测出来才能倒排。在测出产能前给出日历承诺，只会得到一个必然被打破的承诺。
---
## 5. 商业模式
@@ -642,7 +656,17 @@ V1 不收费，但**计量是 V1 最重要的隐性交付物**，它决定 V2
| 初级美学报告 | ≤ ¥0.30 | 视觉分析 + LLM 生成 |
| 全面美学报告 | ≤ ¥2.00 | 章节多、输出 token 大 |
| Agent 单轮对话 | ≤ ¥0.05 | 含 RAG 检索 |
| **免费用户月成本上限** | **≤ ¥8** | 按每日 3 次换装 + 3 次发型 + 10 轮对话的额度上限倒推 |
| 高清导出 | ≤ ¥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 实例按需启停。
@@ -683,12 +707,23 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
| 项 | V1 目标 | 说明 |
|---|---------|------|
| 月度 AI 总成本（MAU 15 万口径） | **≤ ¥12 万/月** | 由配额上限硬性决定，不随用户行为失控 |
| 单免费用户月度 AI 成本 | ≤ ¥8 | 见 §5.2.1，配额倒推 |
| 月度 AI 总成本（MAU 15 万口径） | **¥7~12 万/月（预期，含假设）** | 由 §8.2.2 用量推算 × §5.2.1 单次成本得出，**不是硬上限** |
| 单用户月度 AI 成本（人均） | ≈ ¥0.8 | §5.2.1 档位③；物理上限为 ¥236，见该表 |
| **日成本熔断阈值** | **¥5,000/日** | **这才是真正的成本封顶机制**，见下方 |
| 知识库一次性建设投入 | ¥12~18 万 | 含全职顾问、素材自采、抠图标注 |
| **必须采齐的数据** | 单次真实成本 / 人均使用频次 / 预约率 | **这是 V1 唯一的"商业产出"** |
**成本封顶为什么能成立**：配额是硬限制而非软提示 —— 额度用尽时服务端直接拒绝，不存在超额消耗的路径。因此月度成本上限 = MAU × 单用户配额成本上限，是可以事前算准的确定值，而不是需要事后控制的风险项。这是"不收费"换来的一个额外好处：不收费就没有"付费用户应该无限用"的压力。
**¥7~12 万是怎么来的**（可复算）：报告 3~5 万份 × ¥0.3 + 试穿 8~12 万次 × ¥0.5 + 发型 4~6 万次 × ¥0.2 + 对话 30~50 万轮 × ¥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 起的盈利预测
@@ -752,7 +787,9 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
**Phase 0 出口条件**（已按备案完成调整）：六项技术验证有明确结论；本体 Schema 与发型打标完成；全职顾问到岗且规则库产出节奏可测算；自采流水线跑通首批 20 件单品；**备案编号公示位已在端上预留**。
### 6.1 Phase 1：MVP（1-2 个月）
### 6.1 Phase 1 = V1：MVP
> **周期以出口条件衡量，不设日历周期**（原「1-2 个月」已删除，理由见 §4.3.3）。里程碑与依赖关系见《开发任务拆解》§1。
#### 6.1.1 目标
- 验证市场需求
@@ -803,7 +840,7 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
- [ ] 单品素材 300 件（含白底试穿图）+ 抠图流水线
- [ ] 搭配方案 100 套（含试穿素材绑定）
- [ ] 混合检索链路（硬过滤 + 向量召回 + 重排）
- [ ] 黄金评测集 200 条 + 回归测试脚本
- [ ] 黄金评测集 **330 例，分四个子集**（检索 100 / Agent 问答 100 / 诊断 100 / 报告结构 30，见知识库 §7）+ 回归测试脚本
- [ ] **Agent 基础能力**
- [ ] 大模型选型与对接、流式输出
@@ -831,7 +868,7 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
- 用户反馈报告、技术验证报告
- **单用户成本报告与付费意愿验证结论**（V2 定价依据）
### 6.2 Phase 2 = V2：核心功能完善与商业化（2-3 个月）
### 6.2 Phase 2 = V2：核心功能完善与商业化
> **本阶段即 V2**。所有付费能力都在这里，**不属于 V1 范围**（`TD-28`）。
@@ -869,7 +906,7 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
- [ ] 一衣多搭、衣橱体检、缺口建议
- [ ] **知识库扩充**
- [ ] 规则扩充至 800 条、方案至 300 套、素材至 800 件
- [ ] 知识库规模由 V1 硬指标扩充至长期目标（规则 800~1200 条 / 方案 300~500 套 / 单品 800~1500 件，见知识库 §9.1）
- [ ] **知识库管理后台**（增删改查 + 审核工作流 + 版本对比 + 效果看板）
- [ ] 知识缺口周报机制
- [ ] 图谱层与「为什么推荐」解释链
@@ -894,7 +931,7 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
- 知识库管理后台完整版
- **基于真实数据重做的财务模型与定价**（替代 §5.3.2 中已废弃的季度预测）
### 6.3 Phase 3：多端扩展（3-4 个月）
### 6.3 Phase 3：多端扩展
#### 6.3.1 目标
- 扩展多端（iOS / Android），**届时重新评估跨端方案**（保留鸿蒙原生另起跨端工程 / Uni-App-x / Flutter），判断依据是那时的鸿蒙生态成熟度与团队构成（`TD-01`、`T-P6-15`）
@@ -974,7 +1011,8 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
- **风险描述**：用户照片数据可能泄露或滥用；人脸信息处理不合规将面临监管处罚与下架风险
- **应对措施**：
- 人脸信息**单独授权**，不可默认勾选，可单独撤回
- 原始照片处理完即删（保留 ≤24h 仅用于任务重试），只保留派生特征与结论
- **原始照片处理完即显式删除，临时桶生命周期 ≤ 2 小时兜底**，只保留派生特征与结论（唯一事实源：`CR-02` 与《合规与安全方案》§2.1.2）
- ⚠️ 原文写「保留 ≤24h 仅用于任务重试」**已废弃**，与本文 §7.3.4、`CR-02` 冲突。2 小时已足够覆盖重试窗口（最长任务 320s，重试上限 3 次），**24h 只是白担合规风险** —— 保留期越长，"存储的人脸信息数量"越可能被认定为非零，进而触发 10 万人备案义务
- 明确承诺照片不用于模型训练，并写入隐私政策
- 数据加密传输与存储，OSS 签名链接短时效
- 分享长图默认"结论版"（不含照片），降低泄露面
@@ -1192,21 +1230,30 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
| Agent 对话轮次 | 30~50 万轮/月 | LLM 成本主项 |
#### 8.2.3 成本指标（新增，与收入指标同等重要）
- **单用户月度 AI 成本**：免费用户 ≤ ¥8，会员 ≤ ¥20
- **单次成本**：换装 ≤ ¥0.50 / 发型 ≤ ¥0.20 / 初级报告 ≤ ¥0.30 / 全面报告 ≤ ¥2.00 / 对话 ≤ ¥0.05
- **单次成本**：换装 ≤ ¥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 起考核）
- **毛利率**：> 60%（V2 起考核，V1 无收入不适用）
### 8.3 技术指标
#### 8.3.1 性能指标
- **接口响应**：换装 <320s（P95），发型 <120s（P95）
- **报告生成**：初级 <60s（P95），全面 <5min（P95）
- **Agent 首字延迟**：<2s（P95）
- **知识库检索**：硬过滤 <50ms，向量召回 <200ms（P95）
- **系统可用性**：>99.9%
- **错误率**：<0.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%
@@ -1219,7 +1266,18 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
- **合规审计**：100% 通过
- **用户禁忌项违反率**：**0**（推荐了用户明确拒绝的品类/风格，视为 P0 缺陷）
- **知识准确率**：≥ 95%（黄金评测集）
- **诊断准确率**：体型 ≥85%、脸型 ≥80%、四季季型 ≥80%
**诊断准确率必须分两档，此前两套数值互相冲突的根源就是没区分它们**（单一事实源：《美学报告-需求文档》§9.4）：
| 指标 | ① Phase 0 验证门槛 | ② 上线质量门槛 | 两档的作用不同 |
|------|-----------------|-------------|--------------|
| 体型识别 | ≥ 80% | ≥ 85% | ①判断"这条技术路线是否走得通"（不达标就换方案）；②判断"能否交付给用户" |
| 四季季型 | ≥ 75% | ≥ 80% | 同上 |
| 脸型识别 | ≥ 75% | ≥ 80% | 同上 |
| 意图识别 | ≥ 85% | ≥ 90% | 同上 |
- ①由 `T-P0-10`/`T-P0-11` 在 Phase 0 用小样本验证，**未达标则触发方案切换**（`TD-05`/`TD-06` 的备选路径）
- ②由上线前黄金集全量回归验收，**未达标则该维度降级为"仅供参考"或不展示**，而不是延期上线
---
@@ -1265,7 +1323,7 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
- [ ] 目标用户访谈（重点验证：是否愿意为形象报告付费、心理价位）
- [ ] 需求验证
- [ ] 竞品分析
- [ ] 市场数据信源补齐（§4.1 待办）
- [x] ~~市场数据信源补齐~~ —— **已完成**（`TD-30`）：§4.1 已全部替换为国家统计局、CNNIC、华为 HDC 2026 的可核实数据
### 9.2 2 周内完成
@@ -1288,7 +1346,9 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
- [ ] 运营计划
- [ ] 预算规划
### 9.3 1 个月内
### 9.3 后续（按里程碑出口条件推进，不设日历周期）
> 原标题「1 个月内」已删除 —— 与「按实测产能倒排」的排期原则冲突（见 §4.3.3）。下列内容对应《开发任务拆解》的 M1~M5，各里程碑的出口条件见该文档。
#### 9.3.1 MVP 开发
- [ ] 接口集成（换装/发型）
@@ -1391,10 +1451,17 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
### 10.4 参考资料
#### 10.4.1 行业报告（待补齐信源）
- 《2025年中国时尚电商行业报告》——待确认发布机构与时间
- 《AI美妆行业发展趋势白皮书》——待确认发布机构与时间
- 《鸿蒙生态发展报告》——待确认发布机构与时间
#### 10.4.1 数据信源（已收口）
> ⚠️ 原列的三条「待确认发布机构与时间」的行业报告**已全部删除**（`TD-30`）。它们无法核实来源，属于不可引用的数据。§4.1 已改用下列可核实的官方信源：
| 信源 | 用途 | 出处 |
|------|------|------|
| 国家统计局 | 服装与化妆品零售大盘 | 官方统计公报 |
| CNNIC 第 57 次《中国互联网络发展状况统计报告》 | 生成式 AI 用户规模与普及率 | CNNIC 官网 |
| 华为 HDC 2026 | HarmonyOS 终端规模（**可触达基数口径**，非含 IoT 的生态总数） | 华为官方发布 |
**引用纪律**：凡属本方案推算的数字，必须显式标注「推算」并给出推算口径，**不与官方数据混排**。
#### 10.4.2 合规法规依据
@@ -1451,6 +1518,9 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
| 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 仍待业务输入
@@ -1462,12 +1532,23 @@ V1 不接入支付，因此**本节对 V1 不产生任何影响**。但 V2 定
---
**文档版本**：v6.0
**文档版本**：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 文案不出现价格字样、禁止静默扣减