CarrieYung刚看到“清华机试题目大概思路2C2176cjbPidK4FBABgmeBe7B3A”这个标题时，我愣了一下，后面带着的那串随机字符串明显是某个网盘或分享链接的ID，不是题目内容本身。但“清华机试”这四个字才是重点——这是很多计算机方向学生在保研、考研复试阶段绕不开的一道门槛。
我这些年陆陆续续带过不少学弟学妹准备这类上机考核，自己也下场考过几次，最深的体会是：清华机试拼的不是你会不会写代码，而是你在有限时间内能不能把思路快速落成能跑的代码。平时刷LeetCode那套“想清楚再写”的节奏，在机试里会害死人。这篇就把我总结的机试应对思路和实操教训写透，从题目怎么出、怎么拆解，到考场上的时间分配和容易翻车的细节，一次性讲清楚。
1. 机试考核的本质：不只是算法题，是限时生产代码的能力
很多人第一次接触清华机试，会以为它和ACM校赛或者LeetCode周赛差不多，找个安静角落把算法想明白、把代码写漂亮就行。实际考过一轮就明白了，差别非常大。
1.1 考试环境与评分机制决定了策略
从往年的经验看，清华机试一般给3小时，3到4道题，全程在离线环境下用本地IDE写代码，最后统一提交评测。评分不是人工看代码，而是黑盒评测：你把源码提交上去，评测机用预设的测试数据跑你的程序，比对输出结果。评测数据中有样例，也有大量你根本看不到的边界数据。
这意味着什么？意味着你提交的是一份可执行行为，不是一份代码文档。代码风格好不好看不重要，注释写没写不重要，甚至算法是不是最优雅的也不重要——只有“能否在时限内通过尽量多的测试点”这一条标准。
另外要注意，环境一般支持C/C++、Java、Python。我个人的建议是：如果你备战时间充足，就锁定C++，不要今天用Python明天用Java。机试这个场景下，C++的优势在于STL体系完整、速度可控、对底层内存边界理解更直接，历年考生的“主流武器”也是它。Python虽然写起来快，但大数据的题容易TLE，而且递归深度、自带的性能瓶颈在压力测试下会让你吃大亏。
1.2 从“会做题”到“会得分”的思维转变
LeetCode式的训练特别容易让人养成“解法洁癖”——觉得每个题都必须想出一个理论最优解才配写代码。机试完全不是这个逻辑。拿到一道题，你有几个选择：
- 想出正确算法并完整实现，拿满分；
- 算法不完整，但用暴力/部分算法通过部分小数据点，拿部分分；
- 没思路，但能读懂题目，写一个特殊case的处理，拿个别测试点的分。
机试是按测试点给分的，不是按算法难度给分的。哪怕最后你只写出了暴力搜索，只要能在超时之前跑完小数据，就有收入。这套“得分思维”必须提前建立，否则考场上遇到不会的题，很多人会直接卡死，死磕一道题导致后面全崩，这是最大的失误。
我看过太多这样的考生：平时在OJ上能把难题AC，但机试里第一题（通常是签到题）因为输入格式读不对，白白浪费了40分钟；或者第三题想复杂了，其实一个带剪枝的DFS就能过一半数据。这都不是能力问题，是备战思路没转过来。
1.3 机试题目难度分布：为什么前两题才是命根子
从历年回忆版题目来看，清华机试的构成一般遵循“1道签到 + 1道简单应用题 + 1道中档题 + 1道压轴题”的格局，或者干脆就3道题，一次拉开梯度。签到题往往是字符串处理、简单模拟、算术推导，有竞赛经验的人10分钟内能搞定；简单应用题考的是基础数据结构和基础算法，比如树的遍历、最短路、背包DP、并查集这类；中档题会嵌套一些思维，常见的有“图论模型转化”“区间DP优化”“贪心证明”；压轴题则可能是综合题，或者需要较为冷门的算法技巧。
关键结论：你能不能让机试分数稳住的锚点，是前1到2道题。签到和简单应用加起来能拿到的分数，通常占到40%到50%。把这两个题又快又稳地做对，压轴题随便拿个暴力分，就能立于不败之地。所以后面所有的实战思路，都是围绕“稳保中低档题 + 争取高档题”这个策略展开的。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 近五年高频考点：它们用什么姿势反复出现
我在准备机试和带人准备时，会把历年题目回忆版按考点归类。归类之后发现，清华机试的题目范围其实没有网上传的那么“变态”，它有很明显的高频区。下面这份总结不是从大纲里抄的，是我对着几十套真题回忆一点一点统计出来的。
2.1 高频考点统计表
| 考点大类 | 出现频率 | 常见出题姿势 | 对应突破口 |
|---|---|---|---|
| 模拟与字符串处理 | 极高 | 时间格式转换、指令解析、短信文本还原、压缩解压 | 读题后先画状态转移，用while+switch拆步骤 |
| 动态规划 | 极高 | 背包类、最长递增子序列变体、区间合并、树形DP | 先写递推关系，再想空间优化，不要一上来就想滚动数组 |
| 图论 | 高 | 最短路变体、最小生成树、拓扑排序、连通块 | 先确认图的规模，再选邻接表或邻接矩阵 |
| 数学推导与数论 | 中高 | 最大公约数/最小公倍数、取模循环、质因数分解、快速幂 | 数学题往往代码短，关键是推导，不要硬编码找规律 |
| 基础数据结构 | 中高 | 栈与队列应用、优先队列模拟、并查集合并、哈希映射 | 注意容器的去重规则和比较器写法 |
2.2 从一道“签到题”看清华风格的出题偏好
网上有一道流传很广的回忆题，大致内容是：给定一个日期和一组“工作日/休息日”规则，计算某个任务需要多少天完成。看起来是个日期计算题，但它加了一层“跳过节假日”的逻辑，所以很多人做着做着自己就绕进去了。
这种题的考点有三个：闰年判断、月份天数表、循环推进日期。你说它难吗？不难。但它就是能在一场机试里干掉30%的人，因为大家一上来就想着用现成库函数，比如C++里算日期间隔直接调mktime，结果本地调试正常，提交评测时因为时区/环境差异出错。
我的处理思路非常固定：
- 自己手写一个日期推进函数，用“天数表 + 闰年判断”一格格推，不要用系统库。
- 把所有规则先翻译成判断题，再循环里逐日判断，而不是试图搞什么“跳过N个节假日”的高效算法。
- 边界条件先用题目给的样例验一遍，再自己构造“跨年”“跨闰年”“第一天就是节假日”三个用例。
这道题如果放到赛场上，理想用时是15分钟以内。它考察的不是你懂不懂“蔡勒公式”，而是你在压力下能不能把繁琐但明确的逻辑拆分清楚。
2.3 压轴题真正在考什么：模型转换能力
中低档题检验的是基础牢不牢，压轴题检验的是你能否把陌生问题翻译成熟知模型。我印象里有一道回忆版真题，题干讲的是“多个城市之间有物流线路，每个城市有货物供求，求最小运输成本”，看起来像供应链优化，但本质上就是一个带边权上下界的费用流或者最小费用最大流问题——只不过它用一个物流故事包装起来了。
很多人在考场上看到大段背景描述就先慌了，觉得没学过供应链，其实你不需要懂供应链。机试的压轴题，绝大多数都能映射到经典算法模型。真正拉开差距的，是这种“剥掉叙事外壳、看到算法内核”的能力。这个能力靠什么练？靠平时有意做“抽象化训练”——拿到任何一道生活化/工程化背景的题，先问自己三个问题：
- 谁是节点，谁是边，边的权重代表什么？
- 这个约束条件对应算法里的什么限制？
- 如果是求最值，我能不能用二分答案 + 判定函数的方式转换？
压轴题不需要你AC，你只需要用模型转换拿一部分分，就已经赢过绝大多数人了。
3. 考场上的标准解题流：从读题到提交的五步法
这是我每带一个人都会反复灌输的流程。它不是那种“先想清楚再动手”的鸡汤，而是每一步都有明确的产出物和耗时控制的实操方法。
3.1 第一步：3分钟扫题定策略
拿到题目的前3分钟绝对不要动键盘。先把四道题全部快速读一遍，像浏览新闻标题一样。你在这一轮的目标不是解题，而是回答以下问题：
- 哪些题描述短、没有复杂背景，适合先做？（通常是签到和简单应用）
- 哪些题的输入输出格式很特殊，需要额外小心？
- 哪些题的数据范围特别小，比如n ≤ 20，暗示可以用搜索/状压/暴力？
- 哪些题的背景故事很长，但实际可能只是模拟？
扫完之后，在草稿纸上给题目排个顺序：第一题、第二题……这个动作我建议全程控制在3到5分钟，不要恋战，也不要因为某道题看起来眼熟就立刻开写。
3.2 第二步：用数据范围反推复杂度
选定一道题后，先看输入数据范围，再倒推你允许的复杂度。这个反推表我贴在显示器边上，也建议你记死在脑子里：
| 数据规模 | 允许的近似复杂度 | 常见算法 |
|---|---|---|
| n ≤ 10 | O(n!) | 全排列、状压搜索 |
| n ≤ 20 | O(2^n) | 状态压缩DP、子集枚举 |
| n ≤ 100 | O(n^3) | Floyd、区间DP、三重循环 |
| n ≤ 1000 | O(n^2) | 双层循环、朴素DP |
| n ≤ 10^5 | O(n log n) | 排序+二分、线段树/树状数组 |
| n ≤ 10^6 | O(n) | 单调栈/队列、线性筛 |
举个例子：如果题目说n最多10万，你就该条件反射般地知道暴力O(n^2)必炸，必须上O(n log n)或O(n)的解法。如果题目说n最多15，你却执着地写了一个复杂的贪心，那叫杀鸡用牛刀，还可能因为贪心证明不完整而翻车——这种数据规模下直接暴力枚举加剪枝，又快又稳。
3.3 第三步：先写结构骨架，再填算法
很多人一上来就从头往下写#include <bits/stdc++.h>然后立刻进入核心算法，这是效率极低的开法。我建议倒过来：先把整个程序的骨架搭出来——数据读入部分、数据结构定义、主流程的注释框架。也就是说，你还没写具体逻辑的时候，程序已经能编过、能跑，只差核心代码块。
这样做有三个好处。第一，你通过“写读入”这个动作，强迫自己看清了输入到底是单组还是多组、是空格分隔还是换行分隔、有没有字符串中带空格的坑。第二，你提前把数据结构定下来，后面写核心逻辑等于填空，不容易写着写着发现自己变量类型不对。第三，一旦中途卡住，你至少有个“半成品”在，几分钟后还能回来接着填，不至于清零重来。
具体骨架可以长这样：
cpp复制#include <bits/stdc++.h>
using namespace std;
// TODO: 定义数据结构
struct Edge { int to, w; };
int main() {
ios::sync_with_stdio(false);
cin.tie(nullptr);
// TODO: 读入数据
// TODO: 核心算法
// TODO: 输出结果
return 0;
}
别小看这个骨架。它是你思维的外置硬盘，帮你把焦虑分散到一个个已规划好的“TODO”里。而且考场上的紧张情绪会严重压缩工作记忆，骨架就是给工作记忆减负的。
3.4 第四步：用样例验证，但绝不依赖样例
很多机试提交系统的“样例解释”都带有误导性，样例覆盖不到边界。我见过的翻车案例里，至少有40%是样例本地全过，一交就零分。原因基本是下面几种：
- 只按样例格式写了输出，没考虑多个测试点之间要不要空行；
- 样例输入只有一组，忽略了题目明明写了“多组输入”；
- 数组开得太极限，评测机的栈/内存环境和本机不同；
- 用了
endl代替'\n'，导致大数据量下超时（不要笑，真的有人这么挂）； - 浮点数比较用了
==，而不是fabs(a-b) < 1e-9。
所以我的原则是：样例只是用来快速验证程序“通路通不通”，真正决定通过率的是你自己构造的测试用例。拿到题的第一时间，在草稿纸上先画几个边界用例，比如n=0、n=最大值、字符串为空、全是同一个字符、图是环/链/不连通——等程序写完，立刻把这些用例灌进去。这一套组合拳下来，至少能帮你规避掉60%以上的提交失误。
3.5 第五步：留出15分钟的收尾检查时间
这个习惯救过我很多次。无论如何，离考试结束还有15分钟时，我要求自己必须停下手上的所有代码，回到代码区从头到尾做一遍“提交前检查”。检查清单是固定不变的：
- 所有变量的初始化和清空逻辑对不对？多组数据的循环里，上一组留下来的状态有没有clear干净？
- 数组开的大小够不够？注意有些题下标从1开始，数组大小要开n+5而不是n；
- 所有输出语句的分隔符和换行符和题目描述逐一比对；
- 有没有临时调试输出没删干净，比如
cout << "debug: "这种？ - 有没有题目没要求但你自己加的输入提示？
int是否该换成long long？求和的中间结果会不会爆？
这个检查环节不需要动脑，但需要心细。机试不是比谁做得快，是比谁少犯错。我见过太多人在最后一个小时里狂写代码，结果最后十分钟交了一个带着调试输出或者数组越界的程序上去，前面的努力全部清零。
4. 最容易翻车但没人在考前提醒你的六件事
很多人备考机试，把全部精力放在“算法题刷得够不够多”上，却忽略了环境、习惯、工具链这些同样能决定成败的细节。整理几个我从考场里带出来的血泪经验。
4.1 本地的“正常”和评测机的“正常”不是一回事
不同OJ和评测环境的C++标准、栈空间限制、甚至sizeof(int)都可能不一样。有一种非常恶心的场景：你在本地VS或Clion里跑得好好的，代码在Release和Debug模式下结果都对，一上评测就爆栈——原因很可能是评测环境里Linux的默认栈只有8MB，而你在递归里开了大数组。
应对办法有两个方向。一是训练自己写递归函数时注意“栈深度”，DFS超过十万层就该考虑手写栈或非递归写法；二是关键的递归题，尽量把大数组开成全局变量，不要开局部变量——全局变量在数据段里，不占栈空间，这个习惯在机试里能帮你躲过一半以上的“本地好、线上爆”问题。
4.2 STL很强，但别在关键路径上过度依赖
STL的封装能救你于水火，priority_queue实现Dijkstra、unordered_map做离散化、vector当动态数组，都是常规操作。可一旦数据量上到百万级别，STL的常数开销就会变成压死骆驼的最后一根稻草。这不是让你不用STL，而是让你要知道“什么场景该自己写，什么场景直接调”。
高频考点里的最短路、最小生成树，如果数据规模在十万量级，priority_queue版Dijkstra完全够用。但如果数据是百万量级，建议换成自己手写的邻接表 + 手写堆，或者干脆用SPFA的优化版试试——不要迷信任何算法，拿到题先看数据范围再决定容器和数据结构。
4.3 输入输出同步关不关：一道保命题
C++的cin/cout很方便，但在没有关闭同步的时候，消耗的时间是scanf/printf的数倍。大数据量的题目里，这个差距足以让一个正解直接超时。所以我的默认写法是：
cpp复制ios::sync_with_stdio(false);
cin.tie(nullptr);
这两行代码基本是保命级的。但我得提醒一句：一旦关了同步，你就不要混用cin和scanf。混用会导致输入顺序错乱，那个bug极其难查，而且往往在你最紧张的时候出现，心态直接崩。
4.4 多组数据：清洗比处理更关键
题目里只要是“多组输入”，恭喜你，你遇到了一个隐藏陷阱。常见的多组数据写法是while (cin >> n)或者while (scanf("%d", &n) != EOF)，大多数人都知道。但下一次循环的时候，你上一组数据用的全局变量、STL容器、标记数组清干净了吗？
我有一道印象特别深的题，连续两组测试，第二组的图不连通，但因为我的vis数组没重置，把第二组不该访问的点当成了已访问，直接导致一个连通块算成了两个。后来我在代码里养成了一个强制习惯：所有“每组数据都要重新初始化”的内容，统一封装成一个init()函数，在每组数据读入前调用。不要依赖自己“记得”去重置，要依赖机制去重置。
4.5 int和long long：不要在这个问题上赌
你可能觉得int最大值21亿，一般数据足够用了。但机试题目有个规律：样本数据总是喜欢出到int的边界，尤其是“求和”“动态规划”“最短路距离累加”这种场景。两个int一加就溢出，溢出的结果是负数或者随机值，你本地测小数据根本看不出来。
备战的期间就养成一个习惯：只要题面里出现的值域上限超过10^9，或者存在累加、相乘的操作，就直接用long long，不要贪图节省那4个字节。除非题目明确说了最终结果在int范围内，否则默认long long。
4.6 调试代码：提交之前必须清零
我见过最惨痛的翻车，不是算法写错了，而是代码里留着一行cerr << "当前i = " << i << endl;的调试输出。cerr在本地会显示在终端，但在评测系统里会被当作标准错误流——虽然有的评测系统不会把stderr算进答案，但一旦它混到了stdout里，就是爆零。
强烈建议提交前做一次全文搜索，搜cout、cerr、printf、debug这几个关键词，人工确认每一条输出语句都是题目需要的结果。
5. 上考场前两周的冲刺方案：不是刷得越多越好
这个冲刺计划是我带过好几轮人之后固定下来的一套打法，它不是从“算法知识体系”出发，而是从“应试状态管理”出发。你可能已经刷了很多题，最后两周再刷一千道新题毫无意义，反而会让自己陷入“我怎么还有这么多不会”的焦虑。你要做的是把状态调到“稳定能发挥”的档位。
5.1 前十天：用“限时套题”代替“无限制单题”
从考前十天开始，每天固定抽出一整个下午，完全模拟考场状态，设好倒计时3小时，连续做4道题。做的时候注意：
- 关掉手机和所有消息提醒；
- 不允许中途查题解，也不允许翻自己的笔记；
- 就算是做不出来的题，也必须硬扛满时间，至少把暴力分写出来；
- 结束铃响之后，再花半小时给自己复盘：哪些题花了太多时间？哪些题是因为读题不仔细？哪些是手滑/细节错？
限时套题的价值，不是让你多做四道题，而是锻炼你对“时间压力”的适应力。很多人平时单刷神勇，一到限定时间就手心冒汗、思路中断，这就是缺少模拟训练。第一次模拟可能考砸，但没关系，连续三天之后你就会发现自己的节奏感明显不一样了。
5.2 倒数第五天到第三天：回归模板与代码库
到了这个时候，不要再碰难题怪题了。把精力放在“模板默写”上——不是背代码，而是确保自己能在10分钟之内无错地写出以下这些高频模板的骨架：
- 二分查找及二分答案
- DFS和BFS的两种写法（递归/栈/队列）
- Dijkstra（邻接表+优先队列）
- 并查集的路径压缩+按秩合并
- 快速幂和矩阵快速幂
- 背包九讲里的一维滚动数组版（01背包）
- 线段树的建树/单点更新/区间查询（这个如果时间不够可以只复习区间最值版）
我见过太多人，平时觉得模板都会，考场上因为紧张写出了find函数没用路径压缩的并查集，或者Dijkstra的更新条件写成>，花半小时都查不出错。模板默写的目标就是把这种低级失误在考前清零。
5.3 最后两天：不要再做新题，做减法
最后两天我会让自己干三件事：第一，把所有做过的错题翻一遍，只看思路不重写；第二，把上面那份模板清单再默写一遍，确保肌肉记忆还在；第三，准备好考试要用的环境，比如确认代码编辑器里的默认缩进、字体大小、自动补全开关——别小看这些，一个你熟悉的编辑器能让你少一分焦虑。
最后一天晚上，不碰任何代码。做点轻松的事，早点睡觉。机试是脑力活，熬一个大夜能让你的反应速度下降百分之三十。省下那一夜的时间去多刷两道题，远不如保证一个清醒的脑子划算。
5.4 关于心态：允许自己有一道题不会
每次考前，我都会跟人强调一句话：这道考试不是一个“全部都会”的考试，是一个“尽力多拿分”的比赛。清华机试的压轴题本来就是用来区分顶尖高手的，你切不出来太正常不过了。关键是你在面对“不会”时的决策：是死磕半个小时继续零收益，还是立刻转去做前面没写完的题、把该拿的分都拿稳？
从分数角度考虑，答案是明显的。一道压轴题你死磕半小时未必能写出正解，但这半小时如果用来复查前面的题，找到一处数组越界或者清空遗漏，很可能就值回10到20分。这笔账，考前一定要算清楚。
6. 三道典型题的思路复盘：从读题到AC的完整决策链
最后用三道我反复拿出来当教材的真题风格题，完整走一遍上面的流程，让你看到“思路”不是玄学，而是一套可以复用的决策链。
6.1 题目一：物流分拣模拟
题面大致是：有一个仓库，货物按编号依次到达，每个货物有目标区域。操作员按指定顺序扫码分拣，但有一个缓冲区只能放一件货物。问一系列操作后，是否所有货物都到了正确区域。
考点：栈/队列模拟 + 条件判断。
我拿到题先干三件事：确认n的范围（如果n ≤ 1000，那随意模拟都行；如果n ≤ 10^5，就要确保模拟过程是O(n)），确认输出格式（是“YES/NO”还是“Yes/No”，这个真的会有人因为大小写被卡），再确认有没有“多组输入”。
思路直接一条链走：把所有操作读进来，按顺序执行。缓冲区用栈模拟，目标区域用哈希表映射。需要注意的边界是“缓冲区已经满了但还要往里面放货物”和“操作结束后缓冲区还有货物没处理完”。
这题没有任何算法难度，考察的就是你能不能快速把文字描述转成状态机。很多人卡在没有把“缓冲区只能放一件”这个条件翻译成“任何时刻栈的size不能超过1”，代码写得很长很乱。这就是抽象能力不够的表现——练习方向应该是画状态转换图，而不是背代码。
6.2 题目二：会议安排优化
题面：给你n个会议的开始时间和结束时间，每个会议室同一时间只能开一个会，问最少需要多少个会议室。
考点：贪心 + 优先队列（或差分数组）。
这题是“会议室II”的换皮，网上刷过LeetCode的应该秒懂。思路其实很标准：按开始时间排序，用一个小根堆维护当前正在开的会议的结束时间。每来一个新会议，先看堆顶的会议是否已经结束，如果结束就弹出；然后新会议入堆。整个过程中堆的大小的最大值就是最少需要的会议室数量。
这题想要考倒你，会在输入格式上做文章，比如时间用“HH:MM:SS”给出来，需要先转成秒数才能比较。转格式不要用sscanf的“%d:%d:%d”直接碰运气，我习惯自己写一个解析函数，逐位读、逐位转换，明确控制边界。这样虽然多写几行，但稳。
另一个变体是“会议不能重叠且所有会议都要召开，求最多能选择多少个会议”，那就是经典的“按结束时间排序 + 贪心选取”问题。考场上看到“最多能安排多少个”，条件反射地想到按结束时间排序；看到“最少需要多少个会议室”，条件反射地想到堆。这种条件反射不是玄学，是刷题量堆出来的。
6.3 题目三：括号生成变体
题面：给定n对括号，求所有合法的括号组合，但增加一个限制，任何时候前缀中左括号数量减去右括号数量的差不能大于k。
考点：回溯/DFS + 剪枝。
这种题同样是换皮。核心思路还是经典的“回溯生成括号”，加了一个剪枝条件：当前左括号数量减去右括号数量不超过k。数据结构上用string不断拼接和撤销，用vector<string>收集答案。需要注意输出顺序：题目是按字典序要求，那么先追加左括号，再追加右括号，得到的序列自然就是字典序。
如果你觉得递归深了会爆栈，可以改成用栈模拟回溯过程，但一般来说n不超过20，递归深度完全可控，没必要给自己增加额外的心智负担。这题的关键不是递归怎么写，而是你能不能快速把“前缀差不超过k”翻译成代码里的if (left - right < k)。
6.4 三道题连起来看：它们有什么共同逻辑
把这三道题放在一起，你能看到一个统一的决策模式：
- 先从题面提取状态和操作；
- 根据数据范围确定复杂度上限；
- 把限制条件翻译成代码里的判断语句；
- 用一个合适的容器装状态（栈、堆、队列、数组）；
- 写完立刻构造边界用例验证。
这五步不是某一道题的解法，而是所有机试题目的通用解法。你刷题时如果每次都强行按这套流程走一遍，慢慢就会内化成条件反射，考场上不用过脑子就能用出来。
7. 我自己的做题顺序和考场上的取舍心得
这部分不是理论，是我实际考场上用过的策略，因人而异，但值得参考。
我的默认做题顺序是：先做所有题目的第一分钟扫读，然后从“描述最短”或“输入输出格式最标准”的那一道开始。这样做的原因是，标准输入输出意味着我可以用最短的时间把程序骨架搭好，先拿到一题AC带来的心理安全感，对整场考试的节奏帮助极大。
做题时间分配上，我会给自己设三个时间线：前40分钟必须AC第一题；第40到80分钟必须在第二题上有一个可提交的版本（哪怕只是暴力）；剩余时间全部投入第三第四题，但每隔15分钟强制评估一次“继续死磕还是换题”。
为什么暴力版本要先行？因为“暴力版可以先拿部分分，再优化成正解”是机试里性价比最高的打法。很多人总觉得直接写正解才叫有效，但正解可能写到一半发现思路漏洞，最后连暴力分都没捞到。先写一个必然正确的暴力版交上去，就相当于把钱存进了银行，后面优化出来的正解是利息。就算优化失败，你也不亏。
还有个小技巧：每次提交前，把所有没AC的题目的代码都保存一份离线备份（在本地文件夹里按题号分好）。万一评测系统中途抽风，你还能快速恢复。
机试说到底，就是一场“在时间压力下稳定输出代码”的压力测试。你不需要成为算法天才，只需要把基础的、高频的、框架性的东西练到肌肉记忆，再把考场上的心态调整到位，就已经能跑赢大多数人了。希望这篇思路复盘，能帮你把那道“看起来很深但不知从何下手”的清华机试，拆成一个个能下嘴的馒头。