设计师与产品经理AI界面语义走查指南

AI生成代码的"伪正确"已被广泛讨论：能通过编译、看起来专业、业务逻辑却是错的。AI生成界面存在同构问题：渲染正常、视觉合规、语义却是错的。

界面没有抛出任何异常，用户已经做出了错误决策。代码侧有类型系统与测试兜底，但是界面侧没有对应的防线。Schema-As-Code 把设计规范写成代码格式 框架补充的正是这一层。

框架定义：当AI生成界面时设计意图在偏离。Schema-As-Code 把设计规范写成代码格式 在语义层建立一套机器可读的约束契约（机器可执行的规则文件），让AI在生成界面之前，先知道"这个场景下必须表达什么语义、不能突破什么边界"。框架不替代任何设计工具或AI工具，而是所有AI工具的上游约束层，AI负责生成规则负责把关。

本文定位：以设计师与产品经理为入口，呈现该角色在框架中的完整消费路径，验证框架在真实设计工作流中的可用性。后续将从前端与AI工程师、DesignOps、语义翻译设计师、管理层各自的入口进入同一框架；框架交付件、案例库与落地验证另篇呈现。

1. 设计意图的定义者与验收者

1.1 角色定义

设计师与产品经理是设计意图的定义者与验收者：负责将业务需求转化为可验证的语义约束，并确保AI生成界面的语义输出符合预期。

产品经理定义业务层面的语义要求（如"删除账户必须让用户感知到不可逆"），设计师将其翻译为视觉方案（如"红色描边按钮 + 二次确认弹窗"）。

• 产品经理：负责需求定义，确保功能描述能映射到机器可消费的语义约束。
• 设计师：负责界面体验，确保视觉表达与业务语义一致。

1.2 反复发生的场景

以下3个场景在AI参与界面生产的团队中反复出现。它们是我在观察与诊断阶段经跨产品观察验证过的语义漂移模式（UI层的silent failure：无报错、渲染成功、输出错误）。

😖痛点1：AI生成界面视觉对了语义错了 验收缺少判定依据

• 定义："伪正确"在界面侧的表现，AI生成的代码会"看起来对、跑起来错"，AI生成的界面同样会"看起来对、用起来错"。
• 例子：比如四种错误状态，流式中断、网络抖动、限流、服务降级。后果完全不同，却共用同一种红色。对照视觉规范，色值合规，挑不出毛病；但用户无法判断这是"对话已丢失"还是"等三十秒就好"。
• 根因：走查结论停留在"感觉不对"，因为缺少一份可引用的语义判定标准：视觉走查回答"界面是否符合规范"，回答不了"界面是否表达了正确的语义"。

😖痛点2：设计决策依赖个人经验语义表达跨人不一致

• 定义：设计决策依赖个人经验，缺少统一标准。
• 例子：比如"删除账户"按钮，有人用红色实心，有人用橙色描边，都有理由，都没有依据；PRD里写"明显提示风险"，设计、前端、测试对"明显"各有理解。
• 根因：缺少一份可引用的语义判定标准，同一语义在不同人、不同产品线产出不同表达，组织层面的语义一致性无从谈起。

😖痛点3：语义意图在传递中层层失真

• 定义：设计师说"这个错误提示要让人紧张"。前端理解为深红色加粗文字；走查时设计师认为紧迫感不足，改为红色背景卡片；三轮返工后，仍然不是最初设想的"红色脉冲动画+明确的恢复路径"。因为沟通使用的是形容词，而非定义。
• 例子：文案一侧同样失真：AI生成告警时把 "Critical" 替换为"严重"、把 "Data Loss Risk" 替换为"请稍后重试"，精心设计的语义权重在概率性输出中被随机降级。
• 根因：规范更新同样传不到位：团队将"错误状态分四级"的规范更新发布在文档平台并通知全员，两周后走查发现多个产品的AI生成界面仍是全红，人可能看漏通知，而AI的训练数据里根本没有这条规范。

共同本质：三个场景都不是视觉问题，也不是协作态度问题，而是语义断层（界面没有表达它本应表达的意思），"这个场景下必须表达什么语义"只存在于个人经验与口头约定中，没有标准化、可查询、可核对的载体。

AI没有"语义一致性"的概念，只有"概率最接近"，当语义约束不可机器读取时生成结果只能沿视觉惯性漂移。

1.3 解决思路：从痛点到两项资产

三个痛点的解法指向同一结论：该角色需要的不是更多规范文档，而是两项可直接消费的资产：

• 语义字典：决策与沟通时可查询的"组织级语义码本"，统一"这个词在这个场景下是什么意思"
• 走查Checklist：验收时可逐项核对的断言清单，判定"这个界面是否表达了正确的语义"

这两项资产覆盖三个场景：Checklist解决"怎么判定"，语义字典解决"统一标准"，字典术语替代主观描述。

🤔为什么现有工具给不了？

人工走查受限于时间和认知负荷，判定标准因人而异。AI生成工具基于概率输出，本身没有"语义一致性"概念。

概括：现有工具解决"怎么生产界面"，没有解决"这个场景必须表达什么语义、不能突破什么边界"

🩹 补齐缺失的语义层

Schema-As-Code 把设计规范写成代码格式 是填补这一空缺的语义治理工程框架。它以三阶段工作流产出上述两项资产：

1. 诊断：用结构化方法把界面语义偏差归类为6个通用模式
2. 契约：把语义定义写成YAML文件（机器可读、可校验），并通过编译管线自动翻译成Prompt前缀、JSON Schema、Checklist等消费格式
3. 验证：各角色在工作流中消费这些资产，验证语义一致性

设计师与产品经理的角色：守好两道防线。验收时用Checklist逐项核对，发现问题后把新场景回流到模式库。

Schema-As-Code不替代现有工具（设计规范、Design Token、组件库、AI生成工具），而是作为它们的上游约束层存在：AI仍负责生成，规则负责把关；视觉走查回答"界面长什么样"，语义资产回答"界面表达了什么意思"。

1.4 设计师与产品经理在框架中的核心动作：

• 消费语义字典 Semantic Overlay注册表：查询组件在特定场景下的语义定义，作为设计决策的依据。
• 消费走查Checklist编译管线产出：在验收阶段逐项核对AI生成界面替代主观判断。
• 反馈语义漂移案例：将字典未覆盖或契约未拦截的语义偏差，回流至语义翻译设计师，触发模式库更新。

2. 语义治理的两项资产从何而来

本章以设计师与产品经理的工作场景提出三个问题，语义偏差如何被发现？语义规律如何写成规则？规则如何变成可消费的资产？串联结构化诊断Guard阶段与语义契约化Contract阶段的完整设计。每个环节仅作概述，完整方法详见对应文档。

2.1 结构化诊断：语义偏差如何被结构化地发现

场景：AI生成界面在视觉层面通常符合设计规范，但语义表达可能与场景不匹配，多种错误共用同一种红色，高危操作与普通按钮样式相同。这类偏差不作用于像素，视觉走查无法覆盖，需要一套结构化的观察与诊断方法。

🩺 结构化诊断阶段《组件语义快照与模式诊断》建立了这套方法，详见《组件语义快照与模式诊断AI生成界面的第一道检查》

第一步：组件语义快照6字段记录法。在界面视觉素材之上，强制记录6个标准字段，锚定该界面的语义上下文：详见《我观察AI产品界面时用的6字段记录法》。

snapshot_id: SNAP-202506-001        # 快照唯一编号，供模式库归档与版本管理
product: 某 AI 对话产品              # 漂移发生的产品，支持跨产品对比
component_type: 错误状态             # 组件类型，决定后续匹配的模式分支
visual_record: 界面素材 + 语义标注框  # 标注语义漂移发生的区域
user_confusion: "看到红色就刷新，结果只是限流"  # 用户困惑，语义断层的直接证据
context: 高峰期快速发送 5 条消息后触发            # 触发场景，支持复现

第二步：语义分类与漂移模式匹配。 快照按组件类型归类，与模式库中的既有模式匹配，将分散的界面记录转化为可追踪的模式节点。详见《组件语义分类与漂移模式匹配》。

第三步：结构化诊断 三层判定模型（三级分类器：组件类型 → 语义缺失 → 视觉校验）。每张快照经三层判定逐层收敛，输出模式ID与置信度：详见《结构化诊断 三层判定模型与模式匹配机制》。

第一层 组件类型识别 → 第二层 语义缺失判定 → 第三层 视觉表达校验
                          ↓
   输出：matched_pattern（如 ERR-001）+ confidence_score + 归档路径

📝 诊断结论：6个漂移模式。 全部观察最终归纳为6个经过跨产品验证的语义漂移模式。详见《6个漂移模式AI生成界面的语义断层证据库》。

🔗 从观察到契约：诊断结果指明"缺什么规则"，经Semantic Pipeline的三阶段工作流（Guard→Contract→Verify）进入规则写入环节。详见《从观察到契约Semantic Pipeline的三阶段工作流》。

2.2 语义契约化：语义规律如何转化为机器可读的规则

场景：以文档形式存在的设计规范，读者只有人，人可能看漏、看错版本，AI工具则完全不可见。语义契约化Contract阶段的核心是将设计意图翻译为机器可读的语义契约。

方法论背景详见《把设计规范写成代码格式，是所有 AI 工具的上游约束方法论》，完整阐述见《设计师作为"语义翻译者"当AI生成界面时怎么用规则锁住设计意图》。

语义规范体系：契约的内容不是色值与文案而是语义令牌。Design Token定义"颜色是什么"，语义令牌定义"颜色代表什么"，同一个红色在系统故障场景为status.critical，在高危操作场景为action.destructive。详见《语义规范体系》。

YAML 契约格式：每条契约由7个字段构成：详见《YAML 契约格式》。

intent_id: ERR-001                  # 我是谁：契约唯一标识
description: 错误状态后果差异未分级   # 我解决什么问题
version: 1.1.0                      # 我是哪个版本：变更触发重编译
applicable_products: [...]          # 我在哪些产品生效：防止规则误用
semantic_tokens:                    # 我定义了什么语义：级别 × 视觉 × 行动
  error_severity:
    fatal:
      visual_mapping: { color_token: status.critical, motion_token: pulse.red.urgent }
      user_action: [refresh_page, export_history]
immutable_boundaries: [...]         # 我画了什么红线：绝对禁止项
llm_constraints: [...]              # 我对 AI 的强制要求：必须包含、禁止省略

• 契约库：契约以Git仓库管理：版本可追溯、变更可回滚、修改走PR 批，设计规范像代码一样管理。详见《契约库：让设计规范像代码一样管理》。

2.3 编译管线与语义字典：机器可读的规则如何转化为可消费的资产

场景：YAML契约面向规则维护者与机器，设计师不应直接阅读契约原文。编译管线是语义一致性的"机器翻译层"，将同一份契约自动编译为四种消费格式分发给不同角色：

详见《编译管线是语义一致性的"机器翻译层"》。

                     ┌─→ Prompt 前缀    —— 前端与 AI 工程师
 YAML 契约 ──编译管线──┼─→ JSON Schema   —— 组件 Props 校验
                     ├─→ 走查 Checklist —— 设计师与产品经理（本文消费）
                     └─→ CI 规则        —— 流水线自动拦截

面向设计师与产品经理的另一项资产是语义字典：由语义翻译设计师基于模式库构建，覆盖组织内所有业务语义组件，供设计决策时查询。详见《语义字典：设计系统组件的语义覆盖层》。

3. 语义字典与走查 Checklist 的使用场景

语义字典与走查Checklist是框架的验证闭环Verify阶段面向设计师与产品经理的交付面。本章阐述两项资产的具体消费方式。

3.1 语义字典 Semantic Overlay 注册表

资产来源：由语义翻译设计师维护，基于模式库（错误状态 / 过程状态 / 边界动作 等）构建，覆盖组织内所有业务语义组件。

字典是组织内唯一定义覆盖层、语义绑定与场景映射的资产，所有YAML契约必须引用字典中的已定义项，不可自创。

资产结构：字典分三层，设计师查询时各层回答不同问题：

使用场景 1：设计决策前的语义对齐

设计师在启动新界面设计前，查询语义字典确认关键组件的语义定义。例如：

• 查询字段级定义：error_severity，明确"致命错误"（Fatal）对应红色脉冲+八边形图标+恢复路径，"限流提示"（Retryable）对应黄色时钟 + 倒计时，避免凭直觉选色。
• 查询场景级映射：SCN-001（删除账户），字典直接给出完整方案：覆盖层 transactional，语义绑定 status.critical + action.destructive，组件组合 Alert + Button + Modal，文案必须包含"此操作不可恢复"，交互必须输入账户名二次确认。设计师在既定语义边界内做视觉探索，无需从空白开始推导。

使用场景 2：跨角色沟通时的术语统一

设计师与前端工程师沟通时，使用语义字典中的标准术语替代主观描述：

使用场景 3：需求定义中的语义约束引用（产品经理）

产品经理在PRD中引用字典条目，替代模糊描述，不写"删除账户需明显提示风险"，而写"该场景引用字典场景映射SCN-001（删除账户），语义绑定 action.destructive 必须二次确认"。需求从自然语言描述升级为可校验的语义引用，验收标准在需求阶段即已确定。字典的构建方法与覆盖范围，详见《语义字典：设计系统组件的语义覆盖层》。

3.2 走查 Checklist 编译管线产出

资产来源：由编译管线根据YAML契约自动编译生成。编译逻辑决定了Checklist的结构：契约中的llm_constraints（对AI的强制要求）编译为勾选项，immutable_boundaries（不可变边界）编译为红线阻断项，这是每份Checklist都包含"红线检查"一组的原因。

使用场景：设计验收阶段的逐项核对

设计师在验收AI生成界面（或前端实现）时，打开对应组件的Checklist，逐项勾选：

## 错误状态组件走查清单（基于 ERR-001 v1.1.0）

### 语义分级检查
- [ ] 错误状态是否按级别区分了颜色？（红/灰/黄/蓝）
- [ ] 致命错误是否使用了脉冲动画？
- [ ] 限流提示是否显示了具体倒计时？
- [ ] 降级错误是否说明了哪些功能仍可用？

### 文案检查
- [ ] 致命错误文案是否说明了"对话可能已丢失"？
- [ ] 是否禁止了仅显示"出错了"等模糊文案？
- [ ] 是否禁止了显示纯技术错误码（如 500）？

### 红线检查（违反即阻断）
- [ ] 是否把致命错误做成了普通文字？（不可突破）
- [ ] 是否把限流提示做成了红色？（不可突破）
- [ ] 是否遗漏了二次确认？（不可突破，仅针对高危操作）

判定规则：

• 全部通过 → 验收通过，进入开发或上线。
• 红线项未通过 → 必须修改，不可协商。
• 非红线项未通过 → 记录问题，限期修复，可进入开发但需跟踪。

版本同步：每份Checklist头部嵌入版本声明（基于哪份契约的哪个版本、编译时间、源文件路径）。契约变更后，Git钩子触发编译管线自动生成新版Checklist并通知下游，设计师验收时引用的永远是最新契约版本，验收结论可追溯至具体版本。

验收辅助：对拿不准的文案或组件，可使用框架提供的语义分级器工具，输入错误文案，获得fatal/transient/retryable/degraded的分级建议（对应框架的四层推演引擎：语法/语义/安全/美感四道机器检查）。工具输出为参考结论，最终判定以Checklist人工核对为准。Checklist的生成机制，详见《编译管线是语义一致性的"机器翻译层"》。

4. 引入语义治理前后的工作流

以下三个核心工作流节点，展示引入 Schema-As-Code 前后的状态差异：

5. 上游输入、下游输出与反馈回流

5.1 上游输入

该角色从以下角色获取输入：

5.2 下游输出

该角色向以下角色交付输出：

5.3 协作示例

场景：新产品线需要设计"账户注销"流程。

1. 设计师查询语义字典→发现action_type中已有destructive_action（删除账户），但无account_deletion子类。
2. 设计师按6字段快照格式记录该场景，反馈给语义翻译设计师 → 触发模式库更新：补充 account_deletion语义，明确"注销后30天内可恢复"与"永久删除"的语义差异。模式库详见《6个漂移模式AI生成界面的语义断层证据库》。
3. 语义翻译设计师更新YAML契约→编译管线生成新版Checklist→DesignOps通知全组织。
4. 设计师按新版Checklist设计注销流程 → 前端按新版Prompt前缀生成代码 → 验收通过。

该角色的反馈回流是框架Verify阶段闭环的组成部分：字典未覆盖的场景经快照回流、模式归档、契约更新、重新编译后，以新版字典与Checklist的形式回到所有消费方手中

6. 语义治理框架全景 三阶段与机制网络

设计师与产品经理的消费路径位于框架Verify阶段。框架全景分三层呈现。

6.1 三阶段全景

6.2 资产流转

6.3 本角色在框架网络中的触点

Schema-As-Code由9个机制主题构成一张相互衔接的网络。本角色触及其中4个节点

6.4 角色价值

设计师与产品经理在框架中的核心价值，是使用资产做决策：设计前查询语义字典，确保方案与组织级语义标准对齐；设计中用字典术语沟通，消除主观歧义；验收时按Checklist逐项核对，将语义漂移拦截在上线前；发现遗漏时回流至模式库，持续完善治理框架。

该角色是语义一致性的第一道防线，设计定义阶段不引用字典，后续所有约束都将失去业务语义基础。

7. 一页纸速查

供日常快速查阅：Semantic Pipeline · 语义审查流水线

示例：设计前 → 打开语义字典 → 查 error_severity → 输出带语义标注的设计稿。

Schema-As-Code 语义治理框架 · 角色专题系列。后续发布：《前端与 AI 工程师消费路径》《DesignOps 与设计系统负责人运营机制》《体验架构师 / 语义翻译设计师搭建指南》《管理层 / 决策者决策框架》；框架交付件、案例库与落地验证另篇呈现。