# 修改前确认需求规则

## 核心原则

**在修改任何代码之前，必须先确认用户的真实需求。**

## 禁止行为

- **永远不要**在未理解用户需求的情况下开始修改代码
- **永远不要**假设用户的意图然后直接行动
- **永远不要**一次性做大量修改而不先确认方向

## 正确流程

1. **先理解** - 仔细阅读用户的描述，确保理解问题
2. **再确认** - 如果有任何不确定，先向用户确认：
   - 用户想要达到什么效果？
   - 现有逻辑是什么？
   - 需要改变什么？
3. **后执行** - 确认清楚后再进行修改

## 示例

❌ 错误：
```
用户: show_preset_count这个呢
助手: [直接开始修改代码添加功能]
```

✅ 正确：
```
用户: show_preset_count这个呢
助手: 这个配置项目前被定义了但没有实际使用。您是想让我：
1. 让它生效来控制预设数量显示？
2. 删掉这个冗余配置？
3. 还是只是想了解它的含义？
```

## 特别注意

当用户提问关于某个配置/功能时，可能是：
- 询问含义（只需解释）
- 报告问题（需要先分析）
- 请求修改（需要先确认范围）

**不要默认为"请求修改"然后直接动手！**


## 代码修改规则

### 1. 文档生成
- **不要生成总结说明文档**，除非用户明确要求
- 不要创建 README、CHANGELOG 等文档文件
- 完成工作后只需简短说明即可

### 2. 测试类管理
- **不要编写大量测试类**，尽量复用现有测试类
- 除非用户明确要求创建新的测试类
- 优先在已有测试类中添加测试方法

### 3. 修改前确认
- **修改代码之前先展示修改方案**或提出疑问
- 除非用户直接明确要求立即修改
- 让用户确认方案后再执行

### 4. 语言使用
- **使用中文回答**用户的所有问题
- 代码注释和变量名保持原有风格
- 文档和说明使用中文