如果你第一次打开 Codex，最容易卡住的地方，通常不是安装。
是你不知道它到底该被放在工作流里的哪个位置。
我现在更愿意把 Codex 理解成一个 AI 工作台：它可以围绕一个本地项目读文件、改文件、跑命令、看网页、接插件、记规则、做检查，还能把重复流程沉淀成 Skill 或自动化任务。
这篇不是某一个功能教程。
它更像一张新手地图。
看完以后，你不一定马上精通 Codex 的每个按钮，但至少会知道：
- 第一次打开应该先建什么。
- 一个任务应该放在哪个 Project 和 Thread 里。
- 什么时候用 Plan Mode，什么时候用 Goal Mode。
- 本地文件、插件、MCP、Browser、Chrome、Computer Use 分别解决什么问题。
- 哪些流程值得做成 Skill 或 Automation。
普通人用 Codex，最重要的不是一上来研究所有功能。
先跑通一条小工作流。
比如：把一堆旅行资料整理成网页；把 KOL 表格清洗成跟进名单；把 Obsidian 素材整理成 X 长文结构；每天定时生成一份选题简报。
跑通一次，你就知道 Codex 不是“问一句答一句”的 AI。
它可以接走一段完整工作。
Codex 的 6 层能力地图
新手不要从按钮开始学。
先看地图。
Codex 大概可以分成 6 层：
工作区 |
- Project、Thread、Local、Worktree、Cloud |
- 让任务有边界，不把上下文搅成一锅
规则层
- Permissions、Memories、AGENTS.md
- 让 Codex 知道能做什么、不能做什么、你偏好什么
执行层
- 普通对话、Plan Mode、Goal Mode
- 决定它是回答、规划，还是持续推进
资料入口
- 本地文件、Plugins、MCP、Obsidian
- 决定 Codex 去哪里拿资料
验证操作
- Browser、Chrome、Computer Use、Git、Terminal
- 让它检查真实结果，不只停在生成文本
复用层
- Skills、Automations
- 把跑通过的流程保存下来，下次少说废话
这6 层能力比任何 prompt 都重要。
因为很多人用 Codex 很累，不是因为不会写提示词，而是把所有任务都丢进同一个聊天框里。
你让它今天写文章，明天整理表格，后天改网页，全部挤在一起。上下文越来越脏，它当然越来越像在乱猜。
正确顺序应该是：
先给任务找一个工作区。
再告诉它规则。
然后选择执行模式。
接着给它资料入口。
最后让它检查结果，并把好用流程留下来。
工作区：先把任务放对地方
Codex 里的 Project，可以理解成一个工作台。
你给它一个本地文件夹，它就围绕这个文件夹读写文件、生成结果、保留上下文。官方也把 Codex app 描述成一个按 project 组织、可以并行跑 threads 的桌面体验。
普通人可以这样建项目：
- X 内容创作
- KOL 数据库
- 客户资料整理
- 旅行计划
- 个人知识库
- 本地网页小工具
同一个方向放一个 Project。
同一个 Project 里，每件具体任务开一条 Thread。
比如「X 内容创作」里可以有这些线程：选题监控、长文改稿、短推生成、Obsidian 素材整理。
这样项目共享同一个文件夹，但任务上下文不会互相污染。
新开 Thread 时，你可能还会看到 Local、Worktree、Cloud 这几个模式。
简单理解：
- Local：直接在当前项目文件夹里工作，适合整理资料、写文章、做小工具。
- Worktree：给同一个 Git 项目开一个隔离副本，适合试新功能，不影响原目录。
- Cloud：放到远程环境里跑，适合更长、更重、可以异步处理的任务。
新手先用 Local 就够了。
等你开始让 Codex 改代码、并行试方案，或者不想影响当前项目，再考虑 Worktree。
规则层：先让它少问废话
很多人第一次用 Codex，会直接开始聊天。
可以，但不够省心。
如果你想长期用，先把三类规则想清楚：权限、记忆、项目指令。
权限决定它能不能改文件、跑命令、访问网络。新手可以保守一点：允许读取和修改当前项目文件夹，但删除、移动、覆盖原文件前要先问。
记忆适合放长期稳定偏好。
比如你写 X 长文，偏好可能是：开头先打痛点，不要报告式铺垫；案例贴近日常；不要编造数据；先给结构，再写全文。
项目指令最常见的形式是 AGENTS.md。
你可以把它理解成写给 Codex 的项目说明书。以后它进这个项目，先看这份规则。
比如一个内容项目的 AGENTS.md 可以写：
这个项目用于 X 内容创作。
写文章前先读取相关素材。
不要编造来源、数据和案例。
输出长文时保留真实口语感，少用报告腔。
如果只是改稿，不要擅自换主题。
所有结果先保存为 Markdown，不要自动发布。
这类规则看着普通，但会省掉大量重复解释。
你不用每次都说“不要 AI 味”“不要编造”“先给结构”。
这些东西应该变成默认设置。
执行层：普通对话、Plan 和 Goal
Codex 不是所有任务都应该用同一种模式。
普通对话适合小问题。
比如改一段话、解释一个概念、整理一个清单。
Plan Mode 适合不确定的任务。
比如你想做一个 X 选题看板，但还没想清楚字段、页面、数据存储、后续使用方式。这个时候先开 Plan，让 Codex 问问题、拆方案、列风险，确认后再动手。
Goal Mode 适合已经有明确终点的任务。
比如你要它把一个文件夹里的素材整理成一篇 X 长文，成功标准是：读完素材、整理结构、写正文、自查事实风险、保存文件。这个时候给它目标和完成标准，它可以持续推进。
官方 commands 文档里也写得很清楚：/plan 用于多步骤规划，/goal 用于设置一个持续目标；如果想先定义清楚目标，可以先用 /plan，再用 /goal。
新手可以先记这组判断：
- 不确定怎么做：用 Plan。
- 知道要什么结果：用 Goal。
- 只是问一句：普通对话就行。
一条比较稳的起步提示词：
请先进入 Plan Mode，不要直接执行。
目标：我想用 Codex 跑通一个真实小任务。
任务是：把当前项目里的素材整理成一篇 X 长文草稿。
请你先帮我确认：
1. 需要读取哪些文件
2. 输出应该是什么格式
3. 哪些地方可能需要我补充信息
4. 执行步骤是什么
5. 怎样算完成
我确认后，再开始执行。
这个 prompt 不花哨，但够稳。
它让 Codex 先当项目经理，再当执行者。
资料入口决定上下文质量
AI 写得泛，很多时候不是模型不行。
是它根本没看到你的资料。
Codex 的资料入口大概有三类。
第一类是本地文件。
把 Markdown、Excel、CSV、PDF 转出来的文本、图片说明、项目文档放进 Project，Codex 就可以围绕这些资料工作。
比如：读取一堆 KOL 表格，整理优先联系名单；读取 Obsidian 素材，生成 X 长文结构；读取会议纪要，提炼客户下一步诉求。
第二类是 Plugins。
插件让 Codex 连接 Gmail、Google Drive、GitHub 等工具。适合你不想手动复制资料的场景。
比如让它从 Gmail 里筛出需要回复的合作邮件，只生成草稿，不自动发送。
第三类是 MCP。
MCP 更像是给 Codex 接一个外部资料源或工具。Obsidian 就是典型场景：你把知识库接进去，Codex 才能读到你长期积累的素材、复盘、语气样本。
这三类入口不要混着理解。
本地文件解决“当前项目里有什么”。
插件解决“常用工具里有什么”。
MCP 解决“我的长期知识库和外部系统里有什么”。
如果你是内容创作者，最值得先打通的是 Obsidian 或本地素材库。
如果你做商务、运营、KOL 跟进，最值得先打通的是表格、Gmail、Google Drive。
验证和操作不能省
很多人只会让 Codex 生成，不会让它检查。
这一步很亏。
Codex 真正省心的地方，是它可以把结果拿去验证。
做网页，就让它用 Browser 打开页面，检查按钮、布局、移动端显示、控制台错误。
需要登录状态的网站，可以考虑 Chrome extension。比如你已经登录了后台，让 Codex 看页面、整理信息，但不要提交表单或修改数据。
必须操作桌面软件时，才考虑 Computer Use。官方文档里写到，Computer Use 可以让 Codex 查看并操作 macOS 或 Windows 的图形界面，适合命令行和结构化集成不够用的场景。这里权限要更谨慎：涉及登录、付款、删除、提交，都要停下来让你确认。
还有 Git 和 Terminal。
如果是代码项目，Codex app 有 diff、评论、提交、PR 相关能力，也有项目内终端。终端适合跑测试、看日志、启动本地服务。新手不懂命令也没关系，可以让 Codex 解释它准备跑什么，再确认。
任何任务后面都可以加一句自查：
完成后请自己检查一遍：
结果文件是否生成？
数据是否完整？
有没有重复项或空字段？
网页能不能打开？
输出是否符合我一开始的要求？
不确定的地方请单独列出来。
这句话很朴素，但非常有用。
它会逼 Codex 从“生成者”切到“质检员”。
复用层：跑通一次就沉淀下来
如果一个流程你重复做了三次，就应该考虑保存下来。
在 Codex 里，常见的复用方式有两个：Skills 和 Automations。
Skill 是流程 SOP。
比如你经常做 X 长文，就可以把“读取素材、提炼主题、生成结构、写正文、自查事实、保存 Markdown”做成一个 Skill。下次给它素材，它就按你的流程走。
Automation 是定时任务。
比如每天早上整理 AI / Codex / MCP 更新；每周五汇总 Obsidian 新增素材；每周一检查 KOL 跟进表，列出需要追问的人。
官方文档里也提到，Skills 可以和 Automations 组合，用来处理例行任务。
新手要注意一点：
不要一上来就自动化。
先手动跑通一次。
确认输出稳定、边界清楚、风险可控，再做 Automation。
尤其是邮件、发布、删除文件、改后台数据这类任务，自动化只做草稿和清单，不要直接执行最终动作。
第一次使用的稳妥路线
你不用一次学完所有功能。
第一次用 Codex，我建议按这条路线走：
- 建一个 Project，比如「X 内容创作」或「资料整理」。
- 新开一个 Thread，只处理一个具体任务。
- 写清楚边界：不要删除原始文件，不要自动发布，不确定先问。
- 用 Plan Mode 让它先拆方案。
- 确认方案后让它执行。
- 完成后让它自查。
- 如果结果满意，把流程整理成 Skill。
- 如果以后要定期做，再考虑 Automation。
拿内容创作者举例：
你可以先把 Obsidian 里几篇 Codex 素材放进一个 Project。
然后让 Codex 先规划一篇 X 长文结构。
确认结构后，再让它写正文。
写完后，让它检查有没有编造、有没有跑题、是否适合 X 发布。
如果这套流程好用，就做成「X 长文写作 Skill」。
下次你只需要给素材，不用重新解释一遍写作偏好。
拿资料整理举例：
你可以把一份客户表格或 KOL 表格放进 Project。
让 Codex 清洗字段、找重复、标记缺失信息、生成优先级清单。
最后输出一份 clean 表格和一份 Markdown 报告。
这比你自己在 Excel 里慢慢筛，要舒服很多。
哪些功能先别急着碰
全景图还有一个作用：告诉你哪些东西不用一开始碰。
新手先别急着研究：
- 复杂 CLI 配置。
- 多仓库 Worktree 并行。
- 高风险 Computer Use 自动操作。
- 一上来就做全自动发布。
- 还没跑通过的流程直接 Automation。
这些不是不能用。
只是没必要第一天就用。
普通人最先获得收益的地方，通常是三类任务：
- 资料整理：文件、表格、会议纪要、邮件。
- 内容生产：选题、长文、短推、素材库。
- 小工具原型：旅行计划、用药提醒、跟进看板、预算表。
先从这里开始。
小而真实，最容易建立手感。
最后记住这张图
如果你只想记一版最短的：
Project 管上下文。
Thread 管任务边界。
AGENTS.md 管长期规则。
Plan Mode 管路线。
Goal Mode 管推进。
Files、Plugins、MCP 管资料入口。
Browser、Chrome、Computer Use 管真实世界检查。
Skills 管流程复用。
Automations 管定时执行。
第一次打开 Codex，不要急着问“它有哪些功能”。
先问自己：
我今天有没有一个重复、琐碎、但确实会消耗我的任务？
有的话，把它放进一个 Project，开一条 Thread，用 Plan Mode 先拆清楚，再让 Codex 执行和自查。
这条路跑通以后，后面的功能名就不再抽象了。
你会知道它们分别该放在哪里。
这才是普通人入门 Codex 最重要的全景图。
