Open Design 开源解读：把 Claude Design 做成本地优先的 Agent 工作台

大家好，我是若风。

昨天刚拆完 Huashu Design，今天又看到一个更猛的项目：nexu-io/open-design。

说实话，第一眼我有点警觉，也有点兴奋。警觉是因为它的标题很大：开源版 Claude Design，local-first，BYOK，支持 Claude Code、Codex、Cursor Agent、Gemini CLI、OpenCode、Qwen、Copilot、Hermes、Kimi 等一堆 coding-agent CLI，还内置 Skills、Design Systems、沙盒预览和 HTML / PDF / PPTX / MP4 导出。兴奋是因为，如果这件事真能跑顺，AI 设计就不再只是云端产品里的一个按钮，而会变成开发者本地工作流的一部分。

这类项目如果只是把几个热词堆在一起，通常很容易变成“看起来很未来，跑起来很尴尬”。这个状态挺让人焦虑的，因为你明明看到了一个方向，但实际落地时又会被环境、权限、导出、文件管理这些小事拖崩。

但我把 README 和目录结构认真看了一遍，感觉它值得单独写一篇。

Open Design 真正有意思的地方，不在“Claude Design alternative”这个标签上，而在它背后那个很清晰的工程判断：AI 设计产品不一定要把模型、画布、运行时都锁在云端。它可以变成一个本地 daemon，把你电脑上已有的 Agent CLI、设计系统文件、技能文件和导出脚本串起来。

表面上看，它是在做一个“会画图的聊天框”；真正关键的是，它把 AI 设计拆成了一个能被本地文件、Agent CLI 和设计系统共同约束的工程循环。

截至 2026 年 5 月 25 日我打开 GitHub 时，这个仓库页面显示大约 51k Star、5.8k Fork，许可证是 Apache-2.0。README 里也写得很直接：0.8.0-preview 是下一阶段，项目还在快速迭代中。

这篇文章不写安装教程。

我更想回答一个问题：Open Design 到底解决了什么？它和 Huashu Design、Claude Design、普通 AI 画图工具的区别在哪里？

先说结论

Open Design 的核心价值，不在于“开源一个设计生成器”，而在于把 AI 设计工作流拆成了 6 个可替换的工程层。

所以它不是一个“AI 生成海报”的小工具。更准确地说，Open Design 是一个把本地 coding agent 变成设计师的中间层：它不拥有模型，也不假装自己是万能设计师，它做的是另一件事，把用户需求、设计系统、技能约束、文件系统、沙盒预览、导出格式和本机 Agent CLI 串成一个循环。

一句话概括：

Huashu Design 更像一套设计 Skill，Open Design 更像把这套 Skill 产品化成本地设计工作台。

这个差异很关键。Huashu Design 的重点是“怎么让 Agent 做设计时更像一个专业设计师”；Open Design 的重点是“怎么把这套设计 Agent 工作流变成一个可运行、可持久化、可自托管、可导出的产品系统”。

它为什么会出现

README 里写了一个很明确的背景：Anthropic 的 Claude Design 展示了 LLM 不只写文字，也可以直接交付设计 artifact。但它是闭源、付费、云端、绑定 Anthropic 模型和技能体系的。

Open Design 的反应是：同样的 artifact-first 心智模型，能不能做成开放版本？

这个问题很有现实感。因为 AI 设计一旦进入真实工作，就会遇到 4 个很硬的问题。

第一，模型锁定。 今天你想用 Claude，明天想用 Codex，后天团队又换成 Gemini 或本地模型。设计系统如果绑死在一个模型产品里，迁移成本会越来越高。

第二，文件不可控。 很多云端设计生成工具看起来很顺，但产物到底在哪、怎么版本管理、怎么二次加工，经常不够透明。

第三，上下文不能复用。 品牌规范、设计系统、项目文件、导出记录，如果只存在一次对话里，就很难变成团队资产。

第四，交付格式不够工程化。 只给一张图还不够。真实工作需要 HTML、PDF、PPTX、ZIP、Markdown，甚至视频和可继续编辑的文件。

Open Design 试图把这些东西都拉回本地工程系统里。它的 README 里有一句话很能说明野心：它不 ship 一个 agent，因为最强的 coding agents 已经在你的电脑上。Open Design 做的是把它们接进 skill-driven design workflow。

这句话背后，其实是一种产品哲学：

不要重新发明 Agent，把 Agent 变成可调度的设计引擎。

第一层：浏览器不是全部，本地 daemon 才是关键

Open Design 的架构图很清楚：上面是浏览器里的 Next.js 16 应用，负责 chat、file workspace、iframe preview、settings 和 import；下面是本地 daemon，负责 /api/agents、/api/skills、/api/design-systems、/api/projects、/api/chat、artifact 保存、lint、upload，以及 /artifacts、/frames 这些静态资源服务。

也就是说，浏览器只是操作台。真正有权限碰文件、开进程、调 Agent CLI、写 SQLite、保存 artifact 的，是本地 daemon。这个设计挺聪明。

如果把所有能力塞进浏览器，你会被浏览器沙盒限制住：不能随便扫 PATH，不能 spawn CLI，不能稳定写本地项目目录，也不能把 agent 的 cwd 设到某个 artifact folder。如果完全做成命令行，又会丢掉设计工作最需要的东西：实时预览、文件面板、导出按钮、交互表单、iframe 沙盒。

Open Design 选了一个折中方案：

浏览器管体验，本地 daemon 管权限。

项目第一次运行时会创建 .od/ 目录，里面有 app.sqlite、artifacts/ 和 projects/<id>/。README 里特别提醒，这个目录是本机 runtime folder，应该 gitignore，不要提交。

这不是一个小细节。它意味着 Open Design 把“设计生成”从一次性对话，变成了一个本地项目生命周期：项目、会话、消息、tab、导出文件都能持久化。今天没做完，明天再打开，Agent 的 Todo 卡片还在。这就开始有工作台的味道了。

第二层：它不做模型，而是扫描你的 Agent CLI

Open Design 最特别的一点，是它把已有 coding-agent CLI 当作设计引擎。README 里列了很多：Claude Code、Codex CLI、Devin for Terminal、Cursor Agent、Gemini CLI、OpenCode、Qwen Code、Qoder CLI、GitHub Copilot CLI、Hermes、Kimi、Pi、Kiro、Kilo、Mistral Vibe、DeepSeek TUI 等。daemon 启动时会扫描 PATH，发现哪些 CLI 可用，就把它们放进模型选择器里。

这条路线和传统 AI 设计产品很不一样。

传统产品通常是：我有一个云端模型，你在我的 UI 里输入需求，我返回结果。

Open Design 是：你本机已经有 Agent，我给它 skill、design system、工作目录和预览环境，让它像设计师一样干活。

这带来一个明显好处：执行能力复用。 Codex 擅长改代码，Claude Code 擅长长上下文和工具调用，Gemini CLI 可能在某些多模态场景里更适合。Open Design 不需要押注某一个 Agent，它把不同 CLI 包成 adapter，用 SSE 把事件流回 UI。

当然，这也带来成本。本机 CLI 的行为、权限、输出协议、稳定性都不一样。README 的架构部分也能看到，它要维护一堆 typed-event parser：Claude Code、Qoder、Copilot、Codex / Gemini / OpenCode / Cursor Agent、ACP 协议、Pi RPC、plain 模式等等。

所以 Open Design 的复杂度，不在“画一个界面”。它的复杂度在于：把一堆不同 Agent 的输出，归一成同一个设计工作流。

这件事如果做成了，会很有价值；做不好，也会是后续最容易出 bug 的地方。

第三层：Skills 是文件，不是插件市场

Open Design 的另一个重要判断是：Skills are files, not plugins。

它沿用了 Claude Code 的 SKILL.md 约定：每个 skill 可以由 SKILL.md、assets/、references/ 组成。你把一个 skill 文件夹放进 skills/，重启 daemon，它就出现在 picker 里。

这个设计很朴素，但很有力量。插件市场常常有一个问题：看起来繁荣，但真正能被团队维护、审计、版本管理的东西不多。Skill 作为文件夹，就直接进入工程世界：可以 diff，可以 review，可以 fork，可以把设计纪律写成 Markdown，把模板放进 assets，把任务知识放进 references。

Open Design README 也坦诚写了它站在几个开源项目肩膀上：

• alchaincyf/huashu-design：设计哲学、Junior Designer workflow、品牌资产协议、anti-AI-slop 检查、5 维自我评审、5 学派 × 20 设计哲学。
• op7418/guizang-ppt-skill：deck mode，尤其是杂志风布局、WebGL hero、P0/P1/P2 检查表。
• OpenCoworkAI/open-codesign：streaming artifact loop、sandboxed iframe preview、live agent panel、五格式导出。
• multica-ai/multica：daemon 和 runtime 架构，PATH scan、local daemon、agent-as-teammate 世界观。

这段我挺喜欢，甚至有点释然。因为它没有把自己包装成“从天而降的原创神器”，而是承认自己是在几个开源思路上继续组合、产品化、工程化。

开源项目最怕的不是借鉴，最怕的是借鉴了不承认，最后社区也不知道脉络在哪里。

第四层：Design Systems 用 Markdown，而不是 theme JSON

Open Design 把设计系统也做成了文件。

README 里说它使用来自 awesome-design-md 的 9-section DESIGN.md schema：color、typography、spacing、layout、components、motion、voice、brand、anti-patterns。每个 artifact 都读取当前 active system，切换 system 后，下一次渲染使用新的 tokens。

这个点非常重要。很多 AI 生成设计的卡点，不在“不会排版”，而在“每次都像不同公司做的”。

第一次像 Linear，第二次像 Stripe，第三次像一个紫色渐变 SaaS 模板。你让它“保持品牌一致”，它嘴上答应，下一轮又飘了。

Design System 文件化之后，事情就变了。Agent 不再靠模糊记忆理解品牌，而是读取一份明确的 DESIGN.md。里面写颜色、字号、间距、组件、语气、品牌和反模式。也就是说，品牌风格从“感觉”变成了“输入文件”。

这也是 Open Design 和普通 AI 生图工具的分水岭。

AI 生图工具更像一次性创作。

Open Design 更像在建立一条可复用的设计生产线。

README 里列了很多内置设计系统：Linear、Stripe、Vercel、Airbnb、Tesla、Notion、Apple、Anthropic、Cursor、Supabase、Figma、小红书等。不同区块里的数量还在变化，有的地方写 129，有的地方写首启加载 150；这也从侧面说明项目 main 分支正在高速移动。

我的理解是，不要把这些数字当成最终稳定 API。

更应该看它背后的方向：设计风格的入口可能是一句 prompt，但真正沉淀下来的是一组可被 Agent 读取和复用的文件。

第五层：question form 防止 80% 的返工

我读 README 时，最认同的一段是 interactive question form。Open Design 的 prompt stack 硬编码了一个 RULE 1：每个新的设计 brief，第一步不急着写代码，而是先弹出 <question-form id="discovery">。它会问 surface、audience、tone、brand context、scale、constraints。

这听起来有点慢。

但做过设计协作的人都知道，这一步其实是在省时间。设计返工最贵的地方，往往不在某个按钮圆角错了，而在方向一开始就偏了。

你想要的是投资人 pitch deck，Agent 做成了产品官网。

你想要克制、冷静、B2B，Agent 做成了赛博霓虹。

你想要移动端 onboarding，Agent 先给你来一个 full-screen hero。

这些问题如果在 30 秒的 question form 里问清楚，成本很低。如果等 Agent 做完一整套 artifact 再改，成本就高了。Open Design 在这里继承了 Huashu Design 的 Junior Designer 思路：先批量问问题，早一点给可见结果，让用户低成本纠偏。

这其实是 AI Agent 产品里一个非常通用的原则：

模糊需求不要急着执行，先把分叉点摊开。

不然 Agent 越能干，返工越快。

第六层：prompt stack 才是真正的产品

Open Design README 里有一句很直白的话：The prompt stack is the product。

它把发送时组合的上下文拆成几层：

• discovery directives：首轮表单、品牌分支、TodoWrite、5 维评审；
• identity charter：官方设计师 prompt、anti-AI-slop、junior-pass；
• active DESIGN.md；
• active SKILL.md；
• project metadata：kind、fidelity、speaker notes、animations、inspiration ids；
• skill side files：自动注入 pre-flight 要读的 template 和 references；
• deck framework directive：导航、计数器、滚动、打印等规则。

这段非常像现代 Agent 应用的核心。它没有把一个巨大的 system prompt 塞给模型，也没有把所有能力写死在后端代码里；它做的是在每次请求时，把当前任务需要的设计纪律、品牌系统、技能文件、项目状态和输出约束组合起来。

这比单纯“调一个模型 API”复杂很多，但也更接近真实的专业工作。一个设计师做项目时，也不是只靠脑子里的通用审美。他会看品牌手册、看过往作品、看本次需求、看目标用户、看导出规格、看评审意见。Open Design 只是把这些上下文变成了文件和 prompt stack。

这也是我觉得它最值得关注的地方。

它真正卖点不在某个神奇 prompt，而在一个可组合的上下文系统。

和 Huashu Design 的关系

如果你刚看过 Huashu Design，很容易问：那 Open Design 是不是就是 Huashu Design 加了个 UI？

不完全是。Huashu Design 更像一套高质量设计 Skill：它定义 Agent 做设计时应该如何验证事实、搜集资产、选择风格、做动画、做幻灯片、导出视频和自我评审。Open Design 则把这件事往产品系统方向推进：

所以二者不是替代关系。更像上下游关系：Huashu Design 提供设计工作法，Open Design 把工作法接进本地应用、daemon、文件系统和 UI。

和 Claude Design 的差别

Open Design 的名字里一直在对标 Claude Design，但它的路线其实完全不同。

Claude Design 是云端产品路线：模型、画布、设计能力都在 Anthropic 的产品里，用户体验更一体化，门槛低，视觉交互可能也更顺。

Open Design 是开放工作流路线：你自己带 key，自己选 Agent，自己跑 daemon，项目文件在本地，skills 和 design systems 都是可编辑文件。

这两条路线没有绝对优劣。如果你只想快速做一个视觉稿，云端一体化产品可能更省心；如果你在意自托管、本地文件、模型可替换、团队可审计、技能可维护，那 Open Design 这种路线会更有吸引力。

它牺牲的是一部分“开箱即用的顺滑感”。

换来的是控制权。

适合什么场景

我会把 Open Design 放在这几类场景里优先考虑。

第一，AI 设计工作流实验。 如果你想研究 coding agent 如何从需求、设计系统、skill、文件系统、预览、导出串成闭环，Open Design 是一个很好的样本。

第二，团队内部原型工作台。 比如产品经理、设计工程师、前端工程师一起做 landing page、dashboard、mobile flow、pitch deck，它比单纯在聊天窗口里生成 HTML 更适合沉淀项目。

第三，多 Agent 对比。 因为它支持扫描本机多个 CLI，同一个设计 brief 可以切不同 Agent 跑，观察产物差异。这对团队选型很有用。

第四，品牌化 artifact 生产。 当 DESIGN.md 和 skill 稳定后，团队可以让 Agent 在同一套品牌约束下持续生成不同类型的产物，而不是每次重新解释“我们是谁”。

第五，可导出的设计交付。 如果你不只要一张图，而是要 HTML、PDF、PPTX、ZIP、Markdown 或视频，Open Design 的导出链路会比普通生成工具更贴近实际工作。

不适合什么场景

当然，它也不是万能解。

第一，它不适合只想“一键出图”的人。 Open Design 的核心不在极简按钮，而在本地 runtime、Agent、Skill、Design System 和项目文件。你要接受一点工程复杂度。

第二，它不适合完全不想碰本地环境的团队。 虽然它有 Web UI，但 daemon、CLI、.od/、PATH 扫描这些概念，本质上还是开发者友好的。

第三，它不适合追求稳定 API 的生产依赖。 README 已经明确说 main 在快速迭代，0.8.0-preview 是下一阶段。这个阶段更适合试用、研究、二次开发，不适合把关键业务流程立刻压上去。

第四，它不替代专业设计工具的精修环节。 如果你需要像 Figma 那样精细调图层、组件库、协作评论、设计交接，Open Design 更像前面的生成和探索层，而不是完整替代。

我最喜欢的 3 个设计判断

第一，它把 Agent 当执行器，而不是把模型当产品本体。

这让 Open Design 有机会跟着 Agent 生态一起进化。只要 adapter 跟得上，Claude、Codex、Gemini、OpenCode 都可以成为设计引擎。

第二，它把设计系统文件化。

DESIGN.md 这条路很对。品牌风格如果不能被版本管理，就很难被团队稳定复用。

第三，它把“问清楚”写进流程。

question form 看似不酷，但非常专业。AI 设计最大的浪费，往往不在生成慢，而在方向错。先问清楚，比事后返工更像一个靠谱设计师。

我最担心的 3 个问题

第一，adapter 维护成本。

支持很多 CLI 是卖点，也是负担。每个 CLI 的输出格式、权限模型、错误处理都可能变，长期维护不轻松。

第二，安全边界。

本地 daemon 能 spawn CLI、读写文件、接 API proxy，这天然需要非常清楚的权限边界。README 里已经提到对非 loopback 私有地址、link-local、CGNAT、multicast、reserved 和 redirect target 做 SSRF 阻断，这是好信号，但这类系统后续仍然要持续做安全审计。

第三，体验一致性。

当底层 Agent 不同，输出质量和工具行为可能差很多。Open Design 需要在 prompt stack、skill pre-flight、artifact lint、iframe preview 这些层面继续兜底，否则用户会把 Agent 的不稳定误认为产品不稳定。

最后的判断

写在最后

Open Design 这个项目最有价值的地方，不是它喊出了“开源 Claude Design 替代品”。

这个 slogan 当然有传播力，但真正值得看的是它背后的工程路线：

用本地 daemon 连接浏览器体验和文件系统，用 coding-agent CLI 复用现有执行能力，用 Skills 和 Design Systems 管住输出风格，用沙盒预览和导出链路把 artifact 变成交付物。

这条路线比“再做一个 AI 生成设计稿的网站”更难，也更有想象力。因为它把 AI 设计从一个云端黑盒，往本地、开放、可组合、可审计的方向拉了一步。

如果说 Huashu Design 让我看到“设计能力可以被写成 Skill”，那 Open Design 让我看到下一步：

设计 Skill 可以被组织成一个本地优先的 Agent 工作台。

这可能才是它真正值得关注的地方。