第一天打开题单的时候我第一反应是关掉页面。这不是开玩笑。作为一个当年被“代码随想录 day1”这种打卡计划吸引、又差点在第一天就放弃的人我太清楚那种感觉了标题看起来很正能量评论区一片“打卡成功”但自己一上手数组、指针、复杂度、边界条件每个词都认识拼在一起就是看不懂更别提在限定时间里写出能通过的代码。如果你也正处于这个阶段别急着怀疑智商这篇文章就是写给第一天的你。我会把自己第一天踩过的坑、后来总结出的方法、以及一道题从“完全没思路”到“AC”的完整心理过程全部拆开讲清楚。不管你是刚准备找实习还是单纯想把算法基础补起来这套思路都适用。而且我保证看完之后你至少不会觉得第一天是无用功。1. 刷题第一天最容易被劝退的三个瞬间以及我的处置方式很多人以为刷题第一天最难的是“不会做”其实不是。最难的是“还没开始就觉得自己不行”。我把第一天会遇到的劝退瞬间总结成三类每个我都亲身经历过。1.1 瞬间一题目描述每个字都认识合起来完全看不懂我记得自己第一天拿到第一道数组题时题目里有一个词叫“原地修改”我当时盯着看了两分钟心想原地是什么意思是要我在原数组上面打滚吗后来才知道原地修改就是指不额外开一个新数组直接在原数组上操作。这种专业黑话在题解里比比皆是什么双指针、哨兵节点、哈希表、滑动窗口第一次看到真的像看天书。处置方式其实特别朴素把看不懂的名词记下来当作今天的学习目标之一而不是当作放弃的理由。第一道题看不懂很正常因为题解默认你已经具备了一部分前置知识。我第一天给自己定的规矩是允许自己定义“看懂”——不要求一次看懂所有细节只要求看懂“这道题是想让我干什么”。比如“原地修改”我就翻译成“不许用另外的数组只能动原来的数组”。能把题目翻译成人话就已经赢了一半。1.2 瞬间二别人十分钟 AC我半小时还在编译错误这是最容易让人崩溃的时刻尤其是当你加了几个刷题群看到别人早上六点发“打卡成功今日两题”而自己连一个测试用例都跑不对的时候。我当时的第一反应是完了我是不是不适合写代码。后来我想明白了一件事别人十分钟 AC 的背后是他们已经见过几十道类似的题那些代码几乎是“肌肉记忆”。而第一天的人连输入输出长什么样都要想半天速度当然不一样。这不是智商差距是经验差距。处置方法我只有一条把“十分钟 AC”这个标准从脑子里删掉。第一天只看一件事——我能不能最终跑通。哪怕花两个小时只要跑通了今天就值了。如果跑不通那也值了因为你至少知道了自己卡在哪里。1.3 瞬间三收藏了一堆优质题解觉得已经学会了这个陷阱特别隐蔽。第一天我一旦做不出来就习惯性去搜题解看到一篇写得特别好的逻辑清晰图文并茂我一边点头一边收藏心里想着“哇讲得真好我会了”。结果关掉页面让我自己写脑子一片空白。收藏不等于学会看懂不等于能写。这个道理我第一天就懂了但真正改掉这个毛病花了很久。我的处置方式是把收藏夹当成“复读机”而不是“仓库”。收藏一篇题解之后当天晚上必须关上它自己默写一遍关键逻辑写不出来第二天早上再去看。如果只是收藏不看那就等于没收藏。后来我把这个习惯叫“反收藏机制”对抗的就是我们这种“以为存了就会了”的大脑。2. 开刷前先定死四件事语言、环境、流程、打卡节奏第一天最容易犯的另一个错误是还没想清楚规则就冲进题海。我见过太多人第一天就换了三种语言、两个平台、四套计划最后啥也没坚持下来。刷题虽然看起来是“做题”但它其实是个系统工程。开刷前把下面四件事定死比多做三道题有用得多。2.1 语言选熟不选新很多人会有一种错觉刷题顺便可以学一门新语言比如用 Python 刷题顺便学 Python。我劝你别这么干至少第一天不要。刷题时你的注意力应该全部放在“算法逻辑”上而不是语言语法上。如果你选的是一门不熟悉的语言你会在“这个函数怎么拼”“这个列表怎么切片”“这个分号是不是漏了”这些问题上消耗掉大量精力最后失败了你还会以为是算法太难。选语言就只有一条标准哪门语言你写起来最顺手就用哪门。我当时选的是 Python不是因为 Python 天下第一而是因为我那会儿最熟的就是它写起来不用查文档。后来我也见过用 Java、C、Go 刷题的朋友坚持得都很好。第一天千万别在这上面纠结浪费时间。真要学新语言等刷题节奏稳定下来之后再考虑用新语言重刷旧题那时候才是学语言的好时机。2.2 环境配置本地调试和在线评测各自承担什么第一天我先检查了两样东西本地编辑器能不能跑通最简单的代码在线评测平台的提交按钮是不是正常。听起来很简单但真的有人第一天就栽在这上面——本地代码跑得好好的一提交就报错最后发现是缩进问题或者本地根本没配环境全靠网页编辑器硬写写长了就难受。我自己的安排是这样的本地编辑器负责“调试”在线评测负责“验收”。也就是说我先在本地把代码写好、跑通、打上日志看输出对不对然后再复制到在线评测去提交。这样做的好处是本地调试你能看到完整的变量变化可以在关键位置加 print能真正理解代码在干什么而在线评测只告诉你对错不给太多过程信息。对第一天的人来说能看见中间过程比直接看到“通过”重要得多。另外我建议第一天就学会用测试用例来验证不用很多三五个边界用例就够。比如数组为空、数组只有一个元素、目标值在最前面、目标值在最后面把这些情况都跑一遍比盲目提交十次有用。2.3 一道题的完整处理流5分钟思考 - 15分钟实现 - 复盘第一天最容易出现的两个极端一个是想了五分钟没思路就去看题解另一个是死活不看题解死磕俩小时不出来。这两个极端我都经历过。后来我给自己定了一个“5-15-无限”流程第一天执行下来感觉特别稳。具体来说先自己思考 5 分钟。这五分钟不是干瞪眼而是做三件事第一把题目翻译成人话明确输入和输出是什么第二想一个最笨的办法哪怕时间复杂度是 O(n 的平方)只要能跑通就行第三在纸上画一画假设输入是 1、2、3手动推一下结果会是什么。如果 5 分钟后还是毫无头绪那就去看题解但要带着问题去看我是卡在理解题目还是卡在想不到思路还是想到了思路不会实现。如果 5 分钟内有了思路那就给自己 15 分钟去实现。超过 15 分钟还没跑通说明这个思路里有隐藏的坑比如边界条件处理错了这时允许再花 10 分钟调试。如果还是不行果断看题解。第一天的人最需要的是“完整跑通一道题”的成就感而不是“死磕一道题到底”的英雄主义。把战线拉太长第二天你就不想打开编辑器了。2.4 第一天的时间节奏怎么安排我见过很多人第一天就给自己安排五六道题结果只完成一道然后产生巨大挫败感。第一天真的不要贪多两到三道题就非常够了。我第一天的节奏是早上第一道题找感觉下午第二道题巩固晚上第三道题尝试独立做全程不看题解。三道题里前两道允许看题解第三道不允许。这个安排的核心逻辑是让难度平缓上升又不至于太舒服。另外时间块不要太散。我第一天试过中午刷一道、晚上刷一道、睡前再看一眼题解结果发现每段时间都很碎脑子里刚有点思路就被别的事打断。后来改成每天固定一个 45 分钟的完整时间块加上一个 15 分钟的碎片时间做回顾。45 分钟里前面 10 分钟复习昨天的题中间 25 分钟做新题后面 10 分钟写复盘笔记。这个节奏坚持下来之后效率比我之前一天到晚刷手机看题解高得多。3. 以“数组-二分查找”为例看一道题如何从懵逼到 AC说完了心态、环境和流程接下来聊聊第一天的核心内容。大多数刷题计划第一天都是从“数组”开始的。这不是偶然因为数组是最基础的数据结构它的操作能引出很多经典算法思想。我拿我第一天做的一道二分查找题作为例子把从“完全没思路”到“AC”的全过程拆给你看。3.1 为什么第一天要从数组题入手数组的特点是什么连续的内存空间、相同类型的数据、通过下标随机访问。这三个特点决定了数组题目的变化多端你可以用指针遍历它可以用二分法切它可以用哈希表记录它里面的元素还可以在它内部做各种原地操作。换句话说数组是算法世界里最便于白纸上推演的场景。我第一天看到题单上全是数组题的时候还觉得无聊心想这不就是遍历吗。后来才知道同样的数组难度可以从简单到地狱。二分查找就是一个典型的例子看起来就是“在有序数组里找一个数”但真正写起来边界条件能让人怀疑人生。我第一天就死在这上面。3.2 暴力解法先落地再谈优化拿到一道“在有序数组中查找目标值”的题我的第一版代码写的是暴力遍历。那时候的逻辑特别单纯数组有序我直接 for 循环从头到尾找一遍找到了就返回下标找不到就返回 -1。这当然能通过最简单的测试用例但稍微大一点的输入就会超时。暴力解法的意义不在于“效率”而在于让我先确认自己对题目的理解没有错。如果连最笨的方法都写不出来说明我连题目都没读懂。写暴力解的过程会逼着我去定义清楚变量名、边界和返回值这些是后续优化的地基。我第一天给自己定的规矩是哪怕知道答案是用二分查找也先花五分钟写一版暴力解。别小看这一步它能培养一种很宝贵的能力——把模糊的想法落地成代码的能力。3.3 二分查找的边界为什么是左闭右开当我意识到暴力解会超时下一步就得想更好的办法。“有序数组”和“查找”这两个词放在一起几乎就是在明示二分查找。二分查找的逻辑不复杂每次取中间位置如果中间值大于目标值就去左半边找如果小于目标值就去右半边找如果等于就找到了。但第一天写二分查找我几乎必然会在边界条件上报错。问题出在“区间定义”上。我当时写得特别混乱一会儿 left right一会儿 left right一会儿 right mid一会儿 right mid - 1每次提交都卡在一个奇怪的用例上。后来我才真正理解写二分查找之前必须先想清楚一个问题我维护的这个区间是左闭右闭 [left, right]还是左闭右开 [left, right)这两种区间对应的写法是完全不同的。如果是左闭右闭那 left right 的时候区间里还有一个元素所以循环条件要用 left right当中间值大于目标值时right 要变成 mid - 1因为 mid 已经检查过了不需要再包含它。如果是左闭右开那循环条件要用 left right因为 left right 时区间已经是空的当中间值大于目标值时right 直接等于 mid 就行因为右边界本来就是开的不会包含 mid。我后来写了一个小口诀“闭区间收右边界要减一开区间收右边界不用动。”这个细节就是二分查找的核心也是第一天最大的绊脚石。用一个具体的例子来推演一下假设数组是 [1, 3, 5, 7, 9] 目标值是 7。如果用左闭右闭的写法初始 left0right4。mid(04)//22nums[2]5小于 7所以把 left 更新为 mid1也就是 3。此时 left3right4mid3nums[3]7正好命中返回 3。一切顺理成章。但如果中间某一步我把 right 写成了 mid而不是 mid-1就会出现死循环因为区间永远在包含已经被检查过的元素。3.4 一道双指针练习题为什么快慢指针能省一层循环第一天的题单里除了二分查找往往还会出现“移除元素”这类题。我第一次看到“给你一个数组原地移除所有值等于 val 的元素并返回新长度”的时候第一反应是新建一个数组把不等于 val 的元素装进去再拷贝回来。但这不符合“原地修改”的要求。后来我才知道这类题的经典解法是双指针。双指针的思路其实特别生活化。想象一下你在一条窄路上走前面有个慢吞吞的人挡路你不会推开所有人而是找一个空位快速绕过去。快指针负责“探路”走遍整个数组慢指针负责“安家”只记录那些符合条件的元素。代码写出来大概是这个感觉def removeElement(nums, val): slow 0 for fast in range(len(nums)): if nums[fast] ! val: nums[slow] nums[fast] slow 1 return slow这个代码表面上只有几行但它解决的问题非常深刻我们只用一个数组、一次遍历就把所有不需要的元素“覆盖”掉了时间复杂度 O(n)空间复杂度 O(1)。对比我当初新建数组的暴力写法快慢指针省下的不是一点点开销是一整块额外内存和一个隐藏的循环。第一天把这类题吃透你会发现一个规律很多看似复杂的问题最后就是在数组上维护了几个位置标记仅此而已。4. 提交通过后我还会做这三件事很多人第一天写完代码、提交通过、看到一个绿色的“通过”就心满意足地关了页面。我后来回头看觉得这个动作太亏了。通过只是起点不是终点。如果做完题不进行后续处理那道题过三天你就忘了等于白做。我第一天开始给自己定了一个规矩每道题通过之后必须再花十分钟做三件事。4.1 分析时间和空间复杂度给代码写注释第一件事是回头审视自己的代码在关键行写上注释说明这一步在干什么以及为什么这么写。比如二分查找里的 right mid - 1我会注释“因为当前 mid 已经被检查过下一步要排除它”。别小看这个动作它在逼我用自然语言重新讲一遍代码逻辑。如果你发现自己讲不清楚某一行那往往意味着那一行是你抄来的、或者碰巧跑通的你并没有真正掌握它。这时候就该回头翻题解把思路补全。然后是复杂度分析。第一天只需要会看大 O 就够了你的代码时间复杂度是 O(n)O(n 平方)还是 O(log n)空间复杂度是 O(1) 还是 O(n)我自己的方法是问自己一句话如果数组长度从 100 变成 10000我的代码运行时间会变成原来的多少倍如果大概变成 100 倍那就是 O(n 平方)如果变成大概 2 倍那就是 O(n)如果几乎不变那就是 O(log n) 或者 O(1)。用这种“估倍数”的方法理解复杂度比死记公式直观多了。4.2 错题复盘别只抄答案要写“当时卡在哪”第二件事是错题复盘。第一天我做题最大的问题是看题解的时候总觉得“这也太简单了我怎么没想到”然后就直接进入下一题。后来我改变了策略每道没做出来的题我会在笔记里单独留一块区域只写三行字——我当时的思路是什么、我在哪一步卡住了、题解用了什么关键思路让卡住的地方畅通了。比如我做二分查找的时候笔记里就写着“我卡在不知道什么时候该用 mid-1什么时候该用 mid题解告诉我首先要定义清楚区间是左闭还是右开区间不同处理就不同。”这短短两行话比抄一整篇题解都有用因为它记录的是一种“认知升级”我不只是记住了答案我更清楚地看见了自己思维里的死胡同。这个方法我后来推荐给不少朋友亲测有效。4.3 把第一天的题提炼成模式模板第三件事最有远期价值把题目抽象成模式。第一天你可能只做了两三道题但你会发现它们背后其实是同一个家族的套路。数组遍历是一个模式双指针是一个模式二分查找是一个模式哈希表计数又是一个模式。我会在笔记里给每个模式建一个小节记录它的核心代码骨架、典型应用场景、以及最容易翻车的细节位置。比如双指针模式下就记着“快指针负责探路慢指针负责安家”二分查找模式下就记着“先定区间再写边界”哈希表模式下就记着“查重和计数都优先想哈希表”。当你把题目提炼成模式之后你会发现“刷题”不再是一道一道地刷而是一类一类地刷。第一天可能还看不出这个习惯的威力但等你刷到三十天、五十天的时候再回头翻这些模式笔记会发现自己已经有了一本属于个人的算法手册。这东西的价值远超那些收藏夹里吃灰的题解。5. 第一天过后真正决定能否坚持的是这件事聊到这里你可能会觉得第一天要做的事也太多了吧又要定环境、又要写暴力解、又要复盘、又要建模式库。我承认这套流程听起来繁琐但第一天真的只需要把这些架子搭起来后面每一天都是往架子里面填内容。而比这更重要的是一个心理层面的问题第二天你还愿意打开编辑器吗5.1 把目标从“刷完”改成“搞懂”我在第一天最大的转变是把目标从“我要刷完这个题单”改成“我要搞懂今天这一道题”。事后回想这是我能坚持下来的核心原因。“刷完”是一个没有尽头的目标因为题单永远在更新题永远刷不完但“搞懂”是一个可完成的目标它不要求数量只要求你在某一道具体的题上真正突破了某个盲区今天就算有收获。这种心态的调整影响特别大。因为当你把目标改成“搞懂”之后你就不会因为别人一天刷五道题而焦虑了。别人刷五道题可能是那五道题他都见过而你花两个小时搞懂一道题你今天增加的“理解力”可能比他刷五道还要多。第一天的我并不完全相信这句话但三十天之后我信了。刷题本质不是比谁看到的题多而是比谁脑子里沉淀下来的思路多。5.2 建立最小正反馈本地记录、周复盘为了让自己愿意第二天继续我还给自己设计了一个最小正反馈系统。第一天我就建了一个本地笔记文件用来记录每天做了哪几题、卡在什么地方、明天的任务是什么。每天晚上完成任务后我会在文件前面加一行日期和打卡标记。这个动作很轻但它给大脑一个信号你今天确实做了点东西。别小看这种信号它比任何励志口号都更能对抗“刷题毫无进展”的虚无感。另外我还做了周复盘。第一天当然还谈不上一周但我把复盘框架先定下来了这一周一共做了几题、哪些题第一次就 AC、哪些题卡住了、卡住的题目有没有共同点、下一周我要重点补什么方向。我后来发现很多人刷题刷着刷着就散了就是因为从来不回头看。设立复盘机制相当于给你的刷题计划装上一个导航它会在你偏离方向时提醒你。5.3 我踩过的“求快”的坑最后再分享一个我第一天之后踩过的大坑希望你第一周就能避开。那是我刷到大概第十天的时候觉得自己状态起来了开始疯狂加量一天最多刷了七道题。结果到了第十五天我发现自己对前面很多题的记忆变得特别模糊连当时 AC 的代码逻辑都讲不清楚了。我这才意识到加量不加质约等于白刷。那之后我痛定思痛把每天的题量压回两到三道但要求自己每一道都能在三天后不看题解独立重写出来。“能不能独立重写”这个标准比“当天能不能 AC”严格得多。它逼着我把短期记忆变成长期记忆把“看懂了”变成“会做了”。第一天你可以不设置这个标准免得压力太大但第二天、第三天开始一定要慢慢引入这个要求。否则你会发现自己刷了一个月最后能在白纸上默写出来的题目一只手都能数得过来。第一天的收获不应该是几道题的答案而是一整套可复用的流程遇到不懂的术语就查、五分钟没有思路就看题解、写代码先暴力后优化、提交通过后复盘、把每个套路沉淀成模板、把目标从“刷完”改成“搞懂”。这套流程我后来用在了很多场景里不光是刷题连看框架源码、学新技术栈都是同一个套路。第一天可能显得很笨拙但它值得你认真对待。毕竟只有先把第一天的地基打好第二天的你才愿意推开编辑器的大门。