一、被琐碎任务打断的心流，谁来拯救？
每一位开发者都经历过这样的时刻：正在专注实现核心逻辑，突然发现某个 console.log 忘了删，或者某个函数缺少单元测试。这些任务本身并不复杂，却足够繁琐，足以把完整的思路切割得支离破碎。它们不产生直接价值，却消耗着宝贵的心流状态。
Codex CLI 正是为了解决这类问题而生。它是一个运行在终端里的 AI 编程助手，能够自主阅读代码、修改文件、执行命令，并在循环迭代中逼近目标。对于终端重度用户、自动化爱好者以及追求极致响应速度的开发者来说，它几乎是为他们量身定做的工具。更值得一提的是，Codex CLI 与桌面应用共享同一账号体系，你可以在日常开发中用 CLI 快速处理小任务，在需要并行或复杂审查时切换到桌面端，两者各取所长。
二、从安装到配置：两条路径与一个核心文件
启动 Codex CLI 的方式非常直接。如果你拥有 ChatGPT 账号，只需在终端输入 codex 并按提示登录；如果你更习惯使用 API 密钥，则可以先设置环境变量 OPENAI_API_KEY，再运行同一命令。两种方式殊途同归，选择哪一种完全取决于你的使用习惯。
真正决定 Codex CLI 行为的是位于 ~/.codex/config.toml 的配置文件。这个文件是持久化配置的入口，统一管理模型选择、沙盒权限、审批策略等核心参数。以下是一个典型的配置片段，展示了如何接入第三方 API 服务：
[model_providers.deepseek]
name = "DeepSeek"
base_url = "https://api.deepseek.com/v1"
env_key = "DEEPSEEK_API_KEY"
wire_api = "responses"
requires_openai_auth = false
这里有几个容易踩坑的细节：base_url 必须以 /v1 结尾；env_key 指向的是环境变量的名称，而不是直接写入密钥字符串；由于 OpenAI 已经废弃了 chat/completions 路径，使用 Responses API 的 Provider 必须将 wire_api 设置为 "responses"。这些配置虽然看起来琐碎，却决定了你能否顺利接入 DeepSeek、Azure OpenAI 等第三方模型服务。
三、用 Profiles 为不同场景定制 AI 行为
一个值得称道的设计是 Codex CLI 的 Profiles 机制。它允许你预先定义多组配置组合，针对不同任务快速切换。例如，在分析一个陌生仓库时，你希望 AI 只读代码、不做任何修改，同时每一步操作都需要征求你的确认；而在沙盒环境中进行全自动任务时，你则希望它拥有写入权限且无需反复审批。这些需求都可以通过 Profiles 轻松实现。
[profiles.readonly]
sandbox_mode = "read-only"
approval_policy = "on-request"
[profiles.fullauto]
sandbox_mode = "workspace-write"
approval_policy = "never"
这种配置隔离的思路非常实用：它把安全边界和自动化程度的选择权交还给了开发者。你可以在一个 Profile 中放开手脚让 AI 自主操作，在另一个 Profile 中严格限制它的权限。结合会话控制、代码审查、配置管理、工具调用等命令分类，Codex CLI 已经不再是一个简单的脚本工具，而是一个可以深度定制的 AI 开发环境。
四、从“会聊天”到“能动手”的质变
Codex CLI 与普通 AI 聊天助手的最大区别，在于它具备“动手能力”。它能够直接操作你的文件系统、执行终端命令，并在迭代中修正自己的行为。这种从“建议”到“执行”的转变，意味着开发者可以把大量重复性劳动交给 AI，自己专注于架构设计和创造性工作。
当然，能力越强，责任越大。沙盒模式和审批策略正是为了平衡效率与安全而设计。在享受自动化带来的便利时，我们依然需要保持对代码的掌控力。Codex CLI 的出现，或许预示着未来开发工具的一种新范式：终端不再是冷冰冰的命令行，而是人机协作的智能工作台。如果你已经在使用它，不妨分享你最常用的命令——毕竟，AI 时代的学习方式，本身就是一场集体探索。