AI都能写代码了，为什么资深开发还在死磕算法？

在实际开发中，数据结构与算法真的那么重要吗？

我写 iOS 写了快十年，最近一年基本上大部分代码都是 AI 帮我写的。前两天用 Claude Code 重构一个消息列表模块，它把 reloadData() 全部替换成了基于 DifferenceKit 的增量更新，列表滑动流畅度肉眼可见地提升。我当时的第一反应是"这玩意儿真好用"，第二反应是"等等，这底层跑的是 Paul Heckel 1978 年论文里的 diff 算法，时间复杂度 O(n)，我要是不知道这个，我怎么判断它改得对不对？它会不会在某些边界条件下把 cell 的顺序搞乱？"

这个问题在我脑子里转了好几天。后来我把这个模块的代码手动过了一遍，发现 AI 在处理一个带有嵌套 Section 的场景时确实漏掉了一个 hashValue 的实现，导致某些极端情况下更新不生效。如果我不知道 diff 算法需要元素满足 Hashable 和 Equatable 协议，这个 Bug 上线后可能要花好几个小时才能定位。

CRUD 真的用不到算法吗？我觉得这个说法本身就有个认知陷阱。你不是用不到，你是每天都在用，只是你没意识到。

你以为你在写 CRUD，其实每一行代码都在调用算法

先说一个很多人没意识到的事实。你写一条 SELECT * FROM users WHERE id = 12345，觉得自己在做最简单的 CRUD 操作对吧？但这条查询到达 MySQL InnoDB 引擎之后，发生的事情远比你想象的复杂：引擎沿着 B+ 树索引从根节点开始二分查找，通常只需要 2-4 次磁盘 I/O 就能定位到目标行。为什么是 2-4 次？因为 B+ 树的非叶子节点只存指针不存数据，单个 16KB 的页能塞下上千个指针，这让整棵树变得极其"矮胖"。所有数据都存在叶子节点，叶子之间还用双向链表串联，天然支持范围查询。实测数据显示，三层 B+ 树在单行 0.9KB 时极限可存约 2100 万行，单行 5KB 时降至 285 万行。这也是阿里巴巴 Java 开发手册建议"单表超 500 万行推荐分库分表"的底层原因。

说白了，你写的每一条 SQL 查询，底层都是一次 B+ 树遍历。你不需要手写 B+ 树，但当你遇到慢查询需要做索引优化的时候，不懂 B+ 树就等于在黑箱面前瞎猜。你不知道为什么联合索引要遵守最左前缀原则，不知道为什么 LIKE '%keyword' 走不了索引，不知道为什么 ORDER BY 某些情况下需要回表。这些都是 B+ 树的结构特性直接决定的行为。一位 Web 开发者在博客里写过，他给一个字段加了单列索引后，报告查询从 45 秒降到 0.2 秒，差了 225 倍。IBM FileNet P8 的案例更夸张，添加 B-Tree 索引后事务响应时间从 7000ms 降至 200ms。2025 年发表的一项学术研究系统性地验证了：优化索引使受影响查询性能平均提升 67%，定期审查执行计划在 47% 的关键查询中发现了优化机会，后续优化平均减少 58% 响应时间。

这还只是数据库。你用 Redis 做缓存，它的内存淘汰策略底层是近似 LRU 采样算法。教科书上的标准 LRU 需要维护一个全局双向链表，每次访问都要把节点移到链表头，在 Redis 这种每秒处理十万级请求的系统里开销太大。所以 Redis 的做法是给每个 key 用 24 位存一个 LRU 时钟，淘汰时随机采样 N 个 key（默认 maxmemory-samples=5），从中挑最久没碰过的删掉。Redis 3.0 还引入了候选淘汰池进一步提升精度。Redis 4.0+ 的 LFU 实现更精巧：复用同一 24 位空间，高 16 位存最后衰减时间，低 8 位用 Morris 概率计数器（一种对数计数器），仅 8 位就能表示天文数字级别的访问频率。这个设计在幂律分布的访问模式下（热点数据被反复访问）显著优于 LRU。

你用 Kafka 做消息队列，消息定位依赖二分查找加稀疏索引：Segment 文件以 base offset 命名，查找时先对文件名做 O(log n) 二分查找锁定目标 Segment，再通过稀疏索引精确定位。加上零拷贝（sendfile 系统调用）和顺序写入（磁盘顺序写性能可达 600MB/s），Kafka 才实现了惊人的吞吐量。你用 Nginx 做负载均衡，一致性哈希用的是 Ketama 算法，每个真实节点映射 weight × 160 个虚拟节点到哈希环上，添加或删除节点时只需迁移相邻节点的流量。你用 Elasticsearch 做搜索，倒排索引配合 BM25 算法做概率排序，BM25 在 TF-IDF 基础上引入了词频饱和曲线，同一个词重复出现的贡献递减。你用 etcd 存 Kubernetes 元数据，背后是 Raft 共识算法，斯坦福实验中 33/43 名学生能理解 Raft，只有 10 人能理解 Paxos。

换句话说，你每天都在用算法，只是框架帮你封装好了。但框架是个黑箱，一旦出问题需要你掀开盖子，里面全是数据结构。

移动端开发同样跑不掉。我自己做 iOS 最有体感的场景是列表更新。iOS 的 UICollectionView 高效更新依赖 diff 算法，Apple 在 iOS 13 引入的 NSDiffableDataSource 底层就是这个东西，Instagram 开源的 IGListKit 用的是 Paul Heckel 1978 年论文里的 diff 算法，时间复杂度 O(n)。不用 diff 直接 reloadData() 的性能损耗能到 47%，在长列表场景下用户能明显感受到掉帧。Auto Layout 基于 Cassowary 增量线性约束求解（单纯形法的增量版本），约束变化时不从头算，直接增量更新。SDWebImage 的二级缓存是经典的内存 LRU 加磁盘 MD5 哈希。iOS 事件分发用的是逆序深度优先的 hit-testing。这些东西你平时用 UIKit 的时候根本不需要关心，但当你发现某个页面 CPU 打满、滑动卡顿的时候，不懂这些就只能对着 Instruments 干瞪眼。

前端也一样。React 的 Reconciliation 把传统 O(n³) 的树 diff 压到了 O(n) 的启发式 diff。React Fiber 架构用链表替代递归栈，把渲染拆成可中断的增量单元，支持五级优先级调度。连 Linux 内核的进程调度器 CFS 都在用红黑树，以 vruntime 为 key 取最左节点做调度，选红黑树是因为插入删除最多 2-3 次旋转，比 AVL 树更适合频繁的进程创建销毁。Redis 的有序集合选择跳表，作者 antirez 的理由是跳表更容易实现和调试，而且每个节点平均指针数仅 1.33（平衡树需要 2）。

前 Uber 工程师 Gergely Orosz 分享过一系列他在工作中实际用到算法的案例：在 Skype Xbox One 应用中用 BFS/DFS 构建导航框架，在 Skyscanner 用加权图加 A* 算法算最便宜的多城市航班组合，在 Uber 为六边形地理索引 H3 创建了定制数据结构。他说哈希表是他日常用得最多的东西，从计数到去重到缓存，一路用到分布式系统的分片。

所以问题的核心在于：你以为 CRUD 用不到算法，但你有没有意识到你一直在用？那接下来一个更现实的问题：AI 都能写代码了，你还需要自己懂这些吗？

AI 能写算法，但你得能看出它写错了

先看数据。2025 年发表在 ACM TOSEM 的大规模评测对 LeetCode 全部 2033 道题测试 GitHub Copilot，结果是：Easy 通过率 89.3%，Medium 72.1%，Hard 只有 43.4%。Java 表现最好达到 57.7%，Python 只有 41.0%。另一项 arXiv 研究对比 ChatGPT、Codeium、Copilot 在 300 道题上的表现，所有工具在 Hard 题上都出现断崖式下降，调试成功率最高的 ChatGPT 也只有 42.5%。2026 年 3 月的基准测试显示 Claude Code 在 SWE-bench Verified 上得分 80.8% 领先行业，Cursor 在简单任务上完成时间快 12%，但 Claude Code 使用的 token 比 Cursor 少 5.5 倍。

其实吧，通过率还不是最要命的。CodeRabbit 2025 年 12 月的报告分析了 470 个真实开源 PR 后发现：AI 生成的代码平均每个 PR 产生 10.83 个问题，人类是 6.45 个，差了 1.7 倍。其中逻辑和正确性错误多 1.75 倍，安全问题多 1.57 倍，性能问题多 1.42 倍，过多 I/O 操作问题高达 8 倍，不安全对象引用高 1.91 倍。Cortex 2026 基准报告进一步确认了这个趋势：PR 数量每人增长 20%，但每 PR 事故率上升 23.5%，变更失败率上升约 30%。说白了就是：更快了，但质量更差了。

最让我震撼的是 METR 2025 年 7 月的随机对照实验：16 名经验丰富的开源开发者完成 246 个真实任务，使用 AI 工具（主要是 Cursor Pro 配 Claude 3.5/3.7）的那组完成时间反而增加了 19%。但他们自己觉得快了 20%。认知和现实的差距接近 40 个百分点。这个实验结果让整个行业都停下来想了想：AI 给你的"效率提升"有多少是真实的，有多少是错觉？你把写代码的时间省下来了，但花了更多时间在理解 AI 生成的代码、审查潜在问题和修复那些看上去对但跑起来有坑的逻辑上。

Stack Overflow 2025 开发者调查覆盖了 49000 多名开发者和 177 个国家，数据很有意思：84% 的开发者在用或打算用 AI 工具，但 46% 不信任 AI 输出的准确性，只有 3% 表示"高度信任"。2024 年这个不信任比例才 31%，一年之间涨了 15 个百分点。经验越深信任越低，资深开发者"高度信任"仅 2.6%。66% 的开发者说花了更多时间修那些"几乎对了但不太对"的 AI 代码，72% 表示 vibe coding 不是他们的专业工作方式。JetBrains 2025 调查显示 85% 开发者定期用 AI 工具，但 Opsera 的数据揭示了一个关键不对称：资深工程师从 AI 获得的生产力提升是初级工程师的近 5 倍。

倒是这个"5 倍差距"给了我最大的启发。你猜为什么资深工程师用 AI 更有效？因为他们知道什么是对的，所以能在 AI 出错的时候立刻发现问题。他们审查 AI 生成的排序逻辑时，一眼就能看出时间复杂度是不是跑偏了。他们评估 AI 建议的缓存策略时，知道 LRU 在什么场景下不如 LFU。换句话说，AI 是 Copilot 不是 Autopilot，你的算法底子越厚，它在你手里就越像力量倍增器。你啥都不懂，它就是一台生产 Bug 的加速器。

那有人要问了：既然实际工作中算法以"被封装"的形式存在，面试为什么还要考你手写算法？这个割裂是真实的吗？

面试考算法这件事，确实有问题，但问题出在考法上

2015 年，Homebrew 的创造者 Max Howell 发了一条推文，大意是：Google 90% 的工程师都在用我写的软件（Homebrew），但我不能在白板上翻转二叉树，所以被拒了。这成了技术面试史上被引用最多的吐槽。Howell 后来在 Changelog 播客里补充说，Google 的面试像是"陪审团义务"，面试官从题库随机抽题，对候选人的真实能力毫无针对性。他说的那句话我印象很深："学怎么做这些只需要 Google 一下就行了。"

两年后 Ruby on Rails 创始人 DHH 也发了类似的推文：我叫 David，我不会在白板上写冒泡排序，我一直在网上查代码，我不做谜题。这引发了一场全球开发者的"忏悔运动"，一位 Google 30 年经验的技术负责人承认自己需要查 Python 字符串长度怎么取。DHH 把这种面试方式称为"白板算法霸凌"。

数据也站在批评者这边。北卡罗来纳州立大学 2020 年的研究（发表于 ACM ESEC/FSE）做了一个精巧的对照实验：48 名 CS 学生分两组，一组在面试官面前写代码，一组在私人房间独立解题。被面试官注视的那组表现下降超过一半。更惊人的是，公开面试中所有女性参与者都失败了，私人面试中所有女性都通过了。研究者的结论是白板面试可能实质上在评估焦虑水平。HackerRank 2025 报告（13732 人，102 国）给出了最直接的数字：78% 的开发者认为面试评估不反映实际工作，56% 认为算法题与工作无关，96% 认为问题解决能力比死记硬背更重要。Google 自己的 People Analytics 团队也承认过"面试分数与工作表现零相关"，脑筋急转弯题"完全是浪费时间"。

但这里有个微妙的地方。面试考算法确实有问题，不过问题出在考法上，不完全在"考算法"这件事本身上。百分之 99 的程序员工作中并不需要直接使用复杂算法，搞分布式、云计算基本也用不到。但大厂为什么仍然考？因为一场面试可能只有一小时，算法题是短时间内考察候选人计算思维和代码能力的最高效方式。问题在于很多公司把"最高效"当成了"唯一"，从字节跳动那种自我介绍后直接上编程题、每轮 1-2 道要求 bug free 的极致风格，到一些中小公司直接照搬大厂题库不考虑岗位匹配度，这中间的考法差异才是问题的根源。

改革确实在发生。Stripe 让候选人用自己的笔记本和互联网做实际编码调试，Slack 用一周技术练习加架构讨论取代白板，OpenAI 面试以生产实际问题为核心不考教科书算法，Mozilla 深度讨论过往技术挑战不做现场编码。GitHub 上 hiring-without-whiteboards 项目已经收录了数百家采用替代方案的公司。2025 年海外大厂的趋势是系统设计权重显著上升，中级工程师也开始被考 System Design，但纯算法题并没有消失，Google 甚至在加码，LeetCode Hard 已成面试常态。另一个有意思的变量是 AI 作弊：Amazon 面试官发现 50% 候选人在测试中使用 AI 工具，这正在倒逼更多公司恢复现场面试，面试重心从"能不能写出来"转向"能不能讲清楚背后的推理过程"。

面试的争论可以永远吵下去。但有一件事在争论双方那里其实有共识：算法思维本身是有价值的，分歧只在于考察方式。那算法思维到底值在哪里？

算法思维是一种通用的分析性思维框架

2006 年，卡内基梅隆大学教授 Jeannette Wing 在 Communications of the ACM 发了一篇后来被引用超过 48000 次的论文"Computational Thinking"，核心论断是：计算思维是每个人的基本技能，在阅读、写作和算术之外，应该加入每个孩子的分析能力。她在 2010 年的后续演讲里举了大量生活案例：孩子丢了手套你建议原路返回找，这是回溯；早上往书包里装当天要用的东西，这是预取和缓存；超市排哪条队，这是多服务器系统的性能建模；什么时候该从租雪板改成买一副，这是在线算法。CMU 计算机系主任 Randy Bryant 甚至通过精心设计站位让毕业典礼变成了高效的流水线。

这不只是学术观点。全球教育体系已经以政策形式确认了计算思维的基础地位：美国 2016 年推出 CS for All 倡议，中国 2022 年教育部将"信息技术"更名为"信息科技"并把计算思维纳入国家课程标准，英国最早用计算思维课程替代了传统 ICT 课程。2006-2023 年间 Web of Science 相关文献达 3212 篇，呈持续增长态势。Steve Jobs 1995 年那句"这个国家的每个人都应该学习编程，因为它教你如何思考"在近三十年后被各国教育部门不断验证。

我自己对算法思维最深的体感倒是来自本科。我是化工专业出身，学化工反应动力学的时候，老师反复强调的核心方法就是控制变量法：改一个变量，观察结果变化，排除其他干扰因素。后来我转行做 iOS 开发，发现 Debug 的时候本能地在用同样的方法。线上 crash 了，SIGABRT 信号指向某个 ViewController，但 crash 日志不明确。我怎么排查？注释掉一半代码看还崩不崩，如果不崩了说明问题在被注释掉的那一半，再继续对半分。说白了这就是二分搜索。你在调试的时候做的事情和你在 LeetCode 上写二分查找的时候做的事情，底层思维模型是同一个。我后来甚至发现，我做人生决策的时候也在用控制变量。要不要读硕士？变量是什么？学历对求职的影响、时间成本、经济成本。先固定其他变量，单看"学历对求职的影响"这一个因素：211 结业证和 985 硕士在简历筛选阶段的通过率差距有多大？这个思路和化工实验里改变催化剂浓度观察反应速率变化，本质上完全一样。

跨越半个世纪，几位大师殊途同归地指向了同一个结论。Frederick Brooks 1975 年在《人月神话》里写过：给我看你的数据表，我通常就不需要你的流程图了，一切都是显而易见的。Rob Pike 1989 年在"Notes on Programming in C"第五规则里说：数据主导，如果你选对了数据结构并组织得当，算法几乎总是不言自明的。Linus Torvalds 2006 年在 Git 邮件列表里更直接：坏程序员操心代码，好程序员操心数据结构和它们之间的关系。一位工程师印证了这个观点，说他参与过一个项目，花了很长时间优化一个复杂算法，后来发现通过重构数据结构可以消除整类问题，把一个 500 行的函数替换成了 50 行函数加一个设计良好的数据结构。

Dijkstra 在 1972 年图灵奖演讲中说的那句"计算机科学之于计算机，正如天文学之于望远镜"到今天还被反复引用。他还说过："编程，剥去所有偶然的无关因素后，归结为非常有效的思维。"Knuth 的"过早优化是万恶之源"几乎每个程序员都听过，但后半句"我们不应放过那关键的 3%"很少有人提。什么时候该优化什么时候不该优化，这个判断本身就需要你对算法复杂度有直觉。

所以，算法到底重不重要

回到最初的问题。在实际开发中，数据结构与算法真的那么重要吗？

我的判断分三层。第一层，你以为你在写 CRUD 用不到算法，但你的每条 SQL 查询都在跑 B+ 树，你的每次缓存命中都在执行 LRU 采样，你的每个列表更新都在跑 diff 算法。不是用不到，是框架帮你封装了，你感知不到。当你需要做性能调优的时候（一个索引优化可以带来 225 倍提升），当你需要做架构选型的时候（Twitter 的混合扇出策略直接决定系统能不能用），当你需要排查线上问题的时候（Redis 内存满了你得知道 LRU 和 LFU 的区别才能选对淘汰策略），这些知识就是区分不同级别工程师的核心武器。

第二层，AI 时代没有让算法变得不重要。说白了，它把算法的价值从"手写代码"转向了"理解、审查和决策"。AI 写的代码缺陷率是人类的 1.7 倍，Hard 题通过率只有 43.4%，资深工程师从 AI 获得的提效是初级的 5 倍。你懂得越多，AI 越好用。你啥都不懂，AI 给你的就是一堆看起来对但跑起来不确定对不对的代码，你还没有能力判断。

第三层，算法思维超越代码本身。分治、动态规划、回溯、控制变量，这些思维方式在项目管理、投资决策、科学研究中同样适用。全球教育体系用政策确认了这一点。从 Wing 的计算思维到 Dijkstra 的"计算机科学之于望远镜"，从 Torvalds 的"好程序员操心数据结构"到 Jobs 的"编程教你如何思考"，半个世纪的大师共识在说同一件事。

V2EX 上有个建筑师类比我觉得说得很到位：想当建筑设计师就得系统学习底层知识，想当建筑工人就熟练使用工具就行。你对自己的定位是什么，决定了算法对你重要到什么程度。

不是每个人都需要手写红黑树。但每个人都能从"把大问题拆成小问题、缓存已有解、在约束中寻找最优"的思维方式中获益。这才是算法真正的价值。