需求Spce评审方案
把“需求标准与检测”从一次性验收完整 PRD，改成“模块化、增量式、可追踪”的机制：每个模块有自己的 Spec 评分，同时项目有综合评分；需求评审也从“大评审”改成“分层评审 + 变更评审”。
核心原则
- 不要求 1.0 一次完整：允许需求按模块、阶段、版本逐步形成。
- 不追求静态稳定：允许变更，但要求变更有记录、有影响分析、有重新评分。
- 不只评“文档完整度”：重点评估 AI/研发/测试能否基于当前 Spec 正确执行。
- 模块评分用于局部推进，综合评分用于项目风险判断和上线决策。
一、标准如何设计
建议把需求标准拆成两层：
1. 模块级 Spec 标准
每个模块单独评分，适用于：
- 用户登录模块
- 订单模块
- 支付模块
- 权限模块
- 报表模块
- AI Agent 某个能力模块
- 后台配置模块
每个模块 Spec 至少包含：
- 目标说明：这个模块解决什么问题，服务谁。
- 范围边界：做什么、不做什么。
- 核心流程：用户/系统如何完成主要动作。
- 输入输出：字段、参数、状态、数据结构。
- 业务规则：判断条件、限制、优先级、异常规则。
- 状态变化：状态机、生命周期、数据流转。
- 异常场景：失败、冲突、超时、重试、权限不足。
- 验收标准：什么情况下算完成。
- 依赖关系：依赖哪些模块、接口、数据、角色。
- 变更记录：当前版本相对上一版改了什么。
模块 Spec 不一定一开始就 100 分，但要能支撑当前阶段的开发和验证。
2. 项目级综合标准
项目级不重复评每个模块细节，而是评：
- 模块之间是否衔接
- 关键链路是否闭环
- 风险是否可控
- 版本范围是否清楚
- 是否具备进入开发/测试/上线的条件
项目级综合标准关注的是“整体能不能往前走”。
二、模块评分如何操作
建议每个模块按 100 分评分，分成 8 个维度。
| 维度 | 分值 | 说明 |
|---|---|---|
| 目标清晰度 | 10 | 模块目标、用户价值是否明确 |
| 范围边界 | 15 | 做什么、不做什么是否清楚 |
| 流程完整性 | 15 | 主流程、分支流程是否完整 |
| 规则明确性 | 20 | 业务规则、权限、状态、条件是否可执行 |
| 数据与接口 | 10 | 输入输出、字段、接口依赖是否明确 |
| 异常处理 | 10 | 失败、边界、冲突场景是否覆盖 |
| 验收标准 | 15 | 是否能转化为测试用例和验收项 |
| 变更可追踪 | 5 | 是否有版本、变更原因、影响范围 |
模块评分等级
| 分数 | 等级 | 含义 | 建议动作 |
|---|---|---|---|
| 90–100 | A | 可直接开发/测试 | 进入执行 |
| 75–89 | B | 基本可开发，有少量风险 | 标记风险后推进 |
| 60–74 | C | 可做原型或技术预研，不适合完整开发 | 补齐关键规则 |
| 40–59 | D | 需求不稳定或缺口较大 | 需要重新梳理 |
| <40 | E | 无法执行 | 不进入开发 |
模块评分的作用
模块评分主要用于：
- 判断某个模块能不能进入开发
- 识别该模块的需求风险
- 指导 AI 生成代码、测试、用例时的可靠性
- 让产品、研发、测试对“是否清楚”有共同标准
- 避免因为一个模块不清楚拖住整个项目
例如：
| 模块 | 评分 | 状态 |
|---|---|---|
| 登录注册 | 88 | 可开发 |
| 订单创建 | 76 | 可开发，需补异常规则 |
| 支付退款 | 62 | 只能做方案，不建议进入开发 |
| 权限管理 | 91 | 可开发 |
| 报表统计 | 54 | 需重新定义口径 |
这样项目不需要等所有模块都完美，成熟模块可以先走。
三、综合评分如何操作
综合评分不是简单平均分，建议采用“加权 + 阻断项”的方式。
1. 模块加权
不同模块重要性不同，不能简单平均。
例如一个电商项目：
| 模块 | 权重 | 模块分 |
|---|---|---|
| 用户账户 | 15% | 85 |
| 商品管理 | 15% | 80 |
| 购物车 | 10% | 78 |
| 订单 | 25% | 72 |
| 支付 | 25% | 60 |
| 报表 | 10% | 70 |
综合分：
综合分 = Σ 模块分 × 模块权重但如果支付模块只有 60 分，即使综合分看起来还可以，也不能认为项目整体安全。
所以需要阻断项。
2. 设置阻断项
以下情况不允许进入下一阶段：
- 核心链路模块低于 75 分
- 高风险模块没有明确负责人
- 关键业务规则缺失
- 验收标准无法转化为测试用例
- 模块之间接口或状态不一致
- 涉及资金、权限、数据安全但规则不完整
- 存在未确认的重大产品决策
也就是说：
综合评分 = 加权分 + 阻断项判断不是只看分数。
3. 综合评分等级
| 综合分 | 状态 | 说明 |
|---|---|---|
| 90–100 | 项目需求成熟 | 可进入完整开发/测试 |
| 80–89 | 基本成熟 | 可进入开发，跟踪风险 |
| 70–79 | 局部成熟 | 只允许成熟模块推进 |
| 60–69 | 风险较高 | 适合原型、技术验证、补需求 |
| <60 | 不建议启动 | 需要重新梳理 |
四、模块评分和综合评分分别起什么作用
模块评分的作用
模块评分回答的是：
这个模块现在能不能做？它服务于：
- 模块开发排期
- AI 生成代码前的输入质量判断
- 测试用例生成
- 模块风险识别
- 产品补需求优先级
适合用在日常迭代中。
综合评分的作用
综合评分回答的是：
这个项目/版本整体能不能推进？它服务于：
- 项目立项
- 版本计划
- 资源投入
- 上线风险判断
- 跨模块依赖协调
- 管理层决策
适合用在里程碑节点。
五、需求评审如何操作
建议把需求评审拆成三类，不再只做一次“大评审”。
1. 模块需求评审
适用于单个模块 Spec 完成后。
参与角色
- 产品负责人
- 研发负责人
- 测试负责人
- 设计/运营/业务方，视情况参与
- AI 工具负责人或 Prompt/Spec 负责人，如果公司使用 AI 辅助开发
评审内容
重点不是逐字读文档，而是回答这些问题：
- 这个模块目标是否明确？
- 范围边界是否清楚？
- 主流程是否完整？
- 异常场景是否覆盖？
- 数据字段是否明确？
- 权限规则是否明确？
- 验收标准是否可测试？
- 是否存在未决问题？
- 是否能交给 AI/研发直接执行？
输出物
每次模块评审后必须输出：
- 模块评分
- 风险清单
- 待确认问题
- 是否允许进入开发
- 需要补充的 Spec 项
- 下一次评审时间，若需要
2. 版本综合评审
适用于一个版本准备进入正式开发、联调或上线前。
评审内容
看整体，不纠结单个字段细节：
- 本版本包含哪些模块
- 哪些模块已达到开发标准
- 哪些模块只能做原型或延期
- 核心链路是否闭环
- 跨模块接口是否一致
- 状态流转是否一致
- 是否存在阻断项
- 是否需要调整版本范围
输出物
- 项目综合评分
- 版本范围确认
- 可开发模块列表
- 暂缓模块列表
- 阻断项清单
- 风险负责人
- 开发/测试准入结论
3. 变更评审
这是最关键的，因为真实项目中需求一定会变。
什么情况必须变更评审
- 新增模块
- 删除模块
- 修改核心流程
- 修改数据结构
- 修改权限规则
- 修改计费、支付、审批、风控规则
- 修改验收标准
- 影响其他模块接口或状态
变更评审不用很重
可以用轻量模板：
变更内容： 变更原因： 影响模块： 影响接口/数据： 影响测试用例： 是否影响排期： 是否需要重新评分： 决策结果： 负责人：变更后的动作
- 更新模块 Spec 版本
- 重新计算模块评分
- 如影响核心链路，重新计算综合评分
- 通知研发、测试、AI 生成链路重新同步
六、推荐的实际工作流
可以采用下面这套流程。
阶段 1：需求拆模块
先不要写大而全的 PRD，而是拆成：
项目 → 版本 → 模块 → 场景 → 规则 → 验收项例如：
客户管理系统 V1 - 客户档案模块 - 跟进记录模块 - 销售机会模块 - 权限模块 - 数据报表模块阶段 2：模块 Spec 初稿
每个模块用统一模板写，允许不完整，但必须标记：
- 已确认
- 待确认
- 暂不做
- 有风险
不要让模糊内容混在正文里。
阶段 3：AI 初检
可以让 AI 先做结构化检查：
- 是否有缺失字段
- 是否有矛盾规则
- 是否缺异常场景
- 是否缺验收标准
- 是否能生成测试用例
- 是否能生成接口设计
- 是否能生成开发任务
AI 输出：
模块评分 问题清单 风险等级 建议补充项 可生成的研发任务 不可生成的原因阶段 4：人工评审
AI 评分不能直接作为最终结论，必须经过人工确认。
人工重点看：
- 业务目标是否正确
- 优先级是否合理
- 规则是否符合真实业务
- 取舍是否符合版本目标
- 风险是否可接受
阶段 5：准入决策
每个模块给出准入状态：
| 状态 | 含义 |
|---|---|
| 可开发 | Spec 足够清楚 |
| 可原型 | 可以做 Demo，但不能做最终实现 |
| 待补充 | 缺少关键规则 |
| 暂缓 | 当前版本不做 |
| 阻断 | 影响其他模块或核心链路 |
阶段 6：持续变更管理
每次需求变化都不需要大动干戈，但要做到：
- 有版本号
- 有变更记录
- 有影响分析
- 必要时重新评分
- 同步到研发和测试
七、适合公司内部落地的评分机制
建议采用“三个分数 + 一个结论”。
1. 模块成熟度分
回答：
这个模块描述清楚了吗？例如：订单模块 78 分。
2. 模块风险分
回答：
这个模块做错的代价高不高？例如：
| 风险等级 | 说明 |
|---|---|
| P0 | 资金、安全、合规、核心数据 |
| P1 | 核心流程、关键客户体验 |
| P2 | 普通业务功能 |
| P3 | 辅助功能、后台配置 |
同样 75 分，支付模块和帮助中心模块的处理方式不同。
3. 项目综合分
回答：
这个版本整体准备好了吗？它用于版本层面的决策。
4. 准入结论
最终不要只给分，要给结论：
订单模块：78 分，P1 风险，可开发，但需在联调前补充退款异常规则。 支付模块：63 分，P0 风险，不允许进入正式开发，只允许做技术预研。 报表模块：70 分，P2 风险，可做低保真原型，统计口径确认后进入开发。这个结论比单纯评分更有价值。
八、建议的准入规则
可以在公司内部设定这样的门槛：
进入原型设计
模块评分 ≥ 60 无重大方向性争议进入正式开发
模块评分 ≥ 75 验收标准完整 关键流程明确 无 P0/P1 未决问题进入测试
模块评分 ≥ 80 测试用例可完整生成 异常场景已确认 接口和数据结构已冻结进入上线
综合评分 ≥ 85 核心模块全部 ≥ 80 无阻断项 P0/P1 风险关闭 变更记录完整九、AI 在其中怎么用
AI 不应该只用来写需求，而应该用于“检查需求是否可执行”。
AI 可以做
- Spec 完整性检查
- 矛盾规则检查
- 缺失场景识别
- 验收标准生成
- 测试用例生成
- 接口草案生成
- 用户故事拆分
- 开发任务拆分
- 影响范围分析
- 变更对比分析
AI 不应单独决定
- 业务优先级
- 版本范围
- 商业取舍
- 风险接受
- 上线决策
- 合规判断
AI 是“需求质检员 + 结构化助手”，不是最终评审人。
十、推荐落地模板
每个模块可以统一用这个结构：
模块名称： 所属版本： 模块负责人： 当前状态：草稿 / 待评审 / 可开发 / 开发中 / 已冻结 / 已上线 一、模块目标 二、使用角色 三、范围说明 - 本期做 - 本期不做 四、核心流程 五、业务规则 六、数据字段 七、接口依赖 八、状态流转 九、异常场景 十、权限规则 十一、验收标准 十二、待确认问题 十三、风险点 十四、变更记录 十五、评分结果评分结果可以这样写：
模块成熟度：82/100 风险等级：P1 准入结论：可进入开发 限制条件：测试前需补充异常退款规则 评审时间：2025-xx-xx 评审人：产品、研发、测试最终建议
不要把需求标准设计成“完整 PRD 评分系统”，而要设计成：
模块 Spec 评分 + 项目综合评分 + 阻断项机制 + 变更评审机制最实用的落地方式是：
- 模块评分决定“这个模块能不能做”。
- 综合评分决定“这个版本能不能推进”。
- 阻断项决定“有没有不能冒险的问题”。
- 变更评审保证“需求变化后大家仍然同步”。
- AI 负责初检、补漏、生成用例，人工负责业务判断和最终准入。
这样既适应公司内项目需求逐步明确的现实，也能让 AI 在不确定需求中持续发挥作用。