目的: 整理仍需和产品/相关方确认的问题，按紧急度排序，用于下次产品对齐会议
高优先级（阻塞开发排期）
Q1. Phase 1 & Phase 2 时间节点 + 团队分工
- 问题: Phase 1（FAB → Zand 迁移）和 Phase 2（Salary Credit 功能）的具体时间节点是什么？Native Team 何时介入？Mini-program 由谁开发？
- 背景: 产品回复中明确了 mini-program 是核心交互载体，但未指定开发团队和时间线
- 负责人: @Raj / 产品
- 影响: 阻塞所有前端和 mini-program 的排期
Q2. Batch 2 & Batch 3 用户数量 + Zand API TPS
- 问题: 存量非活跃 IBAN 用户（Batch 2）和无 IBAN 用户（Batch 3）各有多少？可能达到百万级别？
- 背景: 产品回复标注"TBC - Qian to check data"。如果量级很大，需提前和 Zand 确认 Create VA API 的 TPS 限制和批量调用策略
- 负责人: @Qian.Wang（查数据）/ Zand（TPS 确认）
- 影响: 影响批量创建模块的架构设计（是否需要限流、队列、分片等）
Q3. Checkout 页面是否 Phase 1 需要改动
- 问题: 原设计中 Checkout 页面展示新 IBAN 是存量用户迁移的"硬依赖"。但产品回复中只提到 Payment Settings + mini-program，未提及 Checkout。Phase 1 是否需要改 Checkout？
- 背景: 如果 Phase 1 不改 Checkout，可以解除这个硬依赖，减少开发范围
- 负责人: @Raj / 产品
- 影响: 直接影响 Phase 1 开发范围和关键路径
中优先级（阻塞前端开发或需技术确认）
Q4. 通知文案 & ToDo Card UI 交付时间
- 问题: 通知文案和 ToDo Section UI 何时可以提供？
- 背景: 产品回复说由 @xiaoyu 负责提供，但未给出具体时间
- 负责人: @xiaoyu / 产品
- 影响: 阻塞通知模块和 ToDo Card 的前端开发
Q5. Mini-program 设计稿交付时间
- 问题: 迁移详情 mini-program 的设计稿何时提供？
- 背景: 产品回复说"The design of this mini-program and ToDo section will be shared"，但未指定时间
- 负责人: @Raj / Design Team
- 影响: 阻塞 mini-program 开发启动
Q6. PayBy 用户 vs Botim 用户的区别处理
- 问题: 迁移过程中 PayBy 用户和 Botim 用户是否需要区别处理？
- 背景: 原设计标注"Not Sure"，产品回复中完全未涉及此话题
- 负责人: @Raj / 产品
- 影响: 可能影响用户筛选逻辑和通知策略
Q7. personal → VISII 迁移技术细节
- 问题: 从 personal 迁移到 VISII 的具体技术方案是什么？
- 背景: 原设计提到需要 @Qian.Wang 确认，产品回复未涉及
- 负责人: @Qian.Wang
- 影响: VIS 侧架构依赖
Q8. 老 KYC 用户 1000万+ 的迁移口径
- 问题: 原设计提到"老 KYC 用户超过1000万，是否可以不迁移"。产品回复给出了分批策略，其中"非活跃用户（9个月无交易）不处理"。需确认：这1000万是否大部分落入"非活跃"类别？如果不是，Batch 2/3 的量级会非常大
- 负责人: @Raj / @Qian.Wang
- 影响: 影响迁移总量评估和系统容量规划
低优先级（Phase 2 或可后续跟进）
Q9. FAB 关闭方式
- 问题: FAB 下线时，是冻结/注销 0040 FAB 账户，还是向 FAB 申请关闭 VAM 功能？
- 背景: 原设计标注了两种选项，未确认
- 负责人: @jiayu.zhang
- 影响: Phase 2 操作，不阻塞当前开发
Q10. 商户通知策略具体方案
- 问题: 商户迁移的通知策略具体是什么？多次提醒的频率和内容？
- 背景: 产品说交给 Merchant Team 决定，需要他们给出结论
- 负责人: Merchant Team / BD
- 影响: 不阻塞商户侧开发，但需要在 Pilot 前确认
产品回复中新增的 TODO（产品侧待办）
这些是产品方在回复文档中自己标注的 TODO，需要跟踪：
| # | TODO | 负责人 | 状态 |
|---|---|---|---|
| T1 | 提供 mini-program 设计稿和 ToDo Section UI | @Raj / Design | 待交付 |
| T2 | 提供通知文案（In-app + ToDo Card） | @xiaoyu | 待交付 |
| T3 | 确认 Phase 1 & Phase 2 时间节点 | @Raj | 待确认 |
| T4 | 确认 Native Team 介入时间 | @Raj | 待确认 |
| T5 | 确认 mini-program 开发者 | @Raj | 待确认 |
| T6 | 提供 Batch 2/3 用户数量 | @Qian.Wang | 待查数据 |
| T7 | 通知发送者和时间确认（"who & when will send the notifications"） | @xiaoyu / 产品 | 待确认 |
| T8 | 联系 TIANBO ZHOU (TZ) 创建 ToDo Card 模板 | 技术侧 | 待执行 |
建议的跟进计划
- 本周内：拉齐 Q1 ~ Q3（高优先级），确定开发范围和排期
- 下周：拉齐 Q4 ~ Q8（中优先级），确保设计稿和文案到位
- 迁移 Pilot 前：确认 Q9 ~ Q10（低优先级）
- 持续跟踪：产品侧 TODO（T1 ~ T8）