第 1 章 / 共 10 章
Codex 不是补全，是一个会自己动手的同事
1.1 从”我写它猜”到”我说它做”
先看一个具体场景。你接手了一个陌生仓库，需要给一个 API 加上请求频率限制。
用代码补全工具时，流程是这样的：你打开文件，自己找到中间件所在的位置，自己开始写 class RateLimiter，工具在你敲字的过程中猜下一行。判断放在哪、要改哪几个文件、怎么测试，全部由你负责，工具只负责减少击键次数。
用 Codex 时，流程变成：你在仓库根目录说明”给 /api/v1 下的所有路由加上基于 IP 的频率限制，每分钟 60 次，超限返回 429，配置项要能通过环境变量调整，改完跑一遍现有测试”。然后 Codex 自己去读目录结构、找到中间件注册的位置、写代码、运行测试、把失败的用例修好，最后给你一份改动摘要和 diff。
差别不在”生成代码”这一步，而在于谁来做决策、谁来执行、谁来验证。
这里还有一个容易混淆的历史包袱：2021 年 OpenAI 曾发布过一个叫 Codex 的代码补全模型。今天的 Codex 是一条编程代理产品线，同名但不同物。你在网上搜到的老文章如果在讲 API 补全端点，那多半是旧的那个。
1.2 六个入口，一张表看清分工
Codex 目前提供六个使用面。它们共享同一套账号和很大一部分配置，区别在于你在什么场景下唤起它：
| 入口 | 运行位置 | 最适合的场景 | 典型代价 |
|---|---|---|---|
| CLI（终端） | 你的机器 | 需要它读写真实文件、跑真实命令 | 需要自己管权限边界 |
| IDE 扩展 | 你的机器 | 改动集中在几个已打开的文件，想看着 diff 改 | 上下文局限于编辑器视野 |
| 桌面应用 | 你的机器 | 想要图形界面管理多个会话 | 与终端能力大体重合 |
| 网页（Codex Web） | 云端 | 长任务、想同时跑几个方案对比 | 需要先配好云端环境依赖 |
| GitHub 代码评审 | 云端 | Pull Request 上的自动/手动评审 | 只看 PR 范围内的改动 |
| Slack | 云端 | 从对话里直接发起任务 | 不适合需要反复交互的改动 |
IDE 扩展支持 VS Code 及其兼容编辑器（包括 Cursor、Windsurf）、Xcode 和 JetBrains 系列。云端任务可以从网页、GitHub、GitLab、Linear、Slack 发起。
1.3 为什么新手应该从 CLI 开始
六个入口里，终端是最好的学习起点，理由有三条：
- 反馈最直白。CLI 会把它要执行的每一条命令、每一次文件修改都打在屏幕上。图形界面为了美观会折叠这些细节，而你在学习阶段恰恰需要看见它们。
- 权限模型最完整。沙盒和审批策略在 CLI 上是显式的命令行参数，你能直接感受到”调紧一档”和”放开一档”的区别。
- 配置是共享的。你在 CLI 上写好的
config.toml和AGENTS.md，IDE 扩展和桌面应用同样会读。先学 CLI 等于把其他入口的地基也打好了。
所以从第2章开始，本教程的主线是 Codex CLI；第9章会回过头来讲另外几个入口在团队流程里各自站什么位置。
1.4 动手：找出你不敢交出去的那个任务
广告位 · Multiplex 关联广告