我对设计协作工具的要求，一直不只是「能不能画界面」。
真拿它做团队项目之后，我更在意三件事。
设计稿能不能放在自己控制的环境里。开发能不能直接看懂页面里的组件和样式。AI 能不能参与真实画布，而不是只在 AI对话 框里聊两句。
Penpot 吸引我的地方，正好在这三点的交叉处。
它是一套网页端的开源设计平台。可以自己部署。也强调矢量图、样式和网页标记这类开放标准。
再加上 MCP 服务之后，支持这套协议的 AI工具还能读取并操作页面、图层，连组件和设计变量一起改。
我也不想为了远程协作，把整套设计再迁到另一家云平台。最好本地和外网只是访问路径不同，设计项目本身仍然留在原来的环境里。
这次我完整跑了一遍。让 Codex 在当前文件里做一套移动端学生信息管理页面，尺寸 390 × 844。5 个页面大约等了 20 分钟。
然后回到 Windows，用一键脚本通过容器编排把 Penpot 部署起来。本地入口用 9001。
最后装内网穿透工具，把 9001 映射到公网。
随机域名和固定二级子域名，都不是映射完就结束了。还要重新跑一遍部署管理脚本，选数字 9，把公网地址写回平台并重建容器。
这一篇我更关心「设计平台、MCP 与公网地址」之间的依赖关系。而不是把它简单写成一个替代品。
一、真正的差别不在「画得像不像」
Penpot 是一套面向设计师和开发者的开源界面设计协作平台。
在浏览器里就能完成界面设计，也能做交互原型和团队协作。设计交付、组件与共享库都能用。设计变量和自托管部署也在里面。
项目代码开源在 GitHub 上，仓库名就是 penpot。
对我来说，它和普通在线设计工具最值得区分的一点，是同时强调三件事。
设计协作。开放标准。自托管。
设计过程中会尽量贴近真实的网页实现。开发看设计稿的时候，不只是「看图」，还能更直接地理解结构和样式。
这一点在交接环节省下的沟通，比省下的授权费更值钱。
二、MCP 让设计工具往 AI 工作台推了一步
这套平台还有一个很值得折腾的方向，是它的 MCP 服务。
先说清楚它是什么。MCP 是一套让 AI 接入外部能力的通用协议。装上之后，支持这套协议的编码助手就能连到设计文件。
当前流程里提到的客户端包括 Codex 和 Cursor，还有 Claude Code 与 VS Code。
连上以后，AI 可以读取和操作页面和图层，也能改组件、样式和设计变量。
所以这里的 AI 不只是「看完设计稿再给点建议」。
更有意思的是，它直接进设计文件里动手。
三、先看一次真实操作：让 Codex 直接画 5 个页面
这次演示的目标，是移动端的学生信息管理页面。
先在平台里把 MCP 能力打开。
然后复制带令牌的 MCP 地址。
这里要把它当敏感凭据处理。不要出现在聊天回复里，不要写进日志，不要贴进代码注释，更不要发到公开文章里。
当时用的提示词我完整保留如下。
我有一个本地实例，已经启用了 MCP。
MCP 地址如下，请把它当作敏感令牌。不要在回答中复述，也不要写进日志和代码注释，更不要放进最终回复。
【把你的 MCP 地址粘贴到这里】
请连接这个 MCP，并在我当前打开的文件和当前页面里，设计一套「移动端学生信息管理」原型。
要求如下。
- 先调用工具确认连接状态，读取 high_level_overview 和必要的接口信息。
- 使用 execute_code 直接在画布中创建设计稿，不要只给文字方案。
- 设计 5 个移动端页面，尺寸 390 × 844。分别是首页与数据概览、学生列表，然后还有学生详情和成绩统计。
- 所有页面内容必须使用中文，不要用英文替代。
- 风格清爽现代，适合学校教务和班主任使用，不要做成营销落地页。
- 每个页面都要有真实业务信息。比如学生姓名和学号，班级和手机号，还有考勤状态、综合分和成绩趋势。
- 元素要可编辑，尽量用平台原生形状和文本创建。
- 注意中文字体渲染。先做一个小号中文文本测试。如果中文不可见，不要改成英文。改用当前环境能显示的中文字体，让中文在画布中真实可见。
- 完成后告诉创建了哪些画板，并导出首页预览检查一次。
我喜欢这种写法。
它不是让 AI「帮我想一个页面」，而是直接规定清楚。在哪个文件里做，用什么工具，做多少画板，什么尺寸，什么业务内容，最后怎么验证。
四、先连上，再验一次小的
刚开始的时候，设计页面还是空白。
Codex 连上 MCP 之后，先做连接和能力测试。
回到平台页面，能看到已经创建出测试内容。
这一步很重要。
我不会一上来就让 AI 连画 5 个页面。
先验证四件事。MCP 能连上。能写入画布。中文能正常显示。元素真的落进了当前文件。
确认之后再做完整设计，失败成本会低很多。
五、5 个页面大约等了 20 分钟
接着等 Codex 把任务做完。
完成之后回到浏览器页面。
5 个移动端页面已经创建出来。
真正值得关注的不是「AI 画得漂亮」这句评价。AI 确实通过 MCP 对当前文件做了实际操作，这才是重点。
至于布局质量、组件复用和细节规范够不够正式设计系统的要求，仍然要人工再检查一遍。
六、另一家的对比，只当作背景
这套记录里还比较了 Figma 的 MCP。
当前给出的背景是，它会受套餐、席位和调用额度限制。普通查看和协作席位的额度较低。桌面版还涉及付费计划要求。
这类政策本身经常调整。所以我只把它当作这次选择自建工作流的背景，不写成「谁永远更便宜」的长期结论。
能确认的只有一件事。这套 MCP 工作流，在当前环境里已经跑通了。
七、回到本地部署：先确认容器环境
正式部署之前，先安装并启动 Docker 桌面版。
官方支持用 Docker Compose 部署，但配置文件内容较多。所以这里用整理好的一键脚本，降低第一次部署的操作量。
八、用一条命令跑通部署
Windows 上按 Win + X，选「终端（管理员）」，然后执行这条命令。
irm https://gitee.com/jun-wan/script/raw/master/penpot_deploy/deploy-penpot.ps1 | iex
这是从远程地址取脚本并直接执行的写法。方便确实方便。
但正式运行前，我会先确认脚本来源和内容，而不是因为「一键」就跳过检查。
执行以后进入菜单。
选择数字 1，继续按提示完成自定义配置。
脚本会准备所需配置，并通过容器编排拉取和启动相关服务。等镜像拉完。
九、本地先确认 9001 能打开
部署完成以后，用浏览器访问 9001 对应的本地地址。
看到登录页面，说明本地服务已经起来了。
点底部创建账号，进入工作台。
到这里先确认的是一条链路：容器 → 平台 → 本地 9001 → 浏览器。
如果只在这台电脑或者局域网里用，已经可以开始设计了。
十、公网访问不是只做一次端口映射
这是最容易忽略的一点。
平台不只是要让 9001 从公网可达，它还需要知道自己最终对外使用的公网地址。
后面无论用随机域名还是固定二级子域名，都要再跑一次一键部署管理脚本。然后选菜单里的 9，把公网地址写回配置并重建容器。
实际依赖顺序是：先拿到公网地址，再把地址应用到平台，然后重建容器，最后验证。
十一、装内网穿透工具之前，先看清楚
当前用的是 Windows 版 cpolar。
从官网下载 64 位安装包，解压后运行程序完成安装。
装完先用一条命令确认版本。
cpolar version
出现版本信息，再继续进管理界面。
十二、注册并登录管理后台
先注册账号。
进入注册页面。
注册完成后，用浏览器访问本机 9200 端口。
输入账号进入后台。
后面的隧道都在这里配置。
十三、先用随机域名联调
cpolar 可以走两种方式。随机域名，固定二级子域名。
随机域名更适合第一次把公网链路跑通。
后台默认会看到两条隧道。一条是远程桌面，指向 3389，走 TCP。一条是网站，指向 8080，走 HTTP。
这里可以改那条网站隧道，也可以新建一条。
当前需要配置的内容是四项。隧道名称自定义，比如 penpot。协议选 http。本地地址填 9001。地区与前面保持一致。
创建或更新之后进入在线隧道列表。能看到对应的 HTTP 和 HTTPS 公网地址。
十四、随机公网地址拿到后，还要写回平台
回到命令行，再执行一遍那条一键部署脚本。
进入菜单以后选 9，也就是设置穿透域名。
把在线隧道列表里的公网地址复制进去。当前示例用的是 HTTPS 地址。
脚本会重建容器，让平台应用这个公网地址。
完成以后再从浏览器打开刚才那个公网地址。
如果页面没及时出来，当前步骤给出的处理方式是 Ctrl + F5 强制刷新。
登录页面能正常打开，随机公网链路才算真正闭合。本地 9001，公网地址，地址写回平台，容器重建，最后到外部浏览器。一段都不能少。
十五、长期使用再换固定二级子域名
随机地址适合临时测试。
如果以后要长期访问，或者团队成员要收藏同一个地址，换成固定二级子域名更合适。
进入预留页面，选「预留」，再选「保留二级子域名」。
这里要注意三点。地区要和前面的隧道保持一致。二级域名比如 penpot。描述也自己填。
二级子域名有唯一性，最终要以自己账号里实际预留成功的名称为准。
十六、把固定域名配置回隧道
回到本地管理界面，进入隧道管理里的隧道列表，找到刚才那条 penpot 隧道并编辑。
修改四项。协议选 http。本地地址填 9001。域名类型选二级子域名。子域名填预留成功的名称，地区与预留时一致。
更新以后进入在线隧道列表。
这时这条隧道已经生成了固定公网地址。
十七、固定域名也要再次写回平台
这一步同样不能省。
回到命令行，再执行一遍部署脚本。进菜单以后仍然选 9，把刚才那个固定公网地址重新设置为穿透域名。
脚本会重建容器并应用新地址。等完成以后，用固定域名访问。
页面能正常打开，到这里才算完成。固定域名，平台配置，重建容器，外部访问。四步走完。
十八、每一层只做自己该做的事
把工具拆开看，职责其实很清楚。
Penpot 负责界面设计，也管原型和组件。样式、设计变量和协作都归它。
它的 MCP 服务，把当前设计文件的能力提供给支持这套协议的 AI。
Codex 和 Cursor，还有 Claude Code 这些客户端，通过它读取或操作设计内容。
Docker 负责在本地跑起这套服务。
内网穿透工具负责把本地 9001 提供到公网。
它们之间最重要的不是「工具很多」，而是每一层只做自己该做的事。
总结
这次真正跑通的主线是四段。
先在平台里开启 MCP，让 Codex 在画布上做出 5 个中文移动端页面。
再回到 Windows，用容器编排把平台部署到本地 9001。
接着装内网穿透工具，配好随机公网地址并写回平台。
最后换成固定二级子域名，再写回一次。
有几个细节值得继续留意。
MCP 地址带令牌，要按敏感凭据处理，不要直接公开。
这次做 5 个页面等了大约 20 分钟。这是当前环境下的记录，不等于所有任务都保持同样速度。
另一家的席位和额度政策可能调整，不把它写成长期结论。
一键部署用的是远程脚本，执行前最好先确认来源和内容。
本地入口固定用 9001。
随机公网和固定域名都不是「配完即结束」。还要重新运行部署脚本并选菜单 9，把公网地址写回平台后重建容器。
内网穿透只负责公网入口，既不参与设计逻辑，也不参与 MCP 的设计操作。
Penpot 最有意思的地方，并不是「终于有一个开源的替代品」。它把自托管、开放的设计格式和 AI 工作流放到了一起。
真正用起来之后，我更愿意把它看成一套设计基础设施。设计师能画，开发能读，AI 也能进来做实际操作，而部署和访问方式都握在自己手里。
Codex安装汉化 中转站 微信:douhanq
