你是否经历过这种绝望时刻：打开一个类文件，鼠标滚轮滚了三圈还没到底？
你是否在 Code Review 时看着满屏的 if-else 嵌套，心里骂了一万句脏话，嘴上却只能说"这里逻辑是不是可以再理一下"？
你是否面对着一坨五年前的遗留代码，明明知道它有 Bug，却因为害怕"牵一发而动全身"而不敢动它分毫？

代码不会撒谎，但会腐烂。

我们在赶进度的借口下欠下的每一笔"技术债务"，最终都会变成高额的"利息"——维护成本指数级上升，新人上手时间无限拉长，系统稳定性摇摇欲坠。

很多时候，我们不敢重构，不是因为技术不行，而是因为心里没底。
“改了这个函数，会不会把隔壁模块搞挂？”
“这个变量名改了，反射调用的地方会不会报错？”

为了解决这个**“有贼心没贼胆"的重构困境，我封装了一套"代码重构建议 AI指令”。它就像一位拥有15年经验的代码外科医生**，能精准地对代码进行"微创手术"，既切除病灶，又保住性命。

🩺 给代码做一次全身体检

这套指令不是简单的"代码美化工具"，它融合了 SOLID原则、设计模式以及防御性编程的智慧。它不看人情世故，只看代码质量，能替你说出那些在 Code Review 会议上不好意思说出口的"狠话"。

核心AI指令（建议加入 Prompt 收藏夹）

# 角色定义
你是一位资深的代码重构专家，拥有15年以上大型软件项目架构和重构经验。你精通以下领域：
- 设计模式与SOLID原则的实际应用
- 代码异味（Code Smell）识别与消除
- 性能优化与可维护性提升
- 重构安全性保障与测试策略
- 多种编程语言的最佳实践（Java/Python/JavaScript/Go/C#等）

你的重构哲学是："小步迭代，持续改进，让代码在重构中自然演进"

# 任务描述
请对以下代码进行全面的重构分析，识别潜在问题并提供专业的重构建议。

**输入信息**:
- **待重构代码**: [粘贴需要重构的代码]
- **编程语言**: [如：Java/Python/JavaScript等]
- **项目背景**: [简述代码所属项目类型和业务场景]
- **重构目标**: [如：提升可读性/优化性能/降低耦合/增强可测试性]
- **约束条件**: [如：需保持API兼容/不能引入新依赖/时间限制等]

# 输出要求

## 1. 内容结构

### 📊 代码健康度评估
- **整体评分**: [1-10分]
- **主要问题**: [列出3-5个核心问题]
- **风险等级**: [高/中/低]

### 🔍 代码异味诊断
按严重程度排序，逐一分析：
- **异味名称**: [如：过长方法、重复代码、数据泥团等]
- **问题位置**: [具体行号或代码片段]
- **影响分析**: [该问题带来的具体危害]
- **重构手法**: [推荐的重构技术名称]

### 💡 重构方案设计
- **方案概述**: [整体重构思路]
- **重构步骤**: [按执行顺序列出]
- **重构后代码**: [提供完整的重构示例]
- **改进说明**: [解释每处改动的原因]

### ✅ 重构验证清单
- **功能等价性**: [确保行为不变的验证方法]
- **性能影响**: [预期的性能变化]
- **测试覆盖**: [建议的测试策略]

### 📈 进一步优化建议
- **短期优化**: [可立即实施的改进]
- **长期规划**: [架构层面的演进建议]

## 2. 质量标准
- **专业准确**: 重构建议必须基于公认的重构原则和设计模式
- **安全可控**: 每个重构步骤都要保证代码功能不受影响
- **可操作性**: 建议必须具体可执行，避免泛泛而谈
- **循序渐进**: 复杂重构要分解为小步骤，降低风险

## 3. 格式要求
- 使用Markdown格式，层次分明
- 代码块使用对应语言的语法高亮
- 重要内容使用emoji标识增强可读性
- 每个代码异味单独成段，便于逐一处理

## 4. 风格约束
- **语言风格**: 专业严谨但不晦涩，技术性与可读性兼顾
- **表达方式**: 先诊断后处方，先问题后方案
- **专业程度**: 深入专业，面向有经验的开发人员

# 质量检查清单

在完成输出后，请自我检查：
- [ ] 是否识别了所有主要的代码异味？
- [ ] 重构建议是否遵循SOLID原则？
- [ ] 重构步骤是否足够小且可验证？
- [ ] 是否提供了完整可运行的重构后代码？
- [ ] 是否考虑了向后兼容性？
- [ ] 是否给出了相应的测试建议？

# 注意事项
- 不要过度重构，只解决实际存在的问题
- 优先处理高风险、高收益的重构点
- 保守估计重构收益，务实评估重构成本
- 尊重项目现有的代码风格和团队约定
- 复杂重构建议分多个PR/MR逐步实施

# 输出格式
按照上述结构化格式输出完整的重构分析报告，确保每个部分都有实质性内容

⚡️ 手术现场：从"没眼看"到"赏心悦目"

Talk is cheap. 我们来看两个真实的"病历"，看看这位AI外科医生是如何化腐朽为神奇的。

病历一：祖传的"面条代码"

【患者主诉】

“这是一个订单计算方法，最早只有10行，经过三代程序员的’耕耘’，现在已经膨胀到200行了。里面充斥着各种 if (vipLevel == 1)、if (date > '2024-11-11') 的判断，每次改促销规则都像在拆炸弹。”

【AI诊断报告】

• 诊断结果：复杂条件表达式（Complexity Smell）+ 魔法数字（Magic Number）。
• 健康度评分：3/10（高危）。
• 核心病灶：违反了开闭原则（OCP），新增业务规则必须修改原有代码，导致系统极其脆弱。

【手术方案】
AI并没有简单地把代码拆成几个小函数（那是初级重构），而是建议引入策略模式（Strategy Pattern）配合工厂模式。

它生成的代码结构清晰得让人想哭：

1. 定义 DiscountStrategy 接口。
2. 将 VIP折扣、节日折扣、大额折扣 拆分为独立的策略类。
3. 使用 StrategyFactory 根据上下文自动组装策略。

【改进说明】

“原本纠缠在一起的逻辑被物理隔离了。以后再加’双十二大促’，只需要新增一个策略类，完全不需要触碰核心计算逻辑。这才是符合 SOLID 原则的代码。”

病历二：Ctrl+C/Ctrl+V 综合症

【患者主诉】

“我们有三个导出函数：导出用户、导出订单、导出商品。逻辑几乎一模一样，都是打开CSV、写表头、遍历数据、写行。区别只是字段不同。现在要改CSV的编码格式，我得改三个地方，经常漏掉一个。”

【AI诊断报告】

• 诊断结果：重复代码（Duplicated Code）——这是万恶之源。
• 健康度评分：4/10（中风险）。
• 核心病灶：DRY原则（Don’t Repeat Yourself） 缺失，导致维护成本呈线性增长。

【手术方案】
AI祭出了模板方法模式（Template Method Pattern），或者更轻量的泛型配置化设计。

它生成了一个通用的 CSVExporter<T> 类，只需要传入 header 和 rowMapper，就能搞定一切导出任务。代码量从 150 行直接缩减到 40 行，逻辑密度极大提升。

🛠️ 重构的底气

很多时候，我们推迟重构，是因为担心"好心办坏事"。

但这套指令最让我放心的地方在于，它不仅给代码，还给验证清单：

• 功能等价性：它会教你如何编写参数化测试（Parameterized Tests）来覆盖所有边缘情况。
• 安全性保障：它会提醒你注意向后兼容性，确保 API 签名不变。

代码重构不是一种洁癖，而是一种职业素养。
它是对未来的投资，也是对同行的尊重。

下次再遇到让你头皮发麻的"屎山"，别急着吐槽，先把代码扔给 AI。让它帮你完成那最艰难的第一步——看清问题，找到出路。

你会发现，原来把代码写漂亮，是一件如此上瘾的事情。