两周 6900 星：这个工具让草图直接变成 AI 编程提示词
m3e-canvas 是近两周 GitHub 上增速最快的设计工具：在浏览器里像拼积木一样拖出 Material 3 Expressive 界面，连好跳转、调好主题，一键复制给 Claude Code、Codex、Cursor 的提示词。13 天拿下 6900 星。我把它 clone 下来跑通构建和 664 个测试，确认纯前端、零后端、零 API key 也能用。
一句话把应用做出来，卡在哪一步你知道吗
"帮我做一个食谱 App，要 Material 3 风格。"Claude Code 应声开工，十分钟后给你一个能跑的页面——但布局和你脑子里想的不一样：按钮位置不对、卡片层次不对、跳转关系全靠猜。你再描述，它再改，来回三轮，终于"差不多"了。
这就是 vibe-coding（靠自然语言写代码）的日常：代码它写得快，但"你到底想要什么样的界面"这个信息传不过去。文字描述布局，天然低带宽——你说"这里放个大按钮"，它理解成"一个大大的蓝色按钮"，而你想要的是"页面右下角悬浮一个圆形主按钮"。
m3e-canvas（lnkiai/m3e-canvas，MIT）就是来补这一环的：在浏览器里把界面画出来，然后自动翻译成给 AI 编程工具的提示词。9 月 2 日创建，13 天拿下 6900 星（增速榜近 30 天第一，531★/天），我用本机 clone 实测了一遍。
它到底是什么：浏览器里的 M3 画布 + 提示词生成器
先说清楚它不是什么——不是 Figma 平替，不是组件库，不是"AI 生成界面"工具。它是一个面向 vibe-coding 的中间层：你把界面"画"出来，它把"画"翻译成"话"。
画布上能拖什么？Material 3 Expressive 的整套组件：按钮、图标按钮、FAB、chip、应用栏、导航栏、标签页、搜索栏、卡片、列表、对话框、消息条、文本输入、开关、滑块……全部按 M3 Expressive 视觉绘制。拖上去的组件有磁吸连接——两个按钮靠近会连成一组，圆角融合，像真的组件库一样。画布上还能给组件写"行为备注"（比如"点击后收起键盘"），这些备注会原样写进提示词，成为 agent 的实现要求。
然后是三件别的工具少做的事：1. 连跳转。 给任意按钮、图标、导航项指定跳转目标和过渡动画（四个方向滑入、淡入、放大），画布上会出现流程箭头，预览模式里能真的点、真的跳、真的返回。
2. 调主题。 M3 Expressive 的四个轴在一个面板里：配色（7 套预设，或一个基准色生成整套 Material 3 配色，支持深色/浅色/对比度/动态取色）、形状（全部件圆角一键切换）、字体（Roboto 系列）、动效（标准/表现型弹簧方案）。预览里的跳转动画也跟着变。
3. 出提示词。 一键把整个设计翻译成自然语言提示词，支持日/英/中/韩四种语言，目标平台可选 Android（默认）或 Web，提示词会写成对应技术栈的指令。屏幕跳转、组件行为、主题色值全部写进去。
还有一个细节：它支持多屏同设计——手机（412×892）和桌面（1280×800）两种尺寸可以混在同一个设计里，同名屏幕会被提示词写成"同一个屏幕的两种宽度"，bar 自动拉伸、导航栏自动变侧边栏。对要同时出移动端和桌面端的应用，一次画完两端，agent 一次还原。
实测：构建、测试、起服务，一路绿
我把仓库 clone 到本机（Ubuntu，无 GPU），按 README 的 Development 步骤实测：
| 步骤 | 命令 | 耗时 | 结果 |
|---|---|---|---|
| 安装依赖 | npm install | 约 3 分钟 | 成功（node_modules 563M） |
| 构建 | npm run build | 6.3s | 成功，静态导出 out/ |
| 测试 | npm test（vitest） | 9.3s | 19 个文件 664 个测试全过 |
| 起服务 | npm run dev | 首次编译 6s | localhost:3000 返回 200，title "M3E Canvas" |
成本：0 元。纯前端应用，无后端、无数据库、无 API key——AI 辅助功能（可选，给组件写行为描述）是你自带 key 直连各家模型，不经过它的服务器。
耗时：安装约 3 分钟，构建 6 秒，日常用就是打开网页拖组件，零等待。
失败率：0。构建、664 个测试、dev server 一次全过。不确定：我测试的是静态构建路径；浏览器里的拖拽交互（磁吸、跳转预览）没法在无头环境实测，这部分以官方 demo（lnkiai.github.io/m3e-canvas）和测试覆盖为准。
它押中了 vibe-coding 最值钱的一环
为什么 13 天能冲 6900 星？我的判断是它解决的是 vibe-coding 的通用痛点，而不是少数人的工具癖好。
vibe-coding 的核心矛盾是：agent 的理解带宽全押在文字上，而界面设计是空间问题。你可以用 500 字描述一个页面，但一个 30 秒的画布操作能表达同样的信息且零歧义。m3e-canvas 让"视觉决策"留在视觉里完成——你拖、你连、你调主题，然后它把这套结构化的东西翻译成文字，agent 拿到的是"布局明确、组件明确、跳转明确"的施工图，而不是一团模糊的意图。
它和同类生态的配合也顺：拖出来的屏幕可以配 matraic/m3e（M3 Expressive 的 Lit Web Components 实现）或 Beer CSS（Material Design 3 的纯 CSS 框架）真正跑起来；提示词则喂给任何接受 prompt 的 agent——Claude Code、Codex、Gemini CLI、Cursor 都行。
说两点边界。第一，它是"草图工具"，产出的提示词质量依赖你的画布表达——画得越细，agent 还原越准；画个大概，agent 还是自由发挥。第二，不确定/待验证：6900 星是增速榜上的爆发，社区反馈、真实项目的还原率还没有大规模验证数据，它的长期价值要等第一批人把"画布出图 → agent 还原"的完整链路跑熟。
还有个细节值得提：它连 AI 编程工具的使用方式都设计好了——仓库里带了一个 public/agent.md，专门给 Claude Code、Codex 这类 agent 读：agent 自己读这份说明，照着在画布上搭草图，再把链接发回来。也就是说它不只想当"人用的画布"，还想当"agent 和人协作的界面"——人画一部分、agent 补一部分、互相接力。这个野心比"又一个拖拽工具"大得多。它是把"视觉→提示词→代码"这条链路当产品在打磨，而不只是做一个画布。
项目速览
| 项 | 值 |
|---|---|
| 项目 | m3e-canvas |
| 开源地址 | https://github.com/lnkiai/m3e-canvas |
| Stars | 6908（数据采集 2026-09-16） |
| 协议 | MIT |
| 创建 | 2026-09-02（13 天龄） |
| 技术栈 | TypeScript / Next.js 16 / React 19 |
信号强度
前端/移动开发者：如果你用 vibe-coding 搭 Material 风格应用，它是目前把"意图转达"做得最顺的工具之一。Android 原生优先，Web 也能出，画完直接丢给 agent，值得把"画布 → 提示词"加进自己的工作流试试。
设计师：它给了设计师一条新路——不写代码，不切图，在画布上把交互、主题、跳转全定下来，交给 agent 实现。设计交付物从"标注图"变成"可执行的提示词"，这个变化值得关注。
Agent 工具链玩家：m3e-canvas 验证了一个思路：给 agent 的输入不只有文字，也可以是结构化的视觉产物。以后给 coding agent 的"设计输入"大概率不是更长的 prompt，而是这种"画出来就能翻译"的画布。
技术管理者：低成本（纯前端、零服务、MIT）让团队试错几乎没有成本。真正要评估的是产出一致性：同一个画布不同模型还原出来的效果差多少、要不要把提示词模板固化进团队规范——这些还早，但方向值得盯。
vibe-coding 的下一个瓶颈不在代码生成，在"人怎么把自己的想法完整传过去"。m3e-canvas 用一块画布回答了这个问题：与其用文字描述界面，不如直接把界面画出来。这个思路，我认为比多几个模型参数重要得多。
m3e-canvas 押中的是 vibe-coding 最痛的一环——"描述不清楚布局"。它把画草图、连跳转、定主题这些视觉决策留在浏览器里做完，输出的是结构化的自然语言提示词，等于在"人的视觉直觉"和"agent 的代码执行"之间加了一层翻译器。纯前端 + MIT 的路线，让它能靠 GitHub Pages 直接跑，涨星快不是没道理。
本文基于 AI 情报库收录的条目展开深析；事实性信息以原始报道为准，分析与展望为编辑观点。
原始报道：https://github.com/lnkiai/m3e-canvas（GitHub）
