
> 承接上一篇：既然设计意图需要从"文档"走进"系统"，那这份"意图协议"长什么样？
> 本文展示意图协议的具体形态——不是抽象概念，是可以直接复制粘贴的 YAML/JSON 规范。

上一篇聊了设计意图在确定性界面和概率性界面中的三次断裂：语义断裂、规则断裂、验证断裂。结论是：需要一种让设计意图从"文档形态"转化为"机器可读协议"的编译层。

这篇回答一个更具体的问题：**这份协议长什么样？**

我会用 6 个核心文件、1 个编译流程、1 套校验机制来回答。你可以直接复制这些 YAML/JSON 到你的项目里，作为意图协议的 v0.1.0 原型。

---

## 一、协议总览：三层结构

意图协议分为三层，每层回答一个核心问题：

| 层级 | 回答的问题 | 关键产出 | 格式 |
|---|---|---|---|
| **语义层** | "这个界面应该传达什么意图？" | 意图契约 + 语义令牌 | JSON Schema + YAML |
| **治理层** | "怎么验证意图被正确传递？" | 输入约束 + 输出校验规则 | YAML |
| **执行层** | "怎么执行校验？" | 编译思维链 + 场景测试 | Markdown + YAML |

三层之间是**契约关系**：语义层提供"意图的不可变边界"，治理层提供"校验的逻辑规范"，执行层提供"可复现的验证手段"。

---

## 二、语义层：意图契约 + 语义令牌

### 2.1 意图契约（intent-schema.json）

意图契约是"意图的宪法"——定义不可变边界和违规动作。

**我的设计规则**

| 我的自然语言规则 | 对应的 JSON Schema 设计 |
|---|---|
| 每个意图必须有唯一标识，格式为"字母-数字"组合 | `intent_id` 字段 + `pattern` 正则约束 |
| 意图必须属于四个语义域之一：认知型、交互型、交易型、观测型 | `semantic_domain` 字段 + `enum` 枚举约束 |
| 不可变边界必须包含：边界类型（语义/安全/美学/合规）、引用的规则文件路径、违规时的拦截动作 | `immutable_boundaries` 数组结构，每个元素包含 `boundary_type`、`constraint_rule_ref`、`violation_action` |
| 拦截动作只能是：阻断交付 / 升级人工 / 降级处理 | `violation_action` 的 `enum` 限定为 `block`、`escalate`、`fallback` |
| 意图契约必须带版本号，采用语义版本规范 | `version` 字段 + 正则约束 |

**生成的完整 JSON Schema**

```json
{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "IntentContract",
  "description": "设计意图的形式化契约定义",
  "type": "object",
  "required": ["intent_id", "semantic_domain", "immutable_boundaries", "version"],
  "properties": {
    "intent_id": {
      "type": "string",
      "description": "意图唯一标识",
      "pattern": "^[A-Z]{2}-[0-9]{3}$"
    },
    "semantic_domain": {
      "type": "string",
      "enum": ["cognitive", "interactive", "transactional", "observational"],
      "description": "语义域：认知/交互/交易/观测"
    },
    "immutable_boundaries": {
      "type": "array",
      "description": "不可变边界列表：输出绝对不能突破的约束",
      "items": {
        "type": "object",
        "properties": {
          "boundary_type": {
            "type": "string",
            "enum": ["semantic", "safety", "aesthetic", "compliance"]
          },
          "constraint_rule_ref": {
            "type": "string",
            "description": "引用 rules/ 目录下的规则文件"
          },
          "violation_action": {
            "type": "string",
            "enum": ["block", "escalate", "fallback"],
            "description": "违规时的拦截动作"
          }
        }
      }
    },
    "version": {
      "type": "string",
      "description": "语义版本号",
      "pattern": "^[0-9]+\.[0-9]+\.[0-9]+$"
    }
  }
}
```

### 2.2 语义令牌（semantic-tokens.yaml）

语义令牌是 Design Token 的语义化延伸——不仅定义"这个颜色是什么色值"，还定义"这个颜色代表什么业务语义、生成内容时怎么引用"。

**我的设计规则**

| 我的自然语言规则 | 对应的 YAML 设计 |
|---|---|
| critical 令牌：代表系统级故障，需立即响应 | `description: "系统级故障，需立即响应"` |
| critical 的视觉映射：红色状态令牌、紧急脉冲动效、高优提示音 | `visual_mapping` 下的 `color_token`、`motion_token`、`sound_token` |
| critical 的 LLM 约束：必须包含故障定位信息、不能给未经验证的修复建议、必须有人工升级路径 | `llm_constraints` 数组包含三条约束文本 |
| warning 令牌：代表潜在风险，需关注 | `description: "潜在风险，需关注"` |
| warning 的视觉映射：黄色状态令牌、静态无动效 | `visual_mapping` 下的 `color_token: "status.warning"`、`motion_token: "static"` |
| warning 的 LLM 约束：必须说明风险等级和影响面、必须提供监控指标参考值 | `llm_constraints` 数组包含两条约束文本 |

**生成的完整 YAML**

```yaml
semantic_tokens:
  status:
    critical:
      description: "系统级故障，需立即响应"
      visual_mapping:
        color_token: "status.critical"
        motion_token: "pulse.red.urgent"
        sound_token: "alert.high"
      llm_constraints:
        - "生成内容必须包含明确的故障定位信息"
        - "禁止提供未经验证的修复建议"
        - "必须附带人工升级路径"

    warning:
      description: "潜在风险，需关注"
      visual_mapping:
        color_token: "status.warning"
        motion_token: "static"
      llm_constraints:
        - "生成内容必须说明风险等级和影响面"
        - "必须提供监控指标参考值"
```

### 2.3 语义令牌的同义词映射（防语义漂移扩展）

为了防止 LLM 用自然语言同义词替代结构化语义标识，引入同义词映射机制。

**我的设计规则**

| 我的自然语言规则 | 对应的 YAML 设计 |
|---|---|
| "严重"、"紧急"、"危急"、"重大"等自然语言词，在特定意图上下文中应映射为 critical 令牌 | `synonym_mapping` 下每个 `term` 映射到 `standard_token: "critical"`，并限定适用的 `allowed_contexts` |
| 每个映射条目必须指明适用场景，避免在不该映射的地方误映射 | `allowed_contexts` 数组，记录该映射生效的意图上下文 ID |
| 超出适用上下文的同义词不强制映射，由语义推演层标记为待确认 | 无强制映射，待人工确认 |

**生成的完整 YAML**

```yaml
synonym_mapping:
  - term: "严重"
    standard_token: "critical"
    allowed_contexts: ["AW-001", "AW-002"]
  - term: "紧急"
    standard_token: "critical"
    allowed_contexts: ["AW-001"]
  - term: "危急"
    standard_token: "critical"
    allowed_contexts: ["AW-001"]
  - term: "重大"
    standard_token: "warning"
    allowed_contexts: ["AW-003"]
```

---

## 三、治理层：输入约束 + 输出校验 + 人机边界

### 3.1 输入约束——Prompt 不可变边界注入

不是 Prompt Engineering（"怎么问能让 LLM 答得更好"），而是契约注入（"不管你怎么生成，这些边界你不能突破"）。

**我的设计规则**

| 我的自然语言规则 | 对应的 YAML 设计 |
|---|---|
| 在 Prompt 的 system 消息前缀位置注入意图契约约束 | `injection_strategy.type: "schema_prefix"` + `position: "system_message"` |
| LLM 生成内容时，必须从语义令牌列表中选择，禁止自行发明语义描述 | `constraint_id` C-001，在 Prompt 中注入语义令牌绑定约束 |
| 输出必须符合预定义的结构，禁止添加未定义字段 | `constraint_id` C-002，注入 JSON Schema 约束 |
| 涉及不可逆操作时，LLM 不得生成任何可被直接执行的代码/命令/API 调用 | `constraint_id` C-003，注入负向约束 |
| 校验失败的输出直接阻断并升级人工，不进行自动重试 | `violation_detection.method: "output_schema_validation"` + `fallback: "block_and_escalate"` |

**生成的完整 YAML**

```yaml
rule_id: "IC-PROMPT-001"
rule_name: "Prompt Immutable Boundary Injection"
target: "llm_input.prompt_template"

injection_strategy:
  type: "schema_prefix"
  position: "system_message"

constraints:
  - constraint_id: "C-001"
    description: "语义令牌锁定"
    mechanism: |
      在 Prompt 的 system 消息中注入当前意图契约绑定的语义令牌列表。
      生成内容时，必须从 semantic-tokens.yaml 中定义的令牌集合中选择，
      禁止自行发明新的语义描述。
    example: |
      注入约束："你必须使用 status.critical 语义令牌描述系统故障状态，
                禁止使用'严重'/'紧急'等自然语言同义词替代。"

  - constraint_id: "C-002"
    description: "输出结构锁定"
    mechanism: |
      在 Prompt 中注入 JSON Schema 片段，要求输出必须符合定义的结构。
    example: |
      "你的响应必须包含以下字段：root_cause(字符串)、
       confidence_score(0-1浮点数)、remediation(对象数组)。
       禁止添加未定义字段。"

  - constraint_id: "C-003"
    description: "安全边界锁定"
    mechanism: |
      对于 destructive 类操作意图，在 Prompt 中强制注入负向约束。
    example: |
      "当前意图涉及不可逆操作。你不得生成任何可被直接执行的
       代码/命令/API 调用。你只能提供操作建议和确认流程。"

violation_detection:
  method: "output_schema_validation"
  fallback: "block_and_escalate"
```

### 3.2 输出校验——Response Schema

LLM 输出的"安检门"——定义"结构必须有什么"和"内容绝对不能有什么"。

**我的设计规则**

| 我的自然语言规则 | 对应的 YAML 设计 |
|---|---|
| 告警输出必须包含等级、根因、置信度、处置建议四个字段 | `required_fields` 列出 `alert_level`、`root_cause`、`confidence_score`、`remediation` |
| 告警等级只能是 P0/P1/P2/P3，且必须引用语义令牌 | `alert_level` 字段 + `enum: ["P0","P1","P2","P3"]` + `source: "semantic_token.status"` + `validation: "exact_match"` |
| 根因描述长度在 10-200 字之间，且必须引用语义令牌 | `root_cause` 字段 + `min_length`/`max_length` + `validation: "non_empty + semantic_token_reference"` |
| 置信度是 0-1 之间的浮点数 | `confidence_score` + `minimum`/`maximum` |
| 处置建议中禁止出现"自动执行"、"无需确认"等关键词 | `prohibited_patterns` 列出禁止模式，命中 `critical` 级别直接阻断 |

**生成的完整 YAML**

```yaml
schema_id: "RESP-ALERT-001"
schema_name: "Alert Card Response Schema"
intent_binding: "AW-001"

required_fields:
  - field: "alert_level"
    type: "string"
    enum: ["P0", "P1", "P2", "P3"]
    source: "semantic_token.status"
    validation: "exact_match"

  - field: "root_cause"
    type: "string"
    min_length: 10
    max_length: 200
    validation: "non_empty + semantic_token_reference"

  - field: "confidence_score"
    type: "number"
    minimum: 0.0
    maximum: 1.0
    validation: "range_check"

  - field: "remediation"
    type: "array"
    items:
      type: "object"
      properties:
        action_type:
          type: "string"
          enum: ["manual", "automated", "escalation"]
        description:
          type: "string"
        risk_level:
          type: "string"
          enum: ["low", "medium", "high", "critical"]
    validation: "destructive_action_guard"

prohibited_patterns:
  - pattern: "自动执行"
    severity: "critical"
    action: "block"
  - pattern: "无需确认"
    severity: "critical"
    action: "block"
  - pattern: "(?i)ignore.*warning"
    severity: "high"
    action: "escalate"
```

### 3.3 人机边界——AI 不能碰的红线

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

**我的设计规则**

| 我的自然语言规则 | 对应的 YAML 设计 |
|---|---|
| 告警等级判定（P0/P1/P2/P3）必须由人决策 | `human_mandatory` 数组包含该条目 |
| 是否触发自动修复（destructive 操作确认）必须由人决策 | `human_mandatory` 数组包含该条目 |
| 升级路径选择必须由人决策 | `human_mandatory` 数组包含该条目 |
| 根因分析文本、修复建议列表、影响面描述可以由 AI 辅助生成 | `ai_assisted` 数组包含这三个条目 |
| AI 绝对不能直接执行修复操作 | `ai_prohibited` 数组包含该条目 |
| AI 绝对不能修改告警阈值配置 | `ai_prohibited` 数组包含该条目 |
| AI 绝对不能关闭或忽略告警 | `ai_prohibited` 数组包含该条目 |

**生成的完整 YAML**

```yaml
human_ai_boundary:
  human_mandatory:
    - "告警等级判定（P0/P1/P2/P3）"
    - "是否触发自动修复（destructive 操作确认）"
    - "升级路径选择"

  ai_assisted:
    - "根因分析文本生成"
    - "修复建议列表生成"
    - "影响面描述生成"

  ai_prohibited:
    - "直接执行修复操作"
    - "修改告警阈值配置"
    - "关闭或忽略告警"
```

---

## 四、执行层：四层推演校验 + 编译思维链

### 4.1 四层推演校验机制

| 层级 | 校验内容 | 未通过动作 | 优先级 |
|---|---|---|---|
| **语法推演** | JSON 结构完整性、字段类型、必填项 | BLOCK（阻断交付） | P0 |
| **语义推演** | 语义令牌引用正确性、同义词映射校验 | BLOCK（阻断交付） | P0 |
| **安全推演** | 禁止模式命中、高危操作确认标记 | BLOCK（阻断交付） | P0 |
| **美感推演** | 文案长度边界、信息密度、可读性评分 | WARN（黄色警告，不阻断） | P1 |

阻断优于修正：校验失败时，不尝试让 LLM 重新生成，而是直接阻断并升级人工。自动重试可能引入新的概率漂移。

### 4.2 编译思维链（从意图到约束的 6 步翻译）

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

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

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

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

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

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

---

## 五、场景测试：验证协议的有效性

```yaml
test_id: "T-P0-001"
test_name: "P0 告警生成与校验闭环"

scenario_steps:
  - step: 1
    action: "compile_prompt"
    input: { alert_source: "CPU_USAGE", threshold_breach: 95 }
    expected: "Prompt 中包含 status.critical 语义令牌约束 + 输出结构契约"

  - step: 2
    action: "llm_generate"
    mock_response: |
      {
        "alert_level": "P0",
        "root_cause": "CPU 使用率超过阈值",
        "confidence_score": 0.85,
        "remediation": [
          { "action_type": "manual", "description": "检查内存占用进程", "risk_level": "low" }
        ]
      }

  - step: 3
    action: "validate_output"
    expected: "PASS — 结构完整、语义令牌匹配、无禁止模式、置信度达标"

edge_cases:
  - case: "同义词替代"
    mock_response: { "alert_level": "严重" }
    expected_validation: "BLOCK — 语义推演失败，命中同义词黑名单"

  - case: "自动执行建议"
    mock_response: { "remediation": [{ "action_type": "automated" }] }
    expected_validation: "BLOCK — 安全推演失败"

  - case: "置信度不足"
    mock_response: { "confidence_score": 0.5 }
    expected_validation: "ESCALATE — 触发降级策略"
```

说明：测试用例用于验证"约束规则是否真的能拦住概率性漂移"，不涉及自然语言规则到 YAML 的翻译，因此保持原有 YAML 格式不变。

---

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

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

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

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

---

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

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

---
### 关于作者

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

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

**独立研发**｜[intent-schema-compiler](https://link.zhihu.com/?target=https%3A//github.com/2436041978-ops/intent-schema-compiler)  
设计意图的形式化约束编译框架，将设计意图的不可变边界编译进 LLM 的输入约束与输出校验。

**求职意向**：设计系统 / 体验工程 / AI 原生｜广州 / 深圳  
欢迎私信联系请多指教。

---

**下一篇预告**：《设计意图治理的组织经济学价值》

> 本文是设计意图治理系列的第二篇。上一篇聊了"为什么需要意图协议"，本篇聊了"意图协议长什么样"。下一篇将从组织经济学视角论证——设计时语义标准化不是成本中心，而是规模化 AI 交付的杠杆资产。核心判断：设计意图治理的方向与行业大趋势一致，且与 LoongSuite GenAI SemConv 形成明确的阶段互补。


承接上一篇：既然设计意图需要从"文档"走进"系统"，那这份"意图协议"长什么样？ 本文展示意图协议的具体形态——不是抽象概念，是可以直接复制粘贴的 YAML/JSON 规范。

设计意图的形式化：从自然语言到机器可读

简介： 本文详解设计意图的“机器可读协议”原型：以6个可复用YAML/JSON文件为核心，构建语义层（意图契约+语义令牌）、治理层（输入约束+输出校验+人机边界）、执行层（四层推演+编译思维链）三层结构，直击设计与AI落地间的语义断裂。

架构设计

人工智能

本文详细介绍了意图协议的具体实现，通过三层结构（语义层、治理层、执行层）将设计意图转化为机器可读的YAML/JSON协议。协议包含意图契约、语义令牌、输入约束、输出校验等核心文件，确保LLM生成内容符合业务语义与安全边界。提供可复制的规范模板与编译流程，帮助团队在AI界面中实现设计意图的确定性传递，有效解决语义断裂与概率漂移问题。

数据结构

Agent

JSON

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

本文详细介绍了意图协议的具体实现，通过三层结构（语义层、治理层、执行层）将设计意图转化为机器可读的YAML/JSON协议。协议包含意图契约、语义令牌、输入约束、输出校验等核心文件，确保LLM生成内容符合业务语义与安全边界。提供可复制的规范模板与编译流程，帮助团队在AI界面中实现设计意图的确定性传递，有效解决语义断裂与概...

设计意图的形式化：从自然语言到机器可读-腾讯云开发者社区-腾讯云

设计意图的形式化：从自然语言到机器可读

设计意图的形式化：从自然语言到机器可读

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐