Marver画布横空出世：与Figma相反 代码秒变设计稿
内容提要
Marver是一款将代码仓库变为设计画布的工具，与Figma相反，它不内置AI，而是通过渲染TSX/HTML代码生成界面，让编码代理（如Claude Code）根据评论修改代码。它强调“设计即代码”，解决设计与实现脱节问题，支持实时预览、评论锚定和代理协作，但安全依赖用户信任，且存在性能与兼容性局限。
延伸解读
设计即代码：Marver的核心理念
Marver将设计稿直接定义为代码文件，通过渲染引擎在浏览器中展示真实可运行的界面。这与传统设计工具（如Figma）将设计稿作为图片或矢量图形的做法截然不同。Marver强调“设计即代码”，意味着设计过程与代码实现同步，消除了设计与实现之间的脱节。这种理念下，设计师或开发者通过修改代码来调整界面，所见即所得，且所有设计产物（如评论、界面结构）都以文本文件形式存在，便于版本控制和协作。
编码代理作为设计师：工作流程的转变
Marver的设计哲学是将编码代理（如Claude Code、Cursor等）视为真正的设计师，人类通过评论框下达指令，代理负责修改代码。这一流程与Figma中人类直接操作画板、AI辅助的模式相反。Marver本身不包含AI，而是依赖用户本地的编码代理，通过检测环境变量或PATH自动选择代理。这种模式将设计任务转化为代码任务，使得设计变更可追踪、可审查，但也要求用户具备一定的代码能力，并信任代理的执行。
安全与信任边界：Live Jam的潜在风险
Live Jam功能允许代理根据评论自动修改代码，但Marver的安全模型并非基于沙盒，而是依赖用户信任。虽然Marver会禁用代理的shell访问权限，但文件读写工具并未限制在design/文件夹内，且部分CLI保留网络访问，存在数据泄露风险。Marver建议用户仅在自己信任的仓库和机器上启用，并亲自审查每次改动（diff）。这提醒用户，自动化代理虽便捷，但安全责任最终在用户自身。
技术局限与未来改进
Marver作为年轻项目，存在性能与兼容性问题：复杂board可能导致卡顿；Next.js支持不完整，如next/font、next/image等无法在frame中正常使用。但作者持续修复，版本已至0.10.2。此外，Marver的评论锚点机制基于代码语义、结构和文本三层，当代码大幅重构时评论可能丢失，这引发关于设计评论归属的思考。用户需了解这些局限，合理预期工具能力。
Q&A
Marver是什么？它与Figma有什么不同？
Marver是一个将代码仓库变成设计画布的工具，它不内置AI，而是通过渲染TSX/HTML代码生成界面。与Figma相反，Figma是设计师手动绘制界面，而Marver让编码代理（如Claude Code）根据评论修改代码，实现“设计即代码”。
Marver的工作流程是怎样的？
Marver的工作流程是：项目中的TSX/HTML代码文件 → Marver渲染引擎 → 浏览器中的设计画板。代码是输入，画板是输出。用户通过评论@marver，编码代理修改代码，画板实时刷新。
Marver如何与编码代理协作？
Marver通过检测环境变量或PATH来识别已安装的编码代理（如Claude Code、Cursor等），并在评论中@marver时自动启动代理。代理读取design/AGENTS.md文件了解规则，修改代码后画板自动刷新，并在评论中回复。
Marver的安全机制是怎样的？
Marver的安全机制包括：只有本地评论才能触发任务，启动代理时禁用shell访问权限（如Claude Code禁用Bash，Codex和Cursor使用OS沙盒），但文件读写工具未被限制在design/文件夹内，因此建议用户不要在不信任的仓库或机器上运行，并审查每次diff。
Marver有哪些局限性？
Marver的局限性包括：性能问题（复杂frame会导致卡顿）、Next.js支持不完整（如next/font、next/image不可用，Server Components无法运行），以及安全依赖用户信任。
Marver的评论锚点机制是什么？
Marver的评论锚点机制是“分层锚点”，将评论锚定在源代码语义、结构和模糊文本三层之上，使得代码修改后评论仍能定位。但如果三层都改变，评论可能会丢失。
