这次想写的不是工具评测而是一次真实得不能再真实的竞赛复盘省级算法程序设计竞赛最终排名全省第三。第三名在绝大多数人眼里并不差但经历过整场比赛的人知道这个名次带来的遗憾远比成就感更清晰。复盘时我重新翻了每一道题的思路、每一段被注释掉的代码、每一处匆忙提交的边角数据。发现一件很扎心的事丢掉的名次几乎全都可以对应到一个具体的工程技术失误而不是“不会做某类算法”。这篇文章不打算卖惨也不准备讲“心态决定一切”这种空话。我会把这一次“全省第三的遗憾”拆成可验证的细节赛制怎么算分、赛前要准备哪些工具链、比赛过程中如何分配时间、边界条件如何在最后一刻毁掉整道题、以及赛后怎样才能把一次失败变成真正的能力增量。如果你也刷算法题、打比赛或者只是想知道“差一点点”到底差在哪里这篇文章可以直接收藏。1. 核心速览全省第三这个成绩到底怎么来的先给一个速览表方便快速建立整体印象。指标本次复盘的实际内容比赛类型省级算法程序设计竞赛个人赛考察范围基础算法、数据结构、数学推导、程序实现、调试能力排名算法按总分排名通常结合正确题目数与总用时不同赛制略有差异最终结果全省第三名核心遗憾与更高名次的差距并不来自算法盲区而来自边界处理、输入输出、时间分配和稳定复现最大教训样例通过不等价于程序正确越熟悉的代码越要警惕隐含问题适合读者正在备战算法竞赛的学生、刷 LeetCode 的开发者、想提升代码稳定性的工程技术人员表格里没有具体分数是因为复盘这件事最重要的不是那个数字而是数字背后的失分结构。从结果看全省第三已经能说明基础算法能力在线。但“在线”和“稳”是两回事。第三名的位置非常特殊它高到让你没办法说自己不行又低到让你清楚看见自己离天花板还有一步。那一步往往不是知识量而是稳定性。2. 适用场景与边界这篇复盘能解决什么问题先划定本文的适用边界避免误读。本次复盘适用于以下场景参加 OI、ACM、蓝桥杯、CSP、天梯赛等算法程序设计竞赛想提升比赛成绩。日常刷题时经常出现“本地能跑提交就错”“样例通过边界崩掉”的情况。写工程代码时关心输入输出性能、内存占用和边界条件的稳定性。想复盘一次比赛但不知道从哪里入手需要一套可执行的拆解方法。不适用于以下场景想找“速成拿奖”的套路本文没有也不建议信这种东西。想学某个具体算法的完整教程这里只讲与“遗憾”直接相关的能力缺口。需要情绪安慰而不是技术复盘本文会尽量克制。边界条件在这里很重要。竞赛成绩和工程代码一样从来没有“差不多就行”。一道题的数据范围给到 10^5你的算法复杂度是 O(n^2)本地小样例怎么跑都顺一上评测机就超时。这不是玄学是体力活复杂度估算、数据范围读题、极端输入验证每一步都要有记录。3. 赛前环境准备算法之外的工具链很多人把备赛只理解为刷题其实环境准备同样关键。省赛不是让你现场装环境它默认你已经在自己的工具链里训练过几千遍。3.1 语言与编译环境竞赛最稳妥的选择仍然是 C原因是性能可控、STL 丰富、评测环境支持最成熟。Python 能做很多题但在大数据量和多次提交的高压场景下性能常数会成为变量。我当时的备赛环境是操作系统Windows / Linux 双环境 IDEVS Code C 插件 编译器g 11 及以上 调试工具gdb、ASAN 地址检查 对拍脚本Python 3 随机数据生成器建议提前安装 ASAN不开玩笑。比赛中数组越界或者未定义行为有时候本地看不出来但评测机直接判 Runtime Error。用 ASAN 跑一遍很多隐蔽错误在赛前就能暴露。3.2 准备一套“读入输出模板”竞赛输入规模经常大到 cin/cout 直接超时。提前写好快速读入能避免比赛期间临时改 I/O。#include bits/stdc.h using namespace std; using ll long long; ll read_int() { ll x 0, f 1; char c getchar(); while (!isdigit(c)) { if (c -) f -1; c getchar(); } while (isdigit(c)) { x x * 10 (c - 0); c getchar(); } return x * f; } int main() { int n (int)read_int(); vectorll a(n); for (int i 0; i n; i) { a[i] read_int(); } // 业务代码 return 0; }这段代码不是为了炫技是为了让输入环节完全“无脑”。比赛时你的注意力应该放在算法推导上而不是思考为什么cin在 10^6 级别数据上会卡。3.3 模板库按模块整理复盘的另一个重要发现是模板不能只收藏要按模块整理成自己熟练使用的版本。常见的模板模块包括快速幂、最大公约数、扩展欧几里得并查集、树状数组、线段树最短路、最小生成树、拓扑排序二分查找与二分答案动态规划常见状态压缩写法字符串哈希与 KMP每个模板都要能默写不能到比赛时再去翻笔记。4. 比赛过程回放做题节奏与提交策略比赛过程是遗憾发酵的地方。回头看整个时间线可以分为四个阶段。4.1 读题阶段发题之后先花 10 到 15 分钟把所有题目的题面、数据范围、输入输出格式扫一遍。不要急着写代码。目的有两个找到“简单题”和“难题”的分布。识别哪些题有部分分哪些题必须全部 AC。这一步做得好后面就不会出现“最后才发现某道题数据范围小到可以暴力过”的意外。4.2 抢分阶段先用最快速度写完最有把握的题拿到保底分。这个阶段的原则是复杂度允许就写最稳的写法不要一上来就优化。比如数据范围 n 100 时三层循环只要常数不大就可以先过。与其把时间花在写花式优化上不如先拿到分再考虑性能。4.3 攻坚阶段进入中后期开始处理中等难度的题目。此时最容易出现的问题就是样例过了逻辑似乎也对但提交后分数不涨。这背后往往不是算法思路问题而是实现细节存在隐藏错误。4.4 检查阶段最后留下的时间不应该是“再写一题”的时间而应该是“重新验证已有代码”的时间。我在这场比赛里犯的最大错误就是压缩了检查阶段把时间投给了一道还没推导清楚的新题。结果是新题没写出来旧题还有一个边界错误没发现。5. 技术失误复盘三个“差一点”的代码问题这是整篇文章最值钱的部分。遗憾不是抽象的情绪它可以被定位到具体的代码行。5.1 二分查找的溢出问题有一道题需要二分答案我当时的二分写法是int l 0, r 1e9; while (l r) { int mid (l r) / 2; if (check(mid)) { r mid; } else { l mid 1; } }看起来没问题但当 l 和 r 都很大时l r可能超过 int 范围造成整数溢出mid计算出错误值二分直接进入死循环或者返回错误答案。更稳妥的写法int mid l (r - l) / 2;这个错误在本地小数据上根本测不出来。大样例下如果评测机比较严格就会超时或者答案错误。这是个很典型的“熟悉代码陷阱”。二分写了几百次反而最容易在细节上翻车。5.2 动态规划数组初始化遗漏另一道题是线性动态规划状态转移本身没想错但初始化阶段漏了一条路径。vectorvectorlong long dp(n 1, vectorlong long(m 1, -1)); dp[0][0] 0;转移的时候写了if (dp[i - 1][j] 0)但是某个边界状态下dp[i - 1][j]根本没有被正确更新导致后续状态全部继承错误值。这类问题在赛后对拍时一眼就能看出来可在比赛现场我会因为“思路太顺”而跳过验证。5.3 输入输出没有按题面要求处理还有一道题题面要求输出到文件output.txt我默认输出到了标准输出。本地自己写测试工具时重定向覆盖了这个问题提交后才发现输出没有被评测程序读到。这类问题不是算法问题是“读题细心度”问题。这也是竞赛中最可惜的失分方式代码逻辑完全正确但因为输出通道不对一题白做。6. 与第一名的差距从失分结构反推能力短板赛后我拿到排名和部分题目得分之后做了一次“失分拆解”。这里不写具体分数只写结构。失分类别可能对应的代码问题改进方向样例过提交错边界情况未覆盖、整数溢出、未初始化变量造极端数据、使用 ASAN、对拍大数据超时复杂度误判、常数过大估算数据范围、提前设计时间复杂度输出格式错文件读写、多组数据格式、空格换行读题时标记 I/O 要求调试时间过长缺乏系统 debug 方法使用二分定位法、对拍脚本把自己与前两名的差距简单归因于“别人更强”是最舒服的逃避方式。但拆开看很多失分点是可以提前训练的。如果赛前我能多做两轮极端数据测试至少可以把那几处边界问题提前暴露出来。比赛里没有“如果”但赛后复盘里有。7. 时间与精力管理竞赛里的“性能瓶颈”比赛时长通常在三到五小时之间。这个时间跨度约等于一个 4 小时的压力任务。如果把它类比成一个线上服务你的“CPU”和“内存”就是注意力和短期工作记忆。7.1 时间分配建议前 15 分钟不写代码只读题。前 60 分钟拿保底分处理简单题。中间 90 分钟集中火力处理中等题。最后 60 分钟优先检查已提交代码剩余时间再开新题。我的问题出在最后 60 分钟。我选择开新题而不是检查旧题。结果新题没写完整旧题的边界问题也交了上去。如果按照“先检查后开新题”的顺序结局大概率不一样。7.2 精力分配建议连续编码超过 45 分钟后错误率明显上升。这个不是心理作用是注意力资源被清空了。建议每完成一道题就站起来接杯水换个思路再进入下一道。大脑需要一点切换时间硬顶反而容易让后续代码出现低级错误。7.3 评测机差异很多新手会忽略一个变量本地机器和评测机器不一定同性能。本地跑 0.05 秒的数据在评测机上可能跑 0.2 秒。如果时限只有 1 秒多出的 0.15 秒可能就是超时和通过的差距。判断复杂度时不要只看“我觉得能过”而是用数据范围最大构造一组数据在本机跑一遍时间再留出 2 到 3 倍余量。8. 赛后排错把对拍和边界测试变成习惯比赛结束后不要立刻陷入情绪应该立刻进入“赛后排错模式”。最有效的排错方法就是对拍。思路是用暴力程序作为基准用随机小数据反复对比优化版的输出。# 生成随机小数据 python gen.py input.txt # 跑暴力版本和优化版本 python brute.py input.txt out_brute.txt python fast.py input.txt out_fast.txt # 对比输出 diff out_brute.txt out_fast.txt对拍的价值不是证明程序“能跑”而是证明程序在大量不同输入下“结果一致”。我赛后对比赛中的几道题做了对拍找出的问题比比赛现场一小时的肉眼排查更多。更关键的是这些问题全都属于“可以提前暴露”的类型。边界测试也很有用。每一道题写完后不要只跑样例要额外测试n 0 或 n 1最大值和最小值数据全部相同数据呈单调递增或递减输入包含多组数据时的分割格式这些边界不是错觉是后端评测时必然存在的输入形态。9. 下轮训练的重构用回归测试心态做复盘一场比赛结束了不代表训练目标应该结束。我认为最好的方式是把比赛当成一个“预发布版本”排名只是线上指标真正重要的复盘是找出 bug 与回归问题。9.1 每场比赛写一份复盘记录记录每道题的读题时间思路推导时间编码时间调试时间提交结果失败原因有了这份数据你能知道自己卡在哪一步。不是“这道题不会”而是“读题花了 20 分钟”“边界验证花了 2 分钟”。9.2 错题重做只记录不复盘等于白记录。一周后重新做错题如果能独立 AC才算真正掌握如果还是卡就要拆出具体卡点。9.3 准备一个可复用的代码仓库用 Git 管理模板和复盘代码。每个模块分目录例如templates/、contests/、notes/。mkdir -p algorithm-notes/{templates,contests,notes,scripts}这种方式让每次训练都能沉淀为资产。等到下一次比赛前你不需要重新翻几百个网页只需要打开自己的仓库快速过一遍模板和错题记录。10. 总结把遗憾当作一次回归测试全省第三这个名次从外部看是一块不错的敲门砖但从内部看是一次非常具体的回归测试失败。失败不在“算法能力不够”而在于稳定性不足边界没测、输出没复查、时间分配不合理、对拍没有成为赛前习惯。这些都不是无法修复的能力缺陷它们是完全可以通过训练习惯解决的技术问题。如果现在回到那次比赛我不会在倒数十分钟继续优化新题而是会打开已交的代码逐一看边界条件把每个数据范围的最小值和最大值都跑一遍。这是我用自己的名次换来的教训。它比拿第一更深刻也让我后来写代码、做项目、改 bug 的时候多了一个本能反应先怀疑再提交。建议所有正在备赛的读者把“样例过”从“完成”的定义里删掉。真正的完成是极端数据过、对拍过、复杂度确认过。第三名的遗憾说到底是“差一次验证”的遗憾。