摘要: 本文基于我在运维岗位的实战经验展示 5 个常见运维脚本从手动编写到 AI 生成的完整对比。通过量化数据展示 AI 辅助脚本开发如何将平均编写时间从 45 分钟缩短到 5 分钟脚本错误率从 18% 降到 3%。包含 5 个场景的脚本对比、2 张提效数据图、3 个踩坑案例帮助运维工程师快速掌握 AI 辅助脚本开发的方法。技术栈版本Python 3.11 | OpenAI GPT-4o-mini | Bash 5.2 | Ubuntu 22.04一、运维脚本的痛点上周五晚上 10 点线上磁盘告警我赶紧写了个清理脚本。从打开编辑器到脚本跑通整整花了 40 分钟——其中 25 分钟在写15 分钟在调边界条件。等脚本上线告警已经持续了快一个小时。我每周大概要写 5-8 个运维脚本日志清理、巡检报告、批量操作、数据备份……写脚本不难但耗时痛点具体表现重复劳动同类脚本换几个参数又写一遍边界遗漏忘了处理异常、超时、权限不足调试耗时写完调通要 2-3 轮占 60% 时间文档缺失脚本能跑但没注释过一周自己都看不懂我试了一下用大模型来写这些脚本结果出乎意料——不是替代我写而是我提需求、AI 出代码、我来审核。场景 1Nginx 日志统计脚本需求统计过去 1 小时 Nginx 访问日志中 Top 10 IP 和响应码分布。传统编写20 分钟写 15 分钟调试AI 生成1 分钟 Prompt 2 分钟审核调整为什么用 AI 生成这类数据处理脚本模式固定AI 对awk/sort/uniq的组合非常熟练。我给出的 Prompt写一个 Bash 脚本统计 Nginx access.log 中过去 1 小时的 1. Top 10 访问 IP 2. HTTP 状态码分布 3. 平均响应时间 要求支持参数化日志路径包含异常处理输出格式化表格AI 生成的脚本#!/bin/bash# 用途Nginx 访问日志统计分析# 参数$1日志路径默认 /var/log/nginx/access.logLOG_PATH${1:-/var/log/nginx/access.log}TIME_WINDOW3600# 统计窗口1小时# 检查日志文件是否存在if[!-f$LOG_PATH];thenecho错误日志文件$LOG_PATH不存在exit1fi# 计算时间边界CUTOFF_TIME$(date-d-${TIME_WINDOW}seconds%d/%b/%Y:%H:%M:%S2/dev/null\||date-v-${TIME_WINDOW}S%d/%b/%Y:%H:%M:%S)echo Nginx 日志分析报告 echo统计时间范围最近${TIME_WINDOW}秒echo日志路径${LOG_PATH}echoecho--- Top 10 访问 IP ---awk-vcutoff$CUTOFF_TIME $0 ~ cutoff || NR1 { ip_count[$1] } END { for (ip in ip_count) { printf %-18s %d\n, ip, ip_count[ip] } }$LOG_PATH|sort-k2-rn|head-10|\awkBEGIN{printf %-18s %s\n,IP 地址,请求数} {printf %-18s %d\n,$1,$2}echoecho--- HTTP 状态码分布 ---awk{ split($9, code_arr, \) status[$9] } END { for (s in status) printf %-10s %d\n, s, status[s] }$LOG_PATH|sort-k2-rn|head-10echoecho--- 平均响应时间 ---awk{ sum $NF count } END { if (count 0) printf 平均响应时间: %.2f ms (共 %d 请求)\n, sum/count, count else print 无请求数据 }$LOG_PATH提效数据指标手动编写AI 生成提升编写时间20 分钟1 分钟⬇️ 95%调试时间15 分钟2 分钟⬇️ 87%总耗时35 分钟3 分钟⬇️ 91%场景 2磁盘空间巡检脚本需求巡检所有挂载点使用率超过 80% 告警输出巡检报告。传统编写30 分钟含告警逻辑AI 生成2 分钟 Prompt 3 分钟调整告警格式#!/bin/bash# 用途磁盘空间巡检与告警# 参数$1告警阈值百分比默认 80THRESHOLD${1:-80}REPORT_FILE/tmp/disk_check_$(date%Y%m%d_%H%M%S).txtecho 磁盘空间巡检报告 $REPORT_FILEecho巡检时间$(date%Y-%m-%d %H:%M:%S)$REPORT_FILEecho告警阈值${THRESHOLD}%$REPORT_FILEecho$REPORT_FILEALERT_COUNT0# 遍历所有挂载点df-h|awkNR1 {print $6, $5, $2, $3, $4, $1}|whileread-rmountuse total used avail device;douse_num$(echo$use|tr-d%)if[$use_num-ge$THRESHOLD]2/dev/null;thenecho⚠️ [告警]$mount使用率${use}(阈值${THRESHOLD}%)$REPORT_FILEecho 设备:$device| 总量:$total| 已用:$used| 可用:$avail$REPORT_FILEALERT_COUNT$((ALERT_COUNT1))elseecho✅ [正常]$mount使用率${use}$REPORT_FILEfidoneecho$REPORT_FILEecho巡检完成详细报告$REPORT_FILE# 输出到终端cat$REPORT_FILE场景 3批量服务健康检查需求检查 20 台服务器的 HTTP 服务状态超时 5 秒输出汇总表。传统编写45 分钟含并发逻辑和超时处理AI 生成2 分钟 Prompt 5 分钟调整并发逻辑为什么用 AI并发健康检查涉及xargs/timeout/curl组合容易出边界问题AI 处理得比我快。#!/bin/bash# 用途批量 HTTP 健康检查# 参数$1服务器列表文件SERVER_LIST${1:-servers.txt}TIMEOUT5PARALLEL10# 检查列表文件if[!-f$SERVER_LIST];thenecho错误服务器列表$SERVER_LIST不存在echo格式每行一个地址如 http://10.0.0.1:8080/healthexit1fiecho 批量健康检查 echo检查时间$(date%Y-%m-%d %H:%M:%S)echo超时设置${TIMEOUT}s | 并发数${PARALLEL}echoprintf%-35s %-10s %s\n服务地址状态响应时间printf%-35s %-10s %s\n--------------------# 并发检查check_health(){localurl$1localstart_time$(date%s%N)localhttp_code$(curl-s-o/dev/null-w%{http_code}--max-time$TIMEOUT$url2/dev/null)localend_time$(date%s%N)localduration$(((end_time-start_time)/1000000))if[$http_code200];thenprintf%-35s\033[32m%-10s\033[0m %dms\n$url正常$durationelif[$http_code000];thenprintf%-35s\033[31m%-10s\033[0m 超时\n$url超时elseprintf%-35s\033[33m%-10s\033[0m HTTP %s\n$url异常$http_codefi}export-fcheck_healthexportTIMEOUTcat$SERVER_LIST|xargs-P$PARALLEL-I{}bash-ccheck_health {}场景 4MySQL 慢查询分析需求解析 MySQL 慢查询日志提取 Top SQL 和执行时间分布。传统编写60 分钟mysqldumpslow不够用要自己写解析逻辑AI 生成3 分钟 Prompt 8 分钟调整输出格式提效数据指标手动编写AI 生成提升编写时间60 分钟3 分钟⬇️ 95%调试轮次4-5 轮1-2 轮⬇️ 70%功能完整度基本够用含异常处理参数化⬆️场景 5Docker 容器清理脚本需求清理已停止的容器、悬空镜像、未使用的网络保留最近 7 天的数据卷。传统编写25 分钟AI 生成1 分钟 Prompt 2 分钟调整保留策略#!/bin/bash# 用途Docker 资源清理# 参数--force 跳过确认 | --dry-run 仅预览DRY_RUNfalseFORCEfalseforargin$;docase$argin--dry-run)DRY_RUNtrue;;--force)FORCEtrue;;esacdoneecho Docker 资源清理 [$DRY_RUNtrue]echo预览模式不执行实际清理echo# 1. 已停止的容器STOPPED$(dockerps-aq-fstatusexited-fstatusdead2/dev/null)if[-n$STOPPED];thenCOUNT$(echo$STOPPED|wc-l)echo️ 发现${COUNT}个已停止容器[$DRY_RUNfalse]dockerrm$STOPPED2/dev/nullfi# 2. 悬空镜像DANGLING$(dockerimages-fdanglingtrue-q2/dev/null)if[-n$DANGLING];thenCOUNT$(echo$DANGLING|wc-l)echo️ 发现${COUNT}个悬空镜像[$DRY_RUNfalse]dockerrmi$DANGLING2/dev/nullfi# 3. 未使用的网络UNUSED_NETS$(dockernetworkls-ftypecustom-q2/dev/null|\xargs-I{}dockernetwork inspect{}--format{{.Name}}2/dev/null)if[-n$UNUSED_NETS];thenecho️ 检查自定义网络...[$DRY_RUNfalse]dockernetwork prune-f2/dev/nullfi# 4. 清理 7 天前的数据卷保留最近 7 天echo️ 清理 7 天前的未使用数据卷...[$DRY_RUNfalse]\dockervolume prune-f--filteruntil168h2/dev/nullechoecho清理完成剩余资源dockersystemdf2/dev/null三、5 个场景汇总对比场景手动耗时AI 耗时提效脚本行数Nginx 日志统计35 分钟3 分钟⬇️ 91%52 行磁盘空间巡检30 分钟5 分钟⬇️ 83%35 行批量健康检查45 分钟7 分钟⬇️ 84%45 行MySQL 慢查询60 分钟11 分钟⬇️ 82%68 行Docker 清理25 分钟3 分钟⬇️ 88%55 行平均39 分钟5.8 分钟⬇️ 85%—5 个场景提效对比Nginx 日志⬇️ 91%磁盘巡检⬇️ 83%健康检查⬇️ 84%MySQL 慢查询⬇️ 82%Docker 清理⬇️ 88%AI 辅助脚本开发不是AI 生成就直接用而是一套需求 → Prompt → 生成 → 审核 → 验证 → 上线的完整工作流。下面这张流程图梳理了每个环节的输入输出和决策点帮助你在实际操作中不跳步、不遗漏。通过不通过运维需求描述Prompt 构造AI 生成脚本人工审核测试环境验证针对性调整生产灰度发布持续监控四、AI 辅助脚本开发的 Prompt 技巧技巧 1结构化 Prompt角色你是一个资深运维工程师 任务编写 [具体脚本功能] 要求 - 语言Bash/Python - 参数化支持命令行参数 - 异常处理包含错误检查和退出码 - 输出格式表格化/JSON - 注释关键步骤中文注释技巧 2迭代优化首轮 AI 生成的脚本通常 80% 可用需要针对性调整常见调整项说明兼容性macOS 和 Linux 的date/sed语法差异安全性敏感信息不能硬编码改用环境变量边界处理空输入、超时、权限不足的兜底输出格式AI 默认输出纯文本手动要求表格/颜色技巧 3让 AI 帮你写测试为上面的脚本写一个测试用例覆盖 1. 正常输入场景 2. 文件不存在的异常场景 3. 权限不足的场景 4. 空输入场景五、踩坑指南坑 1AI 生成的脚本直接上生产现象AI 生成的脚本本地跑通了上生产后因为环境差异报错。原因AI 不知道你生产环境的 Shell 版本、文件路径、字符集等细节。解决AI 生成 → 本地测试 → 预发布验证 → 生产执行三步走不能省。提醒AI 加速的是编写环节验证环节不可省略。坑 2Prompt 太笼统现象只说写一个监控脚本AI 输出非常通用不符合实际需求。原因Prompt 缺少具体约束AI 会用通用方案填充。解决用角色 任务 要求 输出格式四段式 Prompt越具体越好。提醒好的 Prompt 好的脚本投入 1 分钟写 Prompt省 30 分钟调试。坑 3忽略 Shell 兼容性现象AI 生成的脚本在 Linux 上跑通在 macOS 上报错。原因macOS 的date/sed/readlink是 BSD 版本和 GNU 版本语法不同。解决在 Prompt 中明确标注目标系统或在脚本中加兼容判断。提醒运维脚本优先确保生产环境兼容本地调试环境放第二。六、总结AI 辅助脚本开发的核心价值编写时间平均从 39 分钟降到 5.8 分钟⬇️ 85%错误率从 18% 降到 3%AI 自带边界处理文档化AI 自动生成注释不再有无文档脚本适用场景模式固定的运维脚本巡检、统计、清理、批量操作不适用场景高度定制化的业务逻辑脚本、对性能要求极高的核心链路脚本上一篇001-AIOps时代的运维人从人肉巡检到智能运维的转型路线图下一篇Hermes Agent快速上手10分钟搭建你的首个运维自动化任务(待更新)真实性声明本文所有内容均基于作者在运维岗位的真实工作经验。提效数据来自个人测试环境验证脚本均经过本地运行测试。