Prompt 工程：与 AI 高效沟通的核心技巧
**同样的 AI，不同的 Prompt，产出天差地别。**Prompt 工程是把模糊意图翻译成 AI 可精确执行指令的能力。
经验数据：一次生成可用率 30%→80%，无效对话占 Token 消耗的 40-60%。
Prompt 的四个层级
Level 1：「帮我写个用户列表」 ← 模糊、无约束
Level 2：「用 React + TypeScript 写用户列表」 ← 有技术约束
Level 3：「参考 agents.md 写用户列表，支持分页搜索」 ← 有上下文、有功能
Level 4：「在 features/user/ 下新建 UserList，参照 ← 完整上下文 + 约束 + 验收
OrderList 的结构，Props: {onEdit, onDelete}，
useQuery 取数，覆盖 loading/empty/error/空搜索 四态，
搜索防抖 300ms，分页每页 20 条」从 Level 1 到 Level 4，你只多花了 30 秒，但省掉了 10 分钟返工。
好 Prompt 的六个要素
| 要素 | 作用 | 示例 |
|---|---|---|
| 角色设定 | 告诉 AI "你是谁" | "你是一个资深 React 前端工程师" |
| 任务目标 | 明确要做什么 | "在 features/user/ 下新建 UserList" |
| 技术约束 | 限定技术选型 | "React 18 + TypeScript 严格模式" |
| 上下文引用 | 提供参考 | "参考 @agents.md 和 @OrderList" |
| 验收标准 | 明确完成标准 | "必须覆盖 loading/empty/error 三态" |
| 负面约束 | 明确不要做什么 | "不要 any，不要修改 package.json" |
五段式：Prompt 写作的标准范式
把六个要素收敛为五段，每段职责清晰：
┌──────────────────────────────────────────┐
│ 第一段：角色 你是谁、懂什么 │
├──────────────────────────────────────────┤
│ 第二段：背景 项目是什么、当前阶段 │
├──────────────────────────────────────────┤
│ 第三段：任务 要做什么、产出什么 │
├──────────────────────────────────────────┤
│ 第四段：要求 约束、验收、禁止项 │
├──────────────────────────────────────────┤
│ 第五段：输出格式 代码还是方案、结构如何 │
└──────────────────────────────────────────┘标准模板
markdown
## 角色
你是一个 [技术栈] 工程师，熟悉本项目的 agents.md 规范。
## 背景
- 项目：[项目名 + 一句话定位]
- 当前阶段：[初始开发 / 功能迭代 / Bug 修复 / 重构]
- 关键上下文：[已有类型、参考实现、相关模块]
## 任务
[用 1-2 句话说清楚要做什么]
## 要求
- 技术约束：[框架、库、TS 严格模式]
- 功能要求：[1-3 条具体功能]
- 验收标准：[怎么判断合格]
- 禁止事项：[3-5 条绝对不要做的]
## 输出格式
1. [先给方案/分析，再给代码]
2. [文件路径 + 代码]
3. [简要说明 / 修改清单]五段如何在系统层和用户层分配
五段不是每次都让用户手写完整。稳定部分放系统提示词，变化部分留给用户输入：
| 段落 | 建议位置 | 理由 |
|---|---|---|
| 第一段：角色 | ✅ 系统提示词 | 角色在会话中通常稳定 |
| 第二段：背景 | ⚠️ 部分系统 + 部分用户 | 项目信息放系统；当次上下文由用户输入 |
| 第三段：任务 | 👤 用户输入 | 每次任务不同 |
| 第四段：要求 | 👤 用户为主 | 通用约束放系统；任务级约束、验收由用户输入 |
| 第五段：输出格式 | ✅ 系统提示词 | 输出习惯相对固定 |
核心原则：稳定 → 系统层，变化 → 用户层。
实战示例：新建用户列表组件
markdown
## 角色（系统层固定）
你是一个资深 React 前端工程师，擅长 Ant Design 5 + Zustand + TanStack Query。
## 背景（系统层注入项目，用户层补充当次上下文）
- 项目：企业后台管理系统
- 关键上下文：参考 src/features/order/OrderList 的实现风格
## 任务（用户输入）
在 src/features/user/components/ 下新建 UserList 组件。
## 要求（通用约束在系统层，本次要求在用户层）
- 功能：分页（20 条/页）、搜索（按名称防抖 300ms）、排序（按创建时间）
- 验收：覆盖 loading / empty / error / 空搜索结果 四态
- 禁止：不要修改 package.json、不要写 class 组件、不要硬编码样式
## 输出格式（系统层固定）
1. 先说明组件 Props 设计和状态管理方案
2. 给出完整代码（文件路径 + 代码块）
3. 附上用法示例进阶做法：把上述结构注册为 Slash Command（/new-component），用户只需 /new-component UserList 即可触发。
单角色 vs 多角色：如何配置
场景 A：单角色（推荐起步）
┌─────────────────────────────────┐
│ 系统提示词（单角色） │
│ 角色：资深 React 前端工程师 │
│ 约束：agents.md 全部规范 │
│ 输出：先方案后代码 + 修改清单 │
└─────────────────────────────────┘
▼
用户输入：具体任务 + 当次要求适用：中小型项目、单一技术栈。
场景 B：多角色（按任务类型拆分）
┌─────────────────────────┐
│ 角色路由层（系统提示词） │
└────────────┬────────────┘
┌────────┬────────┼────────┬────────┐
▼ ▼ ▼ ▼ ▼
前端 后端 调试 审查 架构
工程师 工程师 专家 专家 师路由规则示例：
markdown
# .cursor/rules/general.md
你是一个 AI Coding 助手，根据用户任务自动选择角色：
## 角色库
1. 前端工程师：组件、页面、样式、前端状态
2. 后端工程师：API、数据库、业务逻辑
3. 调试专家：Bug 定位、性能优化、异常分析
4. 代码审查者：Code Review、规范检查、安全审计
5. 架构师：模块设计、技术选型、架构重构
## 路由规则
- 提到 "组件 / 页面 / 样式 / Hook" → 前端工程师
- 提到 "接口 / API / 数据库 / 缓存" → 后端工程师
- 提到 "报错 / 异常 / 性能慢 / 排查" → 调试专家
- 提到 "审查 / Review / 检查代码" → 代码审查者
- 提到 "架构 / 重构 / 模块化 / 选型" → 架构师场景 C：多 Agent 协作（高级）
编排 Agent（主控）
│
┌──────────┼──────────┐
▼ ▼ ▼
需求分析 架构设计 编码 测试
Agent Agent Agent Agent详见：多 Agent 角色协同
三种模式对比
| 维度 | 单角色 | 多角色 | 多 Agent 协作 |
|---|---|---|---|
| 复杂度 | 低 | 中 | 高 |
| 配置成本 | 1 份 | 路由 + N 份 | 编排器 + N 个 Agent |
| 适用规模 | 小型 / 中型 | 中型 / 大型 | 大型 / 复杂 |
| Token 消耗 | 低 | 中 | 高 |
| 推荐起点 | ✅ | 按需 | 复杂场景再上 |
演进路径：单角色起步 → 出现"一个角色干不好"再拆多角色 → 任务需要分工协作再上多 Agent。
六大核心技巧
1. 角色设定 —— 给 AI 一个"身份"
markdown
差：「写一个登录表单」
好：「你是一个资深 React 前端工程师，擅长表单处理和用户体验。」为什么有效：角色设定激活了模型训练数据中的"专家知识分布"。
常用角色：资深前端工程师 / 严格代码审查者 / 调试专家 / TDD 布道者 / 架构师 / 重构专家。
2. 分步执行 —— 复杂任务拆成小步
markdown
差：一次性丢整套模块
「帮我做一个完整的用户管理模块，包括列表、新增、编辑、删除、权限、批量、导入导出」
好：分步执行
Step 1：定义 User 类型和 API service
Step 2：写 UserList 列表组件（分页+搜索+排序）
Step 3：写 UserForm 表单组件
Step 4：实现删除功能（确认弹窗 + 乐观更新）好处：每步易验证、Token 可控、方向可调。这与 Plan Coding 模式 一脉相承。
3. 示例驱动 —— 给 AI 看"正确答案"
markdown
差：「写一个数据表格，支持排序筛选分页」
好：「参考以下 OrderTable 写 UserTable：
[粘贴完整示例代码]」三种示例方式：
| 方式 | 适用场景 |
|---|---|
| 零示例（Zero-shot） | 通用任务，AI 有明确范式 |
| 单示例（One-shot） | 有参考实现，仿照风格 |
| 多示例（Few-shot） | 需要展示多种边界情况 |
4. 思维链 —— 让 AI"先想再做"
markdown
差：「这个函数性能有问题，帮我优化」
好：「请：
1. 先分析性能瓶颈在哪里
2. 给出 2-3 种优化方案及取舍
3. 我确认方案后，再写优化代码」
[粘贴函数代码]效果：避免"看起来对但方向错"。与 Plan Coding 的"先方案后实施"理念一致。
5. 负面约束 —— 明确告诉 AI"不要做什么"
markdown
无效：「代码不要太复杂」
有效：「禁止事项：
- 不要使用 any（必要时用 unknown）
- 不要在组件内直接写 fetch（统一走 services/）
- 不要修改 package.json 依赖版本
- 不要使用 class 组件
- 不要硬编码颜色值」技巧：把最关键的 3-5 条禁止事项放在 Prompt 的开头或单独标出。
6. 迭代优化 —— 把 AI 输出当"初稿"
第 1 轮：写基础组件
↓
第 2 轮：加分页搜索
↓
第 3 轮：loading 用 Skeleton，empty 加引导
↓
第 4 轮：搜索防抖 300ms，columns 抽到独立文件要点：一次只改一个维度；每轮先确认上一步；不满意回退；迭代 3-5 轮最佳。
常见反模式
| 反模式 | 问题 | 原则 |
|---|---|---|
| Prompt 过短 | AI 不知技术栈、UI 库 | 至少说清角色、约束、验收 |
| Prompt 过长 | 关键信息被埋没 | 控制在 200-500 字，复杂任务拆多步 |
| 无上下文引用 | 用错 UI 库、校验逻辑 | 引用 @agents.md 或参考实现 |
| 问题描述模糊 | AI 猜错方向 | 描述问题 = 现象 + 位置 + 复现步骤 |
| 一次性要太多 | 每块都做但都不精 | 拆分任务，分批执行 |
速查：AI Coding 高频场景
| 场景 | Prompt 关键要素 |
|---|---|
| 新建组件 | 路径 + 参考实现 + 三态 + 命名约定 |
| 修复 Bug | 现象 + 位置 + 复现步骤 + 期望 vs 实际 |
| 代码重构 | 目标 + 原因 + 不变约束 + 期望方案 |
| 写测试 | 框架 + 必须覆盖场景 + 不引入新依赖 |
| Code Review | 审查要点清单 + 粘贴代码 |
模板详情：Prompt 模板库
自检清单
写完 Prompt 后用 5 个问题自检：
- [ ] **清晰吗？**一个完全不认识你的人能看懂要做什么吗？
- [ ] **有约束吗？**技术栈、命名、文件路径都明确了吗？
- [ ] **有上下文吗？**引用了
@agents.md或参考实现吗？ - [ ] **有验收标准吗？**怎么判断 AI 的输出"合格"？
- [ ] **拆分了吗？**这个任务能不能拆成更小的子任务？
总结
Prompt 工程不是奇技淫巧，而是结构化地描述你的意图。
记住六个字：角色、任务、约束、上下文、验收、禁止。
把 Prompt 当代码一样对待——清晰的意图、严格的约束、明确的验收。投入每次 30 秒写好 Prompt，省掉的是数倍于此的返工。
下一节：Prompt 模板库 — 把高频任务固化为可复用模板。