Open Design：把设计工具做成 Agent 的文件系统
Anthropic 在 2026 年 4 月发布的 Claude Design，第一次让很多人看到 LLM 不只是写代码和文字——它也能直接产出设计 artifact。一整套交互页面、Pitch Deck、品牌视觉，用对话就能生成。
但 Claude Design 有显而易见的限制：闭源、付费、云端、只绑 Anthropic 的模型。
Open Design 就是冲着这些限制去的。它在 GitHub 上开源（Apache-2.0），上线不到两个月拿到 65k+ Star。这个速度说明一件事：很多人想要 Claude Design 的能力，但不想要它的锁。
但我拆完这个项目之后，觉得它真正有意思的地方，不是”做了一个开源版 Claude Design”。
而是它对”设计工具”这个概念本身的重新定义。
它没想做成 Figma
如果你只看表面功能——生成页面原型、制作幻灯片、输出品牌物料——Open Design 看起来和 v0、Lovable、Claude Design 差不太多，都是”用自然语言生成设计”的那类工具。
但架构层差得很远。
v0 和 Lovable 是 SaaS：你在它们的网页上操作，生成在它们的服务器上完成，结果渲染在 iframe 里给你看。Claude Design 是 Anthropic 的闭源产品，artifact 流在云端生成。
Open Design 走的是另一条路。
它的核心不是一个远程服务，而是一个本地 daemon（Express + SQLite），跑在你的机器上。这个 daemon 暴露一套 REST API 和一个 MCP stdio server。前端是 Next.js 16 的 Web UI，Electron shell 包成桌面应用。
但它最特殊的一层，藏在 API 后面。
Open Design 自己不调用任何 LLM。它把生成任务交给本地已有的 coding agent CLI——Claude Code、Codex、Cursor、Gemini CLI、Qwen、甚至 Hermes。daemon 负责编排 prompt stack、管理 skill 和 design system、调度 artifact 流，实际的生成引擎是那些 agent。
这个架构意味着几件事。
第一，你的 API key 只经过你自己的机器。BYOK（Bring Your Own Key）是硬要求，不是可选项。
第二，Open Design 不绑定任何模型。你换了 agent 就等于换了后端模型。今天用 Claude Code 做设计，明天换成 Gemini CLI，不需要改动工具本身。
第三，整个系统可以离线跑。设计系统和 skill 都是本地文件，没有云端依赖。
这些特性合在一起，指向一个跟 Figma 完全不同的方向。
关键设计：Skill 和 Design System 就是文件
Open Design 里最核心的两个抽象是 Skill 和 Design System。
Skill 是生成能力单元。每个 Skill 是一个文件夹，里面有一份 SKILL.md，用 od: 前缀的 frontmatter 声明能力描述、输入参数、输出类型。比如一个 “Landing Page” Skill，描述怎么写 Hero Section、怎么组织 CTA、怎么排版 feature grid。
Design System 是品牌规范。每个 Design System 也是一份 DESIGN.md 文件，9 个标准章节——颜色、字体、间距、动效、语气、反模式等。Linear、Stripe、Notion、Vercel、Apple 等 150 多套品牌都在里面。
关键在这里：这两样东西都是文件。
不是数据库里的记录，不是 SaaS 后台的配置项，就是文件。放在 skills/ 和 design-systems/ 目录下，重启 daemon 就能生效。
这意味着你可以：
- 读一个 Skill 的完整 prompt，理解它到底怎么工作
- 改几行 Markdown，就能调整生成结果的行为
- 把团队自己的 Design System 加进去，成为可选品牌
- 写一个新 Skill 文件夹，就扩展了一种生成能力
- 用 Git 管理所有这些东西
Claude Design 里那些封闭的、不可见的”设计能力”，在 Open Design 里变成了版本可控的文本文件。这个转换的工程意义，比”开源”本身要大。
因为一旦能力变成文件，它就可以被组合、被 review、被分支、被复用。设计流程变成了软件工程流程的一部分。
为什么用 Agent 当引擎
Open Design 不用自己的推理引擎，而是把生成外包给 coding agent CLI。这个选择看起来像偷懒，实际上有清晰的设计理由。
最直接的理由是：coding agent 已经很擅长生成代码了。
设计 artifact 说到底就是 HTML/CSS/JS。Claude Code 本来就能写这些。Open Design 不需要重新训练一个模型，也不需要自己维护推理基础设施。它只需要把 prompt 组织好，把上下文喂对，然后让 agent 干活。
更深一层的理由是：这保持了架构的开放性。
如果 Open Design 自己绑一个模型，那它就回到了 Claude Design 的老路——工具和模型耦合。但通过 MCP 协议连接本地的 agent CLI，它把模型层完全解耦了。用户想换就换，Open Design 不需要改代码。
还有一个不那么明显的好处：agent 生态本身在快速演进。
今天 Claude Code 写 artifact 的方式，和三个月前已经不一样了。Open Design 不需要追赶这个演进——它只需要保证 MCP 接口稳定，agent 的能力升级自动惠及所有 Skill。设计工具的进步速度，不再受限于工具本身，而是跟着整个 agent 生态走。
代价和边界
这套架构不全是好处。
最大的代价是：依赖本地的 agent CLI 环境。你的机器上得有 Claude Code 或 Codex 或至少一个支持的 agent，而且得配好 API key。这对个人开发者来说不是问题，但在团队协作场景里，每个人的环境不一致时会很难排查。
其次是 artifact 质量的决定因素变了。Open Design 只负责 prompt stack 和 design system，最终生成的质量取决于底层 agent 的能力和模型选择。同一个 Skill 在不同 agent 上跑出不同结果，这件事在架构上是预期的，但对用户来说意味着”不可预测”。
还有一个现实问题：桌面端目前只有 macOS 和 Windows 的原生支持，Linux 是 AppImage。而且这些桌面应用本质上是 Electron 包了一个 Web UI 加 daemon sidecar，启动后浏览器体验可能比桌面应用本身更好——我试下来确实如此，直接用浏览器访问 daemon 端口反而更流畅。
可以复用的是什么
Open Design 最有借鉴价值的做法，我列三个。
用文件系统做能力层。 Skill 和 Design System 以文件形式存在，让 Git 成为天然的版本管理工具。这个模式不只适用于设计工具——任何需要不断迭代”能力集合”的系统（测试用例、监控规则、业务流程），都可以用类似思路降低管理成本。
用 MCP 解耦模型。 Open Design 自己不调用 LLM，通过 MCP 把生成外包给本地 agent。这层解耦让工具的生命周期和模型的生命周期分开了。模型换得再快，工具不需要跟着变。如果你在构建 agent 工具链，这层解耦应该学。
把 prompt 组织成可组合的模块。 Open Design 的 Skill 不是一段 prompt，而是一套结构化 prompt stack：先发发现问卷锁方向，再看视觉方向偏好，再设定 todo list 跟踪进度，再生成 artifact。这种分层让复杂的生成任务可管理、可调试。写单段 prompt 的”一次性打法”和这个不是一个量级。
说到底，Open Design 验证了一个判断：设计工具的未来，可能不是一个更大的 Figma，而是一个更开放的文件系统。能力是文件，规范是文件，流程是文件。agent 读这些文件，产出 artifact，团队用 Git 管理一切。
这个方向是不是最终答案，还不好说。但至少它指明了一条和现有工具完全不同的路。而 65k Star 说明，想看这条路走下去的人，不在少数。