设计意图的形式化：从自然语言到机器可读简介：本文详解设计意图的“机器可读协议”原型：以6个可复用YAML/JSON文件

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

{
  "$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

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

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

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

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

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、哪些测试用例需要同步更新

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

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
设计意图的形式化约束编译框架，将设计意图的不可变边界编译进 LLM 的输入约束与输出校验。

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

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

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