通义千问前端组件提示词：加示例让结果更稳定

使用通义千问生成前端组件时，输出常常偏离项目现有的代码风格——Options API、props定义差异、全局CSS干扰。问题根源不在模型能力，而在于提示词缺乏具体上下文。想要输出稳定且贴合项目，关键不是写“写一个按钮组件”，而是将项目中的真实代码片段作为示例嵌入提示词，让模型明确你的框架、编码规范和风格约定。

确认项目框架与编码约束

打开项目源代码，选取一个结构清晰的Vue或React组件文件（例如src/components/LoadingSpinner.vue），完整复制其结构：包括script setup语法、props定义方式、emits声明、CSS作用域写法，甚至注释风格。这一步不能跳过——模型无法自主推断你使用的是Composition API还是Options API，也无法自动识别项目中是否禁用了内联样式（inline style）。

将这段真实组件代码保存为纯文本，后续直接粘贴到提示词中。

构建包含示例的三段式提示词

方法一：网页端手动拼接（适用于快速迭代验证）

在通义千问网页输入框中，按序写入三部分内容，各部分间空一行：

① 角色与任务：你是一名专注于Vue 3 + TypeScript的前端开发工程师，请根据我提供的模板结构，生成一个严格遵循项目规范的新组件。

② 示例块：使用三个反引号包裹你复制的真实组件代码，例如：```vue<script setup lang="ts">...</script>```。

③ 新需求：请生成一个ConfirmDialog组件，接收title、message、confirmText三个props，点击确认按钮时触发confirm emit，禁止引入任何第三方UI库，CSS采用BEM命名法，style标签添加scoped。

执行此步骤后，模型将严格遵循你提供的示例结构生成组件，不会擅自改用export default或使用ref()包裹props——因为示例中并未包含这些写法。

API调用中嵌入示例的正确方法

若使用DashScope SDK调用通义千问API，务必把示例置于user消息中，system message仅用于角色限定，不得夹杂具体结构信息。

错误做法：将示例放入system prompt——模型会将其视为全局规则，反而忽略后续user指令。

正确做法：system消息只定义角色与边界，user消息第一句复述任务，第二句紧接着提供示例，第三句描述新需求。例如：

system: 你是一位Vue 3专家，仅输出可直接运行的.vue文件内容，不附加解释、不添加markdown代码块标签、不补充未提及的逻辑。

user: 请按照以下模板结构生成新组件 → ```vue<script setup...``` → 现在生成一个支持暗色模式切换的HeaderBar组件，props包含logoSrc和isDark，emit触发darkModeChange，CSS中使用:deep(.icon)穿透样式。来源：互联网