第一次使用 Codex，最重要的不是让它完成多复杂的功能，而是建立一个你能看懂、能验证、必要时能撤销的工作流。本教程选择桌面应用作为示例入口，并从只读分析开始，再进入一个聚焦的小修改。
完成后，你应该能够回答五个问题：Codex 正在哪个项目里工作？它准备改什么？实际改了哪些文件？运行了哪些检查？还有哪些事项没有验证？
开始前准备
选择一个本地练习项目，最好满足以下条件：
- 已使用 Git，且开始前没有不明的未提交改动；
- 你知道项目正常运行时大致是什么样子；
- 项目包含 README 或其他启动说明；
- 任务不涉及生产数据、支付、密钥、账号权限或部署；
- 你能够运行项目已有的检查命令。
如果项目本来就有未提交改动，先确认它们是谁创建的、是否需要保留。不要把“工作区不干净”误当成 Codex 刚产生的修改。
第一步：打开正确的项目
安装并登录 ChatGPT 桌面应用后，选择 Codex，然后打开要处理的文件夹或项目。OpenAI 当前 Quickstart 说明，应用可以在你选择的文件夹中读取和修改文件；因此目录选择本身就是权限边界的一部分。
先不要发修改请求。请让 Codex确认环境：
只读取这个项目，不要修改文件。请说明项目用途、主要目录、启动命令和验证命令，并列出你为得出结论实际读取的文件。如果信息不足，请明确指出，不要猜测。
随后对照 README、package.json 或项目配置核对回答。若目录或命令不对，先纠正上下文，再继续任务。
第二步：选择低风险的首个任务
好的第一次修改应当范围小、结果明显、容易撤销。例如：
- 修正一处真实的错别字；
- 为已有按钮补充缺失的可访问名称；
- 改善一段已有错误提示，但不改变业务逻辑；
- 给现有纯函数增加一个明确边界条件的测试。
不建议把升级全部依赖、重构核心架构、迁移数据库或发布生产环境作为第一次任务。任务越大，你越难判断问题来自需求、上下文、实现还是环境。
第三步：把任务写成可验收的说明
OpenAI 的最佳实践建议在任务里提供目标、上下文、约束和完成条件。可以直接使用下面的模板：
目标：修正设置页空状态文案中的错别字。
上下文：请先阅读项目规则和设置页相关组件。不要改动其他页面。
约束：保留现有组件结构、样式和翻译键；不要安装依赖；不要创建新功能。
完成条件：只修改必要文件；运行与该文件相关的格式和类型检查；最后列出改动、检查结果和未执行的检查。“不要安装依赖”和“只修改必要文件”不是万能要求，但它们很适合第一次练习，因为能减少意外范围扩张。
第四步：先检查方案，再允许修改
对陌生项目或多步任务，可以先要求 Codex给出计划：它准备读取哪些文件、预计修改哪些位置、如何验证。检查计划时关注三点：
- 是否指向了正确的文件和功能；
- 是否出现任务之外的重构、依赖或配置变更；
- 验证命令是否真实存在且与修改相关。
如果只是修正一处文案，不需要把流程变得过度复杂；但只要计划超出预期，就应先收窄范围，而不是等改动完成后再清理。
第五步：查看改动和命令
Codex 工作时，留意它读取了什么、修改了什么、准备运行什么命令。不要只看最终总结。检查差异时可以按这个顺序：
- 文件范围： 是否只触及任务需要的文件？
- 内容范围： 是否保留了原有结构、命名和约定？
- 意外删除： 是否移除了注释、测试、翻译或用户原有改动？
- 敏感内容： 是否把密钥、个人数据或本地路径写进代码？
- 可撤销性： 当前 Git 差异是否清楚，能否只恢复本次修改？
当命令需要更高权限、网络访问或影响项目之外的文件时，先理解原因和目标，再决定是否批准。
第六步：运行验证
不要把 Codex 的“看起来正确”当作验收。要求它运行项目实际使用的检查，例如格式、lint、类型检查、单元测试或构建。OpenAI 的最佳实践也强调，应让 Codex在需要时创建测试、运行相关检查、确认结果并审查差异。
验证结果至少要区分：
- 已运行并通过；
- 已运行但失败，以及失败是否与本次修改有关；
- 因环境、时间或权限没有运行；
- 项目根本没有对应检查。
“未运行”可以是诚实的结果，但不能写成“已通过”。如果检查失败，不要立刻要求 Codex绕过或删除测试；先确认失败原因。
第七步：做最终验收
提交前，用一份短清单结束任务：
- 目标行为已经发生变化；
- 差异只包含预期文件；
- 用户原有改动仍然存在；
- 相关检查有可读的真实结果；
- 没有密钥、个人信息或临时文件进入 Git；
- 没有把未验证事项写成已完成；
- 你能解释并接受每一处修改。
如果任何一项无法确认，继续提问或缩小改动，不要急着提交。
一个完整的首任务示例
假设项目的 README 缺少测试命令，但 package.json 已经定义了它。可以这样发起任务：
请先阅读 AGENTS.md、README.md 和 package.json。确认真实测试命令后，只在 README 的开发说明中补充这一条命令。不要修改脚本或依赖。完成后运行文档格式检查（如果项目存在），展示最终差异，并说明你没有运行哪些检查。这个例子让 Codex必须先从权威文件查证命令，又把修改限制在一份文档中，验收成本很低。它比“帮我优化项目”更适合建立第一次成功经验。
如果你还不确定 Codex 的定位，可先阅读Codex 是什么；如果希望在终端完成同类流程，可继续阅读Codex CLI 安装与首次运行。
常见问题
第一次任务一定要让 Codex 修改代码吗？
不需要。只读解释项目、梳理启动流程或定位相关文件，往往更适合作为第一步。先确认它理解了环境，再进入修改。
提示词需要写得很长吗？
不需要。比长度更重要的是目标、相关上下文、约束和完成标准。小任务可以很短，但仍应让结果可检查。
Codex 说测试通过，我还要看输出吗？
要。确认它运行的确实是项目适用的命令，并检查退出状态、失败数量和是否存在跳过项。总结不能替代真实输出。
如果 Codex 改了不该改的文件怎么办？
先停止扩大任务，检查 Git 差异，识别哪些改动属于本次任务。只恢复明确属于本次且不需要的内容，不要覆盖用户原有修改。
什么时候可以尝试更大的任务？
当你已经能稳定确认工作目录、权限、差异和验证结果，并且项目有清晰规则与测试时，再逐步增加任务范围。复杂任务应先规划并设置检查点。