本篇文章持续更新中，总结自己使用 Codex 的新理解。
1. 重点
Codex不是更聪明的聊天框，而是一个工程化执行线程。- 它能把模型、上下文、文件、命令、权限、外部系统和验收串起来。
- 我需要控制四件事：
- 给它地图。
- 管住权限。
- 中途纠偏。
- 用结果验收。
2. 先给它地图
832 是 Codex 的工作地图。
README.md/AGENTS.md：告诉它 workspace 边界。os/notes：承接长期笔记。whoami：承接自我判断。skills：承接稳定动作。auto/：承接本机自动化。general-agent-lab：承接主线实验。
每次进入任务，先判断它属于哪里。
3. 地基先铺好
Git 、Nodejs、Zed 等
4. 沙箱和权限
权限上，最佳平衡是“自动审查”：低风险动作尽量顺，高风险动作停下来确认。
5. Plan 和 Steer
- 复杂任务先 Plan，但 Plan 不要变成仪式。
- 小修小改，直接做。
- 复杂任务，先计划。
- 计划必须带验收方式。
- 没有验收器的 Goal，很容易变成许愿。
- 跑偏时立刻
Steer。- 这不是我要的口气。
- 太像说明书了。
- 再短一点。
- 回到
832的真实用法。 - 给我一个能验收的结果。
- 不要继续扩范围。
快捷键得换一下，当前的个人快捷键不太好
6. Git、回滚和并行
- Git 很重要
worktree是并行能力，但不要乱开
7. 验收台
Codex 说“完成了”不算完成。你是业务方，一定要 “验收”
要看的东西是：
- 文件改了什么、
git diff是否符合预期、测试/构建/lint 有没有跑、前端页面有没有实际打开、截图能不能证明结果、发布链路有没有污染公开内容。
8. 工具怎么接
Codex 强在可以接工具，但工具不是越多越好。
$browser：- 看本地页面。
- 验收前端效果。
- 截图比听总结可靠。
@chrome：- 需要真实登录态时再用。
- 不要为了“完整”随便接。
@computer：- 只能点 GUI 的事情再用。
- 能用文件和命令解决的，不先走桌面操作。
MCP / CLI：- 适合稳定外部系统。
- 写入外部服务前要确认边界。
plugins：- 接上之前先问：这是不是我的真实工作流？
skills：- 只沉淀反复出现的流程。
- 一次性偏好不要过度工程化。
9. 自动化和 Skill
自动化只适合已经想清楚的事。
- 可以自动化：
- 固定检查、固定生成、固定同步、有失败日志、有人工确认点。
- 不要自动化：
- 方向不清楚、需要我做价值判断、可能污染公开内容、只是为了让我感觉系统很完整的事。
自动化的基本闭环应该是：
text
检查 -> 处理 -> 验证 -> 留痕 -> 等我确认Skill 也是一样。它不是把所有偏好都写成 SOP，而是把反复出现、输入输出稳定、能节省真实时间的流程沉淀下来。
这类流程值得写成 Skill。一次性口味、临时偏好、还没跑通的流程，先留在 thread 或 note。
10. 记忆和规则
thread 不是最终记忆库。
- 项目边界，写进
AGENTS.md。 - 长期自我判断，写进
whoami。 - 稳定流程，写进
skills。 - 固定执行，写进
auto/。
全局安全规则也要落文件，尤其是危险动作。
- 不要批量删除文件或目录。
- 必须删除时逐个确认。
- 不确定就停下来，让我手动确认。
真正重要的不是 Codex 记住了多少，而是关键规则有没有进入可复用的工作系统。
11. 提醒
- 不要为了追新功能，把 Codex 用复杂。
- 不要只关心别人的功能清单。
- 不要用“研究工具”代替真实产出。
- 参考资料有价值，但要翻译成自己的工作流。
- 文章有没有写出来、代码有没有跑通、原型有没有成形、判断有没有沉淀、下一步有没有变清楚，比“功能知道多少”更重要。
Codex 的核心不是聊天，是把模型、上下文、文件、工具、权限、外部系统和验收串起来。
12. 其他
Goals是否适合个人项目里的长任务？thread automation是否能做轻量回访。- 不能变成新的噪音源。
Memory / Chronicle哪些适合作辅助。- 哪些必须落到
whoami或AGENTS.md。
- 哪些必须落到
browser / computer-use在前端验收里到底能省多少事。- 什么流程值得写成
skill。- 什么只是一次性任务。
13. 相关来源
Codex为什么叫超级Agent：本篇教你学会它的12 个进阶玩法！
Getting the most out of Codex