| 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869 |
- # 修改前确认需求规则
- ## 核心原则
- **在修改任何代码之前，必须先确认用户的真实需求。**
- ## 禁止行为
- - **永远不要**在未理解用户需求的情况下开始修改代码
- - **永远不要**假设用户的意图然后直接行动
- - **永远不要**一次性做大量修改而不先确认方向
- ## 正确流程
- 1. **先理解** - 仔细阅读用户的描述，确保理解问题
- 2. **再确认** - 如果有任何不确定，先向用户确认：
- - 用户想要达到什么效果？
- - 现有逻辑是什么？
- - 需要改变什么？
- 3. **后执行** - 确认清楚后再进行修改
- ## 示例
- ❌ 错误：
- ```
- 用户: show_preset_count这个呢
- 助手: [直接开始修改代码添加功能]
- ```
- ✅ 正确：
- ```
- 用户: show_preset_count这个呢
- 助手: 这个配置项目前被定义了但没有实际使用。您是想让我：
- 1. 让它生效来控制预设数量显示？
- 2. 删掉这个冗余配置？
- 3. 还是只是想了解它的含义？
- ```
- ## 特别注意
- 当用户提问关于某个配置/功能时，可能是：
- - 询问含义（只需解释）
- - 报告问题（需要先分析）
- - 请求修改（需要先确认范围）
- **不要默认为"请求修改"然后直接动手！**
- ## 代码修改规则
- ### 1. 文档生成
- - **不要生成总结说明文档**，除非用户明确要求
- - 不要创建 README、CHANGELOG 等文档文件
- - 完成工作后只需简短说明即可
- ### 2. 测试类管理
- - **不要编写大量测试类**，尽量复用现有测试类
- - 除非用户明确要求创建新的测试类
- - 优先在已有测试类中添加测试方法
- ### 3. 修改前确认
- - **修改代码之前先展示修改方案**或提出疑问
- - 除非用户直接明确要求立即修改
- - 让用户确认方案后再执行
- ### 4. 语言使用
- - **使用中文回答**用户的所有问题
- - 代码注释和变量名保持原有风格
- - 文档和说明使用中文
|
