OpenPencil 上手：把 AI 设计稿放进工程流水线

OpenPencil 最值得看的地方，不是“输入一句话生成 UI”，而是它把设计文件往代码工程里又推了一步。

过去几年，AI 生成界面大多停在两个端点：要么是聊天框里吐一段 React 组件，要么是设计工具里生成一张看起来挺像样的稿子。前者容易脱离视觉系统，后者又很难进入 Git、CLI、MCP、自动化流水线。OpenPencil 想卡在中间：设计仍然在无限画布上发生，但产物是 JSON 化、可 diff、可被 Agent 修改、也能导出多端代码的 .op 文件。

这不是 Figma 的简单平替，也不是又一个“AI 做网页”的演示项目。它真正有意思的点在于：设计开始变成一种可以被编排、被审查、被版本管理的工程资产。

拿 OpenPencil 和 Figma 正面硬比，很容易跑偏。Figma 强在成熟协作、生态插件、设计系统、评论交付和团队流程，OpenPencil 现在显然不是要在这些维度上立刻硬刚。

它更像一套 AI-native 的设计实验台：

换句话说，它把“设计工具”拆成了三层：画布、人机交互界面、可编程设计引擎。普通用户看到的是画布；开发者真正该关注的是后两层。

OpenPencil 的第一个爽点当然是 Prompt to Canvas：描述一个 SaaS Landing Page、后台仪表盘、移动端设置页，它会在无限画布上流式生成矩形、文本、图标、布局和样式。

一个典型提示词可以这么写：

但这个入口不能被神化。AI 生成 UI 最大的问题从来不是“画不出来”，而是太容易画得像：大圆角、紫色渐变、三张卡片、假图标、假数据，一眼模板味。

OpenPencil 比较聪明的地方，是没有把这件事只交给一个大模型一口气憋完。它引入 Orchestrator，把复杂页面按空间区域拆成子任务；Concurrent Agent Teams 让多个 Agent 同时处理 hero、feature、footer、pricing 等区块；Style Guides 再给视觉语言加约束。这样做的意义不是炫技，而是降低“一坨 AI UI”失控的概率。

对真实项目来说，Prompt 最好别写成一句“做个漂亮页面”。你要把业务信息、信息层级、组件约束和不要什么写清楚。比如：

这类提示词更像产品设计 brief，而不是抽盲盒。

如果只想本机体验，桌面客户端最省事。

macOS 可以用 Homebrew：

Windows 可以用 Scoop：

Linux 和 Windows 也可以直接去 GitHub Releases 下载 AppImage、deb 或 exe。

如果你更关心 CLI 和工程化，可以装 op 命令：

常用命令大概是这样：

op 支持 inline 字符串、@filepath 和 stdin 三种输入方式。这个设计很重要，因为它意味着 OpenPencil 不必永远被困在 GUI 里。你可以把设计任务放进脚本、CI、Agent 工作流里跑。

如果要从源码开发，需要 Bun 和 Node.js：

桌面模式：

项目使用 Bun monorepo，核心技术栈包括 React、TanStack Start、Tailwind CSS、CanvasKit/Skia WASM、Electron、Zustand、Vercel AI SDK 和 TypeScript。它不是一个薄薄的 demo，仓库里确实已经按 Web、Desktop、CLI、packages 拆了不少工程层。

OpenPencil 提供多种 Docker 镜像。最轻量的是 Web 版：

如果要带 Claude Code、Codex、OpenCode、Copilot、Gemini CLI 等 AI CLI，还有对应镜像和 full 镜像。这里要提醒一句：带 AI CLI 的镜像通常牵涉 OAuth 登录、模型凭证、会话持久化，别随便把 3000 端口直接暴露到公网。

Claude 版的思路是先持久化登录会话：

再启动服务：

注意这里把端口绑定到 127.0.0.1。如果要远程访问，建议走 Tailscale、WireGuard、反向代理认证或 Zero Trust，而不是直接 -p 3000:3000 扔到公网。

顺手提一嘴，如果你要长期跑 OpenPencil Web、MCP Server、AI CLI 登录态和设计实验环境，最好单独用一台干净云服务器隔离，不要跟生产数据库、主站后台混在一起。雨云这类云服务器适合拿来做这种 Agent/设计工具试验机，小规格先跑，验证完再扩。

OpenPencil 的关键产物是 .op 文件。它本质上是 JSON：节点、页面、变量、布局、文本、样式都可以结构化保存。

这比“导出一张图”更接近工程资产。因为 JSON 能做几件事：

一个团队可以把 OpenPencil 放进这样的流程里：

这里最重要的是别把导出代码当成最终代码。AI 设计工具能省掉大量初稿和样式搭骨架的时间，但真实产品还要接数据、处理错误态、空态、权限态、移动端、可访问性和性能。OpenPencil 更适合把 0 到 0.6 的设计/前端骨架拉快，而不是替你承担最后的工程判断。

OpenPencil 内置 pen-mcp，支持 stdio 和 streamable HTTP transport，默认 HTTP 端点是：

这意味着 Claude Code、Codex、Gemini CLI、OpenCode、Kiro、Copilot 等 MCP 兼容工具，可以通过工具调用读取、创建、修改 .op 文件。

这层能力比“AI 在画布里聊天”更有想象力。因为设计任务可以进入 Coding Agent 的上下文：

但 MCP 也有风险。让 Agent 改设计文件，最好从低风险目录开始，不要一上来给整个项目写权限。比较稳的做法是：

Agent 只能在 drafts 里生成和修改；进入 approved 前由设计师或前端负责人 review；exports 生成后再进入业务代码仓库。这样能避免“AI 顺手把设计系统改坏了”。

OpenPencil 支持把同一份 .op 导出到多个目标：React + Tailwind、HTML + CSS、Vue、Svelte、Flutter、SwiftUI、Jetpack Compose、React Native。

这对原型、落地页、后台页面、内部工具很有价值。尤其是那些视觉不复杂、信息结构清楚、组件边界明确的页面，AI 先生成结构，前端再接真实数据，比从空白文件开始快不少。

但生产级 UI 不只是布局。真正上线前至少要过这些检查：

所以它更适合做“前端初稿加速器”，不是“上线责任转移器”。这点要整明白，否则最后还是前端来擦屁股。

AI UI 最容易让人烦的不是丑，而是太像。OpenPencil 内置 Style Guides，支持按 tag 模糊匹配视觉风格，比如 glassmorphism、brutalist、retro 等。它还强调 Anti-Slop，用来追踪多次生成之间的重复模式，减少同质化输出。

这方向是对的，但不能全靠工具。实际使用时建议把风格约束写得更具体：

如果是内部后台，就不要追求 Dribbble 味；如果是营销页，就把转化目标、首屏信息、信任背书、CTA 层级讲清楚。OpenPencil 能帮你生成，但“什么是好设计”还得有人管。

比较适合的场景：

不太适合一开始就拿它做这些：

一句话：OpenPencil 更适合把设计从“灵感稿”推进到“可工程化初稿”，而不是跳过设计判断。

如果团队真要试，不建议直接把它塞进主仓库。可以先开一个 design-lab 仓库：

每次设计任务先写 brief：页面目标、用户角色、核心信息、组件约束、禁止事项。OpenPencil 根据 brief 生成 .op 初稿；设计师或前端负责人调整后进 approved；再导出 React + Tailwind；最后前端接入真实业务代码。

这样做有三个好处：

这才是 Design-as-Code 比较务实的打开方式。不是让设计师和程序员“彻底解放双手”，而是把初稿、批量修改、多端导出、Agent 协作这些重复劳动交出去，把判断、取舍、验收留下来。

OpenPencil 的价值也在这里。它没有把设计变成一句魔法咒语，而是把设计文件、画布、CLI、MCP、代码导出放进同一条工程链路。对 AI 产品团队来说，这比“1 分钟生成一个漂亮页面”更值得认真看。