团队里最懂那台交换机的老张离职了，他的经验怎么留下来？
上个月，一个做运维管理的老朋友找我吐槽。
他们公司有个老工程师老张，干了七年，几百台网络设备的配置细节烂熟于心。哪台交换机端口 23 经常掉线、哪台防火墙的 ACL 规则有坑、数据库慢查询的排查套路，全在他脑子里。
结果老张提了离职。
交接期一个月，老张很配合，写了十几页文档。但人一走，问题还是来了：新来的小伙子对着文档照样懵，文档里写"检查端口状态并定位异常端口"，但没说命令输出里的哪个字段代表异常、怎么判断阈值、异常之后联系谁。
知识在人脑子里，不在系统里。
这不是老张的错，也不是小伙子的错。这是所有靠经验驱动的运维团队最终都会撞上的墙。
你的团队有没有这些信号？
走一圈看看，如果中了两条以上，说明问题已经在积累了：
- 核心设备只有一两个人敢碰。 别人不是不想碰，是不敢——万一敲错了命令，背锅。
- 同样的巡检任务，不同人做出来的结果不一样。 张三查出的"异常端口"和李四查出的对不上，因为判断标准不统一。
- 新人上手周期三到六个月。 前两个月在熟悉环境，第三个月才敢独立执行任务，半年才能独当一面。
- 工单经常排队等专家。 一个配置变更要等老王有空才能做，业务方催得紧。
- 审计的时候手忙脚乱。 谁在什么时候执行了什么操作、改了什么配置，记录不全，说不清楚。
这些问题不是招人就能解决的。因为问题的本质是：运维能力是挂在人身上的，不是挂在系统上的。
清巡的思路：把经验固化成可执行的资产
清巡不是一个"脚本生成工具"，它是一套把运维经验从人脑中提取出来、固化成可复用资产的系统。
怎么做的？回到最核心的机制——
命令 → 报文 → 处理逻辑
拿交换机巡检来说。老张在的时候，他的巡检套路是：
- SSH 登录交换机
- 执行
show interface status，凭经验扫一眼输出，找 down 的端口 - 执行
show cpu usage，看看有没有异常飙升 - 执行
show log，搜关键字找告警 - 把结果整理成邮件发出去
这套动作，老张脑子里走了上千遍，闭着眼都能做。但新人不行。
用清巡的做法：让老张把每一步写成提示词，而不是写成文档。
步骤1：
命令：show interface status
响应：Port Name Status Vlan Duplex Speed Type
Gi0/1 Uplink-to-Core connected 1 a-full a-1000 10/100/1000
Gi0/2 Server-Rack-1 notconnect 1 auto auto 10/100/1000
Gi0/3 Access-Floor-2 connected 2 a-full a-1000 10/100/1000
处理逻辑：解析每一行，Status 列为 "notconnect" 或 "disabled" 的端口视为异常，输出端口名称和状态
步骤2：
命令：show cpu usage
响应：CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
处理逻辑：提取 "five seconds" 后的第一个百分比值，大于 80% 则告警
步骤3：
命令：show log | include ERR|CRIT|ALERT
处理逻辑：逐行输出，每行标注日志级别
AI 根据这些提示词生成脚本，沙箱验证通过后，这份脚本就成了可执行的巡检标准。
注意——新人面对的不是脚本代码，不是 Ruby 程序。他看到的是上面那段自然语言写的提示词：
"执行 show interface status，找到 Status 列为 notconnect 或 disabled 的端口" "提取 CPU 使用率，大于 80% 告警"
他能读懂每一步在做什么、判断逻辑是什么、异常标准是什么。因为提示词就是用中文写的操作思路，不是代码。
然后他在客户端里创建任务、选中这台交换机、点执行。脚本自动登录、自动执行命令、自动解析输出、自动生成报告。
老张走了，老张的巡检套路留下来了。
对管理者来说，几个直接的变化
1. 培养周期缩短
以前新人跟着师傅学半年才敢独立操作。不是新人笨——是运维经验需要时间积累，命令怎么敲、输出怎么看、异常怎么判，都得一个一个场景磨。
现在师傅把关键操作写成自然语言提示词。新人看到的不是代码，是这段中文描述：
"执行 show interface status，找出 notconnect 的端口"
他读得懂这段中文，知道这一步在干什么、标准是什么、异常怎么定义。如果业务需求变了——比如新增一种端口状态也要算异常——他直接在提示词里加一句中文就行，不用碰代码。
不是说新人不需要学习——他需要学，但他学的是业务逻辑和判断标准，不是学怎么改代码。提示词本身就是教材：每步做了什么命令、预期什么输出、怎么判成败，清清楚楚用中文写着。
2. 执行质量统一
五个人做巡检，出五份不同格式的报告？不用了。
同一个脚本执行出来的结果格式一致、判断标准一致。谁来点那个"执行"按钮，结果都一样。这对审计和合规来说尤其关键——你不会被问到"为什么张三的报告里这个指标查了、李四的没查"。
3. 知识从人转移到系统
这可能是最重要的一点。
运维团队最怕的不是设备出故障，是处理故障的人恰好不在。清巡的思路不是让人更厉害，而是让系统承担更多——
提示词库就是团队的知识库。
老张写的"检查端口状态并定位异常端口"不再是一句含糊的文档标题，而是一段可执行的自然语言描述：执行什么命令、报文长什么样、怎么判断异常。老张走了，这段提示词留下来。新来的小伙子对着提示词就能看懂老张当初的设计思路——因为写的是中文，不是代码。
积累的是提示词。脚本随时可以从提示词重新生成，但提示词里的业务逻辑才是资产。反过来，需求变了——比如输出格式换了——改提示词重新生成就行，不用维护代码。
4. 安全合规一条线
从管理角度，你需要在三个层面上放心：
- 数据安全：设备密码在客户端本地加密存储，云端从来没见过。就算云端被攻破，攻击者拿不到任何设备的登录凭证。
- 操作留痕：谁在什么时间对哪台设备执行了哪个脚本、每步命令的输出是什么，全部记录在案。审计的时候一键导出。
- 权限收敛：新人能执行任务，但不能随意修改提示词。提示词的创建和修改由有经验的工程师控制，执行权限下放给一线运维。权责清晰。新人看到的始终是自然语言，不需要接触代码层。
5. 团队可以横向扩展
10 台设备和 200 台设备，管理成本的差异有多大？
在没有自动化的情况下，基本是线性的——设备多 20 倍，人力投入也要多 20 倍。
有了标准化脚本 + 客户端批量执行，200 台设备的一次巡检和一个批处理任务的区别不大。创建任务、关联脚本、勾选设备、点执行，客户端并行连接所有设备。哪台成功哪台失败、失败原因是什么，汇总报告一目了然。
怎么开始？
不需要一次把所有的运维经验都固化。从最频繁、最重复、最依赖特定人的那件事开始。
比如你们团队每个月要改一次 ACL、每周要做数据库健康检查、每天要巡检核心交换机。先挑一件，让最熟悉这件事的人花半小时把提示词写出来，生成脚本，跑一遍，感受一下效果。
单件事跑通了，再逐步扩展。提示词积累到一定程度，你会发现团队对"那个人"的依赖在悄悄降低。
客户端完全开源，免费额度足够跑起来验证价值。
推广期间，如果你有具体的场景想自动化但不确定怎么下手，可以联系我协助定制开发。把需求描述清楚，帮你拆成提示词、生成可执行脚本，免费，就当听听真实反馈。
