【GitHub】 Open Design 深度技术解析：把 Claude Design 搬回本地的 Agent 设计工作台

摘要：Open Design 是 GitHub 上 Star 数突破 60K 的开源项目，定位为 Anthropic Claude Design 的本地优先、完全开源的替代方案。本文从系统架构、设计协议、技能系统、HyperFrames 视频渲染管线、Agent 适配器等维度进行全方位拆解，探讨它如何将 AI 设计从云端黑盒转化为可组合、可审计、可版本管理的本地工程资产。

[项目基因：为什么需要 Open Design？](#项目基因：为什么需要 Open Design？)
六层架构全景拆解
[DESIGN.md：将品牌规范写入 Markdown](#DESIGN.md：将品牌规范写入 Markdown)
SKILL.md：技能即文件的协议设计
[HyperFrames：从 HTML 到 MP4 的确定性渲染管线](#HyperFrames：从 HTML 到 MP4 的确定性渲染管线)
[Agent 适配器：21 个 CLI 的统一调度层](#Agent 适配器：21 个 CLI 的统一调度层)
[Prompt Stack：可组合的上下文引擎](#Prompt Stack：可组合的上下文引擎)
应用实战：从零搭建品牌设计工作流
总结与展望

1. 项目基因：为什么需要 Open Design？

1.1 背景

Anthropic 推出的 Claude Design 在 2025 年引发了 AI 辅助设计领域的范式变革------用户用自然语言描述需求，AI Agent 直接生成可交互的 HTML 原型、演示文稿和设计系统。但这种能力被锁定在闭源、云端、绑定单一模型的产品形态中：

痛点	Claude Design 的现状	Open Design 的解法
模型锁定	仅支持 Anthropic 模型	支持 21 个 CLI + BYOK，任意 OpenAI 兼容端点
数据归属	产物存储在云端	产物落地本地 `.od/` 目录，可 `git add`
生态封闭	无法自定义技能/设计系统	155+ 技能、150+ 设计系统全部以文件形式存在
无法自托管	纯 SaaS	桌面应用 + Docker + Vercel 三种部署模式
闭源	黑盒产品	Apache-2.0 许可证

1.2 核心数据

指标	数值
GitHub Stars	60,300+
最新版本	v0.9.0 (2026-06-02)
技术栈	Next.js 16 + React 18 + TypeScript + Node 24
内置技能	155+
设计系统	150+
插件数量	261
支持 Agent	21+ CLIs
导出格式	HTML / PDF / PPTX / MP4 / ZIP / Markdown

1.3 设计哲学

Open Design 的核心主张可以概括为四条原则：

本地优先（Local-First）：桌面应用、守护进程、技能运行时均在本地运行，不依赖厂商云服务
BYOK 全链路：所有层级支持自带密钥，兼容 DeepSeek、Groq、OpenRouter 等任意兼容端点
可组合可扩展：技能和设计系统以文件形式存储，用户可自由编辑、Fork、版本管理
Agent 即执行器：不重复造 Agent，而是复用用户本地已安装的 Coding Agent CLI

2. 六层架构全景拆解

Open Design 的系统架构可以抽象为六个独立且可替换的工程层：

复制代码

┌────────────────────────────────────────────────────────────────┐
│                     ① 入口层 (Entry Layer)                       │
│   Next.js 16 Web UI  ·  Electron Desktop  ·  Chat  ·  Preview  │
├────────────────────────────────────────────────────────────────┤
│                     ② 执行层 (Daemon Layer)                      │
│   Express + SQLite  ·  SSE Streaming  ·  Session Manager       │
│   Artifact Store  ·  Export Pipeline  ·  Preview Compiler       │
├────────────────────────────────────────────────────────────────┤
│                     ③ Agent 层 (Agent Layer)                     │
│   Agent Adapter Pool  ·  PATH Scanner  ·  Stream Normalizer    │
│   Claude Code · Codex · Cursor · Gemini · OpenCode · Qwen ...  │
├────────────────────────────────────────────────────────────────┤
│                     ④ 技能层 (Skill Layer)                       │
│   SKILL.md Protocol  ·  Frontmatter Parser  ·  FS Watch         │
│   prototype · deck · template · design-system                   │
├────────────────────────────────────────────────────────────────┤
│                     ⑤ 设计系统层 (Design System Layer)            │
│   DESIGN.md 9-Section Schema  ·  Memory Cache  ·  Hot Reload   │
│   Linear · Stripe · Vercel · Apple · Tesla · Spotify ...       │
├────────────────────────────────────────────────────────────────┤
│                     ⑥ 交付层 (Delivery Layer)                     │
│   Sandbox iframe  ·  HTML/PDF/PPTX/ZIP Export  ·  HyperFrames  │
└────────────────────────────────────────────────────────────────┘

2.1 入口层：浏览器 + 桌面双模

入口层负责用户交互体验。它不执行任何 Agent 逻辑------所有重型操作都下沉到守护进程。

Web 应用 ：Next.js 16 App Router，开发模式下通过 next.config.ts 将 /api/* 代理到守护进程
Electron 桌面应用：macOS Apple Silicon/Intel + Windows x64，提供原生体验
核心界面组件：聊天面板、文件工作区、沙盒 iframe 预览、技能/设计系统选择器

2.2 执行层：守护进程架构

守护进程（Daemon）是整个系统的中枢，以单二进制或轻量 Node 脚本形式分发，默认监听 http://localhost:7456。

核心子系统的职责矩阵：

子系统	职责	实现要点
Session Manager	为每个 Web 标签页维护独立会话	保存活跃 Agent / Skill / Artifact / 工具调用状态，24h 后 GC
Agent Adapter Pool	管理所有 Agent CLI 适配器实例	跨会话复用，PATH 扫描 + 配置目录探测
Skill Registry	技能发现与优先级合并	三个扫描目录：`./.claude/skills/` > `./skills/` > `~/.claude/skills/`
Design-system Resolver	设计系统的查找与注入	顺序查找：`./DESIGN.md` → `./design-system/DESIGN.md`
Artifact Store	管理磁盘制品文件	纯文件存储，不驻留内存
Preview Compile Pipeline	预览前的编译转换	JSX Babel 转换、CSS 内联
Export Pipeline	多格式导出	HTML / PDF / PPTX / ZIP / Markdown

安全边界设计：

Daemon HTTP API 默认仅绑定 localhost
用户 API 密钥仅存储在 config.toml（权限 0600）
绝不发送至任何远程服务器（项目本身无自有服务器）

2.3 数据持久化：纯文件存储设计

Open Design 放弃了 SQLite/数据库方案，采用纯文件存储，这是一个经过深思熟虑的架构决策：

复制代码

.od/
├── config.json                  # 项目级 daemon 配置
├── artifacts/                   # 制品存储
│   └── 2026-04-24T10-03-12-landing/
│       ├── artifact.json        # 元数据（skill/mode/prompt/父级引用）
│       ├── index.html           # 主输出文件
│       └── assets/              # 生成的图片、字体等资源
├── history.jsonl                # 仅追加操作日志（git 友好）
└── sessions/
    └── <session-id>.json        # 瞬态会话（24h GC）

设计决策理由：

artifact.json 元数据 → 无需数据库即可重建制品树
history.jsonl → 仅追加写入，对 git 友好，方便 grep 搜索
会话与制品分离 → 会话是临时 UI 状态，制品是持久资产

3. DESIGN.md：将品牌规范写入 Markdown

3.1 协议由来

Open Design 遵循 awesome-claude-design 社区约定的 9 节式 DESIGN.md Schema。这不是 Open Design 独创的，而是一个正在形成的社区标准------把品牌设计规范从 Figma 的"视觉参考"转化为 AI Agent 可精确读取、严格遵循的结构化文档。

3.2 九节结构详解

markdown 复制代码

# <品牌名称>

## 1. Visual Theme & Atmosphere
# 视觉主题与氛围 --- 品牌整体调性描述
# 示例："现代、极简、科技感，以留白传递专业与信任"

## 2. Color Palette & Roles
# 调色板与角色 --- 基于 OKLCh 色彩空间的色值体系
# 示例：主色 oklch(65% 0.25 250) 用于CTA按钮
#       辅助色 oklch(85% 0.08 250) 用于背景强调
#       中性色 oklch(95% 0 0) 用于大面积底色

## 3. Typography Rules
# 排版规则 --- 字体族、字号、字重、行高、字间距
# 示例：标题 → Inter Bold | 2rem | line-height 1.2
#       正文 → Inter Regular | 1rem | line-height 1.6

## 4. Component Stylings
# 组件样式规范 --- 按钮、输入框、卡片、导航等
# 示例：主按钮 → 圆角 8px、主色填充、hover 明度+10%

## 5. Layout Principles
# 布局原则 --- 响应式断点、栅格、间距
# 示例：max-width 1280px、8px 栅格系统、section 间距 80px

## 6. Depth & Elevation
# 深度与层级 --- 阴影、z-index、层级视觉区分
# 示例：卡片阴影 → 0 2px 8px rgba(0,0,0,0.08)
#       模态框阴影 → 0 8px 32px rgba(0,0,0,0.16)

## 7. Do's and Don'ts
# 设计规范约束 --- 明确允许与禁止的行为
# 示例：DO → 保持 60-30-10 色彩比例
#       DON'T → 禁止使用超过 3 种字体

## 8. Responsive Behavior
# 响应式行为 --- 各断点的适配规则
# 示例：Mobile (<768px) → 单列布局、图片全宽
#       Desktop (>1024px) → 多列栅格、固定侧边栏

## 9. Agent Prompt Guide
# Agent 提示指南 --- 给 AI 的明确指令
# 示例："所有页面必须包含品牌主色条"
#       "正文行高不得低于 1.6"

3.3 色彩系统的 OKLCh 优势

Open Design 推荐使用 OKLCh 色彩空间而非传统的 HEX/RGB/HSL，原因如下：

与 sRGB/HSL 的对比：

属性	HSL	OKLCh
感知均匀性	❌ 相同数值变化在不同色相下亮度差异大	✅ 人眼感知的亮度变化线性
无障碍性	❌ 难以精确控制对比度	✅ 可直接约束亮度（L）满足 WCAG
AI 可操作	⚠️ 需要额外计算才能安全变体	✅ 调整 L/C/h 即可生成安全调色板

OKLCh 的三个通道：

复制代码

L (Lightness)   ∈ [0, 1]   → 感知亮度，0 = 黑，1 = 白
C (Chroma)      ∈ [0, 0.4] → 饱和度/鲜艳度
h (Hue)         ∈ [0, 360] → 色相角（度）

生成品牌调色板的实际操作：保持色相角 h 不变，通过调节 L 和 C 生成从深到浅的完整色阶。例如：

复制代码

主色：    oklch(55% 0.22 250)   → 中等蓝色
浅变体：  oklch(85% 0.08 250)   → 浅蓝背景
深变体：  oklch(35% 0.15 250)   → 深蓝文本

3.4 设计系统的加载与注入机制

复制代码

用户选择设计系统
      │
      ▼
Design-system Resolver 查找 DESIGN.md
      │
      ▼
解析 9 节结构 → 内存缓存
      │
      ▼
┌─────────────────────────────┐
│  注入到 Agent System Prompt │
│                             │
│  [当前设计系统: Stripe]      │
│  ## Color Palette & Roles   │
│  ## Typography Rules         │
│  ...                        │
│                             │
│  + 技能正文 (SKILL.md body)  │
│  + 工艺参考 (Craft Refs)     │
│  + 用户 Prompt               │
└─────────────────────────────┘
      │
      ▼
Agent 生成 → 自动适配品牌风格

如果技能通过 od.design_system.sections 声明了仅需部分章节（如 [color, typography]），则只注入相关章节------减少不必要的 token 消耗。

4. SKILL.md：技能即文件的协议设计

4.1 协议基础

Open Design 的技能系统遵循 Claude Code SKILL.md 约定 ，并扩展了 od: 命名空间的前置元数据。这意味着：

为普通 Claude Code 编写的技能可直接在 Open Design 中运行
不使用 OD 扩展的技能也可在普通 Claude Code 中运行

双向兼容是协议设计的核心原则。

4.2 完整技能目录结构

复制代码

<skill-root>/
├── SKILL.md              # 清单 + 工作流指令（前置元数据 + Markdown 正文）
├── assets/               # 模板、样板文件、静态资源
│   ├── template.html
│   └── ...
├── references/           # Agent 规划阶段读取的知识文件
│   ├── themes.md
│   ├── layouts.md
│   ├── components.md
│   └── checklist.md
└── tests/                # 可选 CI 测试
    ├── basic.prompt
    ├── basic.expected.manifest.json
    └── basic.expected.regex.txt

4.3 SKILL.md 前置元数据规范

yaml 复制代码

---
name: magazine-web-ppt                    # 技能唯一标识
description: |
  Magazine-style horizontal-swipe web deck.
triggers:                                 # 触发关键词
  - "magazine deck"
  - "杂志风 PPT"

# === OD 扩展字段（全部可选） ===
od:
  mode: deck                              # prototype | deck | template | design-system
  preview:
    type: html                            # html | jsx | pptx | markdown
    entry: index.html
    reload: debounce-100
  example_prompt: "Create a magazine-style web deck from my content."
  example_prompt_i18n:
    zh-CN: "用杂志风网页 PPT 模板把我的内容做成横向翻页 deck。"
  design_system:
    requires: true
    sections: [color, typography]         # 仅注入相关章节
  craft:                                  # 品牌无关的工艺参考
    requires: [typography, color, anti-ai-slop]
  inputs:                                 # 侧边栏类型化输入表单
    - name: title
      type: string
      required: true
    - name: slide_count
      type: integer
      default: 8
      min: 4
      max: 20
    - name: theme
      type: enum
      values: [editorial, minimal, brutalist, dark-glass, warm]
      default: editorial
  parameters:                             # 实时调整滑块
    - name: accent_hue
      type: hue
      default: 18
      range: [0, 360]
    - name: section_spacing
      type: spacing
      default: 48
      range: [16, 128]
  outputs:
    primary: index.html
    secondary: [slides.json]              # PPTX 导出所需辅助文件
  capabilities_required:
    - surgical_edit
    - file_write
---

4.4 四种技能模式

模式	用途	预览类型	主输出	典型工作流
prototype-skill	单屏交互原型	`html` / `jsx`	`index.html`	明确需求 → 解析设计令牌 → 编写组件树 → 写入文件
deck-skill	多页演示文稿	`html`（单文件+导航）	`index.html`	明确主题+页数 → 选择主题 → 填充布局 → 质量自检
template-skill	基于预置模板生成	继承模板类型	填充后的副本	复制 template → 替换占位符 → 调整令牌
design-system-skill	生成 DESIGN.md	`markdown`	`DESIGN.md`	分析输入 → 按 9 节起草 → 预览组件 → 定稿

4.5 无 OD 字段时的智能推断

当技能文件没有 od 字段时，系统会自动推断：

mode ：从技能名称/描述的关键词推断，推断失败默认 prototype
preview.type ：自动嗅探文件类型（*.html → html，*.jsx → jsx）
design_system.requires：如果技能正文提到 "design system" 或 "DESIGN.md" 则自动为 true
inputs / parameters：无，仅支持自由文本输入

这种"渐进增强"的设计确保了最大兼容性------最简单的技能只需一个 SKILL.md 文件即可运行。

4.6 技能发现机制

复制代码

启动 / SIGHUP 信号 / FS-watch 事件
        │
        ▼
  ┌─────────────────────────────┐
  │  Skill Registry 扫描        │
  │                             │
  │  ① ./.claude/skills/  (P1) │ ← 项目私有，优先级最高
  │  ② ./skills/           (P2) │ ← 项目共享
  │  ③ ~/.claude/skills/   (P3) │ ← 用户全局
  │                             │
  │  同名技能使用高优先级版本    │
  │  chokidar 监听文件变化       │
  └─────────────────────────────┘

5. HyperFrames：从 HTML 到 MP4 的确定性渲染管线

5.1 技术定位

HyperFrames 是 Open Design 生态中的"HTML→视频"元层（meta-layer），解决了一个关键工程问题：如何让 AI Agent 用写代码的方式生成确定性、帧级精确的视频？

核心公式：

复制代码

纯 HTML + CSS + GSAP 动画 → HyperFrames 渲染引擎 → 确定性 MP4 输出

"确定性"的含义是：相同输入 → 字节级完全一致的输出帧。这意味着：

不依赖 GPU（帧级稳定，与 Remotion 同级别）
CI 环境可重现（"Same file appears on every machine, identical, every time"）
Agent 可写入、渲染并检查输出，无需人工干预

5.2 渲染管线架构

整个管道分为五个阶段：

复制代码

阶段 ① 源内容获取
    ├── 自然语言 prompt
    ├── 文章链接 → 服务端拉取 → Markdown
    └── GitHub 仓库 → 克隆/拉取 → Markdown
          │
          ▼
阶段 ② Agent 循环（内容规划）
    读取源内容 + 选定模板风格
    → 生成内容图（故事板）
    → 每帧对应的 HTML 代码
          │
          ▼
阶段 ③ 内容图构建（中间表示 IR）
    ContentGraph: {
      nodes: [实体/数据/文本节点],
      edges: [序列关系/依赖关系/对比关系]
    }
    → 拓扑排序 → 确定帧顺序和时长
          │
          ▼
阶段 ④ 逐帧 HTML 生成
    每个节点 → 独立的自包含动画 HTML 文件
    所有 GSAP 依赖、样式、资源内嵌在单文件中
          │
          ▼
阶段 ⑤ HyperFrames 渲染引擎
    无头 Chromium 逐帧加载 HTML
    → 录制 GSAP 动画 → 输出逐帧 WebM
    → FFmpeg (libx264) → 拼接 → MP4
    → 可选：混入 MiniMax 生成的 BGM + 旁白

5.3 确定性渲染的数学基础

HyperFrames 的确定性来源于对动画时间线的精确控制。对于一个 GSAP 动画序列，其时间线可描述为：

设动画序列 A = {a₁, a₂, ..., aₙ}，每个动画片段 aᵢ 由以下参数定义：

复制代码

aᵢ = (t_startᵢ, durationᵢ, easingᵢ, propertiesᵢ)

渲染器在时间 t 的帧 F(t) 由所有活跃动画的交集决定：

复制代码

F(t) = Composite({ aᵢ · progress(t - t_startᵢ) | t ∈ [t_startᵢ, t_startᵢ + durationᵢ] })

其中 progress(τ) 由缓动函数 easingᵢ 计算：

复制代码

progress(τ) = clamp(easingᵢ(τ / durationᵢ), 0, 1)

由于所有参数都是确定性的（纯数学函数，无物理时间依赖），给定相同的输入 HTML 和时间 t，输出帧 F(t) 必然相同。

最终的 MP4 编码参数：

参数	值
视频编码器	`libx264`
帧率	由 HTML 中 `data-duration` 和内容图拓扑排序决定
分辨率	由 `data-width` × `data-height` 指定
中间格式	WebM（无头 Chromium 录制）
音频混流	MiniMax TTS + BGM，背景音乐自动压低以突出人声，支持淡入淡出

5.4 HTML 时间属性语法

HyperFrames 使用 data-* 属性在 DOM 层面表达时间线：

html 复制代码

<!-- 一个 5 秒的视频 -->
<div data-width="1920" data-height="1080">
  <!-- 背景片段：从 0 秒开始，持续 5 秒 -->
  <video src="intro.mp4" data-duration="5"/>

  <!-- 标题：从第 1 秒开始出现，持续 4 秒 -->
  <h1 data-start="1" data-duration="4">
    Hello, friend.
  </h1>

  <!-- 副标题：从第 2 秒淡入 -->
  <p data-start="2" data-duration="3" class="fade-in">
    This is a HyperFrame.
  </p>
</div>

三个核心属性：

属性	含义	类型
`data-width` / `data-height`	画布分辨率	px
`data-start`	元素出现的起始时间	秒（浮点）
`data-duration`	元素持续时长	秒（浮点）

5.5 多引擎适配器接口

当前默认渲染引擎为 HyperFrames，但架构层面预留了统一适配器接口，后续可接入：

引擎	特点
HyperFrames (当前默认)	确定性渲染，不依赖 GPU，Agent-native
Remotion (计划中)	React 组件渲染视频，生态丰富
Motion Canvas / Revideo (计划中)	程序化动画
Manim (计划中)	数学/科学可视化动画

引擎切换通过统一适配器接口完成，上层 Agent 逻辑无需修改。

6. Agent 适配器：21 个 CLI 的统一调度层

6.1 架构决策：不重复造 Agent

Open Design 做了这样一个关键决策：不投入资源自研模型或 Agent，而是复用用户本地已有的 Coding Agent CLI。这意味着：

Agent 层的唯一职责是检测、适配、调度
每个 Agent 的能力边界由适配器声明
用户可自由选择（并随时切换）自己信任的 Agent

6.2 适配器池架构

复制代码

Daemon 启动
    │
    ▼
Agent Scanner (PATH + 配置目录探测)
    │
    ├── claude ✓        → 创建 ClaudeAdapter
    ├── codex ✓         → 创建 CodexAdapter
    ├── cursor ✓        → 创建 CursorAdapter
    ├── gemini ✓        → 创建 GeminiAdapter
    ├── opencode ✓      → 创建 OpenCodeAdapter
    ├── qwen ✓          → 创建 QwenAdapter
    ├── copilot ✓       → 创建 CopilotAdapter
    ├── kimi ✓          → 创建 KimiAdapter
    ├── hermes ✓        → 创建 HermesAdapter
    ├── devin ✗         → 未安装，跳过
    └── ...
    │
    ▼
Agent Adapter Pool (跨会话复用)
    │
    ├── 标准化启动包装
    ├── 流式输出归一化（JSON Lines → 统一 SSE 事件流）
    ├── 能力声明（多轮、精确编辑、原生 Skill 加载等）
    └── 环境变量注入

6.3 支持的 Agent CLI 全矩阵

Agent CLI	安装命令	特点
Claude Code	`od mcp install claude`	Anthropic 官方，skill 原生支持
Codex CLI	`od mcp install codex`	OpenAI 官方
Cursor	`od mcp install cursor`	IDE 内置 agent
VS Code Copilot	`od mcp install copilot`	GitHub Copilot
Gemini CLI	`od mcp install gemini`	Google 官方
OpenCode	`od mcp install opencode`	开源
Qwen Code	`od mcp install qwen`	阿里通义千问
Kimi CLI	`od mcp install kimi`	月之暗面
Hermes Agent	`od mcp install hermes`	-
OpenClaw	`od mcp install openclaw`	-
Antigravity	`od mcp install antigravity`	-
Cline	`od mcp install cline`	VS Code 插件
Trae	`od mcp install trae`	字节跳动
Mistral Vibe	`od mcp install vibe`	Mistral 官方
Pi Agent	`od mcp install pi`	Inflection AI

总计支持 21 个 CLI 及任何 OpenAI 兼容端点（BYOK）

6.4 执行模式：本地 CLI vs API

模式	选择器值	请求流向
Local CLI（默认）	"Local CLI"	Frontend → Daemon → `spawn(<agent>, ...)` → stdout → SSE → 预览
API 模式	"Anthropic API" / "OpenAI API" / ...	Frontend → Daemon `/api/proxy/{provider}/stream` → SSE → 预览

两种模式共用同一个 <artifact> 解析器和同一个沙盒 iframe 预览。

6.5 Agent 运行时环境变量注入

Daemon 在生成 Agent 进程时自动注入以下上下文：

bash 复制代码

OD_BIN          # daemon CLI 的绝对路径
OD_DAEMON_URL   # 运行中的 daemon URL (http://127.0.0.1:7457)
OD_PROJECT_ID   # 当前项目 ID
OD_PROJECT_DIR  # 当前项目文件目录

这使得 Agent 可以回写产物到正确的磁盘位置、调用 daemon 能力、访问项目上下文。

6.6 SSE 流式传输协议

这是前端与 daemon 之间最核心的通信协议。关键架构决策：

nginx 复制代码

location /api/ {
    proxy_pass http://127.0.0.1:7456;
    proxy_buffering off;        # ← 必须关闭！
    gzip off;                   # ← 必须关闭！否则 SSE 被缓冲
    proxy_read_timeout 86400s;  # 长连接容忍
    proxy_http_version 1.1;
    proxy_set_header Connection "";
}

⚠️ 常见故障 ：gzip on 会缓冲 SSE 响应，导致 80-90 秒后出现 net::ERR_INCOMPLETE_CHUNKED_ENCODING。

流事件类型（共享于 packages/contracts/src）：

事件	类型	说明
`text_delta`	文本增量	Agent 输出的文本增量
`tool_call`	工具调用	Agent 执行的工具调用（编辑/写入/读取）
`thinking`	思考过程	Agent 的推理过程（若支持）
`artifact_start`	制品开始	新制品创建
`artifact_end`	制品完成	制品写入完成
`error`	错误	执行异常

7. Prompt Stack：可组合的上下文引擎

7.1 架构概览

每次用户请求发送时，Open Design 并非使用固定的 system prompt。它以动态组合的多层上下文作为输入------这个设计精确模拟了专业设计师的工作流程：查阅品牌手册、回顾过往参考、对齐需求约束、遵循输出规则。

复制代码

┌──────────────────────────────────────────────┐
│            7 层 Prompt Stack                   │
├──────────────────────────────────────────────┤
│  ① Discovery Directive                       │
│     首轮需求表单 · 品牌分支 · TodoWrite ·     │
│     5 维自我评审规则                          │
├──────────────────────────────────────────────┤
│  ② Identity Canon                            │
│     官方设计师 prompt · 反 AI 低质内容检查    │
│     初级设计师校验规则                        │
├──────────────────────────────────────────────┤
│  ③ Active DESIGN.md (品牌设计系统)           │
│     仅注入 `od.design_system.sections`        │
│     指定的相关章节                            │
├──────────────────────────────────────────────┤
│  ④ Active SKILL.md (当前技能)                │
│     工作流步骤 + 输出规则                     │
├──────────────────────────────────────────────┤
│  ⑤ Project Metadata                          │
│     产物类型 · 保真度 · 演讲者备注 ·         │
│     动画配置 · 灵感参考 ID                    │
├──────────────────────────────────────────────┤
│  ⑥ Skill Attachments                         │
│     预注入的模板文件 · 参考资料               │
│     assets/ · references/                     │
├──────────────────────────────────────────────┤
│  ⑦ Framework Directives                      │
│     幻灯片导航 · 计数器 · 滚动 · 打印规则    │
└──────────────────────────────────────────────┘

7.2 RULE 1：需求对齐优先

Open Design 内置了一个关键规则------发现表单优先于代码生成：

复制代码

每个新设计需求的第一轮：
  不直接生成代码
      ↓
  弹出 <question-form id="discovery">
      ↓
  询问：
    · surface（载体：Web/移动/桌面/PPT）
    · audience（受众：C端/B端/内部）
    · tone（风格：专业/活泼/极简/科技）
    · brand context（品牌背景）
    · scale（规模：单页/多页/应用）
    · constraints（约束）
      ↓
  对齐需求方向后 → 再进入生成阶段

这种设计将"提前对齐需求"的工程实践内置到了产品流程中，大幅降低了方向偏差导致的大规模返工。

8. 应用实战：从零搭建品牌设计工作流

8.1 环境准备

方式一：桌面应用（推荐）

macOS / Windows 安装包 → open-design.ai

方式二：Docker 部署

bash 复制代码

git clone https://github.com/nexu-io/open-design.git
cd open-design/deploy
cp .env.example .env
# 编辑 .env 填入 API 密钥（或使用本地 CLI）
docker compose up -d
# 访问 http://localhost:7456

方式三：源码运行

bash 复制代码

git clone https://github.com/nexu-io/open-design.git
cd open-design
corepack enable && pnpm install
pnpm tools-dev run web

8.2 场景一：生成品牌落地页

Step 1 --- 创建项目并激活设计系统

bash 复制代码

# 在 Web UI 中创建新项目，或导入现有文件夹
# 从 150 套设计系统中选择，例如 "Stripe" 风格

Step 2 --- 选择技能

在技能选择器中选择 saas-landing（营销落地页）或 web-prototype（通用原型）。

Step 3 --- 填写发现表单

复制代码

surface: Web 桌面端
audience: 企业客户（B2B SaaS）
tone: 专业、现代、科技感
brand context: 音视频处理 API 平台
scale: 单页（Hero + Features + Pricing + CTA）

Step 4 --- 发送 Prompt

复制代码

创建一个音视频 API 平台的落地页。
核心功能：实时转码、智能去噪、超分辨率。
目标用户：音视频开发者。
需要包含：Hero 区、3 个功能卡片、定价对比表、CTA 按钮。

Step 5 --- 预览与导出

Agent 生成 → 沙盒 iframe 实时预览 → 微调参数 → 导出 HTML/PDF/PPTX。

8.3 场景二：创建自定义品牌设计系统

如果 150 套内置系统中没有你的品牌，可以从零生成：

Step 1 --- 切换到 design-system 模式

在 UI 中选择 design-system 技能。

Step 2 --- 提供品牌输入

复制代码

品牌名称：MyVideoAPI
行业：音视频 SaaS
风格关键词：现代、科技、专业、可靠
竞品参考：Vercel、Cloudinary、Mux
主色偏好：深蓝 + 青蓝

Step 3 --- Agent 生成 DESIGN.md

Agent 会按 9 节 Schema 输出完整的品牌规范文件。

Step 4 --- 保存并激活

bash 复制代码

# 保存为项目设计系统
cp DESIGN.md ./.od/design-system/DESIGN.md

# 或全局安装
cp DESIGN.md ~/.open-design/design-systems/myvideoapi/DESIGN.md

之后所有技能生成的内容都会自动应用这套品牌规范。

8.4 场景三：制作产品介绍视频

Step 1 --- 选择 HyperFrames 技能

Step 2 --- 描述视频内容

复制代码

制作一个 60 秒的产品介绍视频：
- 0-5s：品牌 Logo 动画入场
- 5-15s：标题"实时视频转码 API"打字机效果
- 15-35s：三个功能特性卡片依次滑入
- 35-50s：数据可视化图表动画
- 50-60s：CTA 按钮 + Logo

Step 3 --- Agent 生成内容图 + 逐帧 HTML

Agent 自动完成：

内容图构建 → 拓扑排序
逐帧 HTML 生成（嵌入 GSAP 动画 + 品牌色）
HyperFrames 渲染 → MP4 输出

8.5 场景四：多 Agent 对比测试

同一需求，切换不同 Agent 观察生成质量差异：

bash 复制代码

# 使用 Claude Code 生成
# 记录：色彩准确性、组件完整性、代码质量

# 使用 Qwen Code 生成（同一需求）
# 记录：响应速度、中文理解能力、布局还原度

# 使用 Gemini CLI 生成（同一需求）
# 记录：创意性、动画效果、代码架构

这种对比测试对于团队 Agent 选型非常有价值。

9. 总结与展望

9.1 核心价值判断

Open Design 的真正价值不在于"开源 Claude Design 替代版"这个传播性 slogan。它的工程创新在于：

用本地 daemon 连接浏览器体验和本地文件系统，复用现有 Coding Agent 的执行能力，用 SKILL.md 和 DESIGN.md 约束输出风格，用沙盒预览和导出管线把 AI 生成产物变成可交付的工程资产。

六层可替换架构使得每个层级都可以独立演进：

复制代码

入口层 ─── 可替换 UI 框架（当前 Next.js 16）
执行层 ─── 可替换后端（当前 Express + Node 24）
Agent 层 ── 可替换执行器（当前 21 个 CLI）
技能层 ─── 可组合能力单元（SKILL.md 协议）
设计系统层 ─ 可版本管理品牌规范（DESIGN.md 协议）
交付层 ─── 多格式导出管线（HTML/PDF/PPTX/MP4）

9.2 技术亮点

亮点	说明
DESIGN.md 9 节 Schema	将品牌规范从"感觉"转化为 Agent 可精确执行的规则文件
SKILL.md 双向兼容	Claude Code 原生技能无需修改即可运行，OD 扩展为可选
HyperFrames 确定性渲染	HTML→MP4 管线保证 CI 可重现，字节级一致
Prompt Stack	7 层动态上下文组合，模拟专业设计师工作流程
纯文件存储	`.od/artifacts/` 直接 `git add` 进入 PR 审查流程

9.3 风险与局限

多 Agent 适配器维护成本：支持的 CLI 越多，不同 CLI 的输出格式、权限、错误处理差异带来的维护压力越大
本地 daemon 安全边界：daemon 可以调 CLI、读写文件、代理 API，需要严格的 SSRF 阻断和权限控制
不适合"一键出图"需求：需要理解本地 runtime、Agent、Skill、设计系统等概念，存在一定工程门槛
版本快速迭代：v0.9.0 仍处于 rapid iteration 阶段，生产环境依赖需谨慎评估

9.4 未来方向

功能	状态
注释模式精准编辑	🔄 部分上线
`npx od init` 脚手架	📋 计划中
Plugin SDK + CLI	📋 计划中
Figma → React/Next/Vue 迁移插件	📋 Alpha
刷新现有代码库插件	📋 计划中
Remotion / Motion Canvas 渲染引擎	📋 计划中

参考资料

本文完成于 2026 年 6 月 7 日，基于 Open Design v0.9.0 版本。技术架构与功能特性可能随项目迭代而变化，请以官方文档为准。