Fix

根据参数选择模式：

- `/fix [问题描述]` → 快速修复（定位 → 修复 → 验证）
- `/fix debug [问题描述]` → 系统化调试（复现 → 假设 → 验证 → 报告，不直接改代码）

参数值：「$ARGUMENTS」

---

## 模式 1：快速修复（默认）

快速修复问题，一条龙服务。

### ⚠️ 来自 code-review 的变更范围约束

**当输入以 `[code-review]` 开头时**，必须遵循以下强制规则：

| 规则 | 说明 |
|------|------|
| 只改变更范围内的文件 | 仅修改 `git diff` 涉及的文件，禁止修改未变更的代码 |
| 禁止重构 | 不做代码风格调整、不重命名变量、不提取函数 |
| 禁止改变现有行为 | 修复不能导致原有正常功能不可用 |
| 最小修改 | 每个问题用最少的代码改动解决，不做额外"顺手"优化 |

### 流程

#### 1. 定位问题

根据描述搜索相关代码，找到问题根源。

#### 2. 修复

直接修复，不需要确认（除非有多个方案）。

#### 3. 验证

如果有相关测试，运行测试验证。

#### 4. 输出

```
## 问题
[问题描述]

## 原因
[根因分析]

## 修复
[修改的文件和内容]

## 验证
✅ 测试通过 / ⚠️ 需手动验证
```

---

## 模式 2：debug（系统化调试）

系统化调试问题，遵循科学调试方法。**本模式仅分析，不修改代码。**

### 流程

#### 1. 复现问题

- 确定最小复现步骤
- 记录错误信息和上下文
- 确认问题可稳定复现

#### 2. 收集线索

- 搜索相关代码
- 查看最近的变更（git diff/log）
- 检查日志和错误信息

#### 3. 提出假设

列出 2-3 个可能的原因，按可能性排序：

```
假设 1: [最可能的原因]
假设 2: [次可能的原因]
假设 3: [其他可能]
```

#### 4. 验证假设

- 一次只改一个变量
- 记录每次验证的结果
- 直到定位根因

#### 5. 输出报告

```markdown
## 问题描述
[问题的具体表现]

## 根因分析
[问题的根本原因]

## 调试过程
1. [假设 1] → [验证结果]
2. [假设 2] → [验证结果]

## 建议修复
[修复方案，但不直接修改代码]

## 预防措施
[如何避免类似问题]
```

### 注意事项

- 本模式仅用于调试分析，不修改代码
- 如需修复，请使用 `/fix [问题描述]`
- 对于复杂问题，可能需要多轮调试