把“需求标准与检测”从一次性验收完整 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–100A可直接开发/测试进入执行75–89B基本可开发有少量风险标记风险后推进60–74C可做原型或技术预研不适合完整开发补齐关键规则40–59D需求不稳定或缺口较大需要重新梳理40E无法执行不进入开发模块评分的作用模块评分主要用于判断某个模块能不能进入开发识别该模块的需求风险指导 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 初稿每个模块用统一模板写允许不完整但必须标记已确认待确认暂不做有风险不要让模糊内容混在正文里。阶段 3AI 初检可以让 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 在不确定需求中持续发挥作用。