用 Codex CLI 按构建→审查→测试→修复闭环推进计划…

当用 Codex CLI 在任意代码库中实现计划文件里的任务或直接功能请求，并希望每个增量都经过构建、`/review`、端到端测试与修复后才交付时使用。

适用场景

解决思路

1. 根据工作来源选择任务：若仓库存在计划文件（roadmap、refactor plan 或带 `- [ ]` 复选框的任务列表），先搜索仓库，然后处理第一个未勾选任务；任务顺序是有意安排的，绝不跳过。
2. 若计划引用 spec docs，只阅读与当前任务相关的章节。
3. 若无计划或请求不在计划内：基于用户 prompt 构建；先把 prompt 复述为可验证目标，并列出 2–4 条成功标准，在开始构建前用一条消息确认范围。
4. 对每个任务（或直接提示的功能）运行构建循环；每一步都通过前不要推进。
5. 构建：严格实现任务指定的内容；采用满足要求的最简实现；做外科手术式改动；不要引入推测性范围；匹配现有项目约定。
6. 审查：运行 `/review` 并选择「Review uncommitted changes」。
7. 若改动涉及 auth、payments、user input 或 data access，通过「Custom review instructions」再跑一次审查，例如 `Focus on security vulnerabilities and unvalidated input`。
8. 修复审查发现的范围内所有问题：bug、安全问题、边界情况、性能，以及你触碰文件中的风格问题。
9. 若项目有设计系统规范（design tokens file、DESIGN.md、theme config），检查 UI 改动是否符合：不得硬编码颜色、字体或间距来绕过 tokens。
10. 未触碰代码中的既有问题在报告中注明，不要静默修复。
11. 重复运行 `/review` 直到干净。
12. 若审查发现与任务或 spec 矛盾，以 spec 为准，并标记该分歧。
13. 端到端测试：运行任务的验证步骤（或成功标准）。
14. 运行完整测试套件：之前通过的所有内容必须仍然通过。
15. 为新逻辑添加测试。
16. 像用户一样实际使用功能：运行应用，走真实流程，包括 empty、loading 和 error states。
17. 修复：测试发现的任何问题都回到循环：修复 → `/review` → 重新测试。
18. 绝不把失败任务标记为完成；绝不在应用已损坏时开始下一任务。
19. 继续：将任务标记为 `- [x]`，更新计划中的任何进度/状态行，然后循环到下一任务，直到请求范围完成。
20. 报告：完成后告诉用户构建了什么及计划进度、修复了哪些审查发现及哪些延期、如何验证（测试 + 走查的流程），以及下一步需要他们关注什么。
21. 对任何 flaky 或仅部分验证的内容保持诚实。
22. 规则：跳过审查或未测试的工作等于未完成工作。
23. 规则：不要重新争论计划决策；若任务看起来不对，问一个具体问题而不是猜测。
24. 规则：若发现没有任务覆盖的工作，暴露它并提议一个任务；绝不静默扩大范围。

适用边界 · 注意事项

• 没有安装或不能使用 OpenAI Codex CLI，尤其无法使用 `/review` 及其「Review uncommitted changes」「Custom review instructions」审查流程时。
• 纯一次性或琐碎改动，且明确不需要审查、测试或端到端验证时。
• 代码库无法运行应用或测试，无法完成端到端验证时；此时不应声称工作已完成。