把“需求标准与检测”从一次性验收完整 PRD，改成“模块化、增量式、可追踪”的机制：每个模块有自己的 Spec 评分，同时项目有综合评分；需求评审也从“大评审”改成“分层评审 + 变更评审”。

核心原则

• 不要求 1.0 一次完整：允许需求按模块、阶段、版本逐步形成。
• 不追求静态稳定：允许变更，但要求变更有记录、有影响分析、有重新评分。
• 不只评“文档完整度”：重点评估 AI/研发/测试能否基于当前 Spec 正确执行。
• 模块评分用于局部推进，综合评分用于项目风险判断和上线决策。

一、标准如何设计

建议把需求标准拆成两层：

1. 模块级 Spec 标准

每个模块单独评分，适用于：

• 用户登录模块
• 订单模块
• 支付模块
• 权限模块
• 报表模块
• AI Agent 某个能力模块
• 后台配置模块

每个模块 Spec 至少包含：

• 目标说明：这个模块解决什么问题，服务谁。
• 范围边界：做什么、不做什么。
• 核心流程：用户/系统如何完成主要动作。
• 输入输出：字段、参数、状态、数据结构。
• 业务规则：判断条件、限制、优先级、异常规则。
• 状态变化：状态机、生命周期、数据流转。
• 异常场景：失败、冲突、超时、重试、权限不足。
• 验收标准：什么情况下算完成。
• 依赖关系：依赖哪些模块、接口、数据、角色。
• 变更记录：当前版本相对上一版改了什么。

模块 Spec 不一定一开始就 100 分，但要能支撑当前阶段的开发和验证。

2. 项目级综合标准

项目级不重复评每个模块细节，而是评：

• 模块之间是否衔接
• 关键链路是否闭环
• 风险是否可控
• 版本范围是否清楚
• 是否具备进入开发/测试/上线的条件

项目级综合标准关注的是“整体能不能往前走”。

二、模块评分如何操作

建议每个模块按 100 分评分，分成 8 个维度。

模块评分等级

模块评分的作用

模块评分主要用于：

• 判断某个模块能不能进入开发
• 识别该模块的需求风险
• 指导 AI 生成代码、测试、用例时的可靠性
• 让产品、研发、测试对“是否清楚”有共同标准
• 避免因为一个模块不清楚拖住整个项目

例如：

这样项目不需要等所有模块都完美，成熟模块可以先走。

三、综合评分如何操作

综合评分不是简单平均分，建议采用“加权 + 阻断项”的方式。

1. 模块加权

不同模块重要性不同，不能简单平均。

例如一个电商项目：

综合分：

综合分 = Σ 模块分 × 模块权重

但如果支付模块只有 60 分，即使综合分看起来还可以，也不能认为项目整体安全。

所以需要阻断项。

2. 设置阻断项

以下情况不允许进入下一阶段：

• 核心链路模块低于 75 分
• 高风险模块没有明确负责人
• 关键业务规则缺失
• 验收标准无法转化为测试用例
• 模块之间接口或状态不一致
• 涉及资金、权限、数据安全但规则不完整
• 存在未确认的重大产品决策

也就是说：

综合评分 = 加权分 + 阻断项判断

不是只看分数。

3. 综合评分等级

四、模块评分和综合评分分别起什么作用

模块评分的作用

模块评分回答的是：

这个模块现在能不能做？

它服务于：

• 模块开发排期
• 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：准入决策

每个模块给出准入状态：

阶段 6：持续变更管理

每次需求变化都不需要大动干戈，但要做到：

• 有版本号
• 有变更记录
• 有影响分析
• 必要时重新评分
• 同步到研发和测试

七、适合公司内部落地的评分机制

建议采用“三个分数 + 一个结论”。

1. 模块成熟度分

回答：

这个模块描述清楚了吗？

例如：订单模块 78 分。

2. 模块风险分

回答：

这个模块做错的代价高不高？

例如：

同样 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 在不确定需求中持续发挥作用。