Codex 怎么用？从第一个可验证任务开始
Codex 更适合和你一起读代码、改文件、跑命令，而不是凭一句话生成完整产品。新手第一步应该选一个能在本地验证的小任务。
先确认目标
本文解决什么问题？
这篇文章帮你建立 Codex 的使用流程：怎么描述任务、怎么限制范围、怎么验证结果，以及什么时候该停下来重新说明需求。
第一个任务怎么选
Codex 的强项是把任务落到文件和命令上。第一个任务最好满足四个条件：目标很小、文件范围明确、结果能运行、失败时有报错可以继续追。
| 好任务 | 差任务 |
|---|---|
| 给服务页补一个 CTA 链接 | 做一个完整 SaaS |
| 修一个测试失败 | 优化整个架构 |
| 给工具页加一个输入校验 | 让网站更高级 |
| 写一篇可构建 MDX 文章 | 自动生成 100 篇文章 |
可以直接复制的任务模板
目标：____。
背景：这个项目是 ____，当前问题是 ____。
范围：优先只改 ____ 文件；不要重构无关代码。
验收：完成后请运行 ____，并说明是否通过。
限制：不要修改密钥、配置里的真实账号、数据库连接和无关样式。
第一次使用时，可以把目标写得更小一点：
请阅读这个项目的 package.json 和相关页面文件，帮我找出 /tools/cost-calculator 的主要实现位置。
先不要改代码，只告诉我：入口文件、相关数据文件、验证命令。
这个请求的好处是低风险。你先让 Codex 建立项目地图，再让它执行修改，会比一上来就说“帮我优化整个网站”稳定得多。
可以直接照做
第一条 Codex 任务直接这样写
把下面内容改成你的项目情况：
请先阅读 package.json 和目标页面文件，找出这个功能的入口。
目标：只定位问题，不改代码。
请返回：相关文件、可运行命令、你建议的最小修改步骤。
限制：不要改文件，不要运行破坏性命令。
这条任务的产出是项目地图，适合做所有后续改动的第一步。
使用步骤
说明当前目标
用一句话说清楚结果，例如“让成本计算器在输入为空时不崩溃”。
给出验收方式
告诉 Codex 要跑哪些命令，例如 lint、test、build 或某个页面截图检查。
限制改动范围
指定只改哪些文件，避免它顺手重构无关代码。
看 diff 和测试
不要只看最终回复。检查改了什么、测试是否真的跑过、失败是否解释清楚。
好请求和差请求怎么改写
| 差请求 | 更好的写法 | 为什么更好 |
|---|---|---|
| 帮我把网站做完整 | 先给 /contact 页面加一个服务咨询入口，并运行 pnpm test | 范围小，能验证 |
| 页面不好看，优化一下 | 优化 /tools/cost-calculator 的移动端表单间距，不改颜色系统 | 指出页面、问题和限制 |
| 帮我修 bug | pnpm test 里 content quality gate 失败，请先解释失败原因，再改最小文件 | 有错误来源和验收命令 |
| 写一篇 AI 文章 | 在 content/coding 下补一篇 MDX，必须有 H1、4 个 H2、FAQ、Summary 和内链 | 给出结构约束 |
跑偏时怎么收敛
Codex 跑偏时，不要继续追加一堆要求。先把任务收回来：
暂停扩散
先说“停止继续扩大范围”，要求它总结已经改了哪些文件、哪些改动和目标有关。
缩小下一步
把目标改成一个文件或一个测试失败，例如“只修
src/lib/articles.test.ts的当前失败”。重新指定验收
明确只需要跑一个命令，通过后再考虑下一步。不要同时要求设计、重构、写文章和修测试。
使用前检查清单
| 检查项 | 新手要做到什么 |
|---|---|
| Git 状态 | 知道哪些改动是自己已有的，避免误回滚 |
| 运行命令 | 至少知道 pnpm test、pnpm typecheck、pnpm build 哪个能验证当前任务 |
| 文件范围 | 能指出页面、文章或测试的大概位置 |
| 数据安全 | 不把密钥、客户数据、生产数据库内容贴给模型 |
| 结果审查 | 看 diff、看测试输出，不只看最终总结 |
官方资料和站内下一步
Codex 的入口、模型和权限会变化，长期使用前先看官方资料：
- Codex 官方入口：了解 Codex 适合写代码、读仓库、审查代码、调试和自动化开发任务。
- Codex CLI：确认本地终端用法；官方说明它可以在选定目录里读代码、改代码和运行代码。
- Codex Quickstart：查看当前 IDE 扩展、登录和第一个任务入口。
- Codex 认证说明：区分 ChatGPT 登录和 API Key 登录，以及本地/云端能力差异。
如果你还没决定做什么项目，下一步先看 Codex 适合开发什么项目。如果你主要卡在前端页面不好看，再看 Codex 生成前端 UI 太丑怎么办。
什么时候要重新描述
如果 Codex 连续偏离目标、改动越来越大、测试失败原因说不清，就应该停下来，把目标拆小，而不是继续让它自由尝试。
不要把密钥、私有数据、生产数据库连接串直接贴进任务。需要排查时用脱敏示例。
FAQ
Codex 能不能写前端？
能，但你需要给出具体页面目标、现有设计约束和验证方式。只说“做得好看”通常不够。
Codex 最适合修 bug 吗？
适合可复现、可验证的 bug。最好先有错误日志、失败测试或明确复现步骤。
一次任务要多大？
越小越好。一个页面、一个组件、一个测试失败，比“做完整项目”更容易成功。
阅读结论
总结
使用 Codex 的关键是把任务变成可验证目标：范围清楚、文件明确、命令能跑、结果能检查。