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