build-loop-codex

Codex 构建循环

质量门控的功能开发：不能只凭“能编译”就发布——每个增量都要经过构建、审查、端到端测试，并修复问题，然后才能告诉用户“完成”。

工作来源

• 存在计划文件（路线图、重构计划或带有 - [ ] 复选框的任务列表——在代码库中搜索）：处理第一个未勾选的任务。任务顺序经过刻意安排——绝不跳过前面的任务。如果计划引用了规范文档，只阅读与当前任务相关的部分。
• 没有计划（或请求不在计划范围内）： 根据用户的提示开展工作。将其重述为可验证的目标，列出 2–4 条成功标准，并在开始构建前用一条消息确认范围。

循环

每个任务（或每项用户提出的功能）都运行一遍。所有步骤通过之前，不得进入下一项。

1. 构建。 严格按任务要求实现。采用能满足要求的最简单实现，进行精准修改，不擅自扩展范围。遵循项目现有约定。

2. 审查。 运行 /review 并选择 "Review uncommitted changes"。如果改动涉及身份验证、支付、用户输入或数据访问，再通过 "Custom review instructions" 进行第二轮审查（例如：“重点检查安全漏洞和未经验证的输入”）。修复范围内的所有问题——包括你修改文件中的错误、安全问题、边界情况、性能和代码风格。如果项目有设计系统规范（设计令牌文件、DESIGN.md 或主题配置），则根据该规范检查 UI 改动——不得使用绕过令牌的硬编码颜色、字体或间距。在报告中注明未修改代码中已有的问题，不要悄悄修复。反复运行 /review，直到没有问题。如果审查发现与任务或规范相矛盾，以规范为准——并指出分歧。

3. 端到端测试。 运行任务的验证步骤（或成功标准）。运行完整测试套件——此前通过的所有测试都必须继续通过。为新增逻辑补充测试。然后像用户一样体验该功能：运行应用，走完真实流程，包括空状态、加载状态和错误状态。

4. 修复。 测试发现的任何问题都要重新进入循环：修复 → /review → 重新测试。绝不将失败的任务标记为完成；应用存在问题时，绝不开始下一项任务。

5. 继续。 将任务标记为 - [x]，更新计划中的进度或状态行，然后进入下一项任务并重复循环，直到完成请求范围内的所有工作。

6. 报告。 完成后，告知用户：构建了什么以及计划进度、修复的审查发现及任何延期事项、如何验证（测试和体验的流程），以及接下来需要他们关注的事项。对于不稳定或仅部分验证的内容，要如实说明。

规则

• 跳过审查或未测试的工作都不算完成。
• 不要重新争论计划决策；如果任务似乎有问题，就提出一个具体问题，而不是自行猜测。
• 发现没有任务涵盖的工作？指出来并建议新增任务——绝不悄悄扩大范围。