Figma之外还有什么选择Penpot自托管实战从Docker部署到MCP接入AI设计工作台自托管 · Web 标准 · Design Tokens · MCP · AI Agent#Penpot #UI设计 #自托管 #Docker #Docker Compose #MCP #AI Agent #Design Tokens #设计系统 #前端开发如果你正在寻找 Figma 之外的设计协作方案真正值得比较的已经不只是“能不能画 UI”。本文从工程化视角完整拆解 Penpot先解释它为什么适合强调数据控制、开放标准和设计开发协同的团队再使用官方 Docker Compose 完成自托管梳理 Frontend、Backend、PostgreSQL、Redis、Exporter 与资源存储之间的关系随后启用 MCP把 AI Agent 接入真实设计文件演示从只读探测、最小写入、中文渲染验证到读取组件与 Design Tokens、分批生成业务页面的可靠工作流。文章还覆盖公网 HTTPS、PENPOT_PUBLIC_URI、密钥保护、备份升级、浏览器休眠与 MCP 断连排查。最终目标不是寻找一个“免费替代品”而是搭出一套设计资产可控、设计与代码语言更接近、并能被 AI 安全读写的设计工作台。先给结论如果你只追求最低上手成本成熟云端设计平台依然省心如果团队更在意设计资产边界、自托管、Web 标准以及让 AI 真正进入设计文件执行任务那么 Penpot 已经值得作为一套“设计基础设施”认真评估。图 1 设计工具选型之前先回答四个约束问题1. 为什么 2026 年重新讨论 Figma 之外的选择过去讨论 UI/UX 工具关注点往往是多人协作、组件库、原型、评论和开发交付。到了 AI Agent 开始直接调用工具的阶段问题已经发生变化设计文件能否被机器结构化读取AI 能否真正修改图层、组件和 Token而不只是生成一张静态图团队是否能决定设计资产部署在哪里这意味着设计工具正在从“画布产品”变成“设计基础设施”。Penpot 的价值也应该放在这个维度理解它是 Web 化的开源 UI/UX 平台支持自托管Flex Layout 和 Grid Layout 分别建立在 CSS Flexbox 与 CSS Grid 的语义之上Design Tokens 把视觉规范结构化MCP 则让 AI 客户端能够读取和修改当前设计文件。所以本文不会把 Penpot 简单称作“某某工具的开源平替”。如果只用“像不像”来比较会错过它最值得关注的部分数据边界、开放标准、设计系统与 Agent 自动化可以被放进同一套工作台。2. 先做选型哪些团队更适合 Penpot团队场景匹配度为什么内部平台、政企、研发组织高更重视数据边界、自托管、可审计与可扩展性设计与前端协作密集的团队高Flex / Grid / Token 与 Web 实现语义更接近准备把 AI Agent 引入设计流程高MCP 能读取和修改真实设计文件而不止输出建议完全没有运维能力的小团队中自托管意味着 HTTPS、备份、升级、监控都需要负责人强依赖既有商业插件与资产生态视情况真正的迁移成本通常来自插件、组件库、历史文件和团队习惯没有“永久最优”的设计工具。自托管不是天然加分项它换来控制权也把安全、备份和升级责任交回团队。选型时应把这些成本和收益放在同一张表里。3. Penpot 最值得开发团队关注的地方设计与代码说同一种语言图 2 Flex、Grid、Token 与前端实现之间的对应关系Penpot 的 Flex Layout 基于 CSS FlexboxGrid Layout 基于 CSS Grid。方向、对齐、Gap、Padding、换行、网格行列、Area、FR 等概念都能直接映射到 Web 布局语义。设计师不需要因此变成前端工程师但开发者在交付阶段少了一层“把视觉位置重新翻译成布局规则”的工作。Inspect 进一步把这种语义暴露给开发者。对于响应式页面、列表、卡片、表单、仪表盘等典型 Web UI这种设计模型比大量绝对定位更接近最终实现也更适合后续由 AI 读取结构。4. Design TokensAI 设计能否进入生产流程的分水岭图 3 Design Tokens 让设计规范成为结构化接口AI 生成页面最常见的问题不是“不会画”而是每次都重新猜颜色、间距、圆角和字号。单页看起来可能不错一旦扩展到十几个页面视觉规则就开始漂移。Design Tokens 的价值是把视觉决策从“记忆”和“截图”变成数据。颜色可以叫 color.brand.primary间距可以叫 space.4圆角可以叫 radius.md。设计系统、前端主题和 AI Agent 都可以消费同一套约束。这时 Agent 的工作方式就发生了变化不是先生成、再让人修而是先读取 Token 和组件再在约束内创建页面。AI 从“灵感生成器”变成了“受设计系统约束的执行者”。5. 自托管之前先看懂 Penpot 在运行什么图 4 Penpot 自托管的核心服务与生产边界Penpot 是典型的 SPA 架构。浏览器侧运行前端应用后端负责业务逻辑并把核心数据持久化到 PostgreSQL系统还包含导出服务等附加组件。官方 Docker Compose 把这些服务编排在一起因此“启动成功”只是第一步。真正的生产部署至少要回答数据库如何备份用户上传的资源如何持久化公网域名是什么TLS 在哪里终止Secret Key 如何保存升级失败如何回滚MCP 是否应该暴露到公网这些问题决定了自托管系统能不能长期运行。6. 用官方 Docker Compose 部署先完成本地闭环图 5 官方 Docker Compose 从环境准备到生产加固的部署链路6.1 Windows 与 Linux 的准备Windows / macOS 建议使用 Docker DesktopLinux 服务器可以使用 Docker Engine并安装 Docker Compose V2。先确认命令可用docker --versiondocker compose versionWindows 用户如果使用 Docker Desktop确认 WSL2 后端正常运行并给容器预留足够内存。第一次部署先不要叠加反向代理、域名和 MCP把变量控制在最少。6.2 获取官方 Compose 文件curl -o docker-compose.yaml https://raw.githubusercontent.com/penpot/penpot/main/docker/images/docker-compose.yamldocker compose -p penpot -f docker-compose.yaml up -d官方文档当前给出的默认入口是 http://localhost:9001。启动后先检查服务状态和日志docker compose -p penpot -f docker-compose.yaml psdocker compose -p penpot -f docker-compose.yaml logs --tail2006.3 第一次启动必须验证的 6 件事检查项通过标准失败时先查容器状态核心服务持续运行无反复重启docker compose ps / logsWeb 入口localhost:9001 可稳定打开端口占用、frontend 日志注册与登录可进入工作区认证 Flags、邮件配置文件持久化创建文件后刷新仍存在Backend / PostgreSQL资源持久化上传图片后重启仍存在资源卷与权限导出基础导出功能正常Exporter 与相关日志7. 从 localhost:9001 到团队域名最容易踩坑的是 Public URI本机测试使用 localhost 没问题但团队通过域名访问时必须让 PENPOT_PUBLIC_URI 与用户真正访问的公开地址一致。否则登录跳转、资源地址、MCP URL 或代理行为可能出现“页面能打开但部分功能异常”的错位。# 示例PENPOT_PUBLIC_URI: https://design.example.com生产环境建议在 Nginx、Caddy、Traefik 或现有网关终止 TLS。不要为了快速跑通而长期关闭安全 Cookie非 HTTPS 的临时设置适合本地实验不适合正式公网环境。8. 自托管真正需要负责的安全基线图 6 从“能跑”到“可长期使用”的生产环境清单为 PENPOT_SECRET_KEY 使用高强度随机值绝不保留示例或可预测值。生产域名全站使用 HTTPS并保持安全 Cookie 策略。按团队认证方式控制注册与邮件验证不需要公开注册就不要开放。PostgreSQL 数据与资源文件分别备份并定期做恢复演练。不要把 PostgreSQL、Redis 等内部服务端口直接暴露到公网。MCP Key 按密码/访问令牌级别管理不进入截图、日志、仓库和群聊。生产升级固定明确版本升级前先备份在测试环境验证后再切生产。9. MCP为什么它比“AI 帮我画个页面”更值得关注图 7 AI 客户端、MCP Server、浏览器插件与当前设计页的数据流Penpot MCP 的核心不是多了一个聊天框而是把 AI 客户端、MCP Server、浏览器中的 MCP 插件和当前设计文件串起来。AI 可以读取页面、图层、组件、样式与 Token也可以执行创建、移动、重命名、修改样式等操作。对开发场景它还能辅助提取布局结构、把 Token 翻译成代码变量、导出资源和完成设计到代码的转换。换句话说Agent 面对的不再是一张截图而是一个可以查询和修改的结构化设计对象。当前官方实现里MCP 已经并入 Penpot 主项目自托管环境通过 enable-mcp 启用相应服务前端再代理到独立的 penpot-mcp 容器。10. 启用 MCP按当前官方链路配置在自托管 Compose 中启用 MCP 时核心开关是 enable-mcp。官方配置中前端通过内部服务名连接 MCPPENPOT_FLAGS: ... enable-mcpPENPOT_MCP_URI: http://penpot-mcp:4401PENPOT_MCP_URI_WS: http://penpot-mcp:4402内部地址通常保持官方 Compose 默认值即可除非你修改了服务名或端口。启用后进入账户的 Integrations → MCP Server生成 MCP Key 并复制 Server URL。Key 是不可恢复的个人令牌只会显示一次。随后把 Server URL 添加到支持 MCP 的 AI 客户端再打开目标 Penpot 文件通过 File → MCP Server → Connect 把插件连接到当前文件。完成后AI 客户端应该能够列出 Penpot 工具。11. 第一次连接不要让 Agent 直接生成整套产品图 8 把 AI 设计任务拆成六个可验证阶段能调用工具的 Agent 与普通聊天模型最大的区别是它会真正改变文件。因此第一目标不是“生成得快”而是先证明连接、权限、作用域和回滚都可控。11.1 第一步只读探测请连接当前 Penpot 文件。先不要修改任何元素只执行只读检查1. 列出当前文件的页面2. 读取当前聚焦页面的主要图层结构3. 列出可见组件、样式和 Design Tokens4. 列出当前可用的 Penpot MCP 工具5. 如果任何一步失败只报告失败位置不执行写入。这一步能同时验证客户端、Server、插件、当前标签页和文件上下文。只有只读检查稳定才进入写入阶段。11.2 第二步最小写入探针在当前页面创建一个 390 × 844 的测试画板。只放置- 标题学生信息管理- 主按钮新增学生要求- 优先使用当前文件已有的颜色、Token 或组件- 所有元素保持可编辑- 不创建其他页面- 完成后立即停止。如果这一步失败问题范围已经很小可能是写权限、当前页面、插件连接或某个具体工具而不是几十个页面生成到一半才发现链路不稳定。12. 一个可直接复用的业务 Prompt5 个移动端页面你正在操作我当前打开的 Penpot 文件。安全要求- MCP 地址和 Token 属于敏感凭据- 不要在回复、设计文本、代码注释或日志中复述任何 Token。任务创建一套“移动端 H5 学生信息管理系统”原型。执行顺序1. 先只读检查当前页面、现有组件、样式和 Design Tokens2. 如果存在可复用组件或 Token优先复用3. 创建 5 个 390 × 844 画板- 首页 / 数据概览- 学生列表- 学生详情- 新增或编辑学生- 成绩统计4. 全部使用简体中文5. 业务数据必须真实合理至少包含姓名、学号、班级、手机号、考勤状态、综合分和成绩趋势6. 使用 Penpot 原生可编辑元素不把整页做成图片7. 布局优先采用 Flex / Grid 思维8. 统一间距、圆角、字号、颜色和组件状态9. 先只完成首页完成后停止等待确认10. 每完成一页检查文字溢出、中文显示、对齐和组件复用11. 最后只汇报创建的画板、复用的组件/Token 和发现的问题。这个 Prompt 的关键不是长度而是把“执行顺序、作用域、业务约束、可编辑性、质量检查、敏感信息和停止条件”写清楚。对工具型 Agent 来说这已经接近一份轻量任务协议。13. 当前页面与活动标签页MCP 最容易被忽略的运行条件MCP 总是作用于当前聚焦的 Penpot 页面而且同一时间只能有一个活动 MCP 标签页。更换浏览器窗口或切换聚焦页面时Agent 的上下文也会跟随变化。插件运行在浏览器标签页中。如果 Chrome / Edge 为了节省内存冻结或卸载标签页MCP 任务会中断。长任务建议保持 Penpot 标签页活动把站点加入不休眠名单并把大任务拆成多个阶段。14. 真实排障沿链路定位而不是反复重装图 9 Penpot 自托管与 MCP 的高频故障定位矩阵问题检查点处理方向localhost:9001 无法访问docker compose ps / logs确认容器健康、端口未冲突、镜像完整公网可打开但登录异常PENPOT_PUBLIC_URI / 代理头公开 URI 与实际 HTTPS 域名保持一致AI 客户端没有 Penpot 工具enable-mcp / Server URL确认 MCP 服务已启用且客户端地址正确Agent 看不到当前文件File → MCP Server → Connect插件必须连接目标文件长任务中途断开活动浏览器标签页关闭休眠、重新连接、拆小任务中文显示异常最小中文探针 / 字体回退先验证字体与渲染再批量生成页面越来越不一致组件 / Token 复用率要求 Agent 先读设计系统禁止无约束自创样式15. 备份与升级Compose 文件不是最重要的数据docker-compose.yaml 随时可以重新下载真正不可替代的是 PostgreSQL 中的业务数据和资源存储。至少建立“数据库 资源”双备份并把恢复过程写成 Runbook。只验证备份文件存在、却从未做过恢复演练不能算完成灾备。更稳妥的升级流程是确认目标版本 → 备份 → 测试环境升级 → 验证登录、文件、资源、导出、MCP → 再升级生产。多人团队还应准备维护窗口和回滚路径。16. 从现有设计平台迁移最难的往往不是文件导入真实迁移成本通常来自三个地方历史资产、设计系统、协作习惯。与其追求一次性搬完所有旧文件不如选一个新项目或独立业务线做试点。试点阶段先建立最小设计系统品牌色、文字层级、间距、圆角、按钮、输入框、卡片、导航再让 Agent 在这些约束下生成页面。这样测试的不只是“Penpot 能不能画”而是设计、开发、运维和 AI 能不能形成完整闭环。17. 把 AI 放进团队工作流而不是放在设计师旁边阶段设计师开发者AI Agent需求澄清定义场景、信息层级、关键体验确认技术边界整理页面清单与约束设计系统维护 Token、组件与变体映射主题变量与代码组件审计命名与一致性页面生产完成关键页面与交互提前验证布局可实现性按既有规范铺量设计评审判断体验与视觉质量检查状态、响应式和边界列出不一致项开发交付确认最终设计读取布局、Token、资源辅助结构提取与代码映射迭代维护更新规范同步实现批量修改与一致性检查AI 最适合承担的是可描述、可检查、可回滚的重复工作体验判断、信息架构和最终视觉取舍仍然需要人来负责。这样的分工比“让 AI 一键替代设计师”更容易进入真实生产流程。18. 最后回答Figma 之外Penpot 值不值得搭如果你只需要一个无需维护、团队立即能用的设计工具自托管未必是收益但如果你的约束包括设计资产需要留在可控环境、设计与开发希望共享更接近 Web 标准的布局语言、设计系统需要结构化 Token以及 AI Agent 要真正读取和修改设计文件那么 Penpot 的组合价值会变得非常明确。自托管解决的是资产边界与基础设施控制权Flex / Grid 降低设计到前端实现的语义翻译成本Design Tokens 把视觉规范变成可复用的数据接口MCP 让 AI 从“聊天建议”进入真实画布与设计系统Docker Compose 降低部署门槛但不会替你承担安全、备份和升级责任。真正值得关注的不是“Penpot 能不能复制另一个设计工具”而是它能不能成为团队自己的设计基础设施设计师在里面完成体验与视觉开发者读取接近 Web 标准的结构AI 在明确权限和约束下执行批量工作而设计资产和系统边界仍由团队自己掌控。参考资料Penpot 官方帮助中心Flexible LayoutsFlex Layout / Grid LayoutPenpot 官方帮助中心Penpot MCP serverPenpot 官方技术文档ArchitecturePenpot 官方技术文档Docker self-hosting / Getting StartedPenpot 主仓库configuration.mdMCP 与环境变量配置