省赛结束的那个晚上很多参赛群里都会出现一句话“省赛败北佬们一路顺利”。发这句话的可能是差几名才拿奖的算法选手可能是作品赛答辩时被评委追问到卡壳的队长也可能是第一次参赛、连签到题都很吃力的新人。一句话里有不甘心也有对继续前行者的祝福。但在技术人眼里这句话发完之后真正应该接住的事情只有一件把这次失败拆开弄清楚到底输在哪一层。这篇文章不写鸡汤也不会劝你“明年再来就好”。我想分享的是一套面向开发者的竞赛失败复盘方法论。无论你参加的是算法类省赛、软件服务外包类省赛还是电子设计、信息安全攻防类比赛复盘逻辑都大同小异先还原结果再剖析过程然后落到能力层最后形成一份可执行的改进计划。文中会给出可以直接复用的表格、命令和脚本读完你可以照着做一份属于自己的赛后复盘文档。1. 省赛败北先分清输在哪一层很多人复盘时第一反应是纠结于“就差一名”或者“运气不好”。这种情绪可以理解但它会把复盘引向错误的方向。比赛失利往往不是单点问题而是多层问题叠加的结果。我习惯把失败原因拆成四层结果层、过程层、能力层、认知层。分清楚是哪一层出了问题你才知道到底应该补什么。1.1 结果层先准确记录发生了什么结果层是你最直观看到的层包括最终排名、奖项名次、晋级线、队伍排名中位数等数据。这些数据虽然不能直接解释原因但它们是一份很好的“索引”。复盘第一步是把客观结果先记录下来而不是急于辩护或自我否定。比如你参加的是算法竞赛可以记录本次参赛队伍总数、你们的名次、晋级省一或国赛的名次线、和身前队伍相差多少罚时。这些数据看起来琐碎但它们决定了后续复盘的“精度”。如果只差一次错误提交的罚时重点就应该放在罚时管理如果和身前队伍差了整整一道题那问题大概率出在算法覆盖面和题目熟练度上。先看结果复盘才不会跑偏。1.2 过程层还原赛场上的时间线过程层关注比赛过程中实际发生了什么。对于算法竞赛要还原的数据至少包括每道题第一次提交的时间、AC时间、错误提交次数、卡题最久的那道题、中途放弃的题目。对于作品赛或论文赛则要还原项目什么时候定题、开发花了多长时间、演示或答辩环节哪里被问住、评委对哪个部分不满意。有了过程数据你才能准确判断问题出在哪里。比如签到题用了40分钟才AC说明基础代码熟练度不足一道题提交了6次还在WA说明