前端 Prompt 工程实战：如何搭建场景化 Prompt 库
一、这一章解决什么问题
前端开发里使用 AI，最常见的问题不是"AI 不会写代码"，而是你给它的任务太模糊。
比如一句：
markdown
帮我写一个用户列表页面AI 很可能会给你一份看起来完整、实际很难接进项目的代码。它不知道你的技术栈，不知道接口结构，不知道组件规范，也不知道你们团队怎么处理 loading、错误态、权限和测试。
更好的做法是把常见任务沉淀成可复用的 Prompt 模板。模板不是为了把一句话写长，而是为了让 AI 每次都拿到足够的上下文、约束和验收标准。
读完本章，你应该能做到三件事：
- 为前端高频场景设计可复用 Prompt。
- 判断一个 Prompt 输出是否能进入项目。
- 在面试中讲清楚你如何用 AI 提升前端开发效率。
二、Prompt 工程的核心：把需求变成可执行指令
Prompt 工程可以简单理解为：用结构化语言告诉 AI 任务目标、上下文、限制条件和输出格式。
前端场景里，一个好 Prompt 通常包含六个部分：
markdown
角色：你希望 AI 以什么身份回答
背景：项目技术栈、业务场景、已有约束
任务：这次具体要完成什么
输入：接口、字段、组件需求、错误信息或报告内容
约束：代码规范、边界条件、禁止事项
输出：希望 AI 按什么格式交付可以记成一个公式：
markdown
好 Prompt = 角色 + 背景 + 输入 + 约束 + 输出格式 + 验收标准其中最容易被忽略的是"验收标准"。如果你只说"写得好一点"，AI 很难稳定执行；如果你说"必须包含 loading、empty、error 三种状态，并提供基础测试用例"，输出就会可控很多。
三、如何判断一个 Prompt 是否合格
在写模板前，可以先用下面这个检查表判断质量。
| 检查项 | 不合格写法 | 更好的写法 |
|---|---|---|
| 任务目标 | 帮我写个组件 | 生成一个 React 用户卡片组件，用于展示头像、姓名、部门和职位 |
| 技术上下文 | 用前端写 | React 18 + TypeScript + Ant Design 5 + CSS Modules |
| 输入信息 | 按常规来 | 给出 Props、接口字段、事件回调和默认值 |
| 输出格式 | 给我代码 | 按文件结构输出 index.tsx、types.ts、styles.module.css、测试文件 |
| 质量约束 | 代码规范一点 | 必须处理 loading、empty、error 状态，Props 完整类型定义 |
| 验收标准 | 能用就行 | 生成后能通过 TypeScript 检查，并覆盖 3 个核心交互测试 |
真正可复用的 Prompt，不是一次生成结果好看，而是换一个类似需求也能稳定输出。
四、场景一：组件开发标准化
1. 适用场景
当团队经常开发列表、表单、弹窗、详情卡片这类业务组件时，最适合沉淀组件生成 Prompt。
这类 Prompt 的重点不是"让 AI 写很多代码"，而是让它遵守项目结构和团队规范。
2. React 业务组件 Prompt 模板
markdown
你是一个资深前端工程师，请基于以下信息生成一个 React 业务组件。
【项目技术栈】
- React 18
- TypeScript
- Ant Design 5
- CSS Modules
- 测试框架：Vitest + React Testing Library
【组件信息】
组件名：{ComponentName}
业务用途：{说明这个组件解决什么业务问题}
使用页面：{在哪个页面或模块中使用}
【Props 定义】
- {propName}: {type} - {说明} - {是否必填} - {默认值}
【交互行为】
1. {交互行为一}
2. {交互行为二}
3. {交互行为三}
【状态要求】
- loading：{加载时如何展示}
- empty：{无数据时如何展示}
- error：{异常时如何展示}
【代码规范】
1. Props 必须有完整 TypeScript 类型定义。
2. 组件内部不要直接请求接口，数据通过 Props 传入。
3. 样式写在 styles.module.css 中。
4. 事件回调用 onXxx 命名。
5. 不要引入无关依赖。
【输出要求】
请按以下文件结构输出：
ComponentName/
├── index.tsx
├── types.ts
├── styles.module.css
└── ComponentName.test.tsx
每个文件单独用代码块输出。
最后补充一个"验收清单"，说明生成代码满足了哪些要求。3. 使用示例
markdown
你是一个资深前端工程师，请基于以下信息生成一个 React 业务组件。
【项目技术栈】
- React 18
- TypeScript
- Ant Design 5
- CSS Modules
- 测试框架：Vitest + React Testing Library
【组件信息】
组件名：UserCard
业务用途：展示用户基础信息，支持点击进入用户详情
使用页面：后台用户管理列表
【Props 定义】
- userId: string - 用户 ID - 必填
- name: string - 用户姓名 - 必填
- avatarUrl?: string - 用户头像 - 非必填 - 默认展示占位头像
- department?: string - 所属部门 - 非必填
- title?: string - 职位 - 非必填
- loading?: boolean - 是否加载中 - 非必填 - 默认 false
- onCardClick?: (userId: string) => void - 点击卡片回调 - 非必填
【交互行为】
1. 点击卡片时，如果传入 onCardClick，则调用 onCardClick(userId)。
2. loading 为 true 时展示骨架屏，不触发点击事件。
3. avatarUrl 为空时展示默认头像。
【状态要求】
- loading：展示 Skeleton
- empty：name 为空时展示"未知用户"
- error：本组件不处理接口错误，由父组件传入 fallback 数据
【代码规范】
1. Props 必须有完整 TypeScript 类型定义。
2. 组件内部不要直接请求接口，数据通过 Props 传入。
3. 样式写在 styles.module.css 中。
4. 事件回调用 onXxx 命名。
5. 不要引入无关依赖。
【输出要求】
请按以下文件结构输出：
UserCard/
├── index.tsx
├── types.ts
├── styles.module.css
└── UserCard.test.tsx
每个文件单独用代码块输出。
最后补充一个"验收清单"，说明生成代码满足了哪些要求。4. 这个模板为什么有效
它把组件开发中最容易出问题的点提前说清楚了：数据从哪里来、状态怎么展示、事件怎么命名、文件怎么组织、测试覆盖什么。
注意不要把所有项目规范都塞进去。组件级 Prompt 只需要包含和当前组件生成强相关的规则。比如代码提交规范、路由权限设计、接口重试策略，就不应该放进这个 Prompt。
五、场景二：性能优化分析
1. 适用场景
性能优化类任务适合让 AI 做"分析和方案拆解"，但不适合只给一句"帮我优化性能"。
你需要提供真实输入，例如 Lighthouse 报告、Bundle 分析结果、资源体积、首屏耗时、页面结构。没有这些输入，AI 只能给通用建议。
2. Lighthouse 报告分析 Prompt
markdown
你是一个前端性能优化专家，请分析以下 Lighthouse 报告，并给出可执行的优化方案。
【项目背景】
- 框架：{React/Vue/Next.js/Nuxt}
- 构建工具：{Webpack/Vite/Rollup}
- 部署方式：{Nginx/CDN/Vercel/其他}
- 页面类型：{官网/中后台/移动端 H5/电商详情页}
【Lighthouse 得分】
- Performance: {分数}
- Accessibility: {分数}
- Best Practices: {分数}
- SEO: {分数}
【主要问题】
{粘贴 Lighthouse Opportunities 和 Diagnostics 内容}
【限制条件】
- 不改变现有技术栈。
- 优先给出 1 天内可以完成的优化。
- 涉及代码改动时，请给出示例代码或配置。
- 不要只解释理论。
【输出格式】
请按以下结构输出：
## 优先级排序
用表格列出问题、影响、优先级、预计收益。
## 快速优化项
列出 1 天内可完成的修改，给出具体代码或配置。
## 中长期优化项
列出需要重构或跨团队配合的优化。
## 验收方式
说明优化后应该如何重新测试。3. Bundle 分析 Prompt
markdown
你是一个前端构建优化专家，请根据以下信息分析打包体积，并给出代码分割方案。
【当前情况】
- 构建工具：{Webpack/Vite/Rollup}
- 主包大小：{xxx KB/MB}
- 路由数量：{数量}
- 最大依赖：{列出体积较大的依赖}
- 是否有 SSR：{是/否}
【Bundle 分析结果】
{粘贴 webpack-bundle-analyzer 或 rollup-plugin-visualizer 的主要信息}
【业务限制】
- 首屏必须加载的模块：{列出}
- 可以延迟加载的模块：{列出}
- 不允许改动的依赖：{列出}
【输出要求】
1. 识别可以懒加载的模块。
2. 给出路由级代码分割方案。
3. 给出第三方库按需引入方案。
4. 说明每项优化的风险。
5. 给出优化后的验证方式。4. 性能类 Prompt 的关键
性能优化不能只问"怎么优化"，要让 AI 基于证据判断优先级。
一个高质量性能 Prompt 至少要包含：
- 当前指标。
- 具体报告。
- 页面类型。
- 业务限制。
- 验收方式。
否则 AI 很容易给出"开启缓存、压缩图片、懒加载"这类正确但不够有用的泛泛建议。
六、场景三：团队协作提效
1. 适用场景
团队协作类 Prompt 适合沉淀那些重复但需要表达质量的任务，比如 Commit Message、PR 描述、技术文档、Code Review 总结。
这类任务的重点是统一格式，降低沟通成本。
2. Commit Message 生成 Prompt
markdown
请根据以下改动生成符合团队规范的 Git Commit Message。
【Commit 规范】
格式：<type>(<scope>): <subject>
type 可选值：
- feat：新增功能
- fix：修复问题
- docs：文档修改
- style：格式调整，不影响逻辑
- refactor：重构
- perf：性能优化
- test：测试相关
- chore：工程配置或依赖调整
【本次改动】
{描述改了什么。如果有 git diff，可以粘贴关键 diff。}
【要求】
1. subject 使用中文。
2. subject 不超过 50 个字。
3. 说清楚改了什么，不要写"优化代码"这种模糊描述。
4. 如果是 fix，说明修复了什么问题。
请输出 3 个备选 Commit Message，并说明推荐使用哪一个。3. PR 描述生成 Prompt
markdown
请根据以下信息生成一份 Pull Request 描述。
【改动背景】
{为什么要做这个 PR}
【改动内容】
{列出主要改动点}
【影响范围】
{涉及页面、组件、接口或配置}
【测试情况】
- 单元测试：{通过/未执行/不涉及}
- 手动测试：{列出测试场景}
- 回归风险：{说明可能受影响的地方}
【输出格式】
请按以下结构输出：
## 改动说明
## 改动类型
- [ ] 新功能
- [ ] Bug 修复
- [ ] 重构
- [ ] 性能优化
- [ ] 文档更新
## 测试情况
## Review 重点
## 截图或录屏
如果是 UI 改动，提醒我补充截图或录屏。
要求：内容具体，避免套话，让 reviewer 能快速判断这个 PR 是否需要重点关注。4. 技术文档 Prompt
markdown
你是一个前端技术文档作者，请帮我写一份技术文档。
【文档类型】
{功能设计文档/接口说明/组件使用文档/项目架构说明}
【目标读者】
{前端新人/后端同事/测试同事/产品经理}
【背景信息】
- 项目名称：{项目名}
- 涉及模块：{模块名}
- 技术栈：{技术栈}
- 当前问题：{为什么需要这份文档}
【核心内容】
{用 bullet points 粗略列出要写的内容}
【输出要求】
1. 使用 Markdown。
2. 先写背景，再写方案。
3. 涉及流程时使用 Mermaid。
4. 涉及字段时使用表格。
5. 最后给出注意事项和 FAQ。
请写成可以直接放进团队文档库的版本。七、Prompt 优化方法：从"能用"到"稳定可复用"
1. 拆解复杂任务
复杂任务不要一次性让 AI 从需求写到代码。
不推荐：
markdown
帮我做一个用户管理页面。更推荐：
markdown
我要做一个用户管理页面，请先只完成第一步：设计页面数据结构和接口调用方案。
【页面功能】
- 用户列表
- 搜索筛选
- 新增用户
- 编辑用户
- 删除用户
【技术栈】
- React 18
- TypeScript
- Ant Design 5
- Zustand
【输出要求】
1. 列出需要的接口。
2. 设计前端状态结构。
3. 说明每个组件负责什么。
4. 暂时不要写具体 UI 代码。先让 AI 做设计，再让它写组件，最后让它补测试。任务越复杂，越要拆成可验证的小步骤。
2. 提供正反示例
如果你希望 AI 按某种风格输出，直接给例子比抽象描述更有效。
markdown
请帮我写表单校验函数，错误提示要具体。
【好的示例】
if (!email.includes('@')) {
return { valid: false, message: '邮箱格式不正确，缺少 @ 符号' };
}
【不好的示例】
if (!validate(email)) {
return { valid: false, message: '输入错误' };
}
请按照好的示例风格，生成手机号和身份证号的校验函数。"具体"本身不够具体。把你想要的输出长什么样写出来，AI 才更容易复刻。
3. 明确输出格式
当 AI 输出要进入文档、脚本或系统时，格式必须明确。
markdown
请整理以下接口字段。
【输入】
{粘贴接口字段}
【输出格式】
只输出 Markdown 表格，字段如下：
| 字段名 | 类型 | 必填 | 默认值 | 说明 |
| --- | --- | --- | --- | --- |
不要输出表格以外的解释。这类 Prompt 的核心是减少后处理成本。你越明确，AI 的输出越容易直接复用。
4. 增加验收清单
很多人写 Prompt 只写生成要求，不写验收要求。建议在模板最后固定加一段：
markdown
输出完成后，请补充一个验收清单，逐项说明：
1. 是否满足技术栈要求。
2. 是否覆盖 loading、empty、error 状态。
3. 是否有完整 TypeScript 类型。
4. 是否存在你做出的假设。
5. 哪些地方需要我根据项目实际情况调整。这样做的好处是，AI 会主动暴露假设和风险，方便你 review。
八、如何建设团队 Prompt 库
Prompt 库不应该只是一个"常用语句收藏夹"，而应该像代码片段库一样被管理。
1. 推荐目录结构
markdown
prompts/
├── component/
│ ├── react-component.md
│ ├── vue-component.md
│ └── component-doc.md
├── performance/
│ ├── lighthouse-analysis.md
│ ├── bundle-splitting.md
│ └── image-optimization.md
├── collaboration/
│ ├── commit-message.md
│ ├── pr-description.md
│ └── tech-doc.md
└── README.md每个 Prompt 文件建议包含：
- 适用场景。
- 输入字段说明。
- Prompt 模板。
- 使用示例。
- 输出验收标准。
- 版本记录。
2. 版本管理
Prompt 也需要迭代。建议记录每次修改原因。
markdown
## 版本记录
### v1.0
- 初始版本，支持基础 React 组件生成。
### v1.1
- 增加 loading、empty、error 状态要求。
- 增加测试文件输出要求。
### v1.2
- 删除过重的 JSDoc 要求，避免生成冗余注释。
- 增加"组件内部不直接请求接口"的约束。版本记录不是形式主义。它能帮助团队知道：这个 Prompt 为什么变成现在这样，以及它解决过什么问题。
3. 迭代流程
建议按这个流程维护 Prompt：
- 记录问题：AI 输出哪里不符合项目要求。
- 修改模板：补充缺失的上下文或约束。
- 重新生成：用同一个案例验证结果是否改善。
- 代码 Review：确认生成内容能否进入项目。
- 更新版本：记录改动原因。
不要因为某次输出不好就直接否定 AI。先判断是模型能力问题，还是 Prompt 缺少上下文。
九、面试中如何表达这类经验
如果面试官问："你平时怎么使用 AI 提升前端开发效率？"
不要只回答：
markdown
我会用 AI 写代码、生成文档、优化性能。这个回答太泛，听不出你的工程判断。
可以这样答：
markdown
我不会直接让 AI 写完整业务代码，而是把前端高频任务拆成几个可控场景，比如组件生成、性能分析、PR 描述和技术文档。
对于组件生成，我会在 Prompt 里明确技术栈、Props、状态要求、文件结构和测试要求，避免 AI 生成不能接入项目的代码。
对于性能优化，我会把 Lighthouse 或 Bundle 分析结果作为输入，让 AI 按影响范围和实施成本排序，而不是只给通用建议。
团队层面，我会把这些高频 Prompt 沉淀成模板库，配合版本记录和验收清单持续迭代。这样 AI 不只是个人提效工具，而是团队规范的一部分。这个回答体现了三点：
- 你知道 AI 适合做什么，也知道它的边界。
- 你能把 Prompt 工程落到前端实际工作流。
- 你有团队协作和质量控制意识。
如果想继续加分，可以补一句：
markdown
我会把 AI 生成结果当成初稿，而不是最终答案。涉及业务逻辑、权限、安全和性能的地方，仍然需要人工 review 和测试验证。这句话能体现成熟度。AI 提效不是跳过工程流程，而是把重复劳动前置自动化，把人的精力留给判断和验证。
十、实战练习
练习一：写一个组件生成 Prompt
选择你项目中最常见的组件类型，比如表单、列表、弹窗或详情卡片。
要求：
- 写清楚技术栈。
- 写清楚 Props。
- 写清楚 loading、empty、error 状态。
- 写清楚输出文件结构。
- 让 AI 生成测试用例。
验收方式：
- 生成代码能否通过 TypeScript 检查。
- 是否需要大量手工修改。
- 是否符合团队命名和目录规范。
练习二：优化一个旧 Prompt
找一个你之前用过但效果不稳定的 Prompt，按下面格式复盘：
| 项目 | 说明 |
|---|---|
| 原始 Prompt | 当时怎么写的 |
| 问题 | AI 输出哪里不符合预期 |
| 缺失信息 | 少了技术栈、输入、约束还是输出格式 |
| 优化版本 | 新 Prompt 怎么改 |
| 验证结果 | 输出是否变稳定 |
练习三：建立一个小型团队 Prompt 库
先不用追求完整，建议从 5 个模板开始：
- React/Vue 组件生成。
- 组件文档生成。
- Lighthouse 报告分析。
- Commit Message 生成。
- PR 描述生成。
每个模板都要有"适用场景"和"验收清单"。没有这两项，Prompt 很容易变成复制粘贴的长文本。
十一、常见问题
Q1：Prompt 是不是越详细越好？
不是。
Prompt 的目标是提供必要上下文，而不是把所有团队规范都塞进去。过长的 Prompt 会稀释重点，也会让 AI 在多个目标之间摇摆。
好的做法是：当前任务需要什么，就提供什么。组件生成 Prompt 不要混入部署规范，性能分析 Prompt 不要混入 Commit 规范。
Q2：为什么同一个 Prompt 每次输出还会不一样？
因为大模型本身有生成随机性，且不同模型对约束的遵守程度不同。
如果你希望输出更稳定，可以：
- 明确输出格式。
- 提供正反示例。
- 使用"必须""禁止"等强约束词。
- 把复杂任务拆成多轮。
- 对关键输出加验收清单。
Q3：Prompt 库需要维护吗？
需要。
只要项目技术栈、代码规范、组件结构发生变化，Prompt 就应该同步更新。否则 AI 生成的内容会逐渐和真实项目脱节。
Q4：团队如何避免每个人写一套 Prompt？
可以把 Prompt 放进团队文档或代码仓库，并在 Code Review 中反向沉淀。
如果大家发现某类代码经常需要重复修改，就说明 Prompt 模板需要更新。Prompt 库不是一次性产物，而是跟着团队实践一起演进的工具。
十二、本章总结
前端 Prompt 工程的价值，不是让 AI 替你完成所有开发，而是把高频、重复、规则明确的任务标准化。
一个合格的场景化 Prompt，至少要包含：
- 明确的任务目标。
- 必要的项目上下文。
- 可执行的输入信息。
- 清晰的质量约束。
- 固定的输出格式。
- 可检查的验收标准。
当你能把组件开发、性能优化、团队协作这些场景沉淀成模板库，AI 才真正从"临时聊天工具"变成"工程效率工具"。
对面试来说，重点也不是背几个 Prompt 技巧，而是讲清楚：你如何把 AI 接入真实前端工作流，如何控制输出质量，如何让个人经验沉淀成团队资产。