本文档收录 6 个经过验证的语义漂移模式，全部基于对主流 AI 产品的界面观察。每个模式均包含：症状描述、根因分析、通用场景分类、以及跨产品的一致性证据。
阅读提示：以下模式按组件类型分类，不绑定任何特定产品。文中所有案例均为"通用型 AI 产品"的共性表现。
本文基于 《组件语义快照与模式诊断：AI 生成界面的第一道检查》 中的概念继续展开。
模式分类总览
| 模式 ID | 组件类型 | 漂移模式名称 | 核心症状 |
|---|---|---|---|
| ERR-001 | 错误状态 | 后果差异未分级 | 多种错误共用同一种视觉表达 |
| PRO-001 | 过程状态 | 认知阶段未显化 | AI 执行过程对用户不可见 |
| BND-001 | 边界动作 | 权利差异未区分 | 拒绝与终止混为一谈 |
| ACT-001 | 操作按钮 | 高危操作未约束 | 不可逆操作缺少二次确认 |
| ALR-001 | 告警文案 | 语义降级 | 关键术语被同义词替换 |
| INF-001 | 信息状态 | 状态权重未对齐 | 通知与警告视觉权重相同 |
模式 1：ERR-001 —— 错误状态后果差异未分级
组件类型
错误状态组件（Error State）
漂移症状
在 AI 对话产品中，当系统遇到故障时，用户至少会遇到以下四种完全不同的错误场景：
- 流式输出中断：对话过程中突然断开，已生成的内容可能丢失
- 网络层故障：网络抖动导致响应中断，但系统可自动恢复
- 限流/流控：用户请求频率超过阈值，需要等待或升级
- 服务端兜底：部分功能异常，但核心流程仍可继续
问题：这四种错误在界面上共用同一种视觉表达（通常为红色），用户无法从界面判断：
- 这个错误有多严重？
- 我需要立即行动还是可以等待？
- 我的数据还在吗？
- 我该刷新、等待还是联系客服？
根因分析
系统缺少 error_severity 语义令牌。前端只接收到 isError = true 的布尔值，不知道这个错误的性质是"致命"、"可恢复"、"可重试"还是"部分可用"。
结果：所有错误被压缩成同一种视觉表达，用户只能靠猜测决定下一步行动。
通用场景分类
| 错误性质 | 用户后果 | 应有的视觉表达 | 应有的用户行动 |
|---|---|---|---|
| 致命（Fatal） | 对话上下文可能丢失 | 红色脉冲 + 紧急图标 | 刷新页面 / 导出历史 |
| 可恢复（Transient） | 网络抖动，自动恢复 | 灰色加载 + 旋转图标 | 等待，无需操作 |
| 可重试（Retryable） | 频率限制，时间到了恢复 | 黄色提示 + 时钟图标 | 等待倒计时 / 升级 |
| 部分可用（Degraded） | 部分功能异常 | 蓝色提示 + 信息图标 | 继续生成 / 简化重试 |
跨产品一致性证据
该模式在以下类型的 AI 产品中普遍存在：
- 通用 AI 对话产品：流式输出中断时显示红色错误提示，未区分是否可恢复
- AI 搜索产品：网络故障和系统故障使用相同的错误提示样式
- AI 编程助手：代码生成中断和编译错误使用相同的红色警告
共性结论：无论产品形态如何，当系统使用"单一红色"表达所有错误时，即触发 ERR-001 模式。
模式 2：PRO-001 —— 过程状态认知阶段未显化
组件类型
过程状态组件（Process State）
漂移症状
在 AI 搜索或多步推理产品中，当 AI 执行复杂任务时，界面通常显示：
- "Searching..."
- "Reading..."
- "Wrapping up..."
问题：这些标签告诉用户"AI 在干活"，但没有告诉用户：
- AI 现在是在检索事实，还是在综合推理？
- 检索到的来源是否可靠？
- 不同来源之间是否存在冲突？
- 最终答案是"查出来的"还是"猜出来的"？
根因分析
系统缺少 process_phase 语义令牌。过程状态停留在"动作描述"（我在搜索），而不是"认知阶段描述"（我在验证来源可信度）。
结果：用户无法建立对最终答案可信度的预期，信任感只能在答案出现后事后判断。
通用场景分类
| 认知阶段 | AI 在做什么 | 用户应该知道什么 |
|---|---|---|
| 检索（Retrieval） | 从外部来源获取信息 | 已找到多少来源？来源质量如何？ |
| 综合（Synthesis） | 对比多源信息，识别共识与分歧 | 多少来源一致？存在什么分歧？ |
| 验证（Verification） | 核对引用与原文的一致性 | 引用链接是否有效？是否与原文一致？ |
| 生成（Generation） | 基于验证后的信息生成答案 | 基于多少个已验证来源？ |
跨产品一致性证据
该模式在以下类型的 AI 产品中普遍存在：
- AI 搜索产品：搜索过程标签模糊，用户无法判断可信度积累过程
- AI 数据分析产品：数据处理步骤对用户不可见，无法判断中间结果可靠性
- AI 编程助手：代码生成过程不透明，用户不知道 AI 是在引用文档还是自由发挥
共性结论：无论产品形态如何，当 AI 执行多步任务但只显示"动作标签"而不显示"认知阶段"时，即触发 PRO-001 模式。
模式 3：BND-001 —— 边界动作权利差异未区分
组件类型
边界动作组件（Boundary Action）
漂移症状
在 AI 对话产品中，当用户请求触发安全边界时，系统通常有两种回应：
- 拒绝请求："我无法回答这个问题"——对话继续，用户可以继续问其他问题
- 终止会话："会话已结束"——对话永久关闭，上下文清空，必须重新开始
问题：这两种回应在界面上都是"拒绝"表达，用户无法判断：
- 我的对话历史还在吗？
- 我刚才问的问题被记录了吗？
- 这是"我不该问这个"还是"我被请出门了"？
- 我能申诉吗？还是只能开新会话？
根因分析
系统缺少 boundary_action 语义令牌。系统知道"触发了安全策略"，但没有区分"策略级别"是"拒绝执行"还是"终止会话"。
结果：用户的权利边界在界面语义上是模糊的，挫败感来源于"不知道自己的处境"。
通用场景分类
| 边界动作 | 用户权利状态 | 应有的界面表达 | 应有的信息说明 |
|---|---|---|---|
| 拒绝（Refusal） | 对话继续，上下文保留 | 黄色提示条，保留输入框 | 说明拒绝原因，提供替代建议 |
| 终止（Termination） | 对话关闭，上下文清空 | 红色退出面板，阻断输入 | 说明数据保留政策，提供申诉入口 |
| 升级（Escalation） | 提交人工审核，等待回复 | 蓝色提示，显示预计时间 | 说明审核流程，提供状态查询 |
跨产品一致性证据
该模式在以下类型的 AI 产品中普遍存在：
- 通用 AI 对话产品：安全拒绝和会话终止使用相同的视觉表达
- AI 客服产品：敏感问题处理和账户封禁使用相同的提示样式
- AI 教育产品：内容过滤和账号限制使用相同的反馈界面
共性结论：无论产品形态如何，当"拒绝请求"和"终止会话"在界面上无法区分时，即触发 BND-001 模式。
模式 4：ACT-001 —— 高危操作未约束
组件类型
操作按钮组件（Action Button）
漂移症状
当 AI 生成包含用户数据操作的界面时，常见以下场景：
- 删除账户：AI 生成"确认"按钮，样式为普通主按钮（蓝色实心）
- 清空数据：AI 生成"执行"按钮，没有二次确认步骤
- 转移权限：AI 生成"同意"按钮，没有后果说明
问题：这些操作在界面上与普通操作（保存设置、修改昵称）没有任何区别，用户可能误触：
- 蓝色实心按钮的点击成本太低
- 没有二次确认，一次点击就执行
- 没有说明"此操作不可恢复"
- 没有提供取消或撤销路径
根因分析
系统缺少 destructive_action 语义约束。AI 在生成按钮时，只理解了"用户需要一个按钮"，没有理解"这个按钮的后果是毁灭性的"。
结果：高危操作和普通操作在界面语义上等价，用户误触风险极高。
通用场景分类
| 操作性质 | 后果 | 应有的按钮样式 | 应有的交互流程 |
|---|---|---|---|
| 不可逆删除 | 数据永久丢失 | 红色空心描边 | 二次确认弹窗 + 输入账户名 |
| 批量清空 | 大量数据丢失 | 红色空心描边 | 二次确认 + 数据备份提示 |
| 权限转移 | 控制权变更 | 橙色警告样式 | 确认后果 + 接收方验证 |
| 普通操作 | 可撤销 | 蓝色实心 | 直接执行 |
跨产品一致性证据
该模式在以下类型的 AI 产品中普遍存在：
- AI 生成后台管理界面：删除用户、清空日志等操作缺少约束
- AI 生成设置页面：账户注销、数据导出等操作样式统一
- AI 生成电商界面：订单取消、退款申请等操作缺少后果说明
共性结论：无论产品形态如何，当不可逆操作按钮与普通操作按钮使用相同样式时，即触发 ACT-001 模式。
模式 5：ALR-001 —— 告警文案语义降级
组件类型
告警文案组件（Alert Copy）
漂移症状
在 AI 生成告警或状态提示时，系统级故障的文案经常出现：
- 将 "Critical" 替换为 "严重"——情绪权重降低，用户可能低估紧急程度
- 将 "System Failure" 替换为 "服务异常"——模糊化，不说明影响范围
- 将 "Data Loss Risk" 替换为 "请稍后重试"——掩盖真实后果
问题：LLM 的同义词替换在概率性输出中，把精心设计的语义层级抹平了：
- "严重"和"Critical"在 LLM 的语义空间中是等价的
- 但在用户的认知空间中，"严重"的紧急感低于"Critical"
- 结果：用户延迟响应，系统故障扩大
根因分析
系统缺少 synonym_firewall 语义约束。LLM 没有"语义权重"的概念，只有"词频统计"和"上下文概率"。
结果：同义词替换在概率输出中，把人工设计的语义层级随机降级。
通用场景分类
| 场景 | 标准术语（必须） | 禁止替换为（拦截） | 降级后果 |
|---|---|---|---|
| 系统级故障 | Critical | 严重、紧急、重要 | 用户低估紧急程度，延迟响应 |
| 用户可恢复 | Warning | 注意、提醒、提示 | 用户忽视，不采取行动 |
| 纯通知 | Info | 消息、公告 | 用户过度关注，浪费注意力 |
| 操作成功 | Success | 完成、结束 | 用户不确定是否真正成功 |
跨产品一致性证据
该模式在以下类型的 AI 产品中普遍存在：
- AI 运维助手：生成的告警文案术语不统一，值班员判断困难
- AI 客服系统：生成的风险提示文案情绪权重不一致
- AI 医疗辅助：生成的诊断提示文案严重程度表达模糊
共性结论：无论产品形态如何，当 AI 生成的文案中关键术语被同义词替换，导致语义权重降级时，即触发 ALR-001 模式。
模式 6：INF-001 —— 信息状态权重未对齐
组件类型
信息状态组件（Info State）
漂移症状
在 AI 产品中，系统向用户推送的状态提示包括：
- 系统通知："新功能上线"——纯信息，无需行动
- 状态警告："存储空间不足 80%"——需要注意，但非紧急
- 操作确认："设置已保存"——操作反馈，自动消失
- 安全提示："检测到异常登录"——需要立即关注
问题：这四种完全不同的信息状态，在界面上可能使用相同的视觉权重（相同的颜色、相同的图标、相同的停留时间），用户无法快速区分：
- 这个提示我需要立即处理吗？
- 这个提示会自己消失吗？
- 这个提示如果忽略会有什么后果？
根因分析
系统缺少 info_weight 语义令牌。所有信息状态被统一处理为"通知"，没有按"紧急程度 × 行动要求"分级。
结果：用户的信息处理优先级被界面语义打乱，重要提示被忽略，次要提示被过度关注。
通用场景分类
| 信息权重 | 用户行动要求 | 应有的视觉表达 | 应有的停留策略 |
|---|---|---|---|
| 紧急（Urgent） | 必须立即行动 | 红色脉冲 + 声音提示 | 不自动消失，必须手动关闭 |
| 重要（Important） | 需要关注，但非立即 | 黄色静态 + 图标 | 10 秒后自动消失 |
| 通知（Notice） | 无需行动，知晓即可 | 蓝色静态 + 图标 | 5 秒后自动消失 |
| 反馈（Feedback） | 操作结果确认 | 绿色静态 + 图标 | 3 秒后自动消失 |
跨产品一致性证据
该模式在以下类型的 AI 产品中普遍存在：
- AI 对话产品：系统通知和安全警告使用相同的提示样式
- AI 协作工具：编辑冲突提示和普通消息使用相同的提醒方式
- AI 创作工具：保存成功提示和错误提示使用相同的视觉权重
共性结论：无论产品形态如何，当"紧急安全提示"和"普通功能通知"在界面上无法区分时，即触发 INF-001 模式。
Gap 期局限性声明
当前状态： 架构推演与最小可行原型阶段。YAML 规范、校验逻辑为定义层实现，尚未接入生产级 LLM API 或 CI 流水线。欢迎基于现有思路共建。
关于作者
魏雯，体验架构设计师。
专注于：AI 界面的语义治理。解决的核心问题：让 LLM 生成的界面不偏离设计规范。
10+ 年互联网设计经验。设计系统 / 体验工程 / AI 原生｜广州 / 深圳
