# 常见陷阱与对策

深入工作流之前，了解这些毁掉批量 PR 的常见错误：

## 1. 将不相关的 issue 放在一起

- 把 CLI 功能、webchat 修复和 messaging 重构混在一个批量里
- **为什么不行**：缺乏主题连贯性，审查痛苦、测试复杂
- **正确做法**：按领域分组 — 全部 messaging 修复，或全部 CLI 改进

## 2. 批量过载（太多 issue）

- 试图把 8+ 个 issue 塞进"一个巨型 PR"
- **为什么不行**：变成无法审查的怪物；一个 issue 卡住，全部卡住
- **正确做法**：最多 2-5 个 issue，或按主题拆分（messaging 批次 1、批次 2）

## 3. 忽略 issue 间的依赖

- 实施 issue B 时发现它依赖 issue A 的重构
- **为什么不行**：代码跑不起来，浪费实施时间
- **正确做法**：先检查依赖，先实施重构再修 bug

## 4. 每个 issue 只跑单元测试

- 隔离测试每个修复，从不一起测试
- **为什么不行**：错过 issue 交互产生的集成 bug
- **正确做法**：所有 issue 实施完毕后运行完整测试套件

## 5. PR 描述含糊

- 写 "Fixes several issues" 作为 PR 描述
- **为什么不行**：审查者无法理解改了什么或为什么改
- **正确做法**：按 issue 分别文档化，包含 problem/solution/impact 结构

## 6. 实施时发现 issue 比预期复杂

- 预估 2 小时，实际需要 1 天
- **为什么不行**：拖垮整个批量的时间线
- **正确做法**：Phase 1 分析时保守估算工作量（乘以 1.5 倍）；超出批量预算时果断从批量中移除

## 7. 与已有 PR 冲突（重复工作或合并冲突）

- 选了已有 PR 正在处理的 issue，或修改了已有 PR 涉及的文件
- **为什么不行**：浪费实施时间，PR 之间产生合并冲突，审查者困惑
- **正确做法**：Phase 3 选择前必须执行 3.0 PR 冲突检查 — 排除已有 PR 覆盖的 issue 和文件重叠的 issue
