配路由器这件事,过去十几年基本靠人一条条敲命令,谨慎、慢、容错率低。现在有位长期玩MikroTik的网络爱好者,把这活儿直接甩给了AI——不是"帮我看看配置对不对"那种辅助角色,而是把设备访问权限整个交出去,让Claude Code、Antigravity、Codex、Fable轮流上手改配置。三个月里,他完成了一次旧网络迁移,又从零搭了两套新网络,还写了一份"AI配置MikroTik"的实用清单。他管这种做法叫"dangerously skip permissions"——听着像自嘲,其实是字面意思。
这份清单本身挺扎实:别用SSH一行行敲命令,改用REST/JSON API;用CAPsMAN一次配好几个无线AP;IP地址冲突、设备失联的时候,靠MAC Telnet这种L2层工具救场。但清单里没写的,恰恰是这套玩法最该讲清楚的部分——权限给出去之后,出了错谁来兜底。
一份清单,四个AI,两张新网络
事情不复杂,几句话说完。谁:一位业余但经验丰富的网络玩家。做了什么:用多个大模型协同完成MikroTik设备的迁移和组网。关键技巧:REST API替代SSH命令行、CAPsMAN简化多AP无线、多个模型互相核对配置、MAC Telnet在设备失联时兜底。反常点:作者自己承认是"跳过权限"的危险玩法。
这套做法能跑通,说明大模型确实吃透了MikroTik的配置逻辑,不是花架子。但"跑通"和"可信赖"之间,还差一段没写进清单的距离。
REST API为什么更懂LLM,官方却留了几道口子
MikroTik的REST接口挂在/rest路径下,支持用标准HTTP方法直接读写设备配置,这比SSH里那种文本拼接、猜格式的方式要干净得多——结构化数据本来就是大模型的强项。这也是为什么原文作者反复强调"REST比SSH对LLM更友好"。
但MikroTik官方文档里同时写着几条容易被跳过的提醒:REST认证走的是HTTP Basic Auth,官方建议一定要走HTTPS而不是明文;默认的"read"用户组听着像只读,实际上包含重启设备、访问敏感数据、调用测试工具在内的一堆权限,官方建议自己建精简权限组;设备的Safe Mode能在会话异常中断时自动撤销改动,但历史记录容量有限,官方建议小批量分步改。这些都是"能用"和"配置得安全"之间的差距,原文清单里一句没提。
原文没写的坑:AI也会把自己反锁在外面
行业里已经流传过一个真实案例:某次用Claude Code做网络设备测试时,AI在改配置的过程中把自己正在用的WiFi连接关掉了——它失去了验证和回退这次改动的通路,只能靠人工物理介入才能救回来。这正是原文里"MAC Telnet是救命稻草"这条建议背后真正对应的场景,但原文只讲了工具,没点破它到底在防什么。
- 风险.REST API用的通用POST机制可以直接调用控制台命令,一旦凭证泄露,攻击面比普通CRUD接口大得多;配置导出、日志、DHCP备注这些"数据"里,理论上也能被植入指令诱导AI执行;反复跑同一批AI生成的命令,还容易在防火墙规则、地址列表里堆出重复项,造成配置越改越乱。
这些都不是原文虚构或夸大的问题,而是MikroTik官方安全指引和社区讨论里本来就存在、只是没被这篇经验分享提及的部分。
好玩和好用之间,差一层谁负责回滚
"多个大模型互相核对配置"是个聪明的土办法,能揪出明显的疏漏和幻觉,但它本质上还是人工留意的升级版,不是结构化护栏。第三方项目MikroMCP这类方案想补的,正是原文清单缺的那块:类型化操作封装、变更前预览、基于角色的权限、操作快照和熔断机制——说白了就是把"改错了能不能悄悄退回去"这件事,从靠人品变成靠机制。
好玩和好用之间,隔着一个"谁来负责回滚"的问题。
对个人爱好者而言,家里或朋友的小网络出点岔子,大不了物理跑一趟重插网线,风险容忍度高,这套玩法确实值得试。但一旦搬进企业生产网络,凭证范围、审批留痕、回滚机制就不是加分项,而是底线。原文作者的乐观没有错,只是他站在了风险后果最轻的那一端——真正决定这套做法能不能走出个人博客的,不是模型聪不聪明,是谁在为反锁、泄露、配置漂移这些小概率事件兜底。