Codex 不是读心术。你给它的信息越像一张清楚的小任务卡，它越容易做出可检查、可回滚的修改。

一个好任务说明的四个部分

第一是目标：你希望它完成什么。

第二是背景：相关文件、错误信息、业务规则、上下游影响是什么。

第三是约束：哪些不能改，哪些风格必须遵守，是否允许新增依赖。

第四是验收：怎样算完成，比如测试通过、页面能打开、接口返回符合预期。

不稳定的写法

帮我优化一下这个页面。

这句话的问题是“优化”没有边界。Codex 可能改样式、改结构、改交互，也可能动到你不希望改的文件。

稳定的写法

请优化 /archives 页面，让它和首页风格一致。
背景：
- 首页是教程中心风格；
- /archives 现在像博客归档；
- 文章仍然来自 Halo 后台。

约束：
- 不要改数据库；
- 不要改文章 URL；
- 保留 Halo 的 archives.items 动态列表和分页；
- 移动端不能横向溢出。

验收：
- 页面标题是“全部教程”；
- 不出现“文章归档”；
- 桌面和手机截图都不裁字；
- Halo 容器保持 healthy。

这个任务说明把“审美目标”和“工程边界”同时说清楚，Codex 就不容易跑偏。

Bug 修复模板

问题：<粘贴错误现象或日志>
期望：<正确行为>
范围：相关代码大概率在 <文件/目录>
约束：
- 先定位根因；
- 不要做无关重构；
- 不要改公共接口，除非先说明原因。
验收：
- 复现问题；
- 修改后运行 <测试命令>；
- 总结根因和修复点。

功能开发模板

请实现 <功能>。
用户场景：<谁在什么情况下使用>
必须包含：
- <点 1>
- <点 2>
约束：
- 保持现有设计/代码风格；
- 不新增不必要依赖；
- 涉及共享逻辑时补测试。
验收：
- <命令 1> 通过；
- <手动验证步骤> 可完成。

代码审查模板

请审查当前未提交改动。
重点找：
- 真实 bug；
- 边界条件；
- 行为回归；
- 缺失测试。
不要评价风格偏好，除非它会导致维护风险。

常见坑

不要把多个互不相关的需求塞在同一次任务里。比如“重做页面、生成文章、改支付、部署上线”最好拆开。

不要只说“按最佳实践”。最佳实践必须落到你的项目约束里。

不要省略验收标准。没有验收，Codex 很难知道什么时候应该停。

官方来源

  • https://developers.openai.com/codex/learn/best-practices
  • https://developers.openai.com/codex/quickstart