方案设计模板

基于需求分析，AI 输出至少 2 个可选方案并推荐一个，写入 Issue comment。

输出格式

## 方案设计

### 方案对比

| 维度 | 方案 A: <名称> | 方案 B: <名称> |
|------|---------------|---------------|
| 思路 | <一句话> | <一句话> |
| 改动量 | <文件数/行数估计> | <文件数/行数估计> |
| 优点 | <列出> | <列出> |
| 缺点 | <列出> | <列出> |
| 风险 | <列出> | <列出> |

### 推荐方案
**方案 X**，理由：
- <理由1>
- <理由2>

### 关键决策
- <决策点1>: <为什么这样选>
- <决策点2>: <为什么这样选>

### 风险与缓解
| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|----------|
| <描述> | 低/中/高 | <描述> | <措施> |

示例

## 方案设计

### 方案对比

| 维度 | 方案 A: Options 字段注入 | 方案 B: 接口抽象 |
|------|------------------------|-----------------|
| 思路 | 将 git 函数指针放入 SyncOptions struct | 定义 GitRunner 接口，实现真实/测试两个版本 |
| 改动量 | ~4 files, ~40 lines | ~6 files, ~80 lines (新文件+接口定义) |
| 优点 | 与 clone.go/fork.go 已有模式一致；改动小 | 类型安全；IDE 自动补全 |
| 缺点 | 函数签名重复声明 | 过度设计，仅 2 个函数不值得抽象 |
| 风险 | 字段遗漏编译即报错 | 接口变更需改多处 |

### 推荐方案
**方案 A**，理由：
- 与项目现有模式 (clone.go, fork.go) 一致，降低认知负担
- 改动量小，4 文件即可完成
- Options struct 已有 10+ 函数字段，加两个符合惯例

### 关键决策
- repo/sync 的 GitRun 签名: 使用 `func(string, map[string]string, ...string)` (dir, env, args) 而非旧签名，统一为 RunInDirWithEnv 模式
- pr/sync 的 syncCommits: 改为接收函数参数而非访问 opts 字段，保持纯函数语义

### 风险与缓解
| 风险 | 概率 | 影响 | 缓解措施 |
|------|------|------|----------|
| clone 调用 (dir="" 场景) 行为差异 | 低 | clone 失败 | RunInDirWithEnv 在 dir="" 时不设 cmd.Dir，行为等价于 RunWithEnv |
| 测试 mock 签名不匹配 | 中 | 编译失败 | go test 编译即发现，不会漏到线上 |