提示工程秘籍：如何让Claude Code理解你的需求

核心观点：提示工程不是"咒语集合"，而是建立与Claude的有效沟通协议。掌握核心原则后，效率可以提升5-10倍。

关键词：提示工程、沟通技巧、Claude Code、工作流优化、清晰指令

---

导读

你将学到：

• 什么是提示工程以及为什么它对Claude Code至关重要
• LLM的工作原理导致的提示设计原则
• 提示的三层结构和最佳实践
• 如何使用测试驱动提示（指定输入输出）
• 常见提示模式和何时使用
• 避坑指南：最容易犯的10个错误
• 提示性能优化：成本与效果的平衡

适合人群：中级开发者，想要深化与Claude交互效果的使用者

阅读时间：25分钟 | 难度：中级 | 实用度：5/5

前置知识：

• 已阅读《Claude Code完全入门》和《CLAUDE.md秘密武器》
• 对提示概念有基本理解

---

问题场景

你发现了Claude Code的强大，开始在项目中使用。但效果却不稳定：

• 有时Claude生成的代码完美无缺，有时却南辕北辙
• 同样的需求，改变措辞后结果完全不同
• 你怀疑：是不是Claude本身不够稳定？

其实，问题通常不在Claude，而在于提示的质量。

经验数据表明：

生成结果质量 ∝ 提示质量 ^ 1.5

一份清晰的提示不仅能提升结果质量，还能：

• 减少迭代轮数：60-80%
• 降低Token消耗：30-50%
• 减少理解偏差：70-90%

为什么这很重要？

总成本 = 单次提示成本 + (迭代次数 × 单次迭代成本)

一份质量好的提示可以大幅减少迭代次数，从而降低总成本。

---

核心概念

什么是提示工程？

提示工程是设计和优化提示（prompt）以获得最佳LLM输出的学科。

关键理解：

1. LLM是概率模型 - 它不"理解"你的需求，而是根据统计模式生成最可能的下一个词
2. 提示是上下文 - 你的提示决定了它使用哪个"概率分布"来生成答案
3. 清晰的提示 = 更确定的分布 - 这导致更一致、更符合期望的输出

常见误解

误解	现实
更长的提示更好	冗长会分散注意力，简洁有力更好
提示需要很聪明	清晰和直接比聪明重要
一份提示适用所有任务	不同类型任务需要不同的提示结构
提示中的顺序无所谓	前面的内容影响权重更高
提示就是命令	提示是和Claude合作的协议

---

提示的三层结构

有效的提示遵循这个模式：

第一层：背景与角色

告诉Claude它应该如何"思考"。

作用：建立思维框架

错误的方式：

你：分析这个代码

正确的方式：

你：你是一位经验丰富的Python开发者，
    专门从事性能优化。请分析这段代码的性能问题。

为什么有区别？

第一种提示让Claude在"通用回答模式"中工作。
第二种提示让Claude进入"资深开发者模式"，导致更专业的分析。

示例应用：

对于代码审查：
"你是一位资深的代码审查员，
 关注安全性、性能和可维护性。"

对于系统设计：
"你是一位架构师，
 需要为大规模系统设计方案。"

对于bug修复：
"你是一位调试专家，
 擅长快速定位根本原因。"

第二层：具体任务

清晰描述你想让Claude做什么。

作用：定义目标

结构：任务 + 背景 + 约束

错误的方式：

你：给这个函数加个功能

正确的方式：

你：为这个产品查询函数添加缓存功能。

背景：
- 当前函数在没有过滤条件时对数据库的查询很重
- 同一查询经常在几秒内重复出现
- 缓存失效策略：5分钟或产品数据更新时

要求：
- 使用Redis缓存（已配置）
- 保持现有API兼容
- 添加日志记录缓存命中率

为什么有区别？

第一种是模糊的问题。
第二种提供了足够的上下文让Claude做出准确决策。

第三层：格式与约束

明确指定输出的形式和限制。

作用：控制输出质量

不同场景的格式指定：

对于代码任务：
"请生成一个完整的、可运行的Python函数。
 包括：类型提示、docstring、错误处理。"

对于分析任务：
"请用以下结构回答：
 1. 问题总结（一句话）
 2. 根本原因（2-3点）
 3. 解决方案（优先级排序）
 4. 实施成本（时间和复杂度）"

对于创意任务：
"请提供5个选项，每个不超过100字。
 强调的要点：创新性 > 可实施性 > 成本。"

为什么有区别？

没有格式要求，Claude会给你一个混乱的答案。
有明确格式要求，Claude会按照要求组织答案。

---

具体提示策略

策略1：测试驱动提示（TDP）

这是最强大的策略。不是描述期望，而是给出输入输出例子。

原理：LLM从示例中学习比从描述中更准确。

例子1：数据转换

错误方式：
你：将这个CSV转换为JSON

**正确的方式**：

你：将CSV转换为JSON。

输入示例：

name,age,city
Alice,28,NYC
Bob,35,LA

输出示例：

[
  {"name": "Alice", "age": 28, "city": "NYC"},
  {"name": "Bob", "age": 35, "city": "LA"}
]

现在转换：
[实际要转换的CSV]

**效果对比**：
- 不用示例：Claude可能猜测你想要什么格式，有50%的失败率
- 用示例：Claude理解准确，成功率99%

**例子2：代码生成**

```
你：生成一个验证函数。

期望行为示例：
- validate_email("user@example.com") → True
- validate_email("invalid-email") → False
- validate_email("") → False
- 支持国际域名

代码应该包括：
- 类型提示
- 详细的docstring
- 边界情况处理
```

### 策略2：分解策略

对于复杂任务，分解为多个简单的子任务。

**原理**：大任务容易出错，小任务更准确。

**错误的方式**：
```
你：构建一个完整的认证系统
```

**正确的方式**：
```
你：我需要建立一个认证系统。
    让我们分步进行。

第一步：创建User模型
- 字段：username, email, password_hash, created_at
- 约束：username和email唯一
- 请实现并包括验证

[完成后Claude实现]

第二步：实现注册端点
- 验证邮箱格式和用户名长度
- 密码加密（使用bcrypt）
- 返回JWT token
- 请实现...

[继续...]
```

**效果**：
- 大任务一次性：失败率高，质量不稳定
- 分解为小任务：每步都可验证，质量稳定

### 策略3：链式思维提示（CoT）

让Claude展示"思考过程"而不仅仅是答案。

**原理**：中间步骤的明确表达导致更准确的最终答案。

**应用于代码审查**：

```
你：审查这段代码。

请按以下步骤进行：

步骤1：理解代码的目的
- 这段代码做什么？
- 处理哪些输入？

步骤2：分析潜在问题
- 有没有性能问题？
- 有没有边界情况未处理？
- 有没有安全漏洞？

步骤3：提出改进
- 优先级最高的改进
- 代码示例

[实际代码]
```

**为什么有效**：

Claude在展示思考过程时，会：
- 更仔细地分析
- 更完整地考虑各个方面
- 更准确地得出结论

### 策略4：限制上下文

告诉Claude关于其不应该做什么的约束。

**示例**：

```
你：为这个函数添加功能。

限制条件：
- 不要改变现有API（保证向后兼容）
- 不要添加新的依赖库
- 不要使用全局变量
- 性能退化不能超过5%

[现有函数和要求]
```

**效果**：

这防止Claude自由发挥却超出范围。

---

## 常见提示模式

### 模式1：提示问题陈述

适用于：需要Claude理解问题本质的任务

```
你：

问题陈述：
我们的API响应时间在过去一周增加了30%，
但没有流量增加。这很奇怪。

已尝试：
- 检查数据库查询（看起来正常）
- 检查服务器资源（CPU和内存正常）

现在需要：
一步步诊断这个问题。

[相关的日志和代码]
```

### 模式2：给定几个示例

适用于：需要建立一致的"风格"

```
你：

我想要你按照这种风格生成文档：

示例1：
"""
function_name: 做什么
用法: 如何使用
返回: 返回什么
"""

示例2：
[更多示例...]

现在为这个函数生成文档：[函数]
```

### 模式3：角色扮演

适用于：需要特定观点的分析

```
你：

假设你是这个项目的技术负责人。
你需要在下周的技术评审中介绍这个设计。

准备你的介绍，包括：
- 为什么这是最好的方案
- 有什么权衡
- 潜在的风险

[设计文档]
```

### 模式4：提供参考实现

适用于：需要特定质量水平的代码

```
你：

这是参考实现（高质量代码的标准）：

````python
def reference_function(items: list[int]) -> dict[str, int]:
    """统计项目频率。

    Args:
        items: 整数列表

    Returns:
        {item: count}的字典

    Raises:
        ValueError: 如果items为空
    """
    if not items:
        raise ValueError("items不能为空")

    return {
        item: items.count(item)
        for item in set(items)
    }

现在按照这个风格实现一个类似的函数：[需求]

---

## Token优化与成本控制

### 理解Token

Claude按token计费（约4个字符 = 1个token）。

**成本 = (输入token数 × P_in) + (输出token数 × P_out) + (思考token数 × P_thinking)**

（基于Claude 3.7/4.0系列定价，2026年1月参考。注：随着模型效率提升，单位成本正逐年下降）

### 优化策略

**策略1：模型路由 (Model Routing)**

在2026年，我们不再用单一模型完成所有任务。
- **Claude Haiku 3.5/4.0**：用于简单代码生成、注释、单元测试（速度快，成本低）
- **Claude Sonnet 3.7**：用于日常开发、重构（平衡之选）
- **Claude Opus 3.5/4.0**：用于复杂架构设计、疑难Bug排查（最强推理）

通过在提示中指定或配置默认模型，可节省 60% 成本。

**策略2：精准提示减少迭代**

| 提示质量 | 迭代次数 | 平均Token/轮 | 总Token | 成本 |
|---------|---------|-----------|---------|------|
| 差 | 5 | 2000 | 10,000 | $0.15 |
| 一般 | 3 | 2000 | 6,000 | $0.09 |
| 好 | 1 | 2000 | 2,000 | $0.03 |

**策略2：移除冗余信息**

冗长（浪费token）：
“我有一个问题。这是一个Python函数。
我想要改进它。函数如下…”

精简（节省token）：
“改进这个Python函数：
[函数代码]”

节省：50-70%的token

**策略3：使用CLAUDE.md代替重复上下文**

一次投入（200 token）：写好CLAUDE.md
多次收益：每次对话自动使用，节省100+ token

---

## 避坑指南：最常见的10个错误

### 错误1：期望不明确

错误：
你：修复这个bug

正确：
你：这个bug的症状是什么时候它应该返回用户列表
时，实际上返回空。

期望行为：
GET /api/users?role=admin → 返回所有admin用户

实际行为：
GET /api/users?role=admin → 返回[]

已验证：

• 数据库中有admin用户
• 没有权限问题

调查重点：

• 查询过滤逻辑
• 缓存是否干扰

### 错误2：过度重复

错误：
你：我需要一个函数。这个函数很重要…
它需要做…，而且必须做…
这是一个关键功能…

正确：
你：实现一个函数用于检查支付状态。

要求：

• 查询支付表
• 返回状态码
• 处理不存在的支付ID

### 错误3：混合多个请求

错误：
你：1) 修复这个bug
2) 添加这个功能
3) 优化这个算法

正确：
（分开三次对话）

你：修复这个bug…
[完成]

你：现在添加这个功能…
[完成]

你：最后优化这个算法…

### 错误4：没有上下文

错误：
你：写一个API端点

正确：
你：写一个GET端点用于检索用户。

上下文：

• 项目使用Django REST Framework
• 已有User模型和UserSerializer
• 需要JWT认证
• 返回格式在CLAUDE.md中定义

要求：

• 只允许用户获取自己的信息
• 返回除密码外的所有字段

### 错误5：要求不现实

错误：
你：在5分钟内写一个完整的电商系统

正确：
你：首先，我们分阶段构建。

第一步：用户认证模块
[具体要求…]

（完成后）

第二步：商品管理模块
[具体要求…]

### 错误6：忽略CLAUDE.md

错误：
你：生成一个API端点
（但没有在CLAUDE.md中定义API返回格式）

正确：
你：生成一个API端点

参考CLAUDE.md中的：

• API返回格式标准
• 错误处理约定
• 认证方式
• 命名约定

### 错误7：提示中有矛盾

错误：
你：生成简洁的代码，但要详尽的文档和所有边界情况

正确：
你：生成代码，优先级：
1. 功能正确性
2. 可读性
3. 代码简洁性

### 错误8：没有验收标准

错误：
你：优化这个函数

正确：
你：优化这个函数。

验收标准：

• 性能提升至少20%
• API保持不变
• 测试全部通过

### 错误9：过于依赖Claude

错误：
你：这段代码应该怎么写？
这个架构应该怎么设计？
这个问题应该怎么解决？

正确：
（先自己思考，形成初步看法）

你：我考虑用[方案A]来解决这个问题。
但我也考虑过[方案B]。

你觉得哪个更好？为什么？

### 错误10：不验证输出

错误：
你：生成这个功能
[Claude生成]
→ 直接使用

正确：
你：生成这个功能
[Claude生成]
→ 审查代码
→ 运行测试
→ 验证功能
→ 使用

---

## 高级技巧

### 技巧1：迭代式提示

不是一次性描述所有需求，而是逐步细化。

第一轮：
你：生成一个用户验证函数

[Claude生成]

第二轮：
你：很好，现在添加速率限制（每分钟5次尝试）

[Claude修改]

第三轮：
你：添加日志记录失败尝试

[Claude再次修改]

**优点**：每轮都可以验证，质量更好

### 技巧2：要求解释

让Claude解释它的决策，这通常能发现问题。

你：实现这个功能。

在代码中添加注释解释：

• 为什么选择这个数据结构
• 时间复杂度是多少
• 有什么权衡

### 技巧3：负面示例

告诉Claude什么是不好的。

你：生成一个验证函数。

不好的例子（不要这样做）：

# 不好：没有处理异常
def validate(x):
    return x > 0

# 不好：没有类型提示
def check(items):
    return len(items) > 0

好的做法：

• 包括类型提示
• 处理边界情况
• 有文档字符串

### 技巧4：Persona强化

使用具体的人物角色。

```
你：

你是一位有10年经验的系统架构师。
你曾经设计过处理每秒100万请求的系统。
你关注可扩展性、可维护性和成本。

现在设计这个功能的架构...
```

---

## 测试你的提示

### 方法1：一致性测试

同一个提示运行多次，看结果是否一致。

```
运行5次相同提示，对比结果：
- 结果相似度 > 80% → 提示质量好
- 结果相似度 < 60% → 提示不够清晰
```

### 方法2：修改测试

在提示中做小改动，看输出变化。

```
原提示生成的代码：100行

改动1：改变关键词顺序
→ 生成代码：120行（质量有微妙差异）

改动2：添加示例
→ 生成代码：95行，更符合期望
```

### 方法3：对比测试

用不同的提示格式，对比结果。

```
提示A（描述性）：
"生成一个排序函数"

提示B（示例性）：
"生成一个排序函数

输入：[3, 1, 4, 1, 5]
输出：[1, 1, 3, 4, 5]
..."

对比：提示B的成功率 > 提示A
```

---

## 总结与要点

### 提示工程核心原则

| 原则 | 说明 | 例子 |
|------|------|------|
| **清晰第一** | 准确>聪明 | 说清楚 vs 绞尽脑汁 |
| **示例优先** | 给示例 > 长描述 | 一个例子 > 100字说明 |
| **结构化** | 分段 > 一整段 | 有标题分段 vs 混成一块 |
| **递进式** | 逐步细化 > 一次完成 | 多轮对话 vs 一次性说完 |
| **验证** | 总是验证 > 直接用 | 检查+测试 vs 盲目相信 |

### 提示工程效果倍数

好的提示能带来的改进：

```
迭代次数减少：60-80%
Token消耗减少：30-50%
结果质量提升：50-100%
开发时间减少：50-70%
```

### 一句话总结

提示工程不是"说魔法词"，而是用结构化、明确的语言与Claude建立有效的沟通协议。

### 下一步行动

1. **立即**：回顾你之前写的提示，用本文的原则改进一个
2. **这周**：在项目中尝试"测试驱动提示"（TDP）
3. **持续**：建立个人的"提示库"，记录什么有效

---

## 推荐阅读

### 本系列相关文章
- 上一篇：CLAUDE.md - 秘密武器
- 下一篇：Git工作流规范
- 后续：高级Hooks和Subagents

### 官方资源
- Prompt Engineering Guide: https://promptingguide.ai
- Anthropic博客 - 提示最佳实践: https://www.anthropic.com/blog

### 社区资源
- GitHub: awesome-claude-prompts
- 提示库：https://github.com/f/awesome-chatgpt-prompts

---

## 常见问题

**Q: 我应该在每个提示中复述CLAUDE.md吗？**
A: 不需要。Claude会自动读取CLAUDE.md。你只需在提示中补充CLAUDE.md没有的上下文。

**Q: 怎样知道我的提示何时太长？**
A: 如果超过500字，通常说明要么信息冗余要么分解得不够。尝试简化或分解。

**Q: 同一个提示为什么有时有效有时无效？**
A: LLM本身有随机性。如果结果变化太大，说明提示不够具体。添加更多约束。

**Q: 提示中可以包括代码片段吗？**
A: 可以，而且建议包括。代码的清晰性往往高于文字描述。

**Q: 我应该多久评估和改进我的提示？**
A: 每周审查一次。收集不好的结果，分析原因，改进提示。

---

## 最后的话

提示工程的本质是**理解和沟通**。

理解Claude是一个概率模型，而不是能理解自然语言的智能体。
理解你的目标，能用结构化的方式表达。
理解这两者之间的对齐，就是好的提示。

每一个好提示都是一个**投资**——多花5分钟写清楚，就能节省20分钟的迭代。

---

感谢阅读！下一篇将讲解规范化的Git工作流，这是团队协作和代码安全的基石——敬请期待！