在Figma一家独大的这几年里我身边一直有团队在悄悄寻找它的替代品理由各不相同有的是觉得订阅制连年涨价吃不消有的是企业对设计数据出域有硬性要求还有的纯粹是受够了浏览器里那越来越臃肿的加载体验。直到Penpot出现这个打着“开源Figma替代品”旗号的设计工具用4.4万Star的社区热度证明了它不是一个小众玩具。我花了两周时间把一个小型项目从Figma完整迁移到Penpot上包括界面设计、标注交付、前端切图感受相当直观它在设计与代码协作这件事上的思考深度甚至比很多商业工具还要务实。Penpot是一款完全开源、基于浏览器的跨平台设计工具最大的特点是可以自由部署在自己服务器上设计文件存哪、谁能访问都由你自己说了算。它原生支持SVG格式从设计到前端代码的转化路径极短这正是它被称作“设计与代码协作的完美方案”的根本原因——它不是把设计稿当成图片来处理而是当成结构化数据来处理。这篇文章我会从项目拆解、核心特性、部署实操到协作落地完整走一遍给正在评估或准备上手Penpot的团队提供一个可参考的路线。1. Penpot项目拆解它到底解决了什么痛点1.1 定位不是“Figma克隆”而是“代码友好型设计工具”很多人上来就问Penpot和Figma哪个好用这个问题的前提就有偏差。Penpot的研发团队来自西班牙的Kaleidos公司他们本身是一群开源软件的老兵做Penpot从一开始就不是为了做“另一个Figma”而是想解决设计师和前端工程师之间那个长期存在的鸿沟设计师用图层和画板思考工程师用组件和属性思考中间环节全靠手动标注、切图、命名规范来硬撑。Penpot的设计哲学是“让设计文件本身就具备代码结构”。你画的每一个矩形、文本框、编组在Penpot里都对应着干净的SVG结构导出的CSS、SVG、HTML代码片段几乎是开箱可用的不需要像Figma那样装一堆插件去“翻译”设计稿。这一点在你实际用起来之后会感受特别明显尤其是做复杂表单、响应式布局的时候代码侧拿到的不是一个拍平的位图而是带层级、带约束关系的结构化描述。1.2 4.4万Star意味着什么社区热度背后的生态底气GitHub上4.4万Star是一个什么概念在开源设计工具这个细分领域Penpot的Star数比很多知名前端框架都高这说明它已经跨过了“极客玩具”的阶段进入了主流技术圈层的视野。Star数最直接的价值是生态信号你不用担心它明天就停止维护也不用担心找不到文档、搜不到解决方案。我关注到Penpot的插件生态、主题系统、MCPModel Context Protocol支持都在快速补齐社区里已经出现不少第三方组件库和部署方案。这意味着团队如果选型Penpot技术风险是可控的底下的开源协议、社区活跃度、版本迭代频率都是明牌。对于一个需要长期投入的团队协作工具来说这一点比某个单独功能是否好用更重要。1.3 开源协议里的门道MPL 2.0允许你“留后手”Penpot采用的是MPL 2.0许可证Mozilla Public License 2.0这个协议在开源软件里属于“中间路线”你可以自由使用、修改、商用甚至可以把它内置到你的商业产品里但如果你修改了Penpot本身的源码文件那么这几个文件必须继续开源。这个协议的实用意义在于——企业可以把Penpot作为基础设施放心部署起来如果后续有定制需求自己改代码不受限制只是改动部分需要回馈社区。对于不想承担AGPL协议那种强传染性义务的团队来说MPL 2.0是一个非常友好的选择这也是Penpot能被很多中大型公司接受的核心原因之一。2. 核心特性深剖从架构选型到协作体验2.1 为什么坚持做Web端而不是桌面客户端Penpot从一开始就走Web路线用ClojureScript编写前端后端基于Java的GIMP工具包。这种架构带来的直接好处是无需安装客户端任何设备打开浏览器就能设计Windows、macOS、Linux、平板全平台通吃同时部署场景更灵活既能用官方SaaS服务也能自托管到企业内网。选择Web端也带来一个隐性优势——它天然适配多人实时协作。不用像老一代桌面设计软件那样先设计一套文件锁机制、再想怎么同步。浏览器就是最好的跨平台协作容器这一点在现在的混合办公环境下尤其有吸引力。代价是它对浏览器的依赖度比较高尤其在线字体的渲染和复杂效果的性能表现和原生客户端相比还有差距。但以我实际体验来看在Chrome或Edge最新版上中大型画板的操作流畅度已经追平大部分场景。2.2 原生SVG设计稿就是半个“代码稿”Penpot底层采用SVG作为原生格式这个选型在外行看来只是一个格式偏好但在实际工作中影响深远。SVG本质上是XML格式的矢量描述语言每个元素都有明确的标签、属性、坐标、样式信息。当你在Penpot里画一个圆角卡片时它内部存储的就是一段结构清晰的SVG节点而不是一串像素点的集合。这意味着两个关键场景会发生质变第一导出到前端的代码不需要“反向工程”设计稿的层级关系、圆角数值、阴影参数、间距标注都是现成的前端拿到后几乎可以照着翻译成CSS不用一顿猜第二SVG支持程序化生成和二次修改自动化工具可以基于SVG结构做批量处理比如一键提取所有颜色变量、一键生成设计规范文档这在Figma体系里还需要依赖插件辅助。2.3 本地优先的权限与隐私内网部署有多实用Penpot提供了非常完整的自托管支持官方维护了Docker镜像和docker-compose部署脚本。对于设计数据敏感的企业来说这意味着设计稿可以永远不会离开公司内网没有第三方SaaS服务介入版权和数据归属完全清晰。这个特性在金融、政企、军工等合规要求严格的行业里基本是刚需。自托管版本的权限体系也做得足够细支持基于团队的成员管理、项目级权限控制、公开/私有链接分享。部署一台低配服务器就能扛起几十人设计团队日常使用的压力。我测试过在仅2核4G的轻量服务器上跑Penpot支持十个人以内的小团队并发使用日常操作响应速度完全可以接受只是大型文件首次打开时略显吃力需要一定的耐心。2.4 与Figma、即时设计等工具的横向对比为了让选择更直观我把自己实际使用过的三款工具放在一起做了个对比重点关注团队落地时最容易卡脖子的维度。对比维度PenpotFigma即时设计开源性质完全开源MPL 2.0商业闭源商业闭源自托管支持Docker/K8s部署不支持不支持客户端形式浏览器客户端浏览器客户端浏览器离线可用自托管后可用不可用不可用底层格式原生SVG专有格式专有格式代码导出内置CSS/SVG/HTML代码面板需插件基础代码面板插件生态起步中数量有限非常丰富中等多人协作支持实时协作支持业界标杆支持表格里最扎眼的区别其实是“自托管”和“原生SVG”这两行。如果你只把设计工具当画图工具用Figma依然是综合体验更好的那个但如果你需要在设计到开发的全链路里掌控更多环节Penpot的架构优势就会体现出来。3. 从零部署Penpot两套方案与避坑实录3.1 Docker Compose快速部署20分钟跑通全流程部署Penpot最成熟的方式是通过官方提供的Docker Compose编排。整个过程不复杂但有几个细节必须留意否则容易在数据持久化和端口占用上出问题。# 1. 拉取官方部署仓库 git clone https://github.com/penpot/penpot.git cd penpot # 2. 启动后端和前端服务默认使用docker-compose.yaml docker compose -f docker-compose.yaml up -d # 3. 等待初始化完成后访问 # 默认前端端口为 9001打开 http://你的服务器IP:9001我实测下来官方docker-compose文件会把PostgreSQL数据库、Redis缓存、后端API、前端静态服务全部编排起来启动后稍等一两分钟让数据库完成初始化就可以在浏览器里访问了。需要注意的坑有两个一是服务器防火墙必须放行9001端口以及后续如果要配HTTPS的443端口二是第一次启动后记得修改默认账号密码Penpot会为第一个注册的管理员账号赋予全权。生产环境我建议再加一层反向代理比如Nginx或Caddy把HTTP流量转成HTTPS毕竟设计稿数据在传输过程中加密是基本要求。Caddy的配置尤其简单自动签证书两行配置就搞定penpot.example.com { reverse_proxy 127.0.0.1:9001 }3.2 Helm Chart部署Kubernetes更适合中大规模团队如果你的团队已经上了KubernetesPenpot也有官方维护的Helm Chart可以直接部署到云原生环境。这种方式的好处是可弹性伸缩、可滚动更新、故障自愈对于几十人以上且对可用性有要求的团队来说比单机Docker更稳妥。# 添加Penpot官方Helm仓库 helm repo add penpot https://penpot.github.io/penpot-charts/ helm repo update # 安装Penpot到指定命名空间 helm install penpot penpot/penpot -n design --create-namespaceChart里可以自定义的资源包括副本数、持久化存储类、数据库连接、S3对象存储等。我把对象存储接到MinIO上做文件存储跑了一段时间非常稳。这里提醒一句K8s部署模式下PostgreSQL和Redis的状态持久化一定要检查PVC配置否则Pod重建时数据全部丢失别问我怎么知道的。3.3 从Figma迁移到Penpot素材搬运的实操方案目前Penpot没有一键“从Figma导入”的官方通道但日常迁移其实并不需要搬动所有文件。我总结了一套实用的迁移动作适合大多数以Web端设计稿为主的团队先把设计稿在Figma里逐页导出为SVG格式Penpot支持SVG文件的直接导入保留图层和基础结构如果是移动端界面设计也可以导出PDF再导入但PDF导入后图层会拍扁适合低保真快速搬运图片资源统一导出PNG/WebP在Penpot里使用“导入素材”功能批量上传拖入画板即可设计规范层面花半天时间在Penpot里重建颜色变量、文字样式、组件样例页一步到位建立新规范坦白讲第一周从Figma切到Penpot会有明显的“手生期”快捷键不同、插件变少、部分效率操作缺失团队需要一定的适应成本。但熬过一周之后会开始体会到原生SVG带来的交付效率红利尤其是前端同学拿到设计稿之后的反响会很积极。4. 设计与代码协作的精髓从画板到代码的生产力闭环4.1 内置代码面板设计师交付可以不再写标注在Figma里设计稿交付给前端通常需要走一遍“标注”流程要么手动加红线圈尺寸要么通过插件生成代码片段。在Penpot里这一切变成了默认功能你只需要选中任意图层或编组右侧面板会自动展示CSS代码包含完整的尺寸、定位、圆角、阴影、字体样式、间距等属性。如果你选中的是SVG形状还能直接查看对应的SVG代码。这意味着设计师不再需要对着设计稿手工整理一份“标注文档”前端不再需要拿像素尺去量间距。实际使用中前端拿到Penpot分享链接后直接就能选中元素复制CSS微调后放进项目中交付效率提升非常明显踩线对齐这类基础沟通成本基本归零。4.2 Dev Mode实战让前端拿到“带着设计上下文的代码”Penpot的代码面板不是简单展示CSS属性字符串它提供一个类似Figma Dev Mode的完整界面左侧是图层树中间是画板右侧是代码检查器。前端可以按图层层级逐层检查父容器、子元素、嵌套关系这对还原复杂布局很有帮助尤其是Flex布局和Grid布局不够熟练的初级前端几乎等于对着标准答案写作业。Dev Mode里还有一键复制整个图层树SVG代码的功能对于做图标、插画、组件这类矢量图交付前端直接复制SVG字符串放到代码里就行连切图导出、压缩WebP、跑图标字体这些流程都省了。我甚至见过一个前端同事直接用Penpot导出SVG做页面里的illustration质量和体积都比自己手写SVG或者找图库好得多。4.3 设计Token与组件系统让设计规范和代码规范统一Penpot从1.0开始支持Design Tokens设计变量可以定义颜色、字体、间距、圆角等基础变量然后在组件和画板中统一引用。这样设计文件本身就带上了“语义化”的属性名比如--color-primary、--space-md、--radius-lg而不是一堆裸数值。这个能力对代码协作的意义在于设计变量可以直接和前端CSS Variables一一对应。我实际操作的时候让后端把Penpot里的Token JSON导出一份构建时自动生成CSS变量文件设计组改了颜色值前端里跑一次同步命令就能全局更新两边永远保持同一套规范不再出现设计稿用的颜色和线上差一点儿的尴尬情况。这个工作流在Figma里需要借助Tokens Studio这类插件才能实现而Penpot把它做成了内置能力学习成本低很多。4.4 MCP与AI编程未来协作的新想象力最近AI编程工具爆发MCPModel Context Protocol成为让AI读设计稿的一种方式。Penpot官方也跟进了MCP Server支持这意味着AI编程助手比如Codex、Claude等可以通过MCP协议读取Penpot里的设计数据直接获取图层结构、样式、内容生成的前端代码是贴着真实设计稿走的而不是靠截图盲猜。我试过把Penpot的MCP接入本地开发环境让AI“照着这个设计稿写个页面”它能准确读取画板里的尺寸和配色输出的代码落地程度比“喂一张图片让它猜”要高出好几个量级。这套机制目前还比较早期但方向非常正确——设计工具正在成为AI编程的上下文来源Penpot因为开放、可自托管、原生SVG在这一点上有天然的优势因为它不限制你用什么AI工具也不限制数据流向哪里。5. 常见问题与排查技巧实录5.1 高频问题速查表把我在社区浏览和实际使用中遇到的高频问题整理了一张表方便快速定位问题。现象可能原因解决方案首次访问9001端口无响应防火墙未放行端口检查云安全组/本地防火墙规则放行TCP 9001上传图片后无法在画板中显示对象存储配置错误自托管时确认MinIO/S3的Bucket权限、地址可访问性多人同时编辑时操作冲突浏览器版本过低升级至最新版Chrome/Edge并确认WebSocket连接正常字体渲染与设计稿不一致未将字体上传至Penpot字体库在字体管理页上传项目所需字体文件插件安装后不显示浏览器缓存未刷新强制刷新CtrlShiftR或清除站点缓存导出SVG乱码内容包含特殊字符在文本属性中检查字符编码建议用UTF-8范围字体Docker重启后数据丢失未配置数据卷持久化检查volume挂载备份PostgreSQL数据目录5.2 版本升级和插件兼容那些坑Penpot迭代速度很快当前主版本基本每个月会有小版本更新但自托管环境千万别急着“升级到最新版就完事”。建议先看Changelog如果涉及数据库迁移先导出备份数据在测试环境升一遍确认没问题再动生产。插件兼容性是目前Penpot公认的短板官方为此设计了基于iframe的扩展机制原则上能兼容所有现代Web技术栈但整体生态还非常年轻。遇到某个插件不好用我的经验是先在GitHub Issues里搜一搜很多问题社区都已经有现成解法比自己折腾快得多。5.3 自托管的性能调优实操建议Penpot的官方文档并没有特别详细的性能调优指南这一块我自己摸索了不少时间有几个相对有效的建议数据库连接池在高并发场景下PostgreSQL的连接池配置不合适会导致接口响应变慢建议调整max_connections参数并启用PgBouncer做连接池代理资源画像单个用户操作时的CPU占用其实很低瓶颈一般在数据库和文件存储I/O上给数据库挂SSD盘是最直接有效的性能提升手段图片缓存如果是公网部署建议在前面加一层CDN把静态资源和导出的图片都交给CDN缓存回源压力会下降一个量级限制文件体积在团队规范里约定单个画板文件尽量别超过50MB超大文件的开源处理性能确实比Figma弱提前规避比事后优化更实际提示Penpot目前没有官方桌面客户端所有操作都在浏览器里完成部署时务必配置好HTTPS证书避免密码和设计数据明文传输。6. 团队落地Penpot的选型建议6.1 什么团队适合切到Penpot以我这段时间的观察最适合切换到Penpot的团队画像是这样的设计团队规模在20人以内、有前端开发力量且愿意配合做设计系统、对数据隐私和成本控制有明确要求、团队内没有人重度依赖Figma的高级插件。如果你满足三条以上Penpot会是一个投入产出比极高的选择。反过来如果你的团队高度依赖Figma生态里的社区插件比如自动布局、复杂原型交互、大量嵌套组件变体那Penpot目前的能力还替代不了强行切换会严重影响效率。这时候更合适的方向是用Penpot做“第二设计工具”先在新项目上试用积累经验之后再决定是否全量迁移。6.2 一步步切换的团队实操路线我建议团队切换Penpot不要搞“Big Bang”而是采用渐进式路径先挑一个内部工具型项目或官网改版项目让设计师和前端组成一个5人小分队做试点用一周时间在Penpot里重建设计规范、常用组件库、颜色变量和文本样式项目全流程走一遍从设计、评审到开发交付记录每个环节流程卡点根据试点的经验输出一份团队内部使用指南包含快捷键、命名规范、Token管理约定确认流程跑通后再向其他项目组铺开配合定期培训和答疑这个方式的好处是试错成本低万一Penpot确实不适合自己的业务场景损失的也只是一个小项目的几周时间。但如果跑通了团队收获的是一套自主可控的设计与代码协作基础设施。6.3 从开源软件到团队文化最后想聊一点软件选型之外的东西。Penpot的走红表面上是“Figma平替”的故事底层其实是开源软件在专业工具领域的一次回归。当一个工具既尊重你的数据主权又开放了自定义权限团队的创造力往往会被释放出超预期的东西。我见过有的团队用Penpot做产品设计之外的事比如画架构图、做脑暴白板、给客户出可视化方案它在“不只是设计工具”的泛用性上反而比很多专注做UI的软件更灵活。根据我个人经验选型开源工具最需要关注的指标不是功能清单而是“离开官方支持后你还能不能被这个工具困住”。Penpot在这道题上得分很高——数据能导出服务能自托管代码是开放的无论如何都不会走进死胡同。那种踏实的掌控感是商业软件在便宜的价格也给不了的。
