AI时代你的工具也应该更新了自动生成可编辑设计稿

前阵子发现一个开源项目Penpot :53K Star，现在已经61K了,按趋势看 7 月还在以每天近千颗星的速度往上爬（这个数我按 star-history 估的，没找到官方口径），2026 年 6 月刚发了 2.16.0。在一堆 AI 项目里杀出这么个设计工具，本来想忽略，但它的 MCP Server 那栏让我改了注意，它想做的可能不是「便宜的 Figma」，而是「设计稿能被 AI 直接读写」的那层基础设施。这个有什么用呢,可以这样说ai带来的是全行业的洗牌,以往的工作模式和软件工程已经不符合ai时代了,这个工具要做的是ai能更好使用的设计工具

一道二十年的缝

设计稿从设计师手上到开发者手上，这中间的信息损耗，这个行业已经默认了近二十年。

不是工具不够好。Figma 很好，非常非常好，但它的底层格式是私有的。你在 Figma 里画一个按钮，圆角 8px、padding 16px 32px、颜色 #3B82F6，这些值存在某个封闭的 JSON 结构里，开发者想看，得点开 Inspect 面板，把数字手动抄出来，再翻译成 CSS。每个值过一道手就多一层可能出错。

我说的夸张了吗？你去任何一个前端团队问，画一个设计稿里的按钮花了多少来回，猜 padding 猜了多久，没人笑得出来。

问题不在 Figma 的能力（它确实强），问题在结构。只要设计工具的输出不是开发者能直接跑的东西，这道缝就没法从根上补。**

Penpot 的解法：设计文件就是代码

Penpot 选了另一条路：它的原生格式就是 SVG、CSS、HTML、JSON。你在 Penpot 里画的那个按钮，圆角、padding、颜色值本身就是 CSS 属性，不是藏在某个私有容器里的元数据。

它的 Inspect 模式直接给你三段东西：CSS 代码段、SVG 标记、HTML 结构。不用翻译，不用猜。

这对手上没前端的纯设计师来说可能算冷饭，他们不在乎格式，只在乎图层好不好找、性能流畅不流畅。但对「设计师 + 前端」那种两个人撑起一条产品线的团队来说，这是止痛药级别的东西：设计师画完，开发直接看 CSS 取值，截图画饼甩群里的历史终于可以翻篇了。

还有一个容易被忽略的点：Design Tokens（设计令牌）。Penpot 内置了原生 Design Tokens，做的不是简单的「颜色变量」，而是把设计系统的原子属性（颜色、间距、字号、阴影）抽象成可被引用可被约束的令牌，然后这套令牌设计侧用开发侧也能用，同一份 JSON 结构两边共享。Figma 也有类似能力，但需要通过插件或者第三方工具桥接；Penpot 是原生就搭好的。

翻到引擎盖下面：Clojure + WASM 的工程选择

好，说点更硬的。

Penpot 的工程团队选了一个在大多数前端团队看来非主流的技术栈：

后端是 Clojure（一种运行在 JVM 上的 Lisp 方言），前端是 ClojureScript + React，前端和后端共享同一份数据结构和代码，因为 ClojureScript 是 Clojure 编译到 JavaScript。一个直接的好处是：你在后端定义的 Shape 数据结构，前端不用再重写一份 TypeScript 类型定义，直接拿来用就行，结构天然一致。

但这还不是最骚的部分。Penpot 有个独立的 WASM 渲染模块（render-wasm），用 Rust 编译成 WebAssembly 来处理画布上那些密集的 SVG 渲染操作，矢量路径、布尔运算、渐变填充都走这条路。传统的 DOM 操作在画布上有成千上万个矢量对象时扛不住，WASM 是绕过那层瓶颈的方案。不过老实说，这个新渲染器目前还是 beta、默认关闭，要手动在设置里打开才生效，日常用的其实还是 SVG DOM 那套。

与此同时，它还有一个 exporter 服务，开了一个无头浏览器来渲染 SVG→PDF/bitmap。这个细节有意思：直接用真实浏览器渲染，保证了「你看到的样子 = 导出后的样子」，避免了自己写渲染引擎结果跟浏览器表现不一致的坑。

整条链路是这样的：前端（ClojureScript + React + WASM）← HTTP/WS → 后端（Clojure on JVM + PostgreSQL）→ Exporter（无头浏览器渲染）。代码仓库里还有个 /mcp 目录，MCP Server 的代码是跟主仓库一起维护的，不是单独拎出去的开源项目。

这个技术选择对普通用户来说无所谓，但如果你是一个需要评估「这个项目能不能长期维护」的决策者，这是个信号：Penpot 不是那种拿 Electron 套个壳就出来的开源项目，它的工程投入是有诚意的。

MCP Server：设计稿第一次被 AI 直接读懂

2026 年最值得聊的 Penpot 功能，是 MCP Server。

Model Context Protocol（MCP）是 Anthropic 推的一个协议，让 AI Agent（比如 Claude Desktop、Cursor、VS Code 的 AI 插件）能以标准方式读取和操作外部数据源。Penpot 是第一批深度支持 MCP 的设计工具。

MCP Server 是怎么工作的？三层：

• 你的 AI Client
  （比如 Claude Desktop）：你输入一句「帮我把这个登录页面的按钮改成圆角 12px、主色调换成 #6366F1」。
• Penpot MCP Server
  ：这一层是翻译层，把你的自然语言请求翻译成 Penpot 开放 Plugin API 能理解的操作指令。
• 你的 Penpot 设计文件
  ：API 执行操作——读取元素属性、修改样式、创建新的组件——全部直接在你的 workspace 上生效。

关键区别在中间那层。Penpot 的设计文件本来就是代码表达（SVG/CSS），所以 MCP Server 在和设计文件交互时，不用经过复杂的格式转换，直接从 Plugin API 拿到 SVG 结构就能读、就能改。这就是「设计即代码」在 AI 场景下的真实含义。

更妙的是，MCP Server 本身也是开源的，你可以部署在自己的服务器上，AI Agent 的数据也只在你自己的基础设施里流转，对数据合规敏感的企业来说，这是个巨大的加分项。

坦白说，MCP 现在的生态到底多大了？我不知道。官方说支持 Claude、OpenAI Codex、Cursor、VS Code，但大规模的真实用例我没看到。这个能力更像是「基础设施已经铺好，就等应用层跑起来」的阶段，像高速公路修好了但车流量还没上来。值不值得现在入场，取决于你对那个方向有没有把握。

一条命令跑起来

想试的话，最短路径是 Docker：

跑起来之后监听 http://localhost:9001，浏览器打开就能进。做原型、画界面、建组件库，跟 Figma 的操作逻辑差不多，只是你的数据在你自己机器上。

一个坑得来提前说：纯 HTTP 下剪贴板 API 用不了，官方明确建议上 HTTPS。新手自己起实例，十有八九会在这卡一下。提前知道就行。

锁版本的话，加个环境变量：

MCP 端点默认就在反代配置里留着：/mcp/ws。说明在 Penpot 的架构里，MCP 是和 WebSocket 通知平起平坐的一等公民，不是后期加的功能。

它能替代 Figma 吗？

诚实地说，不完全是。

Plugins 官方市场已经上线、开放 API 和 Webhooks 也搭好了——生态的架子有了，填充需要时间。如果你在做的事对「数据主权」和「AI 工作流」敏感（比如内部设计系统、合规要求高的团队），Penpot 现在就是一个值得认真评估的选择。如果你只是需要一个画界面的工具、对自托管没需求，Figma 依然是最省心的那条路。

说到底就是取舍，别指望它把 Figma 替了。

说说数据主权和许可证

企业端有一点值得单独提：Penpot 的许可证是 MPL-2.0。不是 GPL 也不是 AGPL。MPL 是「文件级」Copyleft，你修改了 Penpot 的源代码，改的那个文件需要开源，但你不碰的部分不受影响。这对企业法务来说友好得多，不像 AGPL 那种「只要提供服务，整个衍生项目都得开源」的强 Copyleft 那样让人紧张。

背后团队是西班牙的 Kaleidos 公司，也做开源项目管理工具 Taiga。Penpot 是 Kaleidos 的核心产品，有自己的 SaaS 服务（design.penpot.app）做收入支撑，不是那种个人项目。社区活跃度也不错：Discourse 论坛帖子量早已过千，GitHub Issue 响应及时。我翻了下最近的 commit 记录，光 2026 年 6 月 19 号一天就合进了十几条修复：页面模糊消失、取色器不读 DPR、缩略图误显标尺、WebGL 瓦片伪影、字体选择器定位错位、颜色库计数不准。都是真实在修的东西，说明不是摆烂状态。

一个没解决的问题

先纠正一个容易说死的点：Figma 同样有官方 MCP Server（远程端点在 mcp.figma.com/mcp，支持 Claude Code、Codex、Cursor、VS Code 等常用客户端），前面那张对比表里我也这么写了。所以「有没有 MCP」不是分水岭。

区别在于路径。Penpot 的设计文件本身就是 SVG/CSS/HTML 开放代码，MCP 读到的就是代码级结构，不用经过额外的序列化层。Figma 的 MCP 走的是它自己的接口，底层文件格式仍是封闭的，AI 拿到的设计上下文是 Figma 主动给的，不是直接读源码。功能上两家都强，但 Penpot 的路线更「原生」，它的设计文件从第一天起就是开发者和 AI 都能直接读懂的代码。

但说到真实用例，我翻了几个社区，确实有人在认真用了。一个人把个人项目从 Figma 完全切到 Penpot，用了 3 个月：第一周适应期发现界面相似零学习成本，第一个月建好了完整的组件库，第三个月所有新项目都在 Penpot 上做了。他的原话是"数据安心，所有文件在自己服务器，睡得踏实"。

还有一支 15 人的设计团队也做了迁移。用了 Docker Compose，整个生产环境部署花了约 30 分钟。评估结论是：核心设计工作流（矢量编辑、组件样式系统、原型交互、设计规范管理）覆盖完整，实时协作对国内团队来说"流畅无卡顿"。他们保留的顾虑跟上面一致，动效设计和插件生态还有差距。

所以这不是"能不能用"的问题，而是"你愿不愿意为数据主权和开放格式，接受一部分主流生态的不便利"。

说回开头那句话，Penpot 不是便宜的 Figma。它是一个把设计文件「开源化 + 可编程化」了的工具，并且在这层基础上接上了 MCP，让 AI 能直接读写设计稿。它的目标不是在打磨度上追平 Figma（虽然他们确实也在做），而是重新定义「设计文件应该长什么样」。

至于值不值得试，看你看重哪头了。