用好 Codex（开发者进阶）
提示词怎么写
给 Codex 写提示词的四个要素：目标、上下文、约束和验证方式，附中途纠偏、计划模式和常见反例。
Codex 不需要特殊语法，用平常说话的方式描述就行，中文也完全可以。但对于稍大一点的任务，说清楚几件关键的事，效果会好很多。
四个要素
官方总结的 Codex 好提示词包含：
| 要素 | 说什么 | 例子 |
|---|---|---|
| 目标 | 你想要的行为或结果 | "保存设置后刷新页面，开关状态应该保留" |
| 上下文 | 相关代码在哪、怎么复现 | "相关代码在 @src/settings/，复现步骤是……" |
| 约束 | 哪些不能动 | "不要改 API 的结构，改动尽量小" |
| 验证 | 怎么确认改对了 | "改完跑 lint 和相关的测试，告诉我命令和结果" |
不必每次都写全，用得上的写上就行。
一个完整的例子
Bug：在设置页点"保存"，有时显示"已保存"但实际没保存。
复现：
1) npm run dev 启动
2) 打开 /settings
3) 切换"启用提醒"
4) 点保存
5) 刷新页面：开关又变回去了
约束：
- 不要改 API 的结构。
- 改动尽量小，能加回归测试就加一个。
先在本地复现这个 bug，再给出修复，然后跑检查。这个提示词里，复现步骤和约束比一句笼统的描述有用得多。
技巧
用 @ 指明文件
在 CLI 里输入 @ 可以搜索文件并插入路径。明确告诉 Codex 看哪些文件，比让它自己满仓库找更快、更省额度：
读一下 @src/api/client.ts 和 @src/api/schema.ts，讲讲请求和响应的数据结构，
重点说明哪些字段是必填、哪些可选。IDE 扩展会自动带上你打开的文件；CLI 里需要你自己用 @ 或 /mention 指出来。
大任务先出计划
多步骤的任务，先输入 /plan，让 Codex 调研并提出方案，你确认之后再动手：
/plan 把用户模块从 REST 迁移到 tRPC，先列出要改的文件和步骤中途纠偏
不用等 Codex 做完：
- 按 Enter 发送：消息会插进当前这一轮，用来改方向、补信息；
- 按 Tab 发送：消息排队到下一轮，适合"做完这个再做那个"。
第一句不用完美
先说个大概，看结果再追加具体要求，比一开始写一大段更高效：
测试部分保留，但把错误处理统一改成抛自定义的 AppError。让它自己检查
重要的任务，最后加一句检查要求：
完成前确认：所有新增的公共函数都有测试，并且 pnpm typecheck 能通过。常见反例
| 不太好 | 更好 |
|---|---|
| "优化一下代码" | "把 utils/date.ts 里重复的格式化逻辑提取成一个函数，行为保持不变，跑测试确认" |
| "修一下这个 bug"（没给信息） | 贴报错信息、复现步骤，说明你期望的结果 |
| "把整个项目重构一下" | 拆成几个小任务，每次一个模块，每步都验证 |
| 每次都重复交代"用 pnpm"、"改完跑 lint" | 写进 AGENTS.md，一劳永逸 |