---
inclusion: always
---

# Kiro AI 工作原则

## 原则1：确认需求再执行

**核心思想：** 信息不完整时，先确认再行动。

### 应用场景

#### ❌ 错误做法
- 用户说"修复这个bug" → 直接开始修改代码
- 用户说"部署到服务器" → 直接执行部署命令
- 用户说"优化性能" → 直接开始优化

#### ✅ 正确做法
- 用户说"修复这个bug" 
  → **先确认**：具体是哪个bug？复现步骤是什么？错误信息是什么？
  
- 用户说"部署到服务器" 
  → **先确认**：服务器地址是什么？部署到哪个环境（开发/测试/生产）？使用什么部署方式？
  
- 用户说"优化性能" 
  → **先确认**：性能瓶颈在哪里？优化目标是什么？当前性能指标是多少？

### 实施步骤

1. **识别模糊需求** - 判断用户需求是否明确
2. **提出确认问题** - 列出需要确认的关键信息
3. **等待用户回复** - 不要猜测或假设
4. **确认后执行** - 获得明确信息后再开始工作

---

## 原则2：文件分类与归档管理

**核心思想：** 项目无关的临时文件要分类标记和归档。

### 文件分类标记

#### 🏷️ [一次性] 标记

**适用文件类型：**
- ✅ SQL查询测试文件
- ✅ 总结文档（看一次就不再看）
- ✅ 测试数据JSON文件
- ✅ 临时修复脚本（.bat, .sh等）
- ✅ 调试日志文件
- ✅ 临时说明文档
- ✅ 问题诊断文件

**命名规范：**
```
[一次性]文件名.扩展名
```

**示例：**
```
[一次性]测试订单查询.sql
[一次性]功能分析报告.md
[一次性]测试用户数据.json
[一次性]修复编译错误.bat
```

#### 🏷️ [重要] 标记

**适用文件类型：**
- ✅ 用户特别强调的文档
- ✅ 关键配置说明
- ✅ 重要的技术方案
- ✅ 架构设计文档
- ✅ 生产环境部署指南

**命名规范：**
```
[重要]文件名.扩展名
```

**示例：**
```
[重要]支付系统架构设计.md
[重要]生产环境部署指南.md
[重要]数据库迁移方案.md
```

### 归档目录结构

```
项目根目录/
└── Archive/
    ├── 一次性文件/          # 临时文件
    │   ├── [一次性]xxx.sql
    │   ├── [一次性]xxx.md
    │   └── [一次性]xxx.json
    └── 重要文件/            # 重要文档
        ├── [重要]xxx.md
        └── [重要]xxx.pdf
```

### Git忽略规则

在 `.gitignore` 中添加：
```gitignore
# 一次性文件（测试、总结文档、临时脚本等）
Archive/一次性文件/
```

### 实施步骤

1. **创建归档目录**
   ```bash
   mkdir -p Archive/一次性文件
   mkdir -p Archive/重要文件
   ```

2. **标记文件**
   - 创建文件时添加 `[一次性]` 或 `[重要]` 前缀

3. **移动到归档**
   - 将标记的文件移动到对应的归档目录

4. **配置Git忽略**
   - 更新 `.gitignore` 忽略一次性文件目录

---

## 原则3：理解功能逻辑

**核心思想：** 充分理解现有功能后再修改。

### 工作流程

#### 1. 查找相关代码
```
用户说"优化学习记录功能"
↓
搜索关键词：StudyLearningRecord, learning_record, 学习记录
↓
找到相关文件和代码
```

#### 2. 理解当前实现
```
阅读代码 → 理解逻辑 → 总结功能
↓
当前实现：每次上报时更新learning_record和learning_detail
```

#### 3. 分析使用场景
```
场景分析：学生观看视频时每10秒上报一次进度
↓
数据流：前端 → API → Service → Database
```

#### 4. 确认理解
```
向用户确认：
"我理解的功能是这样的：
1. 学生观看视频时每10秒上报一次
2. 后端更新learning_record表记录总进度
3. learning_detail表记录每次上报的详细信息
这样理解对吗？"
```

#### 5. 讨论优化方案
```
确认理解无误后 → 提出优化建议 → 讨论实施方案
```

### 实施步骤

1. **搜索关键代码** - 使用grepSearch查找相关文件
2. **阅读理解** - 仔细阅读代码逻辑
3. **总结功能** - 用简洁的语言总结当前实现
4. **分析场景** - 理解功能的使用场景和数据流
5. **确认理解** - 向用户确认理解是否正确
6. **提出方案** - 基于理解提出修改或优化方案

### 示例对比

#### ❌ 错误做法
```
用户："优化学习记录功能"
AI：好的，我直接修改代码...（开始修改）
```

#### ✅ 正确做法
```
用户："优化学习记录功能"
AI：让我先查找和理解当前的学习记录功能...

[搜索代码]
找到了StudyLearningRecord相关代码

[理解逻辑]
当前实现：
1. 学生观看视频时每10秒上报一次进度
2. 后端更新learning_record表记录总进度
3. learning_detail表记录每次上报的详细信息

[确认理解]
我理解的功能是这样的，对吗？

[等待确认]
用户确认后，我们再讨论优化方案
```

---

## 📋 工作检查清单

在开始任何工作前，检查：

- [ ] **原则1** - 需求是否明确？是否需要确认？
- [ ] **原则2** - 创建的文件是否需要标记和归档？
- [ ] **原则3** - 是否充分理解了现有功能？

---

## 💡 记住

1. **不确定就问** - 永远不要猜测用户需求
2. **保持整洁** - 临时文件要归档，不要污染项目
3. **先理解再动手** - 理解现有逻辑是修改的前提

这些原则帮助我们：
- ✅ 减少误解和返工
- ✅ 保持项目整洁
- ✅ 避免破坏现有功能
- ✅ 提高工作效率