Google 在 11 月 5 日上线了一个挺轻的功能：把随手画的草图，直接变成能点、能玩的 App。放在一堆大模型发布里它不算重，但它背后那套「把纸面原型直接推进到可交互」的流程，对做原型、做 demo 的人有点意思。

发生了什么

先下判断：这不是又一个文生图，而是把「从草图到可交互应用」这段原本要手动写代码的路，压成了拍照加一句指令。

完整的流程是三步。第一步，把草图拍照上传给 Gemini——官方的例子是 App 界面草图、习惯打卡器、桌游棋盘这类。第二步，选中 Canvas 工具，然后问它一句「Can you code this app?」，Gemini 会读图、写代码。第三步，在预览窗口里试用这个工具，而且可以实时调整——配色、字体、功能都能改。原文的收尾是一句「下次灵感来了，用 Gemini 把它变成现实」，整个功能的定位很清楚：给纸面原型的快速落地。

关键变化清单

逐个核对原文事实：

  • 输入形式：手绘草图照片，官方举例 app mock-up（界面原型）、habit tracker（习惯打卡）、game board（桌游棋盘）三种。
  • 工具：Canvas，需要手动选中后下达指令。
  • 指令示例：原文直接给了那句「Can you code this app?」。
  • 生成：Gemini 读取图像内容并写代码。
  • 预览：有预览窗口（preview window），可实时调整 colors（配色）、fonts（字体）、features（功能）三项。
  • 发布时间：2026 年 11 月 5 日。

对开发者意味着什么

最直接的信号是：原型阶段的「编码」正在被图像理解加代码生成接管。过去一个产品的纸面草图，要产品经理画完、设计师出稿、前端再手动切，中间隔着好几道。现在拍照就能拿到一个可交互的东西，哪怕它粗糙，也能立刻验证「这个交互对不对」「这个布局顺不顺」，把验证环节大幅提前。

对开发者，这里真正可复用的不是 Gemini 本身，而是那个「草图→可交互原型」的工作流范式。你自己的项目里，如果用户或客户总用草图、截图描述需求，一条「读图→生成代码→可预览可改」的链路，能显著压缩对齐需求的时间。原文特意强调实时调整配色、字体、功能，说明这个工具的价值不在一次性生成，而在生成之后那段反复试、反复改的循环。

和截图转应用工具的关系

判断写进第一句：Gemini 这一步，本质上把此前只属于垂直工具的能力，拉进了通用助手。

过去两年，「截图/草图转应用」一直是 v0、Lovable、Bolt 这类垂直工具的主打，面向的是会写点代码、想快速出原型的开发者。Gemini 的差别在入口——它长在一个几亿人已经在用的通用助手里，用户不用专门去开一个新工具，画张图、拍一下、说一句就行。这意味着「草图转应用」从「开发者的垂直工作流」下沉到了「普通人的随手一试」。对垂直工具是个压力，对生态则是把用户教育这件事替所有人做了——当越来越多人习惯「拍图就能拿到可交互的东西」，整个品类的水位都会被抬高。

待观察

原文没写的，恰恰是决定它能不能真正进工作流的部分。一是可用范围——官方博客没提支持哪些地区、哪些平台、要不要付费订阅，这些边界不明确前，很难判断能覆盖多大用户。二是生成质量——「能生成」和「生成的东西能用」是两回事，草图越潦草，代码能猜对的概率越低，目前原文没给任何质量或成功率的说法。三是和正式开发的衔接——预览窗口里改出来的东西，怎么导出成能继续开发的工程，原文没提。

所以把它定位成「快速验证原型的工具」比「无代码开发平台」更准确。它解决的是「想法变成能点能玩的东西」这一段，不是「能玩的东西变成能上线的产品」这一段。对后者，你手里的编辑器还不会失业。定位先摆正了，才不会对它抱错期待。