Feng's Blog

游戏打手抢单结算系统

Properties1
tags小程序接单

11分钟阅读

对话笔记直发：游戏打手抢单结算系统。分类：小程序接单。

产品需求文档（PRD）

游戏打手抢单结算系统 V1.0（终版）

文档版本修订日期修订说明
V1.02026-07-10终版，基于第一性原理精简退款逻辑，合并为统一退款执行器

1. 项目背景与核心原则

  • 业务场景：用户在小程序下单购买游戏服务（代练/陪玩），订单进入后台。商家员工（打手）抢单并执行服务。

  • 核心原则（第一性）：

    1. 谁执行，谁操作：打手抢单后，「开始服务」和「完成服务」由打手在小程序端触发，原商家后台对应按钮灰显。
    2. 商家保留最终退款权：无论订单处于什么状态，商家后台必须有一个【退款】按钮，用于处理纠纷退钱。
    3. 小程序不提现：所有资金展示仅限于“已结算/待结算”，打款由商家线下完成并在后台确认。

2. 用户角色

角色说明
C端用户小程序下单购买游戏服务的普通用户
打手（员工）注册并通过审核的游戏服务执行者，使用小程序端抢单/操作
商家（管理员）使用商家后台（Web/小程序管理端），负责审核、退款、结算

3. 功能范围（V1.0）

模块包含不包含
入口开关✅ 商家后台控制小程序「我的」页面入口显隐—
注册/登录/审核✅ 完整字段（仅删去「项目组」），审核通过方可登录—
订单池/抢单✅ 列表展示 + 乐观锁防并发自动分配、轮流分配
开始服务✅ 打手触发，同步原商城状态—
完成服务✅ 打手触发，同步原商城状态—
商家权限移交✅ 原按钮灰显，控制权移交打手—
退款功能✅ 用户申请退款 + 商家主动退款，统一执行器复杂仲裁流程、多级审批
数据看板✅ 4个核心数字 + 最近动态列表趋势图、高级筛选
佣金结算✅ 商家批量生成批次 + 确认打款自动打款、员工申请提现
我的收益✅ 汇总卡片 + 明细列表账单导出、按时间筛选

4. 入口位置

  • 小程序端：「我的」页面（个人中心），在下方菜单列表中增加入口按钮。
  • 按钮文案：「打手中心」或「员工入口」。
  • 显示逻辑：受商家后台 employee_entry_visible 开关控制，开启则显示，关闭则隐藏（用于过审）。

5. 注册/登录/审核（完整版）

5.1 注册字段

分区字段输入类型必填说明
登录信息手机号文本输入✅格式校验
密码文本（掩码）✅6位以上
邀请码文本输入✅
实名信息性别下拉选择（男/女）✅
手机号文本输入✅手机号
身份证图片文件上传（图片）✅需上传2张（0/2）
ZFB账号文本输入✅收款支付宝
收款人姓名文本输入✅真实姓名
协议《打手协议》复选框✅必须勾选方可提交

5.2 登录校验逻辑

审核状态登录结果
待审核（0）提示“账号审核中，请耐心等待”，禁止登录
已通过（1）正常登录，进入订单池
已驳回（2）提示“审核未通过，请联系商家”，禁止登录

6. 完整订单状态机

状态流转路径（打手视角）：

待抢单 (grab_status=0)
   │
   ├── 打手点击【抢单】成功
   ▼
已抢待开始 (grab_status=1, service_status=0)
   │
   ├── 打手点击【开始服务】
   ▼
服务中 (grab_status=1, service_status=1)
   │
   ├── 打手点击【完成服务】
   ▼
已完成待结算 (grab_status=2, settle_status=0)
   │
   ├── 商家生成结算批次 → 确认打款
   ▼
已结算 (grab_status=2, settle_status=1)

异常终态：
已退款 (grab_status=-1, settle_status=-1)  ← 任何阶段均可通过退款功能进入

7. 权限移交矩阵

订单状态打手端可操作原商家后台「开始/完成」按钮原商家后台「退款」按钮C端用户退款入口
待抢单无✅ 可点击（沿用旧逻辑）无（无需退款）✅ 显示（秒退）
已抢待开始【开始服务】❌ 灰显，提示“打手XX已接单”✅ 常驻【退款】✅ 显示（秒退）
服务中【完成服务】❌ 灰显✅ 常驻【退款】✅ 显示（需商家审核）
已完成待结算无❌ 灰显✅ 常驻【退款】❌ 无退款按钮
已结算无❌ 灰显置灰，提示“已结算，请线下处理”❌ 无

8. 完整流程图

flowchart TD
    subgraph U[用户端]
        U1[用户下单支付] --> U2{订单状态判断}
        U2 -->|未开始服务| U3[显示退款按钮 点击秒到账]
        U2 -->|服务中| U4[显示退款按钮 提交后需商家审核]
        U2 -->|已完成| U5[无退款按钮 需联系商家]
    end

    subgraph E[打手端 小程序]
        E0[小程序「我的」页面点击「打手中心」] --> E1[登录进入订单池]
        E1 --> E2[抢单成功 订单归自己]
        E2 --> E3[准备就绪 点击'开始服务']
        E3 --> E4[服务执行中 点击'完成服务']
        E4 --> E5[订单标记完成 进入待结算]
    end

    subgraph B[商家后台]
        B0[订单进入后台] --> B1{是否已被打手抢单?}
        
        B1 -->|否| B2[显示【开始服务】【完成服务】可点击]
        B2 --> B3[商家手动操作全流程 沿用旧逻辑]
        
        B1 -->|是| B4[原【开始/完成】按钮变灰 提示:由打手XX处理]
        B4 --> B5[常驻显示【退款】按钮]
    end

    %% 打手触发同步原商城
    E3 -->|接口调用| S[后端同步逻辑]
    E4 -->|接口调用| S
    
    S --> S1{同步原商城订单状态}
    S1 -->|打手点开始| S2[原商城状态变为'服务中' 锁定用户秒退权限]
    S1 -->|打手点完成| S3[原商城状态变为'已完成' 移除用户退款按钮]
    
    S2 --> B4
    S3 --> B4

    %% 退款统一入口
    subgraph R[退款功能]
        R1[用户申请退款] --> R3[统一退款执行器]
        R2[商家点击退款] --> R3
        R3 --> R4{当前订单状态}
        R4 -->|已抢未开始| R5[释放打手绑定 订单回池 用户秒退]
        R4 -->|服务中| R6[终止服务 订单关闭 佣金归零]
        R4 -->|已完成待结算| R7[撤回完成状态 从待结算池剔除 用户退款]
        R5 --> R8[订单标记为已退款 grab_status=-1]
        R6 --> R8
        R7 --> R8
    end

    %% 结算
    E5 --> C1[佣金计入打手待结算]
    C1 --> C2[商家待结算列表可见]
    C2 --> C3[商家生成结算批次 确认打款]
    C3 --> C4[打手收益更新]

9. 退款功能详细说明

9.1 一句话定义

退款 = 商家退钱给用户 + 系统自动处理打手佣金 + 订单进入终态。

9.2 两种触发方式

触发方式触发者触发条件
用户申请退款C端用户用户在订单详情点击「申请退款」（仅限「未开始」和「服务中」状态）
商家主动退款商家后台管理员商家在订单详情点击【退款】按钮（所有已抢状态均可）

两种方式最终调用同一个底层退款执行器。

9.3 退款执行器 - 按状态处理逻辑

当前状态执行动作
已抢未开始①释放打手绑定（employee_id=null）
②订单回池（grab_status=0）
③调用原商城秒退接口退款给用户
服务中①终止服务（service_status=0）
②订单彻底关闭（grab_status=-1）
③调用原商城“商家审核退款”接口退钱
④该笔打手佣金归零（从待结算池实时扣除）
已完成待结算①撤回「已完成」状态（grab_status=-1）
②调用原商城后台强退接口退款
③从待结算池中剔除该笔（settle_status=-1）
④若已生成结算批次（待确认），自动从批次中移除并重算总额

9.4 数据一致性保障

数据项退款后处理
订单状态grab_status=-1，settle_status=-1，记录 refund_time 和 refund_reason
打手佣金该笔 commission 归零，从待结算总额中实时扣除
商家看板「已完成订单数」扣除该笔（grab_status=-1 不计入）
商家看板「待结算佣金总额」重新 SUM（settle_status=0），自动刷新
结算批次（待确认状态）自动剔除该订单，total_amount 重算

11. 接口清单（共18个）

| 模块 |

相关： 00-索引-小程序接单索引 7.15 YoShop 风险分级 AI 开发工作流与使用手册

关系图谱

反向链接