大模型可以自动补全函数、生成整段业务代码，于是一种声音开始流行：算法基础已经过时，复杂度分析更是应试时代的遗留物。事实恰恰相反。当写代码的门槛越来越低，判断代码好坏的能力就越来越值钱，而时间复杂度正是这种判断力最基础的语言。
一、AI 生成的代码，常常“正确但不快”
大模型擅长给出能跑通的答案，却不了解你的数据规模。让它写“在列表中找出重复元素”，它很可能顺手给出两层循环的解法：一百条数据毫无问题，百万条数据接口直接超时。同样的需求，换成哈希表一次遍历即可完成，时间复杂度从 O(n²) 降到 O(n)，性能差距会随数据量拉大到成百上千倍。
模型并不知道你的接口要扛多少 QPS、表里有多少行记录，这些约束只能由工程师补齐。如果看不出 O(n²) 和 O(n log n) 的区别，你就无法在代码评审中拦下那些“上线三天后开始超时”的实现——这类隐患，AI 通常不会主动替你提醒。
二、大模型自身就是复杂度问题的活样本
理解复杂度，还能帮你理解大模型为什么这么贵。Transformer 的自注意力机制在序列长度上是 O(n²)：上下文长度翻倍，计算量变为四倍，这正是长文本调用费用陡增的根本原因。
近年来流行的 Flash Attention、稀疏注意力、KV Cache 等优化，本质上都在做同一件事：降低有效复杂度，或者用空间换时间。阅读技术公告时，熟悉复杂度分析的人能迅速判断一项优化的真实价值；不熟悉的人只能停留在“据说变快了”的层面，难以评估它对自身业务意味着什么。
三、复杂度是工程决策的通用语言
系统设计中的多数取舍都可以归结为复杂度问题：加索引是用空间换查询时间，加缓存是用一致性风险换响应速度，分库分表是用架构复杂度换单表量级的下降。云账单的金额、接口延迟的承诺，最终都会落到这些量级判断上。
招聘同样如此。面试中的复杂度分析至今仍是基本功，并非刻意刁难，而是它能在几分钟内区分“会调用 API 的人”和“能对系统负责的人”。
四、把复杂度学成直觉，而不是背题
要让复杂度真正变成生产力，可以从三件事入手：

建立量级直觉：不必死记推导，但要能脱口而出常用结构的成本——哈希表均摊 O(1)、排序 O(n log n)、二分查找 O(log n)，并理解这些曲线随数据增长的变化。
读代码时随手估算：看到循环嵌套就问一句，数据扩大十倍会怎样？把这个习惯带进日常评审，比集中刷题更能形成敏感度。
用真实系统验证：借助性能剖析工具观察耗时分布，把纸面的 O 记号与实际的响应时间、CPU 曲线对应起来，同时理解常数因子、缓存命中率同样影响真实表现。

工具会不断更替，代码也许会由 AI 写出大半，但“这段代码在数据增长后会发生什么”这个问题，始终需要有人回答。时间复杂度提供的正是回答它的语法——这也是它在大模型时代依然值得每个程序员认真修炼的原因。