复盘 EDG 输给 JDG 这场比赛时,最容易得到也最容易引发争议的一句话是“BP 巨大失误”,随后通常还会补一句“团队协作也明显困难”。这两句话听起来结论完整,实际却不能指导任何改进。因为没有还原选人顺序、版本环境、选手英雄池和比赛时间轴之前,“BP失误”和“协作困难”都只是事后标签。真正的问题在于:这个 BP 在当天的信息条件下,是不是明显偏离了最优解;团队协作到底在第几分钟、哪一个资源点、哪一次决策链路上出现断点;如果换一套 BP 或换一种决策流程,证据是否支持结果会不同。下面的复盘方法,就是把一场 EDG 对 JDG 的比赛当成一个待分析系统,先记录、后归因、再验证,最后产出能指导下一次比赛的结构化结论。
1. 先理解 BP 和团队协同为什么容易被误判
1.1 BP 是赛前方案设计,不是赛后借口
职业比赛里的 BP,全称是 Ban/Pick,也就是禁用和选人。两队通过多轮禁用限制对方可用英雄,再通过多轮选择构建自己阵容,最终每队拿到 5 个英雄,同时阻止对方拿到关键英雄。BP 表面上是选人规则,本质上是一个在信息不完整条件下完成的方案设计:只知道对方擅长什么、最近状态如何、当前版本哪些英雄强势,但不知道对方教练组今天准备了多少套隐藏阵容。
所以“BP 巨大失误”不能只在比赛结束后用一句“阵容选出来就输了”来定义。真正的 BP 失误至少分为几类:优先级排序失误,比如把版本非强势英雄放在一抢位置,而放出了对方胜率很高的体系;Counter 关系失误,比如明知道对方某位选手最近手感极好,却没有在选人阶段限制或针对;阵容结构失误,比如全队只有开团没有反打,只有 poke 没有前排,或者五个英雄对资源需求高度重叠;选手状态与英雄池错配,比如强行选择当前版本数值强但该选手不熟练的英雄,导致对线无法执行。
在 EDG 输给 JDG 的语境里,要判断“BP 巨大失误”是否真的成立,必须先把这一局比赛的完整 BP 过程写成决策日志。只看最终选择的五个英雄,会漏掉更关键的信息:为什么先抢 A 而不抢 B,为什么把某个 Counter 位留给单人路,为什么后两 Ban 主动放掉对方下路组合。BP 是连续决策,最后五张英雄头像只是决策结果的快照。
1.2 团队协作困难是聚合症状,不是根因
团队协作困难听起来像一个原因,其实更像一个结果。一支队伍不会从第一分钟到最后一分钟都随机地“协作困难”,更常见的是在特定阶段、特定资源和特定决策上出现断裂。可能是对线期上单压线,辅助准备做河道视野,打野正在刷另一组野怪,导致对方野辅先到一步形成三包一;可能是小龙刷新前两分钟,团队没有统一“推线还是后撤”的思路,结果兵线没推出去,视野也被压制;也可能是大龙刷新后,有人想打有人想拉扯,在犹豫的几秒钟里被对方开起团战。
用技术化的方式理解,团队协作是一条“感知-决策-执行”的链路。感知环节是视野和队友位置是否有足够信息;决策环节是指挥、信号和队友响应是否一致;执行环节是站位、技能和伤害是否在时间上对齐。任何一环出问题,外在表现都是“看起来配合不好”。因此复盘时不能只说 EDG 团队协作有问题,而要找到具体是哪一段链路、哪一分十几秒、由哪些事件共同触发。
2. 复盘前先准备素材和数据规范,否则判断缺少证据
2.1 不同类型的录像回答的问题不一样
复盘素材至少要覆盖三类:官方 OB 镜头、选手第一视角、赛后数据页面。官方 OB 镜头可以看到全图事件、经济和视野变化,适合追踪资源置换与转线节奏。选手第一视角可以看到某个选手在关键节点是否看了小地图、是否接收到信息,适合定位个人判断和团队信号是否同步。赛后数据页面可以看到分均补刀、伤害占比、视野得分、控制资源率等指标,适合验证“看起来对面更强”是否由数据支撑。
还有一类素材是队内语音,但这在公开复盘里通常拿不到。没有语音不代表不能分析团队协作,而是要把结论的置信度明确降级:通过位置关系和事件时间可以推断“这里很可能沟通没对齐”,但无法确认是哪位选手先说了什么。
2.2 建立统一的比赛归档目录
建议在一场关键比赛结束后,把素材和中间分析文件放进统一目录。没有规范目录会导致复盘时反复翻录像,同一个问题在不同地方被重复讨论。
mkdir -p replay_workspace/EDG_vs_JDG/{raw,analysis,scripts,conclusions} cd replay_workspace/EDG_vs_JDG目录内部分工可以这样安排:
| 目录 | 存放内容 | 说明 |
|---|---|---|
| raw | 录像、截图、官方赛后数据 | 原始材料,只读不修改 |
| analysis | BP 矩阵、事件日志、指标计算 | 分析过程中的中间产物 |
| scripts | 数据处理脚本 | 保留运行环境和参数,便于复现 |
| conclusions | 最终复盘结论和待验证项 | 统一收敛,不散落在讨论区 |
在 raw 目录下建议保留一份 metadata.yaml,把这局比赛的环境信息固定下来。版本、对手、选边、比赛日期都会影响结论,不固定下来,之后很容易用旧版本的理解评价新版本阵容。
match_id: "EDG_vs_JDG_G1" event: "以官方赛程记录为准" patch: "按比赛当日实装版本填写" side: edg: "blue_or_red" jdg: "blue_or_red" analysis_date: "按实际复盘日期填写"这里的关键不是一定要用 yaml,而是必须先形成一份“比赛环境快照”。BP 讨论最怕跨版本误判,一个英雄可能在这个版本还是下路主流,下个补丁就因为数值调整或地图改动变得弱势。归档里如果没有版本号,复盘结论对其他场次的参考价值会大打折扣。
2.3 锁定版本和当日版本认知,再开始评价选人
复盘中经常出现一种错误:用比赛结束后的版本认知去评价几个月前的 BP。比如某个英雄在后续补丁里被加强,人们就认为当时没选是教练组失误,但当时实装版本里该英雄数值并不强,ban/pick 优先级也完全不同。
正确做法是先把比赛日期和游戏版本写入 metadata,再去看该版本对英雄强度、换线策略、地图资源刷新机制的影响。此后讨论“为什么不选某英雄”时,要区分两层:这个英雄在当前版本强不强,以及这个英雄是否适合本队选手当前的状态与体系。前者可以查补丁和胜率,后者需要结合选手近期训练赛和比赛记录,只能推断,不能实锤。
3. 用 BP 矩阵还原选人逻辑,验证“BP 巨大失误”是否成立
3.1 把每一手 Ban/Pick 展开成“操作-意图-联动”三层
判断 BP 是否失误,先把完整 BP 过程按次序还原成一张矩阵。每一行不仅写选择的英雄,还要写这一步要解决什么问题。
| 轮次 | EDG 操作 | 可能意图 | JDG 操作 | 可能意图 | 与前后手联动 |
|---|---|---|---|---|---|
| 第一轮 Ban | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
| 第一轮 Pick | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
| 第一轮 Ban | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
| 第二轮 Pick | 待填写 | 待填写 | 待填写 | 待填写 | 待填写 |
把实际操作填入后,再对每一手问四个候选解释:这个选择是为了拿版本强势英雄,还是为了拆对方体系,还是为了给某位选手创造 Counter 关系,还是为了配合已经选出的前两手。这四个解释不一定互斥,但在复盘表里要标出哪一个优先级最高。
例如红色方第一轮如果直接抢辅助,常见解释是担心蓝色方拿到某个线权极强的辅助,从而保证下路对线不被压。如果这个辅助在该选手的英雄池里胜率普遍偏低,那就要分开讨论:BP 放出版本强势点是失误,还是因为选手状态不佳导致临时改变优先级。
3.2 用选手英雄池数据计算“禁用-选用-胜率”综合维度
BP 评价不能只依赖“感觉某个英雄很厉害”,最好用数据量化选手与英雄的匹配程度。先把近期数据整理成结构化文件,用脚本计算一个价值分,辅助复盘时定位优先级。
{ "player_id": "player_x", "patch": "按实际比赛版本填写", "heroes": [ {"hero": "示例英雄A", "pick": 20, "ban": 6, "wins": 12}, {"hero": "示例英雄B", "pick": 15, "ban": 10, "wins": 6} ] }import json with open("hero_pool.json", "r", encoding="utf-8") as f: data = json.load(f) for player in data["heroes"]: pick = player["pick"] ban = player["ban"] win = player["wins"] win_rate = win / pick if pick else 0 ban_rate = ban / (pick + ban) if (pick + ban) else 0 score = pick * 0.4 + win_rate * 0.3 + ban_rate * 0.3 player["score"] = round(score, 3) data["heroes"].sort(key=lambda x: x["score"], reverse=True) print(data["heroes"])这段代码的意义不是给出最终结论,而是把“某选手必须抢 A 英雄”这类主观观点转成可比较的分数。实际项目中需要注意:pick、ban、wins 都要限定在同一版本区间,并且样本量过小时分数不可靠。选手最近十场表现比过去一年的历史胜率更有参考价值。
3.3 判定 BP 失误要过的三个测试问题
把 BP 矩阵和选手数据整理完后,不要急着下结论,先依次回答三个问题。
第一,是否存在更好的可执行替代方案。所谓可执行,不只是英雄本身强,还包括当时还没被 Ban、选手会玩、和前后选人搭配不冲突。如果找不到更好的替代,那就不能叫失误,只能叫被限制后的次优选择。
第二,导致失败的关键英雄选择是否在对方计划中可预期。JDG 如果第三选才锁下某个英雄,而 EDG 在前三 Ban 阶段没有针对这个英雄,要判断这个英雄是否在近期比赛中高频出现。如果该英雄近十场都是对方优先抢的对象,那放出来就是信息准备不足。
第三,后两手有没有补救前两阶段造成的结构问题。比如前两手选完已经发现伤害不足,后两手是否补进了后期大核;如果前两手拿到两个需要打野频繁照顾的英雄,后两手是继续加码对线强度,还是主动选一个能独立发育的分带位。
如果三个问题都指向“明明有更好方案,却没执行”,BP 失误的结论才算有证据支撑。如果三个问题里有任何一个回答不确定,输出时应该写成“该阵容存在明显结构风险”,而不是“教练组巨大失误”。
3.4 没有队内语音和训练赛资料时,怎么表达判断
公开复盘永远缺少队内信息,因此语言上要控制精确度。看到某手选择很奇怪,可以写为“从公开版本和选手近期状态看,这一手选择的风险较高”,而不是“这手选择无法理解”。可以结合选手近期单排记录和该队此前使用过的体系,寻找“这个英雄或许是为了服务某个战术”的迹象。但单排和训练赛不完全等效,不能单凭 Rank 数据断定选手状态。
所以复盘结论建议分成三个等级:证据充分的结论、基于公开信息的推断、需要内部信息确认的猜想。只有第一类可以直接用于指导下一场,后两类都应该进入待验证清单。
4. 用时间轴定位团队协作困难,细化到分钟级事件
4.1 把一局比赛切成四个阶段,每个阶段看不同指标
团队协作问题不能用一句“中期崩了”来描述。把比赛按目标和资源点切成阶段,每个阶段记录不同的关键问题,更容易定位决策断点。
| 时间范围 | 主要目标 | 怎么看协作 |
|---|---|---|
| 开局到 15 分钟 | 对线、河道视野、第一条峡谷先锋与小龙 | 野辅是否在关键时间点同步行动,边线是否有人接应 |
| 15 到 25 分钟 | 换线、转线、听牌龙和边路一塔 | 单带线是否与团队大部队信息同步,是否导致资源强行让出 |
| 25 到 35 分钟 | 大龙争夺、关键团战 | 开团和反打前是否有人提前交位移,后排输出位置是否被切割 |
| 35 分钟以后 | 远古龙与终结比赛 | 兵线处理是否支撑龙团,决策是否统一在一套博弈路径上 |
这段划分不是固定标准,而是最小分析单位。如果 EDG 输给 JDG 的比赛属于速推局,35 分钟以后的阶段并不存在,分析重点应该前移。复盘表格的价值是防止只盯着最后五分钟,忽略前期资源劣势如何一步步放大。
4.2 用事件日志记录决策分歧点
团队协作问题体现在具体事件的先后顺序里。手动回看录像时,把每个关键事件按统一模板记录。
| 时间点 | 地图事件 | 双方资源状态 | EDG 决策内容 | 执行结果 | 可能的协作断点 |
|---|---|---|---|---|---|
| 例如 17:32 | JDG 集合打小龙 | 双方各两条听牌龙 | EDG 中单清完中路线后向上路靠,打野在小龙坑附近 | JDG 拿下小龙并击杀 EDG 辅助 | 团队信息未统一在打龙或推塔之间 |
事件日志的关键是每个字段都必须来自录像画面或数据,不能写“当时应该打小龙”这类主观判断。资源状态要明确到龙魂、兵线推进方向、关键英雄大招可用性。没有这些约束,复盘很容易变成比赛结束后找理由。
4.3 用经济曲线、视野得分和控制资源率验证事件结果
事件日志记录的是“发生了什么”,指标验证的是“结果有多大影响”。经济曲线可以看一段时间内双方的资源差如何从少量领先变成决定胜势;视野得分可以看各时间节点控图权的变化;控制资源率可以判断团队是否为了某条龙放弃过多其他资源。
单一指标不适合直接得出协作问题结论。例如 EDG 某时点落后两千经济,可能是阵容进入中期弱势期,而不是协作断了。要配合视野得分一起看:如果落后侧在对方野区视野大面积缺失,中单仍然冒险探草丛,那更可能是信息不足或个人过多自信,而不是经济本身就导致必然失败。
4.4 用简单脚本找出经济剧烈跳变的分钟节点
手动逐分钟对录像效率很低,可以先把经济差按分钟导出,用脚本找出经济曲线剧烈变化的节点,再回到录像重点看这几分钟。
import pandas as pd df = pd.read_csv("timeline_econ.csv") df["econ_lead"] = df["econ_lead"].fillna(0) df["swing"] = df["econ_lead"].diff().abs() # 找出经济一时间变化最大的 3 个节点 top_swing = df.nlargest(3, "swing") print(top_swing[["minute", "econ_lead", "swing"]])timeline_econ.csv 是从录像或赛后面板导出的分钟级数据,字段至少包含 minute 和 econ_lead。下面的示例只用来演示格式,正式复盘要替换成比赛实际数据。
minute,econ_lead 1,0 5,150 10,-300 15,-800 20,-1200 25,-1500 30,-1400 35,-2200输出节点后,回到录像看该分钟附近发生了什么:对方拿到了哪条龙,是否通过先锋直接推掉中路一塔,是否完成了一次成功的上单选单带牵扯。这个流程能够把“经济落后”从宏观结果转变成一串可定位原因。
5. 常见复盘误区和错误结论,应该按这条链路排查
5.1 误区一:只看最后一波团战定输赢
现象:比赛结束后分析只盯着最后一波团,说“这里如果谁没先倒,就能翻盘”。原因:最后团战视觉冲击强,画面里容易找到失误。但它往往只是前期资源劣势的最终兑现。
检查方式:看经济曲线和资源事件,判断最后一波开始前是否有翻盘条件。如果 EDG 在最后一波前已经落后多条小龙且边线完全推不出去,就不应该把“最后一波操作失误”作为主要根因。正确做法是把时间轴往前提,找到第一个让 EDG 进入被动位置的关键节点。
5.2 误区二:把单次操作失误当成团队协作问题
现象:某位选手在团战里被开,复盘直接写“辅助没保人、队友没跟输出”。原因:把团战失利等同于协作链条全断,忽略了这次被开可能发生在团队已经持续劣势、只能冒险探视野的背景下。
检查方式:观察被开前 5 秒该选手的位置、小地图上队友的距离、技能交出的顺序。如果是一位选手主动走进无视野的草丛,而队友已经给出“后撤”信号,那首先是个人的关键决策失误,不是全队协作失衡。如果队员位置分散而且没有信号,才是协作信息传递的问题。
5.3 误区三:用 BP 洗白执行,或用执行洗白 BP
现象:输比赛后,支持“BP 有问题”的人拿出阵容不好打团,支持“执行有问题”的人拿出实际操作变形。但实际上二者可能共同作用,也可能只有其中一项起主导作用。
检查方式:把 BP 阶段的预期和实际执行结果对照。BP 阶段设想打前中期,实际却拖到 35 分钟,说明执行没有按阵容节奏走;BP 阶段选出一套后期体系,却在前期主动入侵对方野区导致崩盘,这才是执行层面违背方案。不要笼统说“都是 BP 害的”或“阵容没问题,选手操作太差”,而要描述哪个预期在哪个时间点被打破。
5.4 复盘检查清单
| 项目 | 确认方式 | 通过标准 |
|---|---|---|
| 版本固定 | metadata.yaml | 版本号和比赛日期记录完整 |
| BP 顺序完整 | BP 矩阵 | 每一手操作都填了英雄和候选意图 |
| 关键英雄有数据 | 选手英雄池表 | 至少说明 pick 次数、ban 次数、胜率三个字段 |
| 时间轴事件可查 | 事件日志 | 每个判断都落到具体分钟或资源点 |
| 结论分级 | conclusions 目录 | 明确标注是证据充分还是推断 |
| 行动项明确 | 待验证事项 | 给出下一次比赛可以观察的具体信号 |
这张清单在单场复盘完成前逐项检查,能避免“讨论了很多,最后没有沉淀”的常见情况。
6. 从一场比赛延伸到可复用机制:让复盘不再只服务情绪
6.1 用 3R 结构沉淀每一条复盘结论
复盘结论不要写成散文,建议使用 Result、Root cause、Review point 三段式结构。
Result 描述最后发生了什么,比如“EDG 在中期 20 分钟到 25 分钟经济差被拉大四千”;Root cause 给出最可能的原因,比如“中单连续两波去下路处理兵线,导致队伍在先锋团前缺少伤害核心”;Review point 是下一次要重点验证的内容,比如“如果中单留在中路,边线由谁处理,对方会不会用相同手段施压”。
一个 3R 单元只解决一个问题。单场复盘不需要写三十条结论,提炼三到五条有价值的已经足够。
6.2 建立队伍版本和英雄池样本库
单场复盘的价值有限,跨场次积累才能看出规律。建议维护一个队伍维度的样本库,不只需要 EDG 的信息,还需要对手 JDG 的偏好。
| 字段 | 示例说明 |
|---|---|
| 对手队伍 | JDG 近期偏好哪种开团体系 |
| 对手选手优先级 | 哪位选手拿到某英雄后队伍胜率明显更高 |
| 我方应对方案 | 用哪些 Ban 或 Pick 限制对方优先级 |
| 比赛版本 | 同一版本的结论不能直接挪到下一版本 |
| 结果 | 验证应对方案是否有效 |
表格只描述字段,不预设一劳永逸的结论。队伍英雄池会变,版本会变,真正稳定的是持续更新。一次复盘之后,把样本库中对应版本和对手的记录补充完整,比记住“JDG 这支队伍不能放某某英雄”更有价值。
6.3 个人复盘和团队复盘分开做
个人复盘只回答三个问题:我在哪个时间点获得的信息不完整,我是否在决策时忽略了队友位置,我有没有在关键时刻执行了另一个思路。团队复盘则检查指挥链和信息同步,不平衡于指责任何单个选手的个人操作。
分开做是为了避免“协作困难”这句大帽子覆盖个人问题。比如一波团战如果有人站位靠前,他会觉得自己是主动找机会;队友希望他收缩阵型,就出现了团队层面目标冲突。个人复盘聚焦站位选择是否合理,团队复盘聚焦“找机会”和“保阵型”为什么没在开团前统一。
6.4 观赛复盘和职业赛训复盘要把握不同的深度
普通观众和业余爱好者做复盘,不掌握训练赛数据,也不掌握选手当时的身体和情绪状态,因此要克制“谁必须背锅”的结论。更合理的目标是用复盘学会看门道:看到 BP 优先级、理解资源置换、判断决策链哪个环节先出问题。这和开发者阅读一份线上故障报告类似,不能进入公司内部系统,却能通过日志和时序重建事故现场。
7. 复盘结束时要产出什么,才算没有白做
7.1 “输在哪”的答案必须包含可验证证据
对“EDG 输 JDG 输在哪,BP 巨大失误,团队协作困难”这句话的最终回答,不应只是一句“输在 BP 和配合”。更合适的表达是:第一步,说明哪些 BP 风险被对方放大,具体出现在第三选还是后两 Ban;第二步,说明协作断点发生在哪一分钟,涉及哪条决策链路;第三步,给出下一场遇到相似局面时可以执行的三件具体动作。
这样得出的结论才是可行动项,而不是情绪标签。
7.2 下一次比赛前重点验证这一次的推论
把复盘结论写进待验证清单。如果这次推断 EDG 在后两 Ban 放出了 JDG 的强势体系,下一场再遇到 JDG,就要观察对方是否仍然优先抢同一个英雄。如果这次判断协作问题出现在第二条小龙刷新前的汇合,下一场可以单独复盘那个时间窗口,看队伍是否调整了信息同步方式。
复盘不是终点,只是新一轮观察的起点。把复盘结论交给下一次比赛验证,本质上和测试修复方案是否生效是一样的逻辑:看到现象,提出假设,补充观察样本,验证假设,再修订下一版判断。用这套方式回看 EDG 和 JDG 的比赛,慢慢会发现“BP 巨大失误”和“团队协作困难”都不再是模糊的批评,而是可以被修正、被验证、被沉淀的比赛数据。