企业官网建设流程全解析

有一个性能问题，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 代理在生成单点代码时，经常会把“能用某个容器”当成“应该用某个容器”，忽略了这些附加约束。这也是为什么我们需要把结构