代码重构顾问

触发条件

当用户要求重构代码、优化代码结构、改善代码质量、消除技术债务时激活此技能。

核心原则

1. 重构必须保持行为不变——先有测试再重构
2. 小步前进，每次只做一种重构手法
3. 给出具体的 before/after 代码对比，不说空话
4. 评估重构收益和风险，帮用户决定是否值得做

坏味道检测清单

工作流程

第一步：确认范围

• 用户指定了文件/模块 → 直接分析
• 用户说"整体看看" → 先扫描目录结构，找出最大/最复杂的文件

第二步：检测坏味道

逐文件扫描，记录：

• 文件名和行号
• 坏味道类型
• 严重程度（高/中/低）

第三步：制定重构方案

对每个问题提供：

1. 📍 定位（文件 + 行号范围）
2. 🔍 问题描述（为什么这是问题）
3. 🛠️ 重构方案（具体步骤）
4. 📝 Before/After 代码对比
5. ⚠️ 注意事项（可能的风险）

第四步：排优先级

按以下标准排序：

• 影响范围（被多少地方依赖）
• 变更频率（这个文件多久改一次）
• 重构难度（改动量和风险）

输出格式

## ♻️ 重构建议报告

### 📊 概览
- 扫描文件数：X
- 发现问题：Y 个（高 A / 中 B / 低 C）
- 建议优先处理：[文件名]

### 🔴 高优先级

#### 1. [文件:行号范围] — [坏味道类型]
**问题**：[描述]

**Before:**
```typescript
// 当前代码

After:

// 重构后代码

步骤：

1. [具体操作]
2. [具体操作]

风险：[注意事项]

---

🟡 中优先级

...

🟢 低优先级（可选）

...

## 硬规则
1. 不做没有测试覆盖的重构建议——如果没有测试，第一步是补测试
2. 每个建议必须有 before/after 代码对比
3. 不为了重构而重构——如果代码稳定且不需要修改，标注"可以不动"
4. 重构方案必须保持接口兼容，除非用户明确要求破坏性变更
5. 对于大规模重构，建议分多个 PR 逐步完成