设计稿和可运行产物之间，一直隔着一层。Figma 时代的「设计交付」是这样跑的：设计师在画布上摆好像素稿，标注间距、色值、字号，开发者再手工翻译成 CSS 和组件。稿子越精细，翻译损耗越大--标注的 8px 间距开发者取个整就成了 10px，组件命名设计师叫「Card--hero」开发者写成 HeroCard，响应式断点设计稿里画了三档落到代码里常常只剩一档。一份精细的 Figma 稿，落到代码里常常只剩个「差不多」。这道翻译不只是损耗，还是成本--设计师和开发者来回对齐、标注、返工，往往吃掉一个迭代里可观的时间，而这部分时间在 agent 时代本可以被自动化掉。
到了 vibe-coding 时代，这层断层换了种形态，但没消失。编码 agent 能直接吐代码，甚至吐一整页落地页，但你让它「按我们品牌来」，它要么套个 Tailwind 默认模板，要么自由发挥出一套花花绿绿。设计审美和品牌一致性，agent 拿不到--因为它读不到你的设计系统，也不在你的工作流里。更麻烦的是一致性问题：同一个 agent 今天产出的落地页和明天产出的 deck，色值字体间距可能各跑各的，因为每次生成都是一次独立的「自由发挥」，没有一个品牌契约约束它。
这一层断层，正是 open-design 想填的。它不是又一个「生成 UI」的工具，而是把 Claude Design 那套 agent-native 设计循环开源化、文件系统化，让你笔记本上已经装好的编码 agent 直接变成设计引擎，产出受团队 DESIGN.md 约束的单页可运行产物。
它是什么
open-design（github.com/nexu-io/open-design，官网 open-design.ai）是一个本地优先的原生桌面应用，macOS 和 Windows 都支持。GitHub 星 84003，fork 9765，watchers 84007，open issues 769，主语言 TypeScript，Apache-2.0 许可证，仓库创建于 2026 年 4 月 28 日，最近一次 push 就在今天（2026 年 8 月 6 日）。最新 release 是 v0.18.0，8 月 5 日发布，主题 "Design Team Workspace. Now in Codex"；8 月头几天里连发 0.16.1（7 月 23 日）、0.17.0（8 月 3 日）、0.18.0（8 月 5 日）三个版本，迭代节奏极快。
一句话定位：开源的 Claude Design 替代，也是 agent 时代的 Figma 替代。Claude Design 是 Anthropic 那套闭源的设计 agent--你给它 brief，它走一个 agent-native 的循环（discover brief -> lock direction -> stream artifact -> critique -> deliver）产出设计，但循环跑在它的云上，brief 和品牌资产都得交出去。open-design 把这个循环从闭源 SaaS，变成了一组放在文件系统里的东西--skills、渲染设计模板、DESIGN.md 设计系统、plugins--让你笔记本上已有的编码 agent 读写、remix。
这个「文件系统化」是关键。循环跑在你本地，产物落在你的文件系统里，意味着整套资产可以 git、可以 diff、可以协作 review、可以 version control--这是闭源 SaaS 给不了的。结果是：CLI 成了设计引擎，笔记本成了工作室，团队的 DESIGN.md 成了品牌契约，每个产出都被它约束。
README 有简体中文版，topics 标了 agent-skills / ai-agents / ai-design / byok / claude-design / figma-alternative / design-systems / local-first / prototyping / ui-generator / vibe-coding，定位非常明确--就是冲着「agent 时代的设计工具」这个位置来的。
核心能力
open-design 的核心机制是「把设计循环变成文件系统」。Claude Design 的循环是五步：发现 brief（搞清楚你要什么，把模糊需求拆成可执行的设计意图）、锁定方向（定调子、信息架构和视觉结构，避免后面边做边跑偏）、流式产出产物（边生成边在沙箱里预览，你能实时看到成形过程而不是等一个黑盒结果）、自我 critique（agent 拿设计系统和自己产出的产物对一遍，发现不一致就修）、交付（导出成 HTML / PPTX / MP4 这些可运行格式）。这是个 loop 不是 one-shot--critique 那一步会回头改，deliver 也能基于反馈重跑，整个过程模仿的是人类设计师「初稿-自审-改稿」的工作方式，而不是一次性吐个结果就走。open-design 把这五步拆成可被任意 coding agent 调用的 skills 和模板，agent 在你本地跑完整个循环，产物落在你的文件系统里，不是黑盒云服务。这意味着你既能看到中间状态、手动干预，也能把整套资产 version control 起来，团队协作时还能 review 每一步的 diff。
它跑起来后是五个核心页面，分工覆盖了从入口到自动化的全链路：
| 页面 | 作用 |
|---|---|
| Home | 入口，选 skill、选设计系统、输入 brief，开干 |
| Automation | 把重复的设计工作流编排成可调度的自动化 |
| Design System | 把团队的 DESIGN.md 蒸馏成品牌契约，约束每个产出 |
| Plugin | 浏览、安装、分发工作流插件 |
| Integrations | 接外部系统和 MCP，从任意 IDE、脚本、自动化调用 |
其中 Design System 是品牌一致性的根基：你把团队的 DESIGN.md--品牌色、字体、间距、组件规范--放进去，它被蒸馏成一份契约，之后 Studio 里每一个产出（不管是 Prototype 还是 Deck）都受它约束。这就是它解决「agent 自由发挥导致不一致」的方式：不是靠 prompt 提醒，而是靠一份可读可改的设计系统文件硬约束。prompt 提醒是不可靠的--agent 这次听了下次可能忘；文件约束才是结构性的，每次产出都强制读一遍 DESIGN.md，色值、字体、间距跑不出契约画的范围。Automation 页面则是给重复场景准备的--比如每周都要出一份运营 banner，可以编排成可调度的自动化，不用每次重新写 brief。
Studio 里能产出的东西有四类，覆盖了大多数「设计交付物」的形态：
| 产物 | 形态 |
|---|---|
| Prototype | 单页 HTML，读设计系统，沙箱 iframe 即时预览，可下载源码 |
| HyperFrame | 程序化动效动画，能渲成真 MP4（如 1920×1080·30fps） |
| Deck | pitch deck，键盘翻页，导出 PPTX / PDF |
| Image | 品牌级图片，高分辨率生成下载 |
这四类产物的共同点是：它们都是可运行的、可导出的、受 DESIGN.md 约束的。Prototype 产出的是真 HTML 源码，不是图片稿，开发者拿到就能跑，不存在「翻译」这一步；HyperFrame 渲出来的是真 MP4 不是 GIF，1920×1080·30fps 能直接用于正式场合；Deck 能导出 PPTX，不用再在 PowerPoint 里重排一遍。除了这四类 Studio 产物，README 里还列出 web / desktop / mobile 原型、live dashboards / artifacts、images、video 等更广义的产物类型；预览统一走沙箱 iframe，导出走 HTML / PDF / PPTX / MP4。从一页落地页到一份 pitch deck 到一段动效 promo，它都想包。
真正让它区别于「又一个 UI 生成器」的，是 agent 兼容面的宽度。它支持 25+ 个 coding agent：Claude Code、OpenClaw、Codex、Cursor、OpenCode、Qwen、Copilot、Amp、Hermes、Kimi、Antigravity 等都在列，再加任意 OpenAI-compatible endpoint（BYOK）。这一点意义重大：你不用为了用 open-design 换一个新 agent，已经在用的 Claude Code / Cursor / Codex 直接接上就行，现有工作流、现有配置、现有模型投入都不动。接 MCP server 是一条命令的事：
od mcp install <agent> # 比如 od mcp install claude-code这条命令把 open-design 的 MCP server 接到你指定 agent 的配置里，之后那个 agent 就能调用 open-design 的 skills、读写 DESIGN.md、产出和预览设计产物。open-design 是「加」上去的，不是「换」--这是它和那些「自带 agent 的闭源设计工具」最大的不同。
怎么装怎么用
README 给了 QUICKSTART 三条命令起手（具体命令以仓库 QUICKSTART 为准，下面是典型形态）：
# 1. 装桌面应用 / CLI（macOS + Windows，详见仓库 QUICKSTART）
# 2. 给你的 coding agent 接上 MCP server
od mcp install <agent>
# 3. 在 Home 页选 skill + 设计系统，输入 brief，开跑一个典型流程是这样的：在 Home 页选一个 skill（比如「做落地页」），选你团队的 DESIGN.md 作为设计系统，输入 brief（产品是什么、要突出什么、目标用户是谁），开跑。agent 在你本地走 discover -> lock -> stream -> critique -> deliver 的循环--先理解 brief，锁定方向和结构，流式产出 HTML 产物，自我 critique 一遍，交付。产物落在本地文件系统，沙箱 iframe 里即时预览，不满意可以干预重跑，满意了导出 HTML / PDF / PPTX / MP4。整个过程在本机完成，设计稿和产物之间不再有「翻译」这一步--产物本身就是可运行的 HTML / PPTX / MP4。
模型怎么选，有两条路：
- Open Design Cloud：官方模型服务，一次充值就能用 GPT、Claude、Gemini、DeepSeek 等 20+ 旗舰模型，零配置，按真实 token 用量计费。不想折腾 API key、不想在多个模型平台之间切来切去的人走这条。
- BYOK（Bring Your Own Key）：自带任意 OpenAI-compatible endpoint 的 key，用自己的额度，走自己的账单。已经在某个模型上充了值、或者要走私有化部署、或者对数据出境有合规要求的团队走这条。
两条路都通同一个设计循环，区别只是模型从哪来、账单谁出。这点对已经在某个模型上有投入的团队很关键--不用为了用 open-design 重新充值，已有的模型订阅直接复用。
坑
把它当生产工具前，有几个点先认清：
- 本地优先桌面应用，得装运行时环境。它是原生桌面应用不是纯网页，macOS 和 Windows 都要装本地运行时。无头服务器 / Linux CI 上跑要绕一下，CI 里批量生成设计产物这种场景不如云端 SaaS 顺手；跟所有本地优先工具一样，远程协作场景得想清楚文件和 DESIGN.md 怎么同步，别指望像 Figma 那样开个链接就能多人实时协同。解法是用 git 管理 DESIGN.md 和产物，团队走分支 + PR 的协作模型，跟代码协作一个套路，设计师和开发者 review 同一份 diff。
- BYOK 还是 Open Design Cloud，先想清楚。Cloud 零配置、按真实 token 计费，适合不想管 key 的人；BYOK 走自己的 endpoint 和额度，适合已有模型投入或要私有化的团队。两条路不能混着用同一个产出的计费逻辑，开工前定好，免得后面算不清账--尤其是团队场景，有人用 Cloud 有人用 BYOK，产出的成本归属会糊。建议团队统一一种模式，或在 DESIGN.md 旁边记一笔成本归属规则。
- Apache-2.0 商用友好，但 Cloud 服务是闭源计费的。开源的是桌面应用、skills、CLI、MCP server 这些本地部分，Apache-2.0 商用友好，你可以拿来二次开发、内嵌进自己的产品；但 Open Design Cloud 的模型服务本身是闭源、按用量收费的。商用集成前把这层分清，别把「开源 = 全免费用」想当然--本地引擎免费，云上模型收费，这是它的商业模式。要完全自主、数据不出门，就走 BYOK + 自部署模型。
- v0.18 是早期版本，迭代极快。8 月头几天连发 0.16.1、0.17.0、0.18.0，README 和 CLI 参数可能版本间有变动。本文所有命令、能力描述基于 2026-08-06 核实的 v0.18.0，遇到对不上的以官网和仓库 README 为准。生产环境用要跟紧 release note，别把今天的命令当成下个月还能跑的稳定 API--0.1x 阶段 breaking change 是常态，建议把 open-design 版本钉死，升级前先在测试环境过一遍。
- 25+ agent，各家 MCP 配置有差异。
od mcp install <agent>是一键脚本，但每个 agent 的 MCP 配置文件位置、字段名、权限模型都不一样--Claude Code 的配置在.claude，Codex 在.codex，Cursor 又是另一套。README 列了支持列表，具体某个 agent 的接法还是得查对应 host 的文档，别指望一条命令在所有 host 上都零配置跑通。建议先在主流 agent（Claude Code / Codex / Cursor）上跑通，再往小众的迁，遇到对不上的优先查 host 的 MCP 文档而不是 open-design 的文档。
看法
open-design 命中的是 agent 时代设计交付的真断层，而且时间点卡得准--编码 agent 刚普及到「人人的笔记本上都有一个」的程度，设计交付从「画图工具」往「agent 产物」迁移的窗口正好打开。Figma 解决了「画」的问题，没解决「设计系统直接驱动可运行产物」的问题--它的产物是像素稿，到代码还有一道手工翻译；Claude Design 解决了这个问题，但是闭源 SaaS，你得把 brief 和品牌资产都交给它，循环跑在它的云上，你看不到也控不了中间状态；v0、Lovable 这类 UI 生成器能生成界面，但它们是「生成」导向不是「设计系统约束」导向，多次产出之间的一致性没有契约保证。open-design 的护城河不是 UI 生成质量本身，而是把 Claude Design 那套 agent-native 设计循环开源化、文件系统化，复用用户已经装好的 25+ 个 coding agent，再用 DESIGN.md 当品牌契约保证一致性。8.4 万星、8 月还在连发版本，说明这个定位踩准了一波人--那些已经在用编码 agent、但卡在「设计审美和品牌一致性」上的开发者和小团队。
它适合两类人：一是已经在用 Claude Code / Codex / Cursor 这类编码 agent、想把设计交付也搬进 agent 工作流的开发者；二是需要一套设计系统约束、但又不想锁死在 Figma + 手工翻译流程里的小团队。门槛是你得接受本地优先桌面应用的运行时依赖，并在 BYOK 和 Cloud 之间做个选择。风险点是它还在 0.1x 阶段、迭代极快，能力可能版本间变动，生产环境用要跟紧 release note。但方向--设计系统直接驱动可运行产物、agent loop 开源化、复用而非替换已有 coding agent--是对的。
参考来源
- open-design GitHub 仓库：https://github.com/nexu-io/open-design
- open-design 官网：https://open-design.ai
- 最新 release v0.18.0（2026-08-05，"Design Team Workspace. Now in Codex"）：见仓库 Releases 页
- 星数 / fork / watchers / open issues / 语言 / 许可证等数据依据 GitHub API（2026-08-06 核实，84003 stars）
- 支持 agent 列表、产物类型、核心页面、Open Design Cloud 等依据仓库 README（2026-08-06 核实）