<!-- title: Claude Code Prompt设计模式六大形态实战 -->
# Claude Code Prompt设计模式深度实战：六大形态与反模式修复

## 概述

Claude Code的强大不在于模型本身，而在于你如何向它下达指令。同样的需求，一条模糊的Prompt可能产出90%正确但无法使用的代码，而一条结构精准的Prompt则能在第一轮就交付可部署的结果。本教程基于2026年最新的Prompt工程研究成果，系统拆解Claude Code的六种核心Prompt形态——生成、重构、调试、解释、编排、审查——以及对应的反模式诊断与修复方法。适合已有Claude Code基础使用经验、希望从"能用"跃升到"精准驱动"的开发者。

**前置条件**：已安装Claude Code CLI（v2.1+），了解基本命令操作，有一个真实项目可作为练习场。

---

## 一、为什么Prompt形态决定Claude Code的产出质量

Claude Code不是传统的代码补全工具，而是一个自主代理（Agent）。它接收指令后，会自主选择工具（读取文件、搜索代码、执行命令、编辑代码），循环工作直到满足停止条件。这意味着Prompt的质量直接决定了：

1. **代理的搜索空间**：模糊指令导致代理在庞大的可能性空间中盲目探索
2. **停止信号**：没有明确的验收标准，代理要么过早停止，要么陷入无限循环
3. **上下文利用率**：结构良好的指令让代理精准定位所需文件，而非浪费Token扫描整个代码库

Kevin Kinnett在2026年5月的研究中提出，Claude Code的有效交互可以被归类为**六种Prompt形态**，每种形态有其最优结构。掌握这六种形态，就等于掌握了驱动Claude Code的核心语法。

```mermaid
graph TB
    subgraph "Claude Code 六大 Prompt 形态"
        A[生成 Generate] --> A1["写出执行X的新代码"]
        B[重构 Refactor] --> B1["修改Y的行为，保持Z不变"]
        C[调试 Debug] --> C1["找到X失败的原因"]
        D[解释 Explain] --> D1["描述代码Y做了什么"]
        E[编排 Orchestrate] --> E1["规划并执行多步骤任务"]
        F[审查 Review] --> F1["审计指定关注点"]
    end

    subgraph "通用原则"
        G[明确的验收标准]
        H[文件指针与上下文]
        I[约束条件与边界]
    end

    A & B & C & D & E & F --> G & H & I
```

---

## 二、形态一：生成（Generate）——写出执行X的新代码

### 2.1 核心原理

生成形态是最常见的Prompt类型：你描述期望的行为，Claude Code产出新代码。这类Prompt的最佳结构包含**四个要素**：目标位置、输入输出形状、技术约束、至少一个可验证的验收标准。

### 2.2 弱Prompt vs 强Prompt对比

**弱Prompt**：
```bash
claude "写一个重试函数"
```

这条指令缺少：使用什么语言？放在哪个文件？重试什么类型的操作？最大重试次数？退避策略？

**强Prompt**：
```bash
claude "在 @src/utils/retry.ts 中创建一个通用重试函数 retry<T>，要求：
- 泛型支持，返回 Promise<T>
- 参数：执行函数 fn: () => Promise<T>，最大重试次数 maxRetries: number（默认3），初始延迟 baseDelay: number（默认1000ms）
- 指数退避策略：每次重试延迟翻倍
- 只在网络错误（ERR_NETWORK）和超时（ETIMEDOUT）时重试
- 最后一次重试失败后抛出 AggregateError，包含所有错误
- 验收标准：运行 npx jest src/utils/retry.test.ts 全部通过"
```

### 2.3 生成形态的结构模板

```
[目标] 在 <文件路径> 中创建 <组件/函数/模块>
[输入输出] 接收 <参数描述>，返回 <返回值描述>
[约束条件]
  - <约束1>
  - <约束2>
[验收标准] 运行 <命令> 全部通过
```

### 2.4 常见陷阱：没有验收标准的生成

没有验收标准的生成Prompt是Token浪费的第一大来源。Claude Code在生成代码后会尝试自我验证——但如果你的Prompt中没有明确的验证方式，它可能：
- 生成看起来正确但有隐藏Bug的代码
- 跳过边界情况处理
- 使用与你项目不一致的模式

**修复方法**：始终在Prompt末尾添加验收标准，最好是可以自动化运行的命令：
```bash
# 好的验收标准
"验收标准：npm test -- --grep 'UserService' 全部通过，且 ESLint 零错误"
```

---

## 三、形态二：重构（Refactor）——修改Y的行为，保持Z不变

### 3.1 核心原理

重构形态是最容易出现反效果的Prompt类型。问题在于：重构必须在"改变行为"和"保持不变的部分"之间取得精确平衡。如果你只说了"重构X"，Claude Code无法判断哪些行为是必须保留的。

### 3.2 重构Prompt的四层结构

```bash
claude "重构 @src/services/payment.ts 中的 processPayment 函数：

[变更目标]
  - 将单体函数（180行）拆分为4个独立函数：validateOrder, calculateTotal, chargeCustomer, sendConfirmation
  - 主函数 processPayment 编排这4个子函数

[保持不变]
  - 公共API签名：processPayment(order: Order): Promise<PaymentResult> 不变
  - 错误处理策略：所有错误必须通过 PaymentError 包装后抛出
  - 日志格式：保持 @CLAUDE.md 中定义的结构化日志格式

[参考模式]
  - 参照 @src/services/shipping.ts 中 shipOrder 的拆分模式

[验收标准]
  - 所有现有测试通过：npx jest tests/payment.test.ts
  - 新函数各有独立的单元测试
  - processPayment 的集成测试行为不变"
```

### 3.3 反模式："让代码更干净"

```bash
# 危险！这是最常见的反模式
claude "重构 payment.ts 让它更干净"
```

"更干净"是一个主观判断，Claude Code无法将其转化为具体的操作。可能的后果：
- 重命名所有变量（你原有命名是有业务含义的）
- 抽取不必要的抽象层
- 改变错误处理行为
- 移除看似"冗余"实则是防御性编程的代码

**修复方法**：将"更干净"翻译为具体可操作的指令：
```
"更干净" → "提取超过30行的函数为独立命名函数，添加TypeDoc注释"
"优化性能" → "将N+1查询替换为JOIN查询，目标响应时间<200ms"
"模块化" → "拆分为独立文件，每个文件单一职责，导出明确的公共API"
```

### 3.4 重构的安全网：测试先行

在执行重构前，确保目标代码有足够的测试覆盖。如果没有，Prompt的第一步应该是：

```bash
claude "在执行重构前，先为 @src/services/payment.ts 的 processPayment 函数编写完整的单元测试。
覆盖以下场景：正常支付流程、余额不足、网络超时、并发支付。
使用 @tests/services/shipping.test.ts 作为测试模式参考。"
```

---

## 四、形态三：调试（Debug）——找到X失败的原因

### 4.1 核心原理

调试形态是最能体现Claude Code代理能力的场景。关键在于：**提供实际的失败输出**，而不是描述"有什么问题"。Claude Code需要看到错误消息、堆栈跟踪和测试输出，才能精准定位问题。

### 4.2 调试Prompt的最优结构

```bash
# 方法一：直接传入错误输出
claude "调试测试失败：

<test_output>
FAIL tests/integration/user-auth.test.ts
  ● User Auth › should refresh expired token

    AssertionError: expected undefined to equal 'new-access-token'
    
      at Object.<anonymous> (tests/integration/user-auth.test.ts:45:23)
    
    console.error:
      TokenRefreshError: Refresh token has expired at epoch 1716123456
      at TokenService.refresh (src/services/token.ts:78:13)
</test_output>

涉及文件：@src/services/token.ts @src/middleware/auth.ts @tests/integration/user-auth.test.ts
最近的变更：PR #567 修改了 token 过期逻辑
修复后要求：npm test 全部通过"
```

```bash
# 方法二：管道传入测试输出
npm test 2>&1 | claude "以下是测试输出，诊断失败原因并修复：
涉及文件：@src/services/token.ts @src/middleware/auth.ts
@CLAUDE.md 错误处理规范"
```

### 4.3 调试的反模式："测试挂了，帮我修"

```bash
# 太模糊
claude "测试挂了，帮我修"
```

Claude Code虽然可以运行测试命令来获取输出，但这会消耗额外的Token和时间。直接提供错误输出是最高效的做法。

**效率对比**：

| 方式 | Token消耗 | 响应时间 | 诊断准确率 |
|------|-----------|----------|------------|
| 提供完整错误输出 | ~2,000 | 快（1轮） | ~95% |
| 只说"测试挂了" | ~8,000 | 慢（3-5轮） | ~60% |
| 描述现象不贴输出 | ~5,000 | 中（2-3轮） | ~70% |

### 4.4 调试Prompt的进阶技巧

**技巧一：包含最近的变更历史**
```bash
claude "调试回归问题：

错误：[贴入错误输出]
这个测试在PR #567合并前是通过的。
PR #567的变更：修改了 token 过期检查从绝对时间改为滑动窗口。
涉及文件：@src/services/token.ts（修改行：72-85）"
```

**技巧二：限定调试范围**
```bash
claude "调试 @src/api/users.ts:postUser 的500错误。
只在 @src/api/users.ts 和 @src/services/user-service.ts 中查找原因。
不要修改数据库层代码。
错误日志：[贴入日志]"
```

---

## 五、形态四：解释（Explain）——描述代码Y做了什么

### 5.1 核心原理

解释形态看似简单，但大多数人的Prompt过于宽泛，导致Claude Code输出冗长但缺乏重点的泛泛之谈。关键是**指定你想要理解的具体维度**。

### 5.2 弱解释 vs 强解释

```bash
# 弱：太宽泛
claude "解释一下 @src/services/payment.ts"

# 强：指定维度
claude "解释 @src/services/payment.ts:processPayment 中的支付流程：

我需要理解：
1. 资金流转的时序（从用户点击支付到商户收到款项）
2. 与第三方支付网关的交互协议（请求/响应格式）
3. 失败回滚策略（哪些步骤有补偿事务）
4. 并发控制机制（如何防止重复扣款）

不需要：代码逐行解释、基础概念科普"
```

### 5.3 解释形态的实用场景

解释形态在以下场景中特别有价值：

**场景一：接手遗留代码**
```bash
claude "我刚接手 @src/legacy/batch-processor.js，这是2019年写的无文档代码。
帮我梳理：
1. 这个模块的对外接口和调用者（搜索整个项目中的引用）
2. 数据流向：输入从哪来，输出到哪去
3. 已知的TODO和FIXME注释
4. 外部依赖及其用途"
```

**场景二：理解架构决策**
```bash
claude "分析 @src/middleware/ 目录下所有中间件的执行顺序和依赖关系。
用表格展示：中间件名 | 职责 | 是否阻塞 | 依赖哪些其他中间件"
```

**场景三：生成文档**
```bash
claude "为 @src/api/routes/ 目录下的所有端点生成API文档。
格式：OpenAPI 3.0 YAML，包含请求/响应Schema。
@CLAUDE.md API文档规范"
```

---

## 六、形态五：编排（Orchestrate）——规划并执行多步骤任务

### 6.1 核心原理

编排形态是六种形态中最复杂的，也是最容易出问题的。当你需要Claude Code完成一个涉及多个步骤、多个文件的任务时，必须提供**步骤序列、依赖关系和验收标准**。这正是"原子任务设计"（Atomic Task Design）方法论的用武之地。

### 6.2 原子任务设计原则

原子任务设计的核心思想：**将大目标分解为最小的、可独立验证的任务单元**。每个原子任务满足：
- 有一个明确的输出
- 有一个二元（通过/失败）的验收标准
- 可以独立执行和验证

```mermaid
flowchart TD
    A["大目标：实现用户认证系统"] --> B["原子任务1：创建User数据模型"]
    B --> C["验收：npx jest models/user.test.ts 通过"]
    C --> D["原子任务2：实现注册API"]
    D --> E["验收：curl POST /api/auth/register 返回201"]
    E --> F["原子任务3：实现登录API + JWT签发"]
    F --> G["验收：curl POST /api/auth/login 返回token"]
    G --> H["原子任务4：实现认证中间件"]
    H --> I["验收：受保护端点无token返回401"]
    I --> J["原子任务5：集成测试"]
    J --> K["验收：npm test 全部通过"]

    style A fill:#e74c3c,color:#fff
    style C fill:#2ecc71,color:#fff
    style E fill:#2ecc71,color:#fff
    style G fill:#2ecc71,color:#fff
    style I fill:#2ecc71,color:#fff
    style K fill:#2ecc71,color:#fff
```

### 6.3 编排Prompt的完整示例

```bash
claude "实现用户认证模块，按以下步骤执行：

步骤1：创建数据模型
- 在 @src/models/user.ts 创建 User 模型
- 字段：email（唯一索引）、passwordHash、createdAt、lastLoginAt
- 使用 @src/models/base.ts 作为基类模板
验收：npx jest tests/models/user.test.ts 通过

步骤2：实现注册端点
- POST /api/auth/register
- 输入验证：email格式、密码最小8位
- 密码使用 bcrypt 哈希（参照 @CLAUDE.md 安全规范）
- 返回201 + userId，不返回passwordHash
验收：curl测试返回正确状态码

步骤3：实现登录端点
- POST /api/auth/login
- 返回JWT（过期时间24小时，参考 @src/config/auth.ts 的密钥配置）
- 错误：401 + 'Invalid credentials'（不暴露是邮箱还是密码错误）
验收：curl测试返回有效token

步骤4：认证中间件
- @src/middleware/authenticate.ts
- 从 Authorization header 提取 Bearer token
- 验证JWT并注入 req.user
验收：受保护端点正确拦截无token请求

步骤5：编写集成测试
- 测试完整注册→登录→访问受保护资源的流程
- 测试错误场景：重复注册、错误密码、过期token
验收：npm test -- tests/integration/auth/ 全部通过

约束：
- 不要修改已有的 @src/routes/index.ts 路由注册方式
- 错误处理遵循 @CLAUDE.md 中定义的错误响应格式
- 所有新文件添加到 @src/types/index.ts 的类型导出中"
```

### 6.4 编排的反模式："一锅端"式Prompt

```bash
# 最致命的反模式
claude "帮我实现一个完整的用户认证系统，包括注册、登录、JWT、中间件、测试，
用React和Node.js，PostgreSQL数据库，用最好的实践"
```

这种Prompt的典型失败模式：
1. **上下文溢出**：Claude Code尝试在单个上下文窗口中处理所有决策，导致关键细节被截断
2. **连锁失败**：一个步骤的错误会传播到所有后续步骤，因为代理无法回退
3. **不可验证**：没有中间检查点，最终产物是"看起来对但到处漏"的代码

**修复方法**：分阶段执行，每个阶段完成后验证：

```bash
# 阶段1
claude "执行步骤1：创建User数据模型。[详细描述]"
# 等验证通过后...

# 阶段2
claude "继续。执行步骤2：实现注册端点。[详细描述]"
# 依赖步骤1的产出...
```

---

## 七、形态六：审查（Review）——审计指定关注点

### 7.1 核心原理

审查形态与"解释"形态的关键区别在于：审查需要你**明确指定关注点**。说"审查这段代码"等于没说——你必须告诉Claude Code审查什么维度。

### 7.2 审查Prompt的维度矩阵

| 审查维度 | Prompt关键词 | 产出形式 |
|----------|-------------|----------|
| 安全 | OWASP Top 10、注入、认证绕过 | 漏洞列表 + 修复代码 |
| 性能 | N+1查询、内存泄漏、大循环 | 性能问题列表 + 优化方案 |
| 可维护性 | 圈复杂度、代码重复、函数长度 | 重构建议列表 |
| 一致性 | 与CLAUDE.md规范对比 | 偏差列表 |
| 类型安全 | TypeScript strict模式合规 | 类型错误列表 |

### 7.3 审查Prompt示例

```bash
# 安全审查
claude "对 @src/api/ 目录下所有端点执行安全审查：
- 检查所有用户输入是否经过验证和消毒
- 检查SQL注入可能性（特别是字符串拼接的查询）
- 检查是否有未认证的端点暴露了敏感数据
- 检查错误响应是否泄露了内部实现细节
参照 @CLAUDE.md 安全规范和 OWASP Top 10
输出格式：按严重程度排序（Critical > High > Medium > Low）"

# 性能审查
claude "审查 @src/services/ 目录的性能问题：
- 识别所有数据库查询，标记N+1查询
- 检查是否有不必要的数据获取（SELECT * 但只用了2个字段）
- 检查循环内的异步操作（应替换为批量操作或Promise.all）
- 检查是否有缺失的数据库索引（对比 @prisma/schema.prisma 的索引定义）
输出格式：每个问题包含文件名、行号、当前代码、建议修改"
```

### 7.4 审查的反模式："检查有没有问题"

```bash
# 无效的审查Prompt
claude "审查一下这个文件有没有什么问题 @src/api/users.ts"
```

Claude Code面对这种Prompt可能：
- 只检查语法问题（这ESLint就能做）
- 提出一堆风格建议（无关痛痒）
- 完全忽略真正的安全漏洞（因为你没说要检查安全）

**修复方法**：始终指定审查维度和参照标准：
```bash
# 有效的审查Prompt
claude "审查 @src/api/users.ts 的安全性，特别关注：
1. 所有 req.body / req.params 的输入验证
2. 用户ID是否有权限检查（横向越权）
3. 文件上传端点的大小和类型限制
参照 @CLAUDE.md 安全规范第3节"
```

---

## 八、跨形态通用技巧

### 8.1 XML标签结构化

Claude对XML标签有天然的解析优势——其训练数据中包含大量XML格式的结构化内容。在Prompt中使用XML标签可以显著提升指令的清晰度：

```bash
claude "<task>重构 @src/services/order.ts 的 OrderService 类</task>

<changes>
- 将 createOrder 方法拆分为 validateItems、calculatePricing、processPayment 三个私有方法
- 将状态机逻辑提取到独立的 OrderStateMachine 类
</changes>

<preserve>
- 公共方法签名不变
- 所有现有测试必须继续通过
- 订单号生成算法不变
</preserve>

<reference>@src/services/subscription.ts 的 SubscriptionService 作为重构模式参考</reference>

<acceptance>
- npx jest tests/order/ 全部通过
- OrderService.ts 总行数不超过 150 行
- 每个新方法有对应的单元测试
</acceptance>"
```

### 8.2 @文件引用精准定位

在Claude Code中使用 `@文件路径` 可以将特定文件注入到上下文中，避免代理浪费Token搜索文件：

```bash
# 好的做法：精准引用
claude "参照 @src/templates/email-templates.ts 中的模板格式，在 @src/services/notification.ts 
中添加新的邮件通知方法。@CLAUDE.md 通知服务规范"

# 不好的做法：让代理自己找
claude "参照项目中已有的邮件模板格式，在通知服务中添加新方法"
```

### 8.3 约束框定：告诉Claude Code什么不要做

否定约束（"不要做X"）和肯定约束同样重要。Claude Code的代理特性意味着它可能在执行过程中"创造性"地添加你不需要的东西：

```bash
claude "修复 @src/api/orders.ts 中的分页Bug。

约束：
- 只修改 getOrders 函数中的分页逻辑（第45-60行）
- 不要修改排序逻辑
- 不要修改API响应格式
- 不要添加新依赖
- 不要修改测试文件，只确保现有测试通过"
```

### 8.4 输出格式控制

当你需要特定格式的输出时，直接给出格式模板：

```bash
claude "分析 @src/ 目录的依赖关系图，输出以下格式：

\`\`\`
模块名 | 依赖模块 | 被依赖次数 | 耦合等级(高/中/低)
------------------------------------------------------
auth     | database, config | 5          | 高
payment  | auth, database, stripe | 3    | 中
\`\`\`

按被依赖次数降序排列。只显示跨模块依赖，不显示同模块内的导入。"
```

---

## 九、实战案例：用原子任务设计完成一个完整功能模块

下面用一个完整的实战案例演示如何将六大形态组合使用，实现一个"通知中心"功能模块。

### 步骤1：用解释形态理解现有架构

```bash
claude "分析 @src/ 目录的现有模块架构：
1. 列出所有 service 层模块及其职责
2. 识别现有的通知机制（邮件、SMS、推送）
3. 找到事件总线或消息队列的使用模式
4. 列出 @CLAUDE.md 中关于新模块的规范要求
输出格式：结构化表格"
```

### 步骤2：用编排形态规划任务序列

```bash
claude "基于上一步的分析，规划'通知中心'模块的实现步骤。

目标：创建统一的通知服务，支持邮件、SMS、站内推送三种渠道。

约束：
- 遵循 @CLAUDE.md 模块规范
- 参照 @src/services/email.ts 作为服务模板
- 使用 @src/events/ 的事件总线

输出格式：每个步骤包含名称、文件路径、依赖步骤、验收标准
不要开始编码，只输出计划"
```

### 步骤3：按计划逐步用生成形态实现

```bash
# 先实现核心模型和接口
claude "执行计划步骤1：创建通知类型定义和接口
[步骤1的详细描述和验收标准]"

# 验证通过后继续
claude "继续执行步骤2：实现 NotificationService 核心类
[步骤2的详细描述，引用步骤1的产出文件]"
```

### 步骤4：用审查形态安全检查

```bash
claude "对新建的所有通知模块文件执行安全审查：
- 检查通知内容模板是否有XSS注入风险
- 检查用户通知偏好设置是否有权限绕过
- 检查批量发送是否有速率限制
参照 @CLAUDE.md 安全规范
输出按严重程度排序"
```

### 步骤5：用调试形态修复审查发现的问题

```bash
claude "修复通知模块的安全问题：

问题1（Critical）：模板引擎直接注入用户输入
文件：@src/services/notification/template.ts:23
修复：使用模板参数化而非字符串拼接

问题2（High）：批量发送无速率限制
文件：@src/services/notification/sender.ts:45
修复：添加令牌桶限流器，参考 @src/utils/rate-limiter.ts

验收：npm test 全部通过 + 安全审查复查通过"
```

### 步骤6：用重构形态优化最终产出

```bash
claude "优化 @src/services/notification/ 目录的代码结构：

变更：
- NotificationService.ts 超过200行，拆分为 NotificationRouter、ChannelDispatcher、TemplateEngine
- 三个渠道适配器（email、sms、push）提取到 @src/services/notification/channels/ 目录

保持不变：
- 公共API接口 NotificationService.notify()
- 事件订阅协议
- 现有测试全部通过

验收：npm test 通过 + TypeScript strict 编译零错误"
```

### 完整工作流

```mermaid
sequenceDiagram
    participant D as 开发者
    participant CC as Claude Code
    
    D->>CC: 解释形态：分析现有架构
    CC-->>D: 架构分析报告
    
    D->>CC: 编排形态：规划任务序列
    CC-->>D: 实现计划（5个原子步骤）
    
    Note over D,CC: 循环执行每个原子步骤
    loop 步骤 1-5
        D->>CC: 生成形态：实现步骤N
        CC-->>D: 代码 + 自动测试结果
        D->>D: 验证验收标准
    end
    
    D->>CC: 审查形态：安全审计
    CC-->>D: 安全问题列表
    
    D->>CC: 调试形态：修复安全问题
    CC-->>D: 修复代码 + 测试通过
    
    D->>CC: 重构形态：代码结构优化
    CC-->>D: 重构后代码 + 测试通过
    
    D->>D: 最终验证：完整功能测试
```

---

## 十、七大反模式速查表

以下汇总了最致命的Claude Code Prompt反模式及其修复方案：

| # | 反模式 | 典型表现 | 后果 | 修复方案 |
|---|--------|---------|------|---------|
| 1 | 蒙眼式请求 | "修复这个bug"、"让代码更好" | 代理盲目猜测 | 用具体指标替代主观描述 |
| 2 | 零上下文 | "添加认证"（无文件引用） | 代理发明不存在的模式 | 使用@引用文件和CLAUDE.md |
| 3 | 一锅端 | "构建完整的电商系统" | 上下文溢出，连锁失败 | 分解为可验证的原子任务 |
| 4 | 无验收标准 | "写一个重试函数" | 代理无法判断何时停止 | 添加自动化验收命令 |
| 5 | 主观验收 | "让代码更干净" | 结果与预期不匹配 | 翻译为可量化的指标 |
| 6 | 无边界调试 | "测试挂了帮我修" | 代理搜索整个代码库 | 提供错误输出和范围限定 |
| 7 | 万能审查 | "检查有没有问题" | 输出浮于表面 | 指定审查维度和参照标准 |

**反模式修复的黄金法则**：每条Prompt都应该能回答三个问题——**做什么（What）、不做什么（Not）、怎么算做完（Done）**。

---

## 十一、Prompt质量自检清单

在发送任何Claude Code指令前，用以下清单快速检查：

- [ ] **目标明确**：是否清楚地描述了期望的产出？
- [ ] **范围限定**：是否指定了涉及的文件/目录？
- [ ] **约束完整**：是否列出了"不要做"的边界？
- [ ] **验收标准**：是否有可自动化运行的验证方式？
- [ ] **上下文引用**：是否引用了相关的@文件和@CLAUDE.md？
- [ ] **格式指定**：是否说明了期望的输出格式？
- [ ] **原子性**：任务是否可以在1-3轮对话内完成？

如果你的Prompt通过了以上所有检查，它大概率是一条高质量的Prompt。

```mermaid
flowchart LR
    A[写好Prompt] --> B{目标明确?}
    B -->|No| C[补充具体描述]
    B -->|Yes| D{范围限定?}
    D -->|No| E[添加@文件引用]
    D -->|Yes| F{有验收标准?}
    F -->|No| G[添加自动化验证命令]
    F -->|Yes| H{任务原子性?}
    H -->|No| I[分解为多个子任务]
    H -->|Yes| J[发送Prompt]
    C --> B
    E --> D
    G --> F
    I --> H
```

---

## 延伸阅读

1. **Anthropic官方Prompt工程指南**：`platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices` — Anthropic出品的权威Prompt最佳实践
2. **Claude Code Prompt Taxonomy**：`kevinkinnett.com/posts/claude-code-prompt-taxonomy/` — 六种Prompt形态的原创分类框架
3. **Claude Code Anti-Patterns Guide**：`slava-kudzinau.github.io/cc-guide/docs/07-reference-troubleshooting/04-antipatterns.html` — 完整的反模式参考手册
4. **Claude Code Handbook**：`github.com/ThamJiaHe/claude-code-handbook` — 220+来源的综合指南，含Prompt工程专题
5. **Atomic Task Design**：`ralphable.com/blog/claude-code-prompt-mistakes-developers-2026` — 原子任务设计方法论详解

## 训练营适用性评估

| 评估维度 | 说明 |
|----------|------|
| **适合训练营类型** | 中级开发者训练营（已掌握Claude Code基本操作） |
| **教学时长** | 4-5小时（含实操练习） |
| **实操建议** | 学员携带自己的真实项目，现场对6种形态逐一练习 |
| **考核方式** | 给出同一个需求，学员分别用弱Prompt和强Prompt执行，对比结果差异 |
| **分组建议** | 2-3人一组，一人写Prompt，一人观察代理行为，一人记录Token消耗和产出质量 |

## 参考来源

1. [A Taxonomy of Claude Code Prompt Shapes](https://www.kevinkinnett.com/posts/claude-code-prompt-taxonomy/) — Kevin Kinnett提出的六种Prompt形态分类框架，含反模式分析
2. [7 Claude Code Prompt Mistakes Developers Are Still Making in 2026](https://ralphable.com/blog/claude-code-prompt-mistakes-developers-2026) — 原子任务设计方法论与常见错误修复
3. [Claude Code Anti-Patterns & Common Mistakes](https://slava-kudzinau.github.io/cc-guide/docs/07-reference-troubleshooting/04-antipatterns.html) — Claude Code完整技术指南中的反模式章节
4. [Prompting Best Practices for Claude Code](https://uxplanet.org/prompting-best-practices-for-claude-code-62a914e0fca9) — UX Planet上的Claude Code Prompt工程综合指南
5. [Claude Code Handbook](https://github.com/ThamJiaHe/claude-code-handbook) — 220+验证来源的Claude Code Prompt工程与使用指南（持续更新至2026年3月）

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)