几个月前我开始让 LLM 碰我的 MikroTik 设备。先交代一下我的成分：业余网络管理员，给朋友办公室和自己工作室配配路由，真让我考个正经的路由工程师认证，不认真复习肯定过不了。所以每次配新东西，我都是边查 wiki 边配。最近朋友办公室换路由，几个 VLAN、guest Wi-Fi 隔离、防火墙、几条 NAT 规则，我上次手搓这种配置还是两年前，配到一半卡在 bridge filter 里出不来。我说，反正现在 LLM 什么都会，让它来。
开始是真顺。Interface 建了，地址加了，路由通了。我甚至有点飘——它比我会配多了。
先停一下，问个问题：它真的比我会配，还是只是配得比我快？
我注意到问题是从它读 SSH 输出开始的。比如它要确认某个 bridge 的端口列表，会读到一行 0 192.168.88.254 bridge，然后把开头的 0 当成接口编号——其实那只是一行的序号。这种错不致命，但每次都要我盯一眼，不然它就带着错误信息继续往下配。
我一开始以为是它不够聪明。后来才想明白，问题不在它，在 SSH 本身。那是个给人类眼睛设计的界面，每行输出都靠人脑补全上下文，靠空格对齐、靠你脑子里已经有的那张网络地图去理解。你逼一个模型假装人脑去读这个界面，它当然会读漏。
再往下呢？既然问题出在接口，为什么不换掉接口？
于是我把配置通道都改成了 REST/JSON API。JSON 有结构，字段名写着是什么意思，不用猜。小错误确实少了。但换接口只是把"读错"的概率往下压了一层——没把"配错"的概率压下去。后面这个才是真正要命的地方。
我干过一件现在想起来脸有点热的事：给 Claude Code 开了 dangerously-skip-permissions，让它直接改设备配置。它配完，ping 通了，DHCP 正常发地址。我登进去扫一眼，井井有条。差点就说"搞定"。
然后我 /export 了一份。在 firewall 里发现一条我从来没让它加的规则：
/ip firewall filter
add chain=input action=drop protocol=icmp in-interface=WAN
单看这条规则，没错，甚至是很标准的"安全加固"。但它是错的——那办公室有远程设备要 ping 进来做健康检查，我故意没封 WAN 上的 ICMP。它加这条规则的原因我大概猜得到：训练数据里铺天盖地的安全指南都说 WAN 禁 ping 是标准操作，它顺手帮我补上了"我该做而没做的事"。
它不是在犯傻。它在做它最擅长的事——输出"看起来对"的东西。
这层的答案是：它配错的地方，恰好是它最自信的地方。它不是根据"你这个网络"在配，是根据"它见过的所有网络"在配。这两者之间有条缝，平时看不见，因为它输出得太流利了，流利到你不去怀疑。
这么说吧，它给我的是一个统计上合理的网络，不是属于我的网络。
——也顺便问自己一句：我确定我想要一个统计上合理的网络吗？不确定。但那天晚上的我没问。
于是流程变了。现在配 MikroTik，我让它小步改，每步都 /export 存一份，进 git。改防火墙就只改防火墙，改完从外面连一下、从里面连一下，再让它动下一层。
多模型交叉看是另一个土办法。我手里同时挂四个模型——antigravity、codex、opus、fable——关键配置的 diff 出来，抛给另外三个，问："这堆改动里有没有不该出现的东西？"它们偶尔意见矛盾，那种矛盾本身就有用；它们一致说没事的时候，我反而更警惕——一致可能只是它们从同一批数据里学会了同一个错。
你可能会说，这样搞太慢了。小步改、每步存 git、四个模型交叉看，一天配不了两台设备。而且你还是不信它——那你用 LLM 干吗？
对。多模型交叉解决不了信任问题，它只降低我一个人看漏的概率。信任这件事，最终只能靠我自己去读配置、去理解每条规则为什么存在。模型只是帮我快速圈出可疑的地方，最后的"对不对"还是我的判断。它是个混沌放大器——我给它什么流程，它就放大什么流程。我给它"一把梭"，它就放大一把梭的后果；我给它"小步验证"，它就放大验证的效率。工具本身不创造纪律，它只是让我已有的纪律或者我已有的懒惰都跑得更快。
CAPsMAN 是个有意思的反例。让 LLM 配 CAPsMAN 管理五六个 AP，真的很容易，因为那东西的结构是死的——几个 profile、几行模板、参数就那些。它没有自由发挥的空间，所以几乎不出错。但防火墙、NAT、路由策略，这些地方每个网络都有自己的脾气，它一自由发挥，就开始按惯例补全。补出来的东西语法全对，语义不全对。
还踩过版本不一致的坑。两台设备一台 7.14 一台 7.16，LLM 在旧的上面写了个新版本才有的语法，报错了。它自己绕了半天，越绕越乱。后来我定了个死规矩：所有设备同一版本，谁想让 LLM 配，先把版本对齐了再说。
还有一件事，关于备份。我每配完一台都会 dump 全量配置存 git，但我从来没真的从备份恢复过。后来有次某台设备配置乱了，我自信满满地拿出备份，恢复完 DHCP 租约全丢、AP 掉一地——因为配置是配置，状态是状态，我备份的只有前者。那一刻我才明白：备份不是用来存的，是用来恢复的。没验证过能恢复的备份，等于没有备份。
所以最后落到什么判断上？不是"LLM 会不会配 MikroTik"——它会，比我快得多。真正的问题是：我有没有一套验证的框架。因为不管它配成什么样，对网络负责的人是我。如果我没有"怎么验它配对了"的流程，那它配得越快，我埋雷越快。
验证不是配完 ping 一下。验证是：改了什么、为什么改、改完网络行为变成什么样、出问题怎么退回去。四件事，每一件都要在你把 LLM 放进去之前就搭好架子。
几个月前那个晚上，我犯的错不是让 LLM 碰了我的 MikroTik。是我把"它配完了"当成了"我验证完了"。这两件事之间隔着一整套流程，那套流程才是真正值钱的部分。
我现在有了那套流程，还不齐整。尤其是自动化——自动备份、自动跑验证脚本，还没做出来。先放这儿，下次接着剥。