夜雨聆风
这是 Codex 系列的第 2 篇。
第 1 篇讲的是心智：Codex 不是一个更会写代码的聊天框，而是一个可以进入项目现场的工程 Agent。到了第二篇，问题就会变得更具体：
提示词
我应该从哪个入口开始用 Codex？现在 Codex 有几个常见入口：App、CLI、IDE Extension、Web / Cloud。它们不是简单的“谁更强”，而是适合不同的工作闭环。
我一开始也容易把这个问题想复杂：是不是 CLI 更专业，App 更适合新手，IDE 更像补全，Cloud 更适合团队？后来实际用下来，我觉得更稳的判断方式是：
提示词
不要按工具选入口，要按任务闭环选入口。你这次任务需要本机环境吗？需要正在打开的文件吗？需要终端命令和脚本吗？需要异步跑在 GitHub 仓库里并产出 PR 吗？这些问题比“哪个入口更高级”更重要。
整理日期：2026-06-28。Codex 的入口、命令、权限、模型和套餐说明可能继续变化；本文涉及当前能力的事实，以 OpenAI 官方文档和你账号实际可用入口为准。
这篇解决什么问题
读完这篇，你应该能带走三样东西：
这一篇不追求把每个入口的所有按钮讲完。界面会变，按钮会变，但入口背后的工作方式更稳定。
开始前先做一个前置检查
入口选择之前，先确认四件事。很多“Codex 不好用”的问题，其实不是入口选错，而是项目边界、账号入口、环境和验证方式没准备好。
项目边界
你要确认什么：这次只让 Codex 进入哪个目录或仓库
为什么重要：防止它读太多无关文件，也防止修改范围失控
Git 状态
你要确认什么：当前有没有未提交改动，是否需要先提交或备份
为什么重要：方便看 diff、回滚和比较方案
验证命令
你要确认什么：有哪些测试、lint、build、预览或手动检查
为什么重要：没有验证方式，Agent 的“完成”就只是口头总结
权限模式
你要确认什么：是只读、workspace-write、需要网络，还是必须人工批准
为什么重要：权限决定它能不能真的动手，也决定风险边界
不同入口还有自己的前置条件：
--sandbox workspace-write --ask-for-approval on-request | |
@file 明确引用；复杂任务不要只依赖一个选区 | |
如果你用 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 流
不适合什么：任务依赖本机未提交文件、私密本地数据或只能在本机复现的问题
我的个人默认顺序是：
提示词
不确定 -> 先让 Codex 只读项目并出计划
本地第一次练习 -> App Local
真实仓库调试 -> CLI
正在写具体文件 -> IDE Extension
异步从 issue 到 PR -> Web / Cloud
多方案并行尝试 -> App Worktree 或 Cloud attempts这里最重要的是“不确定时先只读”。入口选错不是大问题，权限开太大、范围给太宽、没看 diff，才是大问题。
2. 不要按设备选，要按工作闭环选
我现在会把 Codex 任务拆成五个环节：
提示词
上下文 -> 执行环境 -> 权限边界 -> 验证方式 -> 交付物入口选择，本质上就是看哪个入口能让这五件事最短地闭合。
如果一个入口能自然覆盖这五个环节，它就是当前任务的好入口。
比如“解释我正在看的 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 里要特别理解三个模式：
这里有一个容易被忽略的点：如果你在一个大仓库里有多个 app 或 package，不要随手把整个 monorepo 顶层当成一个项目交给 Codex。官方文档也建议，单仓库里有多个应用时，可以把不同项目拆成单独的 App projects，让 sandbox 只覆盖这个项目真正需要的文件。
我自己的经验是：App 最适合建立“项目现场感”。你能看到 Codex 做了什么，能看 diff，能开终端，能把线程放进 Worktree，也能把常用命令做成 actions。
但 App 也不是越大越好。不要把桌面、下载目录、整个用户目录交给它。项目边界越清楚，Codex 越像工程同事；边界越散，它越像一个被丢进仓库迷宫里的实习生。
App 的一个好任务
提示词
请在当前博客项目的 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：
/review 工作流，适合看当前 diff 或某个 commit | |
codex exec | |
codex cloud |
最常见的入口就是：
命令
codex或者带一个初始任务：
命令
codex "请解释这个代码库的主要目录结构，并指出测试和构建命令在哪里。"本地低风险工作，我会显式保守一点：
命令
codex --sandbox workspace-write --ask-for-approval on-request "请先阅读项目并输出修改计划，不要直接改。"这组参数的意思是：工作区内可以写，但需要按需请求批准。官方 CLI reference 也把 workspace-write + on-request 作为本地低摩擦工作的组合之一。
CLI 里有几个命令值得早一点知道：
codex | |
codex "..." | |
codex exec "..." | |
/review | |
codex cloud | |
codex apply TASK_ID | |
--image-i | |
--search |
注意，不要过早使用 --dangerously-bypass-approvals-and-sandbox 或 --yolo。官方文档把这类选项明确标成高风险，只适合外部已经做了硬隔离的环境。日常个人项目里，我更愿意多点几次确认，也不想让 Agent 在我的机器上自由奔跑。
CLI 的一个好任务
命令
codex --sandbox workspace-write --ask-for-approval on-request "请检查当前分支未提交改动。先输出你看到的文件变化和风险点，再给出是否需要修改的建议。不要直接改代码。"等它输出计划后，如果你同意，再继续说：
提示词
可以开始修改。请只处理你刚才列出的 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：
@file 能减少误读 | |
IDE 的关键不是“它能不能改整个项目”，而是它离局部上下文最近。
比如你正在看一个 PostList.tsx，想让 Codex 帮你处理空状态。一个好的 IDE Prompt 不是：
提示词
优化一下文章列表。而是：
提示词
请参考 @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 不是万能的。它最怕这些任务：
Cloud 环境有一个重要安全细节：setup 阶段可以访问网络来安装依赖；agent 阶段默认没有互联网访问，除非你在环境里开启。Secrets 也只在 setup script 可用，出于安全考虑会在 agent phase 前移除。这个设计很好，但也说明一件事：Cloud 更适合“仓库里的工程任务”，不是“拿我的本机状态随便跑”。
Cloud 的一个好任务
提示词
请从 main 分支开始处理这个任务。
目标：
修复文章列表在没有文章时仍显示旧分类的问题，并提交一个 PR。
上下文：
分类应该收敛到 AI 与智能体、工程实践、金融投资、阅读笔记、个人随笔、工具与效率、项目记录。
约束：
1. 不要修改文章正文。
2. 不要新增依赖。
3. 保留已有路由结构。
4. 如果发现数据源不清楚，先在总结里说明，不要猜。
完成标准：
1. 说明相关文件和原因。
2. 修改后运行可用的测试或构建命令。
3. PR 描述里写清用户可见变化、风险和验证方式。如果你在 CLI 里提交 Cloud 任务，可以用类似：
命令
codex cloud exec --env ENV_ID "请从 main 分支开始，修复文章列表空状态问题，并在完成后总结 diff、测试结果和 PR 建议。"这里的 ENV_ID 来自你的 Codex Cloud 环境配置。别把环境配置当成小事：依赖安装、运行时版本、环境变量和测试命令越明确，Cloud 任务越可靠。
7. 入口选择流程
我会用下面这张图做判断：
文字版是这样：任务必须使用本机环境、私密文件或本地未提交状态吗？
是：优先 App、CLI 或 IDE。 否：可以考虑 Web / Cloud。
任务强依赖当前打开文件、选区或编辑器上下文吗？
是：优先 IDE Extension。 否：继续判断。
任务需要终端命令、脚本、CI 思路或可重复执行吗？
是：优先 CLI。 否：继续判断。
任务需要多线程、Worktree、Git 面板或更舒服地看 diff 吗？
是：优先 App。 否：新手默认 App Local，熟悉终端的人默认 CLI。
任务最终想要一个 PR，且能在远端环境完成吗？
是：Web / Cloud。 否：本地入口先完成，再决定是否推 PR。
这个流程不是为了限制你，而是为了防止“一上来就把所有事情都交给一个入口”。入口可以切换，任务也可以 handoff，但一开始选对，会少很多无谓摩擦。
8. 入口可以切换，不要硬扛
真实使用里，任务经常会变形。你一开始只是想解释一个文件，后来发现要改测试；一开始只是想让 Cloud 修 issue，后来发现只有本机能复现。这时候不要硬在原入口里继续拧，直接切换入口。
codex apply TASK_ID 带回本地检查 | |
一个简单原则是：
提示词
上下文换地方，入口也可以换地方。
验证换地方，入口更应该换地方。比如 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 尝试。
提示词
请在当前 Codex App 项目里工作。
目标：
【这次要完成什么】
上下文：
【相关目录、文件、页面、截图或参考链接】
约束：
1. 不要修改【文件/目录】。
2. 不要新增依赖，除非先说明理由。
3. 先读项目和 AGENTS.md，再输出计划。
4. 修改后总结 diff、验证结果和剩余风险。
完成标准：
1. 【用户可见变化】
2. 【需要通过的命令或手动检查】
3. 【需要交付的文件或说明】
请先输出计划，不要直接修改。CLI Prompt
适合终端里的 bug、测试、review、批处理。
命令
codex --sandbox workspace-write --ask-for-approval on-request "目标：【任务】。请先读取当前仓库状态和相关文件，输出计划，不要直接修改。约束：【约束】。完成后需要运行：【测试/构建命令】并总结 diff。"如果只是 review：
提示词
/review然后选择 review 当前未提交改动、某个 commit，或自定义范围。
IDE Prompt
适合局部文件、选区和正在写代码的上下文。
提示词
请参考 @当前文件 和 @相关文件。
目标：
【局部修改目标】
约束：
1. 保持当前 API 不变。
2. 不要改无关文件。
3. 不要新增依赖。
4. 如果需要跨文件修改，先列出来等我确认。
请先解释你理解的当前实现，再给出修改计划。Cloud Prompt
适合 GitHub repo、issue、PR 和异步任务。
提示词
请从【分支】开始处理。
目标：
【issue / bug / feature】
上下文：
【issue 链接、复现步骤、期望行为、相关文档】
约束：
1. 不要修改【高风险模块】。
2. 不要引入新依赖，除非 PR 描述里解释原因。
3. 如果环境缺失，请在总结里说明，不要猜测通过。
完成标准：
1. 提供 diff 总结。
2. 运行可用的测试、lint 或 build。
3. 写清手动验证步骤。
4. PR 描述包含风险和回滚建议。这些模板不需要一字不差地背。真正要保留的是结构：目标、上下文、约束、完成标准，以及“先计划，不要直接改”的刹车。
11. 30-60 分钟练习
这一篇的练习不是让你装完所有入口，而是让你比较两个入口的差异。
找一个低风险项目，最好是上篇文章创建的练习目录，或者一个已经有 Git 的小项目。
第一步：用 App 或 IDE 做只读理解
Prompt：
提示词
请只读当前项目，不要修改。
请输出：
1. 项目主要文件结构。
2. 可能的运行或验证命令。
3. 适合交给 Codex 的 3 个小任务。
4. 你认为当前项目最适合用 App、CLI、IDE 还是 Cloud，为什么。记录它的回答。
第二步：用 CLI 问同一个问题
在同一个目录里跑：
命令
codex "请只读当前项目，不要修改。输出项目结构、运行命令、3 个适合 Codex 的小任务，并说明你建议用 App、CLI、IDE 还是 Cloud。"比较两次回答：
是否更理解当前打开文件
App / IDE：
CLI：
是否更理解终端和命令
App / IDE：
CLI：
是否更容易看 diff 或项目状态
App / IDE：
CLI：
你更愿意在哪个入口继续执行
App / IDE：
CLI：
第三步：选一个小任务执行
选一个很小的任务，比如：
提示词
给 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. 我自己的默认用法
如果把它放到这个博客项目里，我大概会这样选：
/review 或 App 里让它按 checklist 检查 | |
我不会让 Cloud 直接处理本地还没提交的草稿，也不会用 IDE 去承担整个博客信息架构调整。不是它做不到，而是那样上下文和验证都不舒服。
这个系列后面的文章会继续拆这些场景：
第 3 篇讲目录、Git、权限和回滚。 第 4 篇讲先让 Codex 读懂项目。 第 7 篇讲 Explore -> Plan -> Code -> Verify -> Review。 第 9 篇单独讲 CLI 实战。 第 10 篇讲 GitHub、issue、PR 和 Cloud。
收藏清单
如果只收藏这一篇，我建议记住这几条：
下一步练习：
找一个低风险项目。 分别用 App/IDE 和 CLI 让 Codex 只读项目。 比较两次回答里的上下文差异。 选一个小任务执行。 写一条入口选择记录。 看 diff、跑验证、记录下次入口选择是否要调整。
入口选择不是一次性决定。真正要训练的是：每次任务开始前，先问“上下文在哪里、执行在哪里、怎么验证、交付物是什么”。这几个问题问顺了，Codex 就不只是一个会写代码的入口，而会慢慢变成一套可控的工程工作流。
参考资料
OpenAI Codex docs OpenAI Codex manual OpenAI Codex App OpenAI Codex App features OpenAI Codex CLI OpenAI Codex CLI reference OpenAI Codex IDE Extension OpenAI Codex Web / Cloud OpenAI Cloud environments OpenAI Agent approvals & security CodexGuide 学习路线 bozhouDev/codex-orange-book servasyy_ai 的 Codex X 教程 SOTA Sync 转写：30 分钟搭出完整 Codex 工作流
