产品需求文档（PRD）

项目名称： 千乘坊（ride-loop）
文档状态： 草稿
负责人： 用户 主要读者： 产品 | 架构 | 开发 | 测试 | 业务方
上游输入： 头脑风暴记录 | 项目章程
下游输出： 架构设计 | 测试计划 | 实施计划
关联 ID： REQ-001 - REQ-018, NFR-001 - NFR-004, UAT-001 - UAT-030
最后更新： 2026-03-29

1. 背景与目标

背景

• 千乘坊的核心目标是把出租车司机从单次运费收入角色，升级为“接单履约者 + 分销渠道 + 站内消费者”。
• 平台需要同时承载本地生活商城与出行调度，形成司机引流、乘客消费、支付返利和司机复购的双闭环。

业务目标

• 在武汉单城跑通商城与出行双主线 MVP。
• 用统一司机账户支撑接单、分销、司机专区消费。
• 返现与返现券只保留在平台站内，不提供提现能力。
• 可转赠返现券支持司机之间站内转赠，提升券使用率和司机关系传播。

成功指标

指标	目标值	观测方式
商城闭环可跑通	达成	二维码归因、下单、支付、返佣、司机专区消费联调通过
出行闭环可跑通	达成	叫车、派单、接单、完单、支付、优惠联调通过
佣金入账准确性	100%	支付回调与佣金台账对账
司机身份统一	达成	同一账户完成三类业务动作

2. 用户与场景

用户角色	场景	核心诉求
乘客	扫司机二维码进入小程序购物	拿到优惠、下单顺畅、支付可靠
乘客	在小程序叫车	快速匹配附近司机、看到订单状态、获得优惠
司机-分销商	分享二维码导流	支付后可获得返佣、可追踪收益来源
司机-履约者	使用司机端接网约车订单	在线接单、明确状态、行程结算清晰
司机-消费者	在司机专区消费	使用站内余额或返现券购买刚需服务
商家/供应商	履约商品或服务	能接单、核销、处理售后
城市运营/调度运营	管理城市、司机、商品、规则和派单异常	配置灵活、可追踪、可人工干预
客服/财务/风控	处理工单、台账、异常与审计	可追查、可对账、可审计

补充说明：

• 端形态与司机端可行性分析见 terminal-strategy.md。
• 角色、业务模块和详细需求分解见 role-module-requirements.md。

3. 功能需求

REQ-001 统一账户与角色模型

• 优先级：P0
• 描述：平台必须支持统一司机账户，同一司机在一个身份体系内同时拥有接单司机、分销商、商城消费者三种能力。
• 用户故事：作为 司机，我希望 用一个账户完成接单、分销和站内消费，以便 不需要在多个系统之间切换。
• 前置条件：司机已完成平台入驻或身份绑定。
• 业务规则：
• 司机账户与乘客账户统一在同一身份域内管理。
• 同一自然人可同时具备司机和乘客视角，但权限边界分开控制。
• 司机与乘客共享用户基础信息，司机特有资料进入司机档案。
• 依赖项：无。
• 排除范围：多法人主体与跨平台账号打通。

验收标准：

• AC-001-1 给定司机已注册，当其进入司机专区和接单工作台时，则使用同一账户身份完成鉴权。
• AC-001-2 给定司机也是商城消费者，当其在司机专区下单时，则订单归属到同一用户主体。
• AC-001-3 给定乘客不是司机，当其访问司机功能时，则系统拒绝并提示无权限。

REQ-002 司机二维码归因与乘客导流

• 优先级：P0
• 描述：平台必须支持为司机生成带归因信息的商品/活动二维码，并在乘客进入小程序后建立归因关系。
• 用户故事：作为 司机分销商，我希望 分享带我身份标识的二维码，以便 乘客消费后系统能识别是我引流的。
• 前置条件：司机已启用分销能力，商品或活动已配置可分销规则。
• 业务规则：
• 二维码至少包含司机标识、活动标识、渠道标识。
• 归因窗口可配置，窗口内的商城支付和出行支付都可参与分销收益判断。
• 归因关系建立后，应可追溯到具体二维码和司机。
• 依赖项：REQ-001
• 排除范围：多级分销和裂变裂级。

验收标准：

• AC-002-1 给定司机分享二维码，当乘客扫码首次进入小程序，则系统建立乘客与司机的归因关系。
• AC-002-2 给定归因窗口仍然有效，当乘客在窗口内完成商城支付或出行支付，则系统能找到正确的引流司机。
• AC-002-3 给定归因窗口已失效，当乘客支付时，则系统不再自动归到旧二维码来源。

REQ-003 商城商品浏览、下单与支付

• 优先级：P0
• 描述：乘客必须能够在小程序中浏览本地生活商品、创建订单并完成支付。
• 用户故事：作为 乘客，我希望 在扫码后直接浏览并购买商品，以便 快速获得优惠和服务。
• 前置条件：商品、库存、价格和活动已在运营后台配置。
• 业务规则：
• 商品必须支持城市可见性控制，武汉单城可售。
• 订单支付成功前不得产生返佣入账。
• 订单应记录归因司机、商品明细、优惠与支付流水。
• 依赖项：REQ-002
• 排除范围：跨城履约、复杂多仓物流。

验收标准：

• AC-003-1 给定商品可售，当乘客下单并支付成功，则订单状态更新为已支付。
• AC-003-2 给定订单已支付，则系统保留商品明细、归因信息和支付流水。
• AC-003-3 给定支付未成功，则不得产生返佣和司机站内余额。

REQ-004 支付后返佣、站内钱包与返现券

• 优先级：P0
• 描述：商城或出行订单支付成功后，平台必须按规则生成司机佣金台账，并把返现以站内余额或返现券形式发放。
• 用户故事：作为 司机，我希望 在乘客支付完成后获得可追踪的站内返利，以便 继续在平台内消费。
• 前置条件：支付成功回调已确认，佣金规则已配置。
• 业务规则：
• 返佣必须在支付成功后才可入账。
• 返现余额与返现券只可站内消费，不支持提现。
• 退款时需要生成逆向台账；若司机已消费返利，可形成负站内余额并在后续收益中冲抵。
• 依赖项：REQ-003, REQ-008
• 排除范围：提现、对公结算、外部钱包转账。

验收标准：

• AC-004-1 给定订单支付成功，当佣金规则命中时，则系统生成佣金台账和对应的站内余额或券。
• AC-004-2 给定司机查看收益明细，则可看到收益来源订单、金额、状态和可用余额。
• AC-004-3 给定已返佣订单发生退款，则系统生成逆向分录并更新司机可用余额。

REQ-005 司机专区消费

• 优先级：P0
• 描述：司机必须能够在司机专区使用站内余额或返现券购买早餐、充电、洗车等刚需服务。
• 用户故事：作为 司机，我希望 把返利直接用于平台内刚需消费，以便 形成稳定复购。
• 前置条件：司机已具备可用余额或券，司机专区商品已配置。
• 业务规则：
• 司机专区商品仅对司机角色可见。
• 支付时优先使用返现券，再使用站内余额，剩余部分可挂起待补充规则。
• 平台需记录消费订单与台账扣减关系。
• 依赖项：REQ-004
• 排除范围：司机专区外的通用商城支付组合策略。

验收标准：

• AC-005-1 给定司机具备可用站内权益，当其在司机专区下单时，则系统按既定顺序抵扣权益。
• AC-005-2 给定司机不是专区目标人群时，则系统不展示专区入口或禁止下单。
• AC-005-3 给定消费成功，则台账扣减与订单状态保持一致。

REQ-006 乘客叫车与行程订单创建

• 优先级：P0
• 描述：乘客必须能够在武汉单城内发起叫车请求，并创建行程订单。
• 用户故事：作为 乘客，我希望 在小程序里叫车，以便 享受平台优惠并完成出行。
• 前置条件：乘客已登录，所在位置在武汉可服务区域内。
• 业务规则：
• 首版只支持武汉单城市内运营。
• 行程订单必须包含起终点、预估价格、乘客信息、归因来源。
• 行程订单创建后才向调度服务发起派单请求。
• 依赖项：REQ-001, REQ-002
• 排除范围：多城联运、拼车、预约单、动态加价。

验收标准：

• AC-006-1 给定乘客位于武汉服务范围内，当其提交叫车请求，则系统创建待派单行程订单。
• AC-006-2 给定乘客位置不在服务范围内，则系统拒绝创建订单并提示不可服务。
• AC-006-3 给定乘客来自司机二维码归因窗口内，则系统把归因信息写入行程订单。

REQ-007 派单调度与司机在线状态

• 优先级：P0
• 描述：系统必须支持独立调度服务管理司机在线状态、候选匹配、派单和超时重派。
• 用户故事：作为 平台，我希望 把司机在线状态和派单逻辑独立出来，以便 后续单独优化调度性能。
• 前置条件：司机已开启接单状态，调度服务可用。
• 业务规则：
• 调度服务不持有最终订单真相，最终订单仍以主业务系统为准。
• 派单应记录派发批次、候选司机、超时与接单结果。
• 单城首版优先支持附近司机优先和超时重派。
• 依赖项：REQ-006
• 排除范围：热力调度、跨城运力共享、复杂派单策略引擎。

验收标准：

• AC-007-1 给定有可用司机在线，当新行程订单进入派单时，则调度服务返回候选司机并发起派单。
• AC-007-2 给定首位司机超时未接单，则系统按规则重派给下一个候选司机。
• AC-007-3 给定司机接单成功，则主业务订单状态同步为已接单。

REQ-008 行程完成、支付与优惠联动

• 优先级：P0
• 描述：出行订单必须支持完单、支付和优惠联动，并在支付成功后触发履约收益与分销收益计算。
• 用户故事：作为 乘客，我希望 行程完成后顺利支付并享受优惠，以便 获得完整出行体验。
• 前置条件：司机已接单并完成行程。
• 业务规则：
• 履约司机与引流司机可以不是同一人。
• 履约收益归接单司机，分销收益归引流司机；若为同一人则合并记账。
• 支付成功后方可触发优惠结算与返佣规则。
• 依赖项：REQ-006, REQ-007
• 排除范围：多段行程拆分、平台外代付。

验收标准：

• AC-008-1 给定行程已完成，当乘客支付成功，则订单状态更新为已完成已支付。
• AC-008-2 给定履约司机和引流司机不同，则系统分别入履约与分销相关账。
• AC-008-3 给定支付失败，则系统不发放履约结算后的分销返利。

REQ-009 运营后台配置与可视化管理

• 优先级：P0
• 描述：运营后台必须支持城市、司机、商品、活动、佣金规则、订单和台账的基础管理。
• 用户故事：作为 运营人员，我希望 通过后台配置和查看核心业务对象，以便 持续运营武汉单城业务。
• 前置条件：运营账号已开通权限。
• 业务规则：
• 城市配置首版只开放武汉，但模型需可扩展。
• 佣金规则、归因窗口、司机专区商品必须可配置。
• 后台应具备订单、司机、收益台账和异常状态查询能力。
• 依赖项：REQ-003, REQ-004, REQ-006, REQ-008
• 排除范围：复杂 BI 报表、自助脚本化营销编排。

验收标准：

• AC-009-1 给定运营具备权限，则可配置武汉城市的商品和佣金规则。
• AC-009-2 给定运营查看订单，则能按商城/出行/司机专区类型筛选。
• AC-009-3 给定收益异常，则能在后台查到对应订单和台账。

REQ-010 审计、对账与异常处理

• 优先级：P1
• 描述：平台必须为支付、返佣、退款和派单关键节点保留审计与对账基础能力。
• 用户故事：作为 运营或财务，我希望 对关键账务和订单状态进行追踪，以便 发现异常并快速处理。
• 前置条件：核心业务流程已产生数据。
• 业务规则：
• 支付回调、佣金发放、退款冲抵、派单状态变更需要可追踪。
• 每笔返佣须能回溯到来源订单和规则。
• 对账模型以主业务数据库的订单与台账为准。
• 依赖项：REQ-004, REQ-007, REQ-008
• 排除范围：完整财务总账系统、复杂审计工作流。

验收标准：

• AC-010-1 给定任一返佣分录，则系统可定位来源订单和司机。
• AC-010-2 给定退款逆向分录，则系统可查到原始分录和冲抵结果。
• AC-010-3 给定派单异常，则系统可查看派单批次与司机响应记录。

REQ-011 司机入驻与审核

• 优先级：P0
• 描述：平台必须支持司机资料提交、资质审核和能力启停。
• 用户故事：作为 司机，我希望 在线提交资料并查看审核结果，以便 获得接单与分销资格。
• 前置条件：司机已完成基础注册。
• 业务规则：
• 接单能力、分销能力、司机专区能力可分开控制。
• 审核动作需要记录操作人和时间。
• 依赖项：REQ-001
• 排除范围：复杂多主体加盟体系。

验收标准：

• AC-011-1 给定司机提交资料，当运营审核通过后，则系统开放对应司机能力。
• AC-011-2 给定司机资料不完整，则系统禁止启用接单能力。
• AC-011-3 给定司机被暂停接单，则其分销与消费能力可按规则独立保留。

REQ-012 商家/供应商履约

• 优先级：P1
• 描述：若第一版引入第三方履约商家，平台需支持履约接单、核销和售后协同。
• 用户故事：作为 商家/供应商，我希望 查看和处理我负责的订单，以便 完成服务交付。
• 前置条件：平台启用了外部履约模式。
• 业务规则：
• 自营模式下可先由运营后台代理履约。
• 第三方履约模式下需记录商家状态和核销结果。
• 依赖项：REQ-003, REQ-005
• 排除范围：完整独立商家生态平台。

验收标准：

• AC-012-1 给定订单分配给履约商家，则商家或运营可查看待履约状态。
• AC-012-2 给定服务已完成，则系统支持核销并回写履约状态。
• AC-012-3 给定售后发生，则系统可追溯到对应履约方。

REQ-018 司机返现券转赠

• 优先级：P1
• 描述：平台必须支持司机把满足条件的返现券转赠给其他司机，支持通过微信分享领取或手机号定向转赠两种方式完成。
• 用户故事：作为 司机，我希望 把暂时用不到的返现券转给其他司机，以便 提升券使用率并增强司机间传播。
• 前置条件：司机已通过审核，券状态为可使用，券模板允许转赠，且已过售后冻结期。
• 业务规则：
• 仅返现券支持转赠，站内余额不支持转赠。
• 每张券最多成功转赠一次，不支持拆分转赠和多跳转赠。
• 手机号转赠要求目标手机号已绑定平台司机账户；微信转赠通过司机轻端分享领取链接完成。
• 发起转赠后，券进入“锁定待领取”状态；领取成功后券归属变更到接收司机；超时未领取或发送方取消后恢复到发送方。
• 接收方必须是平台内已开通司机能力的账户，且仍只可在原使用场景内消费，不改变不能提现约束。
• 依赖项：REQ-004, REQ-011, REQ-013
• 排除范围：站内余额转赠、现金红包、跨平台账户转账、券拆分、多次转赠。

验收标准：

• AC-018-1 给定司机持有可转赠返现券，当其通过微信或手机号发起转赠时，则系统创建转赠记录并锁定该券。
• AC-018-2 给定接收方不是已开通司机能力的账户，当其尝试领取时，则系统拒绝领取并提示先完成司机认证。
• AC-018-3 给定转赠领取成功，则发送方不能再使用该券，接收方可在原适用场景内查看并使用该券。
• AC-018-4 给定转赠超时未领取或发送方取消，则券恢复到发送方可用状态，并记录完整转赠日志。

REQ-013 消息通知与触达

• 优先级：P0
• 描述：平台必须支持订单、派单、收益和售后相关通知。
• 用户故事：作为 乘客或司机，我希望 收到与订单相关的及时通知，以便 及时完成后续操作。
• 前置条件：用户已授权接收对应通知，或对应端具备站内消息能力。
• 业务规则：
• 乘客商城和出行状态可通过微信通知 + 站内消息触达。
• 司机履约接单不应只依赖微信订阅消息。
• 独立司机 App 需要支持实时推送或语音播报。
• 依赖项：REQ-003, REQ-006, REQ-007, REQ-008
• 排除范围：外部营销消息中台。

验收标准：

• AC-013-1 给定商城或出行订单状态变更，则乘客能收到至少一种可追踪通知。
• AC-013-2 给定司机有收益入账或券将过期，则司机能收到提醒。
• AC-013-3 给定新的派单产生，则履约司机通过重端及时收到接单通知。

REQ-014 客服、售后与申诉

• 优先级：P1
• 描述：平台必须支持乘客售后、司机申诉和客服工单处理。
• 用户故事：作为 客服或用户，我希望 就订单异常发起并处理工单，以便 解决退款、投诉和争议。
• 前置条件：订单或台账已产生。
• 业务规则：
• 工单必须关联订单、司机、乘客或台账。
• 处理过程保留状态和责任人。
• 依赖项：REQ-003, REQ-008, REQ-010
• 排除范围：复杂外呼系统。

验收标准：

• AC-014-1 给定乘客发起售后，则客服能查看订单上下文并处理。
• AC-014-2 给定司机发起收益申诉，则系统能关联到对应台账和订单。
• AC-014-3 给定工单关闭，则处理结果被完整记录。

REQ-015 调度运营与人工干预

• 优先级：P1
• 描述：平台必须支持查看派单状态并对异常订单进行人工干预。
• 用户故事：作为 调度运营，我希望 监控派单异常并人工处理，以便 保障订单履约。
• 前置条件：派单服务已接入。
• 业务规则：
• 派单失败、长时间无人接单、司机异常取消需进入可干预列表。
• 人工干预需有审计日志。
• 依赖项：REQ-007
• 排除范围：复杂 AI 调度中台。

验收标准：

• AC-015-1 给定派单失败订单，则后台可看到异常状态并触发处理。
• AC-015-2 给定运营人工指派司机，则系统记录干预动作和结果。
• AC-015-3 给定异常处理结束，则订单状态被正确回写。

REQ-016 风控、审计与合规

• 优先级：P1
• 描述：平台必须支持关键行为审计和基础风控监测。
• 用户故事：作为 风控或审计人员，我希望 追查关键订单和资金链路，以便 识别异常和留存合规证据。
• 前置条件：平台已有订单、支付、台账和规则变更数据。
• 业务规则：
• 支付、退款、返佣、人工干预、审核动作必须留痕。
• 风险规则首版至少覆盖异常取消、异常退款、异常定位和异常收益。
• 依赖项：REQ-010, REQ-014, REQ-015
• 排除范围：全量企业级合规系统。

验收标准：

• AC-016-1 给定任一关键资金动作，则可查询到操作链路和责任主体。
• AC-016-2 给定司机出现异常接单/取消行为，则系统可形成风控线索。
• AC-016-3 给定规则变更，则系统可查到变更前后和操作人。

REQ-017 数据分析与运营看板

• 优先级：P1
• 描述：平台必须支持拉新、出行、返佣和复购相关看板。
• 用户故事：作为 运营或管理者，我希望 看到关键经营指标，以便 调整商品、司机和活动策略。
• 前置条件：已产生业务数据。
• 业务规则：
• 首版看板至少覆盖武汉单城。
• 指标至少覆盖扫码、成交、接单、完单、返佣、司机专区消费。
• 依赖项：REQ-002, REQ-004, REQ-008, REQ-009
• 排除范围：复杂自助 BI 平台。

验收标准：

• AC-017-1 给定运营查看看板，则能看到拉新和成交基础指标。
• AC-017-2 给定运营查看出行指标，则能看到下单、接单、完单、取消相关指标。
• AC-017-3 给定运营查看司机经营指标，则能看到返佣与专区消费表现。

4. 非功能需求

NFR-001 性能

• 指标：
• 面向小程序的核心查询与下单接口 P95 < 500ms。
• 派单请求到首批候选返回 P95 < 300ms。
• 支付回调到佣金入账完成 P95 < 3s。
• 约束：首版按武汉单城容量设计，优先保证单城高峰期稳定性。
• 验证方式：接口压测、联调监控、关键流程埋点。

NFR-002 安全

• 指标：所有用户接口必须经过鉴权；关键资金动作需保留审计日志；支付回调必须做签名校验和幂等处理。
• 约束：站内余额不可提现，后台必须具备角色权限控制。
• 验证方式：接口鉴权测试、幂等测试、权限测试。

NFR-003 可用性/可维护性

• 指标：核心服务月可用性目标 99.5%；关键错误具备日志、追踪与告警基础能力。
• 约束：主业务系统为订单真相源，调度服务失效时应可回退为“派单失败待人工处理”状态，不得污染主订单事实。
• 验证方式：故障演练、降级测试、日志审查。

NFR-004 可扩展性

• 指标：架构必须支持从单城市平滑扩展到多城市；配置、规则、商品和运力池需具备城市维度。
• 约束：首版只实现武汉，但数据模型不能写死城市常量。
• 验证方式：设计审查、数据模型审查。

5. 关键流程

1. 司机分享二维码，乘客扫码进入小程序，系统建立归因关系。
2. 乘客进行商城下单或叫车；系统记录归因来源。
3. 商城订单支付成功或出行订单支付完成后，系统计算返佣并入站内台账。
4. 司机查看返佣明细，并在司机专区使用站内余额或返现券完成复购。

6. 风险、假设与待确认问题

风险

• 出行业务运营规则、计费规则和地图服务仍需后续补充。
• 公开可安装 Stratix 版本与技能锚点不同，进入实现前需要再确认技术画像。
• 退款后允许出现负站内余额，会增加运营解释成本和对账复杂度。

假设

• 武汉单城首版使用统一计费与统一调度规则。
• 乘客商城支付和出行支付都纳入司机二维码归因窗口。
• 管理后台优先服务内部运营，不作为对外开放能力。

待确认

• 具体支付渠道与支付分账方式。
• 地图定位与路线估价服务供应商。
• 司机专区商品履约方式与库存同步策略。
• 券转赠售后冻结期的默认时长，以及是否允许后续运营按模板单独配置。

7. 版本与变更

版本	日期	变更内容	关联 CR
v1.0	2026-03-29	第一版双主线 MVP PRD
v1.1	2026-03-29	新增 REQ-018 司机返现券转赠需求