做基础架构这些年，我强烈地感受到一件事：
很多网络运维团队不是没有工具，而是工具太多、太散、太割裂。
设备资产在一个系统里，IP 地址在另一个系统里，配置变更靠 SSH 和表格，知识文档躺在文件夹里，出了问题再去问大模型时，模型又拿不到现场上下文。
结果就是：
- 明明是简单的问题，却要在多个系统里来回切换
- 明明想做标准化运维，最后还是靠“经验型人工处理”
- 明明有 AI，但 AI 只是聊天，离真实运维场景还差很远
- 明明知道问题出在哪，却缺少一套能真正落地执行的工作流
这也是我决定做 Network AI Ops 的原因。
我想做的，不是再造一个“AI 壳子”，也不是再加一个“孤立的小工具”。
我想做的是一套真正面向网络工程师、网络管理员、网络架构师的 本地优先、一体化、能落到实际业务里的网络运维桌面平台。
为什么网络运维团队总是很忙，却很难真正轻松下来？
因为网络运维里最耗人的，往往不是某一个单点动作，而是整个流程的割裂。
比如一个很典型的场景：
某个站点出现链路异常，你要先查设备信息，再找 IP 和网段归属，再回头看历史配置，再去翻知识库基线文档，再决定要不要批量下发变更。
如果这些数据和动作分散在不同地方，整个过程就会变成：
找信息，切系统，人工判断，再切回来执行。
这不只是慢。
更大的问题是，它很难复制，很难标准化，也很难沉淀成团队能力。
于是，很多团队会遇到这些共性痛点：
1. 设备资产和地址资源是分开的
设备管理看得到设备，IP 管理看得到地址，但两边没有真正联动。
到了排障现场，你知道一个 IP，却不一定能快速定位到对应设备；你看到一台设备，也未必能立刻还原它背后的地址上下文。
2. 批量变更最怕“误下发”
很多时候不是不能批量做，而是不敢批量做。
因为你很难精准地从一堆设备里筛到“这一批应该执行的人”，最后只能保守地一台一台处理，效率很低。
3. 文档、经验、现场数据没法串起来
知识库有文档，设备管理有现场数据，大模型能给建议，但三者往往没有真正打通。
所以很多所谓的“AI 运维”，最后只是“会聊天”，却不能成为真正的运维助手。
4. 工具很多，但业务链条没有闭环
你可能已经有 NetBox、phpIPAM、本地文档、SSH 工具、Excel 表格，甚至还有大模型。
但如果它们之间不能形成一个顺滑的闭环，团队还是会不断重复：
找数据、确认对象、手动执行、人工记录、重复沟通。
我做的这个软件，到底想解决什么问题？
一句话概括：
把“设备管理、IP 管理、批量部署、知识库、AI 能力”放到同一个桌面工作台里，让网络运维从“信息散、动作碎、经验靠人”变成“信息集中、流程联动、能力沉淀”。
这就是 Network AI Ops 的核心方向。
它不是替代你现有的所有系统，而是把你本来就在用的系统和动作整合起来，让运维真正形成闭环。
它现在能做什么？
下面我按最实际的业务场景，讲讲这个软件的几个核心模块。
一、设备管理：先把设备资产真正管起来
设备管理是很多运维动作的起点。
在 Network AI Ops 里，你可以统一管理：
- 设备名称
- IP
- 厂商
- 型号
- 设备组
- 设备类型
你也可以做这些事情：
- 搜索和多条件筛选设备
- 批量选择设备
- 导入导出设备数据
- 同步 NetBox 设备信息
- 查看设备详情
- 管理 SSH 连接信息
- 做批量配置快照
- 做批量健康巡检
- 做配置版本追踪
这件事的业务价值很直接：
先把“对象”管清楚，后面的巡检、变更、分析、定位才有基础。
更重要的是，在最新版本里，设备管理还补上了分页和每页数量选择能力。
当设备规模上来之后，列表浏览、筛选定位、操作节奏都会更稳定。
二、批量部署：从“能批量执行”进化到“能精准批量执行”
我觉得很多运维团队其实不是不想批量部署，而是缺一个足够放心的执行入口。
所以这次 v1.0.4，我重点增强了批量部署模块。
现在你不只是“选中所有设备然后下发”，而是可以先筛，再选，再执行。
支持的筛选维度包括：
- 关键词搜索
- 厂商筛选
- 设备组筛选
- 设备类型筛选
然后你可以在筛选结果里：
- 全选
- 勾选部分设备
- 针对目标设备执行批量下发
这背后的价值非常大。
因为真正的生产网络里，变更往往不是“全量一次性下发”，而是：
- 先按设备组做灰度
- 先按厂商做兼容性处理
- 先按设备类型做分阶段变更
- 先按站点做小范围验证
也就是说，批量部署最重要的不是“批量”，而是“精准”。
如果一个工具只能让你“下发”，但不能让你“放心地下发”，它就很难真正进入生产流程。
三、IP 管理：终于把地址资源和设备资产串起来了
这是这次版本里我非常看重的一块。
v1.0.4 新增了独立的 IP 管理模块。
为什么一定要做这块？
因为很多网络问题，最终都绕不开 IP 地址、网段、前缀和资源归属。
而现实里，很多团队对 IP 资源的管理，要么依赖外部系统，要么依赖 Excel，要么依赖“谁记得谁来回答”。
这非常容易导致：
- 地址归属不清
- 前缀利用率不透明
- 设备和 IP 之间缺少映射
- 人员变动后，知识断层严重
所以在 IP 管理模块里，我把这些对象放进了统一视图：
- VLAN 组
- VLAN
- 前缀
- IP 地址
- IP 范围
并且支持：
- 手动新增
- 编辑维护
- 批量删除
- Excel 批量导入
- CSV / XLSX 导出
更关键的是，它不是一个孤立的地址台账。
它支持和设备管理联动。
也就是说，你在 IP 详情里可以直接跳转到对应设备。
这会让很多日常动作变得非常顺：
- 从 IP 快速定位设备
- 从设备快速理解地址上下文
- 做资源核对时更快
- 做排障定位时路径更短
对网络团队来说，这种联动带来的价值，不只是“方便”，而是明显减少上下文切换成本。
四、外部数据源同步：不是替代 NetBox 和 phpIPAM，而是把它们真正用起来
我并不认为一个本地工具应该去强行替代团队已经在用的系统。
所以 IP 管理模块支持同步：
- NetBox
- phpIPAM
这意味着什么？
意味着你原来已经有的数据源，不需要推倒重来。
你可以继续保留原来的系统作为主数据来源或现有流程的一部分，同时在本地工作台里获得：
- 更统一的查看入口
- 更顺手的编辑和导入导出体验
- 与设备管理、批量部署、AI 分析联动的能力
我更倾向把它理解为：
不是重造一个系统，而是把现有系统真正串联成一个可执行的工作台。
五、AI 运维工作台：AI 不只是回答问题，而是帮助你做事
现在很多软件都在加 AI，但真正有价值的，不是“有 AI”这三个字，而是：
AI 能不能理解你的真实场景，拿到你需要的上下文，并输出能落地的结果。
在我的方案里，AI 运维工作台不是孤立存在的。
它会围绕真实的网络运维问题来工作，比如：
- 配置分析
- 日志辅助分析
- 健康巡检解释
- 设计建议
- 脚本生成
- 知识库问答
而且它和设备、知识库、配置、地址资源这些能力是同一套产品里的，不是彼此脱节的。
这就意味着：
当你让 AI 帮你分析问题时，它不只是“给你一个泛泛而谈的答案”，而是更有机会结合你的设备、文档、上下文，给出更接近实际业务的结果。
这也是我一直坚持的一点：
AI 在运维场景里，真正的价值不是炫技，而是减少判断成本、减少重复劳动、提升执行质量。
六、知识库：让团队经验不再只存在于“某几个人脑子里”
很多团队最怕的一件事，不是没有文档，而是：
文档存在，但用不起来。
于是你会看到：
- 规程写了，但没人查
- 经验有，但很难复用
- 新人上手慢
- 老同事离开后，很多隐性知识一起消失
所以我也把知识库能力放进了这套产品里。
它支持：
- PDF / DOCX / TXT / Markdown 文档上传
- 自动分块和向量化
- 混合检索
- Reranker 精排
最终目标不是“做一个知识库存档工具”，而是让知识真正参与到日常运维判断里。
七、模型设置：把大模型真正接入真实工作，而不是只停留在“能配上”
这一块很多人可能不一定会第一时间注意，但它很关键。
因为如果模型配置层不稳定，前面的 AI 运维、知识库问答、辅助分析就都不稳。
现在这套软件支持的模型来源已经比较完整，包括：
- OpenAI
- Anthropic
- Google Gemini
- DeepSeek
- Mistral
- Azure OpenAI
- 通义千问
- 智谱 AI
- Ollama
- vLLM
- OpenRouter
- AIHubMix
- 自定义 OpenAI 兼容接口
而在最新版本里，我还专门修复和增强了对 Coding Plan 的支持。
这件事看起来像一个配置问题，但本质上关系到：
团队能不能更低门槛地把模型能力真正接进日常运维工作里。
这套软件到底能给团队带来什么实际业务价值？
我觉得可以总结成 4 点。
1. 降低日常运维的信息切换成本
把设备、IP、配置、知识库、AI 放到一个工作台里后，很多动作不再需要在多个系统之间跳来跳去。
2. 提高批量变更的可控性
筛选 + 勾选 + 分批执行，让批量部署真正具备生产可用性。
3. 让地址资源和设备资产形成联动
不再是“知道 IP 不知道设备，知道设备不知道地址上下文”。
4. 让 AI 能力从“聊天”走向“辅助决策和执行”
不是把 AI 当摆设，而是让它在真实运维流程中发挥作用。
这个软件适合谁？
如果你是下面这些角色，我觉得它会比较适合你：
- 网络工程师
- 网络管理员
- 网络架构师
- 中小企业 IT 运维负责人
- 正在做标准化、流程化、自动化建设的网络团队
尤其是下面这几类场景，会非常适合：
- 团队已经有 NetBox 或 phpIPAM，但日常使用体验比较割裂
- 设备规模已经不小，人工处理越来越吃力
- 想引入 AI，但不想只是做一个聊天入口
- 想让设备、地址、文档、变更这几件事串起来
最后，我想说点更直接的
我做这个软件，并不是因为“AI 是热点”，而是因为我真切地感受到：
网络运维领域，太需要一套真正从业务场景出发的本地化、一体化工具了。
不是为了替代所有系统，而是为了把原本分散的能力真正连接起来。
不是为了做一个看起来很厉害的演示，而是为了让工程师在真实工作中少一点重复、少一点低效、少一点救火。
如果你也在做网络运维，如果你也在经历这些痛点，如果你也想看看这套方案是不是适合你，
欢迎关注公众号，了解后续更新。
如果你想第一时间体验新版功能，也欢迎：
- 后台回复 「内测」
- 或者添加我、进群交流
- 一起参与内测，给我真实反馈
我也很希望把这套产品，打磨成一套真正能帮到网络运维团队的工具。
如果你愿意，我们群里聊。
