设计语义→LLM 约束：一个让 AI 界面不再"胡说"的契约编译框架

一个习惯用"设计意图→配置规则→自动化输出"思维做治理的体验设计师说：Schema-As-Code 不仅是工程师的类型契约，也是设计师的语义契约。

---

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

你明明在设计系统里定义了「P0 告警 = 红色脉冲 + 必须人工确认」，但 LLM 生成的文案却写着「严重故障，建议自动修复」。用户看到的界面依然红红绿绿，但背后的语义已经完全跑偏——"严重"不等于"critical"，"自动修复"更是触发了你明令禁止的高危操作。

这不是 Prompt 写得不好，也不是模型不够强。这是设计意图在从"人脑"走向"机器"的过程中，没有一条保真通道。

我过去三年在华为做运维控制台的体验治理，过去一年在 Gap 期独立研发，核心就是在解决这件事。这篇文章想分享的，是我沉淀下来的一个框架：设计语义→LLM 约束（Schema-As-Code）设计意图语义契约编译框架。

名字很长，但意思很简单：让设计师的意图，像代码一样被机器读懂、被版本管理、被自动校验。

---

一、为什么需要这个框架？先看清三个"断裂"

断裂 1：Design Token 只管"长什么样"，不管"代表什么"

现有的 Design Token 系统（比如 Adobe Spectrum、Style Dictionary）已经非常成熟，能确保"主色 #1890FF"在 Web、iOS、Android 上保持一致。但它回答不了这个问题：

当 LLM 要描述一个"系统级故障"时，它应该用 "critical"、"严重"、"紧急" 还是 "危急"？

传统 Token 只定义了「色值」，没有定义「语义」。在确定性界面里，这不算大问题——前端工程师手动写死 "critical" 就行。但在 AI 界面里，LLM 是实时生成文案的，没人帮它"手动写死"。

断裂 2：Prompt Engineering 只管"怎么问"，不管"什么不能说"

现在的 AI 团队都在做 Prompt Engineering，目标是"让 LLM 答得更好"。但 Prompt Engineering 有一个盲区：它只优化生成质量，不约束生成边界。

你可以 Prompt 里写"请用专业语气生成告警文案"，但 LLM 依然可能输出「严重故障，建议自动重启服务」。格式完全正确，语义完全跑偏，安全直接突破。

我们需要的是契约注入——不是"怎么问能让 LLM 答得更好"，而是"不管你怎么生成，这些红线你不能突破"。

断裂 3：设计规范活在文档里，LLM 不读语雀

设计师把规则写在 Figma 注释里、语雀文档里、Excel 表格里。但 LLM 不读语雀，前端工程师也不可能把 50 页设计规范背下来写进 Prompt。

结果是：规则存在，但规则无法被机器执行。这在确定性界面里可以靠"人肉审查"弥补，在 AI 界面里就是系统性风险。

---

二、框架总览：三层架构 + 双轨编译

这个框架的核心思路是：在「设计师的意图」和「LLM 的生成」之间，插入一个编译层——把设计意图翻译成机器可读的约束契约，再让这份契约同时驱动 LLM 的输入（Prompt 约束注入）和输出（四层推演校验）。

2.1 三层架构

┌─────────────────────────────────────────────┐
│  第一层：语义层（Semantic Layer）              │
│  设计师定义：这个界面应该传达什么意图？         │
│  产出：意图契约 + 语义令牌 + 模式卡片           │
└──────────────────────┬──────────────────────┘
                       │ 编译
┌──────────────────────▼──────────────────────┐
│  第二层：治理层（Governance Layer）            │
│  编译器工作：把意图翻译成 LLM 能懂的约束规则   │
│  产出：Prompt 约束块 + 输出校验 Schema        │
└──────────────────────┬──────────────────────┘
                       │ 消费
┌──────────────────────▼──────────────────────┐
│  第三层：执行层（Execution Layer）             │
│  AI/前端/QA 消费：按契约生成、渲染、测试      │
│  产出：约束 Prompt → LLM 生成 → 校验 → 界面   │
└─────────────────────────────────────────────┘

关键设计：三层之间是契约关系，不是命令关系。语义层不规定治理层用什么格式写规则，只提供「意图的不可变边界」；治理层不规定执行层用什么工具实现，只提供「校验的逻辑规范」。

2.2 双轨编译：推演轨道 vs 生产轨道

这个框架设计了两条编译轨道，对应不同的成熟度阶段：

维度	轨道 A：推演编译	轨道 B：生产编译
阶段	独立研发期 / 架构验证期	平台落地期 / 接入研发环境后
触发	人工触发（本地推演）	自动触发（Git Push / CI 流水线）
形态	伪代码逻辑 + YAML 规范	可执行编译器服务 + CI 卡点
校验	mock 数据推演	真实 LLM API 调用 + 运行时校验

为什么要分两条轨道？

因为设计意图的编译不是一蹴而就的。在研发环境没到位之前，你依然可以用「推演轨道」验证架构可行性——用 YAML 定义规则、用伪代码展示编译逻辑、用 mock 数据跑通场景测试。等团队资源到位了，再逐步转化为「生产轨道」的可执行服务。

---

三、【特别标注】语义令牌：Design Token 的语义化延伸

这是框架最核心的概念创新，也是我与现有 Design Token 体系最大的差异点。

3.1 传统 Design Token 长这样：

color:
  critical: "#FF4D4F"      # 只有色值，没有语义

前端工程师知道这是红色，但 LLM 不知道「critical」代表「系统级故障，需立即响应」。

3.2 语义令牌（Semantic Token）长这样：

semantic_tokens:
  status:
    critical:
      # 1. 业务语义层（人读）
      description: "系统级故障，需立即响应"

      # 2. 视觉映射层（前端消费）
      visual_mapping:
        color_token: "status.critical"
        motion_token: "pulse.red.urgent"
        sound_token: "alert.high"

      # 3. LLM 约束层（AI 消费）← 核心增量
      llm_constraints:
        - "生成内容必须包含明确的故障定位信息"
        - "禁止提供未经验证的修复建议"
        - "必须附带人工升级路径"

      # 4. 同义词黑名单（防漂移）
      prohibited_synonyms: ["严重", "紧急", "危急", "重大"]

四层结构的设计意图：

• 业务语义层：让产品经理和设计师确认「这个令牌代表什么」
• 视觉映射层：让前端工程师知道「渲染时用什么色值和动效」
• LLM 约束层：让 AI 工程师知道「生成内容时必须遵守什么规则」
• 同义词黑名单：防止 LLM 用自然语言同义词替代结构化语义标识

这四层支持独立迭代：视觉主题升级不影响 LLM 约束，业务规则变更自动触发约束更新，AI 场景扩展不需要重写视觉定义。

3.3 语义令牌解决什么问题？

用一个真实场景说明：

没有语义令牌：LLM 生成「严重故障，建议自动重启」→ 前端渲染红色告警卡片 → 用户看到红色但文案语义不对，且高危操作建议未被拦截。

有语义令牌：编译器读取 semantic_tokens.status.critical → 在 Prompt 中注入「必须使用 critical 语义令牌，禁止用严重/紧急替代，禁止建议自动执行」→ LLM 生成「critical 故障，建议联系运维工程师确认」→ 前端渲染红色脉冲卡片 → 语义和视觉一致，安全红线未被突破。

---

四、【特别标注】四层推演校验：给 LLM 输出设四道安检门

约束不仅要在输入侧（Prompt），还要在输出侧（校验）。我设计了四层递进式校验，每层负责不同的风险类型：

层级	安检内容	未通过怎么办	优先级
语法推演	JSON 结构完整吗？字段类型对吗？必填项有吗？	阻断（BLOCK）	P0
语义推演	语义令牌匹配吗？命中同义词黑名单了吗？	阻断（BLOCK）	P0
安全推演	命中禁止模式了吗？高危操作有确认标记吗？	阻断（BLOCK）	P0
美感推演	文案太长了吗？信息密度够吗？可读性达标吗？	警告（WARN）	P1

为什么阻断优于修正？

如果校验失败，我不建议让 LLM "重新生成一次"。因为自动重试可能引入新的概率漂移——第一次说"严重"，第二次可能说"危急"。正确的做法是直接阻断，升级人工处理。

状态机流程：

LLM 输出
    ↓
语法推演 → 失败 → BLOCK → 返回"结构缺失"
    ↓ 通过
语义推演 → 失败 → BLOCK → 返回"语义漂移：用'严重'替代了'critical'"
    ↓ 通过
安全推演 → 失败 → BLOCK → 返回"安全突破：建议自动执行修复"
    ↓ 通过
美感推演 → 失败 → WARN → 记录日志，继续交付
    ↓ 通过
置信度校验 → < 0.7 → ESCALATE → 触发降级策略（显示人工模板）
    ↓ >= 0.7
PASS → 允许渲染到界面

---

五、意图契约：设计意图的"宪法"

语义令牌是"原子"，意图契约是"分子"——它把多个语义令牌、约束规则、校验策略组装成一个完整的「设计意图包」。

{
  "intent_id": "AW-001",
  "semantic_domain": "observational",
  "immutable_boundaries": [
    {
      "boundary_type": "safety",
      "constraint_rule_ref": "rules/safety-guardrails.yaml",
      "violation_action": "block"
    },
    {
      "boundary_type": "semantic",
      "constraint_rule_ref": "rules/semantic-tokens.yaml",
      "violation_action": "escalate"
    }
  ],
  "output_schema_ref": "rules/output-constraints/response-schema.yaml",
  "version": "1.0.0"
}

关键字段解释：

• immutable_boundaries：不可变边界。明确告知 LLM 和工程师——这些边界绝对不能突破，突破了触发什么动作（阻断 / 升级 / 降级）。
• violation_action：违规动作。不是"建议不要这样做"，而是"这样做会触发什么工程动作"。
• version：语义版本。意图变更必须版本化管理，像 API 接口一样做 breaking change 声明。

---

六、人机边界：AI 不能碰的红线

在 AI 界面里，设计师不仅要定义"界面长什么样"，还要定义"人和 AI 各自能做什么"。

human_ai_boundary:
  human_mandatory:          # 必须由人决策的
    - "告警等级判定（P0/P1/P2/P3）"
    - "是否触发自动修复（destructive 操作确认）"
    - "升级路径选择"

  ai_assisted:               # AI 可以辅助生成的
    - "根因分析文本生成"
    - "修复建议列表生成"
    - "影响面描述生成"

  ai_prohibited:             # AI 绝对不能碰的
    - "直接执行修复操作"
    - "修改告警阈值配置"
    - "关闭或忽略告警"

这不是技术问题，是治理问题。在没有形式化定义之前，"AI 能不能建议自动重启"是一个扯皮话题——AI 工程师说"模型有能力建议"，产品经理说"用户可能误操作"，设计师说"界面应该二次确认"。

形式化之后，这个话题变成：ai_prohibited 列表里有"直接执行修复操作"，LLM 输出一旦命中，安全推演层直接 BLOCK。

---

七、编译流程：从意图到约束的 6 步翻译

推演编译轨道把设计意图翻译成 LLM 约束，分为 6 个阶段：

阶段 0：意图加载
    读取 intent-schema.json，提取不可变边界列表

阶段 1：语义解析
    加载 semantic-tokens.yaml，解析每个语义令牌的 llm_constraints 和 prohibited_synonyms

阶段 2：约束推导
    将语义约束 → Prompt 约束文本
    将安全约束 → 负向约束文本
    将结构约束 → JSON Schema 片段

阶段 3：校验生成
    生成语法校验规则（字段类型/必填项）
    生成语义校验规则（令牌匹配/同义词黑名单）
    生成安全校验规则（禁止模式/跨字段逻辑）
    生成美感校验规则（文案长度/可读性）

阶段 4：场景生成
    生成 Happy Path 测试用例（正常输入 → 预期通过）
    生成 Edge Case 测试用例（同义词替代/自动执行/置信度不足/结构缺失）
    生成 Fallback 测试用例（校验失败后的降级策略）

阶段 5：影响分析
    比对当前版本与上一版本的差异
    分析哪些组件、哪些 Prompt、哪些测试用例需要同步更新

这 6 个阶段目前以伪代码 + YAML 规范的形式存在，用于验证架构可行性。等接入研发环境后，会逐步转化为可执行的编译器服务。

---

八、与行业现有方案的关系：不是替代，是架桥

这个框架不替代任何现有工具，而是填补它们之间的语义断层：

现有方案	解决什么问题	没解决什么问题	本框架的填补位置
Adobe Spectrum	视觉属性跨平台同步	视觉属性的业务语义定义及 LLM 约束	在 Token 层之上增加语义契约层
OpenAI Structured Outputs	LLM 输出格式 100% 合法	输出内容的业务语义正确性	在格式校验之上增加语义推演层
Pydantic / Zod	工程师定义数据结构 Schema	设计师参与语义定义、校验失败无降级策略	在工程师 Schema 之上增加设计语义 Schema
LangChain	Prompt 模板管理	设计意图的不可变边界注入	在 Prompt 模板层之上增加意图编译层

一句话总结：行业现有方案是三个天花板——设计系统天花板、LLM 工程天花板、合规系统天花板。本框架是天花板之间的梯子。

---

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

当前设计意图语义契约编译框架处于架构推演与最小可行原型阶段：

• 校验引擎为逻辑定义（伪代码），尚未转化为可执行插件
• 尚未接入生产级大模型 API（OpenAI / Claude / 自研模型）
• 企业 SSO / 审计日志 / CI 集成为占位状态
• v0.2.0 目标：支持大模型 API 适配器、ESLint 插件、GitHub Actions 卡点

本文所述架构协议、YAML 规范、编译思维链均已开源发布于 GitHub 仓库，欢迎审阅与 Fork。

---

关于作者

魏雯，14 年互联网工作经验。

5 年阿里中台用户体验设计师，产品化 / 规范化 / 商业化经验。参与从创意工具到规则引擎的转型，建立"设计意图 → 配置规则 → 自动化输出"的中台治理思维，沉淀模式库与组件化规范。

3 年华为研发岗体验设计工程师，规则驱动界面体验治理实践。建立运维控制台"一致性（物理层）→ 易用性（行为层）→ 安全感（感知层）"三维升级方案，将监管控业务闭环映射为设计系统协议，验证设计意图在冻结架构条件下的治理可行性。

独立研发中，深入体验设计领域 Schema 方向。当前处于 Gap 期独立研发阶段，已完成设计意图语义契约编译框架 v0.1.0 架构协议发布。

求职意向：体验架构方向 / AI 原生方向，目标城市广州 / 深圳。欢迎私信联系。