刷题刷到最后，我更确定：真正拉开差距的是这 5 种编程能力

刷题刷到最后，我更确定：真正拉开差距的是这 5 种编程能力

很多人看到我整理的coding，第一反应都会很直接：

“这不就是在刷题吗？”

如果只看目录，这么理解当然不奇怪。后面确实是一道道编程题，从两数之和、滑动窗口、链表、二叉树，到动态规划、图论、Trie、LRU 缓存，一路排到了107题。

但把这件事完整做下来之后，我反而越来越确定一件事：

真正拉开编程能力差距的，从来不是你刷了多少题，而是你有没有借这些题，把一套稳定的问题解决能力练出来。

这篇文章，我想认真把这件事讲清楚。

我后来不再把刷题当成“数量游戏”

我一开始也经历过那种很典型的刷题状态。

找一份热题清单，每天做几道；不会的时候看题解；看懂了就觉得“这题过了”；过几天再遇到一个变形题，又开始卡住。表面上看题在增加，实际上很多题只是短暂留在记忆里，并没有真正沉淀成方法。

后来我越来越不满意这种节奏。不是因为题不够多，而是因为每道题都像孤岛。

你可能做过两数之和，也做过无重复字符的最长子串，做过岛屿数量，做过零钱兑换，甚至看过 LRU 缓存的经典做法。但如果这些内容最后在脑子里只剩下“题号”和“答案”，它们对真实编程能力的帮助其实很有限。

所以我后来整理1.coding时，最在意的已经不是“还差多少题”，而是另一个问题：

这些题，能不能被组织成一条清晰的能力成长路径？

也正因为这个出发点，这107道题最后被归到了15个核心模块里。它不再只是一个题单，而更像一条系统训练路径。

这 5 种能力，才是我最想留下来的部分

如果只把编程题理解成面试准备，我会觉得有点可惜。因为当你真的把一套高频题系统走下来，最后被训练出来的，往往不是“会不会某一题”，而是下面这5种底层能力。

第一种，是模式识别能力。

真正有效的刷题，不是看到题先想“我做过没有”，而是先判断：这更像哈希表、双指针、滑动窗口，还是 DFS、BFS、DP。两数之和背后是互补查找，最小覆盖子串背后是窗口控制，岛屿数量背后是图搜索，零钱兑换背后是状态设计。你一旦开始用“模式”看题，题目之间就会被真正连起来。

第二种，是数据结构选择能力。

很多题最后拉开差距的地方，不是算法多花哨，而是你有没有先选对结构。什么时候该用dict做 O(1) 查找，什么时候该用set判存在，什么时候该用deque维护队列，什么时候该用堆处理 Top-K，什么时候必须上链表、树、图、Trie，这些判断会越来越敏感。写代码的人其实都知道，很多效率差距不是出在“写没写循环”，而是出在“信息怎么组织”。

第三种，是复杂度意识。

很多题如果只是追求“能跑通”，并不难。真正有门槛的是，你能不能在时间和空间限制里，把它写成一个更合理的解。为什么双循环不行，为什么有些题更适合哈希，为什么搜索题必须剪枝，为什么动态规划的状态设计一旦错了，复杂度就会直接失控。这些都不是题解末尾顺手一写的附属内容，它本身就是思考过程的一部分。

第四种，是从暴力到最优的优化链路。

这也是我后来特别重视的地方。我一直不太喜欢那种上来直接给最优解的题解，因为它会制造一种错觉，好像答案是凭空跳出来的。但真实思考从来不是这样。更自然的路径应该是：先接受最直观的暴力思路，再定位瓶颈，判断问题出在重复计算、查找效率、状态维护还是搜索空间，然后再选择合适的工具去优化。两数之和从双循环到哈希表，零钱兑换从爆搜到记忆化搜索或 DP，LRU 缓存从普通容器模拟到哈希表加双向链表，这条推导链本身就非常值钱。

第五种，是结构化表达能力。

很多人会忽略这一点，但我自己越来越看重。做到后面你会发现，真正拉开差距的，已经不是“能不能写出来”，而是“能不能讲清楚为什么这么写”。你能不能说明白性能瓶颈在哪，为什么这个结构合适，优化为什么成立，时间复杂度和空间复杂度分别是多少，题目一旦变形解法还能怎么改。这类能力，对面试有用，对日常开发、方案设计、代码评审也一样有用。

107 道题真正的价值，不是“题多”，而是能复用

如果只是想证明“我做过很多题”，其实根本没必要把这件事做得这么完整。

真正让我愿意持续整理下去的，是我越来越确信：一套内容的价值，不该只停留在“把答案写出来”，而应该尽量让每一题都变成一个可复用的训练单元。

所以我会尽量保留这些东西：

• 题目描述和约束条件
• 边界用例
• 从直觉解法到优化解法的推导过程
• 多解法对比
• 复杂度分析
• 面试现场该怎么讲
• 工程实战里它对应的意义

这也是为什么我会把107道题归到15个模块里去看。因为当题目变成结构化路径之后，你复习的就不再只是“上一题答案是什么”，而是“这一类问题该怎么拆、怎么选结构、怎么控复杂度、怎么解释方案”。

这和单纯积累熟悉感，是两件完全不同的事。

如果你现在也在刷题，我更建议这样用它

如果让我用现在的理解，给正在刷题的人几个更有效的建议，我会更推荐下面这套顺序：

1. 每做一道题，先别急着看答案，先判断它属于哪一类模式。
2. 写解法时，先想数据结构，再想代码流程。
3. 不要只记最优解，要把“从暴力到优化”的推导链自己走一遍。
4. 做完之后，试着不用代码，直接把思路讲给别人听。
5. 复习时按模块回看，不要按题号零散回看。

我后来越来越相信，真正有长期价值的刷题，不是把更多题做过一遍，而是把陌生问题变成熟悉方法。

前者更像记忆和熟练度，后者才更接近真正的编程能力。

所以现在如果再有人问我，这107道题最大的作用到底是什么，我大概不会只回答“面试高频题”。

我更愿意说：

它们是一套非常高密度的编程思维训练。

题目只是入口，真正被训练出来的，是你面对复杂问题时的反应方式。而这，可能才是刷题这件事最值得投入的地方。

如果这篇对你有用，可以顺着这条线继续往下看：

1. 完整代码和持续更新在 GitHub：
   https://github.com/tingaicompass/AI-Compass
2. 这类系统化长文，会继续更新在公众号「汀丶人工智能」
3. 更细的项目复盘、答疑和资料沉淀，会放在知识星球「AI-Compass」