# 

>承接《Schema-As-Code：当设计规范从文档变成代码》：当规范以代码形态存在，下一步要解决的是**如何让约束从"隐性共识"变成"显性契约"**。本文展示意图协议的具体工程形态——不是抽象概念，是可以直接复制粘贴、在线体验、并被机器自动校验的 YAML 协议。

## 一、从"隐性共识"到"显性契约"

上一篇我们论证了：在规模化 AI 交付中，语义不一致的隐性成本呈超线性增长。面对多产品、多模型、多业务域的复杂场景，大多数团队的第一反应是"加强人工审查"。但这只是在**加速熵增**——人眼的带宽有限，分布式系统的一致性保障不可能靠走查维持。

更根本的解法是让约束从隐性变为显性。

所谓约束显化，就是把"高危操作必须二次确认""critical 不能用'严重'替代""LLM 禁止建议自动修复"这些原本存在于设计师大脑、产品经理文档、前端注释中的**碎片化规则**，转化为**机器可读的、版本化的、可追踪的协议文件**。

当约束以 YAML 形态存在于 Git 仓库中时，它获得了文档形态永远无法拥有的属性：

- **Diff 可见**：谁、在什么时间、修改了哪条规则，一行 Git 历史清清楚楚
- **引用闭环**：意图契约引用语义令牌，语义令牌引用约束规则，规则引用场景测试——修改一处，影响面自动传导
- **编译就绪**：可以被翻译为 ESLint 规则、TypeScript 类型、Prompt 前缀、API 校验——从"被看见"走向"被执行"


----
## 二、在线体验：机器查清单

约束显化之后，最直观的问题是：**机器真的能查吗？**

我们基于 `intent-schema-compiler` 仓库中的协议定义，构建了一个可交互的在线演示。你可以直接体验同一份意图协议下，不同 LLM 输出的校验结果：

**在线演示**：https://2436041978-ops.github.io/intent-schema-compiler/demo/

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/28dd17830fee316b9479454ebc786e4c.png)
### 场景一：合规输出（✅ PASS）

选择"合法输出"，左侧是编译后的 JSON Schema，右侧是 LLM 的标准输出：

```
{
  "alert_level": "P0",
  "root_cause": "CPU 使用率超过阈值，导致服务响应延迟",
  "confidence_score": 0.85
}
```
![image](https://developer.qcloudimg.com/http-save/yehe-12505371/87fffa44fcd6938729c4246cd397c624.png)

**结果**：四层推演全部通过，红色 P0 告警卡片正常渲染。
### 场景二：同义词漂移（❌ BLOCK）

选择"同义词漂移"，LLM 用自然语言"严重"替代了标准语义令牌 `P0`：

```
{
  "alert_level": "严重",
  "root_cause": "CPU 使用率超过阈值，导致服务响应延迟",
  "confidence_score": 0.85
}
```
![image](https://developer.qcloudimg.com/http-save/yehe-12505371/2283fb9ebf4e87bdb75b0290576b3e91.png)
**结果**：机器在毫秒级内识别出红线——`alert_level` 不在枚举白名单 `["P0","P1","P2","P3"]` 中。
### 场景三：复合违规（❌ 3 条红线）

选择"复合违规"，LLM 同时触发了三处偏差：

```
{
  "alert_level": "严重",
  "root_cause": "CPU",
  "confidence_score": 1.5
}
```
![image](https://developer.qcloudimg.com/http-save/yehe-12505371/b58de83f33cc9e1c61cc6778b07ff76a.png)
**结果**：

- **语义推演**：`"严重"` 不在语义令牌白名单
- **语法推演**：`"CPU"` 长度不足 10 字符
- **语法推演**：`1.5` 超出置信度上限 `1.0`


**这就是"机器查清单"与"人查清单"的本质区别**：

- **人查**：设计师打开页面，逐字阅读 LLM 生成的文案，凭经验判断"这里好像不太对"，耗时 5 分钟，漏检率随疲劳度上升。
- **机器查**：协议定义好边界，任何输出进入系统前自动过安检，**多条红线毫秒级定位**，漏检率趋近于零。


----
## 三、约束显化的物理形态：三层 YAML 协议

上面的在线演示不是凭空写的，它来自 `intent-schema-compiler` 仓库中的 YAML 协议定义。仓库采用三层目录结构：

```
intent-schema-compiler/
├── 语义层/          ← 定义"这个世界应该有什么语义"
│   ├── intent-schema.json      # 意图契约：不可变边界与合规动作
│   ├── semantic-tokens.yaml    # 语义令牌：业务语义 ↔ 系统标识
│   └── synonym-mapping.yaml    # 同义词防火墙：防 LLM 漂移
├── 约束层/          ← 定义"什么绝对不能做"
│   ├── prompt-constraints.yaml   # 输入侧：Prompt 约束注入
│   ├── response-schema.yaml      # 输出侧：Response 安检门
│   └── human-ai-boundary.yaml    # 权限侧：人机边界划分
└── 验证层/          ← 定义"怎么验证契约被遵守"
    ├── compilation-chain.md      # 编译思维链：从意图到约束的翻译逻辑
    └── scenario-tests.yaml       # 场景测试：合规路径 + 偏差路径
```
### 语义令牌——让"红色"携带业务语义

传统 Design Token 只定义"这个颜色是什么色值"：

```
/* 传统 Token：只有视觉属性 */
--color-danger: #D32F2F;
```
语义令牌在此基础上增加了**业务语义映射**和 **LLM 约束**：

```
# 语义层/semantic-tokens.yaml
semantic_tokens:
  status.critical:
    canonical_id: "ST-001"
    version: "1.0.0"
    immutable: true                    # 关键：变更必须发新版本
    description: "系统级故障，需立即响应"
    visual_mapping:                    # 视觉层绑定
      color_token: "status.critical"
      motion_token: "pulse.red.urgent"
      sound_token: "alert.high"
    llm_constraints:                   # LLM 层绑定
      - "生成内容必须包含明确的故障定位信息"
      - "禁止提供未经验证的修复建议"
      - "必须附带人工升级路径"
    synonym_firewall:                  # 同义词防火墙
      prohibited:
        - term: "严重"
          confidence_threshold: 0.95
          allowed_contexts: ["AW-001", "AW-002"]
```
![image](https://developer.qcloudimg.com/http-save/yehe-12505371/91d0ccd500f83b0ecb1f404b122ded1a.png)

**关键显化点**：这段 YAML 定义了 `status.critical` 不仅是一个红色，更是一套**完整的语义契约**——当 LLM 在告警场景中看到 `status.critical` 时，它知道必须包含故障定位信息，禁止建议自动修复，且不能用"严重"替代。
### 约束契约——让"高危操作"成为协议

自然语言规范通常这样写：

"高危操作必须二次确认，禁止 AI 直接执行修复，禁止修改告警阈值。"

翻译成机器可读的约束契约：

```
# 约束层/human-ai-boundary.yaml
human_ai_boundary:
  destructive-action:
    intent_id: "IC-003"
    semantic_domain: "transactional"
    immutable_boundaries:
      - boundary_type: "safety"
        rule_ref: "rules/safety/destructive.yaml"
        violation_action: "block"
        # block / escalate / fallback
    human_mandatory:                   # 必须由人决策
      - "是否触发自动修复"
      - "升级路径选择"
    ai_prohibited:                     # AI 绝对禁止
      - "直接执行修复操作"
      - "修改告警阈值配置"
      - "关闭或忽略告警"
```
![image](https://developer.qcloudimg.com/http-save/yehe-12505371/7cc43e658824109a153ef11c2cc0865d.png)

**关键显化点**：

- `violation_action: block` 不是建议，是**强制拦截声明**
- `ai_prohibited` 不是口头约定，是**机器可执行的权限矩阵**
- `immutable_boundaries` 不是文档章节，是**带版本引用的结构化数据**

### 场景测试——用代码证明规则有效

约束显化的最后一环是**可验证性**。每条规则都必须附带"怎么证明它有效"的测试用例：

```
# 验证层/scenario-tests.yaml
scenario_tests:
  - test_id: "T-P0-001"
    test_name: "P0 告警生成与校验闭环"
    intent_binding: "AW-001"
    happy_path:
      input: { alert_source: "CPU_USAGE", threshold_breach: 95 }
      expected: "PASS"
    edge_cases:
      - case: "同义词替代"
        mock_response: { alert_level: "严重" }
        expected_validation: "BLOCK — 语义推演失败，命中同义词黑名单"
      - case: "自动执行建议"
        mock_response:
          remediation: [{ action_type: "automated", description: "自动修复" }]
        expected_validation: "BLOCK — 安全推演失败"
      - case: "缺少人工确认"
        mock_response:
          alert_level: "P0"
          human_confirmed: null
        expected_validation: "BLOCK — 安全推演失败，人机边界缺失"
```


----
## 四、引用闭环：四层契约的编织关系

单独看每个 YAML 文件只是静态配置。

约束显化的真正威力在于它们通过**引用**形成闭环。

**闭环验证示例**：

**1. 意图契约引用语义令牌**：

```
# intent-schema.json 片段
{
  "intent_id": "AW-001",
  "semantic_tokens": ["status.critical"]    # ← 引用 semantic-tokens.yaml
}
```
**2. 语义令牌引用约束规则**：

```
# semantic-tokens.yaml 片段
status.critical:
  llm_constraints:
    - "禁止提供未经验证的修复建议"           # ← 引用约束层的安全边界
```
**3. 约束规则引用场景测试**：

```
# human-ai-boundary.yaml 片段
immutable_boundaries:
  - boundary_type: "safety"
    rule_ref: "rules/safety/destructive.yaml" # ← 被 scenario-tests.yaml 测试覆盖
```
**4. 场景测试验证意图契约**：

```
# scenario-tests.yaml
intent_binding: "AW-001"                     # ← 回到 intent-schema.json
```
**这个闭环意味着**：当你修改 `synonym-mapping.yaml` 中的一条同义词规则时，影响面可以沿着引用链自动传导——哪些意图契约受影响、哪些场景测试需要更新、哪些下游编译产物需要重新生成。

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/50623cace4cc35b48747b215bf4a0dba.png)


----
## 五、从约束显化到架构骨架

`intent-schema-compiler` 目前只是**控制平面（Control Plane）**——它存储意图、定义边界、提供显化载体。但它本身不执行编译、不拦截运行时、不采集观测。

完整的 Schema-As-Code 体系需要数据平面的四个节点：


约束显化是起点，不是终点。

当 YAML 协议被编译、被校验、被拦截、被观测时，它才真正从"静态文本"变成"动态电网"。

![image](https://developer.qcloudimg.com/http-save/yehe-12505371/b5b7af98c2610a3a31fc3a75248e9365.png)


----
## 六、结语：显化是工程实践的前提

设计规范的发展经历了三个阶段：

1. **资产库阶段**：组件和 Token 是"参考素材"，靠记忆复用
2. **文档阶段**：规则和约束写在文档里，靠人工审查落地
3. **协议阶段**：意图和约束被形式化为机器可读格式，靠系统自动编译和执行


`intent-schema-compiler` 是第三阶段的**最小可行载体**。它不复杂，只是一个精心设计的 YAML 仓库。但它完成了最关键的一步：**让约束从隐性共识变为显性契约**。

当 LLM 的输出偏差以 YAML 形态被定义、被版本化、被校验时，它获得了三种能力：

- **被看见**：新成员通过阅读代码就能理解业务规则
- **被追踪**：每次规则变更都有完整的审计历史
- **被执行**：为后续的编译、校验、拦截、观测提供了机器可读的事实源


而那张在线 DEMO 中"Found 3 error(s)"的红色提示，就是显化最好的证明——约束不再是文档里的文字，而是系统里的安检门。


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

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


----
### 关于作者

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

**阿里妈妈**（5 年）｜中台体验设计｜创意工具 → 规则引擎 → 设计提效

**华为**（3 年）｜体验设计工程师｜设计系统 / 跨产品一致性 / 三维治理协议（一致性→易用性→安全感）/ 大模型 Agent 交互范式

**独立研发**｜[intent-schema-compiler](https://link.zhihu.com/?target=https%3A//github.com/2436041978-ops/intent-schema-compiler)

设计意图的形式化约束编译框架，将设计意图的不可变边界编译进 LLM 的输入约束与输出校验。

欢迎私信联系请多指教。


----
## 下阶段预告：架构通电

约束已显化，但电网尚未通电。

下一阶段将展开 **Schema-As-Code 的完整架构设计**——声明式语义治理网格的拓扑、控制平面与数据平面的交互协议、以及 Compiler/Validator/Runtime/Bridge 的工程化实现路径。

详见语雀架构设计文档：《声明式语义治理网格》《Schema-As-Code 顶层架构设计方案》。

**项目地址**：

- 控制平面载体：https://github.com/2436041978-ops/intent-schema-compiler
- 在线演示：https://2436041978-ops.github.io/intent-schema-compiler/demo/
- 完整架构仓库：`schema-as-code`（Monorepo，即将发布）

承接《Schema-As-Code：当设计规范从文档变成代码》：当规范以代码形态存在，下一步要解决的是如何让约束从"隐性共识"变成"显性契约"。本文展示意图协议的具体工程形态——不是抽象概念，是可以直接复制粘贴、在线体验、并被机器自动校验的 YAML 协议。

约束显化：通过意图协议将 LLM 不可突破边界转化为机器可读契约

本文提出“意图协议”——将设计约束从隐性共识转为显性契约的工程实践。通过可复制、可运行、可校验的YAML协议，实现语义令牌、约束规则与场景测试三层显化，并支持在线实时校验LLM输出，毫秒级拦截偏差，让规范真正可追踪、可编译、可执行。

人工智能

架构设计

开发工具

intent-schema-compiler将设计规范从隐性共识转化为机器可读的YAML协议，实现约束显化。通过语义令牌、响应校验、人机边界等YAML定义，构建可版本化、可追踪的显性契约。支持在线体验LLM输出自动校验，毫秒级识别语义漂移、安全违规等问题，为规模化AI交付提供一致性保障。

结构化数据

TypeScript

防火墙

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

约束显化：通过意图协议将 LLM 不可突破边界转化为机器可读契约-腾讯云开发者社区-腾讯云

约束显化：通过意图协议将 LLM 不可突破边界转化为机器可读契约

约束显化：通过意图协议将 LLM 不可突破边界转化为机器可读契约

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐