</> codex
为程序员准备的 Codex 使用页

codex
变成你的第二个工程师

它不是一个聊天窗口,而是一套面向开发者的协作方式。你可以在终端、IDE、桌面应用和云端任务里,让 Codex 读仓库、改文件、跑命令、补测试、做 review。关键不是“会不会问”,而是“会不会把工程任务讲清楚”。

Terminal First IDE 可协作 支持云端委托 适合真实仓库

它适合什么

最有价值的不是写一个函数,而是替你吃掉那些重复、耗时、需要上下文切换的工程工作。

Understand

理解旧项目

让它先画出目录、模块依赖、启动入口、风险点,再决定要不要动手改。

Fix

修 Bug

直接交给它定位异常链路、修改受影响文件,并补最小回归测试。

Review

做代码审查

让它从回归风险、边界条件、测试缺口和行为变化四个角度看代码。

Ship

推进交付

把一个需求拆成多步执行,边改边验证,最后输出可读的改动摘要。

5 分钟快速上手

如果你只想马上开始,本页最重要的就是这四步。先跑通,再慢慢提升协作质量。

01

安装 CLI

Codex CLI 是最直接的入口,适合在项目根目录里协作。

install
npm install -g @openai/codex
02

登录账号

推荐直接用 ChatGPT 账号登录,免手动拷贝 API Key。切换账号时可先退出。

auth
codex --login
codex logout
03

在仓库根目录启动

第一次不要上来就改代码。先让它讲清楚项目结构、运行方式和关键风险。

start
codex
04

按任务切协作模式

读代码用 Suggest,批量改文件用 Auto Edit,长任务才考虑 Full Auto。

modes
codex --auto-edit
codex --full-auto
/mode

三种协作模式

不要把所有任务都交给全自动。模式选得对,质量和安全性会高很多。

S

Suggest

默认模式。它可以读文件、提出修改和命令建议,但需要你确认后才执行。

  • 适合读仓库、做 review、梳理方案
  • 适合第一次接触陌生项目
  • 风险最低,推荐先从这里开始
A

Auto Edit

它可以自动写文件,但执行命令前仍会征求你同意,适合中等规模改动。

  • 适合重构、批量替换、补注释
  • 适合你已经明确文件范围的任务
  • 建议同时给出验收标准
F

Full Auto

它会在受限沙箱里自动读写并运行命令,适合长链路任务,但前提是边界要清楚。

  • 适合修构建、跑测试、生成初版实现
  • 最好在 Git 仓库里使用
  • 大任务先拆解,再放权
IDE

不只 CLI

除了终端,你还可以在 IDE、桌面应用或云端任务里使用同一套协作方式。

  • IDE 适合边读边改
  • 桌面应用适合多项目并行
  • 云端任务适合后台长时间执行

把任务说清楚

真正影响结果的不是模型名字,而是约束条件。文件范围、目标行为、验证方式,三样缺一不可。

读项目模板

prompt-1
先不要改代码。阅读这个仓库后,告诉我:
1)启动方式;
2)关键目录;
3)核心数据流;
4)最值得优先关注的风险点。

改功能模板

prompt-2
实现“批量导出”功能,只改 export 模块及直接相关测试。
保持现有接口不变,完成后运行测试并说明改动点。

修 Bug 模板

prompt-3
定位登录接口 500 的根因。
先复现,再修复,再补一个回归测试。
不要顺手重构无关代码。

做 Review 模板

prompt-4
以代码审查的方式检查这次改动,重点看:
行为回归、空指针/边界条件、并发风险、测试缺口。
先列问题,再给建议。

典型工作流

程序员最省时间的用法,不是让它“从零写完整系统”,而是把你正在做的真实工作交给它分担。

Workflow A

接手陌生仓库

  • 先用 Suggest 模式让它做代码导览
  • 要求它标出启动入口、配置文件、核心模块
  • 让它列出“最可能踩坑”的地方
  • 确认理解一致后再进入改动阶段
Workflow B

实现一个小功能

  • 明确边界:只改哪些目录,哪些接口不能动
  • 把验收标准写清楚,例如按钮行为、返回值、测试结果
  • 先让它给方案,再切到 Auto Edit 实施
  • 最后让它输出变更摘要,便于提交 PR
Workflow C

调试线上问题

  • 先要求它复现,不要直接猜测原因
  • 让它输出异常链路、日志位置、最小修复点
  • 要求补回归测试,避免再次出现
  • 控制范围,禁止顺手改无关模块
Workflow D

并行推进任务

  • 本地 CLI 负责即时协作和验证
  • 桌面应用或云端任务负责长时间后台执行
  • GitHub review 用来做额外质量把关
  • 把重复流程沉淀成技能或固定提示词

避免踩坑

这些规则看起来朴素,但决定了你是得到一个靠谱搭档,还是得到一台失控的代码生成器。

先约束,再放权

给出文件范围、非目标项和验收标准。没有边界的“帮我优化一下”,通常只会制造额外 diff。

让它先解释,再修改

对于陌生仓库,第一轮永远先做分析。你要先确认它理解的是不是同一个系统。

验证不要省

要求它跑测试、复现问题、解释结果。能自动验证的任务,优先使用可验证的提示词。

Windows 用户注意

Codex CLI 官方对 Windows 的支持仍偏实验性质,复杂项目通常更适合在 WSL 或类 Unix 环境中使用。