很多人第一次打开 Codex，马上输入：帮我做一个网站。
几分钟后却发现：文件改乱了、依赖装错了、运行不了，甚至不知道 Codex 到底做了什么。
问题不一定出在模型。
更可能是因为你还没告诉 Codex：在哪里工作、可以做什么、不能做什么，以及怎样才算完成。
所以，在正式干活前，建议先完成下面 5 个设置。
01｜先设置项目文件夹
不要让 Codex 一上来就读取你的整个桌面、下载目录或个人文件夹。
正确做法是：一个项目，对应一个独立文件夹。
例如：
Projects/
└── my-first-codex-project/这个文件夹里，只放当前项目需要的内容。
如果是已有项目，就选择它的代码仓库；如果是新项目，就先建立一个空文件夹，再让 Codex 在里面工作。
Codex 会使用你打开位置中的文件和上下文，因此工作目录选得越准确，它越不容易误读无关文件。
最好再提前做两件事：
git init
git add .
git commit -m "Initial backup"看不懂也没关系。
你只需要知道：Git 相当于项目的“存档系统”。
Codex 改坏了，你还有机会恢复，不要把 AI 当成绝不会出错的程序员。
先留备份，再让它动手。
02｜设置模型和思考强度
不是所有任务都需要最高强度的模型。
第一次使用时，建议把默认思考强度设置为：Medium。
它比较适合日常开发、修改页面、修复普通 Bug 和解释代码。
可以按照下面的方式选择：
Low：改文案、改颜色、调整小功能
Medium：日常开发、搭建页面、普通调试
High：复杂 Bug、架构调整、跨文件修改
Extra High：长时间、多步骤、高难度任务
OpenAI 的使用建议同样是：简单任务可以选择 Low，较复杂的修改和调试使用 Medium 或 High，长时间且推理密集的任务再使用更高等级。
不要为了“效果最好”，所有任务都开最高强度。
这通常意味着：更慢、消耗更多，而且小任务未必做得更好。
对于使用 CLI 或 IDE 扩展的人，可以在 config.toml 中设置默认模型和推理强度；目前官方配置示例使用 gpt-5.6，但实际可选模型会随版本和账户计划变化。
model = "gpt-5.6"
model_reasoning_effort = "medium"新手记住一句话就够了：平时用 Medium，遇到真正困难的问题再升档。
03｜设置权限，不要直接开启完全访问
这是最重要的设置之一，Codex 不只是“回答问题”。
它可能会：读取文件、修改代码、运行命令、安装依赖，甚至访问网络。
所以你必须提前决定：它做哪些事情时，需要先问你。
新手推荐从下面的组合开始：
approval_policy = "on-request"
sandbox_mode = "workspace-write"它们大致意味着：
Codex 可以在当前项目中工作，但遇到超出安全边界的操作时，需要向你申请批准。
OpenAI 官方文档说明，沙箱决定 Codex 可以访问哪些文件、是否能够写入和联网；批准策略则决定它什么时候必须停下来询问用户。官方也建议新用户先保持较严格的默认权限，熟悉工作流后再逐步放宽。
第一次使用时，尽量不要选择：
never
danger-full-access
full access特别是涉及以下内容时：生产数据库、支付系统、客户数据、服务器、API 密钥和重要文件。
速度慢一点没有关系。
先确保它不会在你没看清时，替你做出不可逆的操作。
04｜创建一份 AGENTS.md
这是很多新手最容易忽略，却最有用的设置。
你可以把 AGENTS.md 理解成：专门写给 Codex 看的员工手册。
每次开始工作前，Codex 都可以读取这里面的长期规则。
你不需要每次重复告诉它：使用什么语言、先做计划还是直接修改、运行哪些测试、哪些文件不能碰。
这些要求都可以放进 AGENTS.md。
OpenAI 官方文档建议在其中记录项目结构、运行方式、测试命令、开发规范、禁止事项和验收标准；Codex 会自动读取相应层级的指令。
新手可以直接使用下面这份模板：
# 工作规则
- 默认使用中文与我沟通
- 修改代码前，先阅读相关文件
- 复杂任务先给出计划，等待我确认后再执行
- 不要随意删除现有功能
- 不要修改与当前任务无关的文件
- 安装新的依赖前，先说明原因
- 不要把密码、密钥或隐私数据写入代码
# 开发要求
- 优先使用简单、容易维护的方案
- 保持现有项目的代码风格
- 修改完成后运行相关测试
- 遇到不确定的需求时先提问，不要自行假设
# 完成标准
任务完成后，请告诉我：
1. 修改了哪些文件
2. 每项修改解决了什么问题
3. 执行了哪些测试
4. 是否还有风险或未完成事项
5. 我应该怎样检查最终效果不需要一开始写几十条规则，好的 AGENTS.md 不在于长，而在于具体。
每当 Codex 重复犯一个错误，就往里面增加一条规则。用久之后，它会越来越适合你的工作方式。
05｜设置运行环境和验收流程
很多人认为 Codex 做不好，是因为模型不够聪明。
但实际情况可能只是：项目依赖没装、环境变量缺失、启动命令不对，或者 Codex根本不知道怎样验证结果。
所以正式开发前，可以先发出这条指令：
请先检查当前项目的运行环境，包括依赖、启动命令、测试命令和必要的环境变量。暂时不要修改代码，先告诉我当前项目能否正常运行，以及缺少哪些配置。
如果使用 Codex 的云端环境，还可以为项目配置依赖、工具、环境变量和任务需要的密钥。
但要注意：密钥应该放在环境变量或专门的 Secrets 设置中，而不是直接写进提示词或代码。
然后，为 Codex 设置固定的验收流程：
理解需求
↓
检查现有项目
↓
提出计划
↓
执行修改
↓
运行测试
↓
检查最终效果
↓
总结改动不要只说：帮我把这个功能做好。
可以改成：
请先阅读相关代码并分析实现方式。
在修改前给出计划。
修改完成后运行测试和代码检查。
最后总结修改的文件、测试结果和仍然存在的风险。
Codex 最容易翻车的时刻，不是开始工作时。
而是它认为“代码已经写完”，你也认为“任务已经完成”。
实际上：代码写完，不等于功能可用。
只有通过测试、检查页面、确认行为符合需求，任务才算真正结束。
设置完成后，先运行这个测试任务
不要急着让 Codex 开发一个大型产品。
先用下面这段提示词，测试设置是否正常：
请先阅读当前项目，不要立即修改任何文件。告诉我：
这个项目的主要功能是什么；
应该怎样启动；
项目的核心目录和文件有哪些；
当前可能存在什么问题；
如果继续开发，你建议先做什么。在我确认之前，不要安装依赖、删除文件或修改代码。
观察它是否：正确理解项目、遵守不修改文件的要求、主动说明风险，并给出清晰计划。
如果这些都正常，再开始第一个真实任务。
总结
第一次使用 Codex，先完成这 5 个设置：
① 项目文件夹
避免读取和修改无关文件。
② 模型与思考强度
日常使用 Medium，困难任务再提高。
③ 沙箱与批准权限
先严格、后放宽，不要直接完全授权。
④ AGENTS.md
把重复要求变成长期工作规则。
⑤ 环境与验收流程
让 Codex 不只是写代码，还要运行、测试和汇报。
很多人使用 Codex 的方式是：发一句提示词，然后期待奇迹发生。
更有效的方式是：先给它工作场地、权限边界、项目规则和完成标准，再让它执行任务。
Codex 的能力决定它能跑多快，而你的设置，决定它会不会跑错方向。
