一句话核心AI 能把每个零件做对但它不知道你的数据要经过几条链路。而系统出问题往往就出在这几条链路的接缝处。一、上线之后系统挂了这次上线我原以为会是最顺利的一次。需求问得很清楚技术方案是 AI 给的代码也是 AI 写的流程文档一份不少测试也通过了。然后这个系统挂在了 Redis ClusterRedis 集群上。那一刻我才明白AI 能写出「单机能跑通」的代码但它不知道我们的 Redis 是集群部署的。后面我会讲到AI 在这个项目里一共漏掉了三个场景。有意思的是这三个场景看起来毫不相关但它们的成因是同一个。二、先交代背景这个需求在做什么先把背景讲清楚否则后面的坑不好理解。这是一个运营管理系统要新增一块「能力服务」的调用处理。三个关键概念能力服务可以理解成对外提供的一种调用能力。上游厂商这种能力背后由多家厂商提供我们记为 A、B、C。它们提供的是同一种能力只是来源不同。本次需求不再像以前那样固定只用一家而是按比例或按额度自动分流——比如 30% 的请求走 A或者 A 的额度用满之后自动切换到 B。三、这个需求里最难的不是方案拿到需求文档后我没有急着想技术方案而是先把四件事跟产品同事问死页面怎么配置配置是立即生效还是次日生效配置的调整记录要展示哪些信息能力服务的计算规则到底是什么这四问听起来很基础但它们才是这个需求真正的难点。原因在于AI 能回答「怎么做」但回答不了「我们到底要什么」。它不知道我们业务里那些从来没被写进文档的隐藏约定——运营改了配置线上正在跑的流量要不要立刻切换调整记录是给运营看的还是给审计看的这些问题AI 一个都替不了你问。这里要记住一句话「顺利」是最好的麻醉剂。这次需求问得太顺、方案定得太顺反而让我在后面放松了警惕。四、AI 的正确用法它铺开选项我保留决策需求理清之后我做了一件现在觉得挺对的事。我把需求文档和相关业务信息整理好一起交给 AI让它给出实现方案然后我在它给的多个方案里选出当前最优的那个。这里的关键是我没有让 AI 替我决策我只是让它把可能性铺开。决策权在我手里因为只有我知道我们真实的约束。接着我把整个实现拆成了三样东西实现文档、计划清单、设计文档。现在回头看恰恰是这套流程的严谨救了这次开发——设计阶段和主体实现都很顺利问题只出在下面这三个地方。五、AI 漏掉的三个场景场景 1Redis Lua 脚本没考虑集群我们用了一段 RedisLua 脚本一段在 Redis 内部原子执行的小脚本来做分流判断判断当前已经调用的比例、或者剩余额度从而决定这次请求该走上游 A、B 还是 C。这段脚本需要在 Redis 里同时读写好几个 key比如「比例计数」和「额度计数」。在单机 Redis上它工作得很好。但我们的 Redis 是Cluster集群。集群会把数据分片到不同的 **slot槽位**上规则是一段 Lua 脚本里操作的多个 key必须落在同一个 slot否则 Redis 会直接报CROSSSLOT错误。AI 写出的是一个「单机 Redis 假设」下完全正确的脚本。它不知道、也不会主动来问我们你们的 Redis 是集群的吗场景 2新字段只进了数据库没进缓存这次需求新增了一个字段。而这个系统有一个历史做法相关信息除了存进数据库还会在 Redis 里存一份做缓存。新版实现完之后这个新字段同步进数据库了但刷新缓存的时候没有带上它。这里有一个更隐蔽的地方这个系统有两处刷新缓存的逻辑——应用启动时刷一次定时器再周期性地刷一次。这两处都没有带上新字段。结果就是一部分读取路径拿到的是缓存里的旧结构对象而那个对象里根本没有这个新字段。场景 3缓存里的「配置标识」没跟着更新我们缓存了一份「能力服务具体调用哪个服务」的信息。改造前只能配一个上游所以缓存结构很简单。改造后要按比例/额度自动筛选上游就必须多存一个配置标识后续靠这个标识去找到对应的分流规则。问题是缓存这块的数据结构没有跟着改到位——缓存里存的还是旧的东西。于是程序靠配置标识去找规则时找不到。六、这三个坑其实是同一个坑你有没有发现这三件事表面上毫不相干——一个是 Lua 脚本、一个是缓存、一个是数据结构。但它们的成因是同一个它们都不是「代码写得对不对」的问题而是「数据在系统里怎么流转」的问题。那个新字段要从数据库流到缓存、从启动逻辑流到定时器中间经过好几条链路。那段Lua 脚本在单机世界和集群世界遵循的是两套完全不同的规则。那个配置标识从「一个上游」变成「多个上游」意味着所有读它的地方都得一起改。AI 看到的是「一个点」这段代码写得对不对。系统出问题的却是「一条链」这份数据要经过几个地方我改了一处剩下几处要不要一起改所以AI 擅长把每个零件做对但它不会替你想这些零件怎么连起来——因为它不知道你的数据流经几条链路。七、更值得警惕的地方不在技术上复盘时我找到了真正的问题。在我已经掌握的那部分需求上我给出了自己认可的方案。但在那些细枝末节上——缓存、数据同步、脚本边界——我太信任 AI 了。而危险恰恰在这里AI 给的方案太顺了顺到我不愿意再去怀疑它。顺利不是好兆头。顺利是警报。八、AI 时代该守住什么想清楚之后我给自己定了一条分工用 AI 拓展「想什么」用我自己守住「漏什么」。AI 负责广度快速给出一个看起来完整的方案把可能性铺开。我负责边界集群、并发、时序、缓存一致性——这些只有在真实运行环境里才会暴露的东西。九、总结把这次经历压缩成三条结论结论一AI 负责广度你负责边界。AI 的长处是快速铺开一个看起来完整的方案你的价值是判断这个方案在真实环境里站不站得住。结论二改动一份数据之前先画出它流经的所有链路。三个坑里有两个新字段、配置标识本质都是「改了数据库漏了缓存和刷新逻辑」。所以每次改动数据先问自己一句这份数据会经过哪几个地方结论三越顺利越要停下来查一遍边界。顺利是麻醉剂。方案太顺的时候恰恰是你最容易漏掉「细枝末节」的时候。一份可复用的「边界自查清单」AI 生成的代码上线前建议逐条过一遍数据一致性新增/修改的字段数据库、缓存、以及所有刷新链路启动时、定时器是否都覆盖了部署形态代码里有没有隐含的「单机假设」Redis 是集群吗数据库分库分表了吗服务是多实例吗时序启动时、定时器执行时、并发请求时逻辑还成立吗边界条件空值、超时、跨 slot、并发竞争都考虑了吗幂等与恢复失败重试、服务重启之后状态还正确吗在 AI 能写完大部分代码之后后端工程师的价值正好从 AI 看不见的地方长出来。AI 看不见集群。AI 看不见时序。AI 看不见你的数据流转过几条链路。而你看得见。