前些天，我们在正在生产运行的虚拟化平台上增设了新的服务器节点。这项作业是与AI智能体（Claude）分工推进的，在此留下记录。

先说结论：角色分工契合得相当漂亮。但这并不是“交给AI就一切顺利”的故事。恰恰相反，避免了重大事故的那些判断，全部出自人这一侧。 这部分也一并写下来。

分工的实际情况 #

物理归人，逻辑归AI。粗暴地说就这么简单。不过正如后文所述，知道“哪里危险”的是人这一侧。

AI奏效的场面：工序量、重复、逐项比对 #

AI明显强的地方，是那些枯燥、量大、一旦出错就很痛的作业。

1. 版本的完全一致 #

既有集群的运维方式是严格统一全部节点的版本。新节点刚装完操作系统，软件包还是旧了好几代的状态。

如果简单地“更新到最新”，就会比既有集群还新，偏离运维方针。可要是指定特定版本，又会因为依赖关系无法解决而安装失败。

AI从错误信息中定位了原因（不把相关软件包一并指定的话，旧版本会残留并产生冲突／还把本不该在这个阶段安装的服务端组件牵扯了进来，卡在那里），最终收敛到与既有节点分毫不差的版本组合。这类试错要是让人来做，注意力根本撑不住。

2. 跨全部节点的差异校验 #

扩容之后，我们逐台确认了全部节点上共享存储的可见状态是否一致。台数越多，靠人力就越容易想用“大概没问题”糊弄过去的工序。

AI对全部机器执行同样的命令，整理成表格把差异列出来，这类作业它就这么一板一眼地做下去。结果是，新节点与既有节点处于完全相同的状态这一点，不是靠推测，而是靠实测确认下来的。

3. 在“两端”进行证据比对 #

在确认链路聚合（LACP）时，不只看服务器侧，还比对了交换机侧的状态。特别是，服务器侧看到的对端设备标识符，是否与预期的那台交换机一致，我们连这一层都确认了。要证明的不是“链路起来了”，而是“正与预期的对端、以预期的配置连接着”。

AI找出来的、不起眼但危险的东西 #

作业过程中，有几个是AI“没人让它找、但它找到了”的问题。

启动顺序里残留着旧操作系统的残骸 #

某台节点的UEFI启动顺序最前面，残留着以前安装过的另一个操作系统的启动项。它的实体在磁盘上并不存在，因此启动不了；再往后排着的又都是网络启动项，正确的那一项排在第7位。

就这么重启的话，会去找一个不存在的操作系统，再没完没了地等网络启动超时，运气不好还会启动到根本没打算启动的东西。能在重启之前发现，意义很大。

时间的连锁故障（这个最有意思） #

另一台节点上，软件包更新全部失败。报错是“仓库的信息尚未进入有效期（还差901天）”。

顺着追查下去，是这样一条连锁。

1. 硬件时钟（RTC）指着1998年（怀疑是电池没电了）
2. 操作系统判断为异常，把时间向前拨到了操作系统的构建时期（＝约2.5年前）
3. 时间同步的配置是参照互联网上的NTP服务器，但因为DNS设置坏掉了，无法解析参照目标，同步源为0个
4. → 时间一直停在2.5年前 → 软件包管理系统把仓库视为“来自未来的签名”而全部拒绝

“软件包装不上”的真正原因竟然是“DNS坏了”，这是一条跳了四级的连锁。修好DNS、重启时间同步之后，一瞬间就解决了。

而且这个问题要是放着不管，会在加入集群之后发作。 分布式系统对节点间的时间偏差很敏感，把偏差2.5年的节点放进生产集群，根本不用讨论。

配置在“无声地失败” #

负责做网络性能调优的那套机制，因为启动时对象还不存在，什么也没做就正常退出了。不会报错。日志上是成功。

AI从作业顺序上预判到了这一点并去做了确认，发现实际上确实没有生效，于是重新执行了一遍。“显示为成功，其实什么都没做”这类问题，靠人眼确认是最容易漏掉的。

人奏效的场面：这才是本质 #

从这里开始才是正题。这次，避免了致命事故的判断，两个都出自人这一侧。

1. “对接用的文件放置漏掉了” #

AI把作业项目整理了出来，但它把与外部系统对接所需的文件放置归类到了“最后才做的工序”。实际上，那道工序里唯独这个文件放置提前做也没有问题，反而应该提前做。

是人这一侧指出“漏了”，AI才第一次意识到自己的分类错误。要是没有这个指出，后面的工序就会绊住。

2. “得先在存储侧登记。不然看到的会前后不一” #

这个是最大的。

AI作为加入集群前的检查，把版本、网络、时间等项目列了出来，判断“准备完成”。但那里面，没有包含存储设备侧的访问许可登记。

人这一侧指出：“在登记之前就让它加入，共享存储在各节点之间的可见状态会对不上，可能引发严重的不一致”。

AI一查才发现，公司内部留有过去发生过完全相同现象的记录。当时是只有一台识别到存储、其他都识别不到，而且重启另一台节点时，连毫不相干的节点也被卷进去一起重启了。

要是没有这个指出，AI就会摆出一份工工整整的验证结果，然后径直撞进事故里去。

最终的做法是：事先登记好访问许可，在加入之前以非破坏的方式实测“从新节点看到的存储列表是否与既有节点完全一致”，确认后再让它加入，事故为零地完成了作业。

这两点的共通之处，是“来自经验的危机感”。AI能从眼前的信息推出自洽的结论，但“这个项目压根就不在清单上”这件事，它是察觉不到的。 知道什么该被写进清单里的，是吃过苦头的人这一侧。

AI犯的错（不隐瞒，照写） #

为了公平，AI的失败也一并列出。不写这部分的案例介绍，最好别信。

• 在操作手册里写错了顺序，还就这么带到了实机上。 配置的下发顺序写反了，直到在实机上报错才发现。所幸那道工序不影响通信，没有造成实际损害
• 自以为验证了，其实并没有验证。 配置的预检查明明返回了错误，却因为脚本写得不好而显示成了“OK”。事后自己申报并做了修正
• 把不是问题的东西当成问题嚷嚷。 只跟一台做比较就报告“配置对不上”。把全部机器都查了一遍才发现，反倒是新节点那边才是对的
• 明显不对劲，被人叫停了。 作业过程中，发生了AI对与上下文无关的话题作出反应、跑题的现象。人这一侧察觉到异常，让作业全面停止，确认状态之后才重新开始

最后这一点尤其重要。AI无法靠自己检测出自己的异常。 生产作业里，必须要有一个觉得“哪里不对劲”就能喊停的人。

收获：分工该怎么设计 #

把这次做得顺利的原因整理一下，是这样。

交给AI是对的那些 #

• 重复、逐项比对、全数确认（人容易用“大概没问题”跳过去的工序）
• 需要反复试错的依赖关系处理
• 一边留下证据一边验证
• 把作业内容反映到操作手册（做完马上就能写，所以不会过时）

该由人把关的那些 #

• 把什么写进清单（AI察觉不到没写进去的项目）
• 基于过去事故记忆的风险指出
• 叫停的判断
• 物理作业（这是当然的）

另外，对双方都同样奏效的，是“小步执行，每步都实测”这种推进方式。一台一台、一道工序一道工序，每次改动都用实测来确认。正因为有这个套路，无论是AI的错误还是人的疏漏，都在伤口还浅的时候被发现了。

结语 #

一说“AI搭建了基础设施”，可能会让人想象成人只是下个指令然后坐着的画面，但实际情况并非如此。

AI在人会丧失注意力的领域压倒性地强。人在AI结构上无法察觉的领域决定性地强。 当这两者咬合上的时候，就能达到只靠任何一方都到不了的质量。

还有，要把AI放进生产环境，就需要有能喊停的人。 这次它确实起了作用，这是这个案例里我最想分享的一点。