Schema-As-Code：当设计规范从文档变成代码

承接《设计意图治理》前三篇：我们论证了意图断裂的必然性、形式化的必要性、以及治理的组织经济学价值。本文完成最关键的一步——立宪：给这套工程方法论一个精确的命名，定义一个可扩展的轻量架构，并明确它在行业生态中的坐标。

一、从论证到立宪：为什么必须命名和架构化

前三篇完成了三件事：

  • 诊断：设计意图在确定性界面和概率性界面中经历三次断裂（语义断裂、规则断裂、验证断裂）
  • 处方：需要一种让设计意图从"文档形态"转化为"机器可读协议"的编译层
  • 估值：语义不一致的隐性成本呈超线性增长，设计时语义标准化是杠杆资产

但当工程师向团队介绍时，会卡在一个尴尬处：它叫什么？它长什么样？它放在技术栈的哪一层？

没有命名，就无法被引用、被对比、被集成。没有架构定义，就无法被组织采纳——因为组织只能通过清晰的架构边界来分配资源和责任。

我们需要一个精确、可扩展、行业可对话的命名——Schema-As-Code——以及一个与之匹配的联邦自治架构。

二、Schema-As-Code：精确命名

把两个词拆开，再合成：

词 在本语境中的定义 明确不是什么
Schema 设计意图的形式化契约——包含语义定义（应该有什么）、治理规则（不能突破什么）、执行验证（怎么确认） 不是数据库表结构（DB Schema），不是 API 数据结构（JSON Schema），不是视觉规范（Design Token）
As-Code 机器可读 + 版本管理 + 自动编译 + 可执行——以 YAML/JSON 形态存储于 Git，具备完整 diff、影响面分析、CI 编译能力 不是文档化（As-Doc），不是配置化（As-Config），不是图形化（As-Design）

合成定义：

Schema-As-Code 是将设计意图的不可变边界、语义映射关系与治理校验规则，以机器可读的形式化格式（YAML/JSON）编码于版本控制系统中，并通过编译器将其转化为可执行约束产物（类型定义、校验规则、运行时策略、观测指标）的工程方法论。

命名的意义不是包装，是降低组织内部的沟通成本和决策摩擦。 有了这个名字，委员会可以讨论"Schema 版本升级"，平台团队可以发布"Compiler 插件"，业务工程师可以询问"我的组件绑定了哪个意图契约"——各方在同一个语义坐标系内协作。

三、声明式语义治理网格：轻量架构总纲

Schema-As-Code 不是单一工具，而是一个声明式语义治理网格（Declarative Semantic Governance Mesh）。

3.1 双轴正交模型

┌─────────────────────────────────────────┐
│ 控制平面（Control Plane） │
│ intent-schema-compiler │
│ 语义层 / 治理层 / 执行层（YAML/JSON） │
└─────────────────────────────────────────┘
│
│ 声明式同步（GitOps）
▼
┌─────────────────────────────────────────┐
│ 数据平面（Data Plane） │
│ Registry → Compiler → Validator → │
│ Runtime → Bridge（闭环反哺） │
└─────────────────────────────────────────┘
│
│ 正交穿透
▼
┌─────────────────────────────────────────┐
│ 现有基础设施（纵向生产链路） │
│ Token → 组件 → API → 容器 → DB / LLM │
└─────────────────────────────────────────┘

三个关键特征：

  1. 声明式：只需定义"应该是什么"，系统自动收敛——像 K8s 的 YAML，像 Terraform 的 HCL
  2. 网格化：像一层透明电网铺在现有基础设施上，不替代 Ant Design / Carbon / LoongSuite，只向其注入规则
  3. 正交穿透：横向治理平面与纵向生产链路正交相交，业务代码几乎无感知

3.2 五层穿透接口

网格通过标准化的五层穿透接口，将同一份语义契约扩散到全链路：

层级 接口标识 编译产物形态 消费方
L1 Token 层 token.* CSS 变量 / Theme 配置 / 语义注释 Ant Design / Carbon / Tailwind
L2 组件层 component.* TS 类型定义 / Prop 约束 / ESLint 规则 React / Vue / Angular
L3 API 层 api.* OpenAPI 扩展 / JSON Schema / 请求体校验 Express / Koa / GraphQL
L4 容器层 container.* OPA Policy / WASM 配置 / Sidecar 规则 Envoy / K8s / 网关
L5 数据库层 database.* DDL 注释 / CHECK 约束 / 字段语义标签 MySQL / PostgreSQL

关键设计：新增一个平台支持 = 新增一个编译器插件文件，核心层零改动。

四、联邦自治架构契约

治理网格在组织层面的投射，天然呈现联邦自治结构。这不是中央集权，也不是完全自治，而是基线统一、域级扩展、业务无感的分层治理。

4.1 四层角色与契约边界

层级 角色 核心契约 权限边界
委员会 架构师 + 联邦治理委员会 制定联邦元规则（不可变的语义基线） 控制平面中标记 immutable: true 的规则
平台团队 平台 / Infra 工程师 维护 Compiler / Validator / Runtime / Bridge 数据平面的白盒基础设施，向上提供编译与拦截服务
域级 Intent Steward + 域 TL 在联邦基线之上自定义域级规则 domains/{domain}/rules/ 沙盒验证后注册生效
业务 前端 / 设计 / AI 工程师 通过标签 / SDK / 插件黑盒接入 不接触 YAML，只消费编译产物与拦截策略

4.2 联邦元规则清单（不可变基线）

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

  • 语义令牌不可变性：status.critical 等核心语义令牌一旦发布，旧版本冻结，变更必须发新版本
  • 安全边界不可覆盖：ai_prohibited 中的高危操作清单，域级只能扩展，不能删减
  • 版本兼容性契约：Major 版本变更 = Breaking Change，需委员会审批；Minor/Patch 由平台自动分发

4.3 域级自治接口

域级通过标准接口接入联邦：

# domains/{domain}/domain-manifest.yaml
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"
      field: "human_mandatory"
      add: ["二次人脸验证"]

关键机制：域级规则必须先通过 sandbox/scenario-tests.yaml 验证，才能注册到联邦注册表。

五、行业趋势与生态坐标

Schema-As-Code 不是孤立的发明，它诞生于三个行业趋势的交汇点，并填补它们之间的结构性缺口。

5.1 趋势一：LLM 概率性输出催生治理真空

大模型成为内容生产方后，"同一 Prompt 生成不同表述"成为常态。行业目前的应对是碎片化的：

  • 设计系统阵营做了视觉属性同步的天花板
  • LLM 工程阵营做了输出格式约束的天花板
  • 合规系统阵营做了工程规则审计的天花板

三个天花板之间没有梯子。 Schema-As-Code 填补的是"设计语义"与"LLM 约束"之间的断层——让设计系统的 Token 告诉 LLM "这个红色代表什么"，让 LLM 的格式约束承载设计语义。

5.2 趋势二：运行时观测的天花板需要设计时约束托底

阿里巴巴与蚂蚁集团推出的 LoongSuite GenAI SemConv，在 OpenTelemetry 基础上建立了 GenAI 场景的统一可观测数据语言。它解决了"运行时发生了什么"的问题，但无法回答"运行时应该遵守什么"。

Schema-As-Code 与 LoongSuite 形成阶段互补：LoongSuite 回答"事后追踪"，Schema-As-Code 回答"事前约束"。运行时观测发现的漂移案例，反向驱动设计时规则的迭代——这是"观测 → 归因 → 约束 → 验证"的闭环。

5.3 趋势三：AI 设计工具的爆发需要约束层托底

DESIGN.md 等 AI 设计工具让设计师用自然语言描述意图，LLM 自动生成代码。但自然语言是开放的——设计师说"用红色强调"，LLM 可能生成"用红色按钮"也可能生成"用红色背景覆盖全屏"。

Schema-As-Code 与 DESIGN.md 形成双层架构：DESIGN.md 负责意图的丰富表达（正向描述），Schema-As-Code 负责意图的刚性约束（负向边界）。两者在 Compiler 层交汇，构成完整的 AI 设计工作流。

六、结语：立宪完成，电网待通电

Schema-As-Code 联邦自治架构的定义，完成了设计意图治理的立宪：

  • Schema-As-Code 是宪法的命名
  • 声明式语义治理网格 是宪法的拓扑
  • 联邦自治四层契约 是宪法的组织投射
  • 五层穿透接口 是宪法的技术接口

立宪之后，需要通电——让 YAML 协议从"被看见"走向"被执行"，让网格从"架构图"走向"可触摸的演示"。

下阶段预告

文章 5：《约束显化》——我们将走进 intent-schema-compiler 仓库，展示 YAML 协议的具体形态：语义令牌如何携带 LLM 约束，意图契约如何定义不可变边界，以及如何用一张在线校验截图证明"机器真的能查清单"。

文章 6：《生态互补》——我们将展开 Schema-As-Code 与 LoongSuite GenAI SemConv、DESIGN.md 的咬合关系：运行时观测如何反哺设计时约束，AI 设计描述如何与语义护栏形成双层闭环，以及这套联邦自治架构在组织经济学层面的完整价值。

项目地址：

  • 控制平面载体（联邦宪法源仓库）：

intent-schema-compiler.png

  • 联邦自治架构仓库（Monorepo）：

Schema-As-Code.png

posted @ 2026-05-30 08:26  Akirweiwen  阅读(11)  评论(0)    收藏  举报