Penpot自托管部署实战：从Figma迁移到开源设计平台

如果你最近在GitHub上搜过“设计工具替代方案”，大概率会撞见Penpot这个名字。简单说，Penpot是一个开源的、免费的设计与原型平台，目标很直接：正面硬刚Figma。支持矢量设计、组件系统、自动布局、交互原型，还能团队实时协作，并且可以部署到自己的服务器上。作为已经带着团队从Figma迁到自托管Penpot的人，我花了不少时间踩坑、调优，今天把选型、部署、实操、迁移的经验完整分享出来。这篇文章适合谁看？不管你是想摆脱订阅费的小团队、对设计数据敏感的企业，还是纯粹喜欢研究开源项目的开发者，这里都有可以直接照抄的部分。

1. 为什么我会盯上Penpot：开源设计平台的选型逻辑

1.1 Figma很好用，但你并不总能安心用

先说明一下，我不是那种逢Figma必反的人。Figma的协作体验、组件生态、插件市场，至今仍然是一流水准，我手头大部分项目也还在用。但在实际带团队的过程中，有几个问题越来越绕不开。

第一个是成本。Figma免费版对个人学习很友好，但一旦到了团队规模，涉及到多人协作、版本历史、权限管理，就需要上付费套餐。这笔钱按年算下来并不少。尤其是那种只有三五个设计师加一堆需要看稿的开发、产品的小团队，人均成本其实挺尴尬的。

第二个是数据边界。Figma的设计文件默认存它的云端，虽然企业版有SSO、审计这些合规能力，但很多客户或公司内部要求设计资产不能出内网。我们接过一个政务类项目，对方直接要求在隔离环境下做UI设计稿，Figma这种纯云服务根本没法用。

第三个是网络和服务可用性问题。这个不用展开，大家平时用海外云服务时多多少少都遇到过加载慢、偶尔连不上的情况。虽然不影响大厂内部使用，但对需要稳定交付的团队来说，就是隐形成本。

所以“替代Figma”这个需求其实不是性能问题，而是成本、合规、依赖这三个问题叠加出来的刚需。我当时的筛选标准很简单：要能自托管、要开源且协议友好、功能上至少覆盖设计和原型两大块，最好还别像老古董一样难用。

1.2 Penpot的核心竞争力：自托管、开放、跨平台

Penpot来自西班牙的Kaleidos团队，代码挂在GitHub上，仓库地址是github.com/penpot/penpot，采用MPL 2.0协议。这个协议值得多说一句：你可以自由使用、修改、商用，甚至做成付费服务给别人用；唯一需要注意的是，如果你修改了项目本身的源码，需要把对应的改动开源。对于绝大多数做设计工具集成、二次开发、内部部署的团队来说，这个限制几乎没有感觉。

它的技术栈也很有意思，后端用Clojure，前端用ClojureScript。很多人一听Clojure就发怵，但用起来你根本感知不到，因为对外提供的是Web服务。这个技术选型带来的一个实际好处是：Penpot的数据模型设计得相当严谨，文档里的图层、样式、状态都带有不可变数据结构的特点，多人协作时不容易出现状态错乱。对比一下那些用传统命令式模型硬做协同编辑的工具，Penpot的并发处理思路明显更现代。

还有一点是跨平台。Penpot走的是Web-first路线，浏览器打开就能用。这对Linux用户特别友好，我团队里就有个开发天天用Linux当主力机，以前看设计稿得专门开虚拟机装Figma客户端，现在直接浏览器访问内部部署的Penpot，省了一大堆事。

我把两者做过一个对比，大概是这样的：

这个表不是要论证谁吊打谁，而是说：如果“数据自主可控”是你的硬性指标，Penpot目前是开源阵营里最接近Figma体验的那个。

1.3 适合使用Penpot的四类典型用户

根据我这一年多的观察，Penpot吸引的人大概分四类。

第一类是小团队和初创公司。四五个人做产品，设计稿基本内部看，不想为协作功能额外付费，自托管在一台小服务器上，月成本几十块。第二类是数据敏感行业。金融、政务、医疗这类项目，设计资产本身就是交付物的一部分，放内网最安全。第三类是开源爱好者和开发者。喜欢研究工具内部实现、想给项目提PR、或者想定制一些内部功能的人，Penpot这种完全开放的项目很适合折腾。第四类是高校和培训机构。给学生每人开一个账号，不需要付费授权，教学场景很实用。

我自己属于第二类和第三类的混合体，既要做内网设计平台，又忍不住去看它的源码结构。Penpot吸引我的核心，还是那个词：自由。

2. 五步完成自托管部署：从零跑起一个私有设计平台

2.1 先想清楚：官方云服务还是自己扛服务器

Penpot官方其实提供了一个云服务版本，在app.penpot.app注册一个账号就能直接体验。如果你只是一个人想试试功能，完全没必要一开始就折腾自托管，先上云服务画两个页面，感受一下交互和功能再决定。

但如果你和我一样，最终目标是自己部署一套，那我建议提前评估三个事。

第一是服务器资源。Penpot由前端、后端、PostgreSQL、Redis这几个核心组件构成，2核4G的云主机带一个十人左右的小团队完全够用，文件存储量不大的时候磁盘也没啥压力。第二是访问方式。自托管的Penpot默认是通过IP加端口访问的，真正给团队用必须配域名和HTTPS，否则浏览器一堆报错，协作功能也会被安全策略拦下来。第三是维护意愿。自托管意味着升级、备份、故障恢复都得自己管，这本身就是一笔隐性时间成本。

我个人建议：可以先在云服务上把功能流程跑通，再决定要不要自托管。别一上来就搭环境，功能都没搞明白就部署，出了问题容易劝退。

2.2 Docker Compose部署，一条命令拉起全部服务

Penpot官方在GitHub仓库里提供了完整的Docker Compose部署文件，这是我认为目前最省心的方式。它把前端、后端、PostgreSQL、Redis、对象存储这些组件全部编排好了，你基本只需要做配置和启动。

先把官方仓库拉下来。如果你的服务器能正常访问GitHub，直接：

git clone https://github.com/penpot/penpot.git cd penpot

如果GitHub访问很慢，后面我会专门讲替代方案，这里先按正常流程走。仓库里有个docker-compose.yaml文件，它默认会从Docker Hub拉取penpotapp/frontend和penpotapp/backend这些镜像，拉取时间取决于服务器带宽。

启动之前，有几项配置建议先改一改。编辑同目录下的.env文件，重点看这几个：

PENPOT_PUBLIC_URI=http://design.yourcompany.com PENPOT_DATABASE_URI=postgresql://penpot:penpot@postgres/penpot PENPOT_REDIS_URI=redis://redis:6379

PENPOT_PUBLIC_URI是最关键的一项。它是Penpot对外访问的完整地址，如果配置错了，生成的分享链接、团队邀请链接都会指向错误地址。注意这里要填你最终要通过浏览器访问的公网地址或内网域名，不要填localhost。

改完后直接启动：

docker compose up -d

第一次启动会拉取镜像，需要一点时间。启动完成后，用docker compose ps看看各服务状态，如果都是Up状态，就可以通过浏览器访问了。

这里有个很容易忽略的细节：默认的Compose文件里，前端服务映射的是宿主机80端口，如果你服务器上已经有Nginx、Jenkins之类的服务占用了80，会直接冲突。遇到这种情况，可以在.env里调整端口映射，或者提前把占用端口的服务停掉。

2.3 配置域名、反向代理和HTTPS：让团队真正用起来

裸奔的IP加端口方式只适合自己测试，团队协作必须上HTTPS。理由很实际：浏览器对非安全上下文的限制越来越严格，很多Web API只有在HTTPS环境下才完全开放，协作功能也需要安全的WebSocket连接。Designer 工具里的一些剪贴板功能，在HTTP环境下也会被浏览器拦截。

我自己用的是Caddy做反向代理，配置非常简单，Caddy会自动申请和续期Let‘s Encrypt证书：

design.yourcompany.com { reverse_proxy 127.0.0.1:80 }

如果你习惯Nginx，配置思路是一样的，核心就是反向代理到Penpot前端服务所在的端口，然后加好SSL证书。Nginx还有个额外事项：上传大文件时会受client_max_body_size限制，默认1M肯定不够用，导入Figma文件、上传图片资源很容易失败。我一般在server块里主动设置：

client_max_body_size 50m;

这样既能支撑日常设计文件的导入，又不会把上限抬得过于夸张。

域名解析做好、HTTPS生效以后，第一次访问应该会看到注册页面。这里有个直接影响团队协作的细节：Penpot的权限模型中，第一个注册的账号默认会成为系统管理员。所以第一件事，建议用你规划的超级管理员邮箱来注册，而不是随便拿一个测试邮箱注册完再改权限，后面省事很多。

2.4 中文字体与资源准备：设计稿不乱码的关键操作

这是自托管Penpot和新手之间最大的“劝退点”。Figma用云端字体，你本机装了字体，团队其他人也能看到；但Penpot自托管环境下，浏览器虽然能调用本地字体来渲染，但如果换一台没装这个字体的电脑打开同一份设计稿，字体就会被替换，版式很容易乱。

Penpot从2.0开始支持在服务端挂载自定义字体。官方文档里的做法是：把字体文件放到容器内的/opt/penpot/fonts目录，后端启动时会自动加载这些字体。实际操作中，我会在Compose文件里给后端服务增加一个卷映射：

penpot-backend: image: penpotapp/backend:latest volumes: - ./fonts:/opt/penpot/fonts:ro

然后把常用的中文黑体、宋体、思源系列等字体文件丢到宿主机当前目录下的fonts文件夹里，重启后端容器让字体生效：

docker compose restart penpot-backend

另外，Penpot高版本也在资源管理里提供了字体上传能力。设计师登录后，可以把项目里常用的字体文件上传到团队资源中，这样团队成员在设计时就能选择这些字体，而不是依赖各自本机是否安装。这个能力和服务端挂载不冲突，可以配合使用。

我踩过的一个坑是：一开始只挂载了英文字体，没放中文字体，结果同事打开设计稿时中文全部变成了默认字体，段落换行全乱。后来我把团队常用的中文字体统一整理好，服务端挂载一份、项目资源也传一份，基本就没再出过字体丢失的问题。如果你有正式的商用设计项目，中文字体版权也要提前确认清楚，思源黑体、思源宋体这类开源字体是保险的选择。

2.5 日常维护：升级、备份与迁移

自托管系统的日常维护其实就三件事：升级、备份、迁移。

升级相对简单。Penpot发版比较勤，我一般每隔一两个月盯一次GitHub Release。升级流程是：

git pull docker compose pull docker compose up -d

先更新Compose文件，再拉取新镜像，最后重建容器。数据库结构如果有变更，启动时后端会自动做迁移，大多数时候不需要人工干预。但建议不要在团队正在高强度使用的时间窗口升级，最好选个半夜或者周末，留出回滚余地。

备份才是自托管的真正基本功。Penpot的核心数据在PostgreSQL里，包括用户、团队、项目、图层元数据；设计文件里的图形数据和资源存储则在存储卷里。两个都要备份。最简单的方案是用pg_dump把数据库定期导出，同时把存储目录做异地快照或复制。

docker compose exec postgres pg_dump -U penpot -Fc penpot > penpot_backup_$(date +%Y%m%d).dump

存储卷的备份，如果你用云主机的块存储快照，那就最简单；如果是本地磁盘，就把存储目录压缩归档再传到备份机器。这里一定要记着：只备份数据库不备份存储卷，恢复后会看到一堆空画板，图形全部丢失。

我帮朋友迁移过一次，就是直接把旧服务器的数据库dump和存储目录搬到新机器，再重新部署一套相同版本的Penpot，恢复数据库后指向存储卷，整个过程没有丢文件。只要版本一致，迁移的坑并不多。

3. 从零设计一个落地页：Penpot核心功能实操

3.1 画板、网格与多画板工作流

部署好环境以后，别急着画图，先把Penpot的工作界面摸一圈。登录后创建团队，团队下面再创建项目，项目里就能新建设计文件。Penpot的文件编辑界面长得很“主流”：左边是工具栏和图层树，中间是画布，右边是属性面板。用过Sketch或Figma的人，基本不需要学习成本。

画板在英文里叫Board，快捷键是F。点击工具栏的画板工具，然后在画布上拖动，就能创建出一个画板。我一般会把一个落地页的设计稿拆成多个画板，比如首页、案例详情、价格页、关于页，每个页面一个画板，横向排列在画布里。做交互原型时，这些画板天然就是路由跳转的目标页，很方便。

Penpot支持栅格系统。选中画板后，在右侧属性面板里可以设置栅格数量和间距。做响应式设计时，我通常会在画板上叠加一个12列栅格作为参考，有点像前端框架里的Bootstrap栅格。这样排版时能直观检查内容是否对齐、间距是否统一，而不是全靠肉眼估。

图层管理方面，Penpot的图层树支持分组、锁定、隐藏，操作逻辑和主流设计工具一致。有一个小技巧：给图层命名时直接使用类似“header-logo”“btn-primary”这种有语义的名字，导出到开发那边时，他们在Inspect模式下一眼就能看懂结构，比我以前用“矩形1”“组12”这种名字效率高太多了。

3.2 矢量编辑和组件化：把Sketch习惯平移过来

很多人以为开源设计工具的工具链很简陋，其实Penpot的矢量编辑能力比想象中完整。钢笔工具、路径编辑、布尔运算、裁剪蒙版这些都有。我在Penpot里画过一个图标库，钢笔锚点、曲线控制、路径合并这些操作做下来，手感虽然和Figma还有一点点差距，但绝对到了“可以正经干活”的程度。

组件系统是Penpot的重头戏。选中画板里的一组元素，右键选择“Create component”，就能把它变成组件。之后复制出来的实例，修改实例的颜色、文案，不会影响主组件；但如果你想统一改所有按钮的圆角，只需要改主组件，所有实例会自动同步。这个逻辑和Figma的Component、Sketch的Symbol本质上是一回事。

Penpot还支持变体功能。比如一个按钮，有默认、悬浮、禁用、加载四个状态，可以做成一个Button组件的四个变体，然后在属性面板里切换。做组件库的时候，这是非常核心的能力。我搭过一个基础设计规范的组件库，把颜色、字体、按钮、输入框、弹窗全部组件化，团队其他成员直接拖组件拼页面，交付质量的稳定性提升了不少。

此外，Penpot近几个版本里加入了Styles功能，也就是样式资源。你可以在资源面板里预先定义颜色变量和文本样式，比如“品牌主色”“标题1”“正文2”，画图时直接引用这些样式。改样式的时候，全文件引用了它的元素会一起更新，不会出现那种改十次按钮颜色漏了三个的尴尬事。

3.3 自动布局：动态调整容器，效率提升不少

Penpot 2.0引入的自动布局能力，是它真正能对标Figma Auto Layout的关键一步。自动布局让你不用再手动拉伸容器、逐个调间距，而是把布局规则告诉工具，工具帮你算尺寸。

具体操作是：选中画板里的多个元素，点击右侧属性面板的“Flex layout”按钮，Penpot就会自动把这些元素放入一个弹性容器。你可以设置主轴方向是水平还是垂直，设置元素间距，设置容器的内边距，还能控制子元素在主轴和交叉轴方向的对齐方式。这基本就是把前端Flexbox的概念搬到了设计工具里。

比如做一个导航栏：左边放Logo，右边放菜单按钮。以前我得手动把Logo固定到左边，再手动把按钮组推到右边；现在开启自动布局后，把Logo和按钮组放进同一个容器，设置主轴方向为水平、间距为自动，再做两个弹性子项，它们会自动分布在两端。修改Logo的宽度时，按钮组位置会自动跟着变化，不会出现重叠或留白。

我在Penpot里做表单组件时特别依赖自动布局。输入框+错误提示+辅助文案，用自动布局垂直排列，上下间距统一8px，内边距都写到规则里，后续复制出来的表单天然整齐，不会再出现“看起来差不多但是总差两像素”的问题。

3.4 交互原型：从静态稿到可点击Demo

设计稿画完，下一步就是把它变成能点击的原型。Penpot的交互原型功能覆盖了日常场景里的核心需求：元素点击、页面跳转、返回上一页、以及一些基础转场动画。

实操流程很简单。选中元素后，切到右侧属性面板的Prototype标签，点击“Add interaction”，选择一个触发方式，比如点击、悬停、聚焦等，然后设置行为动作。最常见的动作为“Navigate to”，目标选择另一个画板。转场动画可以设置持续时间、缓动函数和动画效果。设置完成后，顶部工具栏会有一个播放按钮，点击进入全屏交互预览模式，就可以像使用真实页面一样点击按钮跳转了。

我做公司产品落地页原型时，一般会把首页、案例页、价格页、表单页各画一个画板，把CTA按钮连到对应页面，再把次级按钮连到反馈页。这个可点击原型可以生成一个分享链接发给产品、开发和客户，对方直接在浏览器里点，不需要装任何软件，也不需要Figma账号。

有一点要提前说明：Penpot在交互原型上还没有Figma那么深的生态，不支持复杂的变量和条件逻辑，做高保真业务流模拟会吃力一些。但如果只是验证导航流、展示页面关系、给开发评审交互稿，完全够用。那些复杂的逻辑演示，我会用真实的HTML原型来做，不在Penpot里死磕。

3.5 交付给开发：Inspect模式与资源导出

设计和开发之间的交付，是Penpot另一个让我刮目相看的地方。选中任意图层，切到属性面板的Inspect模式，开发人员就能看到这个元素的尺寸、位置、圆角、背景色、边框、阴影，以及对应的CSS样式。选中多个元素还能看到间距测量信息。虽然不像Figma Dev Mode那样能直接生成完整的代码片段，但常用属性一目了然，前端照着写完全没问题。

导出资源也很方便。选中图层或组，在导出面板里选择格式，PNG、SVG、PDF都支持，可以设置倍率和尺寸。比如给开发导出App图标，我可以一键导出1x、2x、3x三套尺寸，省得再开图片处理软件切图。

这里补充一个小技巧：Penpot支持直接把整个画板以SVG格式导出。遇到那种需要前端一比一还原的复杂图形，写上SVG导出给开发作为底稿，比自己用CSS硬画实现要快得多。当然，这个需要开发那边会读写SVG，不是所有团队都适用，但对我们技术型团队来说非常高效。

4. 我踩过的坑：常见问题排查与避坑指南

4.1 字体问题：自托管环境最容易被绊倒的地方

这个问题值得再拿出来强调一次。自托管Penpot的字体问题，基本集中在两个场景。

第一个场景是设计稿里用了团队其他成员电脑上没有的字体。你本机渲染很好，别人一打开就变了样。解决办法就是我前面讲的：服务端挂载字体目录，或者在团队资源里上传字体文件。挂载字体后，一定要重启后端容器让它重新扫描字体目录，只重启前端容器是不生效的。

第二个场景是从Figma导入文件时字体缺失。Figma里的很多商业字体，Penpot环境里根本没有，导入后自动替换成默认字体，版面会乱。我的经验是：在Figma里先把所有文字图层转成“轮廓化”再导出导入，虽然不能再编辑文字，但版面能保住。如果后续还要在Penpot里改字，那就只能逐个去重新设置字体样式。

另外提醒一点：字体文件不要贪多。挂载上百个字体后，Penpot后端启动时扫描字体的时间会明显变长，设计器里字体下拉菜单也会变得很长。保持一个精选的字体集，反而有利于团队规范落地。

4.2 GitHub下载与镜像：安装资源获取的替代方案

有朋友部署时卡在了GitHub访问和下载上。这个问题的解法其实多样，我个人经验是优先绕开GitHub。

第一个思路是直接用Docker镜像，而不要执着于GitHub仓库本身。Penpot的官方镜像都发布在Docker Hub上，你只要在服务器上配置好镜像拉取：

docker pull penpotapp/backend:latest docker pull penpotapp/frontend:latest

拉到本地后，再配合Compose文件启动即可。这样GitHub访问问题基本不存在了。

第二个思路是下载ZIP包。GitHub仓库页面提供“Download ZIP”功能，下载整个仓库的压缩包通常比git clone稳定、快速，尤其适合一次性部署场景。如果你需要的是某个发布版本的固定代码，可以从Release页面下载对应的Source code归档。

第三个思路是GitHub仓库的国内镜像。国内不少代码托管平台支持同步GitHub仓库，你也可以在Gitee上搜索热心用户维护的Penpot镜像仓库，用镜像完成clone后再切换回原仓库的远程地址。镜像仓库的责任人各不相同，同步时效不一定及时，但用于部署获取一次性的代码包，问题不大。

还有一个我自己常用的小技巧：如果你只需要在某台服务器上安装，不需要完整的Git历史，直接下载ZIP解压，省去了clone带来的网络压力，也更适合一次性部署。

4.3 性能卡顿与大文件问题

Penpot是浏览器应用，性能上限很大程度取决于浏览器。我用下来，Chrome和Edge的表现明显优于其他内核。在自托管系统的设置里也建议主动开启硬件加速，模糊特效和大画布操作会顺滑很多。

有几次同事反馈“画布拖不动”，排查之后发现是设计稿里用了大量的模糊效果和透明阴影。这类效果在浏览器渲染中特别吃资源，尤其是整页全局模糊，基本能把帧率拉到个位数。我的建议是：在草稿阶段尽量少用实时模糊，采用一次性导出的静态位图代替；等定稿后再局部加效果，整体体验会好很多。

大文件也是自托管环境下一道坎。一个几百兆的项目文件，在低配服务器上打开时会明显卡顿。我的处理方式是：把项目按模块拆分，比如官网一个文件、后台一个文件、移动端一个文件，而不是所有画板全塞进一个文件。Penpot的文件结构支持团队里创建多个项目，多个文件之间通过组件库共享基础样式，这样既控制单文件大小，又保持设计规范的统一性。

还有一个常被忽略的问题：自托管服务器的带宽。如果服务器上行带宽太小，多人同时打开大文件时，加载会非常慢。我自己把静态资源做了CDN加速之后，体验改善明显，但如果你只是内网使用，这一步可以省略。

4.4 从Figma迁移：导入工具链与转换限制

Penpot官方做了一个Figma导入工具，入口在penpot.app的Figma导入页面。整体流程不算复杂：

1. 在Figma中复制需要迁移的文件链接；
2. 打开Penpot的Figma导入页面，用你的Figma账号生成一个token并输入；
3. 提交后，Penpot会在云端生成一个.penpot文件；
4. 下载这个文件，在Penpot工作台里导入。

听起来很简单，但我要提醒几个实际会遇到的限制。

第一，组件和变体的映射不是百分百完整。Figma里的复杂组件嵌套，导入后可能会退化成普通组，变体状态可能丢失。如果原文件重度依赖组件库，导入后需要花时间重建。第二，交互逻辑不确定性较高。Figma里的Prototype连线，导入到Penpot后可能不会还原成交互，需要重新在Penpot里做一遍。第三，字体问题前面说过，导入前建议先统一下字体。

如果你是第一次迁移，我的建议是先挑一个小文件试水，跑通流程后建立自己的导入规范文件，再逐步迁移大文件。别一次性把整个Figma团队文件全部导入，否则后期整理成本很高。

4.5 实用速查表

4.6 团队协作与权限管理的补充经验

最后补一个很多团队容易忽略的点：Penpot的权限系统虽然不如Figma细，但基础够用。团队里可以设置管理员、编辑者、查看者角色。我给团队定的规矩是：设计师给编辑权限，开发和产品默认只给查看权限。这样能防止有人误改画板里的设计稿，评审时也只读不走样。

协作方面，Penpot支持多人同时编辑同一个文件，能看到在线用户的光标。它的实时协作能力已经能满足日常使用，但我不建议两个设计师同时改同一个复杂组件的边界情况，因为并发冲突时版本合并的体验还比不上Figma。我的习惯是：大改之前先在团队里喊一声，或者用画板的图层锁定功能把正在编辑的部分锁住，避免互相覆盖。

作为管理员，定期看一下后台的用户列表和存储用量，把不活跃的僵尸账号清理掉，不仅更安全，还能减少存储负担。国内团队尤其建议开启强制邮箱验证，避免有人随便填个邮箱就能注册进来，给自托管系统留下安全隐患。

5. 写在最后：我对Penpot的真实评价

从我自己把团队迁移到Penpot的那一天起，我对它的态度就分得很清楚：它不是Figma的完美复刻，而是一个适合特定需求场景的开源设计平台。如果你追求插件的丰富程度、极致的交互原型表现力、以及完整的企业级协作生态，Figma依然是更省心的选择。但如果你需要把设计数据放在自己的服务器上，希望设计规范和组件库完全可控，或者你只是想在开源工具上折腾点什么，Penpot给你的自由度，是闭源云端工具给不了的。

我实际用下来，Penpot 2.0之后的版本进步速度非常快，自动布局、样式资源、团队资源面板这些补上来之后，已经能承接正式的UI设计项目。我现在会建议那些本身就走自托管路线的团队，直接用Penpot做内部所有非高保真设计稿，然后用它产出可点击原型给客户演示，整套流程跑下来确实省下了不少工具订阅费。

最后再分享一个我在实际使用中最深的体会：把一个设计工具纳入团队技术栈，从来不是“它功能更多”就赢，而是“它适不适合你的协作方式和数据要求”。Penpot用一年下来，最让我踏实的不是省了多少钱，而是所有设计资产都握在自己手里，出任何问题都有办法兜底。这种掌控感，用过的应该都懂。