给大模型下达前端组件生成任务时，提示词的颗粒度直接决定了产出代码是否能用。Gemini这类模型本身具备很强的代码理解能力，但它并不会主动替你把“视觉规范”“边界条件”“无障碍要求”这些隐性的工程约束补全。你写得越模糊，它返回的代码就越像教学示例；你写得越精确，它就越可能输出可以直接合并进仓库的组件。所以别把提示词当成一句愿望，要把它当成一份微型技术规格书。
把组件需求拆解为不可再分的规格
一个前端组件的需求通常包括属性、事件、插槽、样式变体、尺寸策略、默认值和边界表现。如果你只说“生成一个卡片组件”，Gemini大概率会给出一个固定样式的div，里面塞进标题和文字，连props都没有。但如果你把每个维度都列出明确清单，它就会按照清单逐项实现。
以React + TypeScript的按钮组件为例，一份合格的提示词应该包含：组件名称、框架和语言版本、所有可配置属性、每个属性的类型和默认值、事件回调签名、是否支持原生button属性透传、禁用态与加载态的行为、键盘交互要求。把这些写清楚之后，Gemini生成的代码通常已经能直接通过编译。
// 提示词示例：请使用React 18 + TypeScript生成一个Button组件 // 属性：variant（primary/secondary/ghost，默认primary） // size（sm/md/lg，默认md） // disabled（boolean，默认false） // loading（boolean，默认false） // onClick（MouseEventHandler<HTMLButtonElement>，可选） // 要求：组件继承原生button的所有HTML属性 // 当loading为true时自动添加disabled并显示加载中的文本 // 使用forwardRef转发ref到内部button元素 // 不要引入任何第三方UI库，样式通过CSS Modules实现
上面这段提示词看起来篇幅不短，但每一句话都对应一个具体的代码决策。比起写“生成一个好用的按钮”，这种规格化的描述能让Gemini减少自由发挥的空间，把注意力集中在你真正关心的地方。如果你的团队已经有一套组件规范，完全可以把规范文档中的字段定义直接粘贴进提示词，Gemini对结构化文本的理解能力非常强。
用设计Token和代码规范约束生成结果
只定义组件接口还不够，否则Gemini可能会用一堆硬编码的颜色值、随意的margin和padding来填充样式。要把设计系统也喂给它。例如在提示词中明确写出“颜色使用CSS变量 var(--brand-primary)、var(--text-secondary)”“间距只能使用4px的倍数”“圆角统一为6px”。这样生成出来的样式才有资格进入真正的项目。
除了视觉规范，代码风格约束同样重要。告诉Gemini你的项目用的是一般函数组件还是箭头函数、props是否要求解构、文件名和导出方式是什么、是否需要PropTypes或JSDoc注释。很多人忽略了这一点，结果拿到的组件虽然能运行，但和仓库里其他代码风格完全不同，review时被当成“AI味”代码打回。
// 提示词补充：样式约定 // 颜色：使用CSS变量 var(--color-primary)、var(--color-bg)、var(--color-text) // 间距：只允许 4px, 8px, 12px, 16px, 24px，禁止其他数值 // 字体：字号12/14/16，行高1.5 // 文件名：Button.tsx，默认导出函数组件 // 组件内禁止使用内联style，统一使用import styles from './Button.module.css' // 必须包含一段JSDoc说明每个props的含义
把设计Token写进提示词还有一个额外好处：当后续需要调整主题或品牌色时，只需要在提示词里替换变量名，Gemini就会自动适配新的视觉变量，而不会在代码深处埋下magic number。同样地，如果你约束了“禁止用any”“必须处理未定义值”“所有事件处理函数需要显式声明参数类型”，能显著降低后续TypeScript报错的数量。
通过多轮对话修正边界情况
第一版代码很少能一次到位，尤其是涉及到异步加载、表单联动、键盘导航这类复杂交互。比较好的做法是先让Gemini生成一个基础版本，然后针对暴露出来的问题追加约束。比如第一次它没有处理loading状态下禁用点击的问题，你可以在第二轮提示词中明确指出“当loading为true时，即使用户传入了onClick也不应该触发，并且在内部button上设置disabled”。
不要试图在一开始就把所有可能的边界情况都写全，那样提示词会变得冗长而且难以维护。更合理的策略是“先骨架、后补丁”。每发现一个不符合预期的行为，就追加一条针对性的修改指令。Gemini在多轮对话中的上下文理解能力足够强，它能记住之前生成的代码和你的约束，并准确地修改对应部分。
// 第二轮提示词示例： // 请修改刚才生成的Button组件，要求： // 1. loading为true时，按钮内部显示一个span元素，文本为“加载中...” // 2. 此时按钮的disabled属性强制为true，且忽略外部传入的disabled值 // 3. onClick回调在disabled状态下不执行 // 4. 为按钮添加aria-busy属性，值为loading ? true : undefined // 5. 不要改动其他无关逻辑
这种增量式的提示词写法能让Gemini保持输出稳定，也方便你在本地对每一版diff进行审查。如果一次性塞入太多修复要求，模型有时会顾此失彼，例如为了修一个样式问题而把另一个props的默认值改掉。多轮对话的另一个好处是，你可以随时用“请保留之前的方案，只修改xxx”来限制改动范围，模型对这类指令的遵循程度通常很高。
让Gemini自测并输出使用文档
拿到最终组件代码之后，还可以再利用Gemini做一轮质量检查。你可以要求它“分析上面这个Button组件，指出哪些地方可能无法通过react-hooks/exhaustive-deps检查”“检查是否有无障碍问题”“如果放在严格模式的TypeScript项目中，可能产生哪些编译错误”。模型会像一位审查者那样列出潜在风险，你可以根据这些风险点继续追加修正提示词。
更实用的一步是让Gemini基于最终代码生成一份使用文档，包括每个props的表格说明、默认值、示例代码，以及集成到项目中的步骤。这样做不仅方便同事使用，也能迫使你自己重新审视组件设计是否足够清晰。如果某个props的文档写起来很别扭，那往往意味着这个props本身的设计就有问题。
提示词的迭代过程和写代码一样，没有一劳永逸的模板。每次拿到不理想的输出，就分析一下是哪个约束没有表达清楚，然后把那条约束提炼成可复用的短语，沉淀进自己的提示词库。用不了多久，你就能形成一套符合自己项目风格的“组件生成提示词规范”，到那时Gemini才会真正变成一个可信赖的前端开发搭档。