周一清晨，领导一口气布置了三个任务：Nginx日志统计、磁盘巡检阈值调整，以及20台服务器的健康检查。这种场景对运维来说再熟悉不过了——手头正在写脚本，新需求又接踵而至。手动编写一个脚本通常需要30到60分钟，三个任务干完基本就到下午了。
真正的痛点不在于不会写，而在于写的都是没什么技术含量的重复代码，还总在边界条件和调试环节翻车。一起来看看几个典型痛点：
| 痛点 | 实际感受 |
|---|---|
| 重复劳动 | 同类脚本换几个参数又重写一遍，令人厌烦 |
| 边界遗漏 | 运行时才报错，总是忘记处理文件不存在、权限不足等情况 |
| 调试耗时 | 写完到调通需要2到3轮，60%的时间都消耗在调试上 |
| 文档缺失 | 脚本能跑但没注释，两周后自己都看不懂 |
后来尝试让AI生成脚本——不是全交给AI，而是自己提需求，AI出代码，自己来审核。结果令人惊喜。
五个真实场景的提效实录
场景1：Nginx日志统计——从35分钟缩短到3分钟
需求是统计过去1小时Nginx访问日志中Top 10 IP和响应码分布。以前需要花20分钟编写、15分钟调试awk/sort/uniq命令组合，每次都得查man手册。现在只需1分钟写Prompt，2分钟审核调整，轻松搞定。
Prompt是这样的：写一个Bash脚本，统计Nginx access.log中过去1小时的：1. Top 10 访问IP 2. HTTP状态码分布 3. 平均响应时间。要求支持参数化日志路径，包含异常处理，输出格式化表格。
AI生成的脚本节选：
#!/bin/bash
LOG_PATH="${1:-/var/log/nginx/access.log}"
TIME_WINDOW=3600
if [ ! -f "$LOG_PATH" ]; then
echo "错误：日志文件 $LOG_PATH 不存在"
exit 1
fi
echo "========== Nginx 日志分析报告 =========="
echo "--- Top 10 访问 IP ---"
awk -v cutoff="$CUTOFF_TIME" '...' | sort -k2 -rn | head -10
echo "--- HTTP 状态码分布 ---"
awk '{...}' | sort -k2 -rn | head -10
| 指标 | 手动编写 | AI生成 | 提升 |
|---|---|---|---|
| 总耗时 | 35分钟 | 3分钟 | ⬇️ 91% |
场景2：磁盘空间巡检——从30分钟缩减到5分钟
需求是巡检所有挂载点，使用率超过80%触发告警，并输出巡检报告。AI生成只用了2分钟写Prompt，3分钟调整告警格式：
THRESHOLD="${1:-80}"
df -h | awk 'NR>1 {print $6, $5}' | while read -r mount use; do
use_num=$(echo "$use" | tr -d '%')
if [ "$use_num" -ge "$THRESHOLD" ]; then
echo "⚠️[告警] $mount 使用率 ${use}"
else
echo "✅[正常] $mount 使用率 ${use}"
fi
done
| 指标 | 手动编写 | AI生成 | 提升 |
|---|---|---|---|
| 总耗时 | 30分钟 | 5分钟 | ⬇️ 83% |
场景3：批量健康检查——从45分钟降低到7分钟
需求是检查20台服务器的HTTP状态，超时时间设为5秒，输出汇总表。传统写法最怕处理xargs/timeout/curl组合的并发逻辑——一个超时处理不当，整个脚本就会卡死。AI一次性生成，只需确认并发参数：
check_health() {
local url=$1
local http_code=$(curl -s -o /dev/null -w "%{http_code}" --max-time "$TIMEOUT" "$url" 2>/dev/null)
if [ "$http_code" = "200" ]; then
printf "%-35s 正常 %dms" "$url" "$duration"
elif [ "$http_code" = "000" ]; then
printf "%-35s 超时" "$url"
else
printf "%-35s 异常 HTTP %s" "$url" "$http_code"
fi
}
export -f check_health
cat "$SERVER_LIST" | xargs -P 10 -I {} bash -c 'check_health "{}"'
| 指标 | 手动编写 | AI生成 | 提升 |
|---|---|---|---|
| 总耗时 | 45分钟 | 7分钟 | ⬇️ 84% |
场景4：MySQL慢查询分析——从60分钟压缩到11分钟
需求是解析MySQL慢查询日志，提取Top SQL和执行时间分布。这是5个场景中最耗时的——mysqldumpslow功能有限，自己编写解析逻辑光调试就要4到5轮。AI一次性搞定了参数化、异常处理和输出格式。
| 指标 | 手动编写 | AI生成 | 提升 |
|---|---|---|---|
| 编写时间 | 60分钟 | 3分钟 | ⬇️ 95% |
| 调试轮次 | 4-5轮 | 1-2轮 | ⬇️ 70% |
| 功能完整度 | 基本够用 | 含异常处理+参数化 | ⬆️ |
场景5：Docker容器清理——从25分钟降至3分钟
# 用途：Docker资源清理 # 参数：--dry-run 仅预览 | --force 跳过确认 # 1. 已停止的容器 STOPPED=$(docker ps -aq -f status=exited -f status=dead) # 2. 悬空镜像 DANGLING=$(docker images -f "dangling=true" -q) # 3. 清理7天前的数据卷 docker volume prune -f --filter "until=168h" # 4. 预览模式 [ "$DRY_RUN" = true ] && echo "（预览模式）"
| 指标 | 手动编写 | AI生成 | 提升 |
|---|---|---|---|
| 总耗时 | 25分钟 | 3分钟 | ⬇️ 88% |
汇总：平均从39分钟到5.8分钟
| 场景 | 手动耗时 | 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% | — |
三个Prompt技巧，让AI一次出活
技巧1：结构化Prompt——「角色+任务+要求+输出」四段式
角色：你是一个资深运维工程师 任务：编写 [具体脚本功能] 要求： - 语言：Bash/Python - 参数化：支持命令行参数 - 异常处理：包含错误检查和退出码 - 输出格式：表格化/JSON - 注释：关键步骤中文注释
技巧2：迭代优化——首轮80%可用，剩下20%针对性调整
首轮生成后，针对具体问题提出修正要求，这比重写Prompt效率高得多。
技巧3：让AI自测——生成脚本后立即写测试用例
为上面的脚本写一个测试用例，覆盖： 1. 正常输入场景 2. 文件不存在的异常场景 3. 权限不足的场景 4. 空输入场景
踩坑指南：这三个坑提前帮你踩过了
坑1：AI生成的脚本直接上生产
现象是本地跑通了，一上生产就因为环境差异报错——Shell版本不同、文件路径不一致、字符集不对。解决方案很简单：AI生成 → 本地测试 → 预发布验证 → 生产执行，三步流程不能省。
坑2：Prompt太笼统
只说“写一个监控脚本”，AI输出非常通用，完全不实用。用四段式Prompt把需求说清楚，你对需求多清晰，AI产出就有多精准。
坑3：忽略Shell兼容性
Linux上跑通的脚本，在macOS上报错。原因在于macOS的date/sed/readlink是BSD版，和GNU语法不同。解决方法是在Prompt中标明目标系统，或在脚本中加兼容判断。
总结：AI辅助脚本开发的三个核心价值
编写时间⬇️ 85%：平均从39分钟降到5.8分钟。错误率⬇️ 83%：从18%降到3%，AI自带边界处理。文档化✅：AI自动生成注释，不再留有“无文档脚本”。
这个思路适用于模式固定的运维脚本，比如巡检、统计、清理、批量操作。不适用的是高度定制化的业务逻辑脚本，以及对性能要求极高的核心链路脚本。
