{ "ok": true, "identity": "user", "data": { "document": { "content": "2026.06.17-日报-莫润麟

今日内容

① 文献学习:XGBoost + SHAP 方法参考

②《实证操作手册》整理

③ Codex 业务skill制作

重点学习了一篇使用 XGBoost 与 SHAP 的足球比赛分析论文:

《足球比赛中防守突破检测的断点预测模型分析》 2025

该论文研究的是足球比赛中的突破防线分析:

什么样的空间结构、球员位置、速度和传球方式,会导致进攻方突破防线?

而我们的研究是希望进一步识别:

什么样的游戏机制变量,会影响玩家综合投入?

因此,这篇论文虽然不是游戏领域研究,但可以作为“复杂多人竞争场景 + 高维行为数据 + XGBoost + SHAP 解释”的方法参考支撑。

(一)论文的方法路径

该论文的整体方法路径可以概括为:

业务问题定义 → 构造可计算标签 → 构建结构化特征 → XGBoost 预测 → SHAP 解释 → 回到战术含义。

具体来看:

  1. 先定义因变量
  2. 再构造特征变量
  3. 使用 XGBoost 建模
  4. 使用 SHAP 解释模型
  5. 回到业务解释

他们研究的是体育竞赛中的战术突破,我们研究的是游戏竞赛中的综合投入,

场景不同,但“竞赛结构变量 → 机器学习识别 → SHAP解释机制”的方法逻辑是相通的。

(二)整理《XGBoost_SHAP实证操作手册》

围绕后续 XGBoost / SHAP 实证分析,整理形成了一版可直接执行的操作手册

明天拿到正式数据后用于跑数的实证流程说明

核心思路是:

\"图片为qa:image11<qa:image></qa>为《XGBoost_SHAP实证操作手册》主流程图,数据到位后直接按流程执行。流程包含11个步骤,从输入数据准备>\"

手册源文件👇

二、Codex 业务skill制作

发现 Codex 在多轮对话中容易混淆业务文件角色,核心原因不是模型能力问题,而是业务上下文复杂、文件角色多、流程规则没有被显式固定。

具体表现:

  1. Agent 聊着聊着开始把埋点表当实际数据用,把3月有的字段默认5月也有
  2. 策划案里的规则和后来修正过的变量口径混在一起说
  3. 文件越多、对话越长,串台越严重

根本原因:没有固定流程时,AI 靠\"最近说了什么、文件叫什么名字、上下文联想\"来判断该用哪个文件——业务文件一复杂,上下文一朵就开始出错。

解决方向:

不是多聊,而是把固定任务封装成 Skill / 工作流规则,让 Agent 接到某类任务时先按固定规则读取对应文件、理解文件角色、执行固定步骤。

Skill 一:埋点相关任务

固定执行顺序:

  1. 先看埋点表 — 埋点表是字段字典/指标口径,代表活动已有的全部埋点定义,不是实际数据
  2. 再看3月/5月数据 — 判断哪些字段实际有数据、哪些缺失、字段是否可用
  3. 区分有无数据 — 埋点表有定义 ≠ 数据里实际有;5月有还需判断样本是否稳定
  4. 变量构建时同时核查六项:理论机制是否匹配 / 字段是否真实存在 / 3月5月是否都有数据 / 是否与因变量重叠 / 是否有足够样本变化 / 是否能用于 XGBoost/SHAP

Skill 二:策划案相关任务

固定读取逻辑:

  1. 识别活动规则结构 — 报名、匹配、赛季、联盟、阵营、积分、奖励、排行、限制条件
  2. 抽象机制 — 对应七机制(补偿性、公平性、激励性、互补性、私有性、互动性、流动性)
  3. 判断可观测行为 — 规则里哪些行为可被数据捕捉,如参战、派遣、捐献、鼓舞、竞猜、领奖、兑换、协作
  4. 最后才映射埋点字段 — 不能从策划案直接跳到变量,必须经过完整链路:规则 → 机制 → 行为 → 埋点字段 → 数据可用性

", "document_id": "PHwIdFwThoiT70xFGvKcx7SWnpe", "revision_id": 255 }, "log_id": "20260618095354E396C4BB38E63BA9C443" }, "_notice": { "update": { "command": "lark-cli update", "current": "1.0.32", "latest": "1.0.54", "message": "lark-cli 1.0.54 available, current 1.0.32, run: lark-cli update" } } }