build-loop-claude-code

Claude Code 构建循环

质量把关的功能开发：不会因为“编译通过”就发布——每次迭代都要经过构建、审查、端到端测试，并修复问题，然后才能告诉用户“完成了”。

工作来源

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

循环

每个任务（或每项用户提出的功能）都要执行一轮。所有步骤通过前，不得继续。

1. 构建。 严格按照任务要求实现。采用满足要求的最简单实现，进行精准修改，不扩展到推测性范围。遵循项目现有惯例。

2. 审查。 对修改过的代码运行 /review。如果改动涉及身份验证、支付、用户输入或数据访问，还要运行 /security-review。修复范围内的所有问题——包括你改动文件中的 bug、安全问题、边缘情况、性能问题和风格问题。如果项目有设计系统规范（设计令牌文件、DESIGN.md 或主题配置），就按其检查 UI 改动——不得使用绕过令牌的硬编码颜色、字体或间距。报告中注明未改动代码中已有的问题，不要悄悄修复。反复运行 /review，直到没有问题。如果审查结果与任务或规范冲突，以规范为准——并指出这一分歧。

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

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

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

6. 报告。 完成后，告知用户：完成了什么以及计划进度、修复了哪些审查发现的问题以及有哪些问题延期处理、如何验证（测试＋实际走查的流程），以及接下来需要他们关注什么。对任何不稳定或只完成部分验证的内容如实说明。

规则

• 跳过审查或未测试的工作 = 未完成的工作。
• 不要反复争论计划中的决定；如果某项任务似乎有问题，就提出一个具体问题，而不是猜测。
• 如果发现的工作没有对应任务，就指出来并提议添加任务——绝不要悄悄扩大范围。