最近我发现Claude+DeepSeek还是差点意思，就转到codex体验一下顶级模型。但是，习惯了终端中使用Claude code之后，打开codex之后，我竟然不知道怎么用！
相信很多朋友跟我一样，第一次打开 Codex，第一反应不是“哇，好强”，而是：
这东西到底从哪开始用？
它看起来像一个聊天软件，但又能读文件、改项目、开浏览器、装插件、跑命令、接 MCP。软件界面的左边是一堆入口，中间是对话，右边还会弹出文件、网页、预览、代码变化。
如果你是小白，很容易犯一个错误：
什么都没配置好，就直接让它干活。
最后不是文件乱飞，就是不知道产物放哪（我整理乱糟糟的文件，头都大了！大家一定注意一些）；不是插件装了一堆不会用，就是项目里没有任何规则，Codex 每次都要重新理解你。
所以这篇教程，只讲新手第一次真正上手时最需要配置的东西。
我们只解决一个问题：
一个 Windows 小白，怎么把 Codex 从“能聊天”，配置到“真的能做项目”。
看完这篇，你至少应该能完成三件事：
1. 知道 Codex 可以在哪些地方用。
2. 在 Windows 上建立一个适合 Codex 工作的项目文件夹。
3. 配好基础规则、插件、Skills，并跑通一个真实项目。
先说结论：新手第一次用 Codex，最该先配置的不是模型，而是项目文件夹。
## 一、先别急着提问：Codex 不是普通聊天框
如果你只把 Codex 当成 ChatGPT 的另一个入口，那它确实就是一个聊天框。
但 Codex 真正厉害的地方，不是“回答问题”，而是“直接进入项目文件，扮演你的工作助手帮你做事”。
它可以做这些事：
* 读取你指定的本地文件。
* 修改项目里的文档和代码。
* 运行终端命令。
* 打开网页查资料。
* 通过插件处理文档、表格、PPT。
* 用 Skills 按固定流程完成任务。
* 通过 MCP 连接外部工具。
* 在 IDE 或云端继续处理项目。
这也是为什么新手会懵。
普通聊天工具不会随便碰你的本地文件，但 Codex 会。普通聊天工具通常只给你答案，但 Codex 可能会真的帮你新建文件、改文件、生成项目、跑脚本。
能力越强，越需要边界。
所以小白要先建立一个最重要的意识：
不要一上来就问“Codex 能做什么”，先问“我准备让它在哪个项目里做事”。
项目位置选错了，后面全乱。
## 二、Codex 到底能在哪些地方用
截至 2026-05-16，OpenAI 官方资料里提到，Codex 可以在多个入口使用，比如 App、CLI、Web/Cloud、IDE extension 等。具体入口和按钮名称会更新，你以自己当前看到的界面为准。
小白先看这张表就够了：
| 使用方式 | 解释 | 适合谁 | 小白建议 |
| — | — | — | — |
| Codex App | 装在电脑上的 Codex 工作台 | 想管理本地项目的人 | 主推，从这里开始 |
| Codex Web / Cloud | 在网页或云端委托任务 | 想让任务离开本地持续跑的人 | 后面再学 |
| Codex CLI | 命令行里的 Codex | 会终端的人 | 小白先不用 |
| IDE / VS Code 扩展 | 在代码编辑器里用 Codex | 写代码、改网页、改项目的人 | 有项目后再用 |
| GitHub 里的 Codex | 在代码仓库里委托任务 | 管 GitHub 仓库的人 | 后期再学 |
这篇文章只重点讲一条路线：
Windows 上用 Codex App，把项目真正跑起来。
为什么不一上来讲 CLI、GitHub、云端？
因为小白最先要解决的不是“入口不够多”，而是“我到底该把文件放哪、规则怎么写、权限怎么给、结果怎么看”。
把本地 App 这条路跑通，后面去 VS Code、Cloud、GitHub 都会顺很多。
## 三、Windows 上怎么安装 Codex App
安装这件事本身不复杂，最重要的是别乱下载。
建议只从 OpenAI 官方入口下载：
`https://openai.com/codex/`
基本流程是：
1. 打开官方入口。
2. 下载 Windows 版 Codex App。
3. 按提示安装。
4. 打开 Codex。
5. 用 ChatGPT / OpenAI 账号登录。
如果你已经习惯用 Windows 终端，也可以用官方文档提到的`winget`方式安装。先打开 PowerShell，再执行：
`winget install Codex -s msstore`
如果你后面要让 Codex 改网页、跑脚本、处理代码项目，建议顺手装几个常用工具。OpenAI Windows 文档也提到，Git、Node.js、Python 这类开发工具会让 Codex 做项目更顺。
可以先装这三个：
`winget install –id Git.Gitwinget install –id OpenJS.NodeJS.LTSwinget install –id Python.Python.3.14`
装完以后，重启 Codex App 或重新打开终端，再让 Codex 检查：
`git –versionnode –versionpython –version`
如果你只是体验，优先用账号登录，不要一上来研究 API Key。
免费账号能不能用，要看当时官方开放策略和额度。长期使用，通常还是建议至少准备 Plus 或更高套餐。因为 Codex 一旦进入项目、读文件、改文件、跑长任务，消耗会比普通聊天更明显。
小白成功标志：
* 你已经能打开 Codex App。
* 你已经登录账号。
* 你能新建一个普通对话。
* 你能看到项目或类似项目入口。
到这里，先别急着让它改文件。
先做设置。
## 四、第一次打开后，先做 5 个基础设置
Codex 的设置会随着版本变化，但小白可以先关注 5 类设置。
你不需要把每个按钮都研究透。先把最影响使用体验和安全边界的地方搞清楚。
### 1. 语言和回答风格：先让它按小白方式说话
如果 Codex 支持个性化、自定义说明、偏好设置之类的入口，可以先写一段固定说明。
你可以直接复制这一段：
`请默认用中文回答。如果涉及代码或命令，请先用大白话解释目的，再给具体操作。如果要修改文件、运行命令、访问外部账号，请先告诉我风险。教程类内容请写成小白能照着做的步骤，并标注每一步的成功标志。如果我的需求信息不完整，请先问我缺什么，不要直接编。`
这段话的作用很大。
它不是让 Codex 变强，而是让 Codex 更适合你。
小白最怕的不是 AI 不会做，而是它一上来就抛术语、跑命令、改文件，你完全不知道发生了什么。
### 2. 权限：不要一上来开放整个硬盘
Codex 会请求权限，比如读文件、改文件、运行命令、访问网页、连接账号。
新手最容易犯的错误是：看到确认按钮就点。
不要这样。
第一次使用，建议只给当前项目文件夹权限。
比如你要做网页工具项目，就只让 Codex 访问这个项目目录：
`D:codex_projects_by_jack网页工具项目`
不要一上来给：
`C:D:整个用户目录下载目录个人文件夹桌面全部文件`
如果看不懂权限请求，就直接问 Codex：
`请用小白能懂的话解释：你现在请求的权限会访问什么？为什么这个任务需要它？有没有更低风险的做法？`
### 3. 发送方式：避免写长需求时误发送
如果设置里有“Enter 发送”或“组合键发送”之类的选项，建议新手选择不容易误触的方式。
因为你后面写项目需求时，经常会写很长：
* 项目目标。
* 输出格式。
* 不要做什么。
* 目录结构。
* 验证方式。
如果写一半按回车就发出去了，Codex 可能会拿着半截需求开始干活。（我吃了很多次亏才想起来要设置一下）
### 4. 模型和推理强度：先默认，复杂任务再提高
小白不需要一上来研究每个模型。
建议：
* 普通问答：默认即可。
* 长文写作：用更强模型或更高推理。
* 代码修改、复杂项目：用更强模型或更高推理。
* 简单格式整理：不用开太高。
一句话：
小任务别浪费额度，大任务别省过头。
### 5. 自动化先别急
自动化听起来很诱人：
* 每天自动总结。
* 每周自动检查。
* 定时抓资料。
* 到点继续写文章。
但新手别急。
先把手动流程跑通，再自动化。
如果你手动都没说清楚“输入是什么、输出到哪里、失败怎么办”，自动化只会把混乱定时重复一遍。
## 五、真正开始前，先建一个项目根目录
这一步是全文最重要的地方。
小白用 Codex，第一件事不是装插件，而是建立项目根目录。
你可以建一个这样的文件夹：
`D:codex_projects_by_jack`
或者更简单：
`D:codex_projects`
这个目录以后专门放 Codex 项目。
不要把项目直接放在：
* 桌面。
* 下载目录。
* 聊天软件接收文件夹。
* 笔记库内部。
* 同步盘里随手建的杂乱目录。
* 系统盘乱七八糟的位置。
为什么？
因为 Codex 会读文件、写文件、生成中间数据、跑脚本。
例如，如果你把项目塞进日常笔记库，它可能把一堆日志、配置、代码、缓存都放进去。笔记库就被污染了。
如果你把项目放桌面，时间久了你会分不清哪些是成品、哪些是临时文件。
如果你把项目散在下载目录，三个月后你自己都找不到。
所以先建一个干净的项目根目录。
如果你会打开 PowerShell，可以直接复制这条命令：
`New-Item -ItemType Directory -Path “D:codex_projects_by_jack” -Force`
这条命令的意思是：在 D 盘创建一个叫`codex_projects_by_jack`的文件夹；如果它已经存在，就不重复创建，也不会报错。
小白成功标志：
`D:codex_projects_by_jack`
下面只放项目，不放随手下载的东西。
## 六、第一个项目文件夹应该长什么样
有了项目根目录，每个新项目再建一个独立文件夹。
比如：
`D:codex_projects_by_jack项目1D:codex_projects_by_jack项目2D:codex_projects_by_jack项目3`
新项目推荐结构：
`我的第一个Codex项目/ README.md AgentS.md CONTEXT.md docs/ src/ scripts/ data/ raw/ processed/ export/ assets/ logs/ tmp/`
如果你想一次性建好这些文件夹，可以在 PowerShell 里执行：
`$project = “D:codex_projects_by_jack我的第一个Codex项目”New-Item -ItemType Directory -Path $project -ForceNew-Item -ItemType Directory -Path “$projectdocs”,”$projectsrc”,”$projectscripts”,”$projectdataraw”,”$projectdataprocessed”,”$projectdataexport”,”$projectassets”,”$projectlogs”,”$projecttmp” -ForceNew-Item -ItemType File -Path “$projectREADME.md”,”$projectAGENTS.md”,”$projectCONTEXT.md” -Force`
执行完之后，你应该能在资源管理器里看到这个项目文件夹。
你不一定每个目录一开始都用得上，但先知道它们干什么。
| 文件/目录 | 大白话解释 |
| — | — |
| README.md | 给人看的项目说明 |
| AGENTS.md | 给 Codex 看的工作规则 |
| CONTEXT.md | 给 Codex 看的业务背景 |
| docs/ | 长期说明、方案、运行手册 |
| src/ | 正式代码 |
| scripts/ | 采集、清洗、维护脚本 |
| data/raw/ | 原始数据，不要乱改 |
| data/processed/ | 处理后的中间结果 |
| data/export/ | 最终导出成果 |
| assets/ | 图片、模板、素材 |
| logs/ | 运行日志 |
| tmp/ | 临时文件 |
如果你不是程序员，也不用怕`src`、`scripts`这些词。
它们只是帮你把项目分区。
真正关键的是三个文件：
`README.mdAGENTS.mdCONTEXT.md`
这三个文件写好，Codex 就不会每次都像第一次见你。
## 七、README.md 怎么写：让未来的你也能看懂
`README.md`是给人看的。
不是写给 AI 炫技的，是写给未来的你。
一个最简单的 README 可以这样写：
`# 项目名称这个项目用于：## 快速开始1. 把原始素材放到 data/raw/2. 运行脚本或让 Codex 处理3. 最终结果输出到 data/export/## 目录说明- docs/：说明文档- data/raw/：原始数据- data/export/：最终结果- logs/：运行日志## 常用命令暂无。## 注意事项- 不要删除 data/raw/- 不要把真实密钥写进文档`
README 的目的不是漂亮，而是让你下次打开项目时知道：
这项目是什么，怎么用，文件放哪。
## 八、AGENTS.md 怎么写：让 Codex 不再每次重新理解你
`AGENTS.md`是给 Codex 看的。
你可以把它理解成“项目里的工作规则”。
它告诉 Codex：
* 这个项目目标是什么。
* 哪些文件不能动。
* 修改前要不要先说明。
* 修改后怎么验证。
* 输出应该放在哪里。
小白可以先写一个很短的版本：
`# 项目协作规则## 项目目标这个项目用于：## 不要改动- 不要删除 data/raw/。- 不要展示 .env 中的真实密钥。- 不要把临时文件放到项目根目录。## 工作方式- 修改前先说明准备改什么。- 修改后做最小验证。- 如果新增运行方式，同步更新 README.md。## 常用命令- 启动：- 验证：`
很多人第一次用 Codex，项目体验不好，不是因为模型不行，而是因为项目没有规则。
你每次都临时告诉它“不要删这个”“输出放那里”“先问我再改”，当然累。
写进`AGENTS.md`，就是把这些长期规则固定下来。
注意，这里只写 Codex 自己会读取、会影响当前项目协作方式的规则文件。其他工具的专属规则文件，不放进这篇文章里展开。
## 九、CONTEXT.md 怎么写：让 Codex 知道业务背景
`AGENTS.md`管“怎么工作”。
`CONTEXT.md`管“这个项目是什么”。
比如你做一个 AI 工具资料整理项目，Codex 需要知道：
* 这个项目要整理什么资料。
* 目标读者是谁。
* 原始链接放在哪里。
* 体验记录放在哪里。
* 最终报告放在哪里。
* 哪些信息不能编造。
可以这样写：
`# 项目上下文## 一句话说明这个项目用于整理 AI 工具资料，把零散链接、使用记录和测试结果整理成可读的 Markdown 报告。## 目标读者- 想选择 AI 工具的普通用户- 想提高效率的办公人群- 不想看一堆官网宣传语的人## 输入- 工具链接- 网页摘录- 使用体验- 截图描述- 价格、平台和限制信息## 输出- 工具对比表- 每个工具的优缺点- 适合场景- 不适合场景- 最终选择建议## 写作要求- 不写空泛宣传。- 不确定的信息标注“待核实”。- 多写真实任务和使用场景。- 不要编造工具功能、价格和亲测体验。## 当前状态正在搭建 AI 工具资料整理流程。`
你看，这些信息如果不写，Codex 也能写，但很容易写偏。
写了之后，它就知道你不是要一篇泛泛而谈的介绍，而是要一份“普通用户今天就能拿来做选择”的资料整理报告。
## 十、插件怎么理解：给 Codex 装能力包
现在来说插件。
小白最容易把 Plugin、Connector、Skill、MCP 混在一起。
先别纠结技术定义，看这张表：
| 名词 | 小白理解 | 什么时候用 |
| — | — | — |
| Plugin 插件 | 给 Codex 装能力包 | 做表格、PPT、文档、浏览器操作 |
| Connector 连接器 | 连接外部账号 | Gmail、GitHub、Google Drive |
| Skill 技能 | 工作流说明书 | 固定写作流程、项目规范、测评流程 |
| MCP | 外部工具通道 | 连接更专业的本地或远程工具 |
你刚开始不需要全懂。
记住一个顺序：
`先用 App 自带能力→ 不够再装插件→ 重复任务沉淀成 Skill→ 特殊工具再考虑 MCP`
不要一上来装一堆插件。
插件不是越多越强，而是越明确越好。
比如：
* 你要做 PPT，再考虑 Presentations。
* 你要处理 Excel，再考虑 Spreadsheets。
* 你要读写 Google Drive，再考虑 Google Drive Connector。
* 你要操作浏览器，再考虑 Browser 或 Chrome 相关能力。
每次只为一个明确任务装一个插件。
## 十一、Skills 怎么用：不是魔法，是工作流说明书
Skill 很容易被说玄。
其实它最适合小白理解成：
一套固定工作流说明书。
比如你经常让 Codex 整理工具资料，每次都要说：
* 先问我缺什么信息。
* 再判断哪些资料已经够用。
* 再整理资料。
* 再生成对比表。
* 再写 Markdown 报告。
* 最后检查哪些信息还需要核实。
你每次都打一遍，很麻烦。
那就可以把它写成一个 Skill 或项目内流程文件。
以后你只要说：
`请按 AI 工具资料整理流程处理这个任务。`
Codex 就知道要先问信息缺口，而不是上来就生成最终报告。
Skill 适合这些任务：
* 新项目初始化。
* PPT 生成流程。
* 文档审校流程。
* 数据清洗流程。
小白先不需要自己写复杂 Skill。
你可以先在项目里建一个`workflow.md`，把流程写清楚。等你反复用很多次，再考虑沉淀成正式 Skill。
比如 AI 工具资料整理项目里，可以先建：
`D:codex_projects_by_jackAI工具资料整理workflow.md`
然后写一条很简单的流程：
`# AI 工具资料整理流程1. 先判断信息是否完整。2. 信息不完整时，先问 3-7 个问题。3. 再整理资料。4. 再生成工具对比表。5. 再写 Markdown 报告。6. 最后检查事实风险和待核实信息。`
以后你就可以对 Codex 说：
`请读取 workflow.md，并按这个流程整理 inputtools.md。`
## 十二、MCP 怎么理解：小白先知道，不必急着装
MCP 是 Model Context Protocol。
这名字听起来很吓人。
小白可以先这样理解：
MCP 是让 Codex 连接外部工具或外部资料的一种通道。
比如 OpenAI 官方有开发者文档 MCP，可以让 Codex 在 CLI 或 IDE extension 里读取 OpenAI 相关文档。官方文档里也给了添加和验证的命令。
如果你只是想知道“命令长什么样”，可以先看这个例子：
`codex mcp add openaiDeveloperDocs –url https://developers.openai.com/mcpcodex mcp list`
第一行是添加 OpenAI 开发者文档 MCP，第二行是查看当前 MCP 列表。
如果你是在 VS Code 里配置，也可以在项目根目录新建：
`.vscodemcp.json`
内容示例：
`{“servers”:{“openaiDeveloperDocs”:{“type”:”http”,”url”:”https://developers.openai.com/mcp”}}}`
但注意：如果你还没装 Codex CLI，或者看不懂 MCP 配置文件，就先不要急着执行。小白阶段知道它的用途，比立刻装上更重要。
但对大多数小白来说，前期不用急着配 MCP。
为什么？
因为你一开始最需要的是：
* 建好项目文件夹。
* 写好 README。
* 写好 AGENTS。
* 写好 CONTEXT。
* 学会看权限。
* 学会让 Codex 解释它做了什么。
这些都不需要 MCP。
所以小白顺序还是那句：
`插件优先，Skill 其次，MCP 最后。`
什么时候再研究 MCP？
* 你明确知道要接哪个工具。
* 官方插件满足不了。
* 你需要在 VS Code / CLI 里接入某个资料源。
* 你能看懂基本配置文件。
## 十三、Chrome / 浏览器到底能不能用
这个问题要分清三层。
第一层：Codex App 里的浏览器能力。
它可以打开网页、查看页面、搜索资料、测试本地网页。有些时候右侧会出现网页预览或浏览器界面。
第二层：Browser / Chrome 相关插件或能力。
如果你的 Codex 环境里有 Browser 或 Chrome 相关插件，它可能可以操作浏览器页面，甚至使用你已经登录的账号状态。具体能力取决于你当前安装和授权的插件。
第三层：真实账号操作风险。
这才是小白最该注意的。
浏览器能力很强，但不要第一次就让它操作：
* 聊天软件。
* 支付页面。
* 内容发布后台。
* 电商后台。
* 公司系统。
* 会删除、发布、付款的页面。
第一次练习，可以让它做低风险任务：
`打开一个公开网页，帮我总结页面结构。`
或者：
`打开我本地生成的网页，检查按钮有没有重叠。`
成功标志：
* Codex 能打开或查看页面。
* 它没有进行付款、发布、删除等高风险动作。
* 它能告诉你它看到了什么。
## 十四、VS Code 里怎么用 Codex
如果你完全不写代码，先不用急着打开 VS Code。
Codex App 已经足够你做：
* 写文章。
* 整理资料。
* 做文档。
* 处理表格。
* 生成 PPT。
* 管理项目。
那什么时候需要 VS Code？
当你开始让 Codex 做这些事：
* 改网页。
* 写脚本。
* 改代码项目。
* 做插件。
* 改复杂配置。
* 看很多文件之间的关系。
VS Code 更像代码项目的工作现场。
Codex App 更像项目管理和多任务工作台。
两者可以服务同一个项目文件夹。
比如你的项目在：
`D:codex_projects_by_jack我的第一个Codex项目`
你可以：
1. 用 Codex App 打开这个项目，让它理解需求。
2. 用 VS Code 打开同一个文件夹，看文件结构。
3. 如果你安装了官方 Codex IDE extension，就可以在 VS Code 里继续让 Codex 辅助修改。
如果你已经安装 VS Code，也可以用命令打开项目：
`code “D:codex_projects_by_jack我的第一个Codex项目”`
如果这条命令提示`code`不存在，说明 VS Code 的命令行入口还没配置。小白不用纠结，直接在 VS Code 里点：
`File→ Open Folder→ 选择 D:codex_projects_by_jack我的第一个Codex项目`
小白路线：
`先用 Codex App→ 项目变复杂后，再用 VS Code 打开同一文件夹→ 真要改代码，再研究 IDE extension`
不要为了“看起来专业”一上来就进 VS Code。
工具是为任务服务的。
## 十五、跑通第一个真实项目
现在我们来跑一个最小真实项目。
不要一上来做复杂网站。
我们用一个“AI 工具资料整理项目”举例。
这个项目很适合新手练手。
它不涉及真实账号，也不需要连接复杂后台。你只要准备几个工具链接、几段使用记录，Codex 就能帮你整理成对比表、使用建议和 Markdown 报告。
这类项目的好处是：
* 文件结构简单。
* 不需要写很多代码。
* 能练习项目目录、规则文件、资料输入、结果输出。
* 做完之后真的有用。
### 第一步：建项目文件夹
在你的项目根目录下建：
`D:codex_projects_by_jackAI工具资料整理`
里面建这些目录：
`AI工具资料整理/ README.md AGENTS.md CONTEXT.md input/ notes/ output/ logs/ tmp/`
可以直接用 PowerShell 一次建好：
`$project = “D:codex_projects_by_jackAI工具资料整理”New-Item -ItemType Directory -Path $project -ForceNew-Item -ItemType Directory -Path “$projectinput”,”$projectnotes”,”$projectoutput”,”$projectlogs”,”$projecttmp” -ForceNew-Item -ItemType File -Path “$projectREADME.md”,”$projectAGENTS.md”,”$projectCONTEXT.md” -Force`
这几行命令做了三件事：
* 创建项目主文件夹。
* 创建输入、笔记、输出、日志、临时文件目录。
* 创建`README.md`、`AGENTS.md`、`CONTEXT.md`三个关键文件。
如果你不想用命令，也可以手动新建。效果一样。
### 第二步：写 README.md
`# AI 工具资料整理这个项目用于整理 AI 工具资料，把零散链接、笔记和测试结果整理成可读的 Markdown 报告。## 目录- input/：原始链接、网页摘录、截图说明- notes/：手动记录的使用体验- output/：Codex 整理后的报告- logs/：处理记录- tmp/：临时文件## 使用方式1. 把工具链接和原始材料放到 input/2. 把自己的体验记录放到 notes/3. 让 Codex 读取项目规则并整理4. 最终报告输出到 output/`
### 第三步：写 AGENTS.md
`# 项目协作规则## 项目目标帮助我把 AI 工具资料整理成结构清晰、可复用的 Markdown 报告。## 工作方式- 先读取 README.md、AGENTS.md、CONTEXT.md。- 信息不完整时，先问我缺什么。- 不要编造工具功能、价格、链接和使用体验。- 不确定的信息标注为“待核实”。- 输出报告放到 output/。- 临时分析放到 tmp/。## 禁止事项- 不要删除 input/ 和 notes/ 里的原始材料。- 不要泄露任何账号、Cookie、API Key 或私人文件路径。- 不要把未验证的信息写成确定结论。`
### 第四步：写 CONTEXT.md
`# 项目上下文## 项目用途把多个 AI 工具的资料整理成一份普通用户能看懂的对比报告。## 目标读者- 想选择 AI 工具的普通用户- 想提高效率的办公人群- 不想看一堆官网宣传语的人## 整理要求- 先说这个工具解决什么问题。- 再说适合谁、不适合谁。- 如果有价格、平台、限制，要单独列出。- 不确定的信息不要猜，标注“待核实”。- 最后给出场景化选择建议。## 输出要求- 工具对比表- 每个工具的优缺点- 适合场景- 不适合场景- 最终选择建议`
### 第五步：放入一份原始资料
比如放到：
`inputtools.md`
这个文件可以很简单，像这样：
`# 待整理工具## 工具 A官网：我知道的信息：-## 工具 B官网：我知道的信息：-## 工具 C官网：我知道的信息：-`
如果你已经有一份资料，可以复制到这个目录。命令示例：
`Copy-Item-LiteralPath”D:你的原始资料tools.md”-Destination”D:codex_projects_by_jackAI工具资料整理inputtools.md”`
看不懂也没关系，手动复制文件也完全可以。
### 第六步：让 Codex 开始工作
你可以这样说：
`请先阅读 README.md、AGENTS.md、CONTEXT.md。然后读取 inputtools.md。按项目规则，先告诉我这份资料还缺哪些信息，不要直接生成最终报告。`
这句话很重要。
它会强制 Codex 先做信息补全，而不是一上来生成一份看似完整、其实很多地方靠猜的报告。
等它问完缺口，你再补一句：
`请基于已确认资料，生成一份 Markdown 报告，放到 outputAI工具对比报告.md。报告里必须包含：工具对比表、适合谁、不适合谁、使用门槛、最终选择建议。不确定的信息请标注“待核实”。`
成功标志：
* Codex 能读到你的项目文件。
* Codex 会先问你缺什么。
* 它不会编造工具功能或使用体验。
* 它知道输出应该放到哪里。
* `output/`里出现一份结构清晰的 Markdown 报告。
这就叫项目开始跑起来了。
## 十六、小白最容易踩的 10 个坑
### 1. 没建项目文件夹就开始干活
结果就是文件到处飞。
先建项目，再开始。
### 2. 把项目放进日常笔记库或同步盘
如果只是普通 Markdown 笔记，放进去没问题。
但如果这个项目会运行脚本、生成数据、下载文件、写日志，最好单独放到项目目录。
否则几天后你会发现，笔记、缓存、日志、临时文件混在一起，很难收拾。
### 3. 没写 AGENTS.md
Codex 每次都要重新猜你想怎么工作。
### 4. 没写 CONTEXT.md
Codex 不知道项目背景、目标用户、输出格式和边界条件。
### 5. 看到权限确认就点
这是最危险的习惯。
不懂就问它解释。
### 6. 插件装太多
插件不是越多越好。
先明确任务，再装插件。
### 7. 把 API Key 写进 Markdown
不要把密钥、Cookie、密码写进 README、AGENTS、CONTEXT。
真实配置放`.env`，并且不要公开。
### 8. 不看右侧文件变化
Codex 改了什么文件，你要看。
看不懂就让它解释：
`请按文件逐个解释这次改动，用非程序员能懂的话说。`
### 9. 结果不满意就重开
不要动不动重开。
直接让它基于现有结果改：
`保留现在结构，但把每个工具的适合场景写得更具体，并补充“不适合谁”。`
### 10. 不做最小验证
每次完成后，至少问一句：
`请告诉我这次怎么验证结果是成功的。`
## 十七、Codex 小白启动检查清单
最后给你一张清单。
第一次用 Codex，照着勾就行。
`## Codex 小白启动检查清单- [ ] 我已经从官方入口安装 Codex。- [ ] 我知道 Codex App、Web、CLI、VS Code 大概区别。- [ ] 我有一个独立项目根目录。- [ ] 我每个项目都有单独文件夹。- [ ] 项目里有 README.md。- [ ] 项目里有 AGENTS.md。- [ ] 项目里有 CONTEXT.md。- [ ] 我知道插件、Skill、MCP 的区别。- [ ] 我不会随便授权整个硬盘。- [ ] 我知道输出文件应该放在哪里。- [ ] 我会让 Codex 先问缺什么，而不是直接编。- [ ] 我会让 Codex 解释它改了什么。`
如果这张清单你都能勾上，恭喜你，你已经不是“打开 Codex 只会聊天”的小白了。
你已经开始把它当成一个真正的项目助手。
## 结语
Codex 最容易被低估的地方，不是它会不会写代码。
而是它能不能进入你的真实工作流。
对小白来说，真正的分水岭不是会不会写提示词，而是有没有建立项目意识。
你有一个干净的项目根目录。
你知道每个项目都有独立文件夹。
你知道 README 给人看，AGENTS 给 Codex 看，CONTEXT 给项目背景。
你知道插件不是乱装，Skill 是工作流，MCP 是进阶工具通道。
你知道权限要谨慎，结果要验证，文件变化要看。
到了这一步，Codex 就不再只是一个聊天框。
它会慢慢变成你电脑里的工作台。
先别急着追求高级玩法。
先把第一个项目跑通。
从一个干净的文件夹开始。
## 事实核查备注
本文涉及 Codex 支持平台、App、IDE extension、MCP 等内容，基于 2026-05-16 前后 OpenAI 官方公开资料和当前 Codex App 使用经验整理。Codex 更新很快，具体按钮名称、插件入口和可用功能以你当前账号和官方界面为准。
