Schema-As-Code 商业全景

当 AI 生成界面时，谁在守住设计意图？

当 AI 生成界面时
谁在守住设计意图？

Design-to-Code 工具解决了"怎么写代码"，但漏了一层更关键的翻译：设计意图 → AI 生成内容。 Schema-As-Code 补的就是这一层。

DesignOps · 规范同步

以前：规范写在语雀/Confluence，人工 @ 全员，开 3 场同步会，2 周后走查发现 3 个产品没改对。

现在：规范写成 Executable Design Spec（YAML），Git Diff 自动触发影响面分析，下游 Prompt 模板自动重编译。

2周 → 0.5天

规范同步时间

Design System · Token 语义

以前：Design Token 管住了颜色，但 AI 把 "Critical" 写成 "严重"，把告警红色用在成功提示上。

现在：Semantic Token = 视觉令牌 + 语义约束 + LLM 边界规则。AI 生成前自动匹配场景。

20% → 100%

机器推演覆盖率

前端工程 · AI 返工

以前：前端 30% 时间在修 AI 的语义错误（Critical→严重、删除按钮→普通样式、二次确认→遗漏）。

现在：语义约束前置拦截。前端只收"通过了约束检查"的代码，只修视觉和结构问题。

30% → 5%

AI 返工率

基础设施 · 错误分级

以前：ChatGPT 4 种错误共用红色，用户不知道"刷新一下就好"还是"对话已经丢了"。

现在：Fatal/Transient/Retryable/Degraded 自动语义分级，颜色是语义的结果，不是默认容器。

靠猜 → 明确

用户行动路径

核心洞察

所有 Design-to-Code 工具（DevUI HMC、v0、Claude Code、Figma MCP）都在解决形态问题（长什么样、怎么写代码）。
Schema-As-Code 解决的是语义问题（意味着什么、不能突破什么）。

我不替代它们，我给它们提供一层上游约束——让 AI 生成的内容，在视觉层和工程层之前，先过一遍语义层。

场景 1：DesignOps — 规范同步

规范更新一次，DesignOps 同学要开几场会？以前靠人肉广播，现在靠 Git Diff。

YAML 协议

JSON Schema

LLM 输出

四层推演

界面渲染

ISI 编译响应：DesignOps 规范同步流水线

{ "status": "success", "intent_id": "ALERT-001", "version": "1.1", "git_diff_trigger": true, "downstream_sync": { "tools": ["claude_code", "v0", "devui_hmc"], "auto_compile": true, "sync_time": "0.5h", "manual_meetings": 0 }, "validation_summary": { "total_rules": 3, "prohibited_synonyms": ["严重", "危急", "紧急"], "coverage": "100%" } }

场景 2：Design System — Token 语义

Design Token 管住了颜色，但管不了 AI 把 "Critical" 写成 "严重"。

YAML 协议

JSON Schema

LLM 输出

四层推演

界面渲染

ISI 编译响应：Semantic Token 场景约束

{ "status": "success", "intent_id": "TOKEN-001", "semantic_token": "status.critical", "scene_validation": { "system_alert": { "allowed": true, "visual": "red_pulse" }, "toast": { "allowed": false, "fallback": "status.success" } }, "llm_constraints": [ "禁止在提示场景使用 status.critical", "禁止将 Critical 降级为严重/紧急/危急" ], "coverage": "100%" }

场景 3：前端工程 — 高危操作

AI 生成一个页面，前端同学花 30% 时间在修什么？修语义错误。

YAML 协议

JSON Schema

LLM 输出

四层推演

界面渲染

ISI 编译响应：高危操作语义锁

{ "status": "blocked", "intent_id": "DEL-001", "action_type": "destructive", "violations": [ "button_style != outline_danger", "confirmation_step = false", "consequence_text missing" ], "auto_fix": { "button_style": "outline_danger", "confirmation_step": true, "required_children": ["ConfirmDialog", "Alert"] }, "frontend_savings": "2人天/100张图" }

场景 4：基础设施 — 错误分级

ChatGPT 的四种错误状态，为什么共用同一种红色？

YAML 协议

JSON Schema

LLM 输出

四层推演

界面渲染

ISI 编译响应：错误语义分级映射

{ "status": "success", "intent_id": "ERR-001", "error_severity_mapping": { "fatal": { "color": "status.critical", "motion": "pulse.red", "action": ["refresh", "export"] }, "transient": { "color": "status.neutral", "motion": "spinner", "action": ["wait"] }, "retryable": { "color": "status.warning", "motion": "none", "action": ["upgrade", "remind"] }, "degraded": { "color": "status.info", "motion": "none", "action": ["continue"] } }, "user_guesswork": "eliminated", "semantic_coverage": "100%" }

场景 5：跨工具消费 — Intent Schema Interface

Schema-As-Code 是所有 Design-to-Code 工具的"上游约束层"。同一份 YAML 语义契约，自动编译为不同工具的专属约束格式。

核心问题：Design-to-Code 工具（Claude Code / v0 / DevUI HMC / Figma）解决了"怎么写代码/怎么画界面"，但没有解决"AI 生成的内容是否偏离设计意图"。

Schema-As-Code 的解法：在 AI 生成内容之前，先注入语义约束。同一份 YAML 契约，编译为每个工具能消费的格式。

🔧

Claude Code

角色：工程师 · 在 IDE 里写代码

❌ 没有上游约束层

工程师 Prompt：

"帮我写一个删除账户的确认弹窗"

<Button variant="contained">确认</Button>

⚠️ 高危操作做成了普通蓝色按钮，无二次确认

✅ 有 Schema-As-Code 上游约束

自动注入 System Prompt 前缀：

## 语义约束（来自 intent/DEL-001.yaml）
当 action_type=destructive 时：
- 按钮必须用 outline_danger
- 必须包含二次确认弹窗
- 禁止生成 contained 主按钮

<Button variant="outline" color="danger">确认删除账户</Button>
<ConfirmDialog />
<Alert severity="error">此操作不可恢复</Alert>

📎 接入方式：在 Claude Code 的 system prompt 中引用 intent/DEL-001.yaml 编译产物，作为生成代码的前置约束。

⚡

v0 by Vercel

角色：设计师/产品经理 · 快速生成原型

❌ 没有上游约束层

设计师输入：

"一个删除账户的弹窗"

v0 生成：

普通 Dialog 组件，按钮样式自由发挥，无二次确认

⚠️ AI 不知道这是高危操作，按普通弹窗生成

✅ 有 Schema-As-Code 上游约束

v0 生成前自动读取 YAML 规则：

if (action_type == "destructive") {
  component = "Button";
  props = { variant: "outline", color: "red" };
  required_children = ["ConfirmDialog"];
}

红色描边按钮 + 二次确认 Dialog + 后果说明 Alert

📎 接入方式：v0 组件规则引擎读取 YAML 编译产物，生成前自动校验组件属性是否符合语义约束。

🔷

DevUI HMC

角色：企业前端 · 符合组件库规范

❌ 没有上游约束层

HMC 生成组件：

<d-button type="primary">确认</d-button>

⚠️ 虽然用了 DevUI 组件，但高危操作用了 primary 样式，无二次确认

✅ 有 Schema-As-Code 上游约束

HMC Skill 配置映射：

skill_name: vue-devui-practices
mapping:
  destructive_action:
    component: "d-button"
    props: { type: "danger", outline: true }
    required_modals: ["d-modal[confirm]"]

<d-button type="danger" outline>确认删除</d-button>
<d-modal confirm>此操作不可恢复</d-modal>

📎 接入方式：HMC 的 vue-devui-practices Skill 读取 YAML 映射表，自动将语义标签映射到 DevUI 组件属性。

🎨

Figma MCP

角色：设计系统负责人 · 把控设计质量

❌ 没有上游约束层

设计师在 Figma 里画了一个"删除"按钮：

Button 组件，红色填充，文案"删除"

⚠️ 设计稿看起来对，但不知道是否符合语义规范（应该用描边而非填充）

✅ 有 Schema-As-Code 上游约束

Figma 插件实时读取 YAML 规则：

if (label.contains("删除") && style != "outline_danger") {
  severity = "ERROR";
  message = "删除按钮必须使用 outline_danger 样式";
  node.addRedCircle();
}

Figma 画布上，违规按钮节点自动标红圈提示

📎 接入方式：Figma MCP 插件读取 YAML 语义规则，对设计稿中的组件节点做实时 Lint 检查，违规自动标红。

🎯 核心洞察

所有 Design-to-Code 工具都在解决形态问题（长什么样、用什么组件、怎么写代码）。
Schema-As-Code 解决的是语义问题（这个组件在这个场景下意味着什么、不能突破什么边界）。

我不替代任何工具，我给它们提供一层上游约束——让 AI 生成的内容，在视觉层和工程层之前，先过一遍语义层。

ISI 接口响应：多工具编译结果

{ "isi_version": "1.0", "intent_id": "DEL-001", "semantic_domain": "transactional", "compiled_outputs": { "claude_code": { "type": "prompt_prefix", "format": "markdown", "injection_point": "system_prompt", "priority": "high" }, "v0": { "type": "component_rules", "format": "json", "auto_inject": true }, "devui_hmc": { "type": "skill_config", "format": "yaml", "skill_name": "vue-devui-practices" }, "figma_mcp": { "type": "design_lint", "format": "json", "severity": "ERROR" } }, "tool_coverage": 4, "immutable_boundaries": 2 }