第 8 章：双重代码审查 — gstack + superpowers 配合

你将学到什么

• superpowers 的代码审查流程：/requesting-code-review + /receiving-code-review
• gstack 的审查补充：/review + /qa
• 两条审查线各自关注什么
• 审查意见如何分类和处理

8.1 为什么需要双重审查

第 5 章的 subagent 流水线里已经有 review 了，为什么还要单独一章讲审查？

因为 subagent 流水线里的 review 是逐任务审查——每个任务做完就查，只看增量。但项目做完后还需要一次全局审查——看整体代码质量、一致性、潜在问题。

flowchart TB
    A[逐任务 review
subagent 流水线内] --> B["局部视角
每个文件单独看"]
    C[全局 code review
项目完成后] --> D["全局视角
跨文件、跨模块看"]

    B --> E["检查：功能对不对"]
    D --> F["检查：整体好不好"]

    style A fill:#dbeafe,stroke:#2563eb
    style C fill:#ede9fe,stroke:#7c3aed

8.2 superpowers 代码审查

/requesting-code-review — 发起审查

/requesting-code-review

这个命令让 Claude 对当前分支的所有改动做全面审查。

审查维度：

实战：审查 NoteFlow 全部代码

/requesting-code-review

审查 NoteFlow 项目的全部代码。
重点关注：
- React 组件是否有不必要的重渲染
- localStorage 操作是否有错误处理
- 搜索功能是否有性能问题
- 数据流是否清晰

审查结果示例：

Critical（必须修复）：

1. useNotes.js:23 — saveNotes 在 catch 中没有处理 localStorage 满的情况

   // 问题代码
   try {
     saveNotes(updatedNotes);
   } catch (e) {
     console.error(e);  // 只打了日志，用户不知道
   }
   
   // 修复建议
   try {
     saveNotes(updatedNotes);
   } catch (e) {
     setStorageWarning('存储空间不足，建议导出备份后清理');
   }
   

Important（建议修复）： 2. NoteList.jsx:45 — filter + map 可以合并为一次遍历 3. useSearch.js:12 — 搜索缺少防抖，每次按键都触发过滤

Suggestion（可选改进）： 4. TagSelector.jsx — 标签颜色建议从设计系统 CSS 变量中取，不要硬编码 5. NoteEditor.jsx — 编辑器可以加 autoFocus 属性提升体验

/receiving-code-review — 处理审查意见

如果审查是由其他人（或另一个 subagent）发起的，你用这个命令处理：

/receiving-code-review

它会读取审查意见，逐条判断哪些该修、哪些可以不修，然后自动修复 Critical 和 Important 级别的问题。

8.3 gstack 审查补充

superpowers 关注代码逻辑，gstack 关注用户体验和视觉一致性。

/review — gstack 代码审查

/review

gstack 的 review 更偏向产品视角：

gstack 审查结果：

1. 空状态设计 — 第一次打开应用时列表为空，但缺少引导用户创建第一条笔记的引导
2. 加载体验 — localStorage 读取是同步的，大量笔记时可能卡顿。建议加 loading 状态
3. 移动端适配 — 左右分栏在手机上变成上下布局后，编辑区域太小

/qa — 质量保证

/qa

更全面的质量检查：

QA 检查：

• ✅ 所有 P0 功能可用
• ✅ 搜索功能正常
• ✅ 分类筛选正常
• ⚠️ 大量笔记（500+）时列表渲染有延迟
• ⚠️ 长笔记内容（10000+ 字符）编辑时输入卡顿

8.4 双重审查的工作流

flowchart TB
    START["项目完成"] --> SP["superpowers
/requesting-code-review"]

    SP --> SP_R{"有 Critical?"}
    SP_R -- "有" --> FIX1["自动修复 Critical"]
    FIX1 --> SP
    SP_R -- "没有" --> GS["gstack
/review + /qa"]

    GS --> GS_R{"有体验问题?"}
    GS_R -- "有" --> FIX2["修复体验问题"]
    FIX2 --> GS
    GS_R -- "没有" --> DONE["审查通过 ✅"]

    style SP fill:#dbeafe,stroke:#2563eb
    style GS fill:#fef3c7,stroke:#d97706
    style DONE fill:#dcfce7,stroke:#16a34a

执行顺序： 先 superpowers（修逻辑 bug）→ 再 gstack（修体验问题）。

为什么不反过来？因为 gstack 审查的是"用户看到的"，如果代码逻辑有 bug，修完 bug 界面可能变化，gstack 的审查结果就过时了。

8.5 审查意见处理原则

动手做

1. 运行 /requesting-code-review，获取代码审查结果
2. 处理所有 Critical 和 Important 问题
3. 运行 /review 和 /qa，获取 gstack 的审查结果
4. 处理体验相关问题
5. 运行全量测试确认修复没有引入新问题

本章小结

核心原则： 先修逻辑（superpowers），再修体验（gstack）。双重审查确保代码既正确又好用。