设计意图不是文档里的文字，而是系统里的契约。
如果你做过跨产品的界面设计，一定遇到过这种崩溃时刻：
你定义了「告警卡片 = 红色脉冲 + 必须人工确认」。三个月后，另一个产品的设计师复用了你的组件，但把红色改成了橙色——因为那个产品的主题色是橙色系。再三个月后，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 个迭代周期
- 覆盖不全：50 个产品的 500 个页面，人工走查只能覆盖 20-30%
- 穿透断裂：清单检查了"前端是否按规范实现"，但没有检查"规范本身是否被系统正确理解"
核心判断：当检查清单的维护成本超过其拦截风险的价值时，治理体系就从"资产"变成了"负债"。此时需要一次形态升级——从"人查清单"到"机器查清单"。
四、概率性界面：当 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 的格式约束不承载设计语义，合规系统的审计不感知用户体验。
我们需要的是一架梯子：一种让设计意图从"文档形态"转化为"机器可读协议"的编译层。
这种协议应该具备四个特征：
- 语义化：不仅定义"这个颜色是什么色值"，还定义"这个颜色代表什么业务语义"
- 形式化：用结构化格式（如 YAML/JSON）承载，而非自然语言文档
- 可编译：能被翻译为 LLM 的输入约束和输出校验规则
- 可版本化：像数据库 Schema 一样被 Git 追踪、被影响面分析
六、结语：从"依靠人的理解和记忆"到"依靠系统的编译和执行"
设计治理的发展经历了三个阶段：
- 资产库阶段：组件和 Token 是"参考素材"，靠设计师和工程师的记忆复用
- 规范阶段：规则和约束写在文档里，靠人工审查和走查落地
- 协议阶段：意图和约束被形式化为机器可读的格式，靠系统自动编译和执行
当界面从确定性走向概率性，当 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 交互范式
独立研发｜intent-schema-compiler
设计意图的形式化约束编译框架，将设计意图的不可变边界编译进 LLM 的输入约束与输出校验。
求职意向：设计系统 / 体验工程 / AI 原生｜广州 / 深圳
欢迎私信联系请多指教。
下一篇预告：《设计意图的形式化：从自然语言到机器可读——意图协议长什么样？》
本文是设计意图治理系列的第一篇。后续将围绕意图协议的具体形态、语义层设计、治理层规则、执行层编译、组织落地路径展开。欢迎在评论区讨论：你的团队目前在"人查清单"还是"机器查清单"阶段？
