Codex 如何使用？从安装、登录到让它真正帮你写代码

Codex 如何使用？从安装、登录到让它真正帮你写代码

作者：GPTPro Team 最新更新时间：2026-06-17

站长实测总结：Codex 不是“会聊天的 IDE”，它更像一个能进仓库干活的代码助理

我们测试 Codex 这类 coding agent 时，最明显的感受是：你不能像问聊天机器人一样随口一句“帮我优化一下项目”就完事。 这样大概率会得到一堆看似努力、实际不可控的改动。

更稳的用法是：

• 让 Codex 在一个明确的 Git 仓库里工作。
• 一次只给一个可验证任务。
• 提前说明改哪些文件、不要改哪些文件。
• 让它跑测试、给 diff、解释风险。
• 合并前自己 review，不要无脑接受。

一句话结论：Codex 好用，但前提是你把它当“会执行任务的开发代理”，不是当搜索框。

如果你还没稳定开通 ChatGPT Plus / Pro，或者国内支付一直失败，可以先看 国内没有国外信用卡怎么订阅 ChatGPT。Codex 的可用权益和账号套餐有关，具体以 OpenAI 当前页面和你账号内显示为准。

Codex 是什么？先别把它和普通 ChatGPT 混在一起

Codex 是 OpenAI 面向代码任务的工具形态。按公开说明，它可以作为本地 CLI 使用，也可以通过 Codex Web、Codex App 或 IDE 插件进入开发工作流。

你可以把它理解成三种入口：

• Codex CLI：在本地终端里运行，适合开发者直接在仓库中让它改代码、跑命令、生成补丁。
• Codex IDE：接入 VS Code、Cursor、Windsurf 等编辑器，适合边写边改。
• Codex Web / App：更像云端或桌面入口，适合把任务交给 agent 处理。

本文重点讲 Codex CLI 怎么用。因为对开发者来说，CLI 最容易和真实项目、Git、测试、CI 串起来。

Codex 适合做什么，不适合做什么

先把边界讲清楚，不然后面很容易误用。

适合 Codex 的任务

• 修小 bug。
• 写单元测试。
• 补 README 和使用文档。
• 做小范围重构。
• 根据 issue 复现和定位问题。
• 给 PR 做初步 code review。
• 生成脚本、配置模板、demo 项目。

不适合直接甩给 Codex 的任务

• “帮我重构整个项目”这种范围失控的大任务。
• 没有测试、没有验收标准的需求。
• 涉及线上数据库、支付、权限、密钥的高风险改动。
• 你自己都没想清楚产品逻辑的功能。
• 需要大量业务判断、法律合规判断、商业策略判断的任务。

很多人用不好 Codex，不是模型不行，是任务给得太糊。

Codex 安装方法

根据 OpenAI Codex CLI 公开说明，Mac 和 Linux 可以用安装脚本：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

Windows 可以用 PowerShell：

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

也可以用 npm：

npm install -g @openai/codex

或者用 Homebrew：

brew install --cask codex

安装后运行：

codex

如果命令不存在，先检查：

which codex
codex --version

Windows 用户重点检查 PATH，Mac/Linux 用户重点检查 shell 配置是否加载了安装目录。

Codex 登录：ChatGPT 账号还是 API Key？

公开说明里，Codex CLI 支持运行 codex 后选择 Sign in with ChatGPT。OpenAI 也建议用 ChatGPT 账号登录，把 Codex 作为 Plus、Pro、Business、Edu 或 Enterprise 等计划的一部分使用。

另外也可以用 API Key，但需要额外配置，费用和使用方式会更偏开发者 API 路线。

怎么选？

• 你是普通开发者、学生、独立开发者：优先用 ChatGPT 登录。
• 你已经有 OpenAI API 账单体系：可以研究 API Key 方式。
• 你在公司或团队环境：先问清楚账号、权限、审计和费用归属。

如果你还在纠结 Plus、Pro、Pro 20X 怎么选，可以看这篇：ChatGPT Plus、Pro 与 Pro 20x 区别。不要为了 Codex 盲目上高档，先看你的代码工作强度。

Codex CLI 的基本用法

Codex 最基础的入口就是：

codex

进入交互模式后，你可以在当前项目目录里描述任务，比如：

阅读这个项目，找出测试如何运行，并总结主要目录结构。

更适合实际开发的是一次性执行任务：

codex exec "阅读项目结构，告诉我如何启动开发环境，不要修改文件"

让它改代码时，任务要更具体：

codex exec "修复登录页在移动端按钮溢出的问题。只修改 src/pages/login 和相关样式文件。完成后运行现有前端测试。"

如果你的项目没有 Git 仓库，先初始化：

git init

Codex 这类工具最好在 Git 仓库里使用。原因很简单：你需要 diff，需要回滚，需要知道它到底动了什么。

一个更稳的 Codex 使用流程

别一上来就让 Codex 写大功能。稳一点，按这个流程走：

1. 让 Codex 先读项目，不改文件。
2. 让它复述任务和计划。
3. 只允许它修改限定范围内的文件。
4. 让它运行测试或构建命令。
5. 查看 git diff。
6. 自己 review 后再提交。

可以这样写 prompt：

你在一个已有项目里工作。先阅读 README、package.json 和 src 目录，找出项目启动和测试命令。
任务：修复用户设置页保存按钮点击后没有 loading 状态的问题。
限制：不要修改接口协议，不要改数据库，不要新增大型依赖。
完成后：运行相关测试，给出改动摘要、风险点和未覆盖的情况。

这类 prompt 看着啰嗦，但能少很多坑。

Codex 常用场景示例

场景一：让 Codex 写测试

codex exec "为 src/lib/price.ts 补充单元测试，覆盖正常价格、空值、非法输入和边界值。不要改业务代码，除非测试暴露明显 bug。"

这个场景很适合 Codex。因为测试目标明确，文件范围也清楚。

场景二：让 Codex 修 bug

codex exec "复现 issue #42：支付状态刷新后仍显示 pending。先定位原因，再给最小修复。完成后运行相关测试。"

注意关键词：复现、定位、最小修复、相关测试。

场景三：让 Codex 做文档

codex exec "根据当前项目实际脚本更新 README 的本地开发、测试和构建部分。不要编造不存在的命令。"

写文档时一定要加“不要编造不存在的命令”。这句话很值钱。

场景四：让 Codex 做 PR Review

你可以让 Codex 看 diff：

codex exec "review 当前 git diff，重点检查安全风险、边界条件、测试缺口和可能的破坏性改动。不要修改文件，只输出 review。"

这比让它直接改代码更安全，适合合并前多一层检查。

Codex prompt 怎么写才不容易翻车

一个能用的 Codex prompt，最好包含五件事：

• 背景：这是个什么项目或模块。
• 目标：这次具体要解决什么。
• 范围：允许改哪里，不允许改哪里。
• 验收：跑什么测试，什么结果算完成。
• 输出：改动摘要、风险、后续建议。

糟糕写法：

帮我优化一下这个项目。

靠谱写法：

优化 src/components/CheckoutForm.tsx 的表单校验体验。不要改支付接口，不要改后端。
要求：
1. 邮箱为空时提示更明确。
2. 卡片错误不要清空用户已输入字段。
3. 提交中禁用按钮并显示 loading。
4. 补充或更新相关测试。
完成后运行 npm test，并总结改动风险。

同样是“优化”，后者才像一个能交付的任务。

使用 Codex 最容易踩的坑

坑一：不给边界

你不限制文件范围，它就可能为了完成任务顺手改很多地方。看起来主动，实际很危险。

坑二：不看 diff

Codex 改完不代表能合并。一定要看：

git diff

必要时看具体文件历史：

git status
git log --oneline -5

坑三：没测试就信结果

如果项目没有测试，至少让它给出手动验证步骤。别看到“已完成”就直接上线。

坑四：把密钥和生产权限暴露给它

不要把生产 API Key、数据库凭据、支付后台权限随手放进上下文。开发代理不是保险箱。

坑五：一次塞太多需求

一个任务没验收完，又塞第二个第三个，最后 diff 会变成一锅粥。宁愿拆小任务，也别追求“一句话全自动”。

Codex 和 ChatGPT 写代码有什么区别？

ChatGPT 更像你旁边的技术顾问，适合解释、设计、排错、生成片段。

Codex 更像能进入仓库的执行者，适合读文件、改文件、跑命令、形成 diff。

怎么配合更顺：

• 用 ChatGPT 想方案、拆任务、评估风险。
• 用 Codex 在仓库里执行小任务。
• 用 Git diff 和测试结果做验收。
• 用人来决定是否合并。

这套流程比“让 AI 全自动开发”靠谱得多。

国内用户使用 Codex 前，要先解决账号和套餐问题

Codex 的使用入口和账号权益有关。你能不能用、额度多少、是否包含在当前套餐里，都要以 OpenAI 和你账号页面实时显示为准。

如果你只是轻度写代码，可能 Plus 已经够。 如果你每天高频让 AI 读仓库、写测试、修 bug、做 review，再考虑 Pro 级别。 如果你是团队或超高频工作流，才需要更高档位和更稳定的服务支持。

GPTPro 的分流建议很简单：

• 轻度开发、学生、普通办公：看 Plus。
• 高频开发、内容生产、长文档和代码工作流：看 Pro 5X。
• 团队、企业、研究型或超高频需求：看 Pro 20X。
• 支付失败、银行卡被拒、订阅不生效：先看 支付排障。

如果你担心充值和代充风险，先读 ChatGPT 订阅失败与代充安全指南，别只看价格。

结论：Codex 的正确打开方式，是“小任务 + Git + 测试 + Review”

Codex 确实能提高开发效率，但它不是魔法。

最稳的用法是：

• 在 Git 仓库里运行。
• 一次只交给它一个明确任务。
• 限定修改范围。
• 要求运行测试。
• 合并前检查 diff。
• 不把生产密钥和高危权限交给它。

如果你把 Codex 当成“能干活的初级开发”，它会很有用。 如果你把它当成“全自动 CTO”，它迟早给你整出一堆不好收拾的改动。

下一步：先在一个非生产项目里试一次 codex exec，让它改一个小 bug 或补一组测试。能跑通这条链路，再把它放进真实开发流程。