AI时代的程序员修养：AI 会写代码，但你要知道程序是什么

《AI时代的程序员修养》这个专栏，不打算把重点放在“哪个 AI 工具更会补全代码”。工具会变，模型会变，但程序运行的基本规律没有变。写代码的人还是得看得懂系统怎么拆、问题怎么描述、生成出来的东西该怎么验收。本文是第一篇，先从一句老话讲起：程序 = 算法 + 数据结构。这句话几十年前就写在教科书里，但在 AI 编程时代反而更重要。因为 AI 很擅长“把一句话变成一段代码”，但如果你没有把问题变成算法和数据结构，它生成的往往只是表面能跑的代码。那句老话一点也没过时很多人第一次听到“程序 = 算法 + 数据结构”，是在大学课堂、C 语言教材，或者 Pascal 时代的老书里。这句话听起来很朴素，甚至有点老派。现在我们写的是 Web 服务、移动应用、推荐系统、数据平台、Agent 工具链，好像已经离“算法题”和“链表树图”很远了。但只要把一个真实系统拆开，就会发现这句话还在底层撑着。一个订单系统，算法不是排序题，而是价格计算、库存扣减、优惠叠加、风控判断、状态迁移。数据结构不是手写红黑树，而是订单表、状态机、索引、事件日志、缓存 key、消息体。一个搜索系统，算法不是教科书里的二分查找，而是召回、过滤、排序、融合、去重、分页。数据结构不是抽象的数组和树，而是倒排索引、向量索引、文档结构、特征字段、评分结果。一个 AI Agent，算法不是“让模型想一想”，而是任务拆解、工具选择、失败重试、上下文裁剪、结果校验。数据结构也不是模型内部的 token，而是消息队列、工具 schema、执行记录、状态快照、可恢复的中间结果。所以“程序 = 算法 + 数据结构”不是在说程序员必须天天刷题。它说的是：程序不是一堆语句，而是数据如何被组织，规则如何作用在数据上。AI 可以帮你写语句，但它不能替你决定系统里的数据应该长什么样。先把这些老本行捡回来只说“算法和数据结构很重要”，基本等于没说。对已经工作、又开始大量使用 AI 编程的人来说，下面这些东西值得重新过一遍。不是为了回去刷题，而是为了在看到需求时，脑子里能自然浮现出合适的结构。知识点工程里常见的样子不懂时 AI 容易写错什么数组 / 动态数组分页结果、批处理缓冲区、时间序列点位频繁头部插入删除，隐藏 O(n) 移动成本哈希表去重、缓存、索引、按 ID 聚合key 设计不稳定，内存无限增长，忽略冲突和过期栈表达式解析、递归展开、调用链、撤销操作递归无深度保护，异常路径无法回滚队列 / 优先队列任务调度、消息消费、限速、延迟重试FIFO 和优先级混用，重试任务插回错误位置树评论、组织架构、权限继承、路由匹配全树递归查询，深层节点性能和栈深度失控图依赖分析、工作流、推荐关系、服务调用链不检测环，拓扑顺序错误，级联调用不可控堆Top K、超时管理、定时任务、排行榜近似维护全量排序代替局部选择，复杂度从 O(n log k) 变成 O(n log n)布隆过滤器黑名单、缓存穿透防护、大规模去重预判把“可能存在”当成“一定存在”，误判语义搞错LRU / LFU本地缓存、热点数据、连接池淘汰只会用 dict，不会限制容量，也不会维护访问顺序倒排索引搜索、标签筛选、日志检索每次请求全量扫描文本，再用字符串 contains 过滤状态机订单、任务、审批、支付、部署流水线状态随便改，没有迁移约束，没有非法状态保护这里暂时没有展开红黑树、B+ 树、跳表、LSM Tree 这些更偏底层实现的内容。它们当然重要，但第一步先把“会不会建模”这件事说清楚。等到后面讲数据库和高并发时，再谈 B+ 树为什么影响索引，LSM Tree 为什么影响写入和 compaction，跳表为什么常见于有序内存结构。放到 AI 编程里，重点不是手写一个完美的堆。重点是看到“取最近 5 分钟内延迟最高的 100 个请求”时，马上意识到不能让 AI 简单写sort(all_requests)。数据流可能很大，更合适的做法是流式处理，维护一个大小为 100 的最小堆；每来一个请求只和堆顶