Builder.io 开源 /visual-edit：将本地应用变成 Figma 式可视化编辑画布

Builder.io 团队开源了 Agent-Native 体系中的核心 Skill「/visual-edit」，官方称其 100% 免费且开源。它的表层描述很直观：把正在运行的本地应用装进一个 Figma 式的无限画布，让用户可视化地看页面、改样式。但真正定义这个产品形态的，是它接下来那一步——画布上的视觉改动会交还给编码 agent 写回源码，而不是由画布直接改代码。

这个拆分不是实现细节，而是整个 Skill 的骨架。用户在画布上做的改动会累积为一个待处理批次，永不直接写源码；agent 用 get-visual-edit-pending 取回待处理改动、写入源码，HMR 自动刷新画布，确认后关闭该批次。换句话说，画布负责“表达意图”，agent 负责“落笔成码”，两者之间隔着一个必须被显式确认的批次。

如果画布上只是静态截图，那么“可视化编辑”就退化成在图片上画框，改完还得靠人脑翻译成代码。来源强调，画布上每个 screen 是活的路由页面而非静态截图，看到的永远是真实状态。这是它区别于传统设计稿标注工具的关键：你面对的是正在跑的 dev server 渲染出的页面，而不是某个时间点的快照。

调用方式也围绕这一点设计：调用 open-visual-edit 并传入路由（如 /、/pricing）和视口（desktop、mobile 等），它会创建画布、排好屏幕并返回链接。画布默认排布 3 到 7 个屏幕，按每条路由 × 每个视口一帧网格排列。除正常页面外，画布会主动纳入空态、加载、报错、弹窗这些 URL 可寻址的状态；除非用户明确要求全量审计，画布不铺开所有路由。

这里有一个容易被忽略的约束：使用前需确保 dev server 在跑，agent 自己启动的服务器要用 AUTH_DISABLED=1，避免把登录页当目标。这说明画布的真实性依赖于一个正在运行的本地环境，而不是一个可以离线打包的产物。

把“可视化编辑”和“写源码”拆开，最直接的收益是安全边界变得可陈述。来源列出的边界包括：画布编辑始终是待定提案，修改代码只走 coding agent 这一条路径；结构性修改（重排、.map() 列表、共享组件）会被拒绝直写，必须经 agent 处理；写本地文件须用户手动点击同意弹窗，agent 无法自我授权，且 .env 等敏感文件永远排除。

分享场景也被单独处理：分享链接只渲染脱敏后的快照，访客碰不到用户的 localhost。免登录可用依赖一次性的短时凭证而非账号会话，账号级的保存和分享仍需登录。这些约束共同指向一个判断：这个 Skill 的设计者并不把“让用户随便改”当作卖点，而是把“谁在什么条件下有权改哪一层”当作核心问题。

需要说明的是，以上边界均来自来源的陈述，属于 source_claim，尚无第一方仓库文档或第三方验证。

来源给出的接入方式按优先级降级：MCP App（画布与对话并排）、托管 MCP connector、浏览器 WebMCP。此外，Playwright、CDP 等能执行 JS 的浏览器控制器也可直接使用，无需安装任何东西。

这条降级链本身透露了一个取向：优先把画布和对话放在同一个界面里，其次才是通过托管连接器或浏览器侧协议接入。但来源未说明托管 MCP connector 与 WebMCP 的具体可用状态或限制，因此这条路径目前只能作为方向性描述，不能当作已可用的能力清单。

必须把证据强度说清楚。所有功能细节均来自单一 X 帖子（含转述与官方宣传语），无第一方仓库文档或第三方验证。该 X 帖子发布于 2026-10-01，显示 65 次浏览。开源仓库地址在来源中仅以短链 t.co/kt6cxDipvo 与 github.com/BuilderIO/skil… 形式出现，未提供完整可核验链接。

来源中「Figma 级视觉编辑」「适用于任何 agent 或模型」「多人协作」等表述为官方宣传，来源未给出具体验证。来源也未说明该 Skill 的发布时间、版本号或支持的技术栈范围，未提供任何性能、准确率或用户量等量化指标。因此，本文中所有功能描述都应读作 source_claim，而非已确认事实。