什么时候优先用 CLI

CLI 是 Codex 最贴近本地开发流程的入口。

前置教程：什么时候优先用桌面版
如果你还没看过入口选择和桌面版适用场景，先完成前置教程。

依据来源：OpenAI Codex 官方手册中 Codex CLI、CLI reference、sandboxing、approvals、configuration、workflow examples 等章节。

适合优先用 CLI 的 6 类任务

1. 在本地仓库里改代码

如果你的任务发生在一个本地项目目录里，CLI 很适合。

比如：

修改一个页面。
修一个接口 bug。
调整一个组件。
更新 README。
增加一个测试。

CLI 的优势是：Codex 直接工作在当前项目目录里。

你给它任务时，可以明确说：

请先阅读当前项目，只修改和本任务直接相关的文件。
修改前先说明计划，修改后总结 diff 和验证结果。

2. 需要构建、测试或检查

如果任务完成标准里包含：

构建是否通过。
测试是否通过。
lint 是否通过。
类型检查是否通过。
Git diff 是否干净。

CLI 很适合。

但注意：这不意味着你要手动执行所有命令。

更专业的做法是把验收标准告诉 Codex：

完成后请根据项目现有脚本进行必要验证。
如果你运行了检查，请告诉我运行了什么、结果是什么。
如果没有运行，请说明原因。

Codex 会根据权限、沙箱和项目情况决定能不能执行检查。你要学会看它的检查说明。

3. 需要严格限制修改范围

CLI 很适合做“范围明确”的任务。

比如：

只允许修改 src/pages/index.vue。
不要修改 package.json。
不要格式化无关文件。
不要引入新依赖。

这类任务非常适合 CLI，因为你可以在项目目录里围绕文件、路径、脚本和 diff 进行明确约束。

4. 提交前检查

提交前你需要确认：

哪些文件改了。
有没有无关文件。
有没有敏感信息。
有没有构建或测试结果。
提交说明怎么写。

CLI 很适合让 Codex 帮你做提交前复核。

提示词：

请帮我做提交前检查。

要求：
1. 检查当前变更文件列表。
2. 判断是否有无关文件。
3. 检查是否有明显敏感信息。
4. 总结本次变更。
5. 如果适合提交，请给出 3 个中文提交说明候选。
6. 不要执行提交。

5. 处理命令输出和报错

如果你遇到构建失败、测试失败、依赖安装失败，CLI 很适合。

你可以把错误交给 Codex：

这是当前构建失败的输出。请先分析原因，不要直接修改文件。
请按最可能到最不可能排序，并告诉我下一步应该检查什么。

注意：不要一上来让 Codex “全部修好”。

先让它分析，再决定是否修。

6. 做可重复工作流

如果你想把某些工作做成稳定流程，CLI 更适合沉淀。

比如：

每次提交前检查。
每次修 Bug 的步骤。
每次新增页面的验收。
每次升级依赖的复核。

这些后续可以沉淀到：

AGENTS.md
config.toml
Skills
Hooks
模板库

不适合优先用 CLI 的情况

完全不熟悉终端

如果你连项目目录、PowerShell、Git 状态都不清楚，先用桌面版更稳。

只想解释当前编辑器里的选中代码

这种情况 IDE 扩展更顺手。

想远程并行跑长任务

Cloud 更适合。

CLI 不是“用户手动跑命令”的教程

本站后续 CLI 教程会尽量避免把用户变成命令执行机器。

除了安装、登录、准备环境这种必须手动做的步骤，真正使用 Codex 时，重点是对话：

你告诉 Codex 目标。
你限制范围。
你写验收标准。
Codex 自己读取项目。
Codex 根据需要请求执行检查。
你审批高风险操作。
你阅读总结和 diff。

这才是让 vibe coding 更专业和更高效的核心。

CLI 新手提示词

进入项目后，第一次可以发：

请先只读分析当前项目，不要修改任何文件。

请告诉我：
1. 项目类型。
2. 入口文件。
3. 可用脚本。
4. 潜在风险。
5. 适合新手练习的第一个小任务。

这比直接说“帮我优化项目”靠谱得多。

本篇验收

看完后，你应该能判断：

为什么本地项目实战常用 CLI。
哪些任务适合 CLI。
为什么 CLI 使用重点仍然是对话，而不是用户手动跑命令。
什么情况下应该换桌面版、IDE 或 Cloud。

下一篇看：什么时候优先用 IDE 或 Cloud。