《AI时代的程序员修养》这个专栏想讨论的，不是“AI 会不会替代程序员”，而是程序员在 AI 已经能写大量代码之后，还应该抓住哪些硬东西。第一篇从“程序 = 算法 + 数据结构”讲起，这一篇继续往下挖：数据结构在真实系统里到底长什么样。很多人一听数据结构，就想到链表反转、二叉树遍历、堆排序。那些当然有用，但工程里更常见的问题不是“会不会手写某个结构”，而是：你能不能看出这个业务其实需要队列、索引、状态机、事件日志或者一棵树。AI 可以照着你的描述写代码，但你得知道系统骨架该怎么搭。数据结构不是代码形状，而是访问方式数据结构的本质，不是某个类怎么写，也不是内存里指针怎么连。对工程系统来说，它首先是访问方式。你要按 ID 快速找到对象，通常会想到哈希表或数据库主键索引。你要按时间顺序处理任务，就会想到队列或日志。你要按层级展示评论、组织架构、权限继承，就会想到树。你要按关键词搜索文章、日志、商品，就会想到倒排索引。你要只保留最近访问过的数据，就会想到 LRU。这些结构一旦选定，系统的边界就跟着定了。比如同样是“保存用户操作记录”，可以有三种完全不同的骨架：结构常见实现适合的问题不适合的问题当前状态表user_state表，一行代表最新状态快速读取当前值追溯历史、审计、重放事件日志append-only log，每次操作追加一条审计、回放、异步消费直接查当前状态较慢状态表 + 日志状态表服务查询，日志服务追溯大多数业务系统写入路径更复杂如果只让 AI “实现用户操作记录”，它很可能给你一张表：create table user_actions ( id bigserial primary key, user_id bigint not null, action text not null, created_at timestamptz not null );这不是错，但它没有回答关键问题：这是审计日志，还是业务状态？是否允许修改？是否需要重放？是否需要按用户分页？是否会被其他服务消费？是否有保留周期？这些问题不说清楚，后面的代码都只是猜。哈希表：最快的路，也最容易失控哈希表大概是工程里最常见的数据结构。缓存、去重、按 ID 聚合、连接池、会话表、限流计数，背后经常都是哈希表。在 AI 生成代码里，哈希表最常见的问题不是不会用，而是太随便。例如做一个批量查询接口，需要把商品 ID 去重后再查数据库。AI 很容易写出这样的代码：def dedupe_product_ids(product_ids: list[str]) - list[str]: return