Codex 核心工作流教程：看懂入口、执行环境、上下文、权限与交付

Codex 不是”能写代码的聊天框”，而是一套能进入真实项目执行任务的 Agent 工作流。理解它的关键在于搞清楚五个环节。

1. 入口：四个地方，同一个大脑

入口	适合场景
App	不想开终端时快速派活，可视化看 diff
CLI	批量操作、脚本化、可进 CI
IDE 扩展	边写边改，能看到光标上下文
Cloud	定时/后台任务，不占本地机器

它们的差别不在能力，而在你在哪里看到结果。选一个与你工作方式重合的就行，不必全用。

2. 执行环境：它到底在哪跑

这是最容易被忽略、也最容易出问题的一环。

• 本地模式：直接读写你的工作目录，快，但会动你的文件
• 云端沙箱：隔离环境，安全，但拿不到本地未提交的代码

判断标准：任务需不需要访问未推送的本地改动。需要就本地，不需要就云端。

3. 上下文：它”看到”了什么

Agent 的能力上限取决于上下文质量。三种供给方式：

# 显式指定目录
codex --add-dir ./src

# 让它自己找（慢，但覆盖面广）
codex "找出所有处理支付的代码"

# 结构化上下文（推荐）
# 维护一份 ARCHITECTURE.md，让它每次先读

第三种最省力。花半小时写一份项目结构说明，能省掉后面几十次重复解释。

4. 权限边界：该放手的放手

Codex 的权限通常分三档：只读 / 需要确认 / 自动执行。

推荐的做法：

• 读取、搜索、运行测试 → 自动执行
• 修改文件 → 需要确认
• 删除、强制推送、安装全局包 → 永不自动

权限配置的本质是把”我不信任它做什么”显式写出来，而不是凭感觉点确认。

5. 交付：怎么验收

Agent 交付的不是一个”答案”，而是一组改动。验收要看三样东西：

1. diff：它到底改了哪些文件，有没有顺手动无关的
2. 可运行性：测试过没，构建过没
3. 可回滚性：这次改动能不能一条命令撤回

git diff --stat     # 先看范围
git stash            # 不对就撤

组合起来：一个完整回路

明确目标 → 划定上下文 → 派活 → 看 diff → 验收/回滚 → 沉淀到记忆

大多数人卡在第 2 步和第 4 步。上下文给得太随意，Agent 就会猜；diff 不看就提交，错误就会积累。

最后的建议

先用 Codex 做你本来就要做、但不重要的事。跑顺了，再交给它重要的事。

这个顺序反了，你会得到一堆看起来很努力、实际没法用的产出。