AI 来当你的网工了：UniFi 接上 Claude Code，先让它看、别让它动_IT互联网

两周前，有人把 UniFi 的钥匙递给了 AI

10 月 16 日，做终端工具链的 x-cmd 团队（B 站粉丝约 1.5 万）发布了一个叫 unifly 的东西：一个用 Rust 写的 UniFi 网络管理工具，自带一套专门给 AI Agent 使用的 Skill。装好之后，Claude Code、Codex 这类 Agent 就能查看和管理网络设备、客户端、VLAN、Wi-Fi、防火墙、VPN，甚至执行 VLAN 配置、防火墙审计等操作。哔哩哔哩

不过，视频的作者自己先泼了冷水：他觉得不应该这么快让 Agent 接手网络设备管理，Agent 一旦判断错，可能导致设备无法访问互联网，甚至留下严重的网络安全隐患。哔哩哔哩

有意思的是，比"让 AI 改网络"更早发生的，是翻车案例。就在上周，有小红书用户发帖：昨晚 UDM PRO 更新后就采集不到网口数据了，整了半天搞不定，就自己跑去找官方客服了，还担心客服工程师会不会一眼看出是在和 AI 对话。小红书

也就是说，等 unifly 把路修通的时候，已经有人在拿 AI 处理 UniFi 故障了——只是现在，还是人肉给 AI 递键盘的阶段。

评论区很小，但站队很完整

这条视频的互动量不大（500 多播放、28 收藏），但评论恰好把圈层态度摆全了，比很多"万人围观"的帖子更有代表性：

担心派：让 AI 接管网络设备太危险了，而且没必要吧，万一搞断网了接不回去就成乐子了。
实战派：unifly 很香，但 api 密钥权限很容易踩坑，持久化 totp 只能手动改 toml，部分功能只读，api 覆盖率还有缺口。哔哩哔哩
折腾派：直接问为什么不干脆用 SSH 连。
路人派：我连个 Wi-Fi 就好吧，不需要 AI 吧。

再加上开头那条"找客服"的求助帖，你可以看到一个真实分布：这个圈子里，用 AI 帮自己看网络已经发生了，让 AI 替自己改网络还停在争论阶段。unifly 的出现，本质上是把争论推到了下一个问题：中间有没有一条安全的路。

为什么 AI 接管网络，和接管写代码完全不是一回事

很多人拿"AI 写代码翻车可以回滚"来类比网络配置，这个类比是错的。

代码有 git，配置错了 rollback 就行。网络没有：UniFi 的管理入口（Controller、Web UI、SSH）就跑在这张网络上面。AI 改错一条防火墙规则、划错一个 VLAN、动错一个端口组，最先断的往往就是你回到控制台的那条路——远程站点的话，连插网线重启的物理机会都没有。评论里那句"搞断网了我接不回去"，不是胆小，它是一张网络的真实成本模型：故障路径和管理路径重叠，回滚通道本身就是故障点。哔哩哔哩

再叠加第二层风险：Agent 接入本身是个供应链。10 月 20 日就有 B 站 UP 主做了真机实测，第三方 MCP 插件用 Node 的 exec 调底层 Shell，连基本参数过滤都不做，只要一行恶意参数，本地用户名和 SSH 私钥就明文暴露在终端上。网络设备的 API key 权限如果也走这种来路不明的插件，等于把全网的钥匙交给一个没验过货的门锁匠。哔哩哔哩

第三层，工具自己也还没准备好。实战派评论说得很具体：部分功能只读、API 覆盖率还有缺口。也就是说，就算你愿意签字授权让 AI 动手，它现在也拿不全"改"的权限，更没有一键恢复出厂之外的回滚机制。

三层叠起来，当前证据支持的结论只有一句：让 AI 做"读"，价值已经成立；让 AI 做"写"，回滚和安全前提都还不存在。

"读"这件事，现在就值得干

把"看网络"这件事单独拎出来，它对 UniFi 用户几乎是零风险的纯收益，而且恰好是官方 UI 最不擅长、AI 最擅长的部分：

资产和客户端盘点：几十个 AP、交换机、摄像头分布在多楼层，让 Agent 拉一份"哪些设备还挂在 2.4G、哪些固件落后两个版本"的清单，比翻控制台快得多。
故障前兆整理：开头那位 UDM PRO 用户的处境就是典型——更新后网口数据采集不到，人对着图表看不出规律，AI 可以批量比对更新前后日志、客户端掉线时间线，先缩小到"是采集问题还是链路问题"。
防火墙和共享规则审计：这是 unifly 明确宣传的能力（防火墙审计），也是传统网工最容易积灰的地方——规则加了 50 条没人敢删，让 AI 读一遍、标出冗余和危险放行项，输出报告给人裁决，改不改、怎么改，还是人说了算。

这类用法有一个共同点：AI 的产出是报告，不是配置。它不需要你信任它，只需要你信任自己的复核。

如果你现在就想试，按这个顺序来

基于评论区已经踩过的坑，把安全边际按步拆给你：

单独建 API Key，只开只读权限——别拿站点管理员账号直接喂给 Agent。密钥权限这块，评论区已经点名容易踩坑。
先在备用站点/闲置设备上跑，别在生产网络、更别在企业站点试。UniFi 支持多站点，拿一只闲置 AP 建个测试 site，成本是零。
备份通路先行：在让任何工具连网络之前，给自己留一条不经过这张网的回退路——串口或本地直连是下限，更稳妥的做法是像有玩家那样，在双光纤双 WAN 之外单独备一台 UniFi U5G 当应急备份 WAN。小红书
写操作永远要人工执行：让 Agent 输出"要执行的命令 + 逐条的撤销方法"，你自己审一遍、自己敲。Agent 提案、人执行，是现阶段唯一形态。
插件和 Skill 先审再装：拿 unifly 用可以，但对任何要落 API key 的第三方 MCP/Skill，先看源码或等社区验证——10 月 20 日那次 SSH 私钥泄露实测不是假设。

谁适合上车，谁先别动

适合：手里已经有 Claude Code/Codex、同时玩 UniFi 全家的 homelab 玩家——你读得懂 AI 的输出，读不懂时你也有能力怀疑它；以及想给交付项目做设备盘点、审计报告归档的弱电同行。
不适合：家里单站点、全屋设备一条链路吊着的用户（断网即失联）；以及连什么是 UniFi 生态还没理清的新手——评论区刚有人问过这个问题，这类用户现在缺的不是 AI，是基础认知。
别碰：企业生产网络、承载监控和门禁这类安防负载的站点。在官方对 AI 接入给出明确的权限分级态度之前，把 Agent 接进去属于拿别人的系统交学费。