Grok Bot设计师访谈：一段语音，怎样变成可操作的原型

John Bai 在健身房收到一项设计任务：给一批机器人介绍素材补上图标，大小和位置要与已有设计保持一致。他没有回到电脑前重新排版，而是截了两张图，录下一段口语化的说明，交给自己的AI助手处理。

这个故事来自 How I AI 主持人 Claire Vo 与 Grok Bot 设计师 John Bai、Peng Zheng 的对话。John展示了另一件更有意思的事：一个还没认真整理过的界面动画想法，也可以先交给AI做成可交互原型，等看过效果再决定是否继续。

两次演示给出同一个启发：想法不必完全成熟才开始动手，但随口表达能产生有用结果，往往是因为截图、既有规则和工具连接，已经替人交代了大量细节。

一段语音，为什么能完成排版？

John把自己的AI设计助手叫作FigmaBro。Figma是一款协作设计工具，可以在画板上排列图标、文字和界面元素。

接到任务时，他已经有两份现成资料。一张截图来自图标库，另一张来自需要补齐图标的品牌素材。他还提供了Figma文件链接。

他给助手的语音大意是：左边有现成的图标，另一张图里有些机器人还缺图标。请把图标放大，按照已经完成的样式，放到相同的位置。如果哪里不清楚，就告诉我。

这段话并不精确，没有逐个标注坐标，也没有规定每个图标的尺寸。但任务包含了足够清楚的参照：哪些元素可以使用，哪些位置需要修改，以及完成后应当与什么保持一致。

John说，助手产生了三个输出，随后又根据反馈调整尺寸、圆角效果和颜色。整个过程主要通过手机上的消息完成。

如果只记住“语音就能操作Figma”，很容易误解这次演示。

主持人追问AI究竟怎样连接Figma时，John补充了关键细节：他使用了Figma的MCP连接。MCP可以理解为一种让AI调用外部工具的接口；有了适当权限，AI才可能真正读取或修改设计文件，而不只是提出修改建议。

他还提前给FigmaBro设置了工作习惯，例如画板横向排列、彼此间隔约50或100像素，并让助手遵守已有模板。这些要求减少了反复交代细节的需要，也降低了生成凌乱文件的可能。

换句话说，John临时说出口的只是一项任务的变化部分。稳定的设计习惯、可参考的样例，以及操作工具的能力，早已配置在工作环境里。

这才是语音交办能够成立的原因。

有参照的任务，更适合直接交办

这次任务还有一个容易忽略的特点：它的答案大致已经存在。

设计师并不需要重新发明一套图标风格，只需把已有规则应用到尚未完成的素材上。AI可以参考样例，复制布局关系，再交给人检查。

John在访谈中展示的另一项任务也符合这一特点。他先制作一份营销素材模板，再让助手把相同风格扩展到其他素材，替换背景、图片和文案。

但他没有说所有结果一次就完成。展示过程中，他发现部分图片还没有更新到位，需要继续催促助手修改。

这个小细节比一句“AI自动完成设计”更能说明实际工作方式。

当任务有明确样例时，AI较容易判断应该模仿什么，却仍可能遗漏某些项目。人需要能够看到结果，发现问题，再要求它修正。已有模板提高了一致性，但并不保证每个对象都正确更新。

这种方式的价值，主要体现在重复性制作中。任务规则相对稳定，变化集中在少数内容上，人工检查也有明确依据。

对于普通使用者，道理同样适用。假设要把一份已经定稿的图表样式复制到其他页面，提供原样、待处理内容和验收标准，会比只说“帮我做得专业一点”更容易得到可检查的结果。

不过，John真正让我关注的，是他如何把类似的交办方式用在另一类工作上：那些连自己也不知道最终答案的想法。

原型做出来以后，他决定不用

John展示过一个移动应用中的分享动画构想。

当用户分享一个AI助手时，他希望界面先出现类似截图的效果：当前画面缩小，过渡到一张能够分享的预览卡片。

这个想法涉及画面变化、动画节奏以及用户点击后的反馈。要判断它是否自然，仅凭几句话并不容易。

John当时不在电脑前。他截下已有移动应用的界面，又截取了一个名叫Slack Search的机器人界面，通过语音描述自己的设想，交给DevBot和Experiments这两个用于开发实验的助手处理。

其中一个助手还与名叫Motion God的专用助手交流，处理动态过渡。John说明，为了完成演示，他们需要在测试代码库中重新建立部分界面组件。

最终，他得到了两个可以操作的方案。

第一个版本包含明显的截图、缩放和预览过程；第二个版本更克制，直接过渡到分享界面。John能够点击、切换页面，观察细节，而不必单凭想象推断动画是否合适。

结果却是：他决定不采用这个方向。

原因并非AI无法生成原型，而是完成之后，他认为这个交互太像iOS已有的截图效果，缺少足够独特的设计价值。

这让AI原型的作用变得具体了。

它没有替John证明创意值得上线，而是让原本停留在脑海里的感觉，变成可以直接比较和否定的东西。

过去，复杂的交互想法可能需要先制作大量设计稿，或者协调工程师写出可运行的代码。现在，John可以先让已有的AI工具生成一个实验版本，再决定有没有必要继续投入。

主持人Claire把这种做法称为“垃圾桶式软件开发”：更容易制作，也更容易放弃。

这里的“容易放弃”并不是说创作没有价值。恰恰相反，能够低成本地排除一个不合适的方向，可以让团队把更多精力留给真正值得完善的方案。

当然，这不意味着原型开发没有成本。John已有多个专用助手、测试代码库和可复用的界面组件。演示没有提供完整的时间、费用和后续维护数据，也不能证明同样的流程适合所有团队。

先把想法变成可以判断的东西

John的两次演示，实际上对应两种不同的判断方式。

在图标排版任务里，正确答案可以通过现有样例确定。AI主要承担执行和重复制作，人检查它有没有偏离规则。

在分享动画任务里，答案尚不存在。AI承担的是快速尝试：先让一个想法有具体形态，使人能够评价它的美感、交互感受和实际价值。

两种任务都用到了截图和语音，却不能因此认为语音本身有什么特殊魔力。

截图提供视觉背景，现成样例限定结果，预设偏好维持一致性，工具连接赋予实际操作能力。至于最终是否完成、是否值得继续，仍要通过检查来决定。

这也给普通AI使用者提供了一条比“先写完美提示词”更实用的思路。

当你已有参考资料，只是需要重复执行，可以尽量明确哪些部分必须保持一致、哪些部分允许变化，以及最后怎样检查。

当你只有一个模糊想法，可以先要求AI产出能够观察、修改和比较的草案，而不急于把它写成完整方案。对于设计，可以是交互原型；对于其他工作，也可能是一份结构草稿或几种表达方式。

前提是，输出要足够具体，能够暴露问题。缺少可参考的事实、没有相应工具权限，或者涉及必须严格验证的结果时，口语化交办无法代替必要的准备和审核。

这场访谈最值得关注的变化，是人可以提前进入判断阶段：还没想清楚的方案，先看它实际变成什么样。

John最后放弃了那个分享动画。这不是演示的遗憾，而是它最有说服力的结果——一个尚未被采纳的创意，也可以通过原型帮人更快作出决定。