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

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

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

docs/技术选型与调研报告.md

@@ -1,6 +1,6 @@
 # 技术选型与调研报告
 
-> 版本：v1.0　｜　调研截止日期：2026-08-13　｜　状态：已定稿（可执行）
+> 版本：**v1.2**　｜　调研截止日期：2026-08-13　｜　状态：已定稿（可执行）
 >
 > 本文的作用是把散落在各需求文档中的「待确认事项」一次性收口。每一条都给出：**结论 → 理由 → 备选方案 → 触发切换的条件 → 信源**。
 >
@@ -17,7 +17,7 @@
 
 | 前提 | 取值 | 对架构的影响 |
 | --- | --- | --- |
-| 换装/发型服务归属 | **自有服务，源码可控，可改造** | 可以把它从「黑盒 HTTP 接口」升级为「受管控的内部推理服务」：加鉴权、改异步回调、独立扩容、埋成本点 |
+| 换装/发型服务归属（**编号为 `TD-00`**） | **自有服务，源码可控，可改造** | 可以把它从「黑盒 HTTP 接口」升级为「受管控的内部推理服务」：加鉴权、改异步回调、独立扩容、埋成本点。改造要求见架构 §4.4，被 `FR-TRY-01` 等需求依赖 |
 | 团队规模 | 4~6 人（前端 + 后端 + 算法 + 产品/设计） | 不上微服务。V1 采用**模块化单体 + 独立 AI 能力服务**的两层结构 |
 | 后端技术栈 | **全 Python（FastAPI）** | 业务与 AI 同栈，模型侧代码可直接复用，无跨语言序列化成本 |
 | 云厂商 | **腾讯云为主** | 存储、审核、人脸能力优先用腾讯云；不足处允许跨云补齐（见 `TD-05`） |
@@ -33,6 +33,7 @@
 
 | 编号 | 议题 | 结论 | 状态 |
 | --- | --- | --- | --- |
+| **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 | 已定 |
@@ -64,6 +65,8 @@
 | TD-29 | 企业开发者资质 | V1 不依赖（不接 IAP）；一键登录降级为 P1 | 已定 |
 | TD-30 | 市场数据信源 | 已替换为国家统计局 / CNNIC / 华为 HDC 官方数据 | 已定 |
 | TD-31 | 五行/命理模块 | **不做**（V1 与 V2 均不纳入） | 已定 |
+| **TD-32** | **短信验证码通道** | 腾讯云短信（SMS），与云厂商收口一致 | 已定，V1 必需 |
+| **TD-33** | **天气数据源** | **V1 不接天气 API**，改为「用户告知 + 季节推断」降级 | 已定，V2 再评估 |
 
 ---
 
@@ -324,7 +327,7 @@
 
 **必须实现的能力**（这些是长耗时任务产品化的地基，不是可选项）：
 
-- **幂等**：任务以业务幂等键（如 `tryon_task_id`）去重，重试不会重复扣点数、不会重复出图。
+- **幂等**：任务以业务幂等键（如 `tryon_task_id`）去重，重试不会重复扣减配额、不会重复出图。
 - **状态机**：`pending → running → succeeded / failed / cancelled / timeout`，状态变更落库并可查询。
 - **超时与重试**：区分可重试错误（网络、限流）与不可重试错误（输入非法、审核拒绝），后者立即失败并**退还点数**。
 - **进度上报**：给前端可展示的阶段（排队中 / 分析中 / 生成中 / 后处理中）与预估剩余时间。
@@ -348,7 +351,11 @@
 
 **理由**：需求文档里的漏斗指标（报告触发率、完成率、付费转化率）都是明确的、有限的、可预先定义的聚合，不需要即席探索能力。当指标需求变成「随时切任意维度」时再引入 ClickHouse。
 
-**必须从第一天就埋的事件**（漏斗断点一旦漏埋，数据就永远补不回来）：注册、授权同意、拍照上传、报告触发、报告完成、报告页各模块曝光与展开、分享、Agent 会话开始/轮次/满意度、换装发起/成功/失败、点数消耗、付费页曝光/下单/支付成功。
+**必须从第一天就埋的事件**（漏斗断点一旦漏埋，数据就永远补不回来）：
+
+**V1 必埋**：注册、授权同意、拍照上传、报告触发、报告完成、报告页各模块曝光与展开、**报告结论认同/修正**（`FR-RPT-19`）、分享、Agent 会话开始/轮次/满意度、换装发起/成功/失败、**配额消耗与退还**、**全面报告预约留资**（`FR-RPT-20`）、**会员页曝光与「上线提醒我」留资**（`FR-BILL-12`）、**熔断降级触发**。
+
+**V2 才有（V1 无对应功能，不埋）**：付费页曝光、下单、支付成功、点数购买。
 
 ---
 
@@ -534,6 +541,56 @@ cos://meida-report/      # 报告产物：长图/PDF，含 AI 标识元数据
 
 **实现取巧**：后台不做独立前端工程，用 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 已全部关闭）
@@ -558,7 +615,7 @@ cos://meida-report/      # 报告产物：长图/PDF，含 AI 标识元数据
 **结论**：**全职**，而非外部按条计酬或顾问入股。
 
 **理由**：
-1. **规则库不是一次性交付物，而是需要持续迭代的资产**。800 条规则写完只是起点，之后要根据用户反馈与结论修正率反复校准。按条计酬的外部顾问在"交付完成"后就没有继续投入的动力，而这恰恰是质量提升最关键的阶段。
+1. **规则库不是一次性交付物，而是需要持续迭代的资产**。V1 的 400 条规则写完只是起点（长期目标 800~1200 条，见知识库 §9.1），之后要根据用户反馈与结论修正率反复校准。按条计酬的外部顾问在"交付完成"后就没有继续投入的动力，而这恰恰是质量提升最关键的阶段。
 2. **顾问需要深度参与知识库后台的设计**。V1 就要做极简运营后台（`TD-25`），它的使用者就是顾问本人。全职顾问会天天用它，能持续反馈易用性问题；外部顾问只会在交付期短暂接触，很难提出有价值的改进。
 3. **黄金评测集的标注需要口径一致**。100~200 例样本若由多位外部顾问分批标注，口径漂移几乎不可避免，而黄金集是所有质量指标的基准，一旦口径不稳，后续的准确率数字就失去意义。
 
@@ -707,5 +764,6 @@ cos://meida-report/      # 报告产物：长图/PDF，含 AI 标识元数据
 
 | 日期 | 版本 | 变更 |
 | --- | --- | --- |
+| 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 项转入待业务输入 |