和一个做后端的朋友打球，这哥们吐槽了件事：面试一个候选人，简历上写着"熟练使用AI辅助编程，效率提升300%"，结果白板写一道二叉树遍历，卡在那儿五分钟没憋出来。朋友说：“我不是要为难他，我是真的好奇——他离开AI，还剩下什么？”

这个问题还是挺现实的哦。如今GPT、Claude这类模型现在写代码、刷力扣方面，正确率已经相当能打，中等难度题基本手到擒来。于是一个很自然的疑问冒出来：模型都会做算法题了，我还有必要学吗？

反方：算法是不是要被AI替代了？

先说说"不用学"这一派的道理，其实站得住脚。

你让Claude写一个快速排序，它几秒钟给你一个干净的实现，还能顺便讲清楚为什么平均复杂度是O(n log n)。

日常业务代码里，什么去重、排序、简单DP，AI基本能一把梭。这就像计算器出现之后，没人再要求财务人员手工开平方根——工具足够好用时，底层技能的"手动挡"确实会贬值。

更激进一点的说法是：过去我们花大量时间刷题、背模板，本质上是在训练一种"人肉编译器"式的技能：

——把问题翻译成代码的手速和熟练度。而这恰恰是大模型最擅长的事情。它不会累、不会紧张、见过的题库比任何人都大。继续死磕"手写能力"这件事，某种程度上是在跟机器比谁打字快，这场竞赛人类大概率要输。

如果算法学习的意义只是"能写出正确代码"，那这个意义正在快速缩水。

正方：AI写的代码，你敢直接上线吗？

但反方漏了一个关键环节：AI生成代码的正确率不是100%，尤其是复杂逻辑。

举个例子，让AI写一个"最长递增子序列"的动态规划解法，很多时候会拿到这样的代码：

def lengthOfLIS(nums):
    n = len(nums)
    dp = [1] * n
    for i in range(1, n):
        for j in range(i):
            if nums[j] < nums[i]:
                dp[i] = dp[j] + 1  # bug：漏了 max 比较
    return max(dp)

这个代码看着挺像回事，但这里有个隐蔽错误：
dp[i] = dp[j] + 1 应该是 dp[i] = max(dp[i], dp[j] + 1)。如果不加这个max，遇到多个j满足条件时，后面的更新会把之前更大的dp[i]覆盖掉，导致结果偏小。

这种bug不报错、不崩溃，测试用例简单时甚至能"侥幸"通过，等真实数据跑起来悄悄给你返回错误答案。

如果你不懂DP的状态转移逻辑，你根本发现不了这个问题。这才是核心矛盾：AI能生成代码，但你需要具备算法能力才能校验这段代码对不对。生成能力已经过剩，稀缺的是校验能力。

更麻烦的还在后面：这类bug往往不会在小规模测试里暴露。

你本地跑几个例子全部通过,上线之后遇到某种特定分布的数据才炸,而这时候排查成本比自己从头写一遍还高。

所以"不用学算法"这个说法,省略了一个前提——你得先有能力判断AI什么时候在胡说八道,才谈得上"用AI替代手写"。反方说的没错,人类打字速度确实拼不过模型,但这从来不是算法能力的核心,判断力才是。

真正的问题：我们问错了问题

其实"要不要学算法"这个提法，本身就有点像在问"有了打字和语音输入，还要不要学写字"。答案显然不是简单的是或否，而是要拆开看：学什么、学到什么程度、为了什么。

我把"算法能力"拆成两层：

• 第一层：编码熟练度——手写快排、写个二分查找的具体代码。这一层正在被AI快速替代，机械记忆题型的边际价值确实在下降。
• 第二层：建模与复杂度分析能力——面对一个新问题，能不能识别出它的本质结构（这是图论问题还是背包问题）、能不能估算解法的时间空间开销、能不能判断AI给出的方案有没有漏洞。这一层不但没贬值，反而因为AI的介入变得更重要——毕竟你现在要审核的代码量，比自己纯手写时更大了。

所以别再纠结"要不要学"，真正该问的是"该把力气花在哪一层"。

实战中的建议：三个场景，三种打法

场景一：面试/校招。 规则没变，该刷题还得刷。白板写代码、追问思路的形式，AI暂时插不上手，这依然是最直接的能力信号。

场景二：日常写业务代码。 大胆让AI来写，但你得能一眼看出问题。比如同样是二分查找，AI偶尔会给出这种版本：

def binary_search(arr, target):
    left, right = 0, len(arr)
    while left < right:
        mid = (left + right) // 2
        if arr[mid] == target:
            return mid
        elif arr[mid] < target:
            left = mid + 1
        else:
            right = mid
    return -1

乍看没问题，但right初始化成len(arr)还是len(arr)-1，配合left < right还是left <= right，这几个边界的组合稍微改一个都可能出界或漏判。没有踩过这些坑，你审这段代码时很难心里有底。

场景三：系统设计/架构。 这里比拼的是"如何拆解问题、怎么估算复杂度、方案能不能撑住量级",这恰恰是算法思维的核心价值，和背题关系不大，和AI也没啥关系——这是纯粹的人类判断力。

一句话总结：AI在帮你打字，但没法替你判断对错。

我的想法

有个问题我也没想明白：如果十年后AI真的连边界条件都不会错了，"你得懂算法才能校验AI"这个论点还成立吗？

也许到那时候，判断力本身也会被重新分工——就像现在没人再要求程序员懂晶体管一样，也许未来"审代码"这件事也会被更上层的工具接管。但那是十年后的问题。眼下这几年，模型犯错的方式还挺"人性化"的：看着对，细节错，需要一个懂行的人一眼识破。这个窗口期还在，能不能接住，取决于你现在还愿不愿意花时间弄懂一道DP题背后的逻辑,而不只是让AI帮你把答案生成出来。

这游戏才开始，后面真么样相当不明确。你怎么看？评论区聊聊。