2023年秋招那会儿我印象最深的一次实战演练就是牛客的第三轮模考。前两轮成绩都在及格线附近徘徊编程题要么卡在读不懂题意要么好容易写出来又超时。三模那套题出来以后我当天晚上就完整刷了一遍接下来的两天反复研究题解和讨论区越看越觉得这套卷子藏了不少东西——它不靠偏题怪题吓人而是把校招笔试里最常见的套路、最容易踩的坑、最考验基本功的细节全部集中到了一套题里。这套题适合两类人一类是准备校招笔试、想通过模考找状态的应届生另一类是学完数据结构和算法、想检验真实水平的初学者。这篇文章不打算把每道题的 AC 代码原样贴一遍而是从出题逻辑、破题思路、丢分细节、复盘方法几个角度把三模这套题真正吃透。如果你手头正好有这套卷子建议顺着这个思路重新做一遍体验会完全不一样。1. 三模在备考链条里的真实定位为什么它是分水岭1.1 三轮模考的难度阶梯是怎么铺的牛客的模考很少是孤立的一场而是按备考周期连续铺排的。2023年的三模正好卡在秋招笔试前夕这个时间节点决定了它的出题定位题目不再是单纯的知识点堆砌而是模拟真实笔试的筛选逻辑。我自己做下来的感觉是一轮二轮更像是体检帮你发现哪里薄弱三轮则像是模拟考直接告诉你按现在的状态上场能拿多少分。正是因为三模离实战最近它的数据反馈才最有参考价值。身边不少同学做到第三轮反而比前两轮分数低最开始大家还以为是自己水平退步了后来对照题解才发现是题目从单考点变成了多考点混合以前靠背模板能过的题现在需要临场组合思路。这个落差其实是一种提醒笔试不是比谁背的模板多而是比谁能在有限时间内把学过的东西灵活调出来。三模最大的价值就是让你在正式笔试之前先被综合题真实地冲击一次。还有一个容易被忽略的点三模的成绩曲线和最终笔试成绩的拟合度通常比前两轮高。因为前两轮模考时很多人还没进入备考状态成绩偏低到了三轮大家的复习节奏基本定型这时候暴露出来的问题才是真正需要在最后阶段解决的。所以拿到三模成绩与其焦虑分数不如把它当成一个校准自己复习方向的机会。1.2 编程题的分层设计从送分到压轴从2023年三模的编程题结构来看题目梯度相当清晰。第一梯队通常是基础题涉及数组统计、字符串处理、简单模拟主要考察基础语法和代码熟练度第二梯队开始上双指针、滑动窗口、哈希表这类高频算法模型第三梯队则进入动态规划、贪心、带状态设计的综合题。这个层次和真实互联网公司的笔试出题风格高度一致先用简单题筛掉完全不会写代码的人再用中等题筛掉只会背题的人最后用综合题挑出真正有建模能力的人。理解了这层设计备考策略就清晰了前三题拼的是熟练度和准确率最后一题拼的是临场建模和取舍能力。如果你在压轴题上耗时太多不妨接受这题可以部分放弃的策略把时间留给前面一定能拿到的分。这不是消极而是对考试规则的尊重。我记得当时题解区里有个高赞评论说得很直白三模不是让你证明自己多聪明而是让你在两个小时里拿到尽可能多的分。这句话我一直记到现在。2. 高频题型的破题链路从读题到 AC 的完整推演2.1 模拟与字符串处理先画状态机再写代码三模的模拟题基本不会出纯粹的按步骤执行题而是在模拟基础上叠加分支逻辑。比较典型的是带括号、带重复次数的字符串展开题给你一个编码串比如a3(b2(c))这种形式要求输出展开后的完整字符串。很多人一上来就递归结果括号不匹配、数字位数没处理对、展开顺序搞反各种边界崩。我的做法是先在草稿纸上画一个状态机遇到数字就解析完整的计数、遇到左括号就压栈、遇到普通字符就追加到当前层、遇到右括号就弹出并重复。状态图画清楚以后代码只是一个翻译动作。这类题考察的不是算法天赋而是能不能把自然语言描述的规则转化成无歧义的代码逻辑所以千万别省掉建模那两分钟。笔试里常有这种题看起来简单但 AC 率并不高原因就是大部分人直接动手写写到一半发现逻辑漏洞百出。另外这类题的输入解析也很讲究。字符串里可能有连续多位数字比如a12(b)如果只读一位数字就会出错。处理办法是循环读完整段数字再转成整数而不是用int(s[i])一次取一位。这些细节在平时练习时就要养成固定写法考场上才能形成肌肉记忆。2.2 双指针与滑动窗口先算复杂度再决定能不能优化三模里必有一道滑动窗口或双指针题比如求满足某条件的最短或最长子数组统计满足条件的子数组数量。这类题最容易出现的错误是想都不想就写暴力解。通常暴力解是 O(n²)数据量一放大必超时。这时候就要问自己两个问题内层循环每次重复计算了什么能不能让某个指针单调移动把复杂度降到 O(n)我印象很深的一道题是给定一个整数数组和一个目标值 k统计有多少个子数组的和等于 k。暴力解枚举起点和终点O(n²) 直接超时正确做法是先求前缀和数组 pre然后问题就变成有多少对 i j 使 pre[j] - pre[i] k也就是pre[i] pre[j] - k 出现了多少次。维护一个哈希表在遍历 pre 的过程中统计计数一次循环就能搞定。核心代码如下def subarray_sum(nums, k): count 0 pre 0 freq {0: 1} # 前缀和刚好等于 k 的情况从下标 0 开始 for num in nums: pre num if pre - k in freq: count freq[pre - k] freq[pre] freq.get(pre, 0) 1 return count这个转化思路本身比代码重要得多。三模的题目设计就是希望你具备换个角度看问题的能力所以复盘时别只盯着 AC要把每一步变换的原因记下来。如果下次再遇到统计满足某种条件的区间/子数组第一反应应该是能不能用前缀和、能不能用滑窗、能不能用哈希表记录历史状态。把这些模型在脑子里排一遍比盲目试各种做法高效太多。2.3 哈希表与计数判断该不该用空间换时间哈希表是笔试里的万金油但用得不恰当同样会翻车。比如统计出现次数最多或最少的元素这类题用字典计数是标准操作但如果题目允许排序且 n 不大直接排序再扫描可能更简单不需要额外维护哈希表。判断标准就一句话先看清数据规模。n 在 10^5 量级时O(n log n) 的排序完全够用不必硬上 O(n) 的哈希n 到 10^6 以上且只查存在性哈希表才是更稳的选择。还有一种常见坑用哈希表记录状态时要注意键的可哈希性和值的更新逻辑。比如用元组做键、用列表做值稍不留神就会写错。三模的题解区里很多人在这类问题上栽跟头不是思路不对而是对语言特性的边界不够熟悉。Python 的字典虽然好用但键的类型必须一致、可变对象不能直接当键这些基础点平时多踩几次坑就记住了。我在复盘三模时还发现一个有意思的现象同一道题用哈希表能过用排序也能过但两者在真实笔试里的风险完全不同。哈希表要求你能正确设计键值关系排序则要求你想清楚排序之后怎么扫描。尽量掌握两种解法考试时根据题型灵活切换比死守一种思路稳得多。3. 丢分重灾区边界条件、运行效率与语言细节3.1 一张边界条件自查清单编程题的判题数据里边界条件往往占据大量测试点这是出题人故意为之。我在三模和后续真实笔试中总结出一份自查清单每道题提交前对照一遍能减少很多无谓的 WA输入为空或长度为 0 时主逻辑是否还能正确返回只有一个元素时循环边界和初始值是否仍然成立数值运算是否可能溢出Python 大整数没问题但其他语言要特别小心。索引操作是否可能越界重点检查i1、i-1、j1这类相邻访问。是否存在多组测试数据每组之间需要重置的变量是否都重置了示例能过不代表边界能过务必亲手构造两个极端用例。举个例子处理子数组问题时很多人会把前缀和数组的开头初始化漏掉。没有了pre[0] 0这个哨兵所有从数组第一个元素开始的子数组都会被漏算。这种错误在示例数据上几乎看不出来但判题数据一上立刻原形毕露。所以我现在写代码前都会强制自己在心里跑一遍空输入和单元素输入这两个用例能过滤掉相当大一部分低级错误。3.2 Python 笔试的输入输出别让小细节毁掉整个 AC2023年三模的时候我注意到一个现象很多用 Python 的人算法思路完全正确却因为输入输出写法太慢导致超时。具体来说当数据量达到 10^5 级别逐行调用input()和print()的开销会非常可观。正确做法是一次性读入import sys data sys.stdin.read().split()data里就是按空白切分好的所有字符串再按顺序转成需要的类型就行。输出同理把结果攒进列表最后用sys.stdout.write(\n.join(res))统一输出。实测下来这种写法和逐行读写相比速度能差好几倍在笔试场景里就是过与不过的区别。还有一个细节如果题目要求输出浮点数注意保留位数直接用 f-string 格式化就行不要手写四舍五入逻辑容易踩到浮点精度问题。另外多组测试数据的时候很多人会忘记在每组之间清空结果列表导致输出拼接错乱。这个问题没有捷径只能靠平时养成每组独立处理、最后统一汇总的习惯。3.3 递归爆栈一个让人欲哭无泪的经典错误三模题目里一旦涉及树的遍历、多层嵌套结构展开很多人第一反应就是递归。Python 的默认递归深度只有 1000 左右遇到链式数据或者深层嵌套结构直接就会触发递归深度限制。我的建议是平时练习时就强制自己把每道递归题再用迭代写一遍尤其是用栈模拟递归这套手法考场上真的能救命。比如二叉树的前序遍历递归写法三行就能完成迭代版本需要显式维护一个栈先把根节点压进去再按右子树先压、左子树后压的顺序弹栈。这个过程看似多了几行代码但完全绕开了递归深度限制数据量再大也不怕。更重要的是迭代写法能让你更清楚地看到每个节点的访问顺序反而有助于理解题目本身的逻辑。我在三模复盘时看到题解区有人感慨明明思路是对的就因为用了递归白白丢了一整道题的分。这种亏吃一次就够了。现在我的习惯是任何递归写法都要问自己一句最坏情况下递归深度是多少超过一千立刻换成迭代方案。4. 成绩出来以后一套可以反复使用的复盘流程4.1 把错题分成三类比总分更有价值拿到三模成绩单先别急着看分数也别急着难过。我习惯把每道错题归入三类并对应不同的复习策略错误类型典型表现复习策略知识盲区看到题目完全没思路不知道用什么模型回到对应知识点做专项练习实现瑕疵有思路但代码写得慢、反复出错限时手写代码训练码力复杂度不敏感代码能跑但超时或超内存系统练习复杂度分析熟悉数据规模这三种错误都会丢分但补救方式完全不同。第一类需要回到知识点本身把基础补上第二类需要大量手写代码提升从思路到代码的转换速度第三类则需要专门训练时间和空间复杂度的敏感度。只有先分清错误类型后面的补强计划才不至于眉毛胡子一把抓。我见过很多人拿到成绩之后把错题题解抄一遍就算复盘完结果下次遇到变式还是不会。原因很简单抄题解只解决了这一道题没有解决这一类题。而分类复盘逼着你去想我到底是在哪个环节掉的链子这个思考过程本身就是提升。4.2 两周补强计划从专题冲刺到混合演练针对三模暴露出的问题我给自己的安排是两周一个周期。第一周是专题冲刺期每天拿出固定时段只做一个类型的题比如周一双指针、周二滑动窗口、周三哈希表、周四动态规划每个专题完成十道左右的针对性练习做完立刻对答案把错题标出来。第二周进入混合演练期每天限时做一套混合题模拟真实考试节奏重点训练看到题目快速判断考点的能力。补强阶段最忌讳的是只看题解不动手。我见过太多人看懂了就关掉页面结果下次碰到同类题还是写不出来。编程这个东西眼睛会了和手会了是完全两回事。一个很实用的自测标准是合上题解在限时内独立写出能通过全部用例的代码。做不到就说明还没真正掌握需要再练一组同类题。4.3 题解区的最佳用法每种题至少看三种解法牛客的题解区是三模最被低估的资源。一道题通常不止一种解法有人用标准算法有人思路清奇有人写得啰嗦但特别直观。我的建议是每道题至少看三种解法然后挑最优解自己重写一遍。看题解不是背答案而是观察别人是怎么把问题拆开的有时候一个巧妙的转化能让你思路一下子打开这种收获是单纯刷题刷不出来的。题解区的讨论往往还会提到这道题的变形和坑点这是比题解本身更珍贵的信息。比如有人说这题我一开始用递归爆栈了你就知道这道题必须考虑迭代方案有人说这里漏了空数组的判断你就知道边界条件容易栽在哪。这些别人用 WA 换来的经验相当于免费抄作业。把常见的坑提前记在笔记里下次遇到同类题就多了一道防线。5. 模考的正确打开方式时间分配、难度衔接和复盘习惯5.1 时间分配先易后难给调试留出上限三模的做题顺序直接影响最终分数。我的固定流程是开场先把所有编程题扫一遍按有思路优先、题目短优先、分值高优先排序然后从最简单的开始写。选择题部分控制在每题平均两分钟以内遇到纠结超过三分钟的先标记跳过。编程题每道给自己设一个二十到二十五分钟的调试上限卡住了就果断跳下一道回头有时间再补。这个策略一开始会觉得放弃很难受但数据会告诉你它是合理的。很多时候你死磕的那道难题只有少量分值而后面被它挤掉的简单题加起来反而更多。模考的意义就是把这种考场上的取舍能力练成肌肉记忆。到了真实笔试节奏会比模考更紧张如果连模考都没练过先易后难正式考场上很容易前松后紧、满盘皆输。5.2 三模和 Python 等级考试难度不同基本功相通最近注意到 Python 等级考试比如 2025.3 那一期的一级编程题在编程学习圈子里热度很高。这类等级考试题目和牛客模考相比整体难度要低一些更侧重基础语法、简单逻辑和基本输入输出但两者在基本功层面是完全相通的变量命名是否规范、边界条件有没有考虑、输入输出处理是否高效这些习惯无论放在等级考还是校招笔试里都一样重要。如果你目前做三模的编程题还有明显压力完全可以先从等级考试级别的基础题入手把语法、循环、条件、基础数据结构彻底练熟再逐步升级到牛客模考的难度。基础不牢的人直接刷难题往往只是在背答案而不是在涨能力。反过来能把三模题目做顺的人再回头写等级考试的题会非常轻松因为思维层次已经完全不在一个级别了。5.3 最后分享一个自己的复盘习惯每次模考结束后我会把所有题的代码、错因、题解要点整理进一个单独笔记每道题记录四件事题目类型、当时卡住的原因、最优解的关键一步、重做后的耗时。过两周再翻回来做一遍错题重点感受这次能不能一眼看穿考点。这个习惯我在 2023 年三模之后坚持了很久效果非常直观你能清楚看到自己从看到前缀和就懵到一眼识别哈希优化的变化曲线。编程能力的提升没有捷径但复盘方法对了每一步都不会白走。如果你手头正好有三模的题目建议别急着追求满分先按上面的思路把每一道题真正搞懂。把一套高质量的模考题吃透比囫囵吞枣刷十套新题更有价值。这套卷子放在那里能从中挖出多少东西就看你愿不愿意多花那几个晚上。