说实话我一开始对“AI写脚本”这件事有点不屑。之前也试过在聊天框里让AI生成一段Python拿到手基本不能用要么缺依赖、要么参数写死最后还是自己重写。直到这阵子把 Codex 接进自己的运维工作流我才改变看法——AI 写运维脚本这件事终于从“生成一个玩具demo”变成了“能直接扔去跑的真实生产力工具”。这篇文章把我最近用 Codex 实战写运维脚本的完整过程整理了一遍从安装、配置到用真实需求让它生成脚本再到遇到的各种报错和排查方法都会讲到。内容偏实操适合想把 AI 引入日常工作的运维工程师、SRE也适合刚入行、被各种重复脚本折腾到头疼的新人。如果你只是想围观 AI 编程也能从中看到 Agent 类工具到底和普通聊天式 AI 差在哪里。1. 为什么选Codex来写运维脚本1.1 运维脚本的日常痛点运维工作里写脚本的频率远比想象中高。今天要清理日志、明天要备份数据库、后天要给几百台机器批量改配置看起来都是小活儿可一旦环境复杂起来写脚本的时间成本并不低。我自己的感受是运维脚本最大的痛点是“写起来容易真正可用很难”。你面对的不是一个干净环境而是 CentOS 7 和 Ubuntu 22.04 混着来bash 版本不同命令参数不同软件包源不同。同一个stat命令在 Linux 上是stat -c %s到了 macOS 上就变成stat -f %z。一个脚本要兼容这些环境光调试就得花不少时间。另外还有一堆隐性要求脚本要幂等重复执行不能删错东西要加日志输出出问题能定位要支持参数覆盖不能写死路径删除操作前要做路径保护避免变量为空时执行出危险命令。这些经验通常不在网上任何一份教程里都是踩坑踩出来的。以前我写这类脚本流程基本是先在测试环境手动跑一遍命令确认结果再写成脚本然后在不同系统上反复试错。一套流程下来一个不算复杂的日志清理脚本也得两小时。看起来时间不长但运维每天被各种琐事打断两小时完整时间非常难凑。1.2 Codex和普通聊天式AI的差异Codex 是 OpenAI 出的命令行编程智能体可以理解为一个能读写本地文件、执行命令、根据报错自动修复代码的 AI 同事。它和 ChatGPT 那种“你问一句、它答一句”的模式不太一样Codex 更像一个 Agent你给它一个任务它会自己拆解步骤、读文件、写代码、跑命令、看结果然后继续改到完成。打个比方普通 AI 是给你一份菜谱写得好不好看运气Codex 是站在你旁边把菜切好、下锅、尝味道发现咸了还会自己加点水。对你的要求是讲清楚想吃什么、忌口什么剩下的它来动手。这种差异在写脚本时特别明显。我让 Codex 写一个日志清理脚本它不只是给我一段代码而是真的在工作目录里创建脚本文件然后运行bash -n检查语法。如果发现它自己生成的find命令在某些系统上有兼容问题它会主动改正最后把改动点列给我。它让我省下的不是打字时间而是“调试时间”。写代码半小时、调试两小时的痛苦可能很多运维同行都有体会。Codex 把调试环节也接了过去这才是我认为它值得用的核心原因。2. 环境准备与初始化配置2.1 安装Codex的三种方式Codex 官方提供了比较灵活的安装方式。macOS 用户可以直接用 Homebrewbrew install codexLinux 和 Windows 用户如果已经有 Node.js 环境推荐用 npm 全局安装npm install -g openai/codexWindows 上如果不想折腾 Node.js也可以试试官方桌面版不过我个人更推荐 WSL2 里安装。原因很简单运维脚本最终大多跑在 Linux 服务器上你在 WSL2 里调试环境更接近生产脚本里的路径、权限、软链问题都更容易提前暴露。装完先验证一下版本codex --version第一次运行codex会自动做登录授权按提示在浏览器里完成登录就行。登录完成后它会在用户目录下生成配置目录默认是~/.codex/。2.2 初始化配置模型、目录和审批策略Codex 的主配置文件在~/.codex/config.toml。我第一次打开这个文件时并不知道里面的参数该怎么配后来反复试了几轮才搞清楚几个和运维场景密切相关的选项。第一是model字段。我一开始想指定一个更强的新模型就在配置文件里加了model gpt-5.6-sol结果 Codex 启动时直接报错提示这个模型在当前的 Codex 版本里不支持。后来我把这行删掉让它用内置默认模型问题就没了。所以新手建议先用默认模型等熟悉了再折腾配置。第二是approval_policy。这个字段控制 Codex 执行命令前是否需要你确认。默认情况下很多操作都会弹确认用起来比较打断思路。我习惯设置为approval_policy on_request意思是普通读文件、写脚本这类操作直接做遇到删除、安装软件包、改系统配置这类敏感命令时再问我。这个设置对运维场景非常友好既保留了效率又有安全阀门。第三是sandbox相关配置。Codex 支持沙箱模式可以限制它能访问的文件和命令。对运维来说建议在探索阶段使用只读沙箱让它先分析和写代码不要直接执行任何修改命令。2.3 Windows安装“未完成”的排查安装 Codex 时Windows 用户很容易碰到一个让人抓狂的问题npm 安装跑到最后一步进度卡在 99%过一会儿提示未完成。我最初以为是网络问题等了半天重试好几遍都一样。后来排查发现这个“未完成”大多是三类原因导致的一是 Node.js 版本太老。Codex 对 Node 版本有要求如果你本机还是 16 甚至更早的版本安装过程会在最后编译环节卡住。建议先升级到 Node.js 18 LTS 或更高。二是杀毒软件把临时目录里的可执行文件拦了。Windows Defender 或者第三方杀毒经常会把刚生成的codex.exe当可疑文件隔离安装自然就完不成。解决办法是把 npm 全局安装目录加进信任区或者安装时暂时关闭实时防护。三是 PATH 环境变量没有刷新。安装其实已经完成但命令行里找不到codex命令表现为“没装完”。这时候重新开一个终端窗口或者手动把%APPDATA%\npm加进 PATH问题就解决了。如果三种办法都试过还是不行我会建议直接用 WSL2。在 WSL2 里走 Linux 安装流程基本没有这些糟心事。3. 真实场景用Codex写一个日志清理脚本3.1 需求描述与提示词设计讲完基础配置来点真东西。我拿一个很常见的需求举例清理应用日志目录下的旧归档日志。这个需求几乎每个运维都写过但写得好不好差别很大。我准备了一个需求描述原样给 Codex你是资深 SRE请帮我写一个 bash 脚本保存为 clean_old_logs.sh 1. 扫描 /var/log/myapp/ 下的归档日志*.log.*删除 mtime 超过 7 天的文件 2. 删除前打印每个文件的路径和大小删除后打印释放的总字节数 3. 脚本必须幂等重复执行没有任何副作用 4. 必须兼容 CentOS 7 的 bash 4.2 和 Ubuntu 22.04 的 bash 5.x 5. 统一用 log_info 和 log_error 两个函数输出格式为 [时间] [级别] 内容 6. 任何一步出错都要立即退出并且错误信息要包含出错的命令和文件路径 7. 参数支持环境变量覆盖LOG_DIR、RETENTION_DAYS 8. 不要用 find -delete删除操作前必须用 rm -f 并做好路径保护。这份提示词里的细节很多都是我之前踩坑总结出来的。比如“幂等”意味着脚本被定时任务重复执行也不会误删新数据“环境变量覆盖”意味着不用改代码就能用于不同目录最后一条“路径保护”直接关系到会不会删错东西。3.2 Codex生成与迭代的完整过程Codex 拿到这个任务后第一版就给出了一个可运行的脚本。经过我一次交互后它给出的最终版本大概长这样#!/usr/bin/env bash set -euo pipefail LOG_DIR${LOG_DIR:-/var/log/myapp} RETENTION_DAYS${RETENTION_DAYS:-7} log_info() { echo [$(date %Y-%m-%d %H:%M:%S)] [INFO] $* } log_error() { echo [$(date %Y-%m-%d %H:%M:%S)] [ERROR] $* 2 } if [[ ! -d ${LOG_DIR} ]]; then log_error 日志目录不存在: ${LOG_DIR} exit 1 fi case ${LOG_DIR} in /var/log/*) ;; *) log_error LOG_DIR 必须指向 /var/log 下的目录: ${LOG_DIR} ; exit 1 ;; esac mapfile -t target_files ( find ${LOG_DIR} -maxdepth 1 -type f -name *.log.* -mtime ${RETENTION_DAYS} | sort ) if [[ ${#target_files[]} -eq 0 ]]; then log_info 没有超过 ${RETENTION_DAYS} 天的归档日志退出 exit 0 fi total_size0 for f in ${target_files[]}; do size$(stat -c %s ${f}) log_info 准备删除: ${f} (${size} 字节) total_size$((total_size size)) done for f in ${target_files[]}; do rm -f ${f} log_info 已删除: ${f} done log_info 本次共删除 ${#target_files[]} 个归档日志释放 ${total_size} 字节这版脚本已经基本满足我提的需求有set -euo pipefail有日志函数有目录存在性检查有路径保护删除前会打印文件信息整个过程幂等。比较关键的是那个case判断它确保了LOG_DIR必须指向/var/log下的路径从源头避免因为变量被误传成根目录导致的风险。实际使用中我还让 Codex 加了一个--dry-run参数。加完之后可以先空跑一遍只看它会删哪些文件不真正执行删除。在第一次接入生产环境时这个参数非常救命。3.3 代码审查与安全加固清单AI 生成代码不代表可以直接信任。我每次让 Codex 写完脚本都会按一套固定清单做人工审查。这套清单其实是运维的基本功只不过现在审查对象从同事写的代码换成了 AI 写的代码。第一个检查项是rm命令。脚本里只要有rm -rf我就会特别小心。AI 很容易生成rm -rf ${LOG_DIR}/这种写法一旦LOG_DIR为空这条命令会变成清理根目录。所以我会要求 Codex 必须在删除前加路径前缀校验就像上面的case判断。第二个检查项是幂等性。一个清理脚本如果连续跑两次第二次应该安全退出不能把不该删的东西删掉。上面的find -mtime 7天然满足这个条件因为第一次删完后第二次找不到那么多旧文件自然就退出。第三个检查项是输出可读性。运维脚本通常会被定时任务调用输出内容会进日志系统。如果脚本没有统一格式后续排查问题会非常痛苦。所以我要求所有脚本都用log_info和log_error函数输出并且错误信息要输出到标准错误。第四个检查项是兼容性。AI 的训练数据里有大量 Ubuntu 和 macOS 的写法直接生成的结果经常在 CentOS 7 上跑不通。最简单的办法是在提示词里明确写清楚目标系统和 bash 版本让 Codex 从源头规避兼容性问题。整个流程跑下来我最大的感受是AI 生成代码越“像样”越要抱着怀疑态度去审查。它最擅长的是把语法写得漂亮最不擅长的是理解你的生产环境里到底有哪些坑。这些坑只有你才知道。4. 让Codex学会你的运维规范4.1 用AGENTS.md让Codex记住团队规范用得多了以后我发现每次在提示词里重复“请加上 set -euo pipefail”“请加日志函数”非常啰嗦。Codex 有一个机制可以解决这个问题它会自动读取工作目录下的AGENTS.md文件把里面的内容当作项目级约束。这就意味着你可以把所有脚本编写规范写进AGENTS.md之后在同一目录下让 Codex 写任何脚本它都会默认遵守。我目前的归档文件大致长这样# 运维脚本项目约定 - 脚本统一使用 bash文件头必须包含 #!/usr/bin/env bash 和 set -euo pipefail - 所有脚本必须支持 --dry-run 参数可以空跑并打印将要执行的动作 - 删除类操作必须校验目标路径前缀禁止直接使用变量拼接 rm -rf - 日志输出统一格式[时间] [INFO|ERROR] 描述 - 优先使用 mktemp 创建临时文件避免在 /tmp 写死文件名 - 涉及外部命令时先检查命令是否存在例如 command -v jq - 提交前必须通过 bash -n 语法检查和 shellcheck 静态检查有了这份文件后再让 Codex 写新脚本它生成的第一版就已经符合规范而不是生成后再让我逐条纠正。这比每次敲一长串提示词省心得多。建议第一次使用 Codex 时先运行一下codex init它会在当前目录生成一个基础版AGENTS.md。你可以在这个基础上改成自己团队的规范。长期下来这个文件会变成团队运维脚本的“活文档”。4.2 模板、示例和“不得做”清单规范文件还有个妙用把常见脚本的模板直接放进去。比如我有一段初始化脚本的模板每次生成新脚本都希望沿用#!/usr/bin/env bash set -euo pipefail usage() { echo Usage: $0 [--dry-run] [--log-dir DIR] [--retention-days N] exit 0 } while [[ $# -gt 0 ]]; do case $1 in --dry-run) DRY_RUN1; shift ;; --log-dir) LOG_DIR$2; shift 2 ;; --retention-days) RETENTION_DAYS$2; shift 2 ;; -h|--help) usage ;; *) echo 未知参数: $1 2; exit 1 ;; esac done把这段模板写进AGENTS.md后Codex 生成的任何新脚本都会带上参数解析逻辑。即使你忘了在提示词里要求它也会默认使用这套结构。除此之外我会在AGENTS.md里专门写一段“不得做”的清单禁止生成硬编码的密码或密钥禁止在脚本里使用rm -rf拼接未经验证的变量禁止使用curl ... | bash这类不安全的远程执行方式禁止跳过语法检查和静态检查对 AI 来说“不能做什么”往往比“要做什么”更重要。只要约束得够明确Codex 生成的内容会明显更安全。4.3 使用codex exec接入自动化流程Codex 不只能交互式使用它还提供了codex exec这种非交互模式。这种方式非常适合接入自动化流程比如在 CI 里生成脚本或者批量处理重复任务。一个典型用法是codex exec --sandbox read-only \ 按项目规范写一个 nginx access log 切割脚本输出到 scripts/nginx_rotate.sh--sandbox read-only的意思是让 Codex 只能读文件不能修改除指定输出外的内容。这相当于给它戴了一个“只读手套”适合让它在现有项目里分析和生成新代码不会误改已有文件。如果你想让 Codex 在 CI 里自动提交脚本需要把官方 CLI 的认证 token 配置到 CI 的密钥里。这里要特别注意不要把 token 直接写在配置文件里也不要打印到日志中否则会有泄露风险。我目前的使用习惯是交互模式下做比较复杂的脚本开发codex exec模式处理那些“需求非常明确、格式已经有规范”的批量生成任务。后者几乎可以做到无人值守。5. 常见报错与排查实战5.1 切换本地网络通道时Codex连接失败用 Codex 过程中我遇到过一个比较头疼的报错现象是终端里反复出现类似endpoint /responses的连接失败提示之后 Codex 就一直无法响应。我当时配置了多个网络切换工具问题大概率出在本地出口通道切换后Codex 请求还残留了旧的连接状态。我的排查思路是这样的先确认是不是网络整体不通直接在终端里请求一下 Codex 的 API 地址看返回是否正常。如果网络本身没问题再检查终端环境变量里有没有残留的转发配置。很多时候是之前临时设置的环境变量在“捣乱”重启终端或者重新登录一次就恢复了。这类问题的本质是“Codex 本体没问题但本地网络环境不干净”。排查时不要一上来就重装 Codex先清理运行环境大部分情况下都能解决。5.2 报错模型不支持另一个高频报错是配置文件里写了不支持的模型名。我在前文提过我一开始在~/.codex/config.toml里写了model gpt-5.6-sol然后 Codex 启动时直接拒绝工作提示这个模型在当版本中不被支持。遇到这种报错第一步别着急去检查配置文件。把model那一行删掉或者改成 Codex 当前支持的模型名然后重启 Codex。如果还是不行大概率是 Codex 版本太旧执行一次升级npm install -g openai/codexlatest升级完再启动基本上就好了。这里要说一句不要去网上找那些“非官方模型接入教程”很多方法会让 Codex 的认证和稳定性出问题最后浪费的时间远远超过省下的那点成本。5.3 登录失败和“正在重新连接”Codex 用久了难免会遇到登录态过期现象是运行几分钟后一直显示“正在重新连接”或者直接提示登录失效。最常见的原因是认证 token 过期了。排查顺序可以参考codex login status如果显示未登录就重新登录codex logout codex login如果重新登录也不行检查一下系统时间。系统时间偏差过大会导致 TLS 证书校验失败表现就是无法连接。这个坑我踩过两次一次是测试机器时间快了 10 分钟Codex 怎么都连不上后来校对时间后立刻恢复。Windows 上还有一种情况是凭据管理器里存储的认证信息和当前账号不匹配。解决办法是以管理员身份打开 PowerShell执行codex logout后重新登录。5.4 排查速查表我把这段时间遇到的高频问题整理成了一个速查表给遇到类似问题的朋友一个参考现象常见原因排查动作安装到最后提示未完成Node 版本老、杀毒拦截、PATH 未刷新升级 Node 到 18检查杀毒重开终端启动后提示模型不支持配置文件模型名写错、版本过旧删除 config.toml 里 model 字段更新 Codex请求一直失败提示 endpoint /responses本地网络环境有残留连接状态清理环境变量检查 API 连通性重启终端运行中“正在重新连接”登录过期、系统时间不准codex logout codex login检查date删除脚本报错路径不存在脚本目录判断不够健壮在脚本开头加目录存在性检查并打印LOG_DIR这张表会持续更新因为我发现 Codex 每个新版本都可能带出新的坑。作为运维保留一手排查记录比什么都强。6. 我对AI写运维脚本的几点体会6.1 哪些场景适合交给Codex用了这段时间我心里大概有个边界。适合交给 Codex 的脚本类型很明确日志清理、备份轮转、日志切割、批量文件处理、配置批量修改、告警通知脚本、数据导出报表。这些任务的特点是逻辑清晰、输入输出明确、边界条件可以通过提示词描述清楚。不适合交给 Codex 的场景也有。比如一个涉及多套系统状态流转的复杂发布脚本或者需要深度结合公司内部权限体系的操作AI 看不到完整上下文生成的代码往往“看起来对”但缺少业务判断。这种任务我一般自己先搭好框架再让 Codex 填充细节。另外我强烈建议任何由 Codex 生成的脚本第一次执行前一定要用--dry-run空跑一遍。宁可多花一分钟确认也不要省掉这一步直接上生产。6.2 写提示词的几条铁律经过几十次交互我沉淀了几条给 Codex 写提示词的经验第一开头就告诉它角色和背景。不要只说“写个清理脚本”而是说“你是资深 SRE请写一个用于 CentOS 7 的日志清理脚本”。角色设定能让它使用更合适的命令和习惯。第二把“不要做什么”写清楚。比如“不要用 find -delete”“不要直接 rm 变量拼接路径”“不要跳过语法检查”。AI 在约束条件下生成的内容远好于无约束的版本。第三要求它给出输出路径。如果只是让它写脚本它可能会在终端里输出一大段代码你还得手动复制。明确写上“保存为 scripts/clean_old_logs.sh”它会直接创建文件。第四让它先讲计划再动手。对于复杂需求我会追加一句“先列出实现计划和关键命令我确认后再写代码”。这样能避免它在错误思路上越走越远。第五要求最后的自检步骤。让它执行完生成操作后主动跑一遍bash -n和shellcheck把发现的错误当场改掉。6.3 最后一个建议最后分享一个我自己的小习惯。每次让 Codex 写完脚本我不会直接验收而是故意制造一些“刁钻”的测试场景把日志目录指向一个不存在的路径把参数传成带空格的路径把LOG_DIR设置成根目录看看脚本能不能安全报错而不是直接执行危险操作。AI 写代码有一个特点越是在“一切都正常”的环境里它写得越丝滑但真正的生产环境往往充满意外。所以别把 Codex 当权威把它当成一个能力很强但容易想当然的实习生。你给它明确的规范、完善的约束、足够的审查它才能把潜力真正发挥出来。我现在的日常是让 Codex 写第一版我做代码审查然后让它在我的反馈基础上迭代。效率比原来一个人写高了很多省下来的时间正好用来处理那些 AI 暂时替不了我的复杂问题。 
长河君 · 2026/9/20 0:08:01 · 阅读 1.2k Codex实战：从零编写可靠运维脚本的完整指南
说实话我一开始对“AI写脚本”这件事有点不屑。之前也试过在聊天框里让AI生成一段Python拿到手基本不能用要么缺依赖、要么参数写死最后还是自己重写。直到这阵子把 Codex 接进自己的运维工作流我才改变看法——AI 写运维脚本这件事终于从“生成一个玩具demo”变成了“能直接扔去跑的真实生产力工具”。这篇文章把我最近用 Codex 实战写运维脚本的完整过程整理了一遍从安装、配置到用真实需求让它生成脚本再到遇到的各种报错和排查方法都会讲到。内容偏实操适合想把 AI 引入日常工作的运维工程师、SRE也适合刚入行、被各种重复脚本折腾到头疼的新人。如果你只是想围观 AI 编程也能从中看到 Agent 类工具到底和普通聊天式 AI 差在哪里。1. 为什么选Codex来写运维脚本1.1 运维脚本的日常痛点运维工作里写脚本的频率远比想象中高。今天要清理日志、明天要备份数据库、后天要给几百台机器批量改配置看起来都是小活儿可一旦环境复杂起来写脚本的时间成本并不低。我自己的感受是运维脚本最大的痛点是“写起来容易真正可用很难”。你面对的不是一个干净环境而是 CentOS 7 和 Ubuntu 22.04 混着来bash 版本不同命令参数不同软件包源不同。同一个stat命令在 Linux 上是stat -c %s到了 macOS 上就变成stat -f %z。一个脚本要兼容这些环境光调试就得花不少时间。另外还有一堆隐性要求脚本要幂等重复执行不能删错东西要加日志输出出问题能定位要支持参数覆盖不能写死路径删除操作前要做路径保护避免变量为空时执行出危险命令。这些经验通常不在网上任何一份教程里都是踩坑踩出来的。以前我写这类脚本流程基本是先在测试环境手动跑一遍命令确认结果再写成脚本然后在不同系统上反复试错。一套流程下来一个不算复杂的日志清理脚本也得两小时。看起来时间不长但运维每天被各种琐事打断两小时完整时间非常难凑。1.2 Codex和普通聊天式AI的差异Codex 是 OpenAI 出的命令行编程智能体可以理解为一个能读写本地文件、执行命令、根据报错自动修复代码的 AI 同事。它和 ChatGPT 那种“你问一句、它答一句”的模式不太一样Codex 更像一个 Agent你给它一个任务它会自己拆解步骤、读文件、写代码、跑命令、看结果然后继续改到完成。打个比方普通 AI 是给你一份菜谱写得好不好看运气Codex 是站在你旁边把菜切好、下锅、尝味道发现咸了还会自己加点水。对你的要求是讲清楚想吃什么、忌口什么剩下的它来动手。这种差异在写脚本时特别明显。我让 Codex 写一个日志清理脚本它不只是给我一段代码而是真的在工作目录里创建脚本文件然后运行bash -n检查语法。如果发现它自己生成的find命令在某些系统上有兼容问题它会主动改正最后把改动点列给我。它让我省下的不是打字时间而是“调试时间”。写代码半小时、调试两小时的痛苦可能很多运维同行都有体会。Codex 把调试环节也接了过去这才是我认为它值得用的核心原因。2. 环境准备与初始化配置2.1 安装Codex的三种方式Codex 官方提供了比较灵活的安装方式。macOS 用户可以直接用 Homebrewbrew install codexLinux 和 Windows 用户如果已经有 Node.js 环境推荐用 npm 全局安装npm install -g openai/codexWindows 上如果不想折腾 Node.js也可以试试官方桌面版不过我个人更推荐 WSL2 里安装。原因很简单运维脚本最终大多跑在 Linux 服务器上你在 WSL2 里调试环境更接近生产脚本里的路径、权限、软链问题都更容易提前暴露。装完先验证一下版本codex --version第一次运行codex会自动做登录授权按提示在浏览器里完成登录就行。登录完成后它会在用户目录下生成配置目录默认是~/.codex/。2.2 初始化配置模型、目录和审批策略Codex 的主配置文件在~/.codex/config.toml。我第一次打开这个文件时并不知道里面的参数该怎么配后来反复试了几轮才搞清楚几个和运维场景密切相关的选项。第一是model字段。我一开始想指定一个更强的新模型就在配置文件里加了model gpt-5.6-sol结果 Codex 启动时直接报错提示这个模型在当前的 Codex 版本里不支持。后来我把这行删掉让它用内置默认模型问题就没了。所以新手建议先用默认模型等熟悉了再折腾配置。第二是approval_policy。这个字段控制 Codex 执行命令前是否需要你确认。默认情况下很多操作都会弹确认用起来比较打断思路。我习惯设置为approval_policy on_request意思是普通读文件、写脚本这类操作直接做遇到删除、安装软件包、改系统配置这类敏感命令时再问我。这个设置对运维场景非常友好既保留了效率又有安全阀门。第三是sandbox相关配置。Codex 支持沙箱模式可以限制它能访问的文件和命令。对运维来说建议在探索阶段使用只读沙箱让它先分析和写代码不要直接执行任何修改命令。2.3 Windows安装“未完成”的排查安装 Codex 时Windows 用户很容易碰到一个让人抓狂的问题npm 安装跑到最后一步进度卡在 99%过一会儿提示未完成。我最初以为是网络问题等了半天重试好几遍都一样。后来排查发现这个“未完成”大多是三类原因导致的一是 Node.js 版本太老。Codex 对 Node 版本有要求如果你本机还是 16 甚至更早的版本安装过程会在最后编译环节卡住。建议先升级到 Node.js 18 LTS 或更高。二是杀毒软件把临时目录里的可执行文件拦了。Windows Defender 或者第三方杀毒经常会把刚生成的codex.exe当可疑文件隔离安装自然就完不成。解决办法是把 npm 全局安装目录加进信任区或者安装时暂时关闭实时防护。三是 PATH 环境变量没有刷新。安装其实已经完成但命令行里找不到codex命令表现为“没装完”。这时候重新开一个终端窗口或者手动把%APPDATA%\npm加进 PATH问题就解决了。如果三种办法都试过还是不行我会建议直接用 WSL2。在 WSL2 里走 Linux 安装流程基本没有这些糟心事。3. 真实场景用Codex写一个日志清理脚本3.1 需求描述与提示词设计讲完基础配置来点真东西。我拿一个很常见的需求举例清理应用日志目录下的旧归档日志。这个需求几乎每个运维都写过但写得好不好差别很大。我准备了一个需求描述原样给 Codex你是资深 SRE请帮我写一个 bash 脚本保存为 clean_old_logs.sh 1. 扫描 /var/log/myapp/ 下的归档日志*.log.*删除 mtime 超过 7 天的文件 2. 删除前打印每个文件的路径和大小删除后打印释放的总字节数 3. 脚本必须幂等重复执行没有任何副作用 4. 必须兼容 CentOS 7 的 bash 4.2 和 Ubuntu 22.04 的 bash 5.x 5. 统一用 log_info 和 log_error 两个函数输出格式为 [时间] [级别] 内容 6. 任何一步出错都要立即退出并且错误信息要包含出错的命令和文件路径 7. 参数支持环境变量覆盖LOG_DIR、RETENTION_DAYS 8. 不要用 find -delete删除操作前必须用 rm -f 并做好路径保护。这份提示词里的细节很多都是我之前踩坑总结出来的。比如“幂等”意味着脚本被定时任务重复执行也不会误删新数据“环境变量覆盖”意味着不用改代码就能用于不同目录最后一条“路径保护”直接关系到会不会删错东西。3.2 Codex生成与迭代的完整过程Codex 拿到这个任务后第一版就给出了一个可运行的脚本。经过我一次交互后它给出的最终版本大概长这样#!/usr/bin/env bash set -euo pipefail LOG_DIR${LOG_DIR:-/var/log/myapp} RETENTION_DAYS${RETENTION_DAYS:-7} log_info() { echo [$(date %Y-%m-%d %H:%M:%S)] [INFO] $* } log_error() { echo [$(date %Y-%m-%d %H:%M:%S)] [ERROR] $* 2 } if [[ ! -d ${LOG_DIR} ]]; then log_error 日志目录不存在: ${LOG_DIR} exit 1 fi case ${LOG_DIR} in /var/log/*) ;; *) log_error LOG_DIR 必须指向 /var/log 下的目录: ${LOG_DIR} ; exit 1 ;; esac mapfile -t target_files ( find ${LOG_DIR} -maxdepth 1 -type f -name *.log.* -mtime ${RETENTION_DAYS} | sort ) if [[ ${#target_files[]} -eq 0 ]]; then log_info 没有超过 ${RETENTION_DAYS} 天的归档日志退出 exit 0 fi total_size0 for f in ${target_files[]}; do size$(stat -c %s ${f}) log_info 准备删除: ${f} (${size} 字节) total_size$((total_size size)) done for f in ${target_files[]}; do rm -f ${f} log_info 已删除: ${f} done log_info 本次共删除 ${#target_files[]} 个归档日志释放 ${total_size} 字节这版脚本已经基本满足我提的需求有set -euo pipefail有日志函数有目录存在性检查有路径保护删除前会打印文件信息整个过程幂等。比较关键的是那个case判断它确保了LOG_DIR必须指向/var/log下的路径从源头避免因为变量被误传成根目录导致的风险。实际使用中我还让 Codex 加了一个--dry-run参数。加完之后可以先空跑一遍只看它会删哪些文件不真正执行删除。在第一次接入生产环境时这个参数非常救命。3.3 代码审查与安全加固清单AI 生成代码不代表可以直接信任。我每次让 Codex 写完脚本都会按一套固定清单做人工审查。这套清单其实是运维的基本功只不过现在审查对象从同事写的代码换成了 AI 写的代码。第一个检查项是rm命令。脚本里只要有rm -rf我就会特别小心。AI 很容易生成rm -rf ${LOG_DIR}/这种写法一旦LOG_DIR为空这条命令会变成清理根目录。所以我会要求 Codex 必须在删除前加路径前缀校验就像上面的case判断。第二个检查项是幂等性。一个清理脚本如果连续跑两次第二次应该安全退出不能把不该删的东西删掉。上面的find -mtime 7天然满足这个条件因为第一次删完后第二次找不到那么多旧文件自然就退出。第三个检查项是输出可读性。运维脚本通常会被定时任务调用输出内容会进日志系统。如果脚本没有统一格式后续排查问题会非常痛苦。所以我要求所有脚本都用log_info和log_error函数输出并且错误信息要输出到标准错误。第四个检查项是兼容性。AI 的训练数据里有大量 Ubuntu 和 macOS 的写法直接生成的结果经常在 CentOS 7 上跑不通。最简单的办法是在提示词里明确写清楚目标系统和 bash 版本让 Codex 从源头规避兼容性问题。整个流程跑下来我最大的感受是AI 生成代码越“像样”越要抱着怀疑态度去审查。它最擅长的是把语法写得漂亮最不擅长的是理解你的生产环境里到底有哪些坑。这些坑只有你才知道。4. 让Codex学会你的运维规范4.1 用AGENTS.md让Codex记住团队规范用得多了以后我发现每次在提示词里重复“请加上 set -euo pipefail”“请加日志函数”非常啰嗦。Codex 有一个机制可以解决这个问题它会自动读取工作目录下的AGENTS.md文件把里面的内容当作项目级约束。这就意味着你可以把所有脚本编写规范写进AGENTS.md之后在同一目录下让 Codex 写任何脚本它都会默认遵守。我目前的归档文件大致长这样# 运维脚本项目约定 - 脚本统一使用 bash文件头必须包含 #!/usr/bin/env bash 和 set -euo pipefail - 所有脚本必须支持 --dry-run 参数可以空跑并打印将要执行的动作 - 删除类操作必须校验目标路径前缀禁止直接使用变量拼接 rm -rf - 日志输出统一格式[时间] [INFO|ERROR] 描述 - 优先使用 mktemp 创建临时文件避免在 /tmp 写死文件名 - 涉及外部命令时先检查命令是否存在例如 command -v jq - 提交前必须通过 bash -n 语法检查和 shellcheck 静态检查有了这份文件后再让 Codex 写新脚本它生成的第一版就已经符合规范而不是生成后再让我逐条纠正。这比每次敲一长串提示词省心得多。建议第一次使用 Codex 时先运行一下codex init它会在当前目录生成一个基础版AGENTS.md。你可以在这个基础上改成自己团队的规范。长期下来这个文件会变成团队运维脚本的“活文档”。4.2 模板、示例和“不得做”清单规范文件还有个妙用把常见脚本的模板直接放进去。比如我有一段初始化脚本的模板每次生成新脚本都希望沿用#!/usr/bin/env bash set -euo pipefail usage() { echo Usage: $0 [--dry-run] [--log-dir DIR] [--retention-days N] exit 0 } while [[ $# -gt 0 ]]; do case $1 in --dry-run) DRY_RUN1; shift ;; --log-dir) LOG_DIR$2; shift 2 ;; --retention-days) RETENTION_DAYS$2; shift 2 ;; -h|--help) usage ;; *) echo 未知参数: $1 2; exit 1 ;; esac done把这段模板写进AGENTS.md后Codex 生成的任何新脚本都会带上参数解析逻辑。即使你忘了在提示词里要求它也会默认使用这套结构。除此之外我会在AGENTS.md里专门写一段“不得做”的清单禁止生成硬编码的密码或密钥禁止在脚本里使用rm -rf拼接未经验证的变量禁止使用curl ... | bash这类不安全的远程执行方式禁止跳过语法检查和静态检查对 AI 来说“不能做什么”往往比“要做什么”更重要。只要约束得够明确Codex 生成的内容会明显更安全。4.3 使用codex exec接入自动化流程Codex 不只能交互式使用它还提供了codex exec这种非交互模式。这种方式非常适合接入自动化流程比如在 CI 里生成脚本或者批量处理重复任务。一个典型用法是codex exec --sandbox read-only \ 按项目规范写一个 nginx access log 切割脚本输出到 scripts/nginx_rotate.sh--sandbox read-only的意思是让 Codex 只能读文件不能修改除指定输出外的内容。这相当于给它戴了一个“只读手套”适合让它在现有项目里分析和生成新代码不会误改已有文件。如果你想让 Codex 在 CI 里自动提交脚本需要把官方 CLI 的认证 token 配置到 CI 的密钥里。这里要特别注意不要把 token 直接写在配置文件里也不要打印到日志中否则会有泄露风险。我目前的使用习惯是交互模式下做比较复杂的脚本开发codex exec模式处理那些“需求非常明确、格式已经有规范”的批量生成任务。后者几乎可以做到无人值守。5. 常见报错与排查实战5.1 切换本地网络通道时Codex连接失败用 Codex 过程中我遇到过一个比较头疼的报错现象是终端里反复出现类似endpoint /responses的连接失败提示之后 Codex 就一直无法响应。我当时配置了多个网络切换工具问题大概率出在本地出口通道切换后Codex 请求还残留了旧的连接状态。我的排查思路是这样的先确认是不是网络整体不通直接在终端里请求一下 Codex 的 API 地址看返回是否正常。如果网络本身没问题再检查终端环境变量里有没有残留的转发配置。很多时候是之前临时设置的环境变量在“捣乱”重启终端或者重新登录一次就恢复了。这类问题的本质是“Codex 本体没问题但本地网络环境不干净”。排查时不要一上来就重装 Codex先清理运行环境大部分情况下都能解决。5.2 报错模型不支持另一个高频报错是配置文件里写了不支持的模型名。我在前文提过我一开始在~/.codex/config.toml里写了model gpt-5.6-sol然后 Codex 启动时直接拒绝工作提示这个模型在当版本中不被支持。遇到这种报错第一步别着急去检查配置文件。把model那一行删掉或者改成 Codex 当前支持的模型名然后重启 Codex。如果还是不行大概率是 Codex 版本太旧执行一次升级npm install -g openai/codexlatest升级完再启动基本上就好了。这里要说一句不要去网上找那些“非官方模型接入教程”很多方法会让 Codex 的认证和稳定性出问题最后浪费的时间远远超过省下的那点成本。5.3 登录失败和“正在重新连接”Codex 用久了难免会遇到登录态过期现象是运行几分钟后一直显示“正在重新连接”或者直接提示登录失效。最常见的原因是认证 token 过期了。排查顺序可以参考codex login status如果显示未登录就重新登录codex logout codex login如果重新登录也不行检查一下系统时间。系统时间偏差过大会导致 TLS 证书校验失败表现就是无法连接。这个坑我踩过两次一次是测试机器时间快了 10 分钟Codex 怎么都连不上后来校对时间后立刻恢复。Windows 上还有一种情况是凭据管理器里存储的认证信息和当前账号不匹配。解决办法是以管理员身份打开 PowerShell执行codex logout后重新登录。5.4 排查速查表我把这段时间遇到的高频问题整理成了一个速查表给遇到类似问题的朋友一个参考现象常见原因排查动作安装到最后提示未完成Node 版本老、杀毒拦截、PATH 未刷新升级 Node 到 18检查杀毒重开终端启动后提示模型不支持配置文件模型名写错、版本过旧删除 config.toml 里 model 字段更新 Codex请求一直失败提示 endpoint /responses本地网络环境有残留连接状态清理环境变量检查 API 连通性重启终端运行中“正在重新连接”登录过期、系统时间不准codex logout codex login检查date删除脚本报错路径不存在脚本目录判断不够健壮在脚本开头加目录存在性检查并打印LOG_DIR这张表会持续更新因为我发现 Codex 每个新版本都可能带出新的坑。作为运维保留一手排查记录比什么都强。6. 我对AI写运维脚本的几点体会6.1 哪些场景适合交给Codex用了这段时间我心里大概有个边界。适合交给 Codex 的脚本类型很明确日志清理、备份轮转、日志切割、批量文件处理、配置批量修改、告警通知脚本、数据导出报表。这些任务的特点是逻辑清晰、输入输出明确、边界条件可以通过提示词描述清楚。不适合交给 Codex 的场景也有。比如一个涉及多套系统状态流转的复杂发布脚本或者需要深度结合公司内部权限体系的操作AI 看不到完整上下文生成的代码往往“看起来对”但缺少业务判断。这种任务我一般自己先搭好框架再让 Codex 填充细节。另外我强烈建议任何由 Codex 生成的脚本第一次执行前一定要用--dry-run空跑一遍。宁可多花一分钟确认也不要省掉这一步直接上生产。6.2 写提示词的几条铁律经过几十次交互我沉淀了几条给 Codex 写提示词的经验第一开头就告诉它角色和背景。不要只说“写个清理脚本”而是说“你是资深 SRE请写一个用于 CentOS 7 的日志清理脚本”。角色设定能让它使用更合适的命令和习惯。第二把“不要做什么”写清楚。比如“不要用 find -delete”“不要直接 rm 变量拼接路径”“不要跳过语法检查”。AI 在约束条件下生成的内容远好于无约束的版本。第三要求它给出输出路径。如果只是让它写脚本它可能会在终端里输出一大段代码你还得手动复制。明确写上“保存为 scripts/clean_old_logs.sh”它会直接创建文件。第四让它先讲计划再动手。对于复杂需求我会追加一句“先列出实现计划和关键命令我确认后再写代码”。这样能避免它在错误思路上越走越远。第五要求最后的自检步骤。让它执行完生成操作后主动跑一遍bash -n和shellcheck把发现的错误当场改掉。6.3 最后一个建议最后分享一个我自己的小习惯。每次让 Codex 写完脚本我不会直接验收而是故意制造一些“刁钻”的测试场景把日志目录指向一个不存在的路径把参数传成带空格的路径把LOG_DIR设置成根目录看看脚本能不能安全报错而不是直接执行危险操作。AI 写代码有一个特点越是在“一切都正常”的环境里它写得越丝滑但真正的生产环境往往充满意外。所以别把 Codex 当权威把它当成一个能力很强但容易想当然的实习生。你给它明确的规范、完善的约束、足够的审查它才能把潜力真正发挥出来。我现在的日常是让 Codex 写第一版我做代码审查然后让它在我的反馈基础上迭代。效率比原来一个人写高了很多省下来的时间正好用来处理那些 AI 暂时替不了我的复杂问题。