Skip to main content

【阻力 4】Open Design 语义设计到 Schema 驱动链路

阻力 4：意图识别语义鸿沟 ── 待攻克​

痛点复现：运营说的都是大白话或主观词汇（如：“我要个高端、大气、有爆款感觉的黑金风格数码页面”），大模型无法直接将其映射到底层组件参数。若让 AI 跳过设计阶段、直接吐整页 JSON，极易出现参数幻觉、预览与线上一致性差、运营无法参与微调等问题。

💡 落地解法：Open Design → Schema Compiler → Low-code Runtime 三层流水线​

不要把「理解意图」和「生成配置」混在同一步。参考 Claude Design / DESIGN.md 的思路，但目标不是导出 HTML/CSS，而是产出经过 schema.json 校验的 pageSchema，由低代码运行时数据驱动展示。

运营意图（模糊）
      │
      ▼
┌──────────────────────────────┐
│ Layer A：Open Design         │  语义映射 + 澄清 Loop + 组件 Palette 约束
│ 用已有组件「设计」页面编排      │  输出 DesignDocument
└──────────────┬───────────────┘
               │ Schema Compiler（校验 / preset 展开 / 联动补全）
               ▼
┌──────────────────────────────┐
│ Layer B：Page Schema         │  唯一真相源 pageSchema.json
│ props + layout + dependencies│
└──────────────┬───────────────┘
               │ 同一套组件注册表渲染
               ▼
┌──────────────────────────────┐
│ Layer C：Low-code Runtime    │  Mock 预览 + 多端渲染
│ 读 Schema 驱动展示            │
└──────────────────────────────┘

核心约束：Design 层只能编排已有组件注册表里的组件，Runtime 必须 import 同一套组件——Design Preview 与线上渲染共用组件源码，避免「设计稿好看、配置跑不起来」的漂移。

一、Layer A：Open Design（语义设计层）​

Open Design 负责把运营黑话收敛为可编排的设计稿。它不做自由 UI 生成，而是在 RAG 召回的合法组件 Palette 内做布局与 preset 选择。

1. 设计语言映射矩阵（Semantic → Preset）​

在 RAG 提示词库或独立的 DESIGN.md 中，架构师维护「运营黑话 → 已审批 preset」映射表。preset 不是裸 CSS，而是跨组件 props 组合：

  • 高端/大气/黑金 ──> preset: "black-gold" → 展开为 Banner.heroStyle=darkGold、ProductList.cardDensity=spacious、CouponBar.variant=minimal
  • 年轻/国潮/爆款 ──> preset: "cyber-red" → 展开为 Banner.animationSpeed=fast、ProductList.layout=compact、Countdown.theme=nationalTide

映射表由设计 / 品牌团队审批并版本化；大促期间可锁定 preset，防止 AI 自由发挥（类似 Claude Design 的 admin 锁定 design system）。

2. 澄清型 Agent 编排（Clarification Loop）​

不要让 AI 猜谜。当识别到输入过于模糊时，触发绑定 preset / Palette 的反问，而不是开放式聊天：

  • 运营输入：“我要搞个大促页面。”
  • AI Agent 拦截并反问：“收到！本次大促更倾向于：A. 沉稳高端风（black-gold，适合数码高客单） B. 热烈喜庆风（cyber-red，适合食品快消）？（默认 B）”
  • 选项 A/B 直接收窄 RAG 组件候选集与 preset，1～2 轮后输出高确定性的 DesignDocument

3. 组件 Palette 约束（对接阻力 3）​

Design 层的组件候选集，必须来自 两阶段 RAG 拦截 的合法召回结果。全站没有的组件（如「赛龙舟小游戏」）在 Design 阶段即被拦截并推荐最接近模板，从源头避免幻觉。

4. DesignDocument 中间产物​

interface DesignDocument {
  preset: 'black-gold' | 'cyber-red';
  nodes: Array<{
    componentType: string;       // 如 "Banner"，必须在 Palette 内
    semanticLabel: string;       // "首屏爆款 Banner"
    props: Record<string, unknown>;
    layout: { region: 'hero' | 'body'; order: number };
  }>;
}

MVP 阶段甚至可以先不做可视化画布：Agent 直接输出 DesignDocument，由 Compiler 转 Schema，Runtime 渲染——先跑通数据闭环，再补 Open Design 可视化编辑。

二、Layer B：Schema Compiler（配置编译层）​

Compiler 是 Design 与 Runtime 之间的确定性桥梁，职责包括：

  1. 校验：按 阻力 1 生成的各组件 schema.json 做 enum / required / type 校验，非法字段直接拒绝。
  2. Preset 展开：将 preset: "black-gold" 合并到各 node 的 props，冲突时以 node 级显式 props 为准。
  3. Default 填充：补全 schema 定义的默认值，避免 Runtime 空指针。
  4. 联动补全：跨组件条件逻辑输出为 dependencies[]，协议见 阻力 2。
{
  "version": "1.0",
  "preset": "black-gold",
  "context": { "userSegment": "normal", "activeCouponId": null },
  "components": [
    {
      "id": "Banner_1",
      "type": "Banner",
      "props": { "heroStyle": "darkGold", "title": "数码爆款节" },
      "layout": { "region": "hero", "order": 0 }
    },
    {
      "id": "ProductList_1",
      "type": "ProductList",
      "props": { "cardDensity": "spacious", "baseApi": "/api/products" },
      "layout": { "region": "body", "order": 1 }
    }
  ],
  "dependencies": []
}

pageSchema.json 是唯一真相源：Design 改动、运营画布微调、AI 迭代，最终都应 diff 成 JSON Patch 写回 Schema，而非全量覆盖——详见 阻力 7。

三、Layer C：Low-code Runtime（数据驱动展示层）​

Runtime 只读 pageSchema.json，不解析运营自然语言。渲染链路对接：

Design Preview 与 Runtime 必须引用同一组件路径，例如：

Design Preview  ──→  import Banner from '@corp/components'
Low-code Runtime ──→  import Banner from '@corp/components'

四、与 Claude Design / DESIGN.md 的关系​

维度Claude Design / DESIGN.md本方案（Enterprise 低代码）
输出物HTML 原型、视觉稿、PPTX经校验的 pageSchema.json
约束源品牌 token、Figma 组件组件 schema.json + preset 包
澄清方式视觉微调、选项卡片绑定 preset / Palette 的结构化反问
运行时导出给 Claude Code 写代码低代码引擎直接数据驱动渲染
治理admin 锁定 design systempreset 版本化 + CI Schema 卡点

思路一致：语义层负责理解，配置层负责执行，Runtime 负责确定性展示。差异在于低代码要把创意收敛到已有组件 + Schema DSL，而不是生成自由样式代码。

五、MVP 落地路径与主要风险​

MVP 路径（建议顺序）​

  1. Cursor 批量生成组件 schema.json（阻力 1）
  2. 定义 3～5 个品牌 preset，写入映射矩阵
  3. Design Agent：澄清 → 输出 DesignDocument（Palette 约束）
  4. Schema Compiler：校验 + 转 pageSchema.json
  5. 现有低代码 Runtime 读 Schema 渲染 + Mock 预览

主要风险​

风险对策
Layout 模型与 Runtime 区块不对齐Design 只用 region + order 流式布局，禁止绝对定位
Preset 与运营细调冲突属性三色来源锁，人工改动标记 source: human（阻力 7）
动态联动无法「画出来」Design 层用行为连线或澄清 Agent 一并生成 dependencies
Schema 版本升级Compiler 内置 migrate，旧 DesignDocument 可重编译

🚀 迈向下一个里程碑​

阻力 4 的完整链路跑通后，运营可以用自然语言描述大促风格，在 Open Design 层看到基于真实组件的页面编排，Compiler 产出可校验的 Schema，Runtime 秒级预览。接下来必须面对 【阻力 5：复杂电商 Mock 仿真预览】——如何在沙箱里模拟「Plus 会员 + 北京无货 + 优惠券已过期」等真实运行时状态？详见 Mock 仿真预览方案。