一句话核心：AI 能把每个零件做对；但它不知道你的数据要经过几条链路。而系统出问题，往往就出在这几条链路的接缝处。
一、上线之后，系统挂了
这次上线，我原以为会是最顺利的一次。
需求问得很清楚；技术方案是 AI 给的；代码也是 AI 写的；流程文档一份不少；测试也通过了。
然后，这个系统挂在了 Redis Cluster（Redis 集群）上。
那一刻我才明白：AI 能写出「单机能跑通」的代码，但它不知道我们的 Redis 是集群部署的。
后面我会讲到，AI 在这个项目里一共漏掉了三个场景。有意思的是，这三个场景看起来毫不相关，但它们的成因，是同一个。
二、先交代背景：这个需求在做什么
先把背景讲清楚，否则后面的坑不好理解。
这是一个运营管理系统，要新增一块「能力服务」的调用处理。三个关键概念：
- 能力服务：可以理解成对外提供的一种调用能力。
- 上游厂商：这种能力背后由多家厂商提供，我们记为 A、B、C。它们提供的是同一种能力，只是来源不同。
- 本次需求：不再像以前那样固定只用一家，而是按比例或按额度自动分流——比如 30% 的请求走 A；或者 A 的额度用满之后，自动切换到 B。
三、这个需求里，最难的不是方案
拿到需求文档后，我没有急着想技术方案，而是先把四件事跟产品同事问死：
- 页面怎么配置？
- 配置是立即生效，还是次日生效？
- 配置的调整记录要展示哪些信息？
- 能力服务的计算规则到底是什么？
这四问听起来很基础，但它们才是这个需求真正的难点。
原因在于：AI 能回答「怎么做」，但回答不了「我们到底要什么」。它不知道我们业务里那些从来没被写进文档的隐藏约定——运营改了配置，线上正在跑的流量要不要立刻切换？调整记录是给运营看的，还是给审计看的？
这些问题，AI 一个都替不了你问。
这里要记住一句话：「顺利」是最好的麻醉剂。这次需求问得太顺、方案定得太顺，反而让我在后面放松了警惕。
四、AI 的正确用法：它铺开选项，我保留决策
需求理清之后，我做了一件现在觉得挺对的事。
我把需求文档和相关业务信息整理好，一起交给 AI，让它给出实现方案；然后我在它给的多个方案里，选出当前最优的那个。
这里的关键是：我没有让 AI 替我决策，我只是让它把可能性铺开。决策权在我手里，因为只有我知道我们真实的约束。
接着，我把整个实现拆成了三样东西：实现文档、计划清单、设计文档。
现在回头看，恰恰是这套流程的严谨，救了这次开发——设计阶段和主体实现都很顺利，问题只出在下面这三个地方。
五、AI 漏掉的三个场景
场景 1：Redis 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 看不见你的数据流转过几条链路。
而你看得见。
