Codex 教程：安装后如何完成第一个开发任务
Codex 怎么用，关键不在“发一句话等答案”，而在建立可检查的工作闭环。本教程从选择项目开始，带你写清任务、控制权限，并亲自验收最终改动。
已经安装？直接往下做第一个任务。还没安装，可先看Codex 安装总教程。
Codex 怎么用？先记住五步闭环
Codex 是能读取项目、修改文件、运行命令和解释结果的编程代理。你仍然是任务负责人：负责给边界、判断权限、检查变更、运行验证。把它当作会动手的协作者，比把它当成一次性代码生成器更容易得到稳定结果。
Step zero · 选择入口
App、CLI、VS Code、Web 该选哪个？
四个入口都可以完成真实开发任务。第一次使用不必追求“最专业”，应选择你最容易看清项目范围、权限请求和文件变化的界面。入口不同，验收原则相同。
完全没有终端经验，可先用桌面 App；已经在终端里管理 Git 和测试，再选择 Codex CLI。
Codex 桌面 App
适合：第一次使用、希望图形界面里选项目和看变更
上手直观，适合把任务、审批和结果集中在一个窗口。
Codex CLI
适合：熟悉终端、经常在仓库目录里工作
路径与命令最直接，但你需要能判断终端命令的影响。
VS Code 扩展
适合：主要在编辑器里读代码和逐文件修改
上下文贴近当前文件，适合边看代码边协作。
Codex Web / 云端
适合：希望任务在独立环境运行，完成后集中审查
适合异步工作，但要先确认仓库连接、环境变量和验证方式。
Safety checkpoint
打开项目前，先做三项安全检查
Codex 能执行真实操作，因此第一个任务应选择容易撤回、容易验证的仓库。已有未提交改动时尤其要小心：那可能是你或同事尚未完成的工作，不应被覆盖或混入本次任务。
确认目录
工作目录只包含目标项目；让 Codex 先报告仓库根目录、当前分支和主要文件。
保存现状
查看 Git 状态；重要改动先用团队认可的方式保存。不要让第一次任务从删除或大范围重构开始。
保护敏感信息
不要在对话里粘贴 API Key、Cookie、数据库连接串或真实客户数据；只提供变量名和必要的数据结构。
The operating loop
第一个任务：按五步闭环推进
下面不是只能照做一次的操作清单，而是一套可以重复使用的工作方法。以后任务变复杂，只是每一步需要提供更多证据，顺序不变。
- 01
选项目：把 Codex 放进正确的工作目录，先让它读懂项目结构和现有规则。
第一次不要直接选择桌面、下载目录或包含多个项目的大文件夹。请选择一个有明确边界的代码仓库，并先让 Codex 说明它看到了哪些目录、使用什么技术栈、有哪些测试命令。
Checkpoint
能说清项目入口、技术栈和验证命令，再继续。
- 02
定权限：从“执行前询问”开始，只为当前任务开放必要的文件和命令权限。
权限不是越大越省事。新手建议让 Codex 在修改文件、运行可能改变环境的命令前请求批准；看到命令后先确认作用范围、目标路径和是否会写入外部系统。
Checkpoint
不批准看不懂的命令，不把账号密钥写进提示词。
- 03
写任务：用“目标、上下文、约束、完成标准”把模糊愿望改成可验收任务。
不要只说“优化一下页面”。说明要解决谁的问题、相关文件在哪里、哪些行为不能改变、最后用什么测试或页面现象判断完成。Codex 获取的信息越接近真实验收条件，返工越少。
Checkpoint
任务必须有边界，也必须能判断完成或未完成。
- 04
看执行：关注计划、文件范围、命令和异常，而不是等待最后一句“已完成”。
执行中检查 Codex 是否仍在解决原问题。若它开始扩大重构范围、修改无关文件或反复尝试同一命令，应及时暂停并补充约束。遇到不理解的决策，可以要求它先解释再继续。
Checkpoint
修改范围与任务目标一致，异常有解释、有处理。
- 05
验结果：检查 diff、运行测试、验证页面行为，最后再决定是否接受改动。
先看哪些文件被改、是否混入无关变化，再运行与改动直接相关的测试；涉及页面时还要在浏览器里走一遍关键路径。测试通过不代表产品行为一定正确，代码看起来合理也不能替代运行验证。
Checkpoint
diff 可解释、测试通过、真实行为符合完成标准。
权限模式会随产品更新；执行前请同时查看OpenAI Codex 官方权限模式。
Prompt recipe
一个好任务，至少写清四件事
提示词不需要很长，但需要可执行。先把事实和边界写完整，再讨论技术方案。你也可以要求 Codex 在信息不足时先提问，不要自行猜测关键业务规则。
查看 OpenAI Codex 官方提示词指南最实用的一句补充
“如果信息不足，先列出需要确认的问题；不要在关键规则上自行假设。”
目标（Goal）
一句话说明要实现或修复什么，以及它为谁解决什么问题。
修复结算页在优惠码无效时没有显示错误提示的问题。
上下文（Context）
指出相关页面、组件、错误现象、复现步骤和已有项目规则。
入口在 /checkout，相关代码位于 app/checkout 和 components/coupon。
约束（Constraints）
写清不能改什么、需要沿用什么，以及必须先确认的高风险动作。
不要修改支付接口；沿用现有 Toast；不要新增依赖。
完成标准（Done when）
列出可观察、可测试的验收条件，不使用“更好看”“更稳定”这类模糊词。
无效优惠码显示中文错误；有效优惠码流程不变；相关测试通过。
Copy / Paste
通用任务骨架
替换方括号内容即可。完成标准越具体，最后越容易验收。
目标：【要解决的问题与用户结果】
上下文：【相关路径、复现步骤、现有行为】
约束：【不能修改的范围、必须沿用的规则】
完成标准：【可观察行为、测试、构建或截图】
执行方式：先检查项目并给出简短计划；不确定时先问我；完成后列出改动文件与验证结果。
Verified build record
真实任务：用 Codex 构建本教程页
这不是虚构的演示。2026 年 8 月 8 日，我们在 GetPlus AI 的独立 Git worktree 中完成了本页：先研究关键词和搜索结果，再用测试固定页面契约，最后运行构建并在真实 Chrome 中验收桌面与移动端。
原始任务边界
- • 新增 /codex-jiaocheng，承接“Codex 教程 / Codex 怎么用”
- • 不复制安装页，不修改支付和数据库逻辑
- • 以 diff、测试、生产构建和浏览器行为作为完成标准
RED
测试先因路由不存在而失败
页面契约先断言 Metadata、单一 H1、五步流程、Schema、内链和 Sitemap；首次运行明确报缺少内容模块。
SCOPE
改动范围可以逐项解释
正文与页面拆分维护，路由只接入 Codex 中心、安装页、导航和 Sitemap，没有触碰支付或数据库。
TEST
相关回归全部通过
页面、导航、布局、Codex 中心和安装页的相关测试全部通过；失败信息和验证范围均保留在内部记录中。
BUILD
生产构建成功
Next.js 生产构建成功，/codex-jiaocheng 进入路由清单，页面可由服务端输出完整正文。
BROWSER
移动端无横向溢出
真实 Chrome 验证单一 H1、目录锚点、FAQ、移动端宽度和控制台；页面正文在禁用脚本的 HTML 中仍可读取。
Acceptance checklist
Codex 说“完成”后，你要检查什么？
验收不是再问一句“确定吗”。下面四层证据从静态改动走到真实用户行为，风险较低的小任务至少也要覆盖前三层。
范围
查看 Git 状态和文件列表，确认没有改到任务外的文件。
代码
检查 diff、错误处理、边界情况和是否残留调试内容。
自动验证
运行测试、类型检查和项目要求的构建命令，保留失败信息。
真实行为
按用户路径操作页面或程序，检查结果、响应式和控制台。
如果测试失败，不要把它从验收记录里删掉。先判断失败由本次修改引入，还是项目原本就存在；无法确认时，明确报告“尚未验证”，不要猜成成功。
Ready-made prompts
4 个可以直接复制的 Codex 任务
先选择与你当前场景最接近的模板，再补充具体路径、错误信息和验收结果。模板的作用是防止遗漏，不是替代你的项目事实。
1. 先读项目，不修改
适用：刚打开陌生仓库，先建立共同上下文。
2. 修复一个可复现 Bug
适用：现象明确，希望避免 Codex 只修表面。
3. 实现一个小功能
适用：需求边界清晰，可在一个会话内验收。
4. 审查已有改动
适用：准备接受结果前，再做一次独立检查。
Failure patterns
6 个新手常见错误
大多数第一次失败，不是模型不会写代码，而是目录、任务边界或验收方式没有说清。发现做偏时，越早暂停越容易修正。
一上来就说“把项目优化一下”
改法：把请求缩小成一个用户问题、一组相关文件和一份完成标准。
选错工作目录
改法：先确认仓库根目录、当前分支和未提交改动，避免读取或修改相邻项目。
看见权限请求就全部同意
改法：逐条看命令、路径和外部影响；不了解时先让 Codex 用一句话解释。
把密钥、Cookie 或客户数据贴进对话
改法：只描述变量名和数据形状，敏感值保留在受控环境中。
只看最终总结，不看 diff
改法：总结可能遗漏细节；以实际文件变化、测试输出和页面行为为准。
测试通过就直接上线
改法：还要检查构建、浏览器控制台、响应式布局和真实关键路径。
Plan & usage
Plus、Pro、Credits 先不用急着选
先登录账号并完成一个小任务，再看自己的可用功能与剩余用量。套餐能力和额度可能变化，以账号内显示为准；遇到用量不足时，再比较 Plus、Pro 或额外 Credits，避免把套餐选择和使用方法混在一起。
FAQ
Codex 教程常见问题
Codex 怎么用，最短流程是什么？
选择一个边界清楚的项目，从需要审批的权限模式开始，用目标、上下文、约束和完成标准描述任务。执行后检查 diff、运行相关测试，并亲自验证关键行为。
第一次用 Codex 选 App、CLI 还是 VS Code？
想直观看任务和变更可先选桌面 App；熟悉终端可选 CLI；主要在编辑器内工作可选 VS Code 扩展。它们的核心流程相同，选择你最容易检查改动的入口即可。
Codex 可以直接修改整个项目吗？
它可以在授权范围内读取和修改多个文件，但第一次任务应限制在一个小目标。范围越大，越需要先确认计划、分阶段执行，并在每阶段审查变化。
应该给 Codex 哪种权限？
新手建议从执行前询问开始。只批准当前任务确实需要的文件写入和命令；涉及删除、发布、生产数据、账号或外部消息的动作，要单独确认目标和后果。
Codex 说完成了，为什么还要检查 diff 和测试？
“完成”是代理对过程的总结，不是独立验收。diff 能发现无关改动，测试能发现代码回归，浏览器或实际运行验证能确认用户看到的行为，这三者解决的问题不同。
任务做偏了怎么办？
先暂停，指出偏离发生在哪一步，并重申不能改的范围与完成标准。若上下文已经混乱，保留可用结论后开启一个更小、更明确的新任务，通常比继续堆补充指令更稳妥。
如何让 Codex 先只读分析，不修改文件？
在任务开头明确写“先只读检查，不修改文件，也不运行会写入数据的命令”，并要求它先报告项目结构、相关文件和建议计划。确认范围无误后，再单独授权进入修改阶段。
Official references
本文依据与继续阅读
页面方法以 OpenAI 当前公开资料为依据，核验日期为 2026 年 8 月 8 日。产品界面、套餐和权限选项可能更新，操作时以官方页面与账号内显示为准。
Next routes
按你当前的问题继续
本页解决安装后的使用闭环；不同系统的下载、安装和登录步骤，请转到对应安装教程，避免在这里混用过期命令。