微信扫码
添加专属顾问
我要投稿
Codex不仅是聊天工具,更是能直接读写文件、运行命令的项目助手。本教程将手把手教你从零配置,让Codex真正成为你的开发伙伴。 核心内容: 1. Codex的核心能力与新手常见误区 2. 项目文件夹的建立与关键配置步骤 3. 通过一个真实项目跑通全流程
最近我发现Claude+DeepSeek还是差点意思,就转到codex体验一下顶级模型。但是,习惯了终端中使用Claude code之后,打开codex之后,我竟然不知道怎么用!
相信很多朋友跟我一样,第一次打开 Codex,第一反应不是“哇,好强”,而是:
这东西到底从哪开始用?
它看起来像一个聊天软件,但又能读文件、改项目、开浏览器、装插件、跑命令、接 MCP。软件界面的左边是一堆入口,中间是对话,右边还会弹出文件、网页、预览、代码变化。
如果你是小白,很容易犯一个错误:
什么都没配置好,就直接让它干活。
最后不是文件乱飞,就是不知道产物放哪(我整理乱糟糟的文件,头都大了!大家一定注意一些);不是插件装了一堆不会用,就是项目里没有任何规则,Codex 每次都要重新理解你。
所以这篇教程,只讲新手第一次真正上手时最需要配置的东西。
我们只解决一个问题:
一个 Windows 小白,怎么把 Codex 从“能聊天”,配置到“真的能做项目”。
看完这篇,你至少应该能完成三件事:
先说结论:新手第一次用 Codex,最该先配置的不是模型,而是项目文件夹。
如果你只把 Codex 当成 ChatGPT 的另一个入口,那它确实就是一个聊天框。
但 Codex 真正厉害的地方,不是“回答问题”,而是“直接进入项目文件,扮演你的工作助手帮你做事”。
它可以做这些事:
这也是为什么新手会懵。
普通聊天工具不会随便碰你的本地文件,但 Codex 会。普通聊天工具通常只给你答案,但 Codex 可能会真的帮你新建文件、改文件、生成项目、跑脚本。
能力越强,越需要边界。
所以小白要先建立一个最重要的意识:
不要一上来就问“Codex 能做什么”,先问“我准备让它在哪个项目里做事”。
项目位置选错了,后面全乱。
截至 2026-05-16,OpenAI 官方资料里提到,Codex 可以在多个入口使用,比如 App、CLI、Web/Cloud、IDE extension 等。具体入口和按钮名称会更新,你以自己当前看到的界面为准。
小白先看这张表就够了:
这篇文章只重点讲一条路线:
Windows 上用 Codex App,把项目真正跑起来。
为什么不一上来讲 CLI、GitHub、云端?
因为小白最先要解决的不是“入口不够多”,而是“我到底该把文件放哪、规则怎么写、权限怎么给、结果怎么看”。
把本地 App 这条路跑通,后面去 VS Code、Cloud、GitHub 都会顺很多。
安装这件事本身不复杂,最重要的是别乱下载。
建议只从 OpenAI 官方入口下载:
https://openai.com/codex/
基本流程是:
如果你已经习惯用 Windows 终端,也可以用官方文档提到的 winget 方式安装。先打开 PowerShell,再执行:
winget install Codex -s msstore
如果你后面要让 Codex 改网页、跑脚本、处理代码项目,建议顺手装几个常用工具。OpenAI Windows 文档也提到,Git、Node.js、Python 这类开发工具会让 Codex 做项目更顺。
可以先装这三个:
winget install --id Git.Git
winget install --id OpenJS.NodeJS.LTS
winget install --id Python.Python.3.14
装完以后,重启 Codex App 或重新打开终端,再让 Codex 检查:
git --version
node --version
python --version
如果你只是体验,优先用账号登录,不要一上来研究 API Key。
免费账号能不能用,要看当时官方开放策略和额度。长期使用,通常还是建议至少准备 Plus 或更高套餐。因为 Codex 一旦进入项目、读文件、改文件、跑长任务,消耗会比普通聊天更明显。
小白成功标志:
到这里,先别急着让它改文件。
先做设置。
Codex 的设置会随着版本变化,但小白可以先关注 5 类设置。
你不需要把每个按钮都研究透。先把最影响使用体验和安全边界的地方搞清楚。
如果 Codex 支持个性化、自定义说明、偏好设置之类的入口,可以先写一段固定说明。
你可以直接复制这一段:
请默认用中文回答。
如果涉及代码或命令,请先用大白话解释目的,再给具体操作。
如果要修改文件、运行命令、访问外部账号,请先告诉我风险。
教程类内容请写成小白能照着做的步骤,并标注每一步的成功标志。
如果我的需求信息不完整,请先问我缺什么,不要直接编。
这段话的作用很大。
它不是让 Codex 变强,而是让 Codex 更适合你。
小白最怕的不是 AI 不会做,而是它一上来就抛术语、跑命令、改文件,你完全不知道发生了什么。
Codex 会请求权限,比如读文件、改文件、运行命令、访问网页、连接账号。
新手最容易犯的错误是:看到确认按钮就点。
不要这样。
第一次使用,建议只给当前项目文件夹权限。
比如你要做网页工具项目,就只让 Codex 访问这个项目目录:
D:\codex_projects_by_jack\网页工具项目
不要一上来给:
C:\
D:\
整个用户目录
下载目录
个人文件夹
桌面全部文件
如果看不懂权限请求,就直接问 Codex:
请用小白能懂的话解释:你现在请求的权限会访问什么?为什么这个任务需要它?有没有更低风险的做法?
如果设置里有“Enter 发送”或“组合键发送”之类的选项,建议新手选择不容易误触的方式。
因为你后面写项目需求时,经常会写很长:
如果写一半按回车就发出去了,Codex 可能会拿着半截需求开始干活。(我吃了很多次亏才想起来要设置一下)
小白不需要一上来研究每个模型。
建议:
一句话:
小任务别浪费额度,大任务别省过头。
自动化听起来很诱人:
但新手别急。
先把手动流程跑通,再自动化。
如果你手动都没说清楚“输入是什么、输出到哪里、失败怎么办”,自动化只会把混乱定时重复一遍。
这一步是全文最重要的地方。
小白用 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\项目1
D:\codex_projects_by_jack\项目2
D:\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 -Force
New-Item -ItemType Directory -Path "$project\docs","$project\src","$project\scripts","$project\data\raw","$project\data\processed","$project\data\export","$project\assets","$project\logs","$project\tmp" -Force
New-Item -ItemType File -Path "$project\README.md","$project\AGENTS.md","$project\CONTEXT.md" -Force
执行完之后,你应该能在资源管理器里看到这个项目文件夹。
你不一定每个目录一开始都用得上,但先知道它们干什么。
如果你不是程序员,也不用怕 src、scripts 这些词。
它们只是帮你把项目分区。
真正关键的是三个文件:
README.md
AGENTS.md
CONTEXT.md
这三个文件写好,Codex 就不会每次都像第一次见你。
README.md 是给人看的。
不是写给 AI 炫技的,是写给未来的你。
一个最简单的 README 可以这样写:
# 项目名称
这个项目用于:
## 快速开始
1. 把原始素材放到 data/raw/
2. 运行脚本或让 Codex 处理
3. 最终结果输出到 data/export/
## 目录说明
- docs/:说明文档
- data/raw/:原始数据
- data/export/:最终结果
- logs/:运行日志
## 常用命令
暂无。
## 注意事项
- 不要删除 data/raw/
- 不要把真实密钥写进文档
README 的目的不是漂亮,而是让你下次打开项目时知道:
这项目是什么,怎么用,文件放哪。
AGENTS.md 是给 Codex 看的。
你可以把它理解成“项目里的工作规则”。
它告诉 Codex:
小白可以先写一个很短的版本:
# 项目协作规则
## 项目目标
这个项目用于:
## 不要改动
- 不要删除 data/raw/。
- 不要展示 .env 中的真实密钥。
- 不要把临时文件放到项目根目录。
## 工作方式
- 修改前先说明准备改什么。
- 修改后做最小验证。
- 如果新增运行方式,同步更新 README.md。
## 常用命令
- 启动:
- 验证:
很多人第一次用 Codex,项目体验不好,不是因为模型不行,而是因为项目没有规则。
你每次都临时告诉它“不要删这个”“输出放那里”“先问我再改”,当然累。
写进 AGENTS.md,就是把这些长期规则固定下来。
注意,这里只写 Codex 自己会读取、会影响当前项目协作方式的规则文件。其他工具的专属规则文件,不放进这篇文章里展开。
AGENTS.md 管“怎么工作”。
CONTEXT.md 管“这个项目是什么”。
比如你做一个 AI 工具资料整理项目,Codex 需要知道:
可以这样写:
# 项目上下文
## 一句话说明
这个项目用于整理 AI 工具资料,把零散链接、使用记录和测试结果整理成可读的 Markdown 报告。
## 目标读者
- 想选择 AI 工具的普通用户
- 想提高效率的办公人群
- 不想看一堆官网宣传语的人
## 输入
- 工具链接
- 网页摘录
- 使用体验
- 截图描述
- 价格、平台和限制信息
## 输出
- 工具对比表
- 每个工具的优缺点
- 适合场景
- 不适合场景
- 最终选择建议
## 写作要求
- 不写空泛宣传。
- 不确定的信息标注“待核实”。
- 多写真实任务和使用场景。
- 不要编造工具功能、价格和亲测体验。
## 当前状态
正在搭建 AI 工具资料整理流程。
你看,这些信息如果不写,Codex 也能写,但很容易写偏。
写了之后,它就知道你不是要一篇泛泛而谈的介绍,而是要一份“普通用户今天就能拿来做选择”的资料整理报告。
现在来说插件。
小白最容易把 Plugin、Connector、Skill、MCP 混在一起。
先别纠结技术定义,看这张表:
你刚开始不需要全懂。
记住一个顺序:
先用 App 自带能力
→ 不够再装插件
→ 重复任务沉淀成 Skill
→ 特殊工具再考虑 MCP
不要一上来装一堆插件。
插件不是越多越强,而是越明确越好。
比如:
每次只为一个明确任务装一个插件。
Skill 很容易被说玄。
其实它最适合小白理解成:
一套固定工作流说明书。
比如你经常让 Codex 整理工具资料,每次都要说:
你每次都打一遍,很麻烦。
那就可以把它写成一个 Skill 或项目内流程文件。
以后你只要说:
请按 AI 工具资料整理流程处理这个任务。
Codex 就知道要先问信息缺口,而不是上来就生成最终报告。
Skill 适合这些任务:
小白先不需要自己写复杂 Skill。
你可以先在项目里建一个 workflow.md,把流程写清楚。等你反复用很多次,再考虑沉淀成正式 Skill。
比如 AI 工具资料整理项目里,可以先建:
D:\codex_projects_by_jack\AI工具资料整理\workflow.md
然后写一条很简单的流程:
# AI 工具资料整理流程
1. 先判断信息是否完整。
2. 信息不完整时,先问 3-7 个问题。
3. 再整理资料。
4. 再生成工具对比表。
5. 再写 Markdown 报告。
6. 最后检查事实风险和待核实信息。
以后你就可以对 Codex 说:
请读取 workflow.md,并按这个流程整理 input\tools.md。
MCP 是 Model Context Protocol。
这名字听起来很吓人。
小白可以先这样理解:
MCP 是让 Codex 连接外部工具或外部资料的一种通道。
比如 OpenAI 官方有开发者文档 MCP,可以让 Codex 在 CLI 或 IDE extension 里读取 OpenAI 相关文档。官方文档里也给了添加和验证的命令。
如果你只是想知道“命令长什么样”,可以先看这个例子:
codex mcp add openaiDeveloperDocs --url https://developers.openai.com/mcp
codex mcp list
第一行是添加 OpenAI 开发者文档 MCP,第二行是查看当前 MCP 列表。
如果你是在 VS Code 里配置,也可以在项目根目录新建:
.vscode\mcp.json
内容示例:
{
"servers":{
"openaiDeveloperDocs":{
"type":"http",
"url":"https://developers.openai.com/mcp"
}
}
}
但注意:如果你还没装 Codex CLI,或者看不懂 MCP 配置文件,就先不要急着执行。小白阶段知道它的用途,比立刻装上更重要。
但对大多数小白来说,前期不用急着配 MCP。
为什么?
因为你一开始最需要的是:
这些都不需要 MCP。
所以小白顺序还是那句:
插件优先,Skill 其次,MCP 最后。
什么时候再研究 MCP?
这个问题要分清三层。
第一层:Codex App 里的浏览器能力。
它可以打开网页、查看页面、搜索资料、测试本地网页。有些时候右侧会出现网页预览或浏览器界面。
第二层:Browser / Chrome 相关插件或能力。
如果你的 Codex 环境里有 Browser 或 Chrome 相关插件,它可能可以操作浏览器页面,甚至使用你已经登录的账号状态。具体能力取决于你当前安装和授权的插件。
第三层:真实账号操作风险。
这才是小白最该注意的。
浏览器能力很强,但不要第一次就让它操作:
第一次练习,可以让它做低风险任务:
打开一个公开网页,帮我总结页面结构。
或者:
打开我本地生成的网页,检查按钮有没有重叠。
成功标志:
如果你完全不写代码,先不用急着打开 VS Code。
Codex App 已经足够你做:
那什么时候需要 VS Code?
当你开始让 Codex 做这些事:
VS Code 更像代码项目的工作现场。
Codex App 更像项目管理和多任务工作台。
两者可以服务同一个项目文件夹。
比如你的项目在:
D:\codex_projects_by_jack\我的第一个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_jack\AI工具资料整理
里面建这些目录:
AI工具资料整理/
README.md
AGENTS.md
CONTEXT.md
input/
notes/
output/
logs/
tmp/
可以直接用 PowerShell 一次建好:
$project = "D:\codex_projects_by_jack\AI工具资料整理"
New-Item -ItemType Directory -Path $project -Force
New-Item -ItemType Directory -Path "$project\input","$project\notes","$project\output","$project\logs","$project\tmp" -Force
New-Item -ItemType File -Path "$project\README.md","$project\AGENTS.md","$project\CONTEXT.md" -Force
这几行命令做了三件事:
README.md、AGENTS.md、CONTEXT.md 三个关键文件。如果你不想用命令,也可以手动新建。效果一样。
# AI 工具资料整理
这个项目用于整理 AI 工具资料,把零散链接、笔记和测试结果整理成可读的 Markdown 报告。
## 目录
- input/:原始链接、网页摘录、截图说明
- notes/:手动记录的使用体验
- output/:Codex 整理后的报告
- logs/:处理记录
- tmp/:临时文件
## 使用方式
1. 把工具链接和原始材料放到 input/
2. 把自己的体验记录放到 notes/
3. 让 Codex 读取项目规则并整理
4. 最终报告输出到 output/
# 项目协作规则
## 项目目标
帮助我把 AI 工具资料整理成结构清晰、可复用的 Markdown 报告。
## 工作方式
- 先读取 README.md、AGENTS.md、CONTEXT.md。
- 信息不完整时,先问我缺什么。
- 不要编造工具功能、价格、链接和使用体验。
- 不确定的信息标注为“待核实”。
- 输出报告放到 output/。
- 临时分析放到 tmp/。
## 禁止事项
- 不要删除 input/ 和 notes/ 里的原始材料。
- 不要泄露任何账号、Cookie、API Key 或私人文件路径。
- 不要把未验证的信息写成确定结论。
# 项目上下文
## 项目用途
把多个 AI 工具的资料整理成一份普通用户能看懂的对比报告。
## 目标读者
- 想选择 AI 工具的普通用户
- 想提高效率的办公人群
- 不想看一堆官网宣传语的人
## 整理要求
- 先说这个工具解决什么问题。
- 再说适合谁、不适合谁。
- 如果有价格、平台、限制,要单独列出。
- 不确定的信息不要猜,标注“待核实”。
- 最后给出场景化选择建议。
## 输出要求
- 工具对比表
- 每个工具的优缺点
- 适合场景
- 不适合场景
- 最终选择建议
比如放到:
input\tools.md
这个文件可以很简单,像这样:
# 待整理工具
## 工具 A
官网:
我知道的信息:
-
## 工具 B
官网:
我知道的信息:
-
## 工具 C
官网:
我知道的信息:
-
如果你已经有一份资料,可以复制到这个目录。命令示例:
Copy-Item-LiteralPath"D:\你的原始资料\tools.md"-Destination"D:\codex_projects_by_jack\AI工具资料整理\input\tools.md"
看不懂也没关系,手动复制文件也完全可以。
你可以这样说:
请先阅读 README.md、AGENTS.md、CONTEXT.md。
然后读取 input\tools.md。
按项目规则,先告诉我这份资料还缺哪些信息,不要直接生成最终报告。
这句话很重要。
它会强制 Codex 先做信息补全,而不是一上来生成一份看似完整、其实很多地方靠猜的报告。
等它问完缺口,你再补一句:
请基于已确认资料,生成一份 Markdown 报告,放到 output\AI工具对比报告.md。
报告里必须包含:工具对比表、适合谁、不适合谁、使用门槛、最终选择建议。
不确定的信息请标注“待核实”。
成功标志:
output/这就叫项目开始跑起来了。
结果就是文件到处飞。
先建项目,再开始。
如果只是普通 Markdown 笔记,放进去没问题。
但如果这个项目会运行脚本、生成数据、下载文件、写日志,最好单独放到项目目录。
否则几天后你会发现,笔记、缓存、日志、临时文件混在一起,很难收拾。
Codex 每次都要重新猜你想怎么工作。
Codex 不知道项目背景、目标用户、输出格式和边界条件。
这是最危险的习惯。
不懂就问它解释。
插件不是越多越好。
先明确任务,再装插件。
不要把密钥、Cookie、密码写进 README、AGENTS、CONTEXT。
真实配置放 .env,并且不要公开。
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 更新很快,具体按钮名称、插件入口和可用功能以你当前账号和官方界面为准。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-05-28
小红书支持上传 skill 了,AI 创作者赚钱的时机到了
2026-05-28
大模型的Agent Skill功能,在LLM HTTP底层交互流中是怎么承载的?
2026-05-27
Skill越详细Agent越傻!砍到40词一次选对
2026-05-27
verify-data:一个端到端的数据验数 Agent Skill
2026-05-26
lark-cli:企业 SaaS 走向 AI 化时,值得对照的一份范本
2026-05-25
SkillRouter:从 8 万技能里找对那一个,这套方案只要 1.2B 参数
2026-05-25
让 Codex 设计前端不丑:Skill、参考站点与重开发流程
2026-05-25
Claude Code 这16个官方Skill,用了半年我总结出最值得装的7个
2026-04-05
2026-03-05
2026-03-17
2026-03-04
2026-03-03
2026-03-03
2026-03-17
2026-03-26
2026-03-10
2026-03-05