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