前端开发中的提示词实战：从需求到代码
引言
上节我们理解了AI处理提示词的底层逻辑和五大核心要素（清晰指令、背景信息、角色设定、约束条件、输出格式）。本节进入实战——把这些要素应用到真实的前端开发场景中，提供可以直接复用的提示词模板。虽然叫"前端开发"，这套方法对 Java、Python、Go 项目同样适用；当你不熟悉某门语言、想用对应的框架或技术方案写代码时，也是同样的打法。
但在开始之前，有一个重要前提需要明确：
AI是你的开发助手，不是你的替代品。 提示词工程能提升效率，但它不能替你理解Vue的响应式原理、不能替你做架构决策、不能替你判断AI生成的代码是否正确。纯写页面的初级工作未来可能被替代，但复杂业务功能的落地始终需要人的干预——客户不懂技术，他只说"我要一个什么功能"，把需求捋清楚、把代码验收合格的还是你。你必须具备判断AI输出质量的能力，才能有效使用AI工具。先懂技术，再用AI提效，不会用AI会被淘汰。
好消息是，学技术的门槛已经降到历史最低：以前要找老师、看视频，现在想学 Vue、React、Java、Go，直接问AI就行——只有热门领域的最新动态和不确定的具体用法才需要额外搜索。用好AI需要三样东西：懂技术（能读懂输出）、有判断力（能判断好坏）、理解原理（知道怎么写好提示词，即上一节的内容）。
提示词的核心心法：把AI当新同事
写好提示词的关键心态：假设你在给一个能力很强、但对你的项目完全不了解的新同事下需求。
回顾上节的五大要素，在实际开发中它们的优先级是：
| 优先级 | 要素 | 为什么重要 |
|---|---|---|
| P0 | 清晰指令 | 模糊需求 = 模糊输出，这是质量差的第一大原因 |
| P0 | 技术上下文 | 不说技术栈，AI可能用Options API写Vue3代码 |
| P1 | 约束条件 | 没有约束，AI会"自由发挥"出不符合项目规范的代码 |
| P1 | 输出格式 | 不指定格式，你需要额外时间调整输出 |
| P2 | 角色设定 | 简单任务不需要，复杂架构设计时很有帮助 |
不需要每次都覆盖全部五个要素。简单任务（改个样式、写个函数）只需要P0，复杂任务（设计组件API、架构方案）才需要全部覆盖。
AI辅助开发的全流程：六个环节
写模板之前先看全景。软件开发流程有很多（敏捷、DevOps 是当下最常见的），但对开发者来说核心环节是固定的六个：
不确定自己团队该在哪些环节引入AI时，直接问模型："我们是3人小团队，想了解基础的开发流程，来选择AI介入提效的切入点。"它会结合上下文给出建议，并标注每个环节AI能做什么：
| 环节 | AI怎么介入 |
|---|---|
| 需求梳理 | 把需求文档（文本/PDF/某段话）丢给AI，让它捋清功能点、拆解用户故事 |
| 技术设计 | 用 Plan 模式出方案、多方案对比（提示链拆轮次） |
| 开发编码 | 六大模板 + CLAUDE.md 约束（本节下半部分实战演示） |
| 代码审查 | 模板四：找潜在bug、最佳实践、性能问题 |
| 测试 | 模板五生成单测；用 Playwright 一类 MCP 工具操作浏览器做端到端验证 |
| 部署上线 | AI生成 CI/CD 配置（第9章展开） |
直接可用的提示词模板
以下模板按照使用频率排序，从最常用到最不常用。每个模板都标注了"什么时候用"和"需要填什么"，直接复制修改就能用。
模板一：生成组件（最常用）
什么时候用：需要从零创建一个Vue组件时。
将
[方括号]中的内容替换为你的实际需求即可。
用 Vue3 + TypeScript + UnoCSS 创建一个 [组件名] 组件。
功能要求：
1. [功能点1，如：支持多种类型：primary、secondary、danger]
2. [功能点2，如：支持多种尺寸：small、medium、large]
3. [功能点3，如：支持禁用状态和加载状态]
代码要求：
- 使用 <script setup> 语法
- Props 使用 TypeScript interface 定义
- 样式使用 UnoCSS 原子类名
请提供完整的 .vue 单文件组件。
text
实例：生成Button组件
用 Vue3 + TypeScript + UnoCSS 创建一个 Button 按钮组件。
功能要求：
1. 支持多种类型：primary、secondary、danger、link
2. 支持多种尺寸：small、medium、large
3. 支持禁用状态和加载状态
4. 支持图标（前置/后置）
代码要求：
- 使用 <script setup> 语法
- Props 使用 TypeScript interface 定义
- 样式使用 UnoCSS 原子类名
请提供完整的 .vue 单文件组件。
text
模板二：重构代码
什么时候用：需要优化现有代码、迁移技术方案时。
请重构以下代码，要求：
1. [约束1，如：将 Options API 改为 Composition API（script setup）]
2. [约束2，如：将重复逻辑提取为 composable]
3. [约束3，如：添加完整的 TypeScript 类型注解]
[粘贴你的代码]
text
实例：Options API 迁移 Composition API
请将以下 Vue2 Options API 组件重构为 Vue3 Composition API：
要求：
1. 转换为 <script setup> 语法
2. 将 v-model + emit 升级为 Vue3 的 defineModel
3. 将 beforeDestroy 改为 onBeforeUnmount
4. 添加 TypeScript 类型支持
下面是原代码：
[粘贴原组件代码]
text
模板三：修复Bug
什么时候用：遇到具体问题时，比搜索引擎更快。
我遇到了一个 Vue3 的 [问题描述]，具体表现是：
[粘贴报错信息或截图描述]
相关代码：
[粘贴出问题的代码片段]
我已经尝试了 [你试过的方案]，
但问题是 [尝试后的结果]。
请帮我分析原因并提供修复方案。
text
模板四：代码审查
什么时候用：写完代码想找找潜在问题时。
请审查以下 Vue3 组件代码，关注：
1. 潜在 bug 和逻辑错误
2. Vue3 最佳实践是否符合
3. 性能是否有优化空间
[粘贴代码]
请给出具体的问题列表和改进代码。
text
模板五：生成测试
什么时候用：需要为组件补测试时。
为以下 Vue3 组件生成 Vitest 单元测试：
组件功能：
- [功能1，如：支持 primary/secondary/danger 三种类型]
- [功能2，如：支持 disabled 和 loading 状态]
测试要求：
- 覆盖所有 Props 的不同取值
- 测试点击事件在 disabled 状态下不触发
- 使用 @vue/test-utils
组件代码：
[粘贴组件代码]
text
模板六：设计组件API
什么时候用：开发新组件前，先设计接口再写实现。
作为一位 Vue3 组件库开发者，请为 [组件名] 设计组件 API。
使用场景：[描述这个组件在哪里用、解决什么问题]
请按以下格式输出：
1. Props（属性名、类型、默认值、说明）
2. Events（事件名、参数、触发时机）
3. Slots（插槽名、作用域数据）
4. 使用示例
text
实战工作流：从需求到代码的完整链路
六个模板是单点武器，这一节串成完整链路——从一个真实诉求出发，走完"初始化 → 读代码 → 拆需求 → 定规范 → 执行验收"的全过程。
工作流一：用对话初始化CLAUDE.md（/init之外的另一条路）
第3章讲过 /init 扫描代码库生成 CLAUDE.md。还有一条更"商量着来"的路：先和模型聊清楚工作方式，再让它按流程生成。示例提示词：
我们是3人小团队，想了解基础的开发流程，来选择AI进行介入提效开发。
请按上述核心流程初始化 CLAUDE.md，在该文件中指引如何使用AI工具提效，
涉及复杂功能时使用 plan 模式先规划再执行。
text
模型会先输出六环节流程建议（标注每步AI能做什么），然后在当前目录生成约百行的 CLAUDE.md：六步开发流程、plan 模式触发条件（涉及3个以上文件改动、新增页面组件时先plan再执行）、提交规范、项目结构说明。项目结构部分换成你自己的目录就能用。这种方法的本质：通过与模型对话让它理解你的工作流，再把工作流固化成规则文件约束后续所有对话。
工作流二：新人接手已有项目
拿到一个有代码、有需求文档的项目，完整走一遍（课程配套了可跟练的材料：notes/04/resources/origin/ 下有 Vue3+Vite 模板项目、新需求.md、新需求_复杂.md 和 项目的风格指南.md，复制一份到本地即可实操）：
- 初始化项目上下文：
/init生成项目级 CLAUDE.md（项目已初始化过则跳过） - 拖入需求，定位关联模块：把需求文档直接拖进对话框，然后说——
我需要完成这个功能需求，请读取代码，告诉我本项目相关联的文件有哪些， 协助我读代码、规划功能。text - 追问项目全貌：模型扫描完会输出项目结构、核心文件、当前状态和改动规划；顺着它的输出继续问"如何启动这个项目、如何配置基础运行环境"，它会给出具体步骤
- 对不熟悉的模块小白式追问：比如对
useUserStore不熟，直接复制过来问——useUserStore 这个部分我不熟悉，请假设我是小白，告诉我如何初始化和使用。text
AI 会分三步讲清楚：store 是什么（全局变量仓库）→ 这个仓库长什么样（数据、属性、方法）→ 组件里怎么用。抽丝剥茧，一个模块一个模块问下来，项目就熟悉了 - 初始化环境并运行："请帮我初始化项目环境并运行调试进程"，通过后进入开发阶段
- 先规划后做：按需求"先计划后实施"，或切换 Plan 模式；功能复杂还可以组建 agent 团队（行内 agent 或自定义开发 agent）分工执行
- 计划留档："把上面的计划记录到当前目录下，创建一个 MD 文档"——需求不是总能按顺序完成，留档方便逐项验收
工作流三：复杂需求的拆解与验收
真实需求往往是一份和多轮讨论才定下来的三阶段大文档，工期却只有一个月。把工期和需求一起丢给模型裁剪：
上面的需求相对复杂，工期只有一个月。
请拆解一下如何高效率完成接口文档和落地的开发，规划一个简单可实施的方案。
text
拿到拆解后的计划（含原始工作量估算、可并行部分），接着做三件事：
- 按计划细化：要求AI按这份计划细化工作，安排几个 agent 依次完成——原来一个月的工作量，多个AI并行可能压缩到几天
- 按阶段验收：先完成一、二阶段 → 人工验收 → 通过后再继续后续。不要一口气全跑完再看
- 多轮逼近：某个实现点不贴合细节，就让它调整修改。多轮对话里把需求拆解清楚、计划规划清楚、功能点逐个验收，这就是AI时代的开发方式
代码不规范怎么办：风格指南两方案
落地时最常见的问题：AI 编出来的代码不符合企业或项目规范，"胡说八道编得乱七八糟"。两种解法：
方案一：借用大厂规范。 美团、腾讯等团队的前端规范都是公开的，下载下来直接丢进对话窗口，或写进 CLAUDE.md，要求"按照这份规范来规划上面的计划/实施代码"。企业内部有现成规范当然优先用内部的。
方案二：让AI扫描生成。 没有现成规范时，在 CLAUDE.md 基础上让模型扫描整个项目的代码风格，形成一份风格指南——覆盖工程目录、API接口、数据库、产品文档、设计文档、协作流程的约定，然后按这份指南写代码。
加上风格指南后重新规划，计划的颗粒度会明显不同：组件要遵循风格指南的命名和分层约定、组件API要符合设计规范……一条条对得上，产出自然贴合项目。
进阶技巧：处理复杂任务
上面六个模板能覆盖大部分日常场景。但当任务比较复杂（架构设计、性能优化、大型组件）时，需要两个进阶技巧。
技巧一：思维链——让AI一步步想
不要直接要答案，而是让AI先展示思考过程。这样不仅能得到更好的方案，你还能学到AI的推理逻辑。
基础用法：在提示词末尾加一句"请一步步思考"。
我们需要为组件库选择一个状态管理方案，候选有：Pinia、provide/inject、自定义store。
请一步步思考最佳选择，并说明每个方案的优缺点。
text
进阶用法：给出具体的思考步骤。
请设计一个级联选择器（Cascader）组件。请一步步思考：
1. 首先，分析级联选择器的核心需求和用户交互模式
2. 然后，思考组件的数据结构和状态设计
3. 接着，规划组件的API接口（props、events、slots）
4. 考虑性能优化策略，特别是对大数据集的处理
5. 最后，设计组件的可访问性支持
对每一步，请详细解释你的思考过程和设计决策。
text
技巧二：提示链——拆成多轮对话
不要试图一条消息让AI做完所有事。复杂任务拆成多轮，每轮聚焦一个子任务，效果远好于一次性描述全部需求。
实例：分三轮创建级联选择器
- 第一轮：生成基础结构（数据结构、UI骨架、基本渲染）
- 第二轮：添加交互逻辑（展开下一级、选中关闭、外部点击关闭）
- 第三轮：添加性能优化（虚拟滚动、防抖、懒加载）
核心原则：
- 每轮一个焦点
- 后轮说"基于上面的代码继续"
- 先跑通功能，再加优化
- 每轮生成都验证一下，有问题立刻反馈
- 不追求大跨步：想一次对话就让AI完成一个复杂功能、甚至原先人工几个月的工作量，现阶段做不到——把技巧应用到每一个功能点上，循序渐进推进
上下文管理：让AI跟上你的项目
问题
AI每次新对话都从零开始。你昨天让它用UnoCSS，今天它可能写scoped CSS。
解决方案
把项目规范写在CLAUDE.md中（详见第3章），每次对话自动加载。CLAUDE.md 值得记录三类内容：工程约定与约束（技术栈、语法规范、禁止事项）、项目整体结构（目录职责、核心模块）、代码风格（命名约定、分层规则，没有现成规范就让AI扫描生成风格指南）。这样你只需关注任务本身，不用每次重复说"用Vue3、用script setup、用UnoCSS"。
对于CLAUDE.md没有覆盖的信息，在对话开头简单提一句就行：
我们在开发一个 Vue3 组件库，技术栈是 Vue3 + TypeScript + UnoCSS + Vite。
现在需要设计一个 Table 组件。
text
踩坑记录
| 问题 | 原因 | 解决 |
|---|---|---|
| 生成的代码跑不起来 | 没告诉AI项目环境 | 说明Vite/Vue/Node版本、已安装的依赖 |
| AI用错了技术方案 | 约束太笼统 | 说"用defineModel"而不是"用最佳实践" |
| 代码风格和项目不一致 | 没给参考 | 用@引用已有文件，或说"按XX组件的风格写" |
| 产出不符合企业/团队规范 | 没有规范文档 | 大厂规范丢给AI或写进CLAUDE.md；没有就让AI扫描项目生成风格指南（见实战工作流） |
| 一次改太多看不过来 | 需求范围太大 | 用提示链拆分，或先让AI出方案再写代码 |
| AI忘了前面的对话 | 上下文窗口满了 | 关键信息写CLAUDE.md，定期总结决策点 |
| AI"自由发挥"加了不需要的功能 | 没有明确边界 | 在提示词末尾加"不要添加上述需求之外的功能" |
AI只是工具，技术能力才是核心竞争力
最后强调一点：提示词写得好不好，取决于你对技术的理解深度。
- 你不懂Vue的响应式原理 → 你判断不了AI生成的computed/ref用法是否正确
- 你不懂性能优化 → 你看不出AI写的代码有没有内存泄漏
- 你不懂组件设计 → 你无法评估AI设计的API是否合理
提示词工程能让你更快地把想法变成代码，但想法本身必须来自你。建议的学习顺序是：
- 先学技术：Vue3、TypeScript、组件设计、性能优化
- 再学提示词：掌握本课程的内容
- 在实践中融合：用AI加速开发，但始终保持对代码的判断力
AI能让你从"手写每一行代码"变成"审查和组装AI生成的代码"，但前提是你得有能力审查。AI放大的是你的能力，不是替代你的能力。
最后说说心态：与AI的关系是一种博弈，也是一次双向培养。一方面摸清它的脉络——它擅长什么、边界在哪、什么提示词对它有效；另一方面把它当老师也当伙伴：请教它特定功能怎么实现，同时引导它按你的规范和想法输出。开发过程中不断"训练"它（规范写进CLAUDE.md、成熟流程沉淀成Skill），它就会越用越顺手。这个思路贯穿全书后面每一章。
↑