CLI 是 Codex 最贴近本地开发流程的入口。
> 前置教程：什么时候优先用桌面版
> 如果你还没看过入口选择和桌面版适用场景，先完成前置教程。
> 依据来源：OpenAI Codex 官方手册中 Codex CLI、CLI reference、sandboxing、approvals、configuration、workflow examples 等章节。
适合优先用 CLI 的 6 类任务
如果你的任务发生在一个本地项目目录里，CLI 很适合。
比如：
- 修改一个页面。
- 修一个接口 bug。
- 调整一个组件。
- 更新 README。
- 增加一个测试。
CLI 的优势是：Codex 直接工作在当前项目目录里。
你给它任务时，可以明确说：
``
请先阅读当前项目，只修改和本任务直接相关的文件。
修改前先说明计划，修改后总结 diff 和验证结果。
`
如果任务完成标准里包含：
- 构建是否通过。
- 测试是否通过。
- lint 是否通过。
- 类型检查是否通过。
- Git diff 是否干净。
CLI 很适合。
但注意：这不意味着你要手动执行所有命令。
更专业的做法是把验收标准告诉 Codex：
`
完成后请根据项目现有脚本进行必要验证。
如果你运行了检查，请告诉我运行了什么、结果是什么。
如果没有运行，请说明原因。
`
Codex 会根据权限、沙箱 and 项目情况决定能不能执行检查。你要学会看它的检查说明。
CLI 很适合做“范围明确”的任务。
比如：
`
只允许修改 src/pages/index.vue。
不要修改 package.json。
不要格式化无关文件。
不要引入新依赖。
`
这类任务非常适合 CLI，因为你可以在项目目录里围绕文件、路径、脚本和 diff 进行明确约束。
提交前你需要确认：
- 哪些文件改了。
- 有没有无关文件。
- 有没有敏感信息。
- 有没有构建或测试结果。
- 提交说明怎么写。
CLI 很适合让 Codex 帮你做提交前复核。
提示词：
`
请帮我做提交前检查。
要求：
- 检查当前变更文件列表。
- 每次提交前检查。
- 每次修 Bug 的步骤。
- 每次新增页面的验收。
- 每次升级依赖的复核。
- AGENTS.md
- config.toml
- Skills
- Hooks
- 模板库
- 你告诉 Codex 目标。
- 你限制范围。
- 你写验收标准。
- Codex 自己读取项目。
- Codex 根据需要请求执行检查。
- 你审批高风险操作。
- 你阅读总结和 diff。
- 项目类型。
- 为什么本地项目实战常用 CLI。
- 哪些任务适合 CLI。
- 为什么 CLI 使用重点仍然是对话，而不是用户手动跑命令。
- 什么情况下应该换桌面版、IDE 或 Cloud。
2. 判断是否有无关文件。
3. 检查是否有明显敏感信息。
4. 总结本次变更。
5. 如果适合提交，请给出 3 个中文提交说明候选。
6. 不要执行提交。
`
如果你遇到构建失败、测试失败、依赖安装失败，CLI 很适合。
你可以把错误交给 Codex：
`
这是当前构建失败的输出。请先分析原因，不要直接修改文件。
请按最可能到最不可能排序，并告诉我下一步应该检查什么。
`
注意：不要一上来让 Codex “全部修好”。
先让它分析，再决定是否修。
如果你想把某些工作做成稳定流程，CLI 更适合沉淀。
比如：
这些后续可以沉淀到：
如果你连项目目录、PowerShell、Git 状态都不清楚，先用桌面版更稳。
这种情况 IDE 扩展更顺手。
Cloud 更适合。
CLI 不是“用户手动跑命令”的教程
本站后续 CLI 教程会尽量避免把用户变成命令执行机器。
除了安装、登录、准备环境这种必须手动做的步骤，真正使用 Codex 时，重点是对话：
这才是让 vibe coding 更专业和更高效的核心。
进入项目后，第一次可以发：
`
请先只读分析当前项目，不要修改任何文件。
请告诉我：
2. 入口文件。
3. 可用脚本。
4. 潜在风险。
5. 适合新手练习的第一个小任务。
``
这比直接说“帮我优化项目”靠谱得多。
看完后，你应该能判断：
下一篇看：什么时候优先用 IDE 或 Cloud。