需求分析文档

项目名称： 千乘坊（ride-loop）
文档状态： 草稿
负责人： 主要读者： 架构 | 开发 | 测试 | 项目经理
上游输入： 头脑风暴记录 | PRD | 当前业务约束
下游输出： 架构设计 | 实施计划 | 测试策略
关联 ID： REQ-001 - REQ-018, NFR-001 - NFR-004, RISK-001 - RISK-004
最后更新： 2026-03-29

1. 分析目标

• 这份文档要解决什么判断问题：判断双主线 MVP 在武汉单城、多服务、统一司机账户和站内资金闭环约束下是否可行，以及需求之间的依赖和风险顺序。
• 这份文档输出给谁使用：架构师用于拆模块与接口；开发用于排实施顺序；测试用于构建跨流程验证路径。

2. 核心流程拆解

流程	关联需求	关键参与者	风险点
司机二维码导流到商城下单支付	REQ-001, REQ-002, REQ-003, REQ-004	司机、乘客、支付系统	归因丢失、支付回调幂等、返佣延迟
司机专区站内复购	REQ-004, REQ-005	司机、商城系统	台账与订单不一致、退款冲抵复杂
司机返现券转赠	REQ-004, REQ-011, REQ-013, REQ-018	发送司机、接收司机、消息系统	锁券超时、错误领取、转赠滥用
乘客叫车到派单接单	REQ-001, REQ-002, REQ-006, REQ-007	乘客、司机、调度服务	单城服务边界、司机在线态不一致
行程完成支付与收益拆分	REQ-004, REQ-008, REQ-010	乘客、履约司机、引流司机	履约收益与分销收益错分、退款对账
运营后台配置与审计	REQ-009, REQ-010	运营、财务	规则误配、审计链不完整

3. 需求优先级与依赖

需求 ID	业务价值	实施复杂度	依赖项	建议迭代
REQ-001	高	中	无	迭代 1
REQ-002	高	中	REQ-001	迭代 1
REQ-003	高	中	REQ-002	迭代 1
REQ-004	高	高	REQ-003, REQ-008	迭代 2
REQ-005	中	中	REQ-004	迭代 2
REQ-006	高	中	REQ-001, REQ-002	迭代 1
REQ-007	高	高	REQ-006	迭代 1
REQ-008	高	高	REQ-006, REQ-007	迭代 2
REQ-009	高	中	REQ-003, REQ-004, REQ-006, REQ-008	迭代 3
REQ-010	中	中	REQ-004, REQ-007, REQ-008	迭代 3
REQ-018	中	中	REQ-004, REQ-011, REQ-013	迭代 2

4. 可行性分析

需求 ID	技术可行性	风险	说明
REQ-001	高	中	统一账户是首版的必要简化，有利于后续权限扩展
REQ-002	高	中	二维码归因方案成熟，但需防止归因窗口与订单映射丢失
REQ-003	高	中	商城订单流程常规，但需与归因、支付、返佣联动
REQ-004	中	高	钱包与逆向台账是资金核心，需优先做账务建模
REQ-005	高	中	司机专区消费本质是商城子域，关键在支付抵扣顺序
REQ-006	中	中	单城叫车模型可控，但路线、定价与地图服务尚未确定
REQ-007	中	高	调度服务独立可行，但当前环境没有本地 Go，需要容器化策略
REQ-008	中	高	履约司机与引流司机分离会提升账务与状态协调复杂度
REQ-009	高	中	后台配置边界清晰，首版重点是规则与查询，不做复杂 BI
REQ-010	高	中	审计与对账可先以订单与台账关联实现
REQ-018	中	中	券转赠可行，但必须引入锁券、领取和审计模型，避免同券重复使用

5. 关键约束

• 业务约束：
• 司机返现只能站内循环，不支持提现。
• 武汉单城先跑通，不做跨城调度。
• 履约司机和引流司机可不是同一人。
• 司机接单能力与司机分销/消费能力不宜绑定在同一终端载体上。
• 数据约束：
• 主订单与台账真相必须集中在主业务数据库中。
• 调度服务只管理短态与匹配过程，不拥有最终订单事实。
• 性能/容量约束：
• 乘客调用需要优先优化响应时间。
• 派单流程必须比商城流程更重视实时性。
• 集成约束：
• Node.js + Stratix 为主业务后端框架方向。
• Go 负责派单调度服务。
• PostgreSQL + Redis 为固定基础设施组合。

6. 对设计与测试的影响

• 对架构的影响：
• 需要将订单真相与调度短态显式分离。
• 需要设置独立资金子域，至少在逻辑上把钱包和佣金台账集中建模。
• 需要在券模型中增加“当前持有人、转赠锁定、领取超时和转赠审计”能力。
• 对接口设计的影响：
• 所有支付和派单相关接口需要幂等键和状态机约束。
• 需要内部接口明确区分同步指令和最终事实确认。
• 需要新增券转赠发起、领取、取消与记录查询接口。
• 对测试策略的影响：
• 必须覆盖商城闭环、出行闭环、退款冲抵、调度超时重派四条主回归链。
• 必须有跨服务契约测试，尤其是 platform-core 与 dispatch-engine。
• 必须覆盖手机号定向转赠、微信分享领取、转赠超时回退和错误领取拦截。

7. 未决问题与建议

• 未决问题：支付渠道、路线估价和司机重端在线状态上报协议尚未细化。
• 建议 1：前端产品按“乘客小程序 + 司机小程序 + 司机 App + 运营 Web”分开建模。
• 建议 2：编码阶段先交付“下单/叫车 -> 支付 -> 台账/订单状态闭环”，再优化调度策略。
• 建议 3：在设计阶段提前定义统一错误码和幂等规则，避免跨服务接口返工。
• 建议 4：进入实现前，把技术选型文档里 Stratix 可安装版本再核实一次，并固化为 ADR。

8. 变更记录

日期	变更内容	变更人
2026-03-29	初始版本
2026-03-29	补充 REQ-018 券转赠需求的可行性与风险分析