Gemini UI 设计提示词写得越具体，生成的页面越容易接近需求。比起“做一个好看的页面”，更有效的是说明用户要做什么、页面放哪些内容、按钮如何响应，以及手机端怎么排列。以社区读书活动报名页为例，可以先明确场次、名额和表单状态，再逐步调整布局。需要选择工具入口时，可查看 Gemini Design 中文专题。
一、先确定任务：谁在什么场景完成什么动作
首句写用户和目标，能限制生成范围。案例中的用户是社区居民，主要任务是查看活动信息、选择场次并提交报名；工作人员需要看到剩余名额和报名截止时间。先做报名页与确认状态，暂不加入支付、会员积分和复杂后台。这样既保留了真实场景，也避免让模型把需求扩成整套系统。
- 用户：居民在手机上报名，工作人员查看名额。
- 核心任务：读懂主题、选日期、填写称呼和联系方式、确认报名。
- 内容：活动介绍、主讲人、时间地点、名额、截止时间、注意事项。
- 状态：可报名、名额已满、报名成功、报名失败。
这张任务卡可以先在 Gemini 对话中讨论，再进入 Canvas。Canvas 可创建或编辑文档、应用、幻灯片和代码，并支持在画布中继续修改。把活动名称、场次和报名状态一起提供，后续改稿时就有明确的内容依据。
二、把页面拆成可检查的结构
第二步列出页面层级，写清首屏看到什么、点击后发生什么。报名页可按“活动摘要—场次选择—报名表单—确认反馈”排列。桌面端可以使用双栏：左侧活动信息，右侧表单；手机端改为单列并让确认按钮固定在视线容易找到的位置。不要只给颜色形容词，还要规定标题层级、按钮文字和错误提示。
为社区读书活动创建中文报名页。首屏显示活动主题、主讲人、时间、地点和剩余名额；下方提供场次选择、称呼、手机号和备注。报名成功后显示确认编号，失败时保留已填写内容并说明原因。桌面端使用信息加表单双栏，390px 手机宽度改为单列。使用 6 条虚构活动数据，标注“演示数据”，不要连接真实报名系统。
如果希望比较两种布局，可以要求 Gemini 给出 A/B 方案，并写出选择标准，例如“优先让用户在 5 秒内找到日期与报名按钮”。这比要求“更有设计感”更容易复盘。
三、提供真实长度的文案和状态样例
AI 生成的卡片可能只有占位文案。提示词应提供最小真实内容：两条活动标题、一个已满场次、一个过长的讲者姓名，以及一条错误提示。要求保留中文标点、日期格式和电话号码脱敏样例。这样能暴露换行、按钮宽度和信息优先级问题。
练习时先使用演示数据，并在提示词里写清哪些按钮只模拟反馈。Canvas 可以预览和编辑应用与代码，适合观察提交后的状态变化；Stitch 适合比较布局、颜色与多屏 UI 方向。
四、改稿提示词要指出位置、动作和保留项
首轮生成后，不要再次贴整段需求。指出组件位置、问题、期望动作和必须保留的规则：
只调整报名表单。把“场次”和“剩余名额”放在同一信息组，390px 宽度下分两行；手机号输入错误时，在字段下方显示“请输入 11 位手机号”，不要清空其他字段；保留蓝紫色主色、活动信息双栏结构和演示数据。请列出改动点与仍需人工检查的项目。
若用 Stitch 做界面探索，可以先要求三种视觉方向，再选一版继续改。Google 早期对 Stitch 的公开介绍提到，它可从自然语言、图片或线框生成桌面和移动界面，并曾介绍前端代码与 Paste to Figma；当前导出入口和格式可能随实验版本变化，发布前应以 Stitch 当前界面核对。实际协作时应由设计师整理组件、字体、颜色和间距，再进入 Pixso，而不是把一次生成当成最终规范。想了解 MCP 衔接，可阅读 Gemini Design MCP 教程。
五、把手机验收写成动作和结果
“适配移动端”太笼统。明确用 390px 和 360px 检查：活动标题不被截断；日期、地点和名额有清晰层级；表单标签与输入框有足够间距；错误提示不会挤出屏幕；提交按钮在键盘出现后仍能找到；没有整页横向滚动。还要检查可报名、已满和报名成功三种状态。若工具无法模拟真实提交，就把“待人工验证”写出来。
完成视觉方向后，可在 Pixso UI 设计协作中统一组件和标注，再邀请开发或运营审阅。把选定的字体、颜色、按钮状态和评审意见保存到同一份设计文件中，方便后续修改。
六、保存一份可复用模板
最后把“用户与目标—页面结构—内容样例—状态—响应式约束—验收步骤”保存为模板。下一次只替换业务字段，就能快速比较结果。若需要让团队共同修改，可进入 Pixso 工作台建立项目，手工整理生成结果后再开始评审。想比较 Canvas 与 Stitch 的具体分工，可继续阅读 Gemini Canvas 和 Stitch 工作流。
