大模型辅助运维脚本生成：用Prompt Engineering让AI写出生产级Shell自动化脚本

一、运维脚本的本质与大模型的能力边界

运维脚本的核心特质不是代码复杂度，而是对边界条件的穷举。一个日志清理脚本，真正有价值的代码不是rm -rf那一行，而是前面五个if判断——磁盘使用率是否超过阈值、文件是否在保留名单内、当前是否有进程正在写入、操作是否在维护窗口内、执行结果是否需要审计记录。这些边界条件源自运维人员长期的踩坑经验，大模型在没有领域知识注入的情况下，生成的脚本往往只覆盖了主干路径。

但这不意味着大模型不适合写运维脚本。相反，它在两个维度上表现出色：一是语法层面——Shell/Python的代码生成准确率在GPT-4级别模型上已超过90%。二是模式迁移——当你给出一个已有的生产级脚本作为参考，模型能准确地将其中的错误处理模式、日志格式、锁机制等工程实践迁移到新场景。难点在于如何通过Prompt Engineering将运维领域知识精确注入到生成过程中。

二、运维脚本生成的五层Prompt架构

flowchart TD
    A[任务描述层<br/>明确做什么、在哪做、做到什么程度] --> B[约束规范层<br/>安全性、幂等性、可观测性要求]
    B --> C[上下文注入层<br/>环境变量、目录结构、依赖工具版本]
    C --> D[参考模式层<br/>已有生产级脚本的错误处理范式]
    D --> E[验证检查层<br/>预期输出、边界测试用例、回滚方案]
    
    E --> F[LLM生成]
    F --> G{人工审查}
    G -->|通过| H[沙箱验证]
    G -->|不通过| A
    H -->|通过| I[发布至Ansible/Git仓库]
    H -->|不通过| A

任务描述层要回答三个问题：这个脚本的输入和输出分别是什么，执行环境是什么（操作系统版本、Shell类型、可用命令），成功/失败的判定标准是什么。

约束规范层最为关键。每个运维脚本必须承载三类约束：安全性（不允许以root运行、敏感信息不写明文）、幂等性（重复执行不产生副作用）、可观测性（每步操作输出带时间戳的日志，退出时返回明确的退出码）。这些约束在Prompt中应当以"必须遵守"的强制性语气表达，而非"建议"。

上下文注入层填写环境信息。例如：DATA_DIR=/data/app/logs，保留策略为保留最近7天，压缩超过3天的文件，脚本以appuser用户运行，可用磁盘空间剩余不小于20%。

参考模式层是Prompt Engineering产出生产级质量脚本的核心。不是简单地给一个示例，而是给一个经过验证的错误处理范式：

# 错误处理范式（作为Prompt的Few-shot示例注入）
#!/bin/bash
set -euo pipefail  # 任何命令失败立即退出，未定义变量报错，管道中任一命令失败都失败

# ─── 公共函数定义 ───
log_info() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [INFO] $*" | tee -a "${LOG_FILE:-/var/log/ops_script.log}"
}

log_error() {
    echo "[$(date '+%Y-%m-%d %H:%M:%S')] [ERROR] $*" | tee -a "${LOG_FILE:-/var/log/ops_script.log}" >&2
}

# 锁机制：防止脚本并发执行
acquire_lock() {
    local lock_file="${LOCK_FILE:-/tmp/$(basename "$0").lock}"
    exec 200>"$lock_file"
    if ! flock -n 200; then
        log_error "脚本已在运行中，获取锁失败: $lock_file"
        exit 1
    fi
    # 记录当前PID用于排障
    echo $$ > "$lock_file.pid"
}

# 安全清理：退出时自动释放锁和清理临时文件
cleanup() {
    local exit_code=$?
    # 清理临时文件
    rm -f "${TEMP_FILE:-}"
    # 释放文件锁（文件描述符关闭自动释放）
    exec 200>&-
    log_info "脚本结束，退出码: $exit_code"
    exit $exit_code
}
trap cleanup EXIT INT TERM

# 预检查：执行环境校验
preflight_check() {
    local required_cmds=("jq" "curl" "awk")
    for cmd in "${required_cmds[@]}"; do
        if ! command -v "$cmd" &>/dev/null; then
            log_error "缺少必要命令: $cmd，请先安装"
            exit 2
        fi
    done
    log_info "环境检查通过"
}

将这个范式注入Prompt后，模型的生成结果会自然地包含锁机制、信号处理、预检查和统一日志。

三、实战Prompt设计与生成效果对比

以下是一个真实场景的Prompt设计——生成K8s集群节点自动排水（drain）脚本：

【任务描述】
生成一个Kubernetes节点安全排水脚本，功能包括：
- 接收节点名列表作为参数
- 对每个节点执行kubectl drain操作
- 排水前检查节点上是否有使用Local PV的Pod（这类Pod排水后数据丢失，需要人工确认）
- 排水超时时间为5分钟/节点

【约束规范-必须遵守】
- 使用set -euo pipefail
- 每步操作输出带时间戳的日志（格式：[YYYY-MM-DD HH:MM:SS] [LEVEL] message）
- 使用flock文件锁防止并发
- 通过trap注册清理函数
- 所有kubectl命令必须指定--context参数，从KUBE_CONTEXT环境变量读取
- 返回明确的退出码：0=成功 1=运行时错误 2=参数错误 3=环境不满足
- 涉及删除操作前必须输出"DRY RUN:"提示并等待5秒（可通过--force跳过）

【上下文】
- 运行环境: Linux amd64, bash 5.x
- kubectl版本: v1.28+
- KUBE_CONTEXT: 从环境变量读取，默认值"production"
- 日志输出路径: /var/log/k8s-ops/drain_$(date +%Y%m%d).log

【验证用例】
- 正常排水：./drain_nodes.sh node-1 node-2
- 包含LocalPV Pod的节点：预期脚本应提示警告并要求确认
- 节点不存在：预期脚本应报错并跳过
- 重复执行：预期脚本应通过锁机制防止并发

未使用上述Prompt架构时，模型生成的脚本缺失了锁机制、Local PV检测、退出码规范。

使用五层架构后，生成率显著提升：

四、生成的自动化：从Prompt到Git仓库的工作流

sequenceDiagram
    participant PM as Prompt管理库(Git)
    participant CI as CI流水线
    participant LLM as 大模型API
    participant Test as 沙箱验证环境
    participant Repo as 运维脚本仓库
    
    PM->>CI: 提交新Prompt
    CI->>LLM: 调用API生成脚本
    LLM-->>CI: 返回生成的Shell脚本
    
    CI->>Test: shellcheck静态分析
    Test-->>CI: 通过/不通过
    
    alt shellcheck通过
        CI->>Test: 在Docker容器中执行Dry-run
        Test-->>CI: 通过/不通过
        alt Dry-run通过
            CI->>Repo: 提交脚本至review分支
            Repo->>Repo: 人工Review后合并至main
        else Dry-run失败
            CI->>CI: 记录失败原因，标记需人工处理
        end
    else shellcheck不通过
        CI->>CI: 标记需人工处理
    end

这个流水线的关键是"不直接合入主干"。生成的脚本始终停留在review分支，必须有人工审查。这不是对大模型能力的低估，而是对运维操作的最小敬畏——任何直接操作线上环境的代码，都应当有第二双眼睛确认。

此外，Prompt本身的版本管理也是工程化的重要环节。每条Prompt应当作为代码一样纳入Git管理，包含版本号、变更记录和使用效果跟踪。当一个Prompt被20个运维人员使用、生成了100个脚本后，它的形态会趋于稳定——经过反复验证的Prompt模板是整个团队的知识沉淀，其价值远超任何一个具体脚本。

在实际推行中，最常见的阻力是运维人员对大模型的不信任——"它生成的脚本我不敢用"。消除这种顾虑最有效的方式不是说服，而是展示。将生成的脚本和人工编写的同功能脚本放在一起做盲评对比，大模型在语法规范性、错误处理覆盖率和安全实践方面通常优于多数中级运维工程师的手写代码。当然，前提是Prompt设计得当。

还有一个实际的效益：大模型可以将一次脚本的编写时间从2小时压缩到15分钟（含Prompt调整和验证）。对于每周需要编写3-5个运维脚本的团队来说，这一个月就能节省约30人时的重复性工作，让工程师腾出精力去处理更复杂的架构问题。

ShellCheck是第一步自动检查，它能检测出常见的陷阱：未加引号的变量展开、cd后未检查返回码、find -exec中的命令注入风险。

# 集成ShellCheck到CI的示例（.gitlab-ci.yml片段）
shellcheck-review:
  stage: test
  image: koalaman/shellcheck-alpine:latest
  script:
    # 排除特定规则：
    # SC1091: 不追踪source的外部文件
    # SC2034: 允许未使用的变量（某些环境变量可能后续使用）
    - shellcheck --severity=warning
        --exclude=SC1091,SC2034
        generated_scripts/*.sh
  allow_failure: false  # 静态检查不通过则阻断流水线

五、总结

用大模型写运维脚本，本质是把运维经验编码进Prompt的过程。五层架构（任务描述→约束规范→上下文注入→参考模式→验证检查）是当前经过验证的有效方法。它不追求一次生成即完美，而是将质量保障前置到Prompt设计阶段。

核心原则有三条。第一，约束规范层必须用强制性语气，非协商。第二，参考模式层必须注入真实生产级代码的错误处理范式，而非简单示例。第三，生成后的脚本必须经过ShellCheck + 沙箱Dry-run + 人工Review三道关卡才能上线。

这种方法论的ROI不在于节省写代码的时间（设计一次完整的五层Prompt通常就需要30分钟），而在于保证同一组织内所有运维脚本的质量一致性——每个脚本都带着锁机制、信号处理、分级日志和退出码规范，不再依赖个人水平波动。