build-loop-cursor

Cursor 构建循环

质量门控的功能开发：不能只凭“编译通过”就发布——每次迭代都要完成构建、审查、端到端测试，并在用户听到“完成”之前修复问题。

工作来源

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

循环

每个任务（或每个收到提示的功能）都要执行以下流程。只有所有步骤都通过后才能继续。

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

2. 审查。 对所做修改运行 Cursor 的 /review。修复所有范围内的问题，包括你修改文件中的错误、安全问题、边缘情况、性能和代码风格。如果项目有设计系统规范（设计令牌文件、DESIGN.md 或主题配置），请据此检查 UI 修改——不要使用绕过令牌的硬编码颜色、字体或间距。对于未修改代码中的既有问题，在报告中注明，不要悄悄修复。重复运行 /review，直到没有问题为止。如果发现的问题与任务或规范相冲突，以规范为准，并指出这一分歧。

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

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

5. 继续。 将任务标记为 - [x]，更新计划中的任何进度或状态行，然后循环处理下一个任务，直到完成用户要求的范围。

6. 报告。 完成后，告知用户：已构建的内容和计划进度、修复的审查问题及任何延期事项、验证方式（测试和实际走过的流程），以及接下来需要用户关注的事项。对于不稳定或只完成部分验证的情况，要如实说明。

规则

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