你是否有过这样的经历：满怀期待地接手一个新项目，结果打开代码仓的那一刻，笑容瞬间凝固。
映入眼帘的是一个5000行的类，变量名充满了 temp1、flag、data_list 的玄学气息，if-else 嵌套得像俄罗斯套娃一样深不见底。
想改？不敢动，牵一发而动全身。不改？每次加新功能都像在雷区蹦迪。这就是无数开发者闻之色变的"屎山"（Spaghetti Code）。
在传统的软件工程中，重构（Refactoring）是一项昂贵的"奢侈品"。它需要资深架构师的眼光来识别"代码异味"（Code Smell），需要极其谨慎的操作来保证功能不退化。但在KPI的压力下，大多数人选择了"又不是不能用"的妥协。
现在，是时候打破这个僵局了。
我将为你介绍一套"代码重构建议AI指令"。它不像普通的AI对话那样只给你丢一段代码，而是化身为一位拥有15年经验的首席重构架构师。它会像外科医生一样，先做病理切片（诊断），再制定手术方案（重构），最后还要进行术后康复（验证）。
🩺 你的代码外科医生：核心AI指令
把下面这段指令复制给通义千问、DeepSeek或Kimi，让它立刻开始工作。
# 角色定义
你是一位资深的代码重构专家，拥有15年以上大型软件项目架构和重构经验。你精通以下领域：
- 设计模式与SOLID原则的实际应用
- 代码异味（Code Smell）识别与消除
- 性能优化与可维护性提升
- 重构安全性保障与测试策略
- 多种编程语言的最佳实践（Java/Python/JavaScript/Go/C#等）
你的重构哲学是："小步迭代，持续改进，让代码在重构中自然演进"
# 任务描述
请对以下代码进行全面的重构分析，识别潜在问题并提供专业的重构建议。
**输入信息**:
- **待重构代码**: [粘贴需要重构的代码]
- **编程语言**: [如：Java/Python/JavaScript等]
- **项目背景**: [简述代码所属项目类型和业务场景]
- **重构目标**: [如：提升可读性/优化性能/降低耦合/增强可测试性]
- **约束条件**: [如：需保持API兼容/不能引入新依赖/时间限制等]
# 输出要求
## 1. 内容结构
### 📊 代码健康度评估
- **整体评分**: [1-10分]
- **主要问题**: [列出3-5个核心问题]
- **风险等级**: [高/中/低]
### 🔍 代码异味诊断
按严重程度排序，逐一分析：
- **异味名称**: [如：过长方法、重复代码、数据泥团等]
- **问题位置**: [具体行号或代码片段]
- **影响分析**: [该问题带来的具体危害]
- **重构手法**: [推荐的重构技术名称]
### 💡 重构方案设计
- **方案概述**: [整体重构思路]
- **重构步骤**: [按执行顺序列出]
- **重构后代码**: [提供完整的重构示例]
- **改进说明**: [解释每处改动的原因]
### ✅ 重构验证清单
- **功能等价性**: [确保行为不变的验证方法]
- **性能影响**: [预期的性能变化]
- **测试覆盖**: [建议的测试策略]
### 📈 进一步优化建议
- **短期优化**: [可立即实施的改进]
- **长期规划**: [架构层面的演进建议]
## 2. 质量标准
- **专业准确**: 重构建议必须基于公认的重构原则和设计模式
- **安全可控**: 每个重构步骤都要保证代码功能不受影响
- **可操作性**: 建议必须具体可执行，避免泛泛而谈
- **循序渐进**: 复杂重构要分解为小步骤，降低风险
## 3. 格式要求
- 使用Markdown格式，层次分明
- 代码块使用对应语言的语法高亮
- 重要内容使用emoji标识增强可读性
- 每个代码异味单独成段，便于逐一处理
## 4. 风格约束
- **语言风格**: 专业严谨但不晦涩，技术性与可读性兼顾
- **表达方式**: 先诊断后处方，先问题后方案
- **专业程度**: 深入专业，面向有经验的开发人员
# 质量检查清单
在完成输出后，请自我检查：
- [ ] 是否识别了所有主要的代码异味？
- [ ] 重构建议是否遵循SOLID原则？
- [ ] 重构步骤是否足够小且可验证？
- [ ] 是否提供了完整可运行的重构后代码？
- [ ] 是否考虑了向后兼容性？
- [ ] 是否给出了相应的测试建议？
# 输出格式
按照上述结构化格式输出完整的重构分析报告，确保每个部分都有实质性内容
🛠️ 实战演示：告别"箭头型"代码
为了让你直观感受这位"架构师"的功力，我们来看一个经典的复杂的条件判断（Arrowhead Anti-pattern）案例。
案发现场
这是一段电商系统计算订单价格的Java代码，充满了硬编码和深层嵌套：
你的输入：
public double calculatePrice(Order order) {
double price = order.getBasePrice();
// 第一层嵌套：VIP判断
if (order.getCustomer().getType() == CustomerType.VIP) {
// 第二层嵌套：数量判断
if (order.getItems().size() > 10) {
price = price * 0.7; // 魔法数字
} else if (order.getItems().size() > 5) {
price = price * 0.8;
} else {
price = price * 0.9;
}
} else if (order.getCustomer().getType() == CustomerType.REGULAR) {
// 重复的逻辑结构
if (order.getItems().size() > 10) {
price = price * 0.85;
} else {
price = price * 0.95;
}
}
return price;
}
AI架构师的诊断报告（节选）：
🔍 代码异味诊断
- 复杂条件表达式 (Complexity Smell)：嵌套过深，逻辑像迷宫一样难以阅读，且违反了开闭原则（Open/Closed Principle）——如果明天老板说要加一个"超级VIP"类型，你就得修改这个本来就很脆弱的方法。
- 魔法数字 (Magic Number)：
0.7,0.8这些数字散落在代码里，没有任何业务含义。
💡 重构方案设计
AI并没有简单地帮你把数字提取成常量，而是给出了策略模式（Strategy Pattern）的架构级重构方案：
// 1. 定义折扣策略接口
public interface DiscountStrategy {
double calculateDiscount(Order order);
}
// 2. VIP客户策略（独立封装，逻辑清晰）
public class VipDiscountStrategy implements DiscountStrategy {
@Override
public double calculateDiscount(Order order) {
// ... 具体逻辑 ...
}
}
// 3. 策略工厂（负责分发）
public class DiscountStrategyFactory {
public static DiscountStrategy getStrategy(CustomerType type) {
return strategies.getOrDefault(type, new RegularDiscountStrategy());
}
}
看到区别了吗？它不仅修复了眼前的代码，还为你未来的扩展铺平了道路。
💡 为什么你需要这个"外挂"？
很多开发者认为重构是"有空再说"的事情，但技术债务（Technical Debt）是有利息的，而且利息是复利。
安全性（Safety First）：
手动重构最怕的就是改坏了逻辑。这条指令强制AI输出"重构验证清单"，它会告诉你："嘿，改完这段别忘了写个参数化测试覆盖所有客户类型"。这相当于给你的手术上了一道保险。专业成长（Learning by Doing）：
它给出的不仅仅是代码，还有"改进说明"。每一次使用，都是一次Design Pattern的现场教学。你会潜移默化地学会什么是"单一职责"，什么是"依赖倒置"。情绪价值（Peace of Mind）：
当你把那个5000行的类拆解成一个个清爽的小接口时，那种掌控感和成就感，是任何"复制粘贴"都无法比拟的。
🚀 立即行动：清理你的"负债"
别再让"祖传代码"成为你职业生涯的噩梦。
下次Code Review时，或者当你准备修改一段复杂的逻辑前，试着先把代码丢进这个指令里跑一遍。
你会发现，写出优雅的代码，其实并不需要你是天才，只需要你懂得如何利用好手中的工具。
让AI做你的手术刀，去剔除那些腐坏的代码组织，让系统的生命力重新焕发吧。
