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

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

Co-authored-by: Cursor <cursoragent@cursor.com>

docs/文档评审报告-2026-08-13.md

@@ -0,0 +1,230 @@
+# 「美搭」文档体系评审报告
+
+> 评审日期：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~1500」、§9「长期 800 / V1 硬指标 300」、产品方案 §2.5.2「800 条（≥400 可试穿）」、§2.8「300 件」；规则：知识库 §3.1「800~1200」、§9 表「第一版 800」、§9 文末分期「V1 400」、产品方案 §2.5.2「800」、§2.8「400」 | 产品方案 §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 中给出算式，修订时可直接复算。