ChatGPT Plus/Pro 解锁 Codex 后这样玩：云端任务、本地 CLI 与 CI/CD 的进阶实战手册

一、先厘清概念：Codex 不是"换个模型聊天"，而是一套执行系统

开通 ChatGPT Plus/Pro 之后，很多人的第一反应是在对话框里找个"Codex"模型试试，结果发现它依然在"聊天"。问题就出在理解偏差上：Codex 的关键能力不在于"更会回答"，而在于它能自己动手干活------读文件、写代码、执行命令、观察输出、根据报错迭代修复，直到任务达成。

你现在手里其实有两个入口，能力重叠但使用姿势完全不同：

网页 / 移动端对话框里的 Codex 任务：适合把"一个完整目标"丢给它，比如"分析这个项目为什么构建失败""给这个仓库加一个重试机制"。
本地终端里的 Codex CLI：一个开源的编码智能体（agent），能在你的工作目录里直接读写文件、跑测试、装依赖、提交 git，适合真正的工程流。

两者的共同点是：它交付的是"结果"，不是一个贴出来等你自己排版的代码片段。理解这一点，后面的用法才不会跑偏。

二、网页端 Codex：把"任务"而不是"问题"交给它

网页端 Codex 最大的误区，是把它当普通 ChatGPT 用。普通对话是"我问一句、你答一句"；Codex 任务则是"我给你一个目标和一个环境，你自己做到验收标准再回来"。

一个反例：

text 复制代码

我的项目里 fetch 请求经常超时，怎么办？

这种问法它只会给你一段"建议加 AbortController"的文字。正确姿势是给足上下文 + 验收标准：

text 复制代码

我已上传 backend.zip，这是一个 Node.js 18 的 Express 服务。
问题：调用第三方支付接口时，偶发网络超时导致整个请求 500。
目标：给所有外部 HTTP 调用加一层带指数退避的重试机制。
要求：
1. 不要改动接口签名和返回结构；
2. 重试 3 次，超时时间 10s；
3. 改完后用项目里的测试命令验证，输出通过结果。

上传一个压缩包，Codex 会解压、扫描结构、定位相关文件、动手修改，然后给你一份"我改了什么、测试结果如何"的交付说明。别传整仓库大文件，挑最小可复现的部分打包，上下文越干净，它跑得越准。

三、Codex CLI：真正进入日常开发流

网页端适合"丢出去、拿回来"，但真正高频、可复用的场景，还得落到本地终端。Codex CLI 会直接在你的项目目录里工作，改完后你自己 review git diff，主动权在你手里。

安装很简单：

bash 复制代码

# Node 环境
npm install -g @openai/codex

# 或者 macOS 用 Homebrew
brew install codex

安装完先登录（走你已开通的 ChatGPT 账号授权）：

bash 复制代码

codex login

然后进入项目目录，直接启动交互式会话：

bash 复制代码

cd /path/to/your-project
codex

它会进入一个类似 TUI 的界面，你可以像对同事说话一样给它派活。如果只想一次性执行完就退出，用 exec 子命令：

bash 复制代码

codex exec "梳理 src 目录结构，找出所有未处理的 Promise 拒绝并修复，最后运行单元测试"

这里有个关键体验差异：交互模式适合"边看边改"，exec 适合"脚本化、放 CI 里跑"。前者你能实时审批它每一步的操作，后者你发布的是"目标 + 验收"，它自己决定路径。

四、审批与沙箱：让它放开了跑，但不至于闯祸

一个能在你机器上执行命令的 AI，安全性必须当作第一优先级。Codex CLI 默认用沙箱隔离文件系统写入与网络访问，但工程里更实用的做法是编辑 ~/.codex/config.toml 控制审批策略。

toml 复制代码

model = "gpt-5.1-codex"

[approval_policy]
# always: 每步都要你点头
# on-failure: 正常操作自动过，失败或异常动作才问你（推荐）
# never: 全自动（只建议在一次性容器里用）
default = "on-failure"

[sandbox_policy]
workspace_write = true
network_access = false

要点：

日常开发用 on-failure：改文件、跑测试这类低风险动作自动放行，装依赖、执行删除、访问外网这类动作弹出来让你确认。
网络默认关：除非任务明确需要下载依赖，别轻易打开，避免它"顺手"把生产接口测一遍。
大改之前一定先 git checkout -b codex/xxx 开分支。Codex 会自己写 git commit，但回滚主权的按钮必须留在你手里。

五、用 AGENTS.md 把"项目规矩"写给它

Codex 和很多编码 agent 一样，会读取项目根目录下的 AGENTS.md 作为"入职手册"。这文件不是写给人的 README，而是写给 AI 的约束说明书。写好它，一次投入、长期复用，比每次在 prompt 里重复解释强得多。

一个可直接上手的示例：

markdown 复制代码

# AGENTS.md

## 技术栈
- Node.js 18 + Express 4，TypeScript 严格模式
- 测试框架 Vitest，禁止引入 Jest
- 包管理器 pnpm，禁止使用 npm/yarn

## 代码规范
- 所有异步函数必须显式处理 Promise rejection
- 对外接口返回结构统一为 { code, data, message }
- 不允许使用 any，类型定义放在 types/ 目录

## 命令
- 运行测试：pnpm test
- 类型检查：pnpm typecheck
- 构建：pnpm build

## 红线
- 不要修改 .env 与 migrations/ 目录
- 不要升级任何依赖的主版本
- 改动数据库相关代码前必须先说明影响范围

有了它，"给我加个接口"这句话就从一个模糊需求变成了受约束的任务。尤其多人协作时，这文件本身就是团队规范的一次沉淀。

六、实战：一个多文件服务从"报错"到"可上线"

假设你有一个 Express + TypeScript 的小服务，POST /users 在邮箱重复时直接抛 500，而不是返回业务错误码。你不想自己翻代码，直接交给 Codex。

在项目根目录跑：

bash 复制代码

codex exec "POST /users 在 email 已存在时返回 500。请改为返回业务错误码 40900，message 为 'email already exists'，补充单元测试，并运行测试通过。"

它会自己完成下面的链路：定位路由 → 找到 user service → 补唯一性判断 → 改错误处理 → 写测试 → 跑 pnpm test → 汇报结果。你最后看的是类似这样的 diff。

它不会给你一段"你应该这么写"的建议，而是实际把 src/services/user.service.ts 从：

typescript 复制代码

export async function createUser(input: CreateUserInput) {
  const user = new User(input);
  await user.save();
  return user;
}

改成：

typescript 复制代码

export async function createUser(input: CreateUserInput) {
  const exists = await User.findOne({ email: input.email });
  if (exists) {
    const err = new AppError(40900, "email already exists");
    throw err;
  }
  const user = new User(input);
  await user.save();
  return user;
}

并补上 user.service.test.ts 里的重复邮箱用例。整个过程它的操作记录会实时输出，你随时能喊停。这也是 Codex 和"代码补全"的本质区别：补全给的是片段，Codex 给的是闭环。

七、把 Codex 塞进 CI/CD：让 PR 自动过一遍"AI 审查"

Codex CLI 可以无头执行，这意味着它能进 CI。一个比较实用的场景：PR 打开时，让 Codex 先跑一遍"回归风险扫描"，把低价值的机械审查交给它。

yaml 复制代码

name: Codex PR Review

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  codex-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Run Codex review
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
        run: |
          npm install -g @openai/codex
          codex exec "对比与 main 分支的差异，找出：1) 可能导致生产回归的改动；2) 缺少测试的高风险逻辑；3) 与现有代码风格不一致的地方。以 markdown 列表输出，不要修改代码。"

注意几点：

CI 里只让它"审"和"报"，不让它"改"。改代码的动作必须回到开发者本地或经过人工确认，别让 AI 直接往主分支推补丁。
用一次性 token 或服务账号，别把个人 Plus 账号的登录态塞进 Runner。
这类审查适合"风格一致性 + 明显风险"的初筛，架构判断、性能瓶颈、安全漏洞的最终结论依然要人来拍板。

八、让 Codex 输出质量再上一个台阶的四个心法

工具再强，prompt 写得像雾，它也只能在雾里转。面向 Codex 这类 agent，四个原则比"话术模板"更有用：

第一，给验收标准，不要给操作步骤。 说"让全部测试变绿"比"帮我改第 42 行"好得多。步骤是你的推测，目标才是它存在的意义。你限定路径，反而把它最好的能力（自己探索）阉割了。

第二，一次只让它做一件事。 "顺便把日志也优化一下"是 agent 任务的毒药。任务边界模糊，它的探索空间就失控，消耗的 token 和你的 review 成本都会飙升。拆分需求，一个 exec 一个目标。

第三，让它先"读"再"改"。 对陌生代码库，先发一条"梳理这个项目的模块结构和数据流，输出 500 字以内的总结，不要改任何文件"。它建完心智模型，再派修改任务，命中率明显更高。

第四，要求"用测试证明自己"。 每次派活都带上"修改后运行测试并贴出通过结果"。这既是对你的保护，也是对它幻觉的天然约束------它声称"已修复"，测试红了你一眼就能看出来。

九、边界与代价：什么场景别硬上 Codex

Codex 很强，但不是万能。几个真实的边界：

架构决策它替代不了你。 它擅长在既定架构里高效实现，让它从零设计一套微服务治理模型，出来的东西可能"看起来很专业"，但未必符合你的组织约束和历史包袱。
它对"上下文窗口"有物理上限。 巨型代码库不适合整个丢进去。老项目要先用前面说的"先读再改"，或者筛选相关目录喂给它。
Token 消耗是真实成本。 Plus/Pro 有额度与速率限制，agent 式任务跑起来比普通对话费得多。高频使用前，先在小任务上熟悉它的消耗节奏，再决定要不要上批量场景。
它会在没把握时"装懂"。 agent 的优势是能自己验证，但这不代表它不会在拿不准时硬着头皮往下编。安全和数据相关的改动，必须逐行 review，必要时让它先给方案、你确认、它再执行。
敏感数据别乱喂。 密钥、生产库结构、用户隐私字段不要直接贴进 prompt；本地 CLI 还能靠沙箱兜底，网页端上传打包文件更要先做脱敏。

十、小结：Plus/Pro 只是门票，工程化用法才是分水岭

开通 Plus/Pro 只是拿到 Codex 的入场券，真正的差异来自你怎么组织"人与 AI 的分工"：

临时需求、一次性的小项目修整，丢网页端 Codex 任务最快；
高频、需要看 diff、需要接 CI 的日常开发，用本地 Codex CLI；
用 AGENTS.md 固化团队规范，用 config.toml 守住安全底线，用"验收标准 + 测试证明"约束它的输出；
大改永远开分支，审查永远留给人。

当你能把它当成一个"会写代码、会跑命令、会自我纠正的初级工程师"来管理时，Plus/Pro 那笔订阅费才开始真正产生复利。剩下的，就是去你的下一个真实项目里，发出第一条 codex exec 了。