声明：本文所有界面分析基于 ChatGPT 公开社区截图及可观察界面行为还原，不依赖内部代码或设计文档。分析视角为体验架构，聚焦"界面语义层"而非视觉重设计。
本文是《设计意图治理》系列的第 6 篇。
前 5 篇我们完成了从立论到工程化的完整闭环：第 1 篇指出 AI 界面从确定性走向概率性带来的语义漂移风险；第 2 篇将自然语言规则翻译为机器可读的 YAML 协议；第 3 篇论证了规模化交付中的成本优化逻辑；第 4 篇提出 Schema-As-Code 的架构设计；第 5 篇通过可交互 DEMO 展示了约束显化的工程形态。
从这一篇开始，系列转向具体产品的界面观察。我不再讨论抽象架构，而是把前 5 篇建立的方法论——语义层、意图协议、约束显化——应用到真实可观察的 AI 产品界面中，检验它们是否存在"语义断层"，以及如果显化语义层，界面可以如何改进。
一、我观察到的：四种错误，同一种红色
在 ChatGPT 的用户社区里，我收集到至少四种错误状态的界面截图。它们出现在不同场景下，但共享同一种视觉语言——红色。
“四种后果，同一种颜色”
| 错误文案 | 出现场景 | 视觉表达 | 用户实际后果 |
|---|---|---|---|
| “Error in message stream” | 消息流中断 | 红色背景条 + 警告图标 | 对话可能已丢失，需刷新 |
| “network error” | 网络连接失败 | 红色文字，内联显示 | 完全无法继续，需重发 |
| “Something went wrong” | 系统异常 | 红色边框卡片 + 帮助链接 | 未知故障，可能需联系客服 |
| “Too many requests” | 频率限制 | 红色文字 + 感叹号图标 | 只需等待 1 小时，无需操作 |
问题不在"红色用得太多"，而在"红色只表达了情绪，没有表达性质"。
当用户看到红色时，大脑接收到的信号是"出事了"。但出事的严重程度、可恢复性、用户该采取的行动——这些信息在界面语义层是缺失的。
二、语义断层：后果差异没有被分级
2.1 断层一：视觉权重与后果严重程度倒挂
“network error” 只是两行红色文字，视觉权重最轻，但它意味着对话完全中断，用户必须手动重发或刷新。而 “Too many requests” 也是红色文字，却只是让用户等待，不需要任何操作。
“视觉权重相同，但后果完全不同”
用户在 0.5 秒内无法判断：这个红色是"等一等就好"还是"我的对话已经丢了"？
2.2 断层二：文案只描述现象，不指引行动
四个错误文案都在告诉用户"发生了什么"（Error / Something went wrong / network error），但没有一个告诉用户"该做什么"。
● “Error in message stream” → 我该刷新还是重发？历史还在吗？
● “network error” → 是我的 WiFi 断了还是服务器挂了？点哪里恢复？
● “Something went wrong” → 这是临时故障还是账户问题？help center 能解决吗？
● “Too many requests” → 我是该等、该充钱、还是该换网络？
“4 种错误后果差异极大，但共用同一种红色视觉语言”
2.3 断层三：缺少语义令牌，系统无法区分错误性质
在传统软件界面中，我们会区分：
●通知（Notification）：告诉你一件事，不用管
●警告（Warning）：需要注意，但可以继续
●错误（Error）：阻断操作，必须处理
但 ChatGPT 的四种错误状态，在工程实现层面可能缺少一层**语义令牌（Semantic Token）**来区分它们的性质。系统只知道"出错了，显示红色"，但不知道这个错误是fatal（致命）还是retryable（可重试）。
这导致前端在渲染时，没有语义依据来选择不同的视觉模式。红色成了唯一的默认选项。
三、如果显化语义层：从"颜色分级"到"性质分级"
“语义层显化后的四级错误状态”
不需要 redesign 整个界面，只需要在错误状态里多一层语义分级：
| 语义标签 | 含义 | 视觉 | 用户行动 |
|---|---|---|---|
| Fatal | 系统级故障，对话上下文可能丢失 | 红色脉冲 + 八边形警告图标 | 刷新页面 / 导出历史 |
| Transient | 网络抖动，系统可自动恢复 | 灰色加载动画 | 等待，无需操作 |
| Retryable | 用户可自助恢复（频率限制） | 黄色提示 + 时钟图标 | 升级计划 / 设置提醒 |
| Degraded | 部分功能可用，可继续生成 | 蓝色提示 + 继续图标 | 继续生成 |
关键不是视觉 redesign，而是让"错误的性质"先于"颜色"被定义。
当语义层先对齐，视觉层自然会对齐。Fatal 用红色是因为它确实致命，Retryable 用黄色是因为它只是提醒，Transient 用灰色是因为它无需用户干预——颜色变成了语义的结果，而不是默认的容器。
四、背后的语义层定义（YAML 协议）
“这不需要改前端代码，只需要在生成内容前定义语义契约”
这段 YAML 的核心价值在于：它把"设计师对错误性质的理解"翻译成了机器可读的语义契约。
当 LLM 或前端组件在生成错误状态时，不再只是接收"显示红色"的指令，而是接收"这是一个fatal状态，请使用status.critical令牌对应的视觉模式，并附带refresh_page和export_history两个用户行动按钮"。
五、用户心理的变化：从"猜测"到"明确"
“语义层显化前后，用户决策路径对比”
| 当前界面 | 语义层优化后 |
|---|---|
| 用户看到红色 → 猜测严重程度 → 猜测该做什么 → 尝试刷新/等待/联系客服 | 用户看到语义标签 → 立即知道后果 → 看到明确行动按钮 → 一键执行 |
| 认知负担：高（需要推理） | 认知负担：低（直接匹配） |
| 挫败感来源：不确定性 | 信任感来源：可预期性 |
六、总结：这不是 ChatGPT 的设计失误，而是概率性界面的结构性难题
ChatGPT 的四种错误状态共用红色，不是某个设计师的疏忽，而是概率性界面时代的结构性难题——当界面内容本身是动态生成的，约束"语义一致性"的机制天然比约束"视觉一致性"更难建立。
传统软件的错误状态是人工定义的，设计师可以逐个指定颜色和文案。但 AI 产品的错误状态可能由不同模型、不同 pipeline、不同异常捕获机制触发，如果没有一层语义协议来统一约束，每个团队都会按自己的理解选择红色。
解决这个问题的关键，不是在设计稿里多画几种红色，而是在系统里建立一层语义层——让"错误的性质"在生成界面之前就被定义，让视觉层成为语义层的自然映射。
这个案例验证了前 5 篇提出的核心判断：
当界面从确定性走向概率性，语义层比视觉层更容易被忽略，也更容易造成系统性体验问题。
ChatGPT 的四种错误状态共用红色，不是某个设计师的疏忽，而是概率性界面时代的结构性难题——当错误状态可能由不同模型、不同 pipeline、不同异常捕获机制触发时，如果没有一层语义协议来统一约束，每个团队都会按自己的理解选择红色。
解决这个问题的关键，不是在前端多写几种 CSS，而是在系统里建立一层语义层——让"错误的性质"在生成界面之前就被定义，让视觉层成为语义层的自然映射。
下一篇，我将以同样的方法诊断 Perplexity 的 Pro Search 过程状态，分析"Searching / Reading / Wrapping up" 背后的语义断层——当 AI 生成答案时，用户如何知道"它现在是在查资料，还是在开始编答案"。
Gap 期局限性声明（v0.1.0）
本文所述"意图协议"目前处于架构推演与最小可行原型阶段。具体的协议模板、YAML 规范与编译逻辑将在下一篇中完整展开；当前校验引擎为逻辑定义（伪代码），尚未接入生产级 LLM API 或 CI 流水线。
关于作者
魏雯，我是体验架构设计师。我专注于：AI 界面的语义治理。我解决的核心问题：让 LLM 生成的界面不偏离设计规范。
10+ 年互联网设计经验。设计系统 / 体验工程 / AI 原生｜广州 / 深圳
阿里妈妈｜中台体验设计｜创意工具 → 规则引擎 → 设计提效
华为｜体验设计工程师｜设计系统 / 跨产品一致性 / 三维治理协议（一致性→易用性→安全感）/ 大模型 Agent 交互范式
独立研发｜
[intent-schema-compiler](https://2436041978-ops.github.io/intent-schema-compiler/demo/)
[schema-as-code](https://github.com/2436041978-ops/schema-as-code)
设计意图的形式化约束编译框架，将设计意图的不可变边界编译进 LLM 的输入约束与输出校验。
欢迎私信请多指教。
