Codex 入口选择：App、CLI、IDE、Web / Cloud 怎么选

这是 Codex 系列的第 2 篇。

第 1 篇讲的是心智：Codex 不是一个更会写代码的聊天框，而是一个可以进入项目现场的工程 Agent。到了第二篇，问题就会变得更具体：

text

我应该从哪个入口开始用 Codex？

现在 Codex 有几个常见入口：App、CLI、IDE Extension、Web / Cloud。它们不是简单的“谁更强”，而是适合不同的工作闭环。

我一开始也容易把这个问题想复杂：是不是 CLI 更专业，App 更适合新手，IDE 更像补全，Cloud 更适合团队？后来实际用下来，我觉得更稳的判断方式是：

text

不要按工具选入口，要按任务闭环选入口。

你这次任务需要本机环境吗？需要正在打开的文件吗？需要终端命令和脚本吗？需要异步跑在 GitHub 仓库里并产出 PR 吗？这些问题比“哪个入口更高级”更重要。

整理日期：2026-06-28。Codex 的入口、命令、权限、模型和套餐说明可能继续变化；本文涉及当前能力的事实，以 OpenAI 官方文档和你账号实际可用入口为准。

这篇解决什么问题

读完这篇，你应该能带走三样东西：

产物	用来解决什么
入口选择速查表	判断 App、CLI、IDE、Web / Cloud 分别适合什么任务
入口选择流程图	不确定时按几个问题逐步收敛
四类 Prompt 模板	针对 App、CLI、IDE、Cloud 分别写任务

这一篇不追求把每个入口的所有按钮讲完。界面会变，按钮会变，但入口背后的工作方式更稳定。

Codex 入口地图

开始前先做一个前置检查

入口选择之前，先确认四件事。很多“Codex 不好用”的问题，其实不是入口选错，而是项目边界、账号入口、环境和验证方式没准备好。

检查项	你要确认什么	为什么重要
项目边界	这次只让 Codex 进入哪个目录或仓库	防止它读太多无关文件，也防止修改范围失控
Git 状态	当前有没有未提交改动，是否需要先提交或备份	方便看 diff、回滚和比较方案
验证命令	有哪些测试、lint、build、预览或手动检查	没有验证方式，Agent 的“完成”就只是口头总结
权限模式	是只读、workspace-write、需要网络，还是必须人工批准	权限决定它能不能真的动手，也决定风险边界

不同入口还有自己的前置条件：

入口	开始前最好确认
App	已选择正确项目目录；第一次练习优先用 Local；并行尝试再考虑 Worktree
CLI	当前终端已经在目标目录；知道要不要显式加 `--sandbox workspace-write --ask-for-approval on-request`
IDE Extension	相关文件已经打开；需要的文件用 `@file` 明确引用；复杂任务不要只依赖一个选区
Web / Cloud	GitHub 仓库已连接；Cloud 环境、依赖安装、运行时版本和测试命令足够明确

如果你用 JetBrains 系列 IDE，可以关注官方 JetBrains 集成；本文后面讲 IDE Extension 时，主要以 VS Code / Cursor / Windsurf 这类 VS Code-compatible editor 的使用方式为例。

1. 先给结论

如果只想先用起来，可以按这张表选：

入口	我会在什么时候选它	主要优势	不适合什么
Codex App	第一次上手、本地项目、多线程尝试、需要舒服地看 diff 和 Git 状态	桌面工作台、Local / Worktree / Cloud 模式、内置 Git 工具、集成终端	把整个硬盘、桌面或一堆无关项目都交给它
Codex CLI	我已经在终端里，想让 Codex 读仓库、跑命令、修 bug、review、写脚本化流程	参数明确、适合命令行和自动化、可用 `exec` / `review` / `cloud`	需求很模糊、完全不看命令输出、直接全权限跑
IDE Extension	我正在编辑器里看某几个文件，想让 Codex 理解当前打开文件、选区或 `@file`	上下文近、局部改动快、适合边写边问	让它凭一个选区理解整个大型仓库
Web / Cloud	任务可以在远端 GitHub 仓库里异步完成，目标是 diff、PR 或多人 review	托管执行、可从 GitHub repo 开始、适合异步任务和 PR 流	任务依赖本机未提交文件、私密本地数据或只能在本机复现的问题

我的个人默认顺序是：

text

不确定 -> 先让 Codex 只读项目并出计划
本地第一次练习 -> App Local
真实仓库调试 -> CLI
正在写具体文件 -> IDE Extension
异步从 issue 到 PR -> Web / Cloud
多方案并行尝试 -> App Worktree 或 Cloud attempts

这里最重要的是“不确定时先只读”。入口选错不是大问题，权限开太大、范围给太宽、没看 diff，才是大问题。

2. 不要按设备选，要按工作闭环选

我现在会把 Codex 任务拆成五个环节：

text

上下文 -> 执行环境 -> 权限边界 -> 验证方式 -> 交付物

入口选择，本质上就是看哪个入口能让这五件事最短地闭合。

问题	你在判断什么
上下文在哪里？	在本地目录、终端输出、编辑器选区、GitHub repo，还是浏览器页面？
执行在哪里发生？	本机、Worktree、远端容器，还是只做聊天分析？
权限怎么控制？	只读、workspace-write、需要网络、需要跨目录、需要 Full Access？
怎么验证？	测试、lint、build、预览页面、人工 review、PR checks？
交付物是什么？	解释、计划、diff、commit、PR、文档、图片、发布记录？

如果一个入口能自然覆盖这五个环节，它就是当前任务的好入口。

比如“解释我正在看的 React 组件为什么状态更新两次”，IDE Extension 很自然，因为上下文就在当前打开文件和选区里。

比如“帮我检查当前分支还没提交的所有改动，有没有回归风险”，CLI 或 App 都很自然，因为它们离 Git diff、终端和本地项目更近。

比如“从 GitHub issue 出发修一个不依赖本机数据的 bug，并提交 PR”，Web / Cloud 更自然，因为任务的起点和终点都在远端仓库。

3. Codex App：本地项目工作台

Codex App 的定位是桌面工作台。官方文档把它描述为一个适合并行处理 Codex threads 的桌面体验，并带有 Worktree、Automations 和 Git 功能。

我会在这些情况下优先用 App：

场景	为什么用 App
第一次练习 Codex	UI 能看到线程、diff、Git 状态和终端，心里更有底
同一个项目想试两种方案	Worktree 可以把变化隔离开，不影响当前 Local
前端页面改动	可以配合集成终端、本地预览和浏览器检查
写博客、配图、整理文章	文章、图片、校验、发布 checklist 可以放在同一个线程里
需要边看 diff 边反馈	App 的 diff 和 Git 操作更适合人工介入

App 里要特别理解三个模式：

模式	适合什么
Local	直接在当前项目目录工作，适合小任务和你愿意立即检查的修改
Worktree	在 Git worktree 里隔离改动，适合并行尝试、后台任务、不想打扰当前工作区
Cloud	把任务交到远端环境，适合可以异步完成的仓库任务

这里有一个容易被忽略的点：如果你在一个大仓库里有多个 app 或 package，不要随手把整个 monorepo 顶层当成一个项目交给 Codex。官方文档也建议，单仓库里有多个应用时，可以把不同项目拆成单独的 App projects，让 sandbox 只覆盖这个项目真正需要的文件。

我自己的经验是：App 最适合建立“项目现场感”。你能看到 Codex 做了什么，能看 diff，能开终端，能把线程放进 Worktree，也能把常用命令做成 actions。

但 App 也不是越大越好。不要把桌面、下载目录、整个用户目录交给它。项目边界越清楚，Codex 越像工程同事；边界越散，它越像一个被丢进仓库迷宫里的实习生。

App 的一个好任务

text

请在当前博客项目的 Local 模式下，先阅读 AGENTS.md、drafts 目录和 content/blog 目录。

目标：
把这篇草稿整理成可发布版本，但先不要发布。

约束：
1. 不要修改已经发布的文章。
2. 不要新增外部依赖。
3. 图片只放在 drafts/assets 下。
4. 完成后列出改动文件、图片文件和发布前检查项。

请先输出计划，不要直接改。

这种任务很适合 App，因为它需要读项目、改文件、看 diff、可能生成图片，还需要人工决定是否发布。

4. Codex CLI：终端里的工程入口

CLI 的好处是直接。你站在项目目录里，Codex 就在这个目录里读、改、跑命令。

官方文档里说，Codex CLI 可以在选定目录里读取、修改并运行本机代码；它支持 macOS、Windows 和 Linux，Windows 下可以在 PowerShell 里原生运行，也可以在需要 Linux-native 环境时用 WSL2。

我会在这些情况下优先用 CLI：

场景	为什么用 CLI
我已经在终端里复现问题	命令输出就是上下文，不用再搬来搬去
修 bug、补测试、跑 lint/build	Codex 可以直接执行和解释命令
做代码 review	CLI 有 `/review` 工作流，适合看当前 diff 或某个 commit
写自动化流程	`codex exec` 更适合脚本化、非交互任务
启动 Cloud 任务	`codex cloud` 可以在终端里提交和查看远端任务

最常见的入口就是：

bash

codex

或者带一个初始任务：

bash

codex "请解释这个代码库的主要目录结构，并指出测试和构建命令在哪里。"

本地低风险工作，我会显式保守一点：

bash

codex --sandbox workspace-write --ask-for-approval on-request "请先阅读项目并输出修改计划，不要直接改。"

这组参数的意思是：工作区内可以写，但需要按需请求批准。官方 CLI reference 也把 workspace-write + on-request 作为本地低摩擦工作的组合之一。

CLI 里有几个命令值得早一点知道：

命令 / 能力	用途
`codex`	进入交互式终端 UI
`codex "..."`	给一个快速问题，让它读当前目录后回答
`codex exec "..."`	非交互执行，适合脚本化任务
`/review`	在交互会话里对 diff、commit 或自定义范围做代码 review
`codex cloud`	从终端查看和提交 Cloud 任务
`codex apply TASK_ID`	把 Cloud 任务的 diff 应用到本地工作区
`--image` / `-i`	把截图或设计图作为上下文传入
`--search`	本次运行启用 live web search，适合需要最新资料的任务

注意，不要过早使用 --dangerously-bypass-approvals-and-sandbox 或 --yolo。官方文档把这类选项明确标成高风险，只适合外部已经做了硬隔离的环境。日常个人项目里，我更愿意多点几次确认，也不想让 Agent 在我的机器上自由奔跑。

CLI 的一个好任务

bash

codex --sandbox workspace-write --ask-for-approval on-request "请检查当前分支未提交改动。先输出你看到的文件变化和风险点，再给出是否需要修改的建议。不要直接改代码。"

等它输出计划后，如果你同意，再继续说：

text

可以开始修改。请只处理你刚才列出的 P1/P2 问题，完成后运行可用的检查命令，并总结 diff。

这就是 CLI 的节奏：终端上下文、明确边界、执行命令、检查 diff。

5. IDE Extension：正在写代码时的近场助手

IDE Extension 更像“贴在编辑器旁边的 Codex”。它不是简单补全，而是能利用你打开的文件、选中的代码和编辑器上下文。

官方文档里提到，Codex IDE Extension 可在 VS Code、Cursor、Windsurf 和其他 VS Code-compatible editors 中使用，并和 CLI 使用同一个 agent、共享同一套配置。你可以用 @example.tsx 这样的方式引用编辑器里的文件。

我会在这些情况下优先用 IDE：

场景	为什么用 IDE
我正在看某个文件	当前文件就是上下文，Prompt 可以更短
我只想改一个组件或函数	选区、打开文件、`@file` 能减少误读
我想边写边问	Chat / Agent 模式之间切换更自然
我想先讨论再改	可以用 Chat 做计划，再切 Agent 执行
我想从本地对话委派 Cloud	IDE 可以把上下文带到云端任务

IDE 的关键不是“它能不能改整个项目”，而是它离局部上下文最近。

比如你正在看一个 PostList.tsx，想让 Codex 帮你处理空状态。一个好的 IDE Prompt 不是：

text

优化一下文章列表。

而是：

text

请参考 @PostList.tsx 和 @posts.ts。

目标：
当文章列表为空时，显示一个轻量的空状态。

约束：
1. 不要改变现有排序逻辑。
2. 不要新增依赖。
3. 保持现有样式命名习惯。
4. 如果需要改测试，请先说明。

请先指出你会修改哪些文件。

IDE 入口特别适合小而明确的任务。它的风险是：你以为 Codex 已经理解整个仓库，但它实际更多依赖当前打开文件、选区和你显式引用的文件。任务一旦跨多个模块、涉及构建脚本或需要跑复杂命令，我会更倾向切到 CLI 或 App。

还有一个细节：IDE 里可以调 reasoning effort。官方文档建议从 medium 开始，复杂任务再切到 high，因为更高 effort 会更慢，也会消耗更多 token。我的理解是：局部问题别一上来就拉满，架构分析、复杂 bug、跨文件重构再考虑加深。

6. Web / Cloud：异步任务和 PR 工作流

Web / Cloud 的核心不是“网页上也能聊天”，而是远端执行。

官方文档里，Codex web 的入口是 chatgpt.com/codex，连接 GitHub 后，Codex 可以在你的仓库里工作并创建 pull request。Cloud 任务会在容器里 checkout repo，运行 setup script，然后让 agent 修改代码、跑检查、展示 diff，最后你可以打开 PR 或继续追问。

我会在这些情况下优先用 Web / Cloud：

场景	为什么用 Cloud
从 GitHub issue 到 PR	上下文和交付物都在 GitHub，闭环短
任务可以异步跑	不依赖你本机一直开着
想并行尝试几个方案	Cloud 可以跑多次尝试，最后比较结果
团队需要 review	PR 天然适合多人检查
本地环境太脏	远端环境可用 setup script 重新搭建

但 Cloud 不是万能的。它最怕这些任务：

不适合 Cloud 的情况	原因
依赖本机未提交文件	Cloud 只知道远端 repo 和任务上下文
依赖本机私密数据	不应该把本地数据临时塞给远端 agent
只能在你机器上复现	Cloud 容器环境不一定等于你的本机
环境没有配置好	没有 setup script、依赖或测试命令，Agent 很难验证
需要登录态浏览器操作	Cloud repo 任务不是你的个人浏览器会话

Cloud 环境有一个重要安全细节：setup 阶段可以访问网络来安装依赖；agent 阶段默认没有互联网访问，除非你在环境里开启。Secrets 也只在 setup script 可用，出于安全考虑会在 agent phase 前移除。这个设计很好，但也说明一件事：Cloud 更适合“仓库里的工程任务”，不是“拿我的本机状态随便跑”。

Cloud 的一个好任务

text

请从 main 分支开始处理这个任务。

目标：
修复文章列表在没有文章时仍显示旧分类的问题，并提交一个 PR。

上下文：
分类应该收敛到 AI 与智能体、工程实践、金融投资、阅读笔记、个人随笔、工具与效率、项目记录。

约束：
1. 不要修改文章正文。
2. 不要新增依赖。
3. 保留已有路由结构。
4. 如果发现数据源不清楚，先在总结里说明，不要猜。

完成标准：
1. 说明相关文件和原因。
2. 修改后运行可用的测试或构建命令。
3. PR 描述里写清用户可见变化、风险和验证方式。

如果你在 CLI 里提交 Cloud 任务，可以用类似：

bash

codex cloud exec --env ENV_ID "请从 main 分支开始，修复文章列表空状态问题，并在完成后总结 diff、测试结果和 PR 建议。"

这里的 ENV_ID 来自你的 Codex Cloud 环境配置。别把环境配置当成小事：依赖安装、运行时版本、环境变量和测试命令越明确，Cloud 任务越可靠。

7. 入口选择流程

我会用下面这张图做判断：

Codex 入口选择流程

文字版是这样：

任务必须使用本机环境、私密文件或本地未提交状态吗？
- 是：优先 App、CLI 或 IDE。
- 否：可以考虑 Web / Cloud。
任务强依赖当前打开文件、选区或编辑器上下文吗？
- 是：优先 IDE Extension。
- 否：继续判断。
任务需要终端命令、脚本、CI 思路或可重复执行吗？
- 是：优先 CLI。
- 否：继续判断。
任务需要多线程、Worktree、Git 面板或更舒服地看 diff 吗？
- 是：优先 App。
- 否：新手默认 App Local，熟悉终端的人默认 CLI。
任务最终想要一个 PR，且能在远端环境完成吗？
- 是：Web / Cloud。
- 否：本地入口先完成，再决定是否推 PR。

这个流程不是为了限制你，而是为了防止“一上来就把所有事情都交给一个入口”。入口可以切换，任务也可以 handoff，但一开始选对，会少很多无谓摩擦。

8. 入口可以切换，不要硬扛

真实使用里，任务经常会变形。你一开始只是想解释一个文件，后来发现要改测试；一开始只是想让 Cloud 修 issue，后来发现只有本机能复现。这时候不要硬在原入口里继续拧，直接切换入口。

变化	更稳的切换
IDE 里问着问着，发现要跑很多命令	切到 CLI，让终端输出成为上下文
CLI 里修着修着，发现要多方案并行	切到 App Worktree 或 Cloud 多次尝试
App Local 里改动变大，担心影响当前工作区	把后续尝试放到 Worktree
Cloud 做完了，但需要本机真实环境验证	用 PR、分支或 `codex apply TASK_ID` 带回本地检查
Cloud 任务发现缺少本地未提交文件	停止远端执行，回到本地 App / CLI / IDE
只读分析变成需要实际修改	先确认计划，再把权限从 Chat / Read-only 切到可写模式

一个简单原则是：

text

上下文换地方，入口也可以换地方。
验证换地方，入口更应该换地方。

比如 Cloud 适合从 GitHub issue 到 PR，但 PR 合并前仍然可以回到本地 CLI 跑一遍真实环境。IDE 适合从当前文件开始，但如果改动跨到了脚本、配置和测试，切到 CLI 通常更顺手。

9. 场景速查表

下面这张表更适合收藏：

任务	推荐入口	为什么	验证方式
第一次练习 Codex	App Local	可视化线程、diff、终端和 Git 状态	看 diff，手动打开产物
读一个陌生项目	CLI 或 App	能读目录、总结结构、列运行命令	让它列文件依据和未确认问题
解释当前文件	IDE	打开文件和选区就是上下文	让它引用具体函数和行意图
修一个可复现 bug	CLI	复现命令、日志、测试都在终端	复现失败 -> 修改 -> 测试通过
小组件 UI 修改	IDE 或 App	IDE 适合局部，App 适合看预览和 diff	浏览器截图 / 手动交互
多方案并行尝试	App Worktree 或 Cloud	隔离改动，便于比较	分别看 diff、测试和方案说明
Review 当前 diff	CLI `/review` 或 App	可以只读变化，不必直接改	按严重程度输出 findings
从 GitHub issue 做 PR	Web / Cloud	起点和终点都在 GitHub	PR diff、checks、review
生成博客草稿和配图	App 或 CLI	文件、图片、校验都在本地	frontmatter、链接、图片引用
需要调用外部系统	视情况：MCP / connector / browser	缺的是外部数据或动作，不是入口本身	检查授权、日志和副作用
涉及密钥、财务、生产数据	先只读分析，本地谨慎执行	风险高，不能把边界交给 Agent 猜	人工审查、最小权限、回滚方案

这里我会特别提醒两个场景。

第一，Review 不等于让 Codex 继续改。好的 review 入口应该先让它只读 diff，按严重程度列风险，然后你再决定哪些要修。

第二，Cloud 任务不应该成为“我懒得配置本地环境”的万能替代。如果 Cloud 环境没有 setup script、测试命令和依赖版本，它只是换了一个更远的地方失败。

10. 四类可复制 Prompt

App Prompt

适合本地项目、草稿整理、前端修改、Worktree 尝试。

text

请在当前 Codex App 项目里工作。

目标：
【这次要完成什么】

上下文：
【相关目录、文件、页面、截图或参考链接】

约束：
1. 不要修改【文件/目录】。
2. 不要新增依赖，除非先说明理由。
3. 先读项目和 AGENTS.md，再输出计划。
4. 修改后总结 diff、验证结果和剩余风险。

完成标准：
1. 【用户可见变化】
2. 【需要通过的命令或手动检查】
3. 【需要交付的文件或说明】

请先输出计划，不要直接修改。

CLI Prompt

适合终端里的 bug、测试、review、批处理。

bash

codex --sandbox workspace-write --ask-for-approval on-request "目标：【任务】。请先读取当前仓库状态和相关文件，输出计划，不要直接修改。约束：【约束】。完成后需要运行：【测试/构建命令】并总结 diff。"

如果只是 review：

text

/review

然后选择 review 当前未提交改动、某个 commit，或自定义范围。

IDE Prompt

适合局部文件、选区和正在写代码的上下文。

text

请参考 @当前文件 和 @相关文件。

目标：
【局部修改目标】

约束：
1. 保持当前 API 不变。
2. 不要改无关文件。
3. 不要新增依赖。
4. 如果需要跨文件修改，先列出来等我确认。

请先解释你理解的当前实现，再给出修改计划。

Cloud Prompt

适合 GitHub repo、issue、PR 和异步任务。

text

请从【分支】开始处理。

目标：
【issue / bug / feature】

上下文：
【issue 链接、复现步骤、期望行为、相关文档】

约束：
1. 不要修改【高风险模块】。
2. 不要引入新依赖，除非 PR 描述里解释原因。
3. 如果环境缺失，请在总结里说明，不要猜测通过。

完成标准：
1. 提供 diff 总结。
2. 运行可用的测试、lint 或 build。
3. 写清手动验证步骤。
4. PR 描述包含风险和回滚建议。

这些模板不需要一字不差地背。真正要保留的是结构：目标、上下文、约束、完成标准，以及“先计划，不要直接改”的刹车。

11. 30-60 分钟练习

这一篇的练习不是让你装完所有入口，而是让你比较两个入口的差异。

找一个低风险项目，最好是上篇文章创建的练习目录，或者一个已经有 Git 的小项目。

第一步：用 App 或 IDE 做只读理解

Prompt：

text

请只读当前项目，不要修改。

请输出：
1. 项目主要文件结构。
2. 可能的运行或验证命令。
3. 适合交给 Codex 的 3 个小任务。
4. 你认为当前项目最适合用 App、CLI、IDE 还是 Cloud，为什么。

记录它的回答。

第二步：用 CLI 问同一个问题

在同一个目录里跑：

bash

codex "请只读当前项目，不要修改。输出项目结构、运行命令、3 个适合 Codex 的小任务，并说明你建议用 App、CLI、IDE 还是 Cloud。"

比较两次回答：

对比项	App / IDE	CLI
是否更理解当前打开文件
是否更理解终端和命令
是否更容易看 diff 或项目状态
你更愿意在哪个入口继续执行

第三步：选一个小任务执行

选一个很小的任务，比如：

text

给 README 增加一段“如何运行本项目”，只根据项目实际文件和脚本编写，不要编造不存在的命令。

执行前写下入口选择理由：

## Codex 入口选择记录

- 日期：
- 项目：
- 任务：
- 我选择的入口：
- 不选择其他入口的原因：
- 权限设置：
- 计划验证方式：
- 最终结果：
- 下次会调整什么：

这个记录很土，但很有用。用几次后，你会知道自己什么时候容易给范围太大，什么时候该先 review，什么时候该把规则写进 AGENTS.md。

12. 常见误区

误区	问题	更稳的做法
App 是新手工具，CLI 才专业	入口不是水平高低，而是工作闭环不同	App 适合多线程、Git、预览；CLI 适合终端和自动化
IDE 能看到当前文件，就能理解整个项目	当前文件不等于完整上下文	用 `@file` 明确引用相关文件，复杂任务切 CLI/App
Cloud 能跑就不用管环境	环境不清，验证就会变弱	配好 setup script、依赖版本、测试命令
Full Access 更省事	省掉的是确认，也放大了风险	从 workspace-write / on-request 开始
入口选好了，Prompt 可以随便写	入口只决定场地，不替你定义任务	仍然写清目标、上下文、约束、完成标准
只要 Codex 说完成就结束	Agent 总结不是验收	看 diff、跑测试、人工检查关键路径

我的一个判断是：入口选错通常只是效率问题，权限和验收错了才是安全问题。

13. 我自己的默认用法

如果把它放到这个博客项目里，我大概会这样选：

博客任务	我的入口选择
写一篇新草稿	App 或 CLI
生成配图并检查引用	App
批量校验 frontmatter	CLI
改正在看的页面组件	IDE
发布前 review 当前文章	CLI `/review` 或 App 里让它按 checklist 检查
后台发布文章	浏览器 / Chrome 辅助，不单纯属于这四个入口
从 GitHub issue 改博客源码并开 PR	Web / Cloud

我不会让 Cloud 直接处理本地还没提交的草稿，也不会用 IDE 去承担整个博客信息架构调整。不是它做不到，而是那样上下文和验证都不舒服。

这个系列后面的文章会继续拆这些场景：

第 3 篇讲目录、Git、权限和回滚。
第 4 篇讲先让 Codex 读懂项目。
第 7 篇讲 Explore -> Plan -> Code -> Verify -> Review。
第 9 篇单独讲 CLI 实战。
第 10 篇讲 GitHub、issue、PR 和 Cloud。

收藏清单

如果只收藏这一篇，我建议记住这几条：

问题	入口
第一次本地练习，想看 diff 和 Git	App Local
想隔离多方案，不影响当前工作区	App Worktree
已经有终端命令、日志、测试	CLI
正在看某个文件或选区	IDE Extension
起点是 GitHub issue，终点是 PR	Web / Cloud
不确定能不能改	先 Chat / Read-only，让 Codex 出计划
涉及高风险数据或生产操作	只做分析和清单，人工决策

下一步练习：

找一个低风险项目。
分别用 App/IDE 和 CLI 让 Codex 只读项目。
比较两次回答里的上下文差异。
选一个小任务执行。
写一条入口选择记录。
看 diff、跑验证、记录下次入口选择是否要调整。

入口选择不是一次性决定。真正要训练的是：每次任务开始前，先问“上下文在哪里、执行在哪里、怎么验证、交付物是什么”。这几个问题问顺了，Codex 就不只是一个会写代码的入口，而会慢慢变成一套可控的工程工作流。

这篇解决什么问题

开始前先做一个前置检查

1. 先给结论

2. 不要按设备选，要按工作闭环选

3. Codex App：本地项目工作台

App 的一个好任务

4. Codex CLI：终端里的工程入口

CLI 的一个好任务

5. IDE Extension：正在写代码时的近场助手

6. Web / Cloud：异步任务和 PR 工作流

Cloud 的一个好任务

7. 入口选择流程

8. 入口可以切换，不要硬扛

9. 场景速查表

10. 四类可复制 Prompt

App Prompt

CLI Prompt

IDE Prompt

Cloud Prompt

11. 30-60 分钟练习

第一步：用 App 或 IDE 做只读理解

第二步：用 CLI 问同一个问题

第三步：选一个小任务执行

12. 常见误区

13. 我自己的默认用法

收藏清单

参考资料