第1章：需求范围边界检查

1.1 适用场景

• 新AI产品立项：首次定义需求原型范围，确保各方对“做什么”与“不做什么”达成共识。
• 大版本迭代评审：每次迭代开始前（如Sprint 0），快速校验本期范围与上期排除项变化。
• 跨团队需求澄清会：当产品、算法、工程、测试、运营等角色对边界认知不一致时，作为正本清源的检查基准。
• 外部合作/客户对接：用于与客户或合作伙伴签署需求边界确认书，降低合同风险。

1.2 前置条件

1.3 操作步骤

1. 步骤一：功能范围逐项过筛

   将PRD中列出的每一项功能点，对照原型进行“是否明确”标记。使用以下分类标准：

   • 明确（A）：输入、输出、触发条件、异常路径均有定义。
   • 待定（B）：核心逻辑已定，但边缘场景或状态转换未说明。
   • 模糊（C）：仅描述意图，无具体行为定义。

   仅允许“明确”项进入开发阶段；“待定”项需在本次评审中指定负责人并设定解决时间；“模糊”项应直接转移到下一版本或排除项列表。

2. 步骤二：排除项清单撰写与确认

   使用以下模板，为每一项排除项填写原因及未来版本计划：

   排除项编号：EXCL-001
   描述：不支持语音唤醒
   原因：当前算法精度低于阈值 85%，且硬件资源受限
   预计引入版本：v2.3（Q3 2025）
   负责人：王明（算法组）

   所有排除项必须由PM与技术Leader双签确认，否则视为“未决项”，需在30分钟内同步给变更控制委员。

3. 步骤三：版本规划范围对齐

   将当前版本（vX.0）的“明确项”与Roadmap上的里程碑进行映射，确保每项功能对应唯一的版本标签。同时检查是否存在“跨版本依赖”的情况：

   • 若有，则在依赖关系记录表中标注强依赖版本号，并评估风险。
   • 若无，则确认本版本范围独立可交付。
4. 步骤四：边界冲突检测

   使用如下规则扫描功能范围与排除项之间是否存在隐性冲突：

   例：功能范围包含“实时数据可视化”，但排除项中却列了“数据流接口不开放给第三方”。若可视化依赖第三方数据源，则视为边界冲突。

   发现冲突后，由PM现场仲裁：要么补充接口定义将其转为明确项，要么调整功能描述以匹配排除项。

1.4 输入输出物

1.5 责任边界

• 产品经理（PM）：主导边界检查，提供完整的需求文档与排除项原因，对范围定义的准确性负首要责任。
• 技术负责人（TL）：评估功能范围的技术可行性，判断排除项是否合理，对技术边界负责。
• 测试负责人：确认排除项不会影响核心验收路径，并提出测试视角的遗漏边界。
• 业务方代表：从业务价值角度确认功能范围的优先级，对版本规划的映射合理性负责。
• 变更控制委员（CCB）：审批“未决项”及范围变更请求，确保流程合规。

1.6 记录材料

1.7 异常处理

1.8 验收标准

• 功能范围完整性：所有明确项(A)已100%覆盖原型中的交互状态；待定项(B)均已分配解决责任人与DDL；模糊项(C)为零或已转移至排除项。
• 排除项明确性：每条排除项均包含原因、预计引入版本、负责人，且无未决项（未签字的排除项视为未决）。
• 版本规划对齐：当前版本的功能项与Roadmap里程碑完全一致，无跨版本隐形依赖。
• 边界冲突清零：边界冲突记录表内所有冲突项均已关闭（或已由CCB批准为范围变更）。
• 文档归档：需求原型边界确认书、冲突记录表、会议纪要均已按规范归档，版本号正确。