Open Design: 本地优先架构重塑AI UI生成工作流

摘要

Open Design 不是一个简单的 AI 画界面工具，而是一个本地优先、可以接入现有 Coding Agent、基于 Skill 与 Design System 驱动的开源设计工作流。本文从架构、原理、实战和风险控制角度，来拆解它的技术价值。

---

背景介绍：AI 设计工具的问题不在“不会写 CSS”

近两年，AI 生成 UI 的能力进步飞快。从早期只能生成一段简单的 HTML/CSS，到现在可以直接量产原型、Landing Page、Dashboard、PPT 甚至移动端页面，AI 确实已经具备了相当的设计产出能力。

不过，很多 AI UI 工具依然有那几个老毛病，不知道你注意到没有：

1. 强绑定云端生态：设计能力通常被锁定在特定模型或平台上，很难融入已有的开发环境。
2. 无法本地运行：在团队的私有代码库和内部设计规范下，几乎没法安全地用起来。
3. 输出风格不稳定：同一个需求多生成几次，视觉体系、组件层级、交互重点可能完全不一样。
4. 缺少结构化约束：模型经常自己发挥，搞出一堆圆角卡片、紫色渐变、Emoji 图标和看起来“AI 味”很重的伪指标。

Open Design 的定位就是冲着解决这些短板来的。它没有重新训练一个设计模型，而是搭建了一个 Design Shell：在本地运行，自动检测开发者已有的 Coding Agent，比如 Claude Code、Codex CLI、Cursor Agent、Gemini CLI、OpenCode 这些，然后把它们当作设计执行的引擎。

说到底，Open Design 关心的不是“让 AI 学会设计”，而是给 AI 一个更合理的设计工作流。

---

核心原理：Agent + Skill + Design System

1. 本地优先的 Design Shell

Open Design 最核心的特征就是 Local First。它本身不强制绑定某个云端 AI 服务，而是在本地启动一个守护进程，连接当前机器 PATH 中可用的 Coding Agent。

它的工作模式大致是这样的：

用户需求
↓
Open Design 本地应用
↓
选择 Skill / Design System
↓
调用本地 Coding Agent
↓
生成 HTML / React / Deck / Markdown 等设计产物
↓
本地预览与编辑

这么搞的好处很明显：

• 可以直接复用已有的 AI Coding 工具；
• 设计产物能进入 Git 进行版本管理；
• 团队可以维护自己的 Skill 和 design.md；
• 输出文件是可审查、可测试、可重构的，不像聊天窗口里的东西，关了就没了。

项目本身采用 Apache 2.0 License，完全开源。实际成本取决于底层 Agent 或模型，比如用 Claude Code、Codex CLI、Gemini CLI 时，花费会对应计算各自的模型资源。

---

2. Skill：把“随便做个页面”变成结构化任务

AI UI 生成容易翻车的根本原因，其实不是模型不会写 CSS，而是缺乏一个明确的任务边界。

Open Design 引入了可组合的 Skill，给你举个例子：

• Web Prototype
• SaaS Landing Page
• Dashboard
• Pricing Page
• Docs Page
• Blog Post
• Mobile App
• Magazine-style Deck
• PM Spec
• Weekly Update
• Meeting Notes
• Runbook
• Finance Report
• Invoice
• Kanban Board
• KRs

当你选 dashboard Skill 时，模型会被引导生成偏数据密集型、管理后台风格的界面；选 magazine_ppt 时，就会偏向杂志式版面、视觉叙事和 Deck 结构。

这可比直接输入“帮我做个好看的页面”可靠多了，因为 Skill 会提供：

• 任务边界；
• 组件结构；
• 视觉重点；
• 输出格式；
• 以及一个检查清单。

---

3. Design System：解决 AI UI 的稳定性问题

Open Design 内置了大量的 design.md 设计系统文件，数目超过 70 个。这些设计系统借鉴了 Linear、Stripe、Airbnb、Tesla、Notion、Apple、Cursor、Supabase、Figma、Raycast、Spotify、Webflow、Sentry、MongoDB、ClickHouse 等产品的视觉语言。

design.md 的价值在于，它把抽象的美学审美转化成了文本化的规则。比如：

# Internal Dashboard Design System

## Layout
- 使用 12 栅格布局
- 左侧固定导航，主内容区域最大宽度 1440px
- 数据模块之间保持 24px 间距

## Typography
- 标题使用 28px / 36px
- 正文使用 14px / 22px
- 指标数字使用等宽字体

## Component Rules
- 避免过度圆角
- 避免随机渐变背景
- KPI 卡片必须包含指标来源和更新时间

这样一来，AI 不再是凭直觉胡乱生成页面，而是在一个稳定的视觉系统里完成设计任务。

---

实战演示：用 OpenAI 兼容 API 生成 Dashboard Artifact

下面这段代码模拟的是 Open Design 的核心思路：输入 Skill、Design System 和业务需求，调用模型生成一个可落地的 React + Tailwind Dashboard 页面。

安装依赖

pip install openai python-dotenv

.env 配置

XUEDINGMAO_API_KEY=你的_API_Key

Python 完整示例

import os
from pathlib import Path
from openai import OpenAI
from dotenv import load_dotenv

load_dotenv()

class UIDesignArtifactGenerator:
    """基于 OpenAI 兼容接口的 UI Artifact 生成器。
    可用于模拟 Open Design 中 Skill + Design System + Agent 的工作方式。
    """
    def __init__(self):
        api_key = os.getenv("XUEDINGMAO_API_KEY")
        if not api_key:
            raise ValueError("请先在 .env 中配置 XUEDINGMAO_API_KEY")
        self.client = OpenAI(
            api_key=api_key,
            base_url="https://xuedingmao.com/v1"
        )
        # claude-opus-4-6 适合复杂 UI 规划、长上下文约束和高质量代码生成
        self.model = "claude-opus-4-6"

    def build_prompt(self, requirement: str) -> str:
        skill = """
        你正在执行 dashboard skill。
        目标：生成一个企业级数据分析 Dashboard。
        输出要求：
        1. 使用 React + Tailwind CSS。
        2. 页面必须包含侧边导航、顶部状态栏、KPI 区域、趋势图占位、数据表格和任务列表。
        3. 不能使用紫色渐变、随机 Emoji、虚假夸张指标。
        4. 所有组件需要具备清晰的信息层级。
        5. 代码必须是单文件 React 组件，默认导出 App。
        """
        design_system = """
        Design System:
        - 风格：Linear / Stripe 风格，克制、干净、信息密度高。
        - 颜色：以 slate、zinc、neutral 为主，强调色使用 blue。
        - 圆角：控制在 rounded-lg 以内，避免过度胶囊化。
        - 字体：系统默认 sans-serif。
        - 间距：模块间距 24px，卡片内部间距 16px。
        - 表格：需要包含状态 Badge、更新时间、负责人字段。
        - 可访问性：按钮和导航需要有明确文本，不依赖纯图标。
        """
        critique_rules = """
        生成前请进行五维自检：
        1. Design Philosophy：是否符合企业级 Dashboard 的克制风格？
        2. Hierarchy：标题、指标、图表、表格是否层级清晰？
        3. Execution：React 代码是否完整可运行？
        4. Specificity：是否避免空洞文案和无意义指标？
        5. Restraint：是否避免过度装饰和 AI UI 常见套路？
        """
        return f"""
        {skill}
        {design_system}
        业务需求：{requirement}
        {critique_rules}
        请直接输出完整 React 代码，不要输出 Markdown 解释。
        """

    def generate(self, requirement: str) -> str:
        response = self.client.chat.completions.create(
            model=self.model,
            messages=[
                {"role": "system", "content": "你是一名资深前端架构师和产品设计工程师，擅长生成高质量 UI Artifact。"},
                {"role": "user", "content": self.build_prompt(requirement)}
            ],
            temperature=0.35,
        )
        return response.choices[0].message.content

    def sa ve_artifact(self, code: str, output_path: str = "App.jsx") -> None:
        path = Path(output_path)
        path.write_text(code, encoding="utf-8")
        print(f"UI Artifact 已生成：{path.resolve()}")

if __name__ == "__main__":
    requirement = """
    为一个 AI Agent 运行监控平台生成 Dashboard。
    需要展示：
    - Agent 运行次数
    - 平均响应延迟
    - 工具调用成功率
    - 最近失败任务
    - 模型调用成本趋势
    - 团队成员任务分布
    """
    generator = UIDesignArtifactGenerator()
    artifact_code = generator.generate(requirement)
    generator.sa ve_artifact(artifact_code)

生成 App.jsx 后，可以把它放进一个 Vite React 项目里运行：

npm create vite@latest ai-dashboard -- --template react
cd ai-dashboard
npm install
npm install tailwindcss @tailwindcss/vite

然后把生成的 App.jsx 替换项目中的入口组件，就可以在本地预览和二次修改了。

---

注意事项：Open Design 适合做起点，不应直接替代设计评审

1. 输出质量依赖底层模型

Open Design 的上限取决于 Coding Agent 和模型的能力。强模型能更好地理解 Skill、Design System 和复杂业务上下文；弱模型就算拿到 design.md，也可能生成结构混乱的代码。

2. 本地目录权限需要谨慎控制

Open Design 会为 Agent 分配工作目录。由于 Agent 具备读写文件的能力，一定要避免暴露敏感目录，比如密钥文件、生产配置、客户数据这些。

3. 仍需人工检查响应式与可访问性

对于生产级的 UI，AI 生成的内容最多只能算个初稿。前端工程师必须复查：

• 响应式布局；
• 组件复用；
• 语义化 HTML；
• 键盘可访问性；
• 暗色模式适配；
• 数据真实性；
• 代码可维护性。

4. 不要过度期待“端到端自动设计”

Open Design 目前更适合快速原型、内部工具、Landing Page、Deck、视觉实验这类场景。对于核心产品界面，它更像是设计和前端之间的一个加速层，而不是最终的决策者。

---

总结

Open Design 的价值不在于复刻某个闭源设计产品，而是把 AI UI 生成从“随机扔 Prompt”推进到了“结构化工作流”。

它把三类能力组合到了一起：

1. 已有的 Coding Agent；
2. 文件化的 Skill；
3. 可以版本管理的 design.md 设计系统。

这种模式让团队能在本地运行、审查、分支、复用乃至不断迭代自己的 AI 设计流程。对开发者来说，这也许是 AI UI 生成更务实的方向：少一点不可控的聊天式输出，多一点可检查、可约束、可落地的工程化产物。