考研复试机试C/C回顾每年复试季总有学弟学妹问我机试到底怎么准备、难度如何、该刷哪些题。说实话机试这东西不像笔试那样背一背就能过它考察的完全是另一套能力——短时间内的代码实现、调试、还有临场心理素质。我自己当年备考的时候踩了不少坑也总结了一些真正有用的经验这篇就完整回顾一下。如果你正在准备复试机试或者对C/C机试心里没底这篇文章应该能帮你在有限时间内走最稳的路径。我会从整体策略、环境准备、核心考点、实操技巧到常见问题全部展开讲清楚。1. 项目概述与思路拆解1.1 考研机试到底考的是什么很多同学把机试当成笔试的延伸用复习笔试的思路去刷概念题、背诵知识点这是最大的误区。机试本质上是在模拟“给你一个明确任务、限制时间、要求你写出可运行代码”的工程场景它考察的是你能否把算法想法快速转化为实际代码并且能够正确运行、结果无误。说得直白一点笔试考察“你是不是知道这个知识点”机试考察“你能不能把事情做出来”。这也是为什么很多笔试高分的同学在机试翻车——他们熟悉复杂度分析、能默写算法流程但到了真机环境里连scanf和cin的混用导致输入异常的问题都排查半天。不同学校的机试形式不完全一样但主流无非几种单题限时一般是60到90分钟完成1到2道题、多题限时2小时内完成4到6道题、OJ平台评测全程黑盒跑数据不看你代码风格只看结果。最要命的其实是OJ平台评测这种因为这意味着你的代码必须一次通过所有隐藏测试用例任何一个边界条件考虑不周都会让你这道题直接零分。所以我当时的备考策略就是从一开始就当自己在OJ平台上做题严格按格式、严格想边界、严格测极端数据。平时养成习惯考场上才不会慌。1.2 为什么C/C是机试的主力语言这其实是个很现实的问题。虽然现在Python也很流行算法题写起来还快但在考研机试场景下C/C依然是绝对主力。原因有几点第一几乎所有高校的机试环境都预装C/C的编译器无论是Visual Studio还是Dev-C还是Code::Blocks都原生支持C和C不需要额外配置解释器。而Python环境在某些弱网或不提供外网的考场里反而不一定预装或者版本很老容易出幺蛾子。第二C的STL标准模板库简直是机试神器。vector、stack、queue、set、map、sort、next_permutation、priority_queue这些容器和算法能省掉你大量造轮子的时间。两道同样难度的题用C写STL可能30分钟搞定手写数据结构的C版本可能要50分钟差距是非常明显的。第三机试判题对运行时间有硬性要求。C/C在OJ上的运行速度比Python快很多这意味着同样是O(n log n)的排序算法C能过Python可能就被卡超时了。在复试机试这种短时间内要出结果的场合C/C能提供更大的容错空间。当然我不是说Python完全不行——如果你的目标院校明确说了支持Python或者你自己就是Python特别熟练、C/C薄弱那也可以考虑。但一般来说除非有明确信息否则老老实实用C/C是风险最低的选择。1.3 备考时间线是怎么规划的机试备考最怕的就是“不知道考什么、不知道练什么、不知道该练多久”。我根据自己的经验给一个比较通用的时间线参考复试前8到12周主攻基础功底。重点是C/C语法死角、STL常用容器、经典算法模板排序、二分、双指针、栈和队列、二叉树遍历等。这个阶段不用限时先把每道题吃透。复试前4到8周主攻OJ刷题。每天保持2到3道题的节奏严格按照OJ的输入输出格式。这个阶段要开始限时训练单题控制在40分钟以内。复试前2到4周主攻模拟套题。找目标院校的历年机试题或者类似的模拟套题按考试的真实时长连续做题培养连续编程的耐力和心态。复试前最后1周主攻查漏补缺。把之前的错题、容易犯的错误、常用模板的代码全部过一遍。不要再死磕难题保持手感即可。这套时间线不一定适合所有人但“基础阶段—刷题阶段—模拟阶段—巩固阶段”这个方向是对的。最忌讳的是从第一天就盲目刷难题导致基础不牢后期越刷越虚。2. 环境准备与关键工具选型2.1 机试环境早知道不要最后一天才去适应机试失败的最冤情况就是平时用得顺手的IDE到考场上被限制或者根本没预装。所以信息收集阶段有一个必须做的事想尽办法弄清楚目标院校的机试环境。最常见的几类环境我列一下Dev-C 5.11很多高校的机房老古董界面朴素但稳定、启动快对标准C/C支持没问题。如果你平时用VS Code提前熟悉一下Dev-C的调试功能会很有帮助不然考场上按F9没反应都不知道去哪设置编译选项。Visual Studio部分学校用功能强大但缺点是对标准兼容性细节要求高且启动重。要特别注意VS默认会启用“安全开发生命周期”检查scanf、strcpy这种老牌函数直接报C4996错误需要加预处理指令或者改用scanf_s。这就有个坑——平时在VS上写scanf_s写得顺手到了OJ平台编译器不认这个函数直接编译错误。Code::Blocks轻量、跨平台对标准支持好部分Linux机房和Windows机房都有。纯Linux环境 vim/gcc极少数学校会这么干。如果你目标院校是这个路子提前练命令行gcc编译和gdb基础调试不然到考场连怎么编译都不知道。我备考时拿到的最关键信息就是目标院校用Dev-C 5.11 C11标准于是前期直接用Dev-C训练到后期基本不看其他IDE。提前匹配环境省了很多无谓的适应成本。2.2 编译器和标准的选择C和C虽然经常放在一起说但考试的时候你最好明确自己写的是哪个。选C就按C99/C11的标准写选C就按C11或C14的标准写最怕的就是混合写代码看着能过但某些老编译器会有诡异行为。给大家几个实战建议其一如果用C优先使用C11或更高标准因为C11带来的auto、unordered_map、emplace_back这些特性确实能节省时间。但注意不是所有学校的环境都支持C14或C17保守起见C11是最大公约数。其二如果用C就尽量避免C99以后才有的特性。比如在代码块中间声明变量有的学校编译器用C89模式可能直接报错。最稳妥的方式是全部在函数开头声明变量这是C89风格在任何编译器下都能编译通过。其三一定要知道自己用的编译器默认的编译选项是什么。Dev-C里默认可能不是-stdc11你要在【工具—编译器选项】里手动加上。我在模拟测试的时候就吃过亏写了一个C11特性代码本地没问题换了台测试机器直接编译失败就是这个原因。2.3 刷题平台怎么选绝大多数机试题目本质上是标准OJ题。所以你平时训练的刷题平台越接近考试环境越好。比较推荐的平台有三类第一类是目标院校自有的OJ平台一般在校内可以访问上面有历年的机试真题这是最最最重要的复习资料。如果搞不到历年题也尽量找学长学姐打听题目的风格、难度、题型分布。我当时就是通过学长给的回忆版题目大概知道了出题人偏好爱出图论和模拟题复习就有了重点。第二类是主流刷题网站比如各类OJ上的入门到进阶题库按难度梯度刷。不过我建议不要随机乱刷最好按考点分类刷每个考点集中练这样能够在有限时间内快速覆盖多个高频题型。第三类是带比赛/模拟功能的平台这类网站有些会有周赛、月赛限时排名跟考试的紧张感比较接近。我在临考前几周参加了若干场模拟赛虽然排名一般但限时做题的感觉真的和平时散刷完全不一样对心态帮助很大。3. 核心考点与高频题型分析3.1 考察频率最高的几类题目根据我收集的多所高校机试信息和自己的考试经验机试题目无论怎么变化核心考点基本集中在以下几个方面。第一大类是模拟题。给你一个实际问题场景让你照着规则一步步做。这类题考察代码组织能力和细节处理能力往往不涉及高深算法但对逻辑严谨性要求极高。比如“给定一个日期求它是星期几”“模拟一个银行排队系统”“实现一个简易计算器”。很多同学在这种题目上翻车不是因为不会做而是因为“差不多就行了”的代码经不起推敲。第二大类是经典数据结构和算法题。栈和队列的运用、链表的操作、二叉树的前中后序遍历、图的深度优先和广度优先搜索、最短路径Dijkstra和Floyd、最小生成树Prim和Kruskal、排序算法、二分查找、动态规划入门问题。这里想特别强调动态规划是很多学校的高频压轴题。从背包问题到最长递增子序列再到区间DP基本是必考重点。第三大类是字符串处理题。字符串逆转、子串查找、模式匹配、大数运算高精度加减乘除。这种题目看着简单实际写起来很考验基本功特别是C语言风格的字符数组处理很多人C的string用得飞起但一遇到字符数组就gg其实两种写法都要熟练。第四大类是数学题。质数判断、最大公约数和最小公倍数、快速幂、大数取模、进制转换、排列组合。这些题数量不算多但一旦出现往往是拉分题因为代码量不大但思路要清晰。第五类是文件读写类型。某些学校会直接在题目里要求从文件读入、写出结果而不是从标准输入读。这个细节如果你没注意代码写出来可能本地运行完全正常但在OJ上就是零分。所以备考时一定要养成看题目输入输出说明的习惯。3.2 每个高频考点的应对策略模拟题的核心策略只有一个仔细读题提取所有规则用数据结构去映射现实场景。比如银行排队问题看上去是个复杂场景但抽象出来就是队列的操作。这种题只要理清规则代码并不难写。建议是先在草稿纸上画一个流程再动手写代码不要边写边想规则很容易漏。二叉树和图的遍历是必拿分题。DFS和BFS两种写法要达到“肌肉记忆级”的程度不需要思考就能敲出来。特别是DFS很多题目都是它的变体比如迷宫问题、岛屿数量问题、N皇后问题全都万变不离其宗。我自己的训练方法是把DFS和BFS的模板默写十遍以上直到在任何条件下都能快速、准确地写出来这比刷十道新题更管用。DP题目是区分度最高的一类。掌握DP的关键是三步第一步定义状态第二步写状态转移方程第三步初始化边界条件。很多同学卡在“不知道状态怎么定义”上我的建议是以背包问题为例反复看状态转移的推导过程——为什么是前i个物品在容量j下的最大价值把这个理解透了很多DP题的套路都是一样的。字符串处理要特别注意空串、空格、大小写、越界问题。C风格字符串的结尾标志是\0很多错误的本质就是忘记给字符串末尾留位置。比如你要拼接两个字符串char s[100]但实际读入的字符串长度可能已经超过99再加上\0就直接缓冲区溢出。这类“隐蔽Bug”在OJ评测里非常吃亏。数学题看起来很唬人但实际上考的都是固定套路。质数判断用试除法到sqrt(n)就够最大公约数用辗转相除法快速幂用二进制拆分思想高精度加法用数组模拟竖式。这些模板我建议全部提前准备好考场直接用而不是临时推导。3.3 拿高分必须养成的习惯边界条件与极端数据我见过很多代码算法思路完全正确但一提交就是Wrong Answer。最后排查发现问题全出在边界条件上。这是机试中最普遍、最可惜的丢分点。边界条件常见的有这么几类空输入。如果输入行数为0程序应该怎么处理很多人的代码会对空输入做非法操作直接崩溃。最小值和最大值。当n1m1数组只有一个元素时代码是否还能正确运行负数。题目说“整数”到底包不包括负整数如果包括你的排序、求和、动态规划初始化是否考虑了负数的情况大数溢出。int最大值约21亿如果你求的是累加和、累乘积可能早就超了int范围要用long long甚至字符串处理。重复元素。排序时相同元素怎么处理查找时出现多个结果输出哪个有些题目会明确要求输出最小下标你没注意就错了。应对边界条件最好的方法就是每个题写完之后设计几组极端输入实际跑一遍。比如一个排序题试试n1的输入、全相等元素的输入、已经排好序的输入、完全逆序的输入。这几组数据跑通了这个题的正确率就比较稳了。4. 实操过程与核心环节实现4.1 输入输出那些“坑”一次统清楚机试的输入输出格式是很多考生最大的痛。我自己也在这一块严重吃过亏这里详细讲透。首先是循环读入的问题。OJ题目常见的输入格式有几种第一种是固定数量的输入比如“第一行输入n接下来n行每行两个整数”这种直接读n然后循环n次就行。第二种是不告诉你数量要求一直读到文件尾EOF这个时候要用while(cin x)或者while(scanf(%d, x) ! EOF)的写法。这两种读入方式差别很大一旦判断错很容易陷入死循环或提前退出。其次是输出格式的严格性。OJ评测机对比输出时通常忽略行末空格但对空行和多出的空格很敏感。题目要求“两个数之间用一个空格分隔”那最后一个数后面就不要再额外地输出空格了。我的习惯是先输出第一个数从第二个数开始前面加空格判断条件用 i 0 来控制。再有一个很关键的坑换行。很多题目会特意说明“每组输出占一行”或者“每个输出之间用一个空行隔开”。有没有那个多出来的空行评测结果完全不同。所以每次写完代码对样例输入多跑几遍仔细检查组与组之间的空行是否和题目描述一致。最后字符串的输入最坑。scanf不能读入带空格的字符串要用gets或者cin.getline但gets在C11标准里被移除了会报警告cin.getline又容易和cin混用之后出现遗留换行符的问题。我有一个百试不爽的组合方案C风格的输入全部用cin处理字符串需要读整行时用getline(cin, s)。关键是注意如果你前面用了cin n后面马上用getline(cin, s)getline会先读到一个空行因为输入缓冲区里还留着上次输入结束时的换行符。解决办法是在cin n之后加一句cin.ignore()把这个换行符吞掉。4.2 C和C混用如何安全避开雷区很多学校机试允许C和C二选一但也有不少同学为了图方便两个混着写这极其容易出问题。最典型的就是cin/cout和scanf/printf混用。在C里cin和scanf有各自独立的缓冲区机制如果你一会儿cin一会儿scanf输入顺序就可能错乱。正确做法是要么全部用C风格cin/cout要么全部用C风格scanf/printf。考试时统一一种风格可以省掉大量无谓的调试时间。个人建议如果题目以字符串处理为主用C风格string类和相关的查找、拼接函数会省很多事如果题目以大量数字读入为主用C风格scanf/printf确实效率更高、格式控制更灵活。但要记住选了就要一用到底。还有一个常见的踩坑点C的bool类型在printf中不能直接输出true/false要用%d输出1/0。有些人觉得无所谓但在输出“YES/NO”这类要求时千万不要自作聪明地用printf(%s, bool变量)会直接输出空字符串。我自己的一个习惯是写C代码时主力用cin/cout但遇到需要控制小数位数时用printf搭配%.2lf这是C和C之间为数不多的合理混用因为cout的格式控制代码有点啰嗦。当然用cout就更统一的方案是iomanip头文件里的setprecision和fixed但语法相对复杂一些容易写错。4.3 常用算法模板考前直接背下来机试时间紧张现场推导模板非常浪费精力。我建议把以下模板提前整理成自己的代码库考前默写几遍保证随手就能完整写出来。排序模板可以手写快速排序或归并排序但更推荐直接调用sort复杂度和正确性都有保障。注意sort在C里默认升序如果要降序写法是sort(a, an, greaterint())或者自己写一个比较函数。二分查找模板这是最容易写错的重要模板。核心是while (left right)时mid怎么取、边界怎么移动。我分享一个我用了很久的模板查找第一个大于等于target的位置或者查找最后一个小于等于target的位置这两种变体建议分别整理清楚考试时直接套。DFS模板void dfs(参数) { if (递归出口) { 处理结果; return; } for (枚举所有选择) { 做选择; 标记; dfs(下一层); 撤销标记; } }BFS模板用queue存储当前层状态while循环层序遍历。核心是visited数组防重复入队否则会死循环。二叉树遍历模板前序、中序、后序递归三件套不过大多数机试更常用的是层序遍历BFS以及根据前序中序重建二叉树这类题目。这个重建逻辑是典型的高频考点建议写一遍吃透。图的最短路径模板Dijkstra算法用优先队列优化是必背内容复杂度O((VE)logV)在稀疏图上表现非常好。Floyd算法代码极其简单就三层循环适合稠密图的任意两点最短路但要注意k在最外层顺序错了就全错。最小生成树模板Prim算法适合稠密图代码比Kruskal稍简单Kruskal是边集排序并查集如果题目给的是边的集合Kruskal更快逻辑也更清晰。并查集模板顺手背下来很多题都能用上。动态规划模板背包问题的经典写法、最长公共子序列、最长递增子序列、最大子段和。这些题目代码量不大但要么状态转移方程写错要么初始化不对。建议考前逐个过一遍确保思路和代码完全一致。高精度计算模板高精度加法、减法、乘法、除法。机试有时候会考大数阶乘或者大数斐波那契这类题目只要模板熟练基本是送分题。4.4 实战案例全流程拆解从读题到AC我拿一道典型的模拟题来做全流程演示这个题目差不多是复试机试里出现过的难度。题目给定两个正整数a和b求ab的值。输入第一行为数据组数T接下来每行两个整数a、b输出每组数据的ab每组输出占一行。听起来太简单了对吧但就这么简单的题也有人会写错。我们走一遍完整流程第一步读题。明确输入的第一行是T不是直接两个数。很多人上来就读a、b忽略T输出会直接错位。第二步确定数据范围。题目说正整数没说大小稳妥起见用long long存储避免a和b都接近int上限时相加溢出。第三步确定读入方式。既然是T组数据那就cin T然后循环T次。第四步确定输出格式。每组输出占一行中间不要多空行。代码写出来是这样的#include iostream using namespace std; int main() { int T; cin T; while (T--) { long long a, b; cin a b; cout a b endl; } return 0; }看着是不是很简单但有三个细节需要注意一是long long的格式说明符如果用scanf是%lld很多人写成%d就直接错二是while(T--)这个写法很常见但要确认T不会被后面代码改变三是最后return 0虽然C不写也能过但养成了规范习惯总是好事。第二步测试边界数据。我试着输入T1a和b都为0虽然题目说正整数但你不知道出题人的数据是否严格测试边界无妨程序输出0正确。输入一个特别大的数比如2147483647和2147483647程序输出4294967294没溢出正确。如果T3但实际只给了2行输入呢程序会少做一次循环然后停止不会崩溃——这也是处理非法输入的一种隐式方案。第三步提交前检查变量类型。如果这道题换成a、b的范围是10的100次方那long long也不够就得上高精度加法模板了。这也能看出来简单题背后也一样考察基本功的厚度。5. 考试中的高效Debug与心态管理5.1 入门级调试手段打印大法很多同学平时依赖IDE的断点调试觉得挺好用但到了机试考场时间紧、代码量大有时候反而觉得断点调试太慢。我自己最常用的其实是打印法printf调试法。具体操作就是在关键节点输出临时变量的值看是否符合预期逐步缩小错误范围。比如对于一个DFS迷宫问题我会在每次进入新格子时输出坐标和方向用来确认状态转移是否正确。对于一个动态规划问题我会在每次计算完dp[i][j]后打印dp数组的前几行检查状态转移是否有明显异常。这个技巧虽然土但效率极高尤其在OJ判题不告诉你错在哪一组数据的时候打印法能帮你快速定位逻辑错误。但注意两个坑第一打印调试代码在提交前必须全部注释或删除不然会多输出干扰信息直接被判格式错误第二打印语句本身可能有副作用比如printf调试时不小心将循环变量放在输出里改变了值导致本来正确的逻辑出错。所以调试完记得仔细检查。5.2 经典Bug排查清单机试中最浪费时间的其实是低级Bug。这里整理一份高频Bug排查清单遇到问题按清单顺序排查数组越界尤其是字符串处理字符数组长度不够导致后面数据被覆盖。死循环while循环条件写错或者循环变量没更新。浮点数比较涉及浮点数相等判断时不要直接用要用fabs(a-b) 1e-9。类型溢出int和long long混用时强制转换要写在运算之前。漏掉头文件比如使用memset时没包含cstring使用sort时没包含algorithm编译直接报错。文件名和类名有的学校要求以Main命名主函数入口或者提交时用特定文件名注意看考场说明。中文输入法残留写代码时如果中文标点符号混进去编译会报错排查时先看光标附近的字符。这个清单不是一次就能记住的建议每次做题遇到报错就把自己的低级错误记到笔记里考前集中看一眼非常有效。5.3 时间分配与心态策略机试的节奏感非常重要。我的建议是拿到题目后先花5分钟把所有题都看一遍心里对整个难度有数哪些是稳拿分的哪些是需要花时间的哪些是实在不行可以放弃的。这样分配时间的时候才有的放矢。一个常用的时间分配策略是3-2-1法则第一题如果简单争取15到20分钟内拿下把状态打出来后面的中等题每题控制在25到35分钟如果卡住超过10分钟就果断换题回头有时间再来补最后留足10到15分钟检查全部提交代码的编译情况。考场里最忌讳的是跟一道题死磕。我见过太多人花了一个小时怼一道动态规划结果后面两三道简单题完全没时间写最后还不如把简单题全部拿下的人分数高。机试最终比的是总分不是一道题的最优解。还有心态问题。机试环境里面所有人都是独立做题屏幕上有倒计时旁边有键盘声本来就很紧张。我在模拟测试的时候专门培养过“不受干扰”的能力无论旁边的人敲得多快、翻页多频繁我都专注在自己的题上。这种定力靠临时调节不现实平时就要练。5.4 提交前最后的检查流程每次提交代码前我建议按固定流程走一遍这个流程能拦住90%的粗心错误。第一步确认读题是否正确输入格式、输出格式、大小写、空行和题目描述一字一句重新对一遍。第二步确认编译无误在Dev-C上按F11编译运行或者在命令行g编译确保没有warning和error。有warning也值得注意虽然能跑但有时候warning背后就是未定义行为。第三步测试样例一定跑通外加边界数据。如果题目给出样例样例通过只是及格线边界数据才是保障。第四步删除调试代码提交。提交后如果被判错误第一时间回头看题目有没有理解偏再根据错误类型缩小范围。如果是Runtime Error大概率是数组越界或除零如果是Time Limit Exceeded考虑换更高效算法或优化常数如果是Wrong Answer先在本地跑边界数据如果是Presentation Error检查输出格式的空格空行。这个检查流程看起来简单但很多人漏掉了“样例通过并不等于正确”这一点。OJ评测有多个隐藏测试点只要有一组边界数据不过就是零分。考前一定养成测试极端情况的习惯。6. 常见问题与避坑实战6.1 编译报错的那些雷编译报错是最容易解决的因为编译器会告诉你错误行号和原因。但有些报错信息初学者完全看不明白我列几个常见的。比如expected ; before }多半是前面少了个分号或者花括号没配对。这种要顺着代码往上一行一行看不要只看报错那行。再比如invalid conversion from int to int*这是类型不匹配问题常见于数组名和指针的混用。还有reference to left is ambiguous的报错多半是因为你的变量名和库函数命名空间冲突换个变量名就好。我实战中遇到最匪夷所思的报错是代码在VS上编译通过换到Dev-C就报错。后来发现是VS用了微软特有的头文件或扩展语法。所以考前务必统一编译环境或者至少养成在两种环境都编译验证的习惯。6.2 运行无误但答案错误怎么排查如果程序编译通过、运行不崩溃但提交判Wrong Answer这说明是逻辑层面的问题。我的排查步骤是第一步重读题目确认是否遗漏了某些条件。很多Wrong Answer其实源于读题漏了某个关键字比如“升序”还是“非降序”“正整数”还是“非负整数”。第二步为代码设计几组简单的手工测试数据一步步跟踪计算结果。小数据可以手算核对程序输出是否一致。第三步检查排序条目的比较逻辑尤其是排序规则是自定义的很容易出现比较函数写得不对导致排序结果不符合题意。第四步检查状态数组或标记数组是否重置干净。多组数据输入时上一次计算留下来的脏数据会让下一组结果算错。这个问题极其常见解决办法是在每次循环开始时全部清零或重新初始化。第五步检查变量是否重复使用。比如在两个循环里都用同一个变量i但外层循环修改了内层循环的循环变量导致结果错乱。这个可以靠“每个循环尽量使用不同变量名”来规避。6.3 超时TLE的优化思路很多人在机试中遇到Time Limit Exceeded就慌其实优化思路是有固定套路的第一步检查算法复杂度。如果题目n范围是10的5次方而你写了O(n²)的暴力算法一定会超时。这时候要换思路比如改用二分、前缀和、双指针或者使用哈希表。第二步检查输入输出效率。用cin/cout时如果没有加上ios::sync_with_stdio(false)和cin.tie(0)大数据量时会比scanf/printf慢很多。我之前实测过加上这两句之后cin的速度可以和scanf接近。注意这个优化对C的流输入输出非常有效强烈建议写代码时统一加上。第三步检查是否有多余的重计算。比如一个值在循环体内反复计算且不变提到循环外面就能节省大量时间。第四步检查剪枝是否做到位。搜索类题目DFS和BFS不剪枝和剪枝的差距是指数级的。这些优化不一定每次都能救回来但大部分TLE问题都可以通过这些手段解决。6.4 考前一周的“保温”操作考前一周最重要的事情不是刷难题而是保温。每天保持一定的代码手感。我考前一周的安排是每天固定做2道简单题和1道中等题时间控制在1小时左右。简单题用来保持手感和自信心中等题用来巩固模板。做完之后重点看错题和笔记把所有容易犯的错误再默读一遍。此外考前要把高频模板完整抄写一遍快速幂、并查集、Dijkstra、DFS、BFS、DP背包、高精度加法。抄写不是为了背诵是为了熟练。考试时即使不能完整默写也知道关键逻辑在哪里哪怕推导一下也能快速恢复。还有一个细节如果考场允许带纸质资料把整理的模板打印出来带进去会安心很多。但注意提前确认考场规则有些学校禁止有些学校允许别因为这种小事影响了状态。7. 复试机试的加分项与经验总结7.1 代码规范比你想象的更重要虽然OJ评测不看你代码风格但复试机试不完全是机器评分。部分学校会在机试之后安排面试环节面试官会翻看你写的代码考察你的思路和编程习惯。所以平时就要养成写注释的习惯关键函数、关键变量的含义写清楚核心逻辑用注释标注出来。如果面试环节被问到你代码里的某个细节注释能帮你快速回忆当时的思路。另外函数命名和变量命名尽量做到见名知意。不要写a、b、c这种无意义的变量名哪怕是为了省时间网上阅卷和面试时观感很差。用sum、cnt、visited、dp这样有语义的名字不会多花太多时间但能看出一个程序员的基本素养。7.2 机器评测之外的“隐藏规则”有些机试系统是实时显示的你的每次提交都会被记录代码运行时间、内存消耗等指标都会呈现在测评页面上。面试官可能会看你的提交次数和首次AC时间。如果你反复提交十几次才通过会给面试官留下“调试能力一般”的印象。所以平时刷题就要争取低提交次数训练自己在提交前把代码检查到位。还有一个小规则如果你的代码被评测系统评测失败可能是编译错误、超时、错误、运行错误等不同状态。不同的判题系统对相同错误的分类命名可能不同但大体一致。考前务必搞清楚目标院校所用的OJ系统的错误提示含义不然看到“Rejected”就茫然无措浪费时间。7.3 复试机试的保守策略与得分思维机试拿分有一些通用的策略掌握住之后可以提高整体得分率。策略一难度跳跃式做题。先把所有题都看一遍从最简单的开始做保证每道题都有得分记录。有些同学喜欢先做难题结果卡住后情绪崩溃简单题也没做好得不偿失。策略二部分分思维。即使一道题不会做完整解法也可以尝试暴力解法拿部分分。很多OJ平台对暴力解法会有一部分测试点能通过能得一分是一分。策略三如果题目明确区分了多个子任务优先完成最容易的子任务。比如“第一问必答第二问选答”先把第一问稳稳拿下再考虑第二问不要从后往前做。策略四考试最后5分钟不要写新题全部用来检查已写代码。检查所有提交是否都已确认、文件名是否符合要求、代码中是否有调试残留。7.4 最后留一句实在话机试这个东西本质上拼的是熟练度和细节把控能力。聪明不聪明反而排在后面。你花在刷题上的每一分钟都不会白费只要策略正确、环境熟悉、模板在手、心态稳住绝大多数人的机试成绩都会对得起自己的付出。我到现在还记得自己考场上那道题——我用了十分钟等紧张感过去然后按平时的节奏一道一道做下去全程没有去关心别人的屏幕。这种专注的状态靠的就是平时的限时训练。如果你正在备考希望这篇回顾能帮你少走一点弯路。把基础打牢把模板备好把边界条件想全把环境提前适配好剩下的就是相信自己。考场上的那几个小时终究会变成你研究生生涯第一道跨过去的门槛。