1. 从一次团队续费争议说起为什么“放弃Figma”这个话题突然变得真实去年年底我们团队在续费评审会上第一次认真讨论了“要不要换掉 Figma”。原因很朴素设计席位又涨了而团队里真正每天打开 Figma 的人其实只有三位设计师其余七八个前端、产品、运营都只是偶尔进去看稿、评论、导出切图。按人头买全功能席位这笔账怎么算都不划算。这不是我一个人的感受。最近一段时间关于 Figma 的讨论明显变了味道——以前大家聊的是“这个插件真好用”“这个自动布局怎么玩”现在聊的更多是“汉化怎么搞”“客户端中文怎么设置”“MCP 怎么接到开发工具里”“能不能直接切图”。这些热搜词背后其实藏着一个共同的信号大家不再把 Figma 当成唯一答案而是在评估它的替代成本与迁移收益。开源设计工具这条线这两年确实起来了。Penpot 是最常被拿来对比的一个OpenPencil 这类新面孔也在冒头再加上 BYOKBring Your Own Key自带密钥这种把 AI 能力接进设计流程的思路整个格局从“Figma 一家独大”变成了“多选项并存”。所以这篇不打算给你一个“换”或“不换”的结论而是把这件事拆开你到底在为什么付费、开源工具能接住哪些活、迁移过程中哪些坑是文档里不会写的。如果你是小团队负责人、独立开发者、或者正在被设计工具预算卡脖子的从业者这篇内容应该能帮你把决策逻辑理清楚。我会尽量说人话把每个选择的“为什么”讲透而不是甩一堆功能对比表让你自己猜。2. 先搞清楚你为 Figma 付的钱到底买到了什么2.1 席位模型背后的真实成本结构很多人算 Figma 成本时只看了单价乘以人数但真正的成本结构比这复杂。Figma 的席位大致分几档设计席位可以编辑、协作席位只能查看评论、以及各种组织级的管理能力。问题在于大部分团队的实际使用是“少数人重度编辑、多数人轻度查看”但采购时往往一刀切买了编辑席位。我见过一个典型场景一个 15 人的产品团队3 个设计师、4 个前端、2 个产品经理、6 个其他角色。如果全买编辑席位一年下来是一笔不小的固定支出如果只给设计师买编辑席位其他人用协作席位又会出现“前端想微调一下间距都不行”的尴尬。这个矛盾不是 Figma 独有的而是所有按席位收费的 SaaS 工具的通病。所以当你问“要不要放弃 Figma”时第一个要回答的问题不是“开源工具好不好”而是你的团队里到底有多少人需要真正的编辑权限。如果答案是“不到三分之一”那成本优化的空间就已经存在了换不换工具只是手段之一。2.2 那些被忽略的“隐性依赖”Figma 真正难替代的地方往往不是画图本身而是它长出来的生态。举几个我自己踩过的例子插件依赖团队里有人用某个插件做批量重命名、有人用另一个做图标管理这些插件一旦换平台就得重新找替代品有些根本没有对应实现。字体与汉化Figma 桌面端的中文显示、字体安装、汉化插件这些看起来是小事但真到迁移时设计师第一句话就是“中文能正常显示吗”。开发对接链路现在很多人把 Figma 通过 MCP 接到 AI 开发工具里实现“设计稿直接生成代码”的流程。这条链路一旦建立迁移成本就不只是换个画图工具而是要重建整条工作流。提示评估迁移成本时别只列功能清单要把“谁依赖了什么插件、哪条自动化链路会断”一起列出来这才是真实成本。2.3 开源工具省的是钱但可能花的是时间开源设计工具最大的卖点是“免费”和“数据自主”。Penpot 可以自托管代码在你自己的服务器上不用担心哪天服务条款变了、价格涨了。但这里有个容易被低估的点自托管意味着你要自己维护服务器、处理升级、保证可用性。对于没有运维能力的小团队这部分隐性成本可能比省下的订阅费还高。我个人的判断标准是这样的如果团队里有人愿意并且有能力维护一套自托管服务那开源方案的性价比会非常高如果所有人都只想“打开就能用”那托管版或者继续用 SaaS 反而更省心。工具选型从来不是纯技术问题而是“你的团队愿意为什么付出”。3. Penpot 到底能接住多少活一次真实的迁移测试3.1 从 Figma 导入 Penpot 的实际体验Penpot 官方提供了从 Figma 导入的能力我拿一个中等复杂度的项目实测了一遍。结论是基础图层、画板、颜色样式、文本样式这些能过来但自动布局、部分组件变体、复杂交互原型会有损耗。具体来说导入之后我遇到的情况是元素类型导入结果需要手动处理的程度基础形状与画板基本完整几乎不用动颜色与文本样式大部分保留少量需要重新绑定自动布局部分丢失需要重建组件变体结构可能打散需要重新组织交互原型基本不保留需要重做这个结果其实在预期之内。任何跨工具迁移都不可能 100% 无损关键是损耗的部分是不是你的核心资产。如果你的项目以静态页面和简单组件为主迁移成本可控如果重度依赖自动布局和复杂组件系统那迁移就是一次重构。3.2 自托管 Penpot 的环境准备与踩坑如果你决定走自托管路线Penpot 官方提供了 Docker 部署方案。我按官方文档走了一遍整体流程是清晰的但有几个细节值得提前知道。首先是资源要求。Penpot 的后端、前端、数据库、对象存储这几块加起来对内存和磁盘都有一定要求。我一开始在一台配置偏低的机器上试导入大文件时明显卡顿后来加了内存才顺畅。所以别拿一台闲置的低配机器就上先估算一下团队的项目规模。其次是版本升级。自托管最怕的就是“装完就不管了”等哪天想升级发现数据库结构变了、迁移脚本跑不通。我的做法是固定一个版本周期每次升级前先备份数据库和对象存储在测试环境验证一遍再上生产。这套流程听起来麻烦但比出事之后救火省事得多。# 备份数据库的基本思路以 PostgreSQL 为例 pg_dump -U penpot -h localhost penpot penpot_backup_$(date %Y%m%d).sql # 备份对象存储目录 tar -czf assets_backup_$(date %Y%m%d).tar.gz /path/to/penpot/assets注意自托管方案一定要把备份做成例行任务而不是“想起来才做”。设计资产丢了比工具难用严重得多。3.3 团队协作习惯的迁移才是真正的难点工具换了人的习惯不会自动跟着换。我观察到的几个典型摩擦点评论与评审流程Figma 里大家习惯在画板上直接圈选评论Penpot 也有类似能力但入口和交互不一样需要给团队做一次简单的上手说明。版本管理心智Figma 的版本历史大家用得很随意Penpot 的版本机制逻辑不同设计师需要重新建立“什么时候存版本”的习惯。开发交付方式以前前端习惯从 Figma 直接看标注、导出切图换到 Penpot 后要重新约定交付规范否则会出现“设计师以为给了、前端找不到”的情况。这些都不是技术问题但它们是迁移能否真正落地的关键。我的经验是换工具之前先花半天时间把新工具的协作流程走一遍让团队里最挑剔的那个人先试用把问题提前暴露出来。4. OpenPencil 与 BYOK开源设计工具的另一条路线4.1 OpenPencil 这类新工具在解决什么问题如果说 Penpot 是“开源版的 Figma”那 OpenPencil 这类工具走的是另一条路——更轻、更聚焦、更强调与 AI 能力的结合。它不追求把 Figma 的所有功能都复刻一遍而是把“设计到代码”这条链路做得更顺。这个思路其实很聪明。因为对于很多团队来说Figma 里 80% 的高级功能根本用不上真正高频的就是“画界面、给标注、导出资源、对接开发”。如果有一个工具能把这四件事做好同时把 AI 生成代码的能力接进来那它对一部分团队来说就是更优解。BYOK 这个概念在这里就派上用场了。它的意思是工具本身不绑定某一家 AI 服务而是让你自己填入 API Key用你自己的额度、自己的模型。这样做的好处是成本可控、数据流向清晰、不被单一供应商锁定。对于在意数据自主的团队这个设计比“内置 AI 但不知道数据去哪了”要让人放心得多。4.2 把设计稿接到 AI 开发流程的实际链路现在很多人关心的是“Figma MCP 怎么接到开发工具里”“能不能直接切图”。这条链路的本质是让 AI 能读取设计稿的结构信息然后生成对应的代码。我实测过类似的流程大致分几步设计稿结构化确保图层命名规范、组件结构清晰。AI 读不懂“矩形 123”这种命名但能理解“Button/Primary”。建立连接通过 MCP 或类似协议把设计工具的结构数据暴露给 AI 开发工具。生成与校对AI 生成代码后人工校对布局、间距、响应式行为。这一步不能省AI 生成的代码在细节上经常需要调整。切图与资源图片、图标这类资源AI 通常不能直接“切”出来还是需要从设计工具导出或者用工具提供的导出能力。提示AI 生成代码目前更适合做“初稿”把重复性的布局代码生成出来人再改。指望它一步到位生成可上线的代码现阶段还不现实。4.3 开源 BYOK 组合的适用边界这套组合不是万能的。我总结了几种适合和不适合的情况适合的情况团队有一定技术能力能自己配置 API Key、维护工具链对数据自主有要求不希望设计稿存在第三方服务器项目以中低复杂度界面为主不需要 Figma 那些高级原型能力愿意接受“工具还在快速迭代、偶尔有 bug”的状态不适合的情况团队完全没有技术维护能力只想开箱即用项目重度依赖复杂组件系统和精细原型交互需要和大量外部合作方交换设计文件格式兼容性是硬需求工具选型最怕的就是“因为免费所以选它”结果用起来处处别扭。先明确你的核心需求再看哪个工具能接住而不是反过来。5. 迁移决策的实操框架什么情况下该换什么情况下别折腾5.1 一张自测表帮你判断迁移优先级我把迁移决策拆成了几个维度你可以对着自己的情况打个分评估维度倾向留下倾向迁移团队编辑席位占比高多数人需要编辑低少数人编辑多数人查看插件依赖程度重度依赖特定插件插件用得少或可替代数据自主需求无所谓有明确合规或自主要求技术维护能力无有专人可维护自托管项目复杂度高复杂组件、原型中低静态页面为主外部协作频率高频繁对外交换文件低内部闭环为主如果“倾向迁移”的项明显多于“倾向留下”那迁移是值得认真评估的如果两边差不多我建议先做小范围试点别一次性全量切换。5.2 小步试点的具体做法全量迁移风险太高我的建议是先拿一个真实但非核心的项目做试点。具体步骤选项目挑一个周期短、参与人少、失败影响可控的项目。双轨并行试点期间 Figma 和开源工具同时保留避免影响正常交付。记录摩擦点把每个“卡住”的瞬间记下来这些就是迁移的真实成本。复盘决策试点结束后看摩擦点是“可解决”还是“结构性缺陷”再决定是否扩大范围。我自己的经验是试点阶段最容易暴露的不是工具功能问题而是人的习惯问题。比如有人就是不愿意学新快捷键有人觉得“还是 Figma 顺手”。这些声音要听但也要区分“真的影响效率”和“单纯不想变”。5.3 迁移过程中最容易翻车的三个点第一字体和中文显示。这是设计师最敏感的地方。迁移前一定要确认新工具对中文字体的支持情况包括字体安装、渲染效果、导出是否正常。别等到设计稿做完才发现中文显示有问题。第二版本与备份。自托管方案如果没做好备份一次误操作可能丢一批稿子。我建议迁移初期把备份频率调高稳定之后再恢复正常节奏。第三对外协作的兼容性。如果你的团队经常和外部设计师、甲方交换文件要提前确认对方能不能打开你导出的格式。开源工具通常支持导出通用格式但导入方的体验可能参差不齐。注意迁移不是“换一个软件”那么简单它是一次工作流的重建。把预期放低一点把准备做足一点成功率会高很多。6. 我个人的选择与几条实在建议说说我自己的情况。我们团队最后没有全量迁移而是做了混合方案核心设计工作留在 Figma因为复杂组件和原型能力确实还离不开但把“查看、评论、轻量标注”这部分需求分流到了自托管的 Penpot 上省下了一批协作席位的费用。同时我们在试点 BYOK 的 AI 生成代码链路让前端从重复的布局代码里解放出来。这个方案不完美但它是我们团队当前能力和需求下的平衡点。工具选型从来不是“哪个最好”而是“哪个最适合你现在的状态”。几条实在建议给正在纠结的你别为了省钱而迁移要为了解决问题而迁移。如果 Figma 用得好好的、预算也不紧张那没必要折腾。先算清楚真实成本再谈工具优劣。席位费、维护时间、学习成本、迁移损耗这些都要算进去。小步试点永远比全量切换稳。拿一个真实项目跑一遍比看一百篇对比文章都有用。关注数据自主这条线。如果你的设计资产涉及敏感信息自托管的价值会随着时间越来越明显。AI 链路值得提前布局。不管你现在用不用把设计稿结构规范化、图层命名规范化这些准备工作对将来接任何 AI 工具都有好处。最后分享一个小技巧如果你决定试 Penpot 或类似工具先别急着导入整个项目拿一个页面级别的文件试手。导入、编辑、导出、再导入走完一个完整循环你就知道这个工具能不能接住你的活了。这比任何评测都直接。
