高级提示工程：AI 辅助开发的艺术

令人沮丧的 AI 交互和高效的 AI 交互之间的区别，往往取决于你如何构建请求。本指南揭示了区分新手用户和高级用户的技巧。

有效提示的结构

每个优秀的提示都包含四个关键要素：

1. 上下文（Context）

提供相关的背景信息：

上下文：我正在构建一个使用 TypeScript 的 React 电商应用，
使用 Redux Toolkit 进行状态管理，Tailwind CSS 进行样式设计。
我们遵循 Airbnb 代码风格指南。

2. 意图（Intent）

清楚地说明你想要实现什么：

意图：我需要创建一个购物车组件，显示商品列表，
允许更新数量，并显示总价。

3. 约束（Constraints）

指定任何限制或要求：

约束：
- 必须符合无障碍标准（WCAG 2.1 AA）
- 需要处理空购物车状态
- 需要与现有的 CartItem 类型配合使用
- 性能：不应在无关状态变化时重新渲染

4. 格式（Format）

描述期望的输出：

格式：请提供：
1. 组件文件（ShoppingCart.tsx）
2. 如需要，相关样式
3. 使用 React Testing Library 的单元测试
4. 关键设计决策的简要说明

CRISP 框架

对于复杂请求，使用 CRISP 框架：

字母	含义	示例
C	上下文	"在我们的 Node.js 微服务架构中..."
R	角色	"作为一名资深后端工程师..."
I	意图	"我需要实现限流..."
S	细节	"使用 Redis，每用户每分钟 100 请求..."
P	参数	"返回带测试的中间件函数..."

CRISP 实战

[上下文] 我们有一个 Node.js Express API，每分钟处理 10k 请求。
目前没有限流机制。

[角色] 作为一名专注于安全和性能的资深后端工程师，

[意图] 实现一个限流解决方案：

[细节]
- 限制每个用户每分钟 100 个请求
- 使用 Redis 进行分布式状态存储
- 超限时返回 429 状态码和 Retry-After 头
- 允许 20 个请求的突发
- 排除健康检查端点

[参数]
请提供：
- 中间件实现
- Redis 连接设置
- 配置选项
- 集成测试
- 团队文档

常见任务的提示模式

模式 1：调试侦探

追踪 bug 时，提供结构化的调查请求：

Bug 报告：
- 预期：用户提交表单后应看到成功消息
- 实际：表单提交但页面一直显示加载中
- 复现：填写表单，点击提交，观察加载动画

环境：
- 浏览器：Chrome 120
- React 18.2，React Query 5.0
- 控制台无可见错误

已尝试：
- 检查网络标签：API 返回 200
- 验证 mutation 函数被调用
- 在 onSuccess 中添加 console.log（从未触发）

请帮我：
1. 识别可能的原因
2. 建议调试步骤
3. 为最可能的问题提出修复方案

模式 2：架构顾问

对于设计决策，将其构建为咨询：

架构决策请求：

当前状态：
- 单体 Django 应用，50k 行代码
- PostgreSQL 数据库
- 100 并发用户，每月增长 20%

提议的变更：
将用户认证提取为独立的微服务

问题：
1. 这种方法的权衡是什么？
2. 你推荐什么通信模式？
3. 我们应该如何处理迁移？
4. 有哪些潜在的陷阱？

请提供平衡的分析和具体建议。

模式 3：代码审查员

请求全面的代码审查：

请从以下方面审查这段代码：

1. **正确性**：逻辑错误、边界情况、错误处理
2. **性能**：时间/空间复杂度、不必要的操作
3. **安全性**：输入验证、注入风险、数据暴露
4. **可维护性**：命名、结构、文档
5. **最佳实践**：模式、惯用法、现代方法

待审查代码：
[粘贴代码]

按严重程度排序问题（严重/主要/次要/建议）

模式 4：测试生成器

生成全面的测试：

为以下函数生成测试：

```typescript
async function processOrder(order: Order): Promise<ProcessedOrder> {
  // ... 实现
}

要求：

• 使用 Jest 和 React Testing Library
• 覆盖正常路径和错误情况
• 包含边界情况（空订单、无效商品等）
• Mock 外部依赖（支付 API、库存服务）
• 目标 >90% 分支覆盖率
• 遵循 AAA 模式（Arrange, Act, Assert）

## 高级技巧

### 技巧 1：思维链

让 Claude 解释其推理过程：

在实现之前，请：

1. 分析需求
2. 考虑 2-3 种可能的方法
3. 解释每种方法的权衡
4. 推荐最佳方法并说明理由
5. 然后实现解决方案

### 技巧 2：迭代优化

逐步构建解决方案：

让我们分阶段构建：

阶段 1：创建基础数据结构 阶段 2：添加 CRUD 操作 阶段 3：实现验证 阶段 4：添加缓存层 阶段 5：编写测试

从阶段 1 开始，我确认后再继续。

### 技巧 3：约束放松

遇到困难时，尝试放松约束：

理想的解决方案应该处理所有边界情况，但让我们先从 一个更简单的版本开始：

• 只处理正常路径
• 假设输入有效
• 跳过优化

我们可以从那里迭代。

### 技巧 4：示例驱动开发

提供期望行为的示例：

我需要一个格式化货币的函数。示例：

输入: 1234.5, "USD" → 输出: "$1,234.50" 输入: 1234.5, "EUR" → 输出: "€1,234.50" 输入: 1234.5, "JPY" → 输出: "¥1,235" 输入: 1234.5, "CNY" → 输出: "¥1,234.50" 输入: -50, "USD" → 输出: "-$50.00" 输入: 0, "USD" → 输出: "$0.00"

适当处理边界情况。

## 应避免的反模式

### ❌ 模糊请求

差：「让它更好」 好：「通过添加特定错误类型、用户友好的消息和适当的日志记录 来改进错误处理」

### ❌ 信息轰炸

差：[粘贴 500 行代码]「修复这个」 好：「第 45-60 行的 fetchUsers 函数在 API 返回空数组时 抛出错误。这是相关代码...」

### ❌ 假设陷阱

差：「使用标准方法」 好：「使用带依赖注入的仓储模式， 遵循我们现有的 UserRepository 实现」

### ❌ 移动目标

差：「其实，还要加上 X... 和 Y... 还要改 Z...」 好：完全完成一个任务，然后为更改开始新的请求

## 衡量提示效果

跟踪这些指标来改进你的提示：

1. **首次成功率**：第一次响应满足需求的频率？
2. **迭代次数**：需要多少次来回交流？
3. **解决时间**：从第一个提示到可用代码的总时间
4. **代码质量**：生成的代码是否无需修改即可通过审查？

## 总结

有效的提示工程是一项随着练习而提高的技能。从 CRISP 框架开始，为你的任务类型使用适当的模式，并根据结果持续优化。

记住：目标不是写最长的提示——而是提供成功结果所需的恰当信息。

**下一步**：学习如何使用[自定义技能](/zh/articles/ccjk-skills-deep-dive)扩展 Claude Code 的能力。