我们为什么把 Open Design 做成 skill 层，而不是一款产品

此刻你笔记本上最强的 coding agent，无非是 Claude、Codex、Cursor、Gemini、OpenCode 或 Qwen。我们不认为你还需要再来一个。真正缺的不是原始智能——而是品味、结构，以及一套把设计当作手艺来尊重的工作流。

Open Design 就是我们对那一缺失层的尝试。它不是一款聊天产品，也不是一款「底层用了 AI」的设计工具。它是一层薄薄的 skill 层——一个装满 SKILL.md 文件的文件夹、一座可移植的设计系统库，以及一个 daemon：它会自动检测你已有的 CLI agent，并把它们串联起来。

这篇文章会解释我们为什么这么选，它对你使用 Open Design 的方式意味着什么，以及为什么「做层，而不是做产品」是一场押注于长久、而非走捷径的赌局。

做成产品会是错误的形态

2026 年启动一个 AI 设计项目时，本能反应是去做一款新 app：一个聊天界面、一块画布、一套计费系统，外加一笔随用户数线性增长的模型账单。这条路我们考虑过，又因为三个原因否决了它。

聊天界面是一种大路货

每个用户都已经有了一个能干的 agent 和一个他们信任的聊天框。再塞给他们一个更差的——裹着我们的品牌、又少了他们已经练成的肌肉记忆——对谁都没好处。价值不在界面上。价值在你按下回车之后那个 agent 做了什么：它产出的，是一份看起来经过设计的演示稿，还是一面堆满 div 的墙。

模型账单是对创造力征的税

把推理捆进产品，经济账就会逼着你出手。你不得不给 token 加价、给长会话限速、对最新模型的访问配额化，好让你的利润率活下去。而这每一步动作，恰恰惩罚了一款设计工具本应奖励的那些行为：迭代、探索，以及因为第三稿才是出活的地方而再跑一遍 agent。

锁定是错误的默认值

设计师应该能带着自己的文件、系统和 skill 完整地离开。一款产品会把一切裹进专有状态——导出来，你拿到的只是真实之物被压平后的影子。一层 skill 层没什么可裹的，因为产物就是那些文件。离开毫无成本，而这恰恰是留下来才有分量的原因。

所以我们改去做那一层。放进一个文件夹，重启 daemon，skill 就出现了。带着这个文件夹走，把它放进另一个 agent，skill 在那里照样能用。

一个 skill 到底是什么

在 Open Design 里，一个 skill 就是一个 SKILL.md 文件，外加同一文件夹里可选的配套资源。这个 Markdown 文件描述：

• 这个 skill 做什么——一段话，用大白话讲清
• 什么时候调用它——触发条件，写得让 agent 能正确路由
• 输出的形态——HTML、PDF、幻灯片，或一份 Markdown 简报
• 约束——用 OKLch 表示的配色、字体栈、版式姿态、品牌词汇

agent 读这个文件，决定要不要调用，然后把输出写到磁盘上。没有插件系统，没有 API 面，没有版本兼容矩阵。只要你会写 Markdown，你就能交付一个 skill。

一个 skill 的解剖

具体来说，一个 skill 就是 daemon 在启动时发现的一个目录：

skills/
  magazine-poster/
    SKILL.md          # the contract: trigger, output shape, constraints
    examples/
      launch.html     # a known-good artifact the agent can pattern-match

SKILL.md 的 front matter 给出 skill 的名字和它的触发条件；正文则是 agent 像读简报一样阅读的指引。让 skill 注册生效的，唯有它出现在磁盘上这件事本身——没有要更新的 manifest，没有构建步骤，没有审核队列。

为什么文件胜过插件

这是有意为之的。十五年来，我们眼看着一个个插件生态走向衰朽——每一个都是表达力与长久之间的一笔交易，而两头都没赢。一个插件是某人某一年 API 的一张快照；运行时往前走，API 就坏掉，你赖以为生的那套工作流也就没了。文件不会坏。今天写下的一份 SKILL.md，两年后对一个 agent 读起来分毫不差，对一个手头没有任何工具的人也一样。

为什么 systems 也是 Markdown

Open Design 以 DESIGN.md 文件的形式，交付了数十套设计系统——Linear、Vercel、Stripe、Apple、Cursor、Figma 等等。思路一样：可移植、可阅读、可被 agent 摄入。

在这个语境里，一套设计系统不是一个 Figma 库。它是一份契约：

## Color
--bg: oklch(98% 0.01 95);
--ink: oklch(20% 0.02 260);
--accent: oklch(72% 0.19 35);

## Type
Display — Albert Sans, 600, -0.02em
Body — Albert Sans, 400, 1.7 line-height

## Posture
Generous whitespace. One accent, used sparingly. No drop shadows.

agent 读这份契约，产出尊重它的作品——颜色用 OKLch，好让它们在感知上保持均匀；一条它不会偏离的字号阶梯；一套版式姿态，让十屏生成的画面感觉像同一款产品。

混搭、分叉、占为己有

因为一套系统只是文本，你可以把它分叉了就地编辑，交付一个变体，或者三十分钟内从零写一套自己的。你甚至可以在项目中途混搭系统——从 Linear 取排版，从 Vercel 取配色逻辑，从一份自家定制规范取版式——因为没有任何二进制格式横在你和规则之间。skill 与 system 如何组合的完整机制，在 31 skills, 72 systems: how the Open Design library works 中有详述。

BYOK 是唯一诚实的模式

Open Design 以 bring-your-own-key（自带密钥） 的方式运行。你为任何兼容 OpenAI 的端点粘贴一个 base URL 和一个 API key——DeepSeek、Groq、OpenRouter，或你自己自托管的 vLLM——就搞定了：

OPENAI_BASE_URL=https://api.deepseek.com/v1
OPENAI_API_KEY=sk-…

我们不跑推理。我们不在 token 上抽成。我们和你之间没有计费关系。这不是一个可持续性的问题——它是对「agent 跑起来时谁来付钱？」这个问题唯一诚实的回答。

隐私是同一选择的自然结果

因为 daemon 是从你的机器上直接调用供应商，你的 prompt 从不途经我们的服务器。没有代理去记录它们，没有分析管线在悄悄留存你尚未发布的作品。对于代理机构的活儿，或任何受 NDA 约束的事，「这东西在哪里跑？」不再是一场采购谈判，而变成了一个设置项。更深一层的取舍——以及至今仍存在的粗糙之处——在 the BYOK reality check 里。

谁来付钱的答案是：你来，直接付给你选定的模型供应商。我们让开。

这对你意味着什么

如果你想要一款打磨精良、带着漂亮聊天框、一份订阅搞定的 SaaS，那我们不是合适的工具。市面上有这种形态的好产品——用它们就好。

如果你想要一套这样的工作流：

• 由你本就信任的那个 agent 来干活，
• skill 是你能读、能改的文件，
• 设计系统在不同项目和不同 agent 之间可移植，
• 账单去到模型供应商那里，而不是我们这里——

那么 Open Design 就是为你而造的。进到 GitHub 仓库，运行 pnpm tools-dev，把你的 agent 指向某个 skill，然后交付。

skill 层之所以会赢，是因为它不跟你笔记本上的那个 agent 竞争。它是在增强它。

延伸阅读

• 31 skills, 72 systems: how the Open Design library works ——这一层赖以构建的四个原语
• BYOK design workflow: run Claude, Codex, or Qwen on your own key ——自带密钥模式的实战
• The open-source alternative to Figma ——「做层，而不是做产品」这场赌局在面对老牌玩家时落到了哪里