1. 运维脚本的重复劳动到底卡在哪一步磁盘巡检、服务状态检查、日志关键字筛查这三件事几乎占掉运维日常一半以上的时间。脚本本身逻辑不复杂但每次写都要重新处理一堆细节df -h输出里要过滤tmpfs和loop设备systemctl is-active返回的字符串要判断find删文件要加2/dev/null屏蔽报错日志统计要处理空文件。这些细节单看都不难但组合起来就是 30 到 60 分钟的调试成本。更麻烦的是环境差异。同一段 Shell 在 CentOS 7 上跑得好好的换到 Ubuntu 22.04 可能因为awk字段位置不同直接输出错位。Python 脚本里os.popen在部分精简系统上返回空字符串导致服务状态判断永远为“异常”触发无意义的重启。手写脚本的容错往往靠经验堆出来换个人维护就得重新踩一遍坑。Codex 这类代码生成模型的价值就在这里它见过大量运维场景的代码模式能直接输出带容错、带日志、带状态判断的脚本骨架。你不需要从零写while read循环只需要把业务需求描述清楚让它生成可运行的第一版然后在此基础上做适配。实测下来一个中等复杂度的巡检脚本从需求到可运行时间可以压到几分钟以内。但这里有个前提你得有一个稳定的模型调用通道。直接用官方接口在国内网络环境下经常遇到超时、连接重置调试脚本时频繁断连非常影响节奏。所以这篇会先讲怎么用 TaoToken 统一 Key 把 Codex 通道配好再进入三个实战场景的脚本生成与验证。适合已经写过基础 Shell/Python、想用 AI 提效但还没跑通接入流程的运维同学。2. TaoToken 统一 Key 接入 Codex 通道TaoToken 的作用是把模型调用统一到一个 API 入口你不需要分别维护多个平台的 Key也不用在代码里硬编码不同厂商的 Base URL。对于运维场景来说这意味着你的脚本里调用模型做日志分析、告警摘要时只需要一套鉴权信息。先拿到 API Key。打开 https://taotoken.net/api-keys 登录后创建一个新 Key复制保存。这个 Key 后面会用在环境变量或配置文件里不要直接写进脚本提交到 Git。Base URL 统一用https://taotoken.net/api不要加 UTM 参数。模型 ID 根据你用的工具填Codex 场景一般用gpt-4o或claude-sonnet-4-20250514这类支持代码生成的模型具体以控制台模型列表为准。如果你用的是 Claude Code 做脚本润色和补全配置方式是在项目根目录创建.claude/settings.json{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_API_KEY: sk-你的TaoTokenKey, ANTHROPIC_MODEL: claude-sonnet-4-20250514 } }如果你用的是 Cline 或 Roo Code 这类 VS Code 插件在插件设置里填三件套配置项值Base URLhttps://taotoken.net/apiAPI Keysk-你的TaoTokenKeyModel IDgpt-4o或控制台可用模型Codex CLI 用户如果走auth.json方式文件路径通常在~/.codex/auth.json内容格式{ base_url: https://taotoken.net/api, api_key: sk-你的TaoTokenKey, model: gpt-4o }配好之后先做一次最小验证确认通道通。用 curl 发一个简单请求curl -s https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoTokenKey \ -d { model: gpt-4o, messages: [{role: user, content: 输出一个bash函数打印当前时间}], max_tokens: 100 }如果返回 JSON 里choices[0].message.content有内容说明 Key 和通道都正常。如果返回 401检查 Key 是否复制完整、有没有多余空格。如果返回local proxy failed或连接超时检查 Base URL 是否写成了带路径的完整地址正确写法就是https://taotoken.net/api后面由 SDK 自动拼接/v1/chat/completions。这一步跑通之后后面所有脚本生成和调试都可以走这个通道。你可以在终端里用export把 Key 设成环境变量避免每次输入export TAOTOKEN_API_KEYsk-你的TaoTokenKey export TAOTOKEN_BASE_URLhttps://taotoken.net/api然后写一个简单的 Python 封装函数后面脚本里直接调用import os import requests def ask_codex(prompt, modelgpt-4o): url f{os.environ[TAOTOKEN_BASE_URL]}/v1/chat/completions headers { Authorization: fBearer {os.environ[TAOTOKEN_API_KEY]}, Content-Type: application/json } payload { model: model, messages: [{role: user, content: prompt}], temperature: 0.2 } resp requests.post(url, jsonpayload, headersheaders, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content]这个函数后面在日志分析脚本里会用到。温度设 0.2 是为了让代码生成更稳定减少随机性。3. 磁盘巡检脚本从提示词到可运行 Shell磁盘爆满是最典型的运维突发故障。凌晨两点收到告警登上去发现/var/log或者/tmp占满业务写入失败。手动处理流程是df -h看哪个分区满du -sh逐层找大文件确认可以删的日志find清理再确认空间释放。这套动作如果写成脚本配合 crontab 每天跑一次就能把大部分爆满风险提前处理掉。给 Codex 的提示词要具体到阈值、路径、容错要求。我用的模板是这样的编写一个 Linux Shell 运维脚本实现服务器磁盘自动巡检和清理 1. 检测所有挂载目录磁盘使用率过滤 tmpfs 和 loop 设备 2. 使用率超过 85% 输出警告超过 90% 输出严重告警 3. 自动清理 /tmp 目录下 7 天前的普通文件 4. 自动清理 /var/log 目录下 7 天前的 .gz 压缩日志 5. 所有操作记录到 ./disk_check_log.txt带时间戳 6. 目录不存在时不报错命令执行错误屏蔽 stderr 7. 输出简洁的巡检结果到终端。Codex 生成的脚本骨架大致如下我做了少量路径适配#!/bin/bash # 磁盘自动化巡检日志清理脚本 LOG_PATH./disk_check_log.txt WARN_THRESHOLD85 ERROR_THRESHOLD90 log_print(){ echo [$(date %Y-%m-%d %H:%M:%S)] $1 $LOG_PATH echo [$(date %Y-%m-%d %H:%M:%S)] $1 } check_disk_usage(){ df -h | grep -vE Filesystem|tmpfs|loop | awk {print $1,$5,$6} | while read -r part use mount do use_num${use%?} if [ $use_num -ge $ERROR_THRESHOLD ]; then log_print 【严重告警】挂载点 $mount 使用率 $use即将爆满 elif [ $use_num -ge $WARN_THRESHOLD ]; then log_print 【警告】挂载点 $mount 使用率 $use建议清理 else log_print 【正常】挂载点 $mount 使用率 $use fi done } safe_clean_log(){ log_print 开始执行过期日志清理 if [ -d /tmp ]; then find /tmp -type f -mtime 7 -delete 2/dev/null log_print 已清理 /tmp 目录 7 天前文件 fi find /var/log -name *.gz -type f -mtime 7 -delete 2/dev/null log_print 已清理 /var/log 目录 7 天前压缩日志 } main(){ log_print 开始磁盘巡检 check_disk_usage safe_clean_log log_print 巡检结束 } main保存为disk_check.sh加执行权限chmod x disk_check.sh本地跑一次看输出./disk_check.sh终端会打印每个挂载点的使用率和清理结果同时disk_check_log.txt里会有完整记录。如果某个分区使用率超过 90%你会看到严重告警行。清理部分会实际删除/tmp下 7 天前的文件和/var/log下 7 天前的.gz文件测试时可以先注释掉find -delete行换成find ... -print确认匹配范围。这个脚本的容错点在于grep -vE过滤了虚拟文件系统2/dev/null屏蔽了权限不足的报错${use%?}去掉了百分号再做数值比较。如果你在 Ubuntu 上跑df -h输出格式略有不同但awk {print $1,$5,$6}取的是设备、使用率、挂载点字段位置一致不需要改。配 crontab 每天凌晨 3 点执行crontab -e加入一行0 3 * * * /path/to/disk_check.sh /var/log/disk_check_cron.log 21这样每天自动巡检一次日志留在disk_check_log.txt里可以追溯。4. 服务监控自愈脚本Python 版生成与验证磁盘巡检是预防性的服务监控则是故障自愈。Nginx、MySQL、Redis 这些核心服务如果挂了人工发现往往有延迟。用 Python 写一个监控脚本检测到服务停止就自动重启重启后延时校验状态失败则输出告警日志。提示词模板编写一个 Python 运维脚本监控 nginx、mysqld、redis 三个服务 1. 使用 systemctl is-active 检测服务状态 2. 服务非 active 时执行 systemctl restart 重启 3. 重启后 sleep 2 秒再次检测确认是否恢复 4. 重启成功记录日志重启失败输出严重告警 5. 所有操作带时间戳写入 ./service_monitor.log 6. 添加 try/except 异常捕获兼容 CentOS 系统 7. 代码注释完整可直接部署。生成的脚本#!/usr/bin/env python3 import os import time MONITOR_SERVICE [nginx, mysqld, redis] LOG_FILE ./service_monitor.log def log_info(msg): current_time time.strftime(%Y-%m-%d %H:%M:%S, time.localtime()) log_msg f[{current_time}] {msg} print(log_msg) with open(LOG_FILE, a, encodingutf-8) as f: f.write(log_msg \n) def check_service_status(service_name): cmd fsystemctl is-active {service_name} result os.popen(cmd).read().strip() return result def restart_service(service_name): log_info(f服务 {service_name} 异常开始重启) os.system(fsystemctl restart {service_name}) time.sleep(2) new_status check_service_status(service_name) if new_status active: log_info(f服务 {service_name} 重启成功) else: log_info(f【严重告警】服务 {service_name} 重启失败请人工排查) def main(): log_info( 启动服务监控任务 ) for service in MONITOR_SERVICE: try: status check_service_status(service) if status ! active: restart_service(service) else: log_info(f服务 {service} 运行正常) except Exception as e: log_info(f监控服务 {service} 异常{str(e)}) if __name__ __main__: main()保存为service_monitor.py直接运行python3 service_monitor.py输出会显示每个服务的状态。如果某个服务当前是 active日志里会写“运行正常”。你可以手动停掉一个测试服务比如systemctl stop redis再跑一次脚本观察它是否自动重启并记录成功日志。这里有个细节os.popen在部分系统上可能返回空字符串导致状态判断异常。更稳妥的写法是用subprocess.runimport subprocess def check_service_status(service_name): result subprocess.run( [systemctl, is-active, service_name], capture_outputTrue, textTrue ) return result.stdout.strip()Codex 生成的第一版可能用os.popen你可以让它优化成subprocess提示词写“把 os.popen 替换为 subprocess.run捕获 stdout 和 stderr”。这样脚本在不同 Linux 发行版上更稳定。配 crontab 每分钟跑一次* * * * * /usr/bin/python3 /path/to/service_monitor.py /var/log/service_monitor_cron.log 21这样服务宕机后最多一分钟内自动重启重启失败会留下告警日志你可以在日志系统里对“严重告警”关键字做二次告警。5. 日志异常筛查Shell 统计与 Codex 辅助分析日志筛查是故障定位的第一步。线上服务日志动辄几百 MB人工grep效率低而且容易漏掉关键字。写一个 Shell 脚本遍历日志目录统计error、timeout、fail、exception的出现次数输出结构化结果。提示词编写 Shell 脚本遍历 /var/log 目录 1. 筛查 error、timeout、fail、exception 四个关键字 2. 统计每个关键字出现的总次数 3. 结果写入 ./log_check_result.log带时间戳 4. 空日志文件不报错grep 错误屏蔽 stderr 5. 输出简洁的统计结果到终端。生成的脚本#!/bin/bash LOG_DIR/var/log KEY_WORDS(error timeout fail exception) RESULT_LOG./log_check_result.log $RESULT_LOG echo 日志异常筛查结果 $(date %Y-%m-%d %H:%M:%S) $RESULT_LOG for key in ${KEY_WORDS[]} do count$(grep -r $key $LOG_DIR 2/dev/null | wc -l) echo 【关键字$key】 出现次数$count $RESULT_LOG done echo 筛查完成结果已保存至 $RESULT_LOG cat $RESULT_LOG运行chmod x log_check.sh ./log_check.sh终端会输出四个关键字的统计次数log_check_result.log里保留完整记录。如果某个关键字次数异常高比如timeout突然从几十涨到几千说明服务可能有超时问题需要进一步定位。但 Shell 统计只能给数字不能告诉你“为什么 timeout 变多了”。这时候可以用 Codex 做二次分析。把日志片段喂给模型让它总结异常模式。用前面配好的 TaoToken 通道写一个 Python 脚本import os import requests def analyze_log(log_snippet): url f{os.environ[TAOTOKEN_BASE_URL]}/v1/chat/completions headers { Authorization: fBearer {os.environ[TAOTOKEN_API_KEY]}, Content-Type: application/json } prompt f分析以下日志片段总结异常类型、可能原因和建议排查方向 {log_snippet} payload { model: gpt-4o, messages: [{role: user, content: prompt}], temperature: 0.2 } resp requests.post(url, jsonpayload, headersheaders, timeout60) resp.raise_for_status() return resp.json()[choices][0][message][content] if __name__ __main__: with open(/var/log/nginx/error.log, r) as f: snippet f.read(3000) print(analyze_log(snippet))这个脚本读取 Nginx 错误日志的前 3000 字符发给模型分析。返回结果会列出异常类型、可能原因和建议排查方向。你可以把log_check.sh统计出的高频关键字对应的日志片段截取出来喂给这个分析函数快速得到排查思路。注意不要把包含敏感信息的完整日志直接发给模型。截取片段时过滤掉 IP、用户 ID、Token 等字段或者在内网环境用本地模型处理。6. 常见报错与排查对照接入和运行过程中最容易遇到几类报错这里对照说明。401 UnauthorizedKey 无效或没带上。检查Authorization头是否写成Bearer sk-xxx注意Bearer后面有一个空格。如果用的是环境变量确认echo $TAOTOKEN_API_KEY有输出且没有换行符。Codex CLI 的auth.json里字段名是api_key不是apiKey写错会导致鉴权失败。local proxy failed / connection refusedBase URL 写错。正确写法是https://taotoken.net/api不要写成https://taotoken.net/api/v1SDK 会自动拼接/v1/chat/completions。如果你在代码里手动拼了/v1最终请求路径会变成/api/v1/v1/chat/completions直接 404。reading choices 报错返回 JSON 里没有choices字段通常是模型 ID 写错或模型不可用。检查控制台模型列表确认你填的 Model ID 在可用范围内。如果返回体里有error字段先打印完整响应再排查。OAuth 相关报错Claude Code 或 Codex CLI 如果走了 OAuth 登录流程可能和 API Key 模式冲突。在settings.json或auth.json里显式指定api_key和base_url不要同时保留 OAuth token。如果之前登录过先清理~/.claude或~/.codex下的缓存文件再重试。脚本执行报错$\r: command not foundWindows 换行符问题。用dos2unix转换或者sed -i s/\r$// script.sh去掉回车符。systemctl is-active返回unknown服务名写错或者服务不存在。先用systemctl list-units --typeservice | grep 服务名确认准确名称。CentOS 上 MySQL 的服务名可能是mysqldUbuntu 上可能是mysql需要按实际环境调整。df -h输出字段错位不同发行版df输出列数可能不同。用df -P强制 POSIX 格式字段位置更稳定。或者改用df -h | awk NR1 {print $5, $6}只取使用率和挂载点。crontab 不执行检查脚本是否有执行权限路径是否写绝对路径环境变量是否在 crontab 里缺失。crontab 的环境变量和登录 shell 不同建议在脚本开头source /etc/profile或显式设置PATH。7. 脚本生成之后怎么持续迭代三个场景的脚本跑通之后你会发现 Codex 生成的代码不是终点而是起点。实际环境里总有边界情况磁盘巡检脚本在容器环境里df输出不同服务监控脚本在 systemd 不可用的系统上要换成supervisorctl日志筛查脚本遇到二进制文件会输出乱码。这些都需要在生成的基础上做适配。我的做法是维护一个ops-scripts目录每个脚本配一个README.md记录生成时的提示词、适配了哪些环境、已知限制、测试命令。下次需要类似脚本时把旧脚本和 README 一起喂给 Codex提示词写“参考这个脚本的风格和容错逻辑生成一个监控 XXX 的脚本”生成结果会更贴近你的实际规范。另外把 TaoToken 的调用封装成命令行工具在终端里直接问codex-ask 写一个检查 SSL 证书剩余天数的 bash 脚本少于 30 天告警这样不用打开编辑器就能快速生成片段复制到脚本里微调即可。封装方式可以用一个简单的 shell 函数codex-ask() { curl -s https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -d {\model\:\gpt-4o\,\messages\:[{\role\:\user\,\content\:\$1\}],\temperature\:0.2} \ | python3 -c import sys,json; print(json.load(sys.stdin)[choices][0][message][content]) }加到~/.bashrc里source之后就能用。生成结果直接打印到终端重定向到文件就是脚本初稿。长期做自动化运维的话可以考虑 Coding Plan 这类按量计费的方式把模型调用成本控制住。具体入口在 https://taotoken.net/coding-plan 适合需要频繁生成和迭代脚本的场景。模型对话调试可以在 https://taotoken.net/chat 里直接试提示词确认输出稳定后再写进脚本。接入文档在 https://taotoken.net/doc 里面有各语言 SDK 的配置示例。