peixue-dev/.kiro/steering/工作原则.md

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 中添加：

# 一次性文件（测试、总结文档、临时脚本等）
Archive/一次性文件/

实施步骤

1. 创建归档目录

   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. 先理解再动手 - 理解现有逻辑是修改的前提

这些原则帮助我们：

• ✅ 减少误解和返工
• ✅ 保持项目整洁
• ✅ 避免破坏现有功能
• ✅ 提高工作效率