最近项目组在设计稿交付这件事上踩了不少坑。UI标注改了又改前端工程师对着设计稿一像素一像素地量状态切换、组件命名、间距圆角这些细节设计师解释一遍开发理解一遍最后还原度全靠临场发挥。有个同事突然甩过来一个链接说要不试试开源的 Penpot我把 GitHub 仓库翻了一遍4.4 万 Star 摆在那里心里就有了数——这项目不是小打小闹。Penpot 是一个基于 Web 的开源设计工具主打 UI/UX 设计与原型制作同时特别强调设计和代码之间的无缝协作。它和 Figma 的核心功能高度重合但最大的不同在于Penpot 完全开源、可自托管数据掌握在自己手里。这篇文章我会从功能对比、代码协作、私有化部署、适用场景四个角度把我自己实测两周的真实体验写出来适合正在评估设计工具选型的技术负责人、设计团队负责人以及想少走弯路的独立开发者。1. 从开源替代品这个说法讲起Penpot真正解决的痛点1.1 设计工具这件事为什么需要开源选项说句实话Figma 是很优秀的产品。它的协作体验、插件生态、团队资产库都是目前行业里做得最成熟的。但成熟归成熟不代表所有团队都适合。首先设计数据是团队的核心资产。界面设计稿、交互流程、组件规范、用户研究素材这些东西每天都在沉淀。放在别人的云服务上团队对数据的控制力其实是有限的。尤其当团队面向的客户对数据本地化、私有化有明确要求时云端部署的工具天然不能满足条件。其次是预算问题。Figma 按席位订阅看起来单价不贵但一个几十人的产品团队加设计团队一年累积下来也是一笔不小的开支持续支出。而且它的高级功能往往和付费档位绑定比如设计系统、共享组件库这些真正提升效率的能力要上更高档位才开放。开源工具的意义在于给团队多了一个选择。不是所有团队都必须要自建一套但能不能自建决定了议价权和主动权。Penpot 的出现恰好填补了高性能开源设计工具这个空白。它不是那种只能画几个原型图的玩具而是真的能承担日常 UI 设计、原型制作、切图交付完整工作流的工具。1.2 4.4万Star背后的含金量GitHub 上的 Star 数容易刷但 Penpot 这 4.4 万 Star 的成色要结合项目的底色来看。Penpot 背后的公司叫 Kaleidos是做开源起家的技术团队项目从 2018 年开始孵化核心代码仓库长期保持非常高的活跃度。它的技术路线也很有意思前端用 ClojureScript 编译成 JavaScript 运行在浏览器里图形渲染层以 SVG 为核心因此在缩放、导出、代码还原这些场景里有一些天然优势后面我会展开讲。Star 数代表的是关注但决定一个开源项目工程质量的是 commit 频率、issue 响应速度和发布节奏。Penpot 在这几方面的表现在我实际使用中有明显感知Bug 修得快新功能迭代节奏稳定社区里也能看到官方积极回复问题。这种背后有一家专业公司全职维护的开源项目用起来比那种个人开发者抛出的半成品要安心得多。2. 实测两周Penpot与Figma的功能对比和真实使用感受2.1 核心功能对照表先把两张表放在前面一张是功能层面的对比一张是我自己主观体验后的结论。为了公平起见对比的基准版本是我当前使用的最新稳定版 Penpot 和团队还在用的 Figma 专业版。功能维度PenpotFigma备注矢量编辑完善极完善Penpot 的路径编辑、布尔运算够用组件与样式支持非常成熟组件变体、自动布局 Figma 更强设计Token支持支持Penpot 引入较晚基础用法已可用实时协作支持第一梯队两者都能多人同时编辑评论批注支持支持Penpot 的批注体验还在进化中原型交互基础可用功能丰富Figma 的 Smart Animate 等效果更强代码查看内置CSS视图依赖开发者模式Penpot 把CSS直接放在属性检查器里切图导出支持支持两者都支持多倍率导出插件生态刚起步非常庞大这是目前差距最大的地方自托管完美支持不支持这是 Penpot 的最大差异点价格完全免费按席位订阅自托管无隐性成本2.2 上手迁移的真实体验我团队里既有设计师也有开发我让他们分别从 Figma 转 Penpot 试了两周反馈很有意思。设计师的第一反应是快捷键不习惯。Penpot 和 Figma 很多基础操作的快捷键不一样比如选择工具、缩放、切图快捷键肌肉记忆需要时间迁移。这其实不是 Penpot 的短板只要在设置里把偏好调一遍大部分常用操作都能找到替代。真正让设计师满意的点是 SVG 渲染带来的缩放体验在画布里放大到极小或极大时图形边缘始终保持锐利导出 SVG 和 PDF 时细节还原度非常高这对需要输出图标、插画资源的团队是实打实的加分项。开发人员的反馈更直接代码查看面板太好用了。选中任意一个图层右侧就能直接看到它的 CSS 属性——宽高、间距、圆角、填充、边框、阴影甚至 transform 变换。设计师把视觉稿的间距从 16px 改成 12px开发不用再去拿标尺测直接看 CSS 面板里的数值就对上了。2.3 中文界面、字体管理和本地化的细节热搜上经常有人问Figma 怎么汉化Figma 安装字体不生效这些困扰说明中文用户对本地化体验是很敏感的。使用 Penpot 的时候我发现它对中文界面和多语言的支持做得比较自然界面本身有多语言版本团队里英文不太好的成员用起来不费劲。字体的处理方式也和 Figma 的逻辑不同。Penpot 支持在系统内上传字体文件然后项目内所有成员都能使用这个字体。团队如果用的是自定义字体或者国内厂商的字体授权不用每台机器手动装一遍直接传上去共享就行。这个点对国内团队尤其友好避免了很多我这台机器看不到这个字体的扯皮场景。3. 设计到代码的最后一公里Penpot的协作价值拆解3.1 静态标注变成实时属性开发不用再量图传统设计交付流程里最容易被吐槽的就是标注。设计师在稿子里标了间距、字号、颜色开发者照着还原但稿子改了一版之后标注经常没同步更新开发按旧数据显示还原度就打了折扣。Penpot 的处理方式绕开了标注这个环节。因为它是 SVG 优先的渲染架构所以每个元素的位置、尺寸、颜色、圆角、阴影这些信息本来就是结构化数据属性检查器里直接呈现的就是真实代码层级的属性值。设计师改完画布CSS 视图里的数据同步更新开发不用等标注随时打开都是最新的。用团队里前端的一句话来讲这相当于把设计稿变成了一个可视化调试器能看到我真正需要的样式值。3.2 设计 Token把设计规范变成团队共识如果说实时属性解决的是单个元素怎么还原那设计 Token 解决的是整套规范怎么统一。我可以在 Penpot 里定义颜色、字体、间距、圆角等基础 Token组件库里的所有元素都引用这些 Token。以后调品牌色只需要改 Token 的值全项目所有用到这个颜色的地方统一更新。这听起来像设计系统该做的事但放到协作语境里的意义是Token 的定义方式和前端代码里的 CSS 变量、设计令牌概念是对齐的设计师用的 Token 名和工程师代码里的变量名可以统一。实际操作中我会列一张 Token 与前端变量的对照关系表比如颜色 Primary500 对应前端组件库的 color-primary-500。团队约定保持一致设计师作图、开发写码就是同一套词表沟通成本大幅下降。Penpot 在这个方向上的支持基础已经可用社区也在迭代更完整的管理界面。3.3 一条更轻的协作工作流我实际在团队里跑通的一条工作流是这样的设计师在 Penpot 里完成界面稿组件基础引用 Token分享评审链接给产品和开发在线评论直接留在画布上前端开发的时候开两个窗口左边 Penpot 看视觉稿右边 IDE 写代码需要数值直接抄属性检查器。这个过程省掉了原先的标注、导出、命名规范文档、设计走查记录等多个环节的文件传递。虽然单看哪个环节都不复杂但一整条链路省下来实际节省的时间非常可观。我粗略统计过一个中等复杂度页面的交付周期从原来的三天压缩到一天半左右这个收益不是工具本身带来的而是工具把信息的流转路径变短了。4. 从零跑通 Penpot私有化部署的完整步骤和踩坑记录4.1 为什么我优先考虑自托管而不是直接用官方版Penpot 也提供官方云端服务注册账号就能用跟 Figma 的体验差不多。但我个人的主张是既然选 Penpot自托管的意义不能忽略。一方面自托管意味着数据完全在自己的服务器上不经过任何第三方平台这对有保密要求的产品研发来说是一条硬约束的解决方案。另一方面自托管还意味着可以自定义基础设施。想要它跑在内网部署一套想要接入自己的统一登录认证改造起来也有抓手。这种自由度是任何商业 SaaS 都很难给的。当然自托管也有代价就是需要团队里有懂运维的人Docker、Nginx、数据库这些基础概念得有人能接住。如果团队完全没有运维能力那可以先用官方的在线版把设计协作跑起来再说。4.2 Docker Compose 部署的完整流程Penpot 官方提供了完善的 Docker 化部署方案我实测下来流程非常顺滑大约一个小时以内可以跑通。下面是完整的部署步骤。前置条件一台能运行 Docker 的 Linux 服务器内存建议至少 4GB我 2GB 的小机器也跑通过但多人并发时会比较吃力安装好 Docker 和 Docker Compose 插件。第一步创建项目目录并准备 Compose 文件。mkdir ~/penpot cd ~/penpot然后从 Penpot 官方 GitHub 仓库或官方文档里找到标准的 docker-compose 编排文件保存到这个目录。整个编排一般包含前端 Nginx 容器、后端服务容器、PostgreSQL、Redis 和对象存储组件帮你把基础依赖全部串联好。第二步修改关键环境变量。自托管场景下你需要把数据库密码、自动生成的密钥、对外访问地址这几项改成自己的值。举个例子如果你的服务将通过 https://design.example.com 访问那环境变量里的 public URI 要对应改成这个地址。数据库密码建议用一个足够长的随机串避免默认弱口令暴露在公网上。第三步启动服务。docker compose up -d docker compose logs -f等前端和后端容器都进入运行状态浏览器访问服务器 IP 或配置好的域名就能看到 Penpot 的登录页。第一次访问时可以注册第一个账号系统会自动把它设为管理员。4.3 部署过程中我踩过的三个坑第一个坑是端口占用。Penpot 默认通过 Nginx 暴露 80 端口如果服务器上已经跑了其他 Web 服务端口就冲突了。解决方案有两个一个是改 Compose 里 Nginx 的端口映射比如把 80:80 改成 8080:80另一个是用已有的反向代理把子域名转发到 Penpot 的端口。我更推荐第二种因为后面如果要挂 HTTPS 证书反向代理层处理起来更顺手。第二个坑是邮件服务。默认配置里邮件服务没有真正对接外部 SMTP所以系统里忘记密码邮件验证这些功能是发不出邮件的。第一次搭建时如果只靠密码登录这个问题感知不大但如果你想开团队协作、邀请成员最好提前配置一个 SMTP 服务常见的邮件服务商都可以配置好之后邀请和通知才走得通。第三个坑是备份。Penpot 的数据分两大部分数据库PostgreSQL里存的是设计稿的元数据和结构信息对象存储默认本地磁盘里存的是图片、字体等文件资产。备份时必须两个都备份只备份数据库会导致附件丢失。我现在的做法是写一个定时脚本每天凌晨把 PostgreSQL 的数据 dump 出来同时把对象存储的目录打包上传到远端存储双保险。4.4 内网环境的分发与日常维护部署好之后团队内部使用是完全没问题的。为了让大家访问方便我做了几个小优化配置好 HTTPS 证书让浏览器不出现安全警告在登录页上绑定团队域名方便记忆在管理员后台创建好项目空间邀请成员时会收到邮件通知。日常维护的话Penpot 的升级也挺简单的docker compose pull 拉新的镜像再 docker compose up -d 重启旧数据会自动保留。自托管版本最让我安心的点是升级、回滚、数据导出这些操作主动权都在自己手里。不会因为服务商策略变动被迫改工作流。注意如果你准备把 Penpot 长期作为团队正式工具建议从第一天就把数据备份和访问安全这两件事做好后续会省掉很多补救工作。5. 哪些团队适合切换到 Penpot哪些需要再等等5.1 我推荐的切换场景第一类数据敏感型团队。不管是做政企项目、金融行业还是医疗相关的产品数据不出内网往往是一条硬性规定。Penpot 自托管的部署方式可以把设计数据完全留在私有网络满足合规要求的同时不牺牲协作效率。第二类中小规模设计与开发团队。比如团队的设计师人数在十人以内开发二十人以内没有太复杂的组织架构和权限层级Penpot 的能力足够覆盖日常需求。这类团队最容易被订阅费用拖累切换到 Penpot 后每年省下的成本相当可观。第三类需要和开源流程深度整合的团队。如果团队本身用 GitLab、开源项目管理工具、开源监控体系那再引入一个开源的 Penpot 也是很和谐的组合。需要批量导出设计资源、脚本处理设计稿、做自动化检查Penpot 的开放性都能提供更多操作空间。5.2 暂时不建议切换的场景如果你的团队重度依赖 Figma 的插件生态比如依赖 Content Reel、Iconify、各种图表生成插件那 Penpot 现在的插件生态还撑不起这个工作量。我建议先观望等插件市场更丰富之后再评估。另外一个场景是大型设计系统。如果你的组件库规模很大、交互状态特别多、依赖非常精细的变体和自动布局能力Figma 在设计系统管理上的成熟度目前仍然领先 Penpot。不是说 Penpot 做不了而是迁移和重建的投入产出比在现阶段还不够理想。5.3 我的迁移建议和一些心里话我自己的建议是不要一刀切。Penpot 和 Figma 完全可以并行跑。先把非核心的、低敏感度的项目放到 Penpot 上试错跑顺之后再把边界逐渐扩大Figma 上已经建立好的核心组件库暂时不用迁移等团队对 Penpot 有了充足信心后再动手也不迟。可能有人会问既然 Figma 这么强为什么还要折腾 Penpot我的看法是设计工具不应该只有一家独大的选择。一个再好的商业工具也不能成为团队长期唯一依赖的基础设施。开源工具带来的是选择权和主动权Penpot 在这个方向上已经走出了非常扎实的一步。最后分享一个我在实际使用中的体会工具选型这事真的不是比谁功能列表更长而是看在你的团队具体工作流里它能帮你省下多少无效沟通。Penpot 让我感受最深的就是设计稿不再是一张图片而是一份能被工程师直接读取的数据源。如果你也想试试这种协作方式建议直接部署一套自己玩玩比看一百篇文章都有用。