ChatGPT Codex 第一个代码任务

第一次使用 Codex，不要从“重构整个项目”开始。选一个可以复现、可以验收、改动范围有限的问题，最容易判断 Codex 是否真的帮你完成了工作。

一个完整的 Codex 任务，应该包含调查、实现、验证和结果说明。

下面用“修复首页在手机宽度下横向溢出”作为示例。你可以把同样的结构换成表单校验、筛选功能或接口错误处理。

第一步：写清楚任务合同

先把目标、范围、约束和验收条件写出来：

目标：修复首页在 390px 宽度下出现横向滚动的问题。

范围：只修改首页布局和相关样式，不改路由、文案和接口。

约束：保持桌面端现有布局，不新增依赖；交互元素仍然可以键盘操作。

验收：
1. 390px 宽度下 document.documentElement.scrollWidth 不超过 viewport 宽度。
2. 导航、首屏标题、按钮和页脚都可见。
3. 运行项目现有构建命令并报告结果。

“把页面做好看一点”不是合格任务，因为没有可检查的完成标准。

第二步：先调查，不要立即改

把调查要求放在任务开头：

请先阅读项目结构、package.json、首页组件和全局样式。
找出横向溢出的具体元素，说明原因、准备修改的文件和验证方法。
暂时不要修改代码。

你需要从 Codex 的调查结果中确认三件事：它找到了真实溢出源，知道项目使用的样式方案，并且没有把问题误判成浏览器或字体问题。

第三步：限定实现范围

确认调查结果后，再允许修改：

按照刚才的调查结果实现修复。
只修改你列出的文件。不要顺手重构无关组件，也不要更新依赖。
完成后列出每个文件改了什么。

范围控制很重要。Codex 能够看到很多文件，但能看到不代表都应该改。

第四步：运行验证

实现完成后，要求 Codex 运行和任务直接相关的检查：

现在运行项目现有的构建、测试或 lint 命令。
如果项目有浏览器检查，请验证 390px 和桌面宽度。
请报告通过的命令、失败的命令和没有条件执行的检查。

不要只接受“看起来已经修好”。构建失败、测试没有运行或移动端没有实际检查，都应该写进结果。

第五步：审查改动

最后让 Codex 自己复查一次：

请审查当前 diff：
1. 是否有超出任务范围的修改。
2. 是否引入了新的依赖或破坏现有交互。
3. 是否覆盖了验收条件。
4. 是否仍有未验证的风险。
只报告问题，不要再次修改代码。

你可以把这一步当成提交前的第二双眼睛。最终是否合并、发布或推送，仍然由你根据 diff 和验证结果决定。

一个任务完成后的合格报告

Codex 的最终报告至少应该包含：

• 修改了哪些文件，以及每个文件的目的。
• 运行了哪些命令，结果是什么。
• 哪些部分没有验证，原因是什么。
• 是否存在需要你决定的取舍或后续工作。

如果报告只有“已完成”，说明任务闭环还没有建立起来。