build-loop-codex

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Codex Build Loop

Codex 构建循环

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 /review
and select "Review uncommitted changes". If the change touches auth, payments, user input, or data access, run a second pass via "Custom review instructions" (e.g. "Focus on security vulnerabilities and unvalidated input"). 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.

每个任务（或每个提示的功能）都需执行此流程。每一步通过后才能进入下一步。

构建：严格按照任务要求实现功能。采用满足需求的最简实现方式，仅做必要修改，不添加额外的预期功能。遵循现有项目的规范。
审查：运行**
```
/review
```
命令并选择“审查未提交的变更”。如果变更涉及认证、支付、用户输入或数据访问，需通过“自定义审查指令”**进行二次审查（例如：“重点关注安全漏洞和未验证的输入”）。修复所有范围内的问题——包括你修改的文件中的漏洞、安全问题、边缘情况、性能问题和代码风格问题。如果项目有设计系统规范（设计令牌文件、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.

跳过审查或未测试的工作=未完成的工作。
不要重新讨论计划决策；如果任务看起来有问题，提出一个具体的问题而非猜测。
发现计划中未涵盖的工作？提出该问题并建议添加任务——绝不擅自扩大范围。