系列第二篇：上一篇介绍了 Codex 对运维场景的价值，本篇聚焦核心技能------如何写出高质量的提示词，让 AI 一次输出可用脚本，而不是反复拉锯。
一、为什么提示词决定 80% 的脚本质量？
同样让 Codex 生成一个"磁盘监控脚本"，看看两种写法的差距：
写法 A（模糊）：
帮我写个磁盘监控脚本输出结果： 一个 df -h 加简单 echo 的 10 行脚本，没有告警、没有阈值、没有日志。
写法 B（结构化）：
请用 Bash 写一个磁盘使用率监控脚本，要求：
- 检查所有挂载点的磁盘使用率
- 阈值：使用率超过 85% 时告警
- 告警方式：发送钉钉 Webhook 通知（Webhook URL 通过环境变量 DINGTALK_WEBHOOK 读取）
- 每次检查结果追加写入 /var/log/disk_monitor.log，格式：[时间戳] [挂载点] [使用率]
- 脚本可直接加入 crontab，每 5 分钟执行一次
- 包含错误处理：curl 失败时记录错误日志但不退出输出结果： 一个带告警、带日志、带环境变量注入、带错误处理的生产级脚本。
二、运维 Prompt 的黄金结构
总结成一个公式：
【脚本类型】+ 【核心功能】+ 【输入/输出】+ 【异常处理】+ 【运行环境约束】+ 【输出格式要求】逐项拆解：
| 要素 | 说明 | 示例 |
|---|---|---|
| 脚本类型 | Bash / Python / Ansible | "请用 Python 3.8+" |
| 核心功能 | 动词 + 对象，越具体越好 | "批量 SSH 登录并执行命令" |
| 输入/输出 | 入参格式、输出位置 | "从 hosts.txt 读取 IP 列表，结果输出到 result.csv" |
| 异常处理 | 超时、失败、权限问题 | "单机失败不影响其他机器继续执行" |
| 运行环境约束 | OS 版本、Python 版本、依赖限制 | "只能用标准库，不能安装第三方包" |
| 输出格式要求 | 代码注释、函数封装等 | "每个函数加 docstring，使用 argparse 解析参数" |
三、七个高效 Prompt 模板（直接复用）
模板 1：批量操作类
请用 Bash 写一个脚本，实现以下批量操作：
目标：对 hosts.txt 中的每台服务器（每行一个 IP）执行以下操作：
1. 检查 [服务名] 服务状态
2. 如果服务未运行，尝试启动并等待 10 秒
3. 再次检查状态，仍未运行则记录为失败
输出：生成 report_YYYYMMDD.txt，包含每台机器的 IP、状态（成功/失败）、耗时
要求：
- 最大并发 10 台
- SSH 超时设置 5 秒
- 失败的机器不影响其他机器继续执行
- 最终统计成功/失败数量模板 2：日志处理类
请用 Python 写一个日志分析脚本：
输入：/var/log/nginx/access.log（标准 Nginx 日志格式）
分析维度：
1. 统计每个 URI 的请求次数，按降序排列，取 Top 20
2. 统计每小时请求量，输出为时序数据
3. 找出响应时间超过 2 秒的请求，记录 URI、时间、客户端 IP
输出：
- 控制台打印 Top 20 URI 表格
- 生成 analysis_YYYYMMDD.json，包含完整分析结果
依赖：只用 Python 标准库（re、collections、json、datetime）模板 3：监控告警类
请用 Bash 写一个系统资源监控脚本：
监控指标：
- CPU 使用率（1 分钟平均）
- 内存使用率
- 磁盘 I/O wait 百分比
- TCP 连接数（ESTABLISHED 状态）
告警阈值：
- CPU > 90%
- 内存 > 85%
- I/O wait > 30%
- TCP 连接 > 1000
告警通道：企业微信 Webhook（URL 从 ENV 变量 WEIXIN_WEBHOOK 读取）
执行方式：可作为 crontab 每分钟调用，重复告警间隔 10 分钟（通过标志文件实现）模板 4：部署发布类
请用 Bash 写一个应用部署脚本，部署流程如下：
1. 从参数 $1 读取版本号（格式：v1.2.3）
2. 从 Nexus 下载对应版本的 JAR 包（URL 模板：${NEXUS_BASE_URL}/app-${version}.jar）
3. 备份当前运行的 JAR（备份到 /backup/app/）
4. 停止现有服务（systemctl stop app-service，等待最多 30 秒）
5. 替换 JAR 包并启动服务
6. 健康检查：请求 http://localhost:8080/health，连续 3 次 200 则判定成功
7. 失败时自动回滚到备份版本
输出：每个步骤打印带时间戳的进度日志模板 5：定时清理类
请用 Python 写一个文件清理脚本：
清理规则（从配置文件 cleanup.yaml 读取）：
- 支持配置多个目录
- 每个目录可单独配置：保留天数、文件扩展名过滤、最小保留文件数
清理逻辑：
- 按修改时间判断
- 确保每个目录至少保留最近 N 个文件（即使超过天数限制）
- 删除前打印将被删除的文件列表，--dry-run 参数时只打印不删除
日志：记录每次运行的删除文件数、释放空间（MB）到 SQLite 数据库，支持查询历史记录模板 6：数据同步类
请用 Python 写一个数据库备份脚本：
数据库：MySQL 5.7+
功能：
1. 读取 /etc/backup/db_list.conf 中的数据库列表（每行一个库名）
2. 对每个库执行 mysqldump，压缩为 gz 格式
3. 上传到阿里云 OSS（Bucket 名和 AK/SK 从环境变量读取）
4. 保留本地最近 3 天备份，OSS 保留 30 天
5. 备份完成后发送结果通知到钉钉
错误处理：单个库失败不影响其他库，最终汇总失败列表
依赖：只允许使用 oss2、subprocess、logging（不用其他第三方库）模板 7：巡检报告类
请用 Python 生成一个服务器巡检脚本：
巡检项目（通过 SSH 连接执行）：
- 系统基本信息（OS 版本、内核、运行时间）
- CPU / 内存 / 磁盘使用率
- 僵尸进程数量
- 系统日志最近 100 行中的 ERROR/WARN 统计
- 开放端口列表
- 关键服务状态列表（从配置文件读取服务名）
输入：从 inventory.csv 读取主机列表（列：ip, hostname, username, key_path）
输出：生成 HTML 格式的巡检报告，包含汇总表和每机器详情
依赖：paramiko、jinja2四、让输出质量翻倍的 5 个追加指令
每次生成完基础脚本后，用以下追加提示词进一步优化：
bash
# 追加 1：强化错误处理
"请检查脚本中所有可能失败的操作，添加对应的错误处理和有意义的错误提示"
# 追加 2：添加参数解析
"请为脚本添加命令行参数支持，使用 argparse（Python）或 getopts（Bash），
并添加 --help 说明"
# 追加 3：要求日志规范
"请将所有 echo/print 替换为标准日志格式：[YYYY-MM-DD HH:MM:SS] [LEVEL] message，
同时写入日志文件和标准输出"
# 追加 4：生产安全加固
"请检查脚本的安全性：避免明文密码、路径注入风险、权限最小化建议"
# 追加 5：生成配套文档
"请为这个脚本生成使用说明，包含：功能描述、依赖安装、配置说明、使用示例、
注意事项"五、常见踩坑 & 规避方法
| 坑 | 现象 | 规避方法 |
|---|---|---|
| 路径硬编码 | 生成的脚本写死 /home/ubuntu | 在提示词中注明"路径通过参数或环境变量传入" |
| 依赖版本假设 | 用了某些版本特有语法 | 明确说明"Python 3.8+" 或 "CentOS 7 的 Bash 4.x" |
| 缺少幂等性 | 重复执行会出错 | 要求"脚本可重复执行，已存在的资源跳过而不是报错" |
| 密码明文 | 直接把密码写在脚本里 | 要求"敏感信息从环境变量或 .env 文件读取" |
| 无超时控制 | SSH/HTTP 请求永久阻塞 | 要求"所有网络操作设置超时，SSH 超时 N 秒" |
| 并发不可控 | 同时操作几百台机器 | 要求"最大并发数通过参数控制，默认 10" |
六、小结：Prompt 质量检查清单
在发送提示词之前，对照这个清单：
- 是否指定了脚本语言和版本？
- 是否描述了完整的输入来源和输出目标？
- 是否说明了错误处理预期？
- 是否提及了运行环境约束？
- 是否明确了敏感信息处理方式？
- 是否要求了幂等性（如果需要）？
达到 5/6 以上，你的脚本生成质量会大幅提升。
下一篇，我们将直接动手：用以上模板批量生成 5 个真实运维场景的 Shell 脚本，逐行解析，拿来即用。
觉得有用请点赞收藏，你的支持是持续更新的动力 🛠️