
> 设计意图不是文档里的文字，而是系统里的契约。

如果你做过跨产品的界面设计，一定遇到过这种崩溃时刻：

你定义了「告警卡片 = 红色脉冲 + 必须人工确认」。三个月后，另一个产品的设计师复用了你的组件，但把红色改成了橙色——因为那个产品的主题色是橙色系。再三个月后，AI 助手生成的告警文案里写着「**严重**故障，建议**自动修复**」——用户看到的界面依然红红绿绿，但背后的语义已经完全跑偏。

这不是某个团队的失误。这是**设计意图在从"人脑"走向"系统"的过程中，没有一条保真通道**。

---

## 一、设计意图的三次断裂

设计意图的传递链条，在确定性界面（即传统由工程师硬编码的界面）里就已经很脆弱了：

```
业务需求 → 设计意图 → 设计稿 → 前端代码 → 用户界面
```

这个链条里有三次断裂：

### 断裂 1：语义断裂（Semantic Fracture）

同一概念在不同产品中的定义不一致。

> A 产品的「红色」代表"系统故障"，B 产品的「红色」代表"按钮强调"，C 产品的「红色"代表"表单错误"。同一个运维工程师在三个产品间切换，看到红色时的反应完全不同。

这不是设计师不专业，而是**语义定义以文档形态存在，无法被机器自动校验**。每个产品的设计师都认真写了规范，但规范之间没有统一的语义注册表。

### 断裂 2：规则断裂（Rule Fracture）

约束规则以文档/表格/语雀形态存在，无法被自动执行。

> 「高危操作必须二次确认」写在设计规范里，但前端代码里没有强制校验。设计师走查时发现了就修，没发现就漏过去。规范的存在，不等于规范的执行——因为文档更新与代码变更之间没有自动同步机制。

这是**规则载体的形态问题**——文档级规则在分布式系统中必然衰减。你可以增加走查频次、加强人工审查，但无法阻止规则与实际界面之间的偏差随时间指数增长。

### 断裂 3：验证断裂（Validation Fracture）

缺乏自动化验证手段，依赖人肉走查。

> 一个新规范发布后，需要手动同步给 10 个前端负责人，遗漏概率随人数指数上升。每次发版前，设计师逐页核对 50 个产品的 500 个页面。覆盖率 20%，漏检率 80%。出了问题回溯时，发现是三个版本前的规范变更没有同步到某个子产品。

这是**验证手段的覆盖问题**——人眼的带宽有限，无法持续监控分布式系统的语义一致性。

---

## 二、治理熵增：规模化组织的结构性必然

上述三次断裂，在缺乏统一治理平台的组织中，会随时间产生**治理熵增（Governance Entropy）**。

什么是单点自治系统？每个子产品拥有独立的设计决策权、独立的技术栈、独立的发布节奏。这种架构在扩张期是高效的——团队小而快，不需要协调成本。但当组织规模超过某个阈值（通常是 5-8 个并行产品），自治的代价开始显现：接口语义、视觉形态、交互路径随时间产生结构性断层。

这不是某个公司特有的困境。任何规模化组织在快速扩张期都会遇到：**规范写在文档里，文档靠人维护，人靠记忆执行，记忆随人员流动衰减。**

---

## 三、从"人查清单"到"机器查清单"

面对治理熵增，大多数团队的第一反应是建立检查清单——用表格和文档把"应该检查什么"系统化。这是必要的，但远远不够。

### 3.1 三类治理维度的普适抽象

任何界面的治理体系，无论行业、无论规模，都可以抽象为三类检查维度：

| 治理维度 | 回答的命题 | 典型检查项 |
|---|---|---|
| **语义定义检查** | "业务意图是否被正确翻译为设计语义？" | 需求基线是否定义了语义边界？接口规格是否携带语义类型？ |
| **约束合规检查** | "内容能不能说？操作能不能做？突破了怎么办？" | 禁用词库是否被强制执行？高危操作是否有二次确认？ |
| **系统健康检查** | "流程通不通？有没有遗漏？出了问题能不能发现？" | 设计系统健康度是否可量化？异常是否能自动告警？ |

### 3.2 "人查"的局限

检查清单在"人查"模式下有四大局限：

1. **效率衰减**：清单越长，人工核对时间越长，边际收益递减
2. **更新滞后**：规范变了，清单更新往往滞后 1-2 个迭代周期
3. **覆盖不全**：50 个产品的 500 个页面，人工走查只能覆盖 20-30%
4. **穿透断裂**：清单检查了"前端是否按规范实现"，但没有检查"规范本身是否被系统正确理解"

**核心判断**：当检查清单的维护成本超过其拦截风险的价值时，治理体系就从"资产"变成了"负债"。此时需要一次形态升级——从"人查清单"到"机器查清单"。

---

## 四、概率性界面：当 LLM 加入后，断裂被指数放大

确定性界面的治理已经很难了。但当 LLM 生成的内容直接进入用户界面时，问题变得更复杂。

### 4.1 确定性界面 vs 概率性界面

| 维度 | 确定性界面 | 概率性界面 |
|---|---|---|
| 内容来源 | 工程师编写的固定代码 | LLM 实时生成的自然语言 |
| 语义稳定性 | 稳定——同一操作始终同一反馈 | 漂移——同一 Prompt 可能生成不同表述 |
| 设计可控性 | 高——设计师可以精确控制每个像素 | 低——设计师只能控制输入，无法精确控制输出 |
| 规则消费方 | 前端系统（可读取设计规范） | LLM（默认不会主动遵循设计规范，除非规范被显式编码到 Prompt 或工具调用中） |

### 4.2 概率性界面的特殊断裂

在概率性界面中，三类断裂被进一步放大：

- **语义断裂**：LLM 用"严重"替代"critical"——格式完全正确，语义已经漂移
- **规则断裂**：「高危操作必须二次确认」的约束无法被编译进 LLM 的输入
- **验证断裂**：LLM 输出直接进界面，传统验证手段无法检测语义正确性

**关键洞察**：确定性界面的治理规则至少还能"靠人查"，概率性界面的治理规则连"人查"都做不到——因为 LLM 默认不会主动遵循设计规范，除非规范被显式编码到 Prompt 或工具调用中。

---

## 五、意图协议：让设计意图从"文档"走进"系统"

面对上述断裂，行业目前的应对是碎片化的：

- 设计系统阵营（如 Adobe Spectrum）做了视觉属性同步的天花板——Token 跨平台一致
- LLM 工程阵营（如 OpenAI Structured Outputs）做了输出格式约束的天花板——JSON 格式 100% 合规
- 合规系统阵营做了工程规则审计的天花板——变更可追溯

但三个天花板（设计系统、LLM 结构化输出、合规审计系统）之间**没有梯子**。设计系统的 Token 不告诉 LLM "这个红色代表告警"，LLM 的格式约束不承载设计语义，合规系统的审计不感知用户体验。

**我们需要的是一架梯子：一种让设计意图从"文档形态"转化为"机器可读协议"的编译层。**

这种协议应该具备四个特征：

1. **语义化**：不仅定义"这个颜色是什么色值"，还定义"这个颜色代表什么业务语义"
2. **形式化**：用结构化格式（如 YAML/JSON）承载，而非自然语言文档
3. **可编译**：能被翻译为 LLM 的输入约束和输出校验规则
4. **可版本化**：像数据库 Schema 一样被 Git 追踪、被影响面分析

---

## 六、结语：从"依靠人的理解和记忆"到"依靠系统的编译和执行"

设计治理的发展经历了三个阶段：

1. **资产库阶段**：组件和 Token 是"参考素材"，靠设计师和工程师的记忆复用
2. **规范阶段**：规则和约束写在文档里，靠人工审查和走查落地
3. **协议阶段**：意图和约束被形式化为机器可读的格式，靠系统自动编译和执行

当界面从确定性走向概率性，当 LLM 成为内容生产方，当语义漂移成为主要风险，设计治理就必须从"依靠人的理解和记忆"升级为"依靠系统的编译和执行"。

这个"系统"不是文档，是**意图协议**。

---

## 预告：下一篇中的语义令牌

下一篇将展示如何把自然语言规则翻译为机器可读的 YAML 语义令牌。以下是预告示例：

| 自然语言规则 | 翻译后的 YAML 片段 |
|---|---|
| critical 令牌代表系统故障，禁止 AI 建议自动修复 | `prohibited_patterns: ["自动修复"]` |
| 高危操作必须人确认 | `ai_prohibited: ["直接执行"]` |
| P0 告警必须用红色脉冲 + 高频音效 | `visual_mapping: { color_token: "status.critical", motion_token: "pulse.red.urgent", sound_token: "alert.high" }` |
| "严重"不能替代 "critical" | `prohibited_synonyms: ["严重", "紧急", "危急", "重大"]` |
| 生成内容必须包含故障定位信息 | `llm_constraints: ["生成内容必须包含明确的故障定位信息"]` |

---

## Gap 期局限性声明（v0.1.0）

本文所述"意图协议"目前处于架构推演与最小可行原型阶段。具体的协议模板、YAML 规范与编译逻辑将在下一篇中完整展开；当前校验引擎为逻辑定义（伪代码），尚未接入生产级 LLM API 或 CI 流水线。

---
### 关于作者

**魏雯**，10+ 年互联网设计经验。

**阿里妈妈**（5 年）｜中台体验设计｜创意工具 → 规则引擎 → 设计提效  
**华为**（3 年）｜体验设计工程师｜设计系统 / 跨产品一致性 / 三维治理协议（一致性→易用性→安全感）/ 大模型 Agent 交互范式

**独立研发**
设计意图的形式化约束编译框架，将设计意图的不可变边界编译进 LLM 的输入约束与输出校验。

**求职意向**：设计系统 / 体验工程 / AI 原生｜广州 / 深圳  

---

**下一篇预告**：《设计意图的形式化：从自然语言到机器可读——意图协议长什么样？》

> 本文是设计意图治理系列的第一篇。后续将围绕意图协议的具体形态、语义层设计、治理层规则、执行层编译、组织落地路径展开。欢迎在评论区讨论：你的团队目前在"人查清单"还是"机器查清单"阶段？


你定义了「告警卡片 = 红色脉冲 + 必须人工确认」。三个月后，另一个产品的设计师复用了你的组件，但把红色改成了橙色——因为那个产品的主题色是橙色系。再三个月后，AI 助手生成的告警文案里写着「严重故障，建议自动修复」——用户看到的界面依然红红绿绿，但背后的语义已经完全跑偏。

设计意图治理：当界面从确定性走向概率性

本文提出“设计意图协议”概念，直击跨产品设计中语义漂移、规则失效与验证缺失三大断裂。当LLM介入界面生成，传统文档式规范彻底失能。唯有将设计意图转化为机器可读、可编译、可校验的结构化协议，才能实现从“人查清单”到“系统自治”的治理跃迁。

人工智能

前端

架构设计

本文探讨设计意图在系统传递中的断裂问题，指出传统依赖文档和人工审查的治理方式在规模化团队和AI生成界面中面临挑战。文章提出“意图协议”概念，主张将设计规则转化为机器可读格式，通过系统自动编译执行，确保语义一致性。适用于设计系统、AI交互及跨产品体验治理场景，助力团队从“人治”迈向“机治”。

数据库

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

设计意图治理：当界面从确定性走向概率性-腾讯云开发者社区-腾讯云

设计意图治理：当界面从确定性走向概率性

设计意图治理：当界面从确定性走向概率性

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐