Schema-As-Code：意图协议的形式化定义与声明式语义治理网格

Akir_weiwen
1 阅读8分钟

承接前三篇：我们讨论了设计意图的断裂、形式化的必要、以及治理成本。本文解决一个实操问题：这套方法在行业里到底叫什么？怎么落地？和现有工具是什么关系？

一、先解决命名尴尬

前三篇论证了设计意图治理的必要性，但工程师向团队介绍时会卡壳：

"我们搞了一套设计规范代码化方案……不是 Design System，不是 Prompt Engineering，不是 Policy-as-Code……"

没有命名，就无法被引用、被集成、被组织采纳。

我们给它一个精确的名字：Schema-As-Code。

一句话定义：

Schema-As-Code 是将设计意图的约束规则以 YAML/JSON 形式写入版本控制，通过编译器转化为可自动执行的校验规则（ESLint/类型检查/运行时拦截）的工程方法。

命名的意义：让团队能问"我们的 Schema 版本是多少"，而不是"那个规范文档更新了吗"。

二、架构定位：轻量网格，不替代现有工具

Schema-As-Code 不是新框架，而是铺在现有工具之上的一层语义校验网格。

2.1 三层结构

┌─────────────────────────────────────────┐
│  控制层：YAML 协议本体                    │
│  intent-schema-compiler 仓库              │
│  语义定义 / 约束规则 / 验证场景            │
└─────────────────────────────────────────┘
                    │
                    │ Git 版本管理 + CI 编译
                    ▼
┌─────────────────────────────────────────┐
│  执行层：五模块协作                        │
│  Registry → Compiler → Validator →      │
│  Runtime → Bridge（观测反哺）             │
└─────────────────────────────────────────┘
                    │
                    │ 正交穿透，不侵入业务
                    ▼
┌─────────────────────────────────────────┐
│  现有基础设施：Ant Design / Carbon / API  │
│  组件 / 接口 / 数据库 / LLM 工具          │
└─────────────────────────────────────────┘

关键特征：

  • 声明式：写 YAML 定义"应该是什么"，系统自动收敛
  • 网格化：像一层透明网铺在现有工具上，业务代码无感知
  • 正交穿透：不替代 Ant Design 或 Carbon，只向其注入语义规则

2.2 五层穿透接口

同一份语义契约，通过编译器扩散到全链路：

新增平台支持 = 新增一个编译器插件，核心层零改动。

三、组织协作：分层自治，基线统一

Schema-As-Code 在组织中的落地，采用分层自治结构——不是中央集权，也不是各自为政。

3.1 四层角色

3.2 基线规则示例

委员会通过基线规则划定"任何域都不可突破"的边界：

# 语义基线：核心语义令牌冻结
semantic_tokens:
  status.critical:
    immutable: true           # 变更必须发新版本
    llm_constraints:
      - "禁止提供未经验证的修复建议"

# 安全基线：高危操作清单
human_ai_boundary:
  destructive-action:
    ai_prohibited:
      - "直接执行修复操作"
      - "修改告警阈值配置"

3.3 域级扩展接口

域级通过标准接口接入：

domain_id: "payment-domain"
steward: "zhangsan"
base_version: "v1.2.0"

rules:
  extensions:                 # 扩展语义令牌
    - token: "status.fraud"
      inherits: "status.critical"
  overrides:                  # 覆盖规则（需委员会审批）
    - rule_ref: "human-ai-boundary.destructive-action"
      add: ["二次人脸验证"]

四、与现有体系的关系：互补，不是替代

Schema-As-Code 填补的是现有工具之间的语义断层。

4.1 与 Design System 的关系

关系：Ant Design 提供组件，Schema-As-Code 提供组件的语义使用约束。两者通过编译器插件对接。

4.2 与 LoongSuite GenAI SemConv 的关系

关系：运行时观测发现的漂移案例，反向驱动设计时规则的迭代。两者形成"观测 → 归因 → 约束 → 验证"的闭环。

4.3 与 DESIGN.md 的关系

关系：设计师用 Markdown 表达创意，工程师用 YAML 锁定红线。两者在编译器层交汇，构成完整的 AI 设计工作流。

五、组织经济学价值：为什么是杠杆资产

5.1 熵增成本公式

治理成本 ∝ 产品数 × 规范版本数 × LLM 场景数 × 时间

当组织并行产品超过 5 个、LLM 消费场景超过 10 个时，未治理系统的成本将首次超过建立治理体系的固定投入。

5.2 维护成本对比

5.3 拐点判断

六、结语：从"人查清单"到"机器查清单"

设计意图治理的进化：

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

Schema-As-Code 是第三阶段的命名与架构定义。它不复杂，只是一个精心设计的 YAML 仓库 + 五模块协作网格。但它完成了最关键的一步：让约束从隐性负债变为显性资产。

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

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

关于作者

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

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

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

独立研发｜

intent-schema-compiler

2436041978-ops.github.io/schema-as-c…

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

欢迎私信联系请多指教。

下阶段预告

文章 5：《约束显化》 ——走进 intent-schema-compiler 仓库，展示 YAML 协议的具体形态，以及如何用一张在线校验截图证明"机器真的能查清单"。

文章 6：《生态互补》 ——展开 Schema-As-Code 与 LoongSuite、DESIGN.md 的咬合关系，以及这套架构在组织经济学层面的完整价值。

项目地址：

  • 控制平面载体：

  • 完整架构仓库：

avatar
文章
阅读
粉丝