4 约束显化：通过意图协议将 LLM 不可突破边界转化为机器可读契约
承接《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/
场景一：合规输出（✅ PASS）
选择"合法输出"，左侧是编译后的 JSON Schema，右侧是 LLM 的标准输出：
{ "alert_level": "P0", "root_cause": "CPU 使用率超过阈值，导致服务响应延迟", "confidence_score": 0.85 }结果：四层推演全部通过，红色 P0 告警卡片正常渲染。
场景二：同义词漂移（❌ BLOCK）
选择"同义词漂移"，LLM 用自然语言"严重"替代了标准语义令牌P0：
{ "alert_level": "严重", "root_cause": "CPU 使用率超过阈值，导致服务响应延迟", "confidence_score": 0.85 }结果：机器在毫秒级内识别出红线——alert_level不在枚举白名单["P0","P1","P2","P3"]中。
场景三：复合违规（❌ 3 条红线）
选择"复合违规"，LLM 同时触发了三处偏差：
{ "alert_level": "严重", "root_cause": "CPU", "confidence_score": 1.5 }结果：
语义推演：
"严重"不在语义令牌白名单语法推演：
"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"]关键显化点：这段 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 绝对禁止 - "直接执行修复操作" - "修改告警阈值配置" - "关闭或忽略告警"关键显化点：
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中的一条同义词规则时，影响面可以沿着引用链自动传导——哪些意图契约受影响、哪些场景测试需要更新、哪些下游编译产物需要重新生成。
五、从约束显化到架构骨架
intent-schema-compiler目前只是控制平面（Control Plane）——它存储意图、定义边界、提供显化载体。但它本身不执行编译、不拦截运行时、不采集观测。
完整的 Schema-As-Code 体系需要数据平面的四个节点：
约束显化是起点，不是终点。
当 YAML 协议被编译、被校验、被拦截、被观测时，它才真正从"静态文本"变成"动态电网"。
六、结语：显化是工程实践的前提
设计规范的发展经历了三个阶段：
资产库阶段：组件和 Token 是"参考素材"，靠记忆复用
文档阶段：规则和约束写在文档里，靠人工审查落地
协议阶段：意图和约束被形式化为机器可读格式，靠系统自动编译和执行
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
设计意图的形式化约束编译框架，将设计意图的不可变边界编译进 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，即将发布）