一、先厘清概念Codex 不是“换个模型聊天”而是一套执行系统开通 ChatGPT Plus/Pro 之后很多人的第一反应是在对话框里找个“Codex”模型试试结果发现它依然在“聊天”。问题就出在理解偏差上Codex 的关键能力不在于“更会回答”而在于它能自己动手干活——读文件、写代码、执行命令、观察输出、根据报错迭代修复直到任务达成。你现在手里其实有两个入口能力重叠但使用姿势完全不同网页 / 移动端对话框里的 Codex 任务适合把“一个完整目标”丢给它比如“分析这个项目为什么构建失败”“给这个仓库加一个重试机制”。本地终端里的 Codex CLI一个开源的编码智能体agent能在你的工作目录里直接读写文件、跑测试、装依赖、提交 git适合真正的工程流。两者的共同点是它交付的是“结果”不是一个贴出来等你自己排版的代码片段。理解这一点后面的用法才不会跑偏。二、网页端 Codex把“任务”而不是“问题”交给它网页端 Codex 最大的误区是把它当普通 ChatGPT 用。普通对话是“我问一句、你答一句”Codex 任务则是“我给你一个目标和一个环境你自己做到验收标准再回来”。一个反例我的项目里 fetch 请求经常超时怎么办这种问法它只会给你一段“建议加 AbortController”的文字。正确姿势是给足上下文 验收标准我已上传 backend.zip这是一个 Node.js 18 的 Express 服务。 问题调用第三方支付接口时偶发网络超时导致整个请求 500。 目标给所有外部 HTTP 调用加一层带指数退避的重试机制。 要求 1. 不要改动接口签名和返回结构 2. 重试 3 次超时时间 10s 3. 改完后用项目里的测试命令验证输出通过结果。上传一个压缩包Codex 会解压、扫描结构、定位相关文件、动手修改然后给你一份“我改了什么、测试结果如何”的交付说明。别传整仓库大文件挑最小可复现的部分打包上下文越干净它跑得越准。三、Codex CLI真正进入日常开发流网页端适合“丢出去、拿回来”但真正高频、可复用的场景还得落到本地终端。Codex CLI 会直接在你的项目目录里工作改完后你自己 review git diff主动权在你手里。安装很简单# Node 环境npminstall-gopenai/codex# 或者 macOS 用 Homebrewbrewinstallcodex安装完先登录走你已开通的 ChatGPT 账号授权codex login然后进入项目目录直接启动交互式会话cd/path/to/your-project codex它会进入一个类似 TUI 的界面你可以像对同事说话一样给它派活。如果只想一次性执行完就退出用exec子命令codexexec梳理 src 目录结构找出所有未处理的 Promise 拒绝并修复最后运行单元测试这里有个关键体验差异交互模式适合“边看边改”exec适合“脚本化、放 CI 里跑”。前者你能实时审批它每一步的操作后者你发布的是“目标 验收”它自己决定路径。四、审批与沙箱让它放开了跑但不至于闯祸一个能在你机器上执行命令的 AI安全性必须当作第一优先级。Codex CLI 默认用沙箱隔离文件系统写入与网络访问但工程里更实用的做法是编辑~/.codex/config.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 里重复解释强得多。一个可直接上手的示例# AGENTS.md ## 技术栈 - Node.js 18 Express 4TypeScript 严格模式 - 测试框架 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。在项目根目录跑codexexecPOST /users 在 email 已存在时返回 500。请改为返回业务错误码 40900message 为 email already exists补充单元测试并运行测试通过。它会自己完成下面的链路定位路由 → 找到 user service → 补唯一性判断 → 改错误处理 → 写测试 → 跑pnpm test→ 汇报结果。你最后看的是类似这样的 diff。它不会给你一段“你应该这么写”的建议而是实际把src/services/user.service.ts从exportasyncfunctioncreateUser(input:CreateUserInput){constusernewUser(input);awaituser.save();returnuser;}改成exportasyncfunctioncreateUser(input:CreateUserInput){constexistsawaitUser.findOne({email:input.email});if(exists){consterrnewAppError(40900,email already exists);throwerr;}constusernewUser(input);awaituser.save();returnuser;}并补上user.service.test.ts里的重复邮箱用例。整个过程它的操作记录会实时输出你随时能喊停。这也是 Codex 和“代码补全”的本质区别补全给的是片段Codex 给的是闭环。七、把 Codex 塞进 CI/CD让 PR 自动过一遍“AI 审查”Codex CLI 可以无头执行这意味着它能进 CI。一个比较实用的场景PR 打开时让 Codex 先跑一遍“回归风险扫描”把低价值的机械审查交给它。name:Codex PR Reviewon:pull_request:types:[opened,synchronize]jobs:codex-review:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4with:fetch-depth:0-name:Run Codex reviewenv: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 字以内的总结不要改任何文件”。它建完心智模型再派修改任务命中率明显更高。第四要求“用测试证明自己”。每次派活都带上“修改后运行测试并贴出通过结果”。这既是对你的保护也是对它幻觉的天然约束——它声称“已修复”测试红了你一眼就能看出来。九、边界与代价什么场景别硬上 CodexCodex 很强但不是万能。几个真实的边界架构决策它替代不了你。它擅长在既定架构里高效实现让它从零设计一套微服务治理模型出来的东西可能“看起来很专业”但未必符合你的组织约束和历史包袱。它对“上下文窗口”有物理上限。巨型代码库不适合整个丢进去。老项目要先用前面说的“先读再改”或者筛选相关目录喂给它。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了。
一、先厘清概念Codex 不是“换个模型聊天”而是一套执行系统开通 ChatGPT Plus/Pro 之后很多人的第一反应是在对话框里找个“Codex”模型试试结果发现它依然在“聊天”。问题就出在理解偏差上Codex 的关键能力不在于“更会回答”而在于它能自己动手干活——读文件、写代码、执行命令、观察输出、根据报错迭代修复直到任务达成。你现在手里其实有两个入口能力重叠但使用姿势完全不同网页 / 移动端对话框里的 Codex 任务适合把“一个完整目标”丢给它比如“分析这个项目为什么构建失败”“给这个仓库加一个重试机制”。本地终端里的 Codex CLI一个开源的编码智能体agent能在你的工作目录里直接读写文件、跑测试、装依赖、提交 git适合真正的工程流。两者的共同点是它交付的是“结果”不是一个贴出来等你自己排版的代码片段。理解这一点后面的用法才不会跑偏。二、网页端 Codex把“任务”而不是“问题”交给它网页端 Codex 最大的误区是把它当普通 ChatGPT 用。普通对话是“我问一句、你答一句”Codex 任务则是“我给你一个目标和一个环境你自己做到验收标准再回来”。一个反例我的项目里 fetch 请求经常超时怎么办这种问法它只会给你一段“建议加 AbortController”的文字。正确姿势是给足上下文 验收标准我已上传 backend.zip这是一个 Node.js 18 的 Express 服务。 问题调用第三方支付接口时偶发网络超时导致整个请求 500。 目标给所有外部 HTTP 调用加一层带指数退避的重试机制。 要求 1. 不要改动接口签名和返回结构 2. 重试 3 次超时时间 10s 3. 改完后用项目里的测试命令验证输出通过结果。上传一个压缩包Codex 会解压、扫描结构、定位相关文件、动手修改然后给你一份“我改了什么、测试结果如何”的交付说明。别传整仓库大文件挑最小可复现的部分打包上下文越干净它跑得越准。三、Codex CLI真正进入日常开发流网页端适合“丢出去、拿回来”但真正高频、可复用的场景还得落到本地终端。Codex CLI 会直接在你的项目目录里工作改完后你自己 review git diff主动权在你手里。安装很简单# Node 环境npminstall-gopenai/codex# 或者 macOS 用 Homebrewbrewinstallcodex安装完先登录走你已开通的 ChatGPT 账号授权codex login然后进入项目目录直接启动交互式会话cd/path/to/your-project codex它会进入一个类似 TUI 的界面你可以像对同事说话一样给它派活。如果只想一次性执行完就退出用exec子命令codexexec梳理 src 目录结构找出所有未处理的 Promise 拒绝并修复最后运行单元测试这里有个关键体验差异交互模式适合“边看边改”exec适合“脚本化、放 CI 里跑”。前者你能实时审批它每一步的操作后者你发布的是“目标 验收”它自己决定路径。四、审批与沙箱让它放开了跑但不至于闯祸一个能在你机器上执行命令的 AI安全性必须当作第一优先级。Codex CLI 默认用沙箱隔离文件系统写入与网络访问但工程里更实用的做法是编辑~/.codex/config.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 里重复解释强得多。一个可直接上手的示例# AGENTS.md ## 技术栈 - Node.js 18 Express 4TypeScript 严格模式 - 测试框架 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。在项目根目录跑codexexecPOST /users 在 email 已存在时返回 500。请改为返回业务错误码 40900message 为 email already exists补充单元测试并运行测试通过。它会自己完成下面的链路定位路由 → 找到 user service → 补唯一性判断 → 改错误处理 → 写测试 → 跑pnpm test→ 汇报结果。你最后看的是类似这样的 diff。它不会给你一段“你应该这么写”的建议而是实际把src/services/user.service.ts从exportasyncfunctioncreateUser(input:CreateUserInput){constusernewUser(input);awaituser.save();returnuser;}改成exportasyncfunctioncreateUser(input:CreateUserInput){constexistsawaitUser.findOne({email:input.email});if(exists){consterrnewAppError(40900,email already exists);throwerr;}constusernewUser(input);awaituser.save();returnuser;}并补上user.service.test.ts里的重复邮箱用例。整个过程它的操作记录会实时输出你随时能喊停。这也是 Codex 和“代码补全”的本质区别补全给的是片段Codex 给的是闭环。七、把 Codex 塞进 CI/CD让 PR 自动过一遍“AI 审查”Codex CLI 可以无头执行这意味着它能进 CI。一个比较实用的场景PR 打开时让 Codex 先跑一遍“回归风险扫描”把低价值的机械审查交给它。name:Codex PR Reviewon:pull_request:types:[opened,synchronize]jobs:codex-review:runs-on:ubuntu-lateststeps:-uses:actions/checkoutv4with:fetch-depth:0-name:Run Codex reviewenv: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 字以内的总结不要改任何文件”。它建完心智模型再派修改任务命中率明显更高。第四要求“用测试证明自己”。每次派活都带上“修改后运行测试并贴出通过结果”。这既是对你的保护也是对它幻觉的天然约束——它声称“已修复”测试红了你一眼就能看出来。九、边界与代价什么场景别硬上 CodexCodex 很强但不是万能。几个真实的边界架构决策它替代不了你。它擅长在既定架构里高效实现让它从零设计一套微服务治理模型出来的东西可能“看起来很专业”但未必符合你的组织约束和历史包袱。它对“上下文窗口”有物理上限。巨型代码库不适合整个丢进去。老项目要先用前面说的“先读再改”或者筛选相关目录喂给它。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了。
