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

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

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

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

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

一、协议总览：三层结构

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

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

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

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

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

我的设计规则

生成的完整 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

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

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

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

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

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

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

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

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

4.1 四层推演校验机制

阻断优于修正：校验失败时，不尝试让 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 格式不变。

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

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

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

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

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

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

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

关于作者

魏雯，10+ 年互联网设计经验。设计系统 / 体验工程 / AI 原生｜广州 / 深圳

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

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

欢迎私信联系请多指教。