修改前确认需求规则

核心原则

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

禁止行为

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

正确流程

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

示例

❌ 错误：

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

✅ 正确：

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

特别注意

当用户提问关于某个配置/功能时，可能是：

询问含义（只需解释）
报告问题（需要先分析）
请求修改（需要先确认范围）

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

代码修改规则

1. 文档生成

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

2. 测试类管理

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

3. 修改前确认

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

4. 语言使用

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