LLM与MikroTik网络配置

# 用 LLM 玩转 MikroTik 网络 来源：https://blog.greg.technology/2026/07/14/llm-networking-with-mikrotik.html 我一直忍着没说“氛围组网”（vibe networking）或“氛围克”（vibkrotik）这类怪词，但事实确实如此——过去几个月里，我一直用 LLM 来搭建几个网络，整体效果相当顺利。 我是 MikroTik (https://mikrotik.com/) 设备的粉丝，说起来很简单：设备可靠、价格便宜，而且覆盖了大量网络使用场景——物联网手机路由器、普通路由器、交换机、点对点系统等等。 大家过去常吐槽 MikroTik 的地方是它复杂的界面/配置。某种程度上，我不知道这算不算真正的问题——因为网络本身就很复杂，只是比我们想象的要深？也许该有个冰山图表 (https://knowyourmeme.com/memes/iceberg-charts) 式的梗图来说明这事。最上面是“IP 地址”，往下深入你会看到“The Dude (https://www.youtube.com/watch?v=wWt6eL6Hj7M)”和其他你闻所未闻的东西。MPLS！IGMP！OSPF！ 我想说的是，没错，网络本来就可能很难。我当业余网络玩家已有段时间了——给朋友和朋友的办公室搭网络、做网线、打小型配线架等等。我几乎肯定考不过官方的“认证路由工程师”——除非大量学习（要相信自己）。 但你知道吗，这并没有阻止我（我想也不该阻止）玩得开心，帮别人修修 Wi-Fi（大多数人的 Wi-Fi 问题其实可以归类为……哦天哪，我应该再写一篇文章专门讲这个。永远别用信号扩展器）。 --- 那 LLM 能做什么呢？和在其他地方（比如编程）一样，它们是混乱的效力倍增器——它们确实知道怎么配置 MikroTik 和一般网络，但也还会出错、走偏等等。和编程一样，你可以/应该牢牢牵着绳子，不信任但验证（Trust, but verify）(https://en.wikipedia.org/wiki/Trust,_but_verify)，同时也能更快取得进展（还记得 2025 年那篇研究说 LLM 带来的提速不真实吗……嗯 (https://metr.org/blog/2026-02-24-uplift-update/#wider-adoption-of-ai-has-made-it-more-difficult-to-measure-task-level-productivity)）。 于是过去几个月里，我成功搭建了几个网络——规模确实不大——而且非常享受让 Claude Code 访问我的设备，然后让它自由发挥的过程。（就像我在那里 (https://agentsandengineers.com/episodes/0001-vibe-coding-in-the-physical-world-robotics-circuits-and-dangerous-permissions/) 讨论过的，没错，我说的就是危险地跳过权限确认。） 我整理了一小份希望能有用的笔记，关于这个话题——有一次是迁移现有网络（从一个非常小的单路由器集成 Wi-Fi 切换到路由器 + 交换机 + 两个无线 AP），另外两次则完全是新建网络。 不管怎样，下面是我的 LLM MikroTik 技巧列表： - 虽然 MikroTik 可以通过 SSH 配置，但 LLM 用那种方式来回传文本很容易陷入“千刀万剐”的零碎状态。更好的（也就是更 LLM 友好的）通道是使用 REST/JSON API。 - 作为通用最佳实践，我建议禁用不安全的服务——非安全的 API 端口、WWW、Telnet 和 FTP。 - 在任何变更前 dump 完整配置，完成后也 dump 一次。用源码版本控制管理这些配置很棒。能有个自动备份工具（我还没腾出空来写）会是最好的。 - CAPsMAN 确实大大简化了多无线 AP 的配置——用 LLM 配置它简直小菜一碟。 - 我经常用“多 LLM 询问”的技巧——反重力、Codex、Opus 和 Fable——让它们互相检查配置，达成共识，看是否有遗漏或严重错误。 - 也许显而易见，但在拆除网络（迁移到 MikroTik 时）之前，记下 SSID、密码、DHCP 保留。 - 准备一个恢复手册！写下从已知良好位置恢复所有设备配置的步骤（所以要先备份配置）。演练一下这个手册——未经测试的备份无异于一堆零。 - 和 LLM 打交道时常会遇到的问题：把任务拆细，一步一步来。是的，就是那句“帮我搭好网络别出错”的笑话——别那样做。每次配置变更后都要测试。LLM 会幻觉！ - 很小的事情，但给所有要配置的设备设置 NTP（时间服务器）很有用。 - 同样是小事情，为了清醒起见，给设备起个描述性名称/标识——你的路由器、交换机、无线 AP。交换机端口也要起名——设备搬来搬去时维护起来会有点烦，但知道哪个端口连着什么在很多时候非常方便。 - 确保所有设备都更新到相同的 RouterOS 版本——LLM 有时也以为它们知道命令怎么用，但语法/选项会随时间变化——让它们去核实。 --- 哦，还有最后一件事！ 我遇到过一些情况（或者也许是 LLM 把我带到了这条路上……）IP 地址冲突，多个 192.168.88.x 网络重叠，整个一团糟，甚至通过以太网物理连接到路由器或交换机（你应该始终这么做）也很难连上去。 我认为最好的工具是 L2 层的“MAC Telnet (https://manual.mikrotik.com/docs/management-tools/mac-server)”，即一个允许你在 L2（MAC 地址）层上 Telnet 的服务器。这有点像使用 WinBox (https://mikrotik.com/download/winbox)（令我惊讶的是，现在它已跨平台，在 Mac 上运行得相当好）——只不过拥有 L2 层的 Telnet 客户端能让你的 LLM 与 MikroTik 设备对话。WinBox 是 GUI 软件，LLM 无法控制。 为此，我强烈推荐 MAC-Telnet (https://github.com/haakonnessjoen/MAC-Telnet)——它会在最糟糕的时候派上用场，即 IP 地址通不了的时候！我/Claude 刚刚做了一个小小的 Homebrew formula (https://github.com/gregsadetsky/homebrew-mactelnet/) 来简化安装，但也可以按照原始安装说明操作——代码是一样的。我还做了这个小 CLI (https://gist.github.com/gregsadetsky/eab0be331cb99342dd4be6bab7353f13) 专门让 MAC-Telnet 更易被 LLM 消费/使用，但一般来说，LLM 会自己学会如何使用 CLI 工具。你不需要 MCP 服务器。 玩得开心——也欢迎告诉我我全错了（以前也不是没有过）。拜拜！xx