pair

# /pair - 结对编程模式

> **核心理念**: 人机协作，每个关键节点确认后再继续。

## 与 /cc-best:iterate 的区别

| 维度     | `/cc-best:pair`              | `/cc-best:iterate`         |
| -------- | -------------------- | ------------------ |
| 决策方式 | 询问用户确认         | 自主推断           |
| 用户参与 | 持续参与             | 仅在阻塞时         |
| 适用场景 | 学习、讨论、敏感操作 | 明确任务的批量执行 |
| 风险控制 | 高（每步确认）       | 中（事后检查）     |

---

## 适用场景

### 推荐使用 /cc-best:pair

- 🎓 **学习新技术** - 需要理解每个步骤
- 💬 **设计讨论** - 架构决策需要权衡
- ⚠️ **敏感操作** - 数据库迁移、生产部署
- 🔍 **代码审查** - 需要解释和讨论
- 🐛 **复杂调试** - 需要人工判断方向
- 📝 **需求澄清** - 边界不清晰的任务

### 推荐使用 /cc-best:iterate

- ✅ 任务清单明确
- ✅ 完成标准清晰
- ✅ 风险可控
- ✅ 不需要频繁决策

---

## 工作流程

```
┌─────────────────────────────────────────────────────────────────┐
│                     结对编程工作流                               │
├─────────────────────────────────────────────────────────────────┤
│                                                                 │
│  1. 理解任务                                                    │
│     └─ 读取需求 → 向用户确认理解是否正确                         │
│                                                                 │
│  2. 方案设计                                                    │
│     └─ 提出方案 → 询问用户选择 → 确认后继续                      │
│                                                                 │
│  3. 逐步实现                                                    │
│     └─ 每个关键步骤 → 展示计划 → 确认后执行                      │
│                                                                 │
│  4. 验证结果                                                    │
│     └─ 展示结果 → 询问是否满意 → 调整或继续                      │
│                                                                 │
│  5. 总结提交                                                    │
│     └─ 总结变更 → 确认提交信息 → 执行提交                        │
│                                                                 │
└─────────────────────────────────────────────────────────────────┘
```

---

## 确认节点

### 必须确认的节点

| 节点       | 确认内容     | 示例问题                     |
| ---------- | ------------ | ---------------------------- |
| 需求理解   | 理解是否正确 | "我理解你需要...，对吗？"    |
| 方案选择   | 多个方案时   | "方案 A/B/C，你倾向哪个？"   |
| 破坏性操作 | 删除、重置等 | "即将删除 X，确认吗？"       |
| 外部调用   | API、数据库  | "即将调用生产 API，确认吗？" |
| 提交代码   | commit 内容  | "提交信息：...，确认吗？"    |

### 可以自主执行的操作

- 读取文件
- 搜索代码
- 运行测试（只读）
- 代码格式化
- 生成文档

---

## 沟通原则

### 主动解释

```
✅ 好的沟通：
"我打算用 Strategy 模式来实现这个功能，因为...
优点是：1. 2. 3.
缺点是：1. 2.
你觉得这个方案如何？"

❌ 不好的沟通：
"我用 Strategy 模式实现了。"
（没有解释原因，没有询问意见）
```

### 提供选项

```
✅ 好的提问：
"有两种实现方式：
A) 使用 Redis 缓存（快但需要额外基础设施）
B) 使用内存缓存（简单但重启后丢失）
考虑到你的场景，我建议 A，你觉得呢？"

❌ 不好的提问：
"你想用什么缓存？"
（没有提供背景和建议）
```

### 承认不确定

```
✅ 诚实：
"这个问题我不太确定，可能的原因有：
1. ...
2. ...
需要我进一步调查吗？"

❌ 假装确定：
"这肯定是因为 X。"
（实际上并不确定）
```

---

## 学习辅助模式

当用户表示想学习时，启用详细解释：

```
用户："我想学习这个过程"

Claude 行为调整：
├─ 每个步骤前解释"为什么这样做"
├─ 展示中间结果
├─ 解释错误和调试过程
├─ 提供相关文档链接
└─ 鼓励用户提问
```

---

## 敏感操作保护

### 高风险操作清单

| 操作类型      | 风险等级 | 处理方式                |
| ------------- | -------- | ----------------------- |
| 删除文件/数据 | 🔴 高    | 必须二次确认 + 备份提醒 |
| 数据库 DDL    | 🔴 高    | 显示 SQL + 确认         |
| 生产环境操作  | 🔴 高    | 警告 + 确认             |
| Git 历史修改  | 🟠 中    | 解释影响 + 确认         |
| 依赖升级      | 🟠 中    | 显示变更 + 确认         |
| 配置修改      | 🟡 低    | 显示 diff + 确认        |

### 确认模板

```
⚠️ 敏感操作确认

操作：[操作描述]
影响：[潜在影响]
可逆性：[是否可回滚]

确认执行？
```

---

## 会话管理

### 上下文控制

```
结对编程中的上下文管理：
├─ 保持对话连贯性（不主动 /clear）
├─ 定期总结进度
├─ 用户可随时要求总结当前状态
└─ 用户决定何时清理上下文
```

### 暂停和恢复

```
暂停时：
"好的，我们目前完成了：
1. [已完成项]
2. [已完成项]

待继续：
- [待办项]

随时说'继续'恢复工作。"
```

---

## 快速开始

```bash
# 启动结对编程模式
/cc-best:pair

# 带上下文启动
/cc-best:pair 我想实现用户认证功能，帮我一起设计和实现

# 学习模式
/cc-best:pair --learn 教我如何写单元测试
```

---

## 示例对话

```
用户: /cc-best:pair 帮我重构这个函数

Claude: 好的，让我先看看这个函数...

[读取文件]

我看到这个函数有以下问题：
1. 函数过长（80 行）
2. 职责不单一（同时处理验证和业务逻辑）
3. 嵌套过深（4 层）

我建议的重构方案：
A) 提取验证逻辑到单独函数
B) 使用早返回减少嵌套
C) 拆分为 3 个小函数

你觉得这个方向对吗？要我先从哪个开始？

用户: 从 A 开始

Claude: 好的，我来提取验证逻辑...

[展示代码变更]

这是提取后的验证函数，变更点：
- 原来在第 15-30 行的验证逻辑移到了新函数
- 主函数现在调用 validate_input()
- 测试仍然通过

看起来符合预期吗？要继续 B 吗？
```

> **记住**: Pair 模式的价值在于人机协同——AI 提供方案，人做决策。每个确认点都是学习和纠偏的机会。