需求发开我是这么做的

你有没有遇到过这种情况：

需求评审完，开发到一半，才发现有个关键交互没说清楚。问产品，产品说"当时说了"。你去翻记录，什么都没有。

或者更常见的——上线前代码评审，翻出来一堆"需求没实现"的问题。

这不是个人的问题，这是流程的问题。

我把自己踩过的这些坑，整理成了一套前端需求工作流，三个质量门禁，从 PRD 到上线，每个阶段都有明确的产出和通过标准。

为什么需要一套工作流

传统的开发流程是这样的：

产品给 PRD → 开发评审 → 开始写代码 → 联调 → 测试 → 上线

看起来没问题。但真实情况是：

PRD 不完整。用户场景没覆盖，边界条件没说，UI 交互靠"你懂的"。

没有基准。开发完了，谁来验证"需求是不是都实现了"？代码评审的时候大家看的是代码写法，不是需求对齐。

问题发现太晚。等到测试阶段才发现需求理解偏差，改动成本已经很高了。

这套工作流的核心思路是：把问题暴露在早期，而不是让它在后期爆炸。

工作流全貌

整个流程分五个阶段，三个质量门禁：

PRD 提取 → 资产扫描 → 技术方案 → 开发 → 代码评审
              ↑              ↑              ↑
           Gate 1         Gate 2         Gate 3
          需求确认        方案确认        质量门禁

Gate 1 和 Gate 2 阻止你带着模糊的认知往下走。Gate 3 确保最终产出符合预期。

下面逐个拆解。

Gate 1：需求确认——强制把模糊点逼出来

核心问题

大多数需求评审流于形式。产品讲完，开发点头，然后各自回去按自己的理解开发。

真正的需求评审应该是让双方的理解对齐，而不是信息传递。

Grill 模式

收到 PRD 的第一步，不是直接开工，而是提出至少 3 个追问——我叫它 Grill 模式。

追问的方向有 15 个检查点，最常见的几个：

Gate 1 的通过标准：所有高风险的"看不懂"内容都已确认，没有遗留。

这一关不通过，后面不能进入技术方案。

阶段产出

• 需求卡片.md — 前端需求摘要，这是后续所有阶段的需求基准
• 待确认事项.md — 追问记录，可以直接发给产品
• 业务背景.md — 为什么做这个需求，帮助理解优先级

Gate 2：技术方案——把开发拆成可执行的单元

先扫描资产，再出方案

很多团队写技术方案，上来就从零开始设计。其实项目里已经有大量可复用的组件、Hook、工具函数，只是没人整理过。

在出方案前，先做一次资产扫描：

• 扫描 components/、hooks/、utils/、services/
• 提取每个模块的 Props 签名、Hook 参数、函数接口
• 按功能族分类：form / data-display / feedback / navigation / layout

好处是：写技术方案时，直接标注"这里复用 useRequest Hook"，而不是又重新写一遍请求逻辑。

资产扫描结果在项目级缓存 7 天，同一个项目的多个需求可以共用，不用每次重新扫。

技术方案的颗粒度

技术方案最常见的问题：要么太粗，就是页面列表+几句话描述；要么太细，写成了代码。

合适的颗粒度是精确到组件/Props/联动逻辑，但不写具体实现：

模块：登录页
- 复用：FormBuilder 组件，配置 fields 数组
- 新增：CountdownButton 组件（props: onSend, countdown）
- 联动：发送验证码成功后，倒计时开始；60s 后恢复可点击
- 接口：POST /api/auth/send-code（手机号），POST /api/auth/login

这个颗粒度的方案，产品看得懂，开发拆任务也清晰。

方案确认：逐个模块来

Gate 2 有一个强约束：必须逐个模块与相关人员确认，不能只回复"都确认了"。

每个模块确认后，才能进入下一个。有任何 P0 风险未解决，禁止开始开发。

开发阶段：追踪而不是管理

进入开发阶段的前提是收到明确的"开始开发"指令——这不是废话，这是边界。技术方案阶段只出方案，不写代码。

开发过程的核心是实时更新任务清单：

- [x] 搭建登录页面框架
- [x] 集成 FormBuilder，配置手机号字段
- [ ] 实现 CountdownButton 组件
- [ ] 接入发送验证码接口
- [ ] 接入登录接口
- [ ] 错误提示处理

每完成一个任务立即打勾，不要等全部完成再更新。这样中途切换上下文时，可以立刻恢复进度。

开发完成后还有一个检查：对比技术方案 vs 实际实现，输出偏差报告。提前暴露"当时方案说用 X，结果用了 Y"的情况。

Gate 3：代码评审——需求对齐才是重点

代码评审在评什么

大多数代码评审只看代码质量：命名规范、函数长度、有没有 console.log。

这套工作流里，代码评审有5 个维度，前两个是最重要的：

需求对齐占 30%，因为代码写得再漂亮，需求没实现就是 0 分。

需求对照表

CR 报告里必须包含这张表：

这张表让评审者和被评审者都清楚："我们在对照同一份需求基准。"

问题优先级

CR 问题分三级：

• P0：必须修复，阻塞合并。例如：需求功能遗漏、接口调用错误、安全漏洞
• P1：重要问题，建议修复后合并。例如：与技术方案偏差、缺少错误处理
• P2：优化建议，可选。例如：magic number 提取常量、代码结构优化

评审结论：

• ≥ 80 分且无 P0 → 通过，可合并
• ≥ 70 分且无 P0 → 有条件通过，修复 P1 后可合并
• < 70 分或有 P0 → 需修改，修复后重新评审

P0 修复后必须重新评审

这是很多团队会走捷径的地方：P0 问题修完，直接标记"已修复"，就当过了。

这套工作流强制要求：P0 问题修复后必须重新评审，不能只回复"已修复"。

修复记录里要写清楚：修复方案是什么、验证方式是什么、代码位置在哪里。

三个质量门禁总结

┌──────────┬────────────┬──────────────────────┐
│  门禁    │  阶段      │  通过标准            │
├──────────┼────────────┼──────────────────────┤
│  Gate 1  │  需求确认  │  无遗留高风险模糊点  │
├──────────┼────────────┼──────────────────────┤
│  Gate 2  │  方案确认  │  所有模块已确认      │
│          │            │  无 P0 风险项        │
├──────────┼────────────┼──────────────────────┤
│  Gate 3  │  代码评审  │  评分 ≥ 80 分        │
│          │            │  且无 P0 问题        │
└──────────┴────────────┴──────────────────────┘

三个门禁的本质是：把问题发现的时间点前移。

Gate 1 在需求阶段发现问题，改一行 PRD。 Gate 2 在方案阶段发现问题，改一份文档。 Gate 3 在代码评审发现问题，改的是代码。

比在测试或上线后发现，成本低得多。

我的使用方式

我用 AI（Claude Code）来驱动这套工作流，命令很简单：

# 从 PRD 开始
/req-workflow --start ./PRD.md

# 开发完触发评审
CR

# 修复 CR 问题
/req-workflow --fix REQ-xxx

AI 会自动驱动每个阶段，强制执行 Grill 追问，生成需求卡片、技术方案、CR 报告，并归档到 .spec/ 目录供团队共享。

每个需求完成后，.spec/ 里会有完整的决策链路，三个月后翻出来还能知道当时为什么这么做。

适合什么场景

这套流程对 B 端产品、功能复杂度高、多人协作 的场景收益最大。

如果是做一个独立的小组件、改个样式 bug，不需要走完整流程，直接开工就好。

门禁的存在是为了降低成本，不是增加成本。判断的标准很简单：这个需求，如果理解错了，代价有多高？

这套工作流还在持续迭代，如果你有更好的实践，欢迎交流。