说实话我给自己定的这个“上机打卡”计划到第三天的时候差点就断了。白天上了四节课晚上回到宿舍脑子都是蒙的打开电脑坐下来的那一刻甚至有点抗拒。但一想到前两天已经连续打过卡放弃的成本比继续做要高得多还是硬着头皮打开了编辑器。先解释一下这个标题是什么意思。DHU是我们学校东华大学的英文缩写上机打卡不是学校强制要求的考勤是我自己给自己安排的一种练习方式每天固定一段时间打开电脑在在线判题系统OJ上刷算法题把过程记录下来就像健身打卡一样。D3就是Day 3第三天。这个系列我打算至少坚持一个月把每天练了什么、卡在哪里、解决了什么问题都摊开来讲既是给自己的记录也希望给同样在准备机考的人一点参考。为什么会想到用这种方式因为“上机”这个词在当下的就业和升学场景里几乎绕不开。华为OD的招聘流程里有一轮上机考试很多学校的研究生复试也有上机环节更不用提各大互联网公司笔试清一色的在线编程题。这些事情有个共同点它们考的都是在规定时间内、规定环境下白手起家把代码写对的能力。这种能力靠看书是看不出来的必须真刀真枪地上机练。这篇文章就是第三天打卡的完整实录包括我对练习内容的设计思路、当天遇到的具体题目和解法、踩过的坑以及这套练习方法对华为OD和复试上机的实际价值。全程大白话不搞虚的。1. 为什么我把“上机打卡”坚持到了第三天1.1 上机打卡是什么我给自己定的规则上机打卡说白了就是逼自己每天做“刻意练习”环境向真实机考看齐。具体规则我定得很简单每天至少一小时全程只用OJ网站、不用本地IDE的模板。一小时分三段10分钟热身、40分钟主战、10分钟复盘。每天必须记录今天AC了几题AC指Accepted代码通过、哪题WA了Wrong Answer、卡在哪个环节、明天要补什么。规则为什么“简单”因为复杂的规则根本无法坚持。我以前也尝试过给自己定“每天刷三题、每道题写题解、还要总结多种解法”这种计划结果是坚持了不到一周就崩了。每天的想法太多光决定“今天要怎么做”就消耗了意志力。所以第三天这套规则我做了减法只要打开OJ练够一小时记录三行字就算打卡成功。这个规则的核心逻辑是“降低启动成本”。人很多时候不是没能力做一件事而是启动这件事的心理摩擦太大。把规则简化到毫无门槛之后打开电脑就变得不那么痛苦了。事实也证明第三天我虽然状态很差但因为规则门槛低还是启动了。1.2 为什么必须“上机”而不是刷题APP或纯看题解这是我很想讲清楚的一点。市面上的刷题APP、题解库、视频课资源多到刷不完但它们的共同缺点是“替你做了太多事”。看题解会给你一种“我懂了”的错觉但实际上机考的时候没有人给你递答案编辑器里连自动补全都可能没有。举一个我身边的真实例子。有个同学LeetCode上题目收藏了三百多道各种题解视频刷了不少笔记做了厚厚一本。结果第一次去华为OD上机考试第一题就卡住了。原因不是题有多难而是他习惯了本地IDE的自动补全和报错提示到了考场那种只有基本编辑器的环境下连Java的import都忘了写。这就是“看”和“做”的区别。上机打卡练的核心能力有三个第一手写代码的速度和准确率第二对OJ输入输出的敏感度第三调试能力——你是真的在跟着数据流走而不是在猜。这些能力在任何一个官方机考里都是直接决定生死的。继续往后看你会发现这三样能力在后面的实操记录里全都体现出来了。2. 第三天练什么选题标准与时间分配方案2.1 题目难度怎么选不求难求覆盖选什么题来练直接决定效率。我见过有人一上来就死磕困难题磕一小时没思路就放弃了也有人天天做简单题做得倒是开心但水平原地踏步。这两种都走了极端。我给第三天的选题定了三个标准覆盖高频考点字符串处理、数组、哈希表、简单动态规划。难度分布121——一道简单热身两道中等偏基础一道想不出就看题解积累套路。必须有一道题和“之前的错题”相关用来对抗遗忘。为什么要这样安排因为机考题目的特点是“广而不深”。华为OD上机、考研复试上机基本不会出那种需要天才灵感的偏题难题绝大多数都是在基础数据结构和常见算法模型上做文章。字符串里的去重、排序、匹配数组里的双指针、前缀和哈希表的空间换时间这些都是高频考点。用一道简单题热身帮大脑切换到编程状态用中等题锻炼真实解题能力遇上看不出思路的题看题解也不丢人关键是看完题解要真的写一遍——这一步很多人偷懒导致“看了很多、会写很少”。2.2 一小时的练习节奏怎么拆一小时听起来不长但如果利用得好效率相当可观。我这次的实际安排是19:00 - 19:10热身题字符串去重属于简单题目标是找回敲代码的手感。19:10 - 19:40主战题两数之和及其变体中等难度重点考察哈希表应用和复杂度分析。19:40 - 20:00收尾题斐波那契数列的三种写法看似简单其实是在练“从递归到动态规划”的思维升级。这里有个很重要的技巧给每道题设一个“思考死线”。主战题比如两数之和我给自己定的死线是20分钟超过20分钟还没思路就直接看题解然后合上题解自己写一遍。为什么设死线因为上机考试是有时间限制的平时练习就是为了模拟这种压力。如果不限时一道题磨一个小时也能磨出来但考场上没人给你那么多时间。这种“限时-卡死-放弃-重写”的循环才是真实的机考节奏。2.3 打卡记录到底记什么很多人练完题就把页面关了第二天再打开一个新的以前的错误全忘了。这样练一个月可能只是把同样的问题重复了一个月。所以我在打卡记录里强制写三样东西通过状态AC、WA、TLETime Limit Exceeded超时还是完全没思路。卡点描述到底是题目没读懂、解法想不到、还是代码写错了必须写清楚。明日计划把当天的遗留问题转化为明天的任务比如“明天做一道哈希表的简单题巩固”。这些记录不是为了好看是为了让练习形成闭环。计算机领域有一句老话说“没有反馈就没有学习”。刷题也是一样如果没有复盘和记录刷一百道和刷一道没有本质区别只是在数学上重复而已。3. 第三天实操记录三道题从读题到AC的全过程3.1 热身题字符串去重并保持顺序这道题很简单给定一个字符串去掉重复字符保证第一次出现的字符顺序不变。说白了就是“abcabc”输入要输出“abc”。我选它热身因为五秒钟就能看懂题适合把脑子从“课堂模式”切到“编程模式”。解法思路很直接从左到右遍历用一个集合记录哪些字符已经出现过没出现过的就加入结果。Java里可以用boolean数组因为字符的ASCII范围有限。贴一下我写的代码public static String removeDuplicate(String s) { StringBuilder sb new StringBuilder(); boolean[] seen new boolean[128]; for (int i 0; i s.length(); i) { char c s.charAt(i); if (!seen[c]) { seen[c] true; sb.append(c); } } return sb.toString(); }这里有个细节值得说用boolean数组而不是HashSet是因为数组的随机访问比哈希运算更快而且在字符范围确定的情况下数组本身就是最简单的哈希表。这个“空间换时间”的思路在后续的题里会反复出现。这道题我提交了两次才AC第一次WA是因为忽略了大小写字母都算独立字符测试用例里有“aAbB”这种混合输入我一开始把大小写当成了同一个字符。这说明一道简单的题也有隐含条件读题不能凭直觉必须认真处理边界情况。3.2 主战题两数之和与其背后的复杂度思考两数之和是编程界的“Hello World”几乎所有刷过题的人都认识它。题目描述是这样的给定一个整数数组和一个目标值找出数组中两个数相加等于目标值的下标假设只有唯一解。最暴力的做法当然是双层循环每对组合都加一遍。复杂度是O(n²)n是数组长度。如果n是几百完全没问题但如果n是几万十万这个算法的运行时间就有风险。上机考试里数据范围经常藏着陷阱题目不会直接告诉你“数组很长”但你如果交了一个O(n²)的解法很可能收获一个TLE。优化思路是用哈希表做“反向查找”遍历每个数字的时候顺便看看“目标值减去当前值”这个差值之前出现过没有。如果出现过直接返回下标。这样只需要一次遍历时间复杂度降为O(n)。代码长这样public static int[] twoSum(int[] nums, int target) { MapInteger, Integer map new HashMap(); for (int i 0; i nums.length; i) { int complement target - nums[i]; if (map.containsKey(complement)) { return new int[]{map.get(complement), i}; } map.put(nums[i], i); } return new int[]{-1, -1}; }这个“空间换时间”的模式非常经典机考里大量题目都是这个思路的变体。比如三数之和、最长无重复子串、字母异位词分组背后全是“哈希表存储已扫描的信息”。如果只记住了两数之和的代码而没有理解“为什么用哈希表”这个逻辑换一道题就抓瞎了。我这次故意给自己加了个变体如果题目要求返回所有满足条件的数对本身而不是下标代码要怎么改答案是改成先对数组排序再用双指针往中间靠拢复杂度同样是O(n log n)。这个变体其实就是很多公司笔试里出现的“三数之和”的简化版练一道能顶三道。3.3 收尾题斐波那契数列的三级优化斐波那契数列是个典型的“入门即入坑”的题目因为所有人都能写出递归版本但绝大多数人都没认真想过它的性能。教科书上的递归写法是这样的public static int fib(int n) { if (n 1) return n; return fib(n - 1) fib(n - 2); }代码很简洁但复杂度爆炸是O(2^n)。原因在于递归过程有大量重复子问题——fib(5)要算两次fib(3)fib(4)要算三次fib(2)这种重复计算在n40的时候就已经慢到肉眼可见了。第二步优化是加一个缓存也就是自顶向下的记忆化搜索把已经算过的结果存起来。但更好的做法是反过来的自底向上用一个循环不断往前推public static int fib(int n) { if (n 1) return n; int a 0, b 1; for (int i 2; i n; i) { int temp a b; a b; b temp; } return b; }这个版本的时间复杂度是O(n)空间复杂度O(1)。我之所以把这道简单题放在收尾是因为它完美地演示了一个思维升级从“人肉递归”到“程序化迭代”。这个“自底向上”的思考方式就是动态规划的核心思想。以后遇到任何类似“从前往后推导”的问题你的第一反应就是找状态转移方程而不是做递归。三道题练完时间正好落在20:02左右。我还花了几分钟把每道题的时间复杂度和卡点记在打卡本上。这种“结束即记录”的习惯很重要因为刚做完题的时候对题目的记忆还热乎趁着这个窗口记下问题比事后回忆要容易得多。4. 上机路上的常见问题与排查实录4.1 OJ与本地IDE的“水土不服”上机打卡和平时自己写代码最大的区别就是OJ这个环境特别“较真”。我在第三天就遇到了一个典型问题本地IDE运行得好好的代码贴到OJ上一提交就编译错误。第一次看到这个报错我还愣了一下。后来检查发现是因为OJ用的Java编译方式要求主类名必须是Main而我建了个叫Solution的类。这个规定在PAT、高校OJ、华为OD的纯代码模式里非常常见。如果你平时只用LeetCode那种自动准备好了类名的环境完全不会意识到这个问题。但也正因为踩了这个坑我才总结出一个经验平时练习就强迫自己在OJ的编辑器里写代码而不是舒服地缩在本地IDE里。让“不舒适”变成日常考场上才不会翻车。除了类名问题还有几个常用的坑我整理了一下常见问题原因解决办法本地编译通过OJ编译失败包名残留、类名不合规检查类名是否为Main删除package语句输入读不到或读错行nextInt和nextLine混用统一用Scanner注意换行符残留AC但OJ报Runtime Error数组越界、空指针检查数组声明大小判空后再取值输出格式无感知的WA多了空格、少了换行测试用例逐字符对拍4.2 超时的排查思路说到TLE这堪称机考里的“第一大杀手”。明明逻辑是对的为啥超时绝大多数时候问题出在复杂度上——你的解法在测试数据变大之后撑不住了。排查TLE的思路其实很固定先看数据范围。题目给的n是10^5还是10^4如果n10^5O(n²)就是天方夜谭。再检查你的解法里有没有“重复扫描”——同一个数组被遍历了好几遍那就该用哈希表或预处理来解决。举个例子第三天热身题如果用双层循环去扫描重复字符数据一长必超时用boolean数组一次遍历就能解决。这种对比让我意识到学会估计算法复杂度比背更多的题解重要得多。看题第一件事不是写代码而是先想“这个数据范围允许什么复杂度”再来决定算法路线。4.3 心态问题与精力管理上机打卡不只是技术问题更是体力活。第三天我状态差的原因很简单前一天的睡眠不到六小时傍晚又上了一堂信息量极大的课脑袋里已经装了很多任务。这种时候坐下来高效编程其实是在透支。我的经验是不要和身体硬扛。状态差的时候练习目标可以往下调——那天我原本计划练四道题最后降到三道其中一道还是简单题。表面看是“缩量了”但至少完成了闭环有热身、有主战、有复盘。假如硬撑着练四道结果第三道开始走神、第四道完全是在乱写那才是浪费时间。另外坐了一小时之后一定要起来喝水、走动。颈椎和腰比任何题目都重要。上机考试一坐就是两三个小时平时的体力储备直接决定你的后半场表现。5. 从华为OD到复试上机上机打卡练出来的东西真的能用5.1 华为OD上机考试常见模式很多人对华为OD这个名词有疑问其实它就是华为的外包研发岗位招聘流程入职后做项目支撑类开发。OD的招聘流程里“上机考试”是淘汰率最高的一关也是最客观的一关因为它不看简历、不看聊天就看你能不能写对题。华为OD上机考试的基本形式通常是这样在指定的在线平台上答题时间大约100到150分钟一般两道题左右难度从简单到中等偏上。考点集中在字符串处理、数组操作、哈希表、排序、简单动态规划偶尔会有一道链表或二叉树的基础题。结合我自己的观察OD上机最典型的失分点有两个一个是“读不懂输入”。OD题目的输入经常是多行描述、多种类型数据混合很多人花大量时间在解析输入上真正思考算法的精力反而被耗尽了。另一个是不熟悉考场的编辑器。没有自动补全、没有语法高亮级别的提示很多平时依赖IDE的人写代码速度会明显下降。所以如果你要准备OD上机我建议直接拿上机打卡的方式练每天在OJ上做三道题按正式考试的时间限制给自己倒计时练习用Scanner正确读取多种类型的输入全程用考场的编辑器写。坚持一个月效果绝对比把题解翻烂要好。5.2 复试上机的差异性复试上机是研究生入学考试里的一个环节不同学校差别非常大。有的学校直接考一种经典OJ题型用的是本校的判题系统有的学校则允许用本地IDE最后把源码打包上传还有的学校会指定语言和编译器版本。差异性大到什么程度呢同样一道题在A校要用Java提交一个主类为Main的文件在B校却允许你直接用C提交一个函数。所以我的建议是准备复试上机之前优先去查目标院校的官网公告和往年经验帖搞清楚三个问题——用什么系统判题、用什么语言和编译器、以什么形式提交代码。把这些信息弄清之后再针对性地设计你的上机打卡内容。比如学校用C那你就该早点从Java切到C练习学校不允许你带模板那你就别依赖自己打印的代码模板。5.3 一套练法通吃建议收藏的复习路线这里分享一条我认为“通吃”的复习路线也是我从打卡第三天就开始执行的方向第一阶段第1-10天搞定语言基础和高频数据结构。数组、字符串、哈希表、栈、队列、排序、二分查找。每天三道简单到中等的题目标是把手和编译器培养出默契感。第二阶段第11-20天主攻常见算法思想。双指针、滑动窗口、递归、贪心、基础动态规划。每天两道中等题加一道简单题重点做“一题多解”的总结。第三阶段第21-30天模拟考试和复盘。每周安排两次完整限时模拟用和真实考试一样的时长和题量其余时间刷经典题和错题。这条路线的核心思路是“由厚到薄”前期广泛覆盖中期总结套路后期查漏补缺。它不激进、也不轻松但胜在可持续。任何一个散落在这条路线里的考点都有可能出现在华为OD上机或者复试上机的考场上。根据我个人经验上机打卡练的不只是代码更是一种“遇到问题不慌、有条理地推进”的能力。第三天虽然差点断掉但真正坐下来之后反而比前两天更专注。大概是因为前两天的打卡已经让我的手指记住了一些肌肉记忆打开OJ就像是打开了熟悉的茶馆坐下来就是喝茶不需要思考“我要不要喝茶”这个问题。如果你也想尝试这种练习方式不用严格照搬我的规则记住两个核心就行第一每天都比昨天多坚持一点哪怕是只做一道最简单题第二记录永远是给自己的礼物一个月后回看打卡记录你会看见一条实实在在的成长曲线。