Goofy Logo高飞宇 | Goofy

7 层设计语言协议：从 Token 到 Page 的结构化路径

总览：为什么需要 7 层

上一篇讲了"为什么 AI 需要设计协议"。这篇深入讲：协议长什么样。

直觉上，你可能觉得设计协议就是一个 JSON 文件，写清楚"主色是 #3B82F6、间距是 8px 倍数"就行了。

但实际做下来发现：一层平铺的约束文件是不够的。原因是——设计决策有层次性。

  • "主色是蓝色" = Token 层决策
  • "按钮有 4 种变体" = Component 层决策
  • "科技感风格优先渐变" = Direction 层决策
  • "数据看板场景用紧凑布局" = Scene 层决策
  • "首页由 Hero + Features + Footer 组成" = Page 层决策

每一层解决不同粒度的设计问题。 如果你把它们全混在一起，AI 无法判断"当前应该参考哪条规则"。

L1: Token 层 — 设计系统的原子

Token 是设计系统最底层的抽象——语义化的值。

{
  "color": {
    "primary": { "$value": "#3B82F6", "$type": "color" },
    "primary-hover": { "$value": "#2563EB", "$type": "color" }
  },
  "spacing": {
    "xs": { "$value": "4px", "$type": "dimension" },
    "sm": { "$value": "8px", "$type": "dimension" },
    "md": { "$value": "16px", "$type": "dimension" }
  },
  "radius": {
    "sm": { "$value": "4px", "$type": "dimension" },
    "md": { "$value": "8px", "$type": "dimension" }
  }
}

Token 解决的问题：让 AI 不用猜具体数值。它不需要"决定"间距用 12px 还是 16px——Token 表告诉它答案。

Schema 约束：Token 文件有 JSON Schema 验证（遵循 W3C DTCG 规范），错误的值格式在写入时就被拦截。

L2: Component 层 — 组件的契约

Component 协议定义每个组件的行为边界：有什么变体、接受什么 props、在什么约束下使用。

{
  "name": "button",
  "level": "L1",
  "category": "interaction",
  "variants": ["default", "secondary", "destructive", "outline", "ghost"],
  "props": {
    "size": { "type": "enum", "values": ["sm", "md", "lg"], "default": "md" },
    "disabled": { "type": "boolean", "default": false }
  },
  "constraints": {
    "max_label_length": 20,
    "min_touch_target": "44px"
  }
}

为什么 AI 需要这个？ 因为没有它，AI 可能生成一个有 7 种 size 的 Button（training data 里见过的都堆上去）。有了 Component 协议，AI 知道："这个设计系统只有 sm/md/lg 三种尺寸，没有 xl。"

注册表统计：当前 31 个组件协议 + 21 个 Section 协议 = 52 个行为定义。

L3: Direction 层 — 设计意图

Direction 是最有趣的一层——它定义的不是具体的值或组件，而是抽象的设计意图。

direction:
  name: "tech-future"
  mood: "professional, innovative, clean"
  color_strategy: "primary dominant, gradient accents"
  density: "comfortable"
  motion: "subtle, purposeful"
  typography_emphasis: "hierarchy through weight, not size"

Direction 解决的问题：当用户说"我想要科技感的界面"——"科技感"是一个 Direction。它不是一个颜色值，而是一组约束的集合：优先用渐变、密度适中、动效克制有目的。

AI 拿到 Direction 后，在选择 Token 和 Component 时有了"倾向性"——不再随机组合，而是沿着 Direction 定义的方向走。

L4: Scene 层 — 场景=方向+组合模式

Scene 是 Direction 的具体化——在某个业务场景下，组件怎么组合。

scene:
  name: "data-dashboard"
  direction: "tech-future"
  density_override: "compact"
  layout_pattern: "grid-12"
  component_preferences:
    data_display: ["chart", "metric-card", "data-table"]
    navigation: ["sidebar", "breadcrumb"]
  spacing_scale: "tight"

为什么需要 Scene？ 因为同一个 Direction 在不同业务场景下的表现不同。"科技感"在首页是大气留白的；在数据看板里是紧凑高密度的。Scene 层捕获这种差异。

L5: Page 层 — Section 编排

Page 协议定义一个完整页面由哪些 Section 按什么顺序组成。

page:
  name: "landing-page"
  scene: "marketing-showcase"
  sections:
    - type: "hero"
      required: true
      position: "first"
    - type: "features"
      required: true
      max_items: 6
    - type: "testimonials"
      required: false
    - type: "cta"
      required: true
      position: "last"

Page 解决的问题：AI 生成一个完整页面时，不再需要"发明"页面结构——协议告诉它"landing page 由 hero → features → testimonials → CTA 组成"。

L6-L7: Exhibition + Template — 高层封装

L6 Exhibition：定义展示上下文——这个界面是在什么屏幕上展示的？是车载屏还是 Web？是竖屏还是横屏？Exhibition 层约束了视口和交互模态。

L7 Template：最高层——一个完整的可用模板包，包含了 L1-L6 所有决策的具体化。用户选择一个 Template，AI 在其内部做个性化调整。

层间关系：引用而非复制

7 层之间是引用关系，不是嵌套复制：

改了一个 Token 值，所有引用它的组件自动生效——不需要逐个文件修改。

Schema 验证：让协议不只是文档

每一层都有对应的 JSON Schema。协议文件不符合 Schema = 写入被拒绝。

这意味着：

  • ❌ 不能定义一个不存在的 variant
  • ❌ 不能引用一个未注册的组件
  • ❌ 不能违反 Token 的类型约束

Schema 验证把"设计规范"从"建议"变成了"约束"。

对 AI 的意义

回到核心问题：这 7 层对 AI 有什么用？

AI 在生成界面时，按需加载对应层级的协议文件作为 context。

用户请求AI 加载的层级效果
"改一下按钮颜色"L1 Token + L2 Button 协议精确修改，不影响其他
"做个数据看板"L1 + L2 + L4 Scene按看板场景选组件和布局
"做一个完整落地页"L1-L5 全部结构化生成完整页面
"这个产品整体偏科技感"L3 Direction全局风格约束

不同粒度的请求，加载不同层级的约束——这就是分层的价值。

设计原则总结

原则说明
层间正交每层解决独立问题，改一层不需要动其他层
引用不复制层间通过 ID 引用，单点修改全局生效
Schema 强制每层有 JSON Schema，违规写入时拦截
渐进约束L1 约束最弱（纯值）→ L7 约束最强（完整模板）
AI 可消费每层输出标准 JSON/YAML，直接进 AI context

7 层听起来复杂——但核心思想很简单：把"设计长什么样"这个模糊问题，拆成 7 个可回答的具体问题。 每层回答一个，叠加起来就是完整的设计决策链。AI 不需要"有审美"——它只需要读协议。

Comments