build-loop-cursor

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Cursor Build Loop

Cursor 构建循环

Quality-gated feature work: nothing ships on "it compiles" — every increment is built, reviewed, tested end to end, and fixed before the user hears "done."

质量管控的功能开发：绝不以「代码可编译」作为交付标准——每一处增量都需经过构建、审查、端到端测试与修复，之后才会告知用户「已完成」。

Source of work

工作来源

A plan file exists (roadmap, refactor plan, or task list with
```
- [ ]
```
checkboxes — search the repo): work the first unchecked task. Tasks are ordered intentionally — never skip ahead. If the plan references spec docs, read only the sections relevant to the current task.
No plan (or the request is outside it): build from the user's prompt. Restate it as a verifiable goal with 2–4 success criteria and confirm scope in one message before building.

存在计划文件（路线图、重构计划或带有
```
- [ ]
```
复选框的任务列表——搜索仓库）：处理第一个未勾选的任务。任务顺序是有意安排的——切勿跳步。若计划引用了规范文档，仅阅读与当前任务相关的章节。
无计划（或请求超出计划范围）：根据用户提示进行构建。在开始构建前，先将提示重述为包含2-4条成功标准的可验证目标，并通过一条消息确认范围。

The loop

循环流程

Run per task (or per prompted feature). Do not advance until every step passes.

Build. Implement exactly what the task specifies. Simplest implementation that satisfies it, surgical changes, no speculative scope. Match existing project conventions.
Review. Run Cursor's /review
on the changes. Fix all findings in scope — bugs, security issues, edge cases, performance, style in files you touched. If the project has a design system spec (design tokens file, DESIGN.md, theme config), check UI changes against it — no hardcoded colors, type, or spacing that bypass tokens. Note pre-existing issues in untouched code for the report instead of fixing silently. Re-run
```
/review
```
until clean. If a finding contradicts the task or spec, the spec wins — flag the disagreement.
Test end to end. Run the task's verification step (or the success criteria). Run the full test suite — everything that passed before must still pass. Add tests for new logic. Then exercise the feature as a user would: run the app, walk the real flow including empty, loading, and error states.
Fix. Anything testing finds goes back through the loop: fix →
```
/review
```
→ re-test. Never mark a failing task complete; never start the next task with the app broken.
Continue. Mark the task
```
- [x]
```
, update any progress/status line in the plan, and loop to the next task until the requested scope is complete.
Report. When done, tell the user: what was built and plan progress, review findings fixed and anything deferred, how it was verified (tests + flow walked), and what needs their attention next. Be honest about anything flaky or partially verified.

针对每个任务（或每个提示的功能）执行此流程。在每一步都通过前，不得进入下一步。

构建：严格按照任务要求实现功能。采用满足需求的最简实现方式，仅做必要修改，不添加预期外的功能范围。遵循现有项目的编码规范。
审查：对变更运行Cursor的**
```
/review
```
**命令。修复所有范围内的问题——包括你修改的文件中的bug、安全问题、边缘情况、性能问题和代码风格问题。若项目有设计系统规范（设计令牌文件、DESIGN.md、主题配置），检查UI变更是否符合规范——不得绕过令牌硬编码颜色、字体或间距。对于未修改代码中存在的原有问题，需在报告中注明，而非默默修复。重复运行
```
/review
```
直至无问题。若发现的问题与任务或规范冲突，以规范为准——标注该分歧。
端到端测试：执行任务的验证步骤（或成功标准）。运行完整测试套件——所有之前通过的测试必须仍能通过。为新增逻辑添加测试。然后以用户的方式使用该功能：启动应用，遍历实际流程，包括空状态、加载状态和错误状态。
修复：测试发现的任何问题都需重新进入循环：修复→
```
/review
```
→重新测试。绝不能标记失败的任务为已完成；应用处于故障状态时，绝不能开始下一项任务。
继续：将任务标记为
```
- [x]
```
，更新计划中的任何进度/状态行，然后循环至下一项任务，直至完成请求的范围。
报告：完成后，告知用户：构建的内容与计划进度、已修复的审查问题及任何暂缓处理的问题、验证方式（测试+流程遍历），以及接下来需要他们关注的事项。对于任何不稳定或仅部分验证的内容，需如实说明。

Rules

规则

Skipped review or untested work = unfinished work.
Don't relitigate plan decisions; if a task seems wrong, ask one specific question rather than guessing.
Discovered work no task covers? Surface it and propose a task — never silently expand scope.

跳过审查或未测试的工作=未完成的工作。
不要重新讨论计划决策；若任务看起来有问题，提出一个具体问题而非自行猜测。
发现计划未涵盖的工作？需提出并建议新增任务——切勿默默扩大范围。