1. 运维脚本这件事为什么值得用AI重做一遍干了七八年运维我对手写脚本这件事的感情很复杂。一方面脚本是运维的命根子批量部署、日志清理、服务健康检查、证书到期提醒哪一样都离不开它另一方面写脚本本身就是个磨人的活。一个看似简单的“找出磁盘占用超过80%的机器并清理七天前的日志”背后要处理SSH连接、异常捕获、并发控制、日志轮转、权限校验写完之后还得在测试环境跑一遍生怕哪台机器上路径不一样直接删错东西。这两年AI编程工具起来了我一开始是抗拒的。理由很朴素运维脚本这东西错一行可能就是生产事故让一个“概率生成”的模型来写心里没底。但真正用下来之后我的看法变了。关键不在于AI能不能一次写对而在于它能不能把那些重复的、模板化的、我每次都要翻文档查语法的部分替我干掉让我把精力放在逻辑校验和风险控制上。Codex这类工具在运维脚本场景里的价值恰恰就在这里。这篇内容我想聊的是怎么用Codex把日常运维脚本的生产效率提上来同时又不把风险带进生产环境。适合谁看如果你是会写一点Shell或者Python、但每次写复杂逻辑都要查半天的运维同学或者你是刚转运维、脚本能力还在爬坡阶段的新人再或者你是团队里负责把AI工具落地到实际工作流的技术负责人这篇都能给你一些能直接抄作业的东西。我不会只讲“AI真好用”我会把提示词怎么写、生成结果怎么验、哪些坑我踩过都摊开讲。先给个结论性的判断Codex写运维脚本最合理的定位是“高级代码补全加逻辑草稿机”不是“自动驾驶”。你给它清晰的输入输出约束它能给你一个80分的骨架剩下20分靠你的经验去补。这个比例用好了就是实打实的效率提升。2. 用Codex写运维脚本的整体思路与方案选型2.1 为什么选Codex而不是直接手写或者纯搜索引擎手写脚本的问题在于“启动成本”高。一个中等复杂度的脚本从打开编辑器到第一版能跑中间要经历查语法、试参数、调缩进、处理边界情况半小时起步。搜索引擎能解决“某个命令怎么写”的问题但解决不了“把五个命令串成一个带错误处理的完整脚本”的问题。Codex的优势在于它是在代码语料上训练出来的对Shell、Python、PowerShell这些运维常用语言的惯用写法非常熟悉。你描述清楚需求它能直接给你一个结构完整的脚本包括参数解析、日志输出、异常捕获这些你本来要手动补的部分。我实测下来一个150行左右的Python运维脚本从描述需求到拿到可运行的第一版大概3到5分钟比手写快至少三倍。但选型上有个关键决策用Codex生成脚本还是用Codex辅助调试已有脚本我的建议是分场景。新脚本、模板化脚本、一次性脚本直接让Codex生成核心生产脚本、涉及数据删除或服务重启的脚本让Codex生成骨架后自己逐行审或者用Codex来review你手写的版本。这个分界线很重要后面会展开讲。2.2 运维脚本的AI生成边界在哪里不是所有运维脚本都适合交给AI生成。我给自己划了几条线适合AI生成的日志清理、磁盘检查、服务状态巡检、证书到期提醒、批量文件分发、配置备份、简单的数据采集和上报。这些脚本逻辑相对线性出错的影响面可控而且有大量公开的相似实现供模型学习。需要谨慎的涉及数据库删改、涉及生产环境服务重启、涉及权限变更、涉及网络配置修改的脚本。这些不是不能生成而是生成之后必须人工逐行确认尤其是那些“看起来对但实际有坑”的地方比如rm命令的路径变量没有做空值保护、kill命令的进程匹配过于宽泛。我的做法是给Codex加一道“安全约束提示”在提示词里明确写“所有删除操作必须先检查变量非空”“所有路径必须使用绝对路径”“所有危险操作必须加确认提示”。这个习惯救过我至少两次后面在实操部分会具体演示。2.3 工具链的搭配Codex不是孤岛Codex单独用也能用但搭配起来效率更高。我的日常组合是这样的Codex负责生成和补全本地终端负责快速验证版本控制负责留痕。具体来说生成的脚本先在一个隔离的测试目录里跑确认逻辑没问题再进正式的脚本仓库。另外提一句Codex的交互方式对生成质量影响很大。同样的需求你用一句话描述和用结构化的方式描述出来的结果差距明显。我习惯用“角色任务约束输出格式”这个框架来写提示词后面会给出具体的模板。这个框架不是玄学它本质上是在帮模型缩小解空间让它别在无关的方向上浪费生成能力。3. 核心细节解析提示词怎么写、脚本怎么验3.1 运维脚本提示词的结构化写法很多人用Codex写脚本提示词就是“帮我写一个清理日志的脚本”。这种提示词出来的结果大概率是一个能跑但不敢用的东西。问题出在信息量太少模型只能按最通用的方式写而通用方式往往不匹配你的实际环境。我的提示词模板长这样角色你是一名有十年经验的Linux运维工程师。 任务写一个Python脚本用于批量检查指定服务器列表的磁盘使用率。 约束 1. 服务器列表从同目录下的servers.txt读取每行一个IP。 2. 使用paramiko库通过SSH连接连接超时设为10秒。 3. 磁盘使用率超过85%时输出WARNING超过95%时输出CRITICAL。 4. 所有输出带时间戳同时写入check_result.log。 5. 单台服务器连接失败不能中断整体流程记录错误后继续。 6. 不要使用shell命令拼接全部用Python原生实现。 输出格式完整可运行的Python脚本带中文注释。这个模板的关键在于“约束”部分。每一条约束都是在排除一种常见的错误写法。比如“连接失败不能中断整体流程”如果不写模型很可能给你一个try-except包住整个循环的版本一台机器连不上后面全不跑了。“不要使用shell命令拼接”是在避免命令注入和转义问题。实测下来带约束的提示词生成结果可用率从大概50%提升到85%以上。剩下的15%主要是环境差异导致的比如你的服务器用了非标准SSH端口这个在提示词里补一句就行。3.2 生成结果的“三遍审查法”Codex生成的脚本我从来不会直接跑在生产上。我的审查流程分三遍第一遍看结构。脚本的整体逻辑对不对有没有漏掉关键步骤异常处理是不是覆盖了主要失败路径。这一遍不抠细节就看骨架。第二遍看危险操作。把所有涉及删除、修改、重启、权限变更的行标出来逐行确认。重点看变量有没有做空值保护路径是不是硬编码通配符会不会匹配到预期之外的文件。我踩过一个坑Codex生成的一个清理脚本用了rm -rf $LOG_DIR/*而$LOG_DIR是从配置文件读的如果配置文件读失败变成空字符串这条命令就变成了rm -rf /*。这个坑让我养成了所有删除操作前必须加[ -z $VAR ] exit 1的习惯。第三遍看边界情况。空输入、超长输入、特殊字符、并发冲突这些模型不一定能全考虑到。我一般会手动构造几个边界用例跑一遍确认脚本不会崩或者产生意外行为。3.3 参数计算与阈值设定的实操逻辑运维脚本里经常涉及阈值和参数比如磁盘使用率超过多少告警、日志保留多少天、并发数设多少。这些数字不是拍脑袋定的背后有计算逻辑。以日志清理为例保留天数怎么定我的算法是先看磁盘总容量和日志日均增长量算出日志占用的安全上限再反推保留天数。假设磁盘500G日志目录分配了50G日均增长2G那么安全保留天数是50 / 2 * 0.8 20天取整留15天作为缓冲。这个计算过程我会写进提示词里让Codex按这个逻辑生成而不是让它随便给个“保留7天”。并发数也是类似。批量SSH检查的场景并发太高会把目标机器打满太低又慢。我的经验值是并发数不超过目标机器数量的1/5且绝对上限32。如果是检查类操作只读可以适当放宽如果是变更类操作并发数要再降一半。这些经验值写进提示词生成出来的脚本才真正可用。4. 实操过程从需求到可运行脚本的完整链路4.1 场景设定批量磁盘巡检脚本我拿一个真实场景来走完整流程。需求是每天定时检查20台服务器的磁盘使用率超过阈值发告警结果写入日志异常情况不能中断整体流程。第一步准备服务器列表文件。这个没什么好说的一行一个IP注意去掉空行和注释行。我习惯在读取的时候加一个过滤[line for line in f if line.strip() and not line.startswith(#)]。这个细节写进提示词Codex就会带上。第二步写提示词。按照前面的模板把角色、任务、约束、输出格式都写清楚。这里补充一个细节如果你的服务器SSH端口不是22或者登录用户不是root一定要在约束里写明。我见过太多生成结果默认用root22结果实际环境根本连不上。第三步生成第一版。Codex大概10秒左右给出一个120行左右的Python脚本。结构是读取服务器列表、定义检查函数、主循环遍历、结果汇总输出。整体骨架没问题。第四步审查和修改。第一遍看结构发现异常处理只包了连接部分没包命令执行部分补上。第二遍看危险操作这个脚本是只读的没有删除操作跳过。第三遍看边界发现服务器列表为空时脚本会静默退出加一个提示。另外把超时时间从默认的30秒改成10秒因为巡检场景不需要等太久。第五步测试。找两台测试机一台正常一台故意关掉SSH跑一遍确认正常机器出结果、异常机器记录错误后继续。确认无误后进脚本仓库。整个流程走下来从写提示词到测试通过大概20分钟。手写的话我估计要一个半小时。4.2 关键代码段的生成与调优Codex生成的脚本里有几个地方我做了针对性调优这些调优经验可以直接复用。连接部分Codex默认用的是paramiko.SSHClient()加set_missing_host_key_policy(AutoAddPolicy())。这个写法在测试环境没问题但生产环境自动接受未知主机密钥有安全风险。我改成了先加载known_hosts找不到就报错。这个改动Codex不会主动做需要你在提示词里明确要求“使用known_hosts校验不自动接受未知主机”。命令执行部分Codex用的是exec_command然后读stdout。这里有个坑如果命令输出很大read()会阻塞。我改成了分块读取并且加了超时控制。这个细节在提示词里写“命令输出可能较大需要分块读取并设置读取超时”Codex就会处理。结果输出部分Codex默认用print。我改成了同时写日志文件和print日志用logging模块带时间戳和级别。这个改动让脚本可以直接接入现有的日志采集系统不用额外适配。4.3 脚本的版本管理与复用策略生成的脚本不要用完就扔。我的做法是建一个内部脚本仓库按功能分类巡检类、清理类、部署类、备份类。每个脚本带一个README写清楚用途、参数、依赖、测试情况。Codex生成的脚本进仓库之前我会做一次“通用化改造”把硬编码的路径、IP、阈值抽成配置文件或命令行参数。这样同一个脚本可以在不同环境复用不用每次重新生成。改造完之后在README里标注“本脚本由AI辅助生成已经过人工审查和测试”既留了痕也提醒后来者不要盲目信任。这个仓库用久了之后我发现一个额外的好处当我要写一个新脚本时可以把仓库里相似的脚本作为上下文喂给Codex让它参考现有风格生成。这样出来的结果和团队现有脚本风格一致维护成本低很多。5. 常见问题与排查技巧实录5.1 生成结果“看起来对但跑不通”的典型原因用Codex写脚本最常见的问题不是它写不出来而是写出来的东西在你环境里跑不通。我整理了几类高频问题问题现象根本原因解决方法连接超时默认端口或用户不对提示词里明确端口和用户命令找不到环境变量未加载脚本里用绝对路径或source profile中文乱码编码未指定提示词要求指定UTF-8编码权限拒绝文件权限或sudo配置提示词说明执行用户和权限要求输出为空命令在非交互环境行为不同加-n等非交互参数或改用API这些问题本质上都是“环境差异”。Codex是在通用语料上训练的它不知道你的服务器装了什么、配置了什么。解决办法就是在提示词里把环境信息补全越具体越好。5.2 危险操作的识别与拦截前面提过删除操作的坑这里展开讲一下我的拦截策略。所有生成的脚本我会用grep扫一遍危险关键词rm、kill、reboot、shutdown、chmod、chown、 /、dd。扫到之后逐行人工确认。确认的时候看三点变量有没有做非空校验路径是不是绝对路径且限定在预期目录内有没有加确认提示或dry-run模式。这三点缺一不可。我现在的习惯是所有涉及变更的脚本都必须支持--dry-run参数先跑一遍看输出确认无误再去掉这个参数正式执行。这个习惯是从一次误删事故之后养成的代价有点大希望你别重复。5.3 Codex使用中的连接与配置问题用Codex的过程中偶尔会遇到连接层面的问题比如提示“正在重新连接”或者“连接失败”。这类问题通常和网络环境、认证状态有关。我的处理顺序是先确认本地网络正常再检查Codex的登录状态是否过期然后看是不是同时开了多个实例导致冲突。如果是本地部署的场景还要注意模型版本和Codex客户端的兼容性。有些模型版本在特定客户端上会报“model is not supported”之类的错误这时候要么升级客户端要么换一个兼容的模型版本。这个排查思路是通用的先排除网络再排除认证最后排除版本兼容。另外如果你在Codex里配置了自定义的模型端点要注意端点的响应格式是否匹配。有些端点返回的JSON结构和Codex预期的对不上就会报解析错误。这种情况看日志里的原始响应内容对比一下预期格式基本就能定位。5.4 提升生成质量的几个实操技巧最后分享几个我实测有效的技巧。第一个给例子。在提示词里附上一段你之前写过的相似脚本让Codex参考风格和结构。这个技巧对保持团队代码风格统一特别有用。第二个分步生成。复杂脚本不要一次性生成先让它生成骨架确认结构没问题再逐个函数让它填充实现。这样每一步都可控出问题容易定位。第三个让它解释。生成之后加一句“请解释这个脚本的执行流程和潜在风险”Codex会给你一段说明。这段说明有时候能帮你发现自己没注意到的逻辑问题。第四个反向验证。把生成的脚本贴回去问“这个脚本在什么情况下会失败”。Codex会列出一些边界情况你可以对照着补测试用例。这几个技巧用下来我对生成结果的信任度明显提升审查时间也缩短了不少。核心逻辑还是那句话AI负责草稿你负责把关。把关的能力才是运维工程师真正的价值所在。