Codex CLI 真正有价值的地方，不是“能不能生成一段代码”，而是能否在已有仓库规则、未提交改动、权限边界和生产验证之间完成一个可审计闭环。
本文记录一次真实任务：分析网站访问量突增后，为第一方统计加入自动化流量去噪，并部署到生产环境。使用环境为 macOS arm64、Codex CLI 0.154.0、Node.js/Express 项目。任务最终上线，但中间也出现了一次部署路径错误；正是验收步骤把它拦在了“宣告成功”之前。
先看结果
| 环节 | 真实结果 |
|---|---|
| 项目约束 | 读取仓库 AGENTS.md 与站点维护 Skill |
| 代码修改 | 新增明确 UA 与行为阈值过滤，后台展示自动化请求 |
| 静态验证 | node --check、git diff --check 通过 |
| 隔离回放 | 14 次请求拆成 10 次有效 PV、4 次自动化请求 |
| 部署 | 范围化上传三个文件，Docker 重建 |
| 故障拦截 | 哈希发现 server/app.js 上传到了错误目录 |
| 最终验收 | 容器内外哈希一致，核心路由 200，自动化计数生效 |
这组结果只能证明 Codex 在本次任务中完成了“理解—修改—测试—部署—复验”。它不是通用性能排行，也不能替代人工对业务口径的判断。
Codex CLI 是什么
OpenAI 官方仓库将 Codex CLI 定义为运行在本地终端中的开源编程 Agent。它可以读取仓库、提出或应用修改、运行命令，并根据当前沙箱和审批策略请求更高权限。
安装后先记录版本，而不是直接复制旧教程中的参数：
codex --version
codex --help
本文核验到的版本是：
codex-cli 0.154.0
版本号必须进入测试记录。CLI、模型入口、协作方式和权限能力都可能变化，旧截图不能证明当前行为。
为什么先写 AGENTS.md
Agent 不会天然知道团队约束。这个仓库的 AGENTS.md 明确了三类信息：
- 架构：静态前端、Express 后端、Docker 部署以及数据文件位置；
- 安全：密钥不能进入 Git，生产配置不能被部署覆盖；
- 工作方式：保留脏工作区中的用户改动，修改后要验证并记录优化历史。
这些规则把“请优化统计”转换成可执行边界。Codex 因此没有重写历史访问数据，也没有用完整部署脚本上传工作区中其他未提交文件，而是只发布本次涉及的文件。
一个实用的项目规则文件至少应回答：
- 项目如何启动、测试和部署？
- 哪些目录或数据绝不能覆盖？
- 哪些验证是完成条件？
- 工作区不干净时如何处理？
- 哪些外部操作需要审批？
沙箱和审批如何配合
Codex 的本地文件权限与网络、进程权限可以分开控制。本次修改允许写入仓库，但本地监听端口和生产 SSH 需要显式批准。
推荐做法是按风险逐层放开：
- 代码阅读、搜索和 Diff 检查保持只读；
- 修改限制在当前仓库；
- 本地服务使用独立端口、测试 Token 和
/tmp统计文件； - 连接生产、上传文件和重建容器单独审批；
- 删除、覆盖或批量同步前先解析出精确目标。
沙箱不是“阻止工作”，而是让权限提升与具体动作绑定。不要为了减少一次确认，就把整个主目录或生产主机交给无限制命令。
如何设计可回放的 Agent 任务
本次统计规则包含两层：明确自动化 User-Agent，以及十分钟窗口内重复同一路径或批量遍历页面的行为阈值。仅做语法检查无法证明统计口径正确，因此使用了隔离回放：
正常访客：2 次跨页请求
明确自动化：SiteAuditBot 与 Undici 各 1 次
伪装浏览器：同一路径连续请求 10 次
回放结果为 10 次有效 PV、4 次自动化请求。正常访客仍被识别为一位 UV 和一位多页访客；超过第八次的同路径请求才进入自动化计数。
一个适合 Coding Agent 的验证任务应具备：输入可控、成功条件机器可读、数据与生产隔离、失败后可以重跑。只有“页面看起来没问题”通常不够。
一次真实部署失误如何被发现
首次范围化上传把三个文件放到远端项目根目录。admin.js 和 admin.html 本来就在根目录，因此更新成功；但本地的 server/app.js 被 SCP 按 basename 写成了远端 /opt/ai-daily/app.js，真正的 /opt/ai-daily/server/app.js 没有变化。
如果只看 Docker 输出，容器确实“重建成功”，很容易误报部署完成。验收继续比较三层哈希：
本地文件 → 服务器工作目录 → 运行容器
哈希不一致后，误传文件被移动为可恢复备份，随后使用精确目标重新上传：
scp server/app.js root@example:/opt/ai-daily/server/app.js
第二次重建后，服务器与容器中的哈希都和本地一致。再从容器内部发送 SiteAuditBot/1.0 请求，自动化计数由 0 增加到 1，才算完成。
Codex、OpenCode 与 ZCode 怎么选
| 需求 | 优先评估 |
|---|---|
| 已有 ChatGPT/Codex 工作流，希望使用仓库规则、沙箱和审批 | Codex |
| 希望自由切换多家模型或自建 OpenAI-compatible Provider | OpenCode |
| 希望使用围绕 GLM 深度整合的桌面 ADE、浏览器预览与长任务 | ZCode |
| 需要自行组合 Agent Loop、模型适配器与插件 | DeepSeek Harness |
选择工具时先固定同一个仓库、任务、验证命令和权限范围，再比较成功率、人工接管次数、墙钟时间与费用。不同模型和不同任务混在一起的排行榜，很难指导实际采购。
最终建议
使用 Codex CLI 时，把完成条件从“代码改了”提高到“约束被遵守、测试可复现、部署目标精确、线上行为可观测”。
先用 AGENTS.md 写清项目事实和禁区；再让测试数据、端口和密钥与生产隔离；外部操作按具体动作审批；最后用文件哈希、HTTP 状态、业务探针和容器日志交叉验证。Agent 仍然会犯普通工程错误，但一条可靠的验收链能够让错误暴露在报告成功之前。