企业官网建设流程全解析

做设计工具选型这几年，Figma几乎成了默认答案。但用过一段时间后，很多人心里其实会冒出一个问题：如果我不想把整个团队的源文件都放在别人服务器上，有没有别的选择？Penpot 就是我在这个命题下试出来的一条路——一个开源的、可以私有部署的、甚至能接上大模型的设计工作台。我前后折腾了差不多一周，把 Penpot 跑在了一台云服务器上，配好了反向代理和备份策略，又给它接了一个本地大模型用来干一些“脏活累活”。这篇文章想把整套思路和踩坑过程完整写出来，给那些正在纠结“Figma 之外还能用啥”的设计师、前端工程师和小团队负责人参考。

我知道很多人听到“自部署设计工具”第一反应是：会不会很麻烦？功能会不会少得没法用？我一开始也是这么想的。但实际跑下来，Penpot 的成熟度比我预期高不少，核心的矢量编辑、组件样式、多页画板、多人实时协作都有，数据完全在自己手上。更关键的是，它给了你一个干干净净的底座，往上接大模型、做自动化流程、定制团队内部的工具链，都变成可落地的事情。这篇文章不聊虚的，所有内容都来自我实际部署、配置、接入模型和日常使用的真实过程。

1. 为什么是 Penpot：Figma 之外的第二选择到底解决什么问题

1.1 Figma 的痛点：费用、数据与定制能力

先说清楚一个事实：Figma 本身是优秀的产品，设计体验、插件生态、协作流畅度都是行业标杆。但它在几个方向上让一部分团队越来越难受。

第一是费用模型。免费版对文件数量、协作人数都有限制，团队一旦上了规模，人均月费很快就变成一个不小的数字。很多小团队预算有限，并不想为了“画个原型”背上长期的订阅成本。第二是数据主权。设计源文件、品牌资产、还没发布的产品方案，全都存在别人的云端。对注重知识产权的公司来说，这属于不可接受的隐患，合规审计的时候格外头疼。第三是定制能力。虽然 Figma 有 API 和插件，但核心功能、服务端逻辑、权限体系都是封闭的，团队想接入内部系统、做深度自动化，始终隔着一层。第四是网络体验。部分地区访问 Figma 服务的速度和稳定性不稳定，团队协作时经常出现同步延迟、图片加载半天的情况。

这些问题叠加在一起，让我开始认真考察开源替代品。市面上的选项其实不少：Penpot、Lunacy、Figma 的开源克隆项目等等。最终我选择 Penpot 的原因概括起来有三条：它是真正 Web 原生的产品，不需要装客户端，打开浏览器就能用，和团队的远程协作场景天然匹配；它的开发团队来自 Kaleidos 这家公司，项目持续维护了很多年，社区活跃度稳定；它从底层就设计成可以被托管，官方提供完整的 Docker Compose 编排，数据存储落在 PostgreSQL 里，这意味着备份、迁移、二次开发都有清晰路径。

1.2 Penpot 的核心定位：开源、自托管、Web 原生

Penpot 官方给自己的定位是“Design and prototyping platform for product teams”，但实际上它的亮点在于“开放”。整个前端和后端都能在代码仓库里看到，你可以根据自己的需求改界面、改逻辑、加功能，不受商业产品的路线图约束。它的编辑模型基于 SVG，画布上生成的元素本身就是标准矢量图形，导出质量非常高，和前端工程化流程天然亲和。另一个细节是它内置了开发者模式，选中一个元素就能直接查看对应的 CSS 属性、样式代码、布局计算，方便设计师和前端围绕同一份设计语言对稿。

从技术架构上看，Penpot 没有采用桌面壳套 Web 的办法，而是纯浏览器渲染，因此部署之后团队成员只需要浏览器就能访问。服务端依赖 PostgreSQL 存核心数据，Redis 做缓存和任务队列，另一个 Exporter 服务专职处理 PDF、PNG 等格式的导出任务。整体架构不复杂，一台 4GB 内存的小服务器跑起来绰绰有余。这一点和 Figma 那种重云端协作的产品形成鲜明反差，也让“自己掌握基础设施”成为可能。

对于团队负责人来说，Penpot 最大的价值并不是“省了几个订阅费”，而是把基础设施主动权拿了回来。你可以把服务部署在内网，源文件永不离开公司网络；你可以控制用户注册方式，限制谁能看到什么项目；你可以把大模型能力直接接进设计流程，而不是等着某个商业产品哪一天突然上线类似功能。这些能力组合起来，就是一套私有的、可演进的设计工作台。

2. 私有部署实操：一个可用的 Penpot 平台是怎么跑起来的

2.1 环境准备与部署方式选型

Penpot 官方提供了好几种部署模式：标准三层架构、单机最小模式、以及面向开发者的本地运行模式。对绝大多数团队来说，直接采用官方在 GitHub 上维护的 Docker Compose 编排文件是性价比最高的路线。不需要手工装 PostgreSQL、Redis、Node 这些组件，一条命令就能把整套服务拉起。

硬件方面我建议至少给 2 核 CPU、4GB 内存。Penpot 后端是 Clojure 写的，吃内存比一般 Node 应用多一点，画布操作密集的场景下 CPU 也要跟上。如果团队人数超过 20，建议 4 核 8GB 起步。磁盘方面，设计数据和上传的字体文件最终都落在 PostgreSQL 里，所以建议给数据库单独挂一块 SSD 数据卷。操作系统我用的 Ubuntu 22.04，Docker 版本 24 以上，Docker Compose 插件也要一起装好。这里有个小经验：如果是国内云服务器，注意选一个带宽充足、到对象存储等外部服务链路稳定的机器，后面如果用到大模型 API，服务器到模型服务的网络延迟直接影响体验。

部署之前，先规划好几个东西：域名或访问 IP、对外暴露的端口、是否需要 HTTPS、是否要限制注册。我在实际部署中把前端端口映射到了宿主机 8080，方便本机预览；对外访问则通过 Nginx 反向代理到 443 端口，证书用免费申请的通配证书搞定。如果你不想搞域名，直接用 IP 访问也能用，但一些浏览器特性（比如剪贴板、摄像头权限）在 HTTP 环境下会受限，建议老老实实上 HTTPS。

2.2 编排文件、环境变量与启动细节

Penpot 的官方仓库里有一个docker-compose.yaml，里面定义了前端、后端、Exporter、数据库、Redis 等服务。我不建议自己从头写编排，直接拿官方模板改环境变量最稳。主要需要关注的环境变量有这么几组：数据库连接地址、Redis 地址、JWT 密钥、公开端点地址、SMTP 邮件配置、用户注册策略。

启动流程很简单，但有几个细节我踩过坑：

# 1. 克隆或下载官方编排模板 git clone https://github.com/penpot/penpot.git cd penpot/docker # 2. 复制环境变量模板 cp .env.example .env # 3. 编辑 .env，把数据库密码、密钥、域名都填好 vim .env # 4. 启动整套服务 docker compose up -d # 5. 查看服务是否正常 docker compose ps docker compose logs -f penpot-backend

首次启动时，后端会自动初始化数据库结构，不需要手动跑迁移脚本。等前端服务起来了，浏览器打开http://你的服务器IP:8080，能看到登录页，说明这套平台已经跑通了。这里有个关键点：如果改了.env里的域名，前后端都需要能解析到同一个域名，否则登录后跳转异常、文件打不开。我遇到过几次这种问题，最后排查下来都是环境变量里PENPOT_PUBLIC_URI没写对，导致后端生成的链接地址不对。

另一个容易忽视的是PENPOT_FLAGS。这个变量可以控制很多功能开关，比如关闭注册、启用认证、禁用公开页面等。我建议团队内部部署时把它配置成关闭开放注册，只允许管理员手动创建账号，避免有人把内部设计平台当成公测产品随便注册。

2.3 反向代理与 HTTPS 配置

Penpot 前后端通过 WebSocket 保持实时协作同步，所以反向代理必须支持 WebSocket 连接升级，否则多人同时编辑时会出现“改了内容别人看不到”的诡异现象。我的 Nginx 配置里有一段专门处理这类请求：

server { listen 443 ssl; server_name design.example.com; ssl_certificate /etc/nginx/certs/design.example.com.pem; ssl_certificate_key /etc/nginx/certs/design.example.com.key; location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }

注意Connection "upgrade"这行不能少，少了 WebSocket 必断。有的 Nginx 配置还会对请求体大小做限制，Penpot 导入大图片时如果出现 413 错误，记得在http或server块里调大client_max_body_size。我设成了 100m，上传设计资源和字体文件基本够用。另外，如果你在 Nginx 层做了缓存，一定要对 WebSocket 路径取消缓存，否则协作消息会被缓存服务吞掉。

2.4 数据初始化与日常备份策略

启动完成后，第一个要做的就是创建管理员账号。Penpot 的初始化没做得很傻瓜化，不像有些系统第一次访问会弹个安装向导。我是直接注册一个账号，然后进数据库手动把该账号提升为管理员；或者更简单的办法是配置好 SMTP 后，用后端命令行的方式创建管理员。具体方式官方文档里有说明，实际操作时我用的是手动标记 auth 表里用户角色的方案，几分钟搞定。

备份是整套自部署方案里最不能省的环节。因为 Penpot 的设计数据全部存在 PostgreSQL 的 Large Object 里，所以现场数据备份就等于数据库备份。我写了一个简单的定时任务，每天凌晨用pg_dump导出数据库，然后推到对象存储的私有桶里：

#!/bin/bash BACKUP_DIR="/data/backups/penpot" DATE=$(date +%F) docker compose exec -T db pg_dump -U penpot -F c penpot > "$BACKUP_DIR/penpot_$DATE.dump" find "$BACKUP_DIR" -type f -mtime +30 -delete

恢复流程也验证过：新服务器装好同样版本的 Penpot 后，停止后端服务，用pg_restore把备份导回数据库，再启动服务即可。这里要强调一点：备份恢复必须保证 Penpot 主版本一致，跨版本恢复容易出现 SVG 数据格式兼容问题。我吃过一次亏，从旧版本备份恢复到新版时，画布里的部分文字样式丢失了，后来只能回到旧版本重新导出备份。所以升级 Penpot 前，一定先手动打一个完整备份。

3. 给设计工作台装“大脑”：Penpot 接入大模型的全过程

3.1 设计场景里，大模型到底能帮上什么忙

很多人听到“设计工具接大模型”第一反应是“AI 一键生成海报”。这种想法当然没错，但落地时真正高频、真正能产生实际价值的，往往是那些不起眼的小任务。我在实际使用中整理了这么几个典型场景：

文案填充是最直接的一个。设计稿里常常需要给按钮、Banner、弹窗填示例文案，人工一个个写又慢又无聊。让大模型根据产品描述生成一组适合同一个设计系统的文案，再手动挑一个放进画布里，效率完全不一样。图层命名也特别实用。设计团队交付前最烦的一件事就是把几十上百个图层从“矩形 12”改成“按钮-主操作-默认态”。把图层结构描述抛给大模型，让它生成语义化命名，再通过脚本批量回写，这活儿原本要半小时，现在变成一分钟的事。

配色建议和样式辅助也值得接。大模型对于色彩心理学、可访问性对比度是有一定知识储备的，选了一套主色之后，让它生成配套的辅色、强调色、背景色，可以作为设计师的灵感参考。代码转 SVG 也可以做：直接让模型根据描述生成一段 SVG 代码，粘贴进 Penpot 画布。它生成的图形可能不是很精细，但作为草稿和占位，比从零画快得多。

3.2 本地大模型还是云端 API：选型对比

接入大模型之前，必须先做一次关键的方案选型：到底是调用云端公开的大模型 API，还是在自己的服务器上部署一个开源模型。两种方式各有适用场景，我用一张表把区别列出来：

我的做法是两条腿走路：非敏感的设计辅助任务走云端 API，速度快、效果好；涉及内部产品留资信息、未公开功能设计的任务一律走本地模型。本地模型我用的方案是 Ollama，它在把模型跑在个人服务器这件事上做得非常顺手，一条命令就可以把 Qwen、Llama 等开源模型拉下来提供服务。硬件压力确实存在，我用一台带 NVIDIA 显卡的工作站跑 7B 量级的量化模型，生成文案和命名足够用了；如果只是纯 CPU，可以选 3B 小模型，速度和效果都在可接受的范围内。

从接口兼容性来看，Ollama 提供了 OpenAI 兼容的 API 路径，调用方式几乎一模一样。这意味着你写的插件代码不需要针对不同来源写两套：只要把 Base URL 换成 Ollama 的地址，就能从云端 API 无缝切到本地模型。我实际测试下来，从云 API 切到本地模型只改了一个配置项，其余代码完全复用，这个兼容性设计让整个接入过程省了很多事。

3.3 用插件机制把大模型接进画布

Penpot 自身具备插件开发能力，可以通过官方 API 操作画布上的元素。插件通常由一个 manifest 文件声明权限和元数据，再加载一段 JavaScript。下面是一个精简示例，我在 Penpot 插件开发环境里验证过，主要思路是用penpot.selection拿到当前选中的元素，然后调用模型接口生成文案，最后写回文本节点：

{ "name": "AI Copy Writer", "description": "Using LLM to generate copy for selected text layers", "version": "1.0.0", "permissions": ["content:read", "content:write", "file:read"] }

// plugin.js const apiKey = "<你的 API Key>"; const modelEndpoint = "https://your-gateway.example.com/v1/chat/completions"; async function getGeneratedCopy(prompt) { const resp = await fetch(modelEndpoint, { method: "POST", headers: { "Content-Type": "application/json", "Authorization": `Bearer ${apiKey}` }, body: JSON.stringify({ model: "qwen2.5:7b", messages: [ { role: "system", content: "你是一个资深 UI 文案专家，回复简洁中文。" }, { role: "user", content: prompt } ] }) }); const data = await resp.json(); return data.choices[0].message.content.trim(); } async function run() { const selection = penpot.selection; if (selection.length === 0) { penpot.ui.openToast("请先选中一个文本图层"); return; } for (const node of selection) { if (node.type === "text") { const copy = await getGeneratedCopy(`为一个按钮生成点击文案，不超过 8 个字，主题是：${node.content}`); node.setContent(copy); } } } penpot.ui.open("AI Copy Writer", run);

这段代码并不复杂，但它说明了一个非常关键的事实：Penpot 的插件接口允许开发人员直接读取、修改画布内容，这相当于给设计工具开了个后门，让大模型真正参与到设计中，而不是停留在外部“跑一段文字出来再复制粘贴”。实际开发时你还可以把多个模型请求串起来：先让模型分析整个画布里的文本，再让另一个模型生成一套统一的设计风格建议，把结果作为新页面追加到工作台里。

3.4 批量自动化的另一条路：服务端脚本调 Penpot API

插件是交互式的，适合设计师在画布中主动触发。但有些场景需要在无人值守时批量处理：比如每天晚上遍历所有项目，把图层命名规范性问题列出来；或者把所有设计稿中的中文文案批量导出交给大模型翻译成多语言版本。这种场景更适合通过 Penpot 的 REST API 写服务端脚本来做。

Penpot 的 API 是基于文件的，可以得到 JSON 格式的完整画布结构。我用 Python 脚本做了一次全量导出，然后把每个文本节点收集起来，统一发给大模型做翻译和润色，再通过文件更新接口把改好的内容回写。整个过程不依赖任何人工操作。这里的关键是准备好 Personal Access Token，在用户设置里生成，脚本请求时放到 Authorization 头里。我在实际操作中给这个脚本加了一层任务队列，因为一个大文件可能有几千个文本节点，串行调用大模型接口要等很久，用并发请求可以大幅度缩短时间，但一定要控制好速率，避免把模型服务打垮。

3.5 接入大模型时的几个经验总结

整个接入过程踩了不少坑，最值得拿出来说的有三点。

第一，模型响应时间要先压测。Penpot 插件调用模型接口是同步等待的，如果模型推理要十几秒，画布就会一直转圈，体验非常差。我的处理方式是先对接口做批量压测，分析不同并发下的响应时间，然后给模型请求加一个较短的超时时间，超时就返回缓存中的上一份结果或者一个友好的错误提示。第二，Prompt 一定要结合实际场景反复打磨。让模型写“按钮文案”和让模型“分析交互稿并给出文案改进建议”是完全不同的指令。我维护了一份 Prompt 模板库，每个场景一个模板，插件通过参数选择模板，而不是在代码里写死 Prompt。第三，本地模型的推理参数要调。比如temperature太高，生成文案会飘；top_p太小，模型输出会机械重复。我针对文案生成场景，最终把 temperature 设在 0.6 左右，效果比较平衡。

另外，如果你团队成员比较多，可以考虑用一个类似 Dify 的中间层把模型网关统一管理起来。所有插件和脚本不直接连模型服务，而是连 Dify 上的应用模板。这样 Prompt 迭代、模型切换、用量统计都在一个后台完成，比在每台机器上改配置容易得多。我在后面对接过程中就把云端 API 和本地 Ollama 模型都接到了同一个网关，插件侧只维护一个接口地址，省了很多事儿。

4. 汉化、字体与日常使用细节

4.1 界面汉化与语言切换

Penpot 在界面国际化方面底子不错，多语言机制是内置的。我部署的版本默认界面是英文，但这不影响通过切换语言选项显示系统支持的其他语言。如果你需要的语言在界面上找不到，或者某个语言包的翻译不够完整，可以考虑自己接管前端资源做覆盖。

比较务实的做法是先把服务端默认语言改成你需要的语言，然后检查汉化覆盖度，再把常见高频操作比如工具栏、右键菜单、属性面板里的英文术语逐个记录，用浏览器扩展翻译辅助理解。归根结底，这类开源工具的汉化程度取决于社区贡献情况，和 Figma 那种官方出多语言的力度不能比，但核心功能的中文路径是能走通的。我的建议是不要强求 100% 汉化，真正影响效率的是常用功能能不能看懂，剩下的遇到就适应，用一段时间自然会熟悉。

如果你确实需要深度汉化，可以查看前端构建流程，用打包替换资源文件的方式把界面硬编码文案替换成中文。这样做的好处是彻底，坏处是每次 Penpot 升级后需要重新构建或重新应用补丁。如果你只是想要个“能用中文看得懂主力菜单”的效果，我更推荐在部署层面设置默认语言，配合少数几个高频位置的界面翻译，投入产出比最高。

4.2 中文字体安装与管理

在 Penpot 里使用中文字体，刚上手的朋友往往会卡住：本地电脑装了字体，但画布里一改中文字体就直接回退成默认字体。原因很简单，Penpot 在浏览器里渲染字体时需要从服务端获取字体文件，你本地装了什么服务和画布没关系。私有部署的字体管理逻辑是所有字体统一上传到平台，再由平台分发给所有协作者。

在 Penpot 的界面中打开字体管理面板，上传字体文件即可，支持常见的 TTF、OTF、WOFF2 格式。上传完成后，需要等字体服务完成一次同步处理，然后刷新画布就能在字体列表里看到刚上传的字体。中文字库文件通常比较大，动辄几十 MB，上传后等待同步的时间会长一些，这是正常现象。我在实际部署中传的是思源黑体，开源可商用，字重齐全，覆盖简体中文、繁体中文、日文、韩文等，设计工作台日常用的字体基本一次搞定，不需要重复上传多套。

这里有一个细节值得提醒：字体文件本质上是有版权的资产，上传到团队公共平台意味着所有协作者都能使用，还是要确认字体许可证允许这种分发方式。另外，如果团队成员在浏览器里看到某个字体始终渲染不对，大概率是本地浏览器字体缓存问题，清理缓存或者强制刷新页面就好，不一定是平台的问题。

4.3 多人协作、评论与团队权限

Penpot 的实时协作体验是称得上“Figma 级”的，多人同时编辑同一个画板时，能看到彼此的鼠标光标，改动会实时同步。私有部署环境里，协作的稳定性直接取决于服务器的带宽和网络环境，我实际测试过 5 个人同时在画布里拖拽、改样式，服务器 CPU 还好，网络延迟在合理范围内，同步基本没有明显卡顿。如果团队人数更多，建议给前端和后端服务单独加资源限制，避免某个大型项目把整个实例拖垮。

权限管理方面，Penpot 支持标准的企业权限模型，包括管理员、编辑者、查看者几种角色，项目也可以单独设置访问范围。自部署环境下，我更习惯把“开放注册”关掉，所有账号由管理员邀请创建，这样能确保每个进入平台的人都经过授权。日常分享时用链接分享，把公开访问的权限控制好即可。评论和标注功能也是有的，设计稿讨论可以直接在画布上留下锚点，避免在 IM 群里“截图+红圈”的低效沟通。

5. 常见问题与排查技巧实录

5.1 部署层面的问题

部署阶段碰到的问题，九成集中在环境变量、端口和数据卷这三件事上。这里整理了一份速查表：

端口冲突也是新手容易踩的坑。如果宿主机 8080 已经被占用了，docker compose 里映射端口需要改，但要注意前端环境的公开地址也要同步改，不然前端拿到的 API 地址还是旧端口。我建议固定目录存放编排文件和数据卷，方便以后升级和迁移，不要随手把容器挂在 /tmp 下手一抖就清没了。

另外，升级 Penpot 一定要谨慎。我的建议是：升级前先备份、升级后先在一台测试机上验证、验证过再动生产环境。有一次我直接从旧版本升级到新版本，没看迁移说明，导致数据库结构和旧数据不匹配，回滚浪费了不少时间。

5.2 字体、邮件与账号问题

字体上传后不生效，这是我收到最多的疑问。检查顺序一般是这样的：先看上传时文件格式支不支持，再看字体服务有没有跑起来、日志里有没有报错，最后看浏览器是否需要强制刷新。还有一个容易被忽略的坑：字体服务完成处理需要时间，传完马上用可能状态还没同步，等两三分钟再刷新，通常就出来了。

邮件系统在自部署环境下往往被人忽视，但 Penpot 的密码找回、邀请注册都依赖 SMTP。如果你没配 SMTP，系统虽然还能登录，但忘记密码基本就废了。我一开始图省事没配邮件，后来有同事密码找回失败，才老老实实把邮件服务加上。如果你的服务器在国内，可以用国内云厂商的邮件推送服务；如果网络环境允许，也可以用常见的免费邮件服务，但别用公共 SMTP 懒人包，发送频率和安全性都不靠谱。

账号权限问题也值得单独说。Penpot 的管理员初始化并不是在网页上完成，我第二次部署时还专门翻了一下文档，确认了命令行操作步骤。如果你看到某个用户角色改不了，先确认自己当前账号是不是管理员；如果你希望限制某个项目只能特定的人访问，记得确认项目的访问模式配置。

5.3 大模型接入的问题

大模型接入环节最容易发生的故障是连接超时和跨域问题。浏览器插件请求远程模型接口时，如果模型服务没有配置允许跨域访问，请求会被浏览器直接拦下，控制台会冒出 CORS 错误。我的处理办法是让后端提供一个代理转发接口，插件不直接跨域请求模型服务，而是请求同源的代理。这样跨域问题消失了，API Key 也得到保护，不需要把密钥写进前端代码。

另一个高频问题是模型输出格式不稳定。比如用大模型生成图层命名，它可能偶尔输出一长串解释文字，而不是纯命名列表。这不能靠运气，要严格限定输出格式，尽量让模型输出 JSON，再在代码里做一次解析校验；解析失败就重试一次或者丢弃这条结果，避免把设计师的画布搞得一团糟。

本地模型推理速度慢也是一个常见痛点。我实测过 7B 模型在 CPU 上的推理速度，一个简单的文案生成任务大概要 5 到 10 秒，交互体验确实不如云端模型瞬时响应。如果你接受不了这种延迟，可以考虑把任务改成异步：插件先把请求提交到一个任务队列里，设计师继续画界面，等模型跑完再通过通知或轮询获取结果。这种体验虽然不如同步等待直接，但在资源有限的前提下是更现实的方案。

5.4 日常使用层面的感受

这套工作台用了一个月之后，我最大的感受是“踏实”。所有设计源文件都在自己的服务器上，备份策略是我自己定的，权限规则是我自己写的，后期想接什么工具、加什么自动化流程，都不需要看别人脸色。对于小团队和独立开发者来说，Penpot 完全可以承担日常设计工作台的角色；对于大型团队，它作为一个数据自主可控的备选方案，配合一定程度的定制开发，也能变成内部设计基础设施的一环。

不过它和 Figma 的差距也确实存在，比如第三方插件生态相对薄弱，社区模板资源没那么丰富，原生组件库和设计系统的运营不如大公司产品完善。我的处理方式是只把 Penpot 作为核心工作台，历史遗留的 Figma 文件可以继续留在 Figma 里面，新项目、敏感项目、需要数据自控的项目一律走 Penpot。两条腿走路，既能享受开源工具的自由度，又不牺牲老项目上的已有积累。

最后分享一个小技巧：Penpot 的开发者模式可以直接读取画布元素的 CSS 和 SVG 属性，前端工程师在还原设计稿时用这个功能核对间距、圆角、字体字号特别方便。再配合一个简单的大模型插件做文案和命名自动化，整个设计到开发的手感很接近我之前用商业设计工具的体验，但数据完全在自己手里这种安心感，是商业工具给不了的。