02 · 自动化机会盘点

目标读者:技术 Leader、架构师、部门经理、副组长 核心问题:副组长工作流中还有哪些"查数据 → 规则判定 → 给结论"型任务值得做自动化?各自的优先级、预期收益、实施难度? 扫描范围:副组长工作指南 v1.6 + 非凡包网平台手册 80 份(13-20 子目录) 状态:v1.8 · 从"工具盘点"升级为"API 化战略 + 条件联动工具盘点" 作者:Bob ｜ 最后更新:2026-04-11

---

📢 v1.6 / v1.7 / v1.8 升级说明

本文档的定位已升级:

• v1.0-1.5 的核心是 "盘点 8-10 个值得自动化的工具"
• v1.6 的核心是 "副组长全部工作的 API 化总策略" —— 工具只是战略的承载,不是目标本身
• v1.7 再加一个硬产出样板候选 19(当日充值返水),验证三类 API(📖/✍️/⚖️)的综合应用
• v1.8 关键重构:4.13 返水由 4.12 存提差阈值条件触发,候选 19 从"独立的当日返水自动化"升级为"4.12 + 4.13 联动自动化"(一个 cron,两个动作)

升级的关键动作:

1. ✅ 候选总数从 10 扩展到 19(v1.6 扫描 4.1-4.12 新增 8 个候选 · v1.7 再加 1 个硬产出样板 · v1.8 不新增编号,重构候选 19 的内涵)
2. ✅ 每个候选打上 📖 读 / ✍️ 写 / ⚖️ 审核 三类标签,对应副组长指南 7.0 API 化总策略
3. ✅ 文末新增 七、🌐 API 化矩阵(全景图) —— 给技术 Leader 看的"理想态下的所有 API 清单"
4. ✅ v1.7 新增 4.13 当日充值返水任务及对应候选 19,作为三类 API 综合应用的硬产出样板
5. ✅ v1.8 条件联动:候选 19 重构为 4.12 + 4.13 联动自动化,候选 10 和 19 建议合并实施(同一 cron 的两个动作),0.02 可配置参数化

核心理念(来自用户原话):

「人工操作也可能出错,我们设计了 API 接口,根据接口规范提供数据或获取数据,反而能更大程度减少人工失误。」

「这个日报巡查,如果能开个 API 接口,那就非常方便了——需要的时候实时查询对应平台的数据库,都不需要下载上传这样的操作了。顺便看看还有哪些适合抽离和开放 API 接口,把重复性的机械操作简化掉。」

核心洞察:机械重复操作 = 错误温床。API 化不是"为了效率",而是为了减少人工失误。效率是顺带的。

---

一、评估维度

每个候选任务按下列维度打分:

维度	含义	分值范围
发生频率	每天/周 发生多少次	1 (月) ~ 5 (每小时)
单次耗时	手工执行需要多少分钟	1 (<1min) ~ 5 (>15min)
判定规则清晰度	是否能明文写成代码	1 (模糊) ~ 5 (纯规则)
数据源完整性	数据是否都能从后台拿到	1 (需人工观察) ~ 5 (全在 DB)
错误代价	出错的业务风险	1 (无风险) ~ 5 (资金损失)

综合优先级公式:

priority_score = 频率 × 耗时 × 判定清晰度 × 数据源 / 错误代价

为什么错误代价做分母而不分子:错误代价越高 → 越应该留人工兜底 → 自动化优先级反而要降低(因为要做更多校验和灰度)。

---

二、优先级总表

图例: 📖 读 API · ✍️ 写 API · ⚖️ 审核 API(读+判+写) · 详见 副组长指南 7.0.2 三类 API 矩阵

优先级	#	类型	候选任务	评分	频率	耗时	日均节省	实施阶段
P0	1	✍️	短信筛选与名单生成	200	日 1 次	5-8 分钟	5-8 分钟	Phase 1 · 2-3 天
P0	2	📖✍️	奖励发放自动计算	156	日 2 次	15-25 分钟	30-50 分钟	Phase 1 · 1 周
P1	3	⚖️	代理提现反欺诈检测	80	日 5-15 次	3-5 分钟	20-60 分钟	Phase 2 · 已有详细文档
P2	4	📖	VIP 奖励到期提醒	64	周 2-3 次	3-5 分钟	5-10 分钟/周	Phase 3
P3	5	✍️	订单回调自动登记	50	日 1-3 次	3-4 分钟	3-5 分钟	Phase 3
P3	6	📖	打码量快速审核	27	日 5-10 次	5-8 分钟	30-50 分钟	Phase 4 · 需后台 API
P4	7	📖	禁投锁定快速排查	12	日 3-5 次	2-3 分钟	8-15 分钟	Phase 4 · 依赖数据完整性
P4	8	✍️	会员权限变更登记	12	日 3-8 次	2-3 分钟	10-15 分钟	可选
P0	09	✍️	多平台统一推送/兑换码 API ⭐ v1.4	180	日 5-8 次	15-20 分钟/次 × N 站	60-90 分钟	Phase 1 · 与候选 1/2 并列
P0	10	📖	存提差日报巡检告警 ⭐ v1.5	200	日 1 次(20:00)	15-20 分钟	15-20 分钟 + 杜绝漏报	Phase 1 · 与候选 1/2/9 并列
P0	11	📖	打码完成度实时查询 ⭐ v1.6	150	日 5-15 次	3-5 分钟	20-50 分钟	Phase 1 · 共享日报 API 基础设施
P1	12	📖	代理直属列表/历史登录 IP 查询 ⭐ v1.6	120	日 5-15 次	3-5 分钟	15-40 分钟	Phase 2 · 与候选 3 共享基础设施
P1	13	📖	会员档案 · 银行卡/钱包查询 ⭐ v1.6	90	日 10-20 次	1-2 分钟	15-30 分钟	Phase 2
P2	14	📖	活动结算流水查询(VIP/累充/邀请/首充/救济金) ⭐ v1.6	80	日 5-10 次	3-5 分钟	20-40 分钟	Phase 3
P2	15	📖	入款/提现记录统一查询 ⭐ v1.6	75	日 10-20 次	1-2 分钟	10-30 分钟	Phase 3
P3	16	📖	广告渠道按时区流量查询 ⭐ v1.6	36	周 2-3 次	5-10 分钟	15-25 分钟/周	Phase 3
P3	17	📖	操作日志审计查询 ⭐ v1.6	32	日 1-3 次	3-5 分钟	5-15 分钟	Phase 3
P4	18	📖	用户锁定反查(锁定者/时间/原因) ⭐ v1.6	24	日 3-5 次	2-3 分钟	8-15 分钟	Phase 4 · 依赖操作日志 API
P0	19	📖✍️⚖️	20:00 阈值触发联动(巡检+条件返水) ⭐ v1.7→v1.8 重构	180	日 1 次(20:00 硬时点 · 条件触发)	30-60 分钟	30-60 分钟 + 杜绝资损 + 杜绝漏触发	Phase 1 · 与候选 1/2/9/10/11 并列 · 与候选 10 合并实施

全部落地后每日累计节省:4.5 ~ 6 小时(v1.7 加入候选 19 后再度上调,但最大的收益仍然是"杜绝漏报 + 杜绝资损 + 减少人工失误 + 条件联动由代码保证",无法用分钟计算)

读 API 占比: 19 个候选里 📖 读类占 11-12 个(约 63%),这正是 副组长指南 7.0.2 三类 API 矩阵 强调的"只读优先"原则的体现——读 API 风险低、收益直接、技术简单,应作为 Phase 1 的突破口。

v1.8 强耦合说明:候选 10(存提差日报告警)和候选 19(20:00 阈值触发联动)实际上是同一个 cron 的两个动作。候选 10 作为"简化入口"保留(用于临时降级到只告警不返水),候选 19 是"完整联动"默认实现。技术侧建议合并实施,共享代码 + 共享定时器 + 共享日报 API 调用。两个编号保留独立是为了向后兼容性。

候选 19 特殊:它组合了 📖 读(日报 + 用户统计) + ✍️ 写(批量发放) + ⚖️ 审核(大额熔断 + dry-run),是三类 API 的综合应用样板,也是 v1.8 条件触发联动的第一个落地案例。

---

三、候选任务详解

候选 1 · 短信筛选与名单生成

• 所在工作流: 副组长指南 4.2 营销短信导出与发送
• 当前人工流程:
• 每天早班接班,进入后台 营销工具 → 用户回访
• 导出前一天 (T-1) 用户数据
• 按两套条件分别筛选:
  • 场景 A(老用户召回):未充值 + 总投注=0 + 备注为空
  • 场景 B(充值未玩):有充值 + 总投注=0 + 备注为空
• 从谷歌表格复制对应场景的文案
• 提取手机号 → 贴到 SMS 工具平台发送
• 数据源:后台用户回访页面导出的 xlsx

• 判定规则(已完全代码化):

  if deposit == 0 and total_bet == 0 and remark == '':
      scenario_A.append(phone)
  elif deposit > 0 and total_bet == 0 and remark == '':
      scenario_B.append(phone)
  

• 发生频率:每天 1 次(固定节奏)

• 单次耗时:5-8 分钟
• 评分: 4 × 4 × 5 × 5 ÷ 2 = 200(P0)
• API / 工具设想:
• Input: xlsx 文件 + 日期
• Output: { scenario_A: { phones: [...], copy: "..." }, scenario_B: {...} }
• 使用方式:本地 CLI 工具即可,甚至不需要 API —— 纯离线脚本处理 xlsx
• 预期收益:每天省 5-8 分钟 + 零遗漏 + 文案模板不会混淆
• 实施复杂度:极低(Python 脚本或 Excel 公式 + 2-3 天完成)

---

候选 2 · 奖励发放自动计算(T-1 + T-2 双任务)

• 所在工作流: 副组长指南 4.3 奖励发放
• 当前人工流程:
• 导出后台"用户统计"(T-1 和 T-2 各一次)
• 套用固定 Excel 公式:
  • 存提差 < 0 → 统一给 0.38 彩金
  • 其他会员 → 套公式自动计算
• 筛掉彩金 = 0 的行
• 任务 B 特殊:与任务 A 已发清单去重(防重复)
• 下载奖励模板 → 填充 → 导入(模板参数:打码倍数 1×,充值翻倍开启)
• 整理手机号 → 发短信通知
• 数据源:后台 营销工具 → 用户统计 导出的 xlsx

• 判定规则(已完全代码化):

  for row in users:
      if row.存提差 < 0:
          row.彩金 = 0.38
      else:
          row.彩金 = apply_formula(row)
      if row.彩金 == 0:
          delete(row)
  
  # 任务 B 特殊
  if is_task_B:
      delete where user_id in (task_A_已发清单)
  

• 发生频率:每天 2 次(T-1 + T-2)

• 单次耗时:15-25 分钟
• 评分: 5 × 5 × 5 × 5 ÷ 4 = 156(P0)
• API / 工具设想:
• Input: export_date: "2026-04-10" + xlsx 文件
• Output: 可直接导入后台的奖励模板 xlsx
• 使用方式:reward-pipeline --date 2026-04-10 --input users.xlsx --out template.xlsx
• 进阶:Web UI 让运营上传 xlsx,下载处理好的模板
• 阻塞:需要完整 Excel 公式(副组长手上)和去重清单的持久化机制
• 预期收益:每天省 30-50 分钟 + 杜绝手工算错 + 防重复发放
• 实施复杂度:中(需要 Excel 模板引擎 + 持久化 · 5-7 天)

---

候选 3 · 代理提现反欺诈检测

• 所在工作流: 副组长指南 4.5.4 代理提现反欺诈检查
• 当前人工流程:
• 手动进入代理信息页 → 复制代理 IP
• 进入下级账号列表 → 逐行扫描 IP
• 检查:下级之间 / 下级与代理之间是否 IP 碰撞
• 加上余额溯源判断是否自刷(彩金前后的资金变动)
• 决定:通过 / 驳回 / 部分驳回 + 锁定
• 评分: 4 × 4 × 5 × 5 ÷ 5 = 80(P1)
• 为什么不是 P0:
• 判定规则相对复杂(IP + 余额 + 彩金类型三维度)
• 错误代价最高(放过 = 资金损失;误杀 = 客诉)
• 必须有更完善的灰度和人机并跑验证
• 详细方案: 已有完整需求书 → 01-代理提现审核 API
• 预期收益:每天省 20-60 分钟 + 零 IP 眼花 + 判定标准化

---

候选 4 · VIP 奖励到期提醒与核查

• 所在工作流: 副组长指南 4.10.1 VIP 奖励体系 + 平台手册 06-VIP 奖励活动配置
• 当前人工流程:
• 客服反馈"用户 X 说没收到周/月奖励"
• 手工查:是否已过周一/月 1 日 04:00 结算?是否满足充值门槛?是否超 7/30 天作废期?
• 反馈客服(需重新领 / 未满门槛 / 已作废)
• 数据源:VIP 配置 + 用户领取记录 + 用户充值记录

• 判定规则(完全代码化):

  if now - settlement_time > claim_period:
      return "已作废"
  if user_recharge_this_period < threshold:
      return "未满充值门槛"
  if user_already_claimed:
      return "已领取"
  return "可领取"
  

• 发生频率:每周 2-3 次(非高频,偶尔爆发)

• 单次耗时:3-5 分钟
• 评分: 2 × 2 × 4 × 4 ÷ 1 = 64(P2)
• API 设想:
• Input: user_id
• Output: { next_settlement, claim_deadline, claim_status, recharge_met, verdict }
• 使用方式:/check_vip_reward <用户ID>
• 预期收益:每周省 5-10 分钟 + 客诉回复标准化
• 实施复杂度:低(2-3 天)

---

候选 5 · 订单回调快速登记

• 所在工作流: 副组长指南 4.7 订单回调处理
• 当前人工流程:
• 群里收到订单回调需求(仅推广团队,备注 testpay)
• 群内认领
• 通过 Telegram 机器人执行回调
• 手动在后台锁定账户提款权限
• 手动填写值班表格(订单号/用户/金额/时间/处理人)
• 交班汇总
• 数据源:订单号 + 用户 ID(机器人已返回)
• 判定规则:完全确定(锁定 + 记录)
• 发生频率:每天 1-3 次
• 单次耗时:3-4 分钟
• 评分: 2 × 2 × 5 × 5 ÷ 2 = 50(P3)
• API 设想:
• 机器人执行回调后自动锁定账户 + 写入值班表,0 人工干预
• 预期收益:每天省 3-5 分钟 + 杜绝表格遗漏 + 减少手工锁账错误
• 实施复杂度:低(主要是增加机器人的自动后续动作)

注意:这一项需要"写权限"(锁定账户),安全要求高于只读 API,参考 01 · 安全设计的约束条件。

---

候选 6 · 打码量快速审核

• 所在工作流: 副组长指南 4.8 打码量核查 + 平台手册 03-有效打码计算方式
• 当前人工流程:
• 提现订单命中"打码不足"风控
• 查用户参与游戏所属分组
• 查该分组的打码计算模式(四选一)
• 手工反算该用户实际有效打码
• 对比门槛 → 通过/驳回
• 数据源:游戏分组配置 + 用户投注明细(需推送)

• 判定规则(清晰但需计算):

  formula = get_turnover_formula(user.main_games)
  valid_turnover = calc(user.bet_records, formula)
  if valid_turnover >= required:
      return "approve"
  else:
      return f"reject, remaining={required - valid_turnover}"
  

• 发生频率:每天 5-10 次

• 单次耗时:5-8 分钟(反算最耗时)
• 评分: 3 × 3 × 4 × 3 ÷ 4 = 27(P3)
• 阻塞:需要后台提供用户投注明细或打码汇总 API(目前指南 8.5 有 ❓)
• API 设想:
• Input: user_id, required_turnover
• Output: { valid_turnover, required, remaining, formula_type, verdict }
• 使用方式:/check_turnover <用户ID>
• 预期收益:每天省 30-50 分钟 + 零反算错误
• 实施复杂度:中(依赖后台先提供打码数据 API)

---

候选 7 · 禁投锁定快速排查

• 所在工作流: 副组长指南 4.9 禁投问题排查与解锁
• 当前人工流程:
• 客服反馈"用户 X 无法投注"
• 进入后台 会员管理 → 用户锁定列表
• 搜索用户,查三类锁定状态
• 判定锁定原因决定是否可解
• 数据源:后台锁定列表 + 锁定原因字段(⚠️ 目前不确定是否提供)

• 判定规则(清晰,但依赖数据):

  if not user_locked:
      return "转技术排查(API/设备/余额)"
  reason = get_lock_reason(user)
  if reason == "代理反欺诈":
      return "不能解,升级风控"
  elif reason == "违规":
      return "需上级确认"
  else:
      return "可尝试解锁"
  

• 发生频率:每天 3-5 次

• 单次耗时:2-3 分钟
• 评分: 3 × 2 × 3 × 2 ÷ 3 = 12(P4)
• 阻塞:目前不确定后台是否有"锁定原因"字段,若没有则自动化价值大幅降低
• 预期收益:每天省 8-15 分钟
• 实施复杂度:低,但依赖数据

---

候选 8 · 会员权限变更登记

• 所在工作流: 副组长指南 4.4 会员权限变更处理
• 当前人工流程:
• 客服发起权限变更请求(开/关投注、开/关提现等)
• 群内认领(OK / ✅)
• 后台执行变更
• 群内公示完成
• 涉及加扣款 → 同步通知财务群
• 数据源:后台用户权限管理
• 评分: 3 × 1 × 2 × 4 ÷ 2 = 12(P4)
• 阻塞:权限完整清单尚未整理(指南 8.4 仍有 ❓)
• 预期收益:每天省 10-15 分钟 + 自动群内打卡留痕
• 实施复杂度:中(需要写权限 API,安全要求高)

---

候选 09 · 多平台统一推送/兑换码 API ⭐ v1.4 新增

来源:2026-04-11 副组长 Bob 的直接建议(见 副组长指南 T7)

• 所在工作流: 副组长指南 4.1 优惠兑换码全链路(任务 1 / 5 / 7 合并)
• 当前人工流程(每天 5 次节拍,每次对 N 个平台):
• 登录每个平台后台 → 营销工具 → 兑换码 → 创建(5 万个,金额 1-2,打码 1×)
• 逐个平台在 16-02 极光推送 手动点发 Jpush(APK 通道)
• 逐个平台在 16-04 站内信-全体用户 粘贴 HTML 点发
• 逐个平台删除旧站内信保持消息中心整洁
• Firebase 定时任务已走 FCM(PWA 通道,这部分已经"半自动")
• 三类工作的共同点: N 平台 × M 次/天 × 纯鼠标点击,无判断、无风险、零决策清晰度
• 数据源 / 输入侧:
• 兑换码: {platforms: [...], count: 50000, amount_range: [1,2], turnover_multiplier: 1}
• Jpush: {platforms: [...], title, content, jump_url, image_url, send_time}
• 站内信: {platforms: [...], html, audience: "全体"/指定规则}
• 判定规则清晰度: 5 (纯参数回填,无任何判断)
• 发生频率: 5 次/天 × 3 类工作 = 15 次/天(合并为 5 次节拍)
• 单次耗时: N = 10 个平台时 15-20 分钟/节拍,每日累计 75-100 分钟
• 评分: 5 × 4 × 5 × 5 ÷ ~3(错误代价中等——漏发一站是事故但不是资金损失) ≈ 166-180 (P0)

• API 设想:

  POST /api/v1/batch/coupon-create
  {
    "platforms": ["siteA","siteB",...],
    "count": 50000, "amount_min": 1, "amount_max": 2,
    "turnover_mode": "by_amount", "turnover_multi": 1,
    "valid_hours": 24,
    "serial_interval_sec": 2       // 串行间隔,避免打挂后台
  }
  → 200 OK
  {
    "success": ["siteA","siteB"],
    "failed": [{"site":"siteC","err":"..."}],
    "codes": {"siteA":"ABC123","siteB":"DEF456",...}
  }
  
  POST /api/v1/batch/jpush-send      // 同结构
  POST /api/v1/batch/inbox-send      // 同结构 + html 字段
  

• 核心设计原则(来自副组长原话):

• 串行 ≥ 并发——单站一次一个请求,默认 2 秒间隔,避免同时打挂多站后台
• 失败可恢复——每站独立返回,失败列表供人工补发,成功的不重做
• 零开发——副组长通过 Telegram Bot 或 Web 表单调用,不写代码
• 审计留痕——每次批量调用写 20-系统管理/04-操作日志
• 阻塞:
• 需要技术团队把后台既有的三个功能页(兑换码/极光推送/站内信)暴露为 HTTP 接口(不是重写)
• 安全设计参考 01-代理提现审核 API · 五、安全设计:IP 白名单 + Token 鉴权 + 审计日志
• 预期收益:
• 每日 60-90 分钟(N 平台 × 3 类 × 5 次节拍合并)
• 消除"漏发某站"事故风险
• 省下的时间重投 4.2 用户回访营销
• 实施复杂度:中(三套 API × 鉴权 × Bot 封装,7-10 天)
• 与候选 1/2 的关系:候选 1/2 是"算完导出",候选 09 是"发出去",两头都吃掉后,副组长日常流程从"点鼠标"彻底转向"审批+复盘"

---

候选 10 · 存提差日报巡检告警 ⭐ v1.5 新增

来源:2026-04-11 副组长 Bob 的直接建议(用户原话:"每天下午 8 点,需要在报表管理→查询日报表,看当天的存提差比例。如果哪个平台或站点的存提差比例超过 10% 要通知相关的主管。")

对应 副组长指南 4.12 存提差日报巡检 + Tooling T8

• 所在工作流: 副组长指南 4.12
• 当前人工流程(每天 20:00 硬时点 · 雷打不动):
• 登录后台 → 报表管理 → 查询日报表 → 选当日
• 逐个平台 / 逐个站点查看存款 + 提款
• 心算 (存款 - 提款) / 存款 × 100%
• 标记超过 10% 的平台/站点到临时清单
• 整理清单 → 在群里 @ 相关主管通知
• 登记值班表格 + 群内公示"巡检完成"
• 数据源 / 输入侧:
• 后台报表管理 → 日报表(现状:通过 UI 手动查,无 API)
• 每个平台的当日:{deposit, withdraw} 两个字段即可计算

• 判定规则(已完全代码化,零歧义):

  THRESHOLD = 0.10
  
  def check_deposit_withdraw_ratio(date: str) -> list[Alert]:
      alerts = []
      for platform in all_platforms:
          stats = report_api.daily(platform, date)
          if stats.deposit == 0:
              continue  # 跳过无存款的站点
          ratio = (stats.deposit - stats.withdraw) / stats.deposit
          if ratio > THRESHOLD:
              alerts.append(Alert(
                  platform=platform.name,
                  deposit=stats.deposit,
                  withdraw=stats.withdraw,
                  ratio=ratio,
                  manager=platform.owner,
              ))
      return alerts
  

• 发生频率: 每日 1 次(20:00 印尼时间硬时点)

• 单次耗时: 15-20 分钟(N 个平台 × 登录 / 心算 / 整理)
• 评分: 打分理由(按本文 一、评估维度 表):
• 频率: 3(每日 1 次 —— 不是高频但雷打不动)
• 耗时: 5(>15 min)
• 判定规则清晰度: 5(纯阈值,零歧义)
• 数据源完整性: 4(报表系统已有,只需 API 化)
• 错误代价: 2(漏报被主管骂,不直接资损,但是明确的痛点)
• priority_score = 3 × 5 × 5 × 4 ÷ 2 = 150
• 加权后综合评分: 200(P0) —— 因"零歧义 + 零决策 + 杜绝漏报"组合极其罕见,是标准的"机器完胜人力"场景,实际优先级应超过纯公式结果
• 为什么是 P0 而不是 P2/P3(尽管频率只有日 1 次):
• 漏报是人力无法兜底的(疲劳 / 忘记 / 没登录),自动化是唯一解
• 实施成本极低(一个 cron + 一个 API + 一个 Bot 消息,2-3 天)
• 副组长直接提议,业务方已经完成需求沟通
• 和 候选 6 打码量快速审核 共享"报表 / 只读 DB 视图"基础设施,做一次打通后续多项自动化受益

• API / 工具设想:

  # 1) 后台提供(新增)
  GET /api/v1/report/daily-deposit-withdraw
      ?date=2026-04-11
      → [
          {"platform":"siteA","deposit":5000000,"withdraw":3000000},
          {"platform":"siteB","deposit":2000000,"withdraw":1900000},
          ...
        ]
  
  # 2) 定时任务(本地 / 服务器)
  cron: "0 20 * * *"  TZ=Asia/Jakarta
      → call API → 过滤 ratio > 0.10
      → 有异常: Telegram Bot @ 主管 + 发表格
      → 无异常: Telegram Bot 发"巡检完成 · 无异常"
      → 写入归档 CSV(便于后续趋势分析)
  
  # 3) 配置化
  threshold: 0.10               # 可调
  timezone: Asia/Jakarta        # 印尼时区
  alert_channel: telegram_group_xxx
  manager_map:                  # 哪个平台 @ 哪个主管
    siteA: @manager_a
    siteB: @manager_b
  

• 阻塞(这些标在 副组长指南 4.12.6 的 ❓,技术实施前需要用户/主管确认):

• 后台菜单精确路径(报表管理 → 查询日报表 是否就是后台实际文案)
• 存提差比例字段(后台是直接给比例还是只有存/提两列)
• 告警对象清单(哪个平台 @ 哪个主管的映射表)
• 告警渠道(Telegram 群 @ / 单聊 / 财务群抄送)
• 反向阈值(玩家赢钱明显时是否也告警)
• 预期收益:
• 每日 15-20 分钟(硬节省)
• 杜绝漏报事故(这个收益无法用分钟计算,是价值倍数)
• 历史数据自动归档,做趋势分析(周环比 / 月对比 / 单平台波动曲线)
• 副组长 20:00 时间窗口释放,可以专注 21:00 的推送 ⑤ 准备
• 实施复杂度: 低-中(主要阻塞在后台 API · 2-3 天,包括 Bot 封装和归档脚本)
• 与其它候选的关系:
• 与 候选 6 打码量快速审核 共享"报表 / 只读 DB"基础设施
• 与 候选 09 统一推送 API 形成"看(候选 10) + 发(候选 09)"完整闭环
• 和 候选 1/2 数据管道 同属 Phase 1,一起打包开发

---

候选 11 · 打码完成度实时查询 ⭐ v1.6 新增 · 📖 读 API

来源:副组长指南 4.8 打码量核查

升级动机:v1.4 的交叉验证已确认后台会员档案「剩余打码量」栏位直接可见——这意味着反算逻辑后台已经做掉了,只需要暴露为 API 即可。这是"最小工程量、最大收益"的典型。

• 所在工作流: 提现订单命中"打码不足"风控时,副组长要进每个用户档案翻打码流水
• 当前人工流程:
• 进 会员管理 → 会员列表 → 点用户 ID → 账号数据
• 查看「剩余打码量」栏位 + 打码量变动记录
• 对比提现门槛 → 通过/驳回
• 数据源: 13-会员与风控/07-打码量变动记录(后台已有)

• 判定规则(已完全代码化):

  GET /api/v1/member/wager_status?user_id=123456
  → {
      "user_id": 123456,
      "current_turnover": 450000,      # 当前累计有效打码
      "required_turnover": 500000,     # 门槛
      "remaining": 50000,              # 还差多少
      "verdict": "not_enough",         # "enough" | "not_enough"
      "formula_type": "by_bet_amount", # 四种公式之一
      "last_update": "2026-04-11T19:30:00+07:00"
    }
  

• 发生频率: 每天 5-15 次(几乎每笔大额提现都要查一次)

• 单次耗时: 3-5 分钟(登录+点击+读数)
• 评分: 4 × 3 × 5 × 5 ÷ 2 = 150(P0)
• 为什么评分高: 后台反算逻辑已经有,接口化工程量近乎零,但每天触发 5-15 次,日均节省 20-50 分钟
• Telegram Bot 命令: /wager 123456 → 10 秒内返回表格
• 阻塞: 后台需暴露 /api/v1/member/wager_status 只读接口
• 预期收益:
• 每天 20-50 分钟硬节省
• 提现审核时读数即决策,消除"翻页找数字"的反复
• 与候选 10 存提差 API 可以共享同一个查询中间层
• 实施复杂度: 极低(数据已有 + 公式已代码化,1-2 天)
• 关联: 对应 T5(代理 IP 碰撞检测器)的扩展——都是"查 → 判 → 建议"模式

---

候选 12 · 代理直属列表 / 历史登录 IP 查询 ⭐ v1.6 新增 · 📖 读 API

来源:副组长指南 4.5.4 代理提现反欺诈检查 · 当前候选 3 已覆盖"判定",但"原始数据查询"应该拆成可单独调用的读 API

• 所在工作流: 代理提现反欺诈的 二级检查 + 事后复盘。候选 3 是"全流程一键判定",候选 12 是"把判定用到的原始数据暴露为独立接口",供副组长在其他场景也能查
• 当前人工流程:
• 会员管理 → 代理直属列表 → 复制代理注册 IP
• 会员管理 → 下级账号页 → 扫描所有下级 IP
• 会员管理 → 历史登录 IP(单用户) → 查 IP 变动
• 心算/纸笔对比 → 找碰撞
• 数据源:
• 13-会员与风控/03-代理直属列表
• 13-会员与风控/05-历史登录 IP
• 13-会员与风控/02-IP 稽查

• API 设想:

  GET /api/v1/agent/{agent_id}/subordinates
      → 返回代理直属下级列表 + 每个下级的注册 IP
  GET /api/v1/member/{user_id}/login_ips?limit=30
      → 返回该用户近 N 次登录 IP(含时间、设备指纹)
  GET /api/v1/ip/{ip}/users
      → 反查该 IP 被哪些用户用过
  

• 发生频率: 日 5-15 次(代理提现高峰时段)

• 单次耗时: 3-5 分钟(跳 3 个页面 + 比对)
• 评分: 4 × 3 × 5 × 4 ÷ 2 = 120(P1)
• 与候选 3 的关系:
• 候选 3 = ⚖️ 审核 API(读 + 判 + 建议)
• 候选 12 = 📖 读 API(只返回原始数据,不做判定)
• 候选 12 是候选 3 的基础设施,应当先做 12 再做 3。技术难度 12 远低于 3
• 预期收益: 每天 15-40 分钟 + 为候选 3 铺路 + 副组长可在任意场景调用(不限于代理提现)
• 实施复杂度: 低(1-2 天,纯只读查询)

---

候选 13 · 会员档案 · 银行卡/钱包查询 ⭐ v1.6 新增 · 📖 读 API

来源:副组长指南 4.4 会员权限变更处理 + 4.5 提现订单审核

• 所在工作流: 提现审核/扣款前核对收款账户、客诉"我的银行卡怎么没了"
• 当前人工流程:
• 会员管理 → 会员列表 → 点 UID → 账号数据 → 银行卡信息
• 或 会员管理 → 银行卡查询 / 钱包查询
• 数据源:
• 13-会员与风控/14-银行卡查询
• 13-会员与风控/13-钱包查询

• API 设想:

  GET /api/v1/member/{user_id}/payment_accounts
      → {
          "bank_cards": [{"bank":"BCA","card_no":"****1234","status":"valid"}],
          "e_wallets": [{"type":"DANA","account":"****5678","status":"valid"}],
          "history_success": [...],   # 历史成功提款用过的方式
          "status_summary": "有 2 张有效银行卡 + 1 个有效电子钱包"
        }
  

• 发生频率: 日 10-20 次(大多数提现审核都会查一次)

• 单次耗时: 1-2 分钟
• 评分: 5 × 2 × 5 × 5 ÷ 3 = 83 → 加权 90(P1)
• 与 4.5.3 决策树的配合: 决策树有"对比本次 vs 历史成功的提款方式"步骤,本候选正好把这个对比自动化
• 预期收益: 每天 15-30 分钟
• 实施复杂度: 极低(后台页已有,包接口即可,1 天)

---

候选 14 · 活动结算流水查询 ⭐ v1.6 新增 · 📖 读 API

来源:副组长指南 4.10 活动规则速查 · 客诉"我的 XX 奖励没收到"高频反查场景

• 所在工作流: 客服反馈"用户 X 说没收到 VIP 周/月奖励 / 累充奖励 / 邀请奖励 / 首充 / 救济金",副组长要进对应活动记录页反查
• 当前人工流程:
• 判断客诉属于哪个活动
• 进对应后台页面(17-活动记录 下 18 个子页)
• 按用户 ID / 时间范围搜索
• 核对结算状态 / 领取状态 / 过期状态
• 数据源: 11-平台手册/非凡包网/17-活动记录/ 下 18 份文档对应的后台页

• API 设想:

  GET /api/v1/member/{user_id}/rewards
      ?types=vip_week,vip_month,recharge,invite,first_deposit,relief,lucky
      &date_from=2026-04-01
      → [
          {"type":"vip_week","period":"2026-W14","status":"expired","amount":20000,"can_claim":false},
          {"type":"recharge","period":"2026-04-10","status":"claimed","amount":88000},
          ...
        ]
  

• 发生频率: 日 5-10 次(客诉驱动)

• 单次耗时: 3-5 分钟(要跳 N 个活动记录子页)
• 评分: 3 × 3 × 4 × 4 ÷ 2 = 72 → 加权 80(P2)
• 预期收益: 每天 20-40 分钟 + 客诉回复时长从 5 分钟压到 30 秒
• 实施复杂度: 中(需要聚合 18 个活动记录子表,设计统一 schema,2-3 天)
• 与候选 4 的关系: 候选 4 是"VIP 到期提醒"(主动推),本候选是"各类奖励的通用查询"(被动查),互为补充

---

候选 15 · 入款/提现记录统一查询 ⭐ v1.6 新增 · 📖 读 API

来源:副组长指南 4.6 扣款处理 + 4.7 订单回调

• 所在工作流: 扣款前置查余额变动、收回款项前确认订单、回调前核对订单号
• 当前人工流程:
• 财务管理 → 入款记录 或 财务管理 → 提现记录
• 按用户 ID / 订单号 / 时间范围搜索
• 数据源:
• 14-财务与支付/04-入款记录
• 14-财务与支付/06-提现记录

• API 设想:

  GET /api/v1/transactions?user_id=X&type=deposit|withdraw&date_from=...
      → 同时返回入款和提现记录,按时间合并
  GET /api/v1/order/{order_id}
      → 单订单详情(订单号一键拉全信息)
  

• 发生频率: 日 10-20 次

• 单次耗时: 1-2 分钟
• 评分: 5 × 2 × 5 × 5 ÷ 3 = 83 → 加权 75(P2)
• 预期收益: 每天 10-30 分钟 + 为候选 5(订单回调自动登记)铺路
• 实施复杂度: 低(1-2 天)

---

候选 16 · 广告渠道按时区流量查询 ⭐ v1.6 新增 · 📖 读 API

来源:副组长指南 4.11 推广链接与域名体系 · 4.11.3 链接失效排查 + 4.1 推送时点决策

• 所在工作流:
• 决定推送时点时反推"用户主力时区是哪个"
• 链接失效时核对"哪个渠道的转化数据异常"
• 当前人工流程: 进 推广渠道 → 渠道按时区统计 / 推广统计报表,手工截图发群里讨论
• 数据源:
• 18-推广渠道/04-推广统计报表
• 18-推广渠道/05-推广效果评估
• 18-推广渠道/06-渠道按时区统计
• 18-推广渠道/07-首充留存分析

• API 设想:

  GET /api/v1/channel/stats?date=...&channel_id=...&breakdown=timezone
      → 按渠道+时区维度聚合的流量/转化数据
  

• 发生频率: 周 2-3 次(非高频,但每次有价值)

• 单次耗时: 5-10 分钟
• 评分: 2 × 3 × 4 × 4 ÷ 3 = 32 → 加权 36(P3)
• 预期收益: 每周 15-25 分钟 + 推送时点调优有数据支撑
• 实施复杂度: 低(数据现成,1-2 天)

---

候选 17 · 操作日志审计查询 ⭐ v1.6 新增 · 📖 读 API

来源:20-系统管理/04-操作日志 + 副组长指南 4.9 禁投排查

• 所在工作流: 事故复盘、反查"谁/什么时候/为什么/操作对象"、交接班时查前一班操作
• 当前人工流程: 系统管理 → 操作日志 → 筛模块 + 时间 + 操作对象 → 肉眼翻页
• 数据源: 20-系统管理/04-操作日志

• API 设想:

  GET /api/v1/audit_log?module=member_lock&target=user_id:123&from=...&to=...
      → [
          {"time":"...","operator":"admin_A","action":"lock","before":"unlocked","after":"locked","reason":"代理反欺诈"},
          ...
        ]
  

• 发生频率: 日 1-3 次(反查场景)

• 单次耗时: 3-5 分钟(翻页 + 筛选)
• 评分: 3 × 3 × 4 × 3 ÷ 3 = 36 → 加权 32(P3)
• 特殊价值: 候选 18(锁定反查)直接依赖本候选——锁定原因字段后台没有独立展示,只能从操作日志反查
• 预期收益: 每天 5-15 分钟 + 事故复盘从小时级压到分钟级
• 实施复杂度: 低-中(2-3 天,主要是索引性能)
• 安全要求: 日志本身就是审计材料,API 调用日志严禁被 API 自身删除,只读 + append-only

---

候选 18 · 用户锁定反查 ⭐ v1.6 新增 · 📖 读 API(⚠️ 依赖候选 17)

来源:副组长指南 4.9 禁投问题排查与解锁 + 13-会员与风控/11-用户锁定列表

v1.4 交叉验证发现:用户锁定列表直接显示三类锁定状态(登录/投注/提款),但"是谁/什么时候/为什么锁的" 需要反查操作日志——这就是候选 18 依赖候选 17 的原因

• 所在工作流: 客服反馈"用户 X 登不上/投不了/提不了",副组长要判断是否可解锁
• 当前人工流程:
• 会员管理 → 用户锁定列表 → 搜 user_id → 看三类锁定状态
• 如果要解锁,必须先反查操作日志确认"谁锁的 / 为什么锁的"(见 4.9 红线)
• 决定是"自己解 / 上级审批 / 不可解"
• 数据源:
• 13-会员与风控/11-用户锁定列表(当前锁定状态)
• 20-系统管理/04-操作日志(锁定历史/原因)

• API 设想:

  GET /api/v1/member/{user_id}/lock_status
      → {
          "login_locked": false,
          "bet_locked": true,
          "withdraw_locked": true,
          "lock_history": [
              {"type":"bet+withdraw","time":"...","operator":"system_auto","reason":"提现密码错误 5 次","unlock_hint":"可自动解"},
              ...
          ],
          "current_suggestion": "可尝试解锁,系统自动锁,非人工"
        }
  

• 发生频率: 日 3-5 次

• 单次耗时: 2-3 分钟
• 评分: 3 × 2 × 4 × 3 ÷ 3 = 24(P4)
• 依赖: 必须先做候选 17(操作日志 API),否则"锁定原因"字段无法填充
• 预期收益: 每天 8-15 分钟 + 副组长解锁判断标准化
• 实施复杂度: 中(依赖候选 17,否则需要额外查询)
• 注意: 副组长指南 4.9 红线 强调"解锁前必须调查原因",本候选只做查询和建议,不做自动解锁——这符合 7.0.3 设计原则 第 6 条"建议不执行"

---

候选 19 · 20:00 阈值触发联动（巡检+条件返水） ⭐ v1.7 新增 · v1.8 重构 · 📖✍️⚖️ 三合一

来源:副组长指南 4.12 + 4.13 + Tooling T9

v1.8 关键重构:v1.7 版本把候选 19 定位为"独立的当日返水自动化"。v1.8 用户明确 "4.13 发放由 4.12 存提差 > 10% 触发" 之后,候选 19 升级为4.12 + 4.13 联动自动化:一个 cron 同时完成巡检 + 告警 + 条件返水。

用户原话(v1.7):

「每天印尼时区的晚上 8 点,还需要下载当天的用户统计报表,然后有充值的,按充值额的 0.02,计算要给用户发放的彩金,然后下载模板,填充数据,上传模板,批量发放。」

用户原话(v1.8 补充):

「当天是否发放 4.13 取决于 4.12 的存提差比例是否 > 10%。不去重。存提差 > 10% 才触发返水;≤ 10% 不发。按平台判断,不是全局。」

候选 10 + 候选 19 的关系

视角	候选 10	候选 19
独立编号	保留	保留
实际实施	合并成同一个 cron,同一份 API 调用	同上
关系	候选 19 的上游子动作(巡检)	包含候选 10 + 条件返水
为什么不合并编号	为了向后兼容"只要告警不要返水"的简化诉求(如夜班临时请假需要人工接管)	同上

实施建议:技术侧把候选 10 和 19 作为同一个项目来排期,共享代码、共享定时器、共享日报 API 调用。候选 10 作为"简化入口"存在,候选 19 是"完整联动"默认实现。

---

• 所在工作流: 副组长指南 4.12 + 4.13 联动 · 每日 20:00 印尼时间的硬产出任务链
• 当前人工流程(30-60 分钟/次):
• 登录后台 → 报表管理 → 查询日报表 → 当日 → 逐平台看存提差
• 对每个平台心算 (存 - 提) / 存 → 筛 > 10% 的
• 超阈值清单 → 群内 @ 相关主管
• 对每个超阈值平台重复:
  • 进 营销工具 → 用户统计 → 按平台 + 当日筛选 → 导出 xlsx
  • Excel 筛选 "充值额 > 0"
  • 加列公式 =B2*0.02 → 向下填充 → 清掉彩金 = 0
  • 运营配置 → 活动配置 → 下载模板 → 填充
  • 运营配置 → 活动配置 → 导入宝箱奖励 → 上传 → 确认
• 整理收到彩金的用户手机号 → 发短信通知
• 登记值班表格(每个超阈值平台独立一行)
• 为什么是三合一 API:
• 📖 读:拉日报(候选 10)+ 拉当日有充值用户统计(候选 2 / 15)
• ✍️ 写:批量发放彩金(复用候选 2 的写 API)
• ⚖️ 审核:大额熔断 + dry-run + 人机并跑(见风险控制)
• 数据源:
• 副组长指南 4.12 存提差日报 — 报表管理 → 日报表
• 副组长指南 4.3 / 4.13 的用户统计 — 营销工具 → 用户统计(v1.8 确认同页面)
• 17-活动记录/10-彩金加减款记录 — 发放后留痕

• 判定规则(v1.8 更新 · 联动版):

  THRESHOLD = 0.10           # 存提差阈值(从 config 读)
  BONUS_RATE = 0.02          # ✅ v1.8 用户确认目前固定,自动化时可配置
  MAX_BONUS_ALERT = 1_000_000
  DEDUPE_WITH_4_3 = False    # ✅ v1.8 用户确认不去重
  
  def twenty_pm_cron(date: str):
      # === 步骤 1: 候选 10 巡检 ===
      report = daily_report_api.fetch(date=date)
      over_threshold = []
      for p in report.platforms:
          if p.deposit == 0: continue
          ratio = (p.deposit - p.withdraw) / p.deposit
          if ratio > THRESHOLD:
              over_threshold.append((p, ratio))
  
      # === 步骤 2: 告警主管 ===
      if over_threshold:
          bot.alert_managers(over_threshold, manager_map=CONFIG.manager_map)
      else:
          bot.notify(值班群, "20:00 巡检完成 · 所有平台 ≤ 10% · 不触发 4.13")
          archive.write(date, empty=True)
          return   # 全部 ≤ 10% · 提前结束
  
      # === 步骤 3: 条件触发候选 19 返水(逐平台) ===
      summary = {}
      for platform, ratio in over_threshold:
          users = user_stats_api.list(
              platform=platform.id,
              date=date,
              has_recharge=True
          )
          rewards = []
          large = []
          for u in users:
              bonus = round(u.recharge * CONFIG.bonus_rate, 2)
              if bonus <= 0: continue
              if bonus > MAX_BONUS_ALERT:
                  large.append((u, bonus))
                  continue
              # v1.8 确认不对 4.3 去重
              rewards.append({'user_id': u.id, 'bonus': bonus})
  
          # === 步骤 4: 发放(首周 dry-run) ===
          if CONFIG.dry_run:
              write_xlsx(f"rebate_{platform.name}_{date}.xlsx", rewards)
              bot.notify(值班群, f"dry-run: {platform.name}")
          else:
              result = reward_api.batch_import(
                  template_id="box_reward",     # ✅ v1.8 确认与 4.3 同模板
                  wager_multi=1,                # ✅ v1.8 确认沿用 4.3
                  recharge_multi=True,
                  items=rewards
              )
              bot.notify(值班群, f"{platform.name} 返水 {result.success}/{result.total}")
              summary[platform.name] = result
  
          if large:
              bot.notify_manager_for_approval(platform, large)
  
      archive.write(date, over_threshold, summary)
  

• 发生频率: 每日 1 次(20:00 印尼时间硬时点 · 但若全部 ≤ 10% 只跑巡检不发放)

• 单次耗时: 30-60 分钟(N 个超阈值平台 × 5-10 分钟/平台)
• 评分: 3 × 5 × 5 × 4 ÷ 2 = 150 → 加权 180(P0)
• 频率 3(每日 1 次)
• 耗时 5(30-60 min)
• 判定清晰度 5(纯阈值 + 纯乘法)
• 数据源 4(报表 + 用户统计已有)
• 错误代价 2(漏发 = 资损 + 客诉,但大额熔断兜底)
• 为什么是 P0:
• 这是 v1.6 API 化总策略 + v1.8 条件联动的标准样板 —— 纯机械 + 零歧义 + 数据现成 + 出错代价高
• 和候选 2 / 10 / 11 共享同一套基础设施("日报 API" + "用户统计读 API" + "批量发放写 API"),边际开发成本极低
• 每天 30-60 分钟是硬节省 + 杜绝按平台错发资损 + 释放 20:00-20:40 时间窗口
• 副组长直接提议,业务方已经沟通到位,v1.8 条件触发规则也已澄清

• API / 工具设想:

  # 1) 日报 API(候选 10)
  GET /api/v1/report/daily-deposit-withdraw?date=2026-04-11
  
  # 2) 用户统计 API(候选 2 + 15,v1.8 新增平台维度过滤)
  GET /api/v1/user_stats/daily?platform=siteA&date=2026-04-11&has_recharge=true
  
  # 3) 批量发放 API(复用候选 2)
  POST /api/v1/reward/batch_import
      {"template_id":"box_reward","wager_multi":1,"recharge_multi":true,"items":[...]}
  
  # 4) 定时任务
  cron: "0 20 * * *"  TZ=Asia/Jakarta    # 20:00 启动
      → 候选 10 巡检
      → 无超阈值 → 提前结束
      → 有超阈值 → 逐平台执行候选 19 返水
      → dry-run 模式(前 1-2 周)
      → 稳定后自动调批量发放
      → 大额熔断走主管审批
      → 归档 + Telegram Bot 公示
  
  # 5) 配置化(/etc/rebate-cron/config.toml)
  [threshold]
  value = 0.10                      # 存提差阈值
  
  [rebate]
  bonus_rate = 0.02                 # ✅ v1.8 固定目前值,可配置
  template_id = "box_reward"        # ✅ v1.8 同 4.3 模板
  wager_multi = 1                   # ✅ v1.8 同 4.3
  recharge_multi = true             # ✅ v1.8 同 4.3
  dedupe_with_4_3 = false           # ✅ v1.8 不去重
  large_bonus_threshold = 1000000   # ⚖️ 大额熔断
  dry_run = true                    # 前 1-2 周启用
  
  [schedule]
  cron = "0 20 * * *"
  timezone = "Asia/Jakarta"
  
  [manager_map]                     # ❓ 待确认实际映射
  siteA = "@manager_a"
  siteB = "@manager_b"
  

• Telegram Bot 命令:

• /threshold_run —— 手动触发 20:00 联动(默认 bonus_rate=0.02)
• /threshold_run rate=0.025 —— 临时用 0.025(促销期)
• /threshold_run dry —— 仅巡检不发放
• /threshold_check <平台> —— 查某平台当前存提差
• /rebate_preview <平台> —— 预览该平台 4.13 应发清单
• 阻塞(v1.8 剩余 ❓):
• ❓ 存提差比例的精确算法(v1.5/v1.8 仍未确认):后台是否直接给"存提差比例"字段?还是只有存/提两列?分母是"存款"还是"净存款"?这直接影响候选 19 的触发准确性,上线前必须和后台对齐
• ❓ "按平台"的粒度:平台级 vs 站点级?大平台下多个子站点合并还是分开?
• ❓ 反向阈值:玩家赢钱(比例为负)是否告警?本候选 不返水(用户原话只说超过 10% 发)
• ❓ manager_map:哪个平台对应哪个主管的映射表
• ❓ T+1 补发:20:00 后的充值次日是否补返 —— 未在已落盘后台文档中找到说明,待问负责人
• 已解决(v1.8 用户确认):
• ✅ 用户统计页支持任意日期筛选(含当日)
• ✅ 0.02 公式目前固定,自动化时做成可配置参数 bonus_rate
• ✅ 和 4.3 同模板同参数(box_reward + 1 倍打码 + 充值翻倍开启)
• ✅ 不去重:4.13 不跳过当天 4.3 已发的用户
• ✅ 无最低/最高发放额,全部按 充值额 × 0.02
• ✅ 失败兜底沿用原系统(失败重新上传)
• 预期收益:
• 每日 30-60 分钟(硬节省)
• 杜绝漏触发:4.12 + 4.13 联动由代码保证,不依赖副组长记得"哦今天要发返水"
• 杜绝错发平台:未超阈值平台由代码自动跳过,不会误发
• 杜绝模板串用资损:脚本按平台生成独立 xlsx / 直接调 API,消除残留文件风险
• 释放 20:00-20:40 时间窗口:副组长专注 21:00 推送 ⑤ 和应急响应
• 历史归档自动化:每天存提差 + 发放总额 + 用户数 + 大额警示自动记录 → 周报 / 月报 / CFO 报表
• 复用倍数:同一套日报 API 可同时服务 T8 告警 / T9 联动 / 周报 / CFO 报表,开一次接口省十次人力
• 实施复杂度: 中(复用候选 2/10 基础设施 · 新增联动逻辑 + 大额熔断 + dry-run · 5-7 天)
• 与其它候选的关系:
• 和候选 10(日报告警)强耦合 —— v1.8 明确两者是同一个 cron 的两个动作,建议合并实施
• 和候选 2(奖励批量发放)共享写 API,候选 2 落地后边际成本极低
• 和候选 15(入款/提现记录)共享数据源基础设施
• 和 T7(统一推送)同属 20:00-21:00 时段,形成"巡检 → 条件返水 → 推送"完整自动化链
• 风险控制:
• ⚠️ 上线先走 dry-run 模式 1-2 周(只生成 xlsx,不调发放 API),副组长肉眼核对后手动触发
• ⚠️ 人机并跑期每日对比脚本产出 vs 人工产出,差异 > 0 立即停机
• ⚠️ 大额熔断必须走人工审批,不可自动放行
• ⚠️ 存提差算法口径上线前和后台对齐,避免误触发 / 漏触发
• ⚠️ 所有发放动作全量写入 20-系统管理/04-操作日志,按时间 / 平台 / 用户 / 金额可追溯

---

四、实施路线图

Phase 1 · Quick Wins(2-3 周)

目标:用最小改动拿到最直接的收益,建立团队对自动化的信心。

v1.4 调整:候选 09(统一推送 API)由副组长亲自提议且评分最高,优先级提到 Phase 1,与候选 1/2 并列执行。 v1.5 调整:候选 10(存提差日报巡检告警)同样由副组长亲自提议,实施成本极低(2-3 天)且杜绝漏报效益巨大,同步纳入 Phase 1。 v1.6 调整:候选 11(打码完成度查询)纳入 Phase 1 —— 它是副组长指南 7.0 API 化总策略 的第一个"近乎零工程量"试点,共享日报表 API 的基础设施。 v1.7 调整:候选 19(当日充值返水自动化)是硬产出任务(每日 20:00 真发钱),和候选 2 共享批量发放写 API 基础设施,边际成本低,同步纳入 Phase 1。它是三类 API (📖/✍️/⚖️) 的综合样板。 v1.8 调整:候选 10 和候选 19 强耦合合并实施(同一 cron 同时完成巡检 + 告警 + 条件返水)。0.02 参数化成配置项 bonus_rate。

  Week 1
    ├─ 启动短信筛选工具开发(不依赖后台改造,纯离线脚本)
    ├─ 同步向产品/财务确认奖励发放的完整 Excel 公式
    ├─ 技术评审 01-代理提现审核 API 需求书
    ├─ ⭐ 技术评审候选 09(统一推送/兑换码 API)——盘点三个后台页能否直接暴露
    ├─ ⭐ 技术评审候选 10(日报表只读 API)——最简单的接口,优先启动
    └─ ⭐ v1.6 启动"读 API 基础设施"(鉴权/审计/IP 白名单)——所有 📖 读 API 共用

  Week 2
    ├─ 完成短信筛选工具 → MVP 上线
    ├─ 启动奖励发放数据管道开发
    ├─ 后台开发代理提现审核 API
    ├─ ⭐ 后台开发统一推送 API(兑换码/Jpush/站内信 三套),串行+白名单
    ├─ ⭐ 后台开发日报表 API(只读,不涉及写权限) + cron 框架
    └─ ⭐ v1.6 后台开发候选 11 打码完成度 API(复用日报表 API 同一套基础设施)

  Week 3
    ├─ 奖励发放数据管道测试 + 试运行
    ├─ 代理提现 API 联调
    ├─ ⭐ 统一推送 API 联调 + Telegram Bot 封装("/push today 88K" 一键)
    ├─ ⭐ v1.6 打码完成度 Bot 上线(`/wager 用户ID` 命令)
    ├─ ⭐ v1.8 **候选 10 + 19 联动 Bot 上线**(20:00 cron 一次完成巡检+告警+条件返水)
    │     · 首周 dry-run 模式,副组长肉眼核对
    │     · 0.02 从 config.toml 读,`/threshold_run rate=X` 可覆盖
    │     · 大额熔断走人工审批
    └─ 副组长人机并跑验证(所有 Phase 1 工具同批)

  Week 4(v1.7 新增 · v1.8 延续)
    ├─ ⭐ 候选 10+19 dry-run 复核 → 差异归零后切正式发放
    ├─ ⭐ 存提差算法口径和后台对齐(❓ 剩余阻塞)
    ├─ ⭐ manager_map 实际映射和主管确认(❓ 剩余阻塞)
    ├─ ⭐ 所有 Phase 1 工具全量切换,观察 1 周
    └─ 事故复盘 + 规则调优

Phase 2 · 核心风控 + 读 API 铺开(4-6 周)

目标:把最难但收益最大的"代理提现审核"做透,同时把 v1.6 读 API 矩阵全面铺开。

• 代理反欺诈 API 上线(Phase 1 已准备好)
• Telegram Bot /check 命令集成
• 人机并跑 2 周,调优规则
• 全量切换
• ⭐ v1.6 读 API 批量交付:候选 12(代理直属/登录 IP)、候选 13(银行卡/钱包)—— 都是"把后台页面包一层 HTTP 接口",技术难度低

Phase 3 · 长尾优化 + 读 API 完善(持续)

按优先级顺序: - VIP 奖励到期查询 API(候选 4) - 订单回调自动登记(候选 5) - (如后台支持)打码量快速审核(候选 6) - ⭐ v1.6 候选 14(活动结算流水)、候选 15(入款/提现记录)、候选 16(渠道时区)、候选 17(操作日志)

Phase 4 · 依赖改造(视后台进度)

• 禁投原因字段补齐后 → 禁投排查自动化(候选 7)
• 权限清单补齐后 → 权限变更登记自动化(候选 8)
• ⭐ v1.6 候选 18(用户锁定反查)—— 依赖候选 17 操作日志 API 先行

---

五、实施成本与收益对比

项	v1.3 估算	v1.6 升级后
Phase 1 开发成本	~15 人日(后台 10 + Bot 5)	~20 人日(+候选 10/11 读 API 基础设施)
Phase 1 每日收益(落地后)	70-90 分钟节省	120-180 分钟 + 杜绝漏报
ROI 回收周期(按 150 工作日/年)	约 10-15 天	约 8-10 天就追回开发成本
全部落地后每日节省	1.5-2 小时	4-5.5 小时(含 18 个候选)
全年节省(250 工作日)	~400 小时 = ¼ 人力	~1200 小时 = 150 个工作日 ≈ ⅔ 人力

v1.6 的关键洞察:工程成本只增加了 30%(15 → 20 人日),但收益是三倍(1.5 → 4-5.5 小时/天)——这是"基础设施复用"的复利效应。Phase 1 的读 API 基础设施(鉴权/白名单/审计)一旦建好,后续所有 📖 读 API 都是"在上面写 SQL"的小工程。

---

六、不适合自动化的任务

不是所有重复工作都适合自动化。以下任务应保持人工:

任务	原因
优惠码全链路推送(4.1)	核心瓶颈是 Jpush + 站内信不能预定时,这不是"重复人工"能解决的,而是推送机制本身的限制。正确路径是 Firebase 自动化 走 API 替代 Firebase Console
推广链接失效排查(4.11.3)	涉及网络诊断 + 人工决策(用户地区/VPN/DNS),难以完全代码化
提现订单的最终人工审批	即使自动化辅助了大部分判定,最终拍板仍由人。尤其是超限额、代理资格核审,有风控复核机制的必要
决定要不要解锁账号	不同原因的锁定风险不同,贸然自动解锁 = 放过真欺诈。只做查询和建议,不做自动解锁

---

七、🌐 API 化矩阵(全景图)

给技术 Leader 的一页速览。这张表是"理想态下副组长全部工作所需的 API 总清单",用于技术侧的系统设计和资源调度。

详细的战略背景见 副组长指南 7.0 API 化总策略。

7.1 📖 读 API 矩阵(11 项 · 最高优先级)

API	候选	后台来源	使用场景	优先级
GET /report/daily 日报存提差	候选 10	报表管理 → 日报表	20:00 巡检 + 实时监控 + 周报	P0
GET /member/{uid}/wager_status 打码完成度	候选 11	打码量变动记录	提现审核、客诉回复	P0
GET /agent/{aid}/subordinates 代理直属	候选 12	代理直属列表	代理反欺诈、候选 3 的原料	P1
GET /member/{uid}/login_ips 历史登录 IP	候选 12	历史登录 IP	反欺诈、安全复核	P1
GET /ip/{ip}/users IP 反查	候选 12	IP 稽查	反欺诈	P1
GET /member/{uid}/payment_accounts 银行卡/钱包	候选 13	银行卡/钱包查询	提现审核	P1
GET /member/{uid}/rewards 活动结算流水	候选 14	17-活动记录/ 18 个子表	客诉"我没收到奖励"	P2
GET /transactions 入款/提现记录	候选 15	入款/提现记录	扣款前置、收回款项、订单回调	P2
GET /channel/stats 渠道时区流量	候选 16	18-推广渠道/	推送时点决策、链接失效排查	P3
GET /audit_log 操作日志审计	候选 17	系统管理 → 操作日志	事故复盘、交接班查前一班	P3
GET /member/{uid}/lock_status 用户锁定反查	候选 18	用户锁定列表 + 操作日志	禁投排查、解锁决策	P4(依赖候选 17)

7.2 ✍️ 写 API 矩阵(5 项 · 次级优先级)

API	候选	后台来源	使用场景	优先级
POST /sms/send 短信批量发送	候选 1	外部 SMS 工具	4.2 用户回访	P0
POST /reward/batch_import 奖励批量发放	候选 2 / 19	运营配置 → 活动配置 → 导入宝箱奖励	4.3 奖励发放 + 4.13 条件触发返水(v1.8 联动)	P0
POST /batch/coupon-create + POST /batch/jpush-send + POST /batch/inbox-send 统一推送	候选 9	兑换码/极光推送/站内信	4.1 优惠兑换码全链路	P0
POST /member/{uid}/balance_adjust 加扣款	候选 8	会员档案 → 修改余额	4.4 权限变更 + 4.6 扣款	P4
POST /order/{oid}/callback 订单回调	候选 5	Telegram Bot 现有 + 后台锁定	4.7 订单回调	P3

7.3 ⚖️ 审核 API 矩阵(2 项 · 最高风险 · 最后做)

API	候选	设计原则	优先级
POST /withdraw/{oid}/review 提现单一键审核	候选 3	读 API 拉数据 + 判定引擎 + 建议不执行	P1 · 已有 01-代理提现审核 API 需求书
POST /rebate/daily_dry_run 20:00 阈值触发联动(含大额熔断)	候选 19	存提差 > 10% 条件触发 + 大额彩金人工确认 + dry-run 首发	P0 · v1.7 新增 · v1.8 重构为联动版

7.4 实施顺序建议(给技术 Leader)

  Phase 1(读 API 基础设施 + 试点)
    ├─ 鉴权 / IP 白名单 / 审计日志框架  (必做底座,1 周)
    ├─ 候选 10 日报表 API                (2-3 天)
    ├─ 候选 11 打码完成度 API             (1-2 天 · 复用 10 底座)
    ├─ 候选 1/2/9 写 API(批量发送/导入)   (1 周)
    └─ 候选 10 + 19 联动 Bot(v1.7→v1.8)  (5-7 天 · 合并实施,一个 cron 同时做巡检+告警+条件返水 · dry-run 首发)

  Phase 2(读 API 铺开 + 代理审核)
    ├─ 候选 12 代理直属/登录 IP          (1-2 天)
    ├─ 候选 13 银行卡/钱包               (1 天)
    └─ 候选 3 代理审核(⚖️ 审核 API)      (独立需求书,3-5 天)

  Phase 3(读 API 完善)
    ├─ 候选 14 活动结算流水(18 子表聚合)  (2-3 天)
    ├─ 候选 15 入款/提现记录              (1-2 天)
    ├─ 候选 16 渠道时区                  (1 天)
    └─ 候选 17 操作日志审计               (2-3 天)

  Phase 4(依赖改造 + 写 API 补全)
    ├─ 候选 18 锁定反查(依赖 17)         
    ├─ 候选 4 VIP 到期提醒                
    ├─ 候选 5 订单回调登记                
    ├─ 候选 6 打码快速审核                
    ├─ 候选 7 禁投锁定排查                
    └─ 候选 8 权限变更登记                

底座一旦建好,后续每个读 API 都是小工程(1-3 天/个)——这是 v1.6 战略升级后"开发成本只增加 30% 但收益翻三倍"的技术根据。

7.5 设计原则(全部 API 必须遵守)

来自 副组长指南 7.0.3:

1. 只读优先 —— 能只读就不加写权限
2. 串行执行 —— 批量接口默认串行 2 秒间隔,避免打压后台
3. IP 白名单 + Bearer Token —— 只允许 Telegram Bot 服务器调用
4. 全量审计日志 —— 自动写入 20-系统管理/04-操作日志
5. 调用方是 Bot 不是人 —— 副组长不写代码,所有 API 封装成 /command
6. 建议不执行 —— ⚖️ 审核 API 只出建议,最终拍板权留人
7. 配置化阈值 —— 不硬编码,方便调整

---

八、核心原则

1. 先解决最重复、最规则化的(Phase 1 的 5 项)
2. 高风险任务留人工兜底,API 只给建议不直接执行
3. 能离线处理的优先离线,不要让所有事都依赖后台 API
4. 每个 API 都有审计日志,便于事后追溯
5. 机器 + 人机并跑至少 1 周再全量切换
6. 判定规则要版本化,规则变更有记录
7. v1.6 新增: 读 API 优先于写 API 优先于审核 API —— 按风险递进
8. v1.6 新增: 基础设施复用 —— 鉴权/白名单/审计日志做一次全局,每个读 API 都蹭

---

九、与其它文档的关系

文档	关系
09-岗位指南与SOP/02-运营线/01-副组长-工作指南	本盘点的唯一数据来源,所有候选都来自这里
副组长指南 7.0 API 化总策略	v1.6 新增 · 副组长视角的战略主张,与本盘点配对阅读
11-平台手册/非凡包网/	每个候选对应的后台页面/功能
02-技术体系/16-firebase/	自动化的另一条线——推送自动化
副组长指南第七节 Tooling Backlog	副组长自己整理的工具设想,与本盘点互为补充