xslandCursor
f4075f6827
统一性能、token、配额与成本口径，补齐短信登录等缺口任务，并回写脚手架实测暴露的思考模式与峰谷计价约束。 Co-authored-by: Cursor <cursoragent@cursor.com>
22 KiB
「美搭」文档体系评审报告
评审日期：2026-08-13 ｜ 评审范围：
docs/目录全部 11 份文档（README + 10 份内容文档） 评审方法：逐份通读 + 跨文档事实交叉比对（数字、枚举、编号、状态）+ 按《开发任务拆解》§9.3 的要求做「需求 → 任务」反查 本文性质：评审反馈，不修改任何被评文档；问题定位到文档与章节，供修订时对照
0. 总体结论
这套文档体系的骨架是好的，可以进入评审流程；但有一批"数字口径"类的事实性冲突需要先修掉，否则评审会上会卡在事实核对而不是方案讨论上。
值得肯定的地方（这些做得比多数项目文档好，应保持）：
- 四层结构与编号体系清晰：FR/NFR/CR/TD/ADR/T/R 七套编号 + 「同一事实只在一处定义、其余引用编号」的纪律（README §4、§6），是这套文档能长期维护的前提。
- 决策留痕完整：每份文档有变更记录，技术选型报告 §8 有「与既有文档的冲突修正清单」，产品方案 §11 有已决策/待输入清单。本轮"备案完成、V1 不收费、素材自采"三个大转向在各文档间基本同步到位。
- 验收标准可判定：需求规格 §1.3 专门给出了"不可验收 vs 可验收"的对照写法，DoD（§1.4）把合规出口、配额三段式、埋点纳入完成定义。
- 风险是真实践过的：腾讯云人体关键点下线、RMBG-2.0 非商用许可、AI 标识元数据被 CDN 剥离，都是调研中实际撞出来的坑，文档如实记录并改了方案。
- 对代理指标的诚实：明确写出"预约 ≠ 付费"、V1 不收费意味着付费意愿无法被证伪（产品方案 §7.2.3、TD-28），没有自欺欺人。
但交叉比对发现：v6.0/v1.1/v1.2 这轮大改版在"定性结论"上同步得很好，在"定量数字"上留下了不少残留矛盾。下面按严重程度分三级列出。
1. P0：事实性冲突与错误（评审前必须修正）
这类问题是"两个文档对同一事实给了不同答案"，不修正则下游（开发、测试、财务）必有一方做错。
P0-1 V1 成本封顶的数字算不平（最重要的一条）
位置：产品方案 §5.2.1、§5.3.1；技术架构 §13
- 产品方案 §5.3.1：「月度 AI 总成本（MAU 15 万口径）≤ ¥12 万/月」，「单免费用户月度 AI 成本 ≤ ¥8」，并声称「月度成本上限 = MAU × 单用户配额成本上限，是可以事前算准的确定值」。架构 §13 复述了同一口径。
- 但 15 万 × ¥8 = ¥120 万，与 ¥12 万相差 10 倍。两个数字不可能同时成立。
- 再验算 ¥8 本身：按配额表基础额度（每日 3 次换装 ×¥0.5 + 3 次发型 ×¥0.2 + 10 轮对话 ×¥0.05 ≈ ¥2.6/日），若用户每日用满，月成本约 ¥78；若按硬上限（8+6+40 次）算是 ¥246/月。¥8 只有在"月均活跃约 3 天"的使用率假设下才成立，但这个假设没有写在任何文档里。
- 后果：这是 V1 唯一的财务锚点，且文档把它定性为"由配额硬性决定的确定上限"。按文中公式算出来的真硬上限（百万级/月）与文中给出的 ¥12 万相差两个数量级，"成本可事前算准"这个论证目前不成立。
建议：把两个口径分开写清楚——① 真·硬上限 = MAU × 配额硬上限 × 单次成本（数字会很大，但它才是"确定值"）；② 预期成本 = 硬上限 × 使用率假设（把活跃天数/功能渗透率的假设显式写出来，并标注为假设）。¥12 万和 ¥8 按口径②重新推导或修正。
P0-2 诊断维度数：技术架构文档仍写 34 项
位置：技术架构 §6.2（pf_diagnosis 行注释「34 个诊断维度」）、§6.3（「34 个诊断维度用 JSONB 存储」）
TD-31 已决定维度由 34 减为 32（删除五行分布、幸运色），美学报告 §4、需求规格 FR-RPT-06、README §0.1/§5、任务拆解 T-P0-25/T-P3-06 均已同步为 32，只有技术架构文档两处遗漏。这是"本轮决策同步"的明确漏网之鱼。
P0-3 性能指标至少四处互相矛盾
同一指标在不同文档给出不同数值，且需求规格 §4.1 并未被其他文档遵守为单一事实源：
| 指标 | 需求规格 §4.1 / 架构 §12.1 | 产品方案 §8.3.1 | 模块文档 | 冲突 |
|---|---|---|---|---|
| 初级报告 P95 | < 90s（NFR-PERF-03） | < 60s | 美学报告 §10.2：< 60s | 90 vs 60 |
| 全面报告 P95 | < 180s（NFR-PERF-04） | < 5min（300s） | 美学报告 §10.2：≤ 5min | 180 vs 300 |
| 换装出图 P95 | < 40s（NFR-PERF-05，不含排队） | < 320s | 产品方案 §2.1.1：前端超时 ≥ 320s | 40 vs 320 |
| Agent 整轮 P95 | < 8s（NFR-PERF-02） | — | 穿搭 Agent §7.1/§8.3：< 15s | 8 vs 15 |
| 系统可用性 | ≥ 99.5%（NFR-REL-01、架构 §12.1） | > 99.9% | — | 停机预算差 5 倍 |
换装一条特别需要说明：40s 与 320s 可能分别是"改造后目标"与"当前接口现实"，但没有任何文档写明这层关系，FR-TRY-01 的验收标准（p95 < 40s）按现有接口实测很可能直接不达标。
建议：性能指标只保留需求规格 §4.1 一处定义，其余文档改为引用；换装/发型补充"现状基线（T-P0-13/14 实测）→ 目标值"的两段式表述。
P0-4 记忆注入的 token 预算有两套互相矛盾的口径
位置：产品方案 §2.4.2、用户系统 §3.8、穿搭 Agent §3.5.2 vs 需求规格 FR-MEM-04、架构 §7.2、穿搭 Agent §10.2、任务拆解 T-P3-17
- 口径 A（≤1400）：画像 ≤250 + 偏好 ≤150 + 事件召回 ≤200 + 会话 ≤800（产品方案、用户系统、Agent §3.5.2 一致）。
- 口径 B：架构 §7.2 与 Agent §10.2 的预算表为「画像摘要 ≤500、会话摘要 ≤400」（总输入 ≤3700 的分解）；FR-MEM-04 验收标准写「注入 token ≤ 500」，T-P3-17 照抄。
- 直接冲突点：会话摘要 800 vs 400；记忆注入合计 1400 vs 500。验收标准（FR-MEM-04）与需求原文（用户系统 §3.8）不一致，测试不知道该按哪个写。
建议：在架构 §7.2 定义唯一的预算分解（建议明确"记忆注入预算"与"总输入预算 3700"的包含关系），FR-MEM-04 与其余文档全部引用该处。
P0-5 人脸原图保留期：2 小时 vs 24 小时
位置：合规方案 §2.1.2/§4.1、CR-02、架构 §7.1/§11.2、任务拆解 T-P1-27 = ≤ 2 小时；产品方案 §7.1.3、美学报告 §9.1 = ≤ 24h 仅用于任务重试
这是合规红线参数，两套说法直接冲突。"24h 用于任务重试"与"处理后显式删除、桶级 2 小时兜底"是两种不同的设计（前者意味着原图要留存到任务结束）。按"下层优先"原则应以合规方案/CR-02 的 2 小时为准，修正产品方案与美学报告；若确实需要重试窗口，则合规方案要补充论证。
P0-6 配额流水类型：两处写"两种"，两处写"三种"
位置：需求规格 §2.9 架构约束、产品方案 §3.3 = V1 只用 system_grant + consume 两种；用户系统 §2.4.2、架构 §6.2 = system_grant / consume / refund 三种
refund 是预扣三段式（FR-BILL-05）的必需类型，需求规格与产品方案的表述属于漏写。按"表结构真相在架构"的原则，应以三种为准，修正需求规格 §2.9 与产品方案 §3.3。
P0-7 美学报告文档内的价格残留（与同节注释自相矛盾）
位置：美学报告 §2.5、§2.1
- §2.5 正文 bullet 仍写「预览卡片（模糊化目录截图 + 内容清单 + 预计价格）」、埋点记录含「点击价格档位」；紧随其后的 ⚠️ 注释明确说这两项"已移除"。同一节内自相矛盾。
- §2.1 分级总览表「价格」行仍写全面报告「单次 ¥29.9」，与 §2.5「全部为占位草案，待定」及"V1 全线不出现价格"的纪律（FR-BILL-07、TD-28）冲突。
建议：删除 §2.5 正文中的「预计价格」「点击价格档位」，§2.1 的 ¥29.9 改为"待定（V2 按真实数据定价）"。
P0-8 全面报告"40+ 项维度"与 32 项维度字典矛盾
位置：产品方案 §2.2.1（「8 项核心 / 40+ 项完整」）、美学报告 §2.1（同）vs 美学报告 §4 维度字典（共 32 项）、README §5
字典总共 32 项，全面报告不可能覆盖 40+ 项。这是五行模块移除（34→32）之前就遗留的旧口径。另外"初级 8 项核心"与字典中初级打 ✅ 的维度数（约 15 项）也对不上——建议把分级表改为"初级覆盖 X 项 / 全面覆盖全部 32 项"的准确口径，或明确"8 项"指的是首屏核心展示数。
P0-9 语音输入在穿搭 Agent 文档中被列为 P0
位置：穿搭 Agent §2.2（P0 能力范围含「文字对话（语音输入转文字）」）、§2.1（能力总览「文字/语音多模态输入」标 P0）
FR-AGT-17 与 TD-14 均明确语音输入为 P1 / V2（Core Speech Kit），本文 §9.1/§9.2 的阶段划分也把语音放在 Phase 2。§2.2 属于改版残留，与需求规格直接冲突。
P0-10 画像/记忆/同意的数据结构与规则在架构与用户系统间不一致
位置：技术架构 §6.2、§8.4 vs 用户系统 §2.2、§3.3、§3.5
| 项 | 架构文档 | 用户系统文档 |
|---|---|---|
pf_memory.status 枚举 |
active / pending_confirm / archived / rejected | active / pending_confirm / decayed / overridden / deleted |
pf_memory.source 枚举 |
explicit / implicit / report / behavior | explicit_user_input / user_setting / report_vision / self_reported / behavior_inferred / llm_extracted |
| 显式陈述初始置信度 | 0.95（§8.4） | 0.90（§3.5；产品方案 §2.4.2 同为 0.9） |
| 同意类型枚举 | terms / privacy / face / minor | 隐私政策 / 人脸 / 个性化推荐 / 推送通知 |
| 手机号存储 | id_user 字段清单中无 phone，id_user_identity 仅示例 huawei |
用户主表含 phone（加密存储） |
其中同意类型枚举的偏差有合规后果：用户系统 §3.10 要求记忆写入建立在「个性化推荐」授权之上，但架构的 id_consent 枚举里没有这一项。建议以用户系统文档的语义为准修订架构 §6.2，并补齐手机号的存储位置说明。
P0-11 准确率门槛两套数值
位置：FR-RPT-05 与 T-P0-10/11（体型 ≥80%、季型 ≥75%）vs 美学报告 §9.4、产品方案 §8.3.3（体型 ≥85%、季型 ≥80%）；FR-AGT-02（意图识别 ≥85%）vs 穿搭 Agent §8.2（>90%）
可能是"Phase 0 验证门槛"与"上线质量门槛"的区分，但没有任何文档写明这层关系。建议显式标注两档（如：验证门槛 80/75，上线门槛 85/80），否则 Phase 0 验收与上线验收会打架。
2. P1：覆盖缺口（需求 → 任务反查发现）
按任务拆解 §9.3 的要求做了 P0/CR 需求反查，以下缺口会直接影响执行：
P1-1 手机号验证码登录：无开发任务、无短信通道选型（最实际的缺口）
- FR-ACC-04 是 P0/V1（登录兜底通道），但任务拆解 Phase 1 §3.2（T-P1-11~18）只有华为账号登录任务，没有手机号验证码任务。
- 更大范围看：技术选型 31 项决策中没有短信服务商选型；架构 §2 外部依赖表与系统上下文图均无短信通道；成本模型 §13 未计短信成本；NFR-SEC-05 防刷未提短信轰炸防护。
- 建议：补一项短信通道选型决策（TD-32）+ 一个开发任务（验证码下发、校验、限频、防刷），并在外部依赖表中登记降级策略。
P1-2 全面报告「预约留资」入口无 WBS 任务
产品方案 §2.2.3 与 §6.1.2 均要求 V1 做「全面报告预约入口 + 埋点」，这是 V1 唯一的商业化验证指标（预约率 ≥8% 决策门槛）的数据来源；FR-RPT-15 验收标准也含"V1 仅做预约留资"。但任务拆解 Phase 3（T-P3-01~20）没有对应任务。漏掉它，V1 上线后连"要不要做付费报告"都回答不了。
P1-3 会员页静态展示 + 「上线提醒我」留资：无 FR、无任务
产品方案 §2.8（🅿️ 区）与 §3.4 均要求 V1 交付，但需求规格中无对应 FR 编号，WBS 无任务。建议补 FR-BILL-xx（或 FR-ACC-07 扩展）与 Phase 5 任务。
P1-4 报告结论的反馈与修正入口无 FR
产品方案 §8.1.2/§8.1.4 的核心质量指标——报告结论认同率 >70%、结论修正率 <15%——依赖"用户主动确认/修正"的采集入口（美学报告 §7.2「不准？修正一下」、§9.4 反馈入口）。需求规格中没有对应 FR（FR-RPT-10 的验收不含此项），WBS 中 T-P4-11 只覆盖 Agent 反馈。指标没有数据来源就等于没有指标。
P1-5 游客配额未进入配额表，FR-ACC-02 验收不可判定
游客额度（1 次换装 / 1 次试戴 / 1 次报告 / 3 次对话）只出现在产品方案 §2.4.1 与用户系统 §2.1 的叙述中，没有进入配额表（产品方案 §3.2 / 用户系统 §2.4.1 均只有注册用户行），违反自定的"单一事实来源"纪律。同时 FR-ACC-02 的验收标准「体验流程中被允许的部分」不可判定，建议把游客额度补入配额表并在 FR-ACC-02 引用。
P1-6 天气数据源完全未选型
Agent 的意图类别含「天气适配」（穿搭 Agent §3.2）、典型场景 §4.4 直接演示"明天 15 度有雨怎么穿"、知识库场景实体含温度带映射（§3.2 ⑥）、L0 城市字段的用途写明"天气定位"——但全部文档中没有天气 API 的来源、选型与成本说明。V1 的 Agent 要回答天气类问题就需要它。建议补一项选型决策（或明确 V1 天气问题降级为"让用户告知天气"）。
P1-7 「清空照片」入口无 FR
用户系统 §2.6 与产品方案 §2.4.1 均承诺"清空照片"作为账号生命周期能力，需求规格无对应 FR（FR-ACC-09 注销、FR-ACC-10 导出之外缺少"清空照片"），合规检查清单 §5.3 也未覆盖。涉及人脸数据删除，建议补 FR 并纳入合规清单。
P1-8 配额模型中 bl_quota 与 bl_wallet/bl_ledger 的关系未说清
架构 §6.2 同时存在周期配额表（bl_quota + bl_quota_rule）与余额账本（bl_wallet + bl_ledger），§7.4 校验公式为 bl_quota.used < limit_value + task_bonus——但 task_bonus 从哪里来（是 bl_ledger 中 system_grant 的周期聚合？）、bl_wallet.balance 在 V1 纯配额模式下代表什么，没有定义。两套机制并存但职责边界模糊，开发时会卡住。建议在架构 §7.4 补一段"V1 配额判定数据流"的明确说明。
P1-9 两个编号/归属问题
- TD-00 被引用但从未定义：需求规格 FR-TRY-01 依赖列写「TD-00 改造」、架构 §4.4 写「（TD-00 前提）」，但技术选型报告的决策总表从 TD-01 开始。§0「已确认的项目前提」中的"换装/发型服务自有可控"应编号化为 TD-00。
- CR-11 日志留存 ≥6 个月无明确落地任务（T-P1-08 只含日志脱敏，CLS 留存周期配置无人认领），建议在 T-P1-04 或 T-P1-08 的验收标准中补上。
3. P2：一致性与维护性问题（不阻塞评审，但应一并修）
| # | 问题 | 位置 | 说明 |
|---|---|---|---|
| P2-1 | 五份文档头部版本号滞留 v1.0 | 需求规格、技术架构、技术选型、合规方案、任务拆解的页首 | 五份文档的变更记录均已升至 v1.1，README §8 也按 v1.1 引用，但页首仍写 v1.0。本轮新增的五份文档全部中招，建议统一刷新 |
| P2-2 | README §8 遗漏一份文档 | README §8「九份文档全部更新」 | 内容文档实为 10 份，表格 9 行漏了《穿搭 Agent-需求文档》（当天同样更新至 v1.2） |
| P2-3 | 文档状态口径不一 | README §7 vs 各文档页首/页尾 | README 写「产品需求已定稿」，但产品方案、美学报告、用户系统、知识库、Agent 五份文档自身状态均为「待评审」 |
| P2-4 | "点数/扣点/计费"措辞残留 | 合规 §2.4.1（"不消耗点数/退点"）、架构 tk_task.points_reserved 字段名、架构 §7.1（"不重复扣点"）、FR-TASK-05、TD-11、产品方案 §2.7（"不重复计费"）、TD-23 埋点清单含"点数消耗/付费页曝光/下单/支付成功" |
V1 已统一为"配额"语义，这些 V2 词汇残留会造成实现期误解；TD-23 的 V2 事件建议标注版本 |
| P2-5 | 枚举计数错误 | 知识库 §3.1 ⑤「8 脸型映射」vs 详情与美学报告 §4 均为 7 种脸型；§3.2 ④「局部特征 12 项」实际列了 13 项 | 小数字错误，但这类错误多了会损害文档可信度 |
| P2-6 | 知识库规模口径需单一事实源 | 单品：知识库 §3.1「冷启动 800 |
产品方案 §2.5.2 的"第一版目标量级"列与 §2.8 直接矛盾；知识库 §9 表格与其自己的分期建议矛盾。建议统一为：V1 = 规则 400 / 单品 300 tryon_ready / 方案 100，长期目标另列 |
| P2-7 | 黄金集规模口径需分列 | 知识库 §7「200 条」、美学报告 §9.4「100 例」、FR-KB-11「≥100」、FR-AGT-05「100 例」、FR-RPT-07「30 例」、产品方案 §6.1.2「200 条」、知识库 §5.1.1「100~200 例」 | 各数字可能对应不同子集（检索/规则/Agent/报告），但没有一处说清。建议在 FR-KB-11 或知识库 §7 定义各子集规模，其余引用 |
| P2-8 | 若干净期承诺与"按产能倒排"原则冲突 | 产品方案 §4.3.3「1-2 个月上线 MVP」、§6.1 标题「Phase 1：MVP（1-2 个月）」、§9.3「1 个月内…正式上线」 | 本轮已把排期原则改为"不按人日估算、按实测产能倒排"（知识库 §5.1 还专门删了"3~4 周"估算），这几处时间盒是改版前残留，建议改为以里程碑出口条件表述 |
| P2-9 | 其他小项 | ① 架构 §12.2 容量基线 1 万 DAU < 产品方案 §8.1.1 目标档 DAU 2 万，建议对齐或说明假设；② 穿搭 Agent §7.1「1000+ 并发对话」相对容量基线缺乏依据；③ FR-TASK-04「推送到达率 ≥90%」未定义分母（全体用户还是已授权用户，TD-17 指出通知授权默认关闭）；④ 产品方案 §9.1.4 仍列「市场数据信源补齐」待办、§10.4.1 仍挂三条"待确认"行业报告，与 §4.1 已完成信源替换矛盾；⑤ 美学报告 §2.1「首次不限」与配额表「首次 1 次（终身）」措辞歧义；⑥ README §0.3「其余 20 项决策」与产品方案 §11.1 实际 21 行；⑦ 任务拆解 §1 依赖图中 M4 编号同时指"换装/发型"与"Agent 对话"两块，易误读；⑧ 需求规格 §1.3 示例（p95 < 90s）与产品方案 §2.2.1（≤60s）矛盾，同 P0-3 | — |
4. 修订建议与处理顺序
第一优先（评审会前）：P0-1（成本口径）与 P0-3（性能指标）。这两条会被任何认真读文档的人第一时间发现，且都涉及"哪个文档是单一事实源"的问题——正好借修订把纪律落实：
| 事实 | 建议的唯一定义位置 | 其余文档 |
|---|---|---|
| 性能指标 | 需求规格 §4.1 | 产品方案 §8.3.1、各模块文档改为引用 |
| 配额数值（含游客） | 产品方案 §3.2 | 用户系统 §2.4.1 引用 |
| Token 预算 | 架构 §7.2 | FR-MEM-04、Agent §3.5.2/§10.2、用户系统 §3.8 引用 |
| 诊断维度数与字典 | 美学报告 §4 | 架构 §6.2/§6.3、README §5 引用 |
| 知识库规模目标 | 知识库 §9 | 产品方案 §2.5.2/§2.8 引用 |
| 黄金集规模 | 知识库 §7 或 FR-KB-11 | 其余引用 |
| 准确率门槛 | 美学报告 §9.4（区分验证档/上线档） | FR-RPT-05、产品方案 §8.3.3 引用 |
| 人脸原图保留期 | 合规方案 §2.1.2 / CR-02 | 产品方案 §7.1.3、美学报告 §9.1 引用 |
第二优先（进入开发前）：P1-1（短信通道）、P1-2（预约留资任务）、P1-8（配额数据流）。这三项会直接卡住开发或让 V1 失去关键数据。
第三优先（随下一轮文档更新）：P0 其余项与全部 P2。建议按 README §6 的变更留痕规范逐份修订并登记。
流程建议：把"数字一致性走查"加入文档评审 checklist——本轮的问题高度集中在数字（维度数、预算数、成本数、性能数、规模数），人工通读很难避免，建议在每次大改版后专门做一次"同一数字全局搜索"（如搜 34、500、1400、90s、300）。
5. 附：评审覆盖清单
| 文档 | 版本（自称） | 实际应为 | 主要问题分布 |
|---|---|---|---|
| README | — | — | P2-2、P2-3、P2-8⑥ |
| 产品方案 | v6.0 | v6.0 ✓ | P0-1、P0-3、P0-4、P0-5、P0-6、P0-8、P2-4、P2-6、P2-8、P2-9 |
| 需求规格说明 | v1.0（页首滞留） | v1.1 | P0-3、P0-4、P0-6、P0-11、P1-1~P1-7、P2-1 |
| 美学报告-需求文档 | v1.2 | v1.2 ✓ | P0-5、P0-7、P0-8、P0-11、P2-9⑤ |
| 穿搭Agent-需求文档 | v1.2 | v1.2 ✓ | P0-3、P0-4、P0-9、P0-11、P2-9② |
| 用户系统与记忆系统-需求文档 | v1.2 | v1.2 ✓ | P0-4、P0-6、P0-10（作为正确口径基准） |
| 美学知识库-建设方案 | v1.2 | v1.2 ✓ | P2-5、P2-6、P2-7 |
| 技术架构文档 | v1.0（页首滞留） | v1.1 | P0-1、P0-2、P0-3、P0-4、P0-10、P1-8、P1-9、P2-1、P2-4、P2-9① |
| 技术选型与调研报告 | v1.0（页首滞留） | v1.1 | P1-1（缺短信选型）、P1-6（缺天气选型）、P1-9（TD-00）、P2-1、P2-4 |
| 合规与安全方案 | v1.0（页首滞留） | v1.1 | P0-5（作为正确口径基准）、P2-1、P2-4 |
| 开发任务拆解 | v1.0（页首滞留） | v1.1 | P1-1、P1-2、P1-3、P1-4、P1-9、P2-1、P2-9⑦ |
评审人：AI 辅助评审 说明：本报告仅基于文档文本的交叉比对，未验证文档与真实世界的一致性（如备案材料内容、接口实际表现）。P0-1 涉及的成本推算过程已在 §1 中给出算式，修订时可直接复算。