Codex 怎么用：从启动到完成第一个可验收任务

Codex 能打开，不等于任务就会自动做对。第一次使用时，最容易出问题的通常不是“提示词写得不够高级”，而是目录进错、任务范围太大、改完没有验证。

更稳的方式是先跑一个很小的闭环：

进入正确目录 → 说清目标和边界 → 看权限 → 检查改动 → 做最小验证 → 决定保留还是撤回。

第一步：先进入真正要处理的项目

在终端里进入项目目录：

cd /你的/项目路径pwdgit status

pwd 用来确认当前位置，git status 用来确认仓库状态和已有改动。

不要在桌面、下载目录或装着多个项目的父目录里随手启动 Codex。Codex 会围绕当前工作目录理解项目，目录选错，后面的读取和修改范围也容易跟着跑偏。

如果还没安装，先看《Codex 安装教程：macOS、Windows 与 Linux 分步说明》。

第二步：第一条任务越小越好

第一次不要直接说：

帮我优化整个项目。

可以换成下面这种写法：

目标：检查 README 里的启动命令是否和 package.json 一致。范围：只读取 README.md 和 package.json。约束：不要修改依赖，不要运行安装命令。输出：先告诉我发现了什么，再决定是否修改。验证：修改后展示 diff，不执行发布。

这类提示的重点不是“专业”，而是边界清楚。

官方 Codex CLI 的起步思路也是先做明确任务，例如解释项目、完成一个聚焦修改或协助排错。

第三步：看懂几个常用入口

当前 Codex CLI 会提供 /permissions、/model、/review、/status 等入口。不同版本的显示可能调整，以本机启动页和 codex --help 为准。

/permissions：查看或调整本次运行允许 Codex 做什么。
/model：选择当前可用模型和推理强度。
/review：审查改动，不等于已经跑过测试。
/status：查看当前会话配置和状态。

如果 Codex 请求执行一条你看不懂的命令，先问两个问题：

它会改什么？
失败以后怎么恢复？

第四步：不要把“任务完成”当成“结果正确”

1. 先看 diff

如果项目用了 Git：

git diff

只改了某个文件，也可以缩小范围：

git diff -- README.md

2. 再做最小验证

代码修改优先运行项目本来就有的测试、类型检查或 lint。

不要为了证明一个小改动“没问题”，临时编一套项目里根本不存在的测试命令。

3. 最后决定保留还是撤回

结果符合预期，再提交 Git 检查点。

需要撤回时，只撤回这次修改。不要一上来就做可能覆盖整个工作区的重置操作。

三个常见卡点

Codex 读不到文件

先检查当前目录、文件是否真的存在、项目是否受信任以及当前权限。

不要第一反应就开放整个磁盘访问。

一次改太多

停止当前方向，把任务改成：

先计划，只读，列出拟修改文件，不要直接改。

确认以后再分步执行。

登录或模型调用失败

先运行：

codex login status

确认当前认证方式，再继续排查。

API Key、Base URL、Provider 和模型属于另一层问题，见《Codex API Key 怎么配置》。

什么时候才需要考虑 AI Code With

如果你的本地 Codex 工作流已经跑通，下一步准备使用 API Key、自定义 Provider，或者希望统一管理多个模型和用量，这时再看 AI Code With 会更自然。

AI Code With 目前有单独的 Codex 配置文档和 API Key 管理流程。它不是 Codex 的必需组件，而是 API / Provider 路线下的一个可选方案。

这条路径比在入门文章开头直接推荐产品更顺：

先学会 Codex → 再处理 API 配置 → 再决定是否接 AI Code With。

资料来源

OpenAI Codex CLI：https://developers.openai.com/codex/cli
OpenAI Authentication：https://developers.openai.com/codex/auth
AI Code With Codex 文档：https://docs.aicodewith.com/zh/docs/codex-cli