风控、审计、GM 与客服

Category

system / 通用服务子树。节点定位：风控、审计、GM、客服四件治理系统——风控不止检测、审计目标是追责、GM 是受控人工干预、客服难在跨系统取证，四者必须协同。

Definition

这几类系统代表的是游戏项目的治理面。玩法系统解决的是“玩家能做什么”，治理系统解决的是“玩家做错了什么、系统做错了什么、团队准备怎么处理”。很多项目直到外挂、诈骗、误封、误发、舆情同时出现时，才意识到治理不是后台补几个按钮，而是一整套证据、处置和协同体系。

Problem

四件都做成了孤立后台就全废：风控只做检测会误伤到封错人，审计只留日志追不了责，GM 没有审批留痕就是内鬼通道，客服跨系统取不了证就只能踢皮球。协同不是锦上添花，是它们各自成立的前提。

风控为什么不能只做检测

风控最容易被理解成“写一些规则抓作弊”，但真正上线后，光有检测远远不够。完整闭环至少包括：

• 识别：日志、行为特征、设备信息、交易路径、社交传播链
• 判定：规则命中、模型评分、人工复核、白名单与误伤控制
• 处置：禁言、封号、回收资产、隔离匹配池、限制交易
• 追踪：处罚是否生效、是否绕过、是否复发
• 申诉：玩家投诉后能否调证据、回放路径、恢复资产

如果系统只会“打一条作弊标记”，但没有后续处置和申诉链路，那它实际上还不算治理能力。

审计的目标不是留日志，而是能追责

很多团队会说“我们有操作日志”，但真正出事时，日志并不回答关键问题。一个合格的审计体系至少要让你知道：

• 谁在什么时间做了什么操作
• 这个操作改了哪些对象、改动前后分别是什么
• 操作依据是什么，例如工单、审批单、活动单、脚本任务
• 操作是否真正执行成功，失败时停在了哪里

审计特别重要的场景包括：

• 客服补发和资产修复
• GM 命令执行
• 运营后台批量发奖
• 封禁与解封
• 配置热修和脚本任务

只记“有人点了按钮”是不够的，最好还能留操作前快照、操作后结果和影响范围。否则事故复盘时只能知道“按钮被点过”，不知道具体损害是什么。

GM 系统的本质是受控人工干预

GM 工具之所以危险，不是因为它功能多，而是因为它天然绕过正常业务流程。它应该被设计成“为了救火和运营必要而存在的受控旁路”，而不是“万能后门”。

成熟 GM 系统通常会把操作分层：

• 查询类：查角色、查订单、查日志、查背包
• 弱写类：改昵称、发邮件、调公告
• 强写类：加减资产、解锁进度、执行封禁、迁移角色

不同层级要配不同权限、审批和审计力度。尤其是强写类操作，最好具备：

• 最小权限原则
• 工单号或原因必填
• 双人复核或高危审批
• 限流和批量保护
• 可撤销或补偿方案

很多经典事故都来自“临时救急先给个超级管理员”，然后这个权限再也没有回收。

客服系统难在跨系统取证

客服表面上是工单系统，实际上是一个聚合查询和有限处置平台。用户来投诉时，客服很少只看一个表就能解决问题，往往需要同时看到：

• 登录和角色信息
• 订单和支付状态
• 资产流水
• 聊天与举报记录
• 处罚历史
• 最近版本更新、活动发奖和异常公告

这意味着客服系统不能只是 UI 壳，它需要可靠的数据聚合接口和权限边界。否则一线客服要么查不到信息，只能把问题升级给研发；要么权限过大，直接对线上数据做危险操作。

风控、客服和审计为什么必须协同

这三者经常被不同团队分别建设，但实际上它们共享同一条问题链：

• 风控负责发现可疑行为
• 审计负责留下可信证据
• 客服负责对外沟通和申诉处理
• GM 或运营后台负责必要的人工处置

如果这些系统彼此割裂，就会出现很糟糕的局面：

• 风控命中了，但客服解释不清楚为什么封禁
• 客服承诺补偿了，但后台找不到精确资产回滚方法
• 运营批量操作失误了，但审计无法确认受影响名单

治理能力真正成熟的标志，不是命中率多高，而是出了争议以后，团队能否在可接受时间内拿出证据、做出处置并恢复秩序。

常见错误

• 把风控当成独立算法项目，不和业务规则、处罚流程、客服申诉联动
• 审计只记文本日志，不记改动对象和前后状态
• GM 权限长期超发，没有审批、没有回收、没有高危保护
• 客服后台直接连生产库查改数据，形成新的风险源

游戏项目越长线、越社交、越商业化，治理系统的重要性就越接近核心玩法。因为真正决定项目下限的，往往不是你能不能做出一个新活动，而是当外挂泛滥、资产出错、用户投诉爆发时，你有没有一套系统把局面稳住。

实战案例：一次「凌晨封了 8000 个号，改判四成」的风控误伤排查

案例为教学示例（非摘自真实项目），数字经过取整简化。它把本页「风控为什么不能只做检测」「审计的目标不是留日志，而是能追责」「GM 系统的本质是受控人工干预」「客服系统难在跨系统取证」「风控、客服和审计为什么必须协同」用到深水区：一次批量封禁把闭环缺环、审批旁路、快照缺失、取证割裂四个缺口同时照了出来。

背景与现象：一款社交型项目上线风控新规则——「同 IP 多账号 + 行为相似」双条件命中即自动封禁。规则凌晨 02:00 生效，首夜命中 8000 个账号，全量自动执行（强写操作直连风控管道，未过 GM 审批，无工单号）。次日 09:00 申诉工单涌到 1200 单，玩家反馈集中在「网吧五连坐」「一家三口三个号」；一线客服只有工单壳，IP 归属、设备指纹、行为记录分散在三个系统里，取证只能升级研发。午间舆情开始发酵。

第一步：现象与口径——先分清「命中多少」和「该封多少」

口径统一：以封禁名单为全集，按「IP 归属库 + 同出口设备数 + 行为相似权重」重判，分「真实工作室 / 误伤」两类。先记两笔：

• 命中：8000 账号，全量自动封禁
• 重判：真实工作室 4600，误伤 3400——误伤率 42.5%

命中不等于该封——先算误伤账，再查规则与链路的账。

第二步：分层归因——从封禁名单到治理链路账本

规则账   凌晨命中 8000：双条件全量自动封禁，共享出口（网吧/校园网/家庭多设备）无一豁免路径
复检账   30 小时联合复检（D1 14:00 → D2 20:00）：4600 + 3400 = 8000，误伤率 42.5%（3400/8000）
申诉账   申诉 1200 单仅为误伤的自发暴露；一线取证需跨三系统，升级研发排单 2 天起
改判账   解封 3400（48 小时分批完成）；误伤中充值用户 900，资产已被批量回收的 210 人逐个补偿

账本收束：42.5% 的误伤率不是规则精度问题，是链路问题——判定环没有本页说的「白名单与误伤控制」；申诉环根本不存在，1200 单申诉只是 3400 个误伤里自发冒头的那部分；能完成重判，靠的是三系统数据手工拼接的 30 小时，而不是任何现成取证链路。

第三步：根因——闭环只建了三环，强写走了旁路

对照本页「风控为什么不能只做检测」的闭环五环：识别、判定、处置连夜跑通，追踪和申诉两环缺位——「玩家投诉后能否调证据、回放路径、恢复资产」整条没有答案。对照「GM 系统的本质是受控人工干预」：批量封禁属于页内分层里的强写类，本该配「双人复核或高危审批」与「限流和批量保护」，风控直连管道把它整个绕开——本页「很多经典事故都来自“临时救急先给个超级管理员”」的变体：不是权限超发，是强写能力根本没进 GM 分层。对照「审计的目标不是留日志，而是能追责」：日志只有「封禁动作」四个字，判定依据快照、影响名单、改动前后状态一概没有——「只记“有人点了按钮”是不够的」逐字应验。协同节的割裂局面命中两条：「风控命中了，但客服解释不清楚为什么封禁」；「客服承诺补偿了，但后台找不到精确资产回滚方法」——210 人的补偿名单是审计从封禁管道里反向挖出来的。

第四步：处置与回填——先改判，再把闭环补成环

修法分两段。应急：D1 14:00 三方联合复检启动，D2 20:00 全量改判完成（30 小时），误伤 3400 在 48 小时内分批解封；210 名资产被回收者按审计流水逐个补偿，900 名充值用户收到致歉与补偿邮件；舆情公告同步改判口径。制度四步：强写类批量封禁收进 GM 分层——双人复核，单批超 500 强制高危审批；处置动作留判定依据与影响名单快照，审计可追责到「为什么封、封了谁、依据什么」；申诉证据包自动生成（判定依据 + 行为回放 + 恢复路径），申诉不再升级研发；客服聚合查询接口把六类数据一次取齐，一线不连生产库。复核：次月规则重上线，命中 5200、误伤 250（4.8%），申诉单均处理 8 分钟，单批超 500 的审批拦截当月触发 2 次。

回填清单：

落点	动作	回填处
审批旁路	强写类批量封禁收进 GM 分层，双人复核 + 单批超 500 高危审批	GM 系统的本质是受控人工干预
快照审计	处置留判定依据与影响名单快照，追责到为什么封、封了谁	审计的目标不是留日志，而是能追责
申诉闭环	申诉证据包自动生成：判定依据 + 行为回放 + 恢复路径	风控为什么不能只做检测
取证聚合	客服聚合查询接口六类数据一次取齐，一线不连生产库	客服系统难在跨系统取证

案例的三个教训

1. 命中不是治理终点——闭环五环缺了申诉环，42.5% 的误伤率只能靠舆情而不是靠系统自己发现。
2. 强写必须走受控旁路——绕过 GM 分层的自动封禁，把「受控人工干预」变成了「无人复核的自动强写」。
3. 争议的解药是证据包——能否在可接受时间内拿出证据、做出处置并恢复秩序，才是治理成熟度的真正标志。

Used By

治理四件套设计评审；误伤申诉流程；协同取证机制。

Related

关系链：风控 → 审计 → GM → 客服 → 协同 → 常见错误 → 实战案例。上游：services/01（账号对象）、security 树（风控面展开）。下游：security/03（行为风控治理）、operation/bi/03（风控分析）。

Reference

本页为工程经验归纳；页内实战案例为教学示例（数字取整简化）。