组件语义快照与模式诊断：AI 生成界面的第一道检查

阶段一总结：从观察到模式

本文是 把设计规范写成代码格式（Schema-As-Code） 方法论的阶段一总结。核心回答三个问题：

1. 怎么观察 AI 产品的语义不一致？（方法论定义）
2. 观察到了什么？（证据库展示，简化版）
3. 这些观察怎么变成可执行的规则？（技术架构论证，简化版）

阅读时间：15 分钟。文末附下一阶段预告。

摘要

AI 正在从"辅助设计"走向"直接生成界面"。当界面从"人画"变成"AI 生成"，一个新的问题出现了：

AI 生成的界面，意思对不对？

同样的红色按钮，在这个场景下是"删除"，在那个场景下是"保存"，AI 可能分不清楚。同样的"严重"一词，在告警场景下情绪权重被弱化，用户可能低估风险。

这不是某个产品的设计缺陷，而是概率性生成带来的固有特性：AI 没有"语义一致性"的概念，它只有"概率最接近"。

本文提出组件语义快照（Component Semantic Snapshot）作为观察方法，通过 6 个标准字段记录界面证据，归纳出 6 种通用不一致模式，为后续"规则显化"提供第一手素材。

1. 观察方法：组件语义快照

详见 《组件语义快照：我观察AI产品界面时用的6字段记录法》

1.1 为什么不是普通截图？

普通截图只有像素信息，没有语义信息。一张某 AI 产品的报错截图，三个月后回看，你可能已经忘了：

• 这是"什么类型"的组件？
• 用户"怎么困惑"的？
• 在"什么场景"下触发的？

组件语义快照是一种结构化的界面记录方法。在截图之上增加 6 个标准字段，让任何人在任何时间看到这张快照时，都能立刻理解问题全貌。

1.2 6 个标准字段

1.3 完整示例

SNAP-202506-001

• product: 某 AI 对话产品 A
• component_type: 错误状态
• screenshot: [红色框标注：4 种错误共用红色背景/文字]
• user_confusion: "看到红色就刷新，结果只是限流。红色让我以为系统崩了。"
• context: 高峰期快速发送 5 条消息后触发
• 匹配模式: ERR-001（后果差异未分级）

2. 产品观察：8 类 AI 产品的语义不一致证据

通过对 8 类 AI 产品的界面观察，发现语义不一致不是个案，是行业共性问题。

说明：完整证据库（含截图、用户反馈、触发场景）见模式库详情页。本文仅展示归纳结论。

3. 组件分类与模式库：从证据到规律

详见 《组件语义分类与漂移模式匹配：从观察到归类的结构化规范》

3.1 5 种组件类型

语义不一致不是随机发生的，它集中在 5 类高频交互组件上：

4. 6 个不一致模式

详见 《6 个漂移模式：AI 生成界面的语义断层证据库》

说明：每个模式的完整证据（截图、用户反馈、YAML 规则）见模式库独立页面。

5. 诊断机制：三层判定模型

组件语义快照积累到一定数量后，需要建立结构化的归类机制，将分散的界面记录转化为可追踪的模式节点。我将其定义为三层判定模型，每一层处理不同维度的语义信息，逐层收敛，最终输出模式匹配结果。

详见 《结构化诊断：三层判定模型与模式匹配机制》

5.1 第一层：组件类型识别（Component Type Classification）

输入：单张组件语义快照（含 visual_record、context 字段）

判定逻辑：根据界面的交互路径，而非视觉形态，确定其归属的组件类型：

边界处理：若单张快照同时满足多个组件类型的判定条件（如操作控件触发后引发边界反馈），标记为复合类型，后续需叠加应用多个组件类型的语义约束。

输出：component_type 标签（单值或复合值）

5.2 第二层：语义缺失判定（Semantic Deficiency Detection）

输入：已标注 component_type 的快照 + user_confusion 字段

判定逻辑：提取 user_confusion 中的语义关键词，匹配预设的语义缺失模式：

判定规则：关键词匹配采用包含逻辑而非精确匹配。单张快照的 user_confusion 可能同时触发多个语义缺失类型，此时按优先级排序（安全类 > 认知类 > 效率类），取最高优先级作为主导缺失类型，其余标记为关联缺失。

输出：semantic_deficiency 标签（主导类型 + 关联类型列表）

5.3 第三层：视觉表达校验（Visual Expression Validation）

输入：已标注 component_type 和 semantic_deficiency 的快照 + visual_record 字段

判定逻辑：对当前界面的视觉表达进行结构化校验，记录与语义级别不匹配的视觉映射：

示例：一张被标记为 ERR-001（后果差异未分级）的快照，visual_record 显示"限流错误使用了红色背景"，则记录为：

color_mapping_mismatch: 
  actual: "status.critical" (红色)
  expected: "status.warning" (黄色)
  severity_level: "retryable"

输出：visual_validation_report（含映射不匹配项、缺失项、冗余项）

5.4 输出与归档

三层判定完成后，系统自动生成诊断报告，包含以下字段：

归档规则：

• confidence_score >= 0.85 → 自动归档到对应模式节点
• 0.60 <= confidence_score < 0.85 → 标记为"待人工复核"
• confidence_score < 0.60 → 标记为"待归类"，触发新模式创建流程

机制说明：三层判定模型不是一次性问卷，而是可嵌入持续集成流程的自动化判定逻辑。第一层和第二层基于规则引擎运行，第三层目前依赖人工标注（视觉表达的自动化解析需要计算机视觉支持，尚未纳入当前实现范围）。

6. 技术架构：从观察到规则的流转（简化版）

6.1 核心流转：Code-Text-Code

观察到的界面证据（截图/文本）→ 写成结构化文本（YAML 规则）→ 编译成机器可执行代码（Prompt 前缀 / 校验规则）。

6.2 分工架构：AI 生成 + 规则把关

• AI 负责生成：发挥创造力，快速产出界面
• 规则负责把关：守住语义边界，防止不一致

6.3 四级审查流程

人工审核 → 系统判决 → 人工修正 → 系统验证。

说明：完整技术架构（注册表 / 编译器 / 校验器 / 运行时 / 桥接 五模块）见工程实现文档。本文仅保留核心流转逻辑。

7. 可运行代码示例：简单的语义分级器

以下是一段可直接运行的 Python 脚本，演示如何用规则对 AI 产品的错误文案进行语义分级：

def classify_error(text):
    """基于关键词规则的错误语义分级器"""
    text_lower = text.lower()

    # 致命级：流式中断、上下文丢失
    if any(kw in text_lower for kw in ['stream', 'message stream', '连接断开', '输出中断']):
        return {
   
            'level': 'FATAL',
            'description': '流式输出中断，对话上下文可能丢失',
            'color': '红色脉冲',
            'action': '刷新页面 / 导出历史'
        }

    # 网络抖动级：可自动恢复
    elif any(kw in text_lower for kw in ['network', '网络错误', 'network error', '加载失败']):
        return {
   
            'level': 'TRANSIENT',
            'description': '网络抖动，系统可自动恢复',
            'color': '灰色加载',
            'action': '等待自动恢复'
        }

    # 限流级：用户可自助恢复
    elif any(kw in text_lower for kw in ['too many', '429', 'throttling', '请求过于频繁', '服务繁忙']):
        return {
   
            'level': 'RETRYABLE',
            'description': '请求频率达到上限',
            'color': '黄色提示',
            'action': '等待倒计时 / 升级套餐'
        }

    # 部分可用级：核心流程可继续
    elif any(kw in text_lower for kw in ['something went wrong', 'something wrong', '创造失败', '服务异常']):
        return {
   
            'level': 'DEGRADED',
            'description': '部分功能异常，核心流程可继续',
            'color': '蓝色提示',
            'action': '继续生成 / 简化问题重试'
        }

    return {
   'level': 'UNKNOWN', 'description': '未匹配到已知语义分级'}


# 测试示例
test_cases = [
    "Too many requests in 1 hour. Try again later.",
    "Error in message stream",
    "network error",
    "Something went wrong"
]

for text in test_cases:
    result = classify_error(text)
    print(f"输入: {text}")
    print(f"分级: {result['level']} - {result['description']}")
    print(f"建议视觉: {result['color']}")
    print(f"用户行动: {result['action']}")
    print("-" * 40)

运行结果示例：

输入: Too many requests in 1 hour. Try again later.
分级: RETRYABLE - 请求频率达到上限
建议视觉: 黄色提示
用户行动: 等待倒计时 / 升级套餐
----------------------------------------
输入: Error in message stream
分级: FATAL - 流式输出中断，对话上下文可能丢失
建议视觉: 红色脉冲
用户行动: 刷新页面 / 导出历史
----------------------------------------
输入: network error
分级: TRANSIENT - 网络抖动，系统可自动恢复
建议视觉: 灰色加载
用户行动: 等待自动恢复
----------------------------------------
输入: Something went wrong
分级: DEGRADED - 部分功能异常，核心流程可继续
建议视觉: 蓝色提示
用户行动: 继续生成 / 简化问题重试
----------------------------------------

说明：这是一个极简的规则引擎示例，用于演示"语义分级"的核心逻辑。生产级实现需要更复杂的规则匹配和置信度计算。

8. 工程实现：Semantic Pipeline

详见 《从观察到契约：Semantic Pipeline 的三阶段工作流》

8.1 三阶段衔接

8.2 消费方工作流（简化）

9. 定位：不是替代，是叠加（简化版）

现有工具（AI 原型工具、AI 编程助手、企业组件库）解决"怎么写代码"。

Schema-As-Code 解决"这个场景下必须表达什么语义、不能突破什么边界"。

关系：Schema-As-Code 是所有形态层工具的上游约束层。

10. 组织价值（简化版）

11. 下一阶段预告：从观察到规则

阶段一（本文）解决了"发现问题"：

• ✅ 有了观察方法（组件语义快照 6 字段）
• ✅ 有了证据库（6 个不一致模式）
• ✅ 有了诊断工具（3 问题问卷）
• ✅ 有了可运行代码（语义分级器示例）

阶段二（即将发布）解决"写出规则"：

• 规则工作台（Contract Library）：浏览所有 YAML 规则，一键复制 Prompt 前缀 / Checklist / CI 规则
• 语义令牌规范：Design Token 之上叠加 Semantic Token，让颜色携带场景语义
• Prompt 前缀模板：前端工程师直接复制粘贴到 AI 编程助手指令里

阶段三（即将发布）解决"验证闭环"：

• 验证实验室（Validation Toolkit）：输入任意 AI 生成的文案/组件，跑四层检查，看有规则 vs 无规则的对比
• 在线分级器：输入错误文案，自动匹配 Fatal/Transient/Retryable/Degraded 分级
• 语义不一致观测 Dashboard：设计时规则 + 运行时归因，双轨闭环

下一步行动：

如果你也想开始观察自己产品的语义不一致，第一步：打开你的 AI 产品，触发一个错误状态，按本文的 6 字段格式记录第一张快照。

第二张会比第一张快 10 倍。

附录

术语对照表

资源

• 语义流水线站点：https://2436041978-ops.github.io/semantic-pipeline/
• 完整模式库及验证工具：见语义流水线站点

Gap 期局限性声明

当前状态： 架构推演与最小可行原型阶段。YAML 规范、校验逻辑为定义层实现，尚未接入生产级 LLM API 或 CI 流水线。欢迎基于现有思路共建。

关于作者

魏雯，体验架构设计师。

专注于：AI 界面的语义治理。解决的核心问题：让 LLM 生成的界面不偏离设计规范。

10+ 年互联网设计经验。设计系统 / 体验工程 / AI 原生｜广州 / 深圳