提示词不是口令，是任务单
官方最佳实践强调：给出真实上下文，描述要完成的工作，并明确什么算完成。对 Codex 来说，最有效的提示词通常像一张简洁的工程任务单。
五件套#
- 目标：最终行为发生什么变化。
- 上下文：问题位置、相关文件、Issue、截图或失败日志。
- 边界：允许改什么，不允许改什么。
- 验证：必须运行哪些测试或检查。
- 交付：最后需要代码、文档、报告还是 PR。
目标：为设置页增加键盘导航。
上下文：入口在 src/settings，设计稿见 @settings.png。
边界：保持现有视觉和公共 API；不要新增依赖。
验证：运行设置页单测、类型检查，并用浏览器走完 Tab/Shift+Tab。
交付：实现代码、测试，以及一段包含验证证据的变更摘要。
大任务先计划#
对跨模块修改，先让 Codex：
- 追踪现有调用链；
- 找出仓库约定和相关测试；
- 给出分阶段计划；
- 标记需要产品判断或权限升级的点。
计划确认后再执行。这样做的价值不是增加仪式，而是尽早发现范围理解错误。
用约束替代微操#
告诉 Codex“必须保持的性质”，比逐行指挥更有效。例如：
- 保持向后兼容；
- 不改变数据库 schema；
- 只做最小修复；
- 先复现再修改；
- 不压制类型错误；
- 给所有外部事实附来源。
让完成可验证#
避免“看起来应该可以”。要求记录命令、退出状态和关键结果；涉及 UI 时要求截图或实际交互；涉及数据时要求行数、汇总值和异常清单。