每接一个新项目都要重新想一遍提示词，这件事在 Codex 里可以省掉。下面这八套模板按场景分好，遇到对应的活直接拿来用，把方括号里的内容换成自己项目的信息就行。
读项目：改代码之前先要一份理解报告
第一次让 Codex 接触某个项目，不要一上来就让它改代码。更稳的做法是先让它读项目，输出一份项目理解报告。你能提前看清几件事。它有没有看懂项目，判断的技术栈对不对，启动方式清不清楚。核心模块有没有找对，风险有没有提前暴露，也会一并交代。
模板里点名了六个部分。前面是技术栈，目录结构，启动方式。后面是测试命令，核心模块，以及后续修改风险。目录结构那一节要它说清哪些是核心目录，哪些不建议随便改。测试命令那一节要求逐条确认 test，lint，typecheck，build 四项。没有的就明确说没有。
收尾那一句是这套模板的关键：只输出项目理解报告，不要修改代码，输出完成后等我确认。
修 Bug 要先定位原因
修 Bug 模板的骨架是四栏。现象，复现步骤，期望结果，实际结果。再补上相关文件或者页面。填完这几栏，Codex 拿到的就不再是一句有 bug 的抱怨，而是一个能复现的场景。
后半段的要求同样重要：先定位原因，不要直接修改。让它先给出可能原因，需要查看的文件，修复方案，风险点。等你确认之后再动代码。
加功能和改页面，计划在前代码在后
加功能模板从功能描述起头，接着是入口位置，交互流程，视觉要求。再往后是数据来源和验收标准。写完这些再补一句：先阅读相关代码，给出实现计划，不要改无关文件，实现后运行测试并总结 diff。
前端页面模板在同样几栏之后多了一步，请先给出组件拆分方案，再开始实现。它把容易返工的地方提前拦住了。
剩下的四套：审查，重构，测试和文档
代码审查模板盯的是当前分支相对 main 的 diff，检查项有七条，从潜在 bug 一直到测试是否充分。它明确要求先输出 review 报告，不要直接改代码。
重构模板给的是目标和约束。目标是把可读性提上去，把重复代码减下来。约束是保持现有行为不变，不改公共 API，不引入新依赖。它还要你先写重构计划，说明怎么验证行为一致。
写测试模板要求覆盖正常路径，异常路径和边界条件，前提是不改业务逻辑，跑完测试报告结果。写文档模板列了八项内容，最后补一句：不要编造不存在的命令，必须基于项目文件判断。
这些模板省的是什么
共同点是把要什么和不允许做什么写在同一段里。前半段给需求，后半段给边界。边界说清楚的时候，Codex 的越权动作会明显变少。
拿模板用的时候留意一点，方括号里的内容必须换成自己项目的真实信息。验收标准写得越具体，后面返工越少。
