第2章 一致性定义标准：字段、交互与视觉的对照体系

2.1 适用场景

• 设计方案（PRD/交互稿）交付后、高保真原型启动制作前。
• 原型初稿完成后，提交设计评审会之前。
• 跨角色（产品、设计、开发）对某一模块一致性产生争议时。
• 测试用例编写阶段，作为预期结果的核心参考依据。

2.2 前置条件

• 输入文档：已定稿的原型文件（Sketch / Figma / Axure）、产品需求文档（PRD）或功能规格说明书。
• 工具准备：能够同时预览原型与方案文档的对比工具（如 Figma 分屏、PDF 并排、专用 diff 插件）。
• 角色到位：至少包含 1 名设计人员与 1 名需求撰写人员，责任边界参见 2.5 节。

2.3 操作步骤

一致性定义标准分为三个子维度，每个子维度对应一套独立的对照规则。以下步骤按维度依次执行，不可跳序。

步骤一：字段对应规则检验（原型元素 → 方案字段）

1. 将原型中所有可编辑或可展示的文字区域（标签、占位符、表格列头、按钮文案、提示文本）逐一列出。
2. 在方案文档（PRD / 规格书）中找到对应的字段定义，使用“字段映射表”记录对应关系。
3. 检查字段名称、数据类型、长度限制、单位、默认值、枚举值是否与原方案完全一致。
4. 对缺失字段或冗余字段进行标注，并标记为“不一致”。

步骤二：交互逻辑与功能描述对照

1. 以方案文档中的“交互逻辑”或“功能规则”段落为基准，拆解为 触发条件 + 系统响应 的原子单元。
2. 对原型中对应的交互区域（按钮、链接、滑动、悬停、自动加载等）逐条测试其行为。
3. 使用二元对照表记录：方案描述的动作是否在原型中可触发、响应状态（加载/成功/失败/空数据）是否匹配。
4. 特别注意边界状态：无网络、空列表、输入校验失败、超时等是否被遗漏。

// 交互对照示例（JSON 结构）
{
  "交互ID": "LOGIN_01",
  "方案描述": "用户输入11位手机号后，点击登录按钮发送POST请求",
  "原型行为": "点击按钮后调用 /api/login",
  "响应对照": {
    "成功": "跳转至首页（✅一致）",
    "失败-账号不存在": "提示'该手机号未注册'（❌原型未实现）",
    "失败-网络错误": "toast提示'网络异常'（✅一致）"
  }
}

步骤三：视觉规范与设计说明匹配

1. 从方案文档中提取“视觉规范”部分（颜色色值、字号行高、间距规则、圆角半径、阴影层级）。
2. 使用取色器/标注工具测量原型中的实际值，并与规范逐一比对。
3. 将比对结果记录于“视觉偏差清单”，标注偏差等级（轻微/一般/严重）。
4. 对于无法在原型中直接体现的设计说明（如动效时长、过渡曲线），单独列出并标注“需在开发阶段落地验证”。

2.4 输入输出物

2.5 责任边界

• 需求方（产品经理）：负责提供准确、无歧义的方案文档，并对字段映射表中的业务含义负责。
• 设计方（UI/UX）：负责输出与方案描述严格一致的原型，并对交互逻辑、视觉规范的落地准确性负责。
• 验证方（测试/效率团队）：负责执行对照检验，输出偏差记录，但不负责修改方案或原型。

2.6 记录材料

每轮一致性验证完成后，需归档以下材料至项目共享空间：

• 2_field_mapping_v{版本}.xlsx — 字段映射表
• 2_interaction_log_{模块名}.json — 交互逻辑对照报告
• 2_visual_deviation_list.md — 视觉规范偏差清单
• 会议纪要与偏差裁决记录（如有分歧）

2.7 异常处理

2.8 验收标准

• 字段映射表中所有字段的一致性判断结果中，“不一致”项占比 ≤ 5%。
• 交互逻辑对照报告中不存在“原型未实现”或“状态缺失”的严重项。
• 视觉规范偏差清单中无严重等级偏差，轻微偏差项需附带修正时间承诺。
• 所有异常场景均已记录并触发相应处理流程，无未解决的问题进入下一阶段。