review

代码能运行，不代表构建就完成了。只有代码正确，才算完成。

AI 发展迅速。速度快意味着，有些东西表面上能用，却偏离了架构、违背了设计系统，或遗漏了重要的边缘情况。这项技能会在问题累积成更大的麻烦之前将其发现。

每完成一个功能后都运行此技能。然后再继续。

此技能不会做什么

它不会修复任何问题，只会报告发现的问题，由开发者决定哪些问题重要，以及如何处理。不理解问题就修复，只会把问题埋起来，而非解决问题。

---

步骤 1 — 明确应该构建什么

开始审查前，先确定评判基准。

按以下顺序阅读：

• 如果存在，先阅读 /architect 中的实施计划
• 功能描述或任务要求
• 任何相关的上下文文件——架构边界、代码规范、设计规则

如果没有计划，请先让开发者描述该功能原本应该实现什么，再开始审查。不知道正确的标准，就无法验证是否正确。

---

步骤 2 — 从三个层面进行审查

层面 1 — 是否符合计划？

将已构建的内容与计划进行对比。

检查：

• 功能描述中的每一项内容——是否都已实现？
• 规划期间做出的决定——是否反映在代码中？
• 范围——实现是否恪守边界，还是添加了未要求的内容？

标出计划中有但实现中缺失的内容。也标出实现了但计划中没有的内容。

层面 2 — 是否遵循系统规范？

这是 AI 最常偏离规范的地方。功能虽然能用，却违反了项目所依赖的规则。

检查：

• 架构边界——代码是否位于正确的位置，并承担正确的职责？API 路由中没有 UI 逻辑，组件中没有数据库调用。无论项目的边界是什么，都应确认是否得到遵守。
• 设计系统——是否使用了正确的令牌、类和模式？是否有本该使用变量的硬编码值？是否有本该使用设计系统的原始颜色类？
• 代码规范——命名约定、文件组织、TypeScript 严格性、错误处理模式——是否与项目既定规范一致？
• 现有模式——在应该使用现有模式时，该功能是否引入了新模式？

层面 3 — 是否已达到生产就绪状态？

检查：

• 错误处理——发生问题时会怎样？错误是否被捕获并处理，还是功能会静默失败？
• 边缘情况——空状态、加载状态、缺少数据——是否都得到了处理？
• 控制台错误——浏览器或终端中是否有错误或警告？
• 明显的 Bug——是否有会导致真实用户明显无法使用的问题？

---

步骤 3 — 报告发现的问题

完成以上三个层面的审查后，生成一份清晰的报告。不要掩盖问题，也不要淡化问题。请如实报告，让开发者能够做出明智的决定。

## Review — [Feature Name]

### Layer 1 — Plan alignment
[PASS / ISSUES FOUND]
[List any gaps between what was planned and what was built]

### Layer 2 — System integrity
[PASS / ISSUES FOUND]
[List any architecture, design, or code standard violations]

### Layer 3 — Production readiness
[PASS / ISSUES FOUND]
[List any error handling gaps, edge cases, or obvious bugs]

### Summary
[X] issues found across [Y] layers.

[If no issues: "No issues found. This feature is ready to ship."]
[If issues: "Resolve the above before moving to the next feature."]

---

步骤 4 — 由开发者决定

提交报告后，停止操作。不要开始修复。除非开发者要求，否则不要提出修复建议。

等待开发者：

• 要求你修复特定问题
• 告知某个问题是有意为之，可以忽略
• 确认所有问题都已解决，可以继续

由开发者决定质量是否达标。你负责提供信息。

---

严重程度指南

并非所有问题都同等重要。请参考以下指南，帮助开发者确定优先级：

严重 — 继续之前必须修复

• 违反架构边界，导致未来功能无法实现
• 缺少错误处理，导致故障未被发现
• 计划中的功能完全缺失

重要 — 尽快修复

• 偏离设计系统，导致 UI 不一致
• 违反代码规范，问题会在整个代码库中不断累积
• 真实用户会遇到的边缘情况

轻微 — 方便时修复

• 不影响行为的命名不一致
• 缺少优化
• 不影响设计系统的样式问题

请为每个问题标注严重程度，以便开发者快速确定优先级。

---

标准

这项技能要回答的问题不是“它能不能运行？”

而是“它是否正确？”

能运行和正确并不是一回事。某项功能今天可以正常运行，明天却可能破坏整个项目。代码审查旨在发现两者之间的差异。