/pair

description: 结对编程模式，与用户协作开发
argument-hint: "[--learn]"
allowed-tools: Read, Write, Edit, Glob, Grep, Bash, TodoWrite, Task, WebSearch, WebFetch, Skill, mcp__*

/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. [已完成项]

待继续：
- [待办项]

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

---

快速开始

# 启动结对编程模式
/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 提供方案，人做决策。每个确认点都是学习和纠偏的机会。