Bug Reflection & Fix Report#

这个 Skill 用于管理 Bug 修复的完整流程，包括问题分析、检查验证、用户沟通和经验沉淀。

触发条件#

当用户反馈有 Bug 时，必须立即触发此 Skill。

一、问题分析阶段#

1.1 收集 Bug 信息#

• 详细记录 Bug 的表现形式
• 了解触发 Bug 的操作步骤
• 记录错误日志、截图等相关信息

1.2 推断问题模块#

永远不要直接打补丁。必须根据 Bug 表现推断可能产生问题的模块：

1. 分析错误信息中的关键提示
2. 定位相关代码模块
3. 检查模块之间的调用关系

二、检查验证阶段#

2.1 对比官方文档#

检查模块的逻辑语法是否正确：

1. 查阅官方文档说明
2. 对比实际代码实现与文档规范
3. 检查 API 使用方式、参数类型、返回值等

2.2 性能检查#

1. 检查代码是否存在性能问题
2. 分析时间复杂度和空间复杂度
3. 检查是否存在内存泄漏、死循环等问题

2.3 向用户确认#

如果检查后认为 没有问题，询问用户是否需要打补丁时，必须：

• 告知用户已检查的具体模块
• 说明检查的依据（官方文档、代码逻辑等）
• 解释为什么当前实现是合理的
• 提供替代方案或建议（如果用户仍希望修改）

三、Fix Report 书写规范#

3.1 记录内容#

修复完 Bug 后，必须将以下内容写入 Fix Report：

1. Bug 描述：问题的具体表现

2. 问题根因：导致 Bug 的根本原因

3. 尝试过的方案：

   • 成功的尝试
   • 失败的尝试（以及失败原因）

4. 最终解决方案：采用的修复方式

5. 检查清单：

   • 对比了哪些官方文档
   • 检查了哪些模块
   • 性能检查结果

6. 经验教训：从这个 Bug 中学到什么

3.2 报告格式示例#

markdown

# Fix Report - [Bug名称]

## Bug 描述
[详细描述问题表现]

## 问题根因
[分析导致问题的根本原因]

## 尝试记录
### 尝试 1：[方案名称]
- 结果：成功/失败
- 原因：[成功原因/失败原因]

### 尝试 2：[方案名称]
- 结果：成功/失败
- 原因：[成功原因/失败原因]

## 最终方案
[采用的修复方式]

## 检查清单
- [ ] 已对比官方文档：XXX
- [ ] 已检查模块：XXX
- [ ] 性能检查：XXX

## 经验教训
[从这个 Bug 学到的经验]

四、经验复用#

1. 在修复新的 Bug 时，查阅历史 Fix Report
2. 确保犯过的错误不再重复
3. 将常见的排查方法整理成知识库
4. 定期回顾 Fix Report，优化排查流程

关键原则#

1. 不盲目打补丁：先分析问题，找到根因
2. 彻底检查：对比官方文档，检查逻辑语法和性能
3. 透明沟通：向用户清晰说明检查过程和结果
4. 经验沉淀：所有尝试都记录到 Fix Report