先按反馈分类，别急着改代码
赛后拿到评测结果，先分清反馈类型：编译错误、答案错误、运行超时。三类问题的排查路径完全不同。编译错误可以直接看编译器提示的行号和说明，通常是语法、头文件或拼写问题；答案错误需要把程序输出和期望输出逐项对比，定位逻辑偏差；运行超时则要回看数据范围和算法复杂度。建议每次提交后都记录一行：题目、反馈类型、出错位置、初步猜测，积累起来就是你下一轮训练的索引。
用最小反例复现问题，再独立重写
答案错误最怕盯着代码空想。与其反复看逻辑，不如构造一个能触发错误的最小输入。比如自拟一道排序题样例：输入数组[3,1]，期望输出[1,3]；如果程序输出[3,1]，问题就复现了。构造时可以从边界值、相等元素、只有一个元素、空输入这些方向入手，往往能快速暴露问题。复现之后，先理解根因，再决定局部修正还是重写相关函数，并用原反例及其他合法测试确认修正。重写时重新推导每一步，而不是想着“上次哪一行写错了”，这样能避免修好一个问题又引出新问题。
超时问题：先估复杂度，再决定优化方向
运行超时可能来自算法复杂度，也可能来自死循环或实现问题，应先区分原因。拿到题目先看数据范围，估算操作次数：例如n=10^5时，O(n^2)约10^10次操作，多数评测环境会超时；这时应寻找O(n log n)或O(n)的解法。先改算法，再抠常数，比如减少重复循环、改用更快的输入输出方式。改完用最大规模数据自测，确认时间达标后再提交。
建立变化记录，把失败变成训练清单
赛后复盘的价值在于把失败转成下一次训练的具体任务。可以做一个三列表格：重复出现的错误、新出现的错误、已解决的错误。例如连续三次在边界条件上出错，就把“边界值测试”列为专项，下次做题前先写边界测试；如果两次都是排序比较函数写反，就专门练写各种比较函数。这份记录不用写感想，只写可执行的动作。持续记录后，可以查看哪些错误反复出现，并据此安排下一轮练习。
