周五发布前，用 Codex CLI 整理老服务器上的备份脚本

备份脚本还在运行，维护的人却不敢修改

周五发布前，团队准备整理一台老服务器上的备份脚本：注释已经过时，目录写死在文件里，遇到失败时只输出一句“完成”。脚本每天由 cron 执行，大家知道它重要，却没人能立即说清每一行的作用。

这类任务适合让 Codex CLI 帮忙，但目标不是“一键重写”。更稳妥的做法是：让它先解释，再提出小范围修改，最后由你检查差异和验证结果。

Codex CLI 是终端里的代码协作工具

CLI 指命令行界面。Codex CLI 可以在终端中接受自然语言任务，读取工作目录里的代码，并根据配置修改文件或调用命令。你可以把它理解为一个能查看项目文件的编程助手，而不是只能聊天的窗口。

它擅长发现重复逻辑、补充错误提示、解释复杂条件，但不了解服务器上的全部约定。例如，一个看似多余的等待动作，可能是在配合另一项定时任务。它提出的修改仍然需要人工确认。

把工作副本放到维护机，而不是直接改生产

老服务器可能缺少运行新版工具所需的环境。不要为了安装 Codex CLI，顺手升级生产机的系统组件。可以在受支持的维护机上，按官方文档安装工具，再获取需要整理的脚本副本。

• 只复制本次任务涉及的文件，不把整个服务器目录交给工具。
• 移除密码、令牌、私钥和真实客户数据；检查日志、配置文件及注释里是否藏有敏感信息。
• 记录目标系统、脚本解释器、相关命令版本，以及 cron 的启动方式。
• 用 Git 保存初始版本，或者保留带时间戳的原文件备份。

在启动前查看当前版本的权限与审批设置，尽量限制可访问目录，并让命令执行经过确认。隔离副本可以减少误操作影响，但不代表可以放心提供秘密信息。

第一条任务只要求阅读和列出风险

进入工作目录后启动 codex，先给它一个明确边界：“请阅读 backup.sh，不修改文件、不执行脚本。说明输入、输出、外部命令和可能删除文件的位置，列出需要向维护者确认的假设。”

接着补充实际约束：“目标脚本由 /bin/sh 执行，需要兼容现有服务器；不得新增依赖，不得改变备份目录、保留天数和退出码。”如果暂时不知道某项行为，就让它标记待确认，不要自行补全。

第二轮再要求：“只修复变量展开缺少引号的问题，并解释每处修改。不要顺便重命名变量或调整整体结构。”范围越小，越容易判断修改是否正确。

老服务器脚本最需要核对的三类细节

• 解释器差异：以 /bin/sh 启动的脚本，不一定支持 Bash 数组或双方括号条件。不要为了代码看起来整齐，引入目标环境不支持的语法。
• 命令差异：date、find、sed 等命令的选项可能因系统和版本不同而变化。维护机上可用，不代表生产机上也可用。
• 运行环境差异：cron 的 PATH、工作目录和交互式终端可能不同。目录权限、文件名包含空格、磁盘已满等情况，也要纳入检查。

不要机械地加入 set -e 等“加固模板”。它们可能改变原有失败处理方式。先说明希望哪些失败导致退出，再逐项设计处理逻辑。

检查差异、静态分析与沙箱验证

每轮修改后先看 git diff，确认改动没有超出任务边界。对于 /bin/sh 脚本，可用 sh -n backup.sh 检查语法；对于明确使用 Bash 的脚本，则使用 bash -n backup.sh。语法通过不等于业务正确。

维护机上还可以运行 ShellCheck，辅助发现引用和条件判断问题。不要只为消除告警而改变行为，更不要把静态分析通过当成上线许可。

需要执行验证时，使用没有生产凭据、不能访问生产路径的隔离环境，准备少量测试文件。覆盖正常备份、源目录不存在、目标目录不可写等情况，并核对退出码和输出。含有删除、同步或远程操作的脚本，必须先确认危险操作已被安全隔离。

模型连接与最终上线各有一道边界

如果团队希望按量使用模型，可以考虑 RelayVano：它支持 Codex 等开发工具，API 基础地址为 https://api.relayvano.com。接入前应核对当前 Codex 版本与服务文档中的认证、接口路径和模型配置，不要把密钥写进脚本或提交到仓库。需要试用时，可以注册账号，从这类小范围整理任务开始。

部署时保留原文件，确认属主、权限和实际调度入口，再在维护窗口替换。首次运行后检查日志、退出状态和备份产物；涉及备份的修改，还应验证恢复流程。Codex CLI 的价值是帮助你读懂并缩小改动，而不是替你承担上线判断。