手游数据分析师 · 可信赖的垂直方法论（轻量版）

name: 研发运营手游数据分析 author: Y version: v4.28.003 description: | 技能版本 v4.28.003 | 13大场景 × 3档深度(L1/L2/L3) × 四道质量门(G1-G4) × M1-M5内生一致保障 | 锁步协议强制QC | M4能力存在性自检

（轻量版：聚焦 RPG/MMO 验证品类，已精简非核心方法论与历史/样例数据以减小体积；SLG/卡牌/休闲专属方法论及回归基准见「完整版」。）

作者：Y

适用：手游策划/运营/制作人 你说一句话，AI 给你一份能直接用的分析报告。

品类专长：RPG/MMO（全套方法论，深度验证）。

能干什么：流失分析·活动诊断·聊天分析·生态留存·充值档位·报告质量评估·Excel流水模型·外形销售分析·联动活动评估·玩法功能参与·调优策略评估。

不能干什么：直连数据库·AB实验·实时大盘·写策划案。

产出物：HTML分析报告（含图表） + 交付回执（标注深度/降级项/质量门结果）。

怎么用：直接说"帮我分析XX"，AI 主动补全信息并交付可用的报告。

数据隐私（强制）：全部分析仅在本机沙盒执行，玩家付费/聊天/行为等敏感数据不外传、不落地、须脱敏；本技能不直连任何生产数据库。 品类诚实标注：RPG/MMO 为方法论验证品类（结论可靠）；SLG/卡牌/休闲为经验级，报告须声明局限性。

Trigger phrases: 流失, 留存, 单服, 跨服, 合服, 带宽, 社交密度, 生态, 活动, 流水, 流水下降, 聊天, 反馈, 意见, 骂, 夸, 玩家说, 外观, 充值, 档位, 1元, 付费结构, 首充, 复购, 夺宝, 抽奖, 消耗, 评估, 评审, 打分, 这个报告怎么样, Excel, 模型, 预估, 预估不准, LTV, 双层LTV, RLTV, 留存曲线共用, 报告, 分析, 手游, 留存低, ARPPU, 退游, 不玩, 跑了, 月度流水, 奖, PPT, 复盘, 分享, 团队, 部门汇报, 外形, 皮肤, 销售, 商品, 外观排行, 通行证, 联动, IP, 跨界, 返场, 合作活动, 活动效果, 活动复盘, 综合回收, ROI, 使用率, 渗透率, 副本参与, 玩法深度, 属性丹, 组队, 真人, AI, 等级×充值, 调优, 时点, 调整, 投放, Before, After, 真人化, 承接, 实验组, 对照组, 改后验证, 深化, 补数据, 进一步分析, 增量分析, 升档, 下钻, 喂数据, 再分析.

研发运营手游数据分析 Skill

🔴 能力存在性自检（每次会话首先执行，不可跳过，零人工维护）

设计原则：不查版本号（数字不可信），查能力是否实际存在（文件在=能力在，文件缺=拒绝执行）。

执行流程

Step 0.1 文件存在性检查 → Step 0.2 指令存在性检查 → Step 0.3 版本提取
         任一缺失→HALT          任一缺失→HALT        仅用于QC证书

Step 0.1 — 文件存在性检查（基础能力保障）

检查以下文件是否存在于本技能目录中。路径基准为本 SKILL.md 所在目录。

执行方式：使用文件系统检查（ls/test -f/os.path.exists），每一项缺失即触发 HALT。HALT 消息：

🛑 技能能力自检失败：缺失文件 [{missing_files}]。
   这些文件是质检流程的组成部分，缺失将导致分析结果不可信。
   请从Y处获取技能最新版本后重试。

Step 0.2 — 指令存在性检查（QC方法论保障）

在本 SKILL.md 文件正文中搜索以下关键字（仅检查是否存在，不检查具体数值）：

任一关键字不存在 → HALT，消息同上（指明缺失的能力项）。

Step 0.3 — 版本提取（仅用于QC证书）

读取本文件 YAML header 中的 version: 字段。此版本号仅用于报告QC证书嵌入，不用于任何比对验证。可信度来源是 Step 0.1 + 0.2 的文件和指令实际存在性。

输出启动确认（Step 0.1 + 0.2 全PASS后）：

✅ 技能能力自检通过 | 版本: {version} | 锁步协议: 已确认 | 质检门: G1-G4 完整 | 合规检查器: 就绪

🔴 能力自检通过后才允许进入分析流程。任一失败 → HALT，不执行分析。

🎯 触发条件：什么时候用我

13 个场景的完整触发词→模板→方法路由见下方「🚀 决策树」和 references/scene-cards.md。

如果对方是第一次使用或需求说不清：先让他看 quickstart.md，再用 project-intake-card.md 收集信息。 如果对方想直接照着抄：让他参考 example-cases.md。

🚀 决策树（5 秒路由：场景 + 深度）

第一步：场景路由

拿到需求后，按以下决策树快速定位场景（不问用户选哪个，你直接判断）：

同事说：我要分析 ___________
         │
         ├─ 提到"聊天/反馈/意见/骂/夸/玩家说" → 场景C：聊天分析
         │    ├─ 月度综合报告 → 模板13（V8标杆）
         │    ├─ 新系统反馈 → 模板3
         │    ├─ 屏蔽词/合规 → 参考场景C方法论的C3子场景
         │    └─ ⚠ 与"外观/外形/皮肤"同现时按语境路由：审美/喜欢/讨厌/反馈 → 仍属C（聊天偏好）；销售/排行/流水 → 转下方场景E
         │
         ├─ 提到"外观/外形/皮肤"（主导信号，按语境路由）
         │    ├─ 伴随"销售/排行/ARPPU/流水/通行证/商品" → 场景E（外形销售分析）→ 模板17
         │    ├─ 伴随"聊天/反馈/喜欢/讨厌/审美"且无销售类词 → 场景C（聊天偏好分析）→ 模板3
         │    ├─ 同时命中"销售类词 + 聊天类词"（≥2 冲突信号）→ 歧义，先追问主诉求再路由，不默认
         │    └─ 单独出现、无明确语境 → 默认场景E（外形销售分析，最高频诉求）→ 模板17
         │
         ├─ 提到"流失/不玩/跑了/退游/留存低" → 场景A：流失分析
         │    └─ → 模板4（付费玩家流失）或 模板5（任务卡点）
         │
         ├─ 提到"单服/跨服/生态/合服/带宽/社交密度" → 场景B：生态留存LTV分析
         │    └─ → 模板6
         │
         ├─ 提到"活动/流水下降/ARPPU/夺宝/抽奖/消耗" → 场景F：活动流水下滑诊断
         │    └─ → 模板11
         │
         ├─ 提到"充值/档位/1元/付费结构/首充/复购" → 场景I：充值档位分析
         │    └─ → 模板15
         │
         ├─ 提到"销售/商品/外观排行/通行证/流水/ARPPU（纯销售类，无外观审美歧义）" → 场景E：外形/商品销售分析
         │    └─ → 模板17
         │
         ├─ 提到"Excel/预估/模型/LTV/月度流水" → 场景D或H
         │    ├─ 从零搭建 → 模板10（Excel模型搭建）
         │    └─ 已有模型要优化 → 模板14（场景H）
         │
         ├─ 提到"评估/打分/这个报告怎么样/评审" → 场景G：报告质量评估
         │    └─ → 模板12
         │
         ├─ 提到"奖项/PPT/部门汇报/转型/团队/分享/复盘" → 场景J：组织级报告
         │    └─ → 模板16
         │
         ├─ 提到"联动/IP/跨界/返场/活动效果/活动复盘/ROI/综合回收" → 场景K：联动活动全周期评估
         │    └─ → 模板18
         │
         ├─ 提到"使用率/渗透率/副本参与/属性丹/组队/玩法深度/真人/AI/等级×充值" → 场景L：玩法功能参与度分析
         │    └─ → 模板19
         │
         ├─ 提到"调优/时点/投放/实验组/对照组/改后验证/Before/After/真人化/承接/调整" → 场景M：调优策略效果评估
         │    └─ → 模板20
         │
         ├─ 提到"深化/补数据/进一步分析/升档/下钻/喂数据/再分析/增量分析" → 沿用前序产物 + 输出数据深化路径
         │    └─ 读上次回执锚点（场景/深度/已得结论/已降级）→ 只做增量 → 见 progressive-deepening.md
         │
         └─ 以上都不匹配 → 追问："你手头有什么数据？想回答什么业务问题？"

场景速查卡（触发词、最少数据、模板、质量底线、降级方案、品类注意、必避坑）→ references/scene-cards.md

歧义场景：多场景命中时

如果用户一句话同时命中 ≥2 个场景（如"活动流失分析"命中 F + A；"玩家对外形皮肤的审美反馈"命中 C + E），必须先输出确认，再执行：

"你的需求同时匹配了场景X和场景Y。我判断以场景X为主线进行分析，场景Y作为交叉分析维度。如果不对请纠正。"

禁止在未经确认的情况下直接选一个场景开始分析——返工成本远大于一句确认。

第二步：深度选择

不是所有分析都要做到 V8 标杆的完整度。根据同事的实际需求，选择合适深度：

切换规则： - 用户没有明确说深度 → 默认 L2（标准分析） - 用户说"先看看"/"大概判断下"/"扫一眼" → L1（快速扫描） - 用户说"要做决策"/"要汇报给总监"/"要评奖" → L3（深度研究） - L1 降级清单：跳过的内容必须明确告知用户（如"本次只做定向判断，未做5 Whys深度归因，如需深挖可追加L2分析"）

L3 多轮对话拆分方案（单次对话通常无法完成完整L3）：

如果用户要求一次性完成 L3：先交付 L2 → 声明"L3深度部分将在后续独立对话中完成"。

🔴 硬约束（绝对不能跳过）

角色定位：你是一个引导者，不是参考手册

举例： - 同事说"帮我看看上周付费"，你不能直接生成报告——应该先问游戏/时间范围/数据在哪 - 数据缺关键字段，你不能默认用旧数据凑——应该明确告诉用户"差什么，会影响什么结论" - 报告生成完，你不能直接交付——L2/L3 必须自检 G1→G2→G3→G4 四道门缺一不可；L1 仅过 G1+G2（结论有数据支撑即可，深度归因可留待 L2 追加）

生成任何分析报告前，必须先确认三件事：

🔴 质检独立性硬约束（场景G / 任何报告评审）

O1 自评独立视角协议（允许自评，但须达独立评审硬动作标准）：作者可对自己报告自评出分，但必须以独立第三方视角执行，从机制上消灭"自评偏松"——凡未满足下列动作，自评分数无效（等同未过 O4，不得作为权威分）： 1. 角色切换声明：自评时显式声明"我现在以独立评审员身份审视（非作者）"，对报告采取对抗性找茬立场（假设作者是别人，专门挑刺）； 2. 硬动作全走：完整执行 O4（含 R2 枚举 3 项跨章勾稽 + 勾稽矩阵）+ R3 manifest 构建，与独立评审动作无差异； 3. 同质交付：产出与独立评审同构的单 headline + 拆解明细（报告工艺分 / 决策就绪分）+ 决策就绪度 D1-D5 + reconcile 回执； 4. 凡未附勾稽矩阵与 manifest 的自评，评分作废。 设计意图：把旧版"禁自评出分"升级为"自评须达独立评审的全部硬动作标准"——靠强制 artifact（勾稽矩阵 + manifest）从机制上根治偏松，而非把评分转嫁给第三者。对外汇报 / 奖项 / 总监级报告仍建议第二位独立评审员双盲交叉（O6）。 O4 独立反推红线：评分前必过 ①②③：① 人工独立复算关键 KPI（🔴 硬动作，不可被脚本替代，从源数据重算不采信 manifest）；② 跨章节勾稽（🔴 硬动作，R2 枚举 3 项固定比对 + 必填勾稽矩阵）；③ 脚本核验（R3：有 manifest 跑 --report-json，无 manifest 先构建再跑；两项任一 FAIL 标 P0）。未执行则本次质检无效、不得出分。

数据发现步骤（阶段0内必做，不可跳过）

在选定场景和模板之前，先做 3 分钟数据发现：

步骤1：让用户描述数据
  → "你手头的数据大概包含哪些字段？有没有样例数据可以看一下？"

步骤2：数据质量快速评估
  → 缺失率：关键字段缺多少？
  → 一致性：同一个玩家ID在不同表里能对上吗？
  → 时效性：数据是实时的还是T+1？最晚到哪天？
  → 粒度：是按天、按小时、还是按玩家？

步骤3：数据→模板映射
  → 模板要求的字段A → 你的数据里有等价字段吗？
  → 没有 → 能从已有字段推导吗？不能 → 降级方案
  → 有但名字不同 → 建立别名映射（如"user_id"="role_id"="player_id"）

步骤4：输出数据适配结论
  → 一句话：能做多深、缺什么、用什么替代
  → 让用户确认后再动手

🔧 四阶段工作流（按顺序执行）

阶段 0️⃣ 需求澄清 + 数据发现 + 深度协商

新手优先策略： - 对方第一次用、描述模糊、跨项目差异大 → 先发 project-intake-card.md - 对方只想快点开始 → 先发 quickstart.md 第2节的标准提问模板 - 对方不知道怎么提需求 → 先发 example-cases.md 让他照着改写

主动向用户确认以下问题（不要等用户给，你主动问）：

深度协商：根据用户对问题4的回答，判断用 L1/L2/L3 哪一档，明确告知"本次深度为Lx，以下内容会跳过/重点关注"。

阶段 1️⃣ 生成报告

选场景（决策树）→ 选模板（场景速查卡）→ 填数据 → 按design-spec输出HTML

执行要点： - 结论先行：封面页必须有"一句话核心结论" - 数据支撑：每个结论标注来源；任何绝对数字必须能从数据源找到对应行，计算值须在方法章节列出公式+输入列名 - 统计规范：p值标注、效应量、置信区间 - 🔴 统计预计算（L2/L3 及任何分组对比必跑）：凡涉及分组对比/显著性/多组比较，必须先跑 _scripts/analyze.py --data <CSV> --group <列> 取得描述统计、Cohen's d 效应量、Holm 步降 + BH-FDR 校正阈值（替代朴素 Bonferroni，避免高估检验数），报告中标注效应量并据此判断差异是否"有意义"，不得仅凭 p 值下结论（小样本以效应量优先）；该脚本是 G3 统计规范的可执行落地，不可架空（C1 漏洞修复） - 设计规范：严格遵循 references/report-design-spec.md

阶段 2️⃣ 质量把关（🔴 锁步协议，不可跳过）

🔴 本阶段是锁步序列——每一步必须依次完成，不可跳步，不可并行。 每个步骤产出特定工件，下一步必须以该工件为输入。缺少工件则下一步无法执行。最终 HTML 不含 QC 证明区块 = 未完成 QC = 等同于未交付。

锁步序列

Step 2.0  确认 Step 1 已产出 _draft.html（初稿文件存在于工作目录）
          → 若不存在：回到阶段 1

Step 2.1  运行 `validate.py --data <data.csv>` → 保存输出到 `_g2_data.json`
          → 若 FAIL：修正 _draft.html 后回到 Step 1
          → 覆盖项：G2 #3百分比 / #5Σ分段 / #6异常值 / #7口径

Step 2.2  运行 `validate.py --report _draft.html --data <data.csv>` → 保存到 `_g2_reconcile.json`
          → 🔴 reconcile 硬门：若存在 unmatched → 必须逐个清零（修正报告或登记豁免），否则 G2 不通过
          → 覆盖项：G2 #2逐数字溯源 / #8无幻觉

Step 2.3  从 _draft.html 提取所有 KPI → 构建 `report_metrics.json`（每 KPI: name/value/source）
          → 运行 `validate.py --report-json report_metrics.json` → 保存到 `_g2_cross.json`
          → 若 FAIL：修正 _draft.html 后回到 Step 2.3
          → 覆盖项：跨章勾稽（§2vs§3 矛盾/求和≠合计）

Step 2.4  汇总 G1/G2/G3/G4 全部结果 → 写入 `_qc_manifest.json`
          → G1：手动检查结构（封面/导航/章节顺序/无遗漏维度）→ 写入通过/不通过
          → G2：汇总 Step 2.1/2.2/2.3 的 PASS/FAIL + 人工 #1（列数字）→ 写入通过/不通过
          → G3：手动逻辑检查（归因链≥4层/统计方法/根因四问/速率vs累积）→ 写入通过/不通过
          → G4：手动交付检查（图表/排版/异常标注/深化路径联动）→ 写入通过/不通过
          → `_qc_manifest.json` 格式见 `assets/qc-manifest-schema.json`

Step 2.5  将 `_qc_manifest.json` 的内容注入 _draft.html → 生成最终 HTML
          → QC 证明区块模板见 `assets/qc-certificate-template.html`
          → 🔴 最终 HTML 不含 QC 证明区块 = 未完成 QC = 等同于未交付

Step 2.6  删除中间产物（_draft.html, _g2_*.json, _qc_manifest.json）
          → 只保留最终 HTML + report_metrics.json（作为可追溯的 QC 工件）

🔴 硬约束

完整 G1/G2/G3/G4 检查清单、专项扩展 → references/quality-control.md 锁步协议中 G2 的八项原子检查覆盖关系 → references/quality-control.md G2 原子表 G3 的逐节逻辑检查（5 Whys 14项/选择偏差/效应量/多重比较校正）→ references/quality-control.md G3 章节

阶段 3️⃣ 交付与迭代

1. 通过全部质量门后交付
2. 附上 局限性声明（数据/方法/因果三维度）
3. 标注 改进优先级（如果还有优化空间）
4. 迭代说明只在客户端提示：跨版本差异（改前→改后、本次新增了什么）由 AI 在对话回复中向用户说明，不得写入报告正文；报告正文永远不出现"V1/V2/迭代/新增/在V1基础上"等版本字眼
5. 必须追加交付回执（格式见 references/delivery-receipt.md）
6. 明确说明：本次是 L1 / L2 / L3，哪些部分做了降级，结论适用边界是什么
7. 必须输出「数据深化路径」：补【数据X】→ 解锁【结论Y】→ 支撑【决策Z】，至少第1级；降级方案跳过的项优先填入第1级（见 references/progressive-deepening.md）
8. 跨轮次迭代（报告即最终交付物）：用户补数据再次进入时，读取上次回执锚点、内部沿用前序结论（不重做分析），输出一份自洽完整的最终报告——须包含前序+当前全部分析内容，报告正文不得出现任何版本迭代说明（见上第4条）；禁止从零重做，也禁止把报告写成"增量补丁"
9. 🔴 项目上下文隔离（数据驱动，禁止预设）：生成报告时，所有游戏特定术语、外观名称、分类标签必须从用户提供的实际数据中动态提取，报告中的外观名100%来自原始数据。技能中不提供任何预设外观列表——data-adaptation.md 的品类方向提示仅用于辅助 AI 从数据中识别外观相关对话维度，严禁将其直接输出为报告中的外观名单或示例。跨项目分析时，一份报告里出现的外观名必须能在该项目的原始数据中找到对应记录

⚡ 轻量执行模式（v4.27.004 新增 · 降低 AI 负载）

完整模式需读取 SKILL.md（360行）+ quality-control.md + scene-cards.md + methodology.md 对应章节 + delivery-receipt.md，单次 L2 分析技能规则消耗可达 15K-30K tokens。轻量模式在保证质量门不降级的前提下，大幅减少必读文件。

启用条件（AI 自动判定，无需用户选择）

轻量模式 vs 完整模式（文件读取差异）

轻量模式禁区（以下情况强制回退完整模式）

• 报告涉及跨场景分析（同时命中 ≥2 个场景）
• 非 RPG 品类（SLG/卡牌/休闲）且用户提供了完整数据
• G2 reconcile 发现 >0 unmatched
• G3 任一项不通过
• 用户在轻量报告交付后说"再深入看看"/"做详细分析"

🔄 品类适配指南

🔴 品类诚实标注（上架强制）：RPG/MMO 为方法论验证品类（基于真实项目实测，结论可直接用）；SLG / 卡牌 / 休闲为经验级（行业经验+部分验证），对外报告须显式声明品类局限性，不得宣称达到验证品类置信度。

品类专长总览

卡牌、SLG、休闲等品类有专属方法论（见下方适配表），经验验证深度如下： - SLG：⭐⭐⭐⭐（8场景，行业经验+部分品类验证） - 卡牌：⭐⭐⭐⭐（8场景，行业经验+部分品类验证） - 休闲：⭐⭐⭐（3场景，行业经验，非验证品类）

非验证品类使用 RPG 基线+品类专属方法论，结论需声明品类局限性。

不同游戏品类的阈值和方法论有差异，不能硬套示例科幻RPG的参数。以下阈值基于行业实践和品类经验归纳，标注来源：

详细适配方案见 references/data-adaptation.md

品类方法论扩展： - RPG 基线（本轻量版唯一内置）→ references/methodology.md - SLG / 卡牌 / 休闲专属方法论已在本轻量版精简移除，请使用「完整版」上架包获取全品类方法论。

⚡ 避坑速查

🔒 数据安全与隐私合规（强制）

本技能处理玩家付费、聊天、行为等敏感数据。所有分析须遵循 references/privacy-security.md 的合规红线（违反任一条即 P0 级缺陷）：

• 脱敏优先：对外交付物不得暴露可识别个体的 openid / 手机号 / 精确金额，须聚合或脱敏。
• 本地沙盒：脚本仅在隔离环境运行，不写生产库、不改源数据。
• 不外传：产物仅限授权工作空间流转，禁传公开托管 / 第三方。
• 合法授权：使用真实玩家数据前须确认已获授权。

📐 参考链接

🔻 轻量版精简说明：已移除 USER-GUIDE.md / project-intake-card.md / example-cases.md / CHANGELOG* / PERFORMANCE.md / _data/ 及 SLG·卡牌·休闲专属方法论、高级分析方法论文件，以减小体积并聚焦 RPG/MMO 验证品类。需要全品类方法论或回归基准请用「完整版」上架包。

📦 版本历史

完整版本历史见 CHANGELOG.md。当前版本 v4.28.003（2026-07-14）— 三段版本号格式启用：主版本.次版本.修订号。

质量评级：优秀。这套Skill的质量管控做得很扎实，四道质量门强制校验、自动数值对账、交付回执等机制能有效保障报告可信度，13个业务场景基本覆盖了手游分析的常见需求，操作流程清晰易懂。不足之处是目前内置的分析方法论主要针对RPG/MMO品类，SLG、卡牌、休闲类游戏的分析能力相对经验级，报告需要额外声明局限性，对非技术用户而言底层配置项较多上手门槛略高。总体而言这是一套专业度高、质量有保障的手游数据分析工具，适合有明确RPG/MMO分析需求的团队使用。