复盘 AG 与 KSG 的第七局巅峰对决时很多讨论会很快滑向两个结论BP 被对手压制或者某几位选手状态低迷。这里的问题不是结论是否成立而是结论颗粒度太粗。教练组拿到“被完爆”这个判断后至少还要知道对手是在哪个 Ban/Pick 节点建立了优先级Carry 位是在前十分钟参团率上落后还是在中后期的关键资源决策里连续失误。不同原因对应的训练方案完全不同。这篇文章会从一场巅峰对决的复盘需求出发搭建一条可复用的数据处理链路。数据源不需要很复杂先把每一局的 BP 顺序、局内事件、选手经济、击杀助攻信息落成结构化数据再用 SQL 和 Python 计算 BP 优先级、选手状态变化和对局关键差异。文章中的代码示例会把队伍脱敏为 TeamA 和 TeamB所有演示数据都只用于说明方法不代表任何真实选手表现也不是正式赛果判断。1. 复盘巅峰对决前先建一条数据处理主链路1.1 结论型复盘为什么不能直接指导训练以“第七局 BP 被对手完爆”为例这句话读起来很直观但它把多个不同层面的问题混在了一起。BP 阶段被压制可能是第一轮 Ban 位浪费了可能是红色方第二轮被迫连续牺牲版本强势英雄也可能是先手拿到的核心英雄被对手最后两手有效克制。这些问题的对象、责任人和修正方式完全不同。选手状态同样不能只用一个“低迷”概括。状态差可以被拆成“对线期没有被抓但补刀落后”“前十分钟参团率明显低于该选手历史基线”“中后期关键技能释放与队友脱节”“经济转化率连续三局下降”等不同表现。如果没有指标定义赛后复盘很容易变成情绪判断而不是训练依据。数据复盘要解决的核心问题是把“谁的锅”转化成“哪个环节、哪个时间窗口、哪项指标出现问题”。这一点对于学习环境尤其重要。没有足够职业数据时可以先从录像回放加手动标记开始积累几场后自然能看到关系不要等到数据完整才动手。1.2 从原始事件到复盘报告的数据链路完整复盘数据链路可以分成四层。第一层是采集层。来源包括官方数据接口、手工录入的 BP 记录、自己打开录屏后在表格里标注的事件时间点。很多业余项目没有自动采集能力手动录入也能用只要确保字段统一。第二层是存储层。文章演示选用 SQLite因为单文件、零部署适合把一批比赛数据快速导入并做查询验证。正式赛训环境可以换 MySQL数据量大以后也可以换 ClickHouse但核心表结构可以先保持一致。第三层是计算层。主要工作是清洗英雄别名、剔除补丁版本不同的对局、统一 BP 阶段和选手编号然后计算禁用率、选用率、优先级得分、前十分钟经济差、参团率、伤害转化率等派生指标。第四层是应用层。输出不是一张堆满数字的表而是两张汇报型表格一张是 BP 过程对照表一张是选手状态时间线。四层链路的价值在于同样一批赛事素材结论可以反复被校验而不是每次复盘都重新翻录像凭印象说话。1.3 最小数据模型能回答哪三个问题第一个问题是英雄选择优先级是否在关键局丢失。通过“哪个英雄在哪个阶段被 Ban/Pick队友是否拿到版本强势组合”可以判断 BP 是被系统限制还是决策本身偏保守。第二个问题是选手状态差出现在哪个时间段。通过选手每分钟击杀、死亡、助攻、经济、团队击杀数可以计算前 5 分钟、前 10 分钟、中后期三个窗口的参与度变化。第三个问题是阵容选择与执行状态到底哪个对结果影响更大。把阵容特征和选手状态特征放进同一份数据表后可以让数据库筛选“选出来的阵容相仿但输赢相反”的对局再回看录像找执行差异。最小模型不必追求完整复刻官方数据。后续你会看到先有一张match_bp、一张match_state、一张hero_dict已经足够完成一次有意义的探索。2. 准备环境把 BP 与状态数据落进 SQLite2.1 项目目录和依赖建议按下面的目录组织项目这样后续不用在临时文件里反复找表结构。review_project/ ├── data/ │ ├── bp_sample.csv │ ├── state_sample.csv │ └── review.db ├── scripts/ │ ├── import_data.py │ ├── features.py │ └── report.py ├── requirements.txt └── README.md本机只需要 Python 3.9 以上加上 Pandas 和 SQLite 内置模块。pandas2.0.0 numpy1.24.0 matplotlib3.7.0如果只是跑数据导入和统计不画图时甚至只需要 Pandas。安装依赖后先确认 Python 能正常打开 SQLite 数据库文件。python -c import sqlite3; import pandas; print(pandas.__version__)这条命令的作用是同时验证 Python、pandas 和 sqlite3 三个模块是否可用。若报ModuleNotFoundError: No module named pandas需要先执行pip install pandas。2.2match_bp表设计BP 表记录每一次 Ban/Pick 动作。设计时要保留两个关键字段event_seq表示全局事件顺序round_code表示发生在第几轮。只看英雄和结果会失去 BP 博弈过程比如同一个英雄在第一轮拿和第五轮拿含义完全不同。CREATE TABLE IF NOT EXISTS match_bp ( id INTEGER PRIMARY KEY AUTOINCREMENT, match_id TEXT NOT NULL, game_no INTEGER NOT NULL, team TEXT NOT NULL, side TEXT NOT NULL CHECK (side IN (BLUE, RED)), event_seq INTEGER NOT NULL, event_type TEXT NOT NULL CHECK (event_type IN (BAN, PICK)), round_code TEXT NOT NULL, hero_name TEXT NOT NULL, result INTEGER NOT NULL, patch_version TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP, UNIQUE (match_id, game_no, team, event_seq) );字段含义可以参考下表。字段名含义示例注意事项match_id一场比赛唯一编号BO7_FINAL_001同一场有多个队伍game_no第几小局7表示巅峰对决所在局team队伍标识TeamA / TeamB正式环境存联盟代码side红蓝方BLUE / RED选边影响英雄优先级event_seqBan/Pick 事件顺序1全局顺序不是英雄序号event_typeBAN 或 PICKPICK字段可扩展为 SWAPround_code轮次编号R1 / R2 / R3分析第几手博弈hero_name英雄名鲁班大师需要与英雄字典一致result本局是否获胜1 或 0队伍维度的结果初学阶段最容易错的一点是把result记成“某个英雄赢没赢”。如果 TeamA 拿下比赛TeamA 所有已选英雄都算 1TeamB 所有已选英雄都算 0。这样才能在禁用率和选用率之外计算英雄胜率。2.3match_state表设计状态表按“选手每局每分钟”保存一次累计数据。这里记录的是累计击杀、累计死亡、累计助攻、累计经济、团队击杀数等基础量不建议把KDA直接存成字段因为后面动态计算更方便避免同一数据多套口径。CREATE TABLE IF NOT EXISTS match_state ( id INTEGER PRIMARY KEY AUTOINCREMENT, match_id TEXT NOT NULL, game_no INTEGER NOT NULL, team TEXT NOT NULL, player_code TEXT NOT NULL, hero_name TEXT, minute INTEGER NOT NULL, kills INTEGER NOT NULL DEFAULT 0, deaths INTEGER NOT NULL DEFAULT 0, assists INTEGER NOT NULL DEFAULT 0, total_gold INTEGER NOT NULL DEFAULT 0, total_xp INTEGER NOT NULL DEFAULT 0, total_damage INTEGER NOT NULL DEFAULT 0, team_kills INTEGER NOT NULL DEFAULT 0, result INTEGER NOT NULL, UNIQUE (match_id, game_no, team, player_code, minute) );player_code使用选手脱敏编号比如P1、P2。正式项目建议关联选手维表不要直接存中文名因为中文名在不同阶段会用不同写法容易产生脏数据。minute从 1 开始每分钟一行。这样做的目的是支持时间窗口切片。如果只保存比赛结束时的全场数据就无法回答“前十分钟状态是否下滑”这类问题。2.4 英雄字典表BP 表和状态表都只保存英雄名。不同渠道的英雄名可能有差异比如“老夫子”与“夫子”、“鲁班大师”与“鲁大”混用。建立英雄字典表是最直接的清洗方式。CREATE TABLE IF NOT EXISTS hero_dict ( hero_name TEXT PRIMARY KEY, hero_alias TEXT, position TEXT, early_power REAL, mid_power REAL, late_power REAL );hero_alias记录常用别名。position记录对抗路、发育路、中路、游走、打野等位置。early_power、mid_power、late_power是主观评分用于探索性分析需要由教练组统一校准不要当作客观属性。导入数据完成后可以用下面命令检查英雄名是否能全部关联。SELECT DISTINCT b.hero_name FROM match_bp b LEFT JOIN hero_dict h ON b.hero_name h.hero_name WHERE h.hero_name IS NULL;只要这条 SQL 返回非空说明 BP 记录里存在字典外的英雄名。此时不要直接改原始表而是补齐字典。3. 写入样例数据并转换成可统计宽表3.1 先准备脱敏样例数据为了演示处理流程这里制造一段不能直接用于真实分析的脱敏数据。重点不是数据量而是让整个导入过程可运行、可检查。先导入 BP 样例数据CSV 内容如下。match_id,game_no,team,side,event_seq,event_type,round_code,hero_name,result,patch_version BO7_FINAL_001,7,TeamA,BLUE,1,BAN,R1,大乔,1,V2025 BO7_FINAL_001,7,TeamB,RED,2,BAN,R1,鲁班大师,0,V2025 BO7_FINAL_001,7,TeamA,BLUE,3,PICK,R1,镜,1,V2025 BO7_FINAL_001,7,TeamB,RED,4,PICK,R1,不知火舞,0,V2025 BO7_FINAL_001,7,TeamA,BLUE,5,PICK,R1,廉颇,1,V2025 BO7_FINAL_001,7,TeamB,RED,6,PICK,R1,孙膑,0,V2025状态数据可以先用 Python 生成一百条左右模拟记录。下面这段代码能快速生成两阶段假数据。import pandas as pd import numpy as np np.random.seed(2025) rows [] for match in [BO7_FINAL_001]: for team in [TeamA, TeamB]: result 1 if team TeamA else 0 for player_code in [P1, P2, P3, P4, P5]: gold 3000 for minute in range(1, 16): gold int(np.random.normal(500, 80)) rows.append({ match_id: match, game_no: 7, team: team, player_code: player_code, minute: minute, kills: int(np.random.poisson(0.3)), deaths: int(np.random.poisson(0.3)), assists: int(np.random.poisson(0.4)), total_gold: gold, team_kills: int(np.random.poisson(1.5)), result: result, }) state_df pd.DataFrame(rows) state_df.to_csv(data/state_sample.csv, indexFalse)这段代码的随机字段只是为了让教程可运行。正式场景中这些字段要来自赛事转播数据或人工录像标注不能直接随机生成后写进复盘结论。3.2 导入 SQLite 并做完整性检查写一个导入脚本把两份 CSV 写入数据库并按唯一键防止重复。import sqlite3 import pandas as pd con sqlite3.connect(data/review.db) bp_df pd.read_csv(data/bp_sample.csv) state_df pd.read_csv(data/state_sample.csv) bp_df.to_sql(match_bp, con, if_existsreplace, indexFalse) state_df.to_sql(match_state, con, if_existsreplace, indexFalse) con.execute( CREATE UNIQUE INDEX IF NOT EXISTS uq_bp ON match_bp(match_id, game_no, team, event_seq) ) con.execute( CREATE UNIQUE INDEX IF NOT EXISTS uq_state ON match_state(match_id, game_no, team, player_code, minute) ) print(match_bp:, con.execute(SELECT COUNT(*) FROM match_bp).fetchone()[0]) print(match_state:, con.execute(SELECT COUNT(*) FROM match_state).fetchone()[0]) con.close()检查点有两个一是行数是否与 CSV 期待行数一致二是重复执行脚本时是否因为唯一索引报错。生产环境建议在脚本前先备份数据库避免索引冲突把已有数据覆盖掉。3.3 用 SQL 或 Pandas 计算 BP 优先级BP 优先级是赛后复盘时经常被提到但很少被精确定义的词。一个比较简单的定义是英雄被第一轮 Pick、第一轮 Ban并且该英雄在当前版本胜率也高则优先级更高。优先级得分可以这样计算priority_score 0.3 * pick_game_rate 0.3 * ban_game_rate 0.4 * pick_win_rate其中pick_game_rate是这个英雄被选用的局数占比ban_game_rate是被禁用的局数占比pick_win_rate是被选用时的队伍胜率。权重需要结合版本调整不是固定公式。用 Pandas 计算如下。import pandas as pd import sqlite3 con sqlite3.connect(data/review.db) bp pd.read_sql_query( SELECT match_id, game_no, team, event_type, hero_name, result FROM match_bp, con, ) total_matches bp[match_id].nunique() pick bp[bp[event_type] PICK].copy() ban bp[bp[event_type] BAN].copy() pick_rate ( pick.groupby(hero_name) .agg(pick_count(match_id, count)) .reset_index() ) pick_rate[pick_rate] pick_rate[pick_count] / total_matches ban_rate ( ban.groupby(hero_name) .agg(ban_count(match_id, count)) .reset_index() ) ban_rate[ban_rate] ban_rate[ban_count] / total_matches win_rate ( pick.assign(winpick[result]) .groupby(hero_name) .agg(pick_win_rate(result, mean)) .reset_index() ) bp_priority ( pick_rate .merge(ban_rate, onhero_name, howouter) .merge(win_rate, onhero_name, howouter) .fillna(0) ) bp_priority[priority_score] ( 0.3 * bp_priority[pick_rate] 0.3 * bp_priority[ban_rate] 0.4 * bp_priority[pick_win_rate] ) print(bp_priority.sort_values(priority_score, ascendingFalse)) con.close()这段代码的意图不是区分谁强谁弱而是把“哪些英雄值得在前两手处理”变成可比较的数字。若数据量只有一局需要明确提示自己单局的 pick_rate 只有 0 或 1不适合下全局结论。3.4 把选手状态加工成分钟级指标状态表导入后可以按时间窗口聚合出选手状态变化。计算参团率时要注意除零问题游戏没有产生击杀的分钟内参团率没有意义应当保留为空值。import pandas as pd import numpy as np con sqlite3.connect(data/review.db) state pd.read_sql_query(SELECT * FROM match_state, con) state state.sort_values([team, player_code, minute]) state[participation_rate] ( (state[kills] state[assists]) / state[team_kills].replace(0, np.nan) ) state[gold_gap] state[team].map( lambda x: 1 if x TeamA else -1 )还可以把每个选手对团队经济的占比算出来。该指标能显示选手在当前时间点是否吃到经济但不能说明吃经济后是否打出应有作用。state[gold_share] state.groupby( [team, minute] )[total_gold].transform(lambda x: x / x.sum()) print(state[state[player_code] P1] .head(10) .to_string(indexFalse)) con.close()这里生成的participation_rate、gold_share已经是可以绘图的时间序列基础字段。要注意的是手动或模拟数据里的Kills可能不是累计值而是每分钟新增值。用前要把“每分钟新增事件”和“累计经济”两种口径分开。4. 用数据回答“BP 是否被压制”和“状态差在哪里”4.1 用优先级得分判断选边和前两手强度在巅峰对决局红蓝双方可用的英雄池基本一致。拿到蓝色方时前两手通常要承担两个任务一个是抢下本队最有胜算的体系核心另一个是破坏对手已经熟练的核心组合。用match_bp表筛选第一轮 Pick 的事件可以快速生成一张优先级对照表。import sqlite3 import pandas as pd con sqlite3.connect(data/review.db) sql SELECT team, hero_name, COUNT(*) AS pick_count, AVG(result) AS win_rate FROM match_bp WHERE event_type PICK AND round_code R1 GROUP BY team, hero_name ORDER BY team, pick_count DESC first_round pd.read_sql_query(sql, con) print(first_round) con.close()如果 TeamA 在第一轮反复抢下的英雄在敌方英雄字典中已经存在明显克制那么优先级数字再高也没有用。这时要回看录像判断是对方故意放出的陷阱还是第五手 Counter 没有处理好。实际操作中不要只看胜率。一个英雄即使全局胜率低但如果某名选手在该英雄上的熟练度明显高于当前英雄池那么优先级也应单独评估。4.2 用对位矩阵查看 Ban/Pick 是否被 Counter单纯统计英雄优先级并不足以解释第 7 局。还要看两个队伍“最终拿到的阵容”之间的对位关系。一种可行的做法是增加人工标注字段counter_edge记录每个 Pick 与敌方关键英雄是否存在 Counter 关系。ALTER TABLE match_bp ADD COLUMN counter_edge TEXT;在数据量较小时可以用 SQL 将同一局内两边阵容按“前两手对位”拉平。SELECT b.team AS blue_team, b.hero_name AS blue_first_round, r.team AS red_team, r.hero_name AS red_first_round, b.result FROM match_bp b JOIN match_bp r ON b.match_id r.match_id AND b.game_no r.game_no AND b.side BLUE AND r.side RED WHERE b.event_type PICK AND r.event_type PICK AND b.round_code R1 AND r.round_code R1;用 SQL 生成对位表后再看录像中前十分钟的实际交手。如果敌方选择的英雄在理论上被某个英雄克制但实际对线时并没有造成击杀或经济差就要怀疑是执行层面的换线或支援策略绕开了克制关系。这里要特别注意不要因为数据样本少就直接判断“这个英雄一定克制那个英雄”。英雄克制需要考虑操作者熟练度、等级、装备、野区支援时机多层因素。4.3 用时间线指标定位选手状态变化“状态低迷”如果只给一个最终数据很难解释。比如一场 25 分钟的比赛Carry 位全场死亡 5 次如果 5 次都发生在最后 3 分钟的高地进攻和前 20 分钟无失误是完全不同的状态。可以用分钟级total_gold计算每 5 分钟经济增量再除以团队经济增量得到该选手在对应时间窗口的经济获取效率。import pandas as pd def add_window_gold(state_df, window5): state_df state_df.sort_values( [team, player_code, minute] ) state_df[window] (state_df[minute] - 1) // window state_df[prev_gold] state_df.groupby( [team, player_code] )[total_gold].shift(1) state_df[gold_gain] state_df[total_gold] - state_df[prev_gold] state_df.loc[state_df[prev_gold].isna(), gold_gain] ( state_df[total_gold] ) window_gold state_df.groupby( [team, player_code, window], as_indexFalse, )[gold_gain].sum() team_window_gold state_df.groupby( [team, window], as_indexFalse, )[gold_gain].sum() return window_gold.merge( team_window_gold, on[team, window], suffixes(_player, _team), ) window_stats add_window_gold(state_df) window_stats[gold_share_in_window] ( window_stats[gold_gain_player] / window_stats[gold_gain_team] )这里的时间窗口默认 5 分钟一般比赛取局内 1 到 5 分钟、6 到 10 分钟、11 到 15 分钟三档已经能覆盖主要节奏变化。如果赛训组想观察对线细节可以改成 3 分钟但窗口过小会让随机波动变大。状态变化需要结合上下文解释。某个选手在经济占比低的窗口里正在下路带线止损不是所有低经济窗口都等于状态差。4.4 补充相关分析谨慎下结论样本足够时可以计算选手分钟级指标与胜负的相关性而不是直接把胜负归因到某一个人。比如用pick_win_rate、first_round_pick_rate、team_kill_str等特征做探索性分析。feature_cols [ pick_rate, ban_rate, pick_win_rate, priority_score, ] print(bp_priority[feature_cols].corr(numeric_onlyTrue))这行代码只输出相关系数矩阵不会替人回答因果。相关系数高只能说明两个变量在同一样本中同时变化不能说明“某数据高所以某人状态好”。如果希望建立预测胜率的模型要先把特征划分为阵容特征和执行特征。阵容特征来自 BP 阶段执行特征来自局内前 10 分钟数据。否则等到 25 分钟才用最终伤亡数猜测胜负本质上已经失去复盘价值。 建模时还要注意局数极少常见模型容易过拟合。演示代码跑出来的结果不能直接作为赛训结论。5. 常见统计坑与排查路径5.1 高频错误和解决方案问题现象常见原因检查方式处理建议英雄名 join 不上采集渠道缩写不一致运行 Hero 字典空值检查补字典不直接改原始表KDA 出现无穷值死亡数为 0 时直接除查看字段缺失统计用replace(0, np.nan)BP 优先级结果不符合认知把单局数据当样本量查看pick_count至少累积一个系列赛再下结论同一场对局重复统计队伍结果字段与对局结果混用检查唯一索引增加 match_id team 唯一约束时间窗口状态异常分钟字段是累计值但按增量计算对比前后行差值先确认口径再写diff选手归因失真只看 KDA 或只看伤害打开明细数据用多指标横向验证5.2 拿到异常结果时的七步排查清单第一步先检查输入。原始录像中的局数是否对应第 7 局队伍红蓝方是否录反。第二步检查字段类型。minute是整数还是字符串result是否被读成了浮点。第三步检查唯一键。同一match_id、同一队伍、同一event_seq是否重复插入。第四步检查补丁版本。不同版本英雄平衡性不同状态表里的玩家熟练度也会随版本变化。第五步检查时间口径。状态表中的kills是累计还是每分钟新增total_gold是否随时间只增不减。第六步检查聚合粒度。计算英雄胜率时是否误把五名选手的行都当成独立样本。第七步先做人工抽样。从模型结果中随机抽两个时间点回看录像确认结论和数据方向一致。5.3 数据不足以支撑情绪化论断教程级别的数据量通常只有几场比赛无法覆盖英雄池、版本更新、选手手感等多变量。把“某位选手状态低迷”当成最终结论等于用单个结果替代过程分析。更稳妥的表述是在某个时间窗口内该选手的某类指标低于自身基线。训练意义可以落到“开局支援路线选择”“中期伤害转化效率”“关键装备合成前参团率”等具体动作上。 个人责任判断应交给教练团队结合语音和训练数据完成复盘工具只提供证据不代替人做定义。6. 把这个复盘流程用于正式赛训的建议6.1 本地学习环境与正式赛训环境差异维度本地学习环境正式赛训环境数据量手工记录几场按赛季和赛区积累数据获取CSV 手工导入官方接口或内部数据服务表权限任意修改只读权限加审计版本管理Git 管理代码还要管理模型指标口径版本输出方式Jupyter 或脚本打印仪表盘、报告、告警红线可以用模拟数据必须保证口径统一且可追溯正式环境的高价值不在“能统计 KDA 多少”而在“每次统计使用的口径都一致”。如果训练一周后重新跑同一条 SQL 得到不同结果数据平台会立刻失去信任。6.2 最佳实践指标、口径、版本先固定比赛唯一键。建议使用series_id game_no team三字段作为比赛维度唯一键避免每次关联都写一长串条件。建立补丁版本表。英雄改版、装备调整都会重新定义优先级不在表中记patch_version后续回溯时无法判断旧结果是正常波动还是版本影响。所有选手状态字段尽可能与英雄字段解耦。统计“参团率”时野核体系、射手大核体系、工具人体系不同不能只用同一个中立阈值判断。输出与训练动作强相关的指标。BP 复盘至少要能回答我方首抢是否存在被 Counter 的记录阵容弱势期在哪个时间窗口换线或支援策略是否让理论克制关系失效。选手状态复盘至少要能回答哪条线经济增速低于对手关键时间点是否不在正面资源团前是否完成关键装备。避免只提供一个综合得分。综合得分看起来很方便却会隐藏问题所在。报告应该保留原始明细和指标定义并给出一到两行可执行建议。6.3 后续扩展方向可以把 BP 数据扩展到语音沟通文本。通过关键词匹配查找比赛开始前教练安排首抢英雄的记录再与场上实际选择对比能判断教练意图与执行结果是否一致。也可以把状态数据扩展到训练赛。训练赛的补刀、死亡、资源控制可以被同一套代码处理积累到一定量后能建立选手个人的基线带异常波动会更容易发现。对新手来说最有价值的练习不是拿真实选手做舆论判断而是把自己曾经打过的对局录像按文中两张表手动记录十分钟再用 Python 跑出时间线。记录过程会让你发现很多原本不被注意的细节一级团前经济是否落后、中路支援路线是否撞脸、拿到强势英雄后是否真的在前期建立视野优势。当数据能稳定覆盖一个系列赛的 BP 和选手状态后这套流程就可以从复盘工具扩展成赛前对手分析工具。对手惯用英雄、前两手优先级、选手状态变化都会被结构化记录后续每次比赛只需更新当天的数据通过同一套指标比对差异既能减少“凭感觉复盘”也能让训练方向有明确依据。复盘不是用数据证明谁对谁错而是把有限样本里的每个环节拆开让下一次训练能在具体问题上多花时间。