06 · 稽核组长工作指南¶
适用对象：稽核组长、现场稽核（培训/质检用） 内容来源：远程稽核岗位新入职操作手册 V1.0 + 学习笔记 作者：Bob ｜ 日期：2026-04-26 状态：初稿，持续更新中
一、稽核组长角色定位¶
1.1 管理范围¶
📝 来源：学习讨论
稽核组长管理 现场稽核 和 远程稽核 两类人员，只有一个稽核组，内部按平台分配不同人处理 A 组和 C 组。
各组对应平台：
| 组 | 平台（共 27 个） |
|---|---|
| A 组（14 个） | 7777W · RP66 · RPRR · RP55 · YYRR · SL888 · 888R · SL999 · 99SL · RP99 · 9SL · RK55 · VC55 · FW66 |
| C 组（13 个） | 666F · S9S9 · F7F7 · RT99 · 33L · AFAF · RK88 · CU888 · 777RT · RK77 · 55RT · SP666 · SPN88 |
| 人员类型 | 工作环境 | 主要职责 |
|---|---|---|
| 现场稽核 | 现场办公 | 负责远程稽核的培训和质检 |
| 远程稽核 | AWS 云桌面 | 处理代理提款订单审核、识别套利用户 |
组长可通过 监控远程桌面 查看远程稽核的工作情况。
1.2 核心职责¶
📝 来源：学习讨论
| 序号 | 职责 | 说明 |
|---|---|---|
| 1 | 培训管理 | 通过现场稽核对远程稽核进行岗前培训和持续指导 |
| 2 | 质检监督 | 安排专人质检 + 绩效加减分制度 |
| 3 | 疑难处理 | 处理下属无法处理的问题 |
| 4 | 日常异常排查 | 存提差异常 + 大额用户排查（含正常大客户回馈）+ 游戏回报率排查 + 代收代付渠道异常排查 |
| 5 | 处理下属反馈 | 处理现场稽核/远程稽核/副组长反馈的无法自行解决的问题（日常占比最大） |
| 6 | 绩效管理 | 远程稽核工作量统计与绩效评估 |
1.3 与副组长的协作关系¶
📝 来源：学习讨论
稽核团队与副组长在代理套利处理上形成 两层防线：
flowchart TD
A["远程稽核 · 第一层防护<br/>发现套利嫌疑 → P1 警告 / P2 处理"]
A -->|上呈| B["副组长 · 第二层核验<br/>二次审核 → 确认 / 推翻 P2 判定"]
B -->|确认| C["执行扣款 → 恢复权限 → 通知客服"]
C --> D["完成闭环"]
B -.推翻.-> E["驳回 / 放行"]远程稽核的主要工作：
| 代号 | 工作内容 | 说明 |
|---|---|---|
| A | 处理代理提款订单 | 识别套利用户，执行 P1/P2 处理 |
| B | 处理用户不允许出款 | 被发现疑似套利的用户后续处理 |
关键分工：远程稽核是第一层防护和识别，副组长是二次排查核验并处理。详见副组长工作指南 4.1.5 代理提现审核流程。
二、远程稽核团队管理¶
2.1 入职流程¶
📘 来源：远程稽核 SOP（V1.0，2026-03-08）
远程稽核入职需要完成以下步骤：
步骤一：账号领取与云桌面登录¶
目标：获取准入验证码，进入虚拟办公环境。
- 新人第一天上班，联系【远程管理人】或【组长/副组长】领取个人专属的云桌面网址/账号及密码
- 严禁私自提供他人账号登录
登录操作：
输入账号 + 密码 + 验证码（验证码找管理人员领取）： - 第一行：帐号 - 第二行：密码 - 第三行：验证码
点击链接 → 点击电脑图标 → 打开链接，进入云桌面。
步骤二：环境适应——云桌面基本操作¶
目标：熟悉云桌面内的基本操作，为工作做准备。
进入云桌面后，观察桌面布局。通常桌面上会有预设好的工作图标： - 浏览器（Chrome 或 Edge） - Telegram、Signal - 截图软件 - 搜狗输入法 - 内部系统快捷方式
步骤三：后台网址开启与 MFA 绑定¶
目标：进入实际工作系统，完成双重身份验证。
- 在云桌面内打开指定的浏览器
- 在浏览器地址栏输入【稽核后台系统】的网址（管理人员提供）
首次登录绑定 Google Authenticator 流程：
- 手机下载 Google Authenticator
- 后台网址打开后，点击「我还未绑定验证码，点击此处绑定」
- 输入账号 + 密码，点击「下一步」，屏幕会显示二维码
- 拿出手机，打开 Google Authenticator，扫描屏幕上的二维码
- 输入 APP 上显示的 6 位动态验证码，完成绑定
以后每次登录都需要输入这串变化的数字。
步骤四：岗前培训¶
目标：理解业务逻辑，上手实操。
- 登录云桌面后，打开指定的线上会议网址，加入导师发起的培训会议链接
- 导师讲解基础流程（详见第三节"标准操作流程"）
2.2 日常管理制度¶
📘 来源：远程稽核 SOP
2.2.1 串号禁令¶
上班第一时间必须优先登录自己的后台账号。严禁使用其他班次同事的账号进行工作，否则会导致：
| 后果 | 说明 |
|---|---|
| 工作量错乱 | 你的稽核记录会算在别人头上，导致个人绩效数据失真 |
| 责任追溯不清 | 一旦出现稽核误判，系统记录的操作人将无法反映真实责任人 |
强调提示：若发现他人账号未退出，请立即将其退出，再登录自己的账号。
2.2.2 强制登出制度¶
下班前必须严格执行：后台退出 → 云桌面退出。
- 严禁直接关闭笔记本电脑屏幕或断开网络，导致后台及云桌面处于"挂起"或"退出"状态
- 严禁遗留锁定出款
2.2.3 违规处罚条例¶
管理人员将进行不定时巡查或通过系统日志核查登出情况。
| 次数 | 处罚 |
|---|---|
| 第一次发现 | 口头警告，团队内通报提醒 |
| 第二次发现 | 严重违规，绩效扣分处理，取消当月评优资格 |
| 导致安全事件 | 追究直接责任 |
2.2.4 群消息与三方通知制度¶
上班第一时间看群：每日登录后台前，务必先查看团队群消息。
重点关注三类信息：
| 类别 | 内容 |
|---|---|
| 使用哪个三方 | 当前时段指定使用哪个第三方支付通道 |
| 三方维护状态 | 哪个三方通道正在维护中（需避开） |
| 三方出款状态 | 哪个三方通道不能出款（需暂停相关操作或按预案处理） |
信息同步即责任：群内发布的通知属于工作指令的一部分，因忽略群消息导致的操作失误，将按工作差错处理（口头警告 + 团队内通报提醒）。
2.3 质检与绩效¶
📝 来源：学习讨论
| 制度 | 说明 |
|---|---|
| 专人质检 | 组长安排一名业务熟练的稽核成员专门负责质检工作，检查其他远程稽核处理的订单 |
| 质检频率 | 一个班 10 小时，每个站点都要查看 |
| 绩效加减分 | 自己出现错误被扣分，发现别人的错误可以加分，通过这个机制督促团队提升工作质量 |
| 温馨提醒 | 每月有 3 次温馨提醒机会，超出后按扣分规则执行 |
2.3.1 扣分细则¶
| 违规项 | 扣分 |
|---|---|
| 会员未充值，抓错会员且顺利提款 | -3 |
| 会员领取 2 个活动，只抓 1 个（漏抓） | -1 |
| 备注错误 | -1 |
| 驳回未填写原因 | -1 |
| 驳回未填写原因（多次） | -5 |
| 驳回未填写原因，隔日不改善 | 扣分翻倍 |
| 会员没有相同 IP，误抓 | -1 |
| 抓错备注扣款，导致会员被误扣 | -5 |
| 抓错备注扣款，但会员没有被扣 | -1 |
2.3.2 按钮关闭扣分规则¶
| 对象 | 扣分 |
|---|---|
| 新人（警告 1 次） | -1 |
| 老员工 | -1 |
2.3.3 补充说明¶
- 每月有 3 次温馨提醒机会，超出后按上述规则扣分
- 多次违规且隔日不改善者，扣分翻倍
2.3.4 绩效考核指标¶
| 指标 | 权重 |
|---|---|
| 出款数量 | 60% |
| 出勤 | 20% |
| 审核正确率 | 20% |
2.4 处理下属反馈的问题¶
稽核组长日常大部分工作是处理现场稽核或远程稽核反馈过来的他们无法自行解决的问题，有时副组长遇到无法解决的问题也会反馈到稽核组长这里处理。
问题来源：
├─ 现场稽核 → 反馈无法解决的问题
├─ 远程稽核 → 反馈无法解决的问题
└─ 副组长 → 反馈无法解决的问题
│
▼
稽核组长判断处理：
├─ 能直接处理 → 及时处理并反馈
└─ 无法处理 → 反馈给经理
这是日常工作中占比最大的部分——不是主动性排查，而是响应式问题处理。
📝 来源：学习讨论
三、远程稽核标准操作流程¶
3.1 代理提款审核四步法¶
📘 来源：远程稽核 SOP
代理提款审核遵循以下四步标准流程：
步骤 1：优先查看"活动奖励"¶
目的：判断会员参与了什么活动，这是套利的源头。
操作：打开会员详情页 → 查看【活动奖励】与【优惠记录】。
重点关注： - 邀请奖励 - 拼多多活动 - 首存送 - 红利活动等
判定逻辑：如果会员大量参与"邀请奖励"类活动，需高度警惕其通过小号刷取奖励的可能性。
步骤 2：查询"直属下线"与同 IP 检查¶
目的：验证步骤 1 的怀疑，查看该会员是否发展了多个小号或套利团伙。
操作：点击【直属下线】。
IPv4 规则：
- 前三段完全相同（如 114.10.77.228 vs 114.10.77.135）→ 可疑性很大，基本可以判定
- 前三段相近但不完全相同（如 114.10.44.xxx vs 114.10.43.xxx，不同 C 段但相邻）→ 需要注意，结合其他可疑信号判断（如是否同设备类型、同注册时间等）
IPv6 规则：观察 IPv6 地址，如发现下线 IP 完全一致（例：2404:c0:2442:5176:789e:fff:fe2b:e71f），属于典型的多账号同 IP 行为，判定为套利。
步骤 3：点击"资金账变"查看资金动向¶
目的：追踪资金流转路径。
操作：点击【资金账变】。
异常信号：多个小号（下线）同 IP，或下线都存 10 元、20 元。
步骤 4：查看"投注记录"查询投注异常¶
目的：确认会员是否存在真实投注行为，是否有使用自动脚本。
操作：会员管理 → 投注记录。
异常信号：
| 异常类型 | 现象 | 风险 | 判断标准 |
|---|---|---|---|
| 长时间游戏无间断 | 账号连续游戏数小时甚至全天，无任何停顿 | 可能是挂机脚本或机器人程序在自动投注，用于刷流水或套利 | 正常人需要休息、吃饭、睡眠，24 小时不间断游戏基本可判定 |
| 秒切投注（<3 秒） | 每次投注切换游戏或调整金额的时间间隔极短（3 秒以内） | 人为操作通常需要数秒思考或点击，长期秒切极可能是自动化脚本 | 连续多次投注间隔 <3 秒，且持续时间长，视为异常 |
3.2 邀请奖励处理流程¶
📘 来源：远程稽核 SOP
判定流程¶
收到代理提款订单（邀请奖励类）
│
▼
查看会员【备注】栏
│
┌─────┴────────────────────┐
│ │
有备注 无备注
│ │
▼ ▼
备注日期是今天？ 检查 IP 地址
│ │
┌──┴──┐ ┌────┴────┐
│ │ │ │
是 否 同 IP 不同 IP
│ │ │ │
▼ ▼ ▼ ▼
直接 检查最近一次 发出警告 检查下属充值
出款 充值日期 金额
│ │
▼ 全部为 10？
是否已获得邀请奖励？ │
│ ┌────┴────┐
┌─────┴────┐ │ │
│ │ 是 否
没有 已获得 │ │
│ │ ▼ ▼
▼ ▼ 直接抓 正常出款
直接出 检查 IP
地址
│
┌────┴────┐
│ │
同 IP 不同 IP
│ │
▼ ▼
直接抓 正常出款
P1 警告（第一次警告——不用发群）¶
| 项目 | 内容 |
|---|---|
| 账号备注 | BH BAT，Peringatan/P1 bx0215 |
| 驳回备注 | Pelanggaran Terdeteksi! Peringatan ini hanya berlaku sekali. Mohon untuk bermain secara tepat dan benar. |
备注中
bx0215为经手人代号+日期，实际使用时替换为自己的代号和当天日期。
P2 处理（第二次警告）¶
| 项目 | 内容 |
|---|---|
| 账号备注 | BH BAT，P2 tarik Bonus+Kemenangan bx0215 |
| 操作 | 点击会员层级 → 打开套利观察 → 关闭 2 个按钮（投注 + 提款） |
| 发群 | 后台名称 + 会员账号 + BH BAT、P2 tarik Bonus+Kemenangan bx0215 |
| 驳回备注 | Segera hubungi live chat |
3.3 拼多多奖励处理流程¶
📘 来源：远程稽核 SOP
判定流程¶
拼多多奖励的判定流程与邀请奖励基本一致：
- 无备注 → 检查 IP 地址 → 同 IP 则发出警告，否则正常出款
- 有备注且是当天 → 直接出
- 有备注但不是当天 → 检查最近一次充值日期 → 确认是否已获得邀请奖励 → 已获得则检查 IP → 同 IP 直接抓
- IP 不匹配但下属充值金额全部为 10 → 直接抓
P1 处理（拼多多只有 P1，没有单独的 P2）¶
| 项目 | 内容 |
|---|---|
| 账号备注 | BH RK，P1 tarik bonus+kemenangan xq0219 |
| 操作 | 点击会员层级 → 打开套利观察 → 关闭 2 个按钮（投注 + 提款） |
| 发群 | 后台名称 + 会员账号 + BH RK，P1 tarik bonus+kemenangan xq0219 |
| 驳回备注 | Segera hubungi live chat（用户必须联系客服处理） |
拼多多的处理逻辑：拼多多套利一般只到 P1 就结束了。P1 直接关闭投注+提款权限，用户必须联系客服。客服沟通后转交副组长审核——如果副组长确认是拼多多套利，直接走邀请奖励 P2 的扣款流程（扣除彩金+盈利）。
与邀请奖励的区别：邀请奖励是 P1 警告（不关按钮）→ 再犯才 P2 关按钮+扣款。拼多多 P1 就直接关按钮了，后续确认套利后直接进入扣款流程，不再有单独的"拼多多 P2"。
未存款套利处理¶
📘 来源：远程稽核 SOP
会员同 IP 领取奖金但没有存过款的情况：
| 套利类型 | 账号备注 | 操作 | 发群 | 驳回备注 |
|---|---|---|---|---|
| 邀请套利未存款 | BH BAT, tanpa deposit Blockir bx0218 |
关闭 3 个按钮（投注 + 充值 + 提款） | BH BAT, tanpa deposit Blockir bx0218 |
Segera hubungi live chat |
| 拼多多套利未存款 | BH RK，tanpa deposit Blockir jl0307 |
关闭 3 个按钮（投注 + 充值 + 提款） | BH RK，tanpa deposit Blockir jl0307 |
Segera hubungi live chat |
关键区别：未存款套利关闭 3 个按钮（比普通 P2 多关闭"充值"按钮）。
特别注意事项¶
📘 来源：远程稽核 SOP
该客户若是已经把彩金游戏玩了，然后存款后发起的提现订单不能列为套利——除非客户套利了那么才能列为套利会员抓起来扣掉盈利 + 彩金退回本金。
3.4 暴奖倍数核查流程¶
📘 来源：远程稽核 SOP
目的：确认会员的中奖金额是否在游戏设定的正常赔率范围内，防止利用漏洞或修改数据。
操作步骤¶
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 记录中奖信息 | 在后台查看该笔订单的投注金额和中奖金额 |
| 2 | 计算暴奖倍数 | 暴奖倍数 = 中奖金额 ÷ 投注金额 |
| 3 | 查询游戏最高赔率 | 自己打开前台，注册测试账号进入该游戏，查看游戏规则或帮助页面中注明的最高暴奖倍数 |
| 4 | 对比判定 | 实际倍数 vs 游戏设定最高倍数 |
判定标准¶
| 情况 | 判定 |
|---|---|
| 实际倍数 ≤ 游戏设定最高倍数 | 正常 |
| 实际倍数 > 游戏设定最高倍数 | 异常（可能是漏洞或数据错误） |
示例¶
投注 10 元，中奖 100 万元 → 倍数 = 100,000 倍 前台游戏显示最高倍数仅为 5000 倍 → 明显异常，需冻结提款并核查
四、日常异常排查¶
📝 来源：学习讨论
日常异常排查涵盖多个维度：存提差异常（含首充套利）、大额用户异常、游戏回报率异常、代收代付渠道异常。能直接处理的及时处理，不能处理的及时反馈经理。
4.1 存提差异常排查¶
4.1.1 触发条件¶
后台路径：后台 → 报表管理 → 日报表 → 查看存提差比例
日报表中存提差比例出现异常。
- 例如 7777W 正常一整天存提差比例约 12%，早上查的时候正常在 3~7% 左右
- 如果早上已达 >9% 则明显偏高，需要排查
- ⚠️ 以上数值仅为 7777W 的参考，其他平台要根据各自的平均存提差来判断（见下方阈值参考表）
异常原因举例： - 首充套利客户：批量注册+充值，存大额送大额。比如套利者操作 10 个账号，前 8 个输钱后 2 个赢钱，这期间存提差比例就会被搅乱升高 - 周一领取 VIP 彩金：基本会出现负存提差，属于正常情况（见周一特殊情况说明）
排查目的：找出异常 → 解决异常问题 → 不让异常点恶化，早发现能及时止损。
📝 来源：学习讨论
异常阈值参考（根据各平台自身的全天平均存提差推算）：
| 全天平均存提差 | 早上参考范围（约 25~60%） | 异常阈值（约 75%） | 说明 |
|---|---|---|---|
| 8% | 2~5% | >6% | 平均较低的平台 |
| 10% | 3~6% | >7.5% | |
| 12% | 3~7% | >9% | 如 7777W |
| 15% | 4~9% | >11% | |
| 20% | 5~12% | >15% | 平均较高的平台 |
重要：以上数值都是基于全天平均值推算的参考，不同平台的用户行为模式不同，实际正常范围可能有差异。建议各平台连续记录 5-10 个正常工作日的早上/全天比值，校准自己平台的实际正常范围。
⚠️ 周一特殊情况：部分站点周末做活动会发放大量彩金（如周拉回、周救援等），导致周一的存提差可能出现负数或异常偏低。排查前先确认是否该站点近期有活动发放了大量彩金——如果是活动彩金导致的，不视为异常。
📝 来源：学习讨论
4.1.2 首充套利排查流程¶
目前 7777W / RP55 / RP66 / RPRR 四个老站点还保留首充奖励设置，首充套利排查主要针对这些站点。
每日查看日报表存提差比例
│
▼
比例是否异常？
│
┌────┴────┐
│ │
正常 异常
│ │
▼ ▼
继续监控 后台 → 营销工具 → 用户统计 → 导出当日客户
│
▼
筛选用户层级：新用户 / 新用户1
│
▼
按最大充值金额从大到小排序
（如最大 1500，从 300 或 500 开始筛）
│
▼
辅助参考：总投注金额是否异常大
│
▼
逐个检查用户详情：充值 + 提款记录
│
▼
识别套利模式（见下方特征）
首充套利的典型模式：
首充 → 领奖 → 投注
│
┌─────┴─────┐
│ │
赢了 输了
│ │
▼ ▼
分笔提款 领各种补贴
（知道自动 继续博大奖
出款限额）
| 特征 | 说明 |
|---|---|
| 以大博大 | 利用首充奖励本金进行高风险投注 |
| 多账号操作 | 注册多个账号反复领取首充奖励 |
| 分笔提款 | 了解自动出款限额，故意拆分金额 |
| 影响平台存提差 | 不管输赢都拉低存提差比例 |
为什么从用户统计看而不是从活动记录看：直接看异常点就能看到异常会员，不一定只是首存套利的用户——存提差异常可能是多种原因导致的，从用户数据入手能更全面地发现问题。
📝 来源：学习讨论
4.2 大额用户排查（异常 + 正常大客户回馈）¶
在排查存提差异常时，同时关注大额充值/提款用户。注意区分两种情况：
情况 A：异常大额用户——可能是套利或异常行为，需要排查处理 情况 B：正常大客户输钱——真实客户运气不好，无任何申请红利行为 → 主动回馈
4.2.1 情况 B · 正常大客户输钱的回馈机制¶
真实的大客户输钱，无任何申请红利行为，只是运气不好——这种用户要主动回馈，不要等到固定时间点。
操作：赠送客户充值的 2% 导入宝箱奖励。发现就送，不用刻意等时间点。
目的：回馈与激励机制，本质是希望客户能记住网站，提升留存。
📝 来源：学习讨论
4.2.2 情况 A · 异常大额用户排查¶
在排查存提差异常时，同时关注大额充值/提款用户：
用户统计报表（已导出）
│
▼
按充值金额从大到小排序
│
▼
逐个检查大额用户详情：
│
├─ 充值记录：是否短时间大量充值？
│ 金额是否异常？来源是否集中？
│
├─ 提款记录：是否赢了大额立刻全提？
│ 是否分笔刻意回避自动出款限额？
│
├─ 投注记录：投注模式是否正常？
│ 是否集中在高风险/高返水游戏？
│
└─ 活动奖励：是否大量领取各类奖励？
大额排查和首充套利排查可以同时进行——都是从用户统计报表出发，筛选不同维度的异常。
📝 来源：学习讨论
4.3 游戏回报率异常排查¶
后台路径：后台 → 报表管理 → 实时统计 → 厂商报表
排查内容：检查每个厂商的回报率是否在设置的正常值内。
原理：电子游戏的回报率是按大数据回报的，可能会出现个别客户大输或大赢，单个平台大输大赢——只要 API 商的总控数据整体回报率正常就没有问题。除非 API 商的总控数据异常了，他们就会去重新调整。
查看厂商报表（每个厂商的回报率）
│
▼
是否有 RTP 异常偏高的游戏？
（出现大额爆奖？整体回报率远超正常值？）
│
┌────┴────┐
│ │
正常 异常
│ │
▼ ▼
继续监控 能直接处理？
│
┌────┴────┐
│ │
能 不能
│ │
▼ ▼
及时处理 两个方向：
（如关闭 1. 检查是否有设置错误
问题游戏） 2. 联系 API 商帮我们
查看是否有回报率
异常点
偏差较大时：先看是否有设置错误；如果没有，联系 API 商帮查看是否有回报率异常点——API 商的总控数据能看到整体情况。
📝 来源：学习讨论
4.4 代收代付渠道异常排查¶
沟通渠道：通过 Telegram 与三方商户创建的商务运营对接群沟通——处理临时状况和要求渠道优化。
排查内容：监控三方代收和代付的成功率，及时发现渠道问题。
查看代收/代付渠道成功率
│
▼
成功率是否跟平常平均水平差别太大？
│
┌────┴────┐
│ │
正常 异常
│ │
▼ ▼
继续监控 两个方向同步处理：
│
┌─────────┼─────────┐
│ │
▼ ▼
跟三方渠道沟通 安排渠道配置调整
反馈情况 （切换/调整权重/
要求优化 开关渠道）
│
▼
测试查询自动出款
失败的订单：
· 接口返回的失败原因
和失败代码是否准确？
· 如果返回数据不准确
→ 跟三方反馈要求优化
渠道排查要点：
| 排查项 | 正常 | 异常信号 |
|---|---|---|
| 代收成功率 | 与平常平均水平一致 | 突然下降明显 |
| 代付成功率 | 与平常平均水平一致 | 批量出款失败 |
| 接口返回信息 | 失败原因准确可参考 | 返回原因与实际不符（如账号正常但返回"账号错误"） |
| 失败代码 | 标准错误代码 | 未知代码/文档中没有的代码 |
与三方商户沟通的两个重点：
- 成功率低/经常波动异常——分析原因，推进渠道优化
- 渠道反馈的信息有误、杂乱——要求优化：需要更详细更精准的反馈
主要原理：解决使用三方商户过程中遇到的痛点，让运营人员在渠道使用上更顺滑。
📝 来源：学习讨论
4.5 排查未发现异常时的处理¶
如果存提差比例异常，但排查用户和渠道后都没有发现问题，可能是：
- 平台回报率（RTP）设置问题——某个游戏 RTP 被错误配置
- 某个游戏出了 bug——赔率计算出错导致异常爆奖
- 其他系统性问题
⚠️ 必须及时反馈给经理，由经理继续排查平台和游戏层面的问题。能直接处理的及时处理，不能处理的不要自己改配置。
📝 来源：学习讨论
五、与副组长工作的衔接¶
📝 来源：学习讨论 + 📘 来源：01-副组长-工作指南 · 4.1.5
远程稽核 → 副组长的完整协作链路：
═══════════════════════════════════════════════════
稽核团队 → 副组长 完整协作链路
═══════════════════════════════════════════════════
远程稽核日常审核代理提款订单
（四步法：活动奖励→直属下线→资金账变→投注记录）
│
▼
发现异常 → 执行 P1/P2 处理
│
┌─────┴─────────────────────┐
│ │
P1 警告 P2 处理
（备注+驳回） （关权限+拉层+发群+驳回）
│ │
│ 用户再次提款仍套利 │
│───────────────────────────│
│
▼
┌─────────────────────┐
│ 副组长二重审核 │
│ （第四条标准） │
│ 按第一条~第三条 │
│ 标准再次判断 │
└──────────┬──────────┘
│
┌──────────┴──────────┐
│ │
符合 P2 不符合 P2
│ │
▼ ▼
客服沟通用户 不扣款处理：
→ 用户同意扣款 · 取消 P2 备注
→ 副组长执行扣款 · 拉出套利观察层
→ 恢复投注/提款权限 · 改为 7日/30日留存层级
→ 财务群报备 · 备注"不扣款，日期+经手人"
关键衔接点¶
| 阶段 | 稽核团队职责 | 副组长职责 |
|---|---|---|
| 发现 | 四步法审核 + P1/P2 标记 | — |
| 升级 | P2 后发群通知 | 接收并确认 |
| 二审 | — | 按五条标准重新审核 |
| 执行 | — | 扣款/不扣款 + 备注 + 通知客服 |
| 恢复 | — | 恢复权限 + 财务群报备 |
审核总原则（来自副组长指南）：不是恶意刷宝箱的会员，尽量保留。宁可错放，不要错杀，尽量留住会员。
六、备注格式速查表¶
📘 来源：远程稽核 SOP
邀请奖励（BH BAT）¶
| 场景 | 账号备注 | 驳回备注 | 发群 | 关闭按钮 |
|---|---|---|---|---|
| P1 警告（首次） | BH BAT，Peringatan/P1 {经手人代号}{日期} |
Pelanggaran Terdeteksi! Peringatan ini hanya berlaku sekali. Mohon untuk bermain secara tepat dan benar. |
不发群 | — |
| P2 处理（二次） | BH BAT，P2 tarik Bonus+Kemenangan {经手人代号}{日期} |
Segera hubungi live chat |
后台名称+会员账号+备注内容 | 投注+提款（2个） |
| 未存款封锁 | BH BAT, tanpa deposit Blockir {经手人代号}{日期} |
Segera hubungi live chat |
备注内容 | 投注+充值+提款（3个） |
拼多多奖励（BH RK）¶
| 场景 | 账号备注 | 驳回备注 | 发群 | 关闭按钮 |
|---|---|---|---|---|
| P1 处理（首次） | BH RK，P1 tarik bonus+kemenangan {经手人代号}{日期} |
Segera hubungi live chat |
后台名称+会员账号+备注内容 | 投注+提款（2个） |
| 未存款封锁 | BH RK，tanpa deposit Blockir {经手人代号}{日期} |
Segera hubungi live chat |
备注内容 | 投注+充值+提款（3个） |
邀请 vs 拼多多关键区别： - 邀请奖励：P1 只是警告（不发群、不关按钮）→ 再犯才进 P2（关按钮+扣款） - 拼多多：P1 直接关 2 个按钮 + 发群 → 没有单独的 P2，用户联系客服后由副组长审核，确认套利直接走邀请 P2 扣款流程
七、自动化与工具建议¶
7.1 排班 + 质检绩效系统构想¶
现状：目前稽核组使用 Google Sheet 做分组排班和质检绩效记录。
痛点： - 排班和质检分散在不同的表格，不直观 - 质检加减分的记录和统计靠手动 - 组长查看绩效数据需要翻多个页面
构想：如果做一个统一的排班 + 质检绩效系统，可以包含：
| 模块 | 功能 | 价值 |
|---|---|---|
| 排班日历 | 可视化排班（A/C 组 × 班次），拖拽调班 | 替代 Google Sheet，更直观 |
| 质检记录 | 记录每次质检结果：谁检查、发现谁的错误、错误类型 | 自动统计，不用手动算 |
| 绩效仪表盘 | 自动计算加减分，按人/按月汇总，排行榜 | 组长一眼看到团队状态 |
| 错误分类统计 | 哪类错误最常见、谁的哪类错误最多 | 定向培训的数据支撑 |
扩展可能：如果做成通用系统，可以推广给副组长组等其他组使用（每个组都有排班需求）。
❓ 状态：目前只是构想，不急着开发。如果实际有需求再深入设计。
📝 来源：学习讨论
八、待确认清单 ❓¶
| 编号 | 待确认事项 | 来源 |
|---|---|---|
| ~~1~~ | ~~质检的具体评分标准和质检频率~~ | ✅ 已在 2.3.1~2.3.4 完整补充（扣分细则+绩效权重 60/20/20） |
| ~~2~~ | ~~首充套利排查后的处理~~ | ✅ 已在 4.1.2 + 4.5 覆盖 |
| ~~3~~ | ~~A/B/C 组对应的具体平台列表~~ | ✅ A 组 14 个平台已确认，B 组暂不处理，C 组平台待确认 |
| ~~4~~ | ~~远程稽核绩效考核的具体指标和权重~~ | ✅ 已确认：出款数量 60% + 出勤 20% + 审核正确率 20% |
| ~~5~~ | ~~拼多多 P2 是否与邀请 P2 一致~~ | ✅ 已确认：拼多多没有单独的 P2，P1 关权限后用户联系客服→副组长审核→确认套利直接走邀请 P2 扣款流程 |
| ~~6~~ | ~~还有哪些平台需要做首充套利排查~~ | ✅ 已确认：7777W / RP55 / RP66 / RPRR 四个老站点 |
| ~~7~~ | ~~存提差比例的正常基准值~~ | ✅ 已在 4.1.1 给出阈值估算公式（全天×0.75），建议各平台校准 |
| ~~8~~ | ~~IPv4 判定规则~~ | ✅ 已确认：前三段完全相同=高度可疑；前三段相近（相邻C段）=结合设备等其他信号判断 |
九、互动自测（学完自查）¶
稽核靠判断力吃饭——下面用情景演练模拟真实套利排查，比背规则更能练出手感。答完即时反馈。
判定规则自测¶
:::quiz{id=ipv4}
两个直属下线的 IPv4 是 114.10.77.228 和 114.10.77.135，怎么判？
- [x] 前三段完全相同 → 高度可疑，基本可判定套利
- [ ] 不完全一样，属正常
- [ ] 无法判断，直接放行
解析：IPv4 前三段完全相同（114.10.77.x）= 高度可疑，基本可判定；若只是相邻 C 段（如 .77 vs .78）则需结合设备/注册时间等其他信号。 :::
:::quiz{id=script multi=true} 下列哪些投注行为提示"脚本/机器人"嫌疑？（多选）
- [x] 账号连续游戏数小时甚至全天无停顿
- [x] 每次投注间隔 <3 秒且长期持续
- [ ] 偶尔连输后加大注额
解析：24 小时无间断（正常人要吃饭睡觉）+ 长期秒切 <3 秒（人为需数秒思考）都是自动化脚本典型信号。偶尔加注是正常博弈心理。 :::
情景演练：代理提款审核四步法¶
:::scenario{id=arb-review}
{
"start": "n1",
"nodes": {
"n1": {
"text": "一个代理会员申请提款。四步法第一步先看什么？",
"choices": [
{ "label": "直接看余额够不够出", "next": "bad1", "feedback": "❌ 第一步是查『活动奖励』——套利的源头。", "good": false },
{ "label": "查活动奖励（邀请/拼多多/首存送）", "next": "n2", "feedback": "✅ 步骤1：先看参与了什么活动。", "good": true }
]
},
"bad1": { "text": "跳过源头排查易漏套利。回到步骤1：先查活动奖励。", "terminal": true },
"n2": {
"text": "发现该会员大量参与『邀请奖励』。下一步？",
"choices": [
{ "label": "查直属下线 + 同 IP 检查", "next": "n3", "feedback": "✅ 步骤2：验证是否发展小号/团伙。", "good": true },
{ "label": "邀请奖励是正常活动，直接放行", "next": "bad2", "feedback": "⚠️ 大量邀请奖励要警惕小号刷取，必须查下线。", "good": false }
]
},
"bad2": { "text": "大量邀请奖励是套利高危信号，不能只看活动名。回到步骤2查下线IP。", "terminal": true },
"n3": {
"text": "多个下线 IPv4 前三段完全相同、都只存 10-20 元。判定？",
"choices": [
{ "label": "同 IP + 小额存款 = 套利团伙，走 P1/P2 处理", "next": "good", "feedback": "✅ 同IP小号+小额存款=典型套利，第4步再核投注（有无脚本）后 P1/P2。", "good": true },
{ "label": "证据不足，先放款", "next": "bad3", "feedback": "❌ 同IP前三段全同+集体小额存款已足够可疑，不应放款。", "good": false }
]
},
"good": { "text": "判定正确：四步法逐层坐实（活动源头→下线同IP→资金账变→投注异常）→ P1/P2 处理，上呈副组长二次核验。", "terminal": true },
"bad3": { "text": "放了套利款=资损。应先关权限走 P1/P2 + 二次核验。", "terminal": true }
}
}
记忆卡（判定规则，常翻）¶
:::flashcards{id=audit-rules} - 四步法顺序 :: ①活动奖励 ②直属下线+同IP ③资金账变 ④投注记录 - IPv4 高度可疑 :: 前三段完全相同（如 114.10.77.x） - IPv6 套利 :: 下线 IP 完全一致 - 资金账变异常 :: 下线同IP 或 都存 10/20 元 - 脚本嫌疑 :: 24h 无间断 / 秒切 <3 秒 - 两层防线 :: 稽核 P1/P2（第一层）→ 副组长二次核验（第二层） :::
:::gate{id=audit-done score=0.8 title=稽核判定自查完成} 两道题答对、四步法情景走对、判定规则闪卡过一轮，你就掌握了代理套利排查的核心判断链。点「标记完成」记入学习进度。 :::