阶段一总结：从观察到模式
本文是 把设计规范写成代码格式（Schema-As-Code） 方法论的阶段一总结。核心回答三个问题：
- 怎么观察 AI 产品的语义不一致？（方法论定义）
- 观察到了什么？（证据库展示，简化版）
- 这些观察怎么变成可执行的规则？（技术架构论证，简化版）
阅读时间：15 分钟。文末附下一阶段预告。
摘要
AI 正在从"辅助设计"走向"直接生成界面"。当界面从"人画"变成"AI 生成"，一个新的问题出现了：
AI 生成的界面，意思对不对？
同样的红色按钮，在这个场景下是"删除"，在那个场景下是"保存"，AI 可能分不清楚。同样的"严重"一词，在告警场景下情绪权重被弱化，用户可能低估风险。
这不是某个产品的设计缺陷，而是概率性生成带来的固有特性：AI 没有"语义一致性"的概念，它只有"概率最接近"。
本文提出组件语义快照（Component Semantic Snapshot）作为观察方法，通过 6 个标准字段记录界面证据，归纳出 6 种通用不一致模式，为后续"规则显化"提供第一手素材。
1. 观察方法：组件语义快照
1.1 为什么不是普通截图？
普通截图只有像素信息，没有语义信息。一张某 AI 产品的报错截图，三个月后回看，你可能已经忘了：
- 这是"什么类型"的组件？
- 用户"怎么困惑"的？
- 在"什么场景"下触发的？
组件语义快照是一种结构化的界面记录方法。在截图之上增加 6 个标准字段，让任何人在任何时间看到这张快照时，都能立刻理解问题全貌。
1.2 6 个标准字段
| 字段 | 说明 | 示例 |
|---|---|---|
| snapshot_id | 快照唯一编号 | SNAP-202506-001 |
| product | 产品名称 | 某 AI 对话产品 A |
| component_type | 组件类型 | 错误状态 / 过程状态 / 边界动作 / 操作按钮 / 告警状态 |
| screenshot | 界面截图（含标注） | 红色框标注不一致区域 |
| user_confusion | 用户困惑描述（原话或推断） | "看到红色就刷新，结果只是限流" |
| context | 触发场景 | 快速发送 5 条消息后触发 |
1.3 完整示例
SNAP-202506-001
- product: 某 AI 对话产品 A
- component_type: 错误状态
- screenshot: [红色框标注：4 种错误共用红色背景/文字]
- user_confusion: "看到红色就刷新，结果只是限流。红色让我以为系统崩了。"
- context: 高峰期快速发送 5 条消息后触发
- 匹配模式: ERR-001（后果差异未分级）
2. 产品观察：8 类 AI 产品的语义不一致证据
通过对 8 类 AI 产品的界面观察，发现语义不一致不是个案，是行业共性问题。
| 产品类型 | 代表产品方向 | 观察到的不一致现象 |
|---|---|---|
| 通用对话 | 国内外主流 AI 对话产品 | 错误状态共用红色，用户分不清后果 |
| 搜索增强 | 搜索类 AI 产品 | 过程状态标签模糊，用户不知道 AI 在干什么 |
| 代码生成 | AI 编程助手 | 高危操作按钮样式不统一，缺少二次确认 |
| 设计生成 | AI 原型工具 | 组件语义场景错位，告警按钮做成普通样式 |
| 企业组件 | 企业级组件库 | 组件用对了，但语义场景用错了 |
| 设计系统 | 设计规范工具 | 设计令牌只管颜色，不管场景语义 |
| 可观测性 | AI 观测平台 | 事后能发现不一致，但事前无法预防 |
| 多模态 | 文生视频/图产品 | 跨模态语义映射缺失，风格控制困难 |
说明：完整证据库（含截图、用户反馈、触发场景）见模式库详情页。本文仅展示归纳结论。
3. 组件分类与模式库：从证据到规律
3.1 5 种组件类型
语义不一致不是随机发生的，它集中在 5 类高频交互组件上：
| 组件类型 | 用户核心困惑 | 典型不一致 |
|---|---|---|
| 错误状态 | "这有多严重？我该做什么？" | 多种错误共用同一种视觉 |
| 过程状态 | "AI 现在是在查资料还是在生成？" | 阶段标签模糊，认知不可见 |
| 边界动作 | "我的操作权限还在吗？" | 拒绝和终止表达混淆 |
| 操作按钮 | "点了会出大事吗？" | 高危操作做成普通样式 |
| 告警状态 | "这个词有多严重？" | 语义弱化（如 Critical 被替换为同义词） |
4. 6 个不一致模式
| 模式 ID | 组件类型 | 不一致名称 | 根因 |
|---|---|---|---|
| ERR-001 | 错误状态 | 后果差异未分级 | 缺少错误严重性语义定义 |
| PRO-001 | 过程状态 | 认知阶段未显化 | 缺少过程阶段语义定义 |
| BND-001 | 边界动作 | 权利差异未区分 | 缺少边界动作语义定义 |
| ACT-001 | 操作按钮 | 高危操作未约束 | 缺少操作风险语义定义 |
| ALR-001 | 告警状态 | 语义弱化 | 缺少同义词约束规则 |
| FRM-001 | 表单验证 | 校验反馈缺失 | 缺少校验语义映射 |
说明：每个模式的完整证据（截图、用户反馈、YAML 规则）见模式库独立页面。
5. 诊断机制：三层判定模型
组件语义快照积累到一定数量后，需要建立结构化的归类机制，将分散的界面记录转化为可追踪的模式节点。我将其定义为三层判定模型，每一层处理不同维度的语义信息，逐层收敛，最终输出模式匹配结果。
5.1 第一层：组件类型识别（Component Type Classification）
输入：单张组件语义快照（含 visual_record、context 字段）
判定逻辑：根据界面的交互路径，而非视觉形态，确定其归属的组件类型：
| 判定条件 | 组件类型 |
|---|---|
| 用户遭遇系统异常，操作被迫中断 | 错误提示 |
| AI 执行多步任务，用户等待过程中可见 | 过程指示 |
| 系统对请求作出拒绝、终止或升级审核响应 | 边界反馈 |
| 用户主动发起，触发系统状态变更 | 操作控件 |
| 系统主动推送，提示用户注意风险或状态变化 | 状态提示 |
边界处理：若单张快照同时满足多个组件类型的判定条件（如操作控件触发后引发边界反馈），标记为复合类型，后续需叠加应用多个组件类型的语义约束。
输出：component_type 标签（单值或复合值）
5.2 第二层：语义缺失判定（Semantic Deficiency Detection）
输入：已标注 component_type 的快照 + user_confusion 字段
判定逻辑：提取 user_confusion 中的语义关键词，匹配预设的语义缺失模式：
| 语义关键词特征 | 语义缺失类型 | 对应模式 ID |
|---|---|---|
| "不知道多严重""不知道该做什么""后果不明" | 后果差异未分级 | ERR-001 |
| "不知道在干什么""检索还是生成""可信度不明" | 认知阶段未显化 | PRO-001 |
| "上下文还在吗""还能继续吗""权利不明" | 会话状态未区分 | BND-001 |
| "点了会出大事吗""能撤销吗""风险不明" | 操作风险未标注 | ACT-001 |
| "这个词严重程度如何""是否忽略""权重不明" | 语义权重未对齐 | ALR-001 |
| "不知道哪一格错了""怎么修正""反馈不明" | 校验反馈未细化 | FRM-001 |
判定规则：关键词匹配采用包含逻辑而非精确匹配。单张快照的 user_confusion 可能同时触发多个语义缺失类型，此时按优先级排序（安全类 > 认知类 > 效率类），取最高优先级作为主导缺失类型，其余标记为关联缺失。
输出：semantic_deficiency 标签（主导类型 + 关联类型列表）
5.3 第三层：视觉表达校验（Visual Expression Validation）
输入：已标注 component_type 和 semantic_deficiency 的快照 + visual_record 字段
判定逻辑：对当前界面的视觉表达进行结构化校验，记录与语义级别不匹配的视觉映射：
| 校验项 | 校验内容 | 记录格式 |
|---|---|---|
| 颜色映射 | 颜色是否与语义级别匹配 | color_token: 实际值 → 预期值 |
| 文案精度 | 是否使用模糊词汇或禁止同义词 | text_precision: 实际文案 → 标准文案 |
| 行动完整性 | 是否提供与后果级别匹配的用户行动 | action_completeness: 缺失行动列表 |
示例：一张被标记为 ERR-001（后果差异未分级）的快照，visual_record 显示"限流错误使用了红色背景"，则记录为：
color_mapping_mismatch:
actual: "status.critical" (红色)
expected: "status.warning" (黄色)
severity_level: "retryable"
输出：visual_validation_report（含映射不匹配项、缺失项、冗余项）
5.4 输出与归档
三层判定完成后，系统自动生成诊断报告，包含以下字段：
| 字段 | 来源 | 说明 |
|---|---|---|
matched_pattern | 第二层输出 | 主导模式 ID（如 ERR-001） |
confidence_score | 三层交叉验证 | 基于关键词匹配度 + 视觉校验一致性计算 |
missing_token | 模式库定义 | 该模式对应的缺失语义维度（如 error_severity） |
archive_path | 系统生成 | 该快照在模式库中的存储路径 |
next_action | 规则引擎判定 | "补充已有模式证据" 或 "触发新模式创建" |
归档规则：
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
8.1 三阶段衔接
| 阶段 | 做什么 | 产出 |
|---|---|---|
| Guard（发现问题） | 组件语义快照 + 诊断问卷 | 模式匹配结果 |
| Contract（写规则） | YAML 语义定义 + 编译输出 | Prompt 前缀 / 校验规则 / Checklist |
| Verify（跑验证） | 四层检查 + 对比验证 | 验证报告 + 改进建议 |
8.2 消费方工作流（简化）
| 角色 | 怎么用 |
|---|---|
| 设计师 | 回答 3 个问题 → 匹配模式 → 拿到 Checklist |
| 前端 | 复制 Prompt 前缀 → 贴到 AI 指令里 → 生成符合语义的代码 |
| DesignOps | 改 YAML → Git 提交 → 下游自动同步 |
| AI 产品 PM | 收集验证数据，计算语义返工率、线上语义事故占比 |
9. 定位：不是替代，是叠加（简化版）
现有工具（AI 原型工具、AI 编程助手、企业组件库）解决"怎么写代码"。
Schema-As-Code 解决"这个场景下必须表达什么语义、不能突破什么边界"。
关系：Schema-As-Code 是所有形态层工具的上游约束层。
10. 组织价值（简化版）
| 指标 | 以前 | 以后 |
|---|---|---|
| 规范同步 | 2 周（人工同步） | 0.5 天（Git Diff 自动） |
| 语义一致性覆盖 | 20%（人工走查） | 100%（机器检查） |
| 语义返工率 | 30% | 5% |
| 线上语义问题 | 15% 用户反馈 | 趋近于 0 |
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 倍。
附录
术语对照表
| 概念 | 大白话解释 |
|---|---|
| 组件语义快照 | 不是普通截图，是带 6 个标准字段的界面记录 |
| 语义不一致 | AI 生成的界面意思跑偏了 |
| Schema-As-Code | 把设计规范写成代码格式，让机器能读 |
| 语义分级 | 给错误状态分级别（致命/网络抖动/限流/部分可用） |
| 同义词约束 | 禁止 AI 把"Critical"换成"严重" |
| 不可变边界 | 绝对不能碰的红线（如高危操作必须有二次确认） |
| 四层检查 | 语法/语义/安全/美感四个维度的自动校验 |
资源
- 语义流水线站点：2436041978-ops.github.io/semantic-pi…
- 完整模式库及验证工具：见语义流水线站点
Gap 期局限性声明
当前状态： 架构推演与最小可行原型阶段。YAML 规范、校验逻辑为定义层实现，尚未接入生产级 LLM API 或 CI 流水线。欢迎基于现有思路共建。
关于作者
魏雯，体验架构设计师。
专注于：AI 界面的语义治理。解决的核心问题：让 LLM 生成的界面不偏离设计规范。
10+ 年互联网设计经验。设计系统 / 体验工程 / AI 原生｜广州 / 深圳
