先掰正一个最常见的误会。
你所提及的“Codex”, 若并非是在2021年就已退役的那个code - 模型, 毕竟那个确实不存在了, 那么它便是在2025年之后重新启动的Codex, 这是一款AI Agent产品。它能够进入你的项目目录, 可以读取文件, 能够分析逻辑, 能够修改代码, 能够运行命令, 能够查看报错, 随后会以diff的形式将改动交给你进行审查。
一句话区分：
下面按"从零到跑通第一个真实任务"的顺序走一遍。
一、选入口：你是哪种用户，就用哪种打开方式
Codex 目前有四条路，别贪，先定一条：
入口
适合谁
什么时候用
Codex App（桌面应用）
新手 / 不想折腾终端
最为值得推荐的起步这般方式, 是借助可视化去查看文件树, 以及diff, 还有终端, 甚至是内置预览。
VS Code / / 扩展
日常写代码的人
边写边问，上下文就近，卡住时最快
Codex CLI（@/codex）
命令行熟、想接自动化
适合脚本化、服务器环境、CI 辅助
Codex Cloud / Web
项目在 上
后台跑任务、出 PR、远程触发
白提出建议, 先去走Codex App, 走完一圈之后, 再去更换成你觉得舒服的入口。
二、安装 & 登录：5 分钟搞定
路线 A：Codex App（最省心）
前往官方入口进行下载安装, 路径为: /codex 或者进入 Codex 页面 → 针对 /macOS 打开之后 → 利用 账号予以登录（亦是支持 API Key 登录的, 不过账号方式最为顺畅）, 挑选一个项目文件夹（本地仓库 / 普通代码目录均可）, 模式方面首先选择 Local, 切勿一开始就触碰 Cloud 或者 Full。
路线 B：CLI（给命令行用户）
确认你有Node.js, 其版本要大于或等于22（或者按照官方当下最新的要求）, 接着:
npm i -g @openai/codex cd /你的/项目目录 codex初次的时候会引导着去进行登录, 并以“Sign in with 来进行, 直至行进完整便可以了, 对于经常会运用到的命令而言, 需要记住三个。”。
三、黄金法则：第一条指令，绝对不要让它"写东西"
这是 90% 新手翻车的原因：一进去就写——
"帮我重构整个项目"
"做个电商网站"
"把所有 bug 修了"
你根本没机会判断它对不对。
正确起步只有一句：
请先不要修改任何文件。
1）这个项目是做什么的？技术栈是什么？
2）入口文件/启动命令可能在哪？
3）目录分别负责什么？
4）我作为新人应该按什么顺序读？
有不确定就说"不确定"，别编。
它的厉害之处成如下之势: Codex会针对目录结构展开扫描, 接着去读取关键配置文件, 随后为你呈上一张“项目地图”, 这张地图乃是后续所有改动的关键所在, 也就是锚点。
四、第一个称作“真修改”的情况是, 仅仅变动一处内容, 然后查看差异对比, 接着再去判定是不是要予以接受。
这么着吧；且得等你确定它领会项目了, 才去做最小程度的修改。建议起始于最为安全的目标——就像:
只改 .md，新增一段"如何启动项目"的说明小节。
不要改其他文件
不要装新依赖
改完告诉我你动了哪里
如果启动命令不明确，写"不确定"别猜
然后做两件事（比看它的总结重要一百倍）：
git status # 看它碰了哪些文件 git diff # 看它到底写了什么App端呈现得更为直观, 直接去查看, Diff面板, 逐块进行确认之后再。
你所审查的并非是“由AI生成的文字”, 而是“你的项目究竟被改成了怎样的状况”, 并且, 一旦养成这个习惯, Codex便会由危险玩具转变为可控工具。
五、我给 Codex 一份名为“项目员工手册”的东西, 这是强烈建议的行为。
于项目根目录之中, 去新建一个.md, 或者是在.codex/之下与之对应的配置, 将你那规矩写明白:
# AGENTS.md —— 给 Codex 看的约定 ## 项目 - 语言：Python 3.11+ - 包管理：uv（别用 pip） - 测试：pytest（改完跑 pytest -x） ## 不许做的事 - 不许随便新增第三方依赖 - 不许改数据库 schema 不加说明 - 不许删注释/日志只为"好看" ## 流程 - 改之前先读相关文件 - 改完说明改了哪些文件 + 怎么验证 - 不确定就停，问我每次开工之前, 它都会去读这个文件, 这就跟把你的工程底线写进它所具备的系统提示词里面是一样的情况。在团队项目当中, 这一点的价值特别突出, 不管换成谁去使用Codex, 规则都是保持一致的状态。
六、四个场景，把 Codex 用"对味"
① 接手陌生仓库（最高 ROI）
暂不触碰代码, 令其输出, 入口, 接着是核心模块, 随后是请求链路, 还有哪些目录不要随意变动。
② 定位 & 修 bug（最稳的流程）
先将报错贴上, 再把复现步骤列出, 接着去分析产生问题的原因 , 提供最小化的修改方案, 在该方案经过我的确认之后再进行操作 , 然后运行测试 , 最后查看差异情况。
永远把"分析"和"执行"拆开，别让它一笔带过。
③ 小功能 / 批量模式替换
设定范围为固定不变（仅允许更改特定的那些目录）, 接着参照已有的书写方式, 随后完成修改后进行检查, 最后通过对比差异来验收结果。
④ PR 前预检（当第二双眼睛）
让它, 在当前, 去查看边界条件, 对异常处理予以留意, 关注明显性能坑, 检查测试遗漏。
七、安全底线（说三遍也不嫌多）
一个完整小实战：从零到"它帮我跑通一个 脚本"
新增~/demo/, 开启 Codex 应用程序, 选择该文件夹, 读取 Local 第一条消息（只读）:
先暂且不要对文件进行修改, 此处在当前阶段是毫无内容处于空白状态的, 协助我去构建一个名为脚本main.py的文件, 在该里面书写一个函数greet(name), 其返回值设定为"Hello,_{name}_!", 然后再加具有一个开始的入口部分用于打印出相应结果, 不过要先告知我你计划怎样去构建、其里面所包含的内容是什么, 等待我进行确认之后才开始书写。
针对它所给予的计划, 你进行确认, 由它创建文件main.py来验证, 执行git init, 接着执行git add., 随后执行git -m"init"。
全程你都在 → 看 → 确认，而不是放手让它狂飙。
最后一句
Codex 最强的状态不是"它一口气写完一个项目"，而是：
它为你去翻代码, 你为自己来把关, 速度快的那一部分给予它, 判断生死的那一部分归属你。
将“先读不改”这一步, 融入流程之中, 接着是“最小修改”这一步, 再融入流程, 然后是“diff 验收”这一步进行融入流程, 最后是“ .md 固化规则”这一步融入流程, 如此这般, 你的 Codex 便不会沦为另一个吃灰 AI 玩具。
