企业官网建设流程全解析

2020年那届团体程序设计天梯赛，我是真没想到自己最后会坐在电脑前，以线上方式打完全程。更没想到的是，比赛结束后对照榜单复盘，我发现自己丢的分里，有将近三分之一不是"不会做"，而是"会做但踩了坑"。这篇文章就是围绕那场比赛的完整复盘：每一类题的核心思路是什么，哪些地方特别容易想当然，以及我们在赛后整理出来的易错点清单。无论你是打算第一次参赛的选手、还在带队的学长学姐，还是想找点算法题练手的同学，这份复盘应该都能帮你少走一些弯路。

我把题目按实际难度和花费时间重新梳理了一遍，写的时候不会只丢一句"这题用XX算法就能过"，而是把"为什么我会先想到错的方向""卡了多久""最后怎么绕出来"都讲清楚。毕竟题解的价值不在答案本身，而在那个从WA到AC的思考过程。

1. 赛制、分值分布与开赛前我最后悔没做的事

1.1 这届比赛的节奏：三档难度不是"各做各的"

团体程序设计天梯赛的题面分三档：基础题、进阶题、压轴题。很多人第一次打的时候，会下意识把三档题目当三条平行线：基础题是热身，进阶题是主力，压轴题是给大佬准备的。实际上这届比赛打下来，我最大的感受是——三档之间是互相渗透的，基础题里埋着进阶题的思考量，压轴题的某些子问题，其实就是基础题的变形。

举个例子，开头几道基础题里有一道是"按规则处理一个队列"，看起来只是模拟，但如果把数据量放大到极限，普通链表操作会超时，必须用环形队列或者双端队列来优化。也就是说，比赛刻意把"会做"和"能拿分"分开：思路谁都能想到，但只有注意到数据范围的人才能拿满分。这一档题的分值看似不高，却是整场比赛的胜负手，因为基础题不允许丢分。

1.2 队伍分工与"拿分优先"策略

我们队赛前定的策略很简单：前四十分钟，十个人全部扑在基础题上，一个人负责扫读全部题面并标记"哪几题表面上难、实际有巧劲"，另外九个人按熟悉度分区块拿分。这个策略来自之前几次模拟赛的教训——总有队友看到压轴题描述很炫，忍不住一头扎进去，结果半小时后颗粒无收，基础题还被别人抢了先。

实际比赛的时候，这个策略起到了很大的作用。基础题里有几道题是典型的"读题陷阱"，比如要求输出保留几位小数、要求补上前导零、要求按字典序而非输入顺序输出。如果不是专门有一个人提前把这类要求圈出来，我们至少会多交几次罚时。队伍十个人不是各写各的，而是先花五分钟对齐题面里的坑，再分散动手。这一点，我觉得比任何算法知识都重要。

1.3 环境、提交时限和心态准备

说一个赛前最容易被忽略的准备工作：编译器版本和提交反馈。天梯赛的评测环境是统一的，但本地环境不一样，有的队友用新版编译器，有的用旧版，结果代码在本地能过、提交后编译错误。我们因为这个问题白送了一次罚时。更坑的是，某些题目的评测机对栈空间有限制，递归写深了直接爆栈，而不是给你超时提示。

心态上，我最后悔的是没有提前模拟"长时间连续思考"的节奏。三个小时的比赛，不是三个小时连续高强度思考，而是九十分钟全神贯注加九十分钟咬牙坚持。后半程的题目往往不难，但脑子已经转不动了，这时候比拼的是前期有没有留下缓冲时间。后来复盘我们队的提交记录，后期通过的题占比明显偏低，不是不会，是累了。

2. 基础题里藏得最深的几个坑：模拟、字符串与边界条件

2.1 模拟题的"排队逻辑"——插队和离队到底该怎么建模

这届比赛的开场题里，有一道模拟题我印象特别深。题面大意是这样的：一群人排队，中途会有人插到某个位置，也会有人因为等不及直接离开，最后要求输出队伍里的编号序列。数据范围不大，但操作次数很多，如果你真按"每插入一次就移动后面所有人"去写，最坏情况下会变成O(n^2)，提交上去直接超时。

这里的易错点第一层是：你会不会意识到需要链表。第二层更隐蔽——有些同学用数组模拟链表，但忘了维护尾指针，导致输出的时候要从头遍历一遍，复杂度没问题，却因为在插入时没处理边界情况而WA。我当时写的就是数组模拟双向链表，结果在"插到队尾"这个分支上写错了指针更新顺序，整整卡了二十分钟。

后来和队友讨论才发现，这类题目最好的建模方式是：数组模拟的双向链表 + 哨兵节点。哨兵节点不仅能简化"空表"和"插到队首队尾"的判断，还能让输出循环的判断条件变得统一。我后来把这种"加哨兵"的思路套用到其他好几道题上，屡试不爽。通过这一题我想说的核心是：模拟题不是靠蛮力，靠的是"用数据结构把规则翻译得更简单"。

2.2 字符串处理：读整行、拆分、空串的连环坑

字符串题是每届天梯赛基础题的常客，2020年也不例外。有一道题要求解析一行输入里的若干字段，按特定分隔符拆分后再做处理。乍看很简单，但坑全在输入处理上：如果直接用某些语言里的按空格切分函数，遇到连续的多个空格，切出来的数组里可能有空字符串，然后你就莫名其妙多了一个字段。

这类题还有一个经典易错点：行末可能有换行符，且换行符之前可能有回车符残留。很多选手在本地测试时没注意，因为编辑器自动处理了，但提交后第一个测试点就WA。我当时的做法是，先读一整行，手动去掉末尾的不可见字符，再按分隔符拆分，最后过滤空串。这段代码看起来多写了三四行，却能把输入相关的坑一次排干净。

另外一个容易忽略的是输出格式。字符串题里经常要求"每个结果占一行"或者"行末无多余空格"，如果题目要求每组输出之间有空行，而最后一组之后不能有多余空行，这个边界能让人WA到怀疑人生。我的经验是：在处理输出前，先想清楚"最后一个元素"和"最后一次循环"的判定条件，而不是在循环体里临时补救。

2.3 一段真实排查记录：从TLE到AC的环形优化

我清楚记得有一道题，题目本身不难：给定一个数组，反复做某种区间操作，求最终的某几个值。我第一版用最直接的循环模拟，本地跑了几个小案例全过，提交后第2个测试点TLE。这时候我才回头看数据范围，发现最坏情况下的操作次数是百万级别，而每次操作又要遍历整个数组，肯定不行。

排查过程是这样的：先把循环里的所有操作打上时间戳，用一个十万级的数据跑本地测速，发现单次操作大概需要几十毫秒，乘上操作次数，总时间轻松超过评测时限。接着我试着把"每次遍历"改为"预处理前缀信息"，让单次操作变成O(1)查询，重新提交后从TLE变成了AC。这道题的教训有两条：第一，看到题目先看数据范围再动手，这是老生常谈但永远有人忘；第二，本地测速不能只跑小样例，要按极限数据生成一组测试，才能暴露复杂度问题。

说到前缀信息，我顺便补充一种很常用的思路：如果操作是对某个区间整体做加减或求最值，优先考虑差分数组和前缀和，而不是线段树。区间问题在基础题和进阶题的边界上经常出现，差分数组写起来简单、排错容易、常数小，是完全够用的。

3. 进阶题的贪心与数据结构：思路对了一半，离AC还差一口气

3.1 贪心题为什么不能只靠直觉排序

进阶题里头几天大家讨论最多的是一道贪心题。题目大意是：有若干任务，每个任务有开始时间和结束时间，选择尽可能多的任务，并且要给选出来的任务排一个执行顺序，要求不能冲突。这题百分之八九十的人第一反应是"按结束时间排序"，这个思路本身是对的，经典的区间调度问题确实是这么解的。

但易错点在于：题目额外加了一个条件——任务之间可能还有依赖关系，或者某些任务的执行时长不是由开始和结束时间决定的，而是一个固定耗时。加了条件之后，"按结束时间排序"就不再是最优策略了。我在赛场上想着"这题我见过"，五分钟后写完提交，WA在最开始的两个例子上，那一刻我才意识到题面里那个额外条件不是摆设。

这类题的正确打开方式应该是：先忽略额外条件，用经典贪心验证一遍；然后构造一个能让经典贪心失效的反例，看看额外条件到底改变了什么决策依据。如果经典贪心会选A而最优解选B，那就是额外的判断维度没有纳入排序关键字。我们队后来总结的规律是：贪心题永远不要急着写排序，先想清楚"每一步决策到底在比较什么"。

3.2 并查集与优先队列：怎么一眼识别该用哪把工具

进阶题里还有一类是数据结构题，最常出现的两把工具就是并查集和优先队列。并查集的识别点很明确：题面里出现"连通""分组""合并""判断两个元素是否属于同一集合"这类字眼，八成就是并查集。但有个坑是并查集题常和离线处理结合起来，比如先给出一堆合并操作，再在某个时间点查询状态，如果没注意到"离线"而硬做在线更新，就会把自己绕晕。

优先队列的识别点则是另一个方向：题面里出现"每次取最大""每次取最小""前K个""最值动态变化"，基本就是在暗示堆。我自己的经验是，优先队列题最难的不是"用堆"这个结论，而是"堆里存什么"。有些题存的是数值本身，有些题存的是索引+数值，还有些题要存负值才能模拟取最大。想清楚堆元素的含义，代码反而简单。

针对2020年那届的题目分布，我要提醒一点：进阶题经常把两个数据结构缝合在一起。比如题目会先让你用并查集维护若干集合，然后把每个集合的最值扔进优先队列，最后再取全体最值。如果你的思维只停留在"一题一数据结构"，这种缝合题就会让你发懵。本质上，它们是在考你"工具的组合能力"，而不是考单工具的熟练度。

3.3 完整WA->AC排查链路：一个反例引发的"推倒重来"

我详细复盘一道我们队卡得最久的进阶题。题面需要维护一组集合，支持合并以及查询当前所有集合中某个指标的最大值。我先按直觉写了两层循环的版本，样例通过，提交后WA在第8个测试点。由于看不到具体输入，我决定自己构造一批能触发问题边界的用例。

构造思路是这样：第一组测试只做合并，不查询，检查合并逻辑；第二组测试每次合并后都查询，检查查询时机；第三组测试人为制造"空集合"，检查空集合是否被错误统计进了最值。三次测试下来，问题立刻暴露——我在合并时没有判断两个元素是否已经在同一个集合里，导致集合大小被重复累加，最终最值算错。

排查手段上，我最推荐的是"内存打点法"：在关键变量变化的地方打印当前值，跑一遍小数据，手算一遍期望值，然后把两者对着看。这个方法很简单，但比debugger还常用。另一个意见是：如果WA在比较靠后的测试点，多半是某个边界条件触发，而不是整体思路错。这时候不要重写代码，先用极值参数构造测试，绝大多数情况下能找到原因。

4. 压轴题怎么开局：DP状态设计和图论建图的取舍

4.1 先写暴力，再谈优化：DP题的递推方向

压轴题部分，最典型的一道动态规划题，我记得题面是某种路径计数方案，要求路径上不能经过某些格子，还要对结果取模。很多选手一看"路径计数"就直接开DP，这没问题，但容易在状态定义上犯错。有人用二维数组表示从起点到(i,j)的方案数，却漏掉了"不能经过某些格子"对当前格子的影响。

我自己的做法是：先写一版最暴力的DFS，把暴力结果打印出来，再手推几个小用例验证暴力是否正确。暴力对了之后，再看暴力递归里的重复子问题在哪里，把"从(i,j)出发到终点的方案数"提取成状态，天然得到记忆化搜索。记忆化搜索写顺了，再决定要不要转成递推。这个方法比一上来就硬推递推公式要稳妥得多，因为递推公式写错的代价是整个思路全错，暴力转记忆化至少每一步都能验证。

这道题里还有一个很大的易错点：取模运算。路径方案数可能很大，题目要求对某个质数取模，但选手在计算的过程中，如果先做减法再取模，可能会得到负数，必须加模数修正。我们队就有队友在这里丢了分，因为本地测试的结果看起来"差不多"，实际差了一个符号。

4.2 图论题："建图方式"比"跑什么算法"更决定生死

另一道压轴题是图论题，我当时一眼看上去觉得像是单源最短路，刚准备写Dijkstra，再读一遍发现边权并不是直接给出的，而是取决于当前节点的某种状态。这种"边走边算边权"的图论题，最关键的步骤是状态扩展：把原始图里的每个节点，根据状态拆成多个节点，再在新图里跑最短路。

我说的这一题，易错点在于"同一个物理节点在不同状态下对应的编号"。很多选手在拆点的时候搞混了映射关系，导致最短路算法跑出的结果张冠李戴。我记得我们队的做法是：写一个函数，输入节点编号和状态，输出拆点后的新编号；所有出入边的更新都必须通过这个函数，绝不手写硬编码。这种方式虽然多写几行，但排错效率和正确率都明显提升。

压轴题的另一类常客是"最小生成树的变体"。如果题面里既涉及连通性又涉及边权最小化，而且图可能不连通，那么先判断连通性、再跑最小生成树、最后检查是否能覆盖所有节点，这个顺序不能反。我见过有人直接把不连通的情况当作生成树权值为0，这显然是理解错了题意。图论题的得分关键，真的就是"先把图建对"。

4.3 优化落地：滚动数组与大常数优化

压轴题的最后一个技术点是优化。DP题如果状态是两维的，数据范围一大，空间就会爆。这时候很多人会想到滚动数组，但滚动数组有个隐蔽的坑：如果转移需要依赖上一轮的多个位置，直接滚动会导致新旧数据混在一起。解决方法是，在每一轮更新前，把上一轮的数据备份一份，或者调整遍历顺序，让每个状态只依赖本轮之前已经计算好的部分。

大常数优化我就不多说了，只说一点：在时间勉强够的情况下，把vector换成长度固定的数组，效果立竿见影。评测机对动态内存分配的惩罚，在压轴题里会被放大。2020年那届的压轴题，就有那么一两道题纯粹是卡常数，算法写对了但实现太"豪华"也会TLE。

另外图论题的邻接表存储，我建议直接开一个足够大的边数组，不要用vector<vector >这种方式。后者写起来方便，但访问时多一层间接跳转，百万级边的情况下速度差异很明显。如果读者平时习惯了用STL容器，至少要在比赛前适应一下"能用数组就不用容器"的写法。

5. 赛后复盘的五个教训，比多拿50分更值钱

5.1 输出格式少看半行，10分直接蒸发

赛后对照题面逐字看，我们队有一道题就是因为输出格式翻车。题目要求每两组样例输出之间用一个空行隔开，我写成了每组输出后都跟一个空行，结果最后一组后面多了一行空白。这种错误在本地几乎看不出来，因为评测机的文本比对是严格的，多一个空格、多一个换行都会判错。

我的建议是：读题的时候，只要看到"输出格式"四个字，就把它当成一道独立的题来处理。可以在草稿纸上画一个输出模板，标清楚哪些地方是空格、哪些地方是换行、哪些地方条件是"除了最后一行"。等代码写完之后，再回头检查一遍输出分支，尤其是"最后一组"和"第一次"这两个边界。

5.2 变量范围与极端数据：0、1、n=1、最大值的检验

几乎每场比赛我们都能在极端数据上翻车，2020年也不例外。有一道题我至今记得，n的最小取值可以是0，我在代码里对n=0的情况没有单独处理，结果数组越界直接RE。后来我们队定了一条规矩：每道题提交前，至少构造四组极端测试——n取最小值、n取最大值、所有值相等、没有可行解。

有些选手觉得构造极端测试浪费时间，但我可以用亲身经历告诉你，这五分钟能省下的罚时往往更多。尤其是RE和WA，往往不来自正常数据，而是来自"空输入""单元素""满边界"这种极端情况。记住一个原则：评测机永远比你想的更会刁难人。

5.3 团队节奏：罚时是团队的事，不是个人英雄主义的事

在团队赛里，罚时是比解题数更隐蔽的胜负手。我们队最终排名和另一支队伍非常接近，仔细一看差距就来自罚时：他们提交次数比我们少了几次，尽管答对题数相同，排名却在我们前面。罚时这个东西，一个人乱抢会影响全队的净用时，所以提交前的自查环节绝对不能省。

我特别想强调一个协作细节：在队友不确定自己的代码是否正确时，别急着提交，让另一个队友帮忙跑一遍极端测试，再一起检查输出格式。这看起来是"浪费"了双倍的时间，实际上避免了多次罚时，而且两个人一起排查的纠错能力远远高于一个人。比赛后半段的沟通效率，经常就决定了最后一小时能多拿多少分。

5.4 把WA原因分类整理，形成错题集

赛后我做了一件很有价值的事：把全队所有的错误提交拉出来，按原因分成"边界条件""输出格式""复杂度超限""读题遗漏""数据范围溢出"五类。一统计，发现接近一半的错误是"读题遗漏"，也就是看漏了题目里的某个限制条件。这个比例远超我们原本的想象，也直接改变了后续的训练重点。

从那以后，每次模拟赛或正式比赛，我都会在结束后的当天写一篇简短的错题总结，重点记录"我为什么错"而不是"题怎么做"。这种反思式的整理，对长期进度的帮助非常大，比再多刷几道题更有效。如果你也在准备算法竞赛，我真心建议你也试一次这种分类复盘，你会发现自己的坑集中在某些固定类型上，知道了坑在哪，才谈得上避开。

5.5 最后分享一个关于"比赛当天的食物与休息"的经验

听着有点跑题，但这确实是很多队伍忽略的。2020年的线上赛要求全程在线，三个小时对脑力和体力的消耗都很大，结果我们队里有两个人中午没怎么吃东西，后半程明显反应变慢，简单的二分边界都要想半天。如果你要参加类似的长时间算法竞赛，建议提前准备好高蛋白、易消化的干粮，并把饮水安排在手边，这三个小时里尽量别起身太久。

还有一个小习惯：比赛开始前，按自己平时的作息时间，上一次厕所。听起来很琐碎，但真到了后半程，多一次离座就可能打断思路。这些细节很难在题解里看见，但我会说，比赛的结果从来都不只是算法能力的比拼。

关于2020年那届天梯赛的复盘，我能写出来的核心经验就这些：基础题要当进阶题对待，贪心题先构造反例再排序，压轴题先把图建对再想算法，赛前一定要规划好输出格式检查和极端数据测试。希望这份复盘里的易错点，能帮你避掉一些我当年踩过的坑。