企业官网建设流程全解析

1. 从一次团队续费争议说起：为什么“放弃Figma”这个话题突然变得真实

去年年底，我们团队在续费评审会上第一次认真讨论了“要不要换掉 Figma”。原因很朴素：设计席位又涨了，而团队里真正每天打开 Figma 的人，其实只有三位设计师，其余七八个前端、产品、运营都只是偶尔进去看稿、评论、导出切图。按人头买全功能席位，这笔账怎么算都不划算。

这不是我一个人的感受。最近一段时间，关于 Figma 的讨论明显变了味道——以前大家聊的是“这个插件真好用”“这个自动布局怎么玩”，现在聊的更多是“汉化怎么搞”“客户端中文怎么设置”“MCP 怎么接到开发工具里”“能不能直接切图”。这些热搜词背后其实藏着一个共同的信号：大家不再把 Figma 当成唯一答案，而是在评估它的替代成本与迁移收益。

开源设计工具这条线，这两年确实起来了。Penpot 是最常被拿来对比的一个，OpenPencil 这类新面孔也在冒头，再加上 BYOK（Bring 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 能读取设计稿的结构信息，然后生成对应的代码。

我实测过类似的流程，大致分几步：

1. 设计稿结构化：确保图层命名规范、组件结构清晰。AI 读不懂“矩形 123”这种命名，但能理解“Button/Primary”。
2. 建立连接：通过 MCP 或类似协议，把设计工具的结构数据暴露给 AI 开发工具。
3. 生成与校对：AI 生成代码后，人工校对布局、间距、响应式行为。这一步不能省，AI 生成的代码在细节上经常需要调整。
4. 切图与资源：图片、图标这类资源，AI 通常不能直接“切”出来，还是需要从设计工具导出，或者用工具提供的导出能力。

提示：AI 生成代码目前更适合做“初稿”，把重复性的布局代码生成出来，人再改。指望它一步到位生成可上线的代码，现阶段还不现实。

4.3 开源 + BYOK 组合的适用边界

这套组合不是万能的。我总结了几种适合和不适合的情况：

适合的情况：

• 团队有一定技术能力，能自己配置 API Key、维护工具链
• 对数据自主有要求，不希望设计稿存在第三方服务器
• 项目以中低复杂度界面为主，不需要 Figma 那些高级原型能力
• 愿意接受“工具还在快速迭代、偶尔有 bug”的状态

不适合的情况：

• 团队完全没有技术维护能力，只想开箱即用
• 项目重度依赖复杂组件系统和精细原型交互
• 需要和大量外部合作方交换设计文件，格式兼容性是硬需求

工具选型最怕的就是“因为免费所以选它”，结果用起来处处别扭。先明确你的核心需求，再看哪个工具能接住，而不是反过来。

5. 迁移决策的实操框架：什么情况下该换，什么情况下别折腾

5.1 一张自测表帮你判断迁移优先级

我把迁移决策拆成了几个维度，你可以对着自己的情况打个分：

如果“倾向迁移”的项明显多于“倾向留下”，那迁移是值得认真评估的；如果两边差不多，我建议先做小范围试点，别一次性全量切换。

5.2 小步试点的具体做法

全量迁移风险太高，我的建议是先拿一个真实但非核心的项目做试点。具体步骤：

1. 选项目：挑一个周期短、参与人少、失败影响可控的项目。
2. 双轨并行：试点期间 Figma 和开源工具同时保留，避免影响正常交付。
3. 记录摩擦点：把每个“卡住”的瞬间记下来，这些就是迁移的真实成本。
4. 复盘决策：试点结束后，看摩擦点是“可解决”还是“结构性缺陷”，再决定是否扩大范围。

我自己的经验是，试点阶段最容易暴露的不是工具功能问题，而是人的习惯问题。比如有人就是不愿意学新快捷键，有人觉得“还是 Figma 顺手”。这些声音要听，但也要区分“真的影响效率”和“单纯不想变”。

5.3 迁移过程中最容易翻车的三个点

第一，字体和中文显示。这是设计师最敏感的地方。迁移前一定要确认新工具对中文字体的支持情况，包括字体安装、渲染效果、导出是否正常。别等到设计稿做完才发现中文显示有问题。

第二，版本与备份。自托管方案如果没做好备份，一次误操作可能丢一批稿子。我建议迁移初期把备份频率调高，稳定之后再恢复正常节奏。

第三，对外协作的兼容性。如果你的团队经常和外部设计师、甲方交换文件，要提前确认对方能不能打开你导出的格式。开源工具通常支持导出通用格式，但导入方的体验可能参差不齐。

注意：迁移不是“换一个软件”那么简单，它是一次工作流的重建。把预期放低一点，把准备做足一点，成功率会高很多。

6. 我个人的选择与几条实在建议

说说我自己的情况。我们团队最后没有全量迁移，而是做了混合方案：核心设计工作留在 Figma，因为复杂组件和原型能力确实还离不开；但把“查看、评论、轻量标注”这部分需求分流到了自托管的 Penpot 上，省下了一批协作席位的费用。同时我们在试点 BYOK 的 AI 生成代码链路，让前端从重复的布局代码里解放出来。

这个方案不完美，但它是我们团队当前能力和需求下的平衡点。工具选型从来不是“哪个最好”，而是“哪个最适合你现在的状态”。

几条实在建议，给正在纠结的你：

• 别为了省钱而迁移，要为了解决问题而迁移。如果 Figma 用得好好的、预算也不紧张，那没必要折腾。
• 先算清楚真实成本，再谈工具优劣。席位费、维护时间、学习成本、迁移损耗，这些都要算进去。
• 小步试点永远比全量切换稳。拿一个真实项目跑一遍，比看一百篇对比文章都有用。
• 关注数据自主这条线。如果你的设计资产涉及敏感信息，自托管的价值会随着时间越来越明显。
• AI 链路值得提前布局。不管你现在用不用，把设计稿结构规范化、图层命名规范化，这些准备工作对将来接任何 AI 工具都有好处。

最后分享一个小技巧：如果你决定试 Penpot 或类似工具，先别急着导入整个项目，拿一个页面级别的文件试手。导入、编辑、导出、再导入，走完一个完整循环，你就知道这个工具能不能接住你的活了。这比任何评测都直接。