第1章 适用场景与前置条件
本章定义了一致性验证的适用范围、进入前提以及必须参与确认的相关方角色。任何验证活动未满足本节所述条件之前，不得进入执行阶段。
1.1 适用场景
一致性验证机制适用于下列四种典型场景。由项目负责人（PM/PD）根据当前阶段选择对应场景，并在《验证启动检查单》中标记。
| 场景编号 | 场景名称 | 具体说明 | 触发条件 | 责任角色 |
|---|---|---|---|---|
| S01 | 版本发布前验证 | 新功能或迭代版本上线前，需确认前端实现与原型、方案完全对齐。 | 版本发布冻结前 5 个工作日 | 产品经理、前端开发、设计师 |
| S02 | 需求变更后验证 | 需求变更导致原型或方案文档发生修改后，重新验证受影响模块。 | 变更流程完成、文档基线更新 | 变更控制委员会、产品团队 |
| S03 | 跨团队协作验证 | 涉及多个团队（如云平台、客户端、后端）共同实现的复杂功能。 | 联调环境准备就绪 | 各团队 Tech Lead、系统架构师 |
| S04 | 重大缺陷修复验证 | 线上缺陷修复涉及原型或方案逻辑调整时，需回归验证一致性。 | 修复方案评审通过 | QA、开发、产品 |
关键核查：上述场景选择不可交叉混用。每次验证启动前必须在《验证启动检查单》中明确勾选且仅勾选一个场景编号。混用场景会导致验证范围不清晰、验收标准冲突。
1.2 前置条件
以下前置条件必须全部满足（条件状态为 Y）方可启动验证。任意条件不满足时，执行 挂起 操作，直至条件达成。
- 原型文档已就绪：交互原型文件（Figma / Axure / Sketch）已定稿，附带版本号与锁定标识，且与最新需求基线一致。
- 方案文档已就绪：技术方案/产品方案（PRD + 技术架构文档）终稿完成，由对应负责人签字确认。
- 原型与方案基线差异已标记：若原型与方案之间存在差异（如出于技术约束调整的 UI 布局），差异点必须在文档中用“基线差异标记”标注并解释原因。
- 干系人名单已确认：所有涉及验证的角色已识别，并且干系人已收到通知，预留了验证时间窗口。
- 验证环境可访问：测试环境、Staging 环境或对应分支代码已部署，功能可被验证人员直接访问。
# 前置条件检查清单（启动验证前执行）
checklist:
- item: "原型文档已冻结"
status: null # 填写 Y/N/NA
- item: "方案文档已终稿"
status: null
- item: "基线差异标记已完成"
status: null
- item: "干系人名单确认"
status: null
- item: "验证环境就绪"
status: null
# 全部为 Y 时方可进入下一步
1.3 相关干系人确认
干系人按角色分配确认事项与责任边界。以下为最小必要角色集合，项目可根据规模扩展。
| 角色 | 确认事项 | 产出物 | 时间约束 |
|---|---|---|---|
| 产品经理（PM/PD） | 确认原型与方案基线一致，差异标记可接受 | 《验证启动签字》 | 验证启动前 2 个工作日 |
| 交互/视觉设计师 | 确认最终呈现符合原型交互与视觉效果 | 《UI 一致性走查单》 | 验证启动时 |
| 前端开发工程师 | 确认实现逻辑与方案文档一致，未遗漏边界 | 《自测报告》 | 验证启动前 1 个工作日 |
| 测试工程师（QA） | 确认测试用例覆盖所有原型与方案差异点 | 《测试用例-验证映射表》 | 验证启动前 1 个工作日 |
| 技术架构师（可选） | 确认方案技术约束未影响核心交互路径 | 《技术评审折衷记录》 | 验证启动前 3 个工作日 |
合作建议：在验证启动前 24 小时召开一次 15 分钟对齐会，由 PM 主持，所有干系人同步前置条件状态。会上仅确认“条件是否满足”，不开展验证细节讨论。对齐会结束后发出《验证启动确认邮件》留痕。
1.4 操作步骤
- 步骤 1 —— 场景选择：根据当前项目阶段选择适用场景（S01~S04），填写场景编号与理由。
- 步骤 2 —— 前置条件检查：逐一审核 5 项前置条件，在检查清单中填写 Y/N/NA。存在 N 时，挂起并通知责任人限期整改。
- 步骤 3 —— 干系人确认：召集最小必要角色，确认各自产出物已就绪。PM 在《验证启动确认单》上签字。
- 步骤 4 —— 环境与时间窗口确认：验证环境 URL 或分支信息、验证起止时间（不可超过 48 小时）填入记录表。
- 步骤 5 —— 正式启动：PM 发送《验证启动通知》邮件，附上场景编号、前置条件检查结果、干系人签字列表。邮件发出后视为验证正式启动。
1.5 输入输出物
| 类型 | 输入物 | 输出物 |
|---|---|---|
| 文档 | 原型文档（含版本号）、方案文档（含版本号） | 《验证启动检查单》《验证启动确认单》 |
| 环境 | 验证环境 URL / 分支 / 版本标签 | 验证环境可用性确认截图 |
| 沟通 | 干系人名单与时间窗口 | 《验证启动通知》邮件存档 |
1.6 责任边界
- 产品经理：对场景选择正确性、前置条件完整性负总责。不得在条件未满足时强行启动验证。
- 设计师：对原型文档的基线差异标记准确性负责。未标记的差异一旦在验证阶段发现，设计师承担主要责任。
- 前端开发：确认实现逻辑与方案文档一致。若方案文档与实际实现不符，开发需在验证前提出并记录差异。
- 测试工程师：确保测试用例无遗漏地覆盖所有原型与方案交互路径，包括差异标记处。
- 技术架构师（若参与）：对技术约束影响范围界定负责，不得遗漏关键路径上的折衷。
1.7 记录材料
所有启动阶段的记录材料统一使用固定模板，存放于项目 Doc 仓库的 docs/validation/start/ 目录下。模板如下：
# 一致性验证启动记录
项目名称：_______________________
验证场景编号：__________________
启动日期：______________________
前置条件检查结果：
1. 原型文档就绪: [Y/N]
2. 方案文档就绪: [Y/N]
3. 基线差异标记: [Y/N]
4. 干系人确认: [Y/N]
5. 环境就绪: [Y/N]
干系人签字列表：
- PM:_______________
- Designer:_______________
- Developer:_______________
- QA:_______________
- Architect(可选):_______________
验证时间窗口：____年__月__日 __:__ 至 ____年__月__日 __:__
备注：_______________________
1.8 异常处理
| 异常场景 | 处理措施 | 责任方 |
|---|---|---|
| 原型文档未锁定 | 挂起验证，PM 通知设计师 2 小时内锁定版本；若不满足则延期 | 设计师、PM |
| 方案文档未终稿 | 挂起验证，技术负责人须在 1 个工作日内完成终稿；延期需做变更申请 | 技术负责人、PM |
| 干系人名单不全 | PM 调用项目成员表补充角色，确保最小角色集到位；若角色缺失，记录在案并评估风险 | PM |
| 验证环境无法访问 | 环境负责人（DevOps）须在 2 小时内修复；长期不可用时切换至备用环境 | DevOps、QA |
| 基线差异标记遗漏 | 设计师立即补充标记，重新走差异评审流程；验证启动推迟至标记完成 | 设计师、PM |
1.9 验收标准
本章（第 1 章）的验收标准即为后续章节可以进行的前提条件，具体如下：
- 《验证启动检查单》中 5 项前置条件全部为 Y。
- 《验证启动确认单》已由 PM、设计师、开发、QA 四方签字。
- 干系人角色最小集合已完整。
- 《验证启动通知》邮件已发出，且验证时间窗口已明确。
- 记录材料已归档至
docs/validation/start/，文件命名规范为验证启动_项目名称_日期.md。
只有上述验收标准全部通过，项目方可进入第 2 章——验证计划制定。本阶段产出的所有记录作为第 2 章的输入。