App Open-Design 让智能体按你的设计规范出图

一、项目介绍

设计师和前端之间那道鸿沟，AI 并没有自动填平。设计师说的是" Linear 那种冷调极简风"，AI 出来的是又一个千篇一律的紫色渐变；再好的模型，也得先知道你的设计系统长什么样。

Open-Design 定位为协作式 AI 设计代理工作台，本地优先、开源。它的思路是：让设计规范成为可被 Agent 读取的项目文件，再让 Agent 按规范产出设计稿与页面。仓库提供 DESIGN.md 这样的约定文件，以及可直接使用的功能技能与设计模板，Agent 会把它们与你的规范组合起来，生成规范化的项目文件。

它不要求你非得打开 GUI：可以直接以技能、插件或 MCP 服务的形式装进 Claude Code、Codex、Cursor、Copilot、OpenClaw、Antigravity、Hermes、Kimi 等十余种 Agent 宿主。桌面应用则提供图形化工作台，也支持 Docker 自托管。star 数已破 10 万，Apache 2.0 协议。

设计规范之所以难落地，通常不是因为设计师不愿意写文档，而是因为文档躺在某个网盘里、Agent 根本读不到。Open-Design 的核心思路就是把这个断层补上：把规范变成项目里的文件（DESIGN.md 这类约定文件），让 Agent 和人读同一份。

它同时提供"设计技能"与"设计模板"两类资产。技能是可复用的功能片段，模板是成套的视觉方案；配合项目里的规范文件，Agent 会把它们组合起来生成规范化的项目文件，而不是每次都从零发挥。在本地文件系统支持的 CLI 运行方式下，Agent 真的会写出这些文件，再由 OpenDesign 预览它们。

它最大的特点是形态灵活。同一套能力既能作为桌面应用使用（图形化工作台），也能以技能、插件或 MCP 服务的形式装进十几种 Agent 宿主——Claude Code、Codex、Cursor、Copilot、OpenClaw、Antigravity、Hermes、Kimi 都在支持列表里。这意味着它不是一个要你迁移过去的独立工具，而是一层能叠加到现有工作流上的能力。

部署上，官方提供 Docker Compose 方案与 Sealos 模板，并明确了鉴权方式：默认用 OD_API_TOKEN 做 Basic Auth，API 客户端也可以继续用 Bearer Token。值得注意的是，作者专门说明 install.sh 是一个薄封装，目的是避免托管 URL 在某些 shell 下返回 HTML 落地页而不是脚本——这种细节能看出团队踩过坑。

二、项目基本信息

三、核心优势

• 设计规范文件化，Agent 按 DESIGN.md 与设计模板产出结果，风格不再靠猜
• 可作技能、插件或 MCP 服务接入十余种 Agent 宿主，不必迁就某一套工具链
• 本地优先，文件落在本地目录，版本可管可控
• 提供 Docker 自托管方案，服务端口与鉴权方式都写清楚
• 既能用桌面应用，也支持浏览器直接使用的托管形态
• Apache 2.0 协议，可自由二次开发
• 设计规范、技能与模板三类资产组合，产出结果有据可依而非凭空发挥
• 本地文件优先，Agent 直接写入规范化项目文件，产出可进版本控制
• Sealos 应用商店提供现成部署模板，容器化落地路径短
• 支持 BYOK 与纯 API 两种运行方式，无文件系统工具时也能返回完整产物

四、适用场景

适合有专职设计团队、却总被"AI 出的图不像我们的设计系统"困扰的前端与设计团队；也适合希望把设计规范沉淀成文件、让 Agent 直接复用的组织。

最直接的适用场景是：团队有明确的设计系统，但 AI 产出总是"像那么回事却不是你们的风格"。这时把规范文件化，让 Agent 读同一份规范，收益立刻可见。

如果团队还没有成型的设计规范，Open-Design 也能用——它自带的技能与模板本身就是可用的起点，先跑起来再逐步沉淀自己的规范。

形态选择上：想要可视化工作台就用桌面应用；已经在某个 Agent 里干活、想顺手加上设计能力，就用 od mcp install <agent> 把它装进去；需要团队共享或跑在服务器上，用 Docker 自托管。

有一个坑要提前说：macOS 与 WSL2 用户如果命令行里的 od 指向系统的十六进制转储工具，会和 OpenDesign 的命令冲突。官方给的解法是从桌面应用的 Settings → MCP server 里复制对应客户端的配置片段（用的是绝对路径，不依赖裸 od 命令）。

如果你正被同类问题反复绊住——要么是人肉重复劳动没完，要么是工具装不上跑不通、要么是产出的结果根本没法用——那这个项目值得先花十分钟装一遍试试。

五、安装教程

当前最新版本 open-design-v0.26.1。下面是可直接执行的安装方式：

# 方式一：装进你正在用的 Agent（推荐）
od mcp install claude
# <agent> 可选：claude | codex | reasonix | raven | cursor | copilot | openclaw
#         | antigravity | pi | vibe | hermes | cline | kimi | kiro
#         | trae | opencode

# 方式二：托管安装脚本
curl -fsSL https://open-design.ai/install.sh | sh -s claude

# 方式三：Docker 自托管
git clone https://github.com/nexu-io/open-design.git
cd open-design/deploy
cp .env.example .env
echo "OD_API_TOKEN=$(openssl rand -hex 32)" >> .env
docker compose up -d
# 打开 http://127.0.0.1:7456
# 用户名 open-design，密码为上面写入 .env 的 OD_API_TOKEN

常见报错与处理：依赖缺失时先确认运行时版本（Node、Python、Rust、PHP 等）是否满足项目要求；网络超时多半是镜像或代理问题，可换源重试；权限类报错请检查当前账号是否已登录对应平台，以及脚本是否需要管理员权限执行。

六、使用示例

下面这段是可以直接参照的真实用法：

# 在 Agent 内直接下达设计任务
> Use open-design to generate a landing page with the Linear design system

# 装进 MCP 宿主后的典型调用形式
od mcp install cursor

# 以源码方式运行
git clone https://github.com/nexu-io/open-design.git
cd open-design
corepack enable

七、常见问题

问：装完 GUI 后 od 命令不生效？答：macOS 自带的 /usr/bin/od 是十六进制转储工具，会抢占命令名。此时在桌面应用的 Settings → MCP server 里复制对应客户端的配置片段即可，它用的是绝对路径，不依赖裸 od 命令。

问：WSL2 用户要注意什么？答：同样存在命令名冲突，官方建议先按仓库里的 WSL2 setup guide 处理。

问：可以自托管吗？答：可以，官方提供 Docker Compose 部署，并支持 Sealos 一键部署模板。

问：API 调用需要鉴权吗？答：Docker 部署默认用 OD_API_TOKEN 做 Basic Auth，API 客户端也可继续使用 Authorization: Bearer <OD_API_TOKEN>。

问：必须写 DESIGN.md 吗？答：不必须，但它是让产出贴合自家规范的关键，建议至少写一份基础规范。

问：能离线用吗？答：核心工作流在本地执行，模型调用仍需配置相应的 API 凭据。

以上是实际使用中最常被问到的几个问题。若遇到文档未覆盖的情况，可以先翻项目的 Issues 与 Discussions 区，那里有更多真实踩坑记录。

八、总结

Open-Design 在把复杂链路收进一个顺手的工作台这件事上做到了足够扎实的程度：它不追求大而全，而是把一个具体环节做透，让原本要靠人盯的流程变成可以交给工具执行的流程。

从上面的安装步骤和使用示例可以看出，它的接入成本并不高：一条命令装好，按提示完成配置，然后就能把它放进你原有的工作流里。如果你正在被同类问题困扰，不妨先在自己的一小块任务上试一轮，确认顺手了再推广到日常流程中。