承接前三篇：我们讨论了设计意图的断裂、形式化的必要、以及治理成本。本文解决一个实操问题：这套方法在行业里到底叫什么？怎么落地？和现有工具是什么关系？
一、先解决命名尴尬
前三篇论证了设计意图治理的必要性，但工程师向团队介绍时会卡壳：
"我们搞了一套设计规范代码化方案……不是 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 拐点判断
六、结语：从"人查清单"到"机器查清单"
设计意图治理的进化：
- 资产库阶段：组件和 Token 是参考素材，靠记忆复用
- 规范阶段：规则写在文档里，靠人工审查落地
- 协议阶段：规则被形式化为机器可读格式，靠系统自动编译和执行
Schema-As-Code 是第三阶段的命名与架构定义。它不复杂，只是一个精心设计的 YAML 仓库 + 五模块协作网格。但它完成了最关键的一步：让约束从隐性负债变为显性资产。
Gap 期局限性声明（v0.1.0）
本文所述"意图协议"目前处于架构推演与最小可行原型阶段。具体的协议模板、YAML 规范与编译逻辑将在下一篇中完整展开；当前校验引擎为逻辑定义（伪代码），尚未接入生产级 LLM API 或 CI 流水线。
关于作者
魏雯，10+ 年互联网设计经验。设计系统 / 体验工程 / AI 原生｜广州 / 深圳
阿里妈妈（5 年）｜中台体验设计｜创意工具 → 规则引擎 → 设计提效
华为（3 年）｜体验设计工程师｜设计系统 / 跨产品一致性 / 三维治理协议（一致性→易用性→安全感）/ 大模型 Agent 交互范式
独立研发｜
https://2436041978-ops.github.io/schema-as-code/
设计意图的形式化约束编译框架，将设计意图的不可变边界编译进 LLM 的输入约束与输出校验。
欢迎私信联系请多指教。
下阶段预告
文章 5：《约束显化》——走进 intent-schema-compiler 仓库，展示 YAML 协议的具体形态，以及如何用一张在线校验截图证明"机器真的能查清单"。
文章 6：《生态互补》——展开 Schema-As-Code 与 LoongSuite、DESIGN.md 的咬合关系，以及这套架构在组织经济学层面的完整价值。
项目地址：
- 控制平面载体：
- 完整架构仓库：
