第 2 章：需求碰撞 — 三角色审查你的想法

你将学到什么

• 为什么不急着写代码，先让三个角色"挑刺"
• 用 gstack 的三角色审查命令碰撞需求
• 把三方反馈汇总成结构化需求文档

2.1 为什么不直接开始写代码

很多开发者拿到需求就想动手。这很正常——写代码有成就感，讨论需求感觉在浪费时间。

但现实是：写错方向比写慢更可怕。

举几个常见的翻车场景：

gstack 提供了三个"虚拟角色"来帮你想清楚。每个角色从不同角度审视你的想法，找出你没想到的问题。

2.2 三个角色各管什么

flowchart TB
    R[NoteFlow 需求
在线记事本] --> CEO

    subgraph 三角色审查
        CEO["/plan-ceo-review
CEO 视角
━━━━━━━━━━
值不值得做？
核心功能是什么？
MVP 边界在哪？"]
        DES["/plan-design-review
设计师视角
━━━━━━━━━━
用户怎么用？
交互流程合理吗？
体验上有坑吗？"]
        ENG["/plan-eng-review
工程师视角
━━━━━━━━━━
技术可行吗？
复杂度多高？
有什么风险？"]
    end

    CEO --> S[汇总反馈]
    DES --> S
    ENG --> S
    S --> D[结构化需求文档]

    style CEO fill:#fef3c7,stroke:#d97706
    style DES fill:#ede9fe,stroke:#7c3aed
    style ENG fill:#dcfce7,stroke:#16a34a

CEO 视角 — 商业价值

CEO 关心的是：这个功能值不值得花时间做？

典型问题：

• 用户愿意用吗？解决什么痛点？
• 核心功能是什么？哪些可以砍掉？
• MVP（最小可用版本）应该包含什么？

设计师视角 — 用户体验

设计师关心的是：用户用起来爽不爽？

典型问题：

• 创建笔记要几步操作？
• 笔记多了怎么找？搜索还是分类？
• 手机上能用吗？响应式怎么处理？

工程师视角 — 技术可行性

工程师关心的是：能不能做、难不难做、有什么坑？

典型问题：

• localStorage 存 1000 条笔记会有性能问题吗？
• 搜索用前端过滤够用吗？需要索引吗？
• 数据结构怎么设计才能支持未来的功能扩展？

2.3 实战：三角色审查 NoteFlow

Step 1：准备需求描述

先写一个简单的需求说明：

NoteFlow — 在线记事本

核心功能：
- 创建、编辑、删除笔记
- 笔记列表展示
- 搜索笔记（按标题和内容）
- 分类标签（工作、生活、学习等）
- 数据持久化（刷新不丢失）

技术约束：
- 纯前端，无后端
- 使用 localStorage 存储数据
- React + Vite 技术栈

Step 2：CEO 审查

在 Claude Code 中输入：

/plan-ceo-review NoteFlow 在线记事本需求审查

需求：创建一个纯前端的在线记事本应用。
核心功能：笔记CRUD、搜索、分类标签、localStorage持久化。
目标用户：个人用户，需要轻量级的笔记管理工具。

你可能得到的反馈：

CEO 审查结果：

1. 核心价值明确 — 轻量级笔记管理，不依赖云端，隐私友好
2. MVP 建议 — 第一版先做 CRUD + localStorage，搜索和分类放到第二版
3. 风险 — localStorage 有 5MB 限制，大量笔记可能不够用。建议加一个"导出"功能作为备份
4. 优先级排序：
   • P0（必须有）：创建、编辑、删除、列表展示
   • P1（应该有）：搜索、分类标签
   • P2（可以有）：导出、主题切换、Markdown 支持

Step 3：设计师审查

/plan-design-review NoteFlow 交互设计审查

基于CEO审查结论，审查交互设计方面的问题。
用户流程：打开应用 → 看到笔记列表 → 点击创建 → 编写 → 保存 → 回到列表。

你可能得到的反馈：

设计师审查结果：

1. 创建流程 — 建议支持"快速创建"：一键新建空白笔记，标题自动生成"未命名笔记"
2. 列表设计 — 笔记多的时候需要分页或虚拟滚动，不能一次渲染 500 条
3. 搜索体验 — 搜索应该是实时的（输入即搜索），不需要按回车
4. 分类交互 — 拖拽分类 > 点击选择分类 > 下拉选择分类（推荐点击选择，实现简单且直观）
5. 空状态 — 第一次打开没有笔记时，需要引导文案（"点击 + 开始你的第一条笔记"）

Step 4：工程师审查

/plan-eng-review NoteFlow 技术可行性审查

基于CEO和设计师的审查结论，评估技术实现。
技术栈：React 18 + Vite + localStorage。
约束：纯前端，无后端。

你可能得到的反馈：

工程师审查结果：

1. 数据结构建议：

   // 每条笔记的数据结构
   {
     id: string,        // 唯一标识，用 crypto.randomUUID()
     title: string,     // 标题
     content: string,   // 内容
     tags: string[],    // 分类标签
     createdAt: number, // 创建时间戳
     updatedAt: number  // 更新时间戳
   }
   

2. 性能建议 — 搜索用前端过滤即可（1000 条以内），不需要搜索引擎。用 Array.filter() + String.includes() 足够
3. localStorage 限制 — 5MB 大约能存 2000-3000 条笔记（取决于内容长度），需要加容量检测
4. 架构建议 — 自定义 Hook 封装 localStorage 操作，组件只关心业务逻辑

2.4 汇总三方反馈

把三个角色的反馈整理成一份需求文档。在 Claude Code 中输入：

请汇总以下三角色审查的反馈，生成结构化的需求文档：

1. CEO 审查反馈：[粘贴上面 CEO 的反馈]
2. 设计师审查反馈：[粘贴设计师的反馈]
3. 工程师审查反馈：[粘贴工程师的反馈]

输出格式：按功能模块分组，标注优先级（P0/P1/P2），包含技术建议。

产出文档结构：

# NoteFlow 需求文档（三角色审查版）

## P0 功能（MVP 必须）
### 笔记 CRUD
- 创建笔记（支持快速创建）
- 编辑笔记（实时保存）
- 删除笔记（带确认）
- 笔记列表展示（支持排序）

### 数据持久化
- localStorage 存储
- 自定义 Hook 封装（useNotes）
- 数据结构：id, title, content, tags, createdAt, updatedAt
- 容量检测和提示

## P1 功能（第二版）
### 搜索
- 实时搜索（输入即搜索）
- 按标题和内容搜索
- 搜索结果高亮

### 分类标签
- 预设标签（工作、生活、学习）
- 自定义标签
- 按标签筛选

## P2 功能（未来可选）
- 导出功能
- 主题切换
- Markdown 支持

## 技术约束
- 纯前端，React 18 + Vite
- localStorage 上限约 5MB
- 搜索用前端过滤（不超过 1000 条）

2.5 为什么不直接用 brainstorming

superpowers 也有一个 /brainstorming 命令，它是一问一答式的需求澄清。对比一下：

建议： 项目初期用 gstack 三角色碰撞，等方向确定了再用 superpowers 的 brainstorming 细化技术方案。

动手做

1. 写出你的 NoteFlow 需求描述（不超过 10 行）
2. 依次运行 /plan-ceo-review、/plan-design-review、/plan-eng-review
3. 把三份反馈汇总成结构化需求文档
4. 保存到 docs/notes/requirement-review.md

本章小结

核心原则： 写代码前先想清楚。三个角色帮你找出你一个人想不到的问题。5 分钟的审查，省 5 天的返工。