AI时代前端工程师实战指南：Prompt工程

发表于 分类于 阅读次数：

AI时代前端工程师实战指南：Prompt工程

本文目的：从”随机问 AI”到”系统化地使用 AI”，建立可复用的 Prompt 工程体系。涉及 .cursorrules、CLAUDE.md、AGENTS.md、项目级 Prompt 模板库等多种配置文件的使用。

4.1 为什么需要 Prompt 工程？

一个简单的实验：同样的问题，不同问法，AI 的回答质量天差地别。

1
2
3
4
❌ 差："帮我写一个搜索组件"
    → AI 生成一个最简单的搜索框，大概率不符合项目规范

✅ 好：见下方结构化 Prompt

Prompt 工程就是在系统化地缩小 AI 的”猜测空间”。你给的信息越精确，AI 的”猜测”就越接近你的真实需求。

1
2
3
4
5
AI 的猜测空间：
  无限可能 ──────────────→ 精确匹配需求
     ↑                          ↑
  模糊 Prompt              结构化 Prompt
  （"写个搜索"）         （带约束、上下文、格式）

4.2 结构化 Prompt 五要素

这是本文推荐的 Prompt 框架，适用于大多数 AI Coding 工具（Cursor、Claude Code、OpenCode、ChatGPT）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
┌─────────────────────────────────────────┐
│  ① 角色定义                              │
│  你是一个 [角色]，精通 [领域]               │
├─────────────────────────────────────────┤
│  ② 上下文                                │
│  项目背景、技术栈、相关文件                │
├─────────────────────────────────────────┤
│  ③ 任务描述                              │
│  具体要做什么，输入是什么，预期输出是什么    │
├─────────────────────────────────────────┤
│  ④ 输出格式                              │
│  代码/文档/列表/JSON，是否需要注释          │
├─────────────────────────────────────────┤
│  ⑤ 约束条件                              │
│  风格约束、性能约束、安全约束、负面清单      │
└─────────────────────────────────────────┘

完整示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
┌─ ① 角色 ──────────────────────────────────────────┐
│ 你是一个资深前端工程师，精通 Vue 3 Composition API    │
├─ ② 上下文 ──────────────────────────────────────────┤
│ 项目使用 Vue 3 + TypeScript + Tailwind CSS           │
│ 参考现有组件：@src/components/BaseInput.vue          │
├─ ③ 任务 ────────────────────────────────────────────┤
│ 实现一个防抖搜索组件 SearchInput                      │
│ 用户在输入框输入，300ms 后调用 /api/search?q=xxx      │
│ 显示搜索中状态、空状态、错误状态                      │
├─ ④ 格式 ────────────────────────────────────────────┤
│ 使用 <script setup lang="ts">                        │
│ Props 和 Emits 要有完整类型定义                       │
│ 输出单个 .vue 文件                                    │
├─ ⑤ 约束 ────────────────────────────────────────────┤
│ - 防抖逻辑放在 composable 中（useDebounce）           │
│ - 不要使用 any 类型                                   │
│ - 不要修改现有文件                                    │
│ - 处理组件卸载时的竞态条件                              │
└─────────────────────────────────────────────────────┘

4.3 Codebase-aware Prompt 设计

Cursor/Claude Code/OpenCode 的一大优势是能感知整个项目。设计 Prompt 时要充分利用这一点。

告诉 AI 参考谁

1
2
3
4
5
6
7
8
# ❌ 不好的做法：没有参考
实现一个表单验证组件

# ✅ 好的做法：告诉 AI 参考什么
实现一个表单验证组件，参考以下现有代码的风格：
- @src/components/LoginForm.vue（表单结构）
- @src/utils/validators.ts（验证逻辑）
- @src/types/form.ts（类型定义）

告诉 AI 不要碰什么

1
2
3
4
5
6
# 明确负面清单
请实现用户列表页，注意：
- ❌ 不要修改 @src/api/user.ts（API 层不需要改动）
- ❌ 不要修改 @src/router/index.ts（路由不需要改动）
- ❌ 不要引入新的 npm 包
- ✅ 只创建 @src/views/UserList.vue 和 @src/components/UserCard.vue

给 AI 提供错误/成功示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# 告诉 AI 什么风格是你想要的 vs 不想要的
✅ 正确的模式（我们项目中已有的）：
export function useUser() {
  const user = ref<User | null>(null)
  const loading = ref(false)
  // ...
  return { user, loading }
}

❌ 不正确的模式（不要用这种方式）：
export default {
  setup() {
    // Options API，不要用
  }
}

4.4 Context Window 管理

AI 的上下文窗口是有限的（Cursor 约 10 万 token，Claude Code 约 20 万 token），你给的内容越多，AI 的回答质量越稳定，但超出后质量会急剧下降。

有效上下文 vs 无效上下文

1
2
3
4
5
6
7
8
9
10
✅ 有效上下文
- 相关文件的代码结构和类型定义（不需要全部内容，可以只贴关键部分）
- 项目规范（通过 .cursorrules / CLAUDE.md）
- 错误信息和调用链

❌ 无效上下文（占空间但不提供有用信息）
- 整个 node_modules 或 dist 目录
- 500 行无关的 CSS
- 重复的对话历史
- "你好"、"继续"、"帮帮我"等无效轮次

上下文策略

场景 建议的上下文策略
新功能开发 引用依赖的文件 + 规范文件，其余不引用
Bug 修复 报错信息 + 调用链上相关文件 + 你尝试过的方案
重构 旧代码完整内容 + 期望的新结构描述
Code Review diff 内容 + 项目规范 + 需要关注的重点

压缩技巧

当你需要给 AI 大量上下文但窗口不够时：

1
2
3
4
5
6
7
8
9
10
11
12
技巧 1：只贴接口/类型定义，不贴实现
  ✅ 贴接口：export interface User { id: number; name: string }
  ❌ 贴整个实现文件（500 行）

技巧 2：用 @Folder 让 AI 自己读取
  ✅ @src/api/（让 Agent 自己去读需要的文件）
  ❌ 手动把所有 API 文件内容复制粘贴进来

技巧 3：分步进行
  第一轮：先让 AI 理解架构
  第二轮：再让 AI 开始实现
  第三轮：Review 和修复

4.5 Prompt 模板化

把常用的 Prompt 固化为模板，避免每次重写。

模板管理方式

1
2
3
4
5
6
7
项目根目录/
├── prompts/
│   ├── component.md          # 创建新组件的 Prompt 模板
│   ├── api-service.md        # 创建 API 服务层的 Prompt 模板
│   ├── fix-bug.md            # Bug 修复的 Prompt 模板
│   ├── code-review.md        # Code Review 的 Prompt 模板
│   └── unit-test.md          # 生成单元测试的 Prompt 模板

Template 示例：prompts/component.md

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
你是一个资深前端工程师，精通 [框架] + TypeScript。

## 上下文
- 项目：[项目名称]
- 技术栈：[Vue 3 / React 18]
- 样式方案：[Tailwind CSS / CSS Modules]
- 参考文件：[相关文件路径]

## 任务
创建一个 [组件名] 组件，功能是 [功能描述]。

## Props 接口
- [prop1]: [类型] - [说明]
- [prop2]: [类型] - [说明]

## Emits/事件
- [event1]: [payload] - [触发时机]

## 状态说明
- [状态1]: [描述]
- [状态2]: [描述]

## 约束
- 使用 [Composition API / Hooks]
- 完整的 TypeScript 类型
- 处理 loading / empty / error 状态
- 性能：数据量大时考虑虚拟滚动

4.6 配置文件的 Prompt 作用

不同类型的配置文件在不同工具中起到”后台 Prompt”的作用：

文件 工具 作用 优先级
.cursorrules Cursor 指导 Cursor AI 的行为规范 最高，每次都读
.cursor/rules/*.mdc Cursor (新版) 按文件路径匹配的规则 命中时生效
CLAUDE.md Claude Code 项目级别的上下文和指令 每次都读
AGENTS.md OpenCode Agent 的知识库和行为规则 每次都读
.github/copilot-instructions.md GitHub Copilot Copilot 的代码风格指令 补全时参考

以下是一个完整的 CLAUDE.md 配置示例，它为 Claude Code 提供了完整的项目上下文和行为指令：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
# CLAUDE.md — Claude Code 项目指南
# 位置：项目根目录
# 作用：指导 Claude Code 理解项目结构、约定和行为规范

## 项目概览
这是一个 [Vue 3 / React] 前端项目，使用 TypeScript + Vite 构建。
详细的架构说明见 docs/ARCHITECTURE.md。

## 技术栈
- 框架：[具体框架]
- 构建：Vite
- 语言：TypeScript (strict)
- 样式：[Tailwind / CSS Modules / styled-components]
- 测试：Vitest
- Lint：ESLint + Prettier

## 代码约定
1. 所有文件使用 2 空格缩进
2. 组件文件：PascalCase（UserProfile.tsx）
3. 工具文件：kebab-case（format-date.ts）
4. 类型定义集中在 src/types/
5. API 调用统一在 src/api/ 中，使用 axios 实例

## 开发工作流
- npm run dev — 启动开发服务器
- npm run test — 运行单元测试
- npm run build — 生产构建
- npm run lint — 代码检查

## 在使用 Claude Code 时的最佳实践
1. 复杂任务先用 /plan 生成计划再执行
2. 涉及多文件修改时，使用 Claude Code Agent 模式
3. 代码生成后执行 npm run test && npm run lint 验证
4. 大量重构前先 git stash 或创建新分支

配置文件的最佳实践

1. .cursorrules 应该包含什么？

1
2
3
4
5
6
7
8
9
10
11
12
13
14
✅ 必须有的：
- 技术栈声明（框架、语言、构建工具）
- 代码风格规范（缩进、命名、import 顺序）
- 项目结构说明

✅ 建议有的：
- 常用组件的路径和用法
- 当前正在开发的功能说明
- 已知的技术债务和遗留问题

❌ 不要放：
- 400 行以上的大段内容（占用上下文）
- 经常变化的内容（每次修改都会刷新 AI 的认知）
- 已经过时的技术约束

2. 如何维护多份配置？

对于 Monorepo 或多技术栈项目：

1
2
3
4
5
6
# 项目根目录 .cursorrules — 通用规则
# packages/web/.cursorrules — Web 前端特有规则
# packages/api/.cursorrules — API 服务特有规则

# Cursor 会从当前文件所在目录向上查找，合并所有找到的 .cursorrules
# 越具体的规则优先级越高

3. 利用配置文件控制 AI 行为

在 .cursorrules 中加入行为指令：

1
2
3
4
5
# AI 行为规则
- 在修改现有代码前，先阅读完整的文件内容
- 修改前先创建备份或使用 git
- 每个函数必须有 JSDoc/TSDoc 注释
- 所有错误必须被处理，不允许 throw 未捕获的错误

而对于 GitHub Copilot，其自定义指令文件的格式与侧重点有所不同，更聚焦于代码补全时的风格控制：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# GitHub Copilot 自定义指令
# 位置：.github/copilot-instructions.md
# 作用：为 GitHub Copilot 提供项目级别的上下文，影响代码补全和 Chat 回答

## 技术栈
- 前端框架：Vue 3 (Composition API, `<script setup>`) / React 18+
- 语言：TypeScript (strict mode)
- 构建工具：Vite
- 样式方案：Tailwind CSS / CSS Modules
- 测试框架：Vitest

## 编码规范
1. 使用 2 空格缩进
2. 行尾加分号
3. 字符串使用单引号
4. 组件名使用 PascalCase
5. 文件名使用 kebab-case

## 代码风格偏好
- 优先使用箭头函数
- 解构赋值优先
- 使用 optional chaining (`?.`) 和 nullish coalescing (`??`)
- import 语句分组：第三方库 → 项目内部 → 样式文件

## 测试规范
- 测试文件命名为 *.test.ts
- 测试文件与源文件放在同一目录
- 使用 describe/it/expect 结构
- 优先测试行为而非实现细节

4.7 进阶技巧

技巧 1：Chain-of-Thought (CoT) Prompting

让 AI 逐步推理，而不是直接给答案。

1
2
3
4
5
6
7
8
9
# ❌ 直接问
这个列表渲染为什么卡？

# ✅ CoT 方式
请逐步分析列表卡顿的原因：
1. 先告诉我数据量有多大
2. 分析当前渲染策略
3. 找出可能的性能瓶颈
4. 提出优化方案，分析每个方案的 trade-off

技巧 2：Few-shot Prompting

给 AI 1-3 个输入输出示例，让 AI 理解你要的模式。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
请按照以下模式生成类似的组件：

示例 1 - UserCard：
  Props: { user: User; showEmail?: boolean }
  功能：显示用户头像、名称、邮箱
  状态：loading / ready / error

示例 2 - ProductCard：
  Props: { product: Product; onAddToCart: () => void }
  功能：显示商品图片、名称、价格、加入购物车按钮
  状态：loading / ready / sold_out

现在请实现 OrderCard，类似的模式：
  Props: { order: Order }
  功能：[让 AI 自己推断]

技巧 3：Negative Prompting

明确告诉 AI 不要做什么，比告诉它要做什么更重要。

1
2
3
4
5
6
重要约束：
- ❌ 不要使用 any 类型
- ❌ 不要引入新的第三方依赖
- ❌ 不要修改 src/api/ 目录下的文件
- ❌ 不要使用 display: none 来控制显隐
- ✅ 使用 v-if 或条件渲染

技巧 4：迭代式 Refinement

不要期望 AI 一次给出完美答案，通过多轮迭代逼近目标。

1
2
3
4
第一轮：生成基础实现
第二轮：指出问题，要求修改
第三轮：性能优化
第四轮：边缘情况处理

技巧 5：技术选型 Prompt 模板

在新项目启动或技术方案决策时，使用结构化的模板能让 AI 给出更全面的分析：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
# 技术选型 Prompt 模板
> 用途：在新项目或新功能启动时，做技术方案选型
> 适用工具：ChatGPT / Claude / Cursor

## 模板

我正在做一个技术选型，请帮我分析候选方案。

【项目背景】
- 项目类型：[描述]
- 团队规模：[人数]
- 团队技术背景：[成员熟悉的技术栈]
- 项目周期：[时长]

【需求描述】
{需要做选型的具体需求}

【候选方案】
{列出已知候选方案，没有的话让 AI 生成}

请对每个候选方案进行以下分析：

## 1. 方案简介
一句话描述这个方案是什么。

## 2. 核心能力
- 解决了什么问题
- 不解决什么问题

## 3. 对比评分

| 维度 | 方案A | 方案B | 方案C |
|------|-------|-------|-------|
| 学习成本 | 评分+说明 | ... | ... |
| 开发效率 | 评分+说明 | ... | ... |
| 运行性能 | 评分+说明 | ... | ... |
| 生态成熟度 | 评分+说明 | ... | ... |
| 维护成本 | 评分+说明 | ... | ... |
| 可扩展性 | 评分+说明 | ... | ... |

（评分：1-5 分，附简要理由）

## 4. 适用场景
每个方案最适合什么场景、不适合什么场景。

## 5. 推荐方案及理由
- 推荐哪个方案
- 为什么（结合项目背景）
- 如果采用这个方案，建议的落地步骤
- 潜在风险及应对策略

## 使用注意事项

1. **先定义评估维度**：不同项目侧重点不同，调整评分维度的权重
2. **AI 有流行度偏差**：它可能推荐最流行而非最适合的方案，自己判断
3. **数据要自己验证**：AI 说的"性能数据"可能是编的，实测为准
4. **最终决策自己做**：AI 提供决策依据，决策责任在你

4.8 Prompt 质量的自我检查清单

1
2
3
4
5
6
7
8
9
10
每次发送 Prompt 前，问自己：

□ 角色定义清楚了吗？（你是一个...）
□ 技术栈和项目背景说明了没有？
□ 要做什么具体说清楚了？（不是"写个功能"，而是"实现...的需求"）
□ 输出格式指定了吗？（代码/文档/JSON/列表）
□ 约束条件写全了吗？（不能做什么？要参考什么？）
□ 参考文件用 @ 引用了吗？
□ 需要避免的坑写了吗？
□ 上下文会不会太多或太少？