你的需求规格几分？五个维度一测便知
你的需求规格几分？五个维度一测便知
需求写得好，开发少返工。一测便知。
痛点
需求写得不清晰，开发做出来不是你想要的。 "
- "性能要好" → 做出来慢得要死
- "用户友好" → 交互混乱
- "异常情况要处理" → 根本没定义什么是异常
问题不在开发，在需求。
五维度评分
一个5分制的需求规格质量评估体系。
维度1：结构化编写
问题： 需求是否采用结构化风格编写？
5分： 结构化编写，模块整体提供，提供变更点，使用精确的字段名、提供字段表（定义数据来源、显示格式化、处理规则）、使用条目化的规则
3分： 部分结构化（50%-79%），关键模块有字段表
1分： 纯自然语言，无结构化
示例对比：
❌ 1分版本：
用户可以看到订单列表，包括订单号、日期、金额。✅ 5分版本：
## 订单列表模块
### 字段表
| 字段名 | 数据来源 | 显示格式 | 处理规则 |
|--------|---------|---------|---------|
| orderId | Order.id | 字符串，UUID格式 | 点击跳转订单详情 |
| orderDate | Order.createdAt | YYYY-MM-DD HH:mm | 时区：用户本地 |
| amount | Order.totalAmount | 货币，CNY | 保留2位小数 |
### 规则
- 默认按创建时间倒序
- 分页：每页20条
- 状态过滤：全部/待支付/已完成维度2：边界条件标注
问题： 需求是否明确标注边界条件（异常流、超时、空值、并发）？
5分： 全覆盖异常流、超时、空值、并发场景
3分： 部分覆盖（50%-79%边界条件）
1分： 无边界描述
示例对比：
❌ 1分版本：
调用第三方支付接口完成支付。✅ 5分版本：
## 支付流程
### 正常流
1. 用户点击支付 → 调用支付网关 → 返回支付URL → 跳转
2. 支付成功 → 接收回调 → 更新订单状态 → 发送通知
### 异常流
**超时场景：**
- 支付网关响应超时：3秒无响应 → 重试1次 → 仍失败 → 标记"支付超时"，通知用户
- 回调超时：30秒内未收到回调 → 主动查询支付状态 → 每30秒查询一次，最多3次
**空值场景：**
- 支付网关返回空URL → 标记"支付失败"，记录日志，通知用户
- 回调缺少必要参数 → 拒绝处理，返回400错误
**并发场景：**
- 用户重复点击支付 → 前端防抖（1秒） + 后端幂等检查（订单状态）
- 同一订单收到多次回调 → 基于transactionId去重，只处理第一次维度3：可量化验收标准
问题： 需求是否包含可量化验收标准？
5分： 所有关键指标都有可量化标准
3分： 部分指标可量化（50%-79%）
1分： 无可量化标准
示例对比：
❌ 1分版本：
系统要快，响应及时。✅ 5分版本：
## 性能要求
### 响应时间
- 订单列表加载：< 200ms（P95）
- 订单详情页：< 100ms（P95）
- 支付接口调用：< 500ms（P95）
### 并发能力
- 支持并发用户数：1000
- 支付接口TPS：100
### 可用性
- 系统可用率：99.9%（月度）
- 最大停机时间：43.2分钟/月
### 容量
- 订单数据保留：3年
- 单用户最大订单数：10,000维度4：AI需求反讲验证
问题： BA是否使用AI进行需求反讲验证？
5分： 每个需求都用AI反讲，确认理解一致
3分： 重要需求用AI反讲
1分： 不使用AI反讲
为什么重要：
自然语言有歧义。你以为说清楚了，AI反讲时才发现：
- "用户可以查看订单" → AI理解成"只能查看自己的订单"，你实际想的是"管理员可以查看所有订单"
- "订单要支持取消" → AI理解成"任何时候都能取消"，你实际想的是"发货前才能取消"
AI反讲流程：
1. BA写完需求
2. 发送给AI："请用你的话复述这个需求，重点关注：
- 谁能做什么
- 在什么条件下
- 有什么边界情况
3. AI反讲
4. BA对比：和我想的一致吗？
5. 不一致 → 修正需求 → 重新反讲
6. 一致 → 需求清晰，可以发给开发维度5：代码库工具集成
问题： BA是否使用Git和Markdown工作在代码库中？
5分： BA在代码库中工作，需求用Markdown管理，版本控制
3分： BA参与开发流程，但不使用代码库工具
1分： BA独立于代码库工作（Word文档、邮件、口头）
为什么重要：
需求变更追溯：
- Word文档：不知道改了什么、谁改的、什么时候改的
- Git：每个commit都有记录，可以diff、回滚
需求与代码同步：
- 独立文档：需求和代码脱节，开发按记忆做
- 代码库：需求和代码在同一repo，commit message关联需求
协作效率：
- 邮件往来：版本混乱，不知道哪个是最新版
- Pull Request：所有变更在一处讨论，代码review时顺便review需求
示例工作流：
1. BA在代码库中创建需求文档：requirements/user-order-list.md
2. 提交PR：需求review
3. 合并后，开发基于需求创建分支：feature/user-order-list
4. 开发完成，提交PR：代码review + 验证需求实现
5. 需求变更 → 更新Markdown → 新PR → 自动通知开发评分计算
总分计算
五个维度，每个1/3/5分：
- 5分维度 × 5 = 最高25分
- 3分维度 × 3 = 中等15分
- 1分维度 × 1 = 最低5分
总分范围：5-25分
等级划分
| 总分 | 等级 | 含义 |
|---|---|---|
| 20-25 | A | 优秀，需求清晰，开发效率高 |
| 15-19 | B | 良好，大部分清晰，有改进空间 |
| 10-14 | C | 一般，返工率高，需改进 |
| 5-9 | D | 差，需求混乱，返工是常态 |
典型案例
案例1：电商订单列表需求
维度评分：
结构化编写：5分 ✅
- 完整字段表，清晰规则
边界条件：5分 ✅
- 覆盖超时、空值、并发
可量化标准：5分 ✅
- 响应时间< 200ms（P95）
AI反讲：5分 ✅
- 用AI反讲确认理解
代码库工具：5分 ✅
- 在代码库中用Markdown管理
总分：25分，等级A
案例2：用户登录功能
维度评分：
结构化编写：3分 ⚠️
- 有字段表，但不完整
边界条件：1分 ❌
- 只写了正常流，没考虑异常
可量化标准：1分 ❌
- "响应要快"无量化
AI反讲：3分 ⚠️
- 重要需求用AI反讲
代码库工具：1分 ❌
- BA用Word文档
总分：9分，等级D
改进方向：
- 补齐边界条件（超时、失败重试、并发登录）
- 量化性能标准（< 100ms P95）
- 迁移到代码库，用Markdown管理
怎么快速提升
从1分到3分（最容易）
维度1：结构化编写
开始用字段表：
## 字段表
| 字段名 | 数据来源 | 显示格式 | 处理规则 |
|--------|---------|---------|---------|
| ... | ... | ... | ... |维度3：可量化标准
别写"性能好"，写"< 200ms（P95）"。
从3分到5分（中等难度）
维度2：边界条件
每次写需求时问自己：
- 如果超时怎么办？
- 如果返回空值怎么办？
- 如果并发请求怎么办？
维度4：AI反讲
写完需求，发给AI："请用你的话复述这个需求。"
看AI理解的是不是你想的。
从5分到满分（需要改变工作方式）
维度5：代码库工具
停止用Word、邮件。
开始用Git、Markdown、Pull Request。
一次性投入，长期收益。
为什么值得做
对开发
- 需求清晰 → 不用猜，照着做就行
- 边界明确 → 不用反复确认异常处理
- 标准可量化 → 知道做到什么程度算完成
对BA
- AI反讲 → 提前发现歧义
- 版本控制 → 需求变更可追溯
- 代码review时顺便review需求 → 一次沟通，两份产出
对项目
- 返工减少 → 需求一次说清，开发一次做对
- 交付加速 → 不在需求-开发-返工循环中浪费时间
- 质量提升 → 可量化标准让质量可见
最后
需求是开发的起点。
起点错了，后面都是错。
花时间把需求写清楚，是最划算的投资。
你的需求规格几分？
关注公众号 Fen9Pi，聊聊AI时代的工程实践。