有一个性能问题AI 编程代理替我们改过很多次代码却始终看不见数据结构选错了。上周我 review 一个模块提交记录写着“AI 优化性能”。改动看起来是很标准的优化加了 early return把重复计算的表达式抽成了函数注释也写得更完整。但压测报告里的红线还在。把 diff 继续往下翻问题其实藏在更底层代码在循环里反复调用一个 contains 方法在一个普通数组里做线性查找数据量几万条时就是 O(n²)。AI 代理把代码格式和抽象整理得很好却没有动数据结构。它不是不聪明而是“看不全”——一个真实运行系统里的数据规模、访问模式、边界条件、不变量恰恰是数据结构问题的真正藏身处。下面想拆开聊的是这种“看不见”发生在哪里、为什么会发生以及我们可以在工作流里做点什么。对正在学习和使用数据结构的开发者来说这个话题值得停下来想一想AI 可以帮你写链表、写排序、写树但如果它看不见运行环境的边界那些代码就只是“看起来正确的代码”。1. 它改好了代码却没有看见问题1.1 一个典型的“结构错配”场景假设有一个接口需要批量查询用户状态。用户的 ID 列表从上游传入内部需要用 ID 去一个用户表里找到对应的用户对象。用一段伪代码表示问题形态通常长这样def batch_query(user_ids, user_list): result [] for uid in user_ids: # 外层 O(n) user None for u in user_list: # 内层 O(n)整体 O(n²) if u.id uid: user u break if user: result.append(user.status) return result如果你只把这段代码贴给 AI 编程代理不回传任何数据量信息它会做什么根据实际使用体感很多情况下它会给出“看起来更聪明”的局部优化提前 break、用集合去重、把查找过程抽成独立函数甚至可能直接把里层循环改写成列表推导式。这些改动没有错但它们都没有解决核心问题。外层 1 万次循环内层 5 万次线性查找总操作次数仍然是 1 万乘 5 万。真正正确的方向是把 user_list 转成以 id 为键的字典把每次查找从 O(n) 变成 O(1)。这个案例很典型因为它说明了“数据结构问题”和“代码风格问题”的区别。AI 代理非常擅长处理后者而前者需要知道数据的规模、访问的频率、是否要求顺序、是否能容忍额外内存。这些信息并不在代码文本里至少不在一个独立函数的文本里。1.2 结构性成本三个看不见的层次从工程经验看数据结构问题带来的成本可以拆成三层。单点复杂度一次查找、插入、删除操作本身是 O(1) 还是 O(n)。这是最容易被 AI 看到的一层因为它直接对应一个具体操作。聚合复杂度一个看似只调用一次的操作实际处在循环里会被执行 N 次。局部看没问题全局看就是 O(n²)。这一层开始需要跨上下文理解。系统性成本连续访问下的缓存命中率、内存分配频率、并发锁竞争、序列化成本、容器失效规则。这一层往往要结合具体运行环境才能评估。AI 代理通常能处理第一层部分处理第二层第三层几乎完全依赖外部输入。但真正让我们在生产环境里感受到“慢”的恰恰是第二层和第三层。数据量增长、请求并发上来、GC 压力变大这些问题会从运行指标里冒出来而不是从静态代码里冒出来。所以“AI 看不见数据结构问题”真正看不见的其实是这些结构性成本。1.3 它不是“换个类型”那么简单把“数据结构问题”简化成“把数组换成哈希表”是很多人常见的误解。生产环境里一次结构改动可能牵动三个约束。顺序要求HashMap 不保证遍历顺序。如果需要按插入顺序返回就要额外使用有序结构或者在返回前重新排序。唯一性Set 能去重但去重时以哪个字段为准、保留第一条还是最后一条需要有业务规则。生命周期当一个容器被缓存、被多个线程共享、被长期持有它的更新策略和失效规则就变成了新的问题。AI 代理在生成单点代码时经常会把“能用某个容器”当成“应该用某个容器”忽略了这些附加约束。这也是为什么我们需要把结构