ARTICLE · 1110239
AI 协同实践案例|从一份端口说明到随处可用的网络天气图
跟AI聊天做了个东西，顺便请AI写出来，算做一个总结。
我们给出的，只有一份端口说明，和五次一句话的判断题。
AI 交付的，是一个单文件程序：双击即用 —— 不用装环境、不用配数据库、不用懂查询语言。
全程就我们和 AI，一天内完成。下面把这套做法完整拆开讲一遍。
▍一、起点：我们手上只有这些
被观测的对象是我们自己的一个数据中心核心网络：两台核心交换机做堆叠，共 250 个接口；上行两台防火墙；下挂超融合、分布式存储、负载均衡、DNS、专线和云互联等十几类业务。
而我们能拿出来的，只有四样东西：
一份网络情况说明—— 核心设备、防火墙上联、大致拓扑关系。历史文档，可能已经过时。
一份端口说明—— 哪些口重要、每个口大概接什么业务。手工维护，但往往最权威。
一个只读凭据—— SNMP v2c 团体名。由我们在页面上亲手填，程序从不接触。
几次判断题—— 约五次，每次就一句话，见第五节。
通常被认为必要的前提，我们这里一个都没有：没有 CMDB、没有网管平台、没有现成的流量基线、没有专职开发。所以这套做法，你们那边的起点大概率也不会比我们更低。
▍二、我们交付了什么
最终交付五件产物：数据中心拓扑图（单页 HTML，可打印存档）、天气图生成脚本（Python，出静态快照，可转发）、天气图程序（单文件可执行，零依赖，双击启动）、待确认与待办事项（带证据与优先级，滚动更新）、丢包告警方案（阈值与去抖规则的设计依据）。
网络天气图的读法和地图软件一致：
链路线宽= 带宽（1G / 10G / 25G / 40G 四档）
链路颜色= 利用率（绿 → 黄 → 橙 → 红，阈值 0 / 30 / 60 / 85 / 100%）
白色光点流速= 实时流量，完全静止即空载
悬停任意链路，可看接口全名、协商速率、收发速率、利用率和 LLDP 对端设备名；下方是按利用率排序的明细表。
▍三、我们做的第一件事：不照抄文档
拿到文档后，我们AI没有直接画图，而是先用 SNMP 实测把拓扑核了一遍 —— 拿 LLDP 邻居和接口别名做双向交叉验证。这一步查出文档三处错误：
1. 上行口编号根本不存在。文档记的上行端口号，在这台设备的接口表里没有。实测那条 40G 上行接在另一对端口上，对端是两台防火墙，而不是文档写的万兆口。
2. 堆叠互联漏记了一对。文档只记了一对互联端口，实测还有第二对 40G，外加一对万兆口专门用于堆叠检测（BFD MAD）。
3. 两台堆叠成员的身份是反推出来的。文档没写哪台是哪台，靠两个成员的接口别名互相指向才确定下来。
文档会过时也会写错，能连上设备就自己走一遍。图和看板最后会被当成拓扑依据 —— 编出来的节点，比空白更害人。
这条原则，是我们被一次返工教训出来的。
AI 为了省版面，曾把三个互不相干的口合并成一个叫"外部出口"的节点。我们只问了一句："为什么会有个外部出口？"
查下去发现，这三个口的 LLDP 对端是三台各自独立的设备：专线对端、云端入口、边界安全设备。那是一个臆造的假节点。当场拆掉，改成三个独立节点并直接标出对端设备名。
由此固化成一条规则：没有 LLDP 支撑的层级，宁可标未知也不猜。这条后来也写进了交付物，谁看图都不会被误导。
▍四、我们踩过的三个坑
坑一 · 光点流速不能用利用率线性映射。最初按利用率线性计算动画时长，结果低负载时所有链路都挤在 1.7~2.0 秒，肉眼完全分不出快慢。改成按流量的对数映射才拉开差距：40G 干线走得飞快，空载的备用链路完全静止，一眼可辨。
坑二 · 采样窗口不能短于 20 秒。5 秒窗口差分会读到假 0：备用那一侧成员上有多个口读数全为 0，换成 20 秒即恢复正常。这不是设备故障，而是计数器刷新粒度与短窗口差分的固有矛盾。
坑三 · 利用率的分母必须是实测协商速率。文档标"25G"的三条链路，实测接口名的前缀就写着万兆、协商速率也是万兆。我们后来的澄清是：交换机本身是 25G，但上联核心那侧只插了万兆口。
这个差别有多大？同一条分布式存储链路，近 24 小时峰值 2.48 Gbps：
按 10G 算 = 24.8%（接近该扩容了）
按 25G 算 = 10%（看着还很闲）
分母差 2.5 倍，结论完全不同。顺带得到一个运维结论：这三条要提速，要动的是核心侧的口位与模块，不是超融合那一侧。
所以明细表里把"标称"和"协商"并排放，不一致的直接标红 —— 这条纪律也固化在交付物里了。
▍五、我们要做的，其实只有这些
这是我们最想强调的一点 —— 我们在整件事里的工作量，小到可以量化：
提供端口说明—— 已有的业务口清单，复用存量文档
判断题 ①—— "单边承载是不是设计要求？" → 是。改为按主用/备用口径显示，不再当异常上报。一句话
判断题 ②—— "25G 还是 10G？" → 澄清了利用率口径。一句话
判断题 ③—— "为什么有个'外部出口'节点？" → 问出一个假节点。一句话
判断题 ④—— 命名口径：不要写"成员 1/2"，写真实主机名。一句话
填写凭据—— 团体名由我们在页面上亲手填，不进程序、不落盘、不进日志。一次输入
回现场确认—— 页面报连接失败时，看一眼控制台窗口的输出。一次配合
在程序里，需要我们输入的东西就只有两个框：设备地址、SNMP 团体名。
而 AI 从没要求我们做过的事：写设备配置、配数据库、装依赖、读 SNMP 报文格式、理解计数器语义、写 BER 编解码。
▍六、为什么我们最后做了一个 exe
天气图跑起来之后，冒出一个很现实的问题：这东西只有我自己能用。要分发给同事，总不能要求对方装 Python、装依赖、改配置、再去连时序数据库。
于是有了这个形态：
weathermap.exe 双击即用
→ 自动启动本地 HTTP 服务（自动挑空闲端口）
→ 自动打开浏览器
→ 页面上手动填写团体名
→ 之后按周期自动刷新
零依赖。没用第三方 SNMP 库，v2c 完全用标准库手写（BER 编解码 + GET / GETNEXT / GETBULK）。代价是多写几百行（反正是AI写），收益是没有依赖清单、没有供应链风险、静态编译出单文件。
凭据不进程序。这是我们提的需求，但它只对了一半 —— 拿到程序的人照样能用别的工具扫设备，这拦不住。真正要防的是别人蹭用你机器上跑着的这个服务，于是加了三道闸：
一、只监听本机回环地址，绑其他地址必须显式加参数，否则拒绝启动
二、启动时生成一次性随机令牌，写在自动打开的 URL 里，所有接口都校验
三、团体名只存内存，不落盘、不进日志，连错误提示里都不包含它
采集方式与 Telegraf 一致。后台按周期采一次，与上一次的计数器值差分算速率，而不是每次刷新现采两次（后者要等两倍时间）。首次连接 5 秒出第一个数据点。
实测表现。团体名填错时 6 秒内给出明确提示（额外加了轻量探测，否则要干等整个超时周期）；填对时不到 1 秒连上，并完成 250 个接口的索引遍历与首轮采样。
▍七、想复用的同行，可以按这个顺序走
我们这套做法不依赖任何特定厂商或平台，换一个机房可以直接照搬。建议按下面的顺序推进。
第一步：先把手上的资料变成"可核对的问题"
不要急着画图，也不要先设计系统。把已有的拓扑文档、端口说明、变更记录翻出来，逐条列成"待核实的断言"：上行接哪、堆叠几对、每个业务口对应谁，然后逐条去设备上实测。这一步的产出不是图，而是一张核对表 —— 哪些对上了、哪些对不上。对不上的地方，就是最有价值的部分。
第二步：先出静态图，再上实时数据
静态拓扑图（骨干 + 端口对照表）的价值常常被低估：它是后面所有东西的共同底座，也是唯一可以打印、可以贴墙、可以拿去做变更评审的形态。实时天气图只是在这个底座上加了两层信息。底座不稳，实时图画出来只是好看。
第三步：接实时数据时，先确认能拿到什么
需要的最小数据集：接口收发字节计数、协商速率、链路状态，再加上 LLDP 邻居表（用来核对拓扑）。设备是 SNMP v2c/v3，这些值都取得到。如果暂时拿不到写权限或没有监控平台，也不影响起步—— 先出静态图，把该核的先核完。
第四步：把"能看"变成"随处能看"
不要让别人为了看一张图而准备环境。单文件、零依赖、双击即用，是决定这张图会不会被真正使用的分水岭。
凭据不要写进程序。页面打开时让使用者自己填，并明确告知它只存在内存里。
不要用"要不要小心一点"来兜底安全。能靠默认配置挡住的就挡住（比如默认只监听本机），剩下的用引导说明。
几个常见的顾虑
Q：设备不是同一个厂商，能行吗？能。天气图只用到标准 MIB 里的几个值（接口计数、速率、状态），差异主要在接口命名上，脚本里一处适配即可。
Q：没人懂 SNMP 报文，会不会卡住？这一层正是可以交给 AI 的。我们这边的实现是零依赖手写编解码，你不必读它，只需要知道"能取到数"。
Q：连只读团体名都申请不下来怎么办？那就先做静态拓扑核对。它同样需要设备访问，但只读权限通常比改造权限好批；实在拿不到，也可以先用手上的端口文档画出"待核实版"，把不确定的地方明确标出来。
Q：图会被当成拓扑依据，画错了怎么办？把纪律写进交付物里：标称与实测并排放、不一致标红、没有证据的层级不画。
可以直接照抄的四条经验
实测优先—— 文档与设备不一致时以设备为准，把差异摆出来让人确认，不要闷头改
计数器只看增量—— 累计值巨大的历史残留不代表当前故障，先取两个时间点的差
画图不许合并节点—— 为了版面把多个对端塞进一个框，等于制造假拓扑
要人确认的事必须落文件—— 口头说了不算，写进待办清单并排优先级
▍结语
AI 承担的是脏活：遍历 250 个接口的计数器、走 LLDP 表、核对文档的每一条、手写 SNMP 报文、调动画手感、处理进程与端口与编码的种种坑。
我们承担的是只有人能判断的事：单边承载是不是设计意图、速率口径以哪个为准、某个节点是不是真的存在、凭据给不给。
剩下的 —— 界面、渲染、分发形态、排障 —— 交给 AI，然后验收。
如果你那边也是"文档有一份、口径靠人记、想看一眼流量还得登设备"的状态，这套流程值得试一次。起点真的只需要一份端口说明。