2. 评审前置条件与输入准备
2.1 适用场景
本章指导评审组织者在启动AI产品特性边界评审前，完成所有必需输入的收集、对齐与验证。适用于以下典型场景：
- 新特性首次进入边界评审环节，需要识别输入完整性。
- 跨团队协作时（产品、算法、工程、测试），输入文档版本混乱或存在冲突。
- 评审委员会要求标准化输入清单，降低口头传递偏差。
- 评审历史中发现因前置输入缺失导致反复开会、边界判定无效的复盘改善。
2.2 前置条件
在执行本章流程前，团队必须满足：
- 评审发起人已分配（至少确定产品经理、技术负责人、业务负责人）。
- 产品文档、技术规格、业务目标已有初步草稿或权威来源（如PRD、架构设计书、OKR/BRD）。
- 团队对“特性边界”定义已达成基本共识（建议参考第1章基础概念）。
- 版本管理工具（Git、Wiki、共享文档）可访问，文档应标记版本号与修改日期。
2.3 操作步骤
- 收集原始输入 – 从产品、技术、业务三方获取最新版本的产品文档、技术规格、业务目标文件。
- 术语对齐 – 识别并纠正三类文档中关键术语（如“延迟”“召回率”“用户意图”）的定义差异。
- 交叉验证 – 对照业务目标检查产品文档中的特性描述是否覆盖核心指标；对照技术规格检查可行性边界。
- 完整性检查 – 按输入清单逐项确认，标记缺失或模糊项。
- 生成输入包 – 将验证后的文档整理为评审就绪包，附带版本对照表与差异说明。
2.4 输入输出物
| 输入物 | 来源角色 | 输出物 | 格式要求 |
|---|---|---|---|
| 产品需求文档（PRD） | 产品经理 | 经对齐的产品文档 v2+ | Markdown / PDF，含修订记录 |
| 技术规格书（含架构、模型、接口） | 技术负责人 | 经验证的技术规格 v2+ | Markdown / 在线文档，附带API示例 |
| 业务目标（OKR/BRD/指标定义） | 业务负责人 | 可量化的目标清单 | 表格，含基线值与目标值 |
| 术语表（可选） | 评审发起人 | 术语差异对照表 | 表格，三列：术语、三方定义、统一定义 |
| 主要输出物 | 评审就绪输入包（含版本锁） | ZIP / 云盘目录，含README | |
2.5 责任边界
| 角色 | 职责 | 签字/确认节点 |
|---|---|---|
| 评审发起人 | 协调收集，确保各方提交截止时间 | 步骤4完成 |
| 产品经理 | 提供产品文档，澄清用户场景与验收标准 | 步骤2前 |
| 技术负责人 | 提供技术规格，说明技术约束与风险 | 步骤3前 |
| 业务负责人 | 提供业务目标，量化成功指标 | 步骤3前 |
| 评审委员会主席 | 审查输入完整性，决定是否跳过缺失项并记录豁免 | 步骤5 |
2.6 记录材料
| 材料名称 | 内容摘要 | 保留期限 |
|---|---|---|
| 输入收集清单（Checklist） | 每项输入的版本号、提交人、检查结果 | 评审结束后30天 |
| 术语差异对照表 | 各方定义歧义及统一结论 | 项目周期内 |
| 交叉验证纪要 | 产品vs技术vs业务的不一致项及处置记录 | 评审结束后90天 |
| 输入包版本锁文件 | 所有输入的文件哈希值与快照 | 与评审归档一致 |
2.7 异常处理
- 文档缺失 – 若某方在截止时间前未能提交，评审主席可批准“输入豁免”，并要求该方在评审会现场口头补充，但需在纪要中注明风险。
- 术语冲突不可调和 – 暂停流程，由高层裁定统一术语后再进入步骤5，防止后续边界讨论鸡同鸭讲。
- 技术规格与业务目标矛盾 – 标记为“硬边界冲突”，提前升级至项目总监/CTO决策，输入包中附上分歧记录。
- 版本回退 – 若发现已收集文档有重大修订，需重新执行步骤1~4，并更新版本锁。
2.8 验收标准
- 所有输入文档已按清单收集完毕，版本号与提交人明确。
- 术语差异对照表已完成，无遗留未决项。
- 交叉验证通过率 ≥ 90%（即产品–技术–业务三方关键内容一致比例）。
- 评审就绪输入包内包含README文件，说明每个文件的用途、版本及差异处理。
- 所有异常项均有记录或决策文档，且得到相关方签字确认。
提示： 输入包的质量直接决定后续边界评审的深度。建议在评审会前至少2个工作日完成本章流程，以便各方有缓冲时间消化对齐后的输入。
2.9 本章核心流程：前置条件与输入准备逻辑
要点： 上图展示了从三方独立文档到交叉验证，最后形成评审就绪输入包的必经路径。在实际操作中，若某一节点（如技术规格）存在多个版本，应在交叉验证前先内部对齐版本，避免基础数据错误扩散。